Bsb/lyrical jetty build by bsb808 · Pull Request #889 · osrf/vrx

bsb808 · 2026-07-08T21:20:43Z

Symptom

Building gz_waves_rendering on ROS 2 Lyrical + Gazebo Jetty fails at CMake configure:

CMake Error at CMakeLists.txt:48 (message):
  OgreRoot.h not found under /usr/include/OGRE-2.3 (probed from
  gz-rendering::ogre2 = _gz_rend_ogre2_lib-NOTFOUND).

The package never compiles; the FFT/Gerstner providers building in parallel get aborted with it.

Explanation

No consistent dev environment for the target stack. The wave packages target ROS 2 Lyrical + Gazebo Jetty
Brittle, hardcoded Ogre-Next header discovery. gz_waves_rendering/CMakeLists.txt locates the Ogre-Next headers by reading gz-rendering::ogre2's LOCATION property and regex-matching a /opt/ros// path, else falling back to a hardcoded /usr/include/OGRE-2.3. For an imported/interface target LOCATION is empty, so the regex never matches and it drops to the hardcoded fallback — which does not exist on Jetty (newer Ogre-Next).
Multiple OgreRoot.h in the environment. The Jetty container ships three, only one of which is Ogre-Next:

/opt/ros/lyrical/opt/rviz_ogre_vendor/include/OGRE/OgreRoot.h          # classic Ogre 1.x (rviz)
/usr/include/OGRE/OgreRoot.h                                           # classic Ogre 1.x (system)
/opt/ros/lyrical/opt/gz_ogre_next_vendor/include/OGRE-Next/OgreRoot.h

A naive path guess can miss the right header or grab an incompatible classic-Ogre one — the detection only ever worked on the single environment it was written for.

Proposed fix

a) Robust header discovery. Replace the LOCATION probe with a find_path for OgreRoot.h, seeded by the ogre2 target's own INTERFACE_INCLUDE_DIRECTORIES, with PATH_SUFFIXES limited to Ogre-Next dirs (OGRE-Next, OGRE-2.4, OGRE-2.3) so classic Ogre 1.x is never selected. Version-agnostic across Harmonic, Jetty, ROS-vendor, and system installs.

b) A Lyrical/Jetty dev container via Docker compose:

Test / Verify

# 1. Build the Lyrical/Jetty dev image
cd ~/vrx_ws/src/vrx
./docker/build.bash docker lyrical            # -> vrx_dev:lyrical

# 2. Interactive dev container (GPU + X11 + home mount)
./docker/run_compose.bash                     # drops into bash in the container

# 3. Inside the container: build the wave stack
cd ~/vrx_ws
rm -rf build install log
colcon build --merge-install

# 4. Run the sim (EncinoWaves ocean, GPU-rendered)
source install/setup.bash
ros2 launch vrx_bringup simulation.launch.xml

The previous CMake read gz-rendering::ogre2's LOCATION to guess the Ogre-Next include dir, falling back to a hardcoded /usr/include/OGRE-2.3. LOCATION is empty for imported/interface targets (NOTFOUND on the ROS gz vendor + Gazebo Jetty), so configure dropped to the wrong fallback and failed with "OgreRoot.h not found". Replace it with a find_path seeded by the ogre2 target's INTERFACE_INCLUDE_DIRECTORIES, with PATH_SUFFIXES limited to Ogre-Next dirs so classic Ogre 1.x is never selected. Version-agnostic across Harmonic, Jetty, ROS-vendor, and system installs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Brian Bingham <briansbingham@gmail.com>

The existing osrf/vrx-devel image is Jazzy/Harmonic; add a reproducible ROS 2 Lyrical + Gazebo Jetty environment. Modernized Dockerfile on ros:lyrical-ros-base installs the real ros-lyrical-gz-*-vendor packages (dropping the legacy fake-vendor / build-ros_gz-from-source workaround). Adds a Docker Compose workflow (compose.yaml + run_compose.bash) for a GPU + X11 + home-mounted interactive dev container that also sidesteps rocker's hardcoded Ubuntu list (rocker refuses 26.04). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Brian Bingham <briansbingham@gmail.com>

caguero · 2026-07-09T09:28:04Z

In my case the sky doesn't render correctly within the container.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Signed-off-by: Carlos Aguero <caguero@honurobotics.com>

caguero · 2026-07-09T21:08:57Z

