|
|
| Line 33: |
Line 33: |
| | <font size="2"> | | <font size="2"> |
| | | | |
| - | | + | <center> |
| - | <img style="padding:20px;" src="https://static.igem.org/mediawiki/2009/6/6d/UofA09_diyAuto_Photo1.png" align = "right" width="67%"> | + | <img src="https://static.igem.org/mediawiki/2009/6/6d/UofA09_diyAuto_Photo1.png"> |
| - | | + | </center> |
| | | | |
| | <p> | | <p> |
| - | One of the main themes of this project, as well as iGEM in general, is that the simplification of both parts and processes provided by the synthetic biology movement are capable of bringing fairly advanced biological techniques 'to the masses'. | + | 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'. |
| | </p> | | </p> |
| | | | |
| | <p> | | <p> |
| - | With one of the DNA assembly techniques that have been developed during the course of the project, the goal was to speed up and simplify a very time consuming process. 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 robotic device, thereby leaving the both the original lab technician, the high school student, and the trained monkey more time for beer, which leads to the situation where a lab technician, high school student and monkey all walk into the bar (cliche, I know).
| + | 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> |
| - | </p> | + | |
| | | | |
| | </font></div> | | </font></div> |
| Line 73: |
Line 72: |
| | <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 the only the standard pieces and hardware. The firmware has been somewhat customised, however.
| + | 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> | | </p> |
| | | | |
| Line 80: |
Line 81: |
| | <li> | | <li> |
| | | | |
| - | <h4>Why use a 'toy'?</h4> | + | <h2>Why use a "toy"?</h2> |
| | | | |
| - | So 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 micro-controller programming device. These things are usually pretty expensive too, which would probably preclude large chunks of people from being able partake in such robotic delight. The hope was that by using things that are relatively inexpensive, and readily available parts, places like high-schools and similar would be able to make use of this.
| + | 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. |
| | | | |
| | </li> | | </li> |
| Line 118: |
Line 119: |
| | | | |
| | | | |
| - | <h2>Hardware and Software</h2> | + | <h1>Hardware and Software</h1> |
| | | | |
| | <!-- <div align="justify" style="padding-left:20px; padding-right:20px"> --> | | <!-- <div align="justify" style="padding-left:20px; padding-right:20px"> --> |
| Line 130: |
Line 131: |
| | <li> | | <li> |
| | | | |
| - | <h4>Hardware</h4> | + | <h2>Hardware</h2> |
| | | | |
| | <p> | | <p> |
| - | Since the idea was to only parts that came with the construction kit, the problem was a lot like on the Apollo 13 movie, where the engineer comes into the room with a big box of stuff and says something to the effect of, "We have to solve our problem using nothing but this." So the hardware for the robot consists of pieces from the construction kit. Also used was some electrical tape, some small rare earth magnets, and a pipette tip. Oh, and a thin bolt that I found underneath my desk. Ok, scratch that, I didn't really end up using the bolt, I substituted more tape.
| + | |
| | + | 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. |
| | </p> | | </p> |
| | | | |
| - | <p> | + | <h3>Inspiration</h3> |
| - | | + | <P> |
| - | <img style="padding : 20px;" src="https://static.igem.org/mediawiki/2009/7/7d/UofA_diyAuto_dipPen.png" align="right" width ="35%"> | + | 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. |
| - | | + | |
| - | 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 settled on, 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> |
| | | | |
| - | <p> | + | <center> |
| | + | <img style="padding : 20px;" src="http://tiltedtwister.com/img/sudoku/sudoku1.jpg" width="400" height="250" align="center"> |
| | + | </center> |
| | | | |
| - | 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 and only 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 amount of precision for '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.
| |
| - | </p>
| |
| | | | |
| | <center> | | <center> |
| Line 153: |
Line 152: |
| | </center> | | </center> |
| | | | |
| - | </li>
| |
| | | | |
| - | <li> | + | <h3>Structural Design</h3> |
| | + | <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> |
| - | There was a bit more leeway with the choice of software. For this, nxtOSEK (http://lejos-osek.sourceforge.net/) was used to program the 'brains' of the robot. The instructions for installation 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.
| + | 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> |
| | | | |
| - | </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 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. | + | 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. |
| | </p> | | </p> |
| | | | |
| | <p> | | <p> |
| - | 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. | + | 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. |
| | </p> | | </p> |
| | | | |
| | <p> | | <p> |
| - | Software design was very straightforward. Using examples provided for nxtOSEK, the syntax necessary for interacting with the motor classes was easy. The difficult part is working out the program such that the robot is able to position the dip-pen overtop of the desired well most of the time. | + | 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. |
| | </p> | | </p> |
| | | | |
| Line 180: |
Line 196: |
| | | | |
| | </ul> | | </ul> |
| | + | |
| | + | |
| | + | |
| | | | |
| | | | |
| Line 200: |
Line 219: |
| | | | |
| | | | |
| - | <h2>Getting to a Working Prototype</h2> | + | <h1>Calibration</h1> |
| | | | |
| | <!-- <div align="justify" style="padding-left:20px; padding-right:20px"> --> | | <!-- <div align="justify" style="padding-left:20px; padding-right:20px"> --> |
| Line 206: |
Line 225: |
| | | | |
| | <font size="2"> | | <font size="2"> |
| - |
| |
| - | <ul>
| |
| - |
| |
| - |
| |
| - | <li>
| |
| - | <h4>Hardware/Software Iteration</h4>
| |
| | | | |
| | <p> | | <p> |
| - | 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.
| + | 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> |
| - | </p>
| + | |
| - | | + | |
| - | <p>
| + | |
| - | The script writing was also a very much iterative process (you may be familiar with the 'burn and learn' method of micro-controller 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 really 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 travelled distance 'disappears' as far as it is concerned. Due to the 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, and also for staying within the boundaries of the plate.
| + | |
| - | | + | |
| - | | + | |
| - | </li>
| + | |
| - | | + | |
| - | </ul> | + | |
| - | | + | |
| | | | |
| | + | <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 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.</p> |
| | | | |
| | </font></div> | | </font></div> |
| Line 255: |
Line 250: |
| | | | |
| | | | |
| - | <h2>Results</h2> | + | <h1>Results</h1> |
| | | | |
| | <!-- <div align="justify" style="padding-left:20px; padding-right:20px"> --> | | <!-- <div align="justify" style="padding-left:20px; padding-right:20px"> --> |
| Line 266: |
Line 261: |
| | | | |
| | <li> | | <li> |
| - | <h4>What it actually does:</h4> | + | <h2>What the Robot is Capable of</h2> |
| | | | |
| | + | <P> |
| | + | The robot proved to be able to:</P> |
| | + | <ul> |
| | + | <li>Attract beads and lift them out of the well. |
| | + | <li>Move the beads to the next well. It is capable of performing this action without contaminating adjacent wells. |
| | + | <li>Release the beads from the magnet via agitation. |
| | + | </ul> |
| | <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.
| + | Therefore, the robot is capable of all the individual operations needed to build synthetic linear constructs on a paramagnetic bead. |
| - | </p>
| + | |
| | | | |
| | + | <h2>Complications</h2> |
| | <p> | | <p> |
| - | 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. | + | 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. |
| | </p> | | </p> |
| | | | |
| - | <img style="padding : 20px;" src="https://static.igem.org/mediawiki/2009/5/54/UofA09_diyAuto_InitialWells.jpg" align="right">
| |
| - |
| |
| - | <img style="padding : 20px;" src="https://static.igem.org/mediawiki/2009/1/14/UofA09_diyAuto_PostRobotWells.jpg" align="right">
| |
| - |
| |
| - |
| |
| - | <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.
| |
| - | </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 go. This also had to bonus effect of showing another potential problem associated with the reliability problems, which can be seen in the lower photograph.
| |
| - | </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 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 intial 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.
| |
| - | </p>
| |
| - |
| |
| - | </li>
| |
| | | | |
| | | | |
| | <li> | | <li> |
| - | <h4>Problems</h4> | + | <h2>Other Consideration</h2> |
| | <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 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. |
| - | </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.
| + | |
| | </p> | | </p> |
| | | | |
| Line 315: |
Line 292: |
| | | | |
| | <li> | | <li> |
| - | <b>Odometry</b> | + | <b>Sensitivity to Power Levels</b> |
| - | <p>
| + | |
| - | 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.
| + | |
| - | </p>
| + | |
| | | | |
| | <p> | | <p> |
| - | 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.
| + | 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. |
| - | </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.
| + | |
| - | </p>
| + | |
| - | </li>
| + | |
| - | | + | |
| - | <li>
| + | |
| - | <b>Sensitivity to power levels</b>
| + | |
| - | | + | |
| - | <p>
| + | |
| - | 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.
| + | |
| - | | + | |
| - | </p>
| + | |
| - | | + | |
| - | <p>
| + | |
| - | 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.
| + | |
| - | | + | |
| - | </p>
| + | |
| | | | |
| | </li> | | </li> |
| - |
| |
| - |
| |
| - | <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>
| |
| - |
| |
| | | | |
| | </ul> | | </ul> |
| | | | |
| - | </li> | + | <P> |
| - | | + | 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. |
| - | | + | |
| - | <li>
| + | |
| - | <h4>Reliability</h4>
| + | |
| - | <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 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.
| + | |
| - | | + | |
| - | | + | |
| - | </p>
| + | |
| - | | + | |
| - | | + | |
| - | </li>
| + | |
| - | | + | |
| - | <li>
| + | |
| - | <h4>Conclusion:</h4>
| + | |
| - | | + | |
| - | <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 method. In 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.
| + | |
| - | </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).
| + | |
| - | </p>
| + | |
| - | | + | |
| - | </li>
| + | |
| - | | + | |
| | | | |
| | </ul> | | </ul> |
| Line 409: |
Line 326: |
| | | | |
| | | | |
| - | <h2>Future Work</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 415: |
Line 332: |
| | | | |
| | <font size="2"> | | <font size="2"> |
| - |
| |
| - | <ul>
| |
| - |
| |
| - |
| |
| - | <li>
| |
| - | <h4>Extensibility - Moving away from construction sets</h4>
| |
| | | | |
| | <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 impossible to create one robotic platform that performs the desired tasks.
| + | 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> |
| - |
| |
| - | <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.
| |
| - |
| |
| - | </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).
| |
| - |
| |
| - | </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 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 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.
| |
| - | </p>
| |
| - |
| |
| - |
| |
| - | </li>
| |
| - |
| |
| - | </ul>
| |
| - |
| |
| - |
| |
| - |
| |
| - | </font></div>
| |
| - |
| |
| - | </div></div>
| |
| - | <b class="b4f"></b><b class="b3f"></b><b class="b2f"></b><b class="b1f"></b>
| |
| - | </td>
| |
| - | </tr>
| |
| - |
| |
| - | <tr>
| |
| - | <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>
| |
| - |
| |
| - | <div class="Outreach">
| |
| - |
| |
| - | <div style="height: 400; background:#FFFFFF; colorou line-height:100% padding: 3px 0px;">
| |
| - |
| |
| - |
| |
| - | <h2>In the event that you want to build it yourself...</h2>
| |
| - |
| |
| - | <!-- <div align="justify" style="padding-left:20px; padding-right:20px"> -->
| |
| - | <div align="justify">
| |
| - |
| |
| - | <font size="2">
| |
| - |
| |
| - | <ul>
| |
| - |
| |
| - |
| |
| - | <li>
| |
| - | <h4>Are you crazy?</h4>
| |
| - |
| |
| - |
| |
| - | </li>
| |
| - |
| |
| - | <li>
| |
| - | <h4>More seriously:</h4>
| |
| - |
| |
| - | <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.
| |
| - | </p>
| |
| - | </li>
| |
| - | </ul>
| |
| | | | |
| | </font></div> | | </font></div> |
"
