Évaluation d’image ROS 2

La fonctionnalité ros2 est un hook de build orienté Ubuntu. Ses listes de paquets dans le registre sont vides car le hook possède la configuration dépôt et paquets. Relisez les sources générées et la distribution ROS sélectionnée avant le build ; le nom de fonctionnalité seul n’épingle pas une version ROS supportée.

Utilisez des artefacts séparés pour un environnement de développement bureau et un runtime robot. Partagez versions explicites de sources et paquets, pas une configuration « latest » mutable.

Invite développement

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.

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

Frontière de recette

Une recette runtime normalisée doit rendre explicites la base, la fonctionnalité, les paquets natifs, le compte de service et les scénarios :

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

L’appartenance à un groupe n’accorde une permission Unix que là où périphériques et règles correspondants existent. Cela ne prouve pas qu’un adaptateur série, une caméra, un contrôleur GPIO, un bus I2C ou un robot est présent ou sûr à commander.

Preuves virtuelles

Les vérifications invité utiles incluent :

• fichiers de configuration d’environnement ROS et inventaire des paquets ;
• démarrage CLI ros2 ;
• deux nœuds de test échangeant un message synthétique unique via l’implémentation RMW sélectionnée ;
• démarrage, redémarrage, échec et arrêt propre du service ;
• identité de processus et permissions de fichiers ; et
• absence d’exposition réseau non demandée.

ros2 topic list seul n’est pas un test de découverte DDS complet. Utilisez des processus ou VM publisher et subscriber séparés et vérifiez le contenu du message et le délai.

Qualification côté robot

Répétez la suite d’acceptation sur le module de calcul exact, le noyau, la configuration middleware, le réseau, les capteurs, actionneurs et la charge temporelle. Mesurez latence et respect des échéances avec le noyau temps réel voulu si l’un est requis. Validez arrêt d’urgence, watchdog, mode dégradé et arrêt sûr en dehors de l’environnement KVM générique d’OpenFactory.