In my case the sky doesn't render correctly within the container.

It should be fixed in 9341308

caguero

A few more comments inline. It would also be nice to eventually add a CI job that builds this image and compiles gz_waves_rendering inside it, so Lyrical and Jetty breakage shows up early.

caguero · 2026-07-23T20:22:29Z

+find_path(OGRE_NEXT_INCLUDE_DIR
+  NAMES OgreRoot.h
+  HINTS ${_ogre2_incs}
+  PATHS
+    /opt/ros/$ENV{ROS_DISTRO}/opt/gz_ogre_next_vendor/include
+    /usr/include
+  PATH_SUFFIXES OGRE-Next OGRE-2.4 OGRE-2.3
+)


find_path checks the standard system paths before these PATHS, so on a host with both libogre-next-dev and gz_ogre_next_vendor it can pick the mismatched /usr/include copy and silently reintroduce the slow Hlms path. Consider a first pass with NO_DEFAULT_PATH so the vendor headers win, then a plain fallback.

caguero · 2026-07-23T20:22:29Z

+    /usr/include
+  PATH_SUFFIXES OGRE-Next OGRE-2.4 OGRE-2.3
+)
+if(NOT OGRE_NEXT_INCLUDE_DIR)


find_path reuses a stale cached value even if the path no longer exists, so keeping the old EXISTS check on OgreRoot.h would still catch that case.

caguero · 2026-07-23T20:22:29Z

+#
+# Manually:
+#   xhost +SI:localuser:$(id -un)    # let the container reach your X server (once per login)
+#   cd ~/WorkingCopies/oceansim/vrx_ws/src/vrx


This personal path is still here. Maybe something generic like cd <your vrx_ws>/src/vrx.

caguero · 2026-07-23T20:22:30Z

+# NVIDIA reservation refuses to start the container on a host without an NVIDIA
+# GPU, so only layer the overlay in when nvidia-smi actually reports one.
+compose_files=(-f "${SCRIPT_DIR}/compose.yaml")
+if command -v nvidia-smi >/dev/null 2>&1 && nvidia-smi -L >/dev/null 2>&1; then


If the driver is present but the nvidia container toolkit is not, compose fails to start instead of falling back to the iGPU. Maybe also check docker info for the nvidia runtime.

caguero · 2026-07-23T20:22:30Z

@@ -0,0 +1,45 @@
+#!/usr/bin/env bash


build.bash carries the Apache header but this script does not. Should we add it for consistentcy?

caguero · 2026-07-23T20:22:30Z

+docker build --rm -t "$image_plus_tag" -f "${context}/Dockerfile" "${context}" && \
+docker tag "$image_plus_tag" "$image_name:$distro" && \
+echo "Built $image_plus_tag and tagged as $image_name:$distro" && \
+echo "To run:  ./docker/run_compose.bash"


Missing newline at end of file.

caguero · 2026-07-23T20:22:30Z

+# NOTE: nav2 (navigation2, nav2-bringup, nav2-minimal-*) is intentionally
+# omitted — it is often not yet released early in a new distro's life. Add
+# ros-${ROS_DISTRO}-navigation2 etc. once available on Lyrical.
+RUN apt-get update \


This list can drift from our package.xml files over time. Maybe generate it with rosdep or note rosdep as the source of truth.

caguero · 2026-07-23T20:22:30Z

+ && apt-get install -y --no-install-recommends \
+      atop expect gdb gnutls-bin iputils-ping libbluetooth-dev libcwiid-dev \
+      net-tools python3-dbg python3-pip python3-venv vim wget xvfb \
+ && dpkg --add-architecture i386 \


Do we need the i386 GL libs? Nothing in VRX is 32 bit, so this block could probably go.

caguero · 2026-07-23T20:22:30Z

+RUN echo "source /opt/ros/${ROS_DISTRO}/setup.bash" > /etc/profile.d/ros.sh \
+ && chmod +x /etc/profile.d/ros.sh \
+ && echo "source /etc/profile.d/ros.sh" >> /etc/bash.bashrc
+ENV BASH_ENV=/etc/profile.d/ros.sh


Heads up: BASH_ENV makes every noninteractive bash source the ROS setup, which can surprise scripts that use set -u.

bsb808 and others added 2 commits July 8, 2026 14:14

bsb808 requested a review from caguero July 8, 2026 22:42