Re: [Paparazzi-devel] Proposed update in the fixedwing pitch control loop

[Gautier Hattenberger]

Hi,

I agree with Hector on the fact that the math is wrong when only using pitch rate. On the other hand, the error is most of the time small and only sensible at high bank angle. Also, correctly computing the derivative of theta means that we will add the error and noise of the angle estimates in the error signal (and so in the command). As long as we don't do aerobatics, not sure it really make sense to use the full equation.

About adding the possibility to choose the current code or using the measured pitch rate, Michal said that the gains needs to be adapted with the P factor. So I guess the idea is to change the structure of control loop from

u = P * (err + D * d_err)

to

u = P * err + D * d_err

There is already a discussion opened in https://github.com/paparazzi/paparazzi/pull/1658 but not really closed.

I'm also pointing that in the "old" control, it is not the numerical derivative of theta that is used (as in the "new" control) but the difference between the last two values (division by DT is missing). It means that you can't simply replace d_err by q (or a more complete equation). You also need to compensate by the control time step.

Gautier

Le 18/09/2016 à 09:06, Hector Garcia de Marina a écrit :

Hi Michal,

what do you mean by classical control notation? do you have any reference about it?

The _expression_ what I have posted can also be found in control books such as the popular "Aircraft Control and Simulation" by Stevens and Lewis. Pages 27 or 110.

You can also find in the same book in page 293, "The effects of pitch-rate and AoA feedback" or page 327, "Autopilot Pitch-attitude hold" the discussion I was posting about. For nominal flight conditions or

wings-level flight, then it is ok to approximate the pitch rate \dot\theta by just 'q'. But this is only for the design of the control loop, i.e. to calculate the gains off-line, under such assumption.

However, in the actual system you have to feed your controller with the correct physical quantities, e.g. the correct pitch-rate and not its approximation, just via sensors or a correct physical _expression_.

You can find this in more detail in the same book, Section 4.7, Example 4.7-1 (Pitch-rate Nonlinear simulation).

Summarizing:

- It is ok to take 'q' as an approximation of the pitch-rate for design purposes where your roll angle is expected to be small (I would say about plus minus 15 degrees? that depends ofc a lot on the actual aircraft).

- An error signal always has to be computed correctly. If we are controlling the pitch-rate, then we have to provide the correct _expression_ (and not an approximation). Otherwise, we are controlling a different physical thing (this is what is happening now in the code by putting just 'q' in the code as pitch-rate).

- This is not about software, it is just physical/mathematical fact :P.

Of course, I do not want "to impose" anything in your code. In the end if the user is happy with the performance of the actual flight then this is what really matters. On the other hand, I just wanted to point out (and hopefully to clarify with some math and physics facts) why the proposed modification is not correct. In fact, I could also explain why the non-correct modification in this code works (but expectedly worse) in practice from a control-theory point of view, but I would say this is beyond the scope by now xD.

Cheers.

On Sun, Sep 18, 2016 at 1:03 AM, Michal Podhradsky <address@hidden> wrote:

Hi Hector,

hmm, if somebody more knowledgeable wants to make such a change then it probably should go in a different pull-request. For now I would only change the derivative term to be consistent with the classical control notation.

Regards

M

On Sat, Sep 17, 2016 at 10:45 AM, Hector Garcia de Marina <address@hidden> wrote:

Hi Michal,

the correct _expression_ for the pitch rate is

\dot \theta = q \cos(\phi) + r \sin(phi), 

where \theta is the pitch, \phi is the roll and 'pqr' are the three angular rates at the body frame, i.e. the readings of the gyros. One can verify this _expression_ 

in whatever physics book dealing with rigid bodies :P.

Indeed, if the roll angle is close to zero, then we can approximate the pitch rate to just sensor reading 'q'. On the other hand, in situations such as following

a circular pattern the roll angle is "far" from zero. Furthermore, if we also have an action on the rudder, e.g. a coordinated turn, then 'r' will be also different from zero.

Cheers,

On Sat, Sep 17, 2016 at 7:32 PM, Michal Podhradsky <address@hiddensu.edu> wrote:

Hi Hector,

I am not sure if I understand correctly your question about the non-zero roll angle. Can you elaborate? The pitch controller doesn't take in account the roll angle or the roll rate.

To clarify - the proposed change is only in the derivative error calculation (pitch rate), the pitch error itself is unchanged (see https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/firmwares/fixedwing/stabilization/stabilization_attitude.c#L476 )

The term
float d_err = h_ctl_ref.pitch_rate - stateGetBodyRates_f()->q;
takes care of situations when your reference pitch rate is non-zero (although in most cases it will be zero).

To follow non-zero pitch angle there is this term:
float err = h_ctl_ref.pitch_angle - stateGetNedToBodyEulers_f()->theta;

it allows you to follow whichever pitch angle you set as a reference.

Regards

Michal

On Fri, Sep 16, 2016 at 11:33 PM, Hector Garcia de Marina <address@hidden> wrote:

Hi Michal,

instead of 

float d_err = h_ctl_ref.pitch_rate - stateGetBodyRates_f()->q;

should not be (pseudocode) the following?

float d_err = h_ctl_ref.pitch_rate - (q * cos(roll) - r * sin(roll) );

Indeed, the first _expression_ is a particular case of the second when the vehicle is flying with roll = 0, e.g. "following a straight line". However, it is also
normal to fly following circles or other cases where the average of the steady-state roll is not zero.

What do you think?

On Sat, Sep 17, 2016 at 3:09 AM, Michal Podhradsky <address@hiddensu.edu> wrote:

Dear paparazzi users,

there is a proposed update in the way the fixedwing pitch control loop handles the derivative term. Currently a pseudo-derivative is used (see here) - the pitch rate error is calculated as a difference in the previous and current pitch error.

The proposed change follows a solution already present in the adaptive stabilization (here).

The difference is that now the pitch rate error is calculated using a pitch rate (measured from the gyro) and a rate setpoint (typically zero).

The benefit of this change is that it unifies the control loops, within paparazzi and also with standard control theory notation.

The drawback is that the D gain currently used would have to be updated using this formula (see here for details): D_new = D_old * P_old (the old D gain wouldn't work).

Since this is a change that affects multiple fixedwing airframes I would like to know your opinion first - would you be strongly opposed to the change or are you OK with updating the gains (and possibly retuning the aiframe) if it means unified and standardized control loops?

Thank you for your feedback.

Michal

 

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

--

Héctor

Website: http://masteringrobotics.com

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

--

Héctor

Website: http://masteringrobotics.com

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

--

Héctor

Website: http://masteringrobotics.com

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel