ROS + Snappy Ubuntu Core (1) : いったい何なの?

iPhoneのAppStoreやAndroidのGooglePlayのようなアプリのマーケットインフラを、ロボットの世界にも導入するためにはどのような課題があるでしょうか?ROSはその開発当初から「Robot App Store」を視野に入れてきていますが、まだ実現していません。

その中で、最近のUbuntu Snappy Coreと呼ばれる仕組みの登場は、Robot App Storeの開設に大きく貢献するのではないかと思われます。

Snappy + ROS, https://www.crowdsupply.com/krtkl/snickerdoodle/updates/1890

今後、数回に分けて、Ubuntu Snappy CoreとROSについて書いていきたいと思います。

Ubuntuの事情

ROSがメインのベース・オペレーティング・システムとしているUbuntuは、年に2回のRegularリリースがあり、そのサポート期間は9ヶ月です。また、2年おきにLTS(Long Term Support)と呼ばれるリリースがあり、サポート期間は5年です。実用を求める人は安定なLTSを使いつつ、最新技術の取り入れや新規開発はRegularリリースを使う、というサイクルが続いています。

しかし、Ubuntuが対象とするデバイスは、デスクトップPCやサーバだけでなく、IoTやルータなどのエッジデバイスにも広がりつつあります。残念ながらUbuntu Phoneはついに陽の目を見ないことになるようですが…

これらのデバイスでは、セキュリティの観点から、Ubuntuのような同期的なものではなく、もっと不定期かつ細かい間隔の継続的なアップデートが欠かせません。また、耐障害性、たとえば不具合を含むソフトウェアが配信された際にロールバックする、などの機能が必要になります。

Snappy Ubuntu Core

これらの要求に対して、Ubuntuでは、IoTやエッジデバイス向けに、(Snappy) Ubuntu Coreと呼ばれる仕組みが開発されています。

これは、OSとデバイスドライバの分離、またカーネルとアプリケーションを分離して、それぞれを独立に、細かい周期でアップデートできるような仕組みにしよう、というものです。

ROSの事情

ロボットもまたIoTやエッジデバイスの一種と見ることができるため、今後ROSでも、このSnappyなパッケージシステムが主流になる可能性があります。また、ROSのリリースシステムも、ほころびが目立つようになってきています。

これまでROSはUbuntuと同様に、同期的なリリースを行ってきました。しかし、1年に1回のリリースでは、日進月歩の技術を取り入れるのに遅れが大きすぎる気もします。一方で、ROSを業務に使用する場合には、動作させることが優先され、頻繁にアップデートしない(できない)ようになってしまいがちです。

また、ROSのパッケージは、たくさんの外部ライブラリに依存しています。外部ライブラリのAPIが変更になるたびに、ROSのパッケージもそれに対応させる必要があります。仕様が変わる場合には、パッケージを対応させた上に動作確認も必要です。

そのため、リリースされるたびに、リリースから外れていくパッケージが多くなってきました。必要だしよく使われるパッケージであるにもかかわらず、リリースのために修正が必要だけど修正作業を行うメンテナがいない、という理由でリリースされなかったり、リリースが遅れたりするケースもあります。

もしROSを搭載したロボット製品を販売しようと考えた場合、UbuntuやROSが更新されたタイミングで、どのような仕様変更や不具合が混入するかわからず、それに対応するには膨大なリソースが必要であることが予想されます。

以上のようなことから、今後はSnappyなROSシステムが主流になるのではないかと、勝手ながら予想しています。

Canonicalにお勤めのロボットエンジニアの方(Kyle Fazzari氏)が精力的に情報発信をしているのも頼もしいです。4月に公開された以下の一連のブログと動画も必見です。


Roomblock(4): 低価格なレーザ距離計 RPLIDAR A2

今回は、自律移動のためのキーパーツである、レーザ距離センサについて紹介します。レーザースキャナ、LIDAR(Laser Imaging Detection And Ranging)とも呼ばれます。

弱いレーザービームを発光し、物体への反射光を計測して、その時間差により物体までの距離を測ります。計測部分を回転させながら計測(スキャン)すれば、平面内の物体までの距離が計測できます。レーザービームを複数並べたり、細かく向きを変える機構を使うことで、平面内だけでなく3次元的な計測点が得られる3次元レーザ距離センサもあります。

一般的にレーザー距離センサは、2次元のものでも数十万円していたので、そう手軽に使えるものではありませんでした。しかしRoomblockで使っている SlamTech社のRPLIDAR A2 は、なんと5万円程度と破格なのです。

自律移動のキーパーツ、LIDAR

