ros-planning / geometric_shapes

Representation of geometric shapes

Geometric Shapes

This package contains generic definitions of geometric shapes and bodies, as well as tools for operating on shape messages. Shapes represent only the form of an object. Bodies are shapes at a particular pose. Routines such as point containment and ray intersections are provided.

Supported shapes:

• sphere
• box
• cone
• cylinder
• mesh

Note: Bodies for meshes compute the convex hull of those meshes in order to provide the point containment / ray intersection routines.

Note: shape_tools package was recently merged into this package

Note: bodies::Box::corner1_ was renamed to minCorner_ and bodies::Box::corner2_ to maxCorner_ in Noetic.

Note: bodies::ConvexMesh::MeshData was made implementation-private in Noetic and is no longer accessible from the .h file.

Build Status

GitHub Actions:

Devel Job:

Debian Job:

geometric_shapes's Issues

linking to assimp fails on mac 10.10

I am trying to compile ros on mac
When trying to building I get the following error:

[100%] Building CXX object CMakeFiles/geometric_shapes.dir/src/body_operations.cpp.o
Linking CXX shared library devel/lib/libgeometric_shapes.dylib
/usr/local/Cellar/cmake/3.0.2/bin/cmake -E cmake_link_script CMakeFiles/geometric_shapes.dir/link.txt --verbose=1
/usr/bin/c++  -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -dynamiclib -Wl,-headerpad_max_install_names   -o devel/lib/libgeometric_shapes.dylib -install_name /Users/xxx/ros_catkin_ws/build_isolated/geometric_shapes/devel/lib/libgeometric_shapes.dylib CMakeFiles/geometric_shapes.dir/src/shapes.cpp.o CMakeFiles/geometric_shapes.dir/src/shape_operations.cpp.o CMakeFiles/geometric_shapes.dir/src/mesh_operations.cpp.o CMakeFiles/geometric_shapes.dir/src/bodies.cpp.o CMakeFiles/geometric_shapes.dir/src/body_operations.cpp.o  -L/Users/xxx/ros_catkin_ws/install_isolated/lib -lassimp /usr/local/lib/libqhull.dylib /Users/xxx/ros_catkin_ws/install_isolated/lib/libroscpp_serialization.dylib /Users/xxx/ros_catkin_ws/install_isolated/lib/librostime.dylib /usr/local/lib/libboost_date_time-mt.dylib /Users/xxx/ros_catkin_ws/install_isolated/lib/libcpp_common.dylib /usr/local/lib/libboost_system-mt.dylib /usr/local/lib/libboost_thread-mt.dylib /usr/local/lib/libconsole_bridge.dylib /Users/xxx/ros_catkin_ws/install_isolated/lib/libresource_retriever.dylib /Users/xxx/ros_catkin_ws/install_isolated/lib/libshape_tools.dylib /Users/xxx/ros_catkin_ws/install_isolated/lib/librandom_numbers.dylib /usr/local/lib/libconsole_bridge.dylib /usr/local/lib/libboost_system-mt.dylib /usr/local/lib/libboost_filesystem-mt.dylib /usr/local/lib/libboost_thread-mt.dylib /Users/xxx/ros_catkin_ws/install_isolated/lib/libresource_retriever.dylib /Users/xxx/ros_catkin_ws/install_isolated/lib/libshape_tools.dylib /Users/xxx/ros_catkin_ws/install_isolated/lib/librandom_numbers.dylib /usr/local/lib/libboost_filesystem-mt.dylib -Wl,-rpath,/Users/xxx/ros_catkin_ws/install_isolated/lib 
ld: library not found for -lassimp

clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [devel/lib/libgeometric_shapes.dylib] Error 1
make[1]: *** [CMakeFiles/geometric_shapes.dir/all] Error 2
make: *** [all] Error 2
<== Failed to process package 'geometric_shapes': 
  Command '/Users/xxx/ros_catkin_ws/install_isolated/env.sh make -j4 -l4' returned non-zero exit status 2

Reproduce this error by running:
==> cd /Users/xxx/ros_catkin_ws/build_isolated/geometric_shapes && /Users/xxx/ros_catkin_ws/install_isolated/env.sh make -j4 -l4

any idea why libassimp.dylib is not found?
it's installed with brew

> ls -h /usr/local/lib/libassimp.dylib 
... /usr/local/lib/libassimp.dylib -> ../Cellar/assimp/3.1.1/lib/libassimp.dylib

createMeshFromResource crashes with inventor stl files

Description

Calling createMeshFromResource with an stl mesh exported from Inventor 2018, the program crashes on a memory corruption. Call stack below.

Workaround 1: open the inventor stl file in meshlab (no issue there) and export is as-is as an stl. Calling createMeshFromResource on the resulting stl file works fine.
Workaround 2: .obj files exported from Inventor are working fine.

The STL files are in attachment, both are binary.

Probably an issue in assimp, but I will leave that to you to log on their repo.

Your environment

• ROS Distro: Indigo
• OS Version: ros:indigo docker container (aka Ubuntu 14.04)
• Binary build 0.7.11-0trusty-20170621-105324-0800

Debug info

Actual crash: malloc(): memory corruption: 0x00000000013f5390
Stacktrace:

#5  0x00007fe89d6abae0 in __GI___libc_malloc (bytes=2920) at malloc.c:2893
#6  0x00007fe89dc66dad in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x00007fe89dc66ea9 in operator new[](unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#8  0x00007f8419983e6b in ?? () from /usr/lib/libassimp.so.3
#9  0x00007f84197b49f6 in ?? () from /usr/lib/libassimp.so.3
#10 0x00007fe89a4aa2c3 in Assimp::Importer::ReadFile(char const*, unsigned int) () from /usr/lib/libassimp.so.3
#11 0x00007fe89a4acfdd in Assimp::Importer::ReadFileFromMemory
#12 0x00007fe89e6bc235 in shapes::createMeshFromBinary
#13 0x00007fe89e6bc5d3 in shapes::createMeshFromResource
#14 0x000000000041cd42 in main ()

