Background

In Fall 2022, the firmware team rebranded to be embedded flight software, and with that change, followed through on the proposed project LOS proposal from summer 2022.

...

We count the changes from the 2022 season as a “2.0” revision, and so we are now working on the ZP 3.0 Architecture!

General Introduction to ZPSW

ZP3-sw follows a structure loosely based off of the work done for the 2022 competition drone “Vanguard”, where more autonomy was given to Attitude Manager, and our codebase was expanded to support both fixed wing and multi rotor aircraft.

Understanding The Drone

The Drone Reference Frame

It’s important to understand the reference frame of the drone when we work between multiple modules. In our case, we have it defined as such:

+X = Forward

+Y = Right

+Z = Up

...

Understanding the Managers

There are a few main components that are independent from each other in design and code. These are:

• [PM] Path Manager: Path Manager 3.0

• [AM] Attitude Manager: Attitude Manager 3.0

• [TM] Telemetry Manager: <link>

All three of these will be managed by a FSM System Manager.

Path Manager

PM handles path generation and the vast majority of the autopilot function of the aircraft. It communicates with TM and AM using FRTOS MailQueues.

Attitude Manager

AM handles the attitude management of a quadcopter or a fixed wing aircraft, and allows either PM or a teleoperator to control the drone. It communicates with TM and PM, as well as with the user through LOS_Link.

Telemetry Manager

TM will read data from both AM and PM, and produce an output struct that can be sent to ground and CV. This will be done using <insert method>.
TM will also receive data from CV & Groundside, and prepare this for PM & AM.

System Manager

A lot of the work that was in the pre-2022 AM has now been moved to the system manager. This allows a centralized unit for handling the state of the system, including inputs/outputs, managing the individual managers, and generally deciding what to do next. This alleviates Attitude Manager

...

of the tight integration requirement, and allows the three managers above to do what they need to do independently of each other.

The five states

System Manager has 5 states that it can be in:

...

Boot, Disarm, Ground Ops, Flight, Failure

Boot: Allows for boot sequences, runtime configurations & initializations, etc etc.

Disarm: Motors cannot turn on, drone is in a low power state waiting for commands

Ground Ops: Drone is armed, but is not able to takeoff (i.e. restricted to idling on ground or operating UGVs)

Flight: Drone is fully armed, and can do anything it wants basically.

Failure: Drone is unhappy and needs to go home and take a nap.

The Flight Time event loop

System manager gets to make the decision between what threads to run, what not to run, and what to run at anypoint. During flight, the event loop for the flight mode looks something like this:

1. Get controller inputs

2. Disarm if necessary

3. Decode/translate controller inputs (depending on user selection & drone configuration).

4. Pass controller inputs to desired targets (PM/AM)

5. If PM: wait for data, then pass to AM

6. if AM: send telemetry data to TM

7. repeat 1-6 until exiting flight mode.

Controller Mapping

Different pilots and different UAV’s require different controller configurations. System Manager provides a controller decode block that allows any input from LOS_Link to be decoded and then re-encoded as the common struct to AM, or as a waypoint to be given to PM.

Common Interface Structs & Methods

System Manager→ AM

typedef struct CommandsForAM_t{
  WaypointType waypoint_type;  // not necessary

  // heading unit vector and magnitude
  float dist_x; 
  float dist_y; 
  float dist_z; 
  float magnitude; // Magnitude distance to waypoint target
  float heading; // heading at target waypoint
  double speed_target; // Target velocity of drone approaching target
} CommandsForAM;

The heading distances form a unit vector with the combined magnitude such that:

The vector in XYZ space has a magnitude of 1.

The heading magnitude is the distance to the target waypoint. (For use in times such as coordinated turns, etc.)

The velocity target is the desired speed for the drone to approach the waypoint (For use notably in takeoff and landing)

Attitude Manager → System Manager

AM may return:

• Successfully got data

• Successfully executing data

• Error executing data

• Any failure mode

• user control requested

• disarm/arm

System Manager → Path Manager

• Requests for waypoints

• controller inputs in gps/level mode

Path Manager → System Manager

• struct for AM, success codes.

System Manager ↔︎ Telemetry Manager

• all the data