wzyn20051216/ros-robotics-skill

Robotique ROS

Quand utiliser

Utilisez cette compétence lorsque la demande de l'utilisateur concerne l'un des sujets suivants :

• catkin_ws, colcon_ws, src/CMakeLists.txt, package.xml, setup.py
• Nouveau package ROS 1 / ROS 2, portage, construction, test, débogage
• launch / launch.py, paramètres YAML, URDF/Xacro, RViz, TF
• topic / service / action / msg / srv / QoS
• Châssis, IMU, LiDAR, caméra, localisation, SLAM, Navigation2, ros2_control
• Simulation Gazebo / Ignition, simulation de capteurs, ros_gz_bridge
• Développement ROS conteneurisé avec Docker, orchestration multi-nœuds avec docker-compose
• Nœuds Lifecycle, composants rclcpp_components, communication intra-processus
• Enregistrement et relecture avec rosbag2, mcap, diagnostic hors ligne
• Cartographie SLAM (Cartographer, SLAM Toolbox, ORB-SLAM)
• Configuration DDS / QoS, ROS_DOMAIN_ID, choix du RMW, réseau multi-machine
• Définition et génération d'interfaces personnalisées msg / srv / action
• Systèmes multi-robots, isolation par espace de noms, communication inter-machine
• Planification de mouvement MoveIt 2, SRDF, plugins de cinématique
• CI/CD ROS 2 (GitHub Actions, colcon test, ament_lint)
• Visualisation de données et analyse hors ligne avec Foxglove Studio / PlotJuggler
• Développement collaboratif MCU / RTOS / UART / CAN / micro-ROS

Que faire en premier

1. Identifier l'espace de travail

python scripts/detect_ros_workspace.py <chemin-espace-de-travail>

2. Effectuer une vérification de cohérence

python scripts/check_ros_workspace_consistency.py <chemin-espace-de-travail>

3. Charger la documentation minimale nécessaire selon le problème

• ROS 1 : references/ros1-catkin.md
• ROS 2 : references/ros2-colcon.md
• Hybride / Migration : references/interop-and-migration.md
• Modèle / TF : references/robot-description-and-tf.md
• Navigation : references/navigation2.md
• Contrôle : references/ros2-control.md
• Embarqué : references/micro-ros-and-embedded.md
• Simulation : references/gazebo-simulation.md
• Lifecycle / Composants : references/lifecycle-and-components.md
• DDS / QoS / Réseau : references/dds-qos-networking.md
• Enregistrement/relecture / Diagnostic : references/rosbag-diagnostics.md
• SLAM / Cartographie : references/slam-mapping.md
• Docker : references/docker-ros.md
• Interfaces personnalisées : references/custom-interfaces.md
• Multi-robots : references/multi-robot.md
• MoveIt 2 : references/moveit2.md
• CI/CD : references/ros2-cicd.md
• Visualisation : references/foxglove-visualization.md
• Dépannage : references/debug-playbooks.md
• Revue : references/review-checklist.md

Principes à respecter impérativement

• Identifier d'abord le système de construction, puis modifier le code
• Corriger d'abord la cohérence de package.xml / CMakeLists.txt, ensuite envisager la refactorisation
• Vérifier d'abord TF, les timestamps, les repères (frames) et les unités, avant d'incriminer l'algorithme
• Privilégier d'abord la chaîne de preuves, puis les modifications : la sortie de construction, les topics, TF, les paramètres et les journaux doivent être vérifiables
• Pour ROS 1 → ROS 2, passer d'abord par un pont ou une couche intermédiaire, ne pas tout réécrire d'un coup
• Pour MCU / micro-ROS, déterminer d'abord s'il est vraiment nécessaire d'entrer dans le graphe ROS

Approches pour les tâches courantes

Ajouter ou réparer un package

• Déterminer d'abord le type de package : catkin, ament_cmake, ament_python
• Ajouter d'abord la déclaration des dépendances, puis la logique de construction, puis les règles d'installation
• Pour les msg / srv / action personnalisés, vérifier en priorité l'ordre de génération et les dépendances circulaires (voir references/custom-interfaces.md)

Échec de construction

• Exécuter d'abord rosdep
• Vérifier ensuite la cohérence de package.xml avec les scripts de construction
• Vérifier ensuite si l'environnement est correctement sourcé
• Vérifier enfin les dépendances système, l'ABI et la compatibilité de distribution

Fonctionnement normal mais comportement incorrect du robot

• Vérifier d'abord le launch, l'espace de noms, le remappage et les paramètres
• Vérifier ensuite les noms de topics, la fréquence, les timestamps, les unités et frame_id
• Vérifier ensuite si l'arbre TF est unique (racine unique), si les TF statiques/dynamiques sont bien distinguées
• Enfin, remettre en doute l'algorithme lui-même

Nav2 / ros2_control

• Pour Navigation2, prioriser la vérification de la chaîne /cmd_vel, la qualité de la localisation, la fréquence de contrôle et les unités du châssis
• Pour ros2_control, prioriser la vérification du type d'interface matérielle, du fichier YAML du contrôleur, du cycle de lecture/écriture et de l'état actif

MCU / micro-ROS

• Déterminer d'abord si le nœud de pont côté Linux est suffisant
• Si le MCU doit vraiment entrer dans le graphe ROS 2, alors envisager micro-ROS
• Vérifier rigoureusement l'ordre des octets (endianness), les checksums, les timeouts, les reconnexions, la source de temps et la protection contre les déconnexions

Anti-patrons

• Mélanger catkin et ament dans le même package
• Modifier uniquement CMakeLists.txt sans mettre à jour package.xml
• Ignorer TF, les timestamps, les unités et les définitions des axes de coordonnées
• Fourrer le pilote, le protocole, le filtrage, le contrôle et le diagnostic dans un seul et gros nœud
• Lors de la migration ROS 1 → ROS 2, se contenter de remplacer l'API sans effectuer de validation système

Exigences de sortie

Lors du traitement d'une tâche avec cette compétence, privilégier la sortie suivante :

1. Identification de l'espace de travail actuel et du type de package
2. Éléments clés et hypothèses
3. Points de modification et raisons
4. Commandes minimales de construction / test / exécution
5. Points de risque et points de contrôle de régression