Coordinates from dGPS Not Accurate

[pdmarsh5466]

I’m curious if any other users of the dGPS module have seen this issue. To their credit, the folks at Modular Robotics tried to help, but much of the tribal knowledge from Dexter Industries seems to be lost. I understand. It happens.

When posted on Google Earth Pro, GoogleMaps and other on-line maps, coordinates taken from the dGPS sensor appear about 300 feet south and 10-15 feet west of where the unit actually was when the coordinates were recorded. It was thought that this might be a conversion issue, but when the coordinates are converted to other formats they still appear at the wrong spot as noted above.

They say the sensor isn’t defective and that this is expected behavior from the sensor. If that is so, how do people deal with it? Is there a mathematical equation that needs to be applied to correct the readings, and to change coordinates taken from maps as waypoints so that the dGPS will go to the right spot?

I will take more data from miles apart, but so far the error seems to be consistent. If so, I can fool the sensor and fix data-logged coordinates, but it seems to me that this should really be unnecessary. I also get that if I want to use a waypoint within walking distance, all I have to do is take the sensor to that spot and use whatever is in the datalog. I think that’s what Dexter Industries did with the SARG parking lot test project.

I’ll look forward to any responses.

Thank you,
Paul

[jimrh]

Greetings!

Welcome to the forum!

First, I am not an employee of Modular Robotics and I am not an expert on programming this beastie, but I do know a bit about GPS’s in general and I will do what I can to help.

I also have the dGPS. (I am assuming that is the “Dexter GPS sensor module” with the odd-shaped telephone-type connector.) I purchased this to use with my GoPiGo robot since it can use a GPS sensor.

It turns out that this sensor was intended for something much earlier than the GoPiGo-3, or even the earlier GoPiGo, and I have gotten zero information about it - not even a pinout, let alone a datasheet.

I was told that the GPS module intended for the GoPiGo is designed to plug into the serial connector, which - apparently - this is not designed to do.

What I know about GPS’s is that many of them can be programmed into (what I believe is called) WAAS mode, (a special high-accuracy mode), that can accurately place the device within about ±3 meters, depending on the number of satellites seen and surroundings.

As I remember, WAAS is a mode that is programmatically enabled as a feature of the GPS device and is not enabled by default.  Without WAAS being enabled, the tolerance is something like ±300 meters or so - which is the old “civilian” accuracy for GPS geolocation before President Regan de-classified it.

Since I don’t have any datasheets or other information about the device, there is little else I can do.

If YOU have managed to get better information, to the point that you are actually programming it, I’d love to have a copy!

Once I get to look at datasheets and the like, maybe I can be more help.

Thanks!

[pdmarsh5466]

Hi jimrh,

Thank you for your reply. Interesting information.

I have been taking more readings and, honestly, they are all over the place. I wonder if the WAAS thing has something to do with this. Even the error isn’t consistent, I’m finding. Rarely, but sometimes, a reading is spot on. I’m just not seeing a pattern. At this point, I wouldn’t even be able to recreate Dexter Industry’s parking lot (SARG) demonstration. The rover could go just about anywhere within a good-sized parking lot.

Unless I can figure this out, the dGPS is all but useless for me. Sadly, there don’t seem to be any GPS sensors made for NXTs any more. I don’t have the ability to adapt a sensor to the NXT. I’m guessing it could be done with RobotC or something along those lines.

Well, thanks again. I’ll post any new info I get.

Paul

[jimrh]

Readings being all over the place might be dependent on where you are.

I’ve been in places where my car’s GPS has been crazy.
e.g.

• The mountains of West Virginia.
• Mid-town Manhattan.
• Out on Cape Cod, apparently in the path of a multi-million watt Pave-Tac radar.

Anything that emits a strong microwave signal, or is reflective, (like buildings or ore deposits), can cause inaccurate readings.

Can you / have you checked the number of satellites used and/or the reported degree of precision?

Would you please tell me where you got documentation for your GPS module? I’d like to have a copy.

[jimrh]

@pdmarsh5466

