2017年2月
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28        

Amazonウィジェット

  • miniPC
  • 最近買った本
  • Raspberry Pi
  • クアッドコプター
  • 書籍ランキング

AdSense

  • 広告
無料ブログはココログ

« 2015年7月 | トップページ | 2016年1月 »

2015年10月

2015年10月17日 (土)

ROSでSLAMマッピングを試す。

グーグルカーで話題になったSLAMという技術は、ROSをインストールすることで簡単に試すことができる。周囲環境のマッピング技術が簡単に使える分、ロボットでやらせてみたいことに集中して取り組むことができるのが、ROSを使う大きなメリット。

動作に成功すると、こんな風に部屋のマップを作れる。
※散らかっているのであんまり広くはないが。。。

Screenshot_from_20151004_182826

<<使う機材リスト>>
KOBUKI  RTロボットショップで入手。
 ※今はkinect付きのturtlebotしかカタログにない??

URG-04LX
レーザーレンジファインダー。レーザー距離計をモーターでぐるぐる回して、0.25度ステップで周囲のマップを得る凄いセンサ。部屋の形状が詳細にスキャンできる。数年前に東大がNHKロボコンで使っていたのを見たのが最初だったなぁ。ちょっと高いが何かと面白い。移動ステージと組み合わせたら3Dスキャナーなども作れそう。

ubuntu14.04(LTS)をインストールしたPC
 最初に見たのはMaker::Faire大垣だった。なんかテレオペレーションロボットに搭載されていたような。そこそこの性能でLinuxが入って、消費電力が小さいので試しに購入。軽いので持ち運びが楽。

ROS
  indigo Igrooを使っています。
 

下記より簡単に手順だけ紹介


まずはマスターを起動。

 

$ roscore &

<<kobukiとLIDARの起動>>

hokuyoの使っているUSBポートのパーミッションを変更する。

$ sudo chmod a+rwx /dev/ttyACM0

launchファイルから一括でkobukiとLIDARのセッティングをする。

launchファイルを落として、下記コマンドを実行すると、URGを動かすノードと、KOBUKIのノードと、KOBUKIをキーボードで動かすノードが一斉に起動する。
「kobuki_slam.launch」をダウンロード

$ roslaunch kobuki_slam.launch


<<マッピングのノードを起動>>

マッピングのノードを起動。このノードが/mapトピックを吐き出す。


$ rosrun gmaping slam_gmapping

<<視覚化ツールを起動>>

$ rosrun rviz rviz




<<rvizの操作>>

Rviz_topic

1.add (by display type) LaserScanを選んで、Topicの欄に、/scanを入力。

2.add (by display type) TFを追加。  Framesのプルダウンメニューに、登録したフレームが全て表示される。

3.add (by topic)で/mapを追加。 すると画面の色が青磁色に変わる。
なにか不足があるばあいは、WarningやErrorが表示される。
不足しているノードがないか。TFの登録が正しいかを確認する。



ここまでで、正しくTFツリーが登録されると下の画像のようになる。

ここまでくるまでに、ROSのTFをデバッグするためのツールである、rqt_tf_treeを使って、TFツリーの構造を確認しながら1ステップずつ作っていった。使い方はrqt_graphと変わらない。

サンプルのbagファイルを再生して、それがどんなTFツリーを持っているかを解析するのも有効な方法だった。

ROSではプログラムだけをポンと公開するのではなく、それを正しく動かしたときのデータが一緒に提供されていることも、非常に役に立ったし、デバッグのためのツールが使いやすいことも助かった。

Gmapping_frame_graph__frames




static_transform_publisherノードの活用が肝になっていて、
launchファイルの一個目に出てくるstatic_transform_publisherで、

 

mapというフレームを親とする、odomフレームを作っている。
これがTFツリーの全ての始まりとなる。ツリーの一番上に来るフレームのフレーム名は、全く決まっていない。

だから、どこかで親子関係を示してやることによって、ここではmapフレームがツリーのトップにくる。ツリーのトップに来ているフレームが、全てのフレームの基準になる。

※この例では、mapとodomには座標系同士にズレがないとしている。別にmapとodomはずれていてもよく、サンプルのturtlebotをシミュレータで動かすSLAMのデモでは、スタート地点をセットするためにmapフレームとodomフレームの間に平行移動がセットされていた。

2つ目のstatic_transform_publisherノードは、kobukiが出しているbase_footprintというフレームと、base_linkの関係をTFツリーに登録している。

