ROS Robotics
使用するタイミング
ユーザーが次のいずれかのトピックに関する要求を行った場合に、このスキルを使用します。
catkin_ws、colcon_ws、src/CMakeLists.txt、package.xml、setup.py- ROS 1 / ROS 2 パッケージの新規作成、移植、ビルド、テスト、デバッグ
launch/launch.py、パラメータ YAML、URDF/Xacro、RViz、TFtopic/service/action/msg/srv/QoS- 車台、IMU、LiDAR、カメラ、ローカリゼーション、SLAM、Navigation2、
ros2_control - Gazebo / Ignition シミュレーション、センサーシミュレーション、
ros_gz_bridge - Docker コンテナ化 ROS 開発、
docker-composeマルチノードオーケストレーション - Lifecycle ノード、
rclcpp_componentsコンポーネント化、プロセス内通信 rosbag2録音再生、mcap、オフライン診断- SLAM マッピング（Cartographer、SLAM Toolbox、ORB-SLAM）
- DDS / QoS 設定、
ROS_DOMAIN_ID、RMW 選択、マルチマシンネットワーク - カスタム
msg/srv/actionインターフェース定義と生成 - マルチロボットシステム、名前空間分離、マシン間通信
- MoveIt 2 運動計画、SRDF、運動学プラグイン
- ROS 2 CI/CD（GitHub Actions、colcon test、ament_lint）
- Foxglove Studio / PlotJuggler データ可視化とオフライン分析
- MCU / RTOS / UART / CAN /
micro-ROS協調開発
最初に行うこと
1. ワークスペースを特定する
python scripts/detect_ros_workspace.py <workspace-path>
2. 整合性チェックを実行する
python scripts/check_ros_workspace_consistency.py <workspace-path>
3. 問題に応じて必要な最小限のドキュメントを読み込む
- ROS 1：
references/ros1-catkin.md - ROS 2：
references/ros2-colcon.md - ハイブリッド / 移行：
references/interop-and-migration.md - モデル / TF：
references/robot-description-and-tf.md - ナビゲーション：
references/navigation2.md - 制御：
references/ros2-control.md - 組み込み：
references/micro-ros-and-embedded.md - シミュレーション：
references/gazebo-simulation.md - Lifecycle / コンポーネント：
references/lifecycle-and-components.md - DDS / QoS / ネットワーク：
references/dds-qos-networking.md - 録音再生 / 診断：
references/rosbag-diagnostics.md - SLAM / マッピング：
references/slam-mapping.md - Docker：
references/docker-ros.md - カスタムインターフェース：
references/custom-interfaces.md - マルチロボット：
references/multi-robot.md - MoveIt 2：
references/moveit2.md - CI/CD：
references/ros2-cicd.md - 可視化：
references/foxglove-visualization.md - トラブルシューティング：
references/debug-playbooks.md - レビュー：
references/review-checklist.md
必ず守るべき原則
- ビルドシステムを特定してからコードを変更する
package.xml/CMakeLists.txtの整合性を最初に確認し、その後リファクタリングを検討する- TF、タイムスタンプ、フレーム、単位を最初に確認し、その後でアルゴリズムを疑う
- 証拠（ビルド出力、topic、TF、パラメータ、ログ）を確認可能にしてから修正する
- ROS 1 → ROS 2 は、まずブリッジまたは段階的に移行し、一気に書き換えない
- MCU /
micro-ROSは、本当に ROS グラフに参加させる必要があるかを先に判断する
一般的なタスクの処理方法
パッケージの新規作成または修正
- 最初にパッケージタイプを判定する：
catkin、ament_cmake、ament_python - 最初に依存関係の宣言を追加し、次にビルドロジック、最後にインストールルールを追加する
- カスタム
msg/srv/actionは、生成順序と依存関係の循環を優先して確認する（詳細はreferences/custom-interfaces.mdを参照）
ビルド失敗
- 最初に
rosdepを実行する - 次に
package.xmlとビルドスクリプトの整合性を確認する - 環境が正しく source されているかを確認する
- システム依存関係、ABI、ディストリビューションの互換性を確認する
実行は正常だがロボットの動作がおかしい
- 最初に launch、namespace、remap、パラメータを確認する
- 次に topic 名、周波数、タイムスタンプ、単位、
frame_idを確認する - TF が単一ルートか、静的／動的が明確に分離されているかを確認する
- 最後にアルゴリズム自体を疑う
Nav2 / ros2_control
- Navigation2 は、
/cmd_velリンク、ローカリゼーション品質、制御周波数、車台の単位を優先的に確認する ros2_controlは、ハードウェアインターフェースタイプ、コントローラ YAML、読み書きサイクル、アクティブ状態を優先的に確認する
MCU / micro-ROS
- まず Linux 側のブリッジノードが十分かどうかを判断する
- MCU を ROS 2 グラフに参加させる必要が本当にある場合にのみ、
micro-ROSを検討する - バイトオーダー、チェックサム、タイムアウト、再接続、時刻ソース、切断保護を厳密に確認する
アンチパターン
- 同じパッケージに
catkinとamentを混在させる CMakeLists.txtだけを変更してpackage.xmlを更新しない- TF、タイムスタンプ、単位、座標軸の定義を無視する
- ドライバ、プロトコル、フィルタリング、制御、診断をすべて1つの大きなノードに詰め込む
- ROS 1 → ROS 2 移行時に API の置換だけでシステム検証を行わない
出力要件
このスキルを使用してタスクを処理する場合、以下の順序で出力することを優先します。
- 現在のワークスペースとパッケージタイプの判断
- 主要な根拠と前提
- 変更点とその理由
- 最小限のビルド / テスト / 実行コマンド
- リスクポイントと回帰チェックポイント