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

(Created page with "{{Madrid-OLM/1}} <html lang="en"> <style> .tittle-secc{ padding-top: 12em !important; } .figureimage{ margin-bottom: 0.5em...")
 
 
(83 intermediate revisions by the same user not shown)
Line 19: Line 19:
 
      
 
      
 
     </style>
 
     </style>
−
   
 
−
    <head>
 
−
        <meta charset="utf-8">
 
−
        <title>Electronic part of the device</title>
 
−
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
 
−
        <meta name="description" content="Site Description Here">
 
−
    </head>
 
 
     <body class=" ">
 
     <body class=" ">
−
        <a id="start"></a>
+
 
 
         <div class="main-container">
 
         <div class="main-container">
−
            <section class="page-navigator">
+
<section class="imageblock switchable feature-large space--sm bg--secondary">
−
                <ul>
+
 
−
                    <li>
+
−
                        <a href="#home" class="inner-link" data-title="Home"></a>
+
−
                    </li>
+
−
                    <li>
+
−
                        <a href="#hard" class="inner-link" data-title="Hardware"></a>
+
−
                    </li>
+
−
                    <li>
+
−
                        <a href="#soft" class="inner-link" data-title="Software"></a>
+
−
                    </li>
+
−
                   
+
−
                </ul>
+
−
            </section>
+
−
           
+
−
            <section id="home" class="tittle-secc text-center switchable feature-large">
+
 
                 <div class="container">
 
                 <div class="container">
 
                     <div class="row justify-content-around">
 
                     <div class="row justify-content-around">
−
                        <div class="col-md-8 col-lg-8">
+
<div class="col-sm-4">
−
                             <h1 id="Teamtittle">Electronics</h1>
+
                             <h2>Embracing our aptamers</h2>
−
                             <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">
−
                            <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>
+
                              The hardware is the structure that embraces the aptamer to take it to its maximum potentiality. Without an aptamer, our hardware can barely measure anything, and without the hardware, the aptamer is just another molecule.
 +
<br><br>The structure of the device has evolved in parallel to the role that the aptamer assumes in the hardware. A good example is how the first prototype has mutated into the final version.
 +
                            </p>
 
                         </div>
 
                         </div>
 +
 +
 +
<div class="col-sm-4">
 +
                            <h2>More than a piece of hardware</h2>
 +
                            <p class="lead">
 +
                                Depending on the case, a piece of hardware could be only a tool or it could be a bit more than that. When we were brainstorming about how to face the issues related to traditional IoT devices, we concluded that the role of our hardware should walk alongside the aptamer development and integration.
 +
                            </p>
 +
                        </div>
 +
 
                     </div>
 
                     </div>
 
                     <!--end of row-->
 
                     <!--end of row-->
Line 57: Line 47:
 
                 <!--end of container-->
 
                 <!--end of container-->
 
             </section>
 
             </section>
−
           
+
             <section class="imageblock switchable switchable--switch feature-large bg--dark space--sm">
−
             <section id="hard" class="text-center">
+
                <div class="imageblock__content col-lg-6 col-md-4 pos-right">
 +
                    <div class="background-image-holder">
 +
                        <img alt="image" src="https://static.igem.org/mediawiki/2018/8/84/T--Madrid-OLM--proto.png" />
 +
                    </div>
 +
                </div>
 
                 <div class="container">
 
                 <div class="container">
 
                     <div class="row">
 
                     <div class="row">
−
                         <div class="col-md-10 col-lg-8 boxed boxed--border bg--secondary boxed--lg box-shadow">
+
                         <div class="col-lg-5 col-md-7 mt--2">
−
                             <h2>Hardware</h2>
+
                             <h1>Our first prototype</h1>
−
                             <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">
−
                            <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>
+
                                 n our first prototype, the aptamer was just a filter, such that it only trapped the target protein. The role of the hardware was automating the extraction of the target protein from the DNA filter and quantifying the total concentration of the remaining protein at 280nm absorbance, once the pollutants were wiped away.
−
                            <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>
−
                            <p class="lead" style="margin-left:15%; margin-right:10%;">Figure 1: Diagram of the different platforms that run the system.</p>
+
  <a class="btn" href="https://2018.igem.org/Team:Madrid-OLM/FirstPrototype">
