Interoperability layer with OT's software

Proposal

As described in this issue at the OT's repo:

Our request is about making software for different OSH pipetting robots compatible / interoperable.

I made a sketch of both projects and "places" where data may be able to cross between them:

PD: "protocol designer" GUI para la definición de protocolos; App: aplicación para controlar el robot; py: API en python para definir protocolos programando; GCODE: instrucciones de movimiento en lenguaje de máquina CNC; Smoothie/Klipper: firmware de microcontrolador para máquinas CNC.

Software layers

Layer	Opentrons	Pipetting-bot
Web protocol designer	PD source	GUI source
Desktop app	App source	Integrated with the GUI
GCODE Slicer	Python API source	Python module source/gcodeBuilder.py
Machine drivers	Likely here (smoothie_driver class) or here (controller class)	Python module source/gcodeCommander.py
Firmware	SmoothieOT	GRBL/Klipper

Here is a comparison between PD's JSON and the API's python protocols: https://opentrons.com/protocols/

Clues

Clues into the OT2's software innards and design:

• The ProtocolContext class has many functions used by the Python API, which are equivalent to ours.
• An Epic with comments around ProtocolContext, ProtocolEngine, and the self-contained-ness of JSONV6 (a protocol definition?): https://github.com/Opentrons/opentrons/issues/7548
• JSON schemas:
  • https://github.com/Opentrons/opentrons/issues/6399
  • https://github.com/Opentrons/opentrons/tree/edge/shared-data/protocol
  • V6: https://github.com/Opentrons/opentrons/blob/edge/shared-data/protocol/schemas/6.json

Possible implementation layers

There are at least 3 identifiable levels of abstraction, each with their language:

• High-level protocol: representation for humans and computers, usually in JSON or YAML.
  • Contains definitions of objects, contents, protocol steps, etc.
  • OT's protocol designer outputs at least part of this information.
  • Our "GUI" outputs the information in parts, see examples in the latest directory here.
• Mid-level protocol: usually written in a programming language.
  • Esto sería equivalente al API de OpenTrons, o algo similar al proyecto PAML/Labop.
  • Se corresponde nuestras funciones de cada acción y quizás con otras más internas.
• Low-level protocol: usually GCODE (hardware instructions).
  • Este es código interpretado por los controladores CNC (tipo GRBL), o drivers de más bajo nivel.
  • Estoy agregando el GCODE a cada action del high-level protocol en #67 (closed), para tener todo en un solo output y poder rastrear cosas.

Tasks

• Dissect OT's software.
  • Download and install the entire stack.
  • How does the software represent objects and entities?
  • Where is the data stored?
  • How does the data flow between modules of the software stack?
  • Are software modules really independent? Do they rely on remote resources?
• Find an interoperability layer with ours, either:
  • Unidirectional: allow OT protocols to be used with our machine.
  • Unidirectional: allow our protocols to be used with the OT2.
  • Bidirectional.
• Implement it!
  • Probably in Python.
• Write minimal tests.
• Write extensive documentation of every finding and design choice.

Motivation

As described in issue #64 (closed), we want to start implementing a "standard" protocol language.

This issue has an alternative "bottom-up" approach. We will try to implement interoperability, and then look at the mess we made to draw conclusions about standardization.

A more pragmatic approach.