base_footprintは、kobukiがいる床面上にあるので、base_linkで車輪の上まで10cm持ち上げてみた。このあたりは使うマシンによってカスタマイズできる。

 

3つ目のstatic_transform_publisherノードで、先ほど作ったbase_linkフレームを親として、laserという子フレームを作った。

つまずきポイント
非常にややこしい部分になるのだが、このlaserというのは、レーザースキャナが出しているトピックではなく、TFに登録されるフレーム(座標系)である。

フレームとトピックはしっかり区別しなければならない。
rvizで表示を見る場合は、/scanだし、TFで表示されるのはLIDARのいる位置を示した座標系マーカーである。rvizで/laserを指定しても、エラーになるのはそういう理由。


以上で準備が整うので、KOBUKIをキーボードで操作して、レーザーレンジファインダーでデータを集めて回ってみよう。

roslaunchでkobuki_slamを実行した端末をアクティブにすると、キーボード操作ができる。矢印キーを押せばkobukiが走り出すはずだ。

しばらく走り回れば、最初はいびつだったマップが再計算されることで、きちんとした形を成すようになる。ただし壁にぶつけたり、車輪が浮いて空回りになったりするとマップの精度が落ちるので注意。






2015年10月16日 (金)

ROS hokuyo_nodeを使う。launchの使用方法をマスター

ROS Indigo (OS:ubuntu14.04)
hokuyo URG-04LXを使って、このレーザースキャナのスキャンできる範囲をフルで使えるようにlaunchファイルを書いてみた。デフォルトで用意されているlaunchファイルでは、180度までしかスキャンできないのだが、パラメータをいじることで変更することができる。

hokuyo_nodeで設定するparamをlaunchファイルで書いておけば、起動が一発でできるのではないかと考えた。

参考HP: 日本語でまとめてある
launchファイルの例



paramの設定を一発でできることはかなりのメリット。 どんなパラメータがあって、どういう型を入れればいいのかをまず調べることにした。
hokuyo_nodeのポートの設定は、逐一コマンドで打ち込むときは、

 

$ rosparam set hokuyo_node/port /dev/ttyACM0

としていた。

rosparam get /

とすると、パラメータすべてが表示される。 どんな項目が設定できるかが一望できるのだ
これをlaunchファイルでやろうとしたのだが、ROSwikiには、typeとして(int,double,str)が指定できるとある。 ためしに、


と打ち込んでみたら、うまく動作した。ただし、/dev/ttyACM0へのパーミッション変更は別途必要になる。起動時にすべてのデバイスをつないでおいたほうがよい。
あとは、デフォルトのlaunchファイルでは180degまでしかスキャンしないので、 URGの本来持っている240degまでスキャンできるよう設定変更してみた。



ここのvalueはradで指定しなければならないので、ubuntuの電卓を使ってみた サンプルのlaunchファイルの中では1.57radは90degなので、これを120degにすればよくて、2.09radが正解。

応用編として、hokuyoを2台使うときのlaunchファイルの例が載っている。
ポイントは、同じ種類のノードを違う名前で立ち上げること。




2015年10月14日 (水)

ROS 複数のPCを使ってノードを走らせる場合。

2台のPC間でROSを走らせ、wifiなどで遠隔操作する方法の紹介。
このテクニックを使えるようになると、ロボットを遠隔操作で自由に走らせることが出来るようになる。

ロボットに搭載するPCは、今までノートPCが主流のようだったが、ミニPC(LIVA, ZOTAC, intelNUCなど)やスティックPCなど色々選択肢が増えたが、RaspberryPi2にUbuntuをいれてポータブルバッテリーで使うやり方が一番便利だった。

複数台にわたってROSの通信をするには、どのPCでroscoreを実行するかを決めて、そのPCをマスターにする。このマスターはkobukiなど台車ロボットに載っているモバイルPC側でも、コントロール用のデスクトップPC側でもどちらでも構わない。

次に、各PCのIPとマスターの居場所をroscoreに教えてやる必要がある。
教え方は、ROSで用意されている環境変数を使う。

環境変数の設定にはexportコマンドを使う。このコマンドはコマンドラインで使う場合はきちんと反映されるが、スクリプトでやらせようとすると、そのスクリプトをsourceコマンドで実行しないときちんと反映されない。という特徴があるので注意。(初めてやったときにハマッた。)


下記に手順を記載。


<<マスター側>>

1.マスターのIPを設定。
export ROS_MASTER_URI=http://PCNAME.local:11311

