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

Enable unittest for samplerobot euslisp examples. #369

Closed
wants to merge 1 commit into from

Conversation

snozawa
Copy link
Collaborator

@snozawa snozawa commented Aug 25, 2015

Enable unittest for samplerobot euslisp examples.

…als/test/hrpsys-samples/test_samplerobot_euslisp_unittests.launch] Enable unittest for samplerobot euslisp examples
@k-okada
Copy link
Member

k-okada commented Aug 25, 2015

よいけど,start-jsk/rtmros_common#783 (comment) と逆?

@snozawa
Copy link
Collaborator Author

snozawa commented Aug 26, 2015

遅くなりました

まずこのPRは、以前そもそもeuslisp版hrpsys+rosbridgeのテストがtravis上で通らなかった箇所があったので、
その確認を再度travis上で行ってみたものです。

結論からいうとおそらく問題はなおってるっぽかったです。

問題は、
#123
のようにdebインストールでhrpsys_ros_bridgeするとwait-interpolationが
帰ってこないものであり、だいぶ前の話になりますがtravis上でも再現していました。

このPRをだしてみたら、master側は別な問題
jsk-ros-pkg/jsk_travis#129
がでてましたが、snozawa/rtmros_tutorialsのテストは
問題なく実行されて、かつ:wait-interpolation問題もなおっていて
今あるeuslisp版テストがそのままはしることまでは確認できました。
(動いてなかった原因は分からずじまいですが)

@snozawa
Copy link
Collaborator Author

snozawa commented Aug 26, 2015

次にeuslispとtestの方針ですが、
結局source, debのユーザ含めて今後運用できそうか何パターンか考えてみましたが、

method rtm-ros-robot-interface.lをおくばしょ euslispのテストをおくばしょ
A hrpsys_ros_bridge hrpsys_ros_bridge
B hrpsys_ros_bridge hrpsys_ros_bridge_tutorials
C hrpsys_ros_bridge_tutorials hrpsys_ros_bridge_tutorials

ざっくりA,B,Cくらいがあるとして、
現状はB、start-jsk/rtmros_common#783 (comment) に想定してたものはAでした。

いずれにしても、
 rtm-ros-robot-interface.lとeuslispテストを同じところにおいておく
 そのパッケージがeuslisp, euscollada, pr2eus....etcにdependできる
が必要な気がしたので、Cのどちらもhrpssy_ros_bridge_tutorialsにおくのが
良さそうに思いました。

まずA,Cの両方でテストとrtm-ros-robot-interface.lが同じところにおけます。
次にAにすると、euslispにdependしてないのでテスト上のみ追加が必要なのと、
start-jsk/rtmros_common#783 (comment)
実際テストしようとするとかなり色々なファイルを
hrpsys_ros_bridge_Tutorialsからもってこなければいけないことに気がつきました。
(例えばモデル生成も必要なので、samplerobot.yaml, samplerobot-interface.lなども必要)

テスト上のみeuslisp関係にdependさせることはできますが、それよりは普通に
パッケージとしてeuslisp関係にdependさせられるhrpsys_ros_bridge_tutorialsに
おくのがよさそうと思いました(方法C)

@k-okada
Copy link
Member

k-okada commented Aug 26, 2015

うーん.そうかな.この後もいろいろrtmros_commonにコミットが成されるなら,そのテストも同じリポジトリでやったらいいと思うので,
samplerobotだけでもhrpsys_ros_bridgeに持ってきてAでテストするのがいいと思うけど.
そうでなくてメインのテストはrtmros_tutorialsですというなら,rtmros_commonにこんなに活発にコミットが成されることは無いんじゃないかと思うので
色々なコードはrtmros_tutorialsに持っていけば良くなる.ただ,同様の理由でrtmros_hrp2が出来たことによって,ロボット用の.conf等々の生成やそのテス
トはrtmros_hrp2でやったらいいと思う.でないと
start-jsk/rtmros_common#795 (comment)
みたいなことになる.
となると,rtmros_tutorialsはおまけみたいなもので,G001(だっけ?)とか安川のとかが動くようなものになっていく,

