先端技術調査グループの酒井です。
今年も Aptpod Advent Calendar 2019 に参加することになり 1日目を担当することになりました。
ちょっと前の話になってしまいますが、2019/12/2から始まるAWSのイベント 『re:Invent 2019』へ展示していることもあり、AWS RoboMaker 関連の取り組みをお送りします。
AWS RoboMaker（ロボット工学アプリケーションの開発、テスト、デプロイ）| AWS
AWS RoboMakerを使って、TurtleBot3 with OpenMANIPULATORに自社製品intdashを組み込んで、インターネット経由での遠隔制御に挑戦しました！ 成果物は 2019/6/12〜14に開催された AWS Summit Tokyo 2019で展示しました。
本記事ではその取り組みの中で、できたこと、できなかったこと、今後の展望などをまとめています。
ただ、AWS RoboMakerがTokyo Regionで提供される直前くらいからおおむね2か月くらいの取り組みだったので、できなかったことや積み残しも結構残っています。
できたこと
AWS RoboMakerと自社製品のintdash Edge Moduleを使って、インターネット経由でTurtleBot3を遠隔制御できるようにしました。
具体的には、
- PS3コントローラーを使って、TurtleBot3の実機とシミュレーション環境(Gazebo) 内のTurtleBot3を操作する
- 実機とシミュレーション両方を同時に操作する
ことができます。
実際の動画
実際に動かしている様子を動画で撮影しました。
一つ目の動画は、コントローラーで操作している動画です。
Remote control TurtleBot3 with AWS RoboMaker+intdash
二つ目の動画は、シミュレーション環境との同時操作とその結果を可視化している動画です。
Visualize remote control TurtleBot3 with AWS RoboMaker+intdash
取り組みの背景
AWS RoboMakerと自社製品intdashでコラボレーションしたものを何か展示できないかというのがきっかけでした。
弊社としては、intdashがRoboMakerで使えると、パッケージとしての提供やデプロイが可能になるので、自社のデプロイの工数を減らすことができる可能性があります。
また弊社の製品を提供するという視点だと、
- AWS RoboMakerを使うことによってROSの環境構築が簡単にできる点
- Amazon SageMakerなどのAWSのアセットとの連携がしやすくなるという点
がメリットとして考えられそうです。
ビジネス的な価値はまだ明確にできていないので、今後も検討したいと思います。
使用したロボット、環境、自社製品の紹介
TurtleBot3 with OpenMANIPULATOR
ロボットは、Turtlebot3 (with waffle pi) というロボットにOpenMANIPULATORというアームを取り付けた TurtleBot3 with OpenMANIPULATOR を使用しました。
Turtlebot3は研究、教育、プロダクトのプロトタイピングなどに使われるロボットです。ハードウェア、ファームウェア、ソフトウェアのすべてがオープンソースで開発されています。ROS界隈ではよく使われています。また、すぐに使える色々なパッケージが提供されています。例えば、Bluetoothで接続したコントローラーを使った操作、SLAMを使った地図作成、自己位置推定、Navigationを行うためのROSのパッケージが提供されています。
詳しい情報は、Robotis のサイトで見ることができます。
Open Manipulatorはロボットアームです。こちらもTurtlebot3と同様、ハードウェア、ファームウェア、ソフトウェアがオープンソースで開発されています。コントローラーを使った操作、軌道を生成して軌道通りにアームを動かすためのパッケージなどが提供されています。こちらも、Robotisのサイトに詳しい説明が載っています。
TurtleBot3とOpenMANIPULATORを組み合わせた時に必要となるファームウェアやソフトウェアなどもオープンソースで提供されています。
実際に組み立てた完成品は以下のようになります。
AWS RoboMakerの紹介
AWS RoboMakerは、AWSが提供するロボットアプリケーションの開発、シミュレーション（テスト）、デプロイが行えるサービスです。
開発
Cloud9を使って、ROSアプリケーションの開発ができます。Cloud9はクラウド上で開発ができる統合開発環境です。AWS RoboMakerでは、Cloud9にROSアプリケーション開発用の拡張がされています。それによって、ビルド、バンドル、シミュレーションジョブの起動までの処理をすべてCloud9 上から行うことができます。
※バンドルとは、ROSアプリケーションの実行時に依存するライブラリ群をすべてひとまとめにパッケージ化する処理のことです。必要なライブラリがすべてまとまっているので、デプロイ先ではライブラリの依存関係などに悩まされることを無くすための仕組みです。バンドルの詳細は公式のこちら で確認することができます。
シミュレーション（テスト）
実装したROSアプリケーションをGazebo、rqt、Rvizなどを使ってシミュレーションする環境がされています。またターミナルも用意されているのでコマンドラインを使うことも可能です。
シミュレーションには、turtlebot3_gazeboなどのシミュレーション環境上で必要なROSパッケージをまとめたSimulation Applicationと、（最終的に）実機にデプロイして使うROSパッケージをまとめたロボットアプリケーションをそれぞれバンドルしたものを使います。
下の画像は実際にシミュレーション環境でTurtleBot3 with OpenMANIPULATOR を動かした画面をキャプチャしたものになります。
デプロイ
AWS IoT Greengrassを使って、ロボットアプリケーションを実際の機体にデプロイできます。
※事前にTurtleBot3のRaspberry Pi上でGreengrassの設定が必要です。
デプロイを行うと、バンドルしたROSアプリケーションがGreengrass経由でTurtleBot3のRaspberry Piにダウンロード、展開されます。それらを使ってROSアプリケーションを実機上で起動します。
実際には↓のような画面からデプロイの設定を行います。
intdashとは？
自社で開発を行っている製品です。
intdashは、100ミリ秒∼1ミリ秒間隔程度の高頻度で発生する時系列データを品質保証のないネットワークを経由して、高速・大容量かつ安定的にストリーミングするための双方向データ伝送プラットフォームです。 intdashは、プラットフォームを構成する製品・サービスの総称(ブランドネーム)を兼ねており、 INTeractive DAta Streaming Hub の頭文字を並べた略称です。
https://www.aptpod.co.jp/basetech/ より
エッジデバイスから時系列のデータを収集する機構、サーバ側で時系列のデータを保存する機構、UIで時系列のデータを可視化する機構などを備えた製品になります。
双方向のデータのやり取りができるため、本記事のようにロボットを使用する場合は、モニタリングや遠隔制御に使うことができます。自社製品のintdash Edge ModuleはRaspberry Pi 上でも使えるので、今回はそれを使ってデータを流しています。
どうやって動かしたのか
操作側は、PS3コントローラーにRaspberry Pi を接続したものを用意しました。操作情報を送信する側と、Turtlebot3側にそれぞれintdash Edge Moduleを組み込みます。これにより、intdash Edge Moduleはrosbridge経由でPS3コントローラー側の操作情報を、TurtleBot3に渡すことが可能になります。
ROSはローカルネットワークで使うことを前提としています。調べた限りでは、インターネット経由でメッセージのやり取りをする標準的な方法はなさそうでした。なので、インターネットを経由して操作情報を渡すために自社製品のintdash Edge Moduleを使いました。
これによってPS3コントローラーから吸い上げた操作情報をTurtleBot3に届けて、遠隔で制御することができるようになりました。
データの流れ
ここから実際どういうメッセージが流れているかを説明します。
PS3コントローラーの制御情報は以下の図のように、
PS3コントローラー → PS3コントローラー用Raspberry PiのROSノード → intdash Edge Module → インターネット → クラウド上のサーバ → インターネット → intdash Edge Module → turtlebot3用Raspberry PiのROSノード → OpenCR
と伝達されます。
その結果をもとにdynamixel (モーター）を制御します。
具体的な制御メッセージは以下のように流れます。
PS3コントローラーからBluetoothでRaspberry Piに制御信号を飛ばします。PS3コントローラー側内部のROSのノードで信号を拾い
sensor_msgs/Joy型の/teleop/joyメッセージに変換します。変換された
/teleop/joyは、PS3コントローラー用Raspberry Pi上で動いているintdash Edge Moduleに渡されます。PS3コントローラー側のintdash Edge ModuleからTurtleBot3側のintadsh-edgeまで自社製品経由で、
/teleop/joyメッセージを送ります。PS3コントローラー側のintdash Edge Moduleがpublishした/teleop/joyメッセージを、turtlebot3側のintdash Edge Module がsubscribeする形になっています。turtlebot3側のintdash Edge ModuleはTurtleBot3用Raspberry Piの
/rosbridge_tcpに/teleop/joyメッセージを渡します。/rosbridge_tcpは、/teleop/joyメッセージをpublishします。これによって、インターネット経由で取得したPS3コントローラーによる操作情報が無事に、ROSのネットワーク内部まで到達しました。/om_with_tb3/teleop_twist_joyがsensor_msgs/Joy型のteleop/joyメッセージを受信します。/om_with_tb3/teleop_twist_joyは/teleop/joyメッセージを、geometry_msgs/Twist型に変換して、/om_with_tb3/cmd_velをpublishします。その後、
/om_with_tb3/cmd_velをOpenCR内部にいるROSノードが受け取って、TurtleBot3の車輪の制御をしているdynamixelを制御します。ちなみに、OpenCR上でもROSノードが動いていて、/om_with_tb3/cmd_velをsubscribe しています。また、シミュレーション環境では、/gazebo/om_with_tb3/cmd_velを受信します。
実現できなかったこと
アームを動かす
Turtlebot3に装着したOpenMANIPULATORを遠隔制御で動かすのは、今回のAWS Summit Tokyo 2019までの準備期間では間に合いませんでした。Gripperは動かすことができましたが関節は動かせませんでした・・・。
できなかった理由
原因として考えているのは以下の2点です。
- Turtlebot3にOpenMANIPULATORを装着した状態で、OpenMANIPULATORをコントローラーで動かす方法が見つけられなかった点
- 一般的にはMoveIt経由で動かします。（参考: http://emanual.robotis.com/docs/en/platform/turtlebot3/manipulation/）
- OpenMANIPULATOR単体をコントローラーで動かす方法はあります。しかし、TurtleBot3と結合した状態のOpenMANIPULATORをコントローラーで動かす方法は探した限りでは見つかりませんでした。
- ROSのノードの構成が、本来TurtleBot3で想定している構成と差異がある点
- 上記と関連しますが、
/arm/moveitは本来remote PCで動かすことを想定しています。 - Raspberry Pi上で
/arm/moveitを動かそうとしたが、クラッシュしてしまいました。ログを見た限りではメモリ確保の処理で落ちている挙動でした。Raspberry PiではRaspbianを使っていたので、元々64bit向けに実装されていた部分があったとすると、それを32bitで動作させようとしたことが原因になっているかもしれません。
- 上記と関連しますが、
データ吸い上げ
シミュレーション環境では実現できましたが、実機ではRaspberry Piの性能の問題で遠隔制御との両立ができませんでした。
詳細な調査はしていませんが、原因はパフォーマンスの問題の可能性が高いと考えます。内部のプロセスをhtopコマンドで確認したところ、rosbridge_serverのCPU使用率がほぼ100%に張り付いている状態でした。
rosbridge_serverの負荷が高かった原因は、TurtleBot3内部でodometry, imuがかなり高頻度でpublishされていた点と、PS3コントローラーからのメッセージもかなりの高頻度だった２点だと予想しています。
カメラを動かす
raspi-cameraは依存関係上バンドルされていなかったライブラリがあったのが原因で動いていませんでした。
今後試したいこと
rosbridgeに渡すデータ量を減らす
odometry、imuといった情報がかなりの高頻度でpublishされています。rosbridgeに渡す前にトピックの量を間引くことで、rosbridgeの負荷を減らすことはできると思います。PS3コントローラー側から出しているトピックも今はかなりの高頻度で出力しているので、これも操作に支障がないレベルまで減らすことができそうです。
トピック量を減らすことで、モニタリングと遠隔制御が両立できるとよさそうです。
OpenMANIPULATORを動かす。
Raspberry Pi自体はもともと64bitのアーキテクチャなので、Raspbianを別なOSに変えることも検討したいと思います。
Raspberry Pi置き換え。
Raspberry PiをJetsonなどのほかの組み込みボードへの置き換えが考えられます。Raspberry PiとOpenCRは、USB経由でシリアル接続をしています。だから、OpenCRとシリアル接続ができれば問題なく使えるのではと考えています。
これにより、CPUの処理負荷の問題は解決できると考えています。どのOSを使うかにもよりますが、64bitを想定した実装を32bit向けにビルドしている問題は解決も一緒に解決できる可能性があります。
Amazon SageMakerとの連携
完全に妄想ですが、集めたデータを、Amazon SageMakerを使って機械学習したり、そこから制御コマンド発行できたりする連携が可能になると面白いと思います。
ビジネス的な価値の検討
弊社の製品をAWS RoboMaker、あるいはAmazon SageMakerなどと組み合わせてどういう価値が生み出せるのか、まだまだ掘り切れてないところがあるのでそれを明確にする活動は今後も続けたいと思います。
AWS RoboMakerを使ってみて課題に感じた点
ROS Masterの構成の違い
一般的に使われているTurltleBot3とROSのネットワークの構成が違うのが課題に感じました。
調べた限りでは、TurltleBot3はもともとローカルネットワークで動くことを想定しています。AWS RoboMakerを使用しない場合は、以下の図のようにPCとRaspberry Pi上にROSのノードが存在しています。
これによって、PCとturtlebot3のRaspberry Piで動作が分散されます。例えば、SLAM はPCで動かすことが想定されています。またこのような構成の場合、ROS MasterはPC側で動かすのが普通なのではないかと個人的には思います。
一方、AWS RoboMakerを使用した場合、Greengrass経由でデプロイされるので、ROS Masterを含むすべてのROSノードがraspberry pi上で実行されます。そのため、Raspberry Piの負荷が高くなる可能性が高いです。
詳細な調査は行っていませんが、今回の構成でSLAMなどをRaspberry Pi側で実行するのは負荷的に厳しかったです。
確認はしていないですが、AWS RoboMaker経由でデプロイした場合でも、TurtleBot3と同じネットワーク上にいるPCを使って処理の分散はできるかもしれないです。
また、intdashを使うことで、PC上との分散処理が実現できる可能性もあると思います。
感想
私は今回がROSを扱うのが初めてでした。4月入社でAWS Summit Tokyoまではおおむね2か月ほどの開発期間でしたが、ひとまず動くものができてよかったです。また、AWS RoboMakerを使うことで、開発環境の構築は苦戦することなく、ROSの使い方を覚えて開発を進めることに集中できたのでよかったです。
技術的には、ロボットの物理的な組み立て、OpenCRを使ったファームウェア、Raspberry Pi、AWS上での開発、ROSの開発など短期間で集中的にいろいろなことができて楽しかったです。手探りの状態で少しずつ進めないといけなかった点はとても大変でした。
開発では、バンドルの処理時間が重かった点で苦労しました。バンドル処理は並列処理されずにCPU1コアで処理されます。処理にかかる時間はバンドルするライブラリやパッケージの量により変わります。私が試していたときは、10～20分くらいバンドルに処理がかかることがありました。実機へのデプロイ時には、デプロイしたファイルの展開にも10から20分くらい時間がかかることがありました。これによって、わからないことや動作を実機上で確認する試行錯誤のための待ち時間がかなり長くなってしまった点が大変でした。
この点やほかにもAWS RoboMakerを使っていて苦労した点などは、AWS様にフィードバックをする機会がありましたので、今後の改善に期待しています。
そういった中で驚いた点は、AWS RoboMakerの改善の早さです。
具体的に例を一つ上げます。当初はデプロイ先が/tmpでしたが、6/25辺りにgreengrass user直下のディレクトリに変更されました。当初はデプロイ先が /tmp だったため電源を落とすとすべてデータが消えてしまいました。greengrass user直下にデプロイ先が変更されたことによって、電源を切るごとにバンドルされたファイルをダウンロードして展開する処理が必要なくなりました。
また、私が開発している期間の中で、シミュレーション環境のダッシュボードの改善なども行われていました。
最初にリリースした段階でAWS RoboMakerのコアの機能は実装されており、そののちにユーザーの利便性のために改善していくという点がMVP（Minimum Viable Product）の考え方に近い感じがしてとても参考になりました。
以上になります。
最後まで読んでいただきありがとうございました！
おまけ1
本記事で扱ったAWS Summit 2019 Tokyoへ向けた取り組みを2019/11/13に『IoT@Loft #5 - クラウドとロボティクス、オープンソース活用による次世代ロボットの可能性』にて「AWS RoboMakerと連携するクラウド経由の遠隔制御の取り組み」というタイトルで発表させていただきました。
おまけ2
2019/12/2～12/6に米国ラスベガスで開催されるAWSのイベント 『re:Invent 2019』 にも展示します！ AWS Summit Tokyo 2019での展示よりも進化しています！続編に期待！？
