ROS 2入門 — ノード・トピック・DDSでロボットを安全に分散制御する

ROS 2はロボットそのものではない。カメラドライバ、自己位置推定、経路計画、モータ制御を別々のプログラム（ノード）として動かし、標準化されたメッセージと通信で組み合わせるための基盤である。試作段階ではPython一つで始められ、製品ではC++、リアルタイム実行、複数コンピュータ、セーフティ監視へ拡張できる。重要なのはAPIを暗記することではなく、データの所有者、時間、信頼性、停止時の安全状態を設計することだ。

ROS 2

画像: Robot Operating System logo、Wikimedia Commons(CC BY-SA 4.0)。ロゴはミドルウェアの識別用であり、特定ディストリビューションの動作を保証するものではない。

30秒で分かる結論

• ノードは一つの責務を持つプロセス、トピックは継続的なストリーム、サービスは短い要求・応答、アクションは途中フィードバック付きの長い仕事を表す。
• ROS 2の通信はDDSを利用し、QoS（信頼性、履歴、深さ、耐久性、期限）をエンドポイントごとに選べる。センサと制御で同じ設定を使う必要はない。
• TF2は座標系の木と時刻を管理する。map、odom、base_link、センサフレームを混ぜると、認識が正しくてもロボットは誤った場所へ走る。
• 実機では、ライフサイクル、ウォッチドッグ、権限分離、ログ、ネットワーク断時のフェイルセーフを追加する。シミュレーションで動いたことは安全の証明ではない。
• ROS 2 Jazzyなどの長期サポート版、対応するDDS、OS、ドライバの組み合わせを最初に固定し、再現可能なワークスペースを作る。

1. ROS 2の全体像

図1 — ROS 2では、ノード同士がDDSを介して発見・通信する。トピック名だけでなくQoSと型、時刻、座標系を契約として扱う。

ROS 2のグラフは実行時に構成できる。カメラノードが画像を発行し、認識ノードが購読し、制御ノードが結果と自己位置を受けて速度指令を発行する。ノードを別コンピュータへ移しても、DDSの発見とシリアライズが正しければ同じグラフを保てる。

2. 通信プリミティブを使い分ける

トピックメッセージには、値だけでなくheader.stampとframe_idを含める。画像の時刻とIMUの時刻がずれていれば、アルゴリズムは計算できても運動を誤って推定する。カメラ画像を信頼性付きで再送すると帯域が詰まる場合があるため、センサの性質に合わせてQoSを選ぶ。

3. QoSは「通信の契約」

ROS 2のQoSで最低限確認する項目は、Reliability（Best Effort/Reliable）、Durability（Volatile/Transient Local）、History（Keep Last/Keep All）、Depth、Deadline、Livelinessである。高頻度LiDARは古いパケットを捨てるBest Effortが適することがあり、速度指令は欠落を許さないReliableと短いDeadlineを選ぶ。

PublisherとSubscriberのQoSが互換でないと、同じトピック名でも通信できない。ros2 topic info -v /scanで実際の設定を確認し、センサドライバのプリセットを鵜呑みにしない。ネットワークを跨ぐ場合は、MTU、Wi-Fiの再送、マルチキャスト制限、時刻同期を合わせて試験する。

4. TF2と時刻

ロボットの姿勢は座標系の変換として表す。典型的な木は

map ──(SLAM/Localization)──> odom ──(odometry)──> base_link
                                                        ├── base_laser
                                                        ├── imu_link
                                                        └── camera_link

mapは長期的な世界座標、odomは滑らかな短期オドメトリ、base_linkは車体基準である。map→odomをSLAMが補正し、odom→base_linkを車輪・IMUの推定が高頻度で更新する。TF2は変換を時刻付きで保持し、センサの取得時刻へ補間して使う。

座標系を右手系で統一し、光学フレーム（z前方、x右、y下）と車体フレーム（x前方、y左、z上）の違いを明示する。静的変換はstatic_transform_publisherで固定し、動的変換を静的として公開しない。TFツリーの循環や複数親は設計エラーである。

5. パッケージと実装の流れ

ROS 2のPythonノードを最小化すると次のようになる。

import rclpy
from rclpy.node import Node
from std_msgs.msg import Float32

class Speed(Node):
    def __init__(self):
        super().__init__('speed_node')
        self.pub = self.create_publisher(Float32, '/speed', 10)
        self.timer = self.create_timer(0.02, self.tick)  # 50 Hz
    def tick(self):
        msg = Float32(); msg.data = 0.2
        self.pub.publish(msg)

rclpy.init(); node = Speed(); rclpy.spin(node)

実機では、速度指令を直接モータへ出さず、上位ノード、速度制限、非常停止、ハードウェア監視を間に置く。C++のrclcppを使う場合も、コールバックグループ、Executor、メモリアロケーション、リアルタイム性を確認する。

ワークスペースはsrc、build、install、logを分離し、rosdepで依存を解決する。DockerやdevcontainerでOS・DDS・コンパイラを固定し、ros2 doctor、ros2 node list、ros2 topic hz、tf2_toolsをCIと現場の診断に組み込む。

6. ライフサイクルと安全

センサやアクチュエータは、起動した瞬間から指令を受けてよいとは限らない。Lifecycle NodeのUnconfigured→Inactive→Active→Finalizedという状態遷移で、ドライバ初期化、キャリブレーション、通信確認、出力許可を分ける。ウォッチドッグがハートビートを失ったら速度指令をゼロにし、ブレーキやリレーをハードウェア側でも開く。

安全関連では、ROS 2のメッセージ通信はそれだけで機能安全規格を満たさない。IEC 61508/ISO 26262/ISO 13849などの対象範囲を確認し、安全機能を監視系・認証済みMCU・物理非常停止へ分離する。ネットワークに接続する場合はSROS 2の鍵・証明書、DDS Security、アクセス制御、ログ監査を導入する。

7. 現行エコシステムと研究

Nav2は自己位置推定・地図・経路計画・制御をアクションとライフサイクルで統合し、ros2_controlはハードウェアとコントローラの境界を標準化する。MoveIt 2はマニピュレータの運動学・衝突判定・軌道計画を扱う。GazeboやWebotsでシミュレーションし、rosbag2でセンサログを再生すれば、実機を止めずに回帰試験ができる。

研究では、ゼロコピー通信、GPU・NPUを使う型付き画像パイプライン、決定論的Executor、分散学習、DDSを越えたクラウドロボティクスが進んでいる。新機能を導入するときは、ベンチマークだけでなく、ネットワーク断、時刻ずれ、プロセス再起動、センサ欠測、異常なメッセージ長をテストする。

まとめ

ROS 2は、ロボットを部品の集合から再利用可能な分散システムへ変える。ノードの責務、トピックのQoS、TF2の座標と時刻、ライフサイクル、安全状態を先に設計すると、アルゴリズムを交換しても全体が崩れにくい。

参考資料

• ROS 2公式ドキュメント
• ROS 2 Quality of Service settings
• ROS 2 tf2
• DDS Foundation
• Nav2 Documentation
• ros2_control