[SOLVED] ArduCopter disregards GPS position, even though GPS reports RTK-Fixed

https://drive.google.com/file/d/1Qr-EsF0pznWxyK7LzpKu3VjxTEQzHAjA/view?usp=sharing

Greetings all

We are trying to upgrade our configuration to a firmware version beyond 4.3.8. Our crafts are GPS-for-Yaw style, with a stack of Ublox boards where the moving-baseline rover feeds the Autopilot with the position and rtk vector, and the moving-baseline base is physically attached to UART2 of the rover, feeding the rover RTCM messages. Due to our design, we cannot rely on the Cube’s internal compass. Due to the GSF not being available yet in this version, we set COMPASS_ENABLE=1 and COMPASS_USE=0. We get a yaw solution and are off to the races.

Every time we have tested 4.4.0 and above, some part of the ArduPilot core code is unhappy with the gps solution, but there is no obvious culprit. In the above log, you’ll see that the message delta is mostly 200ms, the solution is RTK-Fixed, and the GPS antenna locations are reasonably accurate. In this craft, they are on opposite sides of the cube laterally, 53cm apart. The EKF reports that it has no horizontal position so hence we fail prearm checks that require a position, as well as being unable to go into modes requiring this. EKF innovations for POSD are below 1. I think the GSF is configured correctly, but I don’t know for certain, regardless, the heading doesn’t seem to reflect the compass even if it were turned on.

In the above log, I attempt to use GPS autoconfig and mess up the GPS type, it is supposed to be ublox movingbase-rover. I will fix this tomorrow, but before the majority of the log this was set to type=ublox This configuration works for us in versions 4.3.8 but not after, and I don’t know why.

I am at a loss

Is your update rate higher than 5Hz all the time?
If it drops bellow it it will be marked unhealthy and it will cause the problems you are seeing.

Reduce the number of active constellations.

Yes, in this case the message rate stays around 200ms for most of this log.

Solution:

So like has been said many times before on this forum, the Ublox gps driver in ArduPilot is very particular about knowing the expected radio configuration, regardless of the actual state of the gps configuration. For instance, if you have a properly configured ublox radio, but ArduPilot parameters indicate that the expected configuration doesn’t match what is seen, various aspects of the gps solution will be rejected.