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 erro=
r.The difference is that now the pit=
ch rate error is calculated using a pitch rate (measured from the gyro) and=
a rate setpoint (typically zero).

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

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

<= /div>

--94eb2c14ac82758695053ca9bcd2--
From MAILER-DAEMON Sat Sep 17 02:34:42 2016
Received: from list by lists.gnu.org with archive (Exim 4.71)
id 1bl9D0-0005e8-85
for mharc-paparazzi-devel@gnu.org; Sat, 17 Sep 2016 02:34:42 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:45416)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <= /div>

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

=C2=A0=

Hi Michal,

Indeed, the=
first expression is a particular case of the second when the vehicle is fl=
ying with roll =3D 0, e.g. "following a straight line". However, =
it is also

normal to fly following circles or other cases where the aver= age of the steady-state roll is not zero.

instead of=C2=A0

<=
br>

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

should not b=
e (pseudocode) the following?

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

normal to fly following circles or other cases where the aver= age of the steady-state roll is not zero.

What do you th=
ink?

O=
n Sat, Sep 17, 2016 at 3:09 AM, Michal Podhradsky <micha=
l.podhradsky@aggiemail.usu.edu> wrote:

The proposed change follows= a solution already present in the adaptive stabilization (here)= .Dear paparazzi users,there is a proposed update in the way the fixedwing pitch control loo= p 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 difference is that now the pitch rate error is calculat= ed using a pitch rate (measured from the gyro) and a rate setpoint (typical= ly zero).The benefit of this change is that it unifies = the control loops, within paparazzi and also with standard control theory n= otation.The drawback is that the D gain currently used w= ould have to be updated using this formula (see here for details): = D_new =3D 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 cha= nge or are you OK with updating the gains (and possibly retuning the aifram= e) if it means unified and standardized control loops? Th= ank you for your feedback.M= ichal=C2=A0

_______________________________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/lis= tinfo/paparazzi- devel

=

H=C3=A9ctor

=
Website: http://=
masteringrobotics.com

ah btw,=C2=A0

I have found this change =
very appropriated too! it is better to employ an analytical expression when=
ever is possible than a numerical one.

On Sat, Sep 17, 2016 at 8:33 AM, Hector Ga=
rcia de Marina <noeth3r@gmail.com> wrote:

Hi Michal,instead of= =C2=A0float d_err =3D h_c= tl_ref.pitch_rate - stateGetBodyRates_f()->q;should not be (pseudocode) the following?float d_err =3D 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 =3D 0, e.g. "following a straight lin= e". However, it is also

normal to fly following circles or other ca= ses where the average of the steady-state roll is not zero.<= div>What do you think?On Sat, Sep 17, 2016 at 3:09 AM, Mi= chal Podhradsky <michal.podhradsky@aggiemail.usu.ed= u > wrote:=______________________________The proposed change fol= lows a solution already present in the adaptive stabilization (here<= /a>).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 (<= a href=3D"https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/fi= rmwares/fixedwing/stabilization/stabilization_attitude.c#L480" target=3D"_b= lank">see here) - the pitch rate error is calculated as a difference in= the previous and current pitch error.

