Path Manager

TODO: As of now, we’ve agreed that the state machine contains modes. Modes represent what phase of flight we’re in (takeoff, cruise, land, taxii). Within each mode, we’ve got stages. Stages represent what subphase of the mode we’re in (for ex, taxi mode contains the orient, roll out… stages). And finally, at the lowest level, we’ve got states, which are just the individual elements who’s order of execution makes up a stage of a mode.

Note that often times, a stage will be named after a state of importance. For instance, even though the orient state is just one of many states that make up he orient mode, it is the state that defines that mode (whereas something like sensor fusion is really generic), so the stage is named after it.

Overview

From a high level perspective, Path manager takes care of figuring out how to take the aircraft from point A to point B. It decides how the aircraft should be oriented (requested roll, pitch, and rudder position*) and at what speed it needs to be at to get where it needs to go (requested airspeed). Those instructions are communicated to Attitude manager to be carried out.

When we talk about “Path manager”, we are talking about the path manager state machine, all the sensor modules that belong to path manager (gps and altimeter), all the data processing modules that belong to Path manager (Sensor fusion, Waypoint manager, Coordinated turns and elevation), and the 2 communication modules that belong to path manager (1 to speak to Attitude manager, the other to speak to Telemetry manager).

This page details the design of the state machine, which is the “highest level element” of Path Manager. The children pages detail the designs of all its modules.

State machine design

The Path manager state machine will be implemented in a thread of its own. A full cycle of this state machine needs to be executed at some constant frequency. The states as well as the flow between them is depicted in the drawing below. Each state corresponds to exactly 1 module action. The state machine itself only transfers data between modules. It may also repackage data to facilitate communication between modules, but it never processes or modifies and data, that is the exclusive job of the modules. The figure below depicts the states as well as the flow between them.

Open

Further, the breakdown of the signals received and sent out by each state is depicted in the figure below. Modules are completely isolated from each other. None “knows about” any others. Each one only receives data from the state machine, acts on it as needed, and returns any data it needs to return back to the state machine. This level of modularity is done in an effort to make each module as easy to understand as possible, as easy to unit test as possible and makes the process of debugging easier as well.

Open

*You might be wondering why this isn’t roll, pitch and yaw. Reason here is that yaw is not something we can only control with rudder. Changing the yaw (heading) of the airplane requires a certain bank angle as well (See the coordinated turns module).