Revision history [back]

In your case, as @gvdhoorn noted, you have a compatibility problem between your robot and driver. If the problem persists after you update to the new driver, there are other reasons for jerky motions in ROS/MoveIt.

The most common one is network or CPU load spikes. When you are controlling a robot with ROS, most controller implementations send joint commands to the robot at high frequency through the ROS network. If the network experiences a sudden heavy load, or your PC runs a costly process while moving the robot, the next step in the trajectory may be sent with a significant delay, and the robot may stop for a short time, and then suddenly move quickly to catch up with where it is supposed to be according to the trajectory.

The easiest ways to work around this are, from my experience:

1. Reduce the amount of sensor data that is streaming on the network (e.g. reduce camera frame rates, turn them off or remove them when they are not needed)
2. Install a low-latency or realtime kernel on your machine to ensure that the motion control is prioritized.
3. If possible, perform simple motions that need to be fast directly on the robot controller, e.g. by sending PTP/LIN/CIRC commands directly to the robot controller. This is quite easy and effective on UR robots, since sending the scripts is easy. See here and here for an example.

ROS2 also gives more options to make network loads more reliable.

Related question.

In your case, as @gvdhoorn noted, you have a compatibility problem between your robot and driver. If the problem persists after you update to the new UR driver, there are other reasons for jerky motions in ROS/MoveIt.

The most common one is network or CPU load spikes. When you are controlling a robot with ROS, most controller implementations send joint commands to the robot at high frequency through the ROS network. If the network experiences a sudden heavy load, or your PC runs a costly process while moving the robot, the next step in the trajectory may be sent with a significant delay, and the robot may stop for a short time, and then suddenly move quickly to catch up with where it is supposed to be according to the trajectory.

The easiest ways to work around this are, from my experience:

1. Reduce the amount of sensor data that is streaming on the network (e.g. reduce camera frame rates, turn them off or remove them when they are not needed)
2. Install a low-latency or realtime kernel on your machine to ensure that the motion control is prioritized.
3. If possible, perform simple motions that need to be fast directly on the robot controller, e.g. by sending PTP/LIN/CIRC commands directly to the robot controller. This is quite easy and effective on UR robots, since sending the scripts is easy. See here and here for an example.

Other reasons might be your joint velocity/acceleration limits not being set up correctly for your robot, or insufficient resolution in the trajectory (e.g. eef_step too large when using compute_cartesian_path).

ROS2 also gives more options to make network loads more reliable.

Related question.