PCNAMEにPCのホスト名を入れる。このホスト名は端末にログインしたときに表示されている。または、/etc/hostsに書いてあったと思う。


2.自分のIPをROSに設定
export ROS_IP=192.168.0.10

または、linuxコマンドを使ってこんなやり方もある。ただしネットワークアダプタが複数ある場合は注意。
export ROS_IP=`hostname -I`



<<子機側>>

1.マスターの居場所(IPアドレス)を設定。
 export ROS_MASTER_URI=http://PCNAME.local:11311
2.自分のIPをROSに設定
 export ROS_IP=`hostname -I`


<<動作の確認方法>>

ROSのチュートリアルに載ってるturtle_simなどを走らせると良い。
マスター側のPCでturtle_simを走らせて亀を表示し、子機側でkeyopを使って操作できるか見る。または、rostopic listで子機で流しているトピックがマスター側PCで見えるか確認したり、rostopic echo /topic名 を使ってトピックの中身を見る。


おまけ
netcatの使い方

ROSのノードを複数のPCで連携させる場合に、
ネットワークの疎通を確認するための手順

待ちうけ側のHOSTでこんな風に1234ポートをあける。
netcat -l 1234

つなごうとする側はこんな風に打つ。
netcat ubuntu.local 1234

すると、端末には何も表示されていないので、
あれ?接続できてない?と勘違いするかもしれないが、
これで接続は完了。

文字を打ってリターンすると、打った文字が
自分側と相手側の両方に表示される。
簡易的なチャットのような動作をするようになる。

pingだけでは簡単なテストしかできず、pingは通るのにいざデータを流してみると到達しない!といったときの疎通チェックに使える。
いままではtcpの送受信のコードを書いていたのだが、このコマンドを知ったことで大分労力が減った。

※ちなみに筆者の場合よくやるポカで、ネットワーク内でpingが通るのにデータがやり取りできないのは、デフォルトゲートウェイの設定(ルーターのIPアドレス)が抜けている場合がほとんど。

2015年10月13日 (火)

ROS グリッドマッピングのシミュレータで遊ぶ

ROS Indigo (OS:Ubuntu14.04LTS)を使ってサンプルプログラムの実行を試した。ROSで公開されているプログラムには、サンプルデータがbagファイルという形で提供されていることが多く、最初は上手く実行できなくても、これを解析していくことで正しく実行できるようにもっていくことができる。今回はSLAMのグリッドマッピングを仮想空間にいるロボットを使って実行した。
下記はこのチュートリアルに沿って進めた。

<ROSの準備>
インストールすべきパッケージがたくさんあるので、最初に全部入れてしまうほうがトラブルが少ない。 もしすでに入っているものがあれば、エラーでキャンセルされる。 このチュートリアルにある、このコマンドをコピペすれば入る。

$ sudo apt-get install ros-indigo-turtlebot ros-indigo-turtlebot-apps ros-indigo-turtlebot-interactions ros-indigo-turtlebot-simulator ros-indigo-kobuki-ftdi ros-indigo-rocon-remocon ros-indigo-rocon-qt-library ros-indigo-ar-track-alvar-msgs

<マッピングを試す>
まずこれでGazeboを起動し、障害物が置かれたワールドと、turtlebotを置く。

$ roslaunch turtlebot_gazebo turtlebot_world.launch

グリッドマッピングをやるノードはこれ。

roslaunch turtlebot_gazebo gmapping_demo.launch

マップの生成を眺める

$ roslaunch turtlebot_rviz_launchers view_navigation.launch

そしてロボットを操作するのは2DNavGoalではなく、teleopというキーボード操作のコントローラ このチュートリアルにある、

Make the turtlebot moveの、

$ roslaunch turtlebot_teleop keyboard_teleop.launch

というコマンドで動かせるようになる。

動かしてみるとGazeboがかなり重たいらしく、しょっちゅうブラックアウトするが、 ちょっとずつ動かすならついてくる。 teleopをlaunchした窓を開いて、iキーを押せば前進する。 RVizにマップが少しずつ生成されていくのだが、かなりタイムラグがある。 移動しているうちにロボットの位置が補正されたり、通った場所が白にぬりつぶされたりして更新される。

2015年10月12日 (月)

ROSの基本 トピックを理解する

SROSはノードという処理単位が、トピックという信号を発信し、他のノードがそれを受け取って処理をすることで仕事が進行する。
ノードとトピックがROSの基本なので、チュートリアルを読んでしっかり理解しないと公開されているパッケージを使いこなすことはおろか、買ってきたロボットをキーボードで走らせることもままならない。

