scaled_joint_trajectory_controller not working as expected with simulation time enabled
Affected ROS2 Driver version(s)
2.5.2-9-g408318b
Used ROS distribution.
Humble
Which combination of platform is the ROS driver running on.
Ubuntu Linux with standard kernel, Ubuntu Linux with realtime patch
How is the UR ROS2 Driver installed.
Build both the ROS driver and UR Client Library from source
Which robot platform is the driver connected to.
URSim in docker
Robot SW / URSim version(s)
5.14.3
How is the ROS driver used.
Through the robot teach pendant using External Control URCap
Issue details
Summary
My packages last update was in August 2024, and after updating UR packages to the current version in March 2025, the scaled_joint_trajectory_controller no longer functions correctly when use_sim_time is enabled.
Issue Details
Upon sending a trajectory to the scaled_joint_trajectory_controller, the robot disregards the specified path and moves directly to the final goal. Investigation revealed that this behavior is associated with the use_sim_time parameter. In the ur_moveit.launch.py file, the configuration disables the scaled_joint_trajectory_controller and enables the joint_trajectory_controller when change_controllers is set to "true". I would like to have a fix to always use the scaled_joint_trajectory_controller, even using sim time.
Steps to Reproduce
- Set
use_sim_timetotrue. - If using ur_moveit.launch.py edit line 181 to not changing controller to joint_trajectory_controller.
- Send a trajectory to the scaled_joint_trajectory_controller.
Expected Behavior
The robot should accurately follow the specified trajectory, even with use_sim_time enabled.
Actual Behavior
With use_sim_time enabled, the robot ignores the specified trajectory and moves directly to the final goal.
Workaround Suggestion
Currently, I have not identified an effective workaround for this issue.
Relevant log output
Accept Public visibility
- [x] I agree to make this context public
Where exactly did you specify use_sim_time to true? In the driver launch file or the moveit launch file?
Where exactly did you specify
use_sim_timetotrue? In the driver launch file or the moveit launch file?
In all the launch files.
So, what exactly did you run? Which launchfiles with which arguments? Are you using URSim? In that case use_sim_time doesn't seem appropriate.
Edit: I see that the help text is somewhat misleading
Make MoveIt to use simulation time. This is needed for the trajectory planing in simulation.
A more appropriate one would be
Make MoveIt to use simulation time. Set this if you are using a simulator that is providing it's own simulated time on a '/clock' topic such as Gazebo.
It was working for you before, as we didn't propagate this correctly to the MoveIt nodes earlier. See https://github.com/UniversalRobots/Universal_Robots_ROS2_GZ_Simulation/issues/57 and https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver/pull/1146.
In that case
use_sim_timedoesn't seem appropriate.
Why did you say that use_sim_time is not appropiate if we are running everythin in simulation using URSim and Gazebo?
We are using our own launch_files, which are based on ur_control.launch.py and ur_moveit.launch.py. Apart from that we are launching more nodes, including URSim (to simulate robot behavior) and Gazebo to simulate cameras, and in all the nodes of our simulation we are using sim_time.
But now to have the scaled_joint_trajectory_controller working we must set use_sim_time to False in ur_ros2_control_node, what derivates in the next error in other part of our code, as everything else uses sim time:
ExtrapolationException: Lookup would require extrapolation into the past. Requested time 337.020000 but the earliest data is at time 1742821856.767501, when looking up transform from frame [ee_cam_left_optical_frame] to frame [work_object]
You did not mention Gazebo before. use_sim_time only makes sense if there is a /clock provider available, that's why I said that URSim is not to be combined with use_sim_time.
So, you are basically combining Gazebo and URSim? That's at least interesting :-)
Could you please provide a minimal working example to reproduce the issues that you have?
- Launchfile to
- Launch the driver using sim_time
- Launch a clock source, probably through gz
- A way to trigger the issue. I assume that calling the
example_move.pyscript might be enough? Or would the default movit launchfile with using the scaled JTC be enough?