I have been taking more readings and, honestly, they are all over the place. I wonder if the WAAS thing has something to do with this. Even the error isn’t consistent, I’m finding. Rarely, but sometimes, a reading is spot on. I’m just not seeing a pattern.

Absent WAAS the reading accuracy is ±300 meters, which means that your GPS can appear anywhere, at random, within a 600 meter cube, which is 300 meters above or below, 300 meters left or right, and another 300 meters forward or back. That’s a HUGE tolerance range and it can flit-around to anywhere in that range, randomly, whenever it wants too. That it’s actually random within that range is not surprising and proves that the tolerance band is where it should be.

It sounds like WAAS is not enabled.

Of course, if you are a mathematician with a Ph.D in chaos theory, you could derive the bounds of the chaotic domain and plant yourself in the center. () Enabling WAAS is way easier. . .

Another question:
Where are you taking these measurements? Is it near an airport or a sensitive installation? Are there any potential terrorist threats?

Sometimes the GPS accuracy near “sensitive” locations is deliberately screwed up.

Just a shot in the dark.

[pdmarsh5466]

Hi jimrh,

Thanks for the ongoing interest. With regard to documentation, I just have the manual for the dGPS downloaded from Dexter Industries’ web site, which is the same as this page:
dGPS Manual

I am looking at number of satellites and HDOP, which is usually 7-9 sats with an HDOP of 1. Given the HDOP of 1, I would expect much better results than I am getting given my understanding of the HDOP ratings.

With regard to location, I am in central PA and not near any sensitive military installations, major airports on anything along those lines.

I have been doing a lot more testing and something interesting is emerging. It appears that initialization is part of the mix. When I first turn on the dGPS (via the NXT) and it determines its location, any subsequent readings that I take while walking will be correct relative to each other, but the group of readings itself can be off by hundreds of feet, sometimes less, sometimes hardly off at all. In other words, the individual readings are not bouncing around within that 300’ cube. So, the error I am seeing is not from data point to data point, but rather between on-off cycles of the dGPS itself. At least that’s how things look at the moment.

I have written an NXT-G program that tests whether or not the initial dGPS location reading is within an acceptable distance of where I stand when I turn it on. If it is, the program will continue, otherwise the program stops and I’ll cycle power and try again. I still have testing to do, but if my theory holds that a good initial reading will lead to good subsequent readings, I think this will work for me. Also, and I will test this, the dGPS Navigation Block functions should work as well, which is critical for a mobile robot.

Thanks again,
Paul

[jimrh]

You seem to be striking home near the problem. . .

Did you read this?

Dilution of precision (navigation)

What is the maximum variation, (in meters) for the data? Is it within 3 meters?
What is the typical (average) data spread?
What happens if you average “n” datapoints? Does it become more consistent?

Many GPS units I’ve read the spec-sheets for have an “initialization” that can be run, (or skipped as the case may be), which kind-of sets things up.

Then there is the seeking of the satellites, which - depending on if it is a “warm” start or a “cold” start can take minutes for a “cold” start.

You should be able to save the initialization constants and the current satellite map in NVRAM within the device and then reload it after a cold/warm start to speed up the calibration.

Re: The “manual”.
That does nothing for me as I do not have the NXT platform and it provides no real “spec-sheet” data. I wish I knew the part number for the chip. . .

One thing you could try since many GPS receivers use i²c as a communication protocol, and since the NXT also communicates via i²c, you may be able to do a direct substitution as many have similar command sets - like the old RS232 modems and the AT commands to run them.

I would expect command sets to be very similar if not right on, as it doesn’t make sense for a vendor trying to sell GPS modules if every new module by every new manufacturer has a totally different command set.

Since the NXT, (at least according to the examples), uses a block-based language, I don’t know to what extent you can get “down and dirty” with the device at a command-response level.

Do you have a pinout for the NXT connector?

I just thought of something! If nothing else, you have a stratum-1 time server for your bot!

[pdmarsh5466]

Thanks for the link to DOP info. I will look it over in more detail.

