rqt_joint_trajectory_controller leads to erratic joint movement

[Martin-Oehler]

Describe the bug
Sending commands to a trajectory controller with position command interface through the rqt_joint_trajectory_controller leads to erratic joint movements. This happens in simulation as well as on the real hardware. Upon further investigation, the rqt tool sends the configured joint position as a trajectory with time_from_start: 1.0 repeatedly with 10 Hz. E.g.:

header:
  stamp:
    sec: 0
    nanosec: 0
  frame_id: ''
joint_names:
- joint_1
points:
- positions:
  - 1.0
  velocities: []
  accelerations: []
  effort: []
  time_from_start:
    sec: 1
    nanosec: 0

I suspect that the fixed time_from_start value with the same goal state leads to a slightly different interpolated trajectory each time because the joint has already moved a bit. This might lead to jumps in the goal position.

Indeed, this hypothesis can be verified by manually sending a trajectory:

Sending just one trajectory message leads to a smooth trajectory as expected:

ros2 topic pub /trajectory_controller/joint_trajectory trajectory_msgs/msg/JointTrajectory "header:
  stamp:
    sec: 0
    nanosec: 0
  frame_id: ''
joint_names: ["joint_1"]
points: [{positions: [1.0], time_from_start: {sec: 3}}]" -1

but if the same message is sent with 10 Hz -r 10, an erratic behavior can be observed.

I have not tested any other command interfaces.

To Reproduce
Steps to reproduce the behavior:

1. Start a joint trajectory controller with position command interface
2. Start rqt_joint_trajectory_controller
3. Move any joint
4. The joint with show erratic behavior

Expected behavior
The joint should move smoothly

Screenshots
This graph shows that the generated reference trajectory (blue line) already contains the jitter:

Environment (please complete the following information):

• OS: Ubuntu 24.04
• Version Jazzy 4.21.0-1noble.20250304.234108

[christophfroehlich]

1s is the minimum duration

ros2_controllers/rqt_joint_trajectory_controller/rqt_joint_trajectory_controller/joint_trajectory_controller.py

Line 96 in 9063d8f

_min_traj_dur = 5.0 / _cmd_pub_freq # Minimum trajectory duration

for speed scaling of 50%

ros2_controllers/rqt_joint_trajectory_controller/rqt_joint_trajectory_controller/joint_trajectory_controller.py

Line 437 in 9063d8f

dur.append(max(abs(cmd - pos) / max_vel, self._min_traj_dur))

ros2_controllers/rqt_joint_trajectory_controller/rqt_joint_trajectory_controller/joint_trajectory_controller.py

Line 439 in 9063d8f

duration = rclpy.duration.Duration(seconds=(max(dur) / self._speed_scale))

when your joint is faster, then the current position is not taken into account here.

I think the interpolation should be monotonic in this case, as only position is sent and only linear interpolation takes place (see https://control.ros.org/rolling/doc/ros2_controllers/joint_trajectory_controller/doc/trajectory.html). You could try to

• set the interpolation method to "none" and see if this changes your behavior.
• change the _min_traj_dur constant.

[Martin-Oehler]

Setting the interpolation method to "none" makes the arm not move at all. I suspect, this happens because without interpolation, the next waypoint is only sent when it is due. Because the same command is repeated with 10 Hz, the waypoint is always moved to the future in 1s, and therefore never being reached.

Unfortunately, I am not able to test changing _min_traj_dur at this time.

[github-actions]

This issue is being labeled as stale because it has been open 45 days with no activity. It will be automatically closed after another 45 days without follow-ups.

[github-actions]

This issue was closed because it has been stalled for 45 days with no activity.