Once I get Charlie back on the road again, I would like to be able to utilize the IMU, if at all possible. (i.e. Precision turns, rotation, distances, etc since I don’t have the best floor surface to calibrate against.)
Question:
Aside from the “IMU” lesson in Dexter, what suggestions can you/anyone offer for a good functional test for the IMU?
How about a (hopefully) simple way to actually USE the IMU for something other than a decoration or load on the battery. Is this doable?
Thanks!
P.S.
Charlie has been put away for the time being while I finish the power supply and battery state-of-charge indicator projects, so I don’t have access to what may already be included there. Apologies if there is already a good solution that I forgot.
I can’t help you with programming in Blockly, but if you want to try my “Safe IMU” package …
I just added an logIMU utility to the python2 package (and fixed a python2 vs python3 bug), so if you could mount your IMU horizontal, facing left, chips up (ROS configuration), perform the python2 install:
$ sudo pip install imu4gopigo3ros
Test:
startIMU
readIMU
resetIMU
calibrateIMU
startIMU -i
python3
import ros_safe_inertial_measurement_unit as imupkg
imu=imupkg.SafeIMUSensor()
imu.readAndPrint()
ctrl-c
ctrl-d
logIMU & (note process id to kill later, or start in separate shell)
I will be glad to try it as soon as I get Charlie back on line, and I have every confidence that it will work splendidly.
Question:
(Assuming that this is even possible.)
Is it possible to use the IMU for precision movements? (i.e. Accurate turns of “x” degrees, motion of “x” cm in a straight line, or notice if the 'bot is not traveling directly straight ahead?)
#!/usr/bin/env python
from easygopigo3 import EasyGoPiGo3
import ros_safe_inertial_measurement_unit as imupkg
egpg = EasyGoPiGo3(use_mutex=True)
egpg.imu=imupkg.SafeIMUSensor()
curr_heading = egpg.imu.safe_read_euler()[0]
print("curr_heading: {}".format(curr_heading))
egpg.imu.readAndPrint()
I also have been hoping someone would write egpgwithimu.py
def init_imu(egpg) # instantiates SafeIMUSensor() assigned to egpg.imu
def turn_degrees_imu(egpg, degrees) # assumes imu is egpg.imu
Useage:
from easygopigo3 import EasyGoPiGo3
import egpgwithimu
egpg = EasyGoPiGo3(use_mutex=True)
egpgwithimu.init_imu(egpg)
epgpwithimu.turn_degrees_imu(egpg,90)
or better yet super class EasyGoPiGo3 which adds:
Class EasyGoPiGo3withIMU(EasyGoPiGo) ...
from easygopigo3withimu import EasyGoPiGo3withIMU
egpgwithimu = EasyGoPiGo3withIMU()
egpgwithimu.turn_degrees_imu(90)
If it is any hint why I haven’t written it - turn_degress_imu(90) is not easy - I modified the compassbot example to create headingbot. Not fun, and not pleased with the result:
This almost begs the musical question “Why have an IMU if it is so (apparently) useless?”
Don’t get me wrong, I appreciate that there are a variety of sensors available for the GoPiGo, but the IMU seems particularly difficult and/or haunted.
It almost seems like it would be easier to implement 5G cellular internet from scratch than ask the IMU “which way is up?”
I’m not complaining, but I am curious.
Is it the IMU itself, (i.e.Dexter’s IMU implementation is a beast), or are IMUs just beasts in general and it stinks being us?
and thinking about “drive straight using imu” has got to be even harder. The GoPiGo3 “drive straight using encoders” implements the PID on the dedicated processor on the red board. “drive straight using imu” would have to implement PID on the time-sliced RPi, i2C reads of the IMU, and SPI commands to the red board to alter the motor power.
DI implemented balance-bot and compass-bot using the IMU. I haven’t looked at balance-bot to see how difficult that was to implement, but I’m going to go with “IMUs are just beasts”
One thing I have noticed is that, at least in robotics, there doesn’t seem to be a way to “calibrate” your expectations.
All the stuff I see says things like “inexpensive!” or “easy!” but it’s like the Grand Canyon - with respect to what?
The mini-pupper is “inexpensive” - compared to what, a new Tesla?
The [insert name of sensor/feature] is “easy” - compared to what? Bit-banging a WiFi radio signal using a GPIO pin? Implementing a wideband GPS/GLONASS receiver using discrete components and bare wire?
I don’t mind challenges. Really, I don’t mind at all. (<= Charter member, National Association of Masochists and Sadists.)
I just wish I knew what “easy” and “inexpensive” are supposed to really mean before I’m in hip deep!
From my experiments with the 9250 IMU and the DI BNO055 IMU, it is mathematically challenging and process-architecturally challenging to use IMUs to achieve better than 5% heading or location accuracy across a variety of surfaces and speeds.
Unless you have insanely deep pockets like the DOD. . . .
Then it’s STILL a royal pain, but you have the money to hire the best and brightest to make it work the way you want - and “unit cost” isn’t a consideration!
. . . .and if the guy who tried to get his Dexter GPS working with his NEXT 'bot is any example, messing with a GPS isn’t any easier either.
Wright Brothers: “Flying can’t be that difficult; birds have been doing it for ages!”
Thinking about the problem mathematically, by definition, the “noise” in the signal that dilutes the precision has to be chaotic in nature.
Since it is chaotic, it should be possible to mathematically filter the readings, (via a FFT transform?), into usable data with better precision.
How to do that? That I don’t know.
It won’t be trivial, but it shouldn’t be impossible.
However, if the Big Money spenders were able to get submarine navigation accuracies to within a square meter over thousands and thousands and thousands of miles while submerged in the '60s, using the technology available at that time, then we should be able to do it now.
At least Charlie doesn’t need repairs when he doesn’t know where he is to a sq. meter:
The US Navy submarine that struck an underwater object in the South China Sea last weekend, The Connecticut is one of three Seawolf-class submarines in the Navy fleet, with a price tag of about $3 billion each. The 9,300-ton, 353-foot sub, commissioned in 1998, is powered by a single nuclear reactor and crewed by 140 sailors.
If I have Carl do his best egpg.turn_degrees(360) he will turn 358 one time and 362 the next or so, and 10 revs will end up +/- 3 degrees maybe physically - very hard for me to estimate small angles. Sometimes he will do 10 revs and be visibly right on the starting heading. Sometimes 10 revs will end up 2-3 degrees short and sometimes 2-3 degrees over. That’s when I call wheel dia. and wheel base values correct.
With the difficulty to estimate how much physically the heading is off, the imulog entry will seem to be maybe 1-2 degrees off any one turn, and maybe 2-3 degrees off 10 turns, and sometimes after 20 minutes of driving and turning, the heading will be 10 degrees off what I think the physical heading is.
These are results in IMUPLUS mode which does not use magnetometers. I remember the results as being worse in the full NDOF mode.
Again, I have no way to measure actual headings if they aren’t very close to 180 or 360. I use the floor board lines against the bot’s chassis.
When I was doing the non-ROS occupancy grid stuff, I tried combining encoders for distance and IMU for turns, and did not see amazing results.
I am very curious to see what ROS robot_localization node is going to do for Dave when fed odometry and IMU. My mind is going to have to be working particularly well to figure out how to set it up, so I have been putting off working on that.
The only way to do that accurately would be to have a radial grid laid out with the 'bot in the center.
That reminds me of something I saw many years ago when I lived on Long Island, and Grumman still manufactured the F14 Tomcat.
I saw a Tomcat pilot out on a concrete hardstand at Calverton, do a trick with jets, flaps and brakes that would make the plane jump up, spin some amount either left or right, then settle back down on its mark as if it hadn’t a care in the world.
To this day I am not exactly sure what the plane was doing, but I think it was calibrating or checking its compass or IMU.
Damnedest thing I ever saw, that fighter jet bouncing in place with the precision and grace of a ballerina.
Is this doable?