この記事はチュートリアルを読みながら色々試した内容を書きつくろったものなので、基本的にはROS本家のチュートリアルを読みながら参考にされたし。

topicの中身を詳細に見ることで、どんなトピックを送り込めばタートルを動かせるかがわかる。

rostopic list -v

というコマンドで、トピックの詳細が出てくる。トピックのいわば型がこれでわかる仕組み。"-v"はオプションでトピックがどんな型かという情報と、パブリッシャー・サブスクライバーが何件いるかという情報が表示される。

liva@liva-BAT-MINI:~$ rostopic list -v

Published topics:
 * /turtle1/color_sensor [turtlesim/Color] 1 publisher
 * /turtle1/cmd_vel [geometry_msgs/Twist] 1 publisher
 * /rosout [rosgraph_msgs/Log] 2 publishers
 * /rosout_agg [rosgraph_msgs/Log] 1 publisher
 * /turtle1/pose [turtlesim/Pose] 1 publisher

Subscribed topics:
 * /turtle1/cmd_vel [geometry_msgs/Twist] 1 subscriber
 * /rosout [rosgraph_msgs/Log] 1 subscriber

上の例でいくと、turtle1を動かそうと思ったら[geometry_msgs/Twist]という型を持った、/turtle1/cmd_velという名前のトピックを何らかのノードを使って投げればいいことがわかる。

その型のトピックを投げるのがturtle_teleop_keyというノードで、キーボードを押すことでトピックが飛ぶようになっている。

面白いことに、ノードを使わなくても直接コマンドでそのトピックを投げることもできるのだ。

rostopic pub -1 /turtle1/cmd_vel geometry_msgs/Twist -- '[5.0, 0.0, 0.0]' '[0.0, 1.0, 1.9]'

ちなみに -r というオプションをつけると繰り返しになる。

この geometry_msgs/Twist というメッセージの中身について見たら、

liva@liva-BAT-MINI:~$ rosmsg show geometry_msgs/Twist
geometry_msgs/Vector3 linear
float64 x
float64 y
float64 z
geometry_msgs/Vector3 angular
float64 x
float64 y
float64 z

Vector3が2つ入ったものであることがわかる。

飛んでいるトピックの中身を見ることも出来て、これを見ることでノードが動作しているか。飛ばしているトピックの内容が思ったものと合致しているか。を知ることが出来る。この辺のデバッグ方法を知らないとサンプルプログラムを走らせることさえままならない。

コマンドはこのようなもの。

rostopic echo /turtle1/cmd_vel

turtle1に飛ばしているcmd_velというトピックの中身を表示させる例。

コマンドと文字ばっかりでイメージが湧かないということもあるので、そんなときはノードグラフを表示させる。rqt_graphというGUIツールが存在する。

rosrun rqt_graph rqt_graph

これでどんなトピックが流れているかと、どんなノードが立ち上がっているかをグラフで見ることができる。トピックは四角。ノードは丸で表示されている。上のチェックボックスをいじれば表示が切り替わる。これを駆使してデータのやり取りが途切れているところを調べることができる。

※LIVAでやっていると画面が出るまでに数秒ほど時間が掛かるので、ちょっと操作のテンポが狂う。バックグラウンド起動して、開いたままにしておき、設定を変える都度左上の右巻き矢印を押して更新するような使い方がスムーズでよい。



あとはlaunchファイルの使い方は知っておいたほうがよい。
launchファイルとは、ROSのノードを起動するためのスクリプトファイルである。最初のチュートリアルでは、ノードが必要となるたびにターミナルを立ち上げrosrunを実行していたが、本来はそのような使い方をしなくてもよい。

roslaunch [launchファイル名]

だけで、スクリプトに書かれたrosノードがいっせいに起動できるので、ノードが3個以上になりそうならlaunchファイルを書いたほうが楽だし、間違いも少ない。サンプルプログラムや、やってみた系のブログなどではlaunchファイルが公開されているので、launchファイルの意味を知るまでは何をやっているのかさえわからなかった。launchファイルの内容を理解できるようになれば、大抵のサンプルは走らせて試すことができるようになる。

ノードにパラメータをセットする場合はrosrunの後、パラメータ一個ずつにsetを使って書き込んでいかなければならない。しかしlaunchファイルであればパラメータを書き込んでおくだけでパラメータをセットされた状態のノードが立ち上げられる。チュートリアル以上のことをやろうとすれば必須の技術だ。

