著者:東風上奏絵

ROS2チュートリアル体験記 (3/3)

ROS2のこれから

ROS2はこれからどのように開発が進んでいくのでしょうか．

2018年の9月末頃から，こちらのスレッドで，ROS1からROS2への移行計画についての議論が行われました．簡単に議論内容をまとめてみようと思います．

最初の議論の出発点は，ROS1のリリースをある年度までで辞めることにして，その間の4.5年間にコミュニティ全体でROS2への移行を進め，その後はROS2の開発に集中するというのはどうか，という提案でした．ROS1のリリースをやめる背景には，Python2からPython3への移行の問題もありました．

• 皆がどう思っているか知りたいんだ．ROS2に完全移行するのに，2023年だったら十分な時間があるだろうか？ 2020年にROS1のLTSリリースは必要だろうか？僕の提案は，2020年にROSのリリースはやめて，代わりにROS2の開発に尽力していくこと．

(… So, I’d like to know other users thoughts. Is 2023 enough time to move fully to ROS2? Do we need a LTS release in 2020? My proposal is to forgo a ROS release in 2020 and put the effort in to ROS2 instead. … by mkhansen)

これに対し，複数の賛成意見が寄せられました．

• すぐにできることではないけれど，ROS1の開発とリリースを徐々に減らしていくことを望んでいるよ．代わりに限られたコミュニティの資源を，2007年に大学院の研究室では作れなかったより良いロボティクスミドルウェアの開発に集中していく必要があるからね．

(… While no one is saying it will happen tomorrow, I’m looking forward to ramping down ROS1 development and future releases. Instead we need to focus our limited community resources on a better robotics middleware that wasn’t built in a graduate student lab in 2007. … by davetcoleman)

• Willow Garageを2012年に離れてから，ROS1の維持や改良のためのお金はほとんどもらっていないんだ．それにそういうお金があったとしても，チームの人員は限られているからね．

(… Since leaving Willow Garage in 2012, we’ve received approximately $0 directed at maintenance or improvement of ROS 1. And even if we had such funding, we’d still be limited by the number of people on our team. … by gerkey)

その一方で，ROS1からROS2への移行はもっと徐々に進めてほしいという意見もありました．

• 2020年の4月だと，1年半しかない．既存のROS1パッケージにブリッジして今のROS2のリリースをするのがとても難しくなるよ．合っているよね？ROS1をUbuntu20.04でリリースすれば，もう2年ブリッジのための開発猶予期間ができるよね．

(… To me, that says that after April 2020 (only about 18 months away), it gets a lot harder to run the current ROS2 release with any ROS1 packages bridged in. Is that logic right? By releasing ROS1 on Ubuntu 20.04, you can an extra 2 years of bridge availability. by mikeferguson)

また，ROS1とROS2を共存させていくべきではないかという声もあがりました．

• 全てのROS1のパッケージをROS2に置き換える代わりに，ROS1とROS2の違いを両側から減らしていく努力もできると思う．コミュニティの分断の衝撃と，最終的な完全移行にかかる負担を減らすために．

(… Instead of porting any package to ROS2, efforts could be spend on reducing the differences between ROS1 and ROS2 from both ends, to reduce the impact of the community split, and all costs of eventual full migration. … by tkruse)

• ROS1を使ったロボットシステムを提供している会社としては，自分たちのコードを全て新しいミドルウェアに移行するのはとても大変なことになるだろう．僕らのロボットは倉庫で自動のピッキングを行っているのだけど，高い性能と信頼性のためには中身がよく分かるシステムが必要なんだ．このとても複雑なシステムの基盤を交換して，今までと同じ性能まで持っていくのは簡単なことではないと思う．負担の少ないROS2への移行の道筋か，両方を長期的に管理する方法を見つけられるといいのだけど．

(… As a company building solutions based on ROS 1, porting all of our code base to a new middleware would be a major effort. Our robots perform mobile picking in warehouses, where performance and reliability demands require a well-understood system. Exchanging the foundation of this very complex system and getting to a similar performance level again will not be an easy step. … I hope that we can find either a good migration path or ways for maintaining both versions for a longer time. by moritz)

