Attitude Management

 Problem Statement

In order to fly most drones, some form of closed loop control is required to manage the attitude of the aircraft. Attitude manager will, as the name suggests, manage the attitude of the aircraft for the given flight mode (behaviour based on pilot inputs) and frame type

 Scope

 Timeline

See asana

 Milestones and deadlines

Requirements Breakdown

FW2

• Take input controls

  • Receive channel inputs, corresponding to yaw, pitch, roll

    • float percentage values

    • Receive from SM

•  

• Pass instructions to motor

  • Send percentage value (speed, or angle) for each motor

    • AM call’s drivers directly

  • Dshot Driver

  • PWM driver

Task Brainstorming:

Talk to SM team (Gagan) about how we are getting RC inputs and its format

Actually implementing receiving the inputs (i.e. function parameters)

Converting RC channel input from SM into motor output values

Implement calls to the motor drivers using the converted values

Interface with motor drivers, make sure it works as expected (e.g. input format)

Have configuration of which motor is which (servos vs bldcs) in the models folder

Nice to have: Set up AM thread (as opposed to simple function call)

FW3

• Control pitch and roll with a PID algorithm

  • Implement PID controller (for each axis)

    • Calculate error between setpoint and current state

    • Implement loop to apply P, I, & D calculations

    • Each output value (roll, pitch) maps to motors in the same way as in previous milestone

  • Configurable gains (PID terms)

    • Can be modified during runtime

  • Configurable max roll & pitch angle

  • Defining and running the controller at a specified frequency

• Get pitch and roll from SF in a thread safe manner.

  • Talk to people, make sure input format is as we expect

  • Get this in the appropriate format to use for the PID current state

• Convert roll and pitch input to desired state

  • Should be constrained according to max angle configurations

• Create a thread for AM

  • Run the thread at a fixed frequency (e.g. 200Hz)

• Update SM inputs to be thread safe

• Consider publisher-subscriber model and implement if appropriate

Q1

FW4

Q2

FW5

Q3

FW6

Q4

Architecture

AM Structure

Attitude manager will exist as a standalone class. This class acts as the interface for other parts of the system to control the drone, and will contain the code for the control algorithms that are used for different flight modes.

Open

In order to support multiple flight modes (control algorithms), a interface class of type ControlAlgorithm is used. Implementing every control algorithm using this interface class as a parent allows attitude manager to run any control algorithm for any aircraft without concern for the actual processing that is required for each.

The output of all control algorithms (control signals to various motors on the aircraft) will also be handled by attitude manager, which will be responsible for mapping the control signals to the correct peripherals. This will be configurable depending on the aircraft model that is being flown. Each control algorithm may also have custom configuration information depending on the aircraft it flies on.

Configuration File

The design of this configuration file is highly dependent on the design of system manager, but in general the following goals should be sought:

• Minimize safety and avoid misconfiguration. Use whatever tools are feasible to ensure that the software cannot be incorrectly configured.

• The configuration options should be easily understood by someone who does not know the code well, and should be easily extensible.

The specific things that need to be immediately supported in the configuration file that relate to attitude manager include:

• What motors are connected to what peripherals

• How many motors are connected that will perform a specific action

• The tunings (e.g. PIDs) for each control algorithm

• The control algorithms that the aircraft supports

• control limits (e.g. max roll angle)

AM Input

Inputs to the attitude manager that are used to control the drone will follow the standard inputs that a controller would provide to a drone normally. These are usually labeled Aileron, Elevator, Throttle, Rudder or Roll, Pitch, Throttle, Yaw and each corresponds with an axis of the controller joysticks.

Open

In order to facilitate communication, a thread safe interface for passing these values to attitude manager needs be created, and will follow the design standard that telemetry manager sets.

To simplify the design of attitude manager, all commands to the aircraft will use this same 4 channel input format. If other subsystems (such as path manager) need to send inputs to attitude manager, they should do so through the telemetry manager interface. In this case, the desired flight mode must be considered (and communicated to system manager & attitude manager as appropriate) when passing inputs to the aircraft because the different flight modes will interpret the 4 channels of input slightly differently.