LabControl Vision

This is the vision for this project. [by John Monnier]

Ipad/ipod Touch/iPhone are ideal devices for controlling and monitoring laboratory equipment. IN addition, these platforms can display documentation, allow email and skype, and can act as input devices for taking notes such as in an electronic lab notebook. The closed platform of apple has slowed development of these applications since most research scientists developing similar tools work in open source environments.

The itunes app model is to create general purpose software, not 'experiment'-specific software as in common laboratory/astronomical work. As such, the development of an iOS application for controlling lab equipment has to be either done through enterprise license (i.e., something all UM researchers can use but can share outside) in which case an application can have very narrow scope. The downside of this is that is can not be shared outside the domain easily, nor can the application capture any revenue if there are generally useful features.

The other approach is to develop an application that can be distributed through the apple app store. This has the advantage of being able to share with others (perhaps at a cost) and to generate some revenue if others find the application useful. However, the downside is that the application can not have a narrow scope since it will not be approved for the itunes store. For instance, if I wanted an app to control the alignment of the MIRC instrument at CHARA, this would not likely be approve for itunes store. It is this latter downside that probably explains why there are no applications available currently in this space.

Over the last 2 years, I have developed a vision for how we can develop a iOs application that can both be used for specific projects and also can be generally useful. In addition, my ideas are flexible to allow for implementation on iphone or ipad, and the revenue structuring allows for a custom pricing as a function of capability. I outline these below.

The basis for the user interace will be 'panel'. Each panel will consist of a nxn GRID of tiles, the number n will depend on the platform (ipad will allow larger number of tiles). Each tile (or perhaps a group of tiles) can be separately programmed for various function such as input, output, dynamic label, static label, etc. This flexibility will allow this application to be general purpose and will accommodate a wide range of devices and user-specific applications. In addition, there will an easy selector that will allow the user to move between arbitrarily large number of 'panels', each of which might have some unique purpose in the lab setting. Lastly, the user will be easily able to export and import panels through email or other communication methods so that multiple devices can access the same devices once the programming has been setup.

Each tile will be programmable in its function within the device itself so no external applications will be necessary (although admittedly a web-based form might be practical to implement at some point). The tile functionality would be expandable with various modules costing different amounts. For instance, picomotor controls might cost $XX.XX to allow while control of an Arduino board might cost $yy.yy. The ability to customize the cost of different functions is crucial.

Here I list some examples of possible functions for each tile:

OUTPUTS:

UP ARROW icon might link to a picomotor device, deliviering a certain number of pulses.

slider: maybe used to adjust an external analog voltage

note: each output button will typically have some kind of icon (like an arrow) or it could be text.

INPUT:

webcam display: this could show a postage stamp image of webcam or subarray of webcam.

LABELS: static: used to transmit static information. e.g., "Mirror A Control"

dynamic: used to display internal memory, such as the current number of pulses sent to a given picomotor, or an external voltage.

static image: just shown image or icon for decoration.

dynamic image: perhaps a green or red badge depending on the state of some external variable or 'alarm'

OTHER: reset: a reset button might send a series of actuators back to zero. "Increase"/"decrease" : this buttom might increase or decrease the step size associated with a up arrow click.

Revenue Sharing

Ideally I'd like to do the following with any revenue generated from this app.

1) 50% of revenue should be directed back to Monnier Lab to pay for more development, e.g. undergrad students.] This may not be currently possible through tech transfer office, but might be eventually.

2) the rest of the revenue will be split according to UM guidelines -- for <$200K, 50% inventors, 1/6 dept, 1/6 college, 1/6 university

3) the "inventor" portion of the revenue will be 50% Monnier, and the other 50% split between other contributors, in a fraction determined by MOnnier (based on relative contributions of other inventors).