hulk-booster

[alexschmander]

Why? What?

This PR adds a booster-hulk crate. This builds the binary, that will run on the robot. The scope for this PR is adding the hardware interface, such that all relevant data from the robot is available to the robot, and the low command can be sent back to the robot.
The hardware interface uses zenoh to subscribe and publish robot data. For the robots topics to be available in zenoh, the booster zenoh bridge from #2177 needs to be run on the robot.

Fixes #2107
Fixes #2103

ToDo / Known Issues

• The motor states are need to be handled better. The simulator sends the serial ones, while the robot sends the parallel ones.
• We should figure out, which of the image topics is the best to use for now. Using multiple, at least if we receive them in the same cycler, makes everything very slow. Or making the receiving of all topics fast works too :D Every read on the hardware interface, that should not set the frequency of the cycler, is now moved into its own cycler. This makes these hardware interface calls asynchronous and not block each other.
• The twix image panel currently has hardcoded image dimensions. Making it dynamically use the dimensions from the image proved harder than I thought. Especially, since the JpegImage does not contain its dimensions. Tracked in Dynamic twix image size #2202
• It seems, that if certain data is not available via the Zenoh topics, the framework tries to shut down, but some blocking function does not terminate (perhaps not cancelled via the token) and the framework thus does not return with a useful error.

Ideas for Next Iterations (Not This PR)

How to Test

• On the robot: ~/zenoh_bridge
• Upload the hulk_booster binary: ./pepsi upload 192.168.10.102 --skip-os-check
• The values of the hardware interface, that are output in the robotics code as a MainOutput, should be visible in twix, when connecting to 192.168.10.102 and having a network route to the robot.

[oleflb]

There you go