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;

}

Views: 13494

Attachments:

### Replies to This Discussion

Limiting the feedback output (as Jason indicates) is one solution, but it can also lead to more problems. (I don't have ACM or aeroquad, BTW). Ultimately, your actuator is limited, of course, but we often want the control system to be able to maneuver up to the hardware limits, as opposed to adding additional limits in s/w.

The typical ESC works by effectively sending a fraction of the battery voltage to the motor. Hence, there's a hidden gain based on the battery voltage. If you really want to compensate for this, you can just multiply the motor output by the nominal voltage divided by the sensed voltage. Of course, you will still lose top end performance, but there's nothing you can do about this.

Two caveats: 1) You can damage a Lipo by letting the voltage go too low, so be careful. 2) I suspect (without trying it myself) that a good feedback algorithm would be robust to small degradation in battery voltage. Do you really need all that performance?

- Roy

hi roy/everyone,

here's the additional information of vibration issues. I think it is due to vibrational noise of accelerometer in imu, that causes the Derivative calculated to be insane.

Therefore I'm trying to use bias compensated pitch angle from gyroscope to do the derivative now.

Attachments:
does anybody encounter problem with centre of gravity and pidcontrol? mine seems to be affecting a great deal.
hey roy..here's the captures and data in excel if you are interested..
i am now using derivative from drift corrected gyroscope angular rate instead of derivative of angle from IMU.
It is smoother in wave form but I'm not sure whether to call it sine wave.

The waves become more and more jagged and irregular after i did several independent tests on PID gains, then used back the same gain i originally used(P=0.7, d = 0.3). I don't know if it is a battery drainage level issue.

The oscillation is still too great.
Attachments:

1

2

3

4

5

6

7

8

## Groups

163 members

3 members

1470 members

631 members

• ### ArduBoat User Group

259 members

Season Two of the Trust Time Trial (T3) Contest
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here