ROS way: everything is configuable, everything must be configed, including configuring the multiple, simultaneous, synchonous and asynchronous configuration methods. Hardware is fixed and better not change without telling ROS via a configuration change!
2 Likes
Neither, GoPiGo3 “expects” (defaults to) a non-ROS, non-IMU default orientation and the HoR code is putting its own assumptions into the mix.
2 Likes
. . . which explains why I was so confused trying to orient the IMU the first time.
. . . which (also) explains why standards are so important.
It reminds me of a post office poem/advertisement I saw awhile back:
2 Likes
I started looking for ROS2 tutorials for SLAM and Nav. They seem a bit incestuous - SLAM says to use Nav to make a map, but the Nav tutorial says it requires a map.
Then I backed up a bit in the table of contents, and the tutorial talked about setting up your odometry AND your imu for fusion by a robot_localization node with a kalman filter that combines the odometry and the imu to publish the tf instead of having the robot node publish it like gopigo3_driver does.
So it looks like I need to modify my gopigo3 node to:
- (continue to publish the odom topic)
- if an IMU is found, publish the imu topics (imu,mags,temp, calibration_state?)
- have a no_tf parameter to disable the tf publishing, or comment out the code?
and always run robot_localization since it will use what ever it can find - just odom, or odom and imu in this case.
The tutorial seems to suggest that before I start working on Nav and Mapping, I need reliable localization.
You were saying you plan to ignore the IMU for the moment.
Do you think
- I should ignore it as well?
- or should I work on a reliable, configurable DI IMU node (that does not pub tf anymore)
(a ROS2 version then I would back port to a ROS version for you to test)? - or should I integrate the IMU into my ROS2 gopigo3 node (and not pub tf anymore)
(and then back port the idea into a ROS version for you to test)?
I’m leaning toward 2) which doesn’t blow up anything I have running so far, and I can then do 3) once the IMU driver code is solid.
1 Like
If the vehicle is level on the Earth’s surface, the X and Y accelerometers should report about 0 m/sec^2 and the Z axis accel should be approx +9.8 m/sec^2 reflecting an apparent upward acceleration away from gravity force.
Pitching forward is about the Y axis not X, (and it should be positive).
Rolling left is about the X axis not Y, (and it should be positive).
The rate gyros should be in accordance with the right hand rule as stated in REP –103.
Rotation about the Y axis (pitch motion) should be positive in the nose down direction.
Rotation about the X axis (roll motion) should be positive for right side down motion.
Rotation about the Z axis (yaw) should be positive for CCW rotation looking down on the vehicle.
1 Like
They do all seem to be intertwined. And as you noted, you can’t do localization without first having a map. I think I generated a reasonably good map with SLAM - now it’s the ongoing localization that seems problematic. And perhaps I have too high expectations - my roboland may be too small (and hence the tolerances narrow). I thought it would make things easier, but that may not be correct.
That sounds right. But the node still needs to know where the IMU is in relation to the robot, so there still needs to be some tf between base_link and imu_link.
You do good work. My own approach once I start back with the existing node and work from there.
/K
2 Likes
I had seen that post, but I read is as the poster asking whether their assumptions were correct, and I didn’t see a clear answer. However I’ve now read REP-145, which does clearly state:
- Accelerometers
- The accelerometers report linear acceleration data expressed in the sensor frame of the device. This data is output from the driver as a 3D vector, representing the specific force acting on the sensor. [emphasis mine]
- When the device is at rest, the vector will represent the specific force solely due to gravity. I.e. if the body z axis points upwards, its z axis should indicate +g. This data must be in m/s^2.
I had missed that PEP before. I guess I should think of it as the robot accelerating 9.8 m/s upward along the Z-axis to counteract the pull of gravity (otherwise it would be moving toward the center of the earth). Or another way to think of it (perhaps a better way) is that if the robot was in a space capsule that was accelerating at 9.8 m/s along the Z-axis of the robot, the robot would have the exact same reading. In retrospect I’m kicking myself - this is simply Einstein’s principle of equivalence from his general theory of relativity. Who said ROS was complicated 
Right- rotation would be positive. But as noted above I was thinking of gravity as “pulling forward” and so expected positive linear acceleration. But as we’ve established, I didn’t have the right mental framework.
Now that that’s clarified maybe I will go back to messing with the IMU sooner rather than later to tackle the tf issue.
Thank you @cyclicalobsessive for getting me quite literally re-oriented.
/K
2 Likes
I have the “safe imu for ROS on GoPiGo3” interface running now. Just need to:
- learn how to package python so anyone can “sudo pip3 install imu4ros-gopigo3”
- build ROS2 IMU node without tf publisher
- learn how to use robot_localization
- back port it to ROS
2 Likes
Wow. That was fast.
/K
1 Like
oh, yeah… of course… simply that and every ROS doc … I’m totally with you.
2 Likes
An interesting observation - the IMU acceleration values are quite small with the LIDAR not spinning. When the LIDAR is running, my readIMU program reports the bot has moved - and it is definitely “moving”, just not going anywhere. Having the LIDAR on the third level is “rocking the bo[a]t”.
1 Like
Ugh. I was worried about that (even moreso with Finmark because the IMU is closer). Definite downsides to having something so compact. When I go back to the IMU I may also need to fiddle with a mount. The current friction mount is convenient, but I had to fiddle a bit to get the board level so that I wasn’t getting acceleration in the X and Y directions when the robot was at rest. No doubt vibration will disturb that - so I may work on something more fixed (and adjustable).
/K
2 Likes
Sorry, but I couldn’t resist:
2 Likes
You mean like my “velcro” mounting?
Really? I was assuming that was from lsb flopping in the math.
(I have seen the 9.8m/s of gravity appear as 10.0-10.1 without the LIDAR spinning)
I’m pretty sure ROS will be averaging all accelerations. In one person’s code for a 9250 IMU I saw filtered_value = (95% of the average value + new_value)/2 being used.
$ ./startIMU
Start DI IMU (BNO055 chip)
Using mutex-protected, exception-tolerant SW I2C
on GoPiGo3 port AD1 in NDOF mode
IMU READING AFTER RESET:
Euler Heading: 359.9 Roll: -1.3 Pitch: -0.4 | Linear Acc XYZ: 0.0 0.0 0.1 | Mag XYZ: -22.1 9.0 -24.9 | Gyro XYZ: 0.0 0.1 0.1 | Accel XYZ: -0.2 -0.1 10.0 | Temp: 23.0C
Exiting startIMU
pi@ROSbot:~/rosbot-on-gopigo3/imu4gopigo3ros$ ./readIMU
Reading the Dexter Industries IMU Sensor
Using mutex-protected, exception-tolerant SW I2C on GoPiGo3 port AD1
Expand the window till this line fits
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
SafeIMUSensor INSTANTIATING ON PORT AD1 OR BUS GPG3_AD1 WITH MUTEX True INIT False (no mode change)
InertialMeasurementUnit INSTANTIATING ON BUS GPG3_AD1 INIT False (no mode change)
BNO055 Instantiating on BUS GPG3_AD1 with ADDRESS 40 using UNITS 0 HW INIT False
Set _mode to: 12
BNO055 Instantiation Complete
InertialMeasurementUnit Instantiation Complete
SafeIMUSensor Instantiation Complete
2021-09-19 13:29:05.916174: Exception Count: 0
Euler Heading: 359.9 Roll: -1.3 Pitch: -0.4 | Linear Acc XYZ: -0.0 0.0 0.2 | Mag XYZ: -21.4 10.5 -24.6 | Gyro XYZ: -0.2 -0.1 -0.1 | Accel XYZ: -0.2 -0.0 9.9 | Temp: 24.0C
Euler Heading: 359.9 Roll: -1.3 Pitch: -0.4 | Linear Acc XYZ: -0.0 0.0 0.2 | Mag XYZ: -20.2 10.1 -24.6 | Gyro XYZ: 0.1 0.1 0.0 | Accel XYZ: -0.2 -0.1 10.0 | Temp: 24.0C
Euler Heading: 359.9 Roll: -1.3 Pitch: -0.4 | Linear Acc XYZ: -0.0 0.0 0.2 | Mag XYZ: -21.0 9.8 -25.4 | Gyro XYZ: 0.1 -0.1 0.1 | Accel XYZ: -0.2 -0.1 10.1 | Temp: 24.0C
Euler Heading: 359.9 Roll: -1.3 Pitch: -0.4 | Linear Acc XYZ: -0.0 0.0 0.2 | Mag XYZ: -21.4 9.1 -25.4 | Gyro XYZ: 0.0 -0.2 0.1 | Accel XYZ: -0.2 -0.1 10.0 | Temp: 24.0C
Euler Heading: 359.9 Roll: -1.3 Pitch: -0.4 | Linear Acc XYZ: 0.0 0.0 0.2 | Mag XYZ: -21.0 9.8 -25.0 | Gyro XYZ: 0.0 0.0 -0.1 | Accel XYZ: -0.2 -0.1 9.8 | Temp: 25.0C
and without mags (IMUPLUS mode)
$ ./startIMU -i
Start DI IMU (BNO055 chip)
Using mutex-protected, exception-tolerant SW I2C
on GoPiGo3 port AD1 in IMUPLUS mode
IMU READING AFTER RESET:
Euler Heading: 359.9 Roll: -1.3 Pitch: -0.4 | Linear Acc XYZ: 0.0 -0.0 0.3 | Mag XYZ: 0.0 0.0 0.0 | Gyro XYZ: 0.1 0.2 0.0 | Accel XYZ: -0.2 -0.1 10.1 | Temp: 25.0C
Exiting startIMU
pi@ROSbot:~/rosbot-on-gopigo3/imu4gopigo3ros$ ./readIMU -h
Reading the Dexter Industries IMU Sensor
Using mutex-protected, exception-tolerant SW I2C on GoPiGo3 port AD1
Expand the window till this line fits
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012
SafeIMUSensor INSTANTIATING ON PORT AD1 OR BUS GPG3_AD1 WITH MUTEX True INIT False (no mode change)
InertialMeasurementUnit INSTANTIATING ON BUS GPG3_AD1 INIT False (no mode change)
BNO055 Instantiating on BUS GPG3_AD1 with ADDRESS 40 using UNITS 0 HW INIT False
Set _mode to: 8
BNO055 Instantiation Complete
InertialMeasurementUnit Instantiation Complete
SafeIMUSensor Instantiation Complete
2021-09-19 13:36:50.627147: Exception Count: 0
Euler Heading: 359.9 Roll: -1.3 Pitch: -0.4 | Linear Acc XYZ: 0.0 -0.0 0.3 | Mag XYZ: 0.0 0.0 0.0 | Gyro XYZ: 0.1 0.1 0.0 | Accel XYZ: -0.2 -0.1 10.1 | Temp: 25.0C
X and Y linear accelerations seem to be stable - but I don’t actually think ROS uses them. That Z acceleration makes it look like Dave is constantly climbing the walls (or maybe he is surfing the gravity waves).
2 Likes
Exactly. Love it - college days memory.
2 Likes
Correct me if I am wrong, but isn’t something like 90% of your problem because Dave is too tall?
A 'bot that tall with respect to its wheel-base would scare me.
At the very grave risk of insulting both you and your robot paradigm, I would seriously consider a “scaled down” version of the 'bot without the handles, character, and anything else that is not absolutely necessary for a working robot. Especially things that raise the center of gravity.
Once you get the 'bot working, you can then worry about all the bells, whistles, flashing lights and dancing bears. (At least that’s how I see it, IMHO.)
I would also consider placing the LIDAR on the bottom layer since the lever moment of the LIDAR’s weight and vibration will be mimized the lower you place it.
Things like the Pi itself, the GoPiGo board and associated sensors can be placed on top of that.
What say ye?
Just thought of something.
You’ll probably need to extend the GoPiGo motor wires. Of course, for an old hand at surface mount rework like you, that should be a cinch!
2 Likes
There may come a time for optimization, but at this point all I need from Dave is:
- A sensor mounted somewhere
- A URDF that accurately describes the position relative to the center of the wheels, and orientation
- A node that publishes sensor data with some periodicity without crashing
- A Rviz2 configuration that displays the data
so I can move on to learning about localization, mapping, and navigation.
If you are referring to platform vibrations reflected in the IMU output, I don’t even know if that is a problem. At this point it is an observation.
2 Likes
I can accept that.
Might the same be said for the concerns about the IMU and the LIDAR/wheel motor magnets?
But I remember something about vibration affecting the LIDAR - or, maybe I really am as confused as my wife thinks I am, 'eh?
2 Likes
I didn’t think a handle was that necessary either, but Carl has nearly ripped his scalp off from me lifting him by his safety goggle over the last three years.
I use Dave’s handle several times a day turning him around, putting him up on my desk so I can get at his “guts”, and posing him for the selfies he seems to want every time he gets a new toy.
And the character, well that is necessary … I’m sure - I’m just old enough to have forgotten why.
2 Likes
Always good to have minions at your beck and call
/K
2 Likes