mesh.zip

Update CMakeLists.txt to find eigen in indigo

The FindEigen is in cmake_modules now.

You need to call find_package(Eigen REQUIRED) after find packaging find_package(catkin COMPONENTS cmake_modules)

And cmake_modules needs to be a build_depend.

This sort of patch: ros-visualization/rviz#727

New Release for Rolling / Jammy

geometric_shapes has been failing in buildfarm since the transition into Jammy. #215 fixes it and after that gets merged we need a new release.

Use of deprecated logging functions

See: https://github.com/ros/console_bridge/blob/master/include/console_bridge/console.h#L68-L90

https://github.com/ros-planning/geometric_shapes/search?q=logWarn

https://github.com/ros-planning/geometric_shapes/search?q=logError

scaleAndPadd does not keep the object centered

I tried loading an object and scaling down the mesh with scaleAndPadd (the file is in mm instead of m), but the vertices move to a location that's not the center.

Here is the resulting location of the object after scaling by a factor of 0.1 (the grey slate in the middle of the image is the robot and the map grid):

It looks like the function doesn't calculate the center of the mesh, but rather the center of the vertices. I don't know if that's the cause of this issue, but it seems like a bounding box would be the more appropriate operation here.

I could also imagine a center() function that moves the object to the center according to this measure. That might solve my problem at least.

Appending to CMAKE_MODULE_PATH

I would like to specify my own FindQhull.cmake to your package externally, as I have the qhull include files and libraries in special paths (due to package management). This is currently not possible as you prepend your custom cmake module path to CMAKE_MODULE_PATH in https://github.com/ros-planning/geometric_shapes/blob/hydro-devel/CMakeLists.txt#L4. Would it be possible to instead append to the CMAKE_MODULE_PATH? This will only change the cmake find behaviour if someone else specifes a FindQhull.cmake file on the path as the CMAKE_MODULE_PATH is empty by default. If yes, I can provide a pull request.

0.5.4 does not build on Debian Jessie

It is using a too new version of console bridge. This has caused the regression of ~71 downstream packages so I'm rolling it's release into kinetic back:ros/rosdistro#17589

For example: http://build.ros.org/job/Kbin_dj_dJ64__geometric_shapes__debian_jessie_amd64__binary/53/console

00:23:11.534 make -f CMakeFiles/geometric_shapes.dir/build.make CMakeFiles/geometric_shapes.dir/depend
00:23:11.536 make[4]: Entering directory '/tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/obj-x86_64-linux-gnu'
00:23:11.536 cd /tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/obj-x86_64-linux-gnu && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4 /tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4 /tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/obj-x86_64-linux-gnu /tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/obj-x86_64-linux-gnu /tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/obj-x86_64-linux-gnu/CMakeFiles/geometric_shapes.dir/DependInfo.cmake --color=
00:23:11.615 Scanning dependencies of target geometric_shapes
00:23:11.616 make[4]: Leaving directory '/tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/obj-x86_64-linux-gnu'
00:23:11.617 make -f CMakeFiles/geometric_shapes.dir/build.make CMakeFiles/geometric_shapes.dir/build
00:23:11.629 make[4]: Entering directory '/tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/obj-x86_64-linux-gnu'
00:23:11.629 /usr/bin/cmake -E cmake_progress_report /tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/obj-x86_64-linux-gnu/CMakeFiles 1
00:23:11.637 [ 14%] Building CXX object CMakeFiles/geometric_shapes.dir/src/bodies.cpp.o
00:23:11.646 /usr/lib/ccache/c++   -DGEOMETRIC_SHAPES_HAVE_QHULL_2011 -Dgeometric_shapes_EXPORTS -Dqh_QHpointer -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -DNDEBUG -D_FORTIFY_SOURCE=2  -fPIC -I/tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/include -I/usr/include/eigen3 -I/usr/include/assimp -I/opt/ros/kinetic/include    -std=c++11 -o CMakeFiles/geometric_shapes.dir/src/bodies.cpp.o -c /tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/src/bodies.cpp
00:23:15.908 /tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/src/bodies.cpp: In member function ‘virtual void bodies::ConvexMesh::useDimensions(const shapes::Shape*)’:
00:23:15.908 /tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/src/bodies.cpp:811:57: error: ‘CONSOLE_BRIDGE_logWarn’ was not declared in this scope
00:23:15.908      CONSOLE_BRIDGE_logWarn("Convex hull creation failed");
00:23:15.908                                                          ^
00:23:15.908 /tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/src/bodies.cpp: In member function ‘void bodies::BodyVector::setPose(unsigned int, const Affine3d&)’:
00:23:15.908 /tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/src/bodies.cpp:1209:62: error: ‘CONSOLE_BRIDGE_logError’ was not declared in this scope
00:23:15.908      CONSOLE_BRIDGE_logError("There is no body at index %u", i);
00:23:15.908                                                               ^
00:23:15.908 /tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/src/bodies.cpp: In member function ‘const bodies::Body* bodies::BodyVector::getBody(unsigned int) const’:
00:23:15.908 /tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/src/bodies.cpp:1220:62: error: ‘CONSOLE_BRIDGE_logError’ was not declared in this scope
00:23:15.908      CONSOLE_BRIDGE_logError("There is no body at index %u", i);
00:23:15.908                                                               ^
00:23:15.909 CMakeFiles/geometric_shapes.dir/build.make:57: recipe for target 'CMakeFiles/geometric_shapes.dir/src/bodies.cpp.o' failed
00:23:15.909 make[4]: *** [CMakeFiles/geometric_shapes.dir/src/bodies.cpp.o] Error 1
00:23:15.909 make[4]: Leaving directory '/tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/obj-x86_64-linux-gnu'
00:23:15.909 CMakeFiles/Makefile2:156: recipe for target 'CMakeFiles/geometric_shapes.dir/all' failed
00:23:15.910 make[3]: *** [CMakeFiles/geometric_shapes.dir/all] Error 2
00:23:15.910 make[3]: Leaving directory '/tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/obj-x86_64-linux-gnu'
00:23:15.910 Makefile:120: recipe for target 'all' failed
00:23:15.910 make[2]: *** [all] Error 2
00:23:15.910 make[2]: Leaving directory '/tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4/obj-x86_64-linux-gnu'
00:23:15.910 dh_auto_build: make -j1 returned exit code 2
00:23:15.912 debian/rules:35: recipe for target 'override_dh_auto_build' failed
00:23:15.912 make[1]: *** [override_dh_auto_build] Error 2
00:23:15.912 make[1]: Leaving directory '/tmp/binarydeb/ros-kinetic-geometric-shapes-0.5.4'
00:23:15.914 debian/rules:22: recipe for target 'build' failed
00:23:15.914 make: *** [build] Error 2
00:23:15.915 dpkg-buildpackage: error: debian/rules build gave error exit status 2
00:23:15.917 E: Building failed
00:23:15.920 Traceback (most recent call last):
00:23:15.921   File "/tmp/ros_buildfarm/ros_buildfarm/binarydeb_job.py", line 138, in build_binarydeb
00:23:15.921     subprocess.check_call(cmd, cwd=source_dir)
00:23:15.921   File "/usr/lib/python3.4/subprocess.py", line 561, in check_call
00:23:15.921     raise CalledProcessError(retcode, cmd)
00:23:15.921 subprocess.CalledProcessError: Command '['apt-src', 'build', 'ros-kinetic-geometric-shapes']' returned non-zero exit status 1
00:23:15.921 

