Is the D-term in the multiwii reversed...?

[Berndt]

Hi there,
sorry I am all new to this, but I have a principal question.
It is about some lines of code in this file:
http://code.google.com/p/multiwii/sourc ... ltiWii.pde
This is a part of the code:

Code: Select all

      error -= gyroData[axis];

      PTerm = rcCommand[axis];
     
      errorGyroI[axis]  = constrain(errorGyroI[axis]+error,-16000,+16000);          //WindUp //16 bits is ok here
      if (abs(gyroData[axis])>640) errorGyroI[axis] = 0;
      ITerm = (errorGyroI[axis]/125*I8[axis])>>6;                                   //16 bits is ok here 16000/125 = 128 ; 128*250 = 32000
    }
    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;

I assume that this piece of code calculates the PID for stabilizing angular velocity (correct me if I'm wrong).
P = angular velocity
I = integral of angular velocity = angle
D= derivative of angular velocity = angular acceleration

The D-Term is mainly calculated following

Code: Select all

delta = gyroData[axis] - lastGyro[axis];   

Then, all three terms (P,I,D) are summed up, but the D-term is subtracted

Code: Select all

    axisPID[axis] =  PTerm + ITerm - DTerm;

That would - to my understanding - mean, that the D-term does actually not "amplify the reaction speed", but it will dampen and "weaken" the reaction of the P-term. The D-term is inversed, and the amplitude will be inversed with relation to the P-term.
But to my surprise, I read the following on http://www.multiwii.com/software :

Derivative coefficient: this coefficient allows the tricopter to reach more quickly the requested attitude. In practice it will amplify the reaction speed of the system, and in certain cases an increase of the Proportional term.

Am I understanding something wrong in the code? I must admit that I don't know the syntax, I assume it is something like arduino?

[pm1]

That would - to my understanding - mean, that the D-term does actually not "amplify the reaction speed", but it will dampen and "weaken" the reaction of the P-term. The D-term is inversed, and the amplitude will be inversed with relation to the P-term.

Exactly this is intended. The D Term should limit the speed of change and prevent overshooting. If you have no D term, you can increase P until the system starts to overshoot and to wobble. If you now increase the D term, you can increase the P term further without wobbling. In total, the correction is gained faster with the D term

http://en.wikipedia.org/wiki/PID_controller

[zwiebacksaege]

Hej there,

first of all, greetings to this forum, as I'm new here - but flying the nanoWii for a year now.
Now as the spring comes, I reviewed my settings and digged deeper to understand the PID regulation. I got the same problem in understanding as Berndt. For me the D works also in wrong direction. Ok, it may be intended to damp the system but I tried it in some little Excel-table and a neg. D always caused more oscillation in the system-answer. Where is my mistake?
I assume Output = Pvalue*error + Ivalue*integrated_error + Dvalue*error_derivation...

By the way: I also thought the code would stabilize the angular VELOCITY as this makes sense. But the code shows that the gyro_Data is used directly. In my understanding, gyro_Data is ACCELERATION and it should be integrated before using it. Or is this done already somewhere else? Or am I totally wrong?

Please enlight me! I'm totally confused

[Berndt]

Gyro data is always angular velocity.

[zwiebacksaege]

this means, that the integration is done by hardware? because you can only measure accelerations by physical devices...

[Berndt]

because you can only measure accelerations by physical devices...

Well, I am currently not aware of the principle of a MEMs gyroscope. But you could e.g. oscillate a mass, and then measure the force that is generated when the oscillating mass is rotated. This force should be proportional to the rate of rotation.

[zwiebacksaege]

as far as I know the technics of gyros, there are always some small mass which will bend or move or deform something when they get accelerated. This causes some change in electrical state (voltage, capacity, resistance or whatever) and you can measure a signal proportional to the acceleration. This is how all the gyros for helicopters work.
And the heading hold function they have is only achieved through integration (twice, to have the error in heading)
so the question is, if the integration is already done in wii-sensor and it produces some velocity output - this would make sense for the code.

[Berndt]

which will bend or move or deform something when they get accelerated.

This is how all the gyros for helicopters work

That is both not true, sorry. I don't want to start a fight about this. A while ago, I had the very same thoughts that you have now. Here is a very short explanation of the principle of a MEMS gyro:
http://en.wikipedia.org/wiki/Vibrating_ ... _gyroscope

Due to the vibration, the element resists rotation. The force that is generated through this resistance is measured in a way as you mentioned (capacitive etc.). And the force is proportional to angular velocity (omega). NOT angular acceleration.

Heading hold in the tailrotors of a helicopter could - in theory - also be implemented without any integration. But the performance of a PI control loop is in practice much better than that of a P loop. I am developing my own multicopters since 5 years, that is why I had to read a lot about it.

Here are the correct definitions of P, I, and D (it took me a while to figure them out...):
In a "heading hold" flight mode, where the RC transmitter controls the angular velocity of the copter:
P = angular velocity (signal from gyro)
D = Derivative of gyrosignal (angular acceleration)
I = Integral of gyro signal (angle)

In "Acc Mode", where the RC transmitter controls the angle of the copter:
P = angle (integral from gyro signal)
I = Double integral of gyro signal
D = angular velocity (signal from gyro)

[zwiebacksaege]

thanks very much to this big piece of information... i was not aware of those hardware as i only know acc-sensors from my work, we use for vibration measurement. Then my confusion is half gone, as this now fits to the code for me.

in ACC mode i'm aware that it uses the angle-sensors instead.

But remains the thing with the Minus at the D-Term! Why? In my simple PID-Model it really shows bad results to take a negative value instead of a positive. Because the inverse direction is already caused by the derivation...

Imagining that the copter spins as the should not then the P-Term works counter this by velocity*P-Value. Now the spinning gets slower -> derivation of spinning gets negative -> negative angular acceleration -> D-Term = D-Value*angular_acceleration = negative D-Term -> damps the system

so the D-Term works counter the P-Term if you would write PID = P-Term + D-Term


??? where is the mistake

[zwiebacksaege]

okay I think I found my mistake.

The PTerm and DTerm are defined with opposite signs. So it is somehow like minus and minus makes plus again:

PTerm = - gyroData*PVal
DTerm = + delta(gyroData)*DVal

[Berndt]

The PTerm and DTerm are defined with opposite signs. So it is somehow like minus and minus makes plus again:

PTerm = - gyroData*PVal
DTerm = + delta(gyroData)*DVal

Thanks for this information! That finally solves the mistery of the "inversed" D-Term...

[brm]

Hi there,
sorry I am all new to this, but I have a principal question.
It is about some lines of code in this file:
http://code.google.com/p/multiwii/sourc ... ltiWii.pde
This is a part of the code:

Code: Select all

      error -= gyroData[axis];

      PTerm = rcCommand[axis];
     
      errorGyroI[axis]  = constrain(errorGyroI[axis]+error,-16000,+16000);          //WindUp //16 bits is ok here
      if (abs(gyroData[axis])>640) errorGyroI[axis] = 0;
      ITerm = (errorGyroI[axis]/125*I8[axis])>>6;                                   //16 bits is ok here 16000/125 = 128 ; 128*250 = 32000
    }
    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;

