-
Notifications
You must be signed in to change notification settings - Fork 81
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
euscolladaのテストプログラムを作る #219
Comments
自動テストになっていませんが、とりあえずバグの再現ができるファイルを作りました。 今のところバグは3点
添付のファイルをpackage pathの通ったところで展開して、 |
テストプログラムをつくりました。 内部であればjsk-ros-pkg-unreleased/sandbox テスト方法は テストは各ファイルの結果をyamlに出力して比較していて、
WriteOpenHRP3RobotModel.cpp コードをどこにおくかという点はまた別途議論するとして、 現状だと、 などでモデルの整合性がチェックできそうです。 colladaファイルを他のcollada読み込みプログラムでチェックするもの(collada_parser, openrave?)や |
すいません、 |
euslispはvrml -> collada -> euslispで作られているはずで、vrmlとeuslispに整合性があるように見えるから、ModelLoaderのcolladaを読む部分だと思われる。
この部分で、lvlimit,uvlimitがないと、テストプログラム自体がエラーになっているようにも見える。 このyamlに書き出す方式を極限まですすめると、テストしているすべてのモデルファイル互換の新しいモデルファイルができるように思うのだけどこの方向でOKなのかな? |
これは、 rtm-ros-roboticsの方ではパッチが当たるようになっています。 |
すいません、対応ありがとうございます ちなみに、 rosrun robot_model_conversion_tester testHRP2JSK.sh はとおりますか? |
なので、今は 後者の全身の値やグローバルな値は 結局テストコードでは、
ModelLoaderの上でEuslispのプロセスをforkして、 さらに、yamlに書くべき内容はすべてのフォーマットに互換なロボットモデルというよりは、 この場合は、VRML -> Euslispの例でしたが、 もちろん二つのロボットモデルフォーマットの間の積集合だけでなく、 |
連投になりますが、こちらは少し個別的なはなしになります。
lvlimit, uvlimitは両方もってるのはVRMLだけで、 実際にはVRMLでも大体のロボットでlvlimit= -1 * uvlimitと使われている気がしますし、 また、
の部分は、デフォルト値の問題だと思います。 モデルのチェックだけでなくモデルの変換も
で行われるほうがデフォルト値などが変換時に即値ではいるので、いいと思います。 現状、export-colladaではVRMLで関節limitを書いてない軸は |
ColladaファイルをModelLoaderに読み込むと、segmentsの名前が これで、segmentの名前が適切にはいるとおもいます。 |
http://code.google.com/p/rtm-ros-robotics/source/detail?r=6846 気がついたのは, |
あ,今気が付きましたが,robot_model_conversion_tester と同じことをやっていたのかな.テストコードとソースコードは近い所においたほうがいいので,openhrp3でexport-collladaのテストをしてcolladaとwrlが同じことを確かめて,euscolladaでeusとcolladaが同じであることを確認するのがいいと思います. |
この方法だと、
colladaフォーマットをmodelloaderで比較する vs vrmlフォーマットをmodelloaderで比較する 一方で、色々なモデルのチェックをやろうとすると破綻しそうで、 方法1(modelloader-test.pyの方法) があるとして、 方法1のメリット(≒方法2のデメリット) 方法1のデメリット(≒方法2のメリット) のメリットデメリットがあるきがします。 とりあえず、modelloader-testプログラムを試してみましたが、 Traceback (most recent call last): とエラーがでました。以下はどうしたらいいんでしたっけ。 |
この方法だと、
colladaフォーマットをmodelloaderで比較する vs vrmlフォーマットをmodelloaderで比較する 一方で、色々なモデルのチェックをやろうとすると破綻しそうで、 方法1(modelloader-test.pyの方法) があるとして、 方法1のメリット(≒方法2のデメリット) 方法1のデメリット(≒方法2のメリット) のメリットデメリットがあるきがします。 とりあえず、modelloader-testプログラムを試してみましたが、 Traceback (most recent call last): とエラーがでました。以下はどうしたらいいんでしたっけ。 |
すいません、メッセージがpostできてないとおもい、2回postしてしまいました。
確かに、こちらの手元でもsampleモデルはでてませんでした。 また、modelloader-testの比較プログラムがc++でなくpythonなのには何か理由がありますか?
|
すいません、postのタイミングが入れ違いになってしまいましたが、 少し話がそれますが、colladaのモデルロード方法もかなり扱いが難しいと思ってます。 特にeuscolladaやmodelloaderでなおしたいのは、 少なくともここ1花月でcollada読み込みプログラムのバグ修正として、 本当はopenraveからモデルロード機能だけ抜き出した外部ライブラリがあって、 |
メリットデメリットですが,n個のフォーマットがあった時に,nC2の組み合わせを考えるのではなくて,確かめたいのはコンバータなのでコーバータの数だけフォーマットを試すのでいいとおもいます.比較すべきはコンバータ.また,2の場合は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でもしょうがないだろうか. |
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を持っているのが問題なので,それを治したいと思います. |
いえ、n個のフォーマットというのは、n個のお互いに変換をもつようなもの、という意味でした。 urdf, collada, vrml, euslisp の4つで、 なので、方法1であるといいチェックプログラムは4 C 2 で結局 6個になってしまっています。
これは、前者のA->Bフォーマットを書き出すコンバータは なので、やはりコードの量・メンテするファイル数は方法1の方が増えると思ってます。 ただ、
おっしゃるとおりyamlもあやしいと思ってるので、方法1で
のように比較が適切なプログラムで行える方でいく、というので賛成です。 ファイル数が多い分も、本当にすべての変換をサポートしないでおくのでもいいのかもしれません。
これは、(個人的には)普段はModelLoaderをc++から利用するので |
ここは何回か話題にでていますが,フォーマットの全部の変換は作らずに,決めたパスだけを作って整備するのでいいとおもいます. vrml->collada が当初の作戦だったと思います.urdfでないとgazeboが上手く行かないというのがあるので,collada->urdfも許してもいいですが, 逆に言うと,これ以外のパスが必要なのはなんでだろうか? さらにここで注目すべきものはコンバータではなくて,ロボットモデルのクラスで,
それがしたい場合は,BodyInfoではなくBodyをつかって,比較するんでしょうね. |
僕もそうだと思っていて、
それ以外のパスもなくてもいいとは思います。
これもその通りですね。 最近で遭遇していた問題は、openrave xmlなファイルをcolladaに変換したモデルが、 これは、openrave xmlをopenraveで読み込んでcolladaにするところで、 そのため、多分このケースだと なので、変換プログラムの外の変換までトレースして ただ、根本の原因は
の部分なので、yamlで変感外までトレースするよりここを直すべきでした。 euscolladaはcollada_parserにするのがいいですが、 ところで、
の作戦になったのはなんでなんでしたっけ? urdf => urdfのmodel.h colladaだと、
のようにcolladaをよみこんでurdf/model.hで使うのであれば、 また新しいROSなどのソフトウェアを利用するときに、urdfだとそのまま使えますが、
gazeboもなので大変に思います。 |
r6063でEuslispの変換チェックを行うものを、jsk_model_toolsに追加しました。 |
別途話がでていたので まずそもそもこのissueと上記のissueで出て議題をおさらいすると
となっていると思います。 現状のモデル変換の構成を図にしたものを添付します。 スライド1枚目の構成での問題は
がありました。 ちょっとどうしてもモデルフォーマットのチェックを行わないといけないりゆうがあったので、 スライド2枚めは、collada2eusがurdfmodelを使うようになった後の構成図です。
こうすると、euscolldaのチェックプログラムはrtmbuildはいらなくなり、
ということで、今後送る予定のPReqは
になります。 |
なるほど、これってcollada2eis_urdfmodelはurdfファイルも変換できたりしますか? 2014年3月12日水曜日、[email protected]さんは書きました:
from iPhone |
COLLADAタグがなければparseURDFをしているので、よめるようになると思います。 (今はちょっとpr2のdaeでもセグフォしてしまうようですが)
|
This post was originally posted at http://sourceforge.net/p/jsk-ros-pkg/tickets/224
euscollada(に限らずロボットモデル変換)ですが,できるだけ,テストプログラムを作っていくようにしましょう.
テストプログラムを作るのは面倒だけど,結果的に,他の人にプログラムの変更修正を任せた時の最終確認を自分がすると思うと,その時に救われた思いがします.
[#153][#222][#223]
The text was updated successfully, but these errors were encountered: