ROS-2-Image-Evaluierung

Das Feature ros2 ist ein Ubuntu-orientierter Build-Hook. Registry-Paketlisten sind leer, weil der Hook Repository- und Paket-Setup besitzt. Prüfen Sie erzeugte Quellen und gewählte ROS-Distribution vor dem Build; der Feature-Name allein pinnt kein unterstütztes ROS-Release.

Nutzen Sie getrennte Artefakte für Desktop-Entwicklungsumgebung und Robot-Runtime. Teilen Sie explizite Source- und Paketversionen, keine mutable „latest“-Konfiguration.

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.

Rezept-Grenze

Ein normalisiertes Runtime-Rezept soll Base, Feature, native Pakete, Service-Account und Szenarien explizit machen:

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

Gruppenmitgliedschaft gewährt nur Unix-Berechtigung, wo passende Devices und Regeln existieren. Sie beweist nicht, dass Serial-Adapter, Kamera, GPIO-Controller, I2C-Bus oder Robot vorhanden oder sicher ansteuerbar sind.

Virtueller Nachweis

Nützliche Gast-Checks:

• ROS-Environment-Setup-Dateien und Paketinventar;
• ros2-CLI-Start;
• zwei Test-Nodes tauschen eine eindeutige synthetische Message über die gewählte RMW-Implementierung;
• Service-Start, Restart, Failure und sauberes Shutdown;
• Prozess-Identität und Dateiberechtigungen; und
• Fehlen ungeforderten Netzwerk-Exposure.

ros2 topic list allein ist kein vollständiger DDS-Discovery-Test. Nutzen Sie getrennte Publisher- und Subscriber-Prozesse oder VMs und prüfen Sie Message-Inhalt und Timeout.

Robot-seitige Qualifikation

Wiederholen Sie die Abnahme-Suite auf exakt dem Compute-Modul, Kernel, Middleware-Konfiguration, Netzwerk, Sensoren, Aktoren und Timing-Last. Messen Sie Latenz und Deadline-Verhalten mit dem beabsichtigten Real-Time-Kernel, falls einer nötig ist. Validieren Sie Not-Aus, Watchdog, Degraded-Mode und Safe-Shutdown außerhalb von OpenFactorys generischer KVM-Umgebung.