Updated CI to be based on tesseract_planning CI docker image

[marip8]

Changes per commit message to reduce time required for CI

[Levi-Armstrong]

LGTM

[marip8]

Any ideas why the conversions header from octomap_msgs can't be found in the humble build? I initially thought it was because it is not a part of the messages target, but my attempt in the last commit didn't seem to solve the issue

[Levi-Armstrong]

I am not familiar with ros2 build tools but does anything look incorrect in the link below? I do not see that a interface target is being created, but maybe one of the ros macros should be doing this.
https://github.com/OctoMap/octomap_msgs/blob/ros2/CMakeLists.txt

[Levi-Armstrong]

I think it is because they are not creating an interface target for the header.

[marip8]

I didn't see anything specifically problematic with their CMakeLists (other than not making an interface target). The CMake package config file does define the variable octomap_msgs_INCLUDE_DIRS, so I thought it should be enough to add that to the target_include_directories command.

Here is what is in the CMake file that looks to be associated with include directories

# generated from ament_cmake_export_include_directories/cmake/ament_cmake_export_include_directories-extras.cmake.in

set(_exported_include_dirs "${octomap_msgs_DIR}/../../../include/octomap_msgs")

# append include directories to octomap_msgs_INCLUDE_DIRS
# warn about not existing paths
if(NOT _exported_include_dirs STREQUAL "")
  find_package(ament_cmake_core QUIET REQUIRED)
  foreach(_exported_include_dir ${_exported_include_dirs})
    if(NOT IS_DIRECTORY "${_exported_include_dir}")
      message(WARNING "Package 'octomap_msgs' exports the include directory '${_exported_include_dir}' which doesn't exist")
    endif()
    normalize_path(_exported_include_dir "${_exported_include_dir}")
    list(APPEND octomap_msgs_INCLUDE_DIRS "${_exported_include_dir}")
  endforeach()
endif()

If octomap_msgs_DIR is where this CMake file exists, then the relative directory ../../../include/octomap_msgs does lead to the headers

[Levi-Armstrong]

If you print out ${octomap_msgs_INCLUDE_DIRS} is it empty?

[rjoomen]

This is weird, as unstable on Humble does work

[marip8]

@Levi-Armstrong are you wanting to change CI for this repo to use colcon-action? If so, it's probably worth baking that change into this PR and seeing if that fixes the strange humble build issue

[Levi-Armstrong]

Sure, I think it would be good to get everything moved to use the colcon-action.

[marip8]

Looks like the issue with foxy is that rosdep is not pulling info since foxy is EOL. I opened a PR against colcon-action to add information for EOL distros to solve this.

As far as the octomap_msgs/conversions.h issue goes, it appears that in humble and rolling, this file is install to /opt/ros/<distro>/include/octomap_msgs, but there is also another nested octomap_msgs directory at /opt/ros/<distro>/include/octomap_msgs/octomap_msgs that includes the message and service definitions. I can get a successful build in humble if I use #include <octomap_msgs/../conversions.h. This seems incorrect, and I still don't understand why it fails in humble but succeeds in rolling when their header install setups are the same.

Here is the content of ${octomap_msgs_INCLUDE_DIRS} in a humble docker for reference:

/opt/ros/humble/include/std_msgs;/opt/ros/humble/include/geometry_msgs;/opt/ros/humble/include/rosidl_runtime_c;/opt/ros/humble/include/rosidl_typesupport_interface;/opt/ros/humble/include/rcutils;/opt/ros/humble/include/rosidl_runtime_cpp;/opt/ros/humble/include/rosidl_typesupport_fastrtps_c;/opt/ros/humble/include/rosidl_typesupport_fastrtps_cpp;/opt/ros/humble/include/rosidl_typesupport_c;/opt/ros/humble/include/rmw;/opt/ros/humble/include/rosidl_typesupport_cpp;/opt/ros/humble/include/rcpputils;/opt/ros/humble/include/rosidl_typesupport_introspection_c;/opt/ros/humble/include/rosidl_typesupport_introspection_cpp;/opt/ros/humble/include/octomap_msgs

Someone posted about this same issue here recently, but I wasn't able to follow their solution to get a successful build.

There has also been a PR on octomap_msgs that changes the header install directory, but it's unclear whether this was included in the current debian package (v2.0.0)

[Levi-Armstrong]

I would look at adding the same headers and find_packages in the CMakeLists.txt along with making sure you are linking with the same targets shown in link you provide that said it fixed the issue.

#include <octomap/octomap.h>
#include <octomap_msgs/conversions.h>
#include <octomap_msgs/msg/octomap.hpp>

[Levi-Armstrong]

@marip8 I created a new tag release v5 with your changes for colcon-action

[marip8]

It appears that calling ament_target_dependencies(${PROJECT_NAME} PUBLIC octomap_server) allows the header to be found. Targeting octomap_msgs does not work, and neither does target_link_libraries(... ${octomap_server_TARGETS}). This doesn't seem like a great solution though. I think a better work around is to build the latest version of octomap_msgs from source for Humble on (which results in a successful build) until they release the latest version to the build farm. I'll open an issue there about it

[marip8]

This seems to be working correctly now and is ready for review. The only unresolved issue is now the clang-tidy build. It seems to be failing on something within rclcpp and within boost. Is there a way to prevent files from those projects from being checked?

[Levi-Armstrong]

This seems to be working correctly now and is ready for review. The only unresolved issue is now the clang-tidy build. It seems to be failing on something within rclcpp and within boost. Is there a way to prevent files from those projects from being checked?

I would add a .clang-tidy file from tesseract_planning and add the following to the end of the file.

ExtraArgs:
  - '-std=c++17'

[marip8]

There appear to be a lot of unaddressed clang-tidy issues in this repo (at least with the configuration added from tesseract_planning). I think it's outside the scope of this PR to address all of those here, so I would propose addressing them in a separate PR

[rjoomen]

I don't understand the issue with octomap_msgs. I'm on Humble and have no such problems.

[marip8]

I don't understand the issue with octomap_msgs. I'm on Humble and have no such problems.

I can't explain why this only seems to happen in the Docker image. It seems like it should happen to everyone. But here is my understanding of this particular issue:

The include directory for octomap_msgs 2.0.0 (defined in /opt/ros/humble/share/octomap_msgs/cmake/ament_cmake_export_include_directories-extras.cmake) is ${octomap_msgs_DIR}/../../../include/octomap_msgs, which resolves to /opt/ros/humble/include/octomap_msgs. That directory looks like this:

| /opt/ros/humble/include/octomap_msgs
   | conversions.h
   | octomap_msgs
       | msg
       | srv

This means that if you want to include conversions.h you need to call #include <conversions.h> or #include <octomap_msgs/../conversions.h>.

The latest version of octomap_msgs installs conversions.h in the following way that resolves the issue.

 | /opt/ros/humble/include/octomap_msgs
    | octomap_msgs
        | conversions.h
        | msg
        | srv

[marip8]

Any concerns about this approach now that it's working? I would like to get this merged, so I can proceed to add the Docker files/build job and propagate that to scan_and_plan_workshop