Specification & Modules

- Attitude Manager Re-Architecture

The new system architecture requires controls to be run solely on Safety, which requires some significant changes to the Attitude Manager state machine.

Major Changes to Architecture

• AM will be on Safety now instead of Autopilot

• Sensorfusion will run without any GPS presence

• PM instructions will be taken over interchip rather than FreeRTOS MailQs

• PWM Outputs won’t be sent over Interchip anymore since the actuator controls and Attitude Manager are all on the same chip

New states for Attitude Manager are based on the requirements above. The new states are described below:

1. FetchInstructionsMode - Based on whether the drone is in teleop or autonomous mode, movement instructions are received from PM or the RC Transmitter respectively

2. SensorFusion - Takes input from the IMU and conducts various computations such as low-pass filters , localization, etc. to allow for more robust feedback for PID/Controls

3. Controls Module - Takes instructions from FetchInstructionsMode and the result of sensorfusion, passes into a controls module which conducts PID control and outputs the respective motor percentages

4. OutputMixing - Organize the raw output data (motor percentages) into various arrays for channels, to be sent out to the motors.

5. FAILSAFE MODE - If comms with PM and RC transmitter are dead, then the drone should go into fail-safe mode where all motor power is dead and the drone effectively falls out of the sky. Unfortunate but avoidable.

6. State machine returns to the FetchInstructions mode.

Controls Module

• Takes in current state data && desired position and flies in that direction

Input data:

• Position data from PM (Autonomous) or RC Transmitter (Teleop)

• Position data from IMU (already filtered?)- will be filtered through SensorFusion

• Desired position to be in (as a vector from current position, encoded with yaw angle)

Output:

• motor % → to be converted to PWM signals.

Sensorfusion Module

• Most of the work as the same as done by Tony, but we need to run local sensorfusion for fastest IMU updates.

(ground-side) Simulation

• hopefully have some simulation done in matlab or smth?

Targets & Questions

• Target 1: Stable flight in all directions

• Target 2: Fancy flight in all directions

• How are we localizing - how does PM know to tell us which way to go!?

  • do we operate under one local heading as 0 and PM handles the rest of the spinny localization?

  • local or global reference frame? → not high priority (but I think local is easier?)

    • matters for directional flight (left/right/up/down), but we dont really care about the ORIENTATION of the robot

      • see VRC 5225A global positioning system premilinary doc from 5225a, 5225a code release

• Other Considerations:

  • How to handle pre-flight sensor calibration (is it triggered by user for tele-op or occurs automatically before flying?)

  • How to handle catastrophic failure - if the entire controller system fails to work, would we shut off all motors and let it fall? Or is there a defualt motor PWM value that can allow the drone to fall softly without damaging itself?

Timeline

• development start by reading week.

• Wednesday reading week → discuss how to approach this in terms of implementation

• Manual controls with RAW PWM values can be done by E.O. reading week.

• Implementing fancier methods later

Project Tasks

•  Implement MANUAL PWM based controls for quadcopter.
•  Sensorfusion for IMU data.
•  Determine Controls architecture for remote control control
•  Stability Simulation
•  Stability Code????
•  to be expanded

Meetings

October 13, 2021 Anthony B

Q1: Input Controls

• Before they went through PID Controller

• Usually done (and attempted for ZP)

  • sticks map directly to angles.

  • Pilot commands setpoint and angle.

• what if the value is too much?

  • payload of drone doesn't actually matter, it doesn't matter?

  • objects in the air rotate around their center of gravity, no matter what they weight and what their weight distribution is.

q1a: is one set of PID enough?

• if you take care to adjust, you'll get better results.

q1b: trim from both sides?

• for sake of symmetry, trim from both sides

  • if only increasing one side, you'll have more total thrust and drone will actually go up.

q1c: how is yaw controlled?

• rate of turn -> see dji.

q1d: set hard limits?

• Recommended to set hard limits.

  • if the drone is past some angle, it declares an emergency and goes into failed state.

  • once you are past 90 degrees, all the angles fail

    • gimbal lock !!

Q2: what happens when motors fail?

• In the worst case scenario, we turn off all motors and just fall out of the sky.

