月: 2019年10月

ORBBECのAstra SはマイクロソフトのKinectと同じパターン照射タイプの３Dカメラで、距離画像が必要な産業用アプリケーション用途をターゲットに販売されています。

このAstraS用のROSライブラリが提供されていたのでインストールしてテストしてみました。

参考にしたサイト：　astra_camera – ROS Wiki

ROSについてはまだ手探り状態なので、詳しい手順についての説明は省きますが、やったことは以下の項目です。

1. catkin_wsにソースをダウンロード
2. catkin_makeでコンパイル
3. ~/catkin_ws/src$ roslaunch astra_camera stereo_s.launch で実行
4. 別のターミナルからrvizを実行して画像データを表示する

参考にしたサイトではubuntu 16.04向けのkinetic向けのサンプルということになっていますが、ubuntu 18.04向けmelodicでもとりあえず動作しました。

ただ、一日以上連続して走らせているとハングアップしてしまう症状が発生していて、これがバージョンの違いに起因するものかどうかは確認していません。

ROSロボット用センサとしての実用性

色々なサイトを見てもロボットを動かしながら自己位置推定と地図作成を同時に行うSLAMにはLRF（レーザーレンジファインダー）を使った例ばかりでした。
LRFは水平面で回転するレーザービームで障害物の距離を測るのでロボットの目線の高さの平面にあるものしか検出できませんが、検出距離が３０ｍ以上で屋外での使用にも耐える特性を持っています。

Astra sはSimpleViewerで確認すると有効距離８ｍで30fpsの距離画像を取得できるので、室内での低コストロボット用センサとしてなら、かなり使えそうな気がします。

しかし、ROSで距離画像を取得すると1～2fpsと極端に応答が悪くなってしまいます。
LRFでは2次元の視野なので最大1000データ/scan × 10 / secで、毎秒10,000個のデータを取り込むのに対し、Astra-Sでは640 x 480 x 30fps = 毎秒9,216,000データを取り込んでいます。
これではリアルタイムで距離画像を取得しながらロボットを動かしてマップを生成するSLAMに使うのは難しい印象です。

単に私が使い方を理解していないせいで応答性を上げる手法があるのかもしれませんが、３Dカメラ内部か距離画像を取り込んだ時点でリサンプリングして、例えば画素数を６４ｘ４８に減らすなどすれば3次元データが取れる特性を活かすことが出来るのではないかと思います。

ROSの活躍場所

ROSについてWebで検索すると様々なセンサやアクチュエータを標準的なプロトコルで接続することが出来るシステムで、例えばパナソニックの収穫ロボットなど実用的なロボットにも採用されたとのプラス面を強調した謳い文句ばかり目につきます。

また次のサイトなどを見るとアームロボットの制御にもROSが活躍するような印象を受けていました。

ROSによるロボットアームの制御

しかし、ROSを触っているうちに現段階のROSは実用的なアームロボットの制御に使うものではなく、ロボット全体とLRFや３Dカメラ及びSLAM等の高度なアルゴリズムによるソフトウェアモジュールを使ってみるための研究向けシステムなんだなと思えてきました。

Astra Sという３Dカメラをご存じでしょうか。

Astra SはマイクロソフトのKinectと同じパターン照射タイプの３Dカメラで、私の会社ではピッキングロボットのワーク検出など、距離画像が必要な産業用アプリケーションで活用しています。

特殊なレーザーパターンを照射して距離画像に変換するキネクトや、光が発光してから戻ってくるまでの微小な時間を測定して距離画像を求めるTOFタイプの民生用３Dカメラが発売されたことで、産業用アプリケーションでの３Dカメラ活用場面が一挙に拡大しました。

しかし、キネクトはマイクロソフトの都合に振り回され、ASUSのTOF３DカメラはAppleに買収されて一般向けのものが消えてしまい、残念な思いをしていました。

このORBBECはキネクトと同じ原理のカメラで、産業用途やロボット研究開発をターゲットにしているようで安心して使えるのではないかと期待しています。

価格もUSD$149.99で、産業用途向けの３Dカメラに比べて格段に安く手に入るのがうれしいところです。
日本で販売している窓口もありますがORBBECのサイトにアクセスして右上のBuyというボタンから販売ページに飛ぶことが出来て、カードさえあれば表示価格＋日本向け送料で注文から数日で送ってくれます。

この３Dカメラの在庫が会社にあったのでRaspberry Pi 4に接続してみたところLinux用のサンプルビューワーとROSのサンプルで動作が確認出来ました。

動作環境：Raspberry Pi 4 4GB + Ubuntu 18.04 + ROS melodic

ROSをインストールするためにRaspberry pi にはUbuntu18.04をインストールしました。
ROSを紹介してあるWebの記事やROSサンプルプログラムにはUbuntu 16.04対応のROS kinetic を使った例が多いのですが、Raspberry pi 4にインストール出来るUbuntuイメージが 18.04しか見つからなかったので Ubuntu 18.04 対応のROS melodicを使っています。

Ubuntu用デバイスドライバ