It is possible to support both versions of the console bridge API through a single source tree using macros like this: https://github.com/ros/class_loader/blob/indigo-devel/include/class_loader/console_bridge_compatibility.hpp however another common approach is to simply fork the development branches.

geometric_shapes depends on robot_model which is a metapackage

catkin packages can not depend on metapackages. This causes rosmake to fail when building dry packages which depend on geometric_shapes:

selliott@dri:~/moveit/src/moveit_ros/planning_interface/planning_scene_interface$ make
mkdir -p bin
cd build && cmake -Wdev -DCMAKE_TOOLCHAIN_FILE=/opt/ros/groovy/share/ros/core/rosbuild/rostoolchain.cmake  ..
[rosbuild] Building package planning_scene_interface
Failed to invoke /opt/ros/groovy/bin/rospack deps-manifests planning_scene_interface
[rospack] Error: package/stack 'geometric_shapes' depends on non-existent package 'robot_model' and rosdep claims that it is not a system dependency. Check the ROS_PACKAGE_PATH or try calling 'rosdep update'


CMake Error at /opt/ros/groovy/share/ros/core/rosbuild/public.cmake:129 (message):


  Failed to invoke rospack to get compile flags for package
  'planning_scene_interface'.  Look above for errors from rospack itself.
  Aborting.  Please fix the broken dependency!

Call Stack (most recent call first):
  /opt/ros/groovy/share/ros/core/rosbuild/public.cmake:203 (rosbuild_invoke_rospack)
  CMakeLists.txt:12 (rosbuild_init)


-- Configuring incomplete, errors occurred!
make: *** [all] Error 1

Actually @wjwwood

--- stderr: geometric_shapes/src/bodies.cpp:44: warning: redundant redeclaration(s)

Hi, should this error be logged when building geometric_shapes and does it affect package functionality?

--- stderr: geometric_shapes
In file included from /home/user/ws_ROS2/src/moveit2/geometric_shapes/src/bodies.cpp:44:
/usr/include/libqhull_r/libqhull_r.h:1057:9: warning: redundant redeclaration of ‘void qh_printsummary(qhT*, FILE*)’ in same scope [-Wredundant-decls]
 1057 | void    qh_printsummary(qhT *qh, FILE *fp);
      |         ^~~~~~~~~~~~~~~
/usr/include/libqhull_r/libqhull_r.h:1024:9: note: previous declaration of ‘void qh_printsummary(qhT*, FILE*)’
 1024 | void    qh_printsummary(qhT *qh, FILE *fp);
      |         ^~~~~~~~~~~~~~~
/usr/include/libqhull_r/libqhull_r.h:1099:6: warning: redundant redeclaration of ‘void qh_meminit(qhT*, FILE*)’ in same scope [-Wredundant-decls]
 1099 | void qh_meminit(qhT *qh, FILE *ferr);
      |      ^~~~~~~~~~
In file included from /usr/include/libqhull_r/libqhull_r.h:31,
                 from /home/user/ws_ROS2/src/moveit2/geometric_shapes/src/bodies.cpp:44:
/usr/include/libqhull_r/mem_r.h:218:6: note: previous declaration of ‘void qh_meminit(qhT*, FILE*)’
  218 | void qh_meminit(qhT *qh, FILE *ferr);
      |      ^~~~~~~~~~
