GPS 'Lag'

[Jerry Heim]

I purchased a LS20031 recently--I wanted to upgrade from the EM406 I used last year.  The 5Hz update rate of the LS20031 is an appealing feature, but there is a problem...

I modified the code in my vehicle for the LS20031, but I notice some strange behavior with the LS20031--the GPS readings sometimes seem to lag behind where the vehicle actually is.  For example, I'm carrying my vehicle and watching the current lat and lon readings on the LCD.  I stand still for a while and then walk due south.  The GPS readings don't change for several seconds and then they quickly 'catch up' to my current location.  There are other times when there doesn't appear to be a lag.

I'm running the LS20031 at 5Hz.  WAAS is enabled.

Has anyone seen this kind of behavior?  Any pointers to possible 'fixes' or other diagnostics?

Thanks,

-Jerry (Team Viator)

[Josh Pieper]

Jerry,

Well, there is a chance you have serial port buffering problems, but
hopefully you've already investigated those.

What you're likely seeing is the internal Kalman filter that most
cheap GPS receivers have to compensate for their consumer grade
components. The receiver assumes some motion model, and tries to fit
the measurements to that model. This can manifest in many ways,
especially because some receivers have special handling for "stopped",
for which the exit conditions are relatively opaque to end users.

If you're lucky, the receiver has a mechanism to configure how much
filtering to apply. For instance, u-blox receivers have a few limited
options, such as motionless, pedestrian, car, 1g airplane, 2g
airplane, and 4g airplane. However, even with them, there is no way
to turn the filtering off entirely.

I briefly tried to use an MTK receiver, but it had even more problems
than the u-blox I was comparing it against, particularly at low
speeds. Additionally, it had no observable configuration for the
filter that I could find at all.

The good news, is that if you're moving at a constant velocity without
turning, the position will eventually "catch up", and the measurements
will be good. You'll just have the lag during periods of acceleration
or deceleration, when turning, and when starting and stopping.

That said, pretty much all consumer grade GPS have odd behaviors like
this. I just posted a video covering a different one from our u-blox:

https://www.youtube.com/watch?v=e_yNZ1WovB0

-Josh

[Michael Shimniok]

Yes. It is probably due to the filtering. My Venus lags by 1 sec. My Sirf Star III did too. 

I have a whole blog write up on lag compensation. I lagged the gyro signal before fusing with GPS heading to get a heading estimate. 

I took the error between gyro computed heading and estimate and then corrected both present computed heading and position estimate (via simple rotation) to arrive at a current pose estimate. 

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/f782c3b7-38af-43a6-b6ca-051a2bb13a45%40googlegroups.com?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jerry Heim]

Jason and Michael,

Thanks for your prompt responses.  Jason, I'm sure that it isn't a serial port buffering problem--good suggestion though. 

I figured it had to be a filtering issue--it's not a surprise that they'd need to do some filtering, but I sure wish they'd disclose this stuff.

I guess you guys have already learned to live with this GPS position delay.  I can do the same.  Michael, I'll look for your blog post on GPS delay.

We're looking forward to seeing you guys in 6 days!

Thanks again,

-Jerry (Team Viator)

[Michael Shimniok]

Here is the link

http://www.bot-thoughts.com/2012/07/avc-heading-and-position-estimation.html

It turns out I had a bug in the computed heading correction. Still investigating all the implications. Won't be able to do more until I get back to Denver and my new Venus arrives

Michael

Sent from my iPhone

--

You received this message because you are subscribed to the Google Groups "diyrovers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+...@googlegroups.com.
To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/0fa908ac-d535-4f90-9c00-0c0c8ea60c5e%40googlegroups.com?hl=en.

[wholder]

I asked u-blox technical support about this issue a few months back when I was first considering using the LEA-6H.  Here's the question I sent them:

"I'm working on a mathematical model to fuse GPS position data with odometry using one of your LEA-6H modules.  I need to come up with an estimate of the internal processing lag between when a fix is received vs when it becomes available in the NMEA serial stream.  I relalize that part of the delay comes from the time needed to send a complete NMEA sentence, but I suspect that are other delays possible in the algorithms used to process and filter the fix inside the LEA-6H.  Do you have any information that would help me characterize this delay?  Also, do you have similar data that migth help be predict position fix error under conditions of linear and angular acceleration?"

The response I got back included a typical corporate "confidential" postscript, but I think it's OK to summarize what I was told, which is that the receiver actively keeps its time synchronized to the GPS system clock and as such there is no inherent latency in the position solutions. However, in addition to the message transmission delay, there is an approximate 100 millisecond latency caused by the communication task running at 10 Hz to output any available messages. This scheduling latency is independent of the receiver's navigation update rate and should remain approximately constant.

Wayne

[Michael Shimniok]

On Sunday, June 2, 2013 7:56:18 AM UTC-6, Josh Pieper wrote:

That said, pretty much all consumer grade GPS have odd behaviors like
this.  I just posted a video covering a different one from our u-blox:

https://www.youtube.com/watch?v=e_yNZ1WovB0

Wow, that is utterly bizarre. I've not yet seen that particular drastic behavior with the Venus or SiRF modules. I'm extremely curious to see if I can reproduce it and if anyone can find any further explanation behind this behavior. I should think this would impact lots of ArduPilot/Rover/Copter folks.

Interesting information on uBlox GPS lag. I'm not sure if the Venus produces up-to-date position solutions or not.

