BIOREACTOR OVERVIEW

Here we detail our completion of a "bioreactor" prototype, the Taris Version 1.0, a fermenter built to continuously sustain microbial cultures by controlling the pH, media influx, and temperature within a vessel, and specifically a genetically engineered strain of Bacillus subtilis for the production of erythritol. Our reactor can be run as a chemostat (continuous batch for the purpose of keeping microbes continually in the growth phase), or as a batch fermenter (allowing the bacteria to consume all media). We've implemented live monitoring of several environmental parameters through a remote networked interface, and each sensor/motor of the bioreactor has been carefully calibrated and adjusted over the course of our research in order to attempt to optimize our system. The primary focus of the reactor was establishing a stable system for our culture that would hopefully maximize the output of any culture grown within the system. Behind the scenes, we wrote multiple Python methods to run the feedback controls for the bioreactor’s various inputs, as well as the network handlers to package the resulting sensor data to relay to the online interface. In order to make this hardware accessible to future iGEM teams, we have created a Build-A-Bioreactor Handbook so that any team can create their own low cost bioreactor for further use. Check it out here!

CHEMOSTASIS

One of the basic principles we focused on in our bioreactor’s operation is chemostasis, in which fresh growth media is pumped through a sterilizable vessel (polyethylene autoclave bags) in order to maintain a culture in a constant growth phase. The rate at which media is provided to the reaction chamber is governed by the specific growth rate of the culture. This is determined through the doubling time of the specific bacterial strain:

The goal of chemostasis is to achieve a steady state in which the dilution rate $D$, or the rate at which the bioreactor culture is being diluted with fresh media, equals the rate at which the bacteria are growing. The dilution rate can be calculated from the medium flow rate F, which is defined by the rate which liquid is flowing into and out of the reaction vessel, and the culture volume V:

In the case of our Lactobacillus strains, this doubling time was approximately 100 minutes. This meant that:

With a culture volume of 3.78L (1 US gallon), the medium flow rate can be determined:

This calculation may vary according to the specific conditions provided with the strain, so optimization is required to determine the ideal temperature, pH, and oxygen concentration--the latter of which is currently a rough estimate due to sensor cost--in order to provide the culture with conditions for maximum growth. The result of keeping the culture in a constant state of growth is the avoidance of bacterial stagnation due to intrinsic density limiters (e.g. quorum sensing or nutrient deficiency).

PUMP CHARACTERIZATION

The 0.0256L/min figure calculated above was achievable using widely-available components. To keep the system closed-loop, we used peristaltic pumps. This meant that the system's tubing could be swapped when incompatible cultures were used in the same bioreactor in succession, limiting the amount of sterilization that would have otherwise been required with traditional impeller or diaphragm pumps.

We varied the duty cycle of the PWM signal driving the motor switching and timed the fill rate for different volumes (depending on general flow rate) using a set of graduated cylinders. We also tested several PWM frequencies, namely 50,75, and 100Hz, in order to find any correlation between motor performance and driving frequency. Too high a frequency and the motor would not respond well to variable PWM, too low and the motors would stall out due to loss of clean average power. We found that 75Hz yielded the most linear response over the general duty cycle range, as can be seen below:

<