• Code has to have option to shut everything down.

Q3: Independent PID?

• Works fine.
  -> simple pid will get you in the air and get you stable

• once you start combining euler angles, then they start to behave non-linearly.
  -> at low angles, it's fine.
  -> to get fancier, you'd need something fancier like predictive or non-linear.

• CAN GUARANTEE PID WORKS ! ! !! (yay).

Q4: Tuning in Simulation?

• Simulink model ! !

  • it's a simple model with no complicated physics.

  • modelled as weight in the air with motors as linear forces.

• Matlab has euler angle block

• Can use simulink model for ZP and make it look like a quadcopter instead of a fixed wing to start

• It'll be super simple → refer to Nixon

• He never got it super close to quad

  • it was a super rough place to start.

Q5: IMU Senor drift?

• IMU keeps drone level and pointing in right direction

• Will not keep drone at same longitute and lattitude.

  • drone will drift a bunch.

    • maybe not may be a big issue

    • Update from GPS module from PM then?

• ZP sending data?

  • PM sends a track (fly this far, how)

  • AM obliges, this is how you fly that way.

  • Send Vectors! 😃

  • PM navigator, AM captain 😃

Q5: Sensor Fusion needed?

• Tony’s sensor fusion module will work fine.

  • magnetometer never really got working.

• Need magnetometer, but IMU should have one built in.

• Share IMU data?

  • such fancy imu, why no use?

October 12, 2021

• Might be better to go through articles and guides.

• Have somebody start something soon for raw pwm values.

  • Iterate later.

• Alternatively use Tony’s Sensor Fusion and some PID values to keep heading.

  • Local reference frame updated against global frame soon.

• Center sticks should hover in place, no motion.

• MAP RC values to PID heading

  • PID → PWM values.

• Anthony B

  • how do stick inputs translated into direction (radius, %, rate?)

    • Max angle determined by how the drone can fly stably.

    • Full stick = go that way as fast as you can.

      • PID auto-tunes to go as fast as you can without dropping altitude as you go.

  • how did he setup his pid if he used any?

  • Did he use matlab/simulink?

• How does stabilization work.

  • PID sets to 0 and just keeps it there.

• MAX PWM set after testing (with PID values).

• Attempt testing for PID’s in waterloo.

October 7, 2021

• Send E-mail to Stephen Smith Friday Oct 8th 2021 → end of day. (or early saturday).

  • come up with some ideas to send to him about controls

  • hopefully get guidance wrt our specific requirements → help us choose methods?!

• Sending info to the drone as a spline (especially for autonomous flight)

  • → see FRC 254 controls giving splines and not raw values (link to 254 presentation)

    • link to slideshow

  • can fall back to raw pwm % difference if necessary

• Focus on two aspects

  • teleop and autonomous. → both get pretty ok with vectors.

  • for autonomous → pm should give us a vector.

  • for tele-op, depending on how we handle it, calculate internally or in PM - also consider that PM is on Autopilot while Teleop and RC input will be on safety (prob best to keep teleop localized completely on safety)

• PM → tell you where to go | AM → figure out how to get there without crashing

• Definitely can get manual control done by end of reading week with raw pwm values.

  • fancier flight will have to come later.

October 5, 2021:

• Start development by the end of reading week.

• Meet next Thursday 7:30.

  • Come with ideas. Be prepared to prepare documents.

  • Questions and critical areas to ask the experts.

• Reach out on friday.

• Take weekend to look over data

• Try to meet next tuesday.

• Aim for reading week start

• Try to make applicable for hexa/quadcopter (depending on what’s chosen). Worry about layout agnostic controls later

Questions to Ask Anthony B:

• How do the RC inputs get mapped/converted into PWM - rate of change, set angle, etc.

  • Is there a max angle you set, or is it through PID tuning only?

  • How does the stabilization work (centering sticks sets quad in 0 roll and pitch angle)

• How to stabilize the drone while you’re increasing/decreasing thrust

• How did he set up his PID for the tuning

• If he used MATLAB or Simulink for the tuning and how he used it, any resources, etc.

• Specific switch/sequence for calibration to calibrate IMU at the beginning of each flight.