PDF controller for level mode

[ziss_dm]

Hi,

Just to try something new, I have tried to adjust current PI controller to be PDF contoller(http://stablesimulations.com/technotes/pdf.html). Apart a cool name , it also has nice property: it is never overshoot.
Probably not all people like it, as a stick controls are really soft, but defenetly worth to try:

Code: Select all

  //**** PITCH & ROLL & YAW PID ****    
  for(axis=0;axis<3;axis++) {
    if (accMode == 1 && axis<2 ) { //LEVEL MODE
      errorAngle = rcCommand[axis] - angle[axis];                                 //500+180 = 680: 16 bits is ok here
      PTerm      = -(int32_t)angle[axis]*P8[PIDLEVEL]/100 ;                       //680*20 = 13600: 16 bits is ok here

      errorAngleI[axis] += errorAngle;                                            //16 bits is ok here
      errorAngleI[axis]  = constrain(errorAngleI[axis],-10000,+10000); //WindUp   //16 bits is ok here
      ITerm              = (int32_t)errorAngleI[axis]*I8[PIDLEVEL]/4000;          //32 bits is needed for calculation:10000*I8 could exceed 32768   16 bits is ok for result
    } else { //ACRO MODE or YAW axis
      error = (int32_t)rcCommand[axis]*10*8/P8[axis] - gyroData[axis];            //32 bits is needed for calculation: 500*10*8 = 40000   16 bits is ok for result if P8>2 (P>0.2)
      PTerm = rcCommand[axis];

      errorGyroI[axis] += error;                                                  //16 bits is ok here
      errorGyroI[axis]  = constrain(errorGyroI[axis],-16000,+16000); //WindUp     //16 bits is ok here
      if (abs(gyroData[axis])>640) errorGyroI[axis] = 0;
      ITerm = (int32_t)errorGyroI[axis]*I8[axis]/1000/8;                          //32 bits is needed for calculation: 16000*I8  16 bits is ok for result
    }
    PTerm         -= (int32_t)gyroData[axis]*dynP8[axis]/10/8;                    //32 bits is needed for calculation            16 bits is ok for result

    delta          = gyroData[axis] - lastGyro[axis];                             //16 bits is ok here, because the dif between 2 consecutive gyro reads is limited
    DTerm          = (delta1[axis]+delta2[axis]+delta+1)*dynD8[axis]/3/8;         //16 bits is ok here
    delta2[axis]   = delta1[axis];
    delta1[axis]   = delta;
    lastGyro[axis] = gyroData[axis];

    axisPID[axis] =  PTerm + ITerm - DTerm;
  }

Note: Do not drop Level I to 0, as you would not have stick control at all.

regards,
ziss_dm

[shikra]

Actually, this sounds of interest to me. I like a really soft autolevel. Makes for much nicer FPV flying and smoother video. I probably cant try for at least a week but sounds good...

[jofamilly13]

bonjour comment fait on pour intergrer le code dans le 1.7 doit on suprimer des lignes avant et les remplacée par celle ci ou les rajoutees en plus et ou.
par avance merci

[ziss_dm]

Hi jofamilly13,

For 1.7:

Code: Select all

  //**** PITCH & ROLL & YAW PID ****    
  for(axis=0;axis<3;axis++) {
    if (accMode == 1 && axis<2 ) { //LEVEL MODE
      errorAngle = rcCommand[axis]/2 - angle[axis]/2;
      //PTerm      = (errorAngle)*PLEVEL8/50 - gyroData[axis]*dynP8[axis]/10;
      PTerm      = -(angle[axis]/2)*PLEVEL8/50 - gyroData[axis]*dynP8[axis]/10;
      
      errorAngleI[axis] +=  errorAngle;
      errorAngleI[axis]  = constrain(errorAngleI[axis],-5000,+5000); //WindUp
      ITerm              = errorAngleI[axis] *ILEVEL8/2000;
    } else { //ACRO MODE or YAW axis
      error = rcCommand[axis]*10/P8[axis] - gyroData[axis];
      PTerm = rcCommand[axis]-gyroData[axis]*dynP8[axis]/10;
      
      errorGyroI[axis] += error;
      errorGyroI[axis]  = constrain(errorGyroI[axis],-2000,+2000); //WindUp
      if (abs(gyroData[axis])>80) errorGyroI[axis] = 0;
      ITerm = errorGyroI[axis]*I8[axis]/1000;
    }
    delta          = gyroData[axis] - lastGyro[axis];
    DTerm          = (delta1[axis]+delta2[axis]+delta+1)*dynD8[axis]/3;
    delta2[axis]   = delta1[axis];
    delta1[axis]   = delta;
    lastGyro[axis] = gyroData[axis];

    axisPID[axis] =  PTerm + ITerm - DTerm;
  }

regards,
ziss_dm

[jofamilly13]

un copier coller ok mais ou ??

[babelo]

En lieu et place du code deja present, cette portion de code existe deja et elle commence comme pour l exemple par :

//**** PITCH & ROLL & YAW PID ****

et se termine aussi par :

lastGyro[axis] = gyroData[axis];

axisPID[axis] = PTerm + ITerm - DTerm;
}