=The drawback is that the D gain currently us= ed would have to be updated using this formula (see here for details): D_new =3D D_old * P_old (the old D gain wouldn't work).Since this is a change that affects multiple fixedwing airframes I w= ould 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 ai= frame) if it means unified and standardized control loops?Thank you for your feedback. Michal=C2=A0

=_________________ Paparazzi-d= evel@nongnu.org

Paparazzi-devel mailing list

https://lists.nongnu.org/mailman/lis= tinfo/paparazzi-devel

<= br clear=3D"all">--H=C3=A9cto= rWebsite: http://masteringrobotics.com

H=C3=A9ctor

We=
bsite: http://ma=
steringrobotics.com

Hi Hector,

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

I am not sure if I u= nderstand correctly your question about the non-zero roll angle. Can you el= aborate? 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 i=
s unchanged (see https://github.com/paparazzi/paparazzi/blob/master/sw/airborne/firmwa=
res/fixedwing/stabilization/stabilization_attitude.c#L476 )

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

takes care of situati= ons when your reference pitch rate is non-zero (although in most cases it w= ill be zero).

float err =3D h_ctl_ref= .pitch_angle - stateGetNedToBodyEulers_f()->theta;

Regards

Michal

On Fri, Sep 16, 2016 at 11:33 PM=
, Hector Garcia de Marina <noeth3r@gmail.com> wrote:

--94eb2c14ac82cdc770053cb77696--
From MAILER-DAEMON Sat Sep 17 13:47:00 2016
Received: from list by lists.gnu.org with archive (Exim 4.71)
id 1blJhc-0004Z2-2w
for mharc-paparazzi-devel@gnu.org; Sat, 17 Sep 2016 13:47:00 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:43819)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from Hi Michal,

normal to fly following circles or= other cases where the average of the steady-state roll is not zero.

<= div class=3D"gmail_quote">

<= br clear=3D"all">

--

_______________________________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/lis=
tinfo/paparazzi-devel

i=
nstead of=C2=A0

float d_er=
r =3D h_ctl_ref.pitch_rate - stateGetBodyRates_f()->q;

=

should not be (pseudocode) the following?

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

<=
br>

Indeed, the first expression is a particular case of the se=
cond when the vehicle is flying with roll =3D 0, e.g. "following a str=
aight 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?

<= div class=3D"gmail_quote">

On Sat, Sep 17, 2016 at 3:=
09 AM, Michal Podhradsky <michal.podhradsky@aggiemail.usu.edu > wrote:

______________________________The proposed c= hange follows a solution already present in the adaptive stabilization (here).Dear paparazzi u= sers,there is a proposed update in the way the fixedwing pitc= h control loop handles the derivative term. Currently a pseudo-derivative i= s used (see here) - the pitch rate error is calculated as a diff= erence in the previous and current pitch error.The difference is that now the pitch rate erro= r is calculated using a pitch rate (measured from the gyro) and a rate setp= oint (typically zero).The benefit of this change is tha= t it unifies the control loops, within paparazzi and also with standard con= trol theory notation.The drawback is that the D gain cur= rently used would have to be updated using this formula (see here for d= etails): D_new =3D D_old * P_old (the old D gain wouldn't work).Since this is a change that affects multiple fixedwing airf= rames I would like to know your opinion first - would you be strongly oppos= ed to the change or are you OK with updating the gains (and possibly retuni= ng the aiframe) if it means unified and standardized control loops?

=Thank you for your feedback.Michal= =C2=A0_________________

Paparazzi-devel mailing list

Paparazzi-d= evel@nongnu.org

https://lists.nongnu.org/mailman/lis= tinfo/paparazzi-devel

<= br clear=3D"all">

H=C3=A9cto=
r

Website: http://masteringrobotics.com

______________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/

Hi Michal,

<= /div>

_______________________________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/lis=
tinfo/paparazzi-devel

--

--089e0122829c54cc43053cb7a664--
From MAILER-DAEMON Sat Sep 17 19:03:44 2016
Received: from list by lists.gnu.org with archive (Exim 4.71)
id 1blOe8-0007dj-RE
for mharc-paparazzi-devel@gnu.org; Sat, 17 Sep 2016 19:03:44 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:51922)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from the correct expression for t=
he pitch rate is

\dot \theta =3D q \cos(\phi) + r =
\sin(phi),=C2=A0

where \theta is the pitch, \phi i=
s 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=C2=A0

=
in whatever physics book dealing with rigid bodies :P.

<= /div>

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

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

Cheers,

On Sat, Sep 17, 2016 at 7:32 PM, Michal Podhradsky <michal.podhradsky@aggiemail.usu.edu> wrote:

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

=The term

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

take= s care of situations when your reference pitch rate is non-zero (although i= n most cases it will be zero).

To follow non-zero pitch angle =
there is this term:

float err =3D h_ctl_ref.pitch_angle - stateGetNedToBodyEulers_f()->t=
heta;

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

=

--

_______________________________________________

Paparazzi-devel mailing list

Paparazzi-d= evel@nongnu.org

https://lists.nongnu.org/mailman/lis=
tinfo/paparazzi-devel

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Hi Hecto=
r,

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

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

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

=

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

take= s care of situations when your reference pitch rate is non-zero (although i= n most cases it will be zero).

float err =3D h_ctl_ref.

Regards

Michal

On Fri, Sep 16, 2016 at 11:33 PM, Hector Garcia de Marina <no=
eth3r@gmail.com> wrote:

Hi Michal, instead of=C2=A0

=float d_err =3D h_ctl_ref.pitch_rate - s= tateGetBodyRates_f()->q;should not be (= pseudocode) the following?float d_err =3D h_ctl_ref.pitch_rate - (q * cos(roll) - r * sin(roll) );Indeed, the fi= rst expression is a particular case of the second when the vehicle is flyin= g with roll =3D 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 =
<michal.podhradsky@aggiemail.usu.edu > wrote:

<=
/div>______________________________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 c= alculated as a difference in the previous and current pitch error.Dear paparazzi users,

<= /div>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 gy= ro) and a rate setpoint (typically zero).The benefit of= this change is that it unifies the control loops, within paparazzi and als= o 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 =3D D_old * P_old (the old D gain wou= ldn't work).Since this is a change that affects mult= iple fixedwing airframes I would like to know your opinion first - would yo= u 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 con= trol loops?Thank you for your feedback.Mic= hal=C2=A0_________________

Paparazzi-devel mailing list

Paparazzi-d= evel@nongnu.org

https://lists.nongnu.org/mailman/lis= tinfo/paparazzi-devel

=

H=C3=A9ctor

<=
div>Website: htt=
p://masteringrobotics.com

______________________________

Paparazzi-devel mailing list

Paparazzi-d= evel@nongnu.org

https://lists.nongnu.org/mailm

______________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/

=

H=C3=A9ctor

=
Website: http://=
masteringrobotics.com

Hi Hector,

hmm, if somebody mo=
re 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 t=
o be consistent with the classical control notation. On Sat, Sep 17, 2016 at 10:45 AM, =
Hector Garcia de Marina <noeth3r@gmail.com> wrote:

--

Hi Michal,

<= /div>

_______________________________________________

Paparazzi-devel mailing list

Paparazzi-d= evel@nongnu.org

https://lists.nongnu.org/mailman/lis=
tinfo/paparazzi-devel

the=
correct expression for the pitch rate is

\dot \th=
eta =3D q \cos(\phi) + r \sin(phi),=C2=A0

where \t=
heta 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 th=
is expression=C2=A0

in whatever physics book dealing with rigid b=
odies :P.

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

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

Cheers,

<= /div>

On Sat, Sep =
17, 2016 at 7:32 PM, Michal Podhradsky <michal.podhradsk=
y@aggiemail.usu.edu > wrote:

it al= lows you to follow whichever pitch angle you set as a reference.To follow non-zero pitch angle there is this term: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 an= gle or the roll rate.To clarify - the proposed change i= s only in the derivative error calculation (pitch rate), the pitch error it= self is unchanged (see https://github.com/paparazzi/paparazzi/b= lob/master/sw/airbor )ne/firmwares/fixedwing/stabili zation/stabiliz= ation_attitude. c#L476 The term

float d_err =3D h_ctl_ref.pitch_rate - stateGetBod= yRates_f()->q;

takes care of situations when your refe= rence pitch rate is non-zero (although in most cases it will be zero).

<= br>

float err =3D h_ctl_ref.pitch_angle - state= GetNedToBodyEulers_f()->theta; Regards=Michal<= div>On Fri, Sep 1= 6, 2016 at 11:33 PM, Hector Garcia de Marina <noeth3r@gmail.com> wrote:Hi Michal,<= div>instead of=C2=A0float d_err =3D h_ctl_ref.pitch_rate - stateGetBodyRates_f()->= q;should not be (pseudocode) the following= ?float d_err =3D h_ctl_re= f.pitch_rate - (q * cos(roll) - r * sin(roll) );Indeed, the first expression is a parti= cular case of the second when the vehicle is flying with roll =3D 0, e.g. &= quot;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, 2= 016 at 3:09 AM, Michal Podhradsky <michal.podhradsky@agg= iemail.usu.edu > wrote:______________________________The proposed chan= ge follows a solution already present in the adaptive stabilization (here).Dear paparazzi user= s,there is a proposed update in the way the fixedwing pitch c= ontrol loop handles the derivative term. Currently a pseudo-derivative is u= sed (see here) - the pitch rate error is calculated as a differe= nce in the previous and current pitch error.The difference is that now the pitch rate error i= s calculated using a pitch rate (measured from the gyro) and a rate setpoin= t (typically zero).The benefit of this change is that i= t unifies the control loops, within paparazzi and also with standard contro= l theory notation.The drawback is that the D gain curren= tly used would have to be updated using this formula (see here for deta= ils): D_new =3D D_old * P_old (the old D gain wouldn't work).Since this is a change that affects multiple fixedwing airfram= es 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=C2= =A0_________________

Paparazzi-devel mailing list

Paparazzi-d= evel@nongnu.org

https://lists.nongnu.org/mailman/lis= tinfo/paparazzi-devel

=--H=C3=A9ctor<= div>Website: htt= p://masteringrobotics.com

______________________________

Paparazzi-devel mailing list

Paparazzi-d= evel@nongnu.org

https://lists.nongnu.org/mailman/lis= tinfo/paparazzi-devel

______________________________

Paparazzi-devel mailing list

Paparazzi-d= evel@nongnu.org

https://lists.nongnu.org/mailm

H=C3=A9ctor

Website: http://masteringrobotics.com<=
/div>

______________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/

--94eb2c0912d0bef090053cbc16a8-- From MAILER-DAEMON Sun Sep 18 03:07:26 2016 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1blWCE-0005QD-Tg for mharc-paparazzi-devel@gnu.org; Sun, 18 Sep 2016 03:07:26 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from

Hi Michal,

what do you mean by classica=
l 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 t=
he same book in page 293, "The effects of pitch-rate and AoA feedback&=
quot; or page 327, "Autopilot Pitch-attitude hold" the discussion=
I was posting about. For nominal flight conditions or

wings-leve=
l flight, then it is ok to approximate the pitch rate \dot\theta by just &#=
39;q'. But this is only for the design of the control loop, i.e. to cal=
culate the gains off-line, under such assumption.

=
However, in the actual system you have to feed your controller with the cor=
rect physical quantities, e.g. the correct pitch-rate and not its approxima=
tion, 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 (Pitc=
h-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). Otherwi=
se, we are controlling a different physical thing (this is what is happenin=
g now in the code by putting just 'q' in the code as pitch-rate).

_______________________________________________

Paparazzi-devel mailing list

Paparazzi-d= evel@nongnu.org

https://lists.nongnu.org/mailman/lis=
tinfo/paparazzi-devel

- This is not about software, it is just physical/m=
athematical fact :P.

Of course, I do not want &quo=
t;to impose" anything in your code. In the end if the user is happy wi=
th the performance of the actual flight then this is what really matters. O=
n 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 cod=
e works (but expectedly worse) in practice from a control-theory point of v=
iew, but I would say this is beyond the scope by now xD.

Cheers.

On Sun, Sep 18, 2016 at 1:03 AM, Michal Podhradsky <michal.podhradsky@aggiemail.usu.edu> wrote:

M

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. =

Regardshmm, 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. =

<=
div>

<=
div class=3D"h5">

--

=
On Sat, Sep 17, 2016 at 10:45 AM, Hector Garcia de Marina <noeth3r@gmail.c=
om> wrote:

Hi Michal,the correct expression for the pitch rate is=\dot \theta =3D q \cos(\phi) + r \sin(phi),=C2=A0=where \theta is the pitch, \phi is the roll and &= #39;pqr' are the three angular rates at the body frame, i.e. the readin= gs of the gyros. One can verify this expression=C2=A0in whatever= physics book dealing with rigid bodies :P.Indeed= , if the roll angle is close to zero, then we can approximate the pitch rat= e to just sensor reading 'q'. On the other hand, in situations such= as followinga circular pattern the roll angle is "far"= ; from zero. Furthermore, if we also have an action on the rudder, e.g. a c= oordinated turn, then 'r' will be also different from zero. Cheers,On Sat, Sep 17, 2016 at 7:32 PM, Michal Podhradsky <michal.podhradsky@aggiemail.usu.edu > wrote: it allows you to follow whichever pitch angle you set as a = reference.Hi Hector,<= br>

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 i= n 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/papar= azzi/paparazzi/blob/master/sw/airbor )ne/firmwares/fixedwing/stabil= i zation/stabilization_attitude. c#L476 To follow non-zero pitch angle there is this = term:

The term

float d_err =3D h_ctl_ref.pit= ch_rate - stateGetBodyRates_f()->q;

takes care of situ= ations when your reference pitch rate is non-zero (although in most cases i= t will be zero).

float err =3D h_ctl_ref.pitch_angle= - stateGetNedToBodyEulers_f()->theta; RegardsMichalOn Fri, Sep 16, 2016 at 11:33 PM, Hector Garcia de Marina <noeth3r= @gmail.com> wrote:Hi Michal,instead of=C2=A0float d_err =3D h_ctl_ref.pitch_rate - stateG= etBodyRates_f()->q;should not be (pseud= ocode) the following?floa= t d_err =3D h_ctl_ref.pitch_rate - (q * cos(roll) - r * sin(roll) );=Indeed, the first e= xpression is a particular case of the second when the vehicle is flying wit= h roll =3D 0, e.g. "following a straight line". However, it is al= so

normal to fly following circles or other cases where the average of t= he steady-state roll is not zero.What do you think?=On Sat, Sep 17, 2016 at 3:09 AM, Michal Podhradsky <<= a href=3D"mailto:michal.podhradsky@aggiemail.usu.edu" target=3D"_blank">mic= hal.podhradsky@aggiemail.usu.edu> wrote:______________________________= The proposed change follows a solution already present in the adaptive stab= ilization (here).De= ar paparazzi users,there is a proposed update in the way the = fixedwing pitch control loop handles the derivative term. Currently a pseud= o-derivative is used (see here) - the pitch rate error is calcul= ated as a difference in the previous and current pitch error.The difference is that now the p= itch rate error is calculated using a pitch rate (measured from the gyro) a= nd a rate setpoint (typically zero).The benefit of this= change is that it unifies the control loops, within paparazzi and also wit= h 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 =3D D_old * P_old (the old D gain wouldn&#= 39;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 p= ossibly retuning the aiframe) if it means unified and standardized control = loops?Thank you for your feedback.Michal=C2=A0

Paparazzi-devel mailing list

Paparazzi-d= evel@nongnu.org

https://lists.nongnu.org/mailman/lis= tinfo/paparazzi-devel

=--H=C3=A9ctor<= div>Website: htt= p://masteringrobotics.com

______________________________

Paparazzi-devel mailing list

Paparazzi-d= evel@nongnu.org

https://lists.nongnu.org/mailman/lis= tinfo/paparazzi-devel

______________________________

Paparazzi-devel mailing list

Paparazzi-d= evel@nongnu.org

https://lists.nongnu.org/mailman/lis= tinfo/paparazzi-devel

H=C3=A9ctor

Website: http://masteringrobotics.com<=
/div>

______________________________

Paparazzi-devel mailing list

Paparazzi-d= evel@nongnu.org

https://lists.nongnu.org/mailm

______________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/

=

H=C3=A9ctor

=
Website: http://=
masteringrobotics.com

With that usb telemetry=
should work on Elle0

Cheers, FelixOn Sun, Aug 14, 2016 at 2:04 PM, S=
imon Liebold <simon.liebold@formfall.de> wrote:

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> =20 =20 =20

h= ttps://goo.gl/photos/eQMFsmEaMmakLXSW9

But still, the successful*test_sys_time_timer* suggests that
the Elle0 is not yet ready for the electronics bin. This is a good
thing.

Thanks for the support Felix. I will try a few other things.

Simon

_______________________________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/lis=
tinfo/paparazzi-devel

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> =20 =20 =20

Hi Felix,

Am 13.08.2016 um 21:13 schrieb Felix Ruess:

Am 13.08.2016 um 21:13 schrieb Felix Ruess:

OK, this works for me.test_sys_time_timer will blink set up timers to blink LEDs, ...

h= ttps://goo.gl/photos/

No joy here. It doesn't detect anything if I power up the Elle0 before plugging in the USB.usb_tunnel makes a tunnel between one uart and usb (which can e.g. also be used to configure a GPS through USB).

But still, the successful

Thanks for the support Felix. I will try a few other things.

Simon

______________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/

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 orwings-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-ratefor design purposeswhere 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 <michal.podhradsky@aggiemail.usu.edu> wrote:

MRegardsHi 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.

On Sat, Sep 17, 2016 at 10:45 AM, Hector Garcia de Marina <noeth3r@gmail.com> 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 expressionin 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 followinga 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 <michal.podhradsky@aggiemail.usu.edu > wrote:

it allows you to follow whichever pitch angle you set as a reference.To follow non-zero pitch angle there is this term: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/airbor )ne/firmwares/fixedwing/stabili zation/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).

float err = h_ctl_ref.pitch_angle - stateGetNedToBodyEulers_f()->theta;

Regards

Michal

On Fri, Sep 16, 2016 at 11:33 PM, Hector Garcia de Marina <noeth3r@gmail.com> 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 <michal.podhradsky@aggiemail.usu.edu > wrote:

______________________________The proposed change follows a solution already present in the adaptive stabilization (here).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 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

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

--

Héctor

Website: http://masteringrobotics.com

_______________________________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

--

Héctor

Website: http://masteringrobotics.com

______________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/listinfo/paparazzi- devel

--

Héctor

Website: http://masteringrobotics.com

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

--------------75DF32AE91FBE13DEF05AC3C-- From MAILER-DAEMON Sun Sep 25 17:22:00 2016 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1boGs4-000370-OU for mharc-paparazzi-devel@gnu.org; Sun, 25 Sep 2016 17:22:00 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46578) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from

