ZeroPilot 3.0 Architecture
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: https://uwarg-docs.atlassian.net/wiki/spaces/ZP/pages/2116714497
[AM] Attitude Manager: https://uwarg-docs.atlassian.net/wiki/spaces/ZP/pages/2115830000
[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:
Get controller inputs
Disarm if necessary
Decode/translate controller inputs (depending on user selection & drone configuration).
Pass controller inputs to desired targets (PM/AM)
If PM: wait for data, then pass to AM
if AM: send telemetry data to TM
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