feat(api): Add Gcodes to get histogram measurements from the TOF sensors on the Flex Stacker.

[vegano1]

Overview

We can finally take histogram readings once we load the measurement application, configure the custom SPAD map, load the factory calibration data, and load short-range calibration data. Each histogram reading is 3840 bytes in total; we need to be able to send that data over serial whenever asked, right now, we won't be processing this data internally in the Flex Stacker firmware since we want to collect data to create a baseline. So, we will need a mechanism that allows the Python host to request a histogram reading and receive packets until the entire reading has been transferred. This pull request goes with this Opentrons/opentrons-modules#505 pr.

Closes: EXEC-1181

Test Plan and Hands on Testing

• Make sure we can start/stop TOF measurements with GCODE 225
• Make sure we can receive TOF histogram frames with GCODE 226
• Make sure the get_tof_histogram function requests/parses 30 histogram frames and processes them to produce channel measurements from 0-9.

Changelog

• Added M225 - Start/Cancel TOF Sensor Measurements Gcode
• Added M226 - Get TOF Histogram measurement Gcode
• Added get_tof_function that starts and requests TOF histogram measurements from the Flex Stacker.

Review requests

Any feedback would be great, especially the get_tof_histogram function.

Risk assessment

low, unreleased

[SyntaxColoring]

From an outsider's perspective, this all makes sense and is pretty easy to follow. Thanks!

[ahiuchingau]

Implementation looks good to me!

[sfoster1]

Looks good but let's call the message something else since it does more than start, and we should move the parse code into a place where the system can cancel the measurement if it's ongoing.

What happens if a client starts a measurement then disconnects and reconnects? Can we tolerate an ongoing measurement or detect and cancel it? Will sending two starts in a row just restart the measurement?

Also, please add tests.

[sfoster1]

is a caller above the level of the module ever going to want to get just one frame of the measurement instead of the full histogram? if not, can we lose this from the abstract base class?

[vegano1]

Yeah, the sensor can support other types of measurements which I didn't implement here.
get_tof_measurement would be the interface for getting other types of measurements as well.

[sfoster1]

oh, then can we call it something else?

[vegano1]

Looks good but let's call the message something else since it does more than start, and we should move the parse code into a place where the system can cancel the measurement if it's ongoing.

What happens if a client starts a measurement then disconnects and reconnects? Can we tolerate an ongoing measurement or detect and cancel it? Will sending two starts in a row just restart the measurement?

Also, please add tests.

We can detect and cancel measurements, when there's a measurement already in progress we will receive an invalid response, we can capture that and send cancel.

[sfoster1]

enable_tof_measurement() kind of has the same problem, right? enable_tof_measurement(..., enable=False) doesn't really feel good. Sorry to keep harping on this but it's a real pet peeve. Let's call it manage_tof_measurement or start_stop_tof_measurment or something.