Carl is testing IMU turn logging against wheel logging

Finally got around to building an “always on” turn logger for Carl’s IMU (the DI BNO055 9DOF Inertial Measurement Unit).

Carl has been running a wheel logger based on his wheel encoders, to log forward and reverse travel with approximate turn measurements for quite some time.

Today, I added an IMU turn logger of sorts. It only measures turns when the motors are doing the turning, so the entries will generally line up with the wheel log entries. The IMU is (supposedly) capable of very accurate measurement of rotation.

It also has linear accelerometers but cannot directly measure linear travel. (1st year physics test still in brain 50 years later “distance = one-half a t-squared” and 1st year calculus “integral dx = sum a dt” ) For my first imu logger, I’m not tackling linear motion.

Here is a sample from my first tests using the GoPiGo3 Control Panel to drive and turn Carl:

wheel.log:

pi@Carl:~/Carl $ tail -4 wheel.log
2020-05-02 10:49|[wheellog.py.logMotionStop]travel:   185.1 rotation:    -0.3 motion:     2.5 sec
2020-05-02 10:49|[wheellog.py.logMotionStop]travel:    41.9 rotation:    42.1 motion:     1.2 sec
2020-05-02 10:49|[wheellog.py.logMotionStop]travel:    88.5 rotation:   -88.9 motion:     2.4 sec
2020-05-02 10:53|[wheellog.py.logMotionStop]travel:   413.3 rotation:   415.3 motion:    10.1 sec

imu.log:

pi@Carl:~/Carl $ tail -4 imu.log
2020-05-02 10:49|[imulog.py.logMotionStop]heading:   354.6  rotation:     0.8 motion:     2.5 sec errors: 0
2020-05-02 10:49|[imulog.py.logMotionStop]heading:    35.2  rotation:    40.6 motion:     1.2 sec errors: 0
2020-05-02 10:49|[imulog.py.logMotionStop]heading:   309.4  rotation:   -85.8 motion:     2.3 sec errors: 0
2020-05-02 10:53|[imulog.py.logMotionStop]heading:   357.4  rotation:   408.1 motion:    10.0 sec errors: 0

== Interpretation ==:

First line:
Just driving forward:
Wheel encoder say very slight turn 0.3 deg to left
IMU says very slight turn 0.8 deg to right
“Looked straight to me”
Difference of 1.1 degrees

Second line:
Right turn “visually about 45 degrees” (right wheel not moving):
Wheel encoders say 42.1 deg turn to right
IMU says 40.6 deg turn to right
Difference of roughly 1.5 degrees or 4%

Third line:
Left Turn “Visually about 90 degrees”:
Wheel encoders say left turn 88.9 degrees
IMU says left turn 85.8 degrees
Difference of roughly 3 degrees or 4%

Fourth line:
Right turn “Full rotation plus about 45 deg more”:
Wheel encoders say right turn 415.3 degrees
IMU says right turn of 408.1 degrees
Difference of roughly 7 degrees or 2%

I am unable to measure “actual turns”. I have some wheelbase tests that do a bunch of full circle turns, that might give some insight, but for the time being I’m just happy to have a second set of measurements being logged. (A bit complicated, but I could try to use the pi camera to measure precise angles for turns that stay in a single frame view width.)

The code consists of:

crontab -e entry:

@reboot sleep 90 && /home/pi/Carl/nohup_imulog.sh  

which runs the shell script 90 seconds once after each boot or reboot:
nohup_imulog.sh:

#!/bin/bash

nohup /home/pi/Carl/plib/imulog.py  >/dev/null 2>&1 &

which starts the actual logger running with nohup protection: imulog.py

You might have noticed that "errors: " entry. My IMU driver keeps track of the I2C soft-errors, which occur fairly frequently. Twenty-Seven errors occurred in the span of 8 hours last night. The IMU is interfaced with Dexter’s software I2C that implements clock stretching and seems to suffer frequent soft errors and less frequent hard I2C errors which require rebooting the whole bot.

(I created a set of I2C mutex protected read methods in an attempt to improve the reliability.)

Carl’s distance sensor is interfaced with hardware I2C which I found to be rock solid, able to run for months with no errors.

