0
$\begingroup$

I'm developing my fligth controller board on Tiva Launchpad for quadcoper and while calibrating PID I discovered an unexpected behaviour: sometimes quadcopter seems to experience random angle errors. While trying to investigate it, I've figured out that my code if fairly trying to compensate tham, as soon as they appear - but do not cause them. Even more - i've discovered that such behaviour appears only when two (or more) motors are adjusted, while one motor system shows pretty good stabilisation.

Here is code for PMW output for different motors:

torque[0] = (int16_t)(+ angles_correction.pitch - angles_correction.roll) + torque_set;
torque[1] = (int16_t)(+ angles_correction.pitch + angles_correction.roll) + torque_set;
torque[2] = (int16_t)(- angles_correction.pitch + angles_correction.roll) + torque_set;
torque[3] = (int16_t)(- angles_correction.pitch - angles_correction.roll) + torque_set;

and here is recorded angles for system with one motor and two motors: enter image description here

To be sure that it's not the algorithm problem, while recording this angles only Integral part of PID was non-zero, so angles were not even stabilised.

My question is - could esc noise each other (in my quad they are quite close to each other - just few sentimeters away) to cause such behaviour? Thanks a lot!

| improve this question | |
$\endgroup$
1
$\begingroup$

I don't know that there's enough information here to diagnose anything.

How can you get any angle on a quadcopter with only one or two motors running?

What do you mean, "while recording [these] angles only the integral part of PID was non-zero"?? Did you manually set the proportional and derivative errors or gains to zero?

My guesses would be that:

(1) you are supplying power to the motors as though they were a quadcopter when you have the physical configuration in something other than a quadcopter - you can't tune a stabilization algorithm with half of the stabilizers (motors) offline.

(2) don't monkey with the PID controller by turning off random portions and expecting performance to be the same.

(3) in general, I would avoid using the derivative term of a PID controller if at all possible (that is, use a PI controller instead). If noise causes a spike in your sensor reading for one sample then it doesn't add a lot to the P or I terms, but it causes a huge spike in the D term. Sensor noise may also play a part in your issues, but you can filter the sensor to check.

| improve this answer | |
$\endgroup$
  • $\begingroup$ They probably get the angle by manually tilting it, at least that's what we used to do when testing our quad. I agree with (3) in particular, the derivative term isn't easy to tune. I would also like to know how the sensor data is filtered (if it is filtered at all). $\endgroup$ – Mewa Jul 14 '15 at 16:35
  • $\begingroup$ The whole process confuses me - why would you disable all but one or two of the motors, then manually tilt it, and then expect to get any useful data? The quadrotor is a system, to me this sounds kind of like, "Oh I took two tires off my car, why is pulling so hard to the right?" Well, because half your car is sitting on the pavement. You can look at the per-motor performance, but you can't try to tune the system on a per-motor (per-tire) basis. Each has a contribution, but you need the system, intact, to do any useful tuning. $\endgroup$ – Chuck♦ Jul 14 '15 at 18:18
  • $\begingroup$ Don't get me wrong, as I mentioned, you can do per-motor performance tuning, speed regulation, etc., but you can't look at any "angle" stabilization and expect to be able to tune the system on a per-motor basis. $\endgroup$ – Chuck♦ Jul 14 '15 at 18:32
  • $\begingroup$ Nah I completely agree, I was just trying to put in a reason for why they might be doing it. We didn't disable motors while tuning, but we did while trying to debug the error going on with the sensor measurements. First we were tuning normally (4 motors), then noticed that sometimes the entire system would go haywire, which lead us to the angle measurement problem, at which point we disabled motors and tilted by hand to make sure the measurements were correct. $\endgroup$ – Mewa Jul 14 '15 at 18:39
1
$\begingroup$

To me, the straightforward explanation seems that you are applying a desired torque, but on multiple motors -- when you use 1 motor you get 1× torque, and when you use two motors you are getting 2× torque.

I'd imagine that your code should look more like this:

motors_active = 2
c_p = angles_correction.pitch / motors_active
c_r = angles_correction.roll / motors_active
torque[0] = (int16_t)(+ c_p - c_r) + torque_set;
torque[1] = (int16_t)(+ c_p + c_r) + torque_set;
torque[2] = (int16_t)(- c_p + c_r) + torque_set;
torque[3] = (int16_t)(- c_p - c_r) + torque_set;

I'm unsure why all 4 motors are contributing to both pitch and roll (I would have expected pitch and roll axes to be aligned on the quadrotor axes, but technically things will still work if they are 45° rotated). If that's the case, I assume you've corrected for the rotation in the calculation of angles_correction.

| improve this answer | |
$\endgroup$
0
$\begingroup$

It looks like your PID is oscillating, have you tried turning down the P gains in your controllers? Most PIDs are tuned P first by turning all terms to zero and turning up the P to just above the point where it oscillates then for the I gain adjust it till it "snaps" into position, the D gain can be trickier to get but you should start there. Here is a good reference for tuning PIDs on a Multicopter.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.