ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
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.
2 | No.2 Revision |
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>
3 | No.3 Revision |
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>
4 | No.4 Revision |
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.