The chip on the dGPS board is an Atmel MEGA328P AU 1544. The antenna is a G223. I hope this helps.

The weather has not been conducive to ongoing tests today, and the neighbors wonder what this nut is doing walking around his driveway under an umbrella and looking at a little box in his hands. In any case, my last test was promising. The NXT reported that the initial dGPS coordinates were within a 10’ diameter circle (box, actually, bordered by lat/lon lines) and so I took a short walk. The subsequent data points followed as they should. I might be on to a working solution. It just a matter of power cycles until I get a good start, at least I hope it continues to look good as a fix.

I find it hard to believe that other users of the dGPS have had this experience. There’s no way, without going through what I am going through, that you could build a robot that would reliably navigate around a parking lot. The error is just too great at times.

Thanks,
Paul

[jimrh]

@pdmarsh5466

I find it hard to believe that other users of the dGPS have had this experience. There’s no way, without going through what I am going through, that you could build a robot that would reliably navigate around a parking lot. The error is just too great at times.

Maybe that’s why that particular board has been discontinued?

Which board do you have? The early one with the DIP or the later one that’s all surface mount with a big battery under it?

I have the later model, and there’s mention of updated firmware.

I found some assets here, including a pinout, but none of the signals are described other than as “a” and “b”.

I also discovered that ev3 files are actually pkzip files that unpack into several assets, one of which is the program which is an XML file.

There’s a GitHub repo for this stuff here:

DexterInd/DI_LEGO_NXT

@pdmarsh5466

and the neighbors wonder what this nut is doing walking around his driveway under an umbrella and looking at a little box in his hands

That just proves you’re a full-fledged member of this forum - Welcome to the club!

I have a GoPiGo3, and I chase my wife around with it. . .

Others have various things that they want to do interesting things with.

I have an article I wrote here on interesting things we do with our 'bots:

Let's talk about the Pi-4, Killer Nano-bots, or whatever unreasonable idea strikes your fancy!

I’m starting a “Sure! Sounds Great! Let’s talk about that!” thread that welcomes and encourages conversation about odd-ball configurations that are patently unreasonable. IMHO - “Hobby” robotics is, by definition, “unreasonable” in the same way that taking an Atari XE (16 k of RAM), and hardware-hacking it to run a full 64k, sans schematics, technical specifications, etc. is “unreasonable”. Why not just go spend the few extra bucks and get The Real Deal, without having to solder chips, filte…

