Movement overshoot with UR20 and ROS2-humble

[leander2189]

Affected ROS2 Driver version(s)

2.8.1-1jammy.20250915.231359

Used ROS distribution.

Humble

Which combination of platform is the ROS driver running on.

Docker

How is the UR ROS2 Driver installed.

From binary packets

Which robot platform is the driver connected to.

UR E-series robot

Robot SW / URSim version(s)

5.17.3

How is the ROS driver used.

Through the robot teach pendant using External Control URCap

Issue details

Summary

When doing long movements, the UR overshoots the final position and then corrects it back. This entails a serious risk for collisions.

WhatsApp.Video.2025-10-14.at.16.13.35.mp4

Issue details

We are running the software stack within a docker container, in a Ubuntu 22.04 with realtime kernel installed.

uname -a
Linux rout0-240626aa 5.15.0-1032-realtime #35-Ubuntu SMP PREEMPT_RT Tue Jan 24 11:45:03 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

I am not 100% sure whether the code inside the docker is using the realtime feature but it's not complaining in the launch (it did before the realtime kernel was installed)

We are controlling the UR20 using external control URCap, generating the motion plan using MoveIt and MTC. It looks like the controller detects that the UR has reached the position and returns (process keeps going on, see the light turning on in the video), but the robot is actually moving a little further and then it corrects back.

We are using a copy of ur_control.launch.py, running the ur_ros2_control node and the scaled_joint_trajectory_controller. These are the settings we have:

update_rate.yaml

controller_manager:
  ros__parameters:
    update_rate: 500  # Hz

ros2_control_configuration.yaml

scaled_joint_trajectory_controller:
  ros__parameters:
    joints:
      - ur_shoulder_pan_joint
      - ur_shoulder_lift_joint
      - ur_elbow_joint
      - ur_wrist_1_joint
      - ur_wrist_2_joint
      - ur_wrist_3_joint
    command_interfaces:
      - position
    state_interfaces:
      - position
      - velocity
    state_publish_rate: 200.0
    action_monitor_rate: 100.0
    allow_partial_joints_goal: false
    constraints:
      stopped_velocity_tolerance: 0.2
      goal_time: 0.0
      ur_shoulder_pan_joint: { trajectory: 0.05, goal: 0.03 }
      ur_shoulder_lift_joint: { trajectory: 0.05, goal: 0.03 }
      ur_elbow_joint: { trajectory: 0.05, goal: 0.03 }
      ur_wrist_1_joint: { trajectory: 0.05, goal: 0.03 }
      ur_wrist_2_joint: { trajectory: 0.05, goal: 0.03 }
      ur_wrist_3_joint: { trajectory: 0.05, goal: 0.03 }
    speed_scaling_interface_name: ur_speed_scaling/speed_scaling_factor

Expected Behavior

The robot should follow accurately the planned trajectory

Relevant log output

Accept Public visibility

• I agree to make this context public

[leander2189]

Probably related to this behaviour, the robot is not even following the commanded trajectory:

Untitled.Project.mp4

In the video, the robot has been stopped (through the E-Stop) in the middle of a motion, right before a collision. The planned motion is shown too. It can be seen that the actual position of the UR is not even close to any point of the sent trajectory.

Configuration is the same as in the initial post

[urfeex]

To comment on that I would need the trajectory that is sent to the robot. I know that this is a little hard to do on Humble, as actions aren't observable and the trajectory is coming from MoveIt.

You could try switching to the passthrough trajectory controller to further debug this. For this, modify the moveit controllers file to contain it:

# MoveIt uses this configuration for controller management
moveit_controller_manager: moveit_simple_controller_manager/MoveItSimpleControllerManager

trajectory_execution:
  allowed_execution_duration_scaling: 1.2
  allowed_goal_duration_margin: 0.5
  allowed_start_tolerance: 0.01
  execution_duration_monitoring: false # May lead to unexpectedly aborted goals with scaled JTC

moveit_simple_controller_manager:
  controller_names:
    - scaled_joint_trajectory_controller
    - joint_trajectory_controller
    - passthrough_trajectory_controller

  scaled_joint_trajectory_controller:
    action_ns: follow_joint_trajectory
    type: FollowJointTrajectory
    default: false
    joints:
      - shoulder_pan_joint
      - shoulder_lift_joint
      - elbow_joint
      - wrist_1_joint
      - wrist_2_joint
      - wrist_3_joint


  joint_trajectory_controller:
    action_ns: follow_joint_trajectory
    type: FollowJointTrajectory
    default: false
    joints:
      - shoulder_pan_joint
      - shoulder_lift_joint
      - elbow_joint
      - wrist_1_joint
      - wrist_2_joint
      - wrist_3_joint

  passthrough_trajectory_controller:
    action_ns: follow_joint_trajectory
    type: FollowJointTrajectory
    default: true
    joints:
      - shoulder_pan_joint
      - shoulder_lift_joint
      - elbow_joint
      - wrist_1_joint
      - wrist_2_joint
      - wrist_3_joint

