GPS information

[PhilipLeitch]

Hi.

I have a big project land on my desk using GPS in conjunction with RFID to measure every pickup of every bin in a Local Government Authority area. That's about 150,000 bins.

I tried to search this forum but I'm not turning up much on GPS - so please feel free to reply with links to older messages.

The information I'm after is:
1. What's the best equation to calculate point to point distance between two sets of longitude and latitude co-ordinates? It needs to be accurate to about 0.5 m (when the points are accurately known).

What I've done so far is to use the "Great Circle Distance" - estimating the radius of the earth between the two points based on a Radius at a given geodetic latitude (http://en.wikipedia.org/wiki/Earth_radius) Is there a better calculation, or will that suffice?

2. What's the normal variance on GPS devices?

3. Can someone give a quick run down on the process of Differential GPS, and how I might implement it. I have a couple of dozen trucks that collect data from known locations - approximately 10,000-20,000 reads per day for all trucks.

My thought is that any distortions could be detected and accounted for by using all trucks data. This would increase the accuracy of the GPS reads.

The reason an increased accuracy is advantagous is when we have an unexpected scan of an RFID (bin). This means that either the bin is stolen,
misplaced or otherwise "away" from where it is meant to be. Also, when we "FAIL" to read the RFID (but we do read the GPS), it would be good to find the actual house accurately.

Thanks,
Philip
___________________
Nobody can hear you scream in Euclidean space.

[IRstuff]

On 12/3/2009 9:01:18 AM, pleitch wrote:
>Hi.
>
>I have a big project land on
>my desk using GPS in
>conjunction with RFID to
>measure every pickup of every
>bin in a Local Government
>Authority area. That's about
>150,000 bins.
>
>I tried to search this forum
>but I'm not turning up much on
>GPS - so please feel free to
>reply with links to older
>messages.
>
>The information I'm after is:
>1. What's the best equation to
>calculate point to point
>distance between two sets of
>longitude and latitude
>co-ordinates? It needs to be
>accurate to about 0.5 m (when
>the points are accurately
>known).
>
>What I've done so far is to
>use the "Great Circle
>Distance" - estimating the
>radius of the earth between
>the two points based on a
>Radius at a given geodetic
>latitude
>(http://en.wikipedia.org/wiki/
>Earth_radius) Is there a
>better calculation, or will
>that suffice?

That should be adequate, depending on the size of the area of interest, and the accuracy of the GPS itself.

>
>2. What's the normal variance
>on GPS devices?

That varies. Consumer devices generally are in the range of 10m CEP, adequate for driving and hiking. High end non-DGPS can get down to around 1m-2m CEP, often with post processing. However, it requires that the datalogs include the raw pseudoranges.

DGPS and RTK can get down to around 1cm CEP, but requires a base station that broadcasts error corrections in real time.

>
>3. Can someone give a quick
>run down on the process of
>Differential GPS, and how I
>might implement it. I have a
>couple of dozen trucks that
>collect data from known
>locations - approximately
>10,000-20,000 reads per day
>for all trucks.

Generally, you need to buy the equipment that supports it. Trying to do "poor man's" DGPS usually fails miserably. While your trucks have GPS, they might not have DGPS.

>
>My thought is that any
>distortions could be detected
>and accounted for by using all
>trucks data. This would
>increase the accuracy of the
>GPS reads.
>
>The reason an increased
>accuracy is advantagous is
>when we have an unexpected
>scan of an RFID (bin). This
>means that either the bin is
>stolen,
>misplaced or otherwise "away"
>from where it is meant to be.
>Also, when we "FAIL" to read
>the RFID (but we do read the
>GPS), it would be good to find
>the actual house accurately.

Are the bins always carried by the trucks? So, presumably, a truck will go to a bin, scan its barcode, pick it up etc? Do you need real time, or postprocessed accuracy? How much are you willing to spend?


TTFN,
Eden

[IRstuff]

It's a bit hazy as to why you need to calculate delta angle distances, since you should have all the absolute positions from the trucks?

TTFN,
Eden

[PhilipLeitch]

Hi.

Bins are domestic "wheelie" bins. Large household bins that are wheeled to the kerb for collection. As they are collected the RFID is scanned.

The problem is that bins do funny things. They get stolen, misplaced, tags stop reading and unexpected bins might start getting scanned.

