search

PX4 / PX4-Autopilot

PX4 Autopilot Software
https://px4.io
BSD 3-Clause "New" or "Revised" License
8.52k stars 13.51k forks source link

Cube Orange: icm20649 causes poor position tracking #16194

Closed aet2230 closed 3 years ago

aet2230 commented 4 years ago

General: We use quadrotor in laboratory environment (motion capture). Using Pixhawk2 (cube black) we have very good position tracking. After replacing Pixhawk2 (on the same quadrotor) by CubeOrange, the performance deteriorated (from +/- 1[cm] to +/- 5[cm]). This due to lower degree of belief of ekf2 to VO (this may be observed on the attached uLog plots of position and EKF innovations)

p2_pos Fig.1 - pixhawk 2 position

p2_innov Fig.2 - pixhawk 2 innovations

orange_pos Fig.3 - cube Orange position

orange_innov Fig.4 - cube Orange position

After long investigation and trials we decided to disable one IMU each time (hard coded in rc.board_sensors). We found that disabling icm20649 completely solved the problem. Also the cube temperature decreased (it was not very hot before, but now it's temperature after flight is similar to pixhawk2's) Remarks: 1) we did not observe any excessive IMU noise or bias (on pixhawk2 we had much higher bias) p2_acc Fig.5 - pixhawk2 IMU

orange_imu Fig.6 - cube Orange IMU

2) We use the following setup and parameters:

Quadrotor with motion capture as the only positioning and yaw sensor

EKF2_AID_MASK 24 EKF2_EVV_NOISE 0.10 EKF2_HGT_MODE 3 EKF2_MAG_TYPE 6

dagar commented 4 years ago

Did you see similar results between the icm20948 and icm20649? The relevant difference in the IMU is the dynamic range (16G vs 30G) and where they're mountd in the Cube.

The other thing that might be useful in this case is trying multi-EKF where you run an instance of EKF2 for each IMU. The Cube Orange (stm32h7) can easily afford this.

        # enable multi-ekf
    param set EKF2_MULTI_IMU 3
    param set SENS_IMU_MODE 0
dagar commented 4 years ago

For now we can start the icm20602 first. https://github.com/PX4/PX4-Autopilot/pull/16195

aet2230 commented 4 years ago

Did you see similar results between the icm20948 and icm20649? The relevant difference in the IMU is the dynamic range (16G vs 30G) and where they're mountd in the Cube.

The other thing that might be useful in this case is trying multi-EKF where you run an instance of EKF2 for each IMU. The Cube Orange (stm32h7) can easily afford this.

        # enable multi-ekf
  param set EKF2_MULTI_IMU 3
  param set SENS_IMU_MODE 0

No, we disabled all IMUs and started one each time. We found that when icm20602 or icm20948 or both were enabled, the performance was good. Didn't try MULTI_IMU (it is in master, not in stable v1.11.1 version) and did not try to change the order of imu starting

dagar commented 4 years ago

No, we disabled all IMUs and started one each time. We found that when icm20602 or icm20948 or both were enabled, the performance was good. Didn't try MULTI_IMU (it is in master, not in stable v1.11.1 version) and did not try to change the order of imu starting

It's probably the vibration isolation. We should have been starting the isolated SPI4 sensors first rather than arbitrarily in bus numbering order. https://github.com/PX4/PX4-Autopilot/blob/053bf7e732ecbd3732cc3a24d64a069ec2d2bff4/boards/cubepilot/cubeorange/init/rc.board_sensors#L11-L14

https://github.com/PX4/PX4-Autopilot/pull/16195

In the future it will be interesting to see the side-by-side estimator data in the same log.

dagar commented 3 years ago

Should be fixed by https://github.com/PX4/PX4-Autopilot/pull/16195.

RohitBostin commented 1 year ago

@aet2230 iam facing the same problem can you tell me how you disabled icm20649

aet2230 commented 1 year ago

Go to /boards/cubepilot/cubeorange/init/rc.board_sensors

Comment / delete the following line: icm20649 -s -b 1 start