Develop with OrbbecからOPENNI SDKをダウンロードします。
Raspberry pi からwgetコマンドでダウンロードすると良いでしょう。
Unzipコマンドで解凍すると色々なターゲット用のOPENNIが入っているので
OpenNI-Linux-Arm64-2.3.0.63を使います。
下の例は、ダウンロード後解凍して必要なディレクトリを/home/xxxにコピーしています。

$ cd ~/Downloads
$ wget http://dl.orbbec3d.com/dist/openni2/OpenNI_2.3.0.63.zip
$ unzip OpenNI_2.3.0.63.zip
$ cp -r OpenNI_2.3.0.63/Linux/OpenNI-Linux-Arm64-2.3.0.63 ~/

ディレクトリOpenNI-Linux-Arm64-2.3.0.63にあるReadmeがインストール手順ですが、Intel64をターゲットにした例なので注釈を入れておきます。

# There are two zip files, one is for 32bit machine, the other one is for 64bit # We choose 64bit(x64) and make the example as follows:
実際は、ダウンロードしたファイルの中にLinux用の他Windows用等のファイルが含まれていて、Linuxの下に Arm32, Arm64, X64, X86対応のドライバが入っています。

# To run visual samples(e.g., SimpleViewer), you will need freeglut3 header and libaries, please install:
必要なヘッダとライブラリをインストールする必要があります。

$ sudo apt install build-essential freeglut3 freeglut3-dev

#check udev version, Orbbec Driver need libudev.so.1, if can’t find it, can make symbolic link from libudev.so.x.x, #which usually locate in /lib/x86_64-linux-gnu or /lib/i386-linux-gnu

Orbbecのドライバはlibudev.so.1を必要とするので、もし見つからなかったら libudev.so.x.xからシンボリックリンクを作る必要があるとのことですが、/lib/aarch64-linux-gnu/libudev.so.1 があったので下の操作はパスしました。

$ldconfig -p | grep libudev.so.1 
$cd /lib/x86_64-linux-gnu 
$sudo ln -s libudev.so.x.x.x libudev.so.1

# copy tgz file to any place you want(e.g., Home) # unzip tgz file $ tar zxvf OpenNI-Linux-x64-2.2-0118.tgz $ cd OpenNI-Linux-x64-2.2

これは解凍して必要なディレクトリを/home/xxxにコピーする操作で、最初に説明した内容です。

install.shを実行します

# run install.sh to generate OpenNIDevEnvironment, which contains OpenNI development environment 

$ cd ~/OpenNI-Linux-Arm64-2.3.0.63
$ sudo chmod 777 install.sh
$ sudo ./install.sh

 please replug in the device for usb-register
USBコネクタを抜き差ししてデバイスを登録します

# add environment variables
環境変数を登録します

$ source OpenNIDevEnvironment

 # build sample(e.g., SimpleViewer)
サンプルプログラム SimpleViewerを実行します

$ cd Samples/SimpleViewer 
$ make 
$ cd Bin/Arm64-Release 
$ ./SimpleViewer

# now you should be able to see a GUI window showing the depth stream video
これでGUIウィンドウにデプスデータが表示されるはずです。

 

 

Raspberry Pi 3で最も多いトラブルは電源関係のトラブルみたいです。
Raspberry Pi 4ではUSB3.0ポートが使えるようになり消費電流も大きくなっているはずなのでさらに電源に気を使う必要があります。

私の場合も最初は環境の構築途中でハングアップすることが多かったので熱暴走を疑ってヒートシンクを取り付けたり色々と対策しました。

試行錯誤した後で、それは不安定な電源電圧によるものだったことに気が付きました。
上の写真で電源電圧が5.14VになっているのでOKと思っていましたがdmesgのログを見ると、Undervoltageの嵐！

Raspberry Piのコネクタに出ている５Vをテスターで測ると 4.74Vしかありませんでした。
4.7Vを切るとUnder voltageが表示されるそうなので、細かい電圧変動でたびたび4.7V以下になっているのでしょう。

最初は深く考えずに消費電流と電圧を調べるためにUSBに差し込む写真の電流電圧表示ユニットを使っていましたが、これを外してRaspberry piのコネクタで測ってみると4.94Vとなりました。

電流電圧表示ユニットの電圧降下が0.2Vあったようです。電源のところで5.15Vでしたから残りはケーブルとRaspberry pi内部のUSBコネクタから電源を取り込む部分の電圧降下でしょう。

試しにUSBケーブルを一番短くて太いものに変えると4.99Vになり、0.05V改善されました。USBケーブルの影響はあまり無いみたいです。

Amazonで買ったRaspberry Pi 専用電源なるものをテストすると、Raspberry Pi のコネクタで5.4Vとなりました。

Smraza Raspberry Pi 4 用USB-C 電源アダプター 5V 3A

ということは、USBコネクタ入力部の電圧損失を見越して5.5V以上の電圧を出していることになります。
反則のような気もしますが、内部では5.5V未満の電圧に収まっているし実際に回路で使う電圧は内部のレギュレータが作る3.3Vですからこれで良いのでしょう。