Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
maksimmasalski opened this issue Jun 9, 2022 · 7 comments · May be fixed by #545
Open

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

maksimmasalski opened this issue Jun 9, 2022 · 7 comments · May be fixed by #545

Comments

@maksimmasalski
Copy link

maksimmasalski commented Jun 9, 2022 •
edited
Loading

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:
  • 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
Copy link
Owner

SteveMacenski commented Jun 9, 2022 •
edited
Loading

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
Copy link
Author

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
Copy link
Author

maksimmasalski commented Jun 9, 2022 •
edited
Loading

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
Copy link
Author

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.

@981213 981213 linked a pull request Oct 25, 2022 that will close this issue
Open
@destogl
Copy link

destogl commented Jun 16, 2024

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
Copy link
Author

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?

@Nibanovic Nibanovic mentioned this issue Jun 18, 2024
Open
@destogl
Copy link

destogl commented Jun 19, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

also check headings in shouldProcessScan 981213/slam_toolbox
3 participants
@destogl @SteveMacenski @maksimmasalski