0
$\begingroup$

Rosanswers logo

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 ?


Originally posted by Jarek Potiuk on ROS Answers with karma: 31 on 2017-11-28

Post score: 3


Original comments

Comment by gvdhoorn on 2017-11-29:
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.

Comment by Jarek Potiuk on 2017-12-03:
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.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

If you run kinetic, checkout https://github.com/ThomasTimm/ur_modern_driver/pull/120. 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.


Originally posted by v4hn with karma: 2950 on 2017-12-03

This answer was ACCEPTED on the original site

Post score: 4


Original comments

Comment by Jarek Potiuk on 2017-12-03:
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.

Comment by Jarek Potiuk on 2017-12-05:
@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.

Comment by Jarek Potiuk on 2017-12-05:
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

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.