ROS(ロボットオペレーティングシステム)で遊ぶ

ROSというのは、ロボットを作るために良く使う機能(通信やコントローラ、座標変換の計算、環境マッピングなど)を使いやすくまとめたフレームワーク。Linux上で使うツール群のようなもので、このフレームワークに沿ってソフトを作っておくことで、開発上の色々なメリットが得られる。

まずはこの動画をチェック

ロボット開発に使えることもさることながら、流行のフィジカルコンピューティングや、IOTにもなかなかフィットした開発手法なのではないかと思った。

というのも、通信など面倒なところはROSで宜しくやってくれるので、ソフトはやりたいことだけ書けばよい。本当にやりたいことに集中させてくれると思ったから。

それまでは、TCPやUDPを使ってチマチマとデータをやり取りするコードを書き、スレッドで受信を処理しながらopenGLでグラフィックを描き。。。。などと細かいことに煩わされて、ちっとも開発が前に進まなかった。

ROSをロボットの研究だけにとどめておくのは勿体無い。
ArduinoやGarileo、RaspberryPiなどとも簡単につながるし、RTミドルウェアというほかのロボットOSともつなげることができるなど、結構自由度が高いのだ。

ARマーカーを追跡するパッケージや、顔認識パッケージなども提供されているので、ARを使ったゲーム+物理的に何かを動かすなどの応用も出来そうだ。




以下能書き。ご存知の方はスキップされたし。>>

ROSを使うと、
SLAMマッピングや人物追跡、ARマーカーなど高度な技術を応用したロボットを比較的簡単に構築することができる。世界中のユーザが研究成果をオープンソースで公開しているので、いつでもそれらをダウンロードして試すことができる。更新が活発に行われているのがROSの強み。

ROSでは、
ソフトウェアを機能ごとにブロック分割できるので、流用性が高まる。機能ごとにプロセスを分けて起動するので、どこかの機能で障害が起こってもそのプロセスだけをデバッグすればいい。またある機能だけをバージョンアップしたいときも、そのプロセスについてのソースをいじればよいことになるので切り分けが明確になっている。

プロセス同士はROSという枠組みの中でソケット(UDPブロードキャスト)通信しているので、複数のPCでプロセスを分けて起動することもできる。つまりロボットに搭載するのはラズベリーやLIVAなどのミニPCだけにして、マップや画像処理など重い処理はデスクトップPCにと分担が柔軟にできる。入れ替えもスクリプトで一発だ。

アームロボットなどは座標変換計算の塊だが、これを簡単に組み立てるためにtfというツールがある。openGLやopenCV、Eigenなど座標変換をするためのライブラリは色々あるけれど、いちいちこれらを使って3Dモデルを作り、そこからデバッグまでもっていくのは結構骨が折れる。ところがROS上であれば、スクリプトでロボットの情報を記述すると、手軽にロボットのモデルを作ることができて、シミュレーションも実機デバッグも同じモデルを使ってできる。

ROS対応のロボットを買ってこれば、ROSで用意されたモデルをそのままつかうことができるし、他人が作ったプログラムをそのまま流用することができる。お掃除ロボットのルンバもソフトバンクのペッパーもROSに対応している。DARPAチャレンジやつくばチャレンジでもROSを使ったロボットが続々と増えている。そのうちNHKロボコンでも使われる機会が増えるだろうか。


ROSを試すには>>

・UbuntuをインストールしたPCが必要。
Ubuntu14.04(LTS)というLinuxが入ったPCに、ROSのIndigoというバージョンをインストールする。UbuntuのバージョンとROSのバージョンの組み合わせは決まっていて、たとえばROS IndigoはUbuntu 12.02とか別のUbuntuバージョンでは動かない。

※チュートリアルにあるコマンドではすんなり入らないというだけで、筆者がそのテクニックが無いだけなのかもしれない。ものすごい量のエラーが出て面食らう

※ROSには色々バージョンがあり15年10月現在使っているのはIndigoというバージョン。すでにJadeというのが出ているがIndigoからの引継ぎが行われている最中で、ライブラリが揃っていないケースもある。

今ならマシンを用意しなくても、VMwareなどの仮想マシンにインストールする手がある。
RaspberryPiでlinuxに慣れている場合は専用マシンを買って遊ぶのも良いが、vimやapt-getなどに慣れていないのであれば、無理に用意しなくてもよい。



ROSの世界へ>>

