Hello everyone! I have a math and physics problem that I could use some help with. I am currently working on a simulation of a Quadrotor helicopter using VPython and PyODE. The simulation consists of four motors connected at the ends of a plus sign. I can make the quadrotor rise into the air by increasing the speed of the motor rotations. The force generated by each motor is determined by the speed of the motor multiplied by a "motor constant".

The problem is that the quadrotor can become unstable. I need to maintain a level flying platform... The inputs to the system consist of four motor speeds and when the force generated by all four motors is greater then the downward gravitational force then we achieve flight. I can get a rotational matrix from ODE and VPython gives me the up axis..

I have investigated using PID control but I am unsure as to how to tune the various parameters and what to do with the output that such a routine would give. I tried a routine myself that consisted of simply comparing the Y coordinates and adjusting the motor speeds that way but this proved too unstable (Yes I know that technically this method was cheating as I used more knowledge of the system then I have given here...).

Screenshot of my system:




Any thoughts? I have had some thoughts involving taking the up axis of the main "body" of the quadrotor and taking a dot product with the desired up vector... and then what to do from there is sort of eluding me...

Here is a PID control pseduocode I adapted from wikipedia articles to prove that I am clueless:


Ku = 1
Tu = 2

Kp = 0.33*Ku
Ki = (2*Kp) / Tu
Kd = (Kp*Tu) / 3

previous_error = target - actual
integral = 0

start:
error = target - actual
integral += error * dt
derivative = (error - previous_error) /dt
output = (Kp * error) + (Ki * integral) + (Kd * derivative)
previous_error = error


*Implements PID in Ideal Parallel Form from : http://en.wikipedia..../PID_controller

*Also implements the Ziegler–Nichols method for tuning: http://en.wikipedia....3Nichols_method using overshoot parameters.

P.S. : The entire code is open source and under a GNU GPL v3 license ... I am still actively developing the code... so it probably looks terrible (sorry about that!) but hopefully it will help others! here is a link: quadrotor simulation source

This magazine article (from the IEEE Control Systems magazine) looks very promising. Also check the references cited in it;* at the very least, they're all by big names.