自律移動のキーパーツ、LIDAR

RPLIDAR用のROSドライバが公開されています。

$ sudo apt install ros-kinetic-rplidar-ros

として、

$ roslaunch rplidar_ros view_rplidar.launch

とするだけで、rvizで計測した点が表示されるお手軽さです。

rvizで表示した距離データ

rvizで表示した距離データ

計測可能距離は16m, 更新周期は10Hzと、高価なレーザスキャナと比べて性能では劣るものの、通常の屋内であれば地図生成や自己位置推定に問題はありません。スキャンは1度刻みで360度なので死角がありませんが、センサ上部がむき出しのままぐるぐると回転するので、動作中に触ってしまわないように注意が必要です。インターフェースはUSB2.0で、バスパワー駆動なのもうれしいところです。

laser_scan_matcherパッケージで少し遊んでみましょう。

$ roslaunch rplidar_ros view_rplidar.launch

としてセンサを起動した後、

$ rosrun laser_scan_matcher laser_scan_matcher_node _base_frame:=laser

として、センサの水平を保ちながら、ゆっくりと動かしてみます。

スキャンマッチング

スキャンマッチングの様子

初期状態ではworld座標系と一致していたlaser座標系が、センサの動きに応じて位置と姿勢がレーザのスキャンマッチングにより更新されていきます。センサを元の位置、姿勢に戻すと、だいたいworld座標系に一致しています。ただ、レーザのスキャンマッチングでは、フレーム間の移動量を推定してこれを積算するので、長く移動させるとエラーも積算されていきます。これを避けるためには、より高度な自己位置推定のアルゴリズムが必要になります。

Roomblockの詳細な作り方については、Instructablesで公開しています。ただし当社は、これらの内容によって生じるいかなる損害についても責任を負いません。興味がわいた方はあくまで自己責任で、チャレンジしてくださいね。


ルンバとラズベリーパイとレーザ距離センサによる自律移動ロボット Roomblock(3)

前回はルンバと通信するためのROIコネクタについて紹介しました。今回はルンバと通信するための計算機として用いている、ラズベリーパイ(Raspberry Pi)について書きます。

ラズベリーパイについては改めて言うまでもないかもしれませんが、低価格なARM搭載のボードコンピュータです。Roomblockで用いているのはラズベリーパイ2です。通常のPCと同じように、Ubuntuをインストールしたあと、ROSをインストールすることができます。

IMG_2457

Raspberry Pi 2

ルンバのROIコネクタとラズベリーパイは、USB-シリアル変換器を使って接続します。変換器を内蔵したケーブル秋月電子で購入できます)を使うと、ミニDINコネクタとはんだ付けするだけで写真のようなケーブルが出来上がります。Roomblockで唯一のはんだ付けが必要な部品ですが、3,4箇所をはんだ付けするだけなのでそれほど難しくないと思います。


IMG_2328IMG_1720 (1)
USB-シリアル変換ケーブル
「ラズベリーパイ自身がシリアルポートを持っているのではなかった?」と思った方、その通りです。工作の手間ができるだけ少なくなるようにUSB-シリアル変換器を使っていますが、おそらくラズパイの内蔵シリアルポートを配線しても動作すると思います。興味のある方は試してみてください。

ラズベリーパイの電源はどうしましょうか?ルンバのROIポートにも電源が出ているのですが、これはルンバのバッテリの電圧がそのまま出ているので、使う場合には電圧の変換が必要になってしまいます。Roomblockでは市販のUSBモバイルバッテリーを別電源として使用することにしました。10000mAのものが3000円程度で購入できる、良い時代になりました…これでラズベリーパイを数時間は動作させることができます。

IMG_1618

USBモバイルバッテリー

今回はここまでです。次はレーザースキャナについて紹介します。

Roomblockの詳細な作り方については、Instructablesで公開しています。ただし当社は、これらの内容によって生じるいかなる損害についても責任を負いません。興味がわいた方はあくまで自己責任で、チャレンジしてくださいね。


ルンバとラズベリーパイとレーザ距離センサによる自律移動ロボット Roomblock(2)

Roomblockに使えるルンバは、500, 600, 700, 800 シリーズと呼ばれるものです。これらの機種は、外部と通信するためのシリアルポートを備えています。ただし、現在の最上位機種のルンバ900シリーズは、画像による地図生成までできるすごいものですが、シリアルポートを備えていないのでRoomblockのベースとしては使用できないので注意してください。

ところでそのシリアルポートはルンバのどこにあるのでしょう?シリーズにより位置が異なります。500シリーズ、600シリーズは、上面のカバーを外さなければなりません。このカバーは4か所のツメで固定されていて、最初は少し硬いので外すのに力が必要です。ケガや破損に十分注意してください。


