When the general-purpose NavEKF code is being using on a rover, you’re not likely to have a barometer or an airspeed sensor. So what values are being used or does the code know that these sensors don’t exist? Rovers are really more of a 2D problem than a 3D one so could you skip things like SelectTasFusion and SelectBetaFusion?
It would seem that a 22 state EKF is seriously overkill.
@RogueWarrior,
I have had great success with my rovers when I have left the EKF parameters at their default values which were determined by Paul Riseborough.
Regards,
TCIII AVD
Hmm…well, I ran the thing in both Mission Planner and QGroundControl and I didn’t see any EKF parameters.
But that aside, NavEKF has states for sensor types that rovers don’t have. I’m just wondering what the algorithm is doing when those states have no valid data in them.
@RogueWarrior,
EKF can only run on a PX4 or Pixhawk or the like type of processor.
I counted 24 EKF parameters in my Full Parameter List file.
Regards,
TCIII AVD
Ah ha! That explains a lot. Now, where did I put my credit card?
@RogueWarrior,
The improved mission navigation using EKF is worth the cost of moving up to a Pixhawk and dual GPS configuration like I used during the Sparkfun 2014 AVC.
Competitors could not believe how well my rover negotiated the barrel chicane even though I found out later that I did not have to and that was done without any kind of obstacle detection.
I expect to do much better next year as I have worked out some battery issues that caused a non-start in the second heat of the Peloton Class or I would have placed second instead of 7th:-)
Regards,
TCIII AVD
Awesome. Did you do much tuning of the EKF?
I also try to understand the EKF algorithm. In AP_NavEKF.cpp, in line 820 I found
prevDelAng = correctedDelAng; then in line 824
correctedDelAng = correctedDelAng - prevTnb * earthRateNED*dtIMU + (prevDelAng % correctedDelAng) * 8.333333e-2f;
but from line 820 we know that prevDelAng % correctedDelAng = 0 so why is it here?
Looks like it was a bug that has now been corrected. prevDelAng = correctedDelAng; has been moved BELOW the other line.
Thanks, Grant