• Introduction
  • Home
  • The Team
  • Photo Gallery
• Our Project
  • Results Summary
  • Selection System
  • In-Vitro Characterization
  • In-Vivo Characterization
  • Microfluidics
  • Data
  • Attributions
• Tools
  • Gibson Assembly
  • MITOMI
• Notebook
  • Protocols
  • May
  • June
  • July
  • August
  • September
  • October
• Considerations
  • Human Practices
  • Safety
• Acknowledgements
  • Sponsors
  • Partners

Remote Microfluidics brainstorming

some info on microfluidics and on our microfluidic online game idea...

Hardware stuff we need:

• a USB I/O for driving 24 Volt solenoids (DIY or from national instruments)
• a cheap microscope/camera system: see [http://hackteria.org/?cat=15 link]
• a cheapo PC
• a microfluidic device (we might have some simple ones already that we could play with)

Software things to figure out:

• remote control of solenoids?
• piping video stream?
• latency issues?

• need active feedback between camera and PC to determine end of game, reset game, etc.

Game related stuff:

We could either implement a one player or a two player game. We should have a virtual clone of the game that players can play if the game is very popular (only one person can play the real microfluidic version at a time). Game should be relatively quick, last only a couple of minutes tops. Games should be challenging and provide room for improvement. Implement a high-score, to award the grand-prize winner at the jamboree? Need a login based interface to keep track of who is playing?

• tug of war...
• pong clone
• snake?
• a game that takes advantage of the inherent fluid physics on microfluidic devices (i.e. why emulate physics in computer games if you can play the real deal?)
• could we make the game productive? I.e. have some useful output as a result of people playing it?
• can we somehow strengthen the link to synthetic biology?

Software

All the components to the software part exist, the challenging part will be to glue them together in a stable and secure way.

As Sebastian pointed out, the video stream and user input can remain completely separate. With this in mind, here's a tentative outline of the system: a cheap PC receives video from the USB microscope (webcam) and controls the actuators through an FTDI USB interface (serial communication through a USB port). The PC also runs a web server, to stream live video and receive commands from players. Players remotely control the game through a browser-based interface.

Video

The video stream can initially be setup using Ustream, who provide an embeddable player to stream live from a webcam. We can later figure out how to pipe a different stream to Ustream, to add our image processing layer in between. In later refinement, we can replace Ustream by our own streaming server, if judged necessary.

The image processing layer could probably be written using the Python Imaging Library, or one of the (probably many) augmented reality libraries for python.

Game

Controlling the solenoids from the PCs can be done from python. The PySerial module makes setting up of serial communication simple. The problem will be to make it stable, detect dropped sockets, etc. Activating a valve will be as simple as sending the corresponding stream to the microcontroller via the serial socket. The microcontroller looks after activating the desired valve.

Next, that python program must be hooked up to a server, that can be controlled from a standard web-browser. Therefore, the simplest option would be to run Apache with mod_python (or lighttpd or Nginx or whatever is the most fashionable webserver nowadays). mod_python loads a python program when it is initialised, and feeds it GET or POST requests from connected http clients. This will make it straightforward to link GET requests to corresponding valves: for example, if client requests http://www.example.com/valve_open/3, Apache will pass onto the python script the information "valve_open" and "3", and the script can pass on the "open valve number 3" to the microcontroller.

Finally, the player-side interface should be a relatively simple HTML and Javascript page, containing an embedded video player with the video stream, and passing on keyboard or button presses as GET requests. Button presses would be easier, as the video player might have a tendency to "steal" keyboard input from the rest of the page.

The above is sufficient to implement an initial prototype. For a production game, we still need to figure out feedback on the state of the connection, queues to ensure a single player at a time is connected, security, and so on. Again, all the components are simple, but getting them all to work together might be tough.