I’ve equipped a rather big skid-steer lawn mower with ArduPilot (with Pixhawk 6X, F9P GPS, Raspberry Pi as companion for RTK etc.). Currently, I’m trying to make it navigate properly The basic tunings have all been done.
But what I’m having big issues with is the heading. After pivot turns, the heading is usually off by 5-40 degrees… Compasses just seem not reliable in this case (it’s a big metal frame vehicle with big electric motors), so I had to give up using those compasses and tried using GSF instead (Compass-less Operation — Rover documentation).
I was hoping to achieve a quite precise heading with that (I’m also using RTK with a second F9P at my ground station). First tests looked promising, after moving a little bit it learned the correct heading. But over time, the heading was getting worse again, like it was not learning from the GPS anymore. In fact, looking at the messages in Mission Planner, I saw that it set the yaw two times, but then no more.
So my question at the moment is, does this have to do with EK3_GSF_RST_MAX being set to 2? I was thinking (or hoping…) that the GSF would constantly provide reliable yaw, not just “calibrate” the IMUs initially…?
Thanks very much for helping me understand more
PS: I think dual GPS for GPS yaw would be a good solution in this case, I’m just not having a second (or third with RTK base) F9P here at the moment. Anyway, I don’t see why GSF shouldn’t lead do decent results, too.
GSF is ok in my experience, but it should be more of a backup than a primary source, especially on a large ag vehicle for all the reasons you have already discovered. Look into that second onboard GPS and a moving baseline configuration.
The max reset param seems to do exactly what you think it does, and I don’t see a way to allow unlimited resets.
Alright, thanks for confirming! I’ll definitely try a second onboard GPS in the future.
But for now, what I understood is that GSF is only being used for a limited amount of yaw corrections (2 by default, EK3_GSF_RST_MAX can be 1-10 according to the documentation). It will then still drift away depending on the IMU’s precision, vibrations ect…
Do you happen to know the reason behind this? To me it would make more sense to be able to use GSF in a continuous way - even if it’s only used as a backup for other yaw sources?
I’d wager a guess that it has to do with a backup-systems mentality. In the case of GSF-fallback from another system, you may not want to continually reset, since that may just be contributing to already existing problems.
Not sure why there is a hard limit when it’s advertised as a potentially primary source, though.
You’re right, it looks like GSF is advertised as alternative primary source in the documentation.
I didn’t find many info about the EK3_GSF_RST_MAX parameter, Rover-4.1.0-beta7 has been released for beta testing! mentions “EKF3 GSF can be invoked multiple times with source switching (no longer limited by EK3_GSF_RST_MAX)” under bug fixes.
Let’s hope somebody with some “EK3 GSF developer knowledge” stumbles across this thread to enlighten us further!
I’ve been digging into the code on GitHub a little bit. If I’m not getting it wrong, EK3_GSF_RST_MAX applies to emergency_reset only (e.g. after compass fail).
The “regular” GSF yaw should update continuously, but only if the yaw variance (GSF.yaw_variance) exceeds a hard-coded threshold of 15 degrees specified in AP_NavEKF3_core.h:
#define GSF_YAW_ACCURACY_THRESHOLD_DEG 15.0f
This would make sense with my latest compass-less test drive today, about 30 minutes - yaw was slowly drifting away and navigation got worse, but as the variance still remained under 15 degrees, no correction/update to the IMU happened.
I’m really curious if this threshold could be reduced to like 5 degrees or even less when using a good GPS with stable RTK fix, maybe making a second onboard GPS for yaw unnecessary?!
The basic tunings have all been done.