Agree? “IMU worthless for simple robots' x, y, heading?”

[amcdonley]

Found a phenomenal [90 page introduction and analysis](https://arxiv.org/pdf/1704.06053.pdf) (university level, but first and last sentence of some paragraphs are understandable):

Manon Kok, Jeroen D. Hol and Thomas B. Sch ̈on (2017), ”Using Inertial Sensors for Position and Orientation Estimation”, Foundations and Trends in Signal Processing: Vol. 11: No. 1-2, pp 1-153. http://dx.doi.org/10.1561/2000000094

My conclusions from the paper:

1. IMU heading error quickly becomes 10-30 degrees
2. By itself, no IMU can give useful path and heading.

And my conclusions from this mental excursion:

1. Our body also suffers from the same rapid “eyes closed” error accumulation
2. Brooks is correct that environmental references are stronger than symbolic representations (world coordinates), for the robot mobility domain.
3. Vision will be the most powerful sensor my robot already has, among encoders, TOF distance, microphone, and camera
4. Robotics is (still) hard.

[blimpyway]

try to make a simple two wheel balancing bot (segway bot) without an imu.

[amcdonley]

try to make a simple two wheel balancing bot (segway bot) without an imu.

Understandably impossible for the "keeping its head up" function, but can it provide accurate (world frame: x, y, theta)? It's a serious question. Am I wrong about that application of IMU?

[MrMecatronico]

try to make a simple two wheel balancing bot (segway bot) without an imu.

Balancing a reverse pendulum and providing heading and absolute World position are two very different problems.

My conclusions from the paper:

1. IMU heading error quickly becomes 10-30 degrees
2. By itself, no IMU can give useful path and heading.

And my conclusions from this mental excursion:

1. Our body also suffers from the same rapid “eyes closed” error accumulation
2. Brooks is correct that environmental references are stronger than symbolic representations (world coordinates), for the robot mobility domain.
3. Vision will be the most powerful sensor my robot already has, among encoders, TOF distance, microphone, and camera
4. Robotics is (still) hard.

Balancing the reverse pendulum is solved by feeding directly the accelerations measured by the IMU to the stabilization control system.

On the other hand for the path and heading problem, those variables you what to measure are second derivatives of the IMU original measured variable (linear and angular accelerations). This means you have to integrate twice the IMU measure in order to get an estimation of world position and heading.
Integrating sensor signals is tricky and risky, on each subsequent integration step you are not only adding a signal increment, but a bunch of random noise too. This means that depending on the sensor noise and for how long you've estimated the coordinates you'll get an error on those coordinates.

Your conclusions from the paper are correct. In fact, for useful path and heading on mobile robotics statistical filters are used (e.g. the Kalman filter), mixing different sensor measurements (encoder odometry, GPS, vision estimations,etc..).

Hope i've helped

PS: robotics is still hard yeah, but challenges are fun

[Gavinmc42]

The newer drones use Optical flow sensors for hovering.
Pixart have one that can be used with Crazyflie.

Quaterions and Kalman filtering?
GPS helps to nudge them back on track, later RTK GPS for centimetre accuracy.

I have some hope Bluetooth 5.1 will help for indoor and short range bot.
Optical sensor from a mouse for movement/direction sensing.
Indoor Lidar is now single chip, scanning versions cost more.

Everything helps but the maths is hard

[blimpyway]

try to make a simple two wheel balancing bot (segway bot) without an imu.

Balancing a reverse pendulum and providing heading and absolute World position are two very different problems.

You might be right but the question on the title I answered to was different than the one you are thinking at, since it did not had the "x, y heading" words at the end..

Kind of author changes its ckick-baity question then argues people gave him wrong answers, Then you pop in and say "Indeed, what a wrong answer"

[amcdonley]

You might be right but the question on the title I answered to was different than the one you are thinking at, since it did not had the "x, y heading" words at the end..

Kind of author changes its ckick-baity question then argues people gave him wrong answers,

Please - I asked my question wrong, you gave a great answer. You helped me understand my question was too general, so I changed it. I'm sorry for the bad juju it has engendered for you.

My question is quite serious though "click-baity" it may appear. I have invested several hundred hours searching for and reading example programs, presentations, dissertations, and manufacturer data sheets. I see lots of people asking about 3, 6, and 9-DOF sensors, some with queues, some with "fusion", so I sometimes feel like my robot is the only one not equipped with an IMU, and with so many people using them, am I the only one that can't understand matrix math?

Everyday it seems like another Python package is released to make some complex algorithm available with a few lines of code, and some gracious soul creating a great tutorial that shows mere earthlings how to accomplish great things. I have been hoping to find a non-ROS example that can either use just a 9-DOF IMU or just my differential drive encoder data or combine the two to give an estimated x, y, heading log.

[Gavinmc42]

am I the only one that can't understand matrix math?

No.

Lots of IMU's just give you raw data and then you need to process it in the Pi.
IMU's are getting smarter and Cortex Mx chips get embedded to do that for us, I like them more
You can get external chips that take IMU sensor data and process it.
There are guys making breakout boards.
Pesky Products, Adafruit, Sparkfun, Seeed Studio.........

I want to make bots not hurt my brain with maths.
Something simpler than ROS would be nice.

[Heater]

amcdonley,

I the only one that can't understand matrix math?

You are most certainly not alone. In fact you are in a lot of very good company here. Not people understand this stuff well enough to write their own software for it.

Certainly I have to admit to not having firm grasp of all that "sensor fusion" with Kalman filtering and Quaternion stuff.

We have to face the fact that all this 3D position and physics stuff is a hard problem. Either you roll your sleeves up and get down to some serious study, or you use a ready made solution someone else has created.

I have a love/hate relationship with all this. I can get totally fascinated by bits of mathematics, if I ever get to understand anything, however small, I love it. On the other hand mostly it's terminally frustrating!

Typically I find that if one can ever break through that wall of symbols and equations there is the germ of an idea in there which is pretty simple when you get it.

[Gavinmc42]

Typically I find that if one can ever break through that wall of symbols and equations there is the germ of an idea in there which is pretty simple when you get it.

I read those papers, most are filled with formulas that only mathematicians love.
Give me code examples not formulas, code makes more sense to me.
I have also found traditional methods may not work, a bit of hand tuned code with a few variables can work better.
Sometimes a simple bit of hand tuned code is even simpler than a bit of pro code.

These days I tend towards scripting languages for this tuning stuff.
That I can do remotely instead of the traditional code, compile, program, test, debug cycle.
One day an onboard bit of AI code will do it's own self tuning