-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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.
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
Range sensor layer can't transform from odom to range_sensor_link #2975
Comments
You should print If If the times are on different clocks, that means 1 thinks its on simulation time and the other is on wall time, in that case, you need to correct the use of |
I forgot to mention that the range sensor messages are sent by some node of the pluging libgazebo_ros_ray_sensor.so. I check the parameter of /local_costmap node and range_sensor node and both have use_sim_time to true. There is a difference between the stamp and now ans this difference is getting bigger over time |
That is an odd problem but I'm not sure how I/Nav2 can help with that. It sounds like there's an issue with how the sonar data is coming out of the simulator or something to do with clocks not being the same (?). Doesn't seem the part of Nav2 to resolve but you're welcome to file tickets with the simulator plugin repository or look at the source code yourself about why the delay. |
Our robot is also using some lidar scanner which use the same gazebo pluging (libgazebo_ros_ray_sensor.so). The sensor_msgs/LaserScan are also connected to the local_costmap throught the nav2_costmap_2d::ObstacleLayer and to the global_costmap throught the nav2_costmap_2d::ObstacleLayer and nav2_costmap_2d::VoxelLayer. I do not have a warning with those layer. It seem that the transform are handled differently in the range_sensor_layer and in the obstacle_layer. The obstacle_layer is more complex, but as I understand it is transforming the laserscan to a point cloud using the laser_geometry package, but I don't see where the transformation is done. That why I was thinking that it may have something to do with the range_sensor_layer. |
Does everything work fine after Can you try to modify the canTransform call to use the timeout? https://github.com/ros2/geometry2/blob/ros2/tf2_ros/include/tf2_ros/buffer.h#L170 like we do with If that doesn't work (I think it should), here's what we can do. I tracked down internal to |
Any feedback? |
I did not made the test you suggested with the timeout yet. I should be able to do it before the end of the week. Thanks you for following with me. |
Hi, Any update? |
I modified the can transform call based on https://github.com/ros2/geometry2/blob/ros2/tf2_ros/include/tf2_ros/buffer.h#L170 the log is gone and we see that the range sensor are used in the local costmap. I used the transform tolerance as the duration in the can_transform as this duration us used in the call to transform later. In my test the transform_tolerance was set to 0.3s. I can try to create a pull request with the changes. Thanks you following with me on this request |
Please! I look forward to it! |
Whoops, wrong button |
Il did a pull request to the galactic branch as I tested it using this branch. The mergify bot told me that I should do it to the main branch. Should I create a new pull request to the main branch? #3053 |
Yes please! All changes go from main -> backport elsewhere so that it can be contained in all future distributions |
Required Info:
Operating System: Ubuntu 20.04
ROS2 Version: Galactic binaries
Version or commit hash: 1.08
DDS implementation: Default
Steps to reproduce issue
Expected behavior
It should have a similar behavior than the "ObstacleLayer" pluging when dealing with the update rate of the odom->base_footprint frame instead.
Actual behavior
It seem that the range messages that can't have a transform from odom to range_sensor_link are discarded.
Additional information
I add to the range_sensor_layer.cpp a fallback canTransform check for the latest tranform in the range sensor layer for my test and it did seem to work well, but I know this is probably not a good solution as the transforms can be wrong if they are too old.
The text was updated successfully, but these errors were encountered: