Adding "GPIO functionality" to the Opentrons (or other platforms)

Say I have a workflow centred around an Opentrons. I would like to add a small module and integrate into this workflow. For this example, let’s assume I have an LED controlled by a Raspberry Pi Pico W. The microcontroller is waiting for a specific action, which would turn on this LED. How would I do this?

There’s a few ways of asking this question:

  1. How do I extend the capabilities of the Opentrons platform to allow for GPIO functionality to integrate other sensors/actuators that I may want to use?
  2. How do I do cross-device communication between Opentrons and microcontrollers?
2 Likes

I lean towards setting up the Pico W and the OT-2 with MQTT. You can either use an external orchestrator that communicates with the OT-2 and Pico W (ideal), or use the OT-2 as the orchestrator to send commands to the Pico W.

If due to network/WiFi constraints, you can’t use a Pico W, a suitable alternative would be to get a Raspberry Pi Zero 2W (reasonable price) and connect it to eduroam/university WiFi/etc.

From what I can tell, even though a Raspberry Pi 3+ is at the core of the OT-2, the digital IO pins from the RPi don’t seem to be exposed.

@jeff.watchorn has experience integrating external devices with the OT-2 and may be able to shed some additional light.

I tend to shy away from writing custom serial communication protocols and drivers usually intended only for Windows or MacOS. If it’s a “plug together”, download some code, and “here’s the Python API” setup, great - otherwise it can be pretty time intensive IMO. Setting up two independent devices for control via an external orchestrator is a compelling concept to me from a setup, robustness, and modularity standpoint, at least for when time synchronization on the order of 10’s of ms isn’t absolutely essential (see also Improvements to the Digital Pipette - #8 by chattrick)

https://support.opentrons.com/s/article/Integrating-the-OT-2-with-other-lab-equipment

2 Likes

yeah so the way that we do the integration is:

  1. We have an external orchestration server that is instantiated on a separate computer, this runs a socket server that also wraps an MQTT client.
  2. OT-2 Jupyter notebook runs a protocol that opens a client instance to connect to an external orchestrator (over a socket server)
  3. All other devices we want to integrate connect to the orchestrator either over socket or via MQTT client
  4. Orchestrator can receive protocols over MQTT that can run any of the devices connected to the orchestrator.

To achieve what you are suggesting using this architecture you would send a command to the LED device to turn on, send your OT-2 protocol, and then turn off the LED.

I don’t think there is any achievable way to do communication directly between OT-2 and external device without some kind of translation layer (similar to our implementation of the orchestration server or leveraging MQTT or equivalent). This could likely be done a bit more simply by instantiating an MQTT client and sending an MQTT command from the OT-2 jupyter notebook, if you only care about single use operation.

3 Likes