Hello,

<= /div>

--

--94eb2c1935a605b86b053d5b963c--
From MAILER-DAEMON Mon Sep 26 23:35:26 2016
Received: from list by lists.gnu.org with archive (Exim 4.71)
id 1bojB0-0001Tn-Pw
for mharc-paparazzi-devel@gnu.org; Mon, 26 Sep 2016 23:35:26 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55931)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from )
id 1bojAw-0001So-7Q
for paparazzi-devel@nongnu.org; Mon, 26 Sep 2016 23:35:25 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from )
id 1bojAs-0004h4-J1
for paparazzi-devel@nongnu.org; Mon, 26 Sep 2016 23:35:22 -0400
Received: from mail-ua0-x233.google.com ([2607:f8b0:400c:c08::233]:34416)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from )
id 1bojAr-0004Fx-W4
for paparazzi-devel@nongnu.org; Mon, 26 Sep 2016 23:35:18 -0400
Received: by mail-ua0-x233.google.com with SMTP id u68so1087003uau.1
for ; Mon, 26 Sep 2016 20:34:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=aggiemail.usu.edu; s=google;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=mnxsbwOT+xx9rsycnLej+6kdtTFd/1w+AsNzRo3MG5I=;
b=O1EoB53rBCl560K+eLJRbIZPDaxbpwNERk4ocSrzuysIGJGbsBo5M7I5lEGO/DCUA6
CSeyNaGCojJxs9a+T9MWp1rZ/IxuilX4BbMcs9L2Oqha/ITAkbkIHrkjeMqkWD1VLucl
OaAu0hVW7Z6ZMBrP3Lzk3afq9aeOX9nfOVBKM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=mnxsbwOT+xx9rsycnLej+6kdtTFd/1w+AsNzRo3MG5I=;
b=fTquRCjQXFBz+skrer+paAxB+uia21DumtLQu1hfxQNnwCUy5JldLG6SbXmr30wfh1
yEv2uAUVoDfHGCdqUBN8p5K3Bo/KhfDoEN6YQoAvu6/3vIc5sZuAOCQxWvKfXS35O7yF
4tvhwkRoz83M1RUtUco33ASmyV6dJgBaqdE6MNI/VTc+FraFz06bxTH2irhGi7vosPdW
o5KENQAb62IV1xIUD+9vvRnU2jC4HWYdSLFshvNL/fbeIgVuAgJkmRn63r1c3HMNZfYa
1JhHpuxbI//ywdcsMaM7dicIorrNCJkPvd1zl1KT6+LQZ0wSPrStcWwQk4DeZ6kzoysZ
znSw==
X-Gm-Message-State: AA6/9Rmwrzi/gfvVFQ7k3Jk1FHHx/Ep28pcC2ch94rhU9y/Ek8JnNKnuMhSPGUkygL6lqOu5HMFa3vXo5kIN8Rqf
X-Received: by 10.176.84.7 with SMTP id n7mr1135958uaa.117.1474947295535; Mon,
26 Sep 2016 20:34:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.5.33 with HTTP; Mon, 26 Sep 2016 20:34:54 -0700 (PDT)
In-Reply-To:
References:
<912c7b64-dd5c-fb82-9de1-e23102fc2ee1@gmail.com>
From: Michal Podhradsky
Date: Mon, 26 Sep 2016 20:34:54 -0700
Message-ID:
To: Paparazzi UAV devel list
Content-Type: multipart/alternative; boundary=94eb2c1b047c9cf4f0053d74ed6a
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2607:f8b0:400c:c08::233
Subject: Re: [Paparazzi-devel] Proposed update in the fixedwing pitch
control loop
X-BeenThere: paparazzi-devel@nongnu.org
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: Paparazzi UAV devel list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 27 Sep 2016 03:35:25 -0000
--94eb2c1b047c9cf4f0053d74ed6a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 =3D D_old * P_old?
Regards
Michal
On 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 pit=
ch
> 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 scal=
ed
> by a gain).
>
> If we do aerobatics, i.e. to give a reference signal to be followed by th=
e
> time derivative of the pitch, then I would say that the correct expressio=
n
> 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. O=
n
> 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 <
> gautier.hattenberger@gmail.com> 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 o=
nly
>> 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 =3D P * (err + D * d_err)
>>
>> to
>>
>> u =3D P * err + D * d_err
>>
>> There is already a discussion opened in https://github.com/paparazzi/p
>> aparazzi/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 =C3=A0 09:06, Hector Garcia de Marina a =C3=A9crit :
>>
>> Hi Michal,
>>
>> what do you mean by classical control notation? do you have any referenc=
e
>> about it?
>>
>> The expression what I have posted can also be found in control books suc=
h
>> 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 aircra=
ft).
>>
>> - An error signal always has to be computed correctly. If we are
>> controlling the pitch-rate, then we have to provide the correct expressi=
on
>> (and not an approximation). Otherwise, we are controlling a different
>> physical thing (this is what is happening now in the code by putting jus=
t
>> '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 i=
f
>> 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 <
>> michal.podhradsky@aggiemail.usu.edu> 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 ch=
ange
>>> the derivative term to be consistent with the classical control notatio=
n.
>>>
>>> Regards
>>> M
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Sep 17, 2016 at 10:45 AM, Hector Garcia de Marina <
>>> noeth3r@gmail.com> wrote:
>>>
>>>> Hi Michal,
>>>>
>>>> the correct expression for the pitch rate is
>>>>
>>>> \dot \theta =3D 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 c=
an
>>>> 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 th=
e
>>>> pitch rate to just sensor reading 'q'. On the other hand, in situation=
s
>>>> 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 <
>>>> michal.podhradsky@aggiemail.usu.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/airbor
>>>>> ne/firmwares/fixedwing/stabilization/stabilization_attitude.c#L476 )
>>>>>
>>>>> The term
>>>>> float d_err =3D 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 =3D h_ctl_ref.pitch_angle - stateGetNedToBodyEulers_f()->t
>>>>> heta;
>>>>> 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 <
>>>>> noeth3r@gmail.com> wrote:
>>>>>
>>>>>> Hi Michal,
>>>>>>
>>>>>> instead of
>>>>>>
>>>>>> float d_err =3D h_ctl_ref.pitch_rate - stateGetBodyRates_f()->q;
>>>>>>
>>>>>> should not be (pseudocode) the following?
>>>>>>
>>>>>> float d_err =3D 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 =3D 0, e.g. "following a straight li=
ne".
>>>>>> 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 <
>>>>>> michal.podhradsky@aggiemail.usu.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 previou=
s 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 (typicall=
y 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 =3D D_ol=
d
>>>>>>> * 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 oppos=
ed to
>>>>>>> the change or are you OK with updating the gains (and possibly retu=
ning the
>>>>>>> aiframe) if it means unified and standardized control loops?
>>>>>>>
>>>>>>> Thank you for your feedback.
>>>>>>> Michal
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Paparazzi-devel mailing list
>>>>>>> Paparazzi-devel@nongnu.org
>>>>>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> H=C3=A9ctor
>>>>>>
>>>>>> Website: http://masteringrobotics.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> Paparazzi-devel mailing list
>>>>>> Paparazzi-devel@nongnu.org
>>>>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Paparazzi-devel mailing list
>>>>> Paparazzi-devel@nongnu.org
>>>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> H=C3=A9ctor
>>>>
>>>> Website: http://masteringrobotics.com
>>>>
>>>> _______________________________________________
>>>> Paparazzi-devel mailing list
>>>> Paparazzi-devel@nongnu.org
>>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Paparazzi-devel mailing list
>>> Paparazzi-devel@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>
>>>
>>
>>
>> --
>> H=C3=A9ctor
>>
>> Website: http://masteringrobotics.com
>>
>>
>> _______________________________________________
>> Paparazzi-devel mailing listPaparazzi-devel@nongnu.orghttps://lists.nong=
nu.org/mailman/listinfo/paparazzi-devel
>>
>>
>>
>> _______________________________________________
>> Paparazzi-devel mailing list
>> Paparazzi-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>>
>
>
> --
> H=C3=A9ctor
>
> Drones and other stuff at my website: http://d
> obratech.com
>
> _______________________________________________
> Paparazzi-devel mailing list
> Paparazzi-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
>
--94eb2c1b047c9cf4f0053d74ed6a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Regards

Michal

indeed, the numerical difference=
is very small (for noticing the error, the 'p' has to be 'big&=
#39; 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 fol=
lowing a constant pitch, i.e. we are aiming at a pitch rate equal to zero a=
nd 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 sig=
nal to be followed by the time derivative of the pitch, then I would say th=
at the correct expression will play an important role. In fact I have somet=
hing in mind for testing this... it is on my "to do" list for nea=
r future...

I would also agree about decoupling ga=
ins, it would not be the first time that one changes one gain without think=
ing it also affects another one. On the other hand, one then has to take ca=
re of changing the involved gains in all the conf files :P.

<= /div>

I just noticed (and now I understand why it is coded like this) t=
hat the "old control law" comes from the times when there were no=
t gyros on board :P.

On Sun, Sep 25, 2016 at 10:51 =
PM, Gautier Hattenberger <gautier.hattenberger@gmail.com&=
gt; wrote:

=20 =20 =20Hi,

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 =3D P * (err + D * d_err)

to

u =3D P * err + D * d_err

There is already a discussion opened in https://github.com/paparazzi/

paparazzi/pull/1658 but n= ot 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 b= y q (or a more complete equation). You also need to compensate by the control time step.

Gautier

Le 18/09/2016 =C3=A0 09:06, Hector Garcia de Marina a =C3=A9crit=C2=A0:

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 po= sting about. For nominal flight conditions orwings-level flight, then it is ok to approximate the pitch rate \dot\theta by just 'q'. But this is only for the des= ign 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-ratefor design purposeswhere 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 you= r 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 <michal.podhradsky@aggiemail.u= su.edu > wrote:

MRegardsHi 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.

On Sat, Sep 17, 2016 at 10:45 AM, Hector Garcia de Marina <noeth3r@gmail.com>= wrote:

Hi Michal,

the correct expression for the pitch rate is

\dot \theta =3D q \cos(\phi) + r \sin(phi),=C2= =A0

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=C2=A0in 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 followinga 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 <michal.podhradsky@aggiemail.usu.edu > wrote:

it allows you to follow whichever pitch angle you set as a reference.To follow non-zero pitch angle there is this term: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/airbor )ne/firmwares/fixedwing/s= tabili zation/stabilization_attitude. c#L476

The term =

float d_err =3D h_ctl_ref.pitch_rate - stateGetBodyRates_f()->q;<= /span>

takes care of situations when your reference pitch rate is non-zero (although in most cases it will be zero).

float err =3D h_ctl_ref.pitch_angle - stateGetNedToBodyEulers= _f()->theta;

Regards

Michal

On Fri, Sep 16, 2016 at 11:33 PM, Hector Garcia de Marina <noeth3r= @gmail.com> wrote:

Hi Michal,

instead of=C2=A0

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

should not be (pseudocode) the following?

= float d_err =3D 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 =3D 0, e.g. "follow= ing a straight line". Howeve= r, 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 <michal.podhradsky@aggiemail.usu.edu > wrote:

______________________________The proposed change follows a solution already present in the adaptive stabilization (here)= .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 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 =3D 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

=C2=A0

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

--

= H=C3=A9ctor

Website: http://masteringrobotics.com<= /div>

______________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

____________________________________= ___________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://l= ists.nongnu.org/mailman/listinfo/paparazzi-devel

--

H=C3=A9ctor

Website: http://masteringrobotics.com

_______________________________________________<= br> Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.= org/mailman/listinfo/paparazzi-devel

_______________________________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailm<= wbr>an/listinfo/paparazzi-devel

--

H=C3=A9ctor

Website: http://masteringrobotics.com

_______________________________________________ Paparazzi-devel mailing list Paparazzi-d= evel@nongnu.org https://lists.nongnu.org/ mailman/listinfo/paparazzi- = devel

_______________________________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/lis= tinfo/paparazzi- devel

=

H=C3=A9ct=
or

Drones and other stuff at my website: http://dobratech.com

Thanks to Gautier for explaining my intenti=
ons better. Hector, I finally got hands on the book you mentioned - but imp=
lementing it would be a different story.

Should I understand i=
t that there is consensus on changing the controller structure as Gautier d=
escribed + updating the D gains for affected airfames as: D_new =3D D_old *=
P_old?On Sun, Sep 25, 2016 at 2:20 PM, Hecto=
r Garcia de Marina <noeth3r@gmail.com> wrote:

Hello,

--

_______________________________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/lis=
tinfo/paparazzi-devel

--94eb2c1b047c9cf4f0053d74ed6a--
From MAILER-DAEMON Tue Sep 27 04:01:42 2016
Received: from list by lists.gnu.org with archive (Exim 4.71)
id 1bonKg-0008Mo-RB
for mharc-paparazzi-devel@gnu.org; Tue, 27 Sep 2016 04:01:42 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:48892)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from ) id 1bonKY-0008LZ-Dz
for paparazzi-devel@nongnu.org; Tue, 27 Sep 2016 04:01:41 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from ) id 1bonKS-0002pe-SU
for paparazzi-devel@nongnu.org; Tue, 27 Sep 2016 04:01:34 -0400
Received: from mail-qt0-x233.google.com ([2607:f8b0:400d:c0d::233]:35415)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from ) id 1bonKS-0002g5-CQ
for paparazzi-devel@nongnu.org; Tue, 27 Sep 2016 04:01:28 -0400
Received: by mail-qt0-x233.google.com with SMTP id t63so456046qtd.2
for ; Tue, 27 Sep 2016 01:01:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=vHDzhWQCBrtPviXt5kcj3dPLuiKCWHHnO+o4hdgvqgY=;
b=vgtHf0k4a1JL7WCADTqLvGbKpGTGbiN5fIa4VAHYfOXy+/W86MYuFPykpYGAdUP8vV
8JLuPctAeiipUdsm2qUuvl9NIbL0OMJRm0V1QbaEAZf+X5uKqLpCQzApZTe0ZGbBrBlS
JlNcjJtawDuAw+buDT3TdL51yTMkGxTQYvkGLyWwnUSNzE9/45bjCfl0/FYCmI13memS
lRcCJ8FRHL9C934hvnOiWiKgNUjGJ3sYFE3izorLqxuNHUEmPV66rJIgZk1ZWTVpN/+G
v0DzK1ciQiANiaHftMlyWHe6QALhcVOXrOKPBH4uq12TLdDIGJEmXkIhTJZbSVuFYPxm
H9mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=vHDzhWQCBrtPviXt5kcj3dPLuiKCWHHnO+o4hdgvqgY=;
b=HN3daFAYDXFOrgSpDDjAQNERiIw3nn4euj2p9R8GVG4IsVW3kBpRVxvbV4pKyIQaIe
738Aja6rfY+DmnNWOVjRPdZoqiYiH+WIX3JuXdPJtKWZP6is78chy+QciAL/GxHguzNZ
er/OCZWpa8bEEQMXTNnHGO0GmYIoQyMvY/fxkD7cvviE3sBdmQBT91pQJLP3p2BZMgUk
uzXtdPcW/tLjS7IUbIAaq/EyCsdSSl251iKEULqDDt1/ujqHXhR7AsWVVWzfv7xAotjb
GWzegEhvbtNE60QQBUptZRuNWMF0L/+WyONw//l/1hKQzNanAgnN1W79Mub3KoXgsXfs
vt6A==
X-Gm-Message-State: AA6/9Rm5R9KoF2Bqj/Zd1kGGEilgfDixPzV9cmBSaQqjtny0H+RVcfHscNhPYZLGjCdyKN+cNc4DNr4RKxMMGA==
X-Received: by 10.28.198.130 with SMTP id w124mr1627790wmf.67.1474963265817;
Tue, 27 Sep 2016 01:01:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.145.139 with HTTP; Tue, 27 Sep 2016 01:01:05 -0700 (PDT)
Received: by 10.28.145.139 with HTTP; Tue, 27 Sep 2016 01:01:05 -0700 (PDT)
In-Reply-To:
References:
<912c7b64-dd5c-fb82-9de1-e23102fc2ee1@gmail.com>
From: Hector Garcia de Marina
Date: Tue, 27 Sep 2016 10:01:05 +0200
Message-ID:
To: Paparazzi UAV devel list
Content-Type: multipart/alternative; boundary=94eb2c19419e841267053d78a549
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2607:f8b0:400d:c0d::233
Subject: Re: [Paparazzi-devel] Proposed update in the fixedwing pitch
control loop
X-BeenThere: paparazzi-devel@nongnu.org
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: Paparazzi UAV devel list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 27 Sep 2016 08:01:41 -0000
--94eb2c19419e841267053d78a549
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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" <
michal.podhradsky@aggiemail.usu.edu> 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 airfam=
es
> as: D_new =3D D_old * P_old?
>
> Regards
> Michal
>
> On Sun, Sep 25, 2016 at 2:20 PM, Hector Garcia de Marina <
> noeth3r@gmail.com> 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?). I=
n
>> fact, in practice it does not play any significant role since the contro=
l
>> loop is meant for following a constant pitch, i.e. we are aiming at a pi=
tch
>> 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 sca=
led
>> 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 tim=
e
>> 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 boar=
d
>> :P.
>>
>>
>>
>> On Sun, Sep 25, 2016 at 10:51 PM, Gautier Hattenberger <
>> gautier.hattenberger@gmail.com> 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 o=
f
>>> 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 wit=
h
>>> the P factor. So I guess the idea is to change the structure of control
>>> loop from
>>>
>>> u =3D P * (err + D * d_err)
>>>
>>> to
>>>
>>> u =3D P * err + D * d_err
>>>
>>> There is already a discussion opened in https://github.com/paparazzi/p
>>> aparazzi/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 =C3=A0 09:06, Hector Garcia de Marina a =C3=A9crit :
>>>
>>> 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 Le=
wis.
>>> 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 hol=
d"
>>> 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 express=
ion
>>> (and not an approximation). Otherwise, we are controlling a different
>>> physical thing (this is what is happening now in the code by putting ju=
st
>>> '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 thi=
s 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 <
>>> michal.podhradsky@aggiemail.usu.edu> wrote:
>>>
>>>> Hi Hector,
>>>>
>>>> hmm, if somebody more knowledgeable wants to make such a change then i=
t
>>>> probably should go in a different pull-request. For now I would only c=
hange
>>>> the derivative term to be consistent with the classical control notati=
on.
>>>>
>>>> Regards
>>>> M
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Sep 17, 2016 at 10:45 AM, Hector Garcia de Marina <
>>>> noeth3r@gmail.com> wrote:
>>>>
>>>>> Hi Michal,
>>>>>
>>>>> the correct expression for the pitch rate is
>>>>>
>>>>> \dot \theta =3D 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 situ=
ations
>>>>> 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 <
>>>>> michal.podhradsky@aggiemail.usu.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/airbor
>>>>>> ne/firmwares/fixedwing/stabilization/stabilization_attitude.c#L476 )
>>>>>>
>>>>>> The term
>>>>>> float d_err =3D 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 =3D h_ctl_ref.pitch_angle - stateGetNedToBodyEulers_f()->t
>>>>>> heta;
>>>>>> 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 <
>>>>>> noeth3r@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Michal,
>>>>>>>
>>>>>>> instead of
>>>>>>>
>>>>>>> float d_err =3D h_ctl_ref.pitch_rate - stateGetBodyRates_f()->q;
>>>>>>>
>>>>>>> should not be (pseudocode) the following?
>>>>>>>
>>>>>>> float d_err =3D h_ctl_ref.pitch_rate - (q * cos(roll) - r * sin(rol=
l)
>>>>>>> );
>>>>>>>
>>>>>>> Indeed, the first expression is a particular case of the second whe=
n
>>>>>>> the vehicle is flying with roll =3D 0, e.g. "following a straight l=
ine".
>>>>>>> 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 <
>>>>>>> michal.podhradsky@aggiemail.usu.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 previo=
us 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 usin=
g
>>>>>>>> a pitch rate (measured from the gyro) and a rate setpoint (typical=
ly 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 =3D D_o=
ld
>>>>>>>> * 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 oppo=
sed to
>>>>>>>> the change or are you OK with updating the gains (and possibly ret=
uning the
>>>>>>>> aiframe) if it means unified and standardized control loops?
>>>>>>>>
>>>>>>>> Thank you for your feedback.
>>>>>>>> Michal
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Paparazzi-devel mailing list
>>>>>>>> Paparazzi-devel@nongnu.org
>>>>>>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> H=C3=A9ctor
>>>>>>>
>>>>>>> Website: http://masteringrobotics.com
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Paparazzi-devel mailing list
>>>>>>> Paparazzi-devel@nongnu.org
>>>>>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Paparazzi-devel mailing list
>>>>>> Paparazzi-devel@nongnu.org
>>>>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> H=C3=A9ctor
>>>>>
>>>>> Website: http://masteringrobotics.com
>>>>>
>>>>> _______________________________________________
>>>>> Paparazzi-devel mailing list
>>>>> Paparazzi-devel@nongnu.org
>>>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Paparazzi-devel mailing list
>>>> Paparazzi-devel@nongnu.org
>>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>>
>>>>
>>>
>>>
>>> --
>>> H=C3=A9ctor
>>>
>>> Website: http://masteringrobotics.com
>>>
>>>
>>> _______________________________________________
>>> Paparazzi-devel mailing listPaparazzi-devel@nongnu.orghttps://lists.non=
gnu.org/mailman/listinfo/paparazzi-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> Paparazzi-devel mailing list
>>> Paparazzi-devel@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>>
>>>
>>
>>
>> --
>> H=C3=A9ctor
>>
>> Drones and other stuff at my website: http://d
>> obratech.com
>>
>> _______________________________________________
>> Paparazzi-devel mailing list
>> Paparazzi-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>>
>>
>
> _______________________________________________
> Paparazzi-devel mailing list
> Paparazzi-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
>
>
--94eb2c19419e841267053d78a549
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

_______________________________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/lis=
tinfo/paparazzi-devel

--94eb2c19419e841267053d78a549--
From MAILER-DAEMON Tue Sep 27 17:23:25 2016
Received: from list by lists.gnu.org with archive (Exim 4.71)
id 1bozqX-0002He-Hg
for mharc-paparazzi-devel@gnu.org; Tue, 27 Sep 2016 17:23:25 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:52109)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from ) id 1bozqU-0002Fo-27
for paparazzi-devel@nongnu.org; Tue, 27 Sep 2016 17:23:23 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from ) id 1bozqP-0007s3-TO
for paparazzi-devel@nongnu.org; Tue, 27 Sep 2016 17:23:21 -0400
Received: from mail-wm0-x243.google.com ([2a00:1450:400c:c09::243]:34598)
by eggs.gnu.org with esmtp (Exim 4.71)
(envelope-from ) id 1bozqP-0007r5-MH
for paparazzi-devel@nongnu.org; Tue, 27 Sep 2016 17:23:17 -0400
Received: by mail-wm0-x243.google.com with SMTP id l132so3003533wmf.1
for ; Tue, 27 Sep 2016 14:23:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=to:from:subject:message-id:date:user-agent:mime-version
:content-transfer-encoding;
bh=KRO3pbaUnbMGUQUvexLd/EKw6mLntAq5E6wbbOUy390=;
b=SRs+YPtiboqTCwHGGjeAI7f9PyrbEP171hceAIstqG+H4U9ls6H76gACK2SBkpLR9C
O5AaIT7EdVIgk7/yVHxnE7A9AUn2dQ3gebjgKUEhxQV1Zsts4YMF+je01Yu30RJ038hm
8CLWjp/JtVefJqa8F0S4ULZaoS7l6R88n0XNbbuHj6AWLkcudR2o3Tlw0CY3CSrNj+CH
XW0+FJ0mirz2mGPyG7964BIQFfXurG35CoJZKlEH+tHJf23PE+rsKVs/fSGTtfxytGhb
7FF7zpMPktrtWoUYFkmgPE2YI1LEdjZiJdVXZUB2SsUDOd6y+0tERTbIQbVGg5/kitv6
froQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:to:from:subject:message-id:date:user-agent
:mime-version:content-transfer-encoding;
bh=KRO3pbaUnbMGUQUvexLd/EKw6mLntAq5E6wbbOUy390=;
b=mV1r31CbIUQBTcJ3RJ9aiJj9zvXMOnANNSsStvMH92Z6ntWEg1YxTyUZiO99kky8yR
kIWkki2khC3RO1yMeh0HRzgydeYy3q4XphUypVaol5LwUtKiT6CR0yYttnrepfZBZCPb
44YAzMeh8VwLZntNQ+/Dr6PjL/6IHs9JLQVrcyM0IVbApS5boX+CAlDtCaDBCqeHrgXb
1P4kXAOJc+0dBHrcP4uaEZzUkuKFekatxz3IH0NNmTDgi+fpCeyHmnPWQhffPja0xx96
8eo34BbRyqPKknp6wVlj0S5HVenkEEkuSOJXFFRXe0K31FI3jjroSMmFqDRqDWKwpxdk
yrow==
X-Gm-Message-State: AA6/9RlP/tTzCawtbL/B/bwJJm8lE4LccmYX8W9ldp1HRDSllFiq3+pBBcLb17jpGvwEkA==
X-Received: by 10.28.187.4 with SMTP id l4mr4656517wmf.124.1475011396599;
Tue, 27 Sep 2016 14:23:16 -0700 (PDT)
Received: from [192.168.1.27] (AToulouse-553-1-168-36.w92-156.abo.wanadoo.fr.
[92.156.232.36]) by smtp.googlemail.com with ESMTPSA id
142sm5100141wmh.12.2016.09.27.14.23.15
for
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 27 Sep 2016 14:23:16 -0700 (PDT)
To: Paparazzi
From: Gautier Hattenberger
Message-ID:
Date: Tue, 27 Sep 2016 23:23:15 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2a00:1450:400c:c09::243
Subject: [Paparazzi-devel] Stable release v5.10
X-BeenThere: paparazzi-devel@nongnu.org
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: Paparazzi UAV devel list
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 27 Sep 2016 21:23:23 -0000
Dear Paparazzi community,
We are pleased to announce that the new stable release of Paparazzi,
numbered v5.10, is out!
The "stabilization" have been very short, but as said in a previous
mail, the master branch already had many new features and haven't moved
a lot during the past weeks.
The most important changes of this version are:
- many conversion of subsystems to modules, which means in
particular a better generated documentation
http://docs.paparazziuav.org/latest/onboard_modules.html
- a full implementation of an architecture based on ChibiOS,
allowing better integration of threaded code for STM32-based boards
- many improvements and additions to the computer vision
algorithms, especially on Linux-based systems
As usual, the complete change log can be found on Github:
https://github.com/paparazzi/paparazzi/blob/v5.10/CHANGELOG.md
This version should also be the last one to support the backward
compatibility with "susbsystems" as we are almost done converting
everything to modules.
I wish the best luck to Paparazzi teams involved in competitions,
especially Mavlab from TUDelft!
Gautier for the Paparazzi UAV team

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 l=
oop 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 b=
e 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 d=
o" list for near future...

