Hey folks, as mentioned on Monday, I wanted to give some additional details on the Mech Control service.

Command Types:

The Mech Control service and microcontroller communicate using 4 primary commands:

move_cone
move_spout
move_both
zero_spout

In addition to these commands, there are also ACK responses for when a command completes. You can see them, an error command, and the command’s associated types in the screenshot below.

The descriptive names are not actually sent over to the microcontroller. All serial communication uses numerical representations of these commands. ACKs do not have associated types or values being sent along with the command. Just receiving the numerical representation for the ACK lets the parent service know the previously sent command completed successfully.

Command Processing:

If a batch of move commands contains some malformed data, the microcontroller is able to skip over them and just process the next command. Previously, this would cause that entire batch of commands to be lost.

A batch of commands typically represents a single step of a brew recipe. A single step will always have a single value for how much water to pour during the step, plus multiple move commands that control the pour pattern until the desired water weight is reached.

When all move commands have been processed, the mech control service sends a message back up to the brew service that contains how many commands it received, how many completed successfully, and any additional metadata that may exist. This metadata is currently just used for error info, but it can be used for more as needed.

When the brew service receives this message, it sends the next step, and on and on until the brew completes.

Here is a screenshot showing this message with a single failed command:

All higher level services use JSON when communicating step commands. The brew service is sending JSON to the mech control service, which then parses it to format the instructions to be sent over serial.

Here is an example of a JSON command:

Please note that the included direction field is a holdover and will be removed. All direction info is communicated with negative or positive values for cone steps or spout angles.

Zeroing

Zeroing is now handled by a command instead of automatically when a new serial connection occurs. The system will not allow any moves to occur until the spout is zeroed.

All in all, the setup is really robust and quite simple to reason about. If you want to check the code out, you can find both the python service and the microcontroller code in the Operator repo here. I also pushed up a self contained websocket endpoint if you want to try sending commands to the mech control service. You can find it in the helpers dir.

Ok, that’s all for now. Will see everyone again on Sunday. Cheers!

Mech Control Follow Up