CHOMP fails to plan

[captain-yoshi]

I cannot plan with CHOMP through MTC:

QH6248 qh_lib_check: Incorrect qhull library called.  Caller uses reentrant Qhull while library is non-reentrant
QH6249 qh_lib_check: Incorrect qhull library called.  Size of qhT for caller is 8768, but for library is 2896.
QH6255 qh_lib_check: Cannot continue.  Library 'qhull 7.2.0 (2015.2 2016/01/18)' uses a dynamic qhT via qh_QHpointer (e.g., qhull_p.so)

• I cannot get GDB bactraces...
• CHOMP works with the moveit benchmarking module.
• OMPL and STOMP planners works.
• Usin ROS Noetic with latest master branch from MTC and MoveIt.
• In the past I think CHOMP worked in melodic but cannot test it anymore.

This has something to do with QHULL library being compiled with reentrant vs non-reentrant https://github.com/qhull/qhull:

  The reentrant 'C' code (src/libqhull_r), passes a pointer to qhT 
  to most Qhull routines.  This allows multiple instances of Qhull to run 
  at the same time.  It simplifies the C++ interface.

  The non-reentrant 'C' code (src/libqhull) looks unusual.  It refers to 
  Qhull's global data structure, qhT, through a 'qh' macro (e.g., 'qh ferr'). 
  This allows the same code to use static memory or heap memory. 
  If qh_QHpointer is defined, qh_qh is a pointer to an allocated qhT; 
  otherwise qh_qh is a global static data structure of type qhT.

Sorry if this error is not bound to MTC (CHOMP does work with MoveIt through the benchmark package). Should I compile the QHULL library in reentrant mode? I think MTC uses multiple threads for each Connect stage that why it fails when using CHOMP.

[rhaschke]

MTC doesn't (yet) use threading. However, we migrated to qhull_r a while ago in moveit/geometric_shapes#149. So, please check, which library is actually used. Do you link any other lib using the non-reentrant version?

[captain-yoshi]

I have the latest geometric_shapes package (noetic-devel -> c69948a).

Do you link any other lib using the non-reentrant version?

Nope. Unless there is another package doing this by default.

EDIT: I use the 0.7.2 TAG but I see that there is a 2.0.0 TAG (maybe used for ROS2)

[captain-yoshi]

ldconfig -p | grep libqhull

libqhull_r.so.7 (libc6,x86-64) => /lib/x86_64-linux-gnu/libqhull_r.so.7
libqhull_r.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libqhull_r.so
libqhull.so.7 (libc6,x86-64) => /lib/x86_64-linux-gnu/libqhull.so.7
libqhull.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libqhull.so

I think the pcl_ros needs libqhull.so.

[v4hn]

ldconfig -p | grep libqhull ``` sh libqhull_r.so.7 (libc6,x86-64) => /lib/x86_64-linux-gnu/libqhull_r.so.7 libqhull_r.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libqhull_r.so libqhull.so.7 (libc6,x86-64) => /lib/x86_64-linux-gnu/libqhull.so.7 libqhull.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libqhull.so ```

That looks really bad and you will have to recompile either of the culprits, changing the interfaces to the other version! I believe PCL itself migrated to libqhull_r at some point as well. If this is actually an issue with standard ROS-released packages, please file a separate bugreport in geometric_shapes.

[captain-yoshi]

Yup! Found the same thing! When ignoring the PCL package it works. I did a complete reinstall of my OS to Ubuntu 20.04, 3 weeks ago, so it should have picked the PCL from the ros-noetic package automatically.

If this is actually an issue with standard ROS-released packages, please file a separate bugreport in geometric_shapes.

Will do more testing and will do if I can replicate it.

Thank you both for your help.

[captain-yoshi]

@v4hn When adding pcl_ros ROS-released packages:

sudo apt install ros-noetic-pcl-ros

The following NEW packages will be installed:
 libqhull-dev libqhull-r7 libqhull7

This command installs the following libraries on the system:

 libqhull_r.so.7 (libc6,x86-64) => /lib/x86_64-linux-gnu/libqhull_r.so.7
 libqhull_r.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libqhull_r.so
 libqhull.so.7 (libc6,x86-64) => /lib/x86_64-linux-gnu/libqhull.so.7
 libqhull.so (libc6,x86-64) => /lib/x86_64-linux-gnu/libqhull.so

So is this a bug in the release? Should it install only the libqhull-r7 package? I cannot reproduce my error now even with PCL reintegrated... maybe I got to clean my workspace but I don't want to loose 20 minutes for compiling!

If this is a bug should I still report it to the geometric_shapes or the pcl_ros?

[v4hn]

The problem is not that it installs these libraries - that might be fine, but it's probably a bug too - but linking them in the library you need for your node. If pcl_ros depends on both libraries, they should provide versions of their own libraries linking against one of them each. Otherwise their released library will be incompatible with geometric_shapes. There definitely should be no library in `pcl_ros` that links to both versions (not sure whether there is).

[rhaschke]

Both versions of libqhull are pulled in (correctly) via libqhull-dev, which is required by libpcl-dev, which in turn is required by ros-noetic-pcl-ros. The culprit is that libpcl_surface.so still uses the non-reentrant version of libqhull. @jspricke, could you please take a look at this? You originally introduced qhull_r in geometric_shapes...

[jspricke]

PCL did not move to qhull_r yet, there is a PR here: PointCloudLibrary/pcl#4540.

[v4hn]

So that leaves you with the option to either build PCL and pcl_ros locally with the patch or revert moveit/geometric_shapes#149 and build geometric_shapes (and MoveIt on top of it) locally. Beware we migrated geometric_shapes because of unresolved segfaults in geometric_shapes, so if you revert this you might find other difficult segfaults. Lastly, of course, you can outsource your perception code into a separate node to invoke via ROS interfaces. That way the different library requirements do not matter. Either way, this is no problem with MTC, so I will close it here.

[AndyZe]

It's interesting to note that the text "qhull" does not appear in moveit/stomp/stomp_ros repositories, so it's not clear to me where qhull is actually being called from. I stopped digging at that point.