Goal accuracy and tolerances after path executing

[Michael Wojtynek]

Hello,

I’m currently working on a pick and place application with an UR5 robot. I’m using the ROS industrial driver to control the robot. For the path planning I’m using MoveIt! with the KDL kinematic plugin. From the OMPL I’m using planners like PRM, PRMstar, RRT and RRTstar. The path planning and execution works fine.

********
Work Process:
The goal position is defined and always the same. First I’m using a defined joint state position for starting the robot. Next I’m moving the robot to a pregrasp position by using cartesian path planning (computeCartesianPath function) and afterwards the robot moves to the grasp position (also by Cartesian path planning).

********
Problem:
My problem is the goal accuracy. Sometimes I reach the goal very accurate. Next time, the gripper is 2 mm besides the goal. After next the gripper is maybe 3 mm besides the goal in some other direction. So, the error is not reproducible.
Approach to the problem until now:
- Rasing the goal and position tolerance of the move group interface (setGoalPositionTolerance function) but it didn’t work out
- Next attempt will be rasing the kinematics_solver_search_resolution to get a higher resolution?

********
Does someone have some other solutions or approaches for an accurate pick and place application?

Greetings,
Michael

[G.A. vd. Hoorn - 3ME]

Your post reminds me of this [1] thread on the ROS-Industrial mailing
list. See [2] for my answer then.

In short: the driver itself has goal tolerances that it uses while
executing the trajectory and it may be that those are too permissive for
your application.


Gijs

[1]
https://groups.google.com/d/msg/swri-ros-pkg-dev/2Mb4CO8anCI/uzOYiinjWuoJ
[2]
https://groups.google.com/d/msg/swri-ros-pkg-dev/2Mb4CO8anCI/u4TPwbizmgAJ

[Michael Wojtynek]

Seems you are right with your remembrance. Last time you solved this problem by lowering the preconfigured tolerances inside the driver. Right now I’m not sure where the tolerances are defined. I guess in [1] are the joint angle tolerances in radians and in [2] the position tolerances in meters defined?
Do I have to adjust the tolerances in MoveIt! according to the driver tolerance?

[1] https://github.com/ros-industrial/universal_robot/blob/hydro-devel/ur_driver/src/ur_driver/driver.py#L662

[2] https://github.com/ros-industrial/universal_robot/blob/hydro-devel/ur_driver/src/ur_driver/driver.py#L832-833

[G.A. vd. Hoorn - 3ME]

On 5-3-2015 14:51, Michael Wojtynek wrote:
>
> Seems you are right with your remembrance. Last time you solved this problem by lowering the preconfigured tolerances inside the driver. Right now I’m not sure where the tolerances are defined. I guess in [1] are the joint angle tolerances in radians and in [2] the position tolerances in meters defined?

The driver adheres to ROS standards, so all angles are in radians,
velocities in rad/s and distances in meters.

> Do I have to adjust the tolerances in MoveIt! according to the driver tolerance?

if tol(moveit) > tol(driver): not a problem.

if tol(driver) > tol(moveit): then driver can probably never (or only
incidently) reach goal position.

I think the second is the situation you have now.


Personally, I would submit an enhancement request for those tolerances
in the driver to be configurable using ROS parameters from a launch
file. Just report it as an issue on the tracker [3] (and link back to
this thread).


Gijs

PS: you linked to files in hydro-devel. The indigo-devel branch is the
default one now.

> [1] https://github.com/ros-industrial/universal_robot/blob/hydro-devel/ur_driver/src/ur_driver/driver.py#L662
>
> [2] https://github.com/ros-industrial/universal_robot/blob/hydro-devel/ur_driver/src/ur_driver/driver.py#L832-833

[3] https://github.com/ros-industrial/universal_robot/issues