In file included from /home/user/ws_ROS2/src/moveit2/geometric_shapes/src/bodies.cpp:44:
/usr/include/libqhull_r/libqhull_r.h:1100:6: warning: redundant redeclaration of ‘void qh_memfreeshort(qhT*, int*, int*)’ in same scope [-Wredundant-decls]
 1100 | void qh_memfreeshort(qhT *qh, int *curlong, int *totlong);
      |      ^~~~~~~~~~~~~~~
In file included from /usr/include/libqhull_r/libqhull_r.h:31,
                 from /home/user/ws_ROS2/src/moveit2/geometric_shapes/src/bodies.cpp:44:
/usr/include/libqhull_r/mem_r.h:217:6: note: previous declaration of ‘void qh_memfreeshort(qhT*, int*, int*)’
  217 | void qh_memfreeshort(qhT *qh, int *curlong, int *totlong);
      |      ^~~~~~~~~~~~~~~
In file included from /home/user/ws_ROS2/src/moveit2/geometric_shapes/src/bodies.cpp:44:
/usr/include/libqhull_r/libqhull_r.h:1123:9: warning: redundant redeclaration of ‘void qh_collectstatistics(qhT*)’ in same scope [-Wredundant-decls]
 1123 | void    qh_collectstatistics(qhT *qh);
      |         ^~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/libqhull_r/libqhull_r.h:121,
                 from /home/user/ws_ROS2/src/moveit2/geometric_shapes/src/bodies.cpp:44:
/usr/include/libqhull_r/stat_r.h:515:9: note: previous declaration of ‘void qh_collectstatistics(qhT*)’
  515 | void    qh_collectstatistics(qhT *qh);
      |         ^~~~~~~~~~~~~~~~~~~~
In file included from /home/user/ws_ROS2/src/moveit2/geometric_shapes/src/bodies.cpp:44:
/usr/include/libqhull_r/libqhull_r.h:1124:9: warning: redundant redeclaration of ‘void qh_printallstatistics(qhT*, FILE*, const char*)’ in same scope [-Wredundant-decls]
 1124 | void    qh_printallstatistics(qhT *qh, FILE *fp, const char *string);
      |         ^~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/libqhull_r/libqhull_r.h:121,
                 from /home/user/ws_ROS2/src/moveit2/geometric_shapes/src/bodies.cpp:44:
/usr/include/libqhull_r/stat_r.h:519:9: note: previous declaration of ‘void qh_printallstatistics(qhT*, FILE*, const char*)’
  519 | void    qh_printallstatistics(qhT *qh, FILE *fp, const char *string);
      |         ^~~~~~~~~~~~~~~~~~~~~
---

env

• Ubuntu 20.04
• ROS2 Foxy
• binaries
• server glx vendor string: SGI
• sudo apt update = up to date

Is not building in release on trusty/indigo

The configuration on the buildfarm inserts "-DCMAKE_BUILD_TYPE=None", which was not the case in hydro, and which causes https://github.com/ros-planning/geometric_shapes/blob/hydro-devel/CMakeLists.txt#L7 not to be set to Release.

This causes major issues when doing "mergeVertices" in the startup of MoveIt. What normally takes about 3 seconds, suddenly takes over 6 minutes.

It appears that -DCMAKE_BUILD_TYPE=None comes from dh_make? I'm not entirely sure the proper way to fix this. @wjwwood @tfoote do you guys have any input on this from the buildfarm side?

Release geometric_shapes into ROS Noetic?

Would you mind releasing geometric_shapes to ROS Noetic? It looks like all of its dependencies have been released, and recursively 41 repos need it.

Possible Memory Leak in constructBodyFromMsgHelper()

Won't it causes memory leak if shape is allocated but never deleted?
https://github.com/ros-planning/geometric_shapes/blob/85999cb/src/body_operations.cpp#L182

Lunar release

Hi @isucan, @davetcoleman and geometric_shapes maintainers,

As you may know the next ROS release Lunar Loggerhead is around the corner 🎉
Is it possible to roll out the current release of geometric_shapes on ROS Lunar? Being a low level package it will allow many maintainers to release their own packages that depend directly or indirectly on geometric_shapes.

Thanks!

How to install for import

Hello,

maybe my question is obvious, but I am not sure how to install the library, so that I can import them into my own packages.

[Indigo] Release 0.4.5

Already tagged.

Release for Indigo isn't urgent so I'll wait to make a release for ros-infrastructure/ros_buildfarm#347 to be resolved.

C++11 error on ROS buildfarm for kinetic

Can @davetcoleman, @de-vri-es address this issue? I'm not the right person to fix this.

From #48 (comment)

This appears to use c++11 in it's headers but doesn't export it for downstream. Causing failures:

01:11:58 In file included from /tmp/binarydeb/ros-kinetic-collada-urdf-1.12.3/src/collada_urdf.cpp:52:0:
01:11:58 /opt/ros/kinetic/include/resource_retriever/retriever.h:81:38: warning: defaulted and deleted functions only available with -std=c++11 or -std=gnu++11
01:11:58    Retriever(const Retriever & ret) = delete;
01:11:58                                       ^
01:11:58 In file included from /tmp/binarydeb/ros-kinetic-collada-urdf-1.12.3/src/collada_urdf.cpp:82:0:
01:11:58 /opt/ros/kinetic/include/geometric_shapes/shapes.h:254:21: error: ‘shared_ptr’ in namespace ‘std’ does not name a template type
01:11:58    OcTree(const std::shared_ptr<const octomap::OcTree> &t);
01:11:58                      ^
01:11:58 /opt/ros/kinetic/include/geometric_shapes/shapes.h:254:31: error: expected ‘,’ or ‘...’ before ‘<’ token
01:11:58    OcTree(const std::shared_ptr<const octomap::OcTree> &t);
01:11:58                                ^
01:11:58 /opt/ros/kinetic/include/geometric_shapes/shapes.h:264:8: error: ‘shared_ptr’ in namespace ‘std’ does not name a template type
01:11:58    std::shared_ptr<const octomap::OcTree> octree;
01:11:58         ^
01:11:58 CMakeFiles/collada_urdf.dir/build.make:65: recipe for target 

