Bad Gyro Health only on startup on RC

I have a CubeOrange+ with ArduCopter 4.5.4 running. It has already flown succesfully. Recently I am getting a “CRT: Bad Gyro Health” Message on the remote directly after the “INF: Initialising ArduPilot” Message. After that the message does not reappear. It also does not appear in the log of MissionPlaner when its connected to the PC.

I already recalibrated the accelerometers and the compass multiple times. I also tried the pre-flight reboot or pre-flight calibration via MissionPlanner (as suggested here). Using the pre-flight reboot or pre-flight calibration the message does not appear (neither in MissionPlanner nor on the RC). It only appears when the copter is started by connecting the battery and the message is only delivered to the RC. Can I ingore the message in that case? Is it safe to fly? It also does not appear as a warning on HUD in MissionPlanner which I saw in some screenshots.

Additionally, I tested the hints from Fixing Bad Gyro Health but when I set the INS_ENABLE_MASK to 7 I get more errors like BAD AHRS… so that is not working.

I uploaded a recent log file here: TUHH-Cloud . But be aware I did/could not fly the copter the movement you see is just me carrying the copter.

Maybe I need to add some infos: I am hesitating to fly the drone with this error message as it crashed the last time it was flown. The message appeared only afterwards. Has anyone an idea where this “CRT: Bad Gyro Health” message comes from? As calibration of IMU and compass didn’t resolve it I don’t know what could be the problem.

Maybe during start-up copter is not stable? Maybe something is wrong with heating the IMUs can be hardware problem…

Thanks for the answer! I would rule out the heating for the moment, as it is also ocurring after start up directly in the morning. Any ideas where to start looking for IMU hardware failures? I am not sure what you mean by “not stable” during start-up?

I mean:during powering the copter it is moving or not??

Maybe try to disable first or second IMU in parameters and check what will happen. I think that’s IMU_ENABLE_MASK

1 Like

Okay, now I get it. The copter is standing still on a table, i.e. not moving at all.
I tried to disable one IMU after the other (there should be three in a CubeOrange+, right?). However, for IMU 1 and 2 that didn’t change anything. It is still showing the message at startup. When I activate only IMU 3, the copter gives me the following messages in a loop:
02.09.2024 12:41:40 : Config Error: INS: unable to initialise driver
02.09.2024 12:41:40 : Config Error: fix problem then reboot
And on the RC it shows inbetween the Bad Gyro Health message.
So there might be the problem.

But, when I upload my .log file to the Hardware Report tool ArduPilot Hardware Report , it shows that all Gyro health values are ok:

Maybe try to disconnect GPS and recalibrate compass again…and check only Cube without other hardware…

Disconnecting GPS also disconnects the compass so thats not an option. Plus, I only get the message on the remote control never in the Mission Planer log window, i.e. I can’t really disconnect any more hardware. Sometimes the message appears befor “Initialising ArduPilot”, sometimes after:

Looking at the log from Mission Planner, everything looks fine:

05.09.2024 09:40:32 : EKF3 IMU2 MAG0 initial yaw alignment complete
05.09.2024 09:40:32 : EKF3 IMU1 MAG0 initial yaw alignment complete
05.09.2024 09:40:32 : EKF3 IMU0 MAG0 initial yaw alignment complete
05.09.2024 09:40:32 : EKF3 IMU2 tilt alignment complete
05.09.2024 09:40:32 : EKF3 IMU1 tilt alignment complete
05.09.2024 09:40:32 : EKF3 IMU0 tilt alignment complete
05.09.2024 09:40:30 : AHRS: EKF3 active
05.09.2024 09:40:30 : EKF3 IMU2 initialised
05.09.2024 09:40:30 : EKF3 IMU1 initialised
05.09.2024 09:40:30 : EKF3 IMU0 initialised
05.09.2024 09:40:28 : RC9: MotorEStop LOW
05.09.2024 09:40:28 : LandingGear: DEPLOY
05.09.2024 09:40:28 : GPS 1: specified as DroneCAN1-125
05.09.2024 09:40:28 : RCOut: PWM:1-8 DS150:9-12 PWM:13-14
05.09.2024 09:40:28 : AHRS: DCM active
05.09.2024 09:40:28 : ArduPilot Ready
05.09.2024 09:40:27 : Barometer 2 calibration complete
05.09.2024 09:40:27 : Barometer 1 calibration complete
05.09.2024 09:40:26 : Frame: QUAD/X
05.09.2024 09:40:26 : RCOut: Initialising
05.09.2024 09:40:26 : IOMCU: 420 1001 411FC231
05.09.2024 09:40:26 : CubeOrangePlus 002F0019 3032510E 33383839
05.09.2024 09:40:26 : ChibiOS: 6a85082c
05.09.2024 09:40:26 : ArduCopter V4.5.5 (142aece2)
05.09.2024 09:40:26 : Frame: QUAD/X
05.09.2024 09:40:26 : RCOut: Initialising
05.09.2024 09:40:26 : IOMCU: 420 1001 411FC231
05.09.2024 09:40:26 : CubeOrangePlus 002F0019 3032510E 33383839
05.09.2024 09:40:26 : ChibiOS: 6a85082c
05.09.2024 09:40:26 : ArduCopter V4.5.5 (142aece2)
05.09.2024 09:40:26 : Frame: QUAD/X
05.09.2024 09:40:26 : RCOut: Initialising
05.09.2024 09:40:26 : IOMCU: 420 1001 411FC231
05.09.2024 09:40:26 : CubeOrangePlus 002F0019 3032510E 33383839
05.09.2024 09:40:26 : ChibiOS: 6a85082c
05.09.2024 09:40:26 : ArduCopter V4.5.5 (142aece2)
05.09.2024 09:40:26 : Calibrating barometer
05.09.2024 09:40:25 : Initialising ArduPilot

As I was testing to enable only single IMUs I saw that you get the “Bad Gyro Health” Message in a loop if there is really no IMU available. So I guess, getting the message only once on startup is not that critical…?

You probably have a defective board of defective soder joint to the gyro.

As far as I remember, one of the reasons, why the “Methodic Configurator” recommends the temperature calibration as one of the first steps, is avoiding these “bad gyro health” messages at startup during the heat-up phase. Perhaps you can try the temperature calibration and see, if the message is gone after calibration

IMU temperature calibration is to avoid “Gyro inconsistent” errors.

The solution to “bad gyro health” is a different one. :slight_smile:

Gyro inconsistent means → Gyro 1 data is not consistent with gyro 2 data
Bad Gyro health means → no valid data received from the gyro

1 Like

So you mean, the only solution is to replace the board?
Is there any way I can open the cube without destroying it…? I tried to pull up the orange cube from the main board but didn’t want to apply too much force…

I also did some more systematic test regarding the INS_ENABLE_MASK to figure out which IMU produces the error. But I am still not sure how to map the entries in the MASK to the physical sensors, is there any documentation on this?
I figured out that the IMUs are connected to the 1, 3, 4 entries of the INS_ENABLE_MASK. The Bady Gyro Health Messge appears for every combination of the three IMUs. So either, all of them are defective or there is something wrong with MCU?

There is nothing serviceable inside it. Do not take it apart. And if you do, unscrew it first.

Yes, there is documentation. it is a simple bitmaksK:

  • Bit 0 is IMU1
  • Bit 1 is IMU2
  • Bit 2 is IMU3

INS_ENABLE_MASK = 2^IMU3 + 2^IMU2 + 2^IMU1