Tag Archives: tuning PID

Beta2test.Before going on Vacation

During the last week  I  made some improvements on the code that I need to report here in order to avoid any  oversights after the upcoming vacations…

  • Added a function to tune manually the P,I and D  on the run.
  • in pid.py added a function to calculate an average during the D_correction calculation. This help to have a smoother value.
  • Display results every 0.2 sec, instead every cycle (trying to reduce cpu load).
  • improved log
  • Calculation of  the angular speed (roll_rate, pitch_rate and yaw_rate) in the sensor_py. Those values are coming from the derivate of the roll,pitch and yaw already filtered with the complementary filter. they are not the row  roll_rate,pithc_rate and yaw rate  from the gyroscope.

The main improvement has been the introduction of the  PID  for the roll_rate.I did a new  module called beta2.py  where I put  two PIDs in series. This is a typical approach in the quadcopter controller. The first PID  returns the  Roll_correction. (this number represent the angle variation that I ‘d like to have in one step).

Dividing the  Roll_correction for the cycletime, it represent the angular speed (roll_rate) I’d like to have in one step.It is the target for my new roll_rate PID.The feedback is the angular speed calculated in the sensor.py.The result is a really more stable quadcopter, less nervous and more quick on the response.

Below the graph that show the current state of the tuning.

Beta2_pid_tuning

 

As you can see, there is still an oscillation, but it is  between +/- 1 degree.Where I need to work is  fact that  the system never reach the target.(now I have a very simple roll_Pid , with I=0 and D=0. I’m thinking to set a v alue for the I also).

Beta1test. Bugs and a steps ahead

Yesterday I got this result:

beta1_graph1

Thanks to the following actions:

1)The test with the ball on the bottom of the drone,did not convince me. the friction on the ball, the  rotation limits due to the basement, were all components that are not present during the flight.

So I decided to switch to the more used and recognized  solution with the quadcopter tied up with 2 wires.

beta1_tied_up

2) I realized  that something was wrong on the motors behaviour.When I  run the beta1.py   the motor sound  was unstable and unconstant evenif  I was not  controlling it with PID ,just make them run in throttle speed.

This is not happening if I run the motor_test.py.

Finally I was able to reproduce the problem and I realized there is a bug (or better an unexpected behaviour)  in the  library RPIO. If I run this loop (that reproduces the main loop of the beta1) I got the unstable motor rotation:

while true:

mymotor.servo.set_servo(self.pin, PW)

sleep(0.01)

 

My explanation is everytime  calling the set_servo()  function, it resets to zero the signal than set it to the desired value PW).

Instead of that funciont I introduced the lower level function

myMotor.PWM.add_channel_pulse(1,self.pin,0,PW)

When I put it in the test loop I got a perfect, stable, constant sound for the motor rotation.

This 2 improvements gave me the opportunity to move  a  great step haed. Now the tuning can be faster and more consistent.

Above just a graph showing the current behavior.In blue the requested   roll , in red the real roll when  the quadcopter is  using the pid controller. I still need to  tune it to reduce the time to reach the target (5/6 seconds)  and to avioid the oscillation ( +/- 3 degrees).But I’m really satisfy about the current situation.