http://build.ros.org/view/Kbin_uX32/job/Kbin_uX64__collada_urdf__ubuntu_xenial_amd64__binary/16/console

Add mutex to protect global map

@peci1, please address ed4cf13#r38767382. Thanks.

building geometric_shapes results in error /visualization_msgs/msg/detail/markertraits.hpp

Following the moveit getting started tutorial but substituting 'galactic' for 'foxy' i got this error message while building:

https://gist.github.com/toomuchcookies/22dd60fde7e6e5691956c16efd4f2f3e

@JafarAbdi , i hope this helps.

Negative cylinder mesh shapes eat up all (at least, most) of memory

I'm currently looking at ros/robot_model#175 , and ran into what may be a bug. According to the URDF spec, a link with a cylinder can have a negative length and still be well-formed. For most software, this means the cylinder grows in the negative direction from the origin. However, when urdf_to_collada runs across it, it ends up down in geometric_shapes:createMeshFromShape(cylinder), where we have this code:

  double h = cylinder.length;
  ...
  unsigned int h_num = ceil(h / circle_edge);
  ...
  for (unsigned int i = 0; i < h_num - 1 ; ++i)
    for(unsigned int j = 0; j < tot; ++j)
      vertices.push_back(Eigen::Vector3d(r * cos(phi + phid * j), r * sin(phi + phid * j), h / 2 - (i + 1) * hd));

Essentially, we divide a negative length by a positive number, assign to an unsigned (now a huge positive number), and then push_back millions of items into the vector, exhausting memory. One way to fix this might be to take fabs(h) when calculating h_num, but I'm not sure if that is correct. Any advice here on how we might fix this?

Broken box-ray intersection

Had some cases where the ray/box intersection was broken.

#67

octomap include dirs not included

octomap is find_package'ed, and the OCTOMAP_INCLUDE_DIRS are exported in the catkin_package call, but they are never passed to include_directories:

https://github.com/ros-planning/geometric_shapes/blob/hydro-devel/CMakeLists.txt#L38

This causes a build failure on a truly isolated caktin workspace build.

Possible memory leak in MoveIt's usage of geometric_shapes

I have noticed a potential memory leak in MoveIt's usage of geometric_shapes for the planning_scene. After adding and removing boxes thousands of times to different planning_scene::PlanningScenePtrs, removing boxes starts to take an incredibly long time. This can be demonstrated by modifying suction_grasp_pipeline_demo.cpp to filter grasps with the moveit_grasps::SuctionGraspFilter > 10 times in a single run. (see: suction_grasp_pipeline_demo.launch)

I was wondering, what reason do we have for using raw pointers with explicit memory management for the planning scene world and the underlying geometric shapes?

Perhaps @davetcoleman, @rhaschke or @v4hn could weigh in here

Support nonuniform shape scaling.

Now it is only possible to use a single number as the shape's scale. But I create shapes read from a URDF as meshes, where nonuniform scaling may occur. I'd like to be able to propagate this nonuniform scaling into the resulting shapes::Shape, too.

Release into kinetic 0.4.5 (or higher)

Currently version 0.4.4 is released into kinetic, but a problem with the shared_ptr types has since been fixed.

needs hydro-devel branch?

like the rest of moveit now has...

Release into ROS Jade

Before release, want to:

• test and pull other changes from #25 into indigo-devel

Blocking upstream dependencies:

• eigen_stl_containers
• octomap
• random_numbers
• resource_retriever
• shape_tools

bodies::Body::containsPoint() has non-consistent behavior for "surface" points

Sphere excludes surface points.

Cylinder includes top and bottom surfaces, but excludes the sides.

Box includes all surface points.

Mesh includes all surface points.

I think being consistent would be great. What's bad is that there is no documentation that would help determining what's the desired result.

I created a test suite in #90 . I defined a macro

#define EXPECT_SURF EXPECT_TRUE
//#define EXPECT_SURF EXPECT_FALSE

which you can change to see what happens if you define that surface points should be included or excluded. So far, the test suite fails in both cases.

With #define EXPECT_SURF EXPECT_FALSE:

With #define EXPECT_SURF EXPECT_TRUE:

What to do next? Apparently, there are 3 options:

1. Define that surface points should be considered inside (my preferred option).
2. Define that surface points should be considered outside.
3. Do nothing and claim the current status as desired (wouldn't break existing code; but Wiki says C++ API is UNREVIEWED and UNSTABLE, so it shouldn't matter).

What are your opinions? When there's a consensus about this choice, I can implement the fix.

Drop -devel from release branch names

As these branches are used for releases and not current devleopment, could we just use the ros version as the branch name?

Shape Derived Classes Lack Co-Variant Return Type for Clone()

C++ has covariant return types. They are useful for things. They are especially useful for implementing clone() functions polymorphically. See this page.

So for instance:

class Mesh : public Shape
{
//...
virtual Shape* clone() const;
// ...
};

should be

class Mesh : public Shape
{
//...
virtual Mesh* clone() const;
// ...
};

I was attempting to load many, large models using this library. I wanted to cache the shapes::Mesh* pointers using their URI name. Unfortunately even though I know I have a Mesh, I can't clone it to a mesh because the function returns the base class. This currently requires an unneeded dynamic_cast to fix.

Mesh with no faces created for small cylinders

