Yup! Otherwise your navigation would become totally useless the second you entered a tunnel.
Dead reckoning can get quite accurate once you realise that cars drive on roads, so if you have a reasonably up-to-date map you can use turns and corners to "snap" back to the road and reset a good bunch of your accumulated error.
Almost, they use accelerometers and gyros, 'dead reckoning' is the keyword to look for. The wheels are a bit unreliable because the diameter changes slightly with pressure and temperature.
The legal requirements on that (in most places) are that the speedometer is in something like a -0%/+10% range, i.e. never shows lower than you're actually driving. Not only is that not helpful for navigation (but you could compensate that/shift the error window), but the precision is also pretty low (which you can't easily compensate).
(There are two precision problems here — tyre diameter changes slighly while you're driving, but also it's not precise to begin with before you even turn on the car, due to tyre wear.)
You'd need to do something like calibrating wheel speed data while you have good GNSS reception, then you could use it for dead reckoning. But accelerometers and gyros are cheap…
P.S.: I didn't say wheel speed data isn't used, just that it wouldn't be precise enough on its own.
Are there modern cheap IMUs that are able to hold position for some time available?
My understanding is that using plain accelerometers and gyros will drift quite soon due to noise, while some cars (e.g. Tesla) maintain their position quite well when doing to an underground parking structure and then coming back. So I actually do believe that they put a lot of weight to tracking wheels, which I believe would not accumulate that much error. (For more precise location they'd still need to use accelerometers to detect downhill/uphill, though.)
So I believe that the precision actually favors wheels, not IMUs.
In the underground parking case it doesn't actually matter too much if there's a certain % offset, because you're very likely driving a near-closed loop of some sort; and as you say, the wheel size ratio can be calibrated upon good GNSS data.
yeah Phones have pretty good IMUs. the TLDR is you combine accelerometers and gyros (preferably a bunch of them to minimize error) with GPS which gives you pretty accurate position and can also give you velocity data with some tricks)
But if you don't have GPS, then you don't have a high-confidence low-precision absolute position input to your system? Whereas with wheels you already get a lot of data about that when they are not turning at all.
A friend tried to make a phone ruler app (using IMU) and the experience was that it didn't take very long for the distance to shoot to the horizon. So, thought I should try how this kind of solution would work with the hardware of today, but it turns out there seem to be zero such apps in the Play Store.. The tools of that category all seem to use a camera.
I think the lack of these tools is a testament to the approach not really working.
Yup! Otherwise your navigation would become totally useless the second you entered a tunnel.
Dead reckoning can get quite accurate once you realise that cars drive on roads, so if you have a reasonably up-to-date map you can use turns and corners to "snap" back to the road and reset a good bunch of your accumulated error.
Almost, they use accelerometers and gyros, 'dead reckoning' is the keyword to look for. The wheels are a bit unreliable because the diameter changes slightly with pressure and temperature.
Wheels are still used for legal telemetry: speedometer and odometer.
The legal requirements on that (in most places) are that the speedometer is in something like a -0%/+10% range, i.e. never shows lower than you're actually driving. Not only is that not helpful for navigation (but you could compensate that/shift the error window), but the precision is also pretty low (which you can't easily compensate).
(There are two precision problems here — tyre diameter changes slighly while you're driving, but also it's not precise to begin with before you even turn on the car, due to tyre wear.)
You'd need to do something like calibrating wheel speed data while you have good GNSS reception, then you could use it for dead reckoning. But accelerometers and gyros are cheap…
P.S.: I didn't say wheel speed data isn't used, just that it wouldn't be precise enough on its own.
Are there modern cheap IMUs that are able to hold position for some time available?
My understanding is that using plain accelerometers and gyros will drift quite soon due to noise, while some cars (e.g. Tesla) maintain their position quite well when doing to an underground parking structure and then coming back. So I actually do believe that they put a lot of weight to tracking wheels, which I believe would not accumulate that much error. (For more precise location they'd still need to use accelerometers to detect downhill/uphill, though.)
So I believe that the precision actually favors wheels, not IMUs.
In the underground parking case it doesn't actually matter too much if there's a certain % offset, because you're very likely driving a near-closed loop of some sort; and as you say, the wheel size ratio can be calibrated upon good GNSS data.
yeah Phones have pretty good IMUs. the TLDR is you combine accelerometers and gyros (preferably a bunch of them to minimize error) with GPS which gives you pretty accurate position and can also give you velocity data with some tricks)
But if you don't have GPS, then you don't have a high-confidence low-precision absolute position input to your system? Whereas with wheels you already get a lot of data about that when they are not turning at all.
A friend tried to make a phone ruler app (using IMU) and the experience was that it didn't take very long for the distance to shoot to the horizon. So, thought I should try how this kind of solution would work with the hardware of today, but it turns out there seem to be zero such apps in the Play Store.. The tools of that category all seem to use a camera.
I think the lack of these tools is a testament to the approach not really working.