What the command pipeline should do:
- Entering commands in the MCC frontend
- Need to integrate the command API endpoints into frontend
- Lockout phase, maybe 60s before a session
- Store command data in database
- Command endpoints to store the data into database
- Add delete endpoint, update endpoint
- Create packets with the commands entered
- Can use build_queue to get pending commands from the command (backend/data/resources/commands_pipeline.py)
- Can use queue_to_packets to make packets from the command queue (backend/data/resources/commands_pipeline.py)
- Need to store the packet data, and the transactional data into database
- Create the data layer functions to add contents to the transactional.packet and transactional.packet_commands table
- Send the packets to the microcontroller - Can refer heavily to Adityya’s CLI code. Just imagine an automated version of the CLI in backend/gs_cli/ground_station_cli.py
- Need to periodically build packets from the database in the GS state machine
- Need to send the packets to the OBC once we enter a session/scheduled time
- Need to implement the comms state machine (similar to the GS CLI)
- How to deploy the GS state machine
- Microcontroller executes command callbacks
- Should be done, as long as the packets match the format
Sidequests
- Database security
- ONLY allow API and GS State Machine programs to interact with the Database
- Database synchronization
- Add a table for a flag when last time database is updated, make it so Frontend and GS State Mgr are aware of when their data needs to be updated
- Web sockets for direct communication between GS state machine and frontend
- Speed or security concerns with using database as a middleman
- RPC or other protocol
- Frontend can see packet contents
- AX.25, AES, FEC decoding on frontend or something
- Frontend rehaul to view commands by session
Important notes:
- Frontend/FastAPI and the GS State Machine are separate programs
- They communicate using the database
- Both need database wrappers/layer functions