I am streaming position output to another computer from a Reach module used in a Rover.
I’m interested in others’ experience or informed opinions on how to stabilize the LLH values from an output stream.
At the moment, my Reach module will move between Float and Fix modes. Plus, even when standing still the latitude and longitude will bounce around a bit (which is normal).
Is there a “best practice” on how to filter these values (average, rounding, more sophisticated math?)
Is it possible (how?) can I calculate the accuracy as shown in ReachView? In ReachView, under the latitude / longitude it shows accuracy as +/- x.xxx m. How could I get that value?
In my experience, the ground plate is the first place to start. If you are using the antennas that are provided with the reach kit then it’s important to have adequate ground plates. First and simplest check.
Actually, I was talking not so much about just getting a fix, but rather, even after a fix, doesn’t the lat/long values bounce around a little?
In my last test, I was mostly in float mode, so maybe I need to spend more time in fix.
If the numbers move around even in fix mode, I was looking for suggestions on how to have the numbers be steady - either average, truncate, or at least quantify the error.
The reason I bring this up is that I’m going to do some autonomous navigation, so I need to understand when I’ve hit a waypoint. If the number bounces around too much, I won’t be able to compare it to a fixed lat / long waypoint.
I am new to the RTK, but when you switch reach to the base, than there is option that it can calculate its average position based on his location even if it is not fix (you can choose from 2 min up to 30 min, how long its should observate before showing you the average)
I want the position of the rover to be stable, so that I can do a simple comparison against a specific point. What I’ll do is program the rover to travel from current position to target position. As the rover moves, I’ll compare the current position to target position. When it’s equal, I will stop.
When I look at lat / long values with 8-10 decimal places (more?), then I’m sure the rover position won’t compare to my target position so nicely. I’ll need some type of filter or truncation. But, I don’t want to truncate so much that I stop 1m away. I’d like an accuracy of 2-5 maybe max of 10 cm.
Since this is a moving rover, I’m not sure I can use the position average. If I did that, I’d have to limit the number of values, or else the value would move too slow and I’d overshoot the waypoint.
A truncation probably makes the most sense, but I need to make sure I don’t truncate more than the accuracy required.
Ok I had some time tonight to look at some lat / long formulae.
Specifically, the wikipedia pages for latitude and longitude provide formula for the distance for a change in latitude, or a change in longitude. This distance depends on where you’re at on the earth, especially for longitude (of course, note that longitudes (meridians) converge at the poles, so they’re closer together the closer to the pole you are).
If I punch my lat/long into those formula, I have the distance per degree lat and distance per degree long. I then progressively divide this by 10 to determine how many decimal places of lat and long I need for my application requirements.
7 decimal places of accuracy gives me about 1cm.
So, in my control application, I will round to 7 decimal places and see how stable the numbers are.
In my application, I can create a function that compares two points with a given tolerance (e.g., 10cm) and it can determine if the point supplied matches including the tolerance.
the GeodSolve command line utility in geographiclib can take your rover LLH and your waypoint LLH as input and give bearing and distance to the waypoint as output.
With that, you could watch the distance decrease as you approach the waypoint and then start to increase as you pass the waypoint, and then your software can decide if you got close enough to the waypoint, or if you have to turn around and try to get closer on the next pass.
Brilliant! Thank you for sharing that with me. Based on your pointer, I found that library and it’s extremely helpful. I also found it ported to Python. Here’s the link on source forge: geographiclib That will make it pretty easy to implement.
The only other thing is that geographiclib does not consider height. All coordinates are measured directly on the WGS84 ellipsoid. Hopefully you can work with that.
