Jerky movements of UR10 robot with ur_modern_driver and MoveIt

asked 2017-11-28 16:55:31 -0600

Jarek Potiuk
31 ●1 ●3 ●4

We have a problem with sometimes jerky moves of UR10 (and UR3 before).

We are controlling our UR10 robot via MoveIt + ur_modern_driver combination. All works generally well, trajectories are planned and moves are smoothly executed. We have however problem that quite often the move has some "jerky" slow-downs/pauses. Robot slows down for a brief moment and then catches up - the moves are then not smooth. It does not happen continuously - generally move is smooth, but with longer moves it can happen once/twice during path execution.

It seems that the modern driver uses 125Hz interface and generates quite a lot of traffic, which we suspect might be the cause. Seems that jerkyness increses if we run some CPU-intensive/rostopic intensive ROS nodes (like gazebo). We are running the whole ROS environment in a docker container with --network=host and --privileged on fairly fast 8 core machine with plenty of RAM. We had similar problems with UR3 before.

We have not yet deeply investigated (we are going to) - but before we do, maybe someone had similar problems and know possible reasons ?

edit retag flag offensive close merge delete

Comments

Have you checked the ur_modern_driver/issue tracker?

It might be a known issue. The driver closes the loop with the robot controller over the network, so dropped/late pkts can cause what you are describing.

gvdhoorn ( 2017-11-29 04:06:55 -0600 )edit

Thanks! I spent some time reviewing the issues and the pull requests/discussions and have some things to explore (the comments from @v4hn below reflected my findings pretty accurately. This week we are going to test the refactored branch, TCP socket options mentioned there.

Jarek Potiuk ( 2017-12-03 13:48:16 -0600 )edit

add a comment

answered 2017-12-03 10:10:12 -0600

v4hn
2950 ●18 ●53 ●57

If you run kinetic, checkout https://github.com/ThomasTimm/ur_mode... . This work will probably replace the previous branch in kinetic+ and has some adjustments also w.r.t. latency. Additionally make sure you run a low-latency linux kernel on your machine to avoid random delays.

The driver sends target poses to the controller with 4*125 Hz, but the controller performs an emergency stop (do_brake) if it doesn't receive a target in even a single cycle of the 125Hz update loop. With generic kernel and lots of activity on the machine that is very much possible though and we saw similar behavior in our lab too.

It's gone since we changed the kernel and use the new branch.

Comments

Thanks @v4hn! I've been reading through the code this weekend (5 hours by train today ;) ) and all the issues/ pull requests and came to same conclusions! The "do_brake" comment however was something I have not realised, but it makes sense. I will test all of it and let you know if it helped.

Jarek Potiuk ( 2017-12-03 13:52:20 -0600 )edit

@v4hn - the refector by Simon Rasmussen is definitely an improvement. I tested it and on top of being way more readable and structured, it is also improving smoothness of moves. There are still some slow-downs during the move. I also tested the low-latency kernel but I see no improvements there.

Jarek Potiuk ( 2017-12-05 14:38:30 -0600 )edit

I am going to suggest some improvements and findings in the refactored modern driver github repo. After reviewing and understanding in detail how the driver works, we have some thoughts and proposals on some changes of the architecture that migh improve it, but i need to consult it with authors

Jarek Potiuk ( 2017-12-05 14:40:42 -0600 )edit

add a comment

Jerky movements of UR10 robot with ur_modern_driver and MoveIt

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Jerky movements of UR10 robot with ur_modern_driver and MoveIt edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Jerky movements of UR10 robot with ur_modern_driver and MoveIt