My Pixhawk 2.1 / Cube on a quadplane has recently been constantly stuck in a pre-arm check failing and passing loop - aka it will report it is ready to arm (flashing green lights on the Here GNSS, plays the ready to arm sound sequence, and possible to arm with TX/MP) and after that immediately reports that some pre-arm check is failing and prevent me from arming it (goes back to flashing yellow lights, plays the pre-arm check failing sound sequence).
I’ve been running Plane 3.8.3-dev (e76865e) because I needed support for a Lightware LW20 on my aircraft, and it’s on the backport list right now.
I get a few errors reported to me on Mission Planner when this happens (only one error appears at a time).
Bad GPS Health (the most consistent error). I tried this with a different Here GNSS with a totally different cable and I still got this error. I get good hdop and numsats values (< 0.6, 15 - 20 sats) so I’m not sure why this occurs. My Here GNSS is on GPS2 and my GPS1_TYPE is set to 0.
GPS and AHRS differ by x meters.
Sometimes when I manage to arm it just nicely in the middle of this can/cannot-arm sequence, it flies as expected, but sometimes it begins to yaw excessively. Also sometimes, the aircraft completely refuses to arm (Bad GPS Health) and sometimes it arms without issue.
I have tried re-calibrating the compass and accels, changing firmware to 3.8.4, but the problem still occurs. Is anyone facing a similar issue, or knows how to approach this problem?
I’m attaching a log - the first flight in QHOVER and FBWA happened after the aircraft was armable after going through this pre-arm loop a few times, and it flew fine. The second time, it rotated 90 deg on takeoff in AUTO after going through a similar loop and I had to to takeover and land it. Unfortunately, I didn’t have LOG_DISARM turned on, so I’m going to collect more data in the meantime.
My GPS is seeing satellites, my satcount2 is 22 in that picture.
The GPS is mounted at the top of the aircraft, but I disabled the use of the GPS compass. I’m just using the compass internal to the Cube since it’s been quite consistent so far.
I’ve enabled LOG_DISARMED and collected quite a few logs where the “GPS and AHRS differ” issue keeps coming up. I haven’t had this problem before switching to master - @rmackay9 is there any chance that while this check is appropriate for Rover, it might cause some problems for Plane/quadplanes? The EKF is quite complicated; is there ever a chance that the GPS and AHRS differing in planes is more acceptable / normal than other craft? It could also be a problem on my end, I’m testing this in a parking lot right now, but this problem surfaces even in an open field.
We need to get to the bottom of this issue before the next release for sure. I guess you’ve seen the issue here. I think this probably only occurs if you’ve moved the vehicle from where it was powered on.
You know, this is a bit of why we encourage people to use a stable release instead of master. I’m sure there are good reasons you’re using master but being on the bleeding edge developer version does mean you’re more likely to hit these problems. I’m sure we will get to the bottom of it eventually.;
Absolutely - problems are to be expected on the bleeding edge. I’m trying to use the Lightware LW20
with the Cube, the PR for which hasn’t been backported, I’ll just try to backport it to Plane to get this to work for now
Let me know if there’s any other testing I can help you with. If I find out anything else, I’ll let you know as well!
