r1474 - new yaw algorithm

[Hamburger]

Hi,
I have to run low yaw PIDs (2.0, 0.002, 85). Even with increasing the yaw.rate to possibly insane values like 1.5 I can only get yaw servo signal in the range of 1200-1800 for full input from tx. This looks like a severe limitation?

[nhadrian]

Hi,

I have problems with new algorythm on tri, when small stick input is allied, after release stick I have some degrees back/front drift before yaw stops in direction.

I'll try to describe:

The problem is that on tri there is asymmetrical torque balance, so we have to compensate with yaw continously. We can set the midpoint for hoover, but it will not good for raising/descending or in wind, where not exactly hoovering throttle needed.
And this error between hoovering and actual torque causes the back-drift orfront-drift when I term is zeroed. It acts like a heli gyro in rate mode...
Maybe this new idea still could work but it definitelly needs a fine tuned yaw-throttle curve with at least 5 points. (Just the same as with old rate-gyros on helicopters...)
This problem doesn't occur on a symmertical frame, where rising/ descending doesn't causes torque balance problems. (Unless some CG problem or motor problem...)
Other solution would be separated calculations for motor-blanced (quad, hex,... maybe airpanes too) and for servo balanced (bi, tri,...) models.

BR
Adrian

PS.: does anybody have any results with tricopters?

[albertoLG]

my quad start to rotate very fast with just a little stick input, had to revert back the previous revision...

[Alexinparis]

Hi
I wont be able to investigate it this week (on vacation)
I think the P term contrain should be removed for tricopter in the pid. This should be the same control as before

[Hamburger]

in IMU.ino we still have some averaging code:

Code: Select all

  #elif defined(TRI)
    static int16_t gyroYawSmooth = 0;
    imu.gyroData[YAW] = (gyroYawSmooth*2+imu.gyroData[YAW])/3;
    gyroYawSmooth = imu.gyroData[YAW];
  #endif

Curious this would only apply to TRI but not to BI, FIXEDWING, HELICOPTER, SINGLECOPTER, DUALCOPTER?
Is that averaging still necessary or is it a leftover and could be removed with the new/modified pid controllers or would have to be applied to the other coptertypes with servo(s) as well?

[Hamburger]

with the evolved oldschool yaw algorithm I suddenly need like 50% expo on roll/pitch (on the TX side) for fine granularity flying. This is with a small low power TRI. Maybe lowering the rate conversion (?) default would help - I already have the roll/pitch rate down to 0. I guess with quads this may not be neccessary?

[Alexinparis]

Hi,

Some more investigations:

I have problems with new algorythm on tri, when small stick input is allied, after release stick I have some degrees back/front drift before yaw stops in direction.

I can reproduce it.
This is exactly what happens when the servo yaw mid point is not well adjusted to compensate the torque.
You need first to adjust to right mechanical mid point. (or move mid value of servo via GUI).
Once correctly done, there is no more back drift.

This was less noticeable with the old algo because I term has a more important weight for yaw now.

We can set the midpoint for hoover, but it will not good for raising/descending or in wind, where not exactly hoovering throttle needed.
...
Just the same as with old rate-gyros on helicopters

No, it's not the same situation.
With a heli, the torque is not proportional to throttle especially in idle up mode. That's why we need a curve.
In the case of a tri, the torque is more or less proportional to throttle, and the yaw servo angle to compensate the torque should be more or less constant.

my quad start to rotate very fast with just a little stick input, had to revert back the previous revision...

The yaw stick is now twice more sensitive. Is it too much by default ?
If you want to reduce it, change 60 in 30 here:

Code: Select all

    rc = (int32_t)rcCommand[YAW] * (conf.yawRate + 60)  >> 5;

and you should retrieve the sensitivity of before.

Is that averaging still necessary or is it a leftover and could be removed with the new/modified pid controllers or would have to be applied to the other coptertypes with servo(s) as well?

I think if should be extended to all coptertypes with servo(s).
It was set to minimize the servo jitter due to gyro fluctuation at the time of the first WMP.

