Team:Washington-Software/Challenges

From 2009.igem.org

(Difference between revisions)
 
(10 intermediate revisions not shown)
Line 1: Line 1:
-
{| style="color:Gold;background-color:#500050;" cellpadding="3" cellspacing="1" border="1" bordercolor="#fff" width="62%" align="center"
+
{{:Team:Washington-Software/Header|out|out|out|out|out|in}}
-
!align="center";style="border: none;" |[[Image:WashingtonColorSeal-21-clip.gif|50px]]
+
-
!align="center"; style="border: #6b0c6a outset 3px;" |[[Team:Washington-Software|<font color="gold">Home</font>]]
+
-
!align="center"; style="border: #6b0c6a outset 3px;" |[[Team:Washington-Software/Team|<font color="gold">Team</font>]]
+
-
!align="center"; style="border: #6b0c6a outset 3px;" |[[Team:Washington-Software/Project|<font color="gold">Project</font>]]
+
-
!align="center"; style="border: #6b0c6a outset 3px;" |[[Team:Washington-Software/Modeling|<font color="gold">Modeling</font>]]
+
-
!align="center"; style="border: #6b0c6a outset 3px;" |[[Team:Washington-Software/Notebook|<font color="gold">Notebook</font>]]
+
-
!align="center"; style="border: #6b0c6a inset 3px;" |[[Team:Washington-Software/Challenges|<font color="gold">Challenges</font>]]
+
-
|}
+
<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 build using Lego Mindstorms, the same pieces that middle school students often used in competitions like the FLL (FIRST Lego League).   
+
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 I am only 11 years old might also create a wrong impression that this project is simple. Please take a look at [[Team:Washington-Software/Team/Gabriel|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.
+
 +
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 milliliters of liquid. Hence we replace the Lego NXT firmware with [http://www.robotc.net/ RobotC firmware] that is developed by Carnegie Mellon University Robot Academy. RobotC provide us the needed precision using floating point mathematics.  
+
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 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, with rich feature sets.
+
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 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 [[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 2x2 rotational matrix.
+
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 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.
+
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 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.
+
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 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])
+
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

WashingtonColorSeal-21-clip.gif 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 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 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.