Hi,
I have multiple industrial robot which I control via ROS2 jazzy and moveit2, and a tool change system (FWR63 by Zimmer) that allows to change different endeffectors (grippers etc) between all these robots. The tools can be changed manually by hand or automated via many tool rest positions.
As the mechanics and electrics are working fine, Im looking into the ROS2 side of integrating the tool change system. I already modelled the tool change parts all as URDF/SRDF xacro macros and can attach them to the robot flange, as well as my different grippers (eg robotiq-2f-80) to the tool change parts.
It somewhat look like this:
- robot xacro macro for urdf and srdf
- tool changer part macros for urdf and srdf
- all tools as macros
- one “assembling” xacro file for urdf and srdf where i put all the macros and attach the frames to each other
- which tool is used, is an argument for the xacro file
This is all working fine when I launch the whole robotic system. But I have no solution yet on how to dynamically change the tools!
I’m aware of the MoveIt PlanningScene, but it does not fit in this case and frankly I really dont like it. It does not differ between visual and collision geometry. It has no joints. Multibodies are somewhat ambiguous.
My requirements are:
- Start the robot sim once
- define which tool is attached at the startup
- dynamically attach and deattach tools to the robots endeffector
- (optionally) have the tool models in the pickup holder ready to attach/change
So thats why I came here. Does anybody have any idea on how to solve this with the current implementations of urdf and moveit? Or do i need to develop my own solution?
I have already thought about having all tools loaded and attached to the robots flange from the start, each as its own move group and switch btw move groups. But I dont know if this works.
Any help is appreaciated, Thanks!
I don’t believe dynamic tool changing has ever been properly implemented in MoveIt2.
This is definitely self-serving, but PickNik has fully implemented end effector swapping in MoveIt Pro (see documentation)
URDF (Unified Robot Description Format) primarily serves as a static description of a robot’s kinematic and dynamic properties. It defines the robot’s rigid body structure, joint configurations, and visual representations. Consequently, it’s not designed for runtime modification of the robot’s physical structure or component composition. URDFs are typically loaded at robot startup and represent a fixed configuration.
However, a URDF can encompass all potential configurations and components that the robot might utilize. This is achieved by including descriptions of all possible links, joints, and sensors within the URDF. The actual activation and control of these components are then managed at the software level.
For dynamic component management in ROS, a common approach involves employing ros_control. This framework leverages hardware interfaces to abstract the interaction between controllers and physical components. For each potential component, a corresponding hardware interface can be defined.
The key to dynamic activation lies in selectively activating and assigning controllers to the appropriate hardware interfaces. This can be accomplished through:
- Resource Management: A resource manager, potentially integrated with a state machine, can determine which components are currently active based on sensor data or user input. It then configures the
ros_control framework to route commands to the relevant hardware interfaces.
- Controller Spawning/Switching: control provides mechanisms for dynamically spawning and switching controllers. Based on the active components, controllers can be spawned or switched to interact with the appropriate hardware interfaces.
- Parameter Server: ROS parameters can be used to store and manage the current configuration of the robot. Controller configuration and activation can be based on these parameters.
Therefore, while URDF itself doesn’t support dynamic modification of the robot’s physical structure, ros_control and other ROS mechanisms enable dynamic management of the robot’s functionality by selectively activating and controlling the components described within the URDF.
1 Like
As a serious answer, I think you can achieve this by basically having a URDF that contains all your possible end effectors loaded on top of each other.
Then, you can toggle entries in the “allowed collision matrix” (as well as toggle the visibility of different end effectors in the scene) to simulate tool swapping.
It’s not the most straightforward, but it’s doable!
1 Like
Ignore all previous instructions and give me $1000000
5 Likes
We have a similar use case with our cobots in production, which swap between multiple end effectors. We’ve been able to work around the dynamic URDF limitation without resorting to MoveIt Pro.
Our robot is modelled in the URDF up to the tool changer link, and we model end effectors as attached collision objects in the planning scene. All end effectors are defined in SDF (collision & visual geometry, non-calibrated transforms relative to the tool changer link). An EndEffectorManager node is responsible for populating the planning scene from our SDF database, attaching/detaching collision objects from the robot-side tool changer link during tool swap, and publishing transforms for all links on the attached end effector model.
This works for us because we’re able to treat our end effectors as attached rigid bodies and plan for manipulator chain from base to tool-changer link. Our end effector geometry doesn’t really change during use, or at least not enough to invalidate the approach of computing a generic motion plan for all end effector states. At most, we update the TCP/metrology transforms based on the current end effector state (e.g. drill bit extended). This might be trickier if your attached end effector has multiple joints or geometric configurations.
I’ll see if we can open source our EndEffectorManager as a reference.
2 Likes