やはりROS1のサポートは必要ではないか，という意見もあり，ROS1をサポートする新たな組織が必要ではないかという提案もありました．

• Open RoboticsがROS1にかけられるリソースがもうないことは理解しているよ．でも，もし時が来たら，ROS1のメンテナンスを引き継いでくれる組織を見つけようよ．

(… I understand that OSRF cannot commit resources to ROS1 forever. But when that day comes, please let’s try to find a successor organization that takes over stewardship of ROS1…. by Martin_Guenther)

ROSのコミュニティには多様なニーズや必要性を持っている人が所属しているので，これらを可視化して，皆にとってより良い方向性を決めていくべきではないか，という意見もありました．

• 様々な人が様々なニーズや負担や障害を持っているよね．それだけではなくて，異なる使い方，コミュニティへの貢献の仕方，色々なコードの管理の仕方があるよね．こうした関係性を可視化することはとても価値のあることだと思う．

(… Different segments have different types of needs, requirements, costs, and constraints. Not only that, but different segments use, contribute, and maintain different types code. I think seeing a breakdown and a graph of these relationships of that would be really valuable. … by jbohren)

最後に，スレッドを立てられた方は，これまでの議論を踏まえて，ROS1からROS2移行のために必要な作業をまとめられました．

• 1. ROS1からROS2に移行したい人向けに80%くらいを自動で置き換えてくれるスクリプトの作成
• 2. ROS1とROS2共存のためのROS1ブリッジの改良
• 3. 2020年のUbuntu 18.04, 20.04両方のROS2サポート
• 4. ROS1 Melodicの2023年までのサポート
• 5. ROS2のための分かりやすいドキュメント作成

(…

1. A migration script to do 80% of the ROS1 -> ROS2 conversion for those who want to migrate
2. An improved ROS1 bridge for running hybrid systems?
3. ROS2 support in 2020 on both 18.04 and 20.04
4. Support of Melodic until 2023
5. Better documentation of ROS2 (see @mikeferguson thread) … by mkhansen)

Open Roboticsの方は，ROS2のこれからをこのように予想しています．

• 現在のコミュニティの貢献の状態とレベルを考えると，4年半でMelodicが寿命を迎えるもっと前に，ROS2の実装は充実して，とても使いやすくなっているだろうね．もちろん．ROS2がどうなっていようと，たくさんの人は4年半の間やその先も，ROS1を使い続けるだろう．単にROS1のコードを使い慣れているし，信頼できるからね．

