Team:Alberta/Project/Automation

From 2009.igem.org

Revision as of 00:55, 22 October 2009 by Buchko (Talk | contribs)

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

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.

The Robotic Device

Our robot is built entirely from a single Lego Mindstorms kit, using only the standard pieces and hardware sold with the kit.

  • Why use a "toy"?

    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 programmer. This equipment is rather expensive and not readily available to the general public. We 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.

Hardware and Software

  • Hardware

    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.

    Inspiration

    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.

    Structural Design

    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.

    Structural Obstacles

    An number of challenges had to be addressed in designing the robot.

    • 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.
    • There is a large degree of flex to the individual pieces decreasing the rigidity and consistency of the robot.

    Software

    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.

    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.

    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.

    Software design was relatively straightforward. Examples of the syntax necessary for interacting with the motor classes required was provided by nxtOSEK. However, 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.

Calibration

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.

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 robot. Due 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.

Results

  • What the Robot is Capable of

    The robot proved to be able to:

    • Attract beads and lift them out of the well.
    • Move the beads to the next well. It is capable of performing this action without contaminating adjacent wells.
    • Release the beads from the magnet via agitation.

    Therefore, the robot is capable of all the individual operations needed to build synthetic linear constructs on a paramagnetic bead.

  • Complications

    Unfortunately the robot is not able to move reliable and reproducibly from well to well consecutively due to limitations in either the Lego Mindstorm motors or the Firmware/Software used. At the moment, it is this complication stands in the way of a working, inexpensive automation tool for use with the BioByte construction method.

  • Other Consideration

    • Sensitivity to Initial Conditions

      Since the system is based upon set movements from an initial location, the initial location is key to the individual locations arrived at by the pen of the robot. Even minor deviations from the calibrated starting position can send the whole process askew causing the robot to miss wells.

    • Sensitivity to Power Levels

      The movements of the robot show dependency on the overall battery strength. Decreased battery power exaggerates the errors in odometry and further decreases the reliability of the robot's movements. Fortunately this problem is easy to fix. Connecting the robot to a: 120VAC to 9VDC converter should solve this problem.

    The majority of the complications addressed have the potential to be solved using a sensor based system for movement rather than a 'reckoning' based method. This would serve to correct for errors in odometry as well as decrease the importance of the initial starting position.

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.