Segfaults when doing thousands of RRTconnect calls

[ompl]

Segfaults when doing thousands of RRTconnect calls

[mamoll]

Original comment by Ioan Sucan (Bitbucket: isucan, GitHub: isucan).

---

The planner you are actually using is LBKPIECE. The parameter you specify for changing the planner in MoveIt should be a planner configuration defined in ompl_planning.yaml; The idea is that you could potentially have multiple (different) configurations for the same OMPL planner in MoveIt.

When a configuration that does not exist is specified, defaults are used, and LBKPIECE is run. The fact this crashes is indeed a problem. What architecture are you running on? Which version of OMPL? (name of deb: dpkg -l | grep ros-groovy-ompl).

To get RRTConnect, a configuration that exists by default is:
RRTConnectkConfigDefault

I will close this issue now, but please reply with more crash info, as we need a new issue for the LBKPIECE crash.

[mamoll]

Original comment by Peter Schüller (Bitbucket: peterschueller, GitHub: peterschueller).

---

The thing is that I am sure that for some of my motion plans - all of them are initialized in the same way - the correct RRTConnect planner is used. It seems that only in rare occasions the parameter server information is not correctly retrieved, then "Could not find the planner configuration" message appears, and then only in rare cases the LBKPIECE segfault happens.

Is it possible to detect whether LBKPIECE or RRTConnect was selected? The "Could not find the planner configuration" message does not return with an error code or throw an exception, at least I could not find such a thing. Is there an internal error flag that is set that I can check?

My ompl_planning.yaml is as follows:

#!yaml

base:
  planner_configs:
    - PRM
    - RRT
    - RRTconnect
    - RRTstar
  longest_valid_segment_fraction: 0.1
  projection_evaluator: joints(world_joint)

planner_configs:
  PRM:
    type: geometric::PRM
    range: 10
  RRT:
    type: geometric::RRT
    range: 10
  RRTconnect:
    type: geometric::RRTConnect
    range: 10
  RRTstar:
    type: geometric::RRTstar
    range: 10

I use RRTconnect with

• planning time 0.5 and 3 attempts
• planning time 1.0 and 3 attempts
• planning time 1.5 and 9 attempts

Previously I tried RRTstar but it crashed in 90% of my instances, similar with PRM. RRT did not crash so far but it often does not find solutions ... :(

$ uname -a

Linux turing 3.0.0-26-generic #42-Ubuntu SMP Wed Sep 5 08:37:08 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

$ dpkg -l |grep groovy-ompl
ii ros-groovy-ompl 0.12.2002388-0oneiric-20130531-1348-+0000 OMPL is a free sampling-based motion planning library.

I built moveit from git because I needed to activate debugging. These runs are done without debugging though. Could this version of moveit be an issue? My clone of moveit_planners is at 86326a06c72 (one changeset after 0.4.0)

[mamoll]

Original comment by Peter Schüller (Bitbucket: peterschueller, GitHub: peterschueller).

---

Another (moveit) question that could help me find a solution: is it possible to use OMPLInterface without rosparam?

[mamoll]

Original comment by Peter Schüller (Bitbucket: peterschueller, GitHub: peterschueller).

---

I found a possible reason for the problem: netstat shows many lines like

tcp 0 0 127.0.0.1:11311 127.0.0.1:50611 TIME_WAIT

I think this is the ros master port and the reason are rosparam XMLRPC requests. There are so many that at some points the ports run out. I think to make this work I need to aggressively decrease the TCP timeout or make OMPL/MoveIt run without needing roscore.

[mamoll]

Original comment by Ioan Sucan (Bitbucket: isucan, GitHub: isucan).

---

We should probably move the discussion to the moveit mailing list. I will reply there:
https://groups.google.com/forum/?hl=en#!topic/moveit-users/CuPWSCCt0DM