ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
The problem was in the TF transform from odom -> base_link. I am using robot_localization to fuse IMU and wheel odometry data. When I instead used a static transform publish for the tf odom -> base_link, everything worked fine. I did see that when using robot_localization, there was small variations in the pitch and roll due to noise (or drift / inaccuracies) in the IMU.
"rosrun tf tf_echo odom base_link" gives
At time 1539332949.794
- Translation: [0.030, 0.002, 0.000]
- Rotation: in Quaternion [0.002, -0.000, 0.030, 1.000]
in RPY (radian) [0.005, -0.000, 0.061]
in RPY (degree) [0.268, -0.025, 3.494]
If you can imagine that the laser scan frame is not parallel to the 'ground' plane due to these small inaccuracies. Thus the Costmap2D was ignoring the laser scan values when the laser plane when below the ground plane.
Fix: In robot_localisation parameters.yaml file, there is a parameter called two_d_mode
# ekf_localization_node and ukf_localization_node both use a 3D omnidirectional motion model. If this parameter is
# set to true, no 3D information will be used in your state estimate. Use this if you are operating in a planar
# environment and want to ignore the effect of small variations in the ground plane that might otherwise be detected
# by, for example, an IMU. Defaults to false if unspecified.
two_d_mode: false
setting
two_d_mode: true
fixed the problem completely. The package then assumed 2D as so sets the pitch and roll to 0. There was never any problem with the lidar data or Costmap2D configuration but instead slight planer misalignment of the base_link frame (i.e. the transform odom -> base_link).