I would also agree=
about decoupling gains, it would not be the first time that one changes on=
e 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 i=
s coded like this) that the "old control law" comes from the time=
s when there were not gyros on board :P.

On Sun, Sep 25, 2016 at 10:51 PM, Gautier Hattenberger <gautier.hattenberger@gmail.com > wrote:

=20
=20
=20

_______________________________________________

Paparazzi-devel mailing list

Paparazzi-d= evel@nongnu.org

https://lists.nongnu.org/mailman/lis=
tinfo/paparazzi-devel

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 =3D P * (err + D * d_err)

to

u =3D P * err + D * d_err

There is already a discussion opened in
https://github.com/paparazzi/p

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 b= y q (or a more complete equation). You also need to compensate by the control time step.

Gautier

Le 18/09/2016 =C3=A0 09:06, Hector Garcia de
Marina a =C3=A9crit=C2=A0:

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 po= sting about. For nominal flight conditions orwings-level flight, then it is ok to approximate the pitch rate \dot\theta by just 'q'. But this is only for the des= ign 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-ratefor design purposeswhere 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 you= r 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 <michal.podhradsky@aggiemail.u= su.edu > wrote:

MRegardsHi 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.

On Sat, Sep 17, 2016 at 10:45 AM, Hector Garcia de Marina <noeth3r@gmail.com>= wrote:

