-
Notifications
You must be signed in to change notification settings - Fork 2
DevelopmentRoadmap
Table of Contents generated with DocToc
- Development Roadmap
Note The following section is intended as a request for comments. We encourage you to please give feedback on our development discussion group.
TODO Add populated examples of each of the following data tables
In an effort to increase collaboration in Microdop development, we are starting to develop a new API to provide a standardized interface for the various software components within Microdrop to communicate with one another. We also intend to expose the API through language agnostic mechanisms, such as JSON, allowing external apps to seamlessly interact with Microdrop.
Developing such an API requires language agnostic data representations of key device attributes. With this in mind, we have started to put together a spreadsheet outlining what we see as the core attributes of a DMF system.
Each data structure we propose contains attributes related to a particular part of a DMF system. Currently, we have defined 5 candidate structures.
1. Device connection graph
2. Device attributes
3. Electrode attributes
4. Electrode interface attributes
5. Electrode geometry
It is our goal to define a language agnostic representation of each of these data structures. To do this, we propose an approach inspired by database tables, where each of the above data structures can be represented as a table. Using a table format has several advantages. First, tables may be easily converted to intermediate formats, such as CSV or JSON. Second, as described below, each item, such as an electrode or a connection between electrodes, has an explicit identifier associated with it (similar to a key in a database table), allowing each component in the DMF system to be referenced. Third, various libraries may be used to perform manipulation of these tables, such as joining on key fields, etc., analogous to SQL database queries. For instance, the pandas Python package provides high-performance implementations of operation such as table joins, group-by reductions, sorting, etc. Therefore, we feel that organizing data in table form using unique identifiers for, e.g., each electrode, will provide a well-defined, language agnostic format, allowing transfer data between apps and for efficient analysis of data in the language of choice.
Note that we intend each data structure above to be a base table defining core attributes, where extension tables may be defined that may be joined to the core table. For more information and for discussion of the table structures above, see the spreadsheet here (each worksheet corresponds to a table above.
The device connection graph defines each connection between a pair of electrodes on a DMF device. Two electrodes are considered connected if a droplet can be moved between them.
The device attributes table defines the core attributes of a specific DMF device (e.g., gap height).
The attributes of each electrode (e.g., area in mm^2^).
Attributes of the connections between electrodes (e.g., width of interface).
For a DMF device, for each electrode, the electrode geometry table contains one row per vertex of the vector path defining the electrode geometry. Note that the `x` and `y` coordinates are defined in millimeters.
Note that the tables above are only intended to contain the core/required fields that we assume to apply to every DMF system. It is our intention to allow developers to extend these tables by defining fields that may be joined to these core tables.
For example, for recording feedback measurements throughout an experiment, one could create a new table that has a `node_key` column, a timestamp column, and a `volume` column. This table could then be joined against the `electrode_attributes` table to perform analysis as required.
Such extension tables may sometimes be of use in general. In such cases, the table schema could be published, either in human readable form or programmatically, such that interfaces may be created between subsets of Microdrop plugins or external applications where these extended fields are required.
Support a nested hierarchy of protocols. For example, we would like to be able to repeat a mixing protocol 100x as a step within another protocol.
The device model currently has no concept of electrode location (e.g., it doesn't encode spatial relationships between electrodes). Having a way to generate the connection graph from an SVG file is the first step toward being able to plan and route drop operations (e.g., translation, splitting, mixing, etc.).
See "Device connection graph" structure above.
Assuming we know how devices are connected and can generate a path (sequence of connected electrodes), we want to be able to translate a drop along this path and validate each step.
Automatically split (or dispense) drops without needing to specify the voltage or timing. Use impedance measurements and active feedback to achieve precise volumes.
Once we can perform all of the above operations autonomously, we can will be ready to take a high-level protocol (e.g., mix 1 drop of A with 1 drop of B for 5 seconds, then...) and convert it into basic drop operations (translate, dispense, split, mix, etc.)
This will also involve:
* figuring out dependencies
* collision avoidance (avoid other drops, contamination)
* rerouting around faults
This will have multiple advantages. It will allow people to write plugins in any language, will allow plugins to run in separate processes on the same or different computers connected over the network. It will also allow us to run the main thread on one computer (perhaps integrated into the instrument on a raspberry PI or similar) which can then be controlled by one or more remote/thin clients
Add the ability to record the camera feed used in the video overlay. Could then store this with the experiment logs.
This would facilitate optical tracking, etc.
The next generation of !DropBot (v3) will be a single, integrated system including an amplifier. Essentially, we would like to combine the low-cost and simplicity of something like the OpenDrop with the advanced features of !DropBot (impedance-based measurement of position, velocity, etc.). We are currently developing prototypes, which you can follow here.