ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A answers.ros.org
 Ask Your Question

# MoveIt Commander not able to find a motion plan [closed]

Hello all,

I'm trying to program a UR5 robot arm using ROS.

I'm happy to see there's a lot of development going on, and many packages are already available, such as the universal_robot package, moveit, rviz and many other ROS packages. However, as a new user, it's difficult to see the relations/dependencies between all those packages, and how certain configuration choices (e.g. a specific branch or version of a module, a configuration parameter, etc.) affect the abilities of the robot.

Specifically, I'm trying to program some (simple) moves of the robot arm in an environment with a small number of collision objects to avoid. Sometimes the motion planner finds a solution, sometimes it doesn't. When calling group.plan() repeatedly, it might find a solution after a number of attempts, but sometimes it really doesn't seem to be able to find a motion plan.

I can think of the following "choices" that may or may not affect the planning performance:

• Different versions of the universal_robots package.
• Using KDLKinematicsPlugin vs. UR5KinematicsPlugin.
• Use of the parameter limited:=true vs. limited:=false for ur_driver (is this different when using UR5KinematicsPlugin?).
• Use of the parameter limited:=true vs. limited:=false for moveit.
• Start position of the robot arm (e.g. one of the joint states possibly outside the allowed range in case limited:=true, or maybe just a more "difficult" pose to move from?).

Any information about how these choices affect the motion planner will be very helpful.

I think the most important questions for me at this moment are:

• Should I use the KDLKinematicsPlugin or the UR5KinematicsPlugin?
• Should I use the limited:=true parameter for the ur_driver? And for moveit?
• What should I expect from the current state of the motion planner (in combination with the universal_robot package). Should it be able to always find a solution for "reasonably easy" paths? What are the experiences of other users?

Thanks in advance for your answers!

EDIT: Just to clarify, the reason I asked about "different versions of the universal_driver package", the kinematics plugins and the limit parameters, is that I noticed that between versions 1.0.3 and 1.0.4 of the universal_driver package the kinematics plugin has changed from KDL to UR5. Initially I could not get the motion planning to work at all after this update, but when I removed the limit parameter it worked again (at least sometimes). My guess is that the behaviour of the UR5KinematicsPlugin with respect to the limit parameter is different than that of the KDLKinematicsPlugin. Maybe because the UR5 plugin is specifically targeted for the UR5 and thus always works with the full range?!

But if I remove the limit parameter, moveit apparently has troubles finding trajectories. So how should I get these to work together?

edit retag reopen merge delete

## 2 Answers

Sort by » oldest newest most voted

Apparently there were some issues with the universal_robot package. UR5KinematicsPlugin only works with unlimited joint range, while MoveIt! only works correctly with limited joint ranges, so these modules currently cannot be used at the same time. Furthermore there were some issues with the collision models of the Universal Robots.

See the issues #121, #122 and #127 on GitHub for more information.

The issues are solved with pull requests #128 (for hydro) or #130 (for indigo).

more

I'll touch on just a few things for which I think I am in a position to actually give you something solid. The rest I'll leave to more knowledgeable people.

[..] Sometimes the motion planner finds a solution, sometimes it doesn't. When calling group.plan() repeatedly, it might find a solution after a number of attempts, but sometimes it really doesn't seem to be able to find a motion plan.

If you're using the default planner for MoveIt -- OMPL -- you're working with a sampling-based planner. This can sometimes put you in a situation where it finds a plan, and sometimes it doesn't, or only after a few tries. See MoveIt/Motion_Planning/Overview for more information.

• Different versions of the universal_robots package

This is a bit vague (source vs deb? different ROS distributions? v1.0.2 vs v1.0.3?), but in general the actual motion part of the driver hasn't changed that much since it was released in Fuerte. Only recently has there been a significant change, but even that was only on the sensor side (see PR117). The initial version of the IO interface seemed to cause high CPU utilisation which the UR controller didn't like. It is possible this could influence motion performance, but that is far from certain.

• Using KDLKinematicsPlugin vs. UR5KinematicsPlugin

OpenRave IKFast plugins are blazingly fast (order of microseconds). This specific plugin was written by hand, so I don't know the actual performance figures for it. KDL based ones tend to be slower.

• Use of the parameter limit:=true vs. limit:=false for ur_driver (is this different when using UR5KinematicsPlugin?).
• Use of the parameter limit:=true vs. limit:=false for moveit.

As far as I know, these eventually actually resolve to the same thing. In short: MoveIt seems to have difficulty coming up with proper trajectories for joints that have limits larger than [-pi, pi] (such as the UR5/10). The limited argument just loads a different urdf where the limits have been set to [-pi, pi] for all joints.

As to a difference in planning time and / or whether this influences / is influenced by using UR5KinematicsPlugin I'll leave for others, as I don't have that much experience with it.

• Start position of the robot arm (e.g. one of the joint states possibly outside the allowed range in case limit:=true, or maybe just a more "difficult" pose to move from?).

I'll just say that if you start the limited version of the launchfiles, and your actual arm is outside [-pi, pi] for any joint, planning will always fail. MoveIt will immediately throw an error, as for all it knows the robot is outside its limits (see also universal_robot/issues/112).

more

## Comments

Thanks for your response. I've updated the question to clarify what I meant with "versions of the universal_driver package" and why I'm not sure about how to use the "limited" parameter.

( 2014-10-15 07:20:34 -0600 )edit

You might also want to send a message to the ROS-Industrial mailinglist. The authors and maintainers of the universal_robot repository are frequent posters there.

( 2014-10-15 07:26:10 -0600 )edit

## Stats

Asked: 2014-10-14 08:30:12 -0600

Seen: 1,831 times

Last updated: Oct 23 '14