Migrated from tech-debt.md (deleted, see repo history via git log -- tech-debt.md).
URDF.UR5's gripper_link_index=7 is a hardcoded position, not a stable identifier. UR5.__init__ calls super().__init__("ur5", ..., gripper_link_index=7) -- a raw positional index into the parsed link list meant to mark the gripper/tool attachment link.
Already bit once: robot_descriptions 3.0.0 changed which upstream repo "ur5" resolves to (Universal_Robots_ROS2_Description instead of whatever 2.0.0 pointed at), and the two versions parse to different link counts (11 vs. 13) and orderings -- index 7 moved from the intended attachment point onto wrist_2_link, a real arm joint, silently dropping 2 of 6 joints from self.n. Immediate fix already applied: pinned robot_descriptions>=2.0,<3.0 in pyproject.toml, restoring known-working data. This does not fix the underlying fragility, just stops it firing today.
Confirmed a name/structure-based fix is viable: comparing the full raw link lists between the two robot_descriptions versions, all 6 real arm joints have identical names/isjoint status in both. Only the gripper-attachment link's name differs (ee_link in 2.0.0 vs not present in 3.0.0), but tool0 exists in both -- just at a different index (9 vs. 12). A name-based lookup ("tool0") or a structural one ("first fixed link after the last actuated joint") would survive this exact upstream change.
Proposed fix: replace gripper_link_index: int with a lookup that doesn't depend on absolute position -- match by a small set of known tool-frame names (tool0, ee_link, flange, ...) with a fallback, or derive structurally. Worth checking how many other URDF.* models pass a raw gripper_link_index the same fragile way before deciding on the general fix -- UR5 is likely not unique.
Migrated from
tech-debt.md(deleted, see repo history viagit log -- tech-debt.md).URDF.UR5'sgripper_link_index=7is a hardcoded position, not a stable identifier.UR5.__init__callssuper().__init__("ur5", ..., gripper_link_index=7)-- a raw positional index into the parsed link list meant to mark the gripper/tool attachment link.Already bit once:
robot_descriptions3.0.0 changed which upstream repo"ur5"resolves to (Universal_Robots_ROS2_Descriptioninstead of whatever 2.0.0 pointed at), and the two versions parse to different link counts (11 vs. 13) and orderings -- index7moved from the intended attachment point ontowrist_2_link, a real arm joint, silently dropping 2 of 6 joints fromself.n. Immediate fix already applied: pinnedrobot_descriptions>=2.0,<3.0inpyproject.toml, restoring known-working data. This does not fix the underlying fragility, just stops it firing today.Confirmed a name/structure-based fix is viable: comparing the full raw link lists between the two
robot_descriptionsversions, all 6 real arm joints have identical names/isjointstatus in both. Only the gripper-attachment link's name differs (ee_linkin 2.0.0 vs not present in 3.0.0), buttool0exists in both -- just at a different index (9 vs. 12). A name-based lookup ("tool0") or a structural one ("first fixed link after the last actuated joint") would survive this exact upstream change.Proposed fix: replace
gripper_link_index: intwith a lookup that doesn't depend on absolute position -- match by a small set of known tool-frame names (tool0,ee_link,flange, ...) with a fallback, or derive structurally. Worth checking how many otherURDF.*models pass a rawgripper_link_indexthe same fragile way before deciding on the general fix -- UR5 is likely not unique.