[RFC] Consider setting default IMU_GYRO_RATEMAX to 400 Hz #14614
Conversation
Pixhawk 2 Cube (IMU_GYRO_RATEMAX=400 SYS_AUTOSTART=4001) PID COMMAND CPU(ms) CPU(%) USED/STACK PRIO(BASE) STATE FD
0 Idle Task 191411 31.104 244/ 512 0 ( 0) READY 3
1 hpwork 0 0.000 344/ 1260 249 (249) w:sig 3
2 lpwork 0 0.000 344/ 1612 50 ( 50) w:sig 3
3 init 1462 0.000 2192/ 2668 100 (100) w:sem 3
4 wq:manager 1 0.000 376/ 1252 255 (255) w:sem 3
633 top 254 3.155 1248/ 2028 248 (248) RUN 3
18 wq:lp_default 342 0.075 1000/ 1700 205 (205) w:sem 3
28 wq:hp_default 7194 1.126 1144/ 1900 241 (241) w:sem 3
159 wq:SPI1 39740 6.461 1928/ 2364 253 (253) w:sem 3
169 wq:SPI4 111234 17.580 1928/ 2364 250 (250) w:sem 3
208 wq:att_pos_ctrl 143365 22.464 5016/ 7196 242 (242) w:sem 3
209 wq:rate_ctrl 20784 3.305 1080/ 1596 255 (255) w:sem 3
215 commander 7972 1.202 1296/ 3212 140 (140) w:sig 6
216 commander_low_prio 14 0.000 856/ 2996 50 ( 50) w:sem 6
229 mavlink_if0 29300 4.733 1824/ 2572 100 (100) READY 4
283 gps 500 0.150 1016/ 1676 208 (208) w:sem 4
331 mavlink_if1 9975 1.577 1888/ 2484 100 (100) w:sig 4
332 mavlink_rcv_if1 2506 0.375 2384/ 3908 175 (175) w:sem 4
346 mavlink_rcv_if0 2306 0.375 2192/ 3908 175 (175) w:sem 4
360 px4io 16921 2.629 1048/ 1484 240 (240) READY 4
582 navigator 695 0.150 1072/ 1764 105 (105) w:sem 5
622 logger 2852 0.450 1688/ 3644 233 (233) READY 3
623 log_writer_file 0 0.000 368/ 1164 60 ( 60) w:sem 3
Processes: 23 total, 5 running, 18 sleeping, max FDs: 15
CPU usage: 65.82% tasks, 3.08% sched, 31.10% idle
DMA Memory: 5120 total, 0 used 0 peak
Uptime: 629.682s total, 191.412s idleupdate: 1s, num topics: 78
TOPIC NAME INST #SUB #MSG #LOST #QSIZE
task_stack_info 0 0 1 0 2
adc_report 0 1 100 0 1
system_power 0 2 100 11 1
sensor_baro 0 2 74 0 1
sensor_mag 0 3 94 95 1
sensor_baro 1 2 74 3 1
sensor_accel 0 2 773 0 4
sensor_accel_status 0 3 10 0 1
sensor_gyro 0 2 740 0 4
sensor_gyro_status 0 3 10 0 1
sensor_accel_integrated 0 3 236 242 1
sensor_gyro_integrated 0 4 240 249 1
vehicle_angular_acceleration 0 1 400 0 1
vehicle_angular_velocity 0 6 400 1527 1
vehicle_acceleration 0 1 400 349 1
vehicle_imu 0 0 231 0 1
battery_status 0 8 99 375 1
sensor_combined 0 3 400 401 1
sensor_preflight 0 1 400 0 1
vehicle_control_mode 0 8 1 0 1
vehicle_status 0 16 1 0 1
actuator_armed 0 4 1 0 1
commander_state 0 0 1 0 1
vehicle_magnetometer 0 3 95 93 1
vehicle_status_flags 0 1 1 0 1
vehicle_air_data 0 8 74 384 1
sensor_gyro 1 2 400 0 4
sensor_gyro_integrated 1 4 400 403 1
sensor_gyro_fifo 0 0 400 0 1
sensor_gyro_status 1 3 10 0 1
sensor_accel 1 2 400 0 4
sensor_accel_integrated 1 3 400 403 1
sensor_accel_fifo 0 0 400 0 1
sensor_accel_status 1 3 10 0 1
sensor_gyro 2 1 399 0 4
sensor_gyro_integrated 2 4 399 403 1
sensor_gyro_fifo 1 0 399 0 1
sensor_gyro_status 2 1 10 0 1
sensor_accel 2 1 399 0 4
sensor_accel_integrated 2 3 399 403 1
sensor_accel_fifo 1 0 399 0 1
sensor_accel_status 2 3 10 0 1
actuator_controls_0 0 7 400 1835 1
safety 0 2 44 0 1
servorail_status 0 0 44 0 1
actuator_outputs 0 3 44 54 1
multirotor_motor_limits 0 2 43 0 1
vehicle_imu 1 0 400 0 1
vehicle_imu 2 0 399 0 1
ekf2_timestamps 0 1 400 0 1
landing_gear 0 0 46 0 1
rate_ctrl_status 0 1 400 0 1
vehicle_attitude 0 7 400 1849 1
vehicle_local_position 0 11 125 1143 1
vehicle_land_detected 0 9 1 0 1
telemetry_status 0 2 1 0 3
estimator_sensor_bias 0 4 125 123 1
estimator_status 0 4 125 194 1
estimator_innovations 0 1 125 0 1
estimator_innovation_variances 0 1 125 0 1
estimator_innovation_test_ratios 0 1 125 0 1
vehicle_odometry 0 1 125 156 1
vehicle_attitude_setpoint 0 4 400 376 1
vehicle_rates_setpoint 0 4 400 376 1 |
|
I would change that with flight testing and tuning on different vehicles. I mean if certain boards are just not capable to deal with the load then we're almost forced to lower the rate for them but I saw multiple multicopters benefiting from the improved 1kHz rate loop updates and we should make sure the average user doesn't miss out on this because it's not the default... |
That's true, so we might want to set the value in the config file for some frames. Racers should run at -at least- 1kHz rate loop, while VTOL planes can run at 400Hz or slower. |
|
Yes with the current PWM400 default, we can also keep the rate loop at that default. I would increase it for boards that can support it easily (durandal, kakute, omnibus, pixracer). I would also expose this in the QGC setup pages more clearly (in particular the ESC protocol + rate controller update frequency). @DonLakeFlyer is that something you can take care of? |
|
To be clear, I'm proposing changing the system default as a stop gap for the next release because I think it's too easy to bypass the current per board/type/airframe defaults on upgrade or manual configuration. I think we're safer having a conservative default with the ability for users to opt-in to higher performance. Once #14363 lands we can effectively change these defaults and I would want to revert this. In general I think it's slightly preferable to not have a default, which then lets the drivers decide. Beyond our current common Invensense selections there are many sensors with output data rates that don't align with 400 Hz. |
From reading the thread this all seems like magic values which the majority of users will not understand. Hence exposing them in something other than the parameter editor doesn't match the model of common usage for the setup pages. Am I wrong? Will these get changed by folks frequently enough and they will actually understand what they are for? |
@DonLakeFlyer it's a one time setup parameter that should be airframe specific, but pragmatically might need to be lowered given actual hardware. |
|
New approach as discussed on the dev cal today. I'll keep the actual parameter default value the same (0 to let the sensor driver select), then for fmu-v2/v3 (and similar) have the board specific init script change IMU_GYRO_RATEMAX to 400 only if it's still set to 0. |
Yes I prefer setting good defaults as well, and we now have a solution for the update rate. |
…ro_x21 - this can lower cpu usage considerably on older boards
dagar
force-pushed
the
pr-default_imu_rate
branch
from
09b919c to
d03dcf7
Compare
|
I've updated the branch with the solution discussed on the dev call. Now on px4_fmu-v2/v3 and mro_x21 |
|
This should do for now. [2020-04-16T00:14:24.574Z] Board defaults: /etc/init.d/rc.board_defaults
[2020-04-16T00:14:24.574Z] IMU_GYRO_RATEMAX: curr: 0 -> new: 400 |
The new Invensense IMU drivers have the ability to actually run the driver at a slower (or faster) rate without sacrificing any raw data. The rate at which the driver runs and empties the FIFO is the maximum inner loop (rate controller) update rate (current default is 1000 Hz). Regardless of the configured rate the full FIFO with 8 kHz raw data is transferred (with DMA).
With focus shifting to newer boards based on stm32f7/h7/imxrt/etc (pixhawk 4 launched 2 years ago) and quite a lot of development activity things have been getting tighter on older boards like fmu-v2/v3. For example, current master on a Pixhawk 2 Cube configured as generic multicopter only has around 15% idle cpu (depending on exact configuration). Configured as a VTOL (quadplane, tiltrotor, etc) it can easily drop below 10%.
If we lower the default rate (IMU_GYRO_RATEMAX=400) these numbers become a lot more comfortable (> 30% idle cpu). This is a (probably?) a more appropriate rate for most vehicles other than small multicopters and also synchronizes with typical 400 Hz PWM ESCs.
With a safe default in place we could then explore opting in to much higher rates for specific configurations. For multicopters many of these boards (including f4's like the pixracer) can handle 2 kHz. Newer boards like the Holybro Durandal (and F7s if you're careful) can even comfortably handle 4 kHz.
For historical context PX4's rate was fixed at 250 Hz up until v1.10 (released Dec 2019), so we've really come a long way.