Team:Alberta/Project/Automation

From 2009.igem.org

(Difference between revisions)
 
(16 intermediate revisions not shown)
Line 33: Line 33:
<font size="2">
<font size="2">
-
<center>
+
 
-
<img src="https://static.igem.org/mediawiki/2009/6/6d/UofA09_diyAuto_Photo1.png">
+
<img style="padding:20px;" src="https://static.igem.org/mediawiki/2009/6/6d/UofA09_diyAuto_Photo1.png" align = "right" width="67%">
-
</center>
+
 
<p>
<p>
Line 42: Line 42:
<p>
<p>
-
The Biobytes Assembly is very rigid and reliable; however, it is also very repetitive and tedious.  This has triggered us to develop an automated mechanical system (ie. a robot) capable of speeding up and simplifying our methods.  The overall goal is that our robot would be simple enough to be used by high school students.  This would provide a valuable tool in biological education.  It is also our goal to create a system that is versatile enough to be used in more advanced research labs, thereby decreasing the time needed for plasmid construction.</p>
+
One of the goals of our BioBytes Assembly System was to speed up and simplify the very time consuming process of plasmid assembly.  The hope was that it would be simple enough to be used by high school students.  Even better, a simple inexpensive device, thereby leaving the tedious work to an inanimate object.
 +
</p>
</font></div>
</font></div>
Line 57: Line 58:
<td style="height: 400; padding-left: 10px; padding-right: 10px; padding-top: 11px;">
<td style="height: 400; padding-left: 10px; padding-right: 10px; padding-top: 11px;">
     <b class="b1f"></b><b class="b2f"></b><b class="b3f"></b><b class="b4f"></b>
     <b class="b1f"></b><b class="b2f"></b><b class="b3f"></b><b class="b4f"></b>
-
 
     <div class="Outreach">
     <div class="Outreach">
-
 
     <div style="height: 400; background:#FFFFFF; colorou line-height:100% padding: 3px 0px;">
     <div style="height: 400; background:#FFFFFF; colorou line-height:100% padding: 3px 0px;">
-
 
     <h1>The Robotic Device</h1>
     <h1>The Robotic Device</h1>
Line 71: Line 69:
<p>
<p>
 +
Since the DNA assembly method consists mainly of a few repeated and simple actions, interspersed with relatively long idle periods, it seemed like a good candidate for a little bit of automation.  This little automaton is built entirely out of a popular plastic construction set, using only the standard pieces and hardware.  The firmware, however, has been somewhat customised using open source code written by members of the NXT hobbyist community.
 +
</p>
-
Our robot is built entirely from a single <b>Lego Mindstorms</b> kit, using only the standard pieces and hardware sold with the kit.
+
<p>
-
 
+
The word 'robot' may bring to mind complex devices that have advanced control schemes, state of the art sensors, and a fast microprocessor.  Unfortunately, this device doesn't really have any of those things.  It's control scheme is lacking, for all intents and purposes, there are no sensors, and the microprocessor is about what you would expect from a children's toy.  While somewhat disappointing, these things have to be sacrificed in order to keep the device inexpensive.  What we have ended up with is a simple device, capable of following a scripted set of movements that have been defined at compile-time.  Luckily, the task is simple enough that this is all that we need.
-
 
+
</p>
</p>
<ul>
<ul>
-
    <li>
+
<li>
-
<h2>Why use a "toy"?</h2>
+
<h4>Why use a toy?</h4>
-
You may be wondering why we chose to use a mechanics kit made for adolescents to build our robot when there are much more sophisticated resources available?  The inherent reality is that not everybody has access to a machine shop, PCB manufacturing equipment, and a micro-controller programmerThis equipment is rather expensive and not readily available to the general publicWe hope that by using relatively inexpensive and readily available parts, places like high-schools and undergraduate research labs are be able to make use of our techniques.
+
Why would you want to use something like a toy to build such a device, when there are so many other resources available?  The construction set was chosen because of the reality that not everybody has access to a machine shop, PCB manufacturing equipment, and a microcontroller programming deviceThese things are usually expensive, which would probably preclude a large number of people from being able afford to use such a robotic deviceThe people that we would be excluding by making a complex and expensive machine are exactly the people that synthetic biology is trying to reach, pre-university and junior univeristy students. The hope was that by using materials that are relatively inexpensive, and readily available, places like high-schools and similar would be able to make use of this, both as-provided and as a starting point for any development on it that they may wish to undertake.  
-
  </li>
+
</li>
</ul>
</ul>
-
 
-
<p>
 
-
 
-
 
-
 
-
</p>
 
-
 
-
<p>
 
-
 
-
 
-
</p>
 
</font></div>
</font></div>
Line 118: Line 106:
     <div style="height: 400; background:#FFFFFF; colorou line-height:100% padding: 3px 0px;">
     <div style="height: 400; background:#FFFFFF; colorou line-height:100% padding: 3px 0px;">
 +
    <h2>Hardware and Software</h2>
-
    <h1>Hardware and Software</h1>
 
-
 
-
<!-- <div align="justify" style="padding-left:20px; padding-right:20px"> -->
 
<div align="justify">
<div align="justify">
Line 131: Line 117:
<li>
<li>
-
<h2>Hardware</h2>
+
<h4>Hardware</h4>
<p>
<p>
 +
