Оцінка образу ROS 2

Feature ros2 , Ubuntu-oriented build hook. Registry package lists empty because hook owns repository and package setup. Review generated sources and selected ROS distribution before building; feature name alone does not pin supported ROS release.

Use separate artifacts for desktop development environment and robot runtime. Share explicit source and package versions, not 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

Normalized runtime recipe should make base, feature, native packages, service account, 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 serial adapter, camera, GPIO controller, I2C bus, or robot 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 unique synthetic message through selected RMW implementation;
service start, restart, failure, clean shutdown;
process identity and file permissions; and
absence of unrequested network exposure.

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

Robot-side qualification

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