Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ban-masa opened this issue Apr 18, 2017 · 9 comments
Assignees

Comments

@ban-masa
Copy link

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

@YoheiKakiuchi
Copy link
Member

YoheiKakiuchi commented Apr 18, 2017

#624
積み残し案件だと思います。

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

@YoheiKakiuchi
Copy link
Member

5f2da6f
とりあえず、最新なら出なくはなってるように思います。

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

@ban-masa
Copy link
Author

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

@YoheiKakiuchi
Copy link
Member

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

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

@ban-masa
Copy link
Author

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
Copy link
Member

もうちょっと具体的に、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
Copy link
Author

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
Copy link
Contributor

orikuma commented Apr 19, 2017

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
Copy link
Author

ban-masa commented Apr 19, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants