Team:BU Wellesley Software/Puppetshow

From 2011.igem.org

(Difference between revisions)
 
(47 intermediate revisions not shown)
Line 23: Line 23:
/*actual content styles*/
/*actual content styles*/
-
body {width: 860px; margin:auto;}
+
body {width: 800px; margin:auto;}
#bu-wellesley_wiki_content {height:auto; line-height:100%;}
#bu-wellesley_wiki_content {height:auto; line-height:100%;}
-
#bu-wellesley_wiki_content a {color:#69d01d;}
+
/*#bu-wellesley_wiki_content a {color:#69d01d;}*/
-
#bu-wellesley_wiki_content a:hover {text-decoration:none; color:#bababa;}
+
#bu-wellesley_wiki_content a:hover {text-decoration:none; color:#3d3f3c;}
-
</style>
+
.navbar li {color: #ffffff;}
-
<link rel="stylesheet" type="text/css" href="http://cs.wellesley.edu/~hcilab/iGEM_wiki/css/ProjectSpecific.css">
+
.navbar li a {color: #ffffff;}
 +
.navbar li a:hover {background:#69d01d; color: #ffffff;}
 +
/*only use for current page content header (i.e. Team, G-nomeSurferPro, etc)*/
 +
H6 {
 +
      font-family: Helvetica;
 +
      text-transform: uppercase;
 +
      text-decoration: none;
 +
      text-align: left;
 +
      color: #3d3f3c;
 +
      font-size: 32pt;
 +
    }
 +
</style>
 +
<link rel="stylesheet" type="text/css" href="http://cs.wellesley.edu/~hcilab/iGEM_wiki/css/Team.css">
</head>
</head>
<body class="basiclayout">
<body class="basiclayout">
-
 
<div id="bu-wellesley_wiki_content">
<div id="bu-wellesley_wiki_content">
<p  style="text-align:center;"><a href="https://2011.igem.org/Team:BU_Wellesley_Software"><img src="http://cs.wellesley.edu/~hcilab/iGEM_wiki/images/banner.png" width="800px"></a></p>
<p  style="text-align:center;"><a href="https://2011.igem.org/Team:BU_Wellesley_Software"><img src="http://cs.wellesley.edu/~hcilab/iGEM_wiki/images/banner.png" width="800px"></a></p>
-
<!-- "previous page" action -->
 
-
<a class="prev browse left"></a>
 
-
<!-- root element for scrollable -->
 
-
<div class="scrollable" width="800px"> 
 
-
  <div class="items">
 
-
  <div id="comp">
 
-
<h1>Puppeteer Overview</h1>
 
-
<!-- Comp people's content here-->
 
-
<h2> Description</h2>
+
<ul id="nav">  
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/Team">Team</a></li>
 +
<li><a href="#">Project</a>
 +
<ul>
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/Project_Overview">Overview</a></li>
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/Clotho">Clotho</a></li>
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/G-nomeSurferPro">G-nome Surfer Pro</a></li>
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/OptimusPrimer">Optimus Primer</a></li>
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/Trumpet">Trumpet</a></li>
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/Puppetshow">Puppetshow</a></li>
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/eLabNotebook">eLabNotebook</a></li>
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/Wet_Lab">Wet Lab</a></li>
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/Downloads_and_Tutorials">Downloads and Tutorials</a></li>
 +
</ul>
 +
</li>
 +
<li><a href="#">Process</a>
 +
<ul>
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/Methodology">Methodology</a></li>
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/Safety">Safety</a></li>
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/Notebook">Notebook</a></li>
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/Outreach">Outreach</a></li>
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/Tips">Tips and Tricks</a></li>
 +
</ul>
 +
</li>
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/Gold">Medal Fulfillment</a></li>
 +
<li><a href="#">Additional Info</a>
 +
<ul>
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/Acknowledgement">Acknowledgement</a></li>
 +
<li><a href="https://2011.igem.org/Team:BU_Wellesley_Software/Social">Fun</a></li>
 +
</ul>
 +
</li>
 +
</ul>  
-
 
-
Lab protocols often require careful and precise execution of many individual steps to achieve the desired result. Slight inaccuracies and miscalculations can lead to invalid conclusions. We understand this crucial need to develop a less error prone workflow that will allow us to execute complicated and repetitive lab protocols in a more systematic and infallible matter. Our solution to this problem is Puppeteer, a high-level protocol specifying language that will allow users to construct protocols using our library of Common Human Robot Instruction Set (CHRIS). Using this language, users will be able to create protocols and save them into a Protocol Repository that we have created. This will allow synthetic biologists to share their work among themselves, therefore promoting collaboration within the synthetic biology community.
 
<br>
<br>
-
<br>
+
<h6>PuppetShow</h6>
-
To aid the creation of new protocols using Puppeteer, we have also created a GUI front-end for our language called PuppetShow. Within PuppetShow, users can create protocols in the editor panel and execute the protocol they just wrote with the click of a button. Given that the user’s computer is hooked up to a compatible robot, resource allocation of liquids and plates will happen automatically and a report will be generated containing a resource report, an output report, instructions for the deck setup, and a pipette verification report. For now, we have the software bridge written for the Evoware 150 API and support all major robot commands through this bridge. So far, we have created Restriction Digest and Ligation protocol using PuppetShow and successfully verified their execution on our robot.
+
-
<br>
+
-
<br>
+
-
Using this tool we have created, we aim to improve accuracy and save time. A protocol only needs to be written once and can be run repeatedly with the click of a button. Using PuppetShow, synthetic biologists can create and run protocols without worrying about any low level details or error.
+
 +
<div id="tracking_nav">
 +
JUMP TO...<br>
 +
<a href="#bu-wellesley_wiki_content">Top</a><br>
 +
<a href="#overview">Tool Overview</a><br>
 +
<a href="#flow">Puppeteer Assembly Flow</a><br>
 +
<a href="#dandd">Demo</a><br>
 +
<a href="#results">Results</a><br>
 +
<a href="#safety">Safety Practices</a><br>
 +
<a href="#futurework">Future Work</a>
 +
</div>
-
<img style="float:right; width:380px; height:450px" src="http://wiki.bu.edu/wiki/ece-cidar/images/f/fd/Puphal.jpg"/>
+
<div id="overview">
-
<br><br><br>
+
<p>
 +
<h1>Tool Overview</h1>
 +
<p>
 +
Laboratory protocols often require careful and precise execution of numerous procedures to achieve desired results. However, slight inaccuracies and miscalculations attributable to human-error continually arise and often lead to invalid conclusions. For this reason, we have developed an accurate workflow that executes biological protocols in a more systematic manner. The solution we propose is the Puppeteer Biological Protocol Automation Suite.  Our suite centers on the execution of Puppeteer, a high-level protocol specification language used to programmatically describe biological protocols; it is executed on a liquid-handling robot with minimal user intervention.  PuppetShow allows users to create protocols locally, but will eventually incorporate a “Protocol Repository” that will retain version-controlled instances of uploaded protocols.  This feature will promote all forms of collaboration within the synthetic biology community, with a predominant focus on inter-laboratory protocol sharing.
 +
<p>
 +
</div>
 +
<div id="flow">
 +
<p>
 +
<h1>Puppeteer Assembly Flow</h1>
 +
<p>
 +
<img style="float:right; width:380px; height:450px; border-style:groove; padding:2px;" src="http://cs.wellesley.edu/~hcilab/iGEM_wiki/images/clotho/Puphal.jpg"/>
 +
<p>
 +
Our assembly flow incorporates a five-layer stack as illustrated in the adjacent figure. The Assembly Planner produces an assembly plan for synthetic biological devices, with each assembly step annotated with the name of a biological protocol. Each protocol may be fully specified using PuppetShow.
 +
<p>
 +
The protocols are written in the high-level language called Puppeteer. The Language layer includes a Puppeteer interpreter and linker. A protocol specified in Puppeteer may contain Puppeteer instructions as well as references to previously created Puppeteer programs available in the protocol repository. The Language layer then translates Puppeteer protocols into low-level commands expressed in a Common Human Robot Instruction Set (CHRIS).  CHRIS can be produced by any high-level language, making it ideal for robot vendors to utilize. The Hardware Layer concerning the external control and robot I/O interfacing is wrapped under a Hardware Abstraction Layer (HAL). Vendor-provided software for programming the robot may be proprietary and is used to control the robot. An interface to it is provided by a software bridge, which maps protocols expressed in CHRIS to sequences of native robot instructions.
 +
<p>
 +
The Resource Management layer maintains resource state information and allows for high-level interface standardizations for initializing, requesting, naming, aggregating, and accessing resources to the Language layer, analogous to a ''system call'' suite. This interface abstracts resource management away from the protocol specification language.
 +
<p>
 +
</div>
-
<h5>Architecture:</h5>
+
<div id="dandd">
 +
<p>
 +
<h1>Demo</h1>
 +
<p>
 +
<h5>Software Demo Video</h5>
 +
<center><iframe width="560" height="345" src="http://www.youtube.com/embed/-hyD_S77rh4?rel=0" frameborder="0" allowfullscreen></iframe></center>
 +
<br><br>
 +
<h5>Live Robot Demo Video</h5>
 +
<p>
 +
<center><iframe width="560" height="345" src="http://www.youtube.com/embed/Z7Ad1WiQlOQ?rel=0" frameborder="0" allowfullscreen></iframe></center>
-
Our solution comprises a five-layer stack as illustrated in the figure. Using the Clotho
+
</div>
-
platform, we developed two applications for specifying and executing
+
-
biological protocols. The Assembly Planner is the end-point of an
+
-
end-to-end design workflow  that produces an assembly plan for synthetic
+
-
biological devices, with each assembly step annotated with the name of a biological protocol. Each
+
-
such protocol itself may be fully specified using another Clotho application called PuppetShow, which
+
-
provides an environment for writing, testing, debugging, and executing biological protocols.
+
-
The protocols are written in a new high-level language called Puppeteer. The Language layer
+
<div id="results">
-
comprises the Puppeteer interpreter and linker. A protocol specified in Puppeteer may contain
+
<h1>Results</h1>
-
Puppeteer instructions as well as references to previously created Puppeteer programs available in a
+
<p>
-
library. The Language layer expands and translates a Puppeteer protocol to a sequence of low-level
+
An initial version of the Puppeteer stack is fully integrated with the Clotho software platform and implemented within the wet lab.  Basic BioBricks assembly protocols have been implemented and validated via the physical assembly of basic devices.  Two protocols central to BioBricks assembly—Restriction Digestion and Ligation—have been created using the Puppeteer language. The Puppeteer implementation was validated by executing multiple trials for both protocols and verifying the results via running gels.
-
commands expressed in a Common Human Robot Instruction Set (CHRIS). CHRIS provides a standardized
+
<p>
-
instruction set that high level biological protocol languages like Puppeteer may assume to be
+
<b>Collaboration with other iGEM teams:</b>
-
supported by any robot. Any high-level language may produce CHRIS programs and any robot vendor may
+
<p>
-
support a superset of CHRIS: this decouples robot hardware details from biological protocol and
+
In order to ensure reproducibility and promote collaboration, we visited the Weiss lab at MIT to implement the Puppeteer stack with their robot configuration.  During the visit we encountered a few MIT iGEM team members and coordinated with them to test the Puppeteer flow with the MIT Tecan robot. After we got settled, we noticed several differences between MIT's and our own Tecan robot deck setups; this required modifying settings within the Puppeteer flow for proper protocol execution.  As such, we separated modifiable settings into an easy-to-edit settings file to ensure that Puppeteer maintains configurable settings for varying deck layouts.  The Puppeteer flow was then tested on MIT’s robot, and everything proceeded as expected.  The entire collaborative experience with MIT’s iGEM team remains fruitful since it enforced a more robust and functional Puppeteer flow across multiple robot configurations.
-
specification details and supports our goal of portability and protocol library reuse. The Hardware
+
<p>
-
Layer---the external control and I/O interface of a robot---is wrapped under a Hardware Abstraction
+
<b>Restriction Digest:</b>
-
Layer (HAL). Vendor-provided software for programming the robot may be proprietary and is used to
+
<p>
-
control the robot. An interface to it is provided by a software bridge, which maps protocols
+
<img style="float:right; height:200px; border-style:groove; padding:2px;" src="https://static.igem.org/mediawiki/2011/6/6c/Gel-cropped.png"/>
-
expressed in CHRIS to sequences of native robot instructions.
+
For restriction digest we digested the plasmid containing the BioBrick BBa_J52028 in order to isolate the GFP. After cutting the plasmid with EcoRI and SpeI we ran it on a one percent gel along with a ladder in order to determine the amount of base pairs for each DNA part. As GFP is about 1221 bp the location in which it is located on the gel is correct. Also the backbone was about 3189 bp which is also located in the correct location on the gel.
 +
<p>
 +
<b>Ligation:</b>
 +
<p>
 +
Our first ligation involved BBa_J23100 (RFPc) and BBa_I14033(Pcat). The BBa_J23100 was cut with SpeI and PstI in order to remove the RBS-RFP-Terminator composite part. Three trials were run on the robot with the same parts and the same amounts. A fourth trial was run manually alongside the robot. When ligations were done the total amount for each robot trial was about 5ul off from the desired amount. It took one day for the colonies to grow on the plates but it took about two days for them to finally turn a pinkish color. The ligation was restriction mapped in order to verify that the robot worked properly. One of the robot trials had good results but we needed more verification in order to state that it was successful. Also there were very few colonies so the process had to be fixed.
 +
<p>
 +
We tried ligating again but this time we used BBa_J23101 with Pcat, as we did not have enough digested BBa_J23100. The colonies were very faint and did not seem to produce good outcomes. We decided to test another promoter in order to continue forward. BBa_R0040 (Ptet) worked better so we did two trials on the robot with BBa_J23100 and BBa_R0040 and then one manually. This time around, the colonies looked to be the right color but there were still not enough colonies to call the outcome a success. We decided to take a different approach for fixing the issue by testing new parts. We did a ligation using large parts that have had good ligation outcomes manually. The parts were ligated so that the order in the plasmid is Ptet-RBS-LuxR-YFPc-pLuxR. After being transformed on Ampicillin plates there were a lot of colonies on both the robot trials and the manual trials. This can be seen verified in following figure.
 +
<br>
 +
<center><img style="height:200px; border-style:groove; padding:2px;" src="https://static.igem.org/mediawiki/2011/d/d3/Ligation-success-plates.jpg"/></center>
 +
<br>
 +
<p>
 +
<img style="float:right; height:200px; border-style:groove; padding:2px;" src="https://static.igem.org/mediawiki/2011/5/58/Ligation-success-gel.png"/>
 +
We also did a double volume ligation at the same time as the Ptet-RBS-LuxR-YFPc_pLuxR ligation to see if we could fix the volume issue. The final amounts for each ligation this time was only off by 4ul. BBa_E0240 (GFPc) and promoter BBa_R2000 were used. Unfortunately no colonies grew on the plates. The ligations for Ptet-RBS-LuxR-YFPc-pLuxR was tested by restriction mapping the part. Colony A did not ligate properly but colony B and C did work. The insert is about the same size as the backbone so the fact that there are two bands right under each other is correct. As there was no control for the first double volume ligation, we repeated it but we used RFPc and Ptet once again and did a single volume ligation at the same time. This time the plates clearly showed that the double ligation had the same, if not more, colonies on the plates than the manual control. The regular ligations with the RFPc and Ptet unfortunately still had discrepancies between the robot trials and the manual trial. The restriction mapping for the single and double volume ligations proved that both ligations worked properly.
 +
<p>
 +
</div>
 +
<div id="safety">
 +
<h1>Safety practices</h1>
 +
<p>
 +
As wet-lab protocols were repeated on the robot the same safety procedures were performed. The trials that were run on the robot were done inside a closed laboratory meant for biological processes.  Also while the robot was performing its task, individuals were not allowed to interfere directly with the robot.
 +
<p>
 +
None of the materials used in our iGEM project pose a significant risk to the health and safety of our team members and laboratory. We work in a standard BSL1 certified lab space and mainly work with ''E. coli'' bacteria. Furthermore, there is no risk to the public health or environment if the materials of our project were released. This is because the genes that we are using and studying code for transcriptional proteins and are not pathogenic or toxic. There is no threat of security through misuse of our materials because of their nonlethal nature.
 +
In terms of lab safety and institutional standards, there is an <a href="http://www.bu.edu/orccommittees/ibc/"> Institutional Biosafety Committee </a> (IBC) at Boston University which evaluates all research projects, primarily those involved with recombinant DNA, and insures proper biosafety guidelines. We are in contact with the IBC and are in the process of approving our project.
 +
<p>
 +
There is also a <a href="http://www.bu.edu/orccommittees/laboratory-safety/"> Laboratory Safety Committee </a> through which all wet lab members have taken mandatory laboratory safety training. This training provides a basic overview to chemical and biosafety, fire and life safety, emergency management, and waste management. In the United States, the major centers for biosafety procedures and guidelines are the National Institutes of Health (NIH) <a href="http://oba.od.nih.gov/rdna/nih_guidelines_oba.html"> Guidelines </a> and the <a href="http://www.cdc.gov/"> Center for Disease Control and Prevention </a>(CDC).
-
The Resource Management layer maintains resource state information and provides a standardizable
+
<p>
-
high-level interface for initializing, requesting, naming, aggregating, and accessing resources to
+
</div>
-
the Language layer, analogous to a ``system call'' suite.  This interface supports our goal of
+
-
removing the minutiae of resource management from the protocol specification language.
+
 +
<div id="futurework">
 +
<h1>Future Work</h1>
 +
<p>
 +
<ul>
 +
<li>
 +
Sample History Viewer
 +
<ul>
 +
<li>
 +
Samples currently represent any liquid-like substance used within the laboratory environment.  With the current working database implementation, output sample (e.g., a restriction digested part) information is stored with associated history.  This sample history comprises the individual samples that were utilized to create the output sample (i.e., the buffers and enzymes, etc.) as well as the associated protocols that were executed.  This entire flow has been implemented but is missing a viewer component that will allow users to visually explore the different histories of samples within the database.
 +
</li>
 +
</ul>
 +
</li>
 +
<li>
 +
Protocol Graph Editor
 +
<ul>
 +
<li>
 +
The concept of a protocol graphs focuses on an ideal and simplistic hierarchical representation of biological protocols.  The graph itself is a directed bipartite graph composed of protocol nodes, sample nodes, and connection arcs.  The bipartite label implies that protocol nodes can only connect to sample nodes and vice versa (sample nodes are input(s)/output(s) to/from protocol nodes).  With such a representation, complex biological protocols can be translated into a (potentially large) but scalable and useful graphical representation.
 +
</li>
 +
<li>
 +
Avi Robinson-Mosher, a postdoctoral researcher in the Silver lab at the Wyss Institute for Biologically Inspired Engineering at Harvard University, has shown interest in a protocol graph editor.  We are collaborating with the Silver lab over data structures and database organization regarding the implementation and storage of protocol graphs.
 +
</li>
 +
</ul>
 +
</li>
 +
<li>
 +
Integration with <a href="https://2011.igem.org/Team:BU_Wellesley_Software/eLabNotebook"> eLabNotebook </a>
 +
<ul>
 +
<li>
 +
The eLabNotebook application uses a protocol representation to display procedural steps for wet lab convenience.  Ideally, a layer of communication will coexist between PuppetShow’s database features and the eLabNotebook’s central server configuration.  Generated protocol graphs and associated reports, created by users in Trumpet or any software tools created by future iGEM teams, will be stored on an identifiable server.  The eLabNotebook will then pull and parse the information from the server to provide accurate, up-to-date information for the laboratory environment, thanks to PuppetShow's ability to transfer data between applications.
 +
</li>
 +
</ul>
 +
</li>
-
<br><br><br>
+
<li>
-
<h5>Results:</h5>
+
Integration with <a href="https://2011.igem.org/Team:BU_Wellesley_Software/Trumpet"> Trumpet </a>
 +
<ul>
 +
<li>
 +
Trumpet already generates reconfigurable constructs in the form of Clotho “composite parts”.  This data model is already adaptable to the Puppeteer assembly flow, so it will be very feasible to execute protocols from Trumpet’s output.  This feature can be implemented as soon as a standard for implementation is finalized.
 +
</li>
 +
</ul>
 +
</li>
-
We have finished implementation of an initial version of the Puppeteer stack; it is fully integrated with the Clotho platform. We have implemented basic BioBricks assembly protocols and validated them in the wet lab by assembling basic devices.
+
<li>
 +
Protocol optimizer project
 +
<ul>
 +
<li>
 +
A potential project proposal involves the algorithmic assembly of protocols.  This procedure would be completed on an abstract level, where a sophisticated evaluation of available resources is used to generate optimized protocols.  The available resources would comprise samples within the database, both previously-created and newly-entered, that are paired up with protocols to provide efficient output creation.  The ingenuity behind this application involves the usage of historical context, which is retained in the form of sample history within the database.
 +
</li>
 +
</ul>
 +
</li>
-
<br><br>
+
</ul>
-
<h5>Collaboration with other iGEM teams:</h5>
+
<p>
-
In order to ensure reproducibility and promote collaboration, we visited the Weiss lab at MIT to set up the Puppeteer stack on their robot. We met a few of MIT’s iGem team members and coordinated with them to test the Puppeteer flow on the MIT robot. During this process, we noticed some differences between our robot deck setups and the way this setup was handled in the Puppeteer flow. We separated such settings into an easily edited settings file to ensure that  Puppeteer was easily configured for different deck setups. We successfully tested the Puppeteer flow on the MIT deck and everything ran as expected. This collaborative effort with MIT’s iGem team is definitely fruitful because it made Puppeteer more robust and ensured functionality across multiple robots.
+
-
 
+
-
+
-
 
+
-
<h5>Future Work:</h5>
+
-
Integration between Puppeteer/Puppetshow and the <a href="https://2011.igem.org/Team:BU_Wellesley_Software/eLabNotebook"> eLabNotebook </a> is planned for implementation.
+
-
 
+
-
<br><br>
+
-
<h5>Ethical User Study practices:</h5>
+
-
Aliquam in felis sit amet eros pharetra volutpat.
+
-
+
-
 
+
-
 
+
-
</div>
+
-
<div id="overview">
+
-
<h1>Demo Video</h1>
+
-
<!--DRAFT, please UPDATE as needed-->
+
-
 
+
-
Constructing a combinatorial library of devices is tedious using manual laboratory techniques and would require hundreds of hours of careful work. To remedy this, we are implementing the Puppeteer Biological Protocol
+
-
Automation Suite. This suite includes a high level programming language for specifying biological
+
-
protocols commonly used in the laboratory, which are then executed by a liquid-handling robot with
+
-
minimal user intervention.
+
-
<br><br><br>
+
-
+
-
<a href="#"><img id="download_button" src="http://cs.wellesley.edu/~hcilab/iGEM_wiki/images/temp_download_button.jpg"/></a>
+
-
<br><br><br><br><br><br><br>
+
-
<h5>Demo Video</h5>
+
-
<iframe width="560" height="345" src="http://www.youtube.com/embed/-hyD_S77rh4" frameborder="0" allowfullscreen></iframe>
+
</div>
</div>
-
<div id="wetlab">
+
<p><p><p>
-
<h1>Wetlab Verification</h1>
+
-
 
+
-
We implemented two protocols central to BioBricks assembly---Restriction Digestion and Ligation---in Puppeteer. We validated the Puppeteer implementation by executing multiple trials of both protocols and verifying the result by running a gel.
+
-
<br><br>
+
-
<h5>Restriction Digest:</h5>
+
-
For restriction digest we digested the plasmid containing the BioBrick BBa_J52028 in order to isolate the GFP. After cutting the plasmid with EcoRI and SpeI we ran it on a one percent gel along with a ladder in order to determine the amount of base pairs for each dna part. As GFP is about 1221 bp the location in which it is located on the gel is correct. Also the backbone was about 3189 bp which is also located in the correct location on the gel.
+
-
<br><br><br>
+
-
<h5>Results:</h5>
+
-
The images show the verification results.
+
-
 
+
-
<img style="width:324px; height:209px" src="http://wiki.bu.edu/wiki/ece-cidar/images/6/6c/Gel-cropped.png"/>
+
-
 
+
-
 
+
-
<br><br><br><br><br><br>
+
-
<img style="width:371px; height:318px" src="http://wiki.bu.edu/wiki/ece-cidar/images/2/2a/Ligation-success.png"/>
+
-
 
+
-
<img style="width:680px; height:215px" src="http://wiki.bu.edu/wiki/ece-cidar/images/d/d3/Ligation-success-plates.jpg"/>
+
-
 
+
-
+
-
  <br><br>
+
-
  <h5>Safety practices:</h5>
+
-
  Aliquam in felis sit amet eros pharetra volutpat.
+
-
</div>
+
-
 
+
-
  </div>
+
-
 
+
-
</div>
+
-
<!-- "next page" action -->
+
-
<a class="next browse right"></a>
+
-
+
-
<script>
+
-
// execute your scripts when the DOM is ready. this is mostly a good habit
+
-
$(function() {
+
-
 
+
-
// initialize scrollable
+
-
$(".scrollable").scrollable();
+
-
 
+
-
//move the scrollable content to show the middle section
+
-
                        var api = $(".scrollable").data("scrollable");
+
-
                        api.seekTo(1, 500);
+
-
});
+
-
</script>
+
-
+
-
 
+
-
</div><!--end bu-wellesley_wiki_content div-->
+
</body>
</body>
</html>
</html>

Latest revision as of 01:20, 29 September 2011

BU-Wellesley iGEM Team: Puppetshow


PuppetShow

Tool Overview

Laboratory protocols often require careful and precise execution of numerous procedures to achieve desired results. However, slight inaccuracies and miscalculations attributable to human-error continually arise and often lead to invalid conclusions. For this reason, we have developed an accurate workflow that executes biological protocols in a more systematic manner. The solution we propose is the Puppeteer Biological Protocol Automation Suite. Our suite centers on the execution of Puppeteer, a high-level protocol specification language used to programmatically describe biological protocols; it is executed on a liquid-handling robot with minimal user intervention. PuppetShow allows users to create protocols locally, but will eventually incorporate a “Protocol Repository” that will retain version-controlled instances of uploaded protocols. This feature will promote all forms of collaboration within the synthetic biology community, with a predominant focus on inter-laboratory protocol sharing.

Puppeteer Assembly Flow

Our assembly flow incorporates a five-layer stack as illustrated in the adjacent figure. The Assembly Planner produces an assembly plan for synthetic biological devices, with each assembly step annotated with the name of a biological protocol. Each protocol may be fully specified using PuppetShow.

The protocols are written in the high-level language called Puppeteer. The Language layer includes a Puppeteer interpreter and linker. A protocol specified in Puppeteer may contain Puppeteer instructions as well as references to previously created Puppeteer programs available in the protocol repository. The Language layer then translates Puppeteer protocols into low-level commands expressed in a Common Human Robot Instruction Set (CHRIS). CHRIS can be produced by any high-level language, making it ideal for robot vendors to utilize. The Hardware Layer concerning the external control and robot I/O interfacing is wrapped under a Hardware Abstraction Layer (HAL). Vendor-provided software for programming the robot may be proprietary and is used to control the robot. An interface to it is provided by a software bridge, which maps protocols expressed in CHRIS to sequences of native robot instructions.

The Resource Management layer maintains resource state information and allows for high-level interface standardizations for initializing, requesting, naming, aggregating, and accessing resources to the Language layer, analogous to a ''system call'' suite. This interface abstracts resource management away from the protocol specification language.

Demo

Software Demo Video


Live Robot Demo Video

Results

An initial version of the Puppeteer stack is fully integrated with the Clotho software platform and implemented within the wet lab. Basic BioBricks assembly protocols have been implemented and validated via the physical assembly of basic devices. Two protocols central to BioBricks assembly—Restriction Digestion and Ligation—have been created using the Puppeteer language. The Puppeteer implementation was validated by executing multiple trials for both protocols and verifying the results via running gels.

Collaboration with other iGEM teams:

In order to ensure reproducibility and promote collaboration, we visited the Weiss lab at MIT to implement the Puppeteer stack with their robot configuration. During the visit we encountered a few MIT iGEM team members and coordinated with them to test the Puppeteer flow with the MIT Tecan robot. After we got settled, we noticed several differences between MIT's and our own Tecan robot deck setups; this required modifying settings within the Puppeteer flow for proper protocol execution. As such, we separated modifiable settings into an easy-to-edit settings file to ensure that Puppeteer maintains configurable settings for varying deck layouts. The Puppeteer flow was then tested on MIT’s robot, and everything proceeded as expected. The entire collaborative experience with MIT’s iGEM team remains fruitful since it enforced a more robust and functional Puppeteer flow across multiple robot configurations.

Restriction Digest:

For restriction digest we digested the plasmid containing the BioBrick BBa_J52028 in order to isolate the GFP. After cutting the plasmid with EcoRI and SpeI we ran it on a one percent gel along with a ladder in order to determine the amount of base pairs for each DNA part. As GFP is about 1221 bp the location in which it is located on the gel is correct. Also the backbone was about 3189 bp which is also located in the correct location on the gel.

Ligation:

Our first ligation involved BBa_J23100 (RFPc) and BBa_I14033(Pcat). The BBa_J23100 was cut with SpeI and PstI in order to remove the RBS-RFP-Terminator composite part. Three trials were run on the robot with the same parts and the same amounts. A fourth trial was run manually alongside the robot. When ligations were done the total amount for each robot trial was about 5ul off from the desired amount. It took one day for the colonies to grow on the plates but it took about two days for them to finally turn a pinkish color. The ligation was restriction mapped in order to verify that the robot worked properly. One of the robot trials had good results but we needed more verification in order to state that it was successful. Also there were very few colonies so the process had to be fixed.

We tried ligating again but this time we used BBa_J23101 with Pcat, as we did not have enough digested BBa_J23100. The colonies were very faint and did not seem to produce good outcomes. We decided to test another promoter in order to continue forward. BBa_R0040 (Ptet) worked better so we did two trials on the robot with BBa_J23100 and BBa_R0040 and then one manually. This time around, the colonies looked to be the right color but there were still not enough colonies to call the outcome a success. We decided to take a different approach for fixing the issue by testing new parts. We did a ligation using large parts that have had good ligation outcomes manually. The parts were ligated so that the order in the plasmid is Ptet-RBS-LuxR-YFPc-pLuxR. After being transformed on Ampicillin plates there were a lot of colonies on both the robot trials and the manual trials. This can be seen verified in following figure.


We also did a double volume ligation at the same time as the Ptet-RBS-LuxR-YFPc_pLuxR ligation to see if we could fix the volume issue. The final amounts for each ligation this time was only off by 4ul. BBa_E0240 (GFPc) and promoter BBa_R2000 were used. Unfortunately no colonies grew on the plates. The ligations for Ptet-RBS-LuxR-YFPc-pLuxR was tested by restriction mapping the part. Colony A did not ligate properly but colony B and C did work. The insert is about the same size as the backbone so the fact that there are two bands right under each other is correct. As there was no control for the first double volume ligation, we repeated it but we used RFPc and Ptet once again and did a single volume ligation at the same time. This time the plates clearly showed that the double ligation had the same, if not more, colonies on the plates than the manual control. The regular ligations with the RFPc and Ptet unfortunately still had discrepancies between the robot trials and the manual trial. The restriction mapping for the single and double volume ligations proved that both ligations worked properly.

Safety practices

As wet-lab protocols were repeated on the robot the same safety procedures were performed. The trials that were run on the robot were done inside a closed laboratory meant for biological processes. Also while the robot was performing its task, individuals were not allowed to interfere directly with the robot.

None of the materials used in our iGEM project pose a significant risk to the health and safety of our team members and laboratory. We work in a standard BSL1 certified lab space and mainly work with ''E. coli'' bacteria. Furthermore, there is no risk to the public health or environment if the materials of our project were released. This is because the genes that we are using and studying code for transcriptional proteins and are not pathogenic or toxic. There is no threat of security through misuse of our materials because of their nonlethal nature. In terms of lab safety and institutional standards, there is an Institutional Biosafety Committee (IBC) at Boston University which evaluates all research projects, primarily those involved with recombinant DNA, and insures proper biosafety guidelines. We are in contact with the IBC and are in the process of approving our project.

There is also a Laboratory Safety Committee through which all wet lab members have taken mandatory laboratory safety training. This training provides a basic overview to chemical and biosafety, fire and life safety, emergency management, and waste management. In the United States, the major centers for biosafety procedures and guidelines are the National Institutes of Health (NIH) Guidelines and the Center for Disease Control and Prevention (CDC).

Future Work

  • Sample History Viewer
    • Samples currently represent any liquid-like substance used within the laboratory environment. With the current working database implementation, output sample (e.g., a restriction digested part) information is stored with associated history. This sample history comprises the individual samples that were utilized to create the output sample (i.e., the buffers and enzymes, etc.) as well as the associated protocols that were executed. This entire flow has been implemented but is missing a viewer component that will allow users to visually explore the different histories of samples within the database.
  • Protocol Graph Editor
    • The concept of a protocol graphs focuses on an ideal and simplistic hierarchical representation of biological protocols. The graph itself is a directed bipartite graph composed of protocol nodes, sample nodes, and connection arcs. The bipartite label implies that protocol nodes can only connect to sample nodes and vice versa (sample nodes are input(s)/output(s) to/from protocol nodes). With such a representation, complex biological protocols can be translated into a (potentially large) but scalable and useful graphical representation.
    • Avi Robinson-Mosher, a postdoctoral researcher in the Silver lab at the Wyss Institute for Biologically Inspired Engineering at Harvard University, has shown interest in a protocol graph editor. We are collaborating with the Silver lab over data structures and database organization regarding the implementation and storage of protocol graphs.
  • Integration with eLabNotebook
    • The eLabNotebook application uses a protocol representation to display procedural steps for wet lab convenience. Ideally, a layer of communication will coexist between PuppetShow’s database features and the eLabNotebook’s central server configuration. Generated protocol graphs and associated reports, created by users in Trumpet or any software tools created by future iGEM teams, will be stored on an identifiable server. The eLabNotebook will then pull and parse the information from the server to provide accurate, up-to-date information for the laboratory environment, thanks to PuppetShow's ability to transfer data between applications.
  • Integration with Trumpet
    • Trumpet already generates reconfigurable constructs in the form of Clotho “composite parts”. This data model is already adaptable to the Puppeteer assembly flow, so it will be very feasible to execute protocols from Trumpet’s output. This feature can be implemented as soon as a standard for implementation is finalized.
  • Protocol optimizer project
    • A potential project proposal involves the algorithmic assembly of protocols. This procedure would be completed on an abstract level, where a sophisticated evaluation of available resources is used to generate optimized protocols. The available resources would comprise samples within the database, both previously-created and newly-entered, that are paired up with protocols to provide efficient output creation. The ingenuity behind this application involves the usage of historical context, which is retained in the form of sample history within the database.