2014年を振り返って、といっても個人的にはたくさんのことがありましたが別にみなさんのプラスになるものは 提供できませんので、ROSで今年お世話になったいくつかのノウハウを箇条書きにしておきます。
github便利
今年は研究室の環境をgithubに移行しましたが、プルリクエスト便利ですね。画像が貼れるのがいい。 travisと合わせるととても便利ですね。 すごい。
お金払うからtravisのメモリとCPU増やして欲しい
willowgarageとSharedAutonomyToolkitのメンテナに慣れたのは嬉しい。 willowgarageの方はmultimaster_experimentalだけですが
デバッグ編
ROSのプログラムをデバッグするときはrosnode info
とrostopic info
から初めて行くと良い。
あとはroslaunchのマニアックなオプション--nodes
とか--args
を使うと良いですね。
tfはスケールしない
tfはスケールしないモデルなので、基本的には使わないほうがいいです。といっても使わざるを得ないです。 tfがスケールしないというのは、tfはP2Pでノード間にネットワークを張るのがまずい。 たとえば
- 10個のtfのpublisherノードと10個のlistenerノードがいる。
- publisherはそれぞれ100Hzでframeを出している
となると、/tf
というトピックは結局1000Hzになります。1000HzのトピックはROS的にはかなり厳しくて、
subscribeしているだけでけっこうCPU使用率が上がります。そこに加えて
- 1つの10Hzでpublishするtfのノード
があるとすると、1000Hzの/tf
トピックの中にこの10Hzという遅いtfは紛れ込みます。その結果listenerに
届かないことがあったりします。これは結構致命的です。なので結局の所
- なるべくtfはpublishしない。
robot_state_publisher
と/map
と/odom
くらいにしておく
というところが良いようです。ちなみに、tf2を使うと少しは状況は良くなります。
roslaunchは高速化したほうが作業効率が上がる
hydroになってcatkinが全面的に使われるようになってから、roslaunchはとても遅くなりました。これは 本当によくない。今はここで議論中なのでそのうち解決されると思いますが、、、
- デフォルト
- 高速化
roslaunchが遅いと作業効率が下がる、ちなみに某ロボットだと立ち上げに数分かかったりしています。 今すぐ速くしたい人は以下のコマンドで出来ます(hydro限定かも)
$ wget -q -O - https://gist.githubusercontent.com/garaemon/24243ff199c2457b2369/raw/16cfefc8918c059ef32926f2508266be8a31c15e/catkin_patch.sh | bash
catkinのコンパイルオプション
catkinはコンパイルするときに最適化がデフォルトでは微妙なので -DCMAKE_BUILD_TYPE=RelWithDebInfo
をつけたほうがいいです。
$ catkin_make -DCMAKE_BUILD_TYPE=RelWithDebInfo
catkin_makeで移動するのが面倒
catkin_make
はいちいちros/hydro
のようなworkspaceの一番上に行かなくてはいけない、これは人生を無駄にしている。
適時aliasを貼るべき。
catkin_makeするときは必ず/opt/ros/${ROS_DISTRO}/setup.bashをsourceする
これは必ずやったほうがいいです。devel/_setup_util.py
なるファイルの中身が汚染されると面倒なことがたくさん起きます.
rosenv便利
rosenvというのを作りました。これは複数のcatkin workspaceを管理するための
便利コマンドです。補完も効きます(zshしか試してないけど). ついでにcatkin_makeを便利に使うためのcatmake
なるものが
定義して有ります。
rvizプラグインは怖くない
たくさん作ろう、結構簡単.
rqtのほうが癖が強いです. 気が向いたらrvizに関してはなにか書きます。
そういえば笑い男プラグインとか真面目に作ってます。
roscppでコード書くなら、全部nodeletにすべき
全部nodeletで書いたほうがいいです。それに小さなラッパーをかませて独立した実行ファイルも簡単に作れます。 image_procと同じ作戦ですね。
僕はnodelet.cmakeというのを作って、自動生成されるようにしています.
nodeletのonInitializeで重い処理をしてはダメ
nodelet managerはまずシリアルに各nodeletのonInitialize
を呼んでいくので、onInitialize
の中でループを書くなんてのはもってのほかです
出力をsubscribeされていないときは、入力をsubscribeしないようにする
あるトピックを入力として受け取って、あるトピックを出力としてだすようなシンプルなノードの場合、 出力トピックがsubscribeされない限りは入力もsubscribeしないようにするのは良いですね。 これもimage_procと同じ作戦ですね。
僕はConnectionBasedNodeletというクラスを作って再利用しています。
pcl::PointCloudとsensor_msgs::PointCloud2の変換は重い
例えばVGA30fpsで処理を回す、とかは難しい。
くわしくはこちら
yasnippet便利
yasnippetを導入したのですが、便利ですね。
僕はlaunchファイルでgdb[TAB]
と打つとlaunch-prefix="xterm -e gdb --args"
に展開されるようにしてたりします。捗る。
設定はこのへん.
なにか問題があったらバンバンupstreamにプルリクエスト出すといい
やはりgithub最高ですね。適当にプルリクエスト出すべきですね。
PR2のhydro対応は頑張った
なにか問題があったらバンバンissueに書くといい
可能な限りレポジトリはwatchすべき
可能な限りwatchして、アンテナを張るのは大事ですね。 rosdistroはwatchすべき。
rosdistroを見てるとwillowgarageがなくなってから認識周りが元気ないなーとかわかりますね。
euslisp便利
いざという時に良いインタプリタが使えるのは素晴らしい。euslisp最高です。
来年にむけて
もっと頑張ります。