Hi Michal,

the correct expression for the pitch rate is

\dot \theta =3D q \cos(\phi) + r \sin(phi),=C2= =A0

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=C2=A0in 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 followinga 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 <michal.podhradsky@aggiemail.usu.edu > wrote:

it allows you to follow whichever pitch angle you set as a reference.To follow non-zero pitch angle there is this term: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/airbor )ne/firmwares/fixedwing/s= tabili zation/stabilization_attitude. c#L476

The term =

float d_err =3D h_ctl_ref.pitch_rate - stateGetBodyRates_f()->q;<= /span>

takes care of situations when your reference pitch rate is non-zero (although in most cases it will be zero).

float err =3D h_ctl_ref.pitch_angle - stateGetNedToBodyEulers= _f()->theta;

Regards

Michal

On Fri, Sep 16, 2016 at 11:33 PM, Hector Garcia de Marina <noeth3r= @gmail.com> wrote:

Hi Michal,

instead of=C2=A0

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

should not be (pseudocode) the following?

= float d_err =3D 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 =3D 0, e.g. "follow= ing a straight line". Howeve= r, 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 <michal.podhradsky@aggiemail.usu.edu > wrote:

______________________________The proposed change follows a solution already present in the adaptive stabilization (here)= .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 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 =3D 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