and start the driver with the initial_joint_controller:=passthrough_trajectory_controller command.

I would expect the same behavior as with the scaled JTC, but you can observe the setpoints for the trajectory in the robot's log. Could you then download the support file from the robot and post the log_history.txt from that?

[leander2189]

I haven't been able to get the trajectory data and robot logs, but I think I know when it's happening:

Turns out that if the Tool Speed set in the Robot safety is lower that the settings in MoveIt (which by the way can be only defined as Joint speed), it's when we see this issue.

[urfeex]

Hm, from my understanding that should result in a trajectory slowdown, but not a deviation or even an overshoot. That is exactly why we have added speed scaling to the JTC.

You could also record the controller's state topic by

ros2 topic echo /scaled_joint_trajectory_controller/controller_state  > controller_state.txt

or you record a rosbag with that topic and preferably /speed_scaling_state_broadcaster/speed_scaling

[GinesLopezz]

We were monitoring the /scaled_joint_trajectory_controller/controller_state topic, and noticed that at a certain point in the trajectory, the msg.reference values jump directly to the final goal positions instead of continuing the smooth interpolation.
As shown in the attached image, all joints reference positions (red lines) suddenly move to the goal pose, while the feedback positions (blue lines) lag and then rush to catch up. At this point, the robot cannot follow the trajectory anymore and simply moves all joints to the final configuration:

Is this due to some short of timeout?
We had try to set:
First config of: ros2_control_configuration.yaml:

scaled_joint_trajectory_controller:
  ros__parameters:
    joints:
      - ur_shoulder_pan_joint
      - ur_shoulder_lift_joint
      - ur_elbow_joint
      - ur_wrist_1_joint
      - ur_wrist_2_joint
      - ur_wrist_3_joint
    command_interfaces:
      - position
    state_interfaces:
      - position
      - velocity
    state_publish_rate: 100.0
    action_monitor_rate: 20.0
    allow_partial_joints_goal: false
    constraints:
      stopped_velocity_tolerance: 0.2
      goal_time: 0.0
      ur_shoulder_pan_joint: { trajectory: 0.2, goal: 0.1 }
      ur_shoulder_lift_joint: { trajectory: 0.2, goal: 0.1 }
      ur_elbow_joint: { trajectory: 0.2, goal: 0.1 }
      ur_wrist_1_joint: { trajectory: 0.2, goal: 0.1 }
      ur_wrist_2_joint: { trajectory: 0.2, goal: 0.1 }
      ur_wrist_3_joint: { trajectory: 0.2, goal: 0.1 }
    speed_scaling_interface_name: ur_speed_scaling/speed_scaling_factor

Second config of ros2_control_configuration.yaml, updating:

goal_time: 30.0
goal_time_tolerance: 30.0

We also have these options setted in the MoveGroup configuration:

trajectory_execution = {
        "allow_trajectory_execution": True,
        "moveit_manage_controllers": True,
        "trajectory_execution.allowed_execution_duration_scaling": 1.0,
        "trajectory_execution.allowed_goal_duration_margin": 10.0,
        "trajectory_execution.allowed_start_tolerance": 0.03,
        "trajectory_execution.trajectory_duration_monitoring": False,
        "trajectory_execution.execution_duration_monitoring": False
    }

And nothing seems to fix the issue.

[leander2189]

We keep debugging this.

The cause of the error is setting a slow TCP Speed in the UR Safety configuration (we set it to 250mm/s). With this configuration, MoveIt is creating trajectories that are faster than this speed, so the robot can't follow and at some point a timeout is thrown and the behaviour that my colleague showed appears.

Setting a TCP speed much higher we don't find this issue, even if we change the % of feedrate speed

[urfeex]

Thank you for your continued feedback. I can reproduce this with a slow TCP speed safety setting. I'll need to look into what's happening there.

However, in my case the external_control's safety mechanism kicks in and stops the robot, creating a popup saying that the commanded velocity was too high (resulting from the growing error). Is your software (particularly the ur_client_library) up-to-date?

[urfeex]

May I though suggest that as a workaround you can use the passthrough_trajectory_controller. I couldn't reproduce the issue with that. It uses the same trajectory interpolation method as the scaled JTC, so MoveIt's collision checks do apply.