UR10e movement from MoveIt is not smooth

A partner of us is using a new UR10e robot. They use ur_modern_driver (kinetic-devel) to use the robot with ROS. When they use the RViz plugin to plan a trajectory using MoveIt, the resulting trajectory looks ok in the visualisation. However, when the robot executes the trajectory, it stops at every waypoint. There are 10 waypoints in a plan, so the movement looks clumsy. Moreover, they had to decrease the velocity and acceleration scaling. Otherwise, the movement resulted in the robot to go in safety stop.

The log files show that a list of movej commands is sent to the robot. It looks like the t and/or r parameters are not correct for the robot (r is 0 and t is probably to high). We don't have much experience with this robot. Do we have to tune these parameters to get a smooth trajectory? Is is possible to do this using the RViz plugin? Are there default settings for a UR10e? Should we create the trajectory in a different way?

edit retag close merge delete

The e-series are officially not supported yet by ur_modern_driver. That is partly why Universal Robots started the development of a new driver.

If you post your issue on the issue tracker of ur_modern_driver, it may be that some of the other users that try to use it with e-series robots could help.

( 2019-04-04 04:57:27 -0600 )edit

Just to clarify: in the meantime ur_robot_driver has been released, and it fully supports e-Series robots (as well as CB3 non-e-Series robots).

ur_modern_driver should not be used any more with these robots.

( 2020-03-04 02:34:56 -0600 )edit

Sort by » oldest newest most voted

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.

more