Add datas to GUI for PID tuning

[Bledi]

Hi all,

Actualy we use empiric method for PID tuning. But there is some mathematics methods to find the best P,I,D factors.
There is different methods but all need to compare the excitation (move on a stick) and the response (on gyro).

I am not a software developper so I need help ... Is someone can create me a new GUI with on the graph the 4 sticks datas. With that we can compare the order (the stick exitation) and the response (gyro).

For information about the method you can have a look here : http://en.wikipedia.org/wiki/PID_controller

EDIT : The better is to add the value of the sticks and the derivated value

[fr3d]

will you use air-telemetry through ftdi port ?

[Rob]

I use Ziegler–Nichols for PID calculation....

When I set the tune bit, I tune Gyro pid with AUX2 and level PID witch AUX1
Then With AUX3 I save the PID settings in EEprom.

I tune the setting with the quadrocopter in my hand (Above my head)and feel the reaction.

Code: Select all

      if(PMTR_Tune){
         if(rcData[AUX3]>1700){ // Safe in eeprom
            Opslaan_PID_instellingen_in_Eeprom();
            PID_programmed=1;
         }   
         else if((rcData[AUX3]>1200)&&(PID_programmed==0)){
            PMTR_Acc_on_active; // anders kan deze uit staan!!!
            Freq = 3; // Frequentie in Hz
// P /10
// I /1000
// D    
/*

   Ziegler–Nichols method Control Type 
          Kp           Ki        Kd
      P   0.50Ku    -              -
      PI   0.45Ku  1.2 Kp/Pu  -
      PID 0.60Ku  2 Kp/Pu     KpPu/8

Ku = input waarde 0...250
Kp = berekende P waarde (0,6 Ku)
Pu = de frequentie van oscillatie

*/
            PMTR.Gyro_Roll_Pitch_P   = (char)(((((constrain(rcData[AUX2],1000,2000))-1000)/4)*60)/100);
            tempp = PMTR.Gyro_Roll_Pitch_P; // waarde in een int, i.v.m. uitrekenen
            PMTR.Gyro_Roll_Pitch_I   = (char)((2*tempp)/Freq); //tempp hier niet nodig?
            PMTR.Gyro_Roll_Pitch_D    = (char)((tempp*Freq)/8); // tempp hier wel nodig
            
            PMTR.Acc_Roll_Pitch_P    = (char)(((((constrain(rcData[AUX1],1000,2000))-1000)/4)*45)/100);
            tempp = PMTR.Acc_Roll_Pitch_P; // waarde in een int, i.v.m. uitrekenen
            PMTR.Acc_Roll_Pitch_I    = (char)(((tempp*12)/10)/Freq); 
         }
         else{
            PID_programmed=0;
            if(rcData[AUX1]>1500){   // ACC AAN
               PMTR_Acc_on_active;
            }
            else{               // ACC UIT
               PMTR_Acc_on_inactive; 
            }      
         }
      }            
      else{

         if(rcData[AUX1]>1400){   // ACC AAN
            PMTR_Acc_on_active;
         }
         else{               // ACC UIT
            PMTR_Acc_on_inactive; 
         }
         
         if(rcData[AUX3]>1200){
            OUT2_ON;
         }
         else{
            OUT2_OFF; 
         }
      }

100% result.......

best regards,


Rob

[Bledi]

Excellent it's exactly what I would like to do.
Can you explain a little bit more your procedure to make "THE ROB PID Tutorial" !

[Bledi]

Edit: your code looks not to be complete ?
Can you explain how to add it and can you use only AUX 1 and 2 because most of us have just 2 inter

[Rob]

Hello,

The software is complete...... but not for Multiwii sorry, if there is interest I can fix it.....

The PID tuning is only active when ik set the Tune bit (see picture)

http://lynxshop.nl/product_images/uploaded_images/Mainscreen.png

Normaly AUX1 is for switching LEVEL on/off and AUX2 for BARO on/off (My baro software is not ready yet)

after tuning I turned of the Tune PID bit.

Rob

[matbogdan]

Anybody cares to implement this in multiwii ?

[Rob]

Yes I care,

If there is interest I wil do, but I don't have a multiwii compatible board.

If I'm ready with some heavy programming (2 weeks...) I draw a new multiWII board,
and then I can interfere with the multiwii software


Rob

[matbogdan]

I will try and make it myself ... but until march I am busy with other things and I have no time. If no one will implement it by than, I will do it.

[matbogdan]

I think things should be like this:
1- in GUI mark a bit from AUX1 to make the drone in pid setup mode.
Example 1:
AUX1 LOW - no setup
AUX1 MID - Pitch PID setup
AUX1 HIGH - Roll PID setup

I think that this process should be safer if for the entire process we hold the drone in hand.
In this case we can save the parameter in eprom autocratically every 5-10 seconds if the value of P is changed. I will see how it will be the best as soon I do some tests but I think I will stick to hand PID calibration for safety of my budget.

I am still trying to figure out how to calculate the oscillation frequencies but maybe someone will figure this out or I will have to google it hard.
There are some oscillation detection algorithms but they are using FFT and this is not an option to be calculated on arduino boards.

[felixrising]

Without actually finding the period of oscillation in the craft, this is useless... just assuming 3Hz is incorrect.

[Rob]

Yes, but it's à good start, for most of the models.

Rob