"
Team:Washington-Software/Challenges
From 2009.igem.org
| (7 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
| - | { | + | {{:Team:Washington-Software/Header|out|out|out|out|out|in}} |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | |} | + | |
<html> | <html> | ||
| Line 35: | Line 27: | ||
<h1>Technical Challenges and Complexities of this Project</h1> | <h1>Technical Challenges and Complexities of this Project</h1> | ||
| - | This project looks deceptively simple superficially, because it is | + | This project looks deceptively simple superficially, because it is built using Lego Mindstorms, the same pieces that middle school students often used in competitions like the FLL (FIRST Lego League). The fact that the sole developer, Gabriel, is only 11 years old might also create a wrong impression that this project is simple. However, looks are extremely deceiving and the external [[Team:Washington-Software/Team|industry experts and advisors]] on this team can also testify to that. Please take a look at [[Team:Washington-Software/Team/Gabriel|Gabriel's bio]] and you will agree that he is no ordinary 7th grader. |
| - | + | ||
| - | The fact that | + | |
| - | + | ||
| - | + | ||
| + | There is an extremely vast difference between this project and other Lego Mindstorms Robot projects, in terms of technical complexities, which we will explain below. | ||
<h2>Overcoming Limitations of Lego Mindstorms</h2> | <h2>Overcoming Limitations of Lego Mindstorms</h2> | ||
| - | 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 | + | 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 microliters of liquid. Hence we replaced the Lego NXT firmware with [http://www.robotc.net/ RobotC firmware] that is developed by Carnegie Mellon University Robot Academy. RobotC provided us the needed precision using floating point mathematics. |
| - | Another limitation of Lego | + | Another limitation of Lego Mindstorm 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, with rich feature sets. |
<h2>Computing reverse triangulation in 3-D space</h2> | <h2>Computing reverse triangulation in 3-D space</h2> | ||
| - | Determining the position of a point accurately in 3-D space using a constrained 3-D Polar | + | Determining the position of a point accurately in 3-D space using a constrained 3-D Polar Coordinant 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 built with three 2-segment robotic arms with 5 physical constants (See the section on [[Team:Washington-Software/Modeling|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 3x3 rotational matrix. |
<h2>Pneumatic Control and Mutual Exclusion</h2> | <h2>Pneumatic Control and Mutual Exclusion</h2> | ||
| - | We use a single pneumatic tubing for 3 different pipette operations: aspirating, dispensing and cleaning. To do this, we | + | We use a single pneumatic tubing for 3 different pipette operations: aspirating, dispensing and cleaning. To do this, we developed a 3-way switch which is controlled by one of the motors. We also developed the software to acquire and release mutex (mutual exclusion) and prevent deadlocks. |
<h2>Master Slave Synchronization</h2> | <h2>Master Slave Synchronization</h2> | ||
| - | 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 | + | 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 this 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 RobotC uses a non-intuitive function and because when you attempt two-way communication, messages are lost. 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. |
<h2>Robust Design to enable Multiple Plug-and-Play Modules</h2> | <h2>Robust Design to enable Multiple Plug-and-Play Modules</h2> | ||
| - | We want to design the software system to be extremely robust and it is able to work well with different physical implementations. As a proof of concept, we have implemented 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/ | + | We want to design the software system to be extremely robust and it is able to work well with different physical implementations. As a proof of concept, we have implemented 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/watch?v=w3gM0UWEjjQ 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. | 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. | ||
Latest revision as of 22:42, 21 October 2009
| Home | Team | Project | Modeling | Notebook | Challenges | Miscellaneous |
|---|
Contents |
Technical Challenges and Complexities of this Project
This project looks deceptively simple superficially, because it is built using Lego Mindstorms, the same pieces that middle school students often used in competitions like the FLL (FIRST Lego League). The fact that the sole developer, Gabriel, is only 11 years old might also create a wrong impression that this project is simple. However, looks are extremely deceiving and the external industry experts and advisors on this team can also testify to that. Please take a look at Gabriel's bio and you will agree that he is 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 we 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 microliters of liquid. Hence we replaced the Lego NXT firmware with [http://www.robotc.net/ RobotC firmware] that is developed by Carnegie Mellon University Robot Academy. RobotC provided us the needed precision using floating point mathematics.
Another limitation of Lego Mindstorm 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, with 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 Coordinant 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 built 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 3x3 rotational matrix.
Pneumatic Control and Mutual Exclusion
We use a single pneumatic tubing for 3 different pipette operations: aspirating, dispensing and cleaning. To do this, we developed a 3-way switch which is controlled by one of the motors. We also developed the software to acquire and release mutex (mutual exclusion) and prevent deadlocks.
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 this 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 RobotC uses a non-intuitive function and because when you attempt two-way communication, messages are lost. 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.
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 implementations. As a proof of concept, we have implemented 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/watch?v=w3gM0UWEjjQ 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.
