Newest Ardurover 4.5.5, though this occasionally happened on previous versions at same random intervals.
Occasionally when running the Auto mission, the rover will drive right to the waypoint, then continue to do pivot turns and drive around and through the waypoint. Below is my screenshot showing the waypoint distance which usually stays at 1 meter at this point. Normally I have the WP radius set to 0.2 meters, but when the problem occurs I try setting WP radius larger (currently 0.4M) with no improvement.
Ignore the squiggly track up to the waypoint, I’m experimenting with Lidar proximity sensor. This issue occurred before the sensors where installed however.
All the COMPASS_USE parameters are set to 0. So the compass is not being used to calculate heading
Are you using an external compass? I’m seeing some noticeable offsets between the predicted heading and compass heading (15-30 degrees), which can be indicative of magnetic noise.
Indeed, there is no yaw source. The Rover knows where it is and where to go, but it’s having a hard time pointing in the correct direction via GSF alone.
Well, I’ll enable the compass and try again. As many times as I’ve Enable/Disabled it, I’m not sure of the state when this happened previously.
Speaking of yaw, how can you tell that there is no Yaw source? I had mistakenly believed that the Wheel encoders were being used to assist Yaw. I entered X and Z positions for them, so thought they were being used for more than mere velocity. Now that I think about it, I suppose to know the velocity at the origin, you WOULD need to know how far away the encoders are.
Here is the Log Browser showing HDOP and Waypoint distance. The rover is traveling from waypoint 1 to waypoint 2. HDOP remains very good, but you can see that WpDist starts out high then bounce between 0-1M and a decreasing distance, and by the middle of the plot is bouncing between 0 and 1 M. WP_Radius is 0.4M so the waypoint has been reached many times:
I shouldn’t say no yaw source. GSF is your only yaw source. This means that the vehicle has to be in motion to know its heading. GSF often drifts quickly at slow speed because it’s subject to the “noise” in GPS course (any small variation in fix position returns a course containing that variation). You can see this clearly by plotting any of the yaw estimates against GPS[0].GCrs.
In very layman’s terms (and perhaps verbiage with which someone more versed in state estimation may take issue), GPS is taken as “truth” data to update EKF state. In the absence of GPS course, IMUS and encoders fill in the gaps, and as soon as GPS course updates, the other hardware is “aligned” to it, which accounts for the messy plots. There may be some parameters you could use to change the weighting of each, but the reality is that the approach you’re taking at present is not likely to succeed.
I’d have to dive deeper than I’m willing into the source code to determine exactly why the waypoint isn’t registering as reached, but I’d surmise that it’s because it’s looking for a valid solution to the next waypoint before registering the current as complete, and as you can see, it really has no idea which way it’s pointing.
TLDR; you need a compass or a moving baseline GPS yaw source.
Thanks Yuri, i have ordered a HolyBro RM3100 compass to mount externally. This was always on the back burner, just got moved up
Tested this mission with internal CubeOrange compass re-enabled, and still not reaching the waypoints. Tried disabling proximity sensors by setting AVOID_ENABLE from 3 to 1, leaving Fences enabled. No help. Set AVOID_ENABLE = 0 to disable fences, No help. I had assumed that AVOID_ENABLE was the master to disable Avoidance.
Set OA_TYPE = 0 to disable Bendy Ruler, Voila!!! It now hits the waypoints properly. What on earth is Bendy Ruler trying to do if AVOID_ENABLE mask is set to 0???
Perhaps I missed a key element. I am not going to dig further for now, but this is my guess:
I did see a lot of fence messages in your log, and I think perhaps you had a waypoint inside a fence, which will exacerbate the issues you’re having because not only are you at slow speed with a wandering yaw solution, but it can’t achieve a waypoint that falls inside a fence.
AVOID_ENABLE has nothing to do with Dijkstra or BendyRuler avoidance. It’s for simple avoidance only.
I have been thinking about this, is it practical to install wheel encoders and use this “dead reckoning” data in combination with a single GNSS antenna for yaw estimates? Assuming the tire diameters are equal it should be able to achieve equal RPM on both wheels quicker and more accurate than sampling compass and GPS data to achieve a straight line?
Encoders probably won’t hurt, but I think the approach is still flawed. How is the EKF supposed to account for wheel slip or tire deformation/deflation? I think the answer we’d find in the source code is GPS. So you’d almost certainly have identical behavior with more complexity.
Try the RM3100. It’s a good compass module. If it is interference prone on your vehicle, the solution is moving baseline GPS.
