ROS 2で認識・構図・飛行監視をつなぐ

Topic・Service・Actionの使い分け

ROS 2のTopicは継続するデータの流れ、Serviceは短く終わる要求と応答、Actionは時間のかかる仕事と進捗・中止を扱う整理ができる。例えば映像や機体状態をTopic、短い状態照会をService、撮影シーケンスをActionとして設計するのは、本ガイドの一例じゃ。これは機体メーカーの飛行APIを自動で置き換えるものではない。ROS 2は構成要素をつなぐ枠組みで、カメラドライバーや制御橋渡し、座標変換、実行条件は別に実装・検証する。機能を一つ追加するたびに、どの状態を読んで何を出すかを文書へ残そう。 大きな一つのノードでも、小さく分けた多数のノードでも、境界の説明がなければ運用は難しい。分割の目的は見た目を整えることではなく、遅延や失敗の場所を把握し、交換や再試験をしやすくすることじゃ。担当する責任を短く書こう。

時刻・座標・品質をメッセージに持たせる

画像の対象が画面中央からどれだけずれたかだけを送ると、いつの画像か、どのカメラか、信頼できるかが分からん。タイムスタンプ、座標フレーム、カメラの内部パラメータ、信頼度や有効性を合わせて扱うんじゃ。処理が遅れた映像を順番どおり全部消化することが、制御に適しているとも限らん。通信のQoSやキューの考え方は、最新性、欠落への許容、記録用途を分けて選ぶ。保存では全データを欲しくても、飛行判断では古い情報を捨てたい場合がある。要求の違いを一つの既定値に押し込めんことじゃ。 信頼度という名前の数値も、確率と同じとは限らん。どう計算し、どの条件で下がり、判断へどう使うかを説明するんじゃ。画面へ数字を表示するだけで安心を与えず、古い観測や無効な観測を区別できる表示へつなげよう。

中止を最後まで伝える

撮影Actionをキャンセルしたのに、下流の経路生成や機体アダプターが古い目標を送り続けるなら、中止は成立しとらん。独自演習では、認識、構図計画、飛行指令、監視を分けた図に、キャンセルがどこまで伝わるかを書き込む。正常終了、ユーザー中止、対象喪失、通信異常を別の結果として残すんじゃ。録画停止の判断と機体を安全側へ移す判断も同時とは限らん。ログを再生し、各要素の状態が一貫するか確かめよう。ノードが増えるほど、責任の境界を曖昧にせんことが大事になるんよ。 中止後に再開する設計なら、途中の状態を引き継ぐのか最初からやり直すのかを明記する。撮影対象が移動した後で古い経路へ戻らんためにも必要じゃ。再開を新しい実行として確認するかどうかも、システム全体で統一しよう。

出典と編集上の位置づけ

Sir Airffic Goの解説と練習課題は本ガイド独自の編集じゃ。製品固有の条件はリンク先の該当版を確認してつかあさい。

1. ROS 2 — Topics vs Services vs Actions, official source ↗
2. ROS 2 — Official documentation repository ↗

資料確認：2026年10月21日。製品の対応機種・版、制度の適用条件はリンク先で確認してつかあさい。出典には本文確認済みと公式検索索引での確認が含まれるで。