Overall Goals
Increase software quality assurance through a variety of techniques, including but not limited to
Simulations
Unit Testing w/ code coverage scans
Static Analysis
Address Sanitizers
Develop infrastructure that can simplify interfacing between GSW and FSW
Develop frameworks to improve maintenance of future software
Heavily document software design and architectural decisions for future members to understand and learn from
Ground Software
Rewrite in Golang
Well-suited for networked and concurrent applications
Less likely to f*ck up memory (garbage collection)
Good tooling
Can work on almost any platform (can depend on our design though)
Prototype already in the works with a telemetry configuration manager and some semblance of communication between threads (not processes) using channels
Come up with how new GSW should operate. Ideally, in an extremely user friendly way that simplifies starting up the system, so anyone can do it
Idea: Write backend service(s) and have users run applications that take advantage of service(s). Most likely SOA though, so a single service. Might be simpler too and keep things standardized over microservices.
Service(s) should handle
Setting up a telemetry configuration on startup
Arbitrating between other specified nodes in a network to distribute compute. This can be somewhat complex, so we should start with just supporting a single machine, but make it extensible for this feature. Still looking into what our future ground station hardware will look like since we want to move away from LattePandas
Running other necessary services (i.e InfluxDB and Grafana)
Receiving all telemetry over UDP and processing it before serving it to application code (most likely going to be a broker architecture pattern)
Logging received telemetry over InfluxDB and csv
Logging internal messages (for debugging)
Applications
log_view - View logs. If we operate as a service, it would be ideal to have the logging service log to journalctl, but users may not be tech-pilled enough to do this, so read from that.
telem_view - Telemetry viewer. Can toggle viewing memory in base-2, 10 and 16.
Flight Software
Make code less hack(athon-)y
Re-write in C++ (TBD. Requires more prototyping, determining what the software team will look like and overall avionics team goals for 2024-2025. If we go this route, these are possible libraries (which must be properly designed, discussed and documented before implementation):
Transport - Interface for inter-board communication over various protocols (UDP, LoRa, SLIP)
Event Manager - Monitor and send events over a transport interface
Actors (Pub-Sub) - Have actors/tenants that can subscribe to message ports and send messages over message ports. See about using a zbus implementation with some prototyping. See about standardizing between all ground and flight hardware, which most likely necessitates an auto-gen tool. More on this later. Maybe have actors/tenants be able to share threads, if they access a shared resource?
Sensor - Generic sensor class with subclasses that handle retrieving data automagically
State Machine - Zephyr has a very barebones implemenation. Maybe make an autogen class that other classes inherit from. Concept of events and flags. User defines what are the possible state transitions and what events/flags will trigger these state changes.
Basic CONOPs of how the above should work
Initialize
Configure transports
Set up event manager
Create actors and subscribe to ports
Create tasks and assign actors to a task
“Start the RTOS” - Just starts all the tasks
Start tasks. When each tasks starts running it will go through
Startup() - Initialize stuff
This can include sensors!
Post-Startup() - Initialize stuff that has to be done after startup
Run
Until the end of time (or if we fail out or return early)
Different boolean flags can be set, or events can occur triggering state changes causing run method to change
Sensor classes will automatically grab data if possible and signal when tasks can take that data
etc.
Hardware Simulations
ModSim - Simulate operating a single module
Simplane - Simulate the above, but they all can communicate with each other
Need to determine software stack/tools for this
QEMU
Docker
CI Checks
Unit Tests. Unit Tests. Unit Tests. Easier to do earlier on in the process. Mandate unit tests, especially when we start library development
GTest
Static analysis tools.
Coverity is a good one
Maybe also IKOS?
Address sanitizer
Valgrind
TBD: Significantly slower than address sanitizers. There are trade-offs.
Add a linter and formatter
Internal Software Tooling
Commander (FSW) - Interface with the FSW event manager library by sending commands over a specified transport. Commands are expected to be an 8 bits.
Gaslighter (FSW) - Take generated OpenRocket output, parse a configuration and send specific data from OpenRocket as telemetry over Ethernet to see how the backplane (besides sensor-module will respond)
Generator (GSW/FSW) - Needs further design, since this has high impcat on future GSW and GSW. Take a series of yaml files and generate header and source files that link to the rest of the GSW and FSW codebases. Maybe make this a submodule for both repositories to inherit and determine what to do.