I’m also working on a way to easily multi-boot a Raspberry Pi so I can run both Raspbian for Robots AND GoPiGo O/S, (a simpler system that uses Jupyter notebooks, a Blockly-based programming interface, and a bunch of other fun goodies.

I also included a recent version of Raspbian 64-bit beta, I’m trying to re-spin R4R on a 64 bit userland - and not having much success!

@KeithW has a bot with a LIDAR on it, and he’s teaching himself all the fun stuff you can do with Robot O/S (ROS).

@cyclicalobsessive has a robot named “Carl” (Mine’s Charlie), that he wants to be self-aware.

@thomascoyle11859 is busy working on a “DARPA challenge” class of robot and he gave up on the Raspberry Pi, opting instead for the Jetson Nano and Jetson Xavier dev systems from NVIDIA. (I have a Nano, and it’s a BEAST!)

I really haven’t met anyone with a NXT 'bot, so you are especially welcome and we are all interested in what you can do with that thing.

[pdmarsh5466]

Those projects sound great. I’ll explain my ultimate goal in a moment.

First, I have the new dGPS sensor with the backup battery on the bottom. I have the latest firmware which allows you to access # of sats, HDOP and altitude data.

With regard to my project, I came across a post many years ago where a guy was able to create an autopilot for model airplanes based on the Lego NXT (GEO Crawler 1). I had been in the model airplane hobby since I was about 10 (over half a century ago), and this just blew me away. First, I wasn’t even aware of the NXT, which is essentially a toy for young folks. The idea of a model airplane with autopilot control was the stuff of fantasy at that time. I got actively involved and hoped to make an NXT autopilot myself. However, the associated community took off like a rocket and not long after was offering an autopilot based on the Arduino board (Ardupilot) and NXT was abandoned. Still, I was fascinated and have always wanted to recreate the NXT autopilot. That is my goal. GPS accuracy within, say, a 20’ radius is essential, but I know it can be a lot better than that as I did get an Ardupilot and the GPS data was spot on, way better then even a 10 foot radius. The control was amazing.

So, if I can’t get reliable data out of the dGPS, my project is bust. For me, there are no alternatives. I would love to learn how to code, but I don’t think that’s going to happen. I have to work within the NXT-G environment.

So, we’ll see how this goes.

Paul

[jimrh]

Paul,

I’m an aircraft buff myself, but have never had the $$$ for anything but silly el-cheapo drones and the like.

There are alternatives.

For just “plane” fun, the GoPiGo is my choice. True, it won’t fly, but getting something of any size up in the air is a non-trivial task.

GoPiGo O/S is especially designed for beginners. (I’m a programming hack that struggles with Bash scripts. Python? Fuggeddaboutit!)

It has a very well designed scratch-like block programming language that also allows you to see the underlying Python. To be honest, especially if I’m doing proof-of-concept stuff, I always do that stuff in Bloxter. There’s a working GPS for it too, but it’s a 3rd party device. Difficult to find but over in the states where you are you’ll have better luck than I. (I’m stuck here in Moscow Russia until the Coronavirus dies down a bit in the US)

You can use a Pi-3 or 4 and a grove board by seeed studios and build things out of that. (I hate seeed studio’s products and hate to recommend them.)

There’s the Pivot-Pi.

Then there’s the way you’re going. Though how you’re going to hoist a humongous beastie like that NXT behemoth into the air is a mystery to me.

(I just read your link, and that’s a huge beastie)

I really don’t know what to tell you. I"m tempted to say that you’re tilting at windmills, but then again, my multi-boot project using a dip-switch to select the O/S to start at boot time has been called a “unicorn” by others too - and I have that just about busted wide open.

Don’t give up the ship!

Jim

[pdmarsh5466]

Hi Jim,

I could very well be tilting at windmills. I have gone back-and-forth as to whether or not this is achievable. I have the lifting power, that’s not an issue. I have the sensors, servo multiplexer and NXT servo controller. I have worked out most of the proportional control logic to handle turns and straight flight toward a given waypoint and to maintain a given altitude. Notwithstanding the dGPS issues, I think I’m close to making this work. One concern I have read about from a similar project is sensor vibration. I’ll probably have to convert one of my nitro planes to electric to reduce engine-induced vibration. As you can expect, I’ll do a lot of testing on the ground before I commit to a flight.

You mentioned that you have a dGPS yourself. What has been your experience with the sensor? I bought it a number of years ago but other things kept me from digging into this project. I’m only now seeing the issues with the sensor. Maybe your situation is similar.

In any case, I certainly hope your confinement in Moscow ends soon. My wife and I got our first vaccine shots just this week and go for the second in a month. I think the U.S. is close to getting this under control.

Paul

[jimrh]

There’s nothing wrong with tilting at windmills, The Wright brothers did that too.

“Go to the moon? Yer daft!”

The list goes on and on. Even if you fail miserably, you still will have accomplished much and will be that much more prepared for the next windmill.

Yes I have one, but all it has done so far is collect dust since I don’t have libraries or programming spec’s for it.

However, the GoPiGo supports i²c and now that I have found what might be usable code samples, I might just try it.

Unfortunately, that’s at the end of a long list of other projects that have a better chance of success.

I’d love to here about your project as it makes progresses. Pictures are always welcome!

As for me, my own 'bot, Charlie, had a severe accident today, breaking his baseplate clean in half along with possible other damage.

Viz.:
https://forum.dexterindustries.com/t/breaking-news-charlie-critically-injured-more-at-11/8188

In order to assess the damage, (and try to repair it), I had to completely disassemble the poor beastie.

If I can’t repair the broken parts, I have replacements so, eventually, things should work out.

[pdmarsh5466]

Hi Jim,

I’m sorry to hear about Charlie, but I read the press releases and I’m glad to hear surgery went well.

On the dGPS front, I believe I have the workaround I need. As I mentioned, a good initialization is essential. Why it can initialize itself with an error of as much as 300’ is beyond me, but with good initial coordinates, it works very well. I just have to cycle power until I get a good start.

I did a more extensive test to see how it tracks travel relative to a given waypoint. In the linked screenshot below, my initial point was at the center of the small circle on our driveway. Since I got an initial reading within that circle (or box, really, between lat and lon lines), I walked north and then west toward the waypoint. The long red lines show heading toward and distance from the waypoint at each reading along the way. The yellow lines show my heading while walking and the green ones show angle-of-travel (the sensor provides both). The latter two should be the same, but they must be calculated slightly differently. I was curious, so I captured both.

The long red lines all terminate within a 30 foot radius of the waypoint. That will work for a model airplane circuit. I actually think in practice I can hit a waypoint in a smaller area. It wasn’t easy drawing those lines on the map, so I could be off myself. Also, I never actually walked directly toward the waypoint, which should improve readings over time.

So, things are looking up.

Link to photo:
Screen Capture

Paul

[jimrh]

The screen-capture link took me to a google login and then to a “it’s not here!” (404) page.

You can upload pictures to the post itself.

[pdmarsh5466]

Hi Jim,

I was looking for how to post pics and missed it. Thanks.

[jimrh]

I am assuming that the read lines point toward where the GPS thinks the waypoint is?

A thirty foot radius is still a bit large, (unless you’re a cruise missile). You should, ultimately, be able to get to about 3-5 meters.

The only other constraint I can imagine is the precision of the calculations done by the NXT device itself if there is any interpolation or calculation needed. Or, maybe the precision of the binary representation. These are all potential sources of error.

One other thing: How fresh is the GPS’s battery? If it has to re-calibrate every stinkin’ time - is the battery still good? Or, maybe there’s a jumper somewhere that we both missed that needs to be closed to allow the battery to backup the GPS/NVRAM?

If I could figure out which of the two data pins is the clock and data lines, I could play with the beastie myself - I could wire up a Grove connector to the solder-pads and plug it in.

Looks like you’re making huge progress!

P.S. I long for the day when I live in an area like yours.

This is where I live when I am in Moscow:
(the white circle is our place)

 

And as a humorous aside, this is what Russians think of America’s sanctions:

A bar/pub named “Sanctions”.

Russians have a tradition of naming a mixed drink after significant events.

They created a drink called “Sanctions” which contains no alcohol at all which is their opinion of the sanctions.

On the other hand, there’s a drink called “Coronavirus” which contains, (among other spirits), two or three shots of 200 proof pure grain alcohol, (the canonical recipe specifies raw distilled alcohol or high-octane moonshine), and is guaranteed to bring even the biggest and toughest Russian truck-driver to his knees!

[pdmarsh5466]

Hi Jim,

That is exactly correct–the red lines point to where the dGPS thinks the waypoint is. That was one of the main reasons for test, to see if my theory holds that a good initial reading means the rest will be good and that individual coordinate readings won’t jump around randomly and widely. In fact, the path plotted from the data points is within a few feet of, or is right on, my actual path. I think the unit is performing better than the red lines indicate. If I have to continue using my initialization test, I’ll want to get that starting circle, or box, as small as possible while not having to go through many power cycles first. Also, the dGPS is limited to 8-digit coordinates, which might limit just how small my box can be before the bordering lat and lon lines merge.

The battery is brand new. I did wonder if removing and/or changing the battery has some sort of reset effect on the unit. I actually removed and re-seated the new battery just to see if I got better results. It had no effect on the randomness of initialization.

I did a search to see if any information was out there on GPS initialization error. While I didn’t find anything that relates to my specific problem, there is a lot of info on GPS initialization in general. Here is an example with some good information:

GPS Initialization

Based on that article, I’ll try moving my unit to different areas with power cycles, and then run my initialization test centered within the starting box and see if I get an immediate good start. However, I have done enough restarts that by now the unit should have gone through any required self-initialization already.

Thank you for your kind remarks about our home. This is our retirement home and we moved here about one and a half years ago. We basically share the woods with the local deer population, along with lots of other critters. There is a lake nearby, but we have never been water-sports people, so we don’t take advantage of that.

Thanks for the photo of your current home. It appears to be a bit wooded as well. During my career I had the great good fortune of traveling, but I never had the opportunity to visit Russia, which, along with China, I would have loved.

Speaking of love, I would love to visit “Sanctions” and have a “Sanctions.” However, I enjoy my eyesight, so I don’t think I would sample the “Coronavirus.”

Paul

[jimrh]

“Coronavirus” wouldn’t damage your eyesight, that is unless you get a massive concussion falling off of something, as they don’t use denatured alcohol in their drinks.

Eight-bit precision is limiting indeed as an 8-bit signed integer, (which is what I believe is returned), has a resolution range of ±127. A resolution of ±127 represents a maximum resolution of about 0.71 degrees of arc.

A full degree of arc is not a trivial amount, especially as distance increases, which could explain the large magnitude of error at the waypoint.

Wow - 2/3 of a degree of arc. . . I didn’t think the digital resolution wold be that bad.

You should also note that the degree of precision guaranteed by the GPS is at the location of the GPS itself, not the location of some distant object.

Because of the lack of angular precision, (along with accumulated errors in the imprecise data), the HDOP at a location that is even as close as your target can be quite large. Taking that into account, that 30’ circle is pretty darn good.

If you continue to test, you will likely discover that the positional accuracy of the target point increases as you get closer.

It is important to remember as you test, that the primary function of a GPS is to determine YOUR location with precision, not the location of some distant target.

Since positional information is an eight bit signed integer, that would explain the large variation of precision when starting the GPS. The GPS itself, at maximum accuracy, has a variation of no less than 3 meters, often more. Add to that a 2/3 degree dilution of precision in all directions, it’s no wonder that some of your startup positional readings are in the next county!

BTW, according to this article, a full degree, in either direction at your approximate location, is darn close to 70 square miles.

Since your location is being, (at least internally), calculated to a much higher precision than that, obviously there is either some method of calculating position that is much more highly accurate, or the dilution of precision is caused by the ATMEL processor only being 8-bits wide.

[jimrh]

@pdmarsh5466

I did a search to see if any information was out there on GPS initialization error. While I didn’t find anything that relates to my specific problem, there is a lot of info on GPS initialization in general. Here is an example with some good information

Darn good article that explains things remarkably well.

Question:
Once the GPS is started, does the accuracy location change with time? (It should get better) Do you get better initial accuracy if you are out in a large open space instead of near your house and the copse of trees nearby?

One point to note is that automobile GPS’s have two advantages YOU don’t have.

1. It is programmed to move - and lock - your position to the nearest road. So, even if you are quite distant, it looks like your positional accuracy is quite good. (Assuming you’re out in the open.)

2. The GPS has mapping and waypoint data built-in. Because of this it has, (at least), two points of reference it can use to determine your position - the satellite position and the known geographic location of various places in the mapping and waypoint data.

3. Additionally, since the GPS assumes you are on a road, (and not out in a nearby field), it can use that information as part of the calculation of your position.

All of this extra data provides valuable “hinting” data that a smart GPS will use to fine-tune its own positional accuracy over time; gaining the equivalent of additional bits of precision.

An additional data point for you: When traveling around Moscow, the HDOP is often non-trivial and I’ve had my own GPS, (a later model Garmin), warn me about an upcoming turn or exit AFTER I have already passed it!

One other observation:
When I mark a place on the map, it shows the lat/lon data as a relatively long string of numbers, which leads me to believe that the calculation is being done with signed integers that are - at a minimum - 24 bits long and possibly as many as 32 bits of signed precision, (±2³¹ after you subtract the sign bit)