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. Better yet, a trained monkey. Even better still, a simple inexpensive device, thereby leaving the tedious work to an inanimate object.

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

  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).

• 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.

• 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).

• 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.

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.