[jofamilly13]

ok je remplace les lignes //**** PITCH & Roll & PID LACET **** et suite par celle fournit plus haut

[jofamilly13]

quel effet cela à t il vraiment

[UndCon]

Sounds interesting for FPV/Video use as the default autolevel is very fast to gain control again

[spagoziak]

This does look quite interesting! How can I integrate it into one of the later dev versions? I'm using 0714 r207.

[Alexinparis]

This does look quite interesting! How can I integrate it into one of the later dev versions? I'm using 0714 r207.

it's in the last rev R214 as a #define

[spagoziak]

So I've had a chance to test the PDF controller and I'm both impressed and disappointed! I hope it's just me not understanding how this thing works.

It's very windy for testing today, maybe 9mph with 15 mph gusts. It's a great environment to push the PID values and expose any issues. I was able to add another .5 to P on pitch and roll, and another 1.0 on yaw! It's becoming clear that there are several things different from 1.7... I would never be able to fly on 1.7 on these values.

However, auto level has some interesting features with the PDF turned on. It's impossible to get the wobble of death, even in strong wind & ground effects. It just will NOT screw up. That is brilliant!! However, like dm said, if I is too low, the quad flies like the RC rate is at .10. The trouble is... auto level doesn't .. level! If tipped to maybe 75 degrees and then flipped on, the quad will fix about 30 degrees and then hold steady. Moving it from that position by hand is a real chore, so it seems to be thinking level is -45 degrees. If I tip it only 20 degrees and turn AL on, only a few degrees of level are restored, then position holds again.

I even turned P up to 25 (max) and flew it in this strong wind.. no wobbles, but still no snapping to level.

Am I misunderstanding how to tune this? Or is it just not quite right in the code yet?

Here are my current settings, just flew them 5 minutes ago and got the results I described above.

[spagoziak]

So it turns out that I had my BMA180 set to 0x80 when it should have been 0x82, under the sensors tab. I've had to make that change for 3 full versions now, you'd think I'd have remembered!

Anyway, once that was sorted out, I began tuning indoors tonight, in a largish space where there's enough air to discount ground effects after 5 feet. After a two batteries of up and down, I must say I'm really impressed with how soft and gentle the leveling process is. Just like _dm said, the control is mushy. It seems this improves by increasing I dramatically. I need to fly this setup FPV before I'll know where I needs to stay. I managed to turn P up too high and all it caused was a bit of a nervous twitch, never a wobble of death. I backed it off .6 and in dead air leveling was smooth.

