Experimental workflow orchestration (exploring Bluesky)

[sgbaird]

@maffettone, what are your thoughts on how an example with Bluesky + SDL-Demo might look to best demonstrate Bluesky? For example, would each of the three LEDs be considered individual pieces of equipment (i.e. the red machine, the blue machine, and the green machine) or make it one device? (or maybe it would be interesting to show how it can be accomplished both ways). The same question can apply to the sensor data, which reads eight distinct wavelengths.

I'm picturing some examples going into a section in the notebooks directory. In terms of interfacing with the demo, section 1 and section 2 show how to control the hardware and run the algorithms all within the RPi 400 (i.e. no communication between separate devices). Since I've redesigned for the Pico W, I left a snapshot of the code that uses Blinkt! and a full Python implementation at https://github.com/sparks-baird/self-driving-lab-demo/tree/main/src/self_driving_lab_demo_blinkt. Section 3 shows how to interact with a local web server to control the hardware with the Pico W. Section 4 shows how to interact with it using an IoT-style MQTT interface with the PicoW. Section 5 shows how to send commands and read data via a USB connection on the PicoW.

Excited to see Bluesky in action here!

[maffettone]

My instinct would be to approach this by creating 5 ophyd devices. All things in ophyd are called motors and detectors for historical reasons, so bear with me on the semantics:

1. A "motor" device for the red channel or red LED. (At its core it is a setter with no feedback).
2. A motor device for blue.
3. A motor device for green.
4. A larger device that houses the red, green, and blue devices.
5. A detector device that compiles the sensor readings into a single array with rich metadata on read.

Once I get the hardware running, I think the notebook is the right call to show the basics in section 1, but using the bluesky RunEngine. Then we can re-visit how to dive into the more advanced control loops.

[sgbaird]

Great! Thanks for explaining the terminology, and I like the concept of each motor device for the LEDs being housed in a larger device.

[sgbaird]

As I'm extending the functionality to a different task #89 and splicing out the task-specific code from the boilerplate code https://github.com/sparks-baird/self-driving-lab-demo/pull/137/files#diff-e3007ea32bf1c21b2ec0d22c19f169646f1fbcbf5609f1b38c5b7a819ff0007c, it's looking more and more like a MicroPython version of experiment orchestration software.

[sgbaird]

Some other examples of experiment orchestration software (mostly taken from https://github.com/stars/sgbaird/lists/lab-automation):

• https://github.com/CederGroupHub/alab_management
• https://github.com/Chemios/chemios
• https://github.com/darkreactions/ESCALATE
• https://github.com/AFRL-ARES/ARES_OS
• https://github.com/PALab/place
• https://github.com/PrefectHQ/prefect (general-purpose, but could be powerful with experimental orchestration)

[sgbaird]

There is a workflow orchestration software section at https://github.com/AccelerationConsortium/awesome-self-driving-labs