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.

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

Setup assistant reads the robot_description parameter overriding the topic reading #3281

Open
Danilrivero opened this issue Jan 28, 2025 · 2 comments
Labels
bug Something isn't working stale Inactive issues and PRs are marked as stale and may be closed automatically.

Comments

@Danilrivero
Copy link

Danilrivero commented Jan 28, 2025

Description

Hello,

Just recently we noticed that after updating with moveit_setup_assistant a few things at our moveit_description package, we would end up with things such as RViz suddenly crashing. Upon inspection we noticed this line at the MoveItConfigsBuilder class.

The part from the .setup_assistant that matters the most is here:

moveit_setup_assistant_config:
  urdf:
    package: robot_pkg_description
    relative_path: urdf/robot.urdf.xacro
  srdf:
    relative_path: config/robot.srdf

Before this change the path given for the package was to another one that did (wrongfully) not contain said file, which would force as stated here to use the topic (which has always been our intended way to do so to avoid using parameters) which has been discussed before #2291 #2291 (comment).

We provide our /robot_description as usual through rsp and setting many arguments (e.g. instantiating different cameras, light mode flag for meshes, avoid instantiating the mobile robot base...), these arguments are set depending on certain requirements that would change the tf_tree of the robot being published, which would be different from the one by default being read when .setup_assistant reaches out for it as a parameter. This would find some issues between the tf_tree being received by the MotionPlanning plugin at RViz and the one we would expect to be given and thus failing.

In short, we are forced to feed the /robot_description through a topic and everytime you use .setup_assistant it will update it to use the parameter instead potentially breaking the functionality.

Packages such as the ur_gz_sim have directly removed said file which would remove you from the ability to do any required updates through moveit_setup_assistant if required.

Is this an unintended consequence, or a feature that simply forces to avoid using such files? Are there any other discussions about this? Are we missing something?

Thanks (This could be moved to discussions)

ROS Distro

Jazzy

OS and version

Ubuntu 24.04

Source or binary build?

Binary

If binary, which release version?

2.12.1

If source, which branch?

No response

Which RMW are you using?

CycloneDDS

Steps to Reproduce

  1. Have .setup_assistant pass the urdf file at the expected path.
  2. Define as a topic a different /robot_description from the default one being passed.
  3. Any nodes being passed the information such as RViz could clash on the information given.

Expected behavior

Avoid passing the parameter by avoiding this instance or deleting .setup_assistant?

Actual behavior

Nodes such as RViz crash because the MotionPlanning plugin finds a clash between the given robot_descriptions.

Backtrace or Console output

No response

@Danilrivero Danilrivero added the bug Something isn't working label Jan 28, 2025
@sea-bass
Copy link
Contributor

I think this code isn't updated often and it comes from a time in which reading from parameter vs topic was not deprecated. It likely needs an update.

Copy link

This issue is being labeled as stale because it has been open 45 days with no activity. It will be automatically closed after another 45 days without follow-ups.

@github-actions github-actions bot added the stale Inactive issues and PRs are marked as stale and may be closed automatically. label Mar 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working stale Inactive issues and PRs are marked as stale and may be closed automatically.
Projects
None yet
Development

No branches or pull requests

2 participants