I’m using the Copter 4.1.2 on a Pixhawk 2.4.6 on which we had a strange beahviour during a fly.
The UAV in hovering, crashed due to the Gyroscope Health(GH) and Accelerometer Health(AH) parameters of the IMU[0] in use, being set to 0 by the Flight Controller.
Analyzing the logs I observe some strange behavior of the IMU[1].AccX and I would have expected this to be disabled and not the IMU[0].
The parameters used are the following:
INS_ENABLE_MASK=127
INS_USE=1
INS_USE2=0
EK3_ENABLE=1
EK3_IMU_MASK=1
Like you can see I disabled the USE of the IMU[1] (second IMU) everywhere but the issue remained the same.
Hi Raffaello,
Just based on what you say it is likely a hardware failure. The “Pixhawk 2.4.x” flight controllers are often constructed with factory-seconds parts or are missing sections of circuitry that were originally designed for reliability.
Quite often they only have one IMU where they should have two, and so on - the list goes on…
Some of them fly forever without an issue, and some dont.
This is all OK if you are aware of their deficiencies and are accepting the risks. Otherwise almost any other supported flight controller is a better choice, and certainly there are now cheaper ones that are better.
If you upload the .bin log file to somewhere such as Dropbox or Onedrive, then share the link, we can all check the log in case there is something else going on apart from an IMU failure.
It’s advisable to update to latest stable firmware too.
Thanks for the reply.
Yes, I am well aware that it is a hardware failure and that is why I disabled the use of the IMU[1] but what I did not expect is that despite the error (see the strange peaks on the IMU[1].AccX) the one that was tagged as unhealth is the IMU[0] which instead has a perfect output.
Now I’m changing the hardware and will probably update the software too.
Yes I would say your diagnosis of IMU failure is likely correct.
However the second IMU [1] remains healthy even when the first IMU [0] is marked as unhealthy.
So you probably would have been better off with keeping defaults for INS_USE and EK3_IMU_MASK, and arducopter would have been able to switch IMUs and continue on.
Yes I know but like you can see the IMU[1] has some spike sometime due to different (problematic) hardware, that’s why I prefer have it disabled and use only the first one IMU[0] that is a MPU6000.
Anyway I still cannot understand why the IMU[0] has been signed like unhealthy if it was working well.
I need to check in the code when and why an IMU is signed as unhealthy.
Given the strange behavior of the IMU[1] at peaks, I would have expected only it to be marked as unhealthy, not causing me any problems because I had disabled it anyway.
