2016年12月5日月曜日

Pynaoqi SDK 2.1.4をUbuntu 16.04で動かすときにハマったことと解決策

僕はSoftbank Pepperを動かすSDKとしてchoregraphe,pynaoqi,qimessaging.jsを主に使っています。
先日Ubuntu 14.04をUbuntu 16.04にアップグレードして、pynaoqiの環境構築を行って動かしてみたところ、2つのエラーが発生しました。
 
エラー1 : libqipython.soを開けませんでした
pynaoqiでUbuntu 16.04でaldebaranの公式マニュアルの通りに環境構築をしたときに以下のエラーが発生しました。

>>> import naoqi
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
    import qi
  File "/path/to/pynaoqi-python2.7-2.1.4.13-linux64/qi/__init__.py", line 72, in <module>
    from _qi import Application as _Application
ImportError: libqipython.so: cannot open shared object file: No such file or directory


このエラーはpynaoqiディレクトリにあるlibqipython.soをqi/__init__.pyが発見できないというエラーです。
この問題は共有ライブラリのパスを通すことで解決できます。

export LD_LIBRARY_PATH="/path/to/naoqi:$LD_LIBRARY_PATH"
sudo ldconfig
 
を実行することで解決できます。 

エラー2  : libboost_python.1.55.0.soを開けませんでした
次に、
ImportError: libboost_python.1.55.0.so: cannot open shared object file: No such file or directory 
 というエラーが発生しました。

 qi/__init__.pyを見てみると、

    deps = [
            "libboost_python.so",
            "libboost_system.so",
            "libboost_chrono.so",
            "libboost_program_options.so",
            "libboost_thread.so",
            "libboost_filesystem.so",
            "libboost_regex.so",
            "libboost_locale.so",
            "libboost_signals.so",
            "libqi.so",
            "libqitype.so",
            "libqimessaging.so",
            "libqipython.so"
    ]


 というコードが発見できます。

 また、
readelf -Ws libqipython.so | grep "boost"
を実行すると、*boost*python*のキーワードが入ったシンボルが発見できるかと思います。

pynaoqiのディレクトリにはlibboost_python.soがあるので、
__init__.py -> libqipython.so -> libboost_python.so -> libboost_python.so.1.55.0
という依存関係が判明しました。

この問題は、libboost-1.55.0の共有ライブラリをpynaoqi/以下に入れれば解決できます。
Ubuntu 16.04では
ls /usr/lib/x86_64-linux-gnu | grep "libboost" 
apt-cache search libboost
を実行してみると、*1.58*というキーワードが発見できたことに対し、*1.55*のキーワードは存在しなかったので、ubuntu 16.04のPC内とaptレポジトリにはlibboost-1.58しか存在しないことがわかりました。

この場合は適当なライブラリに入っているlibboost_*.so.1.55.0の共有オブジェクトファイルを取ってくることで解決できます。

