ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
Hi Naman,
I'm the author/maintainer of that package.
The initial rotation is just the default orientation, since we disabled the magnetometer in that launch file, so there is no external reference. When you use this in combination with robot_pose_ekf
, like we do, this doesn't matter, since robot_pose_ekf
doesn't care for the absolute angles reported by the IMU, it only uses the difference between measurements.
@Humpelstilzchen is right, it's not drift. Instead, in the default magnetometer calibration, there is a huge offset in the Phidgets devices. If you imagine the magnetometer readings as a sphere, it's not centered around the origin, instead it's shifted completely into one quadrant. The result is that the magnetometer vector always points into that quadrant, which the filter tries to compensate for, but fails of course.
The solution is to calibrate the phidgets device (if possible, while it is mounted on the robot, but without switching the robot motors on) using the Windows tool described in the Phidgets user guide. You'll end up with a set of parameters that you'll have to pass to the phidgets driver in the cc_*
(compass correction) params; look at the commented out code in this launch file.
This will calibrate for hard iron and soft iron correction; however, changing magnetic fields will still give you problems (e.g., from the robot's motors or when driving indoors, where there are ferromagnetic materials in the building structure). That's why we chose not to use the magnetometer in our case.