If running the imu logger will cause an hard I2C error, Carl will not be able to return to his dock when his batteries are low. He has a low voltage safety shutdown which will protect his SD card with the logs, so I will be able to see if the imu logger breaks the “juicer” power management program.

2 Likes

Well that didn’t last long…

Wrote a spin test program and now the IMU is reporting all errors and 0.0 for all values.

Reality is such a pain.

1 Like

Luckily, restarting the imulog.py program fixed it.

Another test of the spin in place turns:

  1. 90 right
  2. -180 left
  3. 90 right
pi@Carl:~/Carl/systests/imu $ ./test_spin_turns.py
pi@Carl:~/Carl/systests/imu $ tail -3 ~/Carl/wheel.log
2020-05-02 13:16|[wheellog.py.logMotionStop]travel:     0.3 rotation:    87.3 motion:     1.2 sec
2020-05-02 13:16|[wheellog.py.logMotionStop]travel:    -0.6 rotation:  -179.0 motion:     2.4 sec
2020-05-02 13:16|[wheellog.py.logMotionStop]travel:     0.0 rotation:    88.1 motion:     1.3 sec
pi@Carl:~/Carl/systests/imu $ tail -3 ~/Carl/imu.log
2020-05-02 13:16|[imulog.py.logMotionStop]heading:    74.2  rotation:    88.8 motion:     1.3 sec errors: 3
2020-05-02 13:16|[imulog.py.logMotionStop]heading:   255.6  rotation:  -178.6 motion:     2.3 sec errors: 3
2020-05-02 13:16|[imulog.py.logMotionStop]heading:   342.4  rotation:    86.8 motion:     1.3 sec errors: 4
1 Like

@cyclicalobsessive,

Maybe I’m wrong, but doesn’t the datasheet for the IMU chip say that it has to be calibrated - by moving the IMU in certain specific ways - before it can be used?

Also, supposedly, you can calibrate the IMU and then save the calibration constants - and then re-load them on future startups to restore the “calibrated” state.

Indeed - I added “safe” calibration for individual components and for full calibration, and safe routines to save and restore calibration data to my_easy_inertial_measurement_unit.py

Auto calibration of the BNO055 is possible under certain circumstances, and I have found that loading stored calibration data is not always required for the auto cal function. The chip is actually very smart about calibrating itself as it sits and as it is moved.

If I was really worried about pitch and roll, and getting the best accuracy for heading, the first thing would be to get the IMU away from the encoders and motors and processor and batteries, and to perform 9 DOF characterization, but who’s got the time for all that.

There is a lot to be learned about using the IMU. At this point, I’ll be happy if I can figure out how to run the distance sensor and the IMU on the same bot safely and reliably.

The next thing I would like to figure out is how to reset the heading to zero when Carl is sitting on his Dock, so all the headings are referenced to a wall instead of magnetic North.

1 Like

First question:
Why on God’s Earth would you want to do that?  Isn’t the nice thing about any kind of IMU and/or geo-locator the fact that you know where you are with respect to a fixed standard?  If, at some point in the future, you decide to use any kind of external mapping or geo-location utilities, you’re borked until you re-write.  Wouldn’t it be easier to just store the coordinates of his dock and have him go back to that location?

Second:
It shouldn’t be that hard.  It seems to me that all you should have to do is get your “true” x, y, and z values and then create a “calculated” x, y, and z value by applying a constant offset to the “true” coordinates when Carl is on his dock to make that place 0, 0, 0, when he is docked and facing away from the wall.

My concern with doing something like that, aside from what I mentioned above, is that if conditions change, or the dock is moved for whatever reason, you have to re-calculate your calibration offsets.  If you use a standard grid, all you have to do is programmatically “reset” the coordinates of “home”.

Of course, you could also “programmatically” reset the new coordinates to 0, 0, 0 - so that objection joins many other ideas of mine in the trash bin. . . .

1 Like

“Reality is such a pain. . .”
Truer words have never been said!

I am slowly, but surely, getting my arms around the HTML and JavaScript needed to use a joystick controller with my 'bot.  Just when I think I’ve got it figured out, another line of code pops up and everything goes all pear-shaped on me. . . (laughing!)

If necessary, maybe you could write a “watchdog” that detects when the IMU has gone sideways on you and reboots the IMU software.  Piece of cake for an 'ole code-hound like you.