I assume that this piece of code calculates the PID for stabilizing angular velocity (correct me if I'm wrong).
P = angular velocity
I = integral of angular velocity = angle
D= derivative of angular velocity = angular acceleration

The D-Term is mainly calculated following

Code: Select all

delta = gyroData[axis] - lastGyro[axis];   

Then, all three terms (P,I,D) are summed up, but the D-term is subtracted

Code: Select all

    axisPID[axis] =  PTerm + ITerm - DTerm;

That would - to my understanding - mean, that the D-term does actually not "amplify the reaction speed", but it will dampen and "weaken" the reaction of the P-term. The D-term is inversed, and the amplitude will be inversed with relation to the P-term.
But to my surprise, I read the following on http://www.multiwii.com/software :

Derivative coefficient: this coefficient allows the tricopter to reach more quickly the requested attitude. In practice it will amplify the reaction speed of the system, and in certain cases an increase of the Proportional term.

Am I understanding something wrong in the code? I must admit that I don't know the syntax, I assume it is something like arduino?

the piece missing is a d-term dampener.
pls. add a pt1 element - helps a lot to calm down fast transients

[zwiebacksaege]

The PTerm and DTerm are defined with opposite signs. So it is somehow like minus and minus makes plus again:

PTerm = - gyroData*PVal
DTerm = + delta(gyroData)*DVal

Thanks for this information! That finally solves the mistery of the "inversed" D-Term...

win-win-situation

the piece missing is a d-term dampener.
pls. add a pt1 element - helps a lot to calm down fast transients

could you make an easy example? I'm too weak in regulation theory.

[Hamburger]

[Heading hold in the tailrotors of a helicopter could - in theory - also be implemented without any integration. But the performance of a PI control loop is in practice much better than that of a P loop. I am developing my own multicopters since 5 years, that is why I had to read a lot about it.

from my experience with MWii in multirotors and even more so in helicopters, the yaw regulation is far from what a reasonably good heading hold gyro does for helicopters. With the current MWii code the paramters for yaw can be tweaked to compare to a reasonably good rate gyro but nothing more.

Do you have any experience how to improve on the HH aspect of the regulation?

[doppler]

[Heading hold in the tailrotors of a helicopter could - in theory - also be implemented without any integration. But the performance of a PI control loop is in practice much better than that of a P loop. I am developing my own multicopters since 5 years, that is why I had to read a lot about it.

from my experience with MWii in multirotors and even more so in helicopters, the yaw regulation is far from what a reasonably good heading hold gyro does for helicopters. With the current MWii code the paramters for yaw can be tweaked to compare to a reasonably good rate gyro but nothing more.

Do you have any experience how to improve on the HH aspect of the regulation?

+1 on this, yaw on MWii is a really weak point, you have to set P very high to reduce the drifting, then increase I significantly so you get any yaw control, and yet is still randomly jumps. KK2 does it much better, but I have no idea why. My next project is a tricopter, hoping for better yaw control and hold.

[alll]

Yep, love mwii p&r hate yaw!
I think it is because mwii treats the yaw pid differently as the p&r pid loop, and it should not for acro flying.

[zwiebacksaege]

I can not confirm your complains about yaw. My nanoWii sticks to the heading very good. No noticeable difference to my former 6S Heli with 401 gyro.
I use default settings for yaw.

[Berndt]

Do you have any experience how to improve on the HH aspect of the regulation?

Well, I never flew a MultiWII, so I don't know the performance. On my copters, yaw is equal or better to a 401 gyro on a ThreeDee NT helicopter (a relatively large conventional heli). But I don't know the latest progress in helicopter heading hold gyros, as I am exclusively flying multicopters for quite some time. I am using a PI controller for yaw on multicopters with relatively high gain. That gives a very crisp and precise response ("knackig" auf deutsch...).

[Hamburger]

I am using a PI controller for yaw on multicopters with relatively high gain. That gives a very crisp and precise response ("knackig" auf deutsch...).

'using a PI controller' - on what data, please? rotational speed, same as comes from the gyro?
'high gain' - would that translate to high P in the PID world?

[Berndt]

Well, on the basis I described above (in yaw, angular velocity is controlled):

Here are the correct definitions of P, I, and D (it took me a while to figure them out...):
In a "heading hold" flight mode, where the RC transmitter controls the angular velocity of the copter:
P = angular velocity (signal from gyro)
D = Derivative of gyrosignal (angular acceleration)
I = Integral of gyro signal (angle)

In "Acc Mode", where the RC transmitter controls the angle of the copter:
P = angle (integral from gyro signal)
I = Double integral of gyro signal
D = angular velocity (signal from gyro)

[/quote]

'high gain' - would that translate to high P in the PID world?

That would mean high "P" & "i". I increase "P" until the copter oscillates around yaw, then multiply the gain by 0.5. Then I add "i" until it feels like it is flying on rails. I noticed, that a really good yaw control becomes extremely important if you're flying by FPV.

[zwiebacksaege]

Hey guys,

confusion about the source code again... maybe you can help me another time:

As I interprete the last lines in the MultiWii.ino the PTerm for Level is (roughly) calculated as errorAngle*P(level) - gyroData*P(axis)

This means, they are mixing angles with angular velocity. This sounds just stupid to me.
Shouldn't be the PTerm -= gyroData*P(axis) be inside the ACC-if-block?

edit:
and why is the Pvalue only multiplied with the gyroData and not with the rcCommand? In my imagination the PTerm should be created as Pvalue*(rcCommand - gyroData)..

i'm sure I have some mistake in my imagination as the Wii is actually flying with this code but I would really like to understand this coding!

[zwiebacksaege]

noone to help me understanding this code?