The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
After an extensive investigation involving adjusting various parameters innav2_params.yaml and experimenting with different positions and orientations of the LiDAR sensor, I discovered that the issue was not related to the sensor's range, pose, FOV, or any other related factors.
The root of the problem lies in the configuration of theslam-toolbox package. For some reason, it was misconfigured and did not work properly with the local costmap and voxel layer.
When running a static transform publisher (map --> odom):
ros2 run tf2_ros static_transform_publisher 0 0 0 0 0 0 map odom
Both local and global costmaps are generated, but the map itself is not produced:
image description
Adjustments were made to the Voxel map range (width, height), and the raytrace range was increased to better suit the robot's dimensions and the environment's size.
However, when running the slam dynamic transform (map --> odom) using :
ros2 launch slam_toolbox online_sync_launch.py
The map and global costmap are generated, but the local costmap is not (even for the TurtleBot3 Waffle tutorial example or for my robot):
A closer examination of the /tf topic reveals differences between the transforms when using the slam-toolbox async node and the static transform.
slam-toolbox async node:
transforms:
static transform:
transforms:
There is not aperiodic transform published between the map and odom using static transform, I just infer that probably the local costmap plugin maybe executes this transform (not sure) and when using the slam mapping node, it kind that is overlaid by the periodic transform between from odom to map frame causing conflicts ???....
It's unclear how the Voxel grid plugin code is integrated with the slam-toolbox and how it affects the local costmap generation. Further investigation into the interplay between these components is needed to pinpoint the exact cause of the issue.
In summary, the problem seems to stem from the slam-toolbox configuration and its interaction with the local costmap and voxel layer. A thorough investigation of the relevant components and their interdependencies could potentially reveal the root cause and offer a more permanent solution.
| | 2 | No.2 Revision |
After an extensive investigation involving adjusting various parameters innav2_params.yaml and experimenting with different positions and orientations of the LiDAR sensor, I discovered that the issue was not related to the sensor's range, pose, FOV, or any other related factors.
The root of the problem lies in the configuration of theslam-toolbox package. For some reason, it was misconfigured and did not work properly with the local costmap and voxel layer.
When running a static transform publisher (map --> odom):
ros2 run tf2_ros static_transform_publisher 0 0 0 0 0 0 map odom
Both local and global costmaps are generated, but the map itself is not produced:
image description
Adjustments were made to the Voxel map range (width, height), and the raytrace range was increased to better suit the robot's dimensions and the environment's size.
However, when running the slam dynamic transform (map --> odom) using :
ros2 launch slam_toolbox online_sync_launch.py
The map and global costmap are generated, but the local costmap is not (even for the TurtleBot3 Waffle tutorial example or for my robot):
A closer examination of the /tf topic reveals differences between the transforms when using the slam-toolbox async node and the static transform.
slam-toolbox async node:
transforms:
static transform:
transforms:
There When using the static transform, there is not aperiodic no periodic transform published between the map and odom using static transform, frames. I just infer suspect that probably the local costmap plugin maybe executes might rely on this transform (not sure) (although I'm not certain), and when using the slam mapping node, it kind that is overlaid by the periodic transform between from the odom to and map frame frames may interfere or overlap with the static transform, potentially causing conflicts ???....conflicts.
It's unclear how the Voxel grid plugin code is integrated with the slam-toolbox and how it affects the local costmap generation. Further investigation into the interplay between these components is needed to pinpoint the exact cause of the issue.
In summary, the problem seems to stem from the slam-toolbox configuration and its interaction with the local costmap and voxel layer. A thorough investigation of the relevant components and their interdependencies could potentially reveal the root cause and offer a more permanent solution.
| | 3 | No.3 Revision |
After an extensive investigation involving adjusting various parameters innav2_params.yaml and experimenting with different positions and orientations of the LiDAR sensor, I discovered that the issue was not related to the sensor's range, pose, FOV, or any other related factors.
The root of the problem lies in the configuration of theslam-toolbox package. For some reason, it was misconfigured and did not work properly with the local costmap and voxel layer.
When running a static transform publisher (map --> odom):
ros2 run tf2_ros static_transform_publisher 0 0 0 0 0 0 map odom
Both local and global costmaps are generated, but the map itself is not produced:
image description
Adjustments were made to the Voxel map range (width, height), and the raytrace range was increased to better suit the robot's dimensions and the environment's size.
However, when running the slam dynamic transform (map --> odom) using :
ros2 launch slam_toolbox online_sync_launch.py
The map and global costmap are generated, but the local costmap is not (even for the TurtleBot3 Waffle tutorial example or for my robot):
A closer examination of the /tf topic reveals differences between the transforms when using the slam-toolbox async node and the static transform.
slam-toolbox async node:
transforms:
static transform:
transforms:
When using the static transform, transform, there is no periodic transform published between the map and odom frames. I suspect that the local costmap plugin might rely on this transform (although I'm not certain), and when using the slam mapping node, the periodic transform between the odom and map frames may interfere or overlap with the static transform, potentially causing conflicts.
It's unclear how the Voxel grid plugin code is integrated with the slam-toolbox and how it affects the local costmap generation. Further investigation into the interplay between these components is needed to pinpoint the exact cause of the issue.
In summary, the problem seems to stem from the slam-toolbox configuration and its interaction with the local costmap and voxel layer. A thorough investigation of the relevant components and their interdependencies could potentially reveal the root cause and offer a more permanent solution.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.