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

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

ROS

2016年2月 4日 (木)

ROSでARマーカーを追跡するパッケージを使う

SLAMとnavigationが出来たので、今度はARマーカーの表示を標識として読み込ませて、ロボットに行動を起こさせてみよう。

ARマーカーの認識のためのパッケージは、AlvarとARToolKitの2種類が主に存在している。

ここを参考にやった。Alvar派
韓国のodroidやつも参考になる。

uvc_cameraは手持ちのwebカメラではうまく行かず、
こないだ使ったweb_camという新しい方のノードで試すことにした。
web_cam ros calibrationで調べるとすぐに出てきた。
http://ros-robot.blogspot.jp/2010/11/cameracalibrationusb.html



calibrationツールはかなり重たい。
calibrationはチェッカーボードをカメラに見せる。runボタンが押せるようになるまでいろんな向きに動かす。
SAVEするとカレントディレクトリに画像とキャリブ情報が保存される。それをparserによませてyamlファイルをだす。
それをlaunchファイルでusb_camノードに読ませて、
カメラがキャリブレーションした状態で立ち上げる。
yamlファイルの指定がうまく行かず。xmlファイルの$findというタグがうまく行かない。
環境変数あたりの設定だと思う。




調べてみたら、$find PACKAGE_NAME
というのは、自分の使っているPACKAGE_NAMEをいれろということだった。
パッケージはどこか。。。。というと、作っていなかったのだ。
ファイルのパスを指定する方法がわからなかったので、とりあえずパッケージをこしらえることにした。
odroidの記事に沿って、
githubからソースをおとして、rosmake

ところがPACKAGE_NAMEでもar_track_alvarでもファイルを見つけてこれず。
仕方がないので絶対パス指定で指定する方法を探した。

エラーメッセージを元に検索をかけて、
だいぶおくまで探していたら、パス指定を絶対パスで指定している例を見つけた。
本家ros.orgの解説
これでうまく指定できた。

しかし新たなエラーが出た。

[ INFO] [1445134554.137224096]: camera calibration URL: file:///home/liva/ros_tameshi/webcamTameshi/cal.yml
[ WARN] [1445134554.193922018]: [camera] does not match name narrow_stereo in file /home/liva/ros_tameshi/webcamTameshi/cal.yml

narrow_stereoという名前で立ち上げたカメラがないと言っているのか、cal.ymlのなかを見てみると、確かにnarrow_stereoという文字列がある。 これをlaunchファイルで書いたuvc_cameraに書き換えてみた。


結局uvc_cameraでは画像が出ないことがわかっているので、再度usb_cameraの以前作ったlaunchファイルを元に書き足していくことにした。
カメラとビューワーだけで動作を確認し、次にキャリブレーションファイルを読み込んだ状態で起動するところまでを確認した。



  
    
    
    
    
    
    

    
    
  

  
    
    
  

odroidのXMLの例での疑問nsとはなにか。
調べてみると、roslaunch XMLでは、nsはnamespaceのこと

いろいろ試しながら、 ノードグラフを表示させてみたら、あと一歩のようだ。 image_rawをalvarに入れれば動きそう。

151019rosgraph

 

alvarが動いていないので、tfのエコーをみても、
mapからcameraフレームへの変換(ずっと固定)しか出てこない。
alvarへのimage_rawの入れ方がポイントになりそう。
ついに動かせた。

syntax highlighterを使って書いているが、所々自動で修正が入ってしまうので、正しく表示されていないかもしれない。その場合は下記リンクからダウンロードされたし。



  

  
    
    
    
    
    
    

    
    
  

  
    
    
  


	
	
	
		
	
  
   




151019rosgraph_2

 

rvizを起動すると、by topicにMarkerというトピックが追加されているので、それを選ぶと、3Dグラフィックでマーカーの位置が示される。
結構バタバタしているので、新しいIDでTFに追加され、出ては消えるを繰り返すような感じになっている。カメラのフレームレートが遅いとブレるので結構精度が悪い。
fpsを30に指定してみたが、あまり効果はなく
USBカメラの性能なのかCPUなのか。
もう少し早いPCであれば様子が変わるだろうか。





2016年1月25日 (月)