We encountered this issue when attempting to convert the Robotiq hand model from DRCSim using urdf_to_collada. If a cylinder element is smaller than 0.01, no faces are created, and urdf_to_collada will subsequently crash. From looking at the code in mesh_operations.cpp, the mesh generation for cone objects would be prone to the same issue.

The simplest fix is probably to enforce a sensible minimum for unsigned int tot.

Here is a small example, test with rosrun collada_urdf urdf_to_collada test.urdf test.dae.

<robot name="my_robot">
  <link name="my_link">
    <collision>
      <origin xyz="0 0 0" rpy="0 0 0" />
      <geometry>
        <cylinder radius="0.001" length="0.5"/>
      </geometry>
    </collision>
  </link>
</robot>

Assimp::Importer::ReadFileFromMemory creates a mesh with too many vertices

Assimp::Importer::ReadFileFromMemory creates a mesh with way too many vertices. For example, for this simple .obj cube:

# Blender v2.74 (sub 0) OBJ File: ''
# www.blender.org
mtllib cube_2_5_red_2.mtl
o Cube.001
v 0.012500 -0.012500 -0.012500
v 0.012500 -0.012500 0.012500
v -0.012500 -0.012500 0.012500
v -0.012500 -0.012500 -0.012500
v 0.012500 0.012500 -0.012500
v -0.012500 0.012500 -0.012500
v -0.012500 0.012500 0.012500
v 0.012500 0.012500 0.012500
vn 0.000000 -1.000000 -0.000000
vn 0.000000 1.000000 0.000000
vn 1.000000 -0.000000 0.000000
vn 0.000000 -0.000000 1.000000
vn -1.000000 0.000000 0.000000
vn 0.000000 0.000000 -1.000000
usemtl Material.001
s 1
f 1//1 2//1 3//1 4//1
f 5//2 6//2 7//2 8//2
f 1//3 5//3 8//3 2//3
f 2//4 8//4 7//4 3//4
f 3//5 7//5 6//5 4//5
f 5//6 1//6 4//6 6//6

Creates 24 instead of the 8 required, 2/3 of them duplicated. The why is explained here (thanks to @gavanderhoorn to point me to this explanation).

This should not be a problem, as the resulting mesh looks fine. But for any reason, possibly related with how OpenGL handles occlusions, it doesn't work for clearing the octomap with DepthImageOctomapUpdater::excludeShape. All this is explained in this MoveIt group post.

The solution pointed by @gavanderhoorn's suggested explanation is to use the RemoveComponents post-processing step, removing all but the meshes. (I'll PR in a moment)

Wrong assumption about planes of a ConvexMesh in case padding is used

In ConvexMesh::useDimensions(), there is this code that processes planes (halfspaces) generated by qhull:

https://github.com/ros-planning/geometric_shapes/blob/07a5254b698ecc89e511dc5b3182ecb6c7d2258e/src/bodies.cpp#L903-L904

It checks if the plane for the currently processed triangle/facet isn't too similar to the plane for the previous triangle. If it is, it merges these planes into one and makes both triangles reference the same plane.

However, according to the definition of padding for convex meshes in this library, this optimization goes wrong when non-zero padding is used.

I made some visualizations to make this argument clearly visible:

Here, the red line is original (unscaled) "mesh" (well...). The cyan one is the line after applying only scaling. And the green one is after padding is applied. You can see that the line stops being a line and any planes that would be optimized by the previous algorithm would no longer be parallel.

Maybe even more obvious.

This has also consequences for more code paths. It seems to me that two things are required.

