`rpl-sim`-side Serial Communications using Boost

[daftcube]

Background

We have a simulator. That's pretty cool! But we do not have a way for RPL-Sim to connect to a flight computer and exchange data.

Our current plan is to communicate to the flight computer Arduino over a Serial connection over USB.

1. At the end of the flight computer's loop function, the flight computer will report any commands that it wants to send to the simulator. These commands correspond to hardware functions the flight computer is trying to invoke, for instance deploying the main chute or opening a valve. It will then wait to receive a serial payload from the simulator.
2. At the beginning of the simulator's main loop, the simulator will halt until it receives the above command packet. Note an empty command packet is a valid command packet. Once it receives the command packet, it continues the simulation, simulating the outcome of any commands it receives.
3. At the end of the simulator's main loop, the simulator will send the flight computer a packet of data containing all the sensor data the flight computer could "sense" at that moment in time. The simulator's main loop ends, and goes to step 2.
4. The flight computer has been halting for the next set of sensor info this entire time. The flight computer will run its loop with the new sensor data, bringing us to step 1.

Protocol

For USB communications, we will use a simple protocol.

"DATA" Packets (rpl-sim → Flight Computer)

For data coming to the flight computer, we will send a fixed list of parameters. While the exact parameters remain unfinalized, use the below schema:

double sim_time;
double gps_lat;
double gps_long;
double gps_elev;
double gps_speed;
double altimeter_altitude;
byte is_launch_command; // This is 1 if the ground station sent a "launch" command and 0 if the ground station did not send a "launch" command.

Any double values are IEE-754 doubles.

"COMMAND" Packets (Flight Computer→rpl-sim)

Zero or more commands can be sent in a single loop. Thus, we have two messages:

COMMAND
byte id > 0; // A unique ID, we will build 
variable_struct payload; // We decode this struct based on the payload id.
                                       // So like, if its the main parachute, there might be no payload
                                       // as the message itself represents opening the parachute.
                                       // But if its writing to a file, we might need to decode a string.
                                       // Don't worry too much about this part.

When the flight computer is done sending commands this loop, it will send a

DONE
byte id = 0;

packet. E.g. a single 0 byte.

Requirements

This task leaves the implementation details to the developer. However, there are a few points you should hit:

• Implement the rpl-sim side of the protocol above (steps 2 and 3).
• It might actually be a good idea to shove the logic in main.cpp because that will have access to objects and functions that commands might need to interface with (e.g. a command for the main chute to deploy is handled by calling the PositionProvider's main chute function.)
• If you need to make helper functions, put them in their own header.
• While rpl-sim only supports Windows via WSL, we should still try to keep things multiplatform in case we want to add Windows support next year. Thus, use Boost libraries only as they are already linked in the project.
  • You may need to adjust the project's CMakeLists.txt to include a serial ports library. Ask Owen Bartolf for help.

Resources

This repository might help be helpful in terms of examples!