Replace PID-controller with HeadingHold controller for yaw?

Post Reply
User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Replace PID-controller with HeadingHold controller for yaw?

Post by Hamburger »

Hi,
this is way over my head, so you may just tell me I am dead wrong.

I have recently glued an MWii board on my flybarless helicopter and got it maidened with a friend's help (viewtopic.php?f=8&t=1562&start=40#p15319). But the tail/yaw response differs from what a good classic heading hold gyro can do. Currently the yaw-PID is tuned to work as a good (acceptable) rate gyro (PID=6.5, 0.009, 80).
Now when flying heli, the heading hold (HH) is far superior to rate mode. It holds direction like it is kinda memorized and returns to that direction until told otherwise. In comparison, a rate gyro will only try to keep a steady direction by minimizing bounces - but first gust and original direction is lost forever.

Incindentally I stumbled upon a HH gyro project over at RCG. The author discusses the PID implementation for both rate and HH and shortcomings in some detail. He also claims to have added some extra debounce feature to overcome the PID shortcoming, but is not willing to reveal the nature of it. He has published some of his thoughts and findings here
The Heli Gyro as a Controller: Theory and Experiment http://www.rcgroups.com/forums/showthread.php?t=1538273
Further discussion here
Gyro GA250 + alternative Firmware: The Best of the Cheap!? http://www.rcgroups.com/forums/showthread.php?t=1610075


One of his claims (or what I understood) was to decrease P & increase I for HH. When we tried this on my heli the tail became unstable/oscillating.

So what do you think, is this HH something that was good to have for all multicopters and how can we tune the yaw-PID for a better HH? Or do we need another (extended) algorithm than traditional PID? Ideas, comments?

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Replace PID-controller with HeadingHold controller for y

Post by Hamburger »

I think I forgot
the author OlliW does only release his firmware as hex file. The gyro runs an atmega8 mcu - sound familiar.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Replace PID-controller with HeadingHold controller for y

Post by Hamburger »

just bumping the thread - cannot believe no interest in PID controller theory and the likes.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Replace PID-controller with HeadingHold controller for y

Post by Hamburger »

interesting reading IFAC PROFESSIONAL BRIEF Hands-on PID autotuning a guide to better utilisation
http://www.fastbot.de/red.php?red=30795 ... xruano.pdf

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: Replace PID-controller with HeadingHold controller for y

Post by copterrichie »

good (acceptable) rate gyro (PID=6.5, 0.009, 80).


Just a wild guess, but that I needs to be pumped up to about .04, 05, or as high as .09.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Replace PID-controller with HeadingHold controller for y

Post by Hamburger »

it seems not that easy. Higher I-value did result in oscillations of the tail/yaw. That coincides nicely to our experience with multirotors.

I found mentioned that for HH a lower P was required, then the I-value was to become the P of HH. Still amazes me. My experiments are currently limited by my heli flying skills; some of the more extreme trials will have to wait until I get support from my experienced rc heli pilot friend.

The quoted threads state that for HH something different than a PID-controller is required and I sure would like to get that commented on by our IMU algorithm experts.

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: Replace PID-controller with HeadingHold controller for y

Post by ziss_dm »

Hi Hamburger,

I think, to have good HH with normal PID (wich should be possible), you need good high resolution tail servo. The current Soft PWM implementation has too low resolution and too high jitter, to be used on tail.

rergards,
ziss_dm

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: Replace PID-controller with HeadingHold controller for y

Post by ronco »

Hi,

with 16 bit timer we can do 10 bit HW PWM servo outputs .. like i did for the mega HWPWM gimbal ..

but the promini just has one 16 bit timer with two outputs .. it may be a good thing for the ATmega32u4 and the mega.. we may use it for heli, pure gimbal and airplane mode..

- atmega32u4 has 4 16bit PWM outputs
- the mega has a lot of 16bit PWM outputs ;)

the result would be high resolution and jitter free.. but i dont know if its right to build in so much code into MWC for "not multicopter" :S

regards Felix

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Replace PID-controller with HeadingHold controller for y

Post by Hamburger »

ronco wrote:the result would be high resolution and jitter free.. but i dont know if its right to build in so much code into MWC for "not multicopter" :S


straining for a better HH yaw control is not limited to 'not multicopter' like helicopter, it is also valid for TRIcopter and possibly all other multicopters that use one or more servos to control yaw.