ROS hector_slamを使ってマップを作る。<No.2>

一回目でhector_slamのパッケージをインストールしたら、後はhokuyo_nodeを使ってLRF(laser range finder)の情報をpublishしてhector_slamのマッピングをするノードにデータを入れればよい。

最終的にこんなマップが作れるようになった。
Ws000059

hector_slamを使うまでに、一番ネックになったのはTFの理解だった。
ROSでは座標変換をトピックを使って実施している。これを処理するのがTFノードで、各ノードはTFノードに座標変換情報を投げて、ほしい座標系を受け取っている。

hector_slamが必要としているフレーム(座標系)を持ったTFのトピックを、hector_slamノードに投げてやる必要がある。

hector_slamをLRFを手に持ってデータを取るだけなら、とりあえず難しいことはさておき、全ての座標変換を(x,y,z,roll,pitch,yaw)=(0,0,0,0,0,0)でやってしまっても問題なく動く。

TFを投げる方法として、TFパッケージのstatic_transform_publisherがある。
これを必要なだけlaunchファイルに書き出せばOK。


launchファイルの例。
















 

hokuyo_nodeを起動して、URG-04LXのデータをpublishする方法。 このデータがマッピングノードに送られることで、マップが生成される。











rvizの見方
Fixed Frameはmapにする。tfツリーのトップはmapにしてあるので、mapを基準としてLRFが動き回る。LRFがどこに居るかは/laserというフレームを見ればわかる。LRFの生データは/scanトピックを追加することで見られる。

mapの保存
mapの保存は、rvizではなくrosrunからのmapsaverで行う。

rosrun map_server map_saver -f ./mymap

これを間違いやすい。よくでるエラーは

[ WARN] [1452915362.940959897]: Using deprecated map server interface. Please switch to new interface. [ERROR] [1452915363.068600220]: Map_server could not open -f.

こういうのが出たらmap_saverの打ち間違い。すごく紛らわしいので注意。


mymap.pgmの例

Ws000060

mymap.yamlの例

「mymap.yaml」をダウンロード


次回はマップ作成の実践編

2016年1月24日 (日)

ROSのhector_slamを使ってマップを作る。

hector_slamとLRF(laser range finder)があれば、グリッドマッピングが簡単に実行できる。しかもオドメトリ情報が要らないので、LRFを手で持って移動するだけでマップが作成できる。

※このページの内容を試そうと思ったら、一通りチュートリアルをやってrvizと、launchファイルの起動の仕方。ノードとトピックの見方。などを押さえておいたほうがスムーズに行きます。

LRFの例。

ROSでよく使われているのは北陽電機のURG
最近はお掃除ロボットにも搭載されて、ロボット自体も低価格化が進んでいる。アメリカではLRFを手に入れるためにお掃除ロボットを買って分解する人もいるそうな。


激安LRF¥32,583!!ついにここまで安くなった。ROSに対応していないと思うので、ノードのプログラムを書く技術があるならトライしてみても良いかも。

いきなり実機を使ってやろうとするのは難しかったので、サンプルデータを使ってマップのできる様子やどんなトピックが出ているかを見ていくことにした。

セッティングの方法

hector_slamのサンプルデータを使って、マッピングの様子を見た。

まずは、このコマンドでbagファイルをダウンロードする。基本的にコピペ。

wget http://tu-darmstadt-ros-pkg.googlecode.com/files/Team_Hector_MappingBox_RoboCup_2011_Rescue_Arena.bag

 

 

hector_slamに必要なノード群をlaunchファイルで一括起動して、
roslaunch hector_slam_launch tutorial.launch
さっきダウンロードしたbagファイルを再生させると、実機で動作させたときのトピックの状況が再現される。
rosbag play Team_Hector_MappingBox_RoboCup_2011_Rescue_Arena.bag  --clock
このlaunchファイルはマップを表示させるためのrvizの設定まではやってくれていないので、自分で参照したいトピックを指定する。
マップを見たかったら、by topicでmapを指定する。


次回は実機を使って試します。

2016年1月19日 (火)

ROSでnavigationを試す。

ROSのnavigationを使ってみたときの記録。

目標としているのはこんな事。
⇒既知の地図を用いたTurtleBotの自律ナビゲーション

