|
|
|
|
|
by uuidgen
1704 days ago
|
|
While INS is not simple, it's also not that difficult to implement. As even the cheapest drones that can hover show new MEMS sensors are accurate enough to work with a proper filtering. I did some prototype INS system as my master's thesis 10 years ago, the code was quick and dirty and even then the accuracy was like 30 meters after an hour of walking around with the device. |
|
1. You're integrating twice (acceleration to obtain velocity, then velocity to obtain position). So if you have any noise or error, you're integrating that, and integrate that again. Hello, parabola.
2. Gravity. It's strong. So you have to subtract it (as it induces an apparent acceleration upwards).
If the difference between actual down and where your model thinks is down is just a fraction of a degree, you'll be totally off within minutes.
See eg here: https://www.youtube.com/watch?v=C7JQ7Rpwn2k&t=1401s
Or here: https://www.cl.cam.ac.uk//techreports/UCAM-CL-TR-696.pdf
> As a concrete example consider a tilt error of just 0.05 [degrees]. This error will cause a component of the acceleration due to gravity with magnitude 0.0086 m/s2 to be projected onto the horizontal axes. This residual bias causes an error in the horizontal position which grows quadratically to 7.7 m after only 30 seconds [and thus to 770 m after 5 minutes, unless I'm mistaken, and 110 km after an hour]
Or here: https://liqul.github.io/blog/assets/rotation.pdf (search for "Accuracy of Velocity and Position Estimates").
[1] such as assuming that your foot has velocity zero while on the ground, which does not hold when you're in an elevator, for example, and which you can't use in a drone without some serious sensor fusion.