wzyn20051216/ros-robotics-skill

ROS Robotik

Wann verwenden

Verwenden Sie diesen Skill, wenn die Anfrage des Benutzers eines der folgenden Themen betrifft:

• catkin_ws, colcon_ws, src/CMakeLists.txt, package.xml, setup.py
• Neu erstellen, portieren, bauen, testen, debuggen von ROS 1 / ROS 2 Paketen
• launch / launch.py, Parameter YAML, URDF/Xacro, RViz, TF
• topic / service / action / msg / srv / QoS
• Fahrwerk, IMU, LiDAR, Kamera, Lokalisierung, SLAM, Navigation2, ros2_control
• Gazebo / Ignition Simulation, Sensor-Simulation, ros_gz_bridge
• Docker-Containerisierte ROS-Entwicklung, docker-compose Multi-Node-Orchestrierung
• Lifecycle-Knoten, rclcpp_components Komponenten, prozessinterne Kommunikation
• rosbag2 Aufzeichnung/ Wiedergabe, mcap, Offline-Diagnose
• SLAM-Kartenerstellung (Cartographer, SLAM Toolbox, ORB-SLAM)
• DDS / QoS-Konfiguration, ROS_DOMAIN_ID, RMW-Auswahl, Multi-Machine-Netzwerk
• Benutzerdefinierte msg / srv / action Schnittstellendefinition und -generierung
• Multi-Roboter-Systeme, Namespace-Isolation, Cross-Machine-Kommunikation
• MoveIt 2 Bewegungsplanung, SRDF, Kinematik-Plugins
• ROS 2 CI/CD (GitHub Actions, colcon test, ament_lint)
• Foxglove Studio / PlotJuggler Datenvisualisierung und Offline-Analyse
• MCU / RTOS / UART / CAN / micro-ROS Kollaborative Entwicklung

Was zuerst tun

1. Arbeitsbereich identifizieren

python scripts/detect_ros_workspace.py <workspace-path>

2. Konsistenzprüfung durchführen

python scripts/check_ros_workspace_consistency.py <workspace-path>

3. Minimal notwendige Dokumente basierend auf Problem laden

• ROS 1: references/ros1-catkin.md
• ROS 2: references/ros2-colcon.md
• Hybrid / Migration: references/interop-and-migration.md
• Modell / TF: references/robot-description-and-tf.md
• Navigation: references/navigation2.md
• Steuerung: references/ros2-control.md
• Eingebettet: references/micro-ros-and-embedded.md
• Simulation: references/gazebo-simulation.md
• Lifecycle / Komponenten: references/lifecycle-and-components.md
• DDS / QoS / Netzwerk: references/dds-qos-networking.md
• Aufzeichnung / Wiedergabe / Diagnose: references/rosbag-diagnostics.md
• SLAM / Kartenerstellung: references/slam-mapping.md
• Docker: references/docker-ros.md
• Benutzerdefinierte Schnittstellen: references/custom-interfaces.md
• Multi-Roboter: references/multi-robot.md
• MoveIt 2: references/moveit2.md
• CI/CD: references/ros2-cicd.md
• Visualisierung: references/foxglove-visualization.md
• Fehlerbehebung: references/debug-playbooks.md
• Überprüfung: references/review-checklist.md

Grundsätze, die beachtet werden müssen

• Zuerst das Build-System identifizieren, dann Code ändern
• Zuerst package.xml / CMakeLists.txt Konsistenz reparieren, dann über Refactoring sprechen
• Zuerst TF, Zeitstempel, Frame, Einheiten prüfen, dann Algorithmen beschuldigen
• Zuerst Beweiskette, dann Änderungen: Build-Ausgabe, Topic, TF, Parameter, Logs müssen überprüfbar sein
• ROS 1 → ROS 2 zuerst überbrücken oder schrittweise migrieren, nicht auf einmal umwerfen
• MCU / micro-ROS zuerst beurteilen, ob der Eintritt in den ROS-Graphen wirklich nötig ist

Häufige Aufgabenbehandlung

Neues Paket hinzufügen oder reparieren

• Pakettyp bestimmen: catkin, ament_cmake, ament_python
• Zuerst Abhängigkeitsdeklaration ergänzen, dann Build-Logik, dann Installationsregeln
• Benutzerdefinierte msg / srv / action: Priorität auf Generierungsreihenfolge und Abhängigkeitsschleifen prüfen (Details in references/custom-interfaces.md)

Build-Fehler

• Zuerst rosdep ausführen
• Dann package.xml mit Build-Skripten abgleichen
• Dann prüfen, ob die Umgebung korrekt gesourct wurde
• Dann Systemabhängigkeiten, ABI, Distributionskompatibilität prüfen

Läuft normal, aber Roboter verhält sich falsch

• Zuerst launch, namespace, remap, Parameter prüfen
• Dann Topic-Namen, Frequenz, Zeitstempel, Einheiten, frame_id prüfen
• Dann prüfen, ob TF eine einzelne Wurzel hat, statisch / dynamisch klar getrennt sind
• Zuletzt Algorithmus selbst hinterfragen

Nav2 / ros2_control

• Navigation2: zuerst /cmd_vel-Kette, Lokalisierungsqualität, Steuerfrequenz und Fahrwerkeinheiten prüfen
• ros2_control: zuerst Hardware-Schnittstellentypen, Controller-YAML, Lese-/Schreibzyklus und aktiven Status prüfen

MCU / micro-ROS

• Zuerst beurteilen, ob die Bridge-Knoten auf der Linux-Seite ausreichen
• Nur wenn MCU in den ROS 2-Graphen eintreten muss, dann micro-ROS in Betracht ziehen
• Byte-Reihenfolge, Prüfsummen, Timeout, Wiederverbindung, Zeitquelle und Verbindungsverlustschutz strikt prüfen

Antipattern

• Mischen von catkin und ament im selben Paket
• Nur CMakeLists.txt ändern, aber nicht package.xml
• TF, Zeitstempel, Einheiten, Koordinatenachsdefinitionen ignorieren
• Treiber, Protokolle, Filter, Steuerung und Diagnose alle in einen großen Knoten packen
• Bei Migration ROS 1 → ROS 2 nur API ersetzen, ohne Systemvalidierung durchzuführen

Ausgabeanforderungen

Bei Verwendung dieses Skills zur Aufgabenbearbeitung priorisieren Sie die Ausgabe von:

1. Aktueller Arbeitsbereich und Pakettyp-Bestimmung
2. Wichtige Begründungen und Annahmen
3. Änderungspunkte und Gründe
4. Minimale Build-/Test-/Run-Befehle
5. Risikopunkte und Regression-Checkpoints