Our design had to include sensors that allowed for conditional control. The two main parameters we wanted to measure were temperature and pH. These were detected using Atlas Scientific EZO boards. Each of the boards deployed a similar control scheme, using the I2C communication protocol with a provided series of addressing commands to relay information over GPIO to a Raspberry Pi. I2C was chosen because of its compactness, with up to 1008 devices supported on only 2 data lines (compared to SPI's N+3 for N slaves). The Atlas Scientific EZO sensors were decided upon because the pH sensor offered a competitive price point with relatively easy integration with the Rapsberry Pi; the RTD sensor followed in suit. Although temperature could have been measured using a simple voltage divider, it was stylistically beneficial to put an additional BNC probe on the reactor’s peripheral circuit board, and the communication library was already in place because of the pH sensor.

FEEDBACK CONTROL

The control scheme we used for stabilizing the internal conditions of the bioreactor was PID, which stands for Proportional-Integral-Derivative. This is a common feedback mechanism that is widely applicable because of its simplicity and scalability. The PID control consists of three main transfer functions, each providing a particular gain effect on the system's output:

The first parameter in PID control is the Proportional signal, P(t), where the error e(t) is the difference between the last system output value and the system setpoint. In other words:

This proportional signal is completely based on the current error signal, scaled by some gain factor Kp:

The second parameter is the Integral signal, which takes into account the speed at which an error has occurred. This means that the controller will limit the rate at which it responds to large error in order to decrease over-response to a brief oscillation that would otherwise keep the system average fairly constant. This means that, given the system error:

where Ki is another scaling factor for the integral signal. The integral signal also has the opposite behavior for an error that has not been rectified for a long time. By integrating over the history of the error within a given time frame, the system's output continuously increases if the error is not rectified. It is evident that if e(t)=0 (the system has reached its desired value), the integral signal will reset to 0 and will begin integrating again from that new time origin.

The addition of the integral signal I(t), however, does not come without its consequences. As briefly noted, because any error that exists for a significant multiple of the sampling time Ts will quickly throw the output of the system to a very large value--and ruin the purpose of PID. This sharp rise in integral error then necessitates the additional Derivative signal, which analyzes the rate of change of the signal (and thus its future values) and accordingly dampens the behavior of the integral signal. This prevents the system output from oscillating due to high gain on the first two transfer functions, and allows it to narrow in on the desired final output value. As with the previous transfer functions, the derivative control also has a gain factor:

Combining all of these transfer functions yields the full continuous form of the PID control:

HARDWARE

For the hardware control, we used a Raspberry Pi 3 for several reasons:

It has a 1.2GHz ARM processor and 1GB RAM that provide sufficient computational power to run multiple control loops for the Atlas Scientific EZO sensors and the outputs of the ADC (from the motors' current-sense resistors).
It has integrated I2C on dedicated GPIO pins that allows for easy software access through the /dev/I2C IO path.
It has processor-independent PWM that provides hardware-level duty cycle adjustments without having to do timing interrupts.
It can run Unix-based operating systems and has an integrated WiFi adapter. This allows for easy communication with an external webserver without need for a middleman.

The hardware controller has several purposes, the first of which is to collect data from the pH and temperature sensors into software object instances to be used in the Taris PID loops. Although the motor currents are also recorded, they are more for monitoring purposes and not are used in the control loops (except by software failsafes to ensure that components are not being overdriven). The second purpose of the controller is to run the feedback loops and temporary offline data aggregation that allows for recording and storage even if the network link is inactive or has been randomly cut. Its third purpose is to relay that information to the webserver, which runs the main database and user interface for monitoring reactor response and editing parameters. These user-defined limits are used as the SP (set point) value in the PID control.

Besides the I2C interface, the Raspberry Pi also uses the PiBlaster library to write out PWM signals to the motor-driving nFETs. Although the Raspberry Pi has two dedicated, precision PWM modules, all of the GPIO pins can be driven in hardware at up to approximately 800Hz. Since we used 75Hz PWM frequencies to drive the peristaltic pumps, this was sufficient.

SOFTWARE

The Raspberry Pi communicates with the webserver--which runs a combination of Flask, D3, Bokeh, and SQL--by sending and receiving JSON packets through GET and POST commands. The HTTP communication was done using the Requests Python library, which allows for rapid HTTP development and integration with existing Flask architecture. In the case of our bioreactor, we opted for a packet format consisting of actions to control website UI and Pi-side feedback controls, error messages to allow easy debugging, and a payload containing sensor and motor data. We also included several other packet types with the backend API to better communicate with the Raspberry Pi.

PCB DESIGN

We designed a peripheral circuit board to house all of the reactor’s sensors and motor drivers. This was done in Diptrace Schematic and PCB Layout, which we exported to Gerbtool for milling. The board was routed out in the Baskin School of Engineering’s PCB Design Lab. The bits used for the milling were as small as ten thousandths of an inch!

Team:UCSC/Hardware