Imu can be disabled in the logging mask? Or maybe the imu mask is the same? I mean works the same and you only made an example?
Ok, good to know it can be disabled this easy.
It doesnât actually disable the IMU. It tells the EKF which one(s) to use. The IMU is still powered and you will get basic logging from it anyway even if you set the logging MASK to only log the full output for the first one (or whatever).
As @andyp1per mentioned, the EKF is pretty much rock solid if you only run one process. It handles a failed sensor pretty good, where the DCM does not. I have been able to get a single process to drift a bit like in a double snap roll with a helicopter, pulling 14+ Gâs when testing our new Acro code. But the aircraft remains flyable in Acro, no problem. If it has drifted it will be difficult to handle it in Stabilize. If you have managed to get the EKF to flip then it is not flyable in Stabilize, but still remains flyable in Acro. And if you let the EKF sort of âcatch upâ after doing something that confuses it, it gradually comes back to the correct attitude solution.
Running a single process, if it drifts, the worst thing that happens is you get a flyaway in a attitude leveling mode. It does not suddenly flip over and crash. Switch to Acro, bring it back and itâs not a problem. I used to think the old DCM was better than EKF. After playing with the EKF and setting it the way I like it to work, the EKF beats the DCM hands-down.
I tried to change EK2_IMU_MASK parameter to first and third IMU (value 5), but the message about inconsistense did not disappear.
By default first and second IMU were enabled only.
I was afraid of that. Even though itâs not using it the system is monitoring it anyway.
Maybe @rmackay9 or @tridge have an idea if the pre-arm checks can be set to ignore the #2 IMU.
I decided to order new board. And will send two bad Pixhack V3 back to manufacturer for repair. Iâm afraid to use them again.
I will give them link to this discussion to explain the problem.
1 Like
Got a very windy day today, with gusts that toppled stuff around the yard, so I thought about checking copters stability. It went pretty well until a GPS Glitch event caused an EKF error and switch that sent the copter towards the heavens - which probably saved some propellers, as I see DAlt going to zero - btw, @ChrisOlson which analyzer are you using for those graphs !? - As far as my ability to look at values goes, both EKF instances tracked the values alongside. I canât find the cause of thirst for altitude of the 2nd iteration.
It is APM Planner2
Extra text for a âlegalâ post.
@KbGo It seems that the problem is caused by wrong imu data. Sorry, this is a hardware failure; we will actively cooperate with you to deal with this problem.