IMU: parameterize IMU integration time (IMU_INTEG_RATE)

[dagar]

This effectively controls the vehicle_attitude publication rate and subsequently how fast the attitude controllers run. It's not something I expect regular users to to change, but this is better than having a magic hard coded number.

We might want to consider lowering this by default for FW.

[dagar]

Historically the IMU integration time was 4000 us (250 Hz) and only very recently changed to 2500 us (400 Hz). We could also consider if 5000 us (200 Hz) is a better default.

By default on most systems the rate controller (inner loop) is running at 800 Hz (synchronized with primary gyro).

[dagar]

Changing the integration from 2500 us -> 5000 us saves about 7% cpu on F4 boards. This is spread out over running the attitude controller, the ekf2 frontend (heavier than expected), and a bit of logging/mavlink (HIGHRES_IMU).

[dagar]

Yet another factor to consider for the default is the impact on default logging rate and ekf2 replay.

On a typical simple multicopter configuration the nominal logging rate changes from ~ 47 KiB/s (IMU integration 2500 us) down to ~32 KiB/s (IMU integration 5000 us).

That being said, our top priority should be optimizing control and we'll work back from there.

[MaEtUgR]

Making 200Hz the default attitude update rate also for multicopters makes sense to me.

[MaEtUgR]

Isn't it a problem that all Gyroscope and Accelerometer drivers would try to correct the out of range parameter more or less at the same time?

[MaEtUgR]

I would at least define the [1000, 20000] interval shared to make sure it's always in sync.

[dagar]

Yes I didn't like that part either. Very soon (early in the v1.12 release cycle) the plan is to gut all of this code from PX4Accelerometer/PX4Gyroscope and move it "downstream" to sensors/vehicle_imu where we can effectively synchronize accel + gyro.

[MaEtUgR]

One more question I forgot to ask in the review: Is there a specific reason why the new parameter is an interval while all others I know of are rates in Hz? Just thinking about the user perspective.

[dagar]

One more question I forgot to ask in the review: Is there a specific reason why the new parameter is an interval while all others I know of are rates in Hz? Just thinking about the user perspective.

Not really, I was thinking about it from the perspective of what was already hard coded and aligning with the current ecl/EKF filter update expressed as an interval (10 ms). We reset the integrator and publish the integrated value every ____ microseconds.

[dagar]

Default changed to 5000 us.

[dagar]

SITL appears to be broken with 5000 us IMU integration.

[julianoes]

@dagar we might have to adapt the gazebo side too: https://github.com/PX4/sitl_gazebo/blob/0823f5e006011d36858c2dd39881874c1edac10b/worlds/empty.world#L31-L33

[dagar]

This was tested by @mhkabir in #14735.

It also fixes ekf2 replay logging with no logger changes (#14734).

$ ulog_info 6a006545-b3bf-446f-9baf-f89c5fcfb542.ulg 
Logging start time: 0:00:01, duration: 0:06:00
No Dropouts

[dagar]

CI SITL MC_avoidance and MC_safe_landing still failing due to the sitl_gazebo version.

[dagar]

I've made 2 changes to the PR.

1. renamed IMU_INTEG_TIME -> IMU_INTEG_RATE (I think most users find rate slightly more intuitive)
2. Dropped the sitl_gazebo and jmavsim rate changes for now until we can resolve the performance problems change default update rate to 200 Hz PX4-SITL_gazebo-classic#474.