ROSを試してみようと思ったら、とりあえずROSのチュートリアルで頑張ってみるのがオススメ。専門書を買うのは、ひとしきりここで格闘してからでも遅くない。


親切なことに日本語で書かれているので、かなりとっつきやすい。
また、内容もかなり親切に書かれているのでこのドキュメントだけでもある程度のレベルまではこのサイトだけで何とかなる。


ROSの専門書。日本語の本が出たのはつい最近。
それまでは英語の分厚い書籍しかなかった。









 

2015年10月 5日 (月)

とあるcmakeでトラブルがあったときに対処した内容 使ってみた感想

オープンソースを使っているとよくお目にかかるmakefileやCMakeであるが
ちょっとでもエラーで躓くと、その対処にはものすごく時間がかかることを覚悟しなければならない。しかも、たまに他のPCで試してみると、なぜかすんなり通ったりすることがあるのでなんだか遣る瀬無い。

別のマシンを使って試せないときは、おとなしくエラー内容を解析していくことになる。
色々グーグルをあさってみるのだが、CMakeに限っては有力な手がかりってそうそう無いものだ。

以下
openRTMのパッケージを作ろうとしてCMakeを使ったときのメモ。


エラー情報によると、
一個目はワーニングで、

CMake Warning at CMakeLists.txt:51 (find_package):
  Could not find a package configuration file provided by "OpenRTM" with any
  of the following names:

    OpenRTMConfig.cmake
    openrtm-config.cmake

  Add the installation prefix of "OpenRTM" to CMAKE_PREFIX_PATH or set
  "OpenRTM_DIR" to a directory containing one of the above files.  If
  "OpenRTM" provides a separate development package or SDK, be sure it has
  been installed.

OpenRTMConfigというパッケージコンフィグファイルがないと言っていて、
・CMAKE_PREFIX_PATHにOpenRTMのインストールプレフィックスを加える
・OpenRTM_DIRに上記のうちいずれかを含むディレクトリをセットする。
のどちらかをやれとある。
OpenRTMが分割開発パッケージやSDKか、インストールされているか確かめろと言っている。

残りの2つについては、

Use cmake/Modules/FindOpenRTM.cmake in the project
Could NOT find PkgConfig (missing:  PKG_CONFIG_EXECUTABLE)
CMake Error at cmake/Modules/FindOpenRTM.cmake:73 (file):
  file STRINGS file
  "C:/Users/Nanashi/workspace/Flip/OPENRTM_INCLUDE_DIR-NOTFOUND/rtm/version.h"
  cannot be read.
Call Stack (most recent call first):
  CMakeLists.txt:57 (find_package)

プロジェクトの中の、cmake/Modules/FindOpenRTM.cmake
はPkgConfigを見つけられない。
cmake/Modules/FindOpenRTM.cmakeの73行目とあり、
STRINGSの中のパスがおかしなことになっている。

"C:/Users/Nanashi/workspace/Flip/OPENRTM_INCLUDE_DIR-NOTFOUND/rtm/version.h"

OPENRTM_INCLUDE_DIR-NOTFOUNDという文字列が入っていて、
存在しないパスをさしているのだ。
OPENRTM_INCLUDE_DIR-NOTFOUNDをセットしたのがどこだったかを探し、
正しいパスをセットすれば動きそう。

CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.3/Modules/FindPackageHandleStandardArgs.cmake:148 (message):
  Could NOT find OpenRTM (missing: OPENRTM_INCLUDE_DIR COIL_INCLUDE_DIR
  OPENRTM_LIBRARY COIL_LIBRARY OPENRTM_IDL_COMPILER)
Call Stack (most recent call first):
  C:/Program Files (x86)/CMake/share/cmake-3.3/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE)
  cmake/Modules/FindOpenRTM.cmake:99 (find_package_handle_standard_args)
  CMakeLists.txt:57 (find_package)


ーーーーーーーーーーーーーーーー解析編

2個のエラーは、
最初に出てくるワーニングにあるファイルが見つからないために、DIR-NOTFOUNDというパスが無理やり設定されていると想像できるので、

OPENRTM_INCLUDE_DIR-NOTFOUND
がセットされる場所を検索した。

書いてあるとおぼしきcmakeやlistをnotepad++で洗いざらい検索してみたが、ちっとも出てこなかった。
そこで、find_packageというコマンドを使っている場所(ワークスペースのプロジェクトフォルダ直下にあるCMakeLists.txtの51行目)を見つけ、
その中にある