=C2=A0

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

--

= H=C3=A9ctor

Website: http://masteringrobotics.com<= /div>

______________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

____________________________________= ___________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://l= ists.nongnu.org/mailman/listinfo/paparazzi-devel

--

H=C3=A9ctor

Website: http://masteringrobotics.com

_______________________________________________<= br> Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.= org/mailman/listinfo/paparazzi-devel

_______________________________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailm<= wbr>an/listinfo/paparazzi-devel

--

H=C3=A9ctor

Website: http://masteringrobotics.com

_______________________________________________ Paparazzi-devel mailing list Paparazzi-d= evel@nongnu.org https://lists.nongnu.org/mailm an/listinfo/paparazzi-devel=

______________________________

Paparazzi-devel mailing list

Paparazzi-d= evel@nongnu.org

https://lists.nongnu.org/mailm

H=C3=A9ctor

Drones and other stuff at my website: http://dobratech.com

______________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/

great!

please, do not hesitate to ask me here or in the chat at git= ter if you have further questions about the implementation :P.

cheers

On 27 Sep 2016 05=
:36, "Michal Podhradsky" <michal.podhradsky@aggiemail.usu.edu> wrote:

MichalRega= rds Thanks to Gautier for explaining my intentions better. Hector, I fin= ally got hands on the book you mentioned - but implementing it would be a d= ifferent 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 =3D D_old * P_old?

