search

jsk-ros-pkg / jsk_control

jsk control ros packages
http://github.com/jsk-ros-pkg/jsk_control
14 stars 51 forks source link

[jsk_footstep_controller]footcoords.cppのpublish_odom_tfの仕様について #681

Open ban-masa opened 7 years ago

ban-masa commented 7 years ago

footcoords.cpp内にはpublish_odom_tfというparamがあるのですが、これをfalseにしても、odom->root_linkへの変位0のtfが出続けるようです。 publish_odom_tfをfalseにした時に単純にodom->root_link間のtfを出さないようにするほうが、footcoords以外のodometryを使用してtfを出したいときに干渉しないので便利だと思うのですが、この仕様には何か理由があるのでしょうか？

YoheiKakiuchi commented 7 years ago

https://github.com/jsk-ros-pkg/jsk_control/issues/624 積み残し案件だと思います。

と、書いたらアサインされていた。

YoheiKakiuchi commented 7 years ago

https://github.com/jsk-ros-pkg/jsk_control/commit/5f2da6f0b7f303c4a631cfeaa22e2e7bd74d9d09 とりあえず、最新なら出なくはなってるように思います。

いずれにせよ、 #624 のとおり、整理したいところです。

ban-masa commented 7 years ago

あ、本当ですね。 自分のPCと17号機のAuditorPCで確認したときに最新かどうか調べるのを忘れていました。 申し訳ありません。 このissue自体はcloseした方がいいですか？

YoheiKakiuchi commented 7 years ago

せっかくなので、tfのodomを止めて、どういう風に使うつもりか書いてみて下さい。

そもそも、footcoordsのノード自体を上げないという選択肢は無いのか？ はどうだろうか？

ban-masa commented 7 years ago

robot_pose_ekfに/odomのtopicとvisual_odometryを入れて、研究会で話に出たようなodomの統合を試してみたいので、footcoordsがodom->rootlinkのtfをbroadcastしないようにする必要がありました。

footcoordsを上げないという方法でもいいのですが、BODY->groundなどのtfも消えるので、もし他のノードに影響がでたら面倒なのと、rosparamで切り替えられる方が便利だと思ったので、publish_odom_tfを使おうとしました。

publish_odom_tfはodomのbroadcastをon/offするほうが自然だと思ったので、あえてbroadcastし続ける仕様になっているのには特別な理由があるのではないかと考えたのですが。

YoheiKakiuchi commented 7 years ago

もうちょっと具体的に、robot_pose_ekfのインプットとアウトプットの接続を教えてください。 あと、テストと運用は分けて考えてもいいかもしれません。 #624は運用上の話。

robot_pose_ekfについては、covarianceがそれなりの正しさで入っていることが期待されていそうなので、 入力topicのcovarianceをチェックしておくことをおすすめします。 /odom (のトピック)は何もしなくても、covariance入っているのかな？ @orikuma システムではどこかで入れているはずだ。 /imu のcovarianceはここだ。 https://github.com/start-jsk/rtmros_common/blame/master/hrpsys_ros_bridge/src/HrpsysSeqStateROSBridge.cpp#L1016-L1024 @orikuma これはどうやって求めた値ですか？ vo は出してくれているんだと思うけれども、確認は必要。

ban-masa commented 7 years ago

robot_pose_ekfがsubscribeする/odom、/voのそれぞれにhrpsys_ros_bridgeの出す/odomのtopicとrtabmapの出すvisual_odometryのtopicを用いて、それらを統合したodomをtfへbroadcastさせようと考えています。

robot_pose_ekfは同時に/odom_combinedというtopicを出すようですが、nav_msgs/Odometry型ではないので、既存のノードがこのtopicを用いることはないと思います。

covarianceについては全く注意を払っていませんでした。 /odomにはdefaultでcovarianceがあったように思いますが、本当に機能しているかなんとかチェックしてみたいと思います。

HRP2の場合は/imuのorientationの値がYaw軸回りについては信用できないので、robot_pose_ekfには使わないつもりです。

orikuma commented 7 years ago

HrpsysSeqStateROSBridge内で入っている/imuのcovarianceは昔から使われていた特に根拠のない値だった記憶があります. odom.pose.covarianceは何もしない状態でodom.twist.covariance(デフォルト値は根拠のない定数)から計算された値が出てきます. rtabmapのvisual_odometryのcovarianceについてはわからないですが, もともと使っていたviso2ではcovarianceは根拠のない定数でした.

なおlocalizationで使っているcovarianceの値は実測から求めて https://github.com/jsk-ros-pkg/jsk_robot/blob/master/jsk_robot_common/jsk_robot_startup/src/jsk_robot_startup/OdometryOffset.py で上書きしたものを使っています(HrpsysSeqStateROSBridgeやvoから出てくる生の値は使っていない)

ban-masa commented 7 years ago

ありがとうございます。 /odomのcovarianceはそれほど根拠のあるものではないということですが、 とりあえずそのまま実際にrobot_pose_ekfに与えてみて、どんな感じになるか検証してみようと思います。