all axis/sign definitions should follow aerospace conventions (e.g. roll command from rc)

[flixr]

Currently the roll command from rc does not follow the normal aerospace convention, but is reversed.
This is very confusing, especially when debugging.

[gautierhattenberger]

I fully agree, but is there a solution to change this without touching airframe or radio files ?

[flixr]

Probably not... at least I can't think of any.
Maybe we should introduce a version for the config files?
Then we could change things, announce it when it's merged back to master (make a release?) and at least print a warning if you have an older config file...

[flixr]

Wrong signs:

• RC roll
• RC yaw

Please list everything you can find that doesn't comply here...

[flixr]

Ok, I changed the signs of RC roll and yaw in all the functions taking radio_control.values as input in the rotorcraft firmware. See flixr/paparazzi@532c810c2b69f in my aerospace_conventions branch...

I also corrected it in the radio control input for the nps sim.

@lamestllama The spektrum signs still need to be adapted as well, do we just need to change the signs of RC_SPK_THROWS in the spektrum_dx7se(_joby).h files or do we need to consider something else as well?
When are these actually used instead of RADIO_CONTROL_SPEKTRUM_SIGNS defined in the airframe file?

@gautierhattenberger From http://paparazzi.enac.fr/wiki/Radio_Control#Direction it seems that roll is also wrong for fixedwings. Does this actually need any changes in the code? Or is this only reflected in the radio_control.xml file and the command_laws in the airframe file?

Any other commands, whatever that don't follow the sign convention?

[gautierhattenberger]

You probably need to change the code. AP commands and RC commands have to match. command_laws mixing are at the very end (do they really need to be changed ?).

[flixr]

What am I missing? I'm confused...

It never says anywhere what signs the h_ctl_aileron_setpoint and h_ctl_roll_setpoint (same for h_ctl_elevator_setpoint and h_ctl_pitch_setpoint) actually have. While I have never done much in the fw control, I was always fairly sure that the commands obey the standard aerospace axes conventions, since the attitude (estimator_[phi|theta|psi] does.
Ah, that reminds me, really need to get rid of that estimator "interface" on fixedwings...

[gautierhattenberger]

firmwares/fixedwing/main_ap.c:353 looks very suspecious. I think it's a this line that the radio sign is change to have the roll setpoint correctly
finishing the new state interface would be very nice indeed...

[flixr]

ah, that was well hidden...

What about yaw for fixedwings? As far as I can see that seems to be correct, can you confirm that?

So far, (afaik) the only thing that needs to be changed by the user, is the RC configuration to get the rc values with the correct signs for roll and yaw. Of course any custom flight_plans, modules or other code that directly read the radio control channels will have to follow the sign convention as well.

@dewagter What about cam point? Are you using that?

@martinmm What about rc_datalink? Where is that configured, or where would this need to updated on the ground side?

Anything else we need to change? Anything on the ground segment that needs to be adapted for this?

[dewagter]

What about yaw for fixedwings? As far as I can see that seems to be
correct, can you confirm that?

Nose right positive.

@dewagter What about cam point? Are you using that?

Yes we use that. This can get quite complex due to the large amount of
mounting options. A pitch-axis-attached-to-body pantilt that looks forward
in rest can yaw right positive but will roll left positive when looking
down.

@martinmm What about rc_datalink? Where is that configured, or where would
this need to updated on the ground side?

Anything else we need to change? Anything on the ground segment that needs
to be adapted for this?

---

Reply to this email directly or view it on GitHub:
#124 (comment)

[flixr]

Nose right positive.

good, thx... just weird that expected RC yaw input was then only inverted
for rotorcrafts, but RC roll for both...

@dewagter What about cam point? Are you using that?

Yes we use that. This can get quite complex due to the large amount of
mounting options. A pitch-axis-attached-to-body pantilt that looks forward
in rest can yaw right positive but will roll left positive when looking
down.

Ok, I can change all the signs where RADIO_ROLL is read for cam_phi in
point.c line 236-255

[gautierhattenberger]

For rc_datalink, the airborne code is only passing the values coming from the ground without sign modifications.
If some files need to be changed, they are the config files of the joysticks (in conf/joystick/).

[flixr]

ok, merged into 4.0_beta
So it means that you will have to change your radio control xml file to get a positive value when pushing roll stick right and a positive value when pushing yaw stick right!

If you encounter any issues, please report them... and don't forget to do proper pre-flight checks (as you should always) before going into the air ;-)

[gautierhattenberger]

I'm just realizing that we discussed the idea of changing the signs, but not what are the correct signs...
With the aeronautical conventions we are using (and I believe it is the common way), a positive command produce a negative moment (the result of a positive deflection on a classical plane). Which means that positive commands are:

• stick pushed to the left for roll
• stick pushed (nose down) for pitch
• rudder bar pushed to the left (nose left) for yaw
  These conventions are made for piloted aircraft, and usually aerodynamic coefficients' signs take this into account. Do we want to follow them or not ?
  In my opinion, it would make sense. And we don't have a lot of opportunities to make changes like that!

[flixr]

a positive command produce a negative moment (the result of a positive deflection on a classical plane).

Well, our "commands" are quite different from classical plane commands you have on piloted aircrafts, no?
Since in our case, a certain amount of e.g. roll stick to the right, directly translates to an actual attitude setpoint and not a moment.

Which means that positive commands are:

• stick pushed to the left for roll

hm... that really doesn't make sense to me, since as I said we take that as a roll setpoint (positive is bank right), so the rc input setpoint should not have the opposite sign... right?

You propose to make all the commands the opposite, or which commands are you referring to?

[dewagter]

Good question... in flight dynamics we also define a positive DEFLECTIONS
as a rotation along the positive axis: e.g. elevator turns along body y,
positive right so indeed a positive deflection is nose down, etc...

However, in paparazzi (except in RC_DIRECT), sticks are mapped to commands.
A positive roll command is a positive along the body-x axis. In paparazzi
this latter convention might get my vote.

-Christophe

On Fri, Mar 16, 2012 at 9:34 PM, Gautier Hattenberger <
reply@reply.github.com

wrote:

I'm just realizing that we discussed the idea of changing the signs, but
not what are the correct signs...
With the aeronautical conventions we are using (and I believe it is the
common way), a positive command produce a negative moment (the result of a
positive deflection on a classical plane). Which means that positive
commands are:

• stick pushed to the left for roll
• stick pushed (nose down) for pitch
• rudder bar pushed to the left (nose left) for yaw
  These conventions are made for piloted aircraft, and usually aerodynamic
  coefficients' signs take this into account. Do we want to follow them or
  not ?
  In my opinion, it would make sense. And we don't have a lot of
  opportunities to make changes like that!

---

Reply to this email directly or view it on GitHub:
#124 (comment)

[gautierhattenberger]

As Christophe said, the aeronautical convention make sense for A/C without autopilot (positive command = positive deflection).
I'm rising this issue as indeed, most of the time we are commanding angles and then the signs are reversed.
Not following the convention is easier and removes negative signs. Still, it is not the convention...

[dewagter]

You should make a canard aircraft, then you can pitch up with a positive
deflection ;-)

