Evaluación de imagen ROS 2

La feature ros2 es un hook de compilación orientado a Ubuntu. Sus listas de paquetes en el registro están vacías porque el hook es dueño de la configuración de repositorio y paquetes. Revisa las fuentes generadas y la distribución ROS seleccionada antes de compilar; el nombre de la feature solo no fija una versión ROS admitida.

Usa artefactos separados para entorno de desarrollo de escritorio y runtime en robot. Comparte versiones explícitas de fuente y paquete, no una configuración «latest» mutable.

Prompt de desarrollo


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.

Prompt de runtime


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.

Límite de la receta

Una receta de runtime normalizada debe hacer explícitos la base, feature, paquetes nativos, cuenta de servicio y escenarios:


{
  "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"
      }
    ]
  }
}

La pertenencia a grupos concede solo permiso Unix donde existen dispositivos y reglas coincidentes. No prueba que haya un adaptador serial, cámara, controlador GPIO, bus I2C o robot presente o seguro de mandar.

Evidencia virtual

Comprobaciones útiles en guest incluyen:

archivos de configuración del entorno ROS e inventario de paquetes;
arranque del CLI ros2;
dos nodos de prueba intercambiando un mensaje sintético único mediante la implementación RMW seleccionada;
inicio, reinicio, fallo y apagado limpio del servicio;
identidad de proceso y permisos de archivo; y
ausencia de exposición de red no solicitada.

ros2 topic list solo no es una prueba completa de descubrimiento DDS. Usa procesos o VM separados de publicador y suscriptor y verifica contenido del mensaje y timeout.

Calificación en el robot

Repite la suite de aceptación en el módulo de cómputo, kernel, configuración de middleware, red, sensores, actuadores y carga de timing exactos. Mide latencia y comportamiento de deadline con el kernel de tiempo real previsto si se requiere uno. Valida parada de emergencia, watchdog, modo degradado y apagado seguro fuera del entorno KVM genérico de OpenFactory.