ROS 2のアーキテクチャ

ROS 1のmasterはなぜ実機投入で壁になったか

ROS 1のノード間通信は、roscore が提供する単一のXML-RPCサーバー「ROS master」に全ノードが登録し、名前解決を仲介してもらう構成でした。ノードAとノードBが直接ソケット接続（TCPROS）するのはmasterでの名前解決が終わった後で、通信そのものはP2Pですが、discovery（相手を見つける仕組み）が単一プロセスに集中しています。研究室のデスクトップ1台で完結する実験ではこれで十分でしたが、実機・量産ロボットに投入すると次の3点が構造的な壁になりました。

1. 単一障害点: masterが落ちると新規接続やトピックの再購読が一切できなくなり、複数ロボットが協調する分散システムの前提と相性が悪い。
2. リアルタイム性の欠如: TCPROSは可変長ヘッダ＋TCPで、パケット順序保証や輻輳制御の遅延がそのまま制御ループに乗り、ハードリアルタイム制御（モーター直結ループなど）には別経路が必要だった。
3. セキュリティ皆無: 認証・暗号化の仕組みがなく、同一ネットワーク上の誰もがトピックを盗聴・偽装できる設計だった。

ROS 2は、この3点を通信基盤そのものの入れ替えによって解決するという方針を取りました。その核が産業用ミドルウェア標準であるDDSの採用です。

DDSという通信基盤：masterを消してディスカバリを分散化する

DDS（Data Distribution Service）はOMG（Object Management Group）が策定するpublish-subscribe型のミドルウェア規格で、航空管制・防衛・金融取引など高信頼が要求される分野で実績のある標準です。ROS 2はDDSを直接の下位層として採用し、rmw（ROS Middleware interface）という抽象層を介して複数のDDS実装（Fast DDS、Cyclone DDS、RTI Connext等）を差し替え可能にしています。

ROS 2のレイヤー構成（上位→下位）:

  ユーザーコード（rclcpp / rclpy）
        │
  rcl（言語非依存の共通クライアントライブラリ）
        │
  rmw（ROS Middleware interface、抽象化層）
        │
  DDS実装（Fast DDS / Cyclone DDS / Connext など）
        │
  UDP/IP（通常はマルチキャストでディスカバリ）

DDSの核心は**動的ディスカバリ（Dynamic Discovery）**です。各ノードはDDS参加者（DomainParticipant）として起動すると、マルチキャストで自身の存在とトピック情報をネットワークへアナウンスし、他の参加者も同様にアナウンスし合うことで、中央サーバーなしに互いを発見します。これによりROS masterという単一障害点が構造的に消滅し、ノードの起動順序に依存しない疎結合が実現します。同時にDDSはドメインID（Domain ID）による論理的なネットワーク分離、後述するQoSポリシー、そしてセキュリティ拡張（DDS-Security）も規格として持っており、ROS 2はこれらをほぼそのまま継承します。

トピック・サービス・アクションの使い分け

ROS 2は目的の異なる3つの通信パターンを提供し、これらはRPC的な同期通信とストリーム的な非同期通信の使い分けという、分散システム設計一般の課題に対するロボティクス版の回答になっています。

**トピック（Topic）**は非同期・多対多のpublish-subscribeです。センサー値や推定姿勢など、決まった周期または発生時に流れ続けるデータストリームに向きます。パブリッシャーはサブスクライバーの有無や応答を気にせず送り続け、疎結合を保てます。

**サービス（Service）**は同期的な要求応答（request-response）で、1回のリクエストに対して1回のレスポンスを返します。「地図を1枚くれ」「経路を再計算してくれ」のように、有限時間で終わり結果が1つに定まる処理に向きますが、呼び出し側は応答を待つ間ブロックしうるため、処理時間が不定・長時間に及ぶタスクには不向きです。

アクション（Action）はサービスの弱点を補うために設計された、長時間実行タスク向けの非同期パターンです。目標（Goal）を送ると、実行中はフィードバック（Feedback）が継続的に返り、完了時に結果（Result）が返ります。加えて実行中のキャンセルが可能です。「目的地まで移動する」「アームを目標姿勢まで動かす」のように、数秒〜数分かかり途中経過が意味を持ち、かつ気が変わったら中断したいタスクに向きます。内部的にはアクションはトピックとサービスの組み合わせ（goal/result用のサービス、feedback/status用のトピック）として実装されています。

