ROS 2 image evaluation

The ros2 feature is an Ubuntu-oriented build hook. Its registry package lists are empty because the hook owns repository and package setup. Review the generated sources and selected ROS distribution before building; the feature name alone does not pin a supported ROS release.

Use separate artifacts for a desktop development environment and a robot runtime. Share explicit source and package versions, not a mutable “latest” configuration.

Development prompt

Create an Ubuntu 24.04 GNOME ROS 2 development image. Request ROS 2 Jazzy,
RViz, the required build tools, Git, Python, C++, and a non-password account
named robot in only the groups needed for the virtual test. Show the exact ROS
repository, signing key, package names, and versions in the plan. Add a clean
environment-source test and a two-node DDS discovery test using synthetic data.

Runtime prompt

Create an Ubuntu 24.04 headless ROS 2 runtime evaluation image with SSH and the
minimum ROS packages required by my reviewed launch file. Install the launch
file through a versioned package, run it as an unprivileged robot account, and
add bounded service, publish/subscribe, restart, and shutdown tests. Do not
claim PREEMPT_RT or physical peripheral support unless the exact kernel and
hardware are tested.

Recipe boundary

A normalized runtime recipe should make the base, feature, native packages, service account, and scenarios explicit:

{
  "name": "ros2-runtime-evaluation",
  "base_image": "ubuntu-24.04",
  "os": {
    "features": ["headless", "ssh", "ros2"],
    "packages": ["ros-jazzy-ros-base", "ros-jazzy-sensor-msgs"],
    "users": [
      {
        "username": "robot",
        "groups": ["dialout", "video"],
        "shell": "/bin/bash"
      }
    ]
  }
}

Group membership grants only Unix permission where matching devices and rules exist. It does not prove that a serial adapter, camera, GPIO controller, I2C bus, or robot is present or safe to command.

Virtual evidence

Useful guest checks include:

• ROS environment setup files and package inventory;
• ros2 CLI startup;
• two test nodes exchanging a unique synthetic message through the selected RMW implementation;
• service start, restart, failure, and clean shutdown;
• process identity and file permissions; and
• absence of unrequested network exposure.

ros2 topic list alone is not a complete DDS discovery test. Use separate publisher and subscriber processes or VMs and verify the message content and timeout.

Robot-side qualification

Repeat the acceptance suite on the exact compute module, kernel, middleware configuration, network, sensors, actuators, and timing load. Measure latency and deadline behavior with the intended real-time kernel if one is required. Validate emergency stop, watchdog, degraded-mode, and safe-shutdown behavior outside OpenFactory’s generic KVM environment.