/usr/lib64/openrtm-1.1/cmake
というパスが、完全にUNIX向けであることに気づいた。そこで、windows向けに
C:\Program Files\OpenRTM-aist\1.1\cmake
のようなパスをいれてみた。
注意:エスケープ文字として、スペースの前にバックスラッシュを入れる必要がある。

すると、先ほどとは違うエラーが出て、

CMake Error at idl/CMakeLists.txt:34 (add_custom_target):
add_custom_target cannot create target "InterfaceDataTypes_TGT" because
another target with the same name already exists. The existing target is a
custom target created in source directory
_"C:/Users/Nanashi/workspace/Flip/idl". See documentation for policy CMP0002
for more details.
Call Stack (most recent call first):
idl/CMakeLists.txt:45 (_COMPILE_IDL)
idl/CMakeLists.txt:50 (OPENRTM_COMPILE_IDL_FILES)

add_custom_target
というのが、同じ名前のターゲットがすでに存在していたため
"InterfaceDataTypes_TGT"を作成できなかった。
というエラーに変わった。

そのすでに存在するターゲットはソースディレクトリ
"C:/Users/Nanashi/workspace/Flip/idl"
の中に作られたカスタムターゲットである。

CMP0002ドキュメントを見ろとあるが、これはマクロや変数に、全体にわたって(globalに)同じ名前を付けるなという内容のようで、エラー内容とほぼ同じ意味を書いてある。

同じ名前のファイルがあるからいけないのかとおもい、
プロジェクト内のidlフォルダにある
InterfaceDataTypes.idl ファイルを
別なフォルダに移してやってみた。
しかし、エラー内容は全く変わらなかった。


Call Stackにある、45、50行目を見ると、
idl,idlsという変数があり、macro定義の中で使われている。

setというコマンドは、リストへの追加を意味する。
最初の一行目で
set(idls ${CMAKE_CURRENT_SOURCE_DIR}/InterfaceDataTypes.idl ${CMAKE_CURRENT_SOURCE_DIR}/InterfaceDataTypes.idl )

ということをやっているから、
idls
にはCMAKE_CURRENT_SOURCE_DIRにある
InterfaceDataTypes.idl
のファイルがリストに追加される。

add_custom_target
というのはcmakeのコマンドの一種で、ドキュメントに説明がある。
http://www.cmake.org/cmake/help/v2.8.10/cmake.html#command:add_custom_target

CallStackというからには関数、マクロを呼び出したということ。
よく見ると、

macro(OPENRTM_COMPILE_IDL_FILES)

macro(_COMPILE_IDL _idl_file)

macro(_IDL_OUTPUTS _idl _dir _result)

と3つのマクロが書かれていることがわかる。
エラーの中で、

_COMPILE_IDL
OPENRTM_COMPILE_IDL_FILES

というマクロが使われたことがわかる。
そして、OPENRTM_COMPILE_IDL_FILES
というやつがforeachを使ってファイルを一個ずつ_COMPILE_IDL
というマクロにファイル名を渡していっているから、

エラーが出たのは_COMPILE_IDLの中らしい。
28から30行目にかけて、TGTという文字列が登場するから、
InterfaceDataTypes_TGT
というのはこの中で作られた文字列の一つであると想定できる。

気になるのは、.pyというのが混ざっている点で、どうもpythonを入れてないと動かないところがあるのかもしれない。

desktopPC(win8)ではここまでやってタイムアップだったが、別のミニPC(win8.1bing)でやったところすんなりcmakeが通った。
このときはちっともエラーが出なかった!!!


解析のコツ
自分で書いたCソースをコンパイルするときと同じで、CMakeが吐き出すエラー内容を読み解いていくしかない。
そもそもcmakeというツールを使うことがあまりなかったので、
どういうツールであり、何をするためにこのツールがあるのか。入力・出力するものは何か。
をまず知識として入れないと、やみくもにGoogle検索しても、有力な情報は得られなかった。

cmakeってこんなツール

つまるところCのマクロと同じで、OPENRTM_DIRなどの文字列がパス文字列に置き換わっていくと考えれば、
ほとんどのエラーは、パスの指定がおかしくて起こっているということがわかる。

messageというコマンドを使えば、configuration中の途中経過にメッセージを表示できる。
ちょうどprintfを使ったデバッグのようだ。

 

#include 

void main(void){
  printf("hello world\n");
}

raspberry pi2にubuntuをインストールする

