search

jsk-ros-pkg / jsk_common

common programs for jsk-ros-pkg
43 stars 81 forks source link

euscolladaのテストプログラムを作る #219

Open k-okada opened 10 years ago

k-okada commented 10 years ago

This post was originally posted at http://sourceforge.net/p/jsk-ros-pkg/tickets/224

euscollada（に限らずロボットモデル変換）ですが，できるだけ，テストプログラムを作っていくようにしましょう． テストプログラムを作るのは面倒だけど，結果的に，他の人にプログラムの変更修正を任せた時の最終確認を自分がすると思うと，その時に救われた思いがします． [#153][#222][#223]

k-okada commented 10 years ago

自動テストになっていませんが、とりあえずバグの再現ができるファイルを作りました。

今のところバグは３点

  1. library_nodesに書いてあるノードを読まない library_nodesの部分を切り貼りしている diff sample3dof.org.dae sample3dof.dae の違い

  2. ベースノードのtranslation/rotationがあるとジオメトリの位置がずれる 対処法 -> とりあえずベースノードの位置を0点とする

  3. 関節軸の向きが一方向になってしまう (OpenHRP3 ColladaWriterで出力したcolladaはこの問題が起こらない) collada内の以下のようになっているところがうまくパースできていない？？

<translate>0.14 0.07000000000000001 0</translate>
<rotate>-1 0 0 89.99999999999999</rotate>
<rotate sid="node_joint1_axis0">0 0 1 0</rotate>
<translate>0 0 0</translate>
<rotate>1 0 0 89.99999999999999</rotate>

添付のファイルをpackage pathの通ったところで展開して、 makeしてroslaunch urdf_viewer.launchで視覚的に確認ができます。 今のところeuslispへの変換は1.を除きうまく行っているように見えます。

k-okada commented 10 years ago

テストプログラムをつくりました。 （JSK内部では一旦jsk-ros-pkg-unreleased/sandboxにコミットしました）

内部であればjsk-ros-pkg-unreleased/sandbox でsvn up && make してもらえればmakeされます。

テスト方法は rosrun robot_model_conversion_tester testSampleRobot.sh などです。他にも、HRP2JSK, HRP2JSKNT, HRP2JSKNTS, HRP2W, HRP4R, STARO, kawada-hironxあたりがあります。

テストは各ファイルの結果をyamlに出力して比較していて、

　WriteOpenHRP3RobotModel.cpp がcollada か vrmlファイルをModelLoaderからよむもの、 　write-euslisp-robot-model.l がeuslispファイルをeuslispからよむもの、 　compare_robot_model_yaml.py が比較のunittest、 　test*.sh が各ロボットに対して、yaml生成と比較を行うスクリプトです。

コードをどこにおくかという点はまた別途議論するとして、 現状ジョイントの整合性(llimit, lvlimitなど)と リンクの整合性(オフセット・マスプロパティなど)、 センサの整合性などを比較しています。 他にも足したいものはあります。

現状だと、 全ロボット：VRMLをmodelLoaderでよんだinertiaとcolladaをModelLoaderでよんだinertiaが違う -> export-colladaかcolladaをよむModelLoaderの部分のバグ HRP2JSKなど：VRMLがeuslispまで正しく変換されている -> 今のところcolladaを介さないとOKな可能性がたかい HRP4R, SampleRobot : もともとVRMLにはいってないプロパティがデフォルト値でいれられてdiffがでてそう

などでモデルの整合性がチェックできそうです。

colladaファイルを他のcollada読み込みプログラムでチェックするもの（collada_parser, openrave？）や urdfはまだはいってません。 （urdfのは一こ前の垣内さんの添付ファイルでできるでしょうか）

k-okada commented 10 years ago

内部であればjsk-ros-pkg-unreleased/sandbox でsvn up && make してもらえればmakeされます。

すいません、 cd ~/ros/groovy/jsk-ros-pkg-unreleased/sandbox svn up roscd robot_model_conversion_tester make でした

k-okada commented 10 years ago

全ロボット：VRMLをmodelLoaderでよんだinertiaとcolladaをModelLoaderでよんだinertiaが違う -> export-colladaかcolladaをよむModelLoaderの部分のバグ HRP2JSKなど：VRMLがeuslispまで正しく変換されている

euslispはvrml -> collada -> euslispで作られているはずで、vrmlとeuslispに整合性があるように見えるから、ModelLoaderのcolladaを読む部分だと思われる。 コードを見ていないけど、colladaは主軸成分とmassframeでinertiaテンソルを表現しているので、massframeが適切に使われていない印象。

HRP4R, SampleRobot : もともとVRMLにはいってないプロパティがデフォルト値でいれられてdiffがでてそう

この部分で、lvlimit,uvlimitがないと、テストプログラム自体がエラーになっているようにも見える。

このyamlに書き出す方式を極限まですすめると、テストしているすべてのモデルファイル互換の新しいモデルファイルができるように思うのだけどこの方向でOKなのかな？ それぞれのファイルに表現力に違いがあって、例えばlvlimitとlulimitを持っているのはvrml(euslispも？)でcolladaとurdfは１つだけになっている。こういう部分はどうしていくべきなのだろうか。

k-okada commented 10 years ago

euslispはvrml -> collada -> euslispで作られているはずで、vrmlとeuslispに整合性があるように見えるから、ModelLoaderのcolladaを読む部分だと思われる。 コードを見ていないけど、colladaは主軸成分とmassframeでinertiaテンソルを表現しているので、massframeが適切に使われていない印象。

これは、 https://openrtp.jp/redmine/issues/2168 として対応しました。

rtm-ros-roboticsの方ではパッチが当たるようになっています。 https://code.google.com/p/rtm-ros-robotics/source/detail?r=6795

k-okada commented 10 years ago

すいません、対応ありがとうございます （作業がかぶって、同じパッチをかいていました）

ちなみに、

rosrun robot_model_conversion_tester testHRP2JSK.sh

はとおりますか？

k-okada commented 10 years ago

このyamlに書き出す方式を極限まですすめると、テストしているすべてのモデルファイル互換の新しいモデルファイルができるように思うのだけどこの方向でOKなのかな？ 新しいモデルファイルという形にはならなくて、 あくまでもモデルフォーマットAとモデルフォーマットBとの間の変換のための テスト結果をかくようにしたいです。

なので、今は links: WAIST: ... でリンクローカルな座標変換やCOMの値がでてますが、 テストとして複数の姿勢(init-pose, reset-pose, reset-manip-poesくらい？)の グローバル（か腰相対）のリンク座標・COMの値、 全身のCOMの値なども比較したいと思ってます。

後者の全身の値やグローバルな値は モデルとして必要なデータでなく冗長ですが、 これがないと問題になるケースが多々あります。 グローバルな値がないと、fix jointでつながれた マスプロパティがカウントしわすれてた、ということが過去ありました。 グローバルな値については、youheiさんからチケットきってもらえると助かります。

結局テストコードでは、

ModelLoaderの上でEuslispのプロセスをforkして、 とやらなければ、何らかのファイルにかきだすのがいいかなぁと思って 今回はyamlにかきだしました。

さらに、yamlに書くべき内容はすべてのフォーマットに互換なロボットモデルというよりは、 積集合っぽいロボットモデルなのかなと思ってます。 例えばlvlimitの例だと(一旦colladaを介して変換することを無視すると) 　VRML (lvlimit, uvlimit) -> Euslisp (uvlimitのみ) としてそもそもの変換を行っています。 そもそもの変換でuvlimitのみが考慮されているので、 変換をチェックするプログラムもuvlimitだけ比較すればいいはずです。

この場合は、VRML -> Euslispの例でしたが、 VRML->collada, collada->euslisp, urdf->euslispなど 比較したいフォーマットの組み合わせで別々なyamlを作るのは大変そうなので、 異なるフォーマット間の組み合わせの間でのyamlの差異はなくしたほうが簡単そうです。

もちろん二つのロボットモデルフォーマットの間の積集合だけでなく、 リミットがハードリミットなのかソフトリミットなのか、といったところも 考慮したいですが、それでなくとも 慣性テンソル・重心が正しくない、軸の向きが違う、リンク座標系が違う、、、 といったバグのチェックにはなると思います。

k-okada commented 10 years ago

連投になりますが、こちらは少し個別的なはなしになります。

それぞれのファイルに表現力に違いがあって、例えばlvlimitとlulimitを持っているのはvrml(euslispも？)でcolladaとurdfは１つだけになっている。こういう部分はどうしていくべきなのだ\ ろうか。

lvlimit, uvlimitは両方もってるのはVRMLだけで、 euslisp, collada, urdfはuvlimitだけです。

実際にはVRMLでも大体のロボットでlvlimit= -1 * uvlimitと使われている気がしますし、 変換でその情報が抜け落ちるのであればuvlimitだけでいいと思います。

また、

この部分で、lvlimit,uvlimitがないと、テストプログラム自体がエラーになっているようにも見える。

の部分は、デフォルト値の問題だと思います。 モデルファイルでデフォルト値を書かないと どういう値がいれられるかがモノによってマチマチです。 euslispでは関節リミットのデフォルト値は確か90度とかになっていますが、 VRMLやColladaのModelLoaderは不定値 (なので、概ね1e300とかでかい値) が入ります。

モデルのチェックだけでなくモデルの変換も

  • 変換で書き出されたモデルファイルを
  • そのモデルファイルを読み込むプログラムの結果

で行われるほうがデフォルト値などが変換時に即値ではいるので、いいと思います。

現状、export-colladaではVRMLで関節limitを書いてない軸は colladaでも関節limitがかいてないようです。 個人的には、ここはデフォルト値をいれたほうが後々混乱がないように思いますが、 ただ不定値をいれられると困りますね。

k-okada commented 10 years ago

ColladaファイルをModelLoaderに読み込むと、segmentsの名前が 適切に入りませんでしたが、直しました。 本家では https://openrtp.jp/redmine/issues/2169 でパッチを送り報告し、rtm-ros-roboticsでは http://code.google.com/p/rtm-ros-robotics/source/detail?r=6844 でパッチをあてるようにしています。

これで、segmentの名前が適切にはいるとおもいます。 rtm-ros-roboticsの方にも、これで治るissueが何個かあったきがします。

k-okada commented 10 years ago

http://code.google.com/p/rtm-ros-robotics/source/detail?r=6846 にテストコードをついかしました．sample.wrlとsample.daeを読んできて比較します．試して下さい． 比較が足りないところがあれば教えて（追加して）下さい．

気がついたのは， １） セグメントの名前が違う問題はキャッチできて上のパッチで直っている． ２）　inertiaのパッチも追加されているけど，これが必要な場面sampleモデル，PA10モデルでは見つかっていない ３）　ルートリンクの名前が違う．これは治したい．

k-okada commented 10 years ago

あ，今気が付きましたが，robot_model_conversion_tester と同じことをやっていたのかな．テストコードとソースコードは近い所においたほうがいいので，openhrp3でexport-collladaのテストをしてcolladaとwrlが同じことを確かめて，euscolladaでeusとcolladaが同じであることを確認するのがいいと思います．

k-okada commented 10 years ago

この方法だと、

colladaフォーマットをmodelloaderで比較する vs vrmlフォーマットをmodelloaderで比較する だけを行うには、上記で追加していただいたmodelloader-testのような http://code.google.com/p/rtm-ros-robotics/source/detail?r=6846 の方法がベストだと思います。

一方で、色々なモデルのチェックをやろうとすると破綻しそうで、 苦肉の策としてrobot_model_conversion_testerを作りました。 方法は

方法１（modelloader-test.pyの方法） 　Aフォーマット、Bフォーマトを一つのプログラムで 　ロードして、変換チェックを行う 　　　　 方法２（robot_model_conversion_testerの方法） 　Aフォーマット、Bフォーマトの結果を何かに書き出して、 　変換チェックは別プログラムで行う

があるとして、

方法１のメリット（≒方法２のデメリット） 1 （それができるフォーマット間であれば、）robot_model_conversion_testerの 　ように怪しいYAMLを別途つくらずとも、 　標準のモデル利用方法のみでチェックプログラムがかける 2 今回のcollada+modelloader vs vrml+modelloaderのケースのように、 　modelloaderがある一つのシステムのものの場合、 　つまりある単一のシステムがフォーマットA、フォーマットB両方をサポートしていて、 　それをチェックしたいときは、そのシステム内だけで完結しているほうが 　チェックプログラム自体もパッチとして取り入れてもらえそう。 　というかそうするべき。

方法１のデメリット（≒方法２のメリット） 1 フォーマットや使用言語が違ってくると難しくなる。 　例えば、pythonやcからeuslispのモデルをロードできない、など。 2 比較したいファイルフォーマットが増えるほど、破綻しそう。 　例えばn個のファイルフォーマット間の変換をチェックしたいとします。 　方法１だと、n C 2 = n*(n-1)/2個のチェックプログラムを書いてメンテナンスする 　必要があると思います 　方法２だと、YAMLに書くプログラムをn個、YAML間を比較するプログラムが 　1個なので、計n+1個のプログラムを書いてメンテナンスすることになります。 　nが大きいとファイルの個数は方法１>方法２となります。 　また、方法１だと比較やモデル利用のコードの部分でだいぶオーバヘッドが 　でるので、ファイルの量も方法1の方が増えそうに思います 3 「方法１メリットの１」の用な場合でなく、 　システムが別々なものにまたがるときは、変換プログラムのチェックプログラムは 　多分どこにもとりいれてもらえなさそう。 　例えばあるフォーマットとEuslispの変換プログラムのチェックプログラムは、 　多分jsk-ros-pkgに入れるしかなさそう。 　そうなると、別々な変換間でチェックプログラムが共通な方法２のほうがメリットは増えそう。

のメリットデメリットがあるきがします。 ご意見きかせていただけると助かります。

とりあえず、modelloader-testプログラムを試してみましたが、 rtmlaunch openhrp3 modelloader-test.launch をすると

Traceback (most recent call last): File "/home/nozawa/ros/groovy/rtm-ros-robotics/openrtm_common/openhrp3/test/modelloader-test.py", line 15, in from OpenHRP import ImportError: No module named OpenHRP [modelloader_test-3] process has died [pid 14978, exit code 1, cmd /home/nozawa/ros/groovy/rtm-ros-robotics/openrtm_common/openhrp3/test/modelloader-test.py __name:=modelloader_test __log:=/home/nozawa/.ros/log/46087698-88df-11e3-90e3-0021ccd1da7d/modelloader_test-3.log]. log file: /home/nozawa/.ros/log/46087698-88df-11e3-90e3-0021ccd1da7d/modelloader_test-3.log C-c C-c[modelloader-2] killing on exit

とエラーがでました。以下はどうしたらいいんでしたっけ。 http://code.google.com/p/rtm-ros-robotics/issues/detail?id=305&start=100 （自分の手元はアップデートが足りない気がしますが）

k-okada commented 10 years ago

この方法だと、

colladaフォーマットをmodelloaderで比較する vs vrmlフォーマットをmodelloaderで比較する だけを行うには、上記で追加していただいた http://code.google.com/p/rtm-ros-robotics/source/detail?r=6846 の方法がベストだと思います。

一方で、色々なモデルのチェックをやろうとすると破綻しそうで、 苦肉の策としてrobot_model_conversion_testerを作りました。 方法は

方法１（modelloader-test.pyの方法） 　Aフォーマット、Bフォーマトを一つのプログラムで 　ロードして、変換チェックを行う 　　　　 方法２（robot_model_conversion_testerの方法） 　Aフォーマット、Bフォーマトの結果を何かに書き出して、 　変換チェックは別プログラムで行う

があるとして、

方法１のメリット（≒方法２のデメリット） 1 （それができるフォーマット間であれば、）robot_model_conversion_testerの 　ように怪しいYAMLを別途つくらずとも、 　標準のモデル利用方法のみでチェックプログラムがかける 2 今回のcollada+modelloader vs vrml+modelloaderのケースのように、 　modelloaderがある一つのシステムのものの場合、 　つまりある単一のシステムがフォーマットA、フォーマットB両方をサポートしていて、 　それをチェックしたいときは、そのシステム内だけで完結しているほうが 　チェックプログラム自体もパッチとして取り入れてもらえそう。 　というかそうするべき。

方法１のデメリット（≒方法２のメリット） 1 フォーマットや使用言語が違ってくると難しくなる。 　例えば、pythonやcからeuslispのモデルをロードできない、など。 2 比較したいファイルフォーマットが増えるほど、破綻しそう。 　例えばn個のファイルフォーマット間の変換をチェックしたいとします。 　方法１だと、n C 2 = n*(n-1)/2個のチェックプログラムを書いてメンテナンスする 　必要があると思います 　方法２だと、YAMLに書くプログラムをn個、YAML間を比較するプログラムが 　1個なので、計n+1個のプログラムを書いてメンテナンスすることになり、 　nが大きいとファイルの個数は方法１>方法２となります。 　また、方法１だと比較やモデル利用のコードの部分でだいぶオーバヘッドが 　でるので、ファイルの量も方法1の方が増えそうに思います 3 「方法１メリットの１」の用な場合でなく、 　システムが別々なものにまたがるときは、変換プログラムのチェックプログラムは 　多分どこにもとりいれてもらえなさそう。 　例えばあるフォーマットとEuslispの変換プログラムのチェックプログラムは、 　多分jsk-ros-pkgに入れるしかなさそう。 　そうなると、別々な変換間でチェックプログラムが共通な方法２のほうがメリットは増えそう。

のメリットデメリットがあるきがします。 ご意見きかせていただけると助かります。

とりあえず、modelloader-testプログラムを試してみましたが、 rtmlaunch openhrp3 modelloader-test.launch をすると

Traceback (most recent call last): File "/home/nozawa/ros/groovy/rtm-ros-robotics/openrtm_common/openhrp3/test/modelloader-test.py", line 15, in from OpenHRP import ImportError: No module named OpenHRP [modelloader_test-3] process has died [pid 14978, exit code 1, cmd /home/nozawa/ros/groovy/rtm-ros-robotics/openrtm_common/openhrp3/test/modelloader-test.py __name:=modelloader_test __log:=/home/nozawa/.ros/log/46087698-88df-11e3-90e3-0021ccd1da7d/modelloader_test-3.log]. log file: /home/nozawa/.ros/log/46087698-88df-11e3-90e3-0021ccd1da7d/modelloader_test-3.log C-c C-c[modelloader-2] killing on exit

とエラーがでました。以下はどうしたらいいんでしたっけ。 http://code.google.com/p/rtm-ros-robotics/issues/detail?id=305&start=100 （自分の手元はアップデートが足りない気がしますが）

k-okada commented 10 years ago

すいません、メッセージがpostできてないとおもい、２回postしてしまいました。 スレッドが増えると別ページになるんですね。。。

２）　inertiaのパッチも追加されているけど，これが必要な場面sampleモデル，PA10モデルでは見つかっていない

確かに、こちらの手元でもsampleモデルはでてませんでした。 (roscd openhrp3/build/OpenHRP-3.1/server/ModelLoader && svn revert BodyInfoCollada_impl.cpp && make && yes | cp ../../bin/openhrp-model-loader ../../../../bin/) をすると、パッチなしの状態に戻ると思いますが、 こちらではHRP2JSKなどクローズドなロボットたちで不具合がでてきました。

また、modelloader-testの比較プログラムがc++でなくpythonなのには何か理由がありますか？ このあたりのプログラムを書くユーザは基本的にはc++からmodelLoaderを使うきがするので、 　c++のモデルローダテストのサンプルとしても意義が出てくる、 　c++の内容がテストしてある 　c++でテストプログラムが書いてあるがゆえにテスト項目の追加が容易になる などの理由でc++がうれしいのですが、どうでしょうか。

３）　ルートリンクの名前が違う．これは治したい． ルートリンクの名前って違ってましたっけ？ ルートジョイント（WAIST）ではないでしょうか。

k-okada commented 10 years ago

あ，今気が付きましたが，robot_model_conversion_tester と同じことをやっていたのかな．テストコードとソースコードは近い所においたほうがいいので，openhrp3でexport-collladaのテス\ トをしてcolladaとwrlが同じことを確かめて，euscolladaでeusとcolladaが同じであることを確認するのがいいと思います．

すいません、postのタイミングが入れ違いになってしまいましたが、 　robot_model_conversion_testerは読み込みとテストを分ける方法（方法２） 　modelloader-test.pyはテストと読み込みを同じでやる方法（方法１） と違っていると思ってまして、openhrp3のテストとしては方法１が正しいですが、 他のことを考えると個人的には方法２なのかなぁと思ってます。

少し話がそれますが、colladaのモデルロード方法もかなり扱いが難しいと思ってます。 今ROSのcollada_parser, openhrp3のmodelloader, euscollada, openrave ...と 別々なモデルロードプログラムがあるように思います。

特にeuscolladaやmodelloaderでなおしたいのは、 ロボットモデルとしてcolladaを読んでるというよりは、 XMLとしてcolladaを読んでいるかんじに近いという点です。

少なくともここ１花月でcollada読み込みプログラムのバグ修正として、 euscolladaもmodelloaderもいじる必要がありましし、 これまでも慣性テンソルのバグをeuscolladaでなおし、 modelloaderでもなおし、となっていたように思います。

本当はopenraveからモデルロード機能だけ抜き出した外部ライブラリがあって、 それを全部のプログラムがdependして使うようになっているのがいいのかなぁと思っています

k-okada commented 10 years ago

とりあえず、modelloader-testプログラムを試してみましたが、 rtmlaunch openhrp3 modelloader-test.launch をすると openhrp3/lib/python2.7/dist-packages/OpenHRPというディレクトリはありますか？なければ，rm installed; make してください．

メリットデメリットですが，ｎ個のフォーマットがあった時に，nC2の組み合わせを考えるのではなくて，確かめたいのはコンバータなのでコーバータの数だけフォーマットを試すのでいいとおもいます．比較すべきはコンバータ．また，２の場合はAフォーマットを読んでBフォーマットを書き出すプログラムと，Aフォーマットを読み込んでYAMLフォーマットを書き出すプログラムの両方が必要なので，その分オーバヘッドだと思う．さらに，新たにYamlのフォーマットの維持管理もしていて，前にコメントがあったけど，あたらしいロボットフォーマットを作ることになっている．

CあPythonかですが今回はモデルがCORBAの型になっているので，CでもPythonでも（CORBAがちゃんとしていれば）C++でかかれたModelLoaderが生成するインスタンスを比較していることになります．ので，言語間の差分は無いと思います．

euscolladaはcollada_parserに依存させて urdf/model.h を読むようにするのが正解だと思います．

urdf -> collada 間の変換も，両方同じurdf::Model インスタンスが作られるから，そのインスタンス同士を直接比較すべきだと思います．ここで一回Yamlに書き出すとそこでエンバグする可能性がありますね．

eusは難しいですね．上の作戦は一つのローダで複数のフォーマットに対応しているので出来ているので，eusは独立なので難しいですね．そこはYamlでもしょうがないだろうか．

k-okada commented 10 years ago

https://openrtp.jp/redmine/issues/2170 で openhrp3のidlを /lib/python2.7/OpenHRPにインストールしていますが，これすると/lib/python2.7/OpenHRPとコンフリクトする．つまりimport OpenHRPとするとopenhrp3以下が読まれる．いままではhrspys以下のOpenHRPだった．さらにopenhrp3以下のOpenHRPはopenhrp3のIDLだけをロードするがhrpsys以下のOpenHRPはhrpsysのIDLもローﾄﾞする．という問題が会ったので，openhrp3のIDLはOpenHRP3という名前になるようにしました．多分ですが，hrpsysでOpenHRPのIDlを持っているのが問題なので，それを治したいと思います．

k-okada commented 10 years ago

メリットデメリットですが，ｎ個のフォーマットがあった時に，nC2の組み合わせを考えるのではなくて，確かめたいのはコンバータなのでコーバータの数だけフォーマットを試すのでいいとおもいます．比較すべきはコンバータ．また，２の場合はAフォーマットを読んでBフォーマットを書き出すプログラムと，Aフォーマットを読み込んでYAMLフォーマットを書き出すプログラムの両方が必要なので，その分オーバヘッドだと思う．さら\ に，新たにYamlのフォーマットの維持管理もしていて，前にコメントがあったけど，あたらしいロボットフォーマットを作ることになっている．

いえ、n個のフォーマットというのは、n個のお互いに変換をもつようなもの、という意味でした。 一般論だと必ずしも全組み合わせの変換がないですが、現実に即して整理すると、 今よくつかうフォーマットは

urdf, collada, vrml, euslisp

の４つで、 　urdf<->collada 　vrml<->collada 　collada<->euslisp 　euslisp<->vrml 　urdf<->euslisp 　euslisp<->urdf の変換プログラムがすでに存在します(全部が双方向というわけでないですが)。

なので、方法１であるといいチェックプログラムは4 C 2 で結局 6個になってしまっています。 方法２では４つのフォーマットからyamlに書き出し、yaml間のチェックプログラムは１個で 計５個のメンテナンスですみます。 コード量と上で書いていたのは、方法１だと print_ok(" CoM {0:24} {1:24}".format(wrl_l.centerOfMass, dae_l.centerOfMass), centerOfMass_ok) のような比較分などがnC2 全部でかくことになるので、 オーバーヘッドがおおいということでした。

また，２の場合はAフォーマットを読んでBフォーマットを書き出すプログラムと，Aフォーマットを読み込んでYAMLフォーマットを書き出すプログラムの両方が必要なので，

これは、前者のA->Bフォーマットを書き出すコンバータは 方法１、２どちらでも必要なので、ここでカウントすべきでないと思います。

なので、やはりコードの量・メンテするファイル数は方法１の方が増えると思ってます。

ただ、

ここで一回Yamlに書き出すとそこでエンバグする可能性がありますね．

おっしゃるとおりyamlもあやしいと思ってるので、方法１で

euscolladaはcollada_parserに依存させて urdf/model.h を読むようにするのが正解だと思います． urdf -> collada 間の変換も，両方同じurdf::Model インスタンスが作られるから，そのインスタンス同士を直接比較すべきだと思います．

のように比較が適切なプログラムで行える方でいく、というので賛成です。

ファイル数が多い分も、本当にすべての変換をサポートしないでおくのでもいいのかもしれません。 例えば、n個フォーマットがあれば、ちょっと遠回りになりますが ホントはn-1個の変換プログラムで全部のフォーマット間で変換ができますね。 上記の例ですと、euslisp->vrmlも環境モデルが吐き出せて便利ですが、 現状rbrainにあって唯一公開されてないプログラムなので、 ここをサポートせず他のファイルから変換していくのでもいいのかもしれません。

CあPythonかですが今回はモデルがCORBAの型になっているので，CでもPythonでも（CORBAがちゃんとしていれば）C++でかかれたModelLoaderが生成するインスタンスを比較していることになります．ので，言語間の差分は無いと思います．

これは、（個人的には）普段はModelLoaderをc＋＋から利用するので それでテストしたほうがわかりやすい、というのと、 リンクローカルな値以外にワールドに直したものを 比較するようなチェックをいれたくて、 そういった計算をするとなるとc++の方が普段使っているので world_c = link->p + link->R * link->c みたいにやりやすいのかな、ということでした。 ちなみにこれはpythonのサンプルだとnumpyとかを使うかんじなのでしょうか。 あまりopenhrp3のModelLoader利用時にこのへんの 演算まで行う標準的な方法がよくわかってません。

k-okada commented 10 years ago

今よくつかうフォーマットは

urdf, collada, vrml, euslisp

の４つで、 　urdf<->collada 　vrml<->collada 　collada<->euslisp 　euslisp<->vrml 　urdf<->euslisp 　euslisp<->urdf の変換プログラムがすでに存在します(全部が双方向というわけでないですが)。

ここは何回か話題にでていますが，フォーマットの全部の変換は作らずに，決めたパスだけを作って整備するのでいいとおもいます． そうでないと，このように全ての変換を作って，さらにそのテストをしなければいけなくなって，結局自分の首をしめるということになります． 自分の首を締めないためには，取捨選択する必要があります．

vrml->collada urdf->collada collada -> euslisp

が当初の作戦だったと思います．urdfでないとgazeboが上手く行かないというのがあるので，collada->urdfも許してもいいですが， gazebo(実際にはgazebo_ros?）をcollada対応にする方がいいと思ってはいます．

逆に言うと，これ以外のパスが必要なのはなんでだろうか？ euslisp->urdf euslisp->collada euslisp->vrml の３つが必要なのは何故だろうか？euslisp->vrml一つではダメだろうか．

さらにここで注目すべきものはコンバータではなくて，ロボットモデルのクラスで， OpenHRP::BodyInfo と，urdf::Model　だけをみたらいいので， BodyInfoの比較をするプログラムを一つ作れば，vrml->collada と collada->vrmlの両方を確認できます． urdf<->colladaも同様にurdf::model一つでOKです． euslispは困ったところですが，urdf::Model<->euslispの確認プログラムをつくればよくて合計３つ OpenHRP::BodyInfo<->euslispがあても４つだとおもいます． さらに最初の２つはインスタンスの変数を比較すればいいので，間違いがないのと， print_ok(" 　の部分はpprint(link)でちゃんと表示すべき部分で，それは比較プログラムのなかに書くのではなく， ロボットモデルのクラスが管理する部分としてソチラもっていくのがいいです． なんと言ってもあたらしいYamlロボットモデルフォーマットを管理しなくていいのが嬉しいはずです．

world_c = link->p + link->R * link->c みたいにやりやすいのかな、ということでした。 ちなみにこれはpythonのサンプルだとnumpyとかを使うかんじなのでしょうか。

それがしたい場合は，BodyInfoではなくBodyをつかって，比較するんでしょうね． その場合はCの方が楽ですね．

k-okada commented 10 years ago

ここは何回か話題にでていますが，フォーマットの全部の変換は作らずに，決めたパスだけを作って整備するのでいいとおもいます． そうでないと，このように全ての変換を作って，さらにそのテストをしなければいけなくなって，結局自分の首をしめるということになります． 自分の首を締めないためには，取捨選択する必要があります．

僕もそうだと思っていて、

逆に言うと，これ以外のパスが必要なのはなんでだろうか？

それ以外のパスもなくてもいいとは思います。 現状あって、かつjsk-ros-pkgなどでも公開されているので、 どこかの段階でけずっていくのかなと思います。

さらにここで注目すべきものはコンバータではなくて，ロボットモデルのクラスで， OpenHRP::BodyInfo と，urdf::Model　だけをみたらいいので， BodyInfoの比較をするプログラムを一つ作れば，vrml->collada と collada->vrmlの両方を確認できます． urdf<->colladaも同様にurdf::model一つでOKです． euslispは困ったところですが，urdf::Model<->euslispの確認プログラムをつくればよくて合計３つ OpenHRP::BodyInfo<->euslispがあても４つだとおもいます．

これもその通りですね。 今更ですが、今思うと方法２でyamlにしてしまっていたのは、 ２つのファイル間の変換だけをチェックするのでなく 全部の変換をトレースしてチェックしたかったためだった気がします。

最近で遭遇していた問題は、openrave xmlなファイルをcolladaに変換したモデルが、 euscolladaやopenhrp3のmodelloaderで全然うまくうごいていない、 というものでした。

これは、openrave xmlをopenraveで読み込んでcolladaにするところで、 openraveは多分対応しているけど他の euscollada, openhrp3のBodyinfoColladaが対応してない 書き方でファイルが書き出されていて、動きませんでした。

そのため、多分このケースだと openrave xml <-> collada の変換なのでopenrave自体ではテストはとおりますが、 テストがとおったと思って安心してeusocllada, openhrp3で使うと 何か動かない、ということがあります。これは、 openrave xml <-> colladaのチェックをopenraveで行うと、 「colladaファイルのチェック」ではなくて厳密には 「はきだしたcolladaファイルがopenraveで適切に読めてる」 チェックなので、実はそのcolladaファイルがopenhrp3などで 読めてなかった、というののチェックにならないからです。

なので、変換プログラムの外の変換までトレースして チェックする必要があり、yamlにしてチェックをしてました。

ただ、根本の原因は

openraveは多分対応しているけど他の euscollada, openhrp3のBodyinfoColladaが対応してない

の部分なので、yamlで変感外までトレースするよりここを直すべきでした。

euscolladaはcollada_parserにするのがいいですが、 collada_parserもopenraveの方に追いついていってないきもします。 （上記のバグもyouhei さんに調べてもらっているので、何かフォローお願いします） openhrp3もcollada_parser的なかんじになるとメンテナンスが 軽くなりますが、難しいでしょうか。

ところで、

vrml->collada urdf->collada collada -> euslisp が当初の作戦だったと思います．

の作戦になったのはなんでなんでしたっけ？ 僕があまりcolladaのメリットをわかってないだけかもしれませんが、 colladaを中心に回していくのはメリットよりデメリットの方がおおいように感じます。

urdf => urdfのmodel.h vrml => openhrp3のBody.h euslisp => euslispのcascaded-link など、ロボットのモデルフォーマットにはそれを使うオススメソフトウェアや ロボットのインスタンスがつきものです。

colladaだと、 collada => openraveのロボットクラス が元来オススメなんだと思いますが、openraveを使わないとすると、例えば

euscolladaはcollada_parserに依存させて urdf/model.h を読むようにするのが正解だと思います．

のようにcolladaをよみこんでurdf/model.hで使うのであれば、 この部分はurdfでいいのでは、とも思います。

また新しいROSなどのソフトウェアを利用するときに、urdfだとそのまま使えますが、 colladaだとそのソフトウェアをcollada対応にするという ワンクッションはいります。 rvizなどもそうしてきて、次は

urdfでないとgazeboが上手く行かないというのがあるので，collada->urdfも許してもいいですが， gazebo(実際にはgazebo_ros?）をcollada対応にする方がいいと思ってはいます．

gazeboもなので大変に思います。 ただ、"urdfだとそのまま使えますが"、もちょっと怪しいきもするので、 何を基準モデルフォーマットとしていくかは難しい問題だとも思います。 colladaも大変ですが、collada以外にしてもホントにラクなのかは判断が難しいと思います。

k-okada commented 10 years ago

eusは難しいですね．上の作戦は一つのローダで複数のフォーマットに対応しているので出来ているので，eusは独立なので難しいですね．そこはYamlでもしょうがないだろうか．

r6063でEuslispの変換チェックを行うものを、jsk_model_toolsに追加しました。

snozawa commented 10 years ago

別途話がでていたので https://github.com/jsk-ros-pkg/jsk_model_tools/issues/4 こちらに書きます。

まずそもそもこのissueと上記のissueで出て議題をおさらいすると

となっていると思います。

現状のモデル変換の構成を図にしたものを添付します。 角四角がモデルフォーマット、丸四角がモデルローダ、矢印が変換プログラムです。 天下り的になりますが、スライド１枚めがcollada2eus_urdfmodelがコミットされる前の構成です。

スライド１枚目の構成での問題は

がありました。

ちょっとどうしてもモデルフォーマットのチェックを行わないといけないりゆうがあったので、 euslisp_model_conversion_testerは直接euscolladaの変換をチェックせずに、 ModelLoaderで読み込んだものをチェックしていました。 そのためrtmbuildに依存していました。

スライド２枚めは、collada2eusがurdfmodelを使うようになった後の構成図です。 改善してる点は、

こうすると、euscolldaのチェックプログラムはrtmbuildはいらなくなり、

ということで、今後送る予定のPReqは

になります。

snozawa commented 10 years ago

pdf添付できないんですね。困った。。。 model-conversion-before-collada2eusurdfmodel がcollada2eus_urdfmodel以前、 model-conversion-after-collada2eusurdfmodel が以降です。

garaemon commented 10 years ago

なるほど、これってcollada2eis_urdfmodelはurdfファイルも変換できたりしますか？

2014年3月12日水曜日、snozawanotifications@github.comさんは書きました:

pdf添付できないんですね。困った。。。 [image: model-conversion-before-collada2eusurdfmodel]https://f.cloud.github.com/assets/6102287/2396714/97332d40-a9de-11e3-8a72-5c568ce5104c.png がcollada2eus_urdfmodel以前、 [image: model-conversion-after-collada2eusurdfmodel]https://f.cloud.github.com/assets/6102287/2396715/9c1c2096-a9de-11e3-8f8a-b32c7050af5b.png が以降です。

— Reply to this email directly or view it on GitHubhttps://github.com/jsk-ros-pkg/jsk_common/issues/219#issuecomment-37400953 .

from iPhone

snozawa commented 10 years ago

COLLADAタグがなければparseURDFをしているので、よめるようになると思います。 なので、図のurdfとeuslispとの間の矢印もはいってくると思います。

(今はちょっとpr2のdaeでもセグフォしてしまうようですが）

roscd euscollada
rosrun euscollada collada2eus_urdfmodel pr2.dae pr2.yaml /tmp/pr2.l