ROSとROS 2は何が違うのか、なぜROS 2は生まれたのか、についての記事です。 ROS 2の設計思想に関する情報は、下記にまとめられています。

http://design.ros2.org

これからの数回で、それぞれの記事をかいつまんで要約していきます。ところどころ、自分の意訳もあります。

なぜROS 2なのか?から診てみましょう。

http://design.ros2.org/articles/why_ros2.html

ROS 1ユースケース

  • 1体のロボット
  • 潤沢な計算資源
  • リアルタイム制御は求めない(ros_controlの特別な仕組みで別途対応)
  • 高速、安定なネットワーク環境
  • 研究、学術用途
  • プログラミングの高い自由度

を求めて、ROS 1は設計されました。PR2はそのどのユースケースも満足し、高いパフォーマンスと自由度を研究者に提供しました。 これによって、研究者やロボットエンジニアは、ロボットのソフトウェア構成要素を再利用性の高い形で共有できるようになり、オープンソースソフトウェアを使ったプログラミングスタイルとコミュニティが拡がりました。車輪の再発明が防がれるようになったのです。

しかし、コミュニティが広がるに連れて、当初のユースケースと違う使われ方がされるようになりました。 つまり、ユースケースとは逆のケースです。複数ロボット、組込みシステム、リアルタイム制御、不安定なネットワーク、産業応用、などです。

新しい通信技術

ROSを設計した2007年頃には、ROSの特徴であるPub/Sub通信を行う通信ライブラリは、目立ったものがなく、一から作る必要がありました。 メッセージ定義、シリアライゼーション、通信、ノード検出などもすべて独自実装です。

しかし、数年経ち、Pub/Sub通信は一般的なものととなり、いくつか代替できるメジャーな通信技術が現れます。その中に、ROS 2で採用されることになるData Distribution Service (DDS)もありました。

ROS独自の通信ミドルウェアを用意することなく、一般に広がったオープンソースライブラリを使えるようになったのです。

API変更

ROSは2009年2月にリリースされてから現在まで、クライアントライブラリのAPIの互換性が保たれてきました。 しかし、数年経ち、そのAPI設計も最善のものではなくなってきました。

そこで、ROSコミュニティの集合知を使って、新しいAPI、ROS 2を設計することになりました。 その結果、ROSのキーコンセプトである

  • 分散処理
  • 非同期Pub/Subメッセージ
  • フィードバック付きRPC(つまりactionlib
  • プログラミング言語問わず
  • システム内部状態の可視性

などは残した上で、ROSとのAPI互換性はなくす方がよいと決断されました。

しかし、ROS 2とROSのノードは共存できます。ROSとROS 2の通信ブリッジはすでにあり、ROS 2のライブラリでROSのソースコードをコンパイル、実行できるようにしていく計画も進んであります。

なぜROS 1を拡張しないのか?

すでに存在するROSのエコシステムを破壊する可能性のあるAPI変更を、現在のROSバージョンに導入することはリスクが大きすぎます。

だから、ROS 2はROSと並列に存在し、共存して動くようにしていきます。