https://github.com/krastanov/bioreactor

An automated bioreactor for rapid growth and directed evolution of genetically modified bacteria strains. Applicable in the study of synthesis of biofuels and other organics in modified bacteria.
https://github.com/krastanov/bioreactor

control-systems embedded plotting

Last synced: 12 months ago
JSON representation

An automated bioreactor for rapid growth and directed evolution of genetically modified bacteria strains. Applicable in the study of synthesis of biofuels and other organics in modified bacteria.

• Host: GitHub
• URL: https://github.com/krastanov/bioreactor
• Owner: Krastanov
• License: gpl-3.0
• Created: 2016-05-28T18:52:57.000Z (about 10 years ago)
• Default Branch: master
• Last Pushed: 2017-09-06T00:30:21.000Z (almost 9 years ago)
• Last Synced: 2025-06-02T22:14:22.780Z (about 1 year ago)
• Topics: control-systems, embedded, plotting
• Language: Python
• Homepage: https://blog.krastanov.org/2016/11/15/bioreactor/
• Size: 1010 KB
• Stars: 2
• Watchers: 3
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

          
# bioreactor

Automated bioreactor for bacteria growth.

See https://blog.krastanov.org/2016/11/15/bioreactor/ for pictures and description.

## Design notes

- The code assumes the existence of a single reactor, hence numerous global

  variables (`reactor` of class `Reactor`, `db` as an `sqlite3 connection`

  object, `calibration` as a `json dict`, etc.) spread over submodules

  (`reactor`, `database`, `calibration`, etc.). The number of wells is hard

  coded (maybe it will move to `calibration` in the distant future).

- Three threads are created: the scheduler from submodule `scheduler`; the web

  interface from submodule `web`; the temperature control in `reactor`. The web

  interface talks to the scheduler from a single location. The scheduler does

  not talk to anybody.

- An `sqlite` on-disk database is used by most threads. Threads access the

  database for reading and writing, relying only on `sqlite`'s internal locks.

  No optimizations of disk access are done (might lead to wear of flash-based

  drives).

- The templating for the web UI is rudimentary, relying only on `str.format`.

  The navigation toolbar is hardcoded.

- Not much attention is paid to encoding url parameters. Non ASCII parameters

  are not guaranteed to work. Special symbols might explode. More testing

  necessary.

- Temperature control is done with a PID loop in a separate (third) thread.

  Some protection and resets through `usbdevicesfs` is enabled (requires the

  compilation of `usbreset.c`) in the case of a hangup. Additional watchdogs

  are possible in the Arduino, but are not currently enabled.

- Proper database normalization would be to have a single table with data

  measurements with a column dedicated to measurement type, but the more naive

  approach with multiple tables (one per measurement type) is good enough for

  this simple project.

Copyright (C) 2017 Hegarty, Krastanov, Racharaks