Quadcopter PID: Feedback please (pun intended) - Page 1
Forum section: electronics / projects

author: BurnedResistor
author_rank: Regular Contributor
timestamp: November 27, 2016, 06:04:53 pm
content: Dear All,I am looking to design a quadcopter controller and have been thinking a lot about how to use data from the 9dof IMU (Accelerometer, gyroscope and magentometer) to keep the quadcopter stabile and in the air.I am struggeling a bit because there are 4 motors, yet there are 4 outputs that they combine to produce:Vertical displacementForward TiltSideways TiltRotation(Note that movement is simply a function of tilt)Now If all I had to do was control tilt and movement on a single axis, this would be easy: I would setup a cascaded PID loop where the inner loop keeps the quadcopter at a desired tilt and an outer PID loop which keeps it moving or stability at the correct velocity, each of which is fed with data from the gyroscope and accelermeter respectively.This can be scaled to a system where there are 2 degrees of tilt and 2 degrees of motions: Two cascaded PID loops, where again the inner loop keep the quadcopter at a certain angle and the outer loop keeps it at a certain velocity, and then the motor is fed with half the value of one loop and half the value of the other.This is where I am not quite sure what I am doing is correct: Is there a better way of doing this, instead of just taking half the value from one loop and half the value from another?This continues as more complexity is added, for example vertical motion: The quadcopter is flat, yet there is still movement....Any ideas?Am I approaching this incorrectly?Thanks for your ideas!

author: Rerouter
author_rank: Super Contributor
timestamp: November 27, 2016, 07:48:48 pm
content: You end up having a cascade, first layer is motor speed for each rotorNext up is your degrees of freedom, which is 4 to my understanding, (roll, pitch, yaw, vertical translation) your imu will likely give you your error terms, so your left with 4 Top level pids than sum and cascade the 4 motor speed pid'sE.g. roll sums into 2 motors and subtracts from the other 2 for its degree of freedom, (left vs right), pitch is the same just for front /back), yaw is motor speed on diagonals on the ones I have seen, and vertical is summed to all motors.You sum these for each motor then let the motor speed loops deal with matching it.

author: BurnedResistor
author_rank: Regular Contributor
timestamp: November 27, 2016, 08:08:27 pm
content: Very interesting!I am using prebuilt hobby escs, so I dont have any feedback about motor speed. Would be optimal but sadly not possible!Would each of the DOF sum equally? Or is that something that needs to be tuned?So for horizontal translation, which is controlled using the pitch and roll I would have another PID layer on top of that?I sketched a quick scheme, is that about correct? I have no idea how to draw such a 'scheme' or what it is even called. Any recourses?

author: Rerouter
author_rank: Super Contributor
timestamp: November 27, 2016, 08:24:00 pm
content: That is pretty close to it, the esc's you can then treat as the speed controllers,The hard part is your 2 higher layers will need to be pid rather than simpler pi if you want it to settle and not overshoot.However I will say generally the imu is calculated as a whole rather than each sensor being treated seperatly. Your gyro will have a drift factor, and your accelerometer may not be true Center of mass.

author: BurnedResistor
author_rank: Regular Contributor
timestamp: November 27, 2016, 08:45:17 pm
content: What do you mean by the imu is calculated as one?I have heard the term sensorfusion thrown around, is this that? If so what is it?

author: timb
author_rank: Super Contributor
timestamp: November 28, 2016, 01:56:58 am
content: Quote from: BurnedResistor on November 27, 2016, 08:45:17 pmSensor Fusion basically takes data from an accelerometer, gyro and magnetometer and processes the data to provide an output in some sort of coordinate or spatial format.A few years ago it was common to have a separate chip for each of the above functions (accelerometer, gyro, magnetometer), each of which would output raw data, that you'd then process via software in your MCU or DSP.Today, you can buy chips that combine all the functions and the processing. This is typically what is referred to as Sensor Fusion. Some chips only combine the functions but still output the raw data; these are often advertised as 9-DoF or 6-DoF depending on if it includes the magnetometer or not.Sensor Fusion isn't limited to just motion processing. Bosch actually makes a chip that does temperature, humidity and pressure plus the processing. It spits the actual, processed data out over I2C, which means you don't have to implement any special code or algorithms to processing the data. You can use it as it comes out of the chip. It's pretty nice.

