Hi all, i've been googling and reading up on plenty of projects and papers, but not much have been discussed about PID control and updating of PWM of quadrotor.
from my understanding, there are 2 ways of doing the quadrotor hover control..
1) brute force calibration, input = euler angles from IMU which most hobbyists do. set point=0 degree
front motor PWM = user_thrust + PIDpitch - PIDyaw
back motor PWM = user_thrust -PIDpitch - PIDyaw
left motor PWM = user+thrust+PIDroll+PIDyaw
right motor PWM = user thrust -PIDroll + PIDyaw
wait, do we calibrate all PID parameters for pitch roll yaw at the same time or do we calibrate them separately like see-saw balancing?
2) include dynamics, physics, consider moment of inertia.etcetc which research graduates do
Well i chose to use brute force calibration due to time constraints.
Here are some questions I have:
1) do we need to consider the Centre of Gravity in our PID control? My quadrotor's CG is more towards back motor.
2) What is the common frequency of PID control loop? Normally, the IMU data is updated then PID is updated right? The maximum I can go on my 16bit 33MHz MCU is 200Hz, and sending data wirelessly via XBee at 100Hz. Is it too slow?
3) I find my PID too slow because I can never find the Pgain(Igain=0 and Dgain=0) (i.e the pitch pole) that does not oscillate.
We need some limit of the maximum and minimum PWM if we are flying autonomously. however, my PID always reaches the maximum and minimum limit and by the time the pole crosses 0degree, the pitch pole does not change direction even though the PID has caused the PWM to switch. Please see attached (problem.jpg) note that my pwm has been shifted down to see the effects with respect to error pitch.
4) What is the frequency of the PWM sent to the ESC? reverse engineering the common RF receivers, the pwm used should be 50Hz. If we're updating PID(200Hz) wouldn't the PWM be too slow?
However, i have found somebody doing a test that going beyond 50Hz PWM actually affects the motor's thrust, which does more harm than good. please see attached (wobbletest.jpg)
5) Using Pgain and Dgain together, the control has improved, but the pitch pole still oscillates up to +/-20degrees which is bad. Increasing Dgain any further causes the pole to be "stuck".
6) My prof had actually advised me to use PDsquare control but it doesn't help because Dsquare refers to d(error square)/dt= d/dt[d(error)/dt] right? if 1/dt = 200, then will be multiplying the D term by 4000 which will hit the PWM limit even faster.
7) What is PID saturation, steady state error, integral windup, integral antiwindup? omg I'm noob with control theory.
/////My pid code in c/////
float inv_dt=200; // means 1/dt, pid loop at 200Hz
float error_pitch; //global variable
float fm,bm; //front motor and back motor pwm on cycle
float Kp_pitch,Ki_pitch,Kd_pitch; //set these values using my ground station when tuning
float PIDpitch(float Kp, float Ki, float Kd)
{
float previous_error;
previous_error= error_pitch;
error_pitch = 0 - kalman_pitch; //set point = 0 degree
integral_pitch += error_pitch*dt;
derivative_pitch = (error_pitch - previous_error)*inv_dt;
return (Kp*error_pitch)+(Ki*integral_pitch)+(Kd*derivative_pitch);
}
void motorControl() //controls front and back motor's PWM
{
float pitch=0; int temp=0;
pitch = PIDpitch(Kp_pitch,Ki_pitch,Kd_pitch); //update PID loop
fm=fm+pitch;
fm = 750 + pitch; //750=start off at 1.5ms
temp=(int)bm;
if(temp>1000)fm=1000; //max pwm limit 2ms
else if(temp<600)fm=600; //min pwm limit 1.2ms
TPU1.TGRA=(int)fm;
bm=bm-pitch;
bm = 750 - pitch; //750=start off at 1.5ms
temp=(int)bm;
if(temp>1000)bm=1000; //max pwm limit 2ms
else if(temp<600)bm=600; //min pwm limit 1.2ms
TPU3.TGRA=(int)bm;
}
Tags:
The P term determines how hard the system responds to the error. If you set P to zero it won't react at all. Keep lowering P until the overshoot stops. At some low enough value you won't be supplying enough power to get to the zero point. As P increases you will get a response that will overshoot. The P term represents the present error. While you are doing this set I and D to zero. There is nothing wrong with overshoot as long as it doesn't then result in undershoot. Some amount of allowed overshoot will give you a faster reacting system.
The I term prevents the overshoot. The I term accumulates over time to counteract the P term and soften the overall reaction so that you can react strongly at the beginning and back off as the error approaches zero. The I term is the accumulation of past errors.I should be a small number.
I wouldn't touch the D term until you come to grips with P and I. A very small negative D might help.
first set K_{i} and K_{d} values to zero. Increase the K_{p} until the output of the loop oscillates, then the K_{p} should be set to approximately half of that value for a "quarter amplitude decay" type response. Then increase K_{i} until any offset is correct in sufficient time for the process. However, too much K_{i} will cause instability. Finally, increase K_{d}, if required, until the loop is acceptably quick to reach its reference after a load disturbance. However, too much K_{d} will cause excessive response and overshoot. A fast PID loop tuning
usually overshoots slightly to reach the setpoint more quickly.
Hi Dean thanks! but I think you have mixed up I-term and D-term.
why would u suggest a negative I or D?
could you explain what is integral windup/antiwindup?
from wikipedia:
The integral term (when added to the proportional term) accelerates the movement of the process towards setpoint and eliminates the residual steady-state error that occurs with a proportional only controller. However, since the integral term is responding to accumulated errors from the past, it can cause the present value to overshoot the setpoint value (cross over the setpoint and then create a deviation in the other direction).
i seem to face the same problems you faced !!
have you fixed it !!
i have also heard of LQR control !!have you tried it !!
Please se the ACM code http://code.google.com/p/arducopter/source/browse/#svn%2Ftrunk%2FAr...
It can fly perfectly stabilized with almost any kP value. Tuning is only a matter of deciding how responsive you want the quad to be.
What I've found that you need to limit the D term so that it is symmetrical with the P term. Think of two forces opposing each other. If one is greater it will oscillate. (The D term is the rate of rotation dampener.)
I term is not needed for the most part and you can fly fine without it.
Jason
Let me expand.
Normally people think of PIDs when they want to regulate something like a thermostat. But thermostats don't rotate. What you care about is rate of rotation for a quad. Your quad may be tilted at 15°, but what is your motor response? If it is not rotating, give one engine +100pwm. If it's rotating at 2 r/s towards level, don't bother giving it any pwm. If it's rotating at 2r/s away from level, give it 200pwm. The thing that decides how much to adjust the response is the D term. please look at ACM for details on how this works. I've included the math to the right of the code.
Next you need to limit your P and D responses. In my example I have a maximum of 100PWM as a response for each. The two terms need to be symmetrical so that you get a 0 response when the copter is rotating towards the correct orientation at the desired rate.
If you limit your responses, you don't need to worry so much about the lipos. The only thing there is how much energy it takes to make you move up and down. As your lipos discharge they will drop off and that is calculated by voltage. The response of your props needs to be measured and a response curve could be developed. But the I term in your throttle PID should take that into account anyway. So I don't see the point.
Ideally, it should not oscillate +/- 10 degrees at all! If you had a linear issue (e.g. incorrect gain), the response should be a constant frequency (damped) sine wave. This appears to be a non-linear issue. Is there any additional information you can give us?
- Roy
1468 members
630 members
3163 members
© 2019 Created by Chris Anderson. Powered by