Telemetry 2021 Handover

This document was created by the Robertas Norkus (2020/21 Telemetry PM) to capture the state of Telemetry for the next year.

Overview

The goal of the Telemetry submodule is to facilitate the communication between the pod and control computer by having a GUI that allows it to send commands to the pod, receive telemetry data from the pod and display it in a user-friendly way. Networking is implemented using a client-server model written in C++ on the client side (pod) and Java on the server side (base station), employing TCP sockets for receiving pod data and sending commands from the control computer to the pod and using JSON as a data interchange format. The system is also accountable for handling loss of telemetry, in which case the client side system triggers an emergency event and stops the pod.

Mission Control

Mission control is what we call our telemetry system, which allows us to communicate with the pod, receive the messages and send the commands. Mainly it consists of four fairly distinct parts:

1. GUI (frontend),
2. Java server (backend),
3. C++ module in the pod code, and
4. the debugging component, that’s present in both GUI and Java server.

GUI

Overview

GUI has been written in React, together with HTML5 and CSS3 for the frontend design. WebSockets are used for the communication between the GUI (React) and Java server. GUI includes a graph section, where the user can view up to 4 graphs at once and choose to track various data points in them. Also, GUI includes various sections for data points. There is a section where statuses of various components are displayed in color coded way and another section where numerical values and their ranges are displayed in a scrollable list. Furthermore, sizable gauges (with design inspired by SpaceX webcasts) for distance, velocity and acceleration can be viewed at the right side of the GUI and below that there are buttons for sending the commands to the pod.

What can be improved / must be done

• Currently the scrollable data section with all numerical values and their ranges are not populated with actual data points. The ability to add data points is actually there, you just need to communicate with other teams and find out what data points (and what are their ranges) to include.
• A section with current module statuses also does not contain real information. You should communicate with other teams and learn what they would like to see there. The actual design is just a placeholder, you need to come up with your own design and find the place for all the status indicators.
• There might be several bugs, one that I can remember relates to the graph section, after the run min/max values would jump around and not stay still for some reason.

Java server

Overview

It is a Spring Boot application. The main things it does:

• Sets up TCP socket listener (waiting for pod to connect)
• Starts MessageReader thread (reads from pod)
• Starts MessageSender thread when a command is sent through GUI
• Handles all the debugging functionality

What can be improved / must be done

Everything should be working, so nothing else must be done here, maybe it would be nice to just refactor it, since the code is a bit messy right now.

Debugging

Overview

Debugging component of the mission control allows the user to compile and execute the pod code with appropriate flags directly through the GUI and all the output of the code is captured, which can be then filtered and searched by the user. This allows for faster code development and possibility to debug the code through the terminal that is visible in the GUI. All the filtering is done on the backend (Java server), GUI only displays a small portion of the filtered output.

What can be improved / must be done

• Lacks the ability to run the pod code through SSH, it currently executes the pod code on the same computer as the mission control. It would be nice if the mission control were able to connect to the BBB through the SSH, run the pod code and capture the output.
• Overall the debugging part of the mission control takes a lot of processing and due to this the GUI might feel not responsive. It would be nice to somehow optimise it.

Telemetry module (C++)

Overview

The main things it does:

• Handles the connection between the pod and the mission control (Java server)
• Generates JSON messages with all the data points that must be sent to the mission control.
• Receives the commands from the mission control and notifies the state machine.

What can be improved / must be done

• The connection part and the ability to receive the commands should be working, so no work is needed there.
• As mentioned, the ability to add data points to the generated JSON message is there, but it does not currently send the real data points.
• Currently it is only possible to send numerical values (integers and floats), so it would be nice if it was able to send strings as well.