On Sun, Sep 25, 2016 at 2:20 PM, Hector Garcia de Marina <noet=
h3r@gmail.com> wrote:

Hello,indeed, the numerical difference is v= ery 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 followin= g 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 t= o be followed by the time derivative of the pitch, then I would say that th= e 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 fut= ure...I would also agree about decoupling gains, = it would not be the first time that one changes one gain without thinking i= t 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 t= he "old control law" comes from the times when there were not gyr= os on board :P.On Sun, Sep 25, 2016 at 1= 0:51 PM, Gautier Hattenberger <gautier.hattenberger@gmail.co<= wbr>m> wrote:=20 =20 =20Hi,

u =3D P * (err + D * d_err)

to

u =3D P * err + D * d_err

There is already a discussion opened in https://github.com/paparazzi/p

aparazzi/pull/1658 but n= ot 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 b= y q (or a more complete equation). You also need to compensate by the control time step.

Gautier

Le 18/09/2016 =C3=A0 09:06, Hector Garcia de Marina a =C3=A9crit=C2=A0:

Hi Michal,

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

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 po= sting about. For nominal flight conditions orwings-level flight, then it is ok to approximate the pitch rate \dot\theta by just 'q'. But this is only for the des= ign of the control loop, i.e. to calculate the gains off-line, under such assumption.

