[Groundhog] An EVTM listener implementation + basic testing framework

[shubhagrawal30]

Groundhog and BITServer code for receiving UDP multicast through the LOS/biphase and TDRSS/highrate EVTM downlinks. Also, starting a testing framework for groundhog.

Sender in MCP was implemented in #63.

Scope:

• content changes made for new groundhog evtm code
• no content changes made to the old groundhog code. Overall, several formatting changes to pass the style checker/linter
• adding CMakeList stuff for testing
• exhaustive (?) test code for the new evtm code
• no test code (yet) for the other downlinks
• no changes for possible integration with code for Iridium Pilot

TODOs for new GSs or FCs for testing:

1. Configure ufw firewall on the ground station: run sudo ufw allow 20001/udp and sudo ufw allow 20002/udp to get incoming UDP traffice on the relevent ports! If you also want pilot telemetry, do the same but with ports 31213 and 31214.
2. On your flight computer, add a default gateway to the gondola network config in /etc/netplan/00-installer-config.yaml:     routes:         - to: default           via: 192.168.1.1

[shubhagrawal30]

Also adding in EVTM commanding code! tangentially related to this PR overall, but still a good addition to review here.

[shubhagrawal30]

Shubh, do you know if the pilot link has any "in charge" protections? Maybe in bitsender? I think all links should only send telemetry if InCharge == 1 but it would be nice to double check.

Yup. In either one's infinite loop, stuff is only compressed and sent to BITSender when the thread is running on the InCharge computer.

if (!fifoIsEmpty(es->evtm_fifo) && es->ll && InCharge) { // data ready to send in evtm.c:164

if (!fifoIsEmpty(&pilot_fifo) && ll && InCharge) { // data is ready to be sent in pilot.c:116

[evanmayer]

For future reference, reviewers should resolve their own comments when they're satisfied with your changes (after a commit), or once they agree with your pushback on changes that you argue aren't necessary. This helps make sure that reviewers know their comments have been addressed. But it does require reviewers to be attentive.

[shubhagrawal30]

Ah sure, we could do that. I meant to resolve them as a way to track that I have addressed them. But the other way also sounds fine.

[shubhagrawal30]

Can you functionalize this loop body and break each test case out into a separate call to cmocka_unit_test? printfs may help track down what failed, or they may get lost in the noise, but the problem here is that if you lump all your tests together (hyperbole) under one cmocka_unit_test call, the unit test will report as failed and stop executing if any assertion is failed, so you won't have a good idea about which things failed and which things didn't. With separate test invocations for each separate case being tested, even the non-failing tests scheduled after the failing test will still be executed.

yup, that is what I have done now.

[evanmayer]

Update: looks like the flight computer had a problem with the edits to the above netplan file, and we had to remove the file from /etc/netplan dir to get the star camera computer, which we were using as a ground station, to connect to anything. We tested reception of telemetry in this situation and it seems that the above changes are not necessary...