I am sure all multicopters would benefit from a better HH yaw algorithm.
Last edited by Hamburger on Fri Aug 17, 2012 9:29 am, edited 1 time in total.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Replace PID-controller with HeadingHold controller for y

Post by Hamburger »

Hi ziss_dm

ziss_dm wrote:I think, to have good HH with normal PID (wich should be possible), you need good high resolution tail servo. The current Soft PWM implementation has too low resolution and too high jitter, to be used on tail.


I agree one neccessary aspect will be 'good high resolution tail servo'.
But apart from that some modification to the (PID)algorithm may be neccessary as well.

Several developers of software for traditdional (heli) gyros I was in contact with have mentioned
- way lower cycle time (factor 10 to 20)
- tuning PID parameters differently for HH (I becomes P, D becomes I)
- some additional 'debounce' http://www.rcgroups.com/forums/showthread.php?t=1538273

We cannot do much about cycle time (if it really matters?), but about the other two plus high resolution servo it is up to us.
And contrary to some statements here I am sure all multicopters would benefit from a better HH yaw algorithm.
If you are interested I can forward you some info I received.

Cheers, Hamburger

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: Replace PID-controller with HeadingHold controller for y

Post by ronco »

ok..

i dont know how the airplane or heli pinout is ATM.. if you can adjust it to have the most important servos on HW PWM pins ill do the code for it

ill need to know which servo on which pin

the current servo order is..

promini/328p (servo[0] -[7]):
A0, A1, A2, 12, 11, 3, 10, 9
possible 10bit servo HW PWM on 9 & 10 (timer 1)

promicro/32u4 (servo[0] -[7]):
A0, A1, A2, 4, 5, 6, 10, 9
possible 10bit servo HW PWM on 9 ,10, 5 & 11 (timer 1 & 3) .. timer 4 can do 10bit PWM but just with a full range (488Hz)

mega (servo[0] -[7]):
44, 45, 46,37, 6, 2, 5, 3
possible 10bit servo HW PWM on 44, 45, 46, 3, 5, 6, 2, 7 & 8 (and some more)..just timer 2 is 8-bit here

regards Felix

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Replace PID-controller with HeadingHold controller for y

Post by Hamburger »

for heli-120:
servo 3 = d12 = nick
servo 4 = d11 = left
servo 5 = d3 = tail / yaw
servo 6 = d10 = right

servo counting is 0 - 7.
Taken from http://2.bp.blogspot.com/-VDI3u_0fQDw/T ... Servos.png

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Replace PID-controller with HeadingHold controller for y

Post by Hamburger »

can we get higher refresh rate for all servos via SERVO_RFR_160HZ ?
on a 328p I would like to see hw pwm (=higher resolution?) for the rudder/yaw servo (=servo5=d3).
Can you do this mapping somehow or do we need to change the servo->pin assignment - and break all existing airplanes&helicopters?

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: Replace PID-controller with HeadingHold controller for y

Post by ronco »

Hi Hamburger,

Hamburger wrote:can we get higher refresh rate for all servos via SERVO_RFR_160HZ ?

yes SERVO_RFR changes the refresh rate for all servos .. even if thay are software PWM ..
Hamburger wrote:on a 328p I would like to see hw pwm (=higher resolution?) for the rudder/yaw servo (=servo5=d3).
Can you do this mapping somehow or do we need to change the servo->pin assignment - and break all existing airplanes&helicopters?


thats the problem with HW PWM .. we can't change the pins .. so on a promini the only pins that can be used with HW PWM are 9 & 10.
the resolution can also be changed on SW PWM but it will always jitter. With HW PWM we have no jitter but we need a high resolution timer to be able to put out lower servo frequencys withou loosing resolution.

regards Felix

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Replace PID-controller with HeadingHold controller for y

Post by Hamburger »

Ok. So I will tsst with higher refresh rate asap.
Then if you provide patch for hw pwm for yaw servo I will test that later.
Thanks.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Replace PID-controller with HeadingHold controller for y

Post by Hamburger »