IMG_2455IMG_2453
Roomba 500シリーズのROIコネクタ
カバーを外すと、ミニDIN7ピンのコネクタが現われます。これがROI(Roomba Open Interface)コネクタと呼ばれるものです。

700シリーズ、800シリーズは、ルンバ上面の取っ手の下にROIコネクタがあります。カバーを外す必要はなく、取っ手を持ち上げるだけでアクセスできます。


IMG_2450IMG_2451
Roomba 700シリーズのROIコネクタ
以前は、このROIコネクタをPCと繋げるためのケーブルや、BluetoothWiFiで無線化するモジュールが販売されていましたが、、今は手に入らなくなっています。Roomblockでは、ルンバの上に搭載した計算機(ラズベリーパイ)をROIコネクタに接続しますが、これについては次回紹介します。

Roomblockの詳細な作り方については、Instructablesで公開しています。ただし当社は、これらの内容によって生じるいかなる損害についても責任を負いません。興味がわいた方はあくまで自己責任で、チャレンジしてくださいね。


Roomblock: ループを含む大きな建物での地図生成

名城大学構内で実験させていただいたデータから、ROSの地図生成パッケージで地図を生成してみました。データはROSのbagファイルとして取得したので、同じデータに対して異なる地図生成パッケージを適用することが可能です。

ROSの地図生成のパッケージとして、

  •  gmapping
  •  slam_karto
  • hector_slam
  • Google cartographer

の4つのパッケージを用います。

これまで家屋や廊下など、比較的狭い環境で地図を作ってきました。それらの環境ではどの地図生成パッケージも、(誤差はともかくとして)、自律移動に使えないような大きく矛盾する地図を作成することはありませんでした。狭い部屋では、基本的にレーザセンサのデータをずっとつなぎ合わせ続けることで、部屋の地図を作ることが可能です。

しかし、今回のデータは非常に大きな建物の長方形の廊下を一周したものです。廊下を一周回って元の場所に戻ってきた時、それが元の場所であることを認識せず、そのままレーザセンサのデータをつなぎ合わせていくと、最初に作った地図と矛盾したものを上書きし続けてしまいます。これを避けるためには、現在居る場所が以前来たことのある場所であると認識した上で、地図全体を辻褄があうように生成しなければなりません。これは”loop closure”と呼ばれ、地図生成では非常に難しい問題です。

以下の動画は、4つのパッケージで地図を生成した結果をまとめたものです。地図のグリッドサイズは5cmとし、各パッケージのパラメータのほとんどはパッケージの規定値のままで、一部のパラメータのみ少し調整しました。

gmappingは非常に健闘しました。途中の廊下は真っ直ぐになっておらず、地図の形は後半にかけて不正確になっています。これはルンバのあまり正確でないオドメトリを少し信頼しすぎているようです。しかし、一周回ってきた最後に注目してください。以前来たことのある場所だと認識し、辻褄があうように地図全体を変形させました。矛盾のない、ほぼ正しい地図が出来上がりました。

slam_kartoは、今回はloop closureの検出に失敗してしまいました。一周回ってきた後、最初に作った地図を破壊しながら、新しい地図を上書きしていきます。矛盾した地図となってしまいました。

hector_mappingには、じつはloop closureの機能がありません。また、車輪の回転速度(オドメトリ)を使っていません。そのため、この環境ではうまく地図を作ることはできませんでした。

Google cartographerは最後発で、しかもこのような大規模環境の地図を作るために開発されたアルゴリズムです。やはりループを正しく閉じることに成功しました。


gmapping_mapkarto_maphector_mapcartographer_map

最終的に生成された地図(左から、gmapping, slam_karto, hector_slam, cartographer)

 

以上の結果は、どのパッケージやアルゴリズムが優れているか、どのパッケージを選ぶべきかということを示すものではないことに注意してください。今回、パラメータはほとんどチューニングしなかったので、それぞれのパッケージの最高の性能が出ているわけではありません。また、それぞれのアルゴリズムには得意不得意があるので、課題に対してどれが良いかは、実際に試してみないと分からないことが多いはずです。

現在のところROSはこのような様々な地図生成パッケージを比較検討できる唯一のプラットフォームです。オープンソースの利点を活かし、ぜひご自分の手で確かめてみることをお勧めします。

TORKでは、自律移動編を含むROS初級、中級のワークショップ、企業や大学でのプライベートワークショップのご依頼も承っております。お気軽にお問合せください!
info[at]opensource-robotics.tokyo.jp