PS: I personally never saw a convention that defines the signs of cockpit
stick deflections as pitch down negative, only of aerodynamics surfaces. As
far as I remember from flight dynamics we defined stick deflections in the
cockpit also in body axis signs, i.o.w. pull on the stick rotates it along
the positive y-axis... which is mapped using an inverting mechanism with
crossing cables to a negative deflection of the actuators in planes with a
negative elevator deflection moment coefficient (C_{L_{\delta_e}}) in order
to become controllable.

So for me:

pitch-up-stick = positive

in a "conventional" airframe

elevator = - (minus) pitch-stick

-Christophe

On Fri, Mar 16, 2012 at 9:59 PM, Gautier Hattenberger <
reply@reply.github.com

wrote:

As Christophe said, the aeronautical convention make sense for A/C without
autopilot (positive command = positive deflection).
I'm rising this issue as indeed, most of the time we are commanding angles
and then the signs are reversed.
Not following the convention is easier and removes negative signs. Still,
it is not the convention...

---

Reply to this email directly or view it on GitHub:
#124 (comment)

[flixr]

This issue was originally only about the inconsistent signs of the RC command input (which in most cases could be more appropriately called RC setpoint).
But I agree, if we want to change something, now is the time...

You guys surely have more knowlege of "conventional aerospace flight dynamics & control" knowledge.

The way I know it is that setpoints are expressed in the normal axes conventions, so pitch-up = positive, etc..
And when you deal with deflections and moments, it's basically reversed as you said...
But since we are not actually directly setting a control surface deflection, but really are demanding a certain setpoint, I think it makes more sense to have the RC commands follow the setpoint signs.

If we are talking about the commands going to the actual actuators (servos) for the control surfaces on fixedwings, then I guess we could also reverse them to follow the sign of the deflections.

I also tend to mostly think about the multicopters, etc... so there it is more intuitive for me to have the actuator commands with the same sign as the attitude or rate setpoint.

