Team:EPF-Lausanne/Tools/MICROFLUIDICS

From 2011.igem.org

(Difference between revisions)
 
(6 intermediate revisions not shown)
Line 1: Line 1:
 +
{{:Team:EPF-Lausanne/Templates/Header|title=Remote Microfluidics brainstorming}}
 +
some info on microfluidics and on our microfluidic online game idea...
some info on microfluidics and on our microfluidic online game idea...
Line 30: Line 32:
* 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?)
* 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?
* 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.
 +
 +
=== Citizen Science ===
 +
 +
http://www.scientificamerican.com/citizen-science/
 +
 +
Citizen science seems to be the new 'thing': get ordinary people to participate in scientific projects. Both to teach the population about science and to help scientific projects. Crowdsourcing is one approach (which helps advance a project). Education is another one.
 +
 +
For example, we could design a chip that teaches people about transcription factors live: have a linear template that expresses / represses GFP in presence of tetR. Flow tetR on the chip, and watch in awe as the light turns off. In another well, have the same circuit with a different promoter, to show that transcription factors are sequence-specific. Provide a cool explanation of what is happening. Alternatively, we could flow in IPTG, or whatever. The cool thing is, we're using microfluidics to illustrate the mechanisms of DNA transcription. It's educating people about genetics, synthetic biology, and microfluidics. Getting the player to flow in dNTPs, ribosomes, and stuff will illustrate live the importance of every component.
 +
 +
== 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.
 +
 +
 +
{{:Team:EPF-Lausanne/Templates/Footer}}

Latest revision as of 06:11, 12 August 2011

Retrieved from "http://2011.igem.org/Team:EPF-Lausanne/Tools/MICROFLUIDICS"