いつの間にか、こんなところに無料のROS本が公開されている!!
のでありがたくここの内容を参考にさせてもらうことにした。

マシンは、マスター用にミニPCのECS LIVA、kobukiに搭載するPCにraspberryPi2(以下RPI2と記載)を使った。


上記rosbookのrosbook_kobuki packageをダウンロードして、catkin_makeしたら、
source catkin_ws/devel/setup.bash
の実行が必要。
これをやらないとTAB補完で候補として出てこない=登録されない。
launchファイルを起動してみたが、urg_nodeが入っていないというエラーが出たので、仕方なく、urg_nodeをインストールした。
まずはliva上に入れて、エラーメッセージがでなくなることを確認した。
URG-04Xとkobukiを直接livaにつなぎ、liva上でnavigationを実行した。
すると、工程がすすんで起動が完了した。
view_navigation.launchを使ってrvizを起動し、サンプルで用意されたマップとともに現在のスキャンデータが表示された。

最初に2DPoseEstimateをGUIで入力すると、kobukiが登場する。
それから2DNavGoalを入力したらkobukiが移動した。

次に、RPI2上でやろうと思いurg_nodeをインストールしたのだが、
なぜかnot authenticatedというエラーがでてインストールできなかった。
LIVA上ではなんとか動かすところまでいったので、RPI2上でrosbook_kobukiパッケージをhokuyo_nodeで動くように作り変えて見る。


まずはurgという単語を
findを使ってあぶり出すことにした。urgをhokuyoに変えたらいけそうか。

find ./ -type f -print | xargs grep 'urg'



とりあえず全てのurgという単語を置き換えて起動するところまではいったものの、
robot_state_publisher
というノードが立ち上がらず。おそらく、このノードに渡すパラメータがurgとhokuyo_nodeで異なっているために、正しく起動できていないようだ。


仕方がないので再度livaにLRFとkobukiをつないで、node_graphの正解をみることにした。
Rosgraphnavi


続いて、試しにmyRoomのマップ(以前hector_slamで作成したマップ)を読み込ませてみると、うまく動作した。

EstimatedPointを指定して、NavGoalを指定すると、ちゃんと動くのだが、部屋が狭いせいでpotentialCollisonで動けないというエラーが出た。コストマップのパラメータを小さい値に変更すれば良さそうだ。


myRoomのマップを実行した時のrviz

20160116myroomcostmap





2016年1月17日 (日)

ROSでwebカメラを使う

ROSにwebカメラをつないで画像処理をしたり、デスクトップPCに遠隔操作のための画像を配信したりする。


↑最初はラズパイで使っていたelecomのwebカメラを試した。

ROSのパッケージをインストール。
sudo apt-get install ros-indigo-usb-cam
lsusbでつないだUSBが認識されたかみることができる。
このカメラはelecomとしか出てこなかった。
rosparamでyuvuを設定するが、ちっともうまく行かず。
しばらくするとノードが落ちてしまう。
日本語のHPは古いのが多かったので、ひたすら英語サイトを引っ張った。
ここにlaunchファイルの例があったので、それを試した。


roslaunchでwebcam.launchを起動すれば、ウェブカメラの画像が表示される。
launchファイルにカメラのパラメータ、画素数とかフォーマットを書き込む。
結局冒頭のelecom製では起動せず、iBuffaloのレンズ付きカメラで試したらうまく行った。
形式はyuvuではなくmjpegだった。


↑結局こっちを使うことになってしまった。ちょっと高いのだがレンズが大口径で明るい画像が撮れるタイプ。
付属品のフレキシブルミニ三脚が意外としっかりしていて、ロボットの支柱などを掴ませて手軽に固定することができる。



やってみた結果をlaunchファイルにまとめて、一発でカメラを起動できるようにした。


  
    
    
    
    
    
    
  
  
    
    
  

これを、cam.launchなどとしてファイルに保存し、

roslaunch ./cam.launch

で起動すると、カメラとカメラビューワーが一緒に立ち上がる。


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ファイルであればパラメータを書き込んでおくだけでパラメータをセットされた状態のノードが立ち上げられる。チュートリアル以上のことをやろうとすれば必須の技術だ。