first test result:(
on heli with 4 servos analog metal gear mg90s at 160 Hz refresh rate:
first flight felt good, yaw/tail felt way more stable. But at some point get oscillating servo arm on one or more cyclic servos. This resulted in heli crash and broken blades and main gear, bent main shaft. Back on the bench.
Can induce this oscillation with heli on bench and tx roll/nick stick flipping back to neutral position (whipping blades). This servo oscillation does not happen with default 50Hz refresh rate.

4 servos mg90s -> _not_ good.> 50Hz

I will eventually try this again with the other 4 bladed heli with ds922 digital metal gear servos (more carefully, somehow).

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Replace PID-controller with HeadingHold controller for y

Post by Hamburger »

can you do hw pwm on promini for d10, via define? I would then swap servo[] -> pin mapping for yaw and right servos, so yaw servo output will be on pin d10. Swap servo cables for yaw and right servo and test hw pwm?

ronco
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: Replace PID-controller with HeadingHold controller for y

Post by ronco »

Hi Hamburger,

sorry for your heli :(

then ill do a define for HW PWM servo 6 on pin 10 for the promini .. but i think ill make a new folder in my branch for testing ..

regards felix

User avatar
alll
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Replace PID-controller with HeadingHold controller for y

Post by alll »

Hi,

I got redirected here by Hamburger (whats your real name anyway?).

My experience with KK PID firmware, is that the I-term=HH.
If you can "store" the past = accumulate the error = integrate the velocity = angle, you get the HH.

Just do the same PID for roll/pitch AND YAW calculations, no other special 'YAW' filters! Adapt PID of YAW to get the HH!

manu

!!!Gyro ONLY !!!

roll/pitch HEADING:
http://www.youtube.com/watch?v=Navv9j_kMiU
http://www.youtube.com/watch?v=tj84byQ6Y9k

Gyro only!:
http://www.youtube.com/watch?v=RlK6dMbBuS8

yaw HEADING:
http://www.youtube.com/watch?v=b3XQoSTa8Eo
Last edited by alll on Tue Jan 29, 2013 11:48 pm, edited 1 time in total.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Replace PID-controller with HeadingHold controller for y

Post by Hamburger »

you mean real name like here http://www.rcgroups.com/forums/showpost ... tcount=700 ?

Not sure about current implementation, but one difference I can think of is that for nick/roll one can use the gravity vector whilst for yaw one cannot use it because it would be of same value for all yaw angles. From conversations I had with people who did software implementations for regular HH gyros, they all used not PID but ID plus another third parameter for HH.

By all means, please feel free to pursue the issue further.

User avatar
alll
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Replace PID-controller with HeadingHold controller for y

Post by alll »

All depends on how the PID controller is implemented, but i am quite sure that all the "heli" (HH & Rate) gyro's use their own PID controller implementation.

Here a nice discussion on PID:
http://www.plctalk.net/qanda/archive/index.php/t-237.html

I can say that in an "error"-PID implementation, the I-term is the Heading-Hold.

So, who is best suited to explain the current PID implementation of the mwiiv2.1?

Thanks,
manu

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Replace PID-controller with HeadingHold controller for y

Post by Hamburger »

Himself (Alex).

dale.e
Posts: 48
Joined: Sat Sep 29, 2012 6:27 am

Re: Replace PID-controller with HeadingHold controller for y

Post by dale.e »

Ok I just had either an epiphany or a stroke, you guys decide......

Could we not just take a HH gyro like those used in a basic CCPM setup and put it between the Yaw output of the RX and the yaw input of the FC?

Worth a try no?

edit: if somene posted this idea b4 then please just call it a stroke :)

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Replace PID-controller with HeadingHold controller for y

Post by Hamburger »

we could sure do it, would only require to passthrough the yaw signal from the rx to the yaw servo output pin.
But it is not the MWii way to do it - where is the fun?

dale.e
Posts: 48
Joined: Sat Sep 29, 2012 6:27 am

Re: Replace PID-controller with HeadingHold controller for y

Post by dale.e »

I dont know where or when, but I once read a post saying HH could not be done with the hardware built into a MW FC in the way it works on a CCPM Gyro.
I am not fluent enough to repeat the why of it, but I did belive it.......

User avatar
alll
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Replace PID-controller with HeadingHold controller for y

Post by alll »

Never believe too quickly, try it out yourself.
Just open a HH gyro and you will see there is only a mcu and a gyro sensor. So mwii boards are very capable of doing it!
"basic"-HH is not more then the the I-term accumulator. See it as a water bottle that gets filled (+) (with the error) and emptied (-).
For me HH is this as already posted: (if somebody tells me it is not, i will be happy to learn)
manu
http://www.youtube.com/watch?v=Navv9j_kMiU

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Replace PID-controller with HeadingHold controller for y

Post by Alexinparis »

Hi manu,

all the interresting code for yaw PID is located in a small area of Multiwii.ino:

Code: Select all

  for(axis=0;axis<3;axis++) {
    if ((f.ANGLE_MODE || f.HORIZON_MODE) && axis<2 ) { // MODE relying on ACC
      // 50 degrees max inclination
      errorAngle = constrain(2*rcCommand[axis] + GPS_angle[axis],-500,+500) - angle[axis] + conf.angleTrim[axis]; //16 bits is ok here
      PTermACC = (int32_t)errorAngle*conf.P8[PIDLEVEL]/100;                          // 32 bits is needed for calculation: errorAngle*P8[PIDLEVEL] could exceed 32768   16 bits is ok for result
      PTermACC = constrain(PTermACC,-conf.D8[PIDLEVEL]*5,+conf.D8[PIDLEVEL]*5);

      errorAngleI[axis]     = constrain(errorAngleI[axis]+errorAngle,-10000,+10000);    // WindUp     //16 bits is ok here
      ITermACC              = ((int32_t)errorAngleI[axis]*conf.I8[PIDLEVEL])>>12;            // 32 bits is needed for calculation:10000*I8 could exceed 32768   16 bits is ok for result
    }
    if ( !f.ANGLE_MODE || f.HORIZON_MODE || axis == 2 ) { // MODE relying on GYRO or YAW axis
      if (abs(rcCommand[axis])<350) error =          rcCommand[axis]*10*8/conf.P8[axis] ; // 16 bits is needed for calculation: 350*10*8 = 28000      16 bits is ok for result if P8>2 (P>0.2)
                               else error = (int32_t)rcCommand[axis]*10*8/conf.P8[axis] ; // 32 bits is needed for calculation: 500*5*10*8 = 200000   16 bits is ok for result if P8>2 (P>0.2)
      error -= gyroData[axis];

      PTermGYRO = rcCommand[axis];
     
      errorGyroI[axis]  = constrain(errorGyroI[axis]+error,-16000,+16000);          // WindUp   16 bits is ok here
      if (abs(gyroData[axis])>640) errorGyroI[axis] = 0;
      ITermGYRO = (errorGyroI[axis]/125*conf.I8[axis])>>6;                                   // 16 bits is ok here 16000/125 = 128 ; 128*250 = 32000
    }
    if ( f.HORIZON_MODE && axis<2) {
      PTerm = ((int32_t)PTermACC*(500-prop) + (int32_t)PTermGYRO*prop)/500;
      ITerm = ((int32_t)ITermACC*(500-prop) + (int32_t)ITermGYRO*prop)/500;
    } else {
      if ( f.ANGLE_MODE && axis<2) {
        PTerm = PTermACC;
        ITerm = ITermACC;
      } else {
        PTerm = PTermGYRO;
        ITerm = ITermGYRO;
      }
    }

    if (abs(gyroData[axis])<160) PTerm -=          gyroData[axis]*dynP8[axis]/10/8; // 16 bits is needed for calculation   160*200 = 32000         16 bits is ok for result
                            else PTerm -= (int32_t)gyroData[axis]*dynP8[axis]/10/8; // 32 bits is needed for calculation   

    delta          = gyroData[axis] - lastGyro[axis];                               // 16 bits is ok here, the dif between 2 consecutive gyro reads is limited to 800
    lastGyro[axis] = gyroData[axis];
    deltaSum       = delta1[axis]+delta2[axis]+delta;
    delta2[axis]   = delta1[axis];
    delta1[axis]   = delta;
 
    if (abs(deltaSum)<640) DTerm = (deltaSum*dynD8[axis])>>5;                       // 16 bits is needed for calculation 640*50 = 32000           16 bits is ok for result
                      else DTerm = ((int32_t)deltaSum*dynD8[axis])>>5;              // 32 bits is needed for calculation
                     
    axisPID[axis] =  PTerm + ITerm - DTerm;

axis 0,1 = ROLL/PITCH
axis 2 = YAW

So it should be easy to exclude axis 2 here and try your implementation to generate the right axisPID[YAW]

dale.e
Posts: 48
Joined: Sat Sep 29, 2012 6:27 am

Re: Replace PID-controller with HeadingHold controller for y

Post by dale.e »

alll wrote:Never believe too quickly, try it out yourself.
Just open a HH gyro and you will see there is only a mcu and a gyro sensor. So mwii boards are very capable of doing it!
"basic"-HH is not more then the the I-term accumulator. See it as a water bottle that gets filled (+) (with the error) and emptied (-).
For me HH is this as already posted: (if somebody tells me it is not, i will be happy to learn)
manu
http://www.youtube.com/watch?v=Navv9j_kMiU



well I am happy to hear that!! I have been planning an HK450 CCPM MW build and was trying to figure out how to get HH :)
so perhaps in a future build it might be a feature then, that would be way cool! For now I will get out of the way of the peeps that can code.
thats not me :)
But I will be lurking :) see what I can learn...

