Slashdot Mirror
Dead Reckoning For Your Car Eliminates GPS Dead Zones
cartechboy writes "We've all been there. You're relying on your vehicle's built-in navigation system to get to that meeting downtown, but then suddenly the car loses the satellite signal due to the concrete skyscraper canyon you're in--and you're about to be late. Swiss semiconductor manufacturer U-Blox thinks it has the solution with 3D Automotive Dead Reckoning, or 3D ADR for short. It's a new navigation chip that uses the vehicle's built-in sensors to track speed, horizontal movement, and elevation. The 3D ADR system measures movement in three dimensions, letting the navigation system can keep track of the vehicle's location even when it loses its connection to GPS satellites. Imagine never having to see your navigation screen saying connection lost again. In an age where our phones have accelerometers and compasses, it's amazing your car is still trying to catch up, right?"
Seriously this isn't new. Good in-car nav systems have had dead reckoning based on wheel position + speed for ages.
Actually I think it's the opposite, it's only being in a car that makes dead reckoning with any kind of accuracy feasible. A car is a reasonably large and stable platform, which already has good speed information, and can have some accelerometer-type information added relatively easily. A smartphone does have an accelerometer, but the data is far too noisy to do reasonable dead reckoning, because in addition to the macro movements (someone walking, biking, or driving down a street) there area bunch of micro-movements that produce high local acceleration (putting the phone in/out of pockets, taking steps while the phone's in your pocket, etc.). It makes for a much more complex dead-reckoning problem, because instead of just tracking broad movements (car goes 10m this way) you have to resolve a ton of tiny movements (phone was moved 0.3m into pocket, then rapidly accelerated 0.1m left due to owner being jostled on the subway, etc.), which tend to pile too much accelerometer noise on top of the broader movements that you really want to track.
In short, taking a known starting position and keeping it updated via accelerometer data is a lot easier if your accelerometer is on a car, vs. on a handheld device.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
seriously, my old bimmer's on-board navigation already did this 15 years ago ! other than that, I've used u-blox in several embedded designs, and they are by far the most fun GPS unit to play with. They have some great pc software for it too. And they've had this functionality for quite some time now. oh yeah, and boo to beta..
Why 3D? Because GPS provides your elevation and uses that as well as your XY coordinates to determine where you are, trip time, etc.
Contrary to the assertion in the story, I've never been there.
Don't know who well it works, but there was a demo by Apple's iOS developers where they combine GPS and WiFi. In towns with large buildings and awful GPS reception you will usually have tons of WiFi signals around, so at least in principle it should be possible to improve navigation using both.
Use of accelerometers is only to reduce the error. Unfortunately, accelerometers can be wrong - due to rotation, deceleration, and acceleration when there is no feedback on WHAT is causing the readings
Cars don't fly. As long as you have traction, measuring distance shouldn't be a problem (especially if you supplement wheel axle sensors with an optical device similar to modern computer mice, to compensate for the tire pressure, and integrate the data). Unlike with airplanes and ICBMs, you shouldn't need precise acceleration from the accelerometers, vehicle orientation along the three axes is what you need. Direct distance measurements obviate the need for double integration (but are impossible in subs, airplanes, and spacecrafts, unlike in cars).
Ezekiel 23:20
Maybe. Let's break it down - Phones vs Cars...
Phones have Location Based Services (LBS) on a typical phone also uses wifi, GPS and Cell Tower location. A request to LBS expects should return a reasonable fix to the highest accuracy. In a dense urban environment, there is a lot of information from wifi/Cell to give a good fix - probably better than GPS. They have a magnetometer that is affected by materials around them and is not guaranteed to be aligned in a consistent way to the movement. In a dock, it is insulated somewhat and can be compensated.
Cars have wheels that are stuck to the ground and provide a good distance measuring tool - everyone has probably seen a dedicated GPS. They have a fixed magnetometer that is well protected from interference and is fixed relative to the vehicles direction of travel.
Both can align to roads on a map, so you have a correction factor in the roads. Any good nav system will lock onto the roads.
So Cars probably already have a higher probability of tracking reasonable well as is (I've never had the problem described except in hills under dense tree cover). Phones have some better LBS capability. Adding the sensors to the cars, and having a wifi/cell phone lookup capability (live or otherwise) would probably give cars a solid edge. This story seems to be more adware for eyeballs, but may have some merit.
A self-driving car? (In conjunction with other sensors, I assume.)
Ezekiel 23:20
You don't even need to go to all that trouble. That kind of accuracy simply isn't necessary in a car as long as it has GPS. Dead-reckoning, in an in-car navigation system, is only needed to make up for the inaccuracy with GPS, which is mainly because you sometimes lose the signals (inside a parking garage, around too many tall buildings, etc.). You don't normally lose GPS signals for a very long amount of time, only short periods. So DR is just a supplement, and the vehicle's odometer signal alone is enough for supplementation, and an electronic compass signal is even better because this gives you direction, in case you turn the car while your GPS signal is missing. You're not looking for accuracy to the inch or even the foot, 50-foot accuracy is good enough in this application, so compensating for tire pressure is entirely unnecessary; they don't do that for the vehicle's odometer after all. You just need the system to warn you in enough time for you to make the next turn.
It's probably too late to turn back the clock on this, but it's actually spelled "ded" reckoning. Short for "DEDuced".
I can only see one possible outcome of that. -- "Uh, where was my car again?" - (checks GPS) - "Oh, right, it's still right under my butt, duh."
CLI paste? paste.pr0.tips!