RaspberryPi2へのubuntu14.04インストールを試した。
ubuntuといえばバリバリのデスクトップ用であるがpi2になってパワーアップしたことで入れられるようになった。しかしここで試したubuntuのイメージファイルはXserverが入っていなかったので欲しい人は別途入れるか、すでにXserverが入っているイメージファイルを探さなければならない。

具体的な手順

DDwindowsではうまく行かなかったので、diskImager32winのほうで試した。
DDのなにがよくないのかは不明。
参考サイト

このファイルを解凍すればimgファイルが入っている。
必要なのはこのファイルだけ。
Download 2015-04-06-ubuntu-trusty.zip
diskImagerで書き込んで、それをラズパイに入れて電源を入れれば起動する。
起動するとCUIの画面が出てくるだけ。


SSHをインストール
sudo apt-get -y update
sudo apt-get install -y openssh-server

を使えばうまく行った。

開いているポートを調べるコマンド
netstat -l

でSSHの項目があればログインができるはず。

IPを固定せずDHCPで運用したい場合はavahiデーモンを入れる。
※ubuntuではデフォルトで入っているようなのだが、このイメージでは入っていない。
apt-getでインストールすれば直ぐに使えるようになる。

sudo apt-get insatall avahi-daemon
というコマンドだけで動くようになった。




LIVA モニタなしで起動させようとしてGRUBをいじったら、モニタ起動が二度と出来なくなった件

miniPC LIVAにubuntu 14.04を入れて色々楽しく遊んでいたのであるが、普通にPCと使っている分に飽きてしまって、raspberry piのようにSSHで操作して遠隔操作したりしようと思った。そうなるとディスプレイをつながないと起動できないのはなんとも不便なので、ディスプレイなしで起動してくれるような設定を調べて試してみた。

livaをモニターなしで起動する。

GRUBでOSを選択する画面が出てきて、エンターを押さないと起動できない。

そこでGRUBの設定を変えればよいことがわかった。

先に結論を報告しておくと、

GRUBの書き換えは非常にリスクが高い
二度とGUIでログインできなくなる危険性を持っている。
知識が足らず、いままで一度も復活できたことがないので、再インストール決定(著者の場合は・・・)。

GRUBを書き換えてdisplayを表示させなくした場合、
その設定が保存されて、二度とxserverとのリンクが復活しなくなる。

方法は簡単。このファイルを直接編集する。

# sudo vi /etc/default/grub


GRUBファイルの中身はこんな感じ

GRUB_DEFAULT=0
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="text"
GRUB_CMDLINE_LINUX=""
GRUB_DISABLE_OS_PROBER=true ←追記

上記に変更したら、GRUBを反映させる。
update-grub
を実行して完了。

これで二度とXserverは立ち上がらなくなります(T T)
結局あきらめて普通のデスクトップPCとして使っています。
小さくて軽くてポータブルバッテリーでも動くので
何かの装置に組み込んで使えると思ったのにーー。

Linuxマシン同士のSSHの使い方

WindowsからTeraTermを使ってraspberry piにSSHログインする機会が多かったのだが、Linuxマシンを使う機会が増えてからLinuxマシンからraspberry piにログインしなければならないことがあった。ubuntuをインストールしたminiPCのLIVAからraspberry pi2にSSHログインしようとしたら、確かに合っているパスワードを入力しているにも関わらず、パスワードではじかれてしまったのだ。

TeraTermはかなりの作業を自動で行ってくれていたのである。Windowsからteratermを使ってやる分にはログインできるが、linuxからlinuxへのログインができない。teratermでSSHをやるときに出てくる、ASCIIアートみたいな絵で表示されるRSAというやつがポイントのようだ。linuxのSSHではコマンドでその辺を指定してやらねばならない。

1.
クライアント(ログインする側)で、鍵を生成する。

鍵の名前 と、鍵の名前.pub

の2個の鍵が作られる。.pubのほうが公開鍵。

2.

公開鍵をサーバー(ログインされる側)に配置する。

という場所に置かなければならないようなのだが、RPI2のubuntu(ARM)にはなかった。仕方がないのでmkdirで勝手に同じ名前のフォルダを作って、公開鍵を入れておいた。

作業をするときは、Windowsで両方のHOSTにteratermでSSHログインし、そこからwinSCPを使ってファイルを移動させると簡単だった。

3.

SSH起動のコマンド

ssh -l [ユーザ名] -i [秘密鍵のパス] [サーバBのホスト名]

コマンドが結構長いし都度打ち込むのは手間なので、
適当にスクリプトにして残しておいたほうがよい。

« 2015年7月 | トップページ | 2016年1月 »