Background
I’m working on itHalf of this is out of date
Reasoning Behind Restructuring
We are once again restructuring path manager! The current goal is to restructure PM so that it focuses more on path management while AM will take care of movement such as calculating roll, pitch, yaw, and adjusting throttle.
State Machine Changes
Some state names have been renamed to better reflect what is happening within the state. resetVariables
has been renamed to FlightStageSelectorMode
where PM will figure out what stage of flight needs to be executed.
The coordinateTurnElevation
state has been removed as it previously calculated roll, pitch, yaw, etc which has been passed onto AM. Now, the desired heading is calculated in one of the flight modes and is passed to AM to make movement calculations.
Main Structure of PM
A diagram of the general flow of Path Manager, including its modes, stages, and states can be found below.
...
PM will check if the drone is under manual control by receiving a WaypointType
. If it is not under manual control, it will enter FlightStageSelectorMode
, the main part of the state machine. Within this mode, PM will change flight states if triggered to do so. While flying, PM may enter any of the following flight states: Disarmed
, Takeoff
, Cruising
, Landing
, and Landed
. Note: a Preflight
state may be added. If we are in the Disarmed
state or Landed
state PM will go back to the start. However, if we are in Takeoff
, Cruising
, or Landing
, PM will execute their respective stages.
...
Important Structs
Note: All messages to Path Manager will be coming from System Manager in a single packet:
SM → PM
Code Block |
---|
typedef struct CommandsFromSM{ WaypointType waypoint_type; { CommandsFromTM telemetry_commands; JetsonToZpMovementCommand jetson_commands; LandingInitiationCommand landing_initiation; LosSFData sf_data; } CommandsFromSM; |
where WaypointType is defined as
Code Block |
---|
enum WaypointType {PATH_FOLLOW = 0, ORBIT_FOLLOW, HOVER_WAYPOINT, TAKEOFF_WAYPOINT, LANDING_WAYPOINT, TRANSITION_WAYPOINT, MANUAL_WAYPOINT, FATAL_FAILURE}; |
and CV will be sending a list of waypoints during Cruise and Search (sent through TM and SM) where a single waypoint is defined in the TelemWaypointData
struct below. The start_landing
flag will be signaled when a landing pad is found. NOTE: RC Stuff has not been added yet in SM → PM struct
CV/TM → PM During Cruising
Code Block |
---|
struct TelemWaypointData { double longitude; // double lattiude; uint8_t waypoint_id; }; typedef struct CommandsFromTM{ uint8_t num_waypoints; // number of waypoints in the list TelemWaypointData waypoints[num_waypoints]; } CommandsFromTM; |
CV/TM → PM During Search For Landing Pad
Code Block |
---|
// Data given from CV/TM during search and landing
struct JetsonToZpMovementCommand {
float x;
float y;
float z;
float heading;
};
struct LandingInitiationCommand {
bool start_landing;
}; |
PM → AM Struct:
Code Block |
---|
typedef struct CommandsForAM_t{ 2 WaypointTypefloat waypointdist_typeforward; // not necessary 3 4 // heading unit vector and magnitude 5 pitch float dist_xright; 6 float dist_y;// roll 7 float dist_zup; //yaw 8 float magnitude; // Magnitude distance to waypoint target 9 float heading; // heading at target waypoint 10 double speedvelocity_target; // Target velocity of drone approaching target 11} CommandsForAM; |
...