This morning I received the following error when trying to arm. I have intentionally disabled all arming checks for my flight mission objectives.
Arm: AHRS: EKF3 Roll/Pitch inconsistent 26 deg
I am flying missions that are time sensitive and require the ability to take off quickly in stabilize mode. For this flight, it took several minutes before the error disappeared and I was able to arm.
Based on reading previous threads (some from as far back as 2020 and 2022), my understanding is that EKF cores (or EKF vs DCM) are calculating different estimates which leads to the error I am receiving. Is there a way to disable this or only use a single core?
Here is a thread I read, for reference.
Is there a way to only use a single EKF core for stabilize or somehow bypass this inconsistency error?
Thanks for the report. This is quite an important arming check and I think it’s quite good that you wait before taking off if it shows up. Below is a screen shot of the roll and pitch from the two EKF lanes and they are very different. It’s probably the 2nd one that’s incorrect but if the AHRS switched to the 2nd EKF core, I think it’s very likely the vehicle would speed off in some direction until it finds something solid.
The IMU acceleration and gyro values look consistent so I think the issue is the EKF’s estimated gyro biases are incorrect. My guess is that something went wrong during the startup to cause the EKF’s gyro estimate to be off. You’re careful of course to not move the vehicle soon after startup?
BTW, it looks like you’re testing 4.7.0-dev from 3 weeks ago which is OK but of course “latest” changes every day and it hasn’t gone through beta testing. We really appreciate beta testing whenever possible!
I wonder if my mission requirements may conflict with Ardupilot expectations/requirements. Often times I am faced with a scenario where I have to power up the drone in one location and then hand deliver it to another nearby location for take off. This is for various reasons, but for purposes of a meaningful discussion one reason might be that the takeoff location is better suited for diagnosing preflight issues compared to the takeoff location.
You could try setting BRD_BOOT_DELAY,3000
in case connecting batteries or similar is interfering with the boot up and calibration process - gyro cal should wait until there’s no movement, but I also had some ill effects from batteries that were hard to connect.
Also try the IMU temperature calibration process - the values can be permanently saved too, so even if you reset all to default or load different vehicle types the temp cal values remain.
It was cold this morning, about 12 degrees F. I have ran into the roll/pitch inconsistency error in climate controlled environments as well though. I have not done the temperature calibration because I was under the (possibly wrong) impression that the temperature calibration was more for the barometer.
I’m still very interested in a possible conclusion to the roll and pitch inconsistencies. I have no doubt it is caused by moving the drone after powering up. But there’s no getting around that, it’s part of my specific mission requirements.
This may sound a little “out of the box” but am trying to think of a solution…. is it somehow possible to remotely reboot the autopilot so that I dont lose power to entire drone but can start with fresh readings?
Maybe after the temp cal procedure the gyro cal would be good enough for you to enable “boat mode” - which is not really a mode, but allows takeoff from a moving platform.
If you want to use the better off-line IMU temperature calibration method and do not want to mess with python scripts, use ArduPilot methodic configurator software.
This is really great feedback, thank you everyone. Later this week I plan to recreate the axis inconsistency issue as much as possible to confirm that moving the vehicle after power up is the root cause. Then I’ll do temp calibration and continue trying to recreate the issue. Then I’ll enable boat mode. I’ll report back findings and hopefully this will help someone out in the future.
I conducted the temp calibration. I have also been able to consistently recreate my axis issues (sometimes yaw, sometimes pitch/roll, sometimes all three) by powering up my drone stationary and then picking it up and walking around with it as if I were hand delivering it. I was also able to recreate it by holding and rotating it about in the air.
I enabled boat mode and it appears to have resolved the issue, most of the time. I am powering up stationary and then moving the vehicle around (as described above), setting the drone down, and am able to successfully arm. However, I was able to induce a roll/pitch axis inconsistency a couple of times and it never recovered and so I was never able to arm. I don’t have a log of this to share. The HUD in mission planner just showed a permanent roll orientation. I suppose because the gyro calibration never occurred (as expected with boat mode) the drone would never have been able to arm.
Without telemetry, is there a way to trigger a gyro calibration… possibly by script and RC input?
Surely the gyro calibration is a quick procedure so I am wondering if I could deliver the drone to where it needs to launch and then the autopilot conducts the gyro cal via script and input from an RC channel.
I just tried this, powering up the copter, moving it all around nearly like doing a compass calibration. Parameters are normal, untouched. Cube Orange.
I got a couple of Check mag field (xy diff:100>100) which goes away after leaving the copter still for a few seconds. HUD was normal. This was inside the house.
Without powering it off I was able to take the copter outside and would have been able to fly if it wasnt dark, HUD was normal.
I have RC9 (two position switch) changing EKF source. Mission requirements may dictate I fly outside and other times strictly inside and so I prefer to use Loiter via GPS or opflow+lidar.
I was typically able to induce the axis inconsistencies doing a compass calibration style movement but also being a bit more aggressive with the movement. As if possibly simulating sudden changes in direction (think running with the drone in hand) or introducing vibrations (think being inside of a car and trying to put the drone on top of the car for launch or tossing the drone a couple of feet to its launch point).
I realize the general user will think “when would this ever happen” but it does when flying time sensitive missions, sometimes in tight spaces.
That’s an interesting use case for standby. It’s for redundant flight controllers. The standby controller needs to be armed, but not really reacting to it’s surroundings otherwise errors build up if everything is live but it’s not actually flying the drone. Did you see this:
This puts the autopilot control loops into a soft standby mode
so that a parallel,redundant autopilot or
companion computer can assume control of the vehicle.
The PID loops, position, and altitude controllers are modified
such that the autopilot can smoothly resum autopilot can
smoothly resume control of the vehicle when standby is
subsequently disabled. Switching of outputs or other peripherals
Yeah, I was clutching at straw suggesting Standby mode.
I think the original problem is with the flight controller, because I cant replicate it here - I can wave around my Quad X8 all I want and walk around with it, put it down and the HUD is normal and it can Arm just fine.
