Ocena obrazu ROS 2

Funkcja ros2 to hook buildu skierowany na Ubuntu. Listy pakietów w rejestrze są puste, ponieważ hook przejmuje konfigurację repozytorium i pakietów. Przed buildem przejrzyj wygenerowane źródła i wybraną dystrybucję ROS; sama nazwa funkcji nie przypina obsługiwanej wersji ROS.

Używaj oddzielnych artefaktów dla środowiska deweloperskiego na desktopie i runtime robota. Udostępniaj jawne wersje źródeł i pakietów, a nie zmienną konfigurację “latest”.

Prompt deweloperski

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 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.

Granica receptury

Znormalizowana receptura runtime powinna jawnie określać base, feature, pakiety natywne, konto serwisowe i scenariusze:

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

Członkostwo w grupie daje tylko uprawnienia Unix tam, gdzie istnieją pasujące urządzenia i reguły. Nie dowodzi to, że adapter szeregowy, kamera, kontroler GPIO, magistrala I2C lub robot są obecne albo bezpieczne do sterowania.

Wirtualne dowody

Przydatne kontrole gościa obejmują:

• pliki konfiguracji środowiska ROS i inwentarz pakietów;
• uruchomienie CLI ros2;
• dwa węzły testowe wymieniające unikalną syntetyczną wiadomość przez wybraną implementację RMW;
• start usługi, restart, awarię i czyste zamknięcie;
• tożsamość procesu i uprawnienia plików; oraz
• brak nieżądanego ekspozycji sieciowej.

Sam ros2 topic list to niepełny test discovery DDS. Użyj oddzielnych procesów publikatora i subskrybenta albo maszyn wirtualnych i zweryfikuj treść wiadomości oraz timeout.

Kwalifikacja po stronie robota

Powtórz pakiet akceptacyjny na dokładnie tym samym module obliczeniowym, jądrze, konfiguracji middleware, sieci, czujnikach, siłownikach i obciążeniu czasowym. Zmierz opóźnienie i zachowanie terminów z zamierzonym jądrem czasu rzeczywistego, jeśli jest wymagane. Zweryfikuj zatrzymanie awaryjne, watchdog, tryb obniżony i bezpieczne wyłączenie poza ogólnym środowiskiem KVM OpenFactory.