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:
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
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 ==:
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
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%
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%
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:
#!/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.