Problem Description

BitLevel Controls LLC has developed a new low cost fluorescence microscopy imaging workstation that integrates various microscopy subsystems traditionally incorporated as external devices. The instruments primary use is as the control system and image acquisition/processing engine for microscope based fluorescence imaging of cells and tissues. Photograph 1 shows the initial functional prototype being sent to a researcher/partner at UNAM, a large university in Mexico City.

The instrument is a PC based product which combines a conventional Intel Core i5/H77 based PC platform (with GeForce GTX 650Ti 2MB external graphics) with additional internal hardware peripherals including a multi-channel high power LED illuminator, filter wheel, and future provisions for other microscopy devices traditionally integrated into a system as external peripherals from both a hardware and software point of view. A 32-bit ARM Cortex-M3 microcontroller operates internally as a slave controller and manages the internal devices.

A primitive and disjointed set of system software and various utilities are being used for evaluation and testing of the prototype system with our collaborator. The challenge we would like to solve in this project will be to develop a coherent set of system software, accompanying utilities, hardware device control, data (video/image/meta) management, and of course a clean easy-to-use user interface.

For a variety of reasons, which can be discussed more thoroughly outside of this RFP, we have chosen to use an open source microscopy control software library called Micro-Manager (www.micro-manager.org). Micro-Manager (MM) is implemented as a core C++ library for experiment configuration/execution and device control. It uses device dependent modules written in C++ to implement its extensive device framework and supports plugins written in Java. Micro-Manager is tightly integrated with another open source software called ImageJ (http://rsbweb.nih.gov/ij/), which provides all the image processing functionality most microscopy labs need. ImageJ is written in Java and also supports image processing plug-ins written in Java. There are a variety of language bindings and internal scripting capabilities for both Micro- Manager and ImageJ.

Micro-Manager is generally used with its own GUI for configuration and control of the system. Its extensive device support and plug-in framework solves the usual problem associated with non-integrated systems where a large variety of potentially changing hardware setups must be supported. It is an excellent solution to this general problem, providing great flexibility, but it comes at the price of complexity and potential confusion with users easily misconfiguring the system. Our primary goal will be to use the Micro-Manager core libraries and device framework to create a dedicated fixed and simplified configuration for the core of our system. We will still seek to leverage the benefit of the MM architecture, only we will take responsibility out of the end-users hands and place it with our developers instead.

Goals

  1. Provide an almost kiosk like experience for users. Users should be presented with a simplified interface geared toward function rather than configuration.
  2. The system should boot straight into the ‘main’ application or interface and the traditional Windows shell should not be immediately accessible or visible.
  3. A browser based UI solution for use locally or hosts on the LAN would be attractive (but certainly not required)
  4. Develop Micro-Manager device interfaces for our hardware, specifically the Illuminator and the Filter Wheel for now.
  5. Develop Micro-Manager plug-ins that will present GUI based manual control of our device interfaces.
  6. Design a data storage and indexing strategy for user videos/images. A searchable database (on image metadata or other file information) would be very cool.
  7. Design a message based (preferably object oriented) bi-directional communication protocol for communication between the master PC and the slave microcontroller. Physical interfaces will be USB and/or RS-232 serial.
  8. We should have a means of complete system restore, which would include the system image and also system specific configuration from the factory.
  9. Create a software update and management framework for all software elements of the system, including firmware images for the slave microcontroller.
  10. System restore and software updates should be possible over a network.11.) Develop a strategy for making best use of the integrated auxiliary LCD on the front panel of the instrument. Can the system be used standalone without an external monitor? Or is it better used as an image preview or user control?
  11. Maintain a consistent look and feel across all pieces of the system software.
  12. Develop a system wide strategy for dealing with all the nuances of conventional
    Windows systems, for example ‘Windows Update’ should be run in a controlled manner (if at all?) so as not to impact system performance, especially in the middle of an experiment or acquisition.
  13. Develop an approach to benchmarking the system. Availability of the same system components will be impacted by motherboard (chipset), graphics, and processor lifecycles. We want to be able to deliver the same performance level (or greater) at the same or reduced cost basis, even as system components may change.
  14. Benchmarking from a performance point of view will also be important for evaluating cost reduction opportunities. For example, what is the impact of using onboard graphics versus the current external GPU.

Constraints

  • Being a PC based instrument running Windows 8.1, we will need to manage user access to the normal Windows environment and shell. In order to preserve the integrity of the system we will need to limit general access to the Windows environment for general users.

Criteria

Criteria are broken into two categories: (1) customer facing criteria reflecting the experience from an end user point of view, and (2) internal criteria reflecting ease of maintenance, extendabiltiy, ease of deployment, ease of updates, etc.

User

  1. Can senior year Bucknell biology students configure and run a basic experiment with the
    system?
  2. What is the worst case number of clicks (i.e. menu nesting, dialogues, etc.) required to access all functionality/features of the instrument.
  3. What is the density of the user interface? Is there some kind of metric for how cluttered or ‘busy’ the user screens are?
  4. Users that have already written their own ImageJ or Micro-Manager plug-ins must still be able to use those plug-ins.
  5. Remote control of the system over a private LAN via a web-browser should not
    significantly degrade the user experience.

Internal

  1. What kind of benchmarks can we run to maintain same level of performance across
    motherboard and processor lifecycles (i.e.availability).
  2. How easy is it to deploy software updates?
  3. How easy is it to modify or extend the system software.
  4. How easy is it to perform regression testing?

Resources

    1. Hardware – At least one full hardware system will be provided for the student group to develop and test software. Extra hardware subsystems can also be provided for individual subtasks – for example, spare microcontroller slave boards and LED Illuminator hardware is available for development on any laptop or PC.
    2. Firmware/Embedded Software – The student group is welcome to join in the firmware development for the onboard ARM microcontroller. Realizing the nature of embedded software development may be outside the scope of traditional computer science experience/coursework (and tools available to the department), BitLevel Controls will provide all the firmware support necessary for the students to be able to develop at least the PC side of the communications protocol and control framework.
    3. BitLevel Controls’s office in the Bucknell Entrepreneurial Incubator on Market Street Lewisburg, will be available to the group for a quiet place for development, meetings, or access to any hardware and tools that may be required.
    4. Face-Time – The student group will have access to face-to-face meetings in near real-time (at a minimum 2 or 3 times each week), either on campus or at the BitLevel Controls office on Market Street. Communication via email or Skype can be on a daily basis as necessary.

Intellectual Property

Some form of non-disclosure agreement would be necessary among all project participants. BitLevel Controls would need to retain all rights to technology developed.

In the spirit of the primary objective of this program to be student-experience focused, BitLevel can agree to help abstract or generalize certain parts of the project (that should otherwise remain proprietary) to facilitate class presentations and other academic objectives.

Licensing

As the project expects to use open source software for at least two major parts of the system (MicroManager and ImagJ), we will need to work within the scope of those licenses and retain as much derived property as possible.

Any other licensing situations, for example, commercial 3rd Party libraries the student group identifies as good solutions, can be addressed as part of the engineering dialogue through-out the course of the project.

Leave a Reply