Revision history - ROS Answers: Open Source Q&A Forum

Here's your configuration:

<param name="imu0" value="mobile_base/sensors/Imu_data"/>

Here's the topic name in the bag file:

/mobile_base/sensors/imu_data

ROS topics are case-sensitive (see the capital I in the r_l config), so I'm guessing it's not subscribed.

rostopic info and rosnode info are useful tools for determining when nodes aren't receiving data from one another.

Also, your tf tree image is cut off, but make sure something is publishing the base_link->gyro_link transform.

Here's your configuration:

<param name="imu0" value="mobile_base/sensors/Imu_data"/>

Here's the topic name in the bag file:

/mobile_base/sensors/imu_data

ROS topics are case-sensitive (see the capital I in the r_l config), so I'm guessing it's not subscribed.

rostopic info and rosnode info are useful tools for determining when nodes aren't receiving data from one another.

Also, your tf tree image is cut off, but make sure something is publishing the base_link->gyro_link transform.

EDIT in response to update:

That plot looks like it may be correct. Just because you're fusing sensor data doesn't mean the output of that fusion will be perfect. There will still be drift over time, unless you fuse a source of pose data that is externally referenced, e.g., from amcl or a GPS. Also, you're fusing your magnetometer data from your IMU, which can be inaccurate. Go back to your original IMU configuration:

<rosparam param="imu0_config">[false, false, false, 
                               false, false, false, 
                               false, false, false, 
                               false, false, true,
                               false, false, false]</rosparam>

Here's your configuration:

<param name="imu0" value="mobile_base/sensors/Imu_data"/>

Here's the topic name in the bag file:

/mobile_base/sensors/imu_data

ROS topics are case-sensitive (see the capital I in the r_l config), so I'm guessing it's not subscribed.

rostopic info and rosnode info are useful tools for determining when nodes aren't receiving data from one another.

Also, your tf tree image is cut off, but make sure something is publishing the base_link->gyro_link transform.

EDIT in response to update:

That plot looks like it may be correct. Just because you're fusing sensor data doesn't mean the output of that fusion will be perfect. There will still be drift over time, unless you fuse a source of pose data that is externally referenced, e.g., from amcl or a GPS. Also, you're fusing your magnetometer data from your IMU, which can be inaccurate. Go back to your original IMU configuration:

<rosparam param="imu0_config">[false, false, false, 
                               false, false, false, 
                               false, false, false, 
                               false, false, true,
                               false, false, false]</rosparam>

Here's your configuration:

<param name="imu0" value="mobile_base/sensors/Imu_data"/>

Here's the topic name in the bag file:

/mobile_base/sensors/imu_data

ROS topics are case-sensitive (see the capital I in the r_l config), so I'm guessing it's not subscribed.

rostopic info and rosnode info are useful tools for determining when nodes aren't receiving data from one another.

Also, your tf tree image is cut off, but make sure something is publishing the base_link->gyro_link transform.

EDIT 1 in response to update:

That plot looks like it may be correct. Just because you're fusing sensor data doesn't mean the output of that fusion will be perfect. There will still be drift over time, unless you fuse a source of pose data that is externally referenced, e.g., from amcl or a GPS. Also, you're fusing your magnetometer data from your IMU, which can be inaccurate. Go back to your original IMU configuration:

<rosparam param="imu0_config">[false, false, false, 
                               false, false, false, 
                               false, false, false, 
                               false, false, true,
                               false, false, false]</rosparam>

EDIT 2 in response to comments:

Tuning covariance can be a pain. A simple method for calculating variance is to drive your robot and have a means of ground-truthing the real value for that variable. For example, measure distances on the floor and lay down tape, then drive the robot. Look at the reported position and velocity, and compare that with the distance and velocity the robot actually drove. This is a bit naive and ignores off-diagonal correlations between variables in the covariance matrix, but seems to work well in practice. A less elegant method involves hand-tuning the values until the covariance matrix that is output by r_l grows at a realistic rate. There are much more sophisticated methods in the literature, but I think most users get good results using one of the two methods above.

The state estimation nodes in r_l will fuse data from any number of sensors, so long as they produce one of the supported message types. Since amcl can produce a PoseWithCovarianceStamped, its output can be fused into r_l. You might want to use a two-tier setup similar to the one suggested for integrating GPS if you go this route, as amcl poses may jump, so you wouldn't want to execute local path planner motions using that state estimate.

Revision history [back]