Mission Control

The mission control software is equally as important as the robot itself. If it is unable to communicate, we lose all control of the robot. Lunabase is the official term for the mission control software, and it is developed in Godot with some Rust code.

At the heart of Lunabase is the communication protocol, which is a simple protocol made for this use-case called cakap2. It is a sans-io protocol meaning the actual implementation makes no actual use of a transport protocol like UDP or TCP on its own. It is instead implemented as a state machine that accepts data and produces instructions that if followed correctly result in the correct performance of the protocol. This allows this protocol to work in both async and non-async code and is one of the solutions to the function coloring problem.

That being said, cakap2 is designed to work over any unreliable protocol, so we use UDP. This allows us to avoid the handshaking sequence in TCP which can take up some time if the network quality is low. It also offers much lower latencies. However, there are many scenarios where we need the guarantee of message arrival, so cakap2 employs a strategy to reliably send messages over UDP.

For the camera streaming, we use openh264 rust bindings to encode a mosaic of 6 cameras on the robot into h264 packets. Of all the computations performed, this is the most CPU intensive. Converting from RGB to YUV, and then from YUV to H264 takes up a considerable amount of CPU time, even at an FPS of just 24. So as not to overwhelm the cakap2 state machine nor the one port being accessed for it, camera streaming is performed on the next port with no other usage for it. This means Lunabase can immediately decode packets received from that port under the assumption that they are always H264 packets.

H264 works well for lossy compression of similar data - in this case video frames. However, sometimes the operator would like to be able to see the state of the heightmap, gradient map, obstacle map, etc. These could come in the form of video frames as well, but H264 encoding could add some artifacting that could mislead the operator, or simply produce test results that are inaccurate while doing integration testing. On top of this, the latency requirements are far lesser for this data, so the data can take its time to arrive such that it is transmitted reliably. This points to using TCP instead. Since TCP is stream-oriented as opposed to UDP's packet-oriented nature, we can use brotli which is an advanced stream based compression strategy often used for HTTP. This would greatly reduce the bandwidth usage needed to send this data over.

Implementation

TODO