−
                            <p class="lead">Broadly the system is composed of four main sections: </p>
+
<span class="btn__text">First prototype</span>
−
                            <ol class="ourlist">
+
</a>
−
                                 <li><p class="lead">A pump 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>
+
                             <!--end of modal instance-->
−
                                <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 checks <a href="http://forum.iorodeo.com/topic/91/arduino-communication/17">this</a> threat where we have explained to the RodeoStat community our set up.</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>
+
−
                            </ol>
+
−
                            <img class= "figureimage" alt="Figure1" src="https://static.igem.org/mediawiki/2018/7/74/T--Madrid-OLM--Device--FirstPrototype--wifimodule.png" style="width:40%;"/>
+
−
                            <p class="lead">The main controller which operates the rest of the components, Arduino Mega 2560.</p>
+
−
                             <p class="lead nomargin"><spam class="r ed">CAUTION</spam>: The controllers has 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="nomargin"><p class="lead">Arduino’s M7 diode, which 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 solder a 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" 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">An Arduino Shield was mounted to increase the total of pins to 8 Vin an 8 GND, to connects the power of the motor drivers.</p></li>
+
−
                            </ol>
+
−
                             <img class= "figureimage" alt="Figure1" src="https://static.igem.org/mediawiki/2018/5/57/T--Madrid-OLM--Device--FirstPrototype--Shield.png" style="width:50%;"/>
+
 
                         </div>
 
                         </div>
 
                     </div>
 
                     </div>
Line 88: Line 70:
 
                 <!--end of container-->
 
                 <!--end of container-->
 
             </section>
 
             </section>
−
           
+
             <section class="imageblock switchable feature-large space--sm bg--secondary">
−
             <section id="soft" class="text-center">
+
 +
                <div class="imageblock__content col-lg-6 col-md-4 pos-right">
 +
                    <div class="background-image-holder">
 +
                        <img alt="image" src="https://static.igem.org/mediawiki/2018/5/56/T--Madrid-OLM--final.png" />
 +
                    </div>
 +
                </div>
 
                 <div class="container">
 
                 <div class="container">
 
                     <div class="row">
 
                     <div class="row">
−
                         <div class="col-md-10 col-lg-8 boxed boxed--border bg--secondary boxed--lg box-shadow">
+
                         <div class="col-lg-5 col-md-7">
−
                             <h2>Software</h2>
+
                             <h2>The final device</h2>
−
                             <p class="lead">As we have introduced in the previous section, our system is like a patchwork, with several different platforms including actuators, sensors and control elements.</p>
+
                             <p class="lead">
−
                            <p class="lead">Although 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.</p>
+
                              But the concept of “aptamer as a filter” did not last long, as it was not sensitive enough to our purposes. And it evolved towards a different function.
−
                            <img class= "figureimage" alt="Figure1" src="https://static.igem.org/mediawiki/2018/9/96/T--Madrid-OLM--Device--FinalPrototype--SoftwareProto.png" style="width:90%;"/>
+
 
−
                            <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>
+
<br><br>The second prototype demanded a different role for the aptamer. In this new mission, the aptamer was expected to be part of the sensor. It had to adhere to an electrode and obstruct the electrons flow. So the microfluidic chip needed to be adapted to this demand. And thus, the structure of the hardware changed.
−
                            <p class="lead">In our circuit there are five platforms liable to be programmed:</p>
+
 
−
                            <ol class="ourlist">
+
<br><br>In this final version, the device is responsible for pumping a variety of solutions and samples through the chip towards the bound aptamer, collecting the resulting data from the electrode.</p>
−
                                <li><p class="lead">The <b>ESP8266</b>, module 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>
+
  <a class="btn" href="https://2018.igem.org/Team:Madrid-OLM/FinalPrototype">
−
                                <li><p class="lead">In the <b>Rodeostat</b>, potentiostat responsible of the electrochemical measurements of the sensor, we modify the original firmware so it could be controlled through the Arduino Mega, instead of a computer.</p></li>
+
<span class="btn__text">Final Device</span>
−
                                <li><p class="lead">The <b>Arduino Mega</b> controls all the 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>
+
</a>
−
                                <li><p class="lead">Outside the device, the data go to <b>Firebase server</b>. The 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 configure 8 different motors, run protocols sequentially or inject liquid in the microfluidic chips.</p></li>
