[RQT-JTC] Allow incomplete joint limits#2404
Conversation
Co-authored-by: Jakub Delicat <109142865+delihus@users.noreply.github.com> Co-authored-by: dstogl <3429206+dstogl@users.noreply.github.com>
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #2404 +/- ##
==========================================
- Coverage 86.71% 86.70% -0.01%
==========================================
Files 148 148
Lines 15832 15898 +66
Branches 1347 1353 +6
==========================================
+ Hits 13728 13784 +56
- Misses 1609 1618 +9
- Partials 495 496 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
|
@lakhmanisahil I splitted the original PR, this one here is faster to review. As you have refactored the module recently, maybe you can have a quick look if that makes sense? Thank you! |
Hello, I tested it on Lyrical: colcon test passes 28/28, including the 6 new cases, and the parser behaves as expected in both strict and tolerant modes. The new default allow_incomplete_joints=False preserves the existing behavior. |
Co-authored-by: Marq Rasmussen <marq.razz@gmail.com>
| @@ -131,13 +157,32 @@ def parse_joint_limits(urdf_string, joints_names, use_smallest_joint_limits=True | |||
| if joint.type == "continuous": | |||
| minval = -pi | |||
There was a problem hiding this comment.
@MarqRazz the position limits for continuous joints were not changed here. The parser raises an exception if no velocity limit is set, so I hope the position limit is a useful default here?
I realize now before this PR the continuous joints were treated like revolute ones, but with the following lines they will be deactivated:
https://github.com/ros-controls/ros2_controllers/pull/2404/changes#diff-1fe0d2fd8e18b20c3df84a8d9060e7661230e1f8aa0329f7d6f53aa8ce14dedaR291
I think we should change that and set has_position_limits true for continuous joints (the variable name does not fit well, but the behavior remains the same).
What do you think?
There was a problem hiding this comment.
Ya we could set has_position_limits = True here. We are assigning limit values even though it doesn't have any and the RQT widget doesn't support jogging a joint beyond those values currently so we might as well be consistent.
|
|
||
| # No <limit> element at all means urdf_parser_py sets joint.limit to None | ||
| if joint.limit is None: | ||
| if name in joints_names and allow_incomplete_joints: |
There was a problem hiding this comment.
btw urdf_parser from robot_state_publisher will never run without a limit tag
[robot_state_publisher-2] Error: Joint [joint1] is of type REVOLUTE but it does not specify limits
[robot_state_publisher-2] at line 607 in ./urdf_parser/src/joint.cpp
[robot_state_publisher-2] Error: joint xml is not initialized correctly
[robot_state_publisher-2] at line 243 in ./urdf_parser/src/model.cpp
[robot_state_publisher-2] [WARN] [1781641700.051294975] [urdf]: Failed to parse robot description using: urdf_xml_parser/URDFXMLParser
[robot_state_publisher-2]
[robot_state_publisher-2] terminate called after throwing an instance of 'std::runtime_error'
[robot_state_publisher-2] what(): Unable to initialize urdf::model from robot description
but it seems that urdf_parser_py allows this, see test_missing_limit_tag_for_unrequired_joint_skipped_silently
Description
For faster review, I manually cherry-picked the changes regarding joint-limits from #1131
With #2254 and #2281 some of the changes were applied already, and the rest was not possible to be directly merged due to conflicts.
Also, the urdf_parser_py does not allow a
<limit>tag without velocity limits, so I removed the respective fallback section.Is this user-facing behavior change?
yes, but instead of crashing it should now gracefully try to do something useful and give warnings.
Did you use Generative AI?
GPT Codex 5.3