I think I’m actually seeing a problem where the EKF is unhappy until a mag cal is performed. We have COMPASS_USE set to 0 due to too much magnetic interference in this platform. It seems that we still have to go through a magnetometer calibration at boot in order to make the EKF happy even if we later “disuse” the compass for flight.
The overall issue we’re chasing is that we sometimes can’t get the craft to use GPS for yaw and ignore the compass. The symptom is that, at boot, the craft will report a heading of 0 degrees, and its heading will drift as if the EKF doesn’t have access to an absolute heading source, regardless of the state of the GPS. In different platforms running the same firmware, the reported heading will initialize to 0 and drift until an RTK fixed solution is achieved, and then the heading will snap to the gps heading. At first I thought that we were having a configuration problem with our GPS where it wasn’t reporting a heading even though it had obtained an RTK Fixed solution. When I investigated the ublox driver I saw several data validity checks that I suspected of preventing us from using the heading message from the ublox for yaw. Some of those checks are simple configuration sanity checks, like is the reported baseline close enough to the vector of the configured gps antenna positions, as well as the various settings under GPS_ that result in configuration changes being sent to the ublox. In our case we disabled GPS_AUTO_CONFIG, but the driver still checks the ublox configuration against GPS_* configuration in order to consider the gps yaw solution to be usable. I relaxed all of those checks and was still having the issue described above, this time I had printouts to tell me if the ublox driver was rejecting the yaw message or not.
After learning here that the EKF has its own gps data health checks, one of the logs I provided showed that I was not configured correctly to allow for the ublox to send gps state at an appropriate rate, which I corrected. However, the problem persisted.
I now believe that in this version of firmware the EKF does a health check that is currently failing at boot, but is cleared by using the mag cal process. For now, it seems like I can get away with using the large vehicle mag cal process since gps heading is reliable, but I don’t understand the blockers here and while the EKF was reporting bad status, it isn’t clear exactly what it’s unhappy about.
In 4.0, support for compass-free operation isn’t available yet, so I suspect I’m running into issues related to this
@rfriedman, this system is also a Planck system. Does any of this sound like it’s related to Planck’s changes? Ostensibly, this firmware has another yaw input that is fed through the EKF and I wonder if there are more checks added that I’m not aware of