with the evolved oldschool yaw algorithm I suddenly need like 50% expo on roll/pitch (on the TX side) for fine granularity flying.

If you used to have a quite high P for PITCH&ROLL, it's normal.
now the PITCH/ROLL stick sensitivity is independent of P value.
before the more is P, the less is the sensitivity.
If it's too much, you can compensate with rc rate curve. (not the pitch/roll rate)

And what about your feeling about the past yaw drift problem once a direction is locked ?

[Hamburger]

The yaw stick is now twice more sensitive. Is it too much by default ?
If you want to reduce it, change 60 in 30 here:

Code: Select all

    rc = (int32_t)rcCommand[YAW] * (conf.yawRate + 60)  >> 5;

and you should retrieve the sensitivity of before.

yes, we should revert to old default. quad flyers and experienced pilots can up the yaw rate to achieve that effect but others cannot reduce it (no negative yaw rate tuning parameter).

Same thing for roll&pitch sensitivity. With my test TRI I can hardly move the tx stick and have crazy responsiveness with the evolved pid algorithm. How could we tame down the default sensitvity?

Is that averaging still necessary or is it a leftover and could be removed with the new/modified pid controllers or would have to be applied to the other coptertypes with servo(s) as well?

I think if should be extended to all coptertypes with servo(s).

ok.

[mopedcrosser]

Hi Hamburger / Alex,

could you please take a look at this post as well

http://www.multiwii.com/forum/viewtopic.php?f=17&t=3490

I can´t explain the yaw drift since the mag "sees" that yaw still changes after stopping the stick input. I am pretty much sure that I did not have this problem in 2.1.
How can it be that the software tolerates a drift around yaw while the mag is delivering the correct values ? Furthermore it´s only to the right. If I yaw to the left
it stops and holds immediately which is strange as well. Might this be a software bug or just a fault in my setup ? However there are others having similar issues.
Any ideas are appreciated..

Best regards

Seb

[Alexinparis]

yes, we should revert to old default. quad flyers and experienced pilots can up the yaw rate to achieve that effect but others cannot reduce it (no negative yaw rate tuning parameter).

Ok, done.
I've also doubled the influence of yaw rate setting to have a wider tuning possibility about yaw rate.

Same thing for roll&pitch sensitivity. With my test TRI I can hardly move the tx stick and have crazy responsiveness with the evolved pid algorithm. How could we tame down the default sensitvity?

As as said, with the default PID, the stick sensitivity is equal to what it was.

Now the pitch/roll stick sensitivity does not tend to reduce is you set high P values.
I suspect you used to have high P values and you were accustomed to the resulting pitch/roll rate.
So to have the same result as before, you should set your RC rate like this: 0.9 (default) x 3.3 (default P) / your_P

[Hamburger]

yes, we should revert to old default. quad flyers and experienced pilots can up the yaw rate to achieve that effect but others cannot reduce it (no negative yaw rate tuning parameter).

Ok, done.
I've also doubled the influence of yaw rate setting to have a wider tuning possibility about yaw rate.

cool.

I tested on a heli with a modified '+30'. In the past with the original pid controller code, yaw PID was 1.9, 0.001, 0.30. Now with the new code and same values it seems I do not get enough servo travel even for full stick input. Only if I increase yaw-P to 5.0, then the servo travels farther but that high a P value is not possible to fly. Does yaw-P influence both the rcCommand[yaw] value from the tx input and the proportional error correction? Maybe for servo coptertypes this needs to be dealt with in another way?

When I tested with yaw PID 5.0, 0.001, 0.95 the heli got into a yaw spiral of death. This has not happened before with the original yaw pid code. Unfortunately I cannot test any further as some tail parts of the heli are bent now and need replacement. (a heli is not optimal for testing, too many mechanical items) I had not seen this effect with that same algorithm on a TRI, but there I fly almost default yaw-PID.

[PatrikE]

It seems similar to the Stable P-therm on airplanes.
It also comtrolls the total throw on the servos.