QoS（Quality of Service）ポリシー：通信路ごとに信頼性を選ぶ

ROS 1のTCPROSは事実上「信頼性重視の1択」でしたが、ROS 2はDDSのQoSポリシーをそのまま公開し、トピックごと・接続ごとに通信の性質を選べるようにしました。パブリッシャーとサブスクライバーのQoSは互換性チェックされ、両立しない組み合わせでは接続が成立しません。代表的なポリシーは次の通りです。

主要なQoSポリシーと選択肢:

  Reliability（信頼性）
    RELIABLE      : 再送してでも全メッセージ到達を保証
    BEST_EFFORT   : 再送なし、欠落を許容（低遅延優先）

  History（履歴）
    KEEP_LAST(N)  : 直近N件のみ保持
    KEEP_ALL      : リソース許す限り全件保持

  Durability（耐久性）
    VOLATILE            : 接続前のデータは受け取れない
    TRANSIENT_LOCAL     : 後から接続したサブスクライバーにも直近値を配信

  Deadline / Liveliness
    Deadline    : 一定周期内にメッセージが来ないと通知
    Liveliness : パブリッシャーの生存を周期的に確認

センサーの高頻度ストリーム（例: LiDARの点群やカメラ画像）は、多少の欠落より低遅延・低負荷を優先してBEST_EFFORTを選ぶのが典型です。一方、地図やロボットの状態遷移のように一度でも欠落すると致命的な情報にはRELIABLEを選びます。TRANSIENT_LOCALは、静的地図のように「後から起動したノードにも直近の値を渡したい」場面で使われ、遅れて参加するNav2やRVizのようなツールが最新の地図をすぐ受け取れるようにします。

リアルタイム性とセキュリティ：ROS 1との根本的な違い

ROS 1からROS 2への刷新は、単なるAPI整理ではなく実機・量産・多ロボット協調を見据えた非機能要件の作り込みが主目的でした。

リアルタイム性については、DDSの多くの実装がUDPベースで動作しTCPの再送・輻輳制御によるジッターを避けられること、rclcppがリアルタイム安全なエグゼキュータ設計（メモリ確保を制御ループの外に追い出すリアルタイムアロケータ等）を志向していることが、ROS 1との明確な違いです。加えてLinuxのPREEMPT_RTパッチ（カーネルの完全プリエンプション化により割り込みからのレイテンシ上限を保証する）との組み合わせにより、モーター制御など数百マイクロ秒〜数ミリ秒オーダーの締め切りを持つループを、ミドルウェアのオーバーヘッドで壊さずに実装しやすくなりました。

セキュリティについては、SROS 2（Secure ROS 2）がDDS-Security標準を土台に、ノード間通信の認証（誰がなりすましなく通信しているか）・アクセス制御（誰がどのトピックをpublish/subscribeできるか）・暗号化（盗聴防止）を提供します。ROS 1にはこれに相当する仕組みが標準では存在せず、同一ネットワークにいる第三者が任意のトピックを購読・偽装できました。工場や公共空間で稼働するロボットにとって、この差は実機投入の可否を左右する要件です。

まとめ

ROS 2のアーキテクチャは、ROS 1が実機投入で直面した3つの壁（単一障害点、リアルタイム性の欠如、セキュリティ皆無）に対する構造的な回答です。要点は、(1) ノード間通信の基盤を独自プロトコルからDDSという産業標準へ置き換え、中央のROS masterを廃して分散ディスカバリを実現したこと、(2) トピック・サービス・アクションという性質の異なる3つの通信パターンを提供し、非同期ストリーム・同期要求応答・長時間タスクという用途を明確に切り分けたこと、(3) QoSポリシーによって通信路ごとに信頼性・履歴・耐久性を選択でき、センサーストリームと制御指令のように要求が異なるデータを同じミドルウェア上で扱えること、(4) DDSを土台にリアルタイム性とSROS 2によるセキュリティがアーキテクチャレベルで組み込まれたことです。これらはいずれも「研究室の1台のロボット」から「工場・公共空間で稼働する量産ロボットや複数ロボットの協調」へとスケールする際に避けて通れない要件であり、ROS 2の設計判断はその移行を見据えたものだと理解すると筋が通ります。