MoveIt! default planner often goes wild

[130s]

This might as well be reported to upstream (which I might do later) but I also want to raise attention among NXO users.

See the video https://www.youtube.com/watch?v=e4XMzfvK6II
Planned path sometimes goes off VERY wild and it looks almost uncontrollable.

Similar issue is seen with Baxter: https://www.youtube.com/watch?v=1q4W8LQlEwk&feature=youtu.be

Happens on both ROS Indigo and Hydro.

$ dpkg -p ros-indigo-nextage-moveit-config|grep Ver
Version: 0.6.2-0trusty-20150512-1515-+0000
$ dpkg -p ros-indigo-moveit-planners |grep Ver
Version: 0.6.7-0trusty-20150501-1901-+0000
$ dpkg -p ros-indigo-moveit-ros |grep Ver
Version: 0.6.5-0trusty-20150506-0745-+0000
$ dpkg -p ros-indigo-ompl |grep Ver
Version: 1.0.0003094-0trusty-20141029-0351-+0000

Workaround (tedious): Choose RRT-Connect on OMPL pane. Notice that every time you switch the MoveGroup, the planner gets reset so that you have to make sure you specify the planner.

We need better workaround, and a solution.

[DamienSalle]

Hi all,
In Tecnalia we have also found this issue painful for some time now.
We have for example decided Not to use MoveIt in our critical industrial applications until this is solved.

We are working on this at the moment.

ROS-Industrial have found the origin of this bug (moveit exits when the first solution is found, not trying to get other solutions even if Time or Attemps threshold has not been reached) and proposed a solution to solve this.
We are implementing their patch now, that require to recompile MoveIt from source and upgrade some components, including MoveIt_setup_assistant, and leading to the need to re-generate the moveIt configuration....

This is MoveIt dependant, not Robot dependant...
So I'm not sure if NextageOpen debs should provided recompiled moveit also, or if NXO ROS debians should provide both moveit configurations: with and without the additional parameters...

Link to ROS-I Status project: http://rosindustrial.org/ric-americas/ftp-status/
PPT explaining the issue and solution: http://rosindustrial.org/s/IDEXX_Planning_Presentation.pdf

[longjie]

Hi,
I also have noticed this behavior. As you mentioned, I guessed it was because of the planning algorithm, so I have dodged this by choosing RRT(star). Some algorithm like vanilla RRT have no optimality. Can we set the default algorithm as optimize algorithms such as RRT(star) or RRT connect? I don't know which algorithm is default, though.

[longjie]

Oh, @TecnaliaRobotics already mentioned the solution, thanks.

PPT explaining the issue and solution: http://rosindustrial.org/s/IDEXX_Planning_Presentation.pdf

[DamienSalle]

Hello all.
An update on the "solution" I provided earlier:
After a lot of tests with moveit planning packages, we found that:

• The bug related to taking the best solution from the x attempts was fixed since the version 0.5.5 of Moveit Planners
• The improvement in reloading the planning parameters from the server (each time we do .solve()) is related to the use of the new moveit_setup_assistant of Lewis (version 0.5.9). This version will add only parameters to the configuration file (config/ompl_planning.yaml) :

  planner_configs:
  SBLkConfigDefault:
  type: geometric::SBL
  range: 0.0 # Max motion added to tree. ==> maxDistance_ default: 0.0, if 0.0, set on setup() ......

In conclusion, to benefit from these improvements make sure that you have the new version of ros-hydro-moveit-planners (0.5.5 or more) and the config/ompl_planning.yaml file with the additional parameters. To generate this file, you can use the new moveit_setup_assistant or just copy paste these lines.

And we tested with our Kuka LWR, and there is indeed a great improvement.
Did not test with Nextage yet...

[130s]

@TecnaliaRobotics thanks for the valuable info.

The bug related to taking the best solution from the x attempts was fixed since the version 0.5.5 of Moveit Planners

Well, moveit_planners 0.5.5 looks like was released in 2014-03-22 (see changelog for ROS Hydro. Could you make sure if the version you mentioned is correct?

---

If someone wants to programmatically change the kinematic solver, here's a Python example (discussed here).

[130s]

If someone wants to programmatically change the kinematic solver, here's a Python example (discussed here).

More specifically, from this line and below.

[130s]

This issue is not solved but mitigated by #231.