+
−
                            </ol>
+
−
                            <img class= "figureimage" alt="Figure1" src="https://static.igem.org/mediawiki/2018/6/62/T--Madrid-OLM--Device--FinalPrototype--CapturProgram.png" style="width:80%;"/>
+
−
                            <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> 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>
 
                     </div>
Line 114: Line 96:
 
                 <!--end of container-->
 
                 <!--end of container-->
 
             </section>
 
             </section>
−
           
+
−
        </div>
+
                <!--end of container-->
−
        <!--<div class="loader"></div>-->
+
            </footer>
−
        <a class="back-to-top inner-link" href="#start" data-scroll-class="100vh:active">
+
<section class="imageblock switchable switchable--switch feature-large bg--dark space--sm">
−
            <i class="stack-interface stack-up-open-big"></i>
+
                <div class="imageblock__content col-lg-6 col-md-4 pos-right">
−
        </a>
+
                    <div class="background-image-holder">
 +
                        <img alt="image" src="https://static.igem.org/mediawiki/2018/8/8a/T--Madrid-OLM--Device--000.png" />
 +
                    </div>
 +
                </div>
 +
                <div class="container">
 +
                    <div class="row">
 +
                        <div class="col-lg-5 col-md-7 mt--2">
 +
                            <h1>The IoT ecosystem</h1>
 +
                            <p class="lead">
 +
                                As we required an IoT device, it had to satisfy other functionalities. The key one is to upload the acquired data to a cloud server.
 +
 
 +
<br><br>We have also developed an IoT ecosystem that surrounds the device. We have implemented an iOS app to enable the clients to visualize data on a heat map. We have set up a firebase cloud server to gather the data from our sensors, and a PC application to control directly the final device and test our different protocols </p>
 +
  <a class="btn" href="https://2018.igem.org/Team:Madrid-OLM/FirstPrototype">
 +
<span class="btn__text">First prototype</span>
 +
</a>
 +
                            <!--end of modal instance-->
 +
                        </div>
 +
                    </div>
 +
                    <!--end of row-->
 +
                </div>
 +
                <!--end of container-->
 +
            </section>
 +
                 
 +
 
  
 +
  </div>
 +
 
     </body>
 
     </body>
 
</html>
 
</html>
 
{{Madrid-OLM/footer}}
 
{{Madrid-OLM/footer}}

Latest revision as of 03:43, 18 October 2018

Madrid-OLM

Embracing our aptamers

The hardware is the structure that embraces the aptamer to take it to its maximum potentiality. Without an aptamer, our hardware can barely measure anything, and without the hardware, the aptamer is just another molecule.

The structure of the device has evolved in parallel to the role that the aptamer assumes in the hardware. A good example is how the first prototype has mutated into the final version.

More than a piece of hardware

Depending on the case, a piece of hardware could be only a tool or it could be a bit more than that. When we were brainstorming about how to face the issues related to traditional IoT devices, we concluded that the role of our hardware should walk alongside the aptamer development and integration.

image

Our first prototype

n our first prototype, the aptamer was just a filter, such that it only trapped the target protein. The role of the hardware was automating the extraction of the target protein from the DNA filter and quantifying the total concentration of the remaining protein at 280nm absorbance, once the pollutants were wiped away.

First prototype
image

The final device

But the concept of “aptamer as a filter” did not last long, as it was not sensitive enough to our purposes. And it evolved towards a different function.

The second prototype demanded a different role for the aptamer. In this new mission, the aptamer was expected to be part of the sensor. It had to adhere to an electrode and obstruct the electrons flow. So the microfluidic chip needed to be adapted to this demand. And thus, the structure of the hardware changed.

In this final version, the device is responsible for pumping a variety of solutions and samples through the chip towards the bound aptamer, collecting the resulting data from the electrode.

Final Device
image

The IoT ecosystem

As we required an IoT device, it had to satisfy other functionalities. The key one is to upload the acquired data to a cloud server.

We have also developed an IoT ecosystem that surrounds the device. We have implemented an iOS app to enable the clients to visualize data on a heat map. We have set up a firebase cloud server to gather the data from our sensors, and a PC application to control directly the final device and test our different protocols

First prototype