Add rtabmap_ros and fix rtabmap_viz crash on macOS

[baradejoo]

Summary

• Add rtabmap_ros (0.23.7). The metapackage pulls in the rtabmap_* ROS 2 wrappers (msgs, conversions, util, sync, odom, slam, python, rviz_plugins, viz, launch, examples, demos) plus the missing aruco_msgs and aruco_opencv_msgs. The rtabmap core library is already built for lyrical.
• patch/ros-lyrical-rtabmap-conversions.patch: OpenCV 5 renamed features2d to features, so <opencv2/features2d/features2d.hpp> no longer exists. Include <opencv2/features.hpp> on OpenCV >= 5 (same approach as the existing rtabmap patch).
• patch/ros-lyrical-rtabmap-slam.patch: the legacy constant CV_BGR2GRAY was removed in OpenCV 5, use cv::COLOR_BGR2GRAY.
• patch/ros-lyrical-rtabmap-viz.patch: fix rtabmap_viz crashing on startup on macOS (see below).

rtabmap_viz crash on macOS

All packages built, but rtabmap_viz segfaulted as soon as its window was shown, right after reading the parameters:

[INFO] [rtabmap_viz]: Parameters successfully read.
[ros2run]: Segmentation fault: 11

The crash report showed a jump to a null function pointer inside VTK while painting the 3D view:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   ???                                  0x0 ???
1   libvtkRenderingOpenGL2-9.7.9.7.dylib vtkOpenGLVertexArrayObject::Bind() + 100
...
20  libvtkGUISupportQt-9.7.9.7.dylib     QVTKOpenGLNativeWidget::paintGL() + 104
...
46  rtabmap_viz                          rtabmap_viz::GuiWrapper::GuiWrapper(rclcpp::NodeOptions const&) + 3328

rtabmap_viz creates its QApplication without requesting an OpenGL context suitable for VTK. On macOS Qt then creates a legacy OpenGL 2.1 context, in which the vertex array object functions used by VTK 9 are not available, so the call ends up at address 0x0. On Linux the default context usually exposes these functions, which is why the problem does not show up there.

The standalone rtabmap application (from the already published rtabmap package) works on the same machine, because its main() sets the surface format before creating the QApplication. The patch applies the same two calls in rtabmap_viz/src/GuiNode.cpp:

#if VTK_MAJOR_VERSION > 9 || (VTK_MAJOR_VERSION==9 && VTK_MINOR_VERSION >= 1)
	QSurfaceFormat::setDefaultFormat(QVTKRenderWidget::defaultFormat());
#endif
	QApplication::setAttribute(Qt::AA_ShareOpenGLContexts);

	app = new QApplication(argc, argv);

With the patch rtabmap_viz starts normally (rtabmap_viz started.) and connects to rtabmap. This is an upstream issue in introlab/rtabmap_ros, so I can also send the fix there.

Notes

Tested locally on osx-arm64: all packages build, the rtabmap, rgbd_odometry/icp_odometry, rgbd_sync, point_cloud_xyz and rtabmap_viz nodes start, and rtabmap_python imports. Linux and Windows will be verified by CI.

[baradejoo]

The linux-aarch64 failures came from the rtabmap_* packages themselves: for aarch64 their CMakeLists.txt look up some libraries (builtin_interfaces__rosidl_generator_c, rcutils, message_filters, crypto) only in hardcoded system paths (/opt/ros/$ROS_DISTRO/lib, /usr/lib/aarch64-linux-gnu) with NO_DEFAULT_PATH, which don't exist in a conda environment.

I added patches for rtabmap_msgs, rtabmap_conversions, rtabmap_slam, rtabmap_viz, rtabmap_sync, rtabmap_odom and rtabmap_rviz_plugins that keep the find_library(... REQUIRED) calls but drop the hardcoded paths and the NO_DEFAULT_PATH/NO_CMAKE_FIND_ROOT_PATH flags, so CMake finds the libraries in $PREFIX.

Alternatively the whole aarch64 block could just be removed, since it's only a workaround for Debian packaging issues (introlab/rtabmap_ros#1285, #1288) and the found libraries aren't used afterwards. Let me know if you'd prefer that and I'll switch.

With that fixed, rtabmap_sync now configures fine on linux-aarch64, but the job keeps getting killed with Process completed with exit code 143 about 6 minutes in, right at the start of compilation:

[1/24] Building CXX object CMakeFiles/rtabmap_sync.dir/src/impl/CommonDataSubscriberStereo.cpp.o
Error: Process completed with exit code 143.

It doesn't look like a compile error, the process just gets terminated. Re-running via an empty commit gave the same result.

Have you seen something like this before on the aarch64 runners, or is there a preferred way to handle it?

I also disabled rtabmap_ros on Windows for now (rtabmap_conversions doesn't export symbols, so no .lib is produced). I can look into a Windows fix in a follow-up.

@traversaro @Tobias-Fischer