# Proposed update in the fixedwing pitch control loop

11 messages
Open this post in threaded view
|
Report Content as Inappropriate

## Proposed update in the fixedwing pitch control loop

 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 [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Open this post in threaded view
|
Report Content as Inappropriate

## Re: Proposed update in the fixedwing pitch control loop

 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 alsonormal 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 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 [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel -- HéctorWebsite: http://masteringrobotics.com _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Open this post in threaded view
|
Report Content as Inappropriate

## Re: Proposed update in the fixedwing pitch control loop

 ah btw, I have found this change very appropriated too! it is better to employ an analytical expression whenever is possible than a numerical one.On Sat, Sep 17, 2016 at 8:33 AM, Hector Garcia de Marina 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 alsonormal 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 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 [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel -- HéctorWebsite: http://masteringrobotics.com -- HéctorWebsite: http://masteringrobotics.com _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Open this post in threaded view
|
Report Content as Inappropriate

## Re: Proposed update in the fixedwing pitch control loop

Open this post in threaded view
|
Report Content as Inappropriate

## Re: Proposed update in the fixedwing pitch control loop

Open this post in threaded view
|
Report Content as Inappropriate

## Re: Proposed update in the fixedwing pitch control loop

Open this post in threaded view
|
Report Content as Inappropriate

## Re: Proposed update in the fixedwing pitch control loop

Open this post in threaded view
|
Report Content as Inappropriate

## Re: Proposed update in the fixedwing pitch control loop

 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 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 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 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 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 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 [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel -- Héctor Website: http://masteringrobotics.com _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel -- Héctor Website: http://masteringrobotics.com _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel -- Héctor Website: http://masteringrobotics.com _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel  _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Open this post in threaded view
|
Report Content as Inappropriate

## Re: Proposed update in the fixedwing pitch control loop

 Hello,indeed, the numerical difference is very small (for noticing the error, the 'p' has to be 'big' and the bank angle around 45degress or more?). In fact, in practice it does not play any significant role since the control loop is meant for following a constant pitch, i.e. we are aiming at a pitch rate equal to zero and it is used as a "damping term", so what is really important is the sign and not so much the magnitude (since it can be scaled by a gain).If we do aerobatics, i.e. to give a reference signal to be followed by the time derivative of the pitch, then I would say that the correct expression will play an important role. In fact I have something in mind for testing this... it is on my "to do" list for near future...I would also agree about decoupling gains, it would not be the first time that one changes one gain without thinking it also affects another one. On the other hand, one then has to take care of changing the involved gains in all the conf files :P.I just noticed (and now I understand why it is coded like this) that the "old control law" comes from the times when there were not gyros on board :P.On Sun, Sep 25, 2016 at 10:51 PM, Gautier Hattenberger wrote: 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 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 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 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 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 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 [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel -- Héctor Website: http://masteringrobotics.com _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel -- Héctor Website: http://masteringrobotics.com _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel -- Héctor Website: http://masteringrobotics.com _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel  _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel -- HéctorDrones and other stuff at my website: http://dobratech.com _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
Open this post in threaded view
|
Report Content as Inappropriate

## Re: Proposed update in the fixedwing pitch control loop

 Thanks to Gautier for explaining my intentions better. Hector, I finally got hands on the book you mentioned - but implementing it would be a different story.Should I understand it that there is consensus on changing the controller structure as Gautier described + updating the D gains for affected airfames as: D_new = D_old * P_old?RegardsMichalOn Sun, Sep 25, 2016 at 2:20 PM, Hector Garcia de Marina wrote:Hello,indeed, the numerical difference is very small (for noticing the error, the 'p' has to be 'big' and the bank angle around 45degress or more?). In fact, in practice it does not play any significant role since the control loop is meant for following a constant pitch, i.e. we are aiming at a pitch rate equal to zero and it is used as a "damping term", so what is really important is the sign and not so much the magnitude (since it can be scaled by a gain).If we do aerobatics, i.e. to give a reference signal to be followed by the time derivative of the pitch, then I would say that the correct expression will play an important role. In fact I have something in mind for testing this... it is on my "to do" list for near future...I would also agree about decoupling gains, it would not be the first time that one changes one gain without thinking it also affects another one. On the other hand, one then has to take care of changing the involved gains in all the conf files :P.I just noticed (and now I understand why it is coded like this) that the "old control law" comes from the times when there were not gyros on board :P.On Sun, Sep 25, 2016 at 10:51 PM, Gautier Hattenberger wrote: 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 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 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 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 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 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 [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel -- Héctor Website: http://masteringrobotics.com _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel -- Héctor Website: http://masteringrobotics.com _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel -- Héctor Website: http://masteringrobotics.com _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel  _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel -- HéctorDrones and other stuff at my website: http://dobratech.com _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
 great! please, do not hesitate to ask me here or in the chat at gitter if you have further questions about the implementation :P. cheers On 27 Sep 2016 05:36, "Michal Podhradsky" <[hidden email]> wrote:Thanks to Gautier for explaining my intentions better. Hector, I finally got hands on the book you mentioned - but implementing it would be a different story.Should I understand it that there is consensus on changing the controller structure as Gautier described + updating the D gains for affected airfames as: D_new = D_old * P_old?RegardsMichalOn Sun, Sep 25, 2016 at 2:20 PM, Hector Garcia de Marina wrote:Hello,indeed, the numerical difference is very small (for noticing the error, the 'p' has to be 'big' and the bank angle around 45degress or more?). In fact, in practice it does not play any significant role since the control loop is meant for following a constant pitch, i.e. we are aiming at a pitch rate equal to zero and it is used as a "damping term", so what is really important is the sign and not so much the magnitude (since it can be scaled by a gain).If we do aerobatics, i.e. to give a reference signal to be followed by the time derivative of the pitch, then I would say that the correct expression will play an important role. In fact I have something in mind for testing this... it is on my "to do" list for near future...I would also agree about decoupling gains, it would not be the first time that one changes one gain without thinking it also affects another one. On the other hand, one then has to take care of changing the involved gains in all the conf files :P.I just noticed (and now I understand why it is coded like this) that the "old control law" comes from the times when there were not gyros on board :P.On Sun, Sep 25, 2016 at 10:51 PM, Gautier Hattenberger wrote: 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 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 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 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 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 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 [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel -- Héctor Website: http://masteringrobotics.com _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel -- Héctor Website: http://masteringrobotics.com _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel -- Héctor Website: http://masteringrobotics.com _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel  _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel -- HéctorDrones and other stuff at my website: http://dobratech.com _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel _______________________________________________ Paparazzi-devel mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/paparazzi-devel