Open

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:

Open

Note that takeoff/cruise/landing is not a nested state machine but actually sequential stages in the flight mode.

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 (in slow mode).

System Manager will immediately 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. It also will verify that communications from to and from devices is good and exists.

The drone needs hardware arm (button), controller arm (switch on controller), and software arm (GUI OK Button). It will require the hardware and one other arm button to transition to ground Ops.

AM thread is started here so that it can accept PID tuning changes ONLY in Disarm mode.

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 which sends to 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.

• Read back any responses from AM

• Pack and send packet to TM

Enter:

When flight mode is entered the PM thread is started and the TM thread is restarted at higher speed.

Exit:

When flight mode is exited the PM thread is killed and SM sends a 0 command to the LOS Actuators

Takeoff

Call PM to get takeoff targets, PM sends waypoints one at a time to AM.

Cruise

If instruction is autopilot, call PM which checks readPmTargets is true and sends to AM, report to TM

if instruction is GPS/Level User Control, set the readPmTargets global flag to False so PM stops sending to AM and AM stops listening to PM. SM sends direct controls to AM.

When sent a landing command either from controller or CV pass that to PM to manage landing and send to AM unless currently receiving RC teleop controls.

Landing

When cruise done, Jetson sends landing instruction. Follow instructions.

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

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?

Enter:

When flight mode is exited the AM and PM threads are killed and SM sends a 0 command to the LOS Actuators. Leave Telemetry manager running and try to log everything possible before we hit the ground.

Exit:

THERE IS NO EXIT