...
| Expand | ||
|---|---|---|
| ||
|
List of Abbreviations & Links
| Expand | |||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||
|
...
[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.
...
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
...
| Code Block | ||
|---|---|---|
| ||
typedef struct CommandsForAM_t{
WaypointType waypoint_type; // not necessary
// heading unit vector and magnitude
float heading_dist_x;
float heading_dist_y;
float heading_dist_z;
float heading_magnitude; // Magnitude distance to waypoint target
float heading; // heading at target waypoint
double velocityspeed_target; // Target velocity of drone approaching target
} CommandsForAM; |
...
The velocity target is the desired speed for the drone to approach the waypoint (For use notably in takeoff and landing)
AM ↔︎ TM
PM ↔︎ TM
TM ↔︎ CV
...
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