ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

Goal tolerance and trajectory repeteability with MoveIt on real robots

asked 2021-07-21 12:22:58 -0500

IgnacioUD gravatar image

updated 2021-07-21 13:00:30 -0500

While planning pose target goals and testing the repeteability of the trajectory (Planning and executing trajectories with the same pose goal) its very common to get different plans and trajectories. As far as I've tested for the same goal usually gets up to 3-5 different trajectories. So my first question is:

¿Is it possible to get always the same behaviour when planning pose goals (Without saving the trajectories, planning them at runtime)?

The next question has also some relation with the first one. When executing plans obtained from pose goals in simulation everything works as expected. On the other hand, when executing them in real robots the goal tolerance its much higher. Experimenting with the real robots I usually get up to 5 different trajectories when planning and executing poses, as I described earlier. Some of the trajectories get fine to the goal itself with unappreciable errors, but for some reason other trajectories diverge up to 2mm from the goal and always behave this way (For instance, each trajectory always get to the same goal, some of them have no error but others always differs the same amount from the goal). I've tried to tighen MoveIt tolerances, wich seems to have no effect at all. After some research I've found some older posts https://groups.google.com/g/moveit-us... wich seem to have the same problem and relate it to the robots drivers. I've also tried to lower the tolerances in the driver unsuccesfully.

¿Has someone manage to solve this situation (I dont know if its a specific UR problem or affects all robots)?

I'm working with a UR3e with the ur_robot_driver

Planning the trajectories with RTTConnect

ROS noetic on Ubuntu 20.04

edit retag flag offensive close merge delete

Comments

Quick comment: please try to avoid including more than a single question in a post. ROS Answers is not a forum, it's a Q&A site, similar to Stack Overflow.

Those work best with a 1-to-1 ratio of questions-to-answers.

Your "related question" has almost 0 visibility, and it's difficult to answer them both properly in a single answer.

gvdhoorn gravatar image gvdhoorn  ( 2021-07-23 09:52:38 -0500 )edit

Thanks for your comment I'll take it into account for the next time, in this particular case as both questions have a close relation I thought that it could work. Anyways, the main question is the second one, about the tolerance matter. In the link shared I saw that you participated back then, ¿Did you manage to solve the situation in the end?

IgnacioUD gravatar image IgnacioUD  ( 2021-07-23 15:01:18 -0500 )edit

1 Answer

Sort by » oldest newest most voted
0

answered 2021-07-25 11:56:35 -0500

fergs gravatar image

On the first question, no, with the default planners there really is no way to get the exact same trajectory every time you run things (especially on a real robot). This is mainly due to two things:

  • MoveIt primarily uses OMPL. The planners in OMPL are sampling-based, thus you are almost guaranteed to get different samples for every plan even if the start and end pose are the same. If you want highly repeatable trajectories you really need to use something like SBPL - but I don't think there is a maintained version of arm planning with SBPL these days (it can be quite a bit slower, so mostly people stick with the unpredictability of OMPL).
  • On real hardware, your "start" is never actually the same. Even if the arm looks to be in the same position to you as a human, that position is represented by a floating point value and there is going to be small differences in the floating point positions.

As for the second question, yes, this is almost certainly due to the robot drivers. MoveIt just makes the trajectory, how well you follow the trajectory is up to the drivers and hardware. Depending on the tuning of the drivers/hardware, different trajectories will likely end up with different accuracy in getting to the goal.

A final thought is: how are you determining that the trajectory is off by 2mm?

  • Are you using TF tools to measure how far off the robot thinks it is? If so, then this sounds like either the drivers/hardware has some tolerance set higher than you like.
  • Are you measuring that difference in the real world? This is likely more a factor of "global accuracy" - while most industrial robot arms specify very tight repeatability they often have much wider tolerances for global accuracy. Since most industrial robot arms are programmed by moving the robot to a specific location and then recalling that location, repeatability is what matters to them (if you put the arm joints at the same value, the end effector ends up at the same place every time). Global accuracy is quite a bit harder (small errors in the kinematic model due to part tolerances and stackup cause relatively large errors in the global accuracy).
edit flag offensive delete link more

Comments

Thanks for your answer. The difference was measured globally, but I misspeled the error, it's about 2 cm not 2 mm. After some research about the second topic and tests, I've found more people with the same issue, so I decided to open a issue in the ur driver repository with all the details. issue

IgnacioUD gravatar image IgnacioUD  ( 2021-08-24 13:23:08 -0500 )edit

Question Tools

2 followers

Stats

Asked: 2021-07-21 12:22:58 -0500

Seen: 593 times

Last updated: Jul 25 '21