• 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?

Newer game ideas

Labyrinth / Pipedream

A labyrinth would be a straightforward application of microfluidics to gaming. Allow a limited time to figure out what valves to open or close, then flow in a dyed liquid. If the path is correct, the fluid flows into a "win" pool. Otherwise, it leaks into a "lose" pool.

Tamagotchi

Keep an on-chip C. Elegans worm. Flow in food, dyes, or whatever, flush out its excrements. Sounds boring but people like pets...

If we can figure out how to make them reproduce we can make a microsims game.

Crowdsourcing

A cool application of web-controlled games is "crowdsourcing": using the community's "idle brain time", or harnessing all those people wasting their time on facebook games to do something useful. Great examples are ReCaptcha, where by answering captchas people help the gutenberg project transcribe books, or somewhat forgotten ESP game, where people help label images on the internet. I just found Zooniverse: http://www.zooniverse.org/projects, where by playing games people help advance scientific projects.

For a crowdsourcing project to work we need:

• An interesting problem to solve, that is easy to solve by humans, but tough for computers. Any kind of image processing or concept assimilation comes to mind. Tasks like massive image processing are appropriate, for example colouring in neurons on microtomographs.
• A fun, simple, but addictive game. The community has to find it fun to play, and not feel like they are being exploited.
• OR a ReCaptcha style thing. You're only stealing three seconds of the person's time and you are solving a problem that is necessary for the user anyway (Captchas were used before ReCaptcha came up).

For microfluidics, I can think of a shooter-style game where people would locate glowing wells on a plate or chip. I can remember Matt saying he struggled to program that for poorly aligned chips.

Software

All the components to the software part exist, the challenging part will be to glue them toge ther 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.