# ROS2Wiki-NaRRF
---------------------
LAST UPDATE
- [ ] 2019/08/21
- [ ] 2019/08/23

---------------------
# はじめに
ROS2はなぜできたか
---
ROS２が生まれたのは、ROS1が奥の開発者に利用されるようになるに従っい、ROS1が生まれた２００７年に再発最初期には想定していなかったようなユースケースに対応する必要が出てきたため。

ROS1の初期設定時のコンセプトは、基本的に研究用のロボットアプリケーションのラピッドプロトタイプ用のツールを目指したものでした。PR2という全方向に移動できる双腕パーソナルロボットのソフトウェア研究開発の高速化と汎用化実現のために始まり、高性能な計算機と安定したネットワークを前提に設計されていた。また、通信内容が暗号化されておらず、認証機能もない。

# ROS1とROS2違い
- #### ROS1とROS2の比較表
||現在のROS（ROS1）|未来のROS（ROS2）|
|-|-|-|
|ロボットの同時利用数|単体ロボットのみ対応|複数台にも対応|
|計算資源|高性能計算機のみ対応|組み込みプラットフォームにも対応|
|リアルタイム制御|特別な作法に従う必要あり|一般的なプロセス内・プロセス間通信|
|ネットワーク品質|高品質のみ対応|欠損や遅延も許容|
|プログラミング形式|最大限にユーザの自由|柔軟性を残しながらも形式を固定|
|アプリケーション|研究、学術用途のみ対応|製品化にも対応|

- #### ロボットの同時利用数
研究室と違い、工場では当たり前のように複数台のロボットが連携して製品を製造しています。これらのロボットがそれぞれ独立して動作してるようでは、製造ラインの高速化、最適配置は非常に難しくなります。センサーデータの共有やロボットの現在状態の共有があって初めて、真にロボット同士が連携することができます。

**ROS1でも名前空間を分割することにより、複数台ロボットを同時にROSネットワークに接続することができます。しかし、メッセージ通信の仲介役を担うROSマスタは単一でしか存在できません。単一障害点であるROSマスタがもしも不具合を起こしてしまうと、その影響はROSマスタネットワーク全体に伝授し、すべてのノード（ロボット）が動作不能になってしまう欠点がありました。**

しかし、ROS2ではこのROSマスタという仲介役が必要なくなりました。そのため、単一障害点は存在せず、複数台のロボットがROSネットワー障害で1度に不具合を起こすことはありません。また、ノードの実行状態を別のノードから制御できる機能も加わったため、障害からの復帰もROS1に比べて容易になりました。

- #### 計算資源
ROS１は核となり構成要素の実装にC++言語を用いています。また、ROS1独自のメッセージ通信方式ではXML-RPCを扱う必要があるので、非力な計算資源では厳しいのが事実でした。そのため、C言語のプログラムの実行環境しか持たないマイコンのような組み込みプラットフォームでは、動作させることが非常に困難でした。

一方、ROS2は書くとなる構成要素をC現尾で実装しています。さらにメッセージ通信もプラグインとして実装されており、軽量化できるように部分的な機能のみを使えば、組み込みプラットフォームでも動作させることができます。たとえば、外界センサー出力のみを扱うマイコンをROS2のネットワークに参加させる、といった使い方が現実的になったのです。**これまでは、そういった使い方をするには、Arduinoのシリアル通信通信でホストPC を介したり、PC感覚で使えるRaspberry Piなどを使う必要がありました。**
- #### リアルタイム制御
**ROS1は基本的にリアルタイム性を考慮していません。メッセージ通信はTCPを基本としており、その時点でいつ通信が完了するのか決定論的ではないからです。どうしてもROS1でリアルタイム制御を行いたい場合には、ros_controlという特別なプログラミングインターフェイスに対応させる非梅雨がありました。ROS1のメッセージ通信の制御ループとリアルタイム制御のための制御ループを分離する必要があるためです。**

ROS1のTCP通信に対して、ROS２はUDP通信をベースとするプロトコルであるため、送信を完全にリアルタイム周期で行うこともできます。その代わり、受信が確実に行われる約束はありませんが、その可能性も考慮したプロトコルになっているわけです。

また、複数ノードが同じプロセス上で動作するプロセス内通信の枠組みも、ROS１ではnodeletという特殊なプログラムングインターフェイースに対応させる必要がありましたが、ROS2ではその仕組みが標準化されて提供されています。

さらにROS2では、プロセス間通信、プロセス内通信の切り替えも、ソースコードの変更ベンチが必要なく、ノードの実行時に変更できます。
- #### プログラミング形式
**ROS1のプログラミング形式は良くも悪くも非常に自由です。最大限に柔軟性があり、ユーザーに何のプログラミング形式も強制しません。そのおかげで、自分でプログラムの制御ループを設計して、自分の好きなようにROSノードの実行手段、手順を設計できました。**

ROS2では、その最大限の自由何少し制限が加えられました。ユーザはメインループを記述せず、各プログラミング言語用のROS2クライアントライブラリが提供する手順に従ってプログラミングすることが求められます。その代わり、ROS1にはなかったノードの起動順序を知るライフサイクル機能を安易に利用できるため、複数ノードの起動順序などの構成を、正確に記述できるようになりました。
- #### アプリケーション
ROS1はその成り立ちが示しているように、研究や学術用途での利用を想定して開発されたソフトウェアです。最新の研究結果をすぐにロボットに適用してプロトタイピングをすることが第一目的です。ROS1のおかげで、最新の論文に載っているようなアルゴリズムが、ROSパッケージとして提供されていれば、初心者ユーザでも共通の手順でビルド、インストールして、再利用できるようになりました。これにより、似たアルゴリズム同士のベンチマークも手軽にできるようになり、ロボット研究者コミュニティでは、自分の提案する最新技術をROSパッケージとして公開することが一種のステータスとなりました。

ROS2では、そのプロトタイピングの成果をアプリケーションとして実世界で製品化することも想定しています.そのため、昨年、ROS2の開発においては、主開発団体であるOpen Source Robotics Foundationだけが指揮するのではなく、「ROS2 Technical Steering Committee」という委員会を組織し、多数の企業を巻き込んで技術的な方向性を検討することになりました。また、ROSシステムの根幹をなすPublisher/Subscriber通信に関しても、独自に開発したTCPROSではなく、仕様と実装がともに熟成しているDDS/RTPS(Real-Time Publish-Subscribe)を採用することで、信頼性を向上させています。

# ROS2勉強会
エコシステム
自動運転において話すと
ros1のでのーどは開きすぎてわかない
また、１人でそんなに管理できない。
RVIZは問題ない
ＴＦはまず己診断便利