I just put together a new platform and I have been noticing a strange bug where immediately after boot the heading of the drone is almost 180 degrees in the wrong direction and the EKF is red. If I leave it alone for 10 minutes it will eventually correct itself and everything works as normal.
At first I thought maybe the setup for the GPSs was incorrect but since it would randomly correct itself over time I now suspect otherwise. I have setup drones with GPS for yaw like this in the past without issue and normally these GPS units get a 3d fix really quickly and EKF issues are cleared within a minute or so of booting. I’m using a pixhawk 6x with dual helical F9p HRTK units, the GPS connected to the GPS1 port is the primary and mounted to the left of the flight controller, the other is mounted to the right.
My question is, is this likely to be a hardware issue with the pixhawk or GPS units or is it possible that it’s a parametrization problem? I have attached my param file but let me know if a disarm log is required to better identify the problem.
Thanks!
GPS yaw issue.param (19.1 KB)
First things first - initial startup heading is due north until a yaw source is present. If your vehicle is facing south when booted, it would be normal to see a 180 degree disparity in heading for some period of time until initialization is complete. The typical culprit for poor GPS performance is an obstructed view of the sky (testing indoors or near buildings/trees). Rule that out first before reading further.
Otherwise:
I wonder if the compass orientation is 180 degrees from the GPS orientation?
Was the compass properly calibrated (parameter values seem to indicate that at least some attempt was made)?
Does the problem persist if you disable all compasses?
If you recalibrate the compass in use, does any behavior improve?
Other things to check:
Secure GPS antenna connections
Related boot/config messages/warnings
Monitor output of gps2yaw vs yaw on Mission Planner’s Quick tab
Are you really using Copter 4.0? If so, update to latest stable (4.5.0).
Thanks for your response! To address your points:
-
You were correct, the drone was facing south and the heading is facing perfectly north during this error state.
-
It has an unobstructed view of the sky, the batteries are close to one side of the gps but from a top view should be more than enough. (the gps’s have no problem getting a minimum of 27 sats immediately after boot)
-
The compass is an rm3100 and has markings so that it can be oriented manually, enabling auto rot during a calibration shows that the heading is indeed facing forward with the GPS.
-
Yes if i disable all compasses and set the EK3 src to gps only the problem still persists. Setting it to compass only and reenabling allows it to clear any EKF errors after about a minute as it did before.
-
Recalibration of the compass with the same or increased strictness shows the same result.
-
Everything is brand new and secured tightly, I have had the helical antenna unscrew in the past so they are now lightly glued in place.
-
None of the boot messages seem out of the ordinary, the error states that “EKF attitude is bad” for longer than usual
-
I’m using copter 4.5, my mistake with the tag.
I did notice that this problem will not persist if I wait for the heading to correct itself after the drone has sat for a while, then power cycle the system without moving it to a new location. On the second boot everything works within about a minute or two. Moving to a new location makes the error return. I believe perhaps one of the GPS units are faulty but taking a look at them in U center shows that they are up to date and constellations are all set. I may experiment with swapping out the units down the line.
I’m not so sure this indicates faulty behavior, though if you have doubts and the budget to support component swap-out, you could easily rule it out.
You might also try reducing the constellations in use by adjusting GPS_GNSS_MODE and GPS_GNSS_MODE2. Specifically, you might try excluding GLONASS in this day and age…
Also, if a particular constellation consistently shows low SNR in u-Center (most or all signals below 40db in the satellite bar graph), you should probably exclude it as well. 2-3 constellations in use are plenty, but the correct selection for the bitmask highly depends on your location and signal quality available.
I have another smaller drone with a similar setup that works well for the most part so if all else fails I can swap over components to rule out hardware. The fact that it is brand new is making me hesitant but I guess anything is possible. This afternoon I had an instance where the errors were cleared and before I could takeoff they came back and would not clear.
I have attached a log file of a very quick loiter flight and immediately after landing I got the alert stating GPS[2] Yaw not available. I was also noticing the message “PreArm: AHRS: EKF3 Yaw Inconsistent 156deg” as well as “PreArm: Check mag field (xy diff:345>100)” while waiting for the EKF to fix itself prior to takeoff. Additionally I was monitoring the output of gps2yaw vs yaw as you suggested and during this 10 minute stage yaw is held at 0 or 360 and gps2yaw is held at around 645 degrees if I remember correctly. Once the errors are cleared they are both roughly 208 degrees.
I will try raising the mounts for the GPS and see if things improve but after that I will start swapping out components. In my mind there’s no reason why 32 satellites on both GPS units for over 5 minutes shouldn’t suffice to give it an accurate heading.
This log shows no yaw value on GPS2 for its duration, with GPS2 remaining at an RTK Float state (not good enough for moving baseline).
Satellite count does not tell the whole story. However, the other log values do show what appears to be reasonably healthy GPS.
Revisit your GPS_POS* parameters and ensure your measurements are accurate.
Wow now I am very confused, this is the first flight where no GPS yaw value is recorded. In the flight just before that one a GPS yaw value is reported but with constant dropouts. Below is an image of what it looked like on previous flights, not ideal but it was in operation.
I find it very strange that not only was it not recording a gps yaw value but there was no indication that something was wrong right before takeoff or in flight. I know the GPS POS parameters are accurate because I revisited them a few times and looking at the position offset visualization on the hardware report web page shows an accurate representation of the system.
So I will know that the gps for yaw is working well when the second gps has an RTK fix and not float? I normally operate with an RTK base station but for these initial tests I don’t have it running.
The log you showed above was 2 minutes without any GPS yaw indicated.
Moving baseline is INDEPENDENT of your fixed base operation. You DO NOT need a fixed base station to get GPS yaw.
GPS2 will show RTK Fixed when it’s receiving good corrections from GPS1, but that alone doesn’t indicate presence of GPS derived yaw. Monitor gps2yaw in the Quick pane to see that.
I’m asking you to reconfirm that your GPS antenna offset measurements are correct because the signals look healthy, yet the fix state on GPS2 remained at RTK Float, and no yaw was calculated, meaning that something is a bit off. First place to look is an inaccurate relative antenna offset.
