"
Team:Washington-Software/Challenges
From 2009.igem.org
| Home | Team | Project | Modeling | Notebook | Challenges |
|---|
Developer Notes on the Complexities of this Project and Achievements
This project looks deceptively simple superficially, because it is build using Lego Mindstorms, the same pieces that middle school students often used in competitions like the FLL (FIRST Lego League).
The fact that I am only 11 years old might also create a wrong impression that this project is simple. Please take a look at my bio and you will agree that I am no ordinary 7th grader.
There is an extremely vast difference between this project and other Lego Mindstorms Robot projects, in terms of technical complexities, which I will explain below.
Overcoming Limitations of Lego Mindstorms
Our team has chosen to use Lego Bricks as our hardware platform, because it is easily available, and replicable. However, Lego Mindstorms NXT uses integer math which does not give us the level of precision needed to position the pipette head accurately at each of the 96 wells or control the pump to aspirate a few milliliters of liquid. Hence we replace the Lego NXT firmware with RobotC firmware ([http://www.robotc.net/ RobotC website]) that is developed by Carnegie Mellon University Robot Academy. RobotC provide us the needed precision using floating point mathematics.
Another limitation of Lego Mindstrom is the programming environment. The simple drag-and-drop iconic interface from Lego Mindstorm might be sufficient for a typical middle school student, but does not give us a enough flexibility to develop the highly complex sophisticated programs that is needed for this project. We have selected RobotC which provide us complete freedom of programming style using a āCā like language, which rich feature sets.
Computing reverse triangulation in 3-D space.
Determining the position of a point accurately in 3-D space using a constrained 3-D Polar Coordiante System can be difficult. Here, any position on or above the well can be described in terms of x, y and z offsets from a fixed origin. In our Model C, the robot is build with three 2-segment robotic arms with 5 physical constants (See the section on Mathematical Modeling). Trying to determine the 3 angles that Motor 1, 2 and 3 must rotate to position itself to any point in 3-D space is nontrivial. Fortunately, we are able to simplify the reverse triangulation process by repeated application of a 2x2 rotational matrix.
3. Pneumatic Control and Mutual Exclusion
We use a single pneumatic tubing for 3 different pipette operations: aspirating, dispensing and cleaning. To do this, we develop a 3-way switch which is controlled by one of the motors. We also develop the software to acquire and release mutex (mutual exclusion) and prevent deadlocks.
4. Master Slave Synchronization
This part is extremely tricky, because of a limitation that is imposed by the hardware. For those of you that are familiar with NXT bricks, you will know that each brick can only be connected to a maximum of 3 motors. For these project, we need to use 6 motors, and hence we have 2 separate NXT bricks, ALPHA and PHI. The two bricks are connected using blue-tooth wireless technology. Implementing the Master Slave Synchronization between the 2 NXT modules using RobotC is quite tricky because . In our implementation, ALPHA serves as the Master Module, while PHI is the Slave Module. When ALPHA positions itself correctly at the right well, it will send a message to PHI so that it can perform the appropriate pipette operations like aspirating, dispensing or cleaning.
5. Robust Design to enable Multiple Plug-and-Play Modules.
We want to design the software system to be extremely robust and it is able to work well with different physical implementation. As a proof of concept, we have implementing 2 different physical instances of ALPHA, (ALPHA-120 and ALPHA-90, where the inter-arm angles are 120 and 90 degrees respectively). These are 2 different pipette head assemblies with different physical dimensions and geometric configurations. We have also shown that our same software works seamlessly on both instance of ALPHA. We can interchangeably mount either instances of ALPHA on the BETA frame, and it will work (see video [http://www.youtube.com/watchv=w3gM0UWEjjQ&feature=player_profilepage) here]) A flexible plug-and-play design is extremely important because it enables different iGEM project groups to collaborate, develop and swap different module instances for BioBrick-A-Bot.
