As part of an extended project I was working on a couple years ago, I made a Tinkerforge IMU Bricks V2 driver. It came to my attention from chatting with a colleague that this still remains to be one of the only USB IMU options and might be more popular with some of the hobbyist crowd. So I’d like to announce my open-sourcing of this basic IMU driver under an Apache 2.0 license.
It also goes to show how simple a ROS driver really needs to be. If you have stable hardware, there’s no need for more complex code than this. If you have unstable hardware, a while loop and some watch dogs are needed but don’t over-complicate it.
The driver also includes install scripts to download and install the tinkerforge software and daemons required to operate with one line ./tinkerforge_imu_ros/install.sh and you’re on your way with the provided launch files.
Note: Currently, it only provides the IMU’s orientation and orientation covariance information. If you have use for the angular velocities & linear accelerations, PRs are always appreciated. If someone submits a PR to implement that, I’ll spend some cycles to port it all over to ROS2.
I see that you are using 1e-8 as covariance. That is a lot higher then the value of 0.008 I’m using in my python script. I have more or less copied that value from the razor_imu package.
How did you estimate this value? I’ve always wondered on how to calculate the covariance value correctly.
Good question, I noticed that too while I was cleaning things up to post online.
That was done over 2 years ago so I can’t tell for certain, but I’m pretty sure I pulled that from benchmarking I did on another I2C chipset I was profiling with a BNO-055 around the same time after calibration. I agree that struck me a bit too low when I was looking over it just now but I have had a robot running around for the last 18 months with that running so it works empirically.
I just implemented my python script in c++ and cpu usage for this node went down by ~60% on a Cortex A9. So I have to admit using c++ makes more sense for this type of node.
It would be a very unusual situation if C++ were to be slower than python. Feel free to submit a PR to include all the data - right now it only spits out the orientation vector, as the readme indicates (and most people need for fusion)