(… Given the current status and level of community contributions I expect that ROS 2 will be well-featured and very usable for a wide variety of applications long before Melodic goes EOL in 4.5 years. …

おわりに

いかがでしたでしょうか．

ROS1と比べることで，ROS2での変更点が少し探れたのではないかと考えています．また，執筆者自身は，ROS2との違いを意識することで，逆に，普段何気なくROS1を使っていることに気付かされました．ROS1の理解も少し深まった気がしています．ROS1とROS2の違いは，今回書いた点以外にもあると思いますので，皆様も是非チュートリアルを体験してみてください！

また，ROS2への移行に関する議論は，ROS1を研究で使う者として，しっかりこれからも追っていきたいです．皆様も是非ROS2を試してみてください！

著者:東風上奏絵

ROS2チュートリアル 体験記 (2/3)

チュートリアルの体験

それでは，早速チュートリアルを進めていきます．今回は，gbiggsさんが作成された，

ROS Japan ユーザグループ 講習会 ～ ROS 2 の紹介 ～ (https://gbiggs.github.io/rosjp_ros2_intro/index.html)

のチュートリアル資料を使わせていただきます．ROS2ならではのノードの書き方を理解し，ROS1との違いを探ることを目的とします．

インストール

Ubnutu 18.04にROS2 Bouncy をインストールします．ROS2 Bouncyのインストールはこちら (Desktop Install) を参照しました．ROS2のインストールがうまく行っているかはこちらで確認できました．

ROS2の基本

ROS 2の基本 に従ってチュートリアルを進めていきます．ROS1のチュートリアルでお馴染みの talker/ listener プログラム をROS2のノードの書き方で書いていくものです．

ROS2ならではのノードの書き方として，以下のポイントが挙げられると思います．

• メインの関数の中ではなく，共有ライブラリとしてノードを実装する．（このようなノードをコンポーネントノードという．）コンポーネントノードとして実装することで，単体でも，ノードレットとして他のノードと組み合わせても使えるようになる．
• そのために，他ソースファイルに利用するためのコンポーネントノードのクラス定義をまず行い（C++でいうところのhppファイル），その上で，コンポーネントノードの実装を行う（C++でいうところのcppファイル）．

チュートリアルの詳細については，リンク先を参照していただきたいのですが，ここからは，チュートリアルを通して印象に残った点を挙げていきます．

実装時に印象に残った点

1. ROS2を利用するためにインクルードするヘッダの変更（ROS2のノードの書き方を理解->コンポーネントノードのソースを読み解く->ヘッダーファイル 42行目）：

#include <rclcpp/rclcpp.hpp>

ROS1におけるrospyはrclpyに，roscppはrclcppに変更になっています．

2. 初期化の方法の変更（ROS2のノードの書き方を理解->コンポーネントノードのソースを読み解く->スタンドアローンノードラッパーのソースファイル 7, 8行目）：

  rclcpp::init(argc, argv);
  auto greeter = std::make_shared();

ROS1では，

ros::init(argc, argv, "talker");

のようにROSの初期化に合わせてノードを初期化します．一方，ROS2では，ROSの初期化とノードの初期化が別々に分けられています．そのため，ノードを共有ライブラリとして実装すると，複数ノードを同一プロセスの中に入れられるようになります．

（詳しくはこちらのチュートリアルのmain関数4, 5行目

  rclcpp::init(argc, argv);
  auto node = rclcpp::Node::make_shared("greeter");

にも説明があります．）

すべてのノードはexecutorというオブジェクトの中で実行します．

こちらのチュートリアルの greet_and_displayer.cpp 10-18行目を抜粋します．

  // タイマーコールバック，トピックコールバック等を行うexecutor
  rclcpp::executors::SingleThreadedExecutor exec;

  // Greeterコンポーネントノードのインスタンスを作成しexecutorに登録する
  auto greeter = std::make_shared<greeter::Greeter>();
  exec.add_node(greeter);
  // Displayerコンポーネントノードのインスタンスを作成しexecutorに登録する
  auto displayer = std::make_shared<displayer::Displayer>();
  exec.add_node(displayer);

3. ノードなどのインスタンス作成時のスマートポインタの使用（ROS2のAPIの基本を理解->ノードの実装 main関数5行目）：

auto node = rclcpp::Node::make_shared("greeter");

ROS2はC++11/14を使っているため，autoを用い，変数のメッセージ型をコンパイラに判断してもらうようにします．コンパイラに型判断をお任せできるので，ソースコードが簡単になります．

4. ノードの制御の仕方の変更（ROS2のノードの書き方を理解->コンポーネントノードのソースを読み解く->ソースファイル 19行目）：

timer_ = create_wall_timer(1s, std::bind(&Greeter::broadcast_greeting, this));

ROS１の talker/ listener プログラム のチュートリアルでは，whileループを回し，一定時間ごとにsleepすることよってノードの周期を決めていました．ROS2では，リアルタイム制御や実行時間の管理のため，タイマーイベントで制御を行うことが推奨されています．

ビルド時に印象に残った点

1. ビルドシステムの変更（ROS2のノードの書き方を理解->ビルド＆実行）：

ROS1ではcatkinを用いたビルドを行っていました．catkinは直接cmakeのみを扱います．一方，ROS２では，colconと呼ばれるメタビルドシステムを用います．colconは依存関係を考慮してパッケージのビルド順を決め，ビルドを実行します．ビルドの方法は各パッケージに任せるので，cmakeによらず複数のビルドタイプを選択可能です．

2. ソースコード実行のために実行ファイルのインストールが必須に（ROS2のAPIの基本を理解->パッケージのコンパイル方法 CMakeLists.txt 25-29行目）：

# ノードの実行ファイルをインストールする（必須）
install(TARGETS
  greeter
  DESTINATION lib/${PROJECT_NAME}
  )

ROS1ではビルド時に，すべてのビルドされたファイルがソフトリンクされた，development space (devel space) が作られました．この開発環境を用いれば，インストールせずビルドのみで開発したソフトウェアを利用することができました．一方，ROS2のcolconビルドではdevel spaceが作られないため，開発パッケージのCMakeLists.txtに，実行ファイルのインストール先を指定する必要があります．（執筆者は，ROS1でdevel spaceを用いて自身が開発したソフトウェアを実行しており，正直に書くと，これまでインストールのことを意識していませんでした．）

colconについてはこちらのチュートリアルに詳しく紹介されています．

プログラム実行時に印象に残った点

1. source install/local_setup.bash を使用する端末で必ず一回実行（ROS2のAPIの基本を理解->ビルド＆実行）：

source install/local_setup.bash

ROS1でいうところの source ~/catkin_ws/devel/setup.bash の代わりです．

2. 実行コマンドの変更 ( ros2 run greeter_ros2_style greeter )（ROS2のAPIの基本を理解->ビルド＆実行）：

ros2 run greeter_ros2_style greeter

ros2 run displayer displayer

ROS1でいうところの rosrun greeter_ros1_style greeter の代わりです．その他のコマンドについてはこちらのチュートリアルに紹介されています．

3. roscoreが必要なくなる（メッセージ受信ノードの作成->ビルド＆実行）：

データ通信方式が変更になりました．ROS1では，出版購読モデルの先駆けだったため，独自の出版購読モデルを構築していました．ROS2を開発する頃には，既存のライブラリが複数登場するようになりました．そのような経緯で，Data Distribution Service (DDS) を採用しました．これにより，マスタによるノード間接続が必要なくなり，DDSミドルウェアを介して直接ノード間で接続できるようになりました．ROSにおけるDDSは，こちらのサイトに詳しい説明があります．

その他，難しいなと思った点

執筆者が一番難しさを感じているのは，CMakeLists.txtの書き方です．これまでインストールのことを深く考えたことが無かったため，単にツケが回ってきただけだと思いますが，必要な情報についての理解がまだまだ足りていません．ヘッダーファイルのマクロの理解も追いついていません．ドキュメントを読んで，勉強していこうと思います．

さらに，これはROS1のチュートリアルを最初に勉強した時と同じ感想なのですが，talker/ listenerのプログラムの書き方が分かっても，自分が今使っているロボットをどのようにROS2で動かせば良いのかについてはまだよく分かりません．センサデータが取り扱えるパッケージなどの情報があると嬉しく思います．または，既存のROS1の認識系プログラム等をROS2用に置き換える方法が分かるとありがたいなと思いました．

また，ROS2のlaunchファイルは，xml形式からpython形式になったということです．まだ開発中ということで，これから情報が増えてくることを楽しみに待っています．

著者:東風上奏絵

ROS2チュートリアル 体験記 (1/3)

はじめに

皆さんはROS2を知っていますか？

ROS2は，ROSの次世代版です．ROSは元々，ロボティクス研究用ソフトウェアプラットフォームとして開発されてきました．ROSの普及に伴い，研究開発のみの用途だけでなく，製品に活用する動きが活発になってきました．その過程の中で，ROSに対する新たなニーズが生まれ，ROSのフレームワークのみで対応するのが難しくなってきました．

そこで，ROS2が新たに生まれました．2017年12月にArdent Apaloneが，そして今年2018年7月にBouncy Bolsonがリリースされ，現在も開発が続けられています．

本ブログでは，ROS2が生まれた背景について簡単に触れながら，ROS2の日本語版チュートリアル体験を通して，ROSとROS2の違いとして印象に残った点について述べていき，ROS2のこれからに関する議論を追いかけていきます．（ROSのことは，ROS2と区別して，ROS1と記述します．）

ROS2が生まれた背景

Willow Garage PR2

ROS1はPR2というロボットを用いたロボティクス研究開発環境として，その開発がスタートしました．当初は以下のような用途が想定されていました：

• ロボット1台のみの運用
• 計算資源豊富な環境下での運用
• リアルタイム制御は必要としない運用
• 強固なネットワーク接続可能な環境での運用
• 学術研究における開発
• 自由なプログラミング可能な開発

一方で，ROS1が普及することで，PR2だけでなく様々なロボットで用いられるようになったり，学術用途から製品化に用いられるようになったりしていき，以下のような新しい用途が生まれていくようになりました：

• 複数ロボットでの運用
• 小型の組込みシステム下での運用
• リアルタイム制御を必要とする運用
• 不安定なネットワーク接続下での運用
• 製品化を行う産業分野での開発
• 製品化を推し進めるサイクルや開発におけるはっきりとした枠組みが必要な開発

ROS1がこれまで満たしてきたニーズを維持しつつ，このような新たなニーズも満たしていくために，ROS1と切り分ける形でROS2が生まれました．

詳しい内容は，こちらのサイトに記述されています．

著者:東風上奏絵

World MoveIt! Day 2018 in 柏の葉

World MoveIt! Dayが来週です！

皆さんはMoveIt!を知っていますか？ MoveIt!とは，マニピュレータ用のプランニングフレームワークです． MoveIt!を使うことで，サーボの１つ１つを別々に制御するのではなく，一つのマニピュレータとして扱い，動かすことができます．

World MoveIt! DayはMoveIt!のコード，ドキュメント，コミュニティをますます発展させていくことを目的とした国際的なハッカソンです．今年の日本でのイベントは千葉県の柏の葉で，来週末に開催されます！

詳しい内容と参加登録はこちらのConnpassのページをご覧ください．

• World MoveIt! Day 2018 in Kashiwa-no-ha（柏の葉）

何を準備すればいいの？

ハッカソンなんて敷居が高い？いえいえ，そんなことはありません．コードやドキュメントの修正案として，以下のようなものが事前に与えられています．参加する前に，ぜひ一度目を通してみて，出来そうな課題があれば，取り組んでみてください．

（公式のイベントサイトに記載されているものを簡単に和訳しました．）

• moveit day candidate: ハッカソン参加者におすすめの課題
• simple improvements: 参加者のバックグラウンドに応じて，数時間くらいで解決できるかもしれない課題
• documentation: チュートリアルやウェブサイトの更新

例えば，このIssueでは，テストコード（ユニットテスト，インテグレーションテスト両方）がたくさん必要だと提案されています．このIssueでは，RVizのバージョンが上がった時に使用できないフォントを，MoveIt!で使わないようにしようとしています．このIssueでは，moveit_python （MoveIt!のPythonインターフェース）の中身を充実させていこうと提案がされています．このIssueでは，もっと初心者に分かりやすくなるように，RVizを使ったMoveIt!のチュートリアルの内容を整えていこうとしています．このIssueでは，SRDFの文法エラーがあったら，MoveIt!がエラーを出すようにしようと提案されています．

初学者がドキュメントを更新していくことも推奨されています．たとえばこのIssueは，既存のチュートリアルがちゃんと動くか，順を追って確認する，という内容になっています．MoveIt!初心者でも，当日チュートリアルをやりながら修正案を出していくのはできそうですね！

ぜひ一度目を通して，自分で取り組めそうなIssueがあれば，チャレンジしてみてはいかがでしょうか？その際には他の人と作業がかぶらなくてすむように，予めIssueにコメントしておきましょう．assignedタグは，その課題に取り組んでいる人が既にいるかどうかを判断するのに便利です．

参加しましょう！

参加の際はROSのKinetic LTS branch/releaseをインストールされたパソコンをお忘れなく．Kineticの入ったUbuntu16.04のVirtualBox イメージは公式イベントサイトからダウンロードできます．他のROS バージョンについては公式イベントサイトをご確認ください．

それでは，当日会場でお会いしましょう！