1. Get rid of the "if" in the above code excerpt and just add one plane per each triangle.
2. Take a broader look around the code, and e.g. add mesh_data_->scaled_planes_ which would contain the correctly scaled and padded planes which could be used for collision checking. For example this code tries to subtract padding from the data, but fails to do it correctly (a part of it is fixed in #109):

https://github.com/ros-planning/geometric_shapes/blob/07a5254b698ecc89e511dc5b3182ecb6c7d2258e/src/bodies.cpp#L1091-L1100

If there were an already precomputed field containing the scaled planes, all computations of this kind could be done both efficiently and without fear if everything is correctly accounted for. My approach to recomputing the scaled planes would be to just take the scaled vertices and reconstruct the scaled planes from them. It has just one drawback - so far, mesh_data_ are not touched in updateInternalData(), however if we wanted to keep a set of scaled planes, these would obviously need to be updated in updateInternalData(). But this function anyways has a loop over all vertices to recompute the scaled vertices, so I think another loop for scaled planes is not a problem. It might well be compensated by the possible speedups from #126.

problem with either mesh loading or constructMarkerFromShape

I've recently been trying to create markers from mesh objects, and something is badly wrong. At this point I am unsure whether the problem is in loading the mesh from the resource in the marker generating code. In either case, the version of the constructMarkerFromShape that uses triangles doesn't show anything in Rviz, and the line one is garbled, as shown in this image. It looks to me like maybe the triangles are associated with incorrect vertices. I will attempt to attach code to this that will help reproduce the problem. The image shows the results of trying to visualize the base_link of the pr2.

Body::computeBoundingBox?

I've noticed the interface of Body has methods computeBoundingSphere and computeBoundingCylinder, but there's no computeBoundingBox.

I think BBs are so common that it's a pity they're not in the interface. Also, the implementation would be super easy, as the most complicated (ConvexMesh) already computes a helper BB.

However, the other two existing methods are virtual, so it'd make sense to make these also virtual. But that would break ABI. What to do with that?

My suggestion:

• kinetic-devel and indigo-devel: add non-virtual functions to each of the specific bodies, so that if you cast to the correct type, the method would be available, but the ABI doesn't have to change
• melodic-devel (or whatever corresponds to master branch): add a normal virtual function to Body and its overrides to the specific bodies

When we agree on the best approach, I can prepare the PR.

CI build jobs not running on Foxy

Looks like the build jobs haven't been triggered on the foxy branch since b4df18c. At least GitHub doesn't show the build results any more, and I can't find the job runs in the "Actions" panel.

wstool/rosdep fetches incompatible versions of geometric_shapes and libconsole-bridge

I ran into compatibility issues when trying to build this package with ROS from source on armhf Debian jessie following this guide. The problem came from rosdep fetching the latest version it could find of libconsole-bridge which is only 0.2.5-2. #72 removed support for this old version of libconsole-bridge. In order to get the package to compile, I removed the latest version of geometric_shapes which was automatically fetched by wstool and replaced it with version 0.5.3, from before #72.

Is there a way which you can define that geometric_shapes depends on a newer version of console-bridge to prevent people running into this issue in the future?

Box/ray intersections are broken in 0.5.4

I'm on 16.04/Kinetic and geometric_shapes installed from .debs (0.5.4). It appears box/ray intersections do not work at all, at least in my application (ray-based self filtering). I created a test URDF with 3 primitives for testing ray intersection functionality. When I use 3 spheres for these shapes, things look as expected, with the sphere shapes shadowing cloud data behind them:

If I change the primitives to boxes of approximately same size and keep everything else the same, no filtering takes place anymore, as the intersection test appears not to work as intended:

Note the gap at the ceiling is due to LIDAR physically not covering that part and unrelated to the observed issue. I noted #68 supposedly recently fixed box-ray intersection, so wondering if this accidentally introduced another bug.
The code used for the intersection test in my use case is here: https://github.com/team-vigir/robot_self_filter/blob/vlp16_filter/include/robot_self_filter/self_mask.h#L603

Performance: Body::setPose() should use Eigen::Isometry3d::linear() instead of ::rotation().

Here: https://github.com/ros-planning/geometric_shapes/blob/bca6b88be8ba70851c79f785e0d45b12cb1917df/src/bodies.cpp#L318

And here: https://github.com/ros-planning/geometric_shapes/blob/bca6b88be8ba70851c79f785e0d45b12cb1917df/src/bodies.cpp#L549

When using rotation(), Eigen unnecessarily does SVD decomposition via Eigen::Transform::computeRotationScaliing(). But we're working with isometries, so linear part of the transform is equal to the rotation. I've done some performance tests and calling setPose() on 20 000 bodies takes 250 ms, which is a lot (and according to the profiler, the time is dominated by SVD computations).

add so versions?

As discussed in ed4cf13#r38768115 adding so-versions would add some safety and help discover issues on binary incompatibility early on.

If I recall correctly there were some issues that bloom cannot actually pass on this information to Debians but at least the software would not start instead of later crashing unexpectedly ...

fails to configure config.h.in when paths contain spaces

When the path contains spaces configure_file() is unable to find the template:

CMake Error: File /home/dthomas/ros/hydro/desk\ top/sr\ c/geometric_shapes/test/resources/config.h.in does not exist.
CMake Error at test/CMakeLists.txt:6 (configure_file):
  configure_file Problem configuring file

[Kinetic] Release 0.5.2

Suggested at moveit/moveit#18 (comment)

• changelog, tagging
• prerelease test (wily, xenial). Running prerelease test is very preferred (see #48 where prerelease test could have avoided false release)
• bloom

I'm stuck at running prerelease test by ros-infrastructure/ros_buildfarm#347, which may be only happening on my Ubuntu. If someone could run the following command, and if that runs fine then share the result, maybe the last 20 lines of it.

sudo apt-get install python-ros-buildfarm
dpkg -p python-ros-buildfarm |grep Version
mkdir /tmp/prerelease1 && cd /tmp/prerelease1
generate_prerelease_script.py https://raw.githubusercontent.com/ros-infrastructure/ros_buildfarm_config/production/index.yaml kinetic default ubuntu xenial amd64 geometric_shapes  --level 0   --output-dir ./
./prerelease.sh

On another terminal,

generate_prerelease_script.py https://raw.githubusercontent.com/ros-infrastructure/ros_buildfarm_config/production/index.yaml kinetic default ubuntu wily amd64 geometric_shapes  --level 0   --output-dir ./
./prerelease.sh

Migrating from fcl to moveit-geometric shapes

Hello everyone,

I was using before the fcl libraries, but after founding several problems I would like to use this library.
The code I had before was:
typedef std::shared_ptr fcl::CollisionGeometry CollisionGeometryPtr_t;
// Define a Ellipsoid with the dimensions of the joint+link
//This geometry may be modified depending on the robot
CollisionGeometryPtr_t boxGeometry (new fcl::Box (16.,16.,8.));

The one for using this library would be:
shapes::Shape *shape = new shapes::Box(16.0, 16.0, 8.0);
Without any collisiongeometry defined. Now how can I define a collisionGeometry to check if two boxes collide?
Thank you in advance

foxy build error linking boost libbrary

Platform: ubuntu 20.04 foxy
When build the package from source using ros2 branch, something wrong with linking the boost library:

--- stderr: geometric_shapes
/usr/bin/ld: CMakeFiles/test_loaded_meshes.dir/test_loaded_meshes.cpp.o: in function CompareMeshVsPrimitive::SetUp()': test_loaded_meshes.cpp:(.text._ZN22CompareMeshVsPrimitive5SetUpEv[_ZN22CompareMeshVsPrimitive5SetUpEv]+0x13f): undefined reference to boost::filesystem::path::operator/=(boost::filesystem::path const&)'
collect2: error: ld returned 1 exit status
make[2]: *** [test/CMakeFiles/test_loaded_meshes.dir/build.make:158: test/test_loaded_meshes] Error 1
make[1]: *** [CMakeFiles/Makefile2:422: test/CMakeFiles/test_loaded_meshes.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
/usr/bin/ld: CMakeFiles/test_point_inclusion.dir/test_point_inclusion.cpp.o: in function MeshPointContainment_Pr2Forearm_Test::TestBody()': test_point_inclusion.cpp:(.text+0x710b): undefined reference to boost::filesystem::path::operator/=(boost::filesystem::path const&)'
/usr/bin/ld: CMakeFiles/test_point_inclusion.dir/test_point_inclusion.cpp.o: in function MeshPointContainment_Basic_Test::TestBody()': test_point_inclusion.cpp:(.text+0x17216): undefined reference to boost::filesystem::path::operator/=(boost::filesystem::path const&)'
collect2: error: ld returned 1 exit status
make[2]: *** [test/CMakeFiles/test_point_inclusion.dir/build.make:158: test/test_point_inclusion] Error 1
make[1]: *** [CMakeFiles/Makefile2:277: test/CMakeFiles/test_point_inclusion.dir/all] Error 2
/usr/bin/ld: CMakeFiles/test_body_operations.dir/test_body_operations.cpp.o: in function Bodies_ConstructShapeFromBodyMesh_Test::TestBody()': test_body_operations.cpp:(.text+0x2346): undefined reference to boost::filesystem::path::operator/=(boost::filesystem::path const&)'
/usr/bin/ld: CMakeFiles/test_body_operations.dir/test_body_operations.cpp.o: in function Bodies_ConstructMarkerFromBodyMesh_Test::TestBody()': test_body_operations.cpp:(.text+0x341a): undefined reference to boost::filesystem::path::operator/=(boost::filesystem::path const&)'
collect2: error: ld returned 1 exit status
make[2]: *** [test/CMakeFiles/test_body_operations.dir/build.make:158: test/test_body_operations] Error 1
make[1]: *** [CMakeFiles/Makefile2:480: test/CMakeFiles/test_body_operations.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

I'm not sure if this can be fixed with adjusting the Cmakelist.txt

Release in ROS2 Eloquent?

Hi. I was surprised to see this missing in ROS2 Eloquent, but apparently is available in Dashing. Is there plans to include it again?

Can't find Eigen3 when compiling Kinetic from sources

I'm following the build from source instructions, I'm using a Raspberry Pi 3 with Raspbian.

==> cmake /home/victor/libraries/ros_catkin_ws/src/geometric_shapes -DCATKIN_DEVEL_PREFIX=/home/victor/libraries/ros_catkin_ws/devel_isolated/geometric_shapes -DCMAKE_INSTALL_PREFIX=/home/victor/libraries/ros_catkin_ws/install_isolated -DCMAKE_BUILD_TYPE=Release -G Unix Makefiles in '/home/victor/libraries/ros_catkin_ws/build_isolated/geometric_shapes'
-- Checking for module 'assimp'
--   Found assimp, version 3.0.1264
-- Boost version: 1.55.0
-- Found the following Boost libraries:
--   system
--   filesystem
CMake Error at CMakeLists.txt:24 (find_package):
  By not providing "FindEigen3.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Eigen3", but
  CMake did not find one.

  Could not find a package configuration file provided by "Eigen3" with any
  of the following names:

    Eigen3Config.cmake
    eigen3-config.cmake

  Add the installation prefix of "Eigen3" to CMAKE_PREFIX_PATH or set
  "Eigen3_DIR" to a directory containing one of the above files.  If "Eigen3"
  provides a separate development package or SDK, be sure it has been
  installed.


-- Configuring incomplete, errors occurred!

$ sudo find / -iname "FindEigen3.cmake"
/home/victor/libraries/ros_catkin_ws/src/orocos_kinematics_dynamics/python_orocos_kdl/cmake/FindEigen3.cmake
/home/victor/libraries/ros_catkin_ws/src/orocos_kinematics_dynamics/orocos_kdl/config/FindEigen3.cmake
/usr/share/cmake-3.0/Modules/FindEigen3.cmake
/usr/share/cmake-2.8/Modules/FindEigen3.cmake

$ cmake --version
cmake version 3.6.2

 $ dpkg -l | grep eigen
ii  libeigen3-dev  3.2.2-3  all  lightweight C++ template library for linear algebra

I solved the issue with:

sudo ln -s /usr/share/cmake-3.0/Modules/FindEigen3.cmake /usr/share/cmake-3.6/Modules/FindEigen3.cmake

Is it the fault of Eigen package not installing it's FindEigen3.cmake to the right path?

Non-uniform padding of non-convex, long meshes

I noticed that when applying a padding factor to non-convex, long-in-one dimension meshes, such as the table pictured below, the padding applied to the vertices is not uniform, since it is applied along the vector joining the mesh center and the vertex being padded. Any advice on how to make the padding more accurate for this kind of meshes?

Test case example: I have a robot arm on top of the table depicted below and want to add padding of 10 cm to the table to avoid the robot hand to collide during pick and place, meaning that I'd expect to have the table's top, for instance, "grow up" 10 cm (besides "growing in the X and Y directions as well).

In reality, when I apply padding to the table, what I get is that the table top grows in X ~9cm, whereas in Y and Z it grows only ~3cm.

Galactic Release

Blocked by

• OctoMap/octomap#335
• moveit/random_numbers#31

Foxy Release

For a Foxy release of this we need a foxy release of octomap: https://index.ros.org/p/octomap/github-octomap-octomap/#foxy

Release into Melodic

All of the dependencies for geometric_shapes are available in Melodic, so it would be great to get this released there. Thanks in advance!