garaemon.github.io about me
2014 December 31

2014年を振り返って、といっても個人的にはたくさんのことがありましたが別にみなさんのプラスになるものは 提供できませんので、ROSで今年お世話になったいくつかのノウハウを箇条書きにしておきます。

github便利

今年は研究室の環境をgithubに移行しましたが、プルリクエスト便利ですね。画像が貼れるのがいい。 travisと合わせるととても便利ですね。 すごい。

お金払うからtravisのメモリとCPU増やして欲しい

今年書いたプルリクエスト一覧

willowgarageSharedAutonomyToolkitのメンテナに慣れたのは嬉しい。 willowgarageの方はmultimaster_experimentalだけですが

デバッグ編

ROSのプログラムをデバッグするときはrosnode inforostopic 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に書くといい

対応してくれる@catkin

可能な限りレポジトリはwatchすべき

可能な限りwatchして、アンテナを張るのは大事ですね。 rosdistroはwatchすべき。

rosdistroを見てるとwillowgarageがなくなってから認識周りが元気ないなーとかわかりますね。

euslisp便利

いざという時に良いインタプリタが使えるのは素晴らしい。euslisp最高です。

来年にむけて

もっと頑張ります。