naoqi c++ sdkをダウンロードして展開し、lib/以下を見てみると、libboost_*.so.1.55.0の共有オブジェクトが発見できるので,
cp -a path/to/naoqicpp/lib/*.so*.1.55.0 /path/to/pynaoqi
を実行することによってこの問題を解決できます。

これで
>> import naoqi
が成功するとおもいます。

この記事はSoftbank Robotics Community Wikiにも投稿しています。(英語)
https://community.ald.softbankrobotics.com/en/forum/import-issue-pynaoqi-214-ubuntu-7956#node-12298

2016年12月2日金曜日

Pepperハッカソン & 講習会① : いきさつ


祖母の東京の家で暮らしていたPepperが金沢工業大学の研究所に引っ越ししてきました!
研究室のみんなはPepperに興味しんしん!
Pepperとあいさつしたり、一緒に踊ったりして、楽しみました!!!

でも、研究室のみんなは工学部の大学生!
今あるロボットを使うだけじゃなくて、作りたいのが工学部の学生!!!

そこでぼくが、Pepperハッカソン & 講習会を提案したところ、研究室の大学生から「やりたい!」「ぜひ!」「いいね!」という声が!!!!!

そこでPepperハッカソン & 講習会を企画・開催することになりました。
「研究室のゼミの一環としてやろう」という話が大学教授からも出て、開催が決定しました!



Pepperを通して、生活支援ロボットのソフトウエア・人工知能開発を体験してもらいたい!!
生活支援ロボットソフトウエア人工知能を自分で作ることの楽しさを知ってもらいたい!!

次回Pepperハンズオンについて書きます!お楽しみに!

2016年11月13日日曜日

つくばチャレンジ2016




















つくばチャレンジに参加してきました!!
自分が初めて参加したのは2014年にTurtlebotというロボットを使ったときにになります。そのときは1人チームでしたが、今回は他のメンバーのROSのプログラミングをサポートしたり、プログラムのROS化をサポートしたり、ソフトウエアのバグや障害が発生したときに対処する係でした!。
今年の記録は110mでした!


つくばチャレンジとは
ロボットが町を歩ける技術を確立することを目的としたチャレンジです。
ロボットが人間と同じように、自律で公園を走行させ、横断歩道などを渡らせます。
2kmのコースをロボットに走行させます。

つくばチャレンジでは色々な研究者と技術交換ができます。自分のチームは学生だけでなく、NVIDIAやパーソナルモビリティの会社の技術者などとも交流しました。

つくばチャレンジが研究からベンチャーにつながっていくような流れになってきているのを今回感じました。

今回使ったロボット:UNiMO

UNiMO AI



UNiMOはUNiMO社が開発したおしゃれな電動車いすです!
http://newatlas.com/unimo-continuous-track-electric-wheelchair/29748/
駆動部にはクローラーが付いており、雪道・雨道・坂道も気にすることなく走破できます。充電無しで20km走破できます!
 
今回はUNiMOのジョイスティックの信号をArduinoで制御し、LAN通信でArduinoとPCを通信しました。
自律走行のための科学計算はノートPCを使用し、PCとArduinoを通信させて制御しました。
自律制御の安定化のために駆動制御部のArduinoでPID Controllerを実装しています。
なお、ロボットミドルウエアはROSを使用しています。

 
制御システム

測域センサ/ジャイロセンサ -> SLAMプログラム(gmapping) -> move_base関連の自作プログラム -> geometry_msgs/Twist -> Arduino PID Controller -> 駆動部



ROSとは


ROSは世界で最も使用されているロボットのミドルウエアです。
シリコンバレーのロボットベンチャーのWillow Garageが開発し、現在はオープンソースです。
ROSはパッケージシステム, microservicesを採用したプログラミングモデル, 高度なプログラム解析システムがあります。
ROSのコアシステムはTCP/IPとXML-RPCによる通信で実装されているので、通信をさせるプログラムさえ書けばどんなプログラミング言語でもROSプログラムとして使用することが可能です。ROSは主にC++とPythonでプログラミングします。

ROSでプログラミングするイメージとしてはROSはNode.jsのエコシステムに近いです。
(npmパッケージによるプログラムの再利用、Node.jsのモジュール = ROSのmicroservicesプログラミング(Pub/Subモデルとトピック通信) )
必要な部分だけをプログラミングして、他の部分は既存のパッケージを使用することによって高速にロボットソフトウエアを開発することができます。
バグ解析なども、プログラミングフローグラフ可視化(rqt_graph)、2次元グラフ可視化(rqt_plot)、3D可視化(rviz)、CUI可視化ツール(rostopic)、ロボット制御データの保存・再現(rosbag)機能などを使用してスピーディーに行うことができます。

SLAMとは
Octomap

ロボットの自律走行に重要な技術としてSLAM(Simultaneous Localization and Mapping)があります。
これはロボットが各種センサを使用して、ロボットが走行中に地図を作成し、そしてロボット自身が自己位置を推定する技術です。 自律走行自動車もSLAMを使っています。

なぜ「自己位置を測定」ではなく、「自己位置を推定」であるかというと、SLAMのアルゴリズムはほとんどが確率ベースだからです。
「地点Aである」ではなく、「地点Aである確率がX%, 地点Bである確率がY%, よって地点Aである確率が最も高いので地点Aと推定する」です。


gmapping


つくばチャレンジ2016で採用したUNiMOのSLAMアルゴリズムはgmapping + amclです。
gmapping+amclは2DのSLAMアルゴリズムで、ROSでSLAMを使うのにあたって最も利用するのが便利なSLAMパッケージです。

昨年のつくばチャレンジはOctomap + humanoid_navigation(簡単な3D自己位置推定アルゴリズム)でSLAMをしたのですが、humanoid_navigationプログラムを使用するにあたって今年のPCは使用するのに必要なRAMのメモリが足りず動かなかったため、2D SLAMのgmapping + amclになりました。(ROSのプログラムの構造上Octomapで生成されている地図のメモリを2回RAMに読み込む必要があるため) Octomapとhumanoid_navigationを両方nodelet化してnodelet_managerで管理すればメモリ容量的に3D SLAMができたかもしれません。
大体3D SLAMの方が正確な自己位置推定ができます。(ランドマークの特徴量が多いため) 

Autoware
Autoware

humanoid_navigationをするのに必要なRAMのメモリが足りなかったため、採用候補の一つに入った3D SLAMアルゴリズムがAutowareのndt_mapping + ndt_localizationでした。
Autowareは名古屋大学, 長崎大学と産総研が開発した自律走行自動車のための開発キットです。オープンソースです。自律走行に必要な制御が色々とそろっていて、GUIツールでプログラムを動作できるので初心者も簡単に使用できます。

自律走行自動車に興味のある方はAutowareを動かしてみると楽しいと思います。シミュレータ + rosbag付きです。自律自動車の会社であるZMPが一部Autowareのプログラムを採用しているらしいです。
https://github.com/CPFL/Autoware

そのndt_mapping + ndt_localizationを以前つくばで走行させたデータのrosbag(過去のロボットの動作を再現するROS用ツール)を動かして試したのですが、角のカーブで地図生成が発散して使いものにならなかったのでAutowareの採用は断念しました。走行する道に直線が多い場合はndt_mapping + ndt_localizationは利用できるかもしれません。