So it would be really helpful to know with reasonable accuracy where a truck is when one of those events happens.

I'm using the detla record (distance) to create a circular confidence interval for every property.

So far I'm getting a round about 10m as a 95% confidence interval.

Thanks,
Philip
___________________
Nobody can hear you scream in Euclidean space.

[AlvaroDíaz]

I think that you must to "calibrate" the confidence intervals. This is take a sample (very small, i assume) of trucks and tell they that via radio (all trucks have a radio, isn't?) asking where are they actually and compare with the GPS information, assuming also that you have a cartographical information of the avaible locations with long and lat in the maps.

The most important number could be the size of the sample, which is what determine the cost of the studie if it is one; if the trucks are all from the same company probably you need to talk only with the radio operator to collect the data.

If the number of trucks are enough big, I assume that not all have the same model of GPS, so, in the sample study you must to include the fact that you collect data for all kind of GPS artefacts, not only for a few models, this introduces a ponderation in the sample population.

Regards. Alvaro.

[IRstuff]

For your specific application, the usual GPS might have an issue, since they don't normally output the positions to any useful port.

But, there are plenty of USB-based GPS receivers that would be adequate for that, and whatever is hosting the RFID reader can simply query the receiver for the current position.


TTFN,
Eden

[IRstuff]

OK, so these are a bit like garbage bins we have at home?

Then, the usual Garmin or Magellan GPS used for driving would be adequate, since they do force fit the position to the street that the vehicle is driving on.

In that case, all you'd need is to grab the GPS position of the truck at the time you read the RFID.

I'm still a bit hazy as to your delta position; what are you using for the baseline position?

Attached are two files you might find useful. There's a source document showing the calculations of LLA to ECEF and vice-versa, and the Mathcad sheet that implements the equations. There are several different ways of getting from ECEF to LLA, but this is the only one I've seen that does the calculation in a closed form, as opposed to an iterated solution.

TTFN,
Eden

[StuartBruff]

On 12/3/2009 4:32:25 PM, pleitch wrote:
== So far I'm getting a round about 10m as a 95%
confidence interval.

10 m? Might work in Australia but in our urban
environment, some of the houses are closer together
than that, and some of the neighbours have a habit
of putting their bins near each (and if they don't,
the dustbin men, sorry, waste disposal
operatives, will). Blocks of flats must be a
nightmare. Still, I suppose if you're only dealing
with a few "wrong 'uns" it might not be too bad.

Stuart

(given how cheap RFIDs are, could they put several
on each bin, to avoid the 'not working' scenario?)

[AlvaroDíaz]

On 12/3/2009 4:32:25 PM, pleitch wrote:
>Hi.

>The problem is that bins do funny things. They get stolen, misplaced, tags stop reading and unexpected bins might start getting scanned.

So you have a sensor that tell you that the GPS is working or not, and this sensor never fail.

>So it would be really helpful to know with reasonable accuracy where a truck is when one of those events happens. This is the main assumption: all recorded values from the GPS are exact or you know that they have a failure.

This is an extrapolation of the x-y position as function of the time. You can take the Bezier curve or other graphics taking t as geometrical parameter, eliminate t from the equations if want to have the orthogonal equation, and regard over the curve for 'future' values of t. It's important which time take you for fix t=0. One hour back to the failure? Half hour?

Notice that mathematica have (version 5 i think) a package to numerically eliminating the 't' parameter from an x=x(t), y=y(t) set, this is what I meaning as orthogonal equation (numerically, not algebraic form).

Regards. Alvaro.

[ptc-1368288]

Hello, Philip.

I read your request in diagonal and found a work sheet from collab. No idea if it will help or not, hope so.
Merry Christmas and happy New year.

Jean is gone for a while.

[ptc-1214470]

Here is a file that provides information on several spheroid models including the WGS84 model used by the GPS system (slightly dated but I think still valid).
Jim S.

[ptc-1214470]

Regarding GPS accuracy - my Garmin 2720 generally indicates 8 - 11 feet as its "accuracy" - whatever that means.
Jim S.

[PhilipOakley]

Philip,

You will need to determine the overall area over which you want to achieve your relative / absolute accuracy.

The formulas for converting GPS readings to position, are not hard for the mathematician, but most (on the web) are simplicfications.

One key question is whether you are merely attempting relative accuracy [same place today, tomorrow, next week, style] or absolute accuracy [so you can compare with other peoples data].

Differences between coordinate systems can be massive (hundreds of metres] but those errors are common and systematic. The second part is then changes in system curvature which creates run off between systems.

For example the Britich national grid assumes the centre of the earth is in a different place, with axes at a different angle, a different radius of curvature and elipticity compared with the GPS standard(S), and then flattens the prionted maps in its own particular way.

These issues of detail are usually only applicable when needing absolute accuracy with cross refernce to other systems. The very simple spherical earth is good enough for local relative positions.

10m feels reasonable for repeatability of a typical GPS reciever.

Philip Oakley

[bridgefield-dis]

Having read this thread up to this point, it seems that you may be asking a bit too much of the GPS system, but ignoring information that you should already have to hand.

I take it that your problem is that you need to know at any time which bin is on the back of the truck (checked by the RFID ) or - in the event that RFID is defective because of damage, which one it ought to be and (presumably) to check that against a list of the bins which should be at that location. (Presumably, several bins collected at each stop, so the data handling may be a bit more complex)

I assume that the truck is like the ones that pass my window each week and that the bins are manually loaded, two at a time, by people who walk/ride with the truck down the road. The computer doing the identification is presumably in the truck which also carries the RFID scanner. That could also have the base data of where each bin is meant to be on a chip plugged into a USB port and also the GPS which need only be of the standard type with road maps included.

Since the truck is unlikely to drive far from the paved roadway and always be on the side of the road indicated by its direction of travel, the need for 0.5m accuracy in the GPS position is hardly critical. The places where it stops to process the bins will be pre-determined, plus or minus a few metres and the bins/groups of bins will be presented in more or less the same order each time.

Exceptions could be where large apartment blocks are visited or when snow or roadworks cause a detour. In those cases, the driver might need to enter some data manually, but not necessarily so.

When a bin shows up at the wrong address or a new bin is left or the RFID indicates that it is damaged by giving the wrong ID or fails to operate at all, then a replacement RFID could be (? slotted into a holder or whatever) and its ID entered into the database and/or a log via the reader or barcode scanner.

If that is considered too time disruptive for the smooth running of the collection team, then there would have to be a follow-up van with the RFIDs and an identical database, such as would probably be required to install the RFIDs before the first such collection.

In any case, the GPS is the coarse level of location, the sequence of finding the bins (or groups of bins), compared to a listing off the database gives the correct position. The trucks will not be moving at all fast when actually collecting bins. Most GPS tend to give better locations the longer they are in one spot, or the slower they moving because the number of readings from the satellites aggregate, so I do not see that there should be a problem using standard (hence relatively inexpensive) automotive kit.

Tom Radford

[PhilipLeitch]

Firstly, thank you to everyone who has provided feedback. This post inparticular asks questions and makes statements that clarify the situation.

On 12/11/2009 3:13:43 PM, bridgefield wrote:
>Having read this thread up to
>this point, it seems that you
>may be asking a bit too much
>of the GPS system, but
>ignoring information that you
>should already have to hand.

No - I'm not asking any more of the GPS system than what it is giving me. The GPS system (which is integrated via USB) seems relatively accurate. My intention is to focus on the information I have at hand.

>I take it that your problem is
>that you need to know at any
>time which bin is on the back
>of the truck (checked by the
>RFID )

No - these are "Wheelie Bins", or "Mobile Garbage Bins" - they are large 140 and 240L bins with 2 wheels at the base and handles that are wheeled to the curb and collected. On collection the RFID is scanned and geolocation recorded via a GPS read.

or - in the event that
>RFID is defective because of
>damage, which one it ought to
>be and (presumably) to check
>that against a list of the
>bins which should be at that
>location. (Presumably, several
>bins collected at each stop,
>so the data handling may be a
>bit more complex)

Yes - spot on and there in-lies the problem. Once the data is "sorted out" there should be relatively few exceptions as I will know where all the bins are. The delivery of the bins was done poorly, and the data was not maintained as bins were removed and added to various locations throug normal maintenance. But once I get it back in sync all should be okay.


>I assume that the truck is
>like the ones that pass my
>window each week and that the
>bins are manually loaded, two
>at a time, by people who
>walk/ride with the truck down
>the road.

No - the company I work for created a system now used throughout the world. The bin has 1 driver, and an arm that can extends out, grasps the bin (wraps a rubber belt around the bin), lifts it over a hole on the top of the truck upsidedown so the rubbish just falls into the truck. So it's all automated.

>The computer doing
>the identification is
>presumably in the truck which
>also carries the RFID scanner.
>That could also have the base
>data of where each bin is
>meant to be on a chip plugged
>into a USB port and also the
>GPS which need only be of the
>standard type with road maps
>included.

Yes - but the sensors are on the arm that collects the bin. However the road map system (a seperate sub-system) isn't that accurate either. The only reliable read is the GPS.

>Since the truck is unlikely to
>drive far from the paved
>roadway and always be on the
>side of the road indicated by
>its direction of travel, the
>need for 0.5m accuracy in the
>GPS position is hardly
>critical. The places where it
>stops to process the bins will
>be pre-determined, plus or
>minus a few metres and the
>bins/groups of bins will be
>presented in more or less the
>same order each time.

Yes - this is also true/accurate.

>Exceptions could be where
>large apartment blocks are
>visited or when snow or
>roadworks cause a detour. In
>those cases, the driver might
>need to enter some data
>manually, but not necessarily
>so.

It doesn't snow in this part of the world, but we want to keep data entry to a minimum.

>When a bin shows up at the
>wrong address or a new bin is
>left or the RFID indicates
>that it is damaged by giving
>the wrong ID or fails to
>operate at all, then a
>replacement RFID could be (?
>slotted into a holder or
>whatever) and its ID entered
>into the database and/or a log
>via the reader or barcode
>scanner.

Yes - true. Also true when a bin is reported as stolen, missing or burnt. We have systems to do this, once we find out which bin is missing the RFID (process of deduction given the area the bin was scanned and which other bins were scanned).

>If that is considered too time
>disruptive for the smooth
>running of the collection
>team, then there would have to
>be a follow-up van with the
>RFIDs and an identical
>database, such as would
>probably be required to
>install the RFIDs before the
>first such collection.

Yes - this is what is in place. There are about 50,000 locations, most done weekly and some days 15,000 bins are scanned. So we have a follow up "Ute" (utility vehicle - like a sedan with a tray on the back... a small pickup truck).

>In any case, the GPS is the
>coarse level of location, the
>sequence of finding the bins
>(or groups of bins), compared
>to a listing off the database
>gives the correct position.

It should do.

>The trucks will not be moving
>at all fast when actually
>collecting bins. Most GPS
>tend to give better locations
>the longer they are in one
>spot, or the slower they
>moving because the number of
>readings from the satellites
>aggregate, so I do not see
>that there should be a problem
>using standard (hence
>relatively inexpensive)
>automotive kit.
>
>Tom Radford

Also true.


I've found, as other suggested, that there is little point in attempting to correct. The deviation of bin collections from the mean location appears constant from day to day. I had expected that the collections would drift - say to the top right on one day due to daily variation. That's not the case so there is no point in correcting for it.

I'll attach a worksheet in a couple of days. showing the quality of the data and the issues at hand.

What I'm doing right now is geo-coding the street addresses, which aides in identifying where "unexpected" bin scans are coming from.

I'm also generating run information - just at the street level at this stage, to provide sequence scanning to identify locations of unexpected scans.

It's all coming together quite well.

Philip
___________________
Nobody can hear you scream in Euclidean space.

[PhilipLeitch]

Previously I said the data from GPS at time of collections was good, I thought I'd share some figures.

The deviation of bin scans from their centroid is shown on the attached images, with the Z axis showing the number of occurances at that position.

The total mean distance from the centre of previous collections to each new read is approximately 2.7 to 3.4 metres (depending on the day), with a standard deviation of approximately 2 metres.

This is far more precise than I first thought I would get.

The variation comes from where residents place their bins, where the truck is on the street when it makes the collection (the collection arm can extend out and forward/backward), and the variation of the GPS system. Given all this variablility it really shocked me that the precision was actually that good.



Philip
___________________
Nobody can hear you scream in Euclidean space.

[IRstuff]

GPS variability is highly dependent on atmospherics and satellite visibility. Your latitude looks pretty good, so then it depends on hills, trees, etc. If RF obstructions are sparse, then yuo should have pretty good consistency in GPS performance.


TTFN,
Eden