But.. it was slow! I suppose this is how the PDF avoids over compensation--by slowing down as the angle reaches 0. I think for FPV it would be a pleasing thing to watch, but not effective enough for really practical use. For me, I seldom fly with auto level enabled because my control is too mushy and auto level is really unnecessary in FPV.. the horizon is a clear indicator of attitude during normal flight. I use auto level only in moments of panic or when I'm coming in for a landing. At those times, I want auto level to snap me flat as fast as possible and hold me there tightly. This PDF filter doesn't seem able to do that.. but it sure is smooooth

Here are my current settings with dev 0714 r217, with PDF enabled:

[Alexinparis]

Thank you spag for this feedback.

The current implementation is based on an angular mode control (you choose an angle via the sticks, and the multi reaches this angle). It's not very convenient for everyone

I'm thinking about another LEVEL mode:
The multi would still be controlled via a rate mode (like in acro), but there would be also a component which would force the multi to retrieve an horizontal level position (with a customisable relative weight) => this LEVEL mode would be just an assisted acro mode. I think it would be more natural.

[PatrikE]

this LEVEL mode would be just an assisted acro mode. I think it would be more natural.

Kind of fly Acro and center sticks then it will Level..

/Patrik

[spagoziak]

Thank you spag for this feedback.

The current implementation is based on an angular mode control (you choose an angle via the sticks, and the multi reaches this angle). It's not very convenient for everyone

I'm thinking about another LEVEL mode:
The multi would still be controlled via a rate mode (like in acro), but there would be also a component which would force the multi to retrieve an horizontal level position (with a customisable relative weight) => this LEVEL mode would be just an assisted acro mode. I think it would be more natural.

You're welcome, glad I can help somehow

Assisted acro sounds like a good idea! As long as you could put the relative weight value in the GUI, so adjusting it would be easy, it could have a really welcome following. It seems most folks want that strong, flat help when they need it but find to get that feeling, P needs to so high that control is mushy. This combination of features would be interesting to try. Of course, make it a //#define so folks who don't like it can just // it out! There are always a few

[spagoziak]

Ok I had a chance to fly it in light wind today. Turns out I had P turned up too high for wind; the craft was a bit twitchy. Turning that down helped it remain smooth. The main drawback of the filter still remains though: too passive about leveling off. This form of auto level would do poorly as a panic button. For video flight, perhaps. I think that a properly isolated and tuned ACC will offer smooth stabilization and wicked fast return to level when needed.

However, it would be neat to have an option in the GUI for an autolevel expo, similar to pitch/roll and yaw rate. I'm thinking the expo would effectively give more rate as the stick moved farther from center, avoiding the typical mushy response when AL is enabled while preserving the power of AL when it was needed. Alex, I think this is what you meant, right?

[oyibox]

This PDF filter is working very well for at 20hz. special thank to you ziss_dm.

Is it doable and efficient to have this filter between 10 and 20?

Code: Select all

#if defined(ITG3200_LPF_256HZ) || defined(ITG3200_LPF_188HZ) || defined(ITG3200_LPF_98HZ) || defined(ITG3200_LPF_42HZ) || defined(ITG3200_LPF_20HZ) || defined(ITG3200_LPF_10HZ)

is it possible to change the 6 values to 10,12,14,16,18,20 ?
thanks.

[Hamburger]

is tihis supposed to still work with latest v1.9+ ?
Symptoms:
when in acro mode, stick input works as expected (max servo output 1900 for pitch).
When in level mode, I have almost no control over servos with stick input for pitch and roll (on flying wing) (max servo output ~1560).

[doughboy]

I just tried this with the latest shared code. with the default PID values, there is completely no pitch and roll control !!!! not cool.
probably should be fixed or just completely removed, obviously nobody is using this feature.

[shikra]

I don't think anyone uses it any more. Level mode has mode on + we now have horizon of course.

I would suggest considering a version of this...
viewtopic.php?f=7&t=1935

Helps prevent overshoot - which was one of the original aims of ZISS

I wanted to develop further and repost at some time, but just too much on at the moment. I still fly some my copters with a variant of this and see it as a definite positive improvement.