1 Like

Actually, the IMU does not wake up with the same heading two times in a row. The encoders give a very consistent +/- 1 degree every day. The IMU in full NDOF varies between +/-2 degrees to +/- 10 degrees from one docking to the next (every 3-6 hours).

I’m thinking the NDOF might work better if I turn off the earth mags altogether.

Also, The walls are generally at 0 degrees and 90 degrees, which are much better reference than molten iron miles away.

1 Like

While looking at some GPS/IMU documents recently, I remember reading that in a case like this where the IMU is relatively near magnetic sources - robot motors were specifically mentioned - the article suggested either really good magnetic shielding or forgetting about the compass/magnetic tracking altogether.

As silly as this sounds, could you mount the IMU just below the top of Carl,s head, as high up as possible, and see if that makes any difference?

Of course, you could go Full Military Nutzoid and mount three IMU’s on three different axes, averaging the results using complicated algorithms requiring a small supercomputer. (:wink:)

Of course, but actually the only use for the IMU that the wheel encoders do not adequately cover is the ambient temperature sensing. It is amazing how quick the sensor responds to the air conditioning coming on and dumping a bunch of cold air from the ceiling. When the air is off, the imu sensor (on Carl on the floor) reads within 0.2 degrees of a thermometer sitting on my wife’s desk. When the air starts up, the temperature drops four or five degrees F. At first I thought it was bogus, but then I moved the wife’s thermometer to sit next to Carl - sure enough after a few minutes the two sensors again matched!

1 Like

Why is temperature sensing important in this case? Does it affect encoder accuracy?

Only in that it extends Carl’s awareness of his environment. Another awareness that Carl does not use, only reports it. Carl is a bucket of knowledge waiting for me to paint something with. Some days I feel his “wish list” is longer than my wife’s, and both seem to growing rather than shrinking.

Theoretically, if someone was truly obsessive about getting the maximum accuracy out of the distance sensor, there actually is a distance reading vs temperature correction table in the spec, but the reality of shooting a 25 degree wide beam to measure distance makes you wonder what designer thought anyone would need to correct for temperature.

1 Like

@cyclicalobsessive – yours is a succinct variant of one of my favorite aphorisms:

" …in theory, there is no difference between theory and practice, while in practice, there is."
                                                                                                                                 – Benjamin Brewster

/K

2 Likes

Thinking about this, I have a much more fundamental question about this, or maybe I am just showing my abysmal ignorance. . . .

Isn’t the purpose of the IMU to provide ADDITIONAL precision to the measurements already available from things like the wheel encoders, etc.?

If that is the case, then why does it seem that the IMU is providing a gross approximation compared to the decimal precision provided by the wheel encoders?

Since the IMU is providing LESS precision than the wheel encoders, why even have it? What is the potential value-add given by the IMU? (i.e. What does it provide that the wheel encoders cannot?)

My first reaction is to say “Nothing beyond being an expensive ambient air temperature sensor.”

It might be that extensive testing would show that the instantaneous or short term accuracy and precision is much greater than the wheel encoders, but my operational philosophy for Carl is to design for tolerance of variance, eschewing dependance on unnecessary precision.

(The reality is Carl isn’t doing anything more than logging distance travelled and degrees rotated for his posterity, which posterity seems highly improbable.)

1 Like

The one thing I think about that may, or may not, apply is that if there are differing and potentially opposite variations, the one could be use to cross-check and limit the total error.

The reason I ask is that early on in my experiments with Charlie, I wanted to make “90°” turns and was unable to get the required precision. When asked about this, I was told that turns are “an approximation” and if I wanted greater accuracy/precision I’d need to incorporate and use the IMU.

Your results seem to indicate that the true source of error is the lack of precision in calibration, not the IMU, with the IMU being worse than the wheel encoders.

The only other thought is that (possibly, God Willin’ an’ the Creek Don’t Rise), the directional, (compass) orientation of the IMU might be able to reinforce the wheel-encoder’s idea of direction.

Anyway, I’m confused. I’m beginning to wonder if the IMU is actually a worthwhile investment.

IMO, no - just another expensive unnecessary toy to play with.

But then again if your bot is a ROS bot, the IMU is the trusted sensor.

1 Like