Hope everyone is having good luck in the final stretch. The new Venus arrived as did my OSHpark baseboards.

Michael

[Josh Pieper]

Michael Shimniok wrote:
> > That said, pretty much all consumer grade GPS have odd behaviors like
> > this. I just posted a video covering a different one from our u-blox:
> >
> > https://www.youtube.com/watch?v=e_yNZ1WovB0
>
> Wow, that is utterly bizarre. I've not yet seen that particular drastic
> behavior with the Venus or SiRF modules. I'm extremely curious to see if I
> can reproduce it and if anyone can find any further explanation behind this
> behavior. I should think this would impact lots of ArduPilot/Rover/Copter
> folks.

I believe that it is caused when a single channel starts to lose code
tracking, which can happen with either multi-path or low signal
strength. Thus, it will be much more likely for ground applications
where there is a chance of satellite line of sight paths intersecting
trees, buildings, and pedestrians. I've seen it happen on satellites
as high as 30 degrees elevation, so upping the elevation mask isn't
really an answer. For aerial vehicles however, they can generally be
clear of all obstructions and thus it might not be a factor for them.
I also have my u-blox's filter set to 1g airplane mode, which probably
makes it more observable than if you leave it in the default
pedestrian mode.

That said, while moderately frequent, it doesn't cause disruption that
often. While some manifestation seems to occur for 5-20s out of every
10-15 minutes of moving around, not all are problematic. Some are of
much smaller, the magnitude seems somewhat randomly distributed
between 2 and 20m with a bias towards smaller slews. Some of the
times, it happens along the direction of motion and thus you don't
observe any poor driving behavior. The day the dataset in my video
was collected we ran maybe 20 or 30 laps over about 2 hours and that
was the only time that particular phenomenom caused a failure.

> Interesting information on uBlox GPS lag. I'm not sure if the Venus
> produces up-to-date position solutions or not.

Since you have accurate encoders, that is pretty easy to determine.
Just plot the speed as measured by your encoders against GPS speed
under acceleration and while starting and stopping. I've found the
u-blox to be pretty repeatable in these situations. The MTK receiver
I tried had some apparently multi-pronged internal criteria for
kicking itself out of "stopped" mode, and thus it was difficult to
predict when it would start trying to catch up with you from a stop
when moving slowly.

-Josh
http://joshp.no-ip.com:8080/

[Michael Shimniok]

On 06/04/2013 05:14 AM, Josh Pieper wrote:
> While some manifestation seems to occur for 5-20s out of every 10-15
> minutes of moving around, not all are problematic. Some are of much
> smaller, the magnitude seems somewhat randomly distributed between 2
> and 20m with a bias towards smaller slews. Some of the times, it
> happens along the direction of motion and thus you don't observe any
> poor driving behavior. The day the dataset in my video was collected
> we ran maybe 20 or 30 laps over about 2 hours and that was the only
> time that particular phenomenom caused a failure.

Cripes, where do you find time to do 20 or 30 test runs?? :D I'm lucky
if I can that may laps in during a month... usually between 9pm and 1am
after little girl's asleep. :)

I find it a bit baffling that the firmware doesn't address this somehow.
Is it just me?

> Since you have accurate encoders, that is pretty easy to determine.
> Just plot the speed as measured by your encoders against GPS speed
> under acceleration and while starting and stopping.

Ah. Of course. Speed has never appeared to be lagged (except
transmission/parsing time) now that I think of it -- and I just plotted
some recent data, too.

> I've found the
> u-blox to be pretty repeatable in these situations. The MTK receiver
> I tried had some apparently multi-pronged internal criteria for
> kicking itself out of "stopped" mode, and thus it was difficult to
> predict when it would start trying to catch up with you from a stop
> when moving slowly.

Is that position pinning then? Or something else, yet? The Venus has
various configurable thresholds for position pinning and one can also
disable position pinning altogether.

Michael

[Ted Meyers]

So, I'm assuming it is best to disable pinning?  Also, does anyone have an idea of which GPS mode is best for our application?  It seems like "car" mode works better than "pedestrian" (at least on the Venus).  I don't think that there is an aircraft mode.

--
You received this message because you are subscribed to the Google Groups "diyrovers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to diyrovers+unsubscribe@googlegroups.com.

To post to this group, send email to diyr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/diyrovers/51ADF822.20007%40gmail.com?hl=en.

[Michael Shimniok]

On 06/04/2013 08:35 AM, Ted Meyers wrote:
> So, I'm assuming it is best to disable pinning?

I don't really know for sure. I don't know what the old GPS was
configured with (it's not transmitting data so I can't query it). I
think I disabled it. If you're using GPS position in your algorithm
maybe it makes sense to enable pinning but set the thresholds so that
when you're sitting on the starting line the robot can get the most
accurate estimate of position possible before it starts off?

> Also, does anyone have an idea of which GPS mode is best for our
> application? It seems like "car" mode works better than "pedestrian"
> (at least on the Venus). I don't think that there is an aircraft mode.

You're right, no aircraft mode. I use the "high dynamic range" firmware
and car mode. Even so the heading data looks to be fairly heavily
filtered (low pass). I'm not sure what pedestrian mode would do,
probably more filtering/accuracy if anything, given the slow speed.

Michael

[Michael Shimniok]

Just for the record...  Based on testing, it looks like I'm getting about 400ms lag on the uBlox GPS, give or take. I've been too busy to calculate how much of that is transmission and processing delay. And I haven't done enough testing to know if that delay is fixed or not.

Michael