Interesting to read about alternative, non-centralized, forms of navigation. I wish modern cars which already have all the necessary sensors would use this method as a fallback, since GPS reception is not always available.
Vehicle speed and steering position are available through OBDII. And inexpensive Bluetooth OBDII interfaces are available. But I don't think that navigation app developers have done anything to take advantage of that data for dead reckoning input.
I believe Apple requires CarPlay radios to provide wheel speed and compass readings (along with GPS) to the iPhone, and it gets used by CoreLocation to report location to apps.
Every single mapping app has to implement some kind of mapmatching, since you can't rely on the GPS sensors to always be accurate: the GPS position is frequently wrong when you're moving between cell towers , and can be lost for several seconds in cities. Nokia/HERE's implementation (which I was told was very similar to tomtom/garmin's implementation) was written more than a decade ago, and IIRC, every time it encounters a fork in your path, it projects your position on every alternate for a few seconds and chooses the one that best matches the current gps+compass+accelerometer data as your "current" route. The output of this algorithm (which btw is hideously incomprehensible -- I'm talking old c++ with almost no comments) is what is used for map viewing/routing/guidance... the pure gps signal is never used as-is.
> the GPS position is frequently wrong when you're moving between cell towers , and can be lost for several seconds in cities.
You seem to be thinking of cell tower triangulation, not GPS. I do agree that GPS also does not do particularly well in areas with large buildings: it needs a clear view of the sky which can be hard to come by when there's skyscrapers everywhere.
>which btw is hideously incomprehensible -- I'm talking old c++ with almost no comments
What does "old" have to do with it? Modern code is all like that too. Every time I complain about it, including just a day or two right here on HN, I get a bunch of responses saying "I don't need comments, my code is self-documenting". In my experience, most programmers do not use comments much at all, and it's entirely incomprehensible to anyone new to the project.
I think some smartphone navigation apps do temporary dead reckoning, using the accelerometers that are built into the phone.
Dead reckoning using just acceleration data loses accuracy quickly. Using turns to reset position is a really good idea. I think I've seen my iPhone do a similar "recovery" procedure when it gets a little off track.
I have had my Android phone continues to plot my travel through a tunnel when it couldn't receive GPS signal. It's usually off by a small margin when I reach the end of the tunnel but everything syncs once the signal is acquired again.
I've used navigation apps that do this on iPhone, but the navigation portion of the app didn't realize I was in the tunnel, so it kept telling me to make turns on surface roads...
Some of TomTom's high-end devices like the TomTom GO 920 have built-in accelerometers and gyros, and use "Enhanced Positioning Technology" to perform augmented dead reckoning when GPS signals are not available, like in tunnels and highly built-up areas.
Best navigation with Enhanced Positioning Technology
TomTom’s new Enhanced Positioning Technology uses movement and gravity sensors to calculate drivers’ positions when GPS signals are unavailable.
TomTom GO 920 T users will have a much more continuous navigation experience as the Enhanced Positioning Technology ensures the device continues to navigate to its destination, even in circumstances where there may not be a direct line-of-sight connection to a satellite. For example, when driving in a city with tall buildings, underpasses or bridges.
As you drive along you will often encounter places where the Satellite signal is blocked such as tunnels and underground parking lots. TomTom has introduced a system called EPT (Enhanced Position Technology) to keep track of your position using accelerometers. This is not as accurate as GPS but will help guide you in places like Boston where the Big Dig has created a network of underground roads.
TomTom released the GO x30 range in April 2008 based on NavCore 8. New features included IQ Routes, which estimated journey times based on average recorded speeds, rather than speed limits, and Advanced Lane Guidance, an on-screen representation of the correct lane to take. The 930, like the x20, had Enhanced Positioning Technology. GSM HD Traffic receivers, plugging into the car's cigarette lighter, added HD Traffic to the GO range.
Refreshed ONE and XL models were released in May 2008, still based on NavCore 7, with an improved speaker.
NavCore 8 updates for NavCore 7 devices, including the ONE v3 and v4, were released in June 2008, giving x20 users (only) IQ Routes and Advanced Lane Guidance, with the purchase of new maps.
It would also be helpful in case of a hacking event: if the car's local sensors deviate from the gps data significantly, that should throw up a red flag to the car and driver.
> if the car's local sensors deviate from the gps data significantly, that should throw up a red flag to the car and driver.
This happens too often for benign reasons (and GPS hacking too rare) for it to be useful. The GPS system in my Ford Focus jumps around wildly if I start the car in an enclosed space before it gets a good lock, and it can be thrown-off under bridges and around tall buildings as it doesn't have A-GPS (does any car have A-GPS?). The worst is when a poor signal is combined with road-snapping - I've had a lot of trouble with off-ramps on partially submerged urban highways, the I-5 in downtown Seattle, for example.
http://www.plxdevices.com/category-s/195.htm