Flight Executive

[ivogeorg]

Description

Main flight loop has to be stable and easy to recover. Preferably, multi-threaded (RPi 4 has a quad-core processor). It should integrate all components (see Deliverables for details).

Knowledge

1. Python Thread-based parallelism. Due to the Global Interpreter Lock, only one thread can execute at a time, still suitable for multiple I/O-bound tasks (GIL is always released for I/O). For better use of multi-core processing resources, multiprocessing or concurrent.futures.ProcessPoolExecutor should be used.
2. Cubesat flight loops (TODO).
   1. OreSat.
   2. CubeSat standard.
   3. PyCubed.
   4. DynOSSAT.
3. cFS flight loop (TODO).
4. PX4 flight loop (TODO).
5. Research:
   1. Flight loop study.

Deliverables

A main program that manages the following tasks:

1. Telemetry gathering, recording, and sending over Iridium. (See #3, #6)
2. Handling of state and attitude determination events (e.g. rest vs motion, etc.).
3. Handling of system health events (e.g. temperature out of operating range, health check after shock, etc.).
4. Handling of power events (e.g. commence graceful/soft shutdown on low-battery signal, etc.).
5. Camera recording.
6. Ground-station command loop.

Time estimate

12 man-hours

[NotfatPrince]

[NotfatPrince]

[ivogeorg]

Have to design the WiFi streaming for the demo @NotfatPrince @Christopher-Dauchter

[ivogeorg]

Update

[ivogeorg]

Update summary

1. System Monitor part of Flight Executive.
2. Preflight Check's acceptance rules derived from telemetry rules.
3. Split log into Telemetry Log, Camera Log, (Iridium/Comms) Connection Log, Executive Log.
4. Added Rules to:
   1. Camera managing storage.
   2. Camera particular moments of interest.
   3. Telemetry rules in System Monitor.
5. Iridium sends 3 types of messages:
   1. Periodic (automatic) updates.
   2. Responses to data requests from ground.
   3. Critical alerts sent by the System Monitor.
6. Connection status removed from Telemetry log.

[ivogeorg]

Update

[ivogeorg]

Update summary

1. The Flight Executive is the main process.
2. The Flight Executive has stages:
   1. Startup on Power-On.
   2. Pre-flight check & acceptance tests.
   3. Mission & monitoring.
   4. Post-flight operations.
3. The Acceptance Rules are:
   1. Part of the telemetry rules.
   2. Applied in Startup on Power-On and Pre-flight Check & Acceptance Tests.
   3. Applied in stages:
      1. Critical zone: power only.
      2. Acceptance zone: pre-flight check.
      3. Mission alerts: monitoring of mission logs and reporting critical alerts to ground.

[ivogeorg]

@PaulAJanes This should give some more context of what you are doing...

The Flight Executive (FE) is:

1. The top process in the https://github.com/MSUSAT/balloonsat directory, with telemetry, camera, and rockblock being packages it imports. The structure should be like this (with any other necessary sub-packages):

   balloonsat/
   |--executive.py
   |--telemetry/
     |---__init__.py
     |---telemetry.py
   |--camera/
     |---__init__.py
     |---camera.py
   |--rockblock/
     |---__init__.py
     |---rockblock.py

2. Is a state machine. State machines are much easier to write and maintain than non-systematic code. The FE states are the 4 main stages mentioned before, along with any other identifiable states that are important to segregate. The states are an enum class. This is a tentative list of the states: POWER_ON, STARTUP, PREFLIGHT_CHECK, MISSION, POSTFLIGHT. The transitions between states are strictly identifiable functions.

[ivogeorg]

Major FS design points:

1. The FE and the 3 apps are processes, to potentially each run on a separate core.
2. Each of them may be multi-threaded, if necessary.
3. They communicate with message queues, callbacks, and/or a pub-sub bus. Which one is best for cross-core comms?

[ivogeorg]

FE cannot fail

1. The FE cannot fail. This means that it should:
   1. Be minimally complex in its core.
   2. Hand off more complex behavior to threads or sub-processes.
   3. Should have a catch-all for exceptions with a simple recovery strategy.
   4. Should not be involved in functionality that can result it deadlock or blocking.
   5. Should communicate with other processes in a non-committal manner, preferably pub-sub (MavLINK Github, also in ROS).
   6. Should not write to the filesystem.
2. Should it be a deamon process? (Related, from the Python Cookbook: Forking a daemon process on Unix, Google search results)

[ivogeorg]

FE command control

There should be a way to start and stop the FE without Ctrl+c. This is potentially just as damaging as hard shutdown of the RPi (from the perspective of the fexecutive.py process, it's the same thing).

Potential solutions:

1. (easy) For short-term testing of the fexecutive.py code, there can be a time interval argument for the flight loop to stop when the time since the start has elapsed.
2. (a bit more involved) This can be extended to shutting down after some interval after landing.
3. (difficult) Full-on daemon server.