<img style="padding:20px;" src="https://static.igem.org/mediawiki/2009/7/7d/UofA_diyAuto_dipPen.png" align="right" width ="35%">
-
As mentioned before, the majority of parts are from a standard Lego Mindstorm kit.  In addition, rare earth magnets, a pipette tip, and electrical tape were needed to make the Lego Mindstorm kit compatible with the BioByte Assembly System.   
+
The easiest and perhaps only way of accomplishing the automation of the DNA assembly protocol using only the parts in the kit was to move the beads from one well to another, where the wells had previously been filled with the correct DNA pieces, washes, etcThe other option would have been to hold the beads in one place, and move the liqiud in and out of a single tube, as had been done by the experiments that are currently performing the protocol.  Dispensing liquids via a pipette or other means was deemed to be difficult to do using only the 3 motors provided in the kitA sort of 'dip pen' method was chosen, where the beads would be attracted to a 'pen' placed in one well, the lifted up and placed in another well, where they would be shaken off and allowed to sit in the solution.
</p>
</p>
-
<h3>Inspiration</h3>
+
<p>
-
<P>
+
The physical design of the robot was probably the most challenging and time consuming parts of the whole process.  This was mainly owing to the fact that the plastic construction pieces have only certian lengths and sizes of the different types of pieces.  Also a problem was the amount of 'flex' or 'wiggle' that you could get out of the plastic parts.  This led to a few failed implementations that had to be completely disassembled and started again.  The current physical implementation owes its inspiration to Hans Andersons' sudoku solving robot (http://tiltedtwister.com/sudokusolver.html).  This adapted design allowed for the necessary increase precision for the 'pen' to be positioned over the well, along with the advantage of not possessing a large number of points where the play in the gears and joints would become a problem.
-
The current physical design of the robot owes its inspiration to Hans Andersons sudoku solving robot (http://tiltedtwister.com/sudokusolver.html).  Adaptation of the Anderson design allowed for the necessary amount of precision required for the 'pen' to be positioned over the well.  This design has the added advantage of not possessing a large number of points where play in the gears and joints may become a problem.
+
</p>
</p>
-
<center>
+
<p>
-
<img style="padding : 20px;" src="http://tiltedtwister.com/img/sudoku/sudoku1.jpg" width="400" height="250" align="center">
+
It would have been nearly impossible to build a device capable of carrying out the planned procedure using only the parts in the kit.  For one thing, using only plastic parts, there would have been no way to harness the properties of the magnetic beads used in the assembly process.  In order to make the device perform it's task, the following materials were also used: small rare earth magnets, a P1000 pipette tip that has had it's end melted shut, and some electrical tape to attach to pipette tip to the plastic building bricks.
-
</center>
+
</p>
-
 
+
<center>
<center>
Line 152: Line 137:
</center>
</center>
 +
</li>
-
<h3>Structural Design</h3>
+
<li>
-
<p>
+
-
 
+
-
<img style="padding : 20px;" src="https://static.igem.org/mediawiki/2009/7/7d/UofA_diyAuto_dipPen.png" align="right" width ="35%">
+
-
 
+
-
<P>
+
-
 
+
-
The easiest and most feasible method for automating the BioByte Assembly Method involves the movement of beads from one well to the next on a 96 well plate, with each well containing a different solution, such as wash buffer or an individual byte.  Therefore, as the magnet is dragged from well to well, bytes are continually added until a full length construct is generated.  Another option would be to suspend the beads in one place and continually exchange the solutions surrounding the beads.  However, due to the limitations of the Lego Mindstorm kit this option was not chosen.  In the end, a 'dip pen' method was selected.  A small rare earth magnet is secured to the end of a pipette tip, thus producing a 'pen'.  The pen is then lowered into the well, whereby the beads are attracted to the magnet.  The pen is then lifted up and placed in another well dragging the beads with it.  The beads are then shaken off and allowed to sit in the solution whereby individual bytes may bind or the intermediate constructs are washed.  This process is repeated until the full length linear construct is produced.</p>
+
-
 
+
-
<h3>Structural Obstacles</h3>
+
-
<P>
+
-
An number of challenges had to be addressed in designing the robot.</P> 
+
-
 
+
-
<ul>
+
-
    <li>The pieces come in standard lengths and sizes making it difficult to accomodate the kit to the very precise structural considerations needed for the BioBytes assembly process.</li>
+
-
    <li>There is a large degree of flex to the individual pieces decreasing the rigidity and consistency of the robot.</li>
+
-
</ul>
+
-
 
+
-
<h2>Software</h2>
+
 +
<h4>Software</h4>
 +
<img style="padding : 20px;" src="https://static.igem.org/mediawiki/2009/1/12/UofA09_diyAuto_SampleFuncs.png" align="right" width="45%">
<p>
<p>
-
We used free open source software (FOSS) courtesy of nxtOSEK (http://lejos-osek.sourceforge.net/) to provide the 'brains' for our robot.  Installation instructions are located at: http://lejos-osek.sourceforge.net/installation.</p>
+
There was a bit more leeway with the choice of software.  For this, nxtOSEK (http://lejos-osek.sourceforge.net/) was used to program the control unit of the robot.  The instructions for installation of the GNUARM tool chain that was used are located here: http://lejos-osek.sourceforge.net/installation. This installation requires quite a few different steps, and a few different things to be installed, either on the robot brain, or on the programming computer. Unlike some of the other programming methods available, this one has the advantage of being free of charge, and did not require an proprietary development environment.
-
 
+
</p>
-
<center>
+
-
<img style="padding : 20px;" src="https://static.igem.org/mediawiki/2009/1/12/UofA09_diyAuto_SampleFuncs.png" align="center">
+
-
</center>
+
<p>
<p>
-
In the event that the robot would be used for something different later, John Hansen's Enhanced NXT firmware was loaded into the robot's brain in order to preserve its originial functionality (http://bricxcc.sourceforge.net/).  While this did limit the size of the program that could be loaded, it was felt that it would be unlikely that the program would be large enough to strike this upper limit.
+
In order to preserve the original functionality of the robot brain, in the event that it would be used for something different later, the firmware loaded onto the brain was John Hansen's Enhanced NXT firmware (http://bricxcc.sourceforge.net/).  While this did limit the size of the program that could be loaded, it was felt that it would be unlikely that the program would be large enough to strike this upper limit.
</p>
</p>
<p>
<p>
-
The programming language used for this implementation was C++.  The nxtOSEK package provides various classes for the pieces of the NXT system (Motor, Clock, Button, etc).  These classes are comprised of mainly protected data members (in the form of simple data types, mostly integers) and the methods to retrieve and set them.  These data members must be protected as their values are supposed to be modified based on the robot's interaction with the physical world, and you don't really want to accidentally switch the values.  This programming model allows for a high level of abstraction, thus allowing for more time for gig-taxing operations like calibrating the robot's movements.
+
The programming itself can be done in can be done in a few different languages, but the the language used for this implementation was C++.  The nxtOSEK package provides various classes for the pieces of the NXT system (Motor, Clock, Button, etc).  These classes are comprised of mainly protected data members (in the form of simple data types, mostly integers) and the methods to retrieve and set them.  These data members must be protected as their values are supposed to be modified based on the automatons interaction with the physical world, and you don't really want to accidentally switch the values.  This programming model allows for a high level of abstraction, allowing for more time doing really gig-taxing things like calibrating the automatons movements.
</p>
</p>
<p>
<p>
-
Software design was relatively straightforward.  Examples of the syntax necessary for interacting with the motor classes required was provided by nxtOSEKHowever, difficulty arose in working out the program so that the robot was able to position the dip-pen overtop of the desired well as precisely as possible within the constraints of the system.
+
Software design was very straightforward.  Using examples provided for nxtOSEK, the syntax necessary for interacting with the motor classes was easyThe way that the controller determines how far the motor has turned was accomplished using both a time parameter, as well as the measured encoder distance from the motor, which had to be done because of the way the software environment handled conditional statements. The more difficult part was working out the program such that the robot is able to position the dip-pen over the desired well most of the time (see section on Calibration).
</p>
</p>
Line 196: Line 163:
</ul>
</ul>
-
 
-
 
-
 
Line 219: Line 183:
-
     <h1>Calibration</h1>
+
     <h1>Getting to a Working Prototype</h1>
<!-- <div align="justify" style="padding-left:20px; padding-right:20px"> -->
<!-- <div align="justify" style="padding-left:20px; padding-right:20px"> -->
Line 225: Line 189:
<font size="2">
<font size="2">
 +
 +
<ul>
 +
 +
 +
<li>
 +
<h4>Hardware/Software Iteration</h4>
<p>
<p>
-
No sensors were used in the final design of the robot, therefore the calibration of the robot's movement proved rather time consuming.  Due to the fact that the program required all movement calculations to be 'reckoned,' and could not intuitively adjust each consecutive step in the program if preliminary movements had to be changed, many time and distance calculations had to be made and remade to produce to final version of the robot's program.</P>
+
<img style="padding : 20px;" src="https://static.igem.org/mediawiki/2009/c/c0/UofA09_diyAuto_HardwareGear.jpg" align="right">
 +
Getting something that even sort of worked was very much just a iterative process (pictured is what one of these failed iterations in progress looks like).  The most time consuming was the different physical configurations that had to be tried to come up with the current oneThe hardest part was trying to come up with a way that would allow for the tip to descend with or without the magnet using only one motor.  The only attempted solution that somewhat worked was a separate gear that is prevented from moving in one direction by a plastic brick.  As the tip is lowered, the gear is prevented from spinning, which keeps the magnet from descending.  If the tip is made to descend past a certain point, a pushrod trips the gear release, causing the magnet to drop to the bottom of the sealed pipette tip.  
 +
</p>
-
<P>
+
<p>
-
Issues of odometry arose in the calibration of the robot.  There appeared to be a problem in either the motors themselves or a firmware/software issue that does not relay any information on the distance travelled by the robotDue to the 'reckoning' methods involved in programming, it is vital that the robot be able to know how far it has travelled, so that it is capable of returning to previous locations.  This is also important so that it can accurately strike the wells and staying within the boundaries of the plate.</p>
+
The script writing was also a very much iterative process (you may be familiar with the 'burn and learn' method of microcontroller programming).  This was made worse by the fact that not only did the movements require calibration, but every different physical configuration required a completely (and usually radically) different calibration.
 +
</p>
 +
<!-- <img style="padding : 20px;" src="https://static.igem.org/mediawiki/2009/8/8c/UofA09_diyAuto_HardwareInc.jpg" align="right"> -->
 +
 
 +
</li>
 +
<li>
 +
<h4>Calibration</h4>
 +
<p>
 +
Due to the fact that no sensors were used in the final plan for this robot, the calibration of its movement was one of the single most time consuming and aggravating parts of the whole process.  Due the the fact that all the distances were 'dead reckoned' rather than sorted out on the fly, many times and distances had to be estimated and ultimately changed in an iterative process that allowed for something that came close to working.
 +
 
 +
One of the problems that was discovered during this calibration process is the problem the physical set up posed with odometry.  There seems to be a problem somewhere in either the motors themselves or some firmware/software issue, and the issue is such that some of the robots traveled distance 'disappears'When using dead reckoning, it is vital that the robot be able to know how far it has traveled, so that it will be able to make it back, after it has traveled some distance.  This is also important for it being able to accurately strike the wells, as well as staying within the boundaries of the plate.
 +
</li>
 +
 
 +
</ul>
</font></div>
</font></div>
Line 248: Line 233:
     <div style="height: 400; background:#FFFFFF; colorou line-height:100% padding: 3px 0px;">
     <div style="height: 400; background:#FFFFFF; colorou line-height:100% padding: 3px 0px;">
-
 
-
 
     <h2>Results</h2>
     <h2>Results</h2>
Line 256: Line 239:
<font size="2">
<font size="2">
-
 
<ul>
<ul>
-
 
<li>
<li>
Line 264: Line 245:
<p>
<p>
-
Surprisingly, this little automaton is actually capable of moving beads from one well to another.  The magnet handily attracts the beads to the outside of the tip and pulls them out of the solution.  When the tip descends without the magnet, the beads only require a little bit of agitation in order to shake them off into the liquid.  The movement between the wells takes place decently, without splashing things all over the place, contaminating other wells.   
+
Surprisingly, this little robot is actually capable of moving beads from one well to another.  The magnet handily attracts the beads to the outside of the tip and pulls them out of the solution.  When the tip descends without the magnet, the beads only require a little bit of agitation in order to shake them off into the liquid.  The movement between the wells takes place decently, generally without splashing things all over the place, contaminating other wells.   
</p>
</p>
Line 277: Line 258:
<p>
<p>
-
In order to show that it can move the beads around, a quick little experiment was done.  A script was written up such that the automaton would attempt to collect beads from one well, move over to a well full of water, then drop them off.  This would be repeated a bunch of times, just to see if it could do it all on its own, if it had enough tries.   
+
In order to show that it can move the beads around, a quick experiment was done.  A script was written up such that the automaton would attempt to collect beads from one well, move over to a well full of water, then drop them off.  This series of actions was placed in a loop, allowing them to be repeated multiple times, just to see if it could do it all on its own, if it had enough tries.   
</p>
</p>
<p>
<p>
-
The upper photograph show the initial set up of the wells in question, with a bead solution in the center well, flanked by two wells with plain water.  There is water in both flanking wells because, in all honesty I couldn't remember which way it was going to goThis also had to bonus effect of showing another potential problem associated with the reliability problems, which can be seen in the lower photograph.
+
The upper photograph show the initial set up of the wells in question, with a bead solution in the center well, flanked by two wells with plain water.  There is water in both flanking wells in order to test for the possibility of contamination of adjacent wells.   
</p>
</p>
<p>
<p>
-
The lower photograph shows the three wells after the robot has wreaked havoc.  We can see that the center well is indeed a lighter brown, indicating that there is a lower concentration of magnetic beads here.  The well on the right now has a brown colour, indicating that beads did make it into this well.  The well on the left also has a slight brown tint, showing that some beads made it to this well too.  This occurred when the robot did something I like to call, 'going terminator,' where it missed a well and started stabbing its tip into the surrounding plastic.  This causes small splashes which can cross contaminate nearby wells.   
+
The lower photograph shows the three wells after the robot had run through its script.  We can see that the center well is indeed a lighter brown, indicating that there is a lower concentration of magnetic beads here.  The well on the right now has a brown colour, indicating that beads did make it into this well.  The well on the left also has a slight brown tint, showing that some beads made it to this well too.  This occurred when the robot missed a well and started stabbing its tip into the surrounding plastic.  This causes small splashes which cross contaminated nearby wells.  The beads where not completely removed from the starting well both because of surface tension interactions with the liquid, which held a small amount of beads in the initial well.  The concentration of beads in the inital well was also not helped by the unreliability of the pen lowering mechanism, which would sometimes would drop the magnet when it wasn't supposed to, and move the beads in the opposite direction. 
 +
</p>
 +
 
 +
<p>
 +
Some of the beads did remain on the tip, even when the tip was removed from the liquid.  This is likely due to the method that was used to close off the end of the tip.  The tip was melted with a lighter, which left some ridges for the beads to get stuck to.  Future prototypes will have a smoother dip pen that should, at least partially, solve this problem.
</p>
</p>
Line 292: Line 277:
<li>
<li>
-
<h4>Complications</h4>
+
<h4>Problems</h4>
<ul>
<ul>
<li><b>Sensitivity to initial conditions</b>
<li><b>Sensitivity to initial conditions</b>
<p>
<p>
-
Since the process is dead reckoned, getting the initial setup correct is key.  Even minor differences from your calibrated starting setup can send the whole process askew, with the automaton missing wells, knocking stuff over, blasting past soft-stops, wrapping cables around things, blasting cables through gears, or running itself right off the table.  These events are not mutually exclusive either, so the opportunity is there to make quite the pig's breakfast out of things by not resetting the automaton's physical position to where it's brain thinks it should be.
+
Since the process is dead reckoned, getting the initial setup correct is key.  Even minor differences from your calibrated starting setup can send the whole process askew, with the automaton missing wells, knocking stuff over, blasting past soft-stops, wrapping cables around things, blasting cables through gears, or running itself right off the table.  These events are not mutually exclusive either, so the opportunity is there to ruin reagents by not resetting the device's physical position to where it's brain thinks it should be on startup.
</p>
</p>
<p>
<p>
-
This problem arises from two places:  the fact that the position is dead reckoned, and the fact that the automaton stores all its position information in volatile memory, meaning that once its powered down, it will have no recollection of where it is.  I think that in order to solve this problem, only one of these two problems has to be solved.  However, since saving to non-volatile memory may not be possible on this hardware, the only viable option may be to add sensors such that the movements are no longer dependent on a set script.
+
This problem arises from two places:  the fact that the position is dead reckoned, and the fact that the automaton stores all its position information in volatile memory, meaning that once its powered down, it will have no recollection of where it is.  In order to solve this problem, only one of these two problems has to be solved.  However, since saving to non-volatile memory may not be possible on this hardware, the only viable option may be to add sensors such that the movements are no longer dependent on a set script.
</p>
</p>
Line 315: Line 300:
</p>
</p>
<p>
<p>
-
Also a problem in this department, moving 360 units does not move you the same distance as moving 60 units, 6 times in a row.  The addition of sensors is likely the only/best way to get away from this odometry mess.
+
Also a problem in this department, moving 360 units does not move you the same distance as moving 60 units, 6 times in a row.  The addition of sensors is likely the only/best way to get away from this odometry problem.
</p>
</p>
</li>
</li>
Line 335: Line 320:
 +
<li>
 +
<b>Software Datatypes</b>
 +
<p>
 +
More of an annoyance than a problem, but all of the inputs and outputs of the processor are integer datatypes, and not doubles or floats.  While this can no doubt be worked around by changing the physical setup, sometimes it just works out that you want 5.5 instead of 5.  Since all the numbers are integers, you've got your option between 4 and 6, which usually doesn't work when you're trying to do fine control.
 +
</p>
 +
 +
 +
</li>
Line 346: Line 339:
<h4>Reliability</h4>
<h4>Reliability</h4>
<p>
<p>
-
The successful retrieval of beads from a solution in a well depends on a series of movements taking place.  First, the tip has to be positioned over the well, then the tip lowered such that the magent also descends, then the whole assembly is lifted out of the well.  A similar series of events must take place in order to introduce the beads to a new well.  Tip is positioned overtop the new well, then the tip is lowered such that the magnet does not descend.  Here it may be necessary to raise and lower the tip a few times in order to get the beads to come off, but it is very important that the magnet not descend during these actions, else the beads will all be picked back up prematurely.   
+
The successful retrieval of beads from a solution in a well depends on a series of movements taking place.  First, the tip has to be positioned over the well, then the tip lowered such that the magnet also descends, then the whole assembly is lifted out of the well.  A similar series of events must take place in order to introduce the beads to a new well.  The tip is positioned overtop the new well, then it is lowered such that the magnet does not descend.  Here it may be necessary to raise and lower the tip a few times in order to get the beads to come off, but it is very important that the magnet not descend during these actions, else the beads will all be picked back up prematurely.   
-
 
+
-
The current setup can do this, if you're wearing your lucky socks, the moon is in the right position, and there is precisely the right amount of cosmic radiation striking the planet, which is to say, not very often.  To make matters worse, you never need to move beads just once, but a whole bunch of times (if you want to accomplish anything useful that is).  Also, it has to be realised that any screw up in the execution of the script, and you've likely botched the whole construction.  The system as it now isn't really reliable enough to trust with an unsupervised BioByte construction.
+
-
 
+
 +
The current setup can do this, but not very often.  To make matters worse, you never need to move beads just once, but many times in succession (if you want to accomplish anything useful that is).  Also, it has to be realised that any misstep in the execution of the script, and you've likely botched the whole construction.  The system as it now isn't really reliable enough to trust with an unsupervised BioByte construction.
</p>
</p>
Line 360: Line 351:
<p>
<p>
-
It works, but only sometimes.  If the problem with the reliability of the system was worked out, all would be well and we'd have a nifty little, inexpensive method of automating the assembly methodIn fact, I think that it won't really take too many changes to bring this little chunk of plastic, wire, and tape into something someone might actually use.
+
It works, but only sometimes.  When the problem with the reliability of the system was worked out, this will be an inexpensive method of automating the BioByte assembly processBringing the device to this level will likely not take much more effort.
</p>
</p>
<p>
<p>
-
Keeping the same general automaton design with the LEGO, minor modifications could be performed to insert better servo motors.  At least for the the dip pen part.  That one motor/servo switch alone would probably increase the reliability of the system ~2-3x.  The other two motors could also be replaced, or the method of odometry could be improved.  The switch to the voltage converter from batteries would be another change that would not only make the whole system work better, but it would also be better for the environment (the current battery operated method sorta eats batteries, it might just be because I buy the cheap kind though).
+
Keeping the same general automaton design with the construction kit, minor modifications could be performed to insert better servo motors.  At least for the the dip pen part.  That one motor/servo switch alone would probably increase the reliability of the system ~2-3x.  The other two motors could also be replaced, or the method of odometry could be improved.  The switch to the voltage converter from batteries would be another change that would not only make the whole system work better, but it would also be better for the environment (the current battery operated method runs through batteries).
</p>
</p>
Line 392: Line 383:
-
     <h2>Future Work</h2>
+
     <h1>Future Work</h1>
<!-- <div align="justify" style="padding-left:20px; padding-right:20px"> -->
<!-- <div align="justify" style="padding-left:20px; padding-right:20px"> -->
Line 406: Line 397:
<p>
<p>
-
Despite all of the good things about using a construction set, it does introduce some serious limitations.  To introduce more features and reliability, there are a few options.  The first, and perhaps easiest, is to just get another robotic brain and set of motors.  This way you can run six motors rather than the usual three, allowing you to control more things.  The robotic brains are capable of communicating with each other wirelessly, so it would not be difficult to create one robotic platform that performs the desired tasks.
+
Despite all of the good things about using a construction set, it does introduce some serious limitations.  To introduce more features and reliability, there are a few options.  The first, and perhaps easiest, is to just get another robotic brain and set of motors.  This way you can run six motors rather than the usual three, allowing you to control more things.  Theses robotic control units are capable of communicating with each other wirelessly, so it would not be impossible to create one robotic platform that performs the desired tasks.
</p>
</p>
<p>
<p>
Slightly more complex would be to purchase one of the third party servo controller boards that are available, along with a bunch of servos.  Not only do these servo controller boards allow for the connection of more that 3 different motors, the servos that they are capable of connecting are superior in that they are able to provide more accurate positioning when compared to the motors provided with the construction set.  Unfortunately, by default, these servos are not capable of full rotation, but can be purchased with the modifications predone, or the modifications can be performed yourself.
Slightly more complex would be to purchase one of the third party servo controller boards that are available, along with a bunch of servos.  Not only do these servo controller boards allow for the connection of more that 3 different motors, the servos that they are capable of connecting are superior in that they are able to provide more accurate positioning when compared to the motors provided with the construction set.  Unfortunately, by default, these servos are not capable of full rotation, but can be purchased with the modifications predone, or the modifications can be performed yourself.
-
 
</p>
</p>
<p>
<p>
-
The most complex option, would be to do away with the construction kit entirely, or at least the brains and motor parts.  The physical building pieces may still be able to be used, depending on your design.  Replacing the robotic brain would either be a more advanced micro-controller, or a direct connection to a computer (not really a robot anymore, but hey).  The servos previously mentioned would be used for driving the motion of the machine, and would be controlled via pulse width modulation from whatever controller was being used.  This option has the advantages of being the most customisable, but you definitely pay the price in monetary cost, and in complexity of design (both programming and physical design).
+
The most complex option, would be to do away with the construction kit entirely, or at least the controller and motors.  The physical building pieces would still be an effective tool.  Replacing the robotic brain would either be a more advanced microcontroller, or a direct connection to a computer (not really a robot anymore, but hey).  The servos previously mentioned would be used for driving the motion of the machine, and would be controlled via pulse width modulation from whatever controller was being used.  This option has the advantages of being the most customisable, but you definitely pay the price in monetary cost, and in complexity of design (both programming and physical design).
-
 
+
</p>
</p>
<p>
<p>
-
The original plan for this automation project was to first use only the pieces present in the construction set to perform the 'dip-pen' method of bead movement that is presented here.  The second part was use third party parts to give the robot the power to be able to dispense its own liquids, thereby allowing the beads to stay in one tube, and the liquids to be moved around.  Due to time and budget constraints, the more complex robot that would be capable of moving its own liquids remains a pen and paper design.
+
The original plan for this automation project was to first use only the pieces present in the construction set to perform the 'dip-pen' method of bead movement that has been presented here.  The second part was use third party parts to give the robot the power to be able to dispense its own liquids, thereby allowing the beads to stay in a single tube, and the liquids to be moved around, as has been done experimentally by hand.  Due to time and budget constraints, the more complex robot that would be capable of doing this remains a pen and paper design.
</p>
</p>
Line 446: Line 435:
-
     <h2>In the event that you want to build it yourself...</h2>
+
     <h1>Reproducing Our Work</h1>
<!-- <div align="justify" style="padding-left:20px; padding-right:20px"> -->
<!-- <div align="justify" style="padding-left:20px; padding-right:20px"> -->
Line 452: Line 441:
<font size="2">
<font size="2">
-
 
-
<ul>
 
-
 
-
 
-
<li>
 
-
<h4>Are you crazy?</h4>
 
-
 
-
 
-
</li>
 
-
 
-
<li>
 
-
<h4>More seriously:</h4>
 
<p>
<p>
-
Source code is a work in progress and as such has not been posted here.  However, the latest, most up to date version is available upon request.  The physical setup is also somewhat a work in progress.  Also, creating the LCad drawings would have taken forever.  Should you desire building instructions, high resolution photographs can be taken from multiple angles and sent instead.  
+
The source code is a work in progress and therefore has not been posted here.  However, the latest, most up to date version is available upon request.  The physical setup is also somewhat a work in progress.  LCad drawings have not been produced thus far.  Should you desire building instructions, high resolution photographs can be taken from multiple angles and sent instead.  
</p>
</p>
-
</li>
 
-
</ul>
 
</font></div>
</font></div>

Latest revision as of 03:55, 22 October 2009

University of Alberta - BioBytes










































































































DIY Automation

One of the main themes of this project, as well as iGEM in general, is the simplification of both the parts and the processes of molecular biology. This allows synthetic biology to bring relatively advanced biological techniques 'to the masses'.

One of the goals of our BioBytes Assembly System was to speed up and simplify the very time consuming process of plasmid assembly. The hope was that it would be simple enough to be used by high school students. Even better, a simple inexpensive device, thereby leaving the tedious work to an inanimate object.

The Robotic Device

Since the DNA assembly method consists mainly of a few repeated and simple actions, interspersed with relatively long idle periods, it seemed like a good candidate for a little bit of automation. This little automaton is built entirely out of a popular plastic construction set, using only the standard pieces and hardware. The firmware, however, has been somewhat customised using open source code written by members of the NXT hobbyist community.

The word 'robot' may bring to mind complex devices that have advanced control schemes, state of the art sensors, and a fast microprocessor. Unfortunately, this device doesn't really have any of those things. It's control scheme is lacking, for all intents and purposes, there are no sensors, and the microprocessor is about what you would expect from a children's toy. While somewhat disappointing, these things have to be sacrificed in order to keep the device inexpensive. What we have ended up with is a simple device, capable of following a scripted set of movements that have been defined at compile-time. Luckily, the task is simple enough that this is all that we need.

  • Why use a toy?

    Why would you want to use something like a toy to build such a device, when there are so many other resources available? The construction set was chosen because of the reality that not everybody has access to a machine shop, PCB manufacturing equipment, and a microcontroller programming device. These things are usually expensive, which would probably preclude a large number of people from being able afford to use such a robotic device. The people that we would be excluding by making a complex and expensive machine are exactly the people that synthetic biology is trying to reach, pre-university and junior univeristy students. The hope was that by using materials that are relatively inexpensive, and readily available, places like high-schools and similar would be able to make use of this, both as-provided and as a starting point for any development on it that they may wish to undertake.

Hardware and Software

  • Hardware

    The easiest and perhaps only way of accomplishing the automation of the DNA assembly protocol using only the parts in the kit was to move the beads from one well to another, where the wells had previously been filled with the correct DNA pieces, washes, etc. The other option would have been to hold the beads in one place, and move the liqiud in and out of a single tube, as had been done by the experiments that are currently performing the protocol. Dispensing liquids via a pipette or other means was deemed to be difficult to do using only the 3 motors provided in the kit. A sort of 'dip pen' method was chosen, where the beads would be attracted to a 'pen' placed in one well, the lifted up and placed in another well, where they would be shaken off and allowed to sit in the solution.

    The physical design of the robot was probably the most challenging and time consuming parts of the whole process. This was mainly owing to the fact that the plastic construction pieces have only certian lengths and sizes of the different types of pieces. Also a problem was the amount of 'flex' or 'wiggle' that you could get out of the plastic parts. This led to a few failed implementations that had to be completely disassembled and started again. The current physical implementation owes its inspiration to Hans Andersons' sudoku solving robot (http://tiltedtwister.com/sudokusolver.html). This adapted design allowed for the necessary increase precision for the 'pen' to be positioned over the well, along with the advantage of not possessing a large number of points where the play in the gears and joints would become a problem.

    It would have been nearly impossible to build a device capable of carrying out the planned procedure using only the parts in the kit. For one thing, using only plastic parts, there would have been no way to harness the properties of the magnetic beads used in the assembly process. In order to make the device perform it's task, the following materials were also used: small rare earth magnets, a P1000 pipette tip that has had it's end melted shut, and some electrical tape to attach to pipette tip to the plastic building bricks.

  • Software

    There was a bit more leeway with the choice of software. For this, nxtOSEK (http://lejos-osek.sourceforge.net/) was used to program the control unit of the robot. The instructions for installation of the GNUARM tool chain that was used are located here: http://lejos-osek.sourceforge.net/installation. This installation requires quite a few different steps, and a few different things to be installed, either on the robot brain, or on the programming computer. Unlike some of the other programming methods available, this one has the advantage of being free of charge, and did not require an proprietary development environment.

    In order to preserve the original functionality of the robot brain, in the event that it would be used for something different later, the firmware loaded onto the brain was John Hansen's Enhanced NXT firmware (http://bricxcc.sourceforge.net/). While this did limit the size of the program that could be loaded, it was felt that it would be unlikely that the program would be large enough to strike this upper limit.

    The programming itself can be done in can be done in a few different languages, but the the language used for this implementation was C++. The nxtOSEK package provides various classes for the pieces of the NXT system (Motor, Clock, Button, etc). These classes are comprised of mainly protected data members (in the form of simple data types, mostly integers) and the methods to retrieve and set them. These data members must be protected as their values are supposed to be modified based on the automatons interaction with the physical world, and you don't really want to accidentally switch the values. This programming model allows for a high level of abstraction, allowing for more time doing really gig-taxing things like calibrating the automatons movements.

    Software design was very straightforward. Using examples provided for nxtOSEK, the syntax necessary for interacting with the motor classes was easy. The way that the controller determines how far the motor has turned was accomplished using both a time parameter, as well as the measured encoder distance from the motor, which had to be done because of the way the software environment handled conditional statements. The more difficult part was working out the program such that the robot is able to position the dip-pen over the desired well most of the time (see section on Calibration).

Getting to a Working Prototype

  • Hardware/Software Iteration

    Getting something that even sort of worked was very much just a iterative process (pictured is what one of these failed iterations in progress looks like). The most time consuming was the different physical configurations that had to be tried to come up with the current one. The hardest part was trying to come up with a way that would allow for the tip to descend with or without the magnet using only one motor. The only attempted solution that somewhat worked was a separate gear that is prevented from moving in one direction by a plastic brick. As the tip is lowered, the gear is prevented from spinning, which keeps the magnet from descending. If the tip is made to descend past a certain point, a pushrod trips the gear release, causing the magnet to drop to the bottom of the sealed pipette tip.

    The script writing was also a very much iterative process (you may be familiar with the 'burn and learn' method of microcontroller programming). This was made worse by the fact that not only did the movements require calibration, but every different physical configuration required a completely (and usually radically) different calibration.

  • Calibration

    Due to the fact that no sensors were used in the final plan for this robot, the calibration of its movement was one of the single most time consuming and aggravating parts of the whole process. Due the the fact that all the distances were 'dead reckoned' rather than sorted out on the fly, many times and distances had to be estimated and ultimately changed in an iterative process that allowed for something that came close to working. One of the problems that was discovered during this calibration process is the problem the physical set up posed with odometry. There seems to be a problem somewhere in either the motors themselves or some firmware/software issue, and the issue is such that some of the robots traveled distance 'disappears'. When using dead reckoning, it is vital that the robot be able to know how far it has traveled, so that it will be able to make it back, after it has traveled some distance. This is also important for it being able to accurately strike the wells, as well as staying within the boundaries of the plate.

Results

  • What it actually does:

    Surprisingly, this little robot is actually capable of moving beads from one well to another. The magnet handily attracts the beads to the outside of the tip and pulls them out of the solution. When the tip descends without the magnet, the beads only require a little bit of agitation in order to shake them off into the liquid. The movement between the wells takes place decently, generally without splashing things all over the place, contaminating other wells.

    Unfortunately, it doesn't really do it reliably, and therefore hasn't been trusted with anything more than second hand beads that have already been used in BioByte construction experiments. This reliability issue is all that stands in the way of a working, inexpensive automation tool for use with the BioByte construction method.

    In order to show that it can move the beads around, a quick experiment was done. A script was written up such that the automaton would attempt to collect beads from one well, move over to a well full of water, then drop them off. This series of actions was placed in a loop, allowing them to be repeated multiple times, just to see if it could do it all on its own, if it had enough tries.

    The upper photograph show the initial set up of the wells in question, with a bead solution in the center well, flanked by two wells with plain water. There is water in both flanking wells in order to test for the possibility of contamination of adjacent wells.

    The lower photograph shows the three wells after the robot had run through its script. We can see that the center well is indeed a lighter brown, indicating that there is a lower concentration of magnetic beads here. The well on the right now has a brown colour, indicating that beads did make it into this well. The well on the left also has a slight brown tint, showing that some beads made it to this well too. This occurred when the robot missed a well and started stabbing its tip into the surrounding plastic. This causes small splashes which cross contaminated nearby wells. The beads where not completely removed from the starting well both because of surface tension interactions with the liquid, which held a small amount of beads in the initial well. The concentration of beads in the inital well was also not helped by the unreliability of the pen lowering mechanism, which would sometimes would drop the magnet when it wasn't supposed to, and move the beads in the opposite direction.

    Some of the beads did remain on the tip, even when the tip was removed from the liquid. This is likely due to the method that was used to close off the end of the tip. The tip was melted with a lighter, which left some ridges for the beads to get stuck to. Future prototypes will have a smoother dip pen that should, at least partially, solve this problem.

  • Problems

    • Sensitivity to initial conditions

      Since the process is dead reckoned, getting the initial setup correct is key. Even minor differences from your calibrated starting setup can send the whole process askew, with the automaton missing wells, knocking stuff over, blasting past soft-stops, wrapping cables around things, blasting cables through gears, or running itself right off the table. These events are not mutually exclusive either, so the opportunity is there to ruin reagents by not resetting the device's physical position to where it's brain thinks it should be on startup.

      This problem arises from two places: the fact that the position is dead reckoned, and the fact that the automaton stores all its position information in volatile memory, meaning that once its powered down, it will have no recollection of where it is. In order to solve this problem, only one of these two problems has to be solved. However, since saving to non-volatile memory may not be possible on this hardware, the only viable option may be to add sensors such that the movements are no longer dependent on a set script.

    • Odometry

      The movements of the automaton were scripted in a fashion where it was required for it to know how far it it had moved (or swiveled, or jabbed). This information was supposed to allow it move around and be able to get back to where it started, lower its tip and be able to raise it back to where it was etc. Which sorta made sense, one step forward, then one step back and you're back to square one.

      Except that it didn't really work like that. A combination of hardware (motors units themselves) and the software (motor classes provided) seemed to have led to a situation where a whole bunch of error is introduced. In tests, the unit was not capable of doing a given number of motor rotations, then after cycling the power, doing the exact same number of rotations again. It wasn't quite as bad when the power wasn't cycled, but it was still pretty rough. A workaround was attempted that involved gearing the motors down more to reduce the effect of the +/- motor rotation to something that was within tolerance. This did help, but didn't solve the problem.

      Also a problem in this department, moving 360 units does not move you the same distance as moving 60 units, 6 times in a row. The addition of sensors is likely the only/best way to get away from this odometry problem.

    • Sensitivity to power levels

      Using the battery powered NXT brick, the movements of the robot are depend somewhat on the how run down the battery is. A less than full battery really exacerbates problems that the automaton already has; they movements become sluggish and more unpredictable, meaning that it gets a whole bunch harder to have it make it to the necessary wells with any accuracy. Especially annoying, is when you didn't think of this sooner, and you keep trying to calibrate the thing. Takes forever, gets you nowhere.

      Luckily, this is probably the easiest thing to fix. The NXT brick uses 6 AA batteries in series, so 1.5 V times six batteries gives you 9 volts. A couple of alligator clips and a 120VAC to 9VDC converter will solve this problem.

    • Software Datatypes

      More of an annoyance than a problem, but all of the inputs and outputs of the processor are integer datatypes, and not doubles or floats. While this can no doubt be worked around by changing the physical setup, sometimes it just works out that you want 5.5 instead of 5. Since all the numbers are integers, you've got your option between 4 and 6, which usually doesn't work when you're trying to do fine control.

  • Reliability

    The successful retrieval of beads from a solution in a well depends on a series of movements taking place. First, the tip has to be positioned over the well, then the tip lowered such that the magnet also descends, then the whole assembly is lifted out of the well. A similar series of events must take place in order to introduce the beads to a new well. The tip is positioned overtop the new well, then it is lowered such that the magnet does not descend. Here it may be necessary to raise and lower the tip a few times in order to get the beads to come off, but it is very important that the magnet not descend during these actions, else the beads will all be picked back up prematurely. The current setup can do this, but not very often. To make matters worse, you never need to move beads just once, but many times in succession (if you want to accomplish anything useful that is). Also, it has to be realised that any misstep in the execution of the script, and you've likely botched the whole construction. The system as it now isn't really reliable enough to trust with an unsupervised BioByte construction.

  • Conclusion:

    It works, but only sometimes. When the problem with the reliability of the system was worked out, this will be an inexpensive method of automating the BioByte assembly process. Bringing the device to this level will likely not take much more effort.

    Keeping the same general automaton design with the construction kit, minor modifications could be performed to insert better servo motors. At least for the the dip pen part. That one motor/servo switch alone would probably increase the reliability of the system ~2-3x. The other two motors could also be replaced, or the method of odometry could be improved. The switch to the voltage converter from batteries would be another change that would not only make the whole system work better, but it would also be better for the environment (the current battery operated method runs through batteries).

Future Work

  • Extensibility - Moving away from construction sets

    Despite all of the good things about using a construction set, it does introduce some serious limitations. To introduce more features and reliability, there are a few options. The first, and perhaps easiest, is to just get another robotic brain and set of motors. This way you can run six motors rather than the usual three, allowing you to control more things. Theses robotic control units are capable of communicating with each other wirelessly, so it would not be impossible to create one robotic platform that performs the desired tasks.

    Slightly more complex would be to purchase one of the third party servo controller boards that are available, along with a bunch of servos. Not only do these servo controller boards allow for the connection of more that 3 different motors, the servos that they are capable of connecting are superior in that they are able to provide more accurate positioning when compared to the motors provided with the construction set. Unfortunately, by default, these servos are not capable of full rotation, but can be purchased with the modifications predone, or the modifications can be performed yourself.

    The most complex option, would be to do away with the construction kit entirely, or at least the controller and motors. The physical building pieces would still be an effective tool. Replacing the robotic brain would either be a more advanced microcontroller, or a direct connection to a computer (not really a robot anymore, but hey). The servos previously mentioned would be used for driving the motion of the machine, and would be controlled via pulse width modulation from whatever controller was being used. This option has the advantages of being the most customisable, but you definitely pay the price in monetary cost, and in complexity of design (both programming and physical design).

    The original plan for this automation project was to first use only the pieces present in the construction set to perform the 'dip-pen' method of bead movement that has been presented here. The second part was use third party parts to give the robot the power to be able to dispense its own liquids, thereby allowing the beads to stay in a single tube, and the liquids to be moved around, as has been done experimentally by hand. Due to time and budget constraints, the more complex robot that would be capable of doing this remains a pen and paper design.

Reproducing Our Work

The source code is a work in progress and therefore has not been posted here. However, the latest, most up to date version is available upon request. The physical setup is also somewhat a work in progress. LCad drawings have not been produced thus far. Should you desire building instructions, high resolution photographs can be taken from multiple angles and sent instead.