ArduPilot / ardupilot

ArduPlane, ArduCopter, ArduRover, ArduSub source
http://ardupilot.org/
GNU General Public License v3.0
11.02k stars 17.57k forks source link

Arducopter 3.6 Issue: Prearm failure GPS #9649

Closed mtbsteve closed 6 years ago

mtbsteve commented 6 years ago

Bug report

Issue details As soon as the number of sats locked increases beyond somewhere 20-22 sats with my UBLOX m8n, I get a "Prearm GPS not healthy" message in my GCS and can't arm. It continues to flicker on and off within seconds. When the error disappears for a split second and I then press the arming switch fast enough, I can fly w/o problems. As long as the sat count is lower, the prearm check is passed.

Please describe the problem It must be a problem with AC 3.6, since it was working fine all the time in 3.5 and earlier. With my m8n GPS, I usually receive between 22 and 28 sats at HDOP down to 0.47 and never had any issues with Arducopter 3.3, 3.4, 3.5 in the same setup and parameter settings. My other copter with an UBLOX m8p RTK chip runs fine with AC3.6 (however the m8p never exceeds 18 sats)

Version What version was the issue encountered with Arducopter 3.6.0

Platform [ ] All [ ] AntennaTracker [X] Copter [ ] Plane [ ] Rover [ ] Submarine

Airframe type What type of airframe (flying wing, glider, hex, Y6, octa etc) Quad

Hardware type What autopilot hardware was used? (Pixhawk, Cube, Pixracer, Navio2, etc) Pixhawk 2, Drotek m8n GPS

Logs Please provide a link to any relevant logs that show the issue https://1drv.ms/u/s!AnKeW8KMoCcymAWipx8Cj3CaFZO6

mtbsteve commented 6 years ago

Thanks Randy. As you suspected, the likely reason is that I have changed my m8n factory settings in order to receive GPS/Glonass and Galileo which which may cause the update rate to drop under 5Hz. I never experienced any issues over the past years with those settings. For me feels rather the opposite- I get a much better performance under difficult conditions. Is there a way to disable those enforced checks you introduced with 3.6?

WickedShell commented 6 years ago

@mtbsteve The issue here is when the update rate drops below 5Hz. The EKF is expecting us to always provide GPS data at or above 5Hz, and has appropriately sized it's internal buffers for data at this rate. When the GPS fails to meet this rate it means we cannot fully correct the data, and a number of issues with the EKF can be generated. The time between updates from the GPS should be 200 ms, +/- 20 ms due to jitter. If you look at this screenshot you are receiving much worse update rates.

figure_1-116

More satellites is always nice, but in this case it is coming with much to high a price on data timing, and it's rippling through to the rest of the system on you.