author: BurnedResistor
author_rank: Regular Contributor
timestamp: November 28, 2016, 06:58:17 am
content: Quote from: timb on November 28, 2016, 01:56:58 amHmm,Is it viable to implement this yourself? I have a FPU and a lot of headroom!If so, do you have any recourses on this?Thank you!

author: Rerouter
author_rank: Super Contributor
timestamp: November 28, 2016, 08:20:09 am
content: It's where you combine yours sensor values to make up for the limitations of cheap mems sensors, so accelerometer and gyroscope mainly contribute to roll / pitch, while gyro and magnetometer contribute to yaw,Gyroscopes have drift, which the accelerometer as it has a vector pointing down can help cancel out, same as the magnetometer does for yaw,

author: BurnedResistor
author_rank: Regular Contributor
timestamp: November 28, 2016, 08:58:27 am
content: Quote from: Rerouter on November 28, 2016, 08:20:09 amHmm, so after that I would be left with an absolute pitch yaw roll and movement? very interesting!Are there any specific algorithms that would work for this?I was researching and some of the terms I saw whereCentral Limit TheoremKalman filterBayesian networksDempster-ShaferWhich one would be most applicabale? What are the pros/cons for each one? Which one is easiest to implement (grin)?

author: Rerouter
author_rank: Super Contributor
timestamp: November 28, 2016, 11:07:01 am
content: All of them get pretty crazy on the math, however take a look at the GitHub repositories for some of the open source quad packages, you shoul be able to use them as a solid starting point.I think the simplest aapproach was calculate the vectors for acceleration and magnetic. Add a weight to them and then sum in the derivative of the gyro update vs last.From memory on roll pitch it was something like 0.92 for gyro and 0.08 for the accelerometer. And for yaw 0.85 for gyro and 0.15 for magnetometerI will say to work out your magnetic vector you likely will already need to use the accelerometer, so don't burn too much time trying to Mesh it's value into roll or pitch.If you want to get fancy you could subtract the acceleration of your vertical motions from the accelerometer output to prevent weird fluctuations as the vector gets pulled more vertical than the quad actually is.Same can be done with the forward acceleration if your using a velocity controller rather than just rotation and altitude holdEqually that is generally why barometers are used to help control your vertical degree of freedom. As otherwise it's relying solely on a single accelerometer axis.Yes I played with my own software before I had an impact rotate it past 90 degrees and had my sloppy coding crash it into concrete at max power. Always make sure the software will behave when things go wrong.I've taken a break from quads for now but may pick them back up at the end of the year.

author: timb
author_rank: Super Contributor
timestamp: November 29, 2016, 12:54:40 am
content: Quote from: Rerouter on November 28, 2016, 11:07:01 amOr an ultrasonic rangefinder for low altitude hold or indoor use. 3D ToF is also starting to be used in some indoor quads for verticals and horizontal stabilization.I've also seen some quads that use a bottom mounted low resolution camera to help stabilize the X and Y axis. This is done the same way as modern optical computer mice: They tale successive images of the surface below and compare them to each other; the offset between frames is the distance moved.No matter what secondary system you use, generally it's not integrated into the main PID loop.Essentially the main loop takes the processed data from your 9-DoF IMU and uses that to keep the quad in the air and respond to commands from the controller.You'd then have a slower, secondary loop that takes data from the secondary sensors (3DToF, Sonar, Camera, Barometer, etc.) and generates correction data that is then sent to the main loop. In essence, the secondary loop becomes a pseudo-controller for the main loop.That's the way a lot of commercial systems operate.I picked up a Parrot Bebop (it's basically a flying BeagleBone Black with 1080p camera; very slick bit of kit) last week and just got PaparazziUAV going on it over the weekend. Anyway, that's a project you (the OP) should check out: Dissecting their Autopilot Firmware might give you some insight into the math.