programming deadreckoning gps software?

**BeamRider** · 09-21-2004, 11:13 AM

TomTom does nothing more than recalculating the position on the last available speed vector (software only!) then correcting the position to keep the car on the same road. We could implement everything excluding the last correction.
I think that accelerometres are too much for our needings: a solid state compass + speed sensor (speed data from OBD for example) is good enough.
Vertical speed can introduce some error but not too much conidering we're working with high error sensors: speed is up to 7%, compass is around +-1° then add error introduced by car pitch and roll angles when driving (accelerometers are influenced more by this angles)!

**jpelzer** · 09-27-2004, 02:22 AM

So, I actually began writing some code and testing what we'd need to make this all work.

In order to have Routis/iGuidance track, only two NMEA sentence addresses need to be sent; $GPGGA and $GPRMC.

You can get away with only sending GPGGA data to MapPoint, but iGuidance needs both items to lock correctly. Or so my initial testing indicates.

I also have the Phidget accelerometer running in the same app, although it isn't DOING anything as of yet. Haven't actually tested the software in the car yet, so I don't have any logging data.

I still need to write the software to interface with my OBDII reader to grab speedo data. Then I can start driving around and checking my math and acc. correlation.

Anybody else moving along on this?

**wi77iam** · 09-27-2004, 07:23 AM

Originally Posted by jpelzer

In order to have Routis/iGuidance track, only two NMEA sentence addresses need to be sent; $GPGGA and $GPRMC.

You can get away with only sending GPGGA data to MapPoint, but iGuidance needs both items to lock correctly. Or so my initial testing indicates.

How are you going to send the modified NMEA sentences on to these apps?

**Laidback** · 09-27-2004, 07:27 AM

Originally Posted by wi77iam

How are you going to send the modified NMEA sentences on to these apps?

Xport?

**Dominik** · 09-27-2004, 08:47 AM

Hehe, i didnt even see that program the first time you posted it. But it looks super awesome - could even use it to run multiple GPS software with 1 GPS...

Just need to emulate signals. Without any phidgets, the simplest solution would be to extrapolate the coordinates by using the last known direction/speed. Wouldnt be accurate for more than 1-2 seconds, or if you are turning etc, but better than nothing...

**jpelzer** · 09-27-2004, 10:01 AM

Yeah, I'm using XPort2 for this little adventure. I don't remember seeing the discussion when v1 gave way to v2, but v2 is GREAT, fixed my hibernation issues with iGuidance, and also allowed this little hack to work!

My plan for this dead-reckoning was to see if I could write it so it degrades gracefully all the way back to no supplemental sensing. Plus, v1 of my software will definitely not be able to do 'good' reckoning, so it'll explicitly only be able to extrapolate based on previous course/speed.

**wi77iam** · 09-28-2004, 07:10 AM

Originally Posted by Laidback

Xport?

Sorry for being dense. Are you saying that Xport allows you to read the NMEA stream on the real comm port, do some processing with it, and then send it out the virtual port to a mapping program?

The Xport site says
"Current limitations:
The output ports have no write capability and the input port has no read capabilities including asynchronous reads and event waiting. Both functions will return immediately."

Can someone explain how you're doing that.

**Curiosity** · 09-28-2004, 07:50 AM

Xport2 is a virtual one-way null-modem splitter thing. Yeah, that's it. Instead of attaching to the real GPS port, it just has all virtual ports. A special program (like jpelzer's) reads from the GPS and then sends to the input on Xport, which sends it to all the output ports (Routis, Mappoint, Streets & Trips...). It's going to stay one way because it would just suck to have all the data going from 8 ports into 1.

**Turbosatan** · 09-28-2004, 08:59 AM

in regards to getting the information from the wheels to the system most incar navigation systems used to be reliant on speed Pulse Generators which hooked into the cars system at various points (mostly behind the dash on modern cars) and created a pulse for use with navigation based on the signal going to the speedo.
i cant remember the company name in the uk (where i live) that makes these but i will have a look and try to find out if it would be any use

**jpelzer** · 09-28-2004, 10:48 AM

Originally Posted by Turbosatan

i cant remember the company name in the uk (where i live) that makes these but i will have a look and try to find out if it would be any use

I'd definitely be interested in getting better/cheaper speed sensors. The OBDII sensor I'll be using was about $70, and has a refresh rate of about 2Hz. http://obddiagnostics.com/

Also very interested in how accurate an electronic compass will be inside a car... Anyone testing that?