And I guess we don't want to mix it... then what about vehicles where you have both? Like the quadshot.

The main problem was that it wasn't internally consistent, roll had this sign, pitch the other...

[gautierhattenberger]

I also tend to mostly think about the multicopters, etc... so there it is more intuitive for me to have the actuator commands with the same sign as the attitude or rate setpoint.

Actually, this also can appear in the control_laws section by changing the signs of roll or pitch

Anyway, you have a good point when saying that few people are really aware/caring about "low level" aerospace conventions...
For everyone else, choosing something easy to understand might be the best choice. So I also agree that having commands and angles with the same direction is the best option.

[flixr]

I really don't mind much which convention we follow... as long as we follow the same one on all axes!

So concerning fixedwings, in 4.0_beta we have right now:

Roll axis:

• positive roll command ap_state->commands[COMMAND_ROLL] is bank left (so opposite to estimator_phi and h_ctl_roll_setpoint
• h_ctl_aileron_setpoint has the same sign as the roll command (positive setpoint means bank left)
• h_ctl_roll_setpoint is along the positive x-axis (bank right positive)
• the RC roll channel now needs to have the same sign as h_ctl_roll_setpoint (used in Auto1, where the roll setpoint is set from RC in main_ap.c line 358)

Pitch axis:

• positive pitch command ap_state->commands[COMMAND_PITCH] is pitch up (so the same as estimator_theta and h_ctl_pitch_setpoint and hence follows the standard axes signs)
• h_ctl_elevator_setpoint has the same sign as the pitch command (so positive sign is pitch up)

If you fly in auto1 or auto2 it is correct right now, since the h_ctl_roll_setpoint (from rc) now has the same direction as roll axis.

But in manual, where you just copy the values from RC to aileron_setpoint, you need to reverse it. So that currently needs to be changed in the rc_commands section in the airframe file, which then generates SetCommandsFromRC.

 <rc_commands>
    <set command="THROTTLE" value="@THROTTLE"/>
    <set command="ROLL"     value="-@ROLL"/>
    <set command="PITCH"    value="@PITCH"/>
  </rc_commands>

[flixr]

ok, with commit de5b966 the final roll command is now positive for a bank right as well.

Unfortunaltey this means changing the command_laws and/or the servos sections in the airframe files (make sure rc input is correct first):

• if you have a delta wing: in airframe file, change command_laws right=elevator+aileron, left=elevator-aileron (swap signs before aileron)
• for convential aircraft, I would recommand to replace the above by changing min and max in the servo section (to keep left=roll, right=roll)
• if using AILERON_DIFF, don't forget to invert it in control laws (1 : AILERON_DIFF <-> AILERON_DIFF : 1)

The *_example airframes in the repository are updated accordingly.

The h_ctl_aileron_setpoint is still negative, but that is only internal and requires no configuration changes. @dewagter said he will fix that as well before the release.

[dewagter]

Will fix roll setpoint code before the release of paparazzi4 and also check the issue from Eduardo lavratti:

Hello, i am testing mi lisa_m and twog for a week.
For now i am tunnig the ppz and found some problems with MAX ROLL .

Changing the MAX_ROLL to more than 45deg in AUTO1 the attitude never go more than 45deg.
My config are setting to 70deg but in flight never go more than 45deg.

In AUTO2 the same occour.
I set de SETPOINT_MAX_ROLL to 70deg but the plane never go more than 45deg.

Felix make some tests in simulation and confimed the problem.

another problem is :
I never can do STAND-BY or another extra navigation with radius less than 50.

For my purpouse i need make a survei with 25m grid.

With another autopilot my plane make close turns less than 25m without problem.

[gautierhattenberger]

In the simulator, the max roll angle is bounded (hard coded, sw/simulator/flightModel:149) to 0.7 rad.

For the nav radius, I can set it to any value while flying the STANDBY block of basic FP. For the survey, the radius is statically set by the grid attribute. The radius of the circles will be half of it (so grid="50" for a 25m radius turn). If you use a variable to change it dynamically, you will have to go out of the survey block and enter again.

[flixr]

In the simulator, the max roll angle is bounded (hard coded, sw/simulator/flightModel:149) to 0.7 rad.

Ok, with 9ce4478 I changed the sim to take ROLL_MAX_SETPOINT instead of the hardcoded 40degrees.

Btw, this has nothing to do with the sign conventions... if there is a problem with the max setpoints it should probably get it's own issue (Eduardo was testing with master).

[gautierhattenberger]

Closing this issue since signs are corrected from the user point of view.
Some sign errors are remaining inside the control loops, a new issue will be opened for this.