Background:

The AM1 integrates multiple intricate components into an automated process. Due to the complexity of each component, we began by testing each individually and then running an overall experiment that is dependent on each part functioning correctly.

The Parts:

Aquatic Environment:

In order to prove we are able to create the user specified liquid environment, we demonstrate that given a random liquid input with random pH, in our case, 3,4,5,9,10 and 11, our system can correctly and efficiently bring that pH to the pH of choice. In this demonstration, we set the desired value to 7. Using a downer pH of 3 and an upper pH of 10, the liquid environment of both high and low pH shows accurate results within ~40-80 seconds of dousing. We are confident that because of our modular design, it is easy to add more sensors of user choice. We have 3 available sensor holders for future sensors to be added.

Microfludic Device I: Droplet Generation

To test the first microfluidic device, we generated various sized droplets by varying only the biosensor and sample flow rates, and keeping all other parameters the same. We used the total biosensor and sample flow rates and the average droplet generation rate over a second-long sample to calculate the average droplet volume. Using the droplet volume, we determined the average droplet diameter. Overall, we found the droplet generation rate and therefore the droplet volume and diameter are consistent at each flow rate tested. In conclusion, the droplet generation step of our project will consistently mix the stimuli/sample and the biosensor and generate even sized droplets.

Incubation:

The next step in the process is incubation. Here we measured the incubator’s temperature from room temperature until after the temperature had stabilized. The goal for this step was for the incubator to heat up and stabilize in about 30 minutes in order to optimize the preparation time before the droplets are generated. Overall, this test showed the heat up and stabilization time is around 30 minutes, and the incubator will keep the set temperature for the entire incubation period. This is important for the stimuli to induce the biosensor’s production of the desired output at a detectable level by the second microfluidic device.

Microfluidic Device II: Spacing and Sensing

To test the second microfluidic device in the workflow, we first tested the reinjection of the droplets. This was tested by flowing droplets through the input port, and then using the oil flowing through the oil channels to space the droplets apart and drive the total flow rate. To show the microfluidic capabilities of this chip, we recorded videos of the reinjection process at the junction between the droplet and oil channels and where the fluorescence sensing occurs.

Touchscreen & User-Interface:

The user interface of the AM1 is the key feature behind the communication between the user and the device’s hardware. The interface was built using Flask, a Python framework for web applications. The choice of a Python based framework is justified by the fact that the majority of our electronics run on Python code, and using Flask therefore ensures a better compatibility with the AM1’s hardware when automating the water testing and aquatic environment simulation workflows. In order to enhance the user’s experience, we decided to let them communicate with the device without the need for their own personal computer, wifi, or any other external resource. This was achieved by running the Flask application from the AM1’s Raspberry Pi and having it displayed on the device’s touch screen. We managed to restrict the user to the domain of the user interface by reconfiguring the Raspberry Pi to run this application in kiosk mode as soon as the AM1 boots up. This prevents the user from navigating to other websites, closing the application, or attempting anything outside of the device’s capabilities. We structured our interface in a way that guides the user through the different steps of testing (see flow chart above).

As seen in the above screenshot, the user can customize their own aquatic environment using sliders to change different liquid parameters. Using sliders helped us ensure that the chosen parameters will fall within the device’s acceptable range. All user selected values were later passed as arguments to the functions that run the AM1’s hardware. Another achieved goal for our user interface is giving the users of the AM1 the ability to save, modify and delete existing protocols in addition to creating their own.

Having our user interface be a web-based application allowed us to use the Raspberry Pi browser’s Local Storage, an offline key-value database, to store parameters under protocols with user-chosen names.

All saved protocols can later be accessed by the user to be either run, modified, or deleted. In the case where the user chooses to modify or delete a selected protocol, the values stored in the data-base are changed or cleared in real time, and the modifications appear on the interface on the next page refresh.

Throughout the rest of the testing, the AM1’s touch screen displays information about the current progress of the device and guides the user through the process one step at a time.

Housing:

In order to build the best possible prototype housing for the device, we utilized the Engineering Productivity and Innovation Center (EPIC) here at Boston University. It was here that the aluminum 2020 T-bracket rails were cut precisely with saws and milling machines, essential parts 3D printed, hand-crafted nuts and bolts to fit narrow parts of the device, as well as laser cutting acrylic to fit snugly on the different shelving layers. Many parts underwent multiple iterations before reaching the final product. The housing was built to be portable, compact, as well as usable by any lab technician testing liquid environments. Features such as the electronic sliding shelf for easy access, the front panel door to access the microfluidic chips, and the adjustable touchscreen were all designed to make the most user friendly device possible. Other features focus more on making the device as functional as possible, such as the perforated aluminum to allow for air flow to the electronics section and clear shelves to see exactly where the tubing is going.

Automation:

The previously mentioned touch screen interface was also successfully used to run code controlling the device’s hardware. The central part of the AM1 allowing us to automate the testing process from our touch screen is our Raspberry Pi. Though it is as portable as a microcontroller, a Raspberry Pi actually has the properties and specifications of a computer, therefore allowing us to run code from it just the way we would run code from a laptop. We successfully used the Raspberry Pi to control all different parts of the AM1’s hardware (except the incubator, which runs on Arduino code only) with Python code: the pressure for pressure based testing, the syringe pumps for flow based testing, the sensors, and the Arduinos (which themselves control other electronics such as relay switches, peristaltic pumps, and electric valves used for liquid and air routing between microfluidic chips). We also managed to control the electronics mentioned above using our touch screen’s buttons. To avoid the lagging that can occur in the user interface by sequentially running hardware and software code, all of the device’s hardware code was run as a background task, making it parallelized with software operations. The automation of the AM1 was split into three separately tested tasks. The aquatic environment (explained in the Aquatic Environment section of this page), and the pre and post-incubation portions of water testing. The workflow used to write the Python scripts for the automation of the second two tasks can be found in the flowchart below.

System Wide Proof of Concept:

After testing each individual component, we tested the whole system and the integration of the different stages. Here, we started with our 2-input droplet generation microfluidic device and encapsulated the biosensor (IPTG-inducible GFP-bacteria) and water sample with stimuli. These droplets were ~140 um in diameter. Next, the droplets were incubated for 3 hours at 37°C. Then, the droplets were reinjected into the second microfluidic device for fluorescence sensing. The fluorescence sensing data was then passed through peak detection to detect the difference between the voltage when the fluorescent droplets were detected versus the baseline voltage from the fluorescence sensing setup. Lastly, the peak voltages were analyzed and visualized in a histogram. Here, we show the normal distribution of the fluorescence levels for the droplets with inducible bacteria. This serves as the proof of concept for the system as a whole because all the different components had to operate accurately in order to culminate in the final step measuring detectable fluorescence levels.