When there are joints what don't have implemented limits rqt-jtc throws a lot of errors.

I see the need for the namespace issue, but what do you mean by that? A revolute/prismatic joint without limits is not a genuine URDF, and we throw an error since ros-controls/ros2_control#1256, or ros2_control 4.9.0 respectively.

@christophfroehlich
I'm wandering why RQT-JTC checks limits for all joints described in URDF if it has an access for joints controlled by JTC via jtc_info.

I'm asking about this because when the errors about unknown limits of mimic joints throw then there JTC doen't appear in controllers combo.
Here is a video where I cannot select the controller.

Ok, so the problem comes from mimic joints, where no limits are given? That does not make a lot of sense to add it, but it is not explicitly given in the XML specification that it can be omitted. I'll come back later to check what we excpect in the component parser.

Take a look to robotiq_description. The controlled revolute joint ${prefix}robotiq_85_right_knuckle_joint has limits defined but its mimic joints does not. That is why the exceptions throw.

I don't really know if limits should be implemented in continuous mimic joints or not.

The issue with RQT-JTC it that it is not possible to select a controller if the RQT-JTC cannot read the limits of all joints defined in robot_description. I don't really understand why RQT-JTC reads the limits of all joints. I think RQT-JTC should focus on its controlled joints.

Thanks for the background information. I agree that it should check the to-be-controlled joints only, but I'm still curious what should be the correct XML in this case. We have the limit tag in our examples and the release notes, but this should not block this PR but related to: #891
This PR is also related to #894 (you fixed the URDF source, now where we subscribe always from topic).

@christophfroehlich I moved the reading of joints to the another PR #1146

After that I change the robot_description feature.

This pull request is in conflict. Could you fix it @delihus?

@delihus could you please rebase this one? Or just resolve the conflicts

@bmagyar Updated

Thank you!

If we need this kind of setup, does it make sense to have the controller_manager republish the robot_description it is currently using?. This way applications such as rqt_joint_trajectory_controller or others can make use of it. What's your opinion on this? @bmagyar @destogl @christophfroehlich

@delihus We discussed this in the ros2_control meeting tonight, we want to go forward with your proposal. Please address my points above (defaulting to /robot_description etc) and we can go ahead with this 😊