というベクトルなんじゃないかな.

◉ Kei Okada

2015-08-26 14:03 GMT+09:00 Shunichi Nozawa [email protected]:

次にeuslispとtestの方針ですが、
結局source, debのユーザ含めて今後運用できそうか何パターンか考えてみましたが、
method rtm-ros-robot-interface.lをおくばしょ euslispのテストをおくばしょ A
hrpsys_ros_bridge hrpsys_ros_bridge B hrpsys_ros_bridge
hrpsys_ros_bridge_tutorials C hrpsys_ros_bridge_tutorials
hrpsys_ros_bridge_tutorials

ざっくりA,B,Cくらいがあるとして、
現状はB、start-jsk/rtmros_common#783 (comment) に想定してたものはAでした。

いずれにしても、
rtm-ros-robot-interface.lとeuslispテストを同じところにおいておく
そのパッケージがeuslisp, euscollada, pr2eus....etcにdependできる
が必要な気がしたので、Cのどちらもhrpssy_ros_bridge_tutorialsにおくのが
良さそうに思いました。

まずA,Cの両方でテストとrtm-ros-robot-interface.lが同じところにおけます。
次にAにすると、euslispにdependしてないのでテスト上のみ追加が必要なのと、
start-jsk/rtmros_common#783 (comment)
start-jsk/rtmros_common#783 (comment)
実際テストしようとするとかなり色々なファイルを
hrpsys_ros_bridge_Tutorialsからもってこなければいけないことに気がつきました。
(例えばモデル生成も必要なので、samplerobot.yaml, samplerobot-interface.lなども必要)

テスト上のみeuslisp関係にdependさせることはできますが、それよりは普通に
パッケージとしてeuslisp関係にdependさせられるhrpsys_ros_bridge_tutorialsに
おくのがよさそうと思いました(方法C)


Reply to this email directly or view it on GitHub
#369 (comment)
.

@snozawa
Copy link
Collaborator Author

snozawa commented Aug 26, 2015

うーん.そうかな.この後もいろいろrtmros_commonにコミットが成されるなら,そのテストも同じリポジトリでやったらいいと思うので, samplerobotだけでもhrpsys_ros_bridgeに持ってきてAでテストするのがいいと思うけど.

厳密な切り分けは難しいですが、ここ1年くらいの大部分のrtm-ros-robot-interface.lの変更は実はrtmros_commonとあまり関係なくて、hrpsys-baseの変更分を.lのほうに反映させるというのが多いです。
なので、rtmros_commonの何かの変更をテストするという部分は
https://github.com/start-jsk/rtmros_common/blob/master/hrpsys_ros_bridge/test/test-samplerobot.py
のようなEuslisp非依存のテストで行い、rtm-ros-robot-inteface.lとそのテストはあくまでeuslispのインターフェースがエラーでないか、のテストなのかなと思いました。

当初はAでやってみようとしていて、実際やってみると

 rtm-ros-robot-interface.lとeuslispテストを同じところにおいておく
 そのパッケージがeuslisp, euscollada, pr2eus....etcにdependできる

の後者のrtmros_commonがeuslispにdependしてないにも関わらず
euslisp関係のモノが増えてくことになって、ちょっとアレ、と思ったかんじでした。
ということで、rtmros_tutorialsが良いのかは難しいとおもいますが、rtmros_commonにdependしていてかつeuslispにdependして良いものがたまたまrtmros_tutorials,というくらいの感覚でした。

ただ、上記2項目のうち最優先なものは

 rtm-ros-robot-interface.lとeuslispテストを同じところにおいておく

でしたので、Aのrtmros_commonでテストする方向で進めようと思います。

(こちらのPRもチェックと言う意味ではチェックができたので、closeします)

@snozawa snozawa closed this Aug 26, 2015
@snozawa snozawa deleted the enable_euslisp_unittest branch August 28, 2015 07:45
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

Successfully merging this pull request may close these issues.

2 participants