Felix Exner

@marols27 Any updates on this?

Closing this due to inactivity. Feel free to reopen if any new information is there.

This is an interesting problem, yes. One way to solve this, could be to not automatically start the gripper component at startup. This can be achieved using the controller_manager's `hardware_components_initial_state`...

Setup of the tool communication is performed as part of the "regular" [external_control script](https://github.com/UniversalRobots/Universal_Robots_Client_Library/blob/a4226e83ed0102dde8f5ce7fe474e0a35396ed5e/src/ur/ur_driver.cpp#L138-L141) once tool_communication is enabled in the launch file. AFAIK tool communication setup is part of a...

At this point, I cannot say much without seeing the actual assembled URDF and the exact commands and configs used to launch things.

As far as I can see from the files, you didn't include a ros2_control tag for the UR arm anywhere. Hence, ros2_control only knows your gripper, which isn't started. Hence,...

In your `ur10e_urdf.xacro` you add the robot:  I usually don't post screenshots of code, but in that case there's no code to refer to... But that is only giving...

Potentially, the gripper is slowing down the control loop. In that case you would probably need asynchronous hardware interfaces. See https://control.ros.org/rolling/doc/ros2_control/hardware_interface/doc/asynchronous_components.html for details.

Honestly, from this point on there's too much assumptions from my side, as I have personally never integrated a robotiq gripper with a UR arm in ROS 2. Hopefully, I...

> Without the gripper driver, the problem vanishes. If the gripper driver also uses ros2_control and is running on the same controller_manager as the UR driver, then the issue might...