Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

\uD83E\uDD14 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

Must have:

  • Control the aircraft such that aircraft response matches pilot inputs

  • Accept pilot & machine inputs

  • Be useful on multiple aircraft

  • Ability to switch the behaviour of the aircraft

Nice to have:

Not in scope:

  • Calculate aircraft state in space

  • Automous functionality requiring coordination over “long” periods of time

\uD83D\uDDD3 Timeline

See asana

\uD83D\uDEA9 Milestones and deadlines

Milestone

Deadline

Required Elements

FW2 - Manual Fixed Wing

  • Attitude manager takes input controls and passes them through to motors

FW3 - Fixed Wing Fly by Wire A

  • Control algorithm to target pitch/roll angles

  • Data collection from sensorfusion

  • Control algorithm configurations (e.g. PID gains)

  • Configurable values for min/max pitch/roll angles

Q1 - Quad Acro

  • Control algorithm to control rate of rotation on each axis + throttle

  • Configurable frame type (e.g. quad vs fixed wing)

FW4 - Fixed Wing Fly by Wire B

  • Rate of climb/decent maps pitch input

  • Airspeed maps to throttle input

  • Configurable max climb rate & max/min airspeed

Q2 - Quad Stabilize

  • Control algorithm to map stick inputs to (pitch/roll) angles of the aircraft

FW5 - Fixed Wing Cruise

  • Control algorithm to compensate for disturbances and maintain ground track

Q3 - Quad Altitude Hold

  • Control algorithm combining stabilize mode with rate of climb/decent

FW6 - Fixed Wing Auto Takeoff

  • Cruise mode + Path manager coordination

  • Flight mode switching

Q4 - Quad Loiter

  • Control algorithm to hold position with stick inputs mapping to speed

🔧 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)

Nice to have (If we finish early): Make sure this is done in a thread-safe manner

Converting RC channel input from SM into motor output values

Map each input channel to the appropriate output values

Determine correct direction, which motors are relevant

Implement calls to the motor drivers using the converted values

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

Talk to the people assigned to the drivers

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

And what type of control they are (e.g. rudder, throttle)

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 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 input.

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.

  • No labels