Re: [Paparazzi-devel] significant improvements merged to master

Hi Alonso,

the frequency the control loops are running at is different (by default at least) for fixedwings compared to rotorcrafts.

The int_cmpl_quat AHRS was originally written for rotorcrafts and was not well "tuned" for fixedwings running at a lower frequency (e.g. 100Hz).

The frequency is now correctly taken into account in the correction "gains" and it should work well for any frequency, meaning it should also give you much better estimation results out of the box (e.g. for fixedwings running at 60 or 100Hz).

This is not dependent on the autopilot board you are using, but rather your IMU driver and how it's configured.

E.g. using the Aspirin IMU driver with a 120Hz main loop, add to the target ap in your firmware section:

Cheers, Felix

On Sat, Oct 12, 2013 at 1:01 AM, alonso acuña <address@hidden> wrote:

Hello Felix. Thanks for the great work. This part got my attention "Hence this will also give you correct gains for 100Hz fixedwings". Could you please explain in practical and simple terms what are the implications of this, which autopilots are affected, what changes are needed to make use of this and what improvements could be expected?

Thanks

Alonso Acuña

On Fri, Oct 11, 2013 at 8:07 AM, Felix Ruess <address@hidden> wrote:

Hi all,

just merged three larger pull requests with significant improvements to master:

ahrs_int_cmpl_quat frequency scaling #371:

Proper scaling of corrections.
Using AHRS_PROPAGATE_FREQUENCY, AHRS_CORRECT_FREQUENCY and AHRS_MAG_CORRECT_FREQUENCY.
Hence this will also give you correct gains for 100Hz fixedwings, see #240.


Allow tuning of the accel and mag correction natural freqency and damping.
Tunable gravity_heuristic_factor (set to zero to turn it off and replaces the boolean AHRS_GRAVITY_UPDATE_NORM_HEURISTIC)

If you have high vibrations, reduce this factor or completely turn it off...

Baro event handling using ABI interface #525

Main benefits:
Less crappy handler functions in main.c files
Possibility to use multiple sources of sensors (integrated to the board or not)
The filters don't need to know who is sending the raw values (not completely true with the old alt_float filter yet)


The pressure are now standardized in Pascal and the standard atmosphere model is used

The INS_BARO_SENS is hence not needed anymore.
Onboard baros are automatically available in fixedwing firmware as well (use same code as rotorcraft now).


Disable onboard baro with <configure name="USE_BARO_BOARD" value="FALSE"/>
Also all baro_board implementations use the same BARO_BOARD_SENDER_ID,
since there can only be one baro_board at the same time and this provides a good default for INS_BARO_ID.

So if you want to use an onboard baro the INS_BARO_ID is already ok (also if you have additional baro modules).
To use a baro module for INS: <define name="INS_BARO_ID" value="BARO_x_SENDER_ID"/>

Some stuff to check before using: check conversion factor to convert ADC values to Pascal
(mostly older boards/baro, recent digital sensors can output pressure in Pascal already)

Rotorcraft guidance fixes/improvements #539
Now horizontal guidance returns commands in north/east earth frame and doesn't already rotate it to body frame.

This allows for better handling of them in different controllers.

New and properly working transformations from earth commands to quaternions added.
No proper fixedpoint implementation so far... no change there compared to current master though. Should still be done for efficiency at some point.


IMPORTANT: This does NOT have the feature to "add" roll/pitch setpoints via RC in nav/hover anymore.
Instead you can give velocity commands in hover mode via RC.


Includes max bank improvements proposed in #546:

Split PD and I-gain with separate max bank
- no wind: integrator (trim attitude) = 0, PD maxbank = -20 to 20 extra: total: -20 to 20

- huge wind: integrator (trim attitude) = 20, PD maxbank = -20 to 20 extra: total: 0 to 40
Put gain before integrator to get better insight in the saturation values
Reduce integration overshoots while increasing integration speed by adding the speed error as well.

- no speed error: integrate as before
- counterproductive speed error, integrate faster
If the position error is already decreasing fast, no integrator is needed or it will overshoot.

Cheers, Felix

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

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

From:	Felix Ruess
Subject:	Re: [Paparazzi-devel] significant improvements merged to master
Date:	Mon, 14 Oct 2013 13:18:39 +0200