Summarizing:

for design purposeswhere 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 you= r 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 <michal.podhradsky@aggiemail.u= su.edu > 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.

On Sat, Sep 17, 2016 at 10:45 AM, Hector Garcia de Marina <noeth3r@gmail.com>= wrote:

Hi Michal,

the correct expression for the pitch rate is

\dot \theta =3D q \cos(\phi) + r \sin(phi),=C2= =A0

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=C2=A0in whatever physics book dealing with rigid bodies :P.

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 <michal.podhradsky@aggiemail.usu.edu > wrote:

it allows you to follow whichever pitch angle you set as a reference.To follow non-zero pitch angle there is this term:

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/airbor )ne/firmwares/fixedwing/s= tabili zation/stabilization_attitude. c#L476

The term =

float d_err =3D h_ctl_ref.pitch_rate - stateGetBodyRates_f()->q;<= /span>

takes care of situations when your reference pitch rate is non-zero (although in most cases it will be zero).

float err =3D h_ctl_ref.pitch_angle - stateGetNedToBodyEulers= _f()->theta;

Regards

Michal

On Fri, Sep 16, 2016 at 11:33 PM, Hector Garcia de Marina <noeth3r= @gmail.com> wrote:

Hi Michal,

instead of=C2=A0

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

should not be (pseudocode) the following?

= float d_err =3D 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 =3D 0, e.g. "follow= ing a straight line". Howeve= r, 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 <michal.podhradsky@aggiemail.usu.edu > wrote:

______________________________The proposed change follows a solution already present in the adaptive stabilization (here)= .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 drawback is that the D gain currently used would have to be updated using this formula (see here for details): D_new =3D D_old * P_old (the old D gain wouldn't work).

Thank you for your feedback.

Michal

=C2=A0

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

--

= H=C3=A9ctor

Website: http://masteringrobotics.com<= /div>

______________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

____________________________________= ___________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://l= ists.nongnu.org/mailman/listinfo/paparazzi-devel

--

H=C3=A9ctor

Website: http://masteringrobotics.com

_______________________________________________<= br> Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.= org/mailman/listinfo/paparazzi-devel

_______________________________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/mailm<= wbr>an/listinfo/paparazzi-devel

--

H=C3=A9ctor

Website: http://masteringrobotics.com

_______________________________________________ Paparazzi-devel mailing list Paparazzi-d= evel@nongnu.org https://lists.nongnu.org/mailm an/listinfo/paparazzi-devel=

______________________________

Paparazzi-devel mailing list

Paparazzi-d= evel@nongnu.org

https://lists.nongnu.org/mailman/lis= tinfo/paparazzi-devel

--H=C3=A9ctorDrones and other stuff at my website: http://dobratech.com

______________________________

Paparazzi-devel mailing list

Paparazzi-d= evel@nongnu.org

https://lists.nongnu.org/mailman/lis= tinfo/paparazzi-devel

______________________________

Paparazzi-devel mailing list

Paparazzi-devel@nongnu.org

https://lists.nongnu.org/