Difference between revisions of "Team:Madrid-OLM/HardwareElectronics"

 
(24 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
     <style>
 
     <style>
 
         .tittle-secc{
 
         .tittle-secc{
             padding-top: 12em !important;
+
             padding-top: 8em !important;
 
         }
 
         }
 
         .figureimage{
 
         .figureimage{
 
             margin-bottom: 0.5em
 
             margin-bottom: 0.5em
 
             }
 
             }
 +
        .ourlist{ 
 +
            font-size: 80% !important;
 +
        }
 +
        .nomargin{
 +
            margin-bottom: 0.3em !important;
 +
        }
 +
        .red{
 +
            color: red;
 +
        }
 
      
 
      
 
     </style>
 
     </style>
Line 26: Line 35:
 
                     </li>
 
                     </li>
 
                     <li>
 
                     <li>
                         <a href="#hard" class="inner-link" data-title="Hardwara"></a>
+
                         <a href="#hard" class="inner-link" data-title="Hardware"></a>
 
                     </li>
 
                     </li>
 
                     <li>
 
                     <li>
Line 40: Line 49:
 
                         <div class="col-md-8 col-lg-8">
 
                         <div class="col-md-8 col-lg-8">
 
                             <h1 id="Teamtittle">Electronics</h1>
 
                             <h1 id="Teamtittle">Electronics</h1>
                             <p class="lead">The final version of the device integrates multiples features. Each one of these characteristics come with its own platform and its own firmware.</p>
+
                             <p class="lead">The final version of the device integrates multiples features. Each one of these characteristics comes with its own platform and its own firmware.</p>
 
                             <p class="lead">We have chosen each one of them with the essential characteristic of being Arduino compatible. The final device looks like a patchwork, with all the different platforms working together to accomplish the main objective: automate the measurement of the electrode.</p>
 
                             <p class="lead">We have chosen each one of them with the essential characteristic of being Arduino compatible. The final device looks like a patchwork, with all the different platforms working together to accomplish the main objective: automate the measurement of the electrode.</p>
 
                         </div>
 
                         </div>
Line 49: Line 58:
 
             </section>
 
             </section>
 
              
 
              
             <section id="firstass" class="text-center">
+
             <section id="hard" class="text-center">
 
                 <div class="container">
 
                 <div class="container">
 
                     <div class="row">
 
                     <div class="row">
Line 55: Line 64:
 
                             <h2>Hardware</h2>
 
                             <h2>Hardware</h2>
 
                             <p class="lead">The hardware is mainly composed of different modules, interconnected for two main purposes: distributing the powers rails through all the modules and communicating each module with the main controller.</p>
 
                             <p class="lead">The hardware is mainly composed of different modules, interconnected for two main purposes: distributing the powers rails through all the modules and communicating each module with the main controller.</p>
                             <img class= "figureimage" alt="Figure3" src="https://static.igem.org/mediawiki/2018/1/10/T--Madrid-OLM--Device--FinalPrototype--BSA.png" style="width:70%;"/>
+
                             <img class= "figureimage" alt="Figure1" src="https://static.igem.org/mediawiki/2018/1/10/T--Madrid-OLM--Device--FinalPrototype--BSA.png" style="width:70%;"/>
                             <p class="lead" style="margin-left:30%; margin-right:10%;">Figure 3: Agarose gel after 10 cycles of amplification.</p>
+
                             <p class="lead" style="margin-left:15%; margin-right:10%;">Figure 1: Diagram of the different platforms that run the system.</p>
                              
+
                             <p class="lead">Broadly the system is composed of four main sections: </p>
                           
+
 
                             <ol class="ourlist">
 
                             <ol class="ourlist">
                                 <li><p class="lead">The hardware is mainly composed of different modules, interconnected for two main purposes: distributing the powers rails through all the modules and communicating each module with the main controller.</p></li>
+
                                 <li><p class="lead">A pumping system on a microlitre scale. Composed of eight stepper motors, controlling the syringe’s pumps. It is in charge of injecting and removing the fluid from the chips. This system is directly connected to a 12V power supply and controlled through the digital pins from the main controller, Arduino Mega.</p></li>
                                 <li><p class="lead">Optical measurement sensor. The materials required to test our sensor were a 280nm UV LED emitter and an LDR. The amount of light traversing the solution was quantified by a drop in voltage across the LDR: with higher protein concentrations, higher absorption is expected together with an increased drop in voltage. </p></li>
+
                                 <li><p class="lead">A potentiostatic measurement system, the <a href="http://iorodeo.com/products/potentiostat-shield">Rodeostat</a>, directly connected to the microfluidic chip. It connects directly to the Arduino (which governs the device) through Serial communication. For that purpose, the pins 26 and 31 of the P14 connector in the RodeoStat have been connected to the RX2 and TX2 pins on the Arduino Mega. The system is supplied by the 5V pin of the Arduino Mega power converter. For a more detailed description of the system connection, check  <a href="http://forum.iorodeo.com/topic/91/arduino-communication/17">this</a> thread where we have explained to the RodeoStat community our setup.</p></li>
                                 <li><p class="lead">Microfluidics: for channeling fluids through the chip. Microfluidics allows us to move microliters of samples, minimizing the dead volumes and the waste through the chip.</p></li>
+
                                 <li><p class="lead">A WiFi module, designed and developed by ourselves. The system is based on the board ESP8266, broadly extended in IoT applications. It communicates to Arduino through Serial protocol through its RX3 and TX3 pins. The purpose of this module is to uploads the data sent by Arduino to an external cloud server on FireBase. You could go over all the schematic and board designs on <a href="https://github.com/OpenLabMadrid/iGEM-Madrid-OLM/tree/master/Electronics/Final%20version/WiFi%20Module">our GitHub.</a></p></li>
                                <li><p class="lead">Modular design and normalization: We needed to standardize the protocols related to hardware to reduce the number of variables involved. This would restrict the design and manufacture and help us a lot when playing with certain design parameters. </p></li>
+
                                <li><p class="lead">Enable the DIY: We had the need of developing everything in a way such that anyone, regardless his/her origin could replicate our experiments in an affordable and creative way.</p></li>
+
<img class= "figureimage" alt="Figure1" src="https://static.igem.org/mediawiki/2018/7/74/T--Madrid-OLM--Device--FirstPrototype--wifimodule.png" style="width:40%;"/>
                            </ol>
+
<li class= "mt--1">
 +
<p class="lead">The main controller which operates the rest of the components, the Arduino Mega 2560.</p>
 +
<p class="lead nomargin"><spam class="red mt--1">CAUTION</spam>: the controllers have several modifications that allow it to work in the device. Trying to replicate it without the modifications is dangerous and can imply the universe destruction:</p>
 +
<ol class="ourlist">
 +
 +
<li class="mt--1"><p class="lead">Arduino’s M7 diode, whose job is to avoid an eventual situation of reverse current, has been removed. This is because of his inability to stand the 4 amperes that go through the system when the 8 motors are at their full capacity. In its position, we have soldered an IRLZ44N transistor, able to stand up to 50 A. To do it, the pins of the source and drain were connected in a similar way as the pins of the diode and the gate pin was connected to the 12V power supply. A heat sink was also put in the upper side.</p></li>
 +
<img class= "figureimage mt--1" alt="Figure1" src="https://static.igem.org/mediawiki/2018/a/ad/T--Madrid-OLM--Device--FirstPrototype--MOsfet.png" style="width:80%;"/>
 +
<li><p class="lead mt--1">An Arduino Shield was mounted to increase the total of pins to 8 Vin an 8 GND, to connect the power of the motor drivers.</p></li>
 +
</ol>
 +
<img class= "figureimage mt--1" alt="Figure1" src="https://static.igem.org/mediawiki/2018/5/57/T--Madrid-OLM--Device--FirstPrototype--Shield.png" style="width:50%;"/>
 +
</li>
 +
</ol>
 
                         </div>
 
                         </div>
 
                     </div>
 
                     </div>
Line 72: Line 91:
 
                 <!--end of container-->
 
                 <!--end of container-->
 
             </section>
 
             </section>
           
+
            <section id="firstass" class="text-center">
+
            <section id="soft" class="text-center">
 
                 <div class="container">
 
                 <div class="container">
                    <div class="row">
+
<div class="col-md-10 col-lg-8 boxed boxed--border bg--secondary boxed--lg box-shadow">
                        <div class="col-md-10 col-lg-8 boxed boxed--border bg--secondary boxed--lg box-shadow">
+
<span class="h2">Software</span>
                            <h2>Software</h2>
+
<p class="lead">
                            <ol class="ourlist">
+
As we have introduced in the previous section, our system is like a patchwork, with several different platforms including actuators, sensors and control elements.
                                <li><p class="lead">Immobilized aptamers on a PDMS surface. In order to create an electrostatic and mechanical trap for our targeted protein, we planned to work in a PDMS environment. PDMS is a well-known manufacturing material for electronics. So we could easily integrate PDMS in our device. </p></li>
+
</p>
                                <li><p class="lead">Optical measurement sensor. The materials required to test our sensor were a 280nm UV LED emitter and an LDR. The amount of light traversing the solution was quantified by a drop in voltage across the LDR: with higher protein concentrations, higher absorption is expected together with an increased drop in voltage. </p></li>
+
<p class="lead">
                                <li><p class="lead">Microfluidics: for channeling fluids through the chip. Microfluidics allows us to move microliters of samples, minimizing the dead volumes and the waste through the chip.</p></li>
+
Although it is essential to correctly choose the programming language for the different platforms, it is mandatory to keep an eye choosing the communication protocols between all of the device’s platforms.
                                <li><p class="lead">Modular design and normalization: We needed to standardize the protocols related to hardware to reduce the number of variables involved. This would restrict the design and manufacture and help us a lot when playing with certain design parameters. </p></li>
+
</p>
                                <li><p class="lead">Enable the DIY: We had the need of developing everything in a way such that anyone, regardless his/her origin could replicate our experiments in an affordable and creative way.</p></li>
+
<img class= "figureimage mt--1" alt="Figure1" src="https://static.igem.org/mediawiki/2018/9/96/T--Madrid-OLM--Device--FinalPrototype--SoftwareProto.png" style="width:90%;"/>
                            </ol>
+
<p class="lead" style="margin-left:5%; margin-right:5%;">Figure 3: The platform’s programming languages employed and the communication protocols between all of them.</p>
                        </div>
+
<br/>
                    </div>
+
 +
<p class="lead mt--1"><b>In our circuit there are five platforms liable to be programmed: </b></p>
 +
 
 +
<ol class="ourlist">
 +
<li><p class="lead">The <b>ESP8266</b>, module is in charge of all the wifi communications. We have kept the original firmware because we didn’t have time to reprogramme it during this call.</p></li>
 +
<li><p class="lead">In the <b>Rodeostat</b>, potentiostat responsible of the electrochemical measurements of the sensor, we miodified the original firmware so it could be controlled through the Arduino Mega, instead of a computer.</p></li>
 +
<li><p class="lead">The <b>Arduino Mega</b> controls the whole device: handling the motors, receiving the Rodeostat measurements and sending them to the cloud through the WiFi module or the serial communication with the PC.</p></li>
 +
<li><p class="lead">Outside the device, the data go to <b>Firebase server</b>. he server, on one hand, gets all the data and send them to an <b>iOS design app</b>, where the final user can watch the development of the data in real time.</p></li>
 +
<li><p class="lead">Finally, a <b>PC program</b>, written in python with Qt creator, is able to communicate through the serial protocol with the device. The application let you to configure 8 different motors, run protocols sequentially or inject liquid into the microfluidic chips.</p></li>
 +
</ol>
 +
<br/>
 +
<div class="slider box--shadow-wide border--round mt--1">
 +
<ul class="slides">
 +
<li>
 +
<img alt="img" src="https://static.igem.org/mediawiki/2018/6/62/T--Madrid-OLM--Device--FinalPrototype--CapturProgram.png" />
 +
</li>
 +
<li>
 +
<img alt="img" src="https://static.igem.org/mediawiki/2018/f/f6/T--Madrid-OLM--Device--FinalPrototype--slide2.jpeg" />
 +
</li>
 +
<li>
 +
<img alt="img" src="https://static.igem.org/mediawiki/2018/e/ed/T--Madrid-OLM--Device--FinalPrototype--slide1.jpeg" />
 +
</li>
 +
</ul>
 +
</div>
 +
<div class="row justify-content-around">
 +
<div class="col-md-6 col-lg-5 mt--1">
 +
<span class="h5">Codes</span>
 +
<p class="lead">You can find the code for the PC app, the Arduino control and the Rodeostat’s modified firmware in <a href="http://github.com/OpenLabMadrid/iGEM-Madrid-OLM">our GitHub.</a> </p>
 +
</div>
 +
<div class="col-lg-6 col-md-6 mt--1">
 +
<span class="h5">Acknowledgements</span>
 +
<p class="lead">
 +
Both the iOS app and the firebase server was set up thanks to the help of <b>Marcos Hernández Cifuentes.</b>. </p>
 +
</div>
 +
</div>
 +
 +
</div>
 
                     <!--end of row-->
 
                     <!--end of row-->
 
                 </div>
 
                 </div>
 
                 <!--end of container-->
 
                 <!--end of container-->
 
             </section>
 
             </section>
           
+
 
 
         </div>
 
         </div>
 
         <!--<div class="loader"></div>-->
 
         <!--<div class="loader"></div>-->

Latest revision as of 17:59, 7 November 2018

Madrid-OLM

Electronic part of the device

Electronics

The final version of the device integrates multiples features. Each one of these characteristics comes with its own platform and its own firmware.

We have chosen each one of them with the essential characteristic of being Arduino compatible. The final device looks like a patchwork, with all the different platforms working together to accomplish the main objective: automate the measurement of the electrode.

Hardware

The hardware is mainly composed of different modules, interconnected for two main purposes: distributing the powers rails through all the modules and communicating each module with the main controller.

Figure1

Figure 1: Diagram of the different platforms that run the system.

Broadly the system is composed of four main sections:

  1. A pumping system on a microlitre scale. Composed of eight stepper motors, controlling the syringe’s pumps. It is in charge of injecting and removing the fluid from the chips. This system is directly connected to a 12V power supply and controlled through the digital pins from the main controller, Arduino Mega.

  2. A potentiostatic measurement system, the Rodeostat, directly connected to the microfluidic chip. It connects directly to the Arduino (which governs the device) through Serial communication. For that purpose, the pins 26 and 31 of the P14 connector in the RodeoStat have been connected to the RX2 and TX2 pins on the Arduino Mega. The system is supplied by the 5V pin of the Arduino Mega power converter. For a more detailed description of the system connection, check this thread where we have explained to the RodeoStat community our setup.

  3. A WiFi module, designed and developed by ourselves. The system is based on the board ESP8266, broadly extended in IoT applications. It communicates to Arduino through Serial protocol through its RX3 and TX3 pins. The purpose of this module is to uploads the data sent by Arduino to an external cloud server on FireBase. You could go over all the schematic and board designs on our GitHub.

  4. Figure1
  5. The main controller which operates the rest of the components, the Arduino Mega 2560.

    CAUTION: the controllers have several modifications that allow it to work in the device. Trying to replicate it without the modifications is dangerous and can imply the universe destruction:

    1. Arduino’s M7 diode, whose job is to avoid an eventual situation of reverse current, has been removed. This is because of his inability to stand the 4 amperes that go through the system when the 8 motors are at their full capacity. In its position, we have soldered an IRLZ44N transistor, able to stand up to 50 A. To do it, the pins of the source and drain were connected in a similar way as the pins of the diode and the gate pin was connected to the 12V power supply. A heat sink was also put in the upper side.

    2. Figure1
    3. An Arduino Shield was mounted to increase the total of pins to 8 Vin an 8 GND, to connect the power of the motor drivers.

    Figure1
Software

As we have introduced in the previous section, our system is like a patchwork, with several different platforms including actuators, sensors and control elements.

Although it is essential to correctly choose the programming language for the different platforms, it is mandatory to keep an eye choosing the communication protocols between all of the device’s platforms.

Figure1

Figure 3: The platform’s programming languages employed and the communication protocols between all of them.


In our circuit there are five platforms liable to be programmed:

  1. The ESP8266, module is in charge of all the wifi communications. We have kept the original firmware because we didn’t have time to reprogramme it during this call.

  2. In the Rodeostat, potentiostat responsible of the electrochemical measurements of the sensor, we miodified the original firmware so it could be controlled through the Arduino Mega, instead of a computer.

  3. The Arduino Mega controls the whole device: handling the motors, receiving the Rodeostat measurements and sending them to the cloud through the WiFi module or the serial communication with the PC.

  4. Outside the device, the data go to Firebase server. he server, on one hand, gets all the data and send them to an iOS design app, where the final user can watch the development of the data in real time.

  5. Finally, a PC program, written in python with Qt creator, is able to communicate through the serial protocol with the device. The application let you to configure 8 different motors, run protocols sequentially or inject liquid into the microfluidic chips.


  • img
  • img
  • img
Codes

You can find the code for the PC app, the Arduino control and the Rodeostat’s modified firmware in our GitHub.

Acknowledgements

Both the iOS app and the firebase server was set up thanks to the help of Marcos Hernández Cifuentes..