* About academic papers... A lot of them are ostensibly locked up behind paywalls but are nevertheless mirrored by the authors on their personal websites (technically this violates copyright law, but it's very common). CiteseerX and Google Scholar sometimes also have or can find PDFs.

....

Some more thoughts, at the risk of reinventing the wheel... You have four controls, corresponding to the four rotors. You can represent your input vector as a sum of basis vectors (drawn as matrices with each element corresponding to a rotor),


Pitch Forward/Back
-1 -1
+1 +1



Pitch Left/Right
-1 +1
-1 +1



Thrust Up/Down
+1 +1
+1 +1



Yaw Left/Right
+1 -1
-1 +1
.

This gives you 3 DOF control over angular acceleration (two pitch and one yaw input), and one over linear acceleration (the "Up/Down" input). Forgetting the latter... You can do a nonlinear "PD" controller to stabilize orientation, where the "P" and "D" now need to be understood in a way that makes sense for a curved manifold: The 'P' part would be the cross product of the craft's up vector with the global up vector, thought of as an angular acceleration, and the 'D' part would just be its current angular velocity; these are both just elements of so(3)...

A friend of mine has built several of these things and I helped him with the design of the stability control. The hardest part is the integration of the data from the sensors (accelerometers and gyroscopes, at the very least) to figure out your current position, speed, attitude and angular velocity. Presumably in your simulation you can just read those things instead of measuring them. What's left is a relatively simple control problem, for which PID controllers work pretty well.

First of all, you have four numbers to send to the motors (the speed of each motor), but it's easier to work with a different set of four numbers:
* Thrust
* Roll
* Pitch
* Yaw

Front_motor_speed = Thrust + Pitch + Yaw
Left_motor_speed = Thrust + Roll - Yaw
Right_motor_speed = Thrust - Roll - Yaw
Back_motor_speed = Thrust - Pitch + Yaw

Thrust is controlled by a PID controller that looks at the difference between current altitude and the desired altitude. Roll is controlled by a PID controller that looks at the departure from a desired roll angle. Pitch and yaw are analogous to roll.

To tune the parameters, my friend started by tying two opposite arms of the quadcopter to the top of two chairs, so the quadcopter could only roll. Then he played around with the PID controller that took care of achieving the desired roll. Pitch is completely analogous. Once those two were working, it was already possible to fly the quadcopter by hand (two of the inputs from the remote are interpreted as the target roll and pitch, and thrust and yaw are read directly from the remote). He then made a PID controller for yaw (using a magnetometer as a compass), and he eventually built one for altitude as well (using an ultrasonic range finder).

Even after all that, the quadcopter would still drift sideways. The fix for this is coolest part of his machine: an optical mouse with a different lens (to focus at infinity, not at a couple of mm from the sensor) is used to detect drift (you see the floor moving).

The current state of the project can be seen in this video.


[EDIT: s/gain/thrust/g]

Thank you Emergent and alvaro, I will take some time tomorrow to digest both of your posts in detail! I have provided reputation to both of you for taking the time to provide some advice on this problem.

@alvaro: Very cool; I've wanted to build a controller for one for a while...

You might be interested in this:

The solution that you developed with your friend sounds very similar to what the people over at Parrot also did with their AR.Drone; it uses a downward-facing camera, presumably with something like optical flow, to determine sideways motion, together with IMUs for attitude control and ultrasonic sensors for altitude. They're only $200 each (amazing, right?), with control over 802.11. Out-of-the-box, they act as APs, and the idea is that you'll connect to them with a smartphone which acts as a remote --- but, it turns out not to be so difficult to flash them to work in managed mode, in which case they just connect to a wireless router. This makes coordinating several of them easier, and also opens up possibilities like using WiFi extenders (like e.g. on a college/corporate campus) to extend range over a large area.

I just love that they're $200/ea and speak 802.11. :-)
(So, if you're in the market for some cheap quadrotors...)

The only possible downside (upside?) is that the low-level control is all taken care of; you're just feeding it references. This has been fine for our purposes, but would seriously get in the way of doing aggressive flight maneuvers (like Vijay Kumar is doing over at the GRASP Lab), and we haven't looked into getting low-level control of the motors.

Oh, yes. We got my boss one of those Parrots for Christmas. It was very smooth, but it didn't last very long. I think my friend's design is sturdier: It has crashed many times and most of the time you just need to at most replace a propeller. And it has a certain back-to-the-future look that is way cooler.

Oh, yes. We got my boss one of those Parrots for Christmas. It was very smooth, but it didn't last very long. I think my friend's design is sturdier: It has crashed many times and most of the time you just need to at most replace a propeller. And it has a certain back-to-the-future look that is way cooler.

Yeah, we're flying the AR.Drones indoors; I'm pretty sure they'd start falling apart if we took them outside....

Some suggestions:

1. Don't over complicate this, linear control is good enough for your application and what Emergent is talking about(GRASP lab was literally tenure worthy 20 years ago. Linear quadratic regulators (LQR) still dominate most aerospace applications and are purely linear controllers. Nonlinear controllers are amazing but a lot rely that you have a general idea of what the dynamics are going to look like or are very hard to understand unless you are researching them in academia.
2. Create nested PID control, you first want to be able to command rates. After this create a PID controller for the attitudes that will send inputs to your rate controllers. Trust me, it makes your life much easier and rate command is something you'll need anyways.
3. Dont forget about integration windup, have your older data decay off or else you will have drifting issues.
4. Differentiating a signal is a bad idea most of the time. If there is noise in the sensor (and accelerometers are notorious for this) it will make it much worse. Try avoiding this by feeding pitch rates into the pitch attitude controller etc...

Just a preview of what is done in my lab:

Keep me posted on your progress! It's very interesting to see what people are doing with these quadrotors.

Some suggestions:

1. Don't over complicate this, linear control is good enough for your application and what Emergent is talking about(GRASP lab was literally tenure worthy 20 years ago. Linear quadratic regulators (LQR) still dominate most aerospace applications and are purely linear controllers. Nonlinear controllers are amazing but a lot rely that you have a general idea of what the dynamics are going to look like or are very hard to understand unless you are researching them in academia.
2. Create nested PID control, you first want to be able to command rates. After this create a PID controller for the attitudes that will send inputs to your rate controllers. Trust me, it makes your life much easier and rate command is something you'll need anyways.
3. Dont forget about integration windup, have your older data decay off or else you will have drifting issues.
4. Differentiating a signal is a bad idea most of the time. If there is noise in the sensor (and accelerometers are notorious for this) it will make it much worse. Try avoiding this by feeding pitch rates into the pitch attitude controller etc...

Just a preview of what is done in my lab:
http://www.youtube.c...h?v=-vBhgF5rEIg

Keep me posted on your progress! It's very interesting to see what people are doing with these quadrotors.

Very nice advice! I think I have some really nice ideas now. I am holding off posting my current solution until I achieve the stability I would like, but I am actively implementing this advice into my code!