Rotating (pivoting) robot doesn't update map in ROS2 Foxy

[maksimmasalski]

Required Info:

• Operating System:
  • Ubuntu 20.04.4 LTS
• Installation type:
  • from source
• ROS Version
  • ROS2 foxy (foxy-devel branch slam-toolbox)
• Version or commit hash:
  • 4786e90
• Laser unit:
  • SICK NanoScan in ROS2 setup
  • RPLidar A3 in ROS1 setup

Actual behavior

In ROS2 when robot pivot around map is not updating. At the same time in ROS1 the same action updates a map. I want to note that in ROS2 my lidar has around 100 degrees view (it is initially 270 degree lidar), and ROS1 has 360 degrees setup. But anyway, config minimum_travel_heading must work. In ROS2 I was able to update a map when robot turning around only if value os this config is 0 minimum_travel_heading: 0.0

Please watch my two videos to better understand issue:

1. ROS1 Good behavior, map update works when config value is minimum_travel_heading: 0.5
   https://youtu.be/-d_QMwmAbWA

2. ROS2 https://youtu.be/N9AKocROm2c
   ROS2 Map update doesn't work when config value is minimum_travel_heading: 0.5

In ROS2 it works only if minimum_travel_heading: 0.0 AND minimum_travel_distance: 0.0
This video demonstrates behavior when this configs are 0 https://youtu.be/dTisi1g3AyE
When robot is moving straight forward, it can update map, but pivoting doesn't update it.

Want to mention that ROS1 movement is real-time and ROS2 robot movement is a bag. Also they have different wheels, ROS1 robot is like in the video (2 wheels), ROS2 is a Robotnik Vogue https://robotnik.eu/products/mobile-robots/rb-vogui-en/

Expected behavior

I expect in ROS2 to see the same behavior as ROS1. Map updates when robot is turning around with config value minimum_travel_heading: 0.5

[SteveMacenski]

I don't think anything in the codebase w.r.t. that has been changed, but I'd recommend taking a look and seeing if you find something off there in ROS 2. Happy to look over a PR with a patch

[maksimmasalski]

I don't think anything in the codebase w.r.t. that has been changed, but I'd recommend taking a look and seeing if you find something off there in ROS 2. Happy to look over a PR with a patch

Can it be also an odometry problem? I don't use IMU. Because this robot, has totally different ways to steer comparing with the ROS1 robot.

[maksimmasalski]

I don't think anything in the codebase w.r.t. that has been changed, but I'd recommend taking a look and seeing if you find something off there in ROS 2. Happy to look over a PR with a patch

Can it be also an odometry problem? I don't use IMU. Because this robot, has totally different ways to steer comparing with the ROS1 robot.

Will it be a problem for the slam toolbox efficiency creating so many red dots (graphs) due to config values minimum_travel_heading: 0.0 and minimum_travel_distance: 0.0?

[maksimmasalski]

What I can try, is to run ROS2 with the same ROS1 robot using bridge to see what behavior will happen, so will be used the same robot. Then will tell the result.

[destogl]

I can confirm this issue in humble too. With short search through the code, I don't see any issue there with parameter handling, to figure it out, one has to dive into business logic.

For now is my solution to put the both values to 0 and also reduce map_update_interval to 0.1 to have high frequency updates.

[maksimmasalski]

I can confirm this issue in humble too. With short search through the code, I don't see any issue there with parameter handling, to figure it out, one has to dive into business logic.

For now is my solution to put the both values to 0 and also reduce map_update_interval to 0.1 to have high frequency updates.

Could you share screen recording?

[destogl]

@maksimmasalski Can not, informally, as the project is not public yet. The proposal fix if in #709