User avatar
alll
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Replace PID-controller with HeadingHold controller for y

Post by alll »

Hi,

With mwii_ver2.1 i experimented with the yaw PID values. I get some unexpected behavior, not normal! The yaw rate is too low with these values, and sudden rapid spins! (will ipload a video asap). The HH is much better with these values, but the stick rate is not enough..., how could i further increase the YAW stick authority?

manu
Attachments
Screen shot 2013-02-03 at 15.09.07.png

User avatar
alll
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Replace PID-controller with HeadingHold controller for y

Post by alll »

Here the video of the behavior.
https://www.youtube.com/watch?v=8uvZN3LMizo

User avatar
alll
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Replace PID-controller with HeadingHold controller for y

Post by alll »

For what is this good for?
To have consistence loop times, is it not better to stick with "int32_t"?

manu

Code: Select all

    if (abs(gyroData[axis])<160) PTerm -=          gyroData[axis]*dynP8[axis]/10/8; // 16 bits is needed for calculation   160*200 = 32000         16 bits is ok for result
                            else PTerm -= (int32_t)gyroData[axis]*dynP8[axis]/10/8; // 32 bits is needed for calculation   
...

    if (abs(deltaSum)<640) DTerm = (deltaSum*dynD8[axis])>>5;                       // 16 bits is needed for calculation 640*50 = 32000           16 bits is ok for result
                      else DTerm = ((int32_t)deltaSum*dynD8[axis])>>5;              // 32 bits is needed for calculation



User avatar
alll
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Replace PID-controller with HeadingHold controller for y

Post by alll »

Here is a better demonstration of the yaw problem with high PID values and yaw rate = 1, see previous post for screen capture of gui settings.
I had occasionally similar problems with roll/pich where a sudden rapid spin occurs!

http://www.youtube.com/watch?v=4LRVk7okiLk

manu

User avatar
alll
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Replace PID-controller with HeadingHold controller for y

Post by alll »

Conclusion : Careful selection/combination of yaw PID and rate make it ok, extreme values get unexpected behavior.

I will try to dig in the code to understand this behavior.

How can we get quicker response from Alex regarding code logic?

manu

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Replace PID-controller with HeadingHold controller for y

Post by Alexinparis »

alll wrote:Conclusion : Careful selection/combination of yaw PID and rate make it ok, extreme values get unexpected behavior.

I will try to dig in the code to understand this behavior.

How can we get quicker response from Alex regarding code logic?

manu


sorry, I've no magic potion to gain an extra live ;)

Basically, YAW control is just based on P I D term with some customization:
- I term is cancelled when the rate is high
- P and D values are tied to stick position (stick center: P & D matches values in GUI / stick in the corner: P&D are multiplied by (1-yawrate) => the purpose is to cancel progressively the correction. It acts as a "super expo". With yawrate=1 you won't be able to yaw faster, but it's totally uncontrollable. A reasonable value is 0.7 or 0.8 if you think yaw is too soft. Search for dynP8 and dynD8 to understand how terms are dynamically adjusted.

User avatar
alll
Posts: 220
Joined: Fri Dec 07, 2012 9:53 am

Re: Replace PID-controller with HeadingHold controller for y

Post by alll »

Thanks, merci ;)
Its good to have this sort of explanation, it helps to get through the code
manu

Post Reply