System Manager exists as the top level for ZPSW. It is the only manager that is aware of the state of the system, and has the power to start, stop, suspend, and otherwise handle other managers such as telemetry, path manager, attitude manager, etc.

System manager also has the ability to completely override all controls and choose to passthrough control direct by RC, or direct from an external Ardupilot device.

System manager has 5 states described in the flowchart below:

Boot

In this stage, all sensors, communications, etc, should be powered on, initialized, and if necessary, calibrated. It is OK in this state to ask for user input to calibrate devices? (i.e. magnetometer).

On boot, we should also load the configuration file for ZP & LOS, start background threads like SensorFusion, Telemetry, and verify that communications from to and from devices is good and exists (this can be busy waiting - this can be done after everything else is ready).

Once all systems are OK, System Manager can transition into a disarmed state.

Disarmed

When disarmed, the drone will send smaller telemetry packets at a lower frequency to prevent overheating. It can continue to acquire sensor information and should be prepared to be armed.

The drone needs hardware arm (button), controller arm (switch on controller), and software arm (GUI OK Button).

Ground Ops

In ground ops mode, the drone is fully armed & ready to transition into flight, but can be busy waiting for the takeoff command.

We should support future expansion to include sub-vehicle operations in ground-ops mode (i.e. driving around or smth). System Manager will decide how to interpret the inputs and amp them to special ground operations modes in the future.

Flight

The flight mode has 3 stages: takeoff, cruise, landing. They must be sequential and they all can lead to operator override or fatal failure modes. In each mode, System Manager will decide how to mix the inputs, and whether to make calls to path manager, attitude manager, jetson, or ardupilot. Typically, in each flight mode:

• decode controller inputs (map them to attitude manager struct) & extra bits

• Decide waypoint_type sent to PM.

Takeoff

Call PM to get takeoff targets

Report AM info to TM

Cruise

If instruction is autopilot, call PM which sends to AM, report to TM

if instruction is GPS/Level User Control, Call PM which sends to AM, report to TM

if instruction is direct passby user control, encode struct and send to PM to pass through to AM.

If instruction is override, enter override mode in SM. Report to Tm.

When last waypoint reached, confirm with GS and then go to landing

Landing

When cruise done, call Jetsosn for information on what to do next. Follow instructions.

When tx2 says we can land, enter landing procedure and then go into ground ops when landed

Fatal Failure

There should be no exit from fatal failure mode. turn off all outputs and fall from the sky. Parachute may be deployed. Do not attempt to recover from this state. Save logging data and pray?