Traceback (most recent call last):
File "/home/nozawa/ros/groovy/rtm-ros-robotics/openrtm_common/openhrp3/test/modelloader-test.py", line 15, in <module>
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
Traceback (most recent call last):
File "/home/nozawa/ros/groovy/rtm-ros-robotics/openrtm_common/openhrp3/test/modelloader-test.py", line 15, in <module>
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
自動テストになっていませんが、とりあえずバグの再現ができるファイルを作りました。
今のところバグは３点
1. library_nodesに書いてあるノードを読まない
library_nodesの部分を切り貼りしている
diff sample3dof.org.dae sample3dof.dae の違い
2. ベースノードのtranslation/rotationがあるとジオメトリの位置がずれる
対処法 -> とりあえずベースノードの位置を0点とする
3. 関節軸の向きが一方向になってしまう
(OpenHRP3 ColladaWriterで出力したcolladaはこの問題が起こらない)
collada内の以下のようになっているところがうまくパースできていない？？
添付のファイルをpackage pathの通ったところで展開して、
makeしてroslaunch urdf_viewer.launchで視覚的に確認ができます。
今のところeuslispへの変換は1.を除きうまく行っているように見えます。
テストプログラムをつくりました。
（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に出力して比較していて、
- vrmlファイルをModelLoaderで読み込む＋euslispファイルをeuslispで読み込む を比較
- colladaファイルをModelLoaderで読み込む＋euslispファイルをeuslispで読み込む を比較
- colladaファイルをModelLoaderで読み込む＋vrmlファイルをModelLoaderで読み込む を比較
などをしています。
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のは一こ前の垣内さんの添付ファイルでできるでしょうか）
すいません、
cd ~/ros/groovy/jsk-ros-pkg-unreleased/sandbox
svn up
roscd robot_model_conversion_tester
make
でした
euslispはvrml -> collada -> euslispで作られているはずで、vrmlとeuslispに整合性があるように見えるから、ModelLoaderのcolladaを読む部分だと思われる。
コードを見ていないけど、colladaは主軸成分とmassframeでinertiaテンソルを表現しているので、massframeが適切に使われていない印象。
この部分で、lvlimit,uvlimitがないと、テストプログラム自体がエラーになっているようにも見える。
このyamlに書き出す方式を極限まですすめると、テストしているすべてのモデルファイル互換の新しいモデルファイルができるように思うのだけどこの方向でOKなのかな？
それぞれのファイルに表現力に違いがあって、例えばlvlimitとlulimitを持っているのはvrml(euslispも？)でcolladaとurdfは１つだけになっている。こういう部分はどうしていくべきなのだろうか。
これは、
https://openrtp.jp/redmine/issues/2168
として対応しました。
rtm-ros-roboticsの方ではパッチが当たるようになっています。
https://code.google.com/p/rtm-ros-robotics/source/detail?r=6795
すいません、対応ありがとうございます
（作業がかぶって、同じパッチをかいていました）
ちなみに、
rosrun robot_model_conversion_tester testHRP2JSK.sh
はとおりますか？
なので、今は
links:
WAIST:
...
でリンクローカルな座標変換やCOMの値がでてますが、
テストとして複数の姿勢(init-pose, reset-pose, reset-manip-poesくらい？)の
グローバル（か腰相対）のリンク座標・COMの値、
全身のCOMの値なども比較したいと思ってます。
後者の全身の値やグローバルな値は
モデルとして必要なデータでなく冗長ですが、
これがないと問題になるケースが多々あります。
グローバルな値がないと、fix jointでつながれた
マスプロパティがカウントしわすれてた、ということが過去ありました。
グローバルな値については、youheiさんからチケットきってもらえると助かります。
結局テストコードでは、
- 変換で書き出されたモデルファイルを
- そのモデルファイルを読み込むプログラムの結果
でチェックすべきと思ってます。
例えば、VRMLから変換したeuslispのファイルは、
VRMLをModelLoaderで読み込んでロボットのインスタンスからえる結果(m_robotとか)と
euslispをeuslispのプロセスで読み込んでロボットのインスタンスから得られる結果(robotとか)と
を比較しないといけないと思いました。
ModelLoaderの上でEuslispのプロセスをforkして、
とやらなければ、何らかのファイルにかきだすのがいいかなぁと思って
今回はyamlにかきだしました。
さらに、yamlに書くべき内容はすべてのフォーマットに互換なロボットモデルというよりは、
積集合っぽいロボットモデルなのかなと思ってます。
例えばlvlimitの例だと(一旦colladaを介して変換することを無視すると)
VRML (lvlimit, uvlimit) -> Euslisp (uvlimitのみ)
としてそもそもの変換を行っています。
そもそもの変換でuvlimitのみが考慮されているので、
変換をチェックするプログラムもuvlimitだけ比較すればいいはずです。
この場合は、VRML -> Euslispの例でしたが、
VRML->collada, collada->euslisp, urdf->euslispなど
比較したいフォーマットの組み合わせで別々なyamlを作るのは大変そうなので、
異なるフォーマット間の組み合わせの間でのyamlの差異はなくしたほうが簡単そうです。
もちろん二つのロボットモデルフォーマットの間の積集合だけでなく、
リミットがハードリミットなのかソフトリミットなのか、といったところも
考慮したいですが、それでなくとも
慣性テンソル・重心が正しくない、軸の向きが違う、リンク座標系が違う、、、
といったバグのチェックにはなると思います。
連投になりますが、こちらは少し個別的なはなしになります。
lvlimit, uvlimitは両方もってるのはVRMLだけで、
euslisp, collada, urdfはuvlimitだけです。
実際にはVRMLでも大体のロボットでlvlimit= -1 * uvlimitと使われている気がしますし、
変換でその情報が抜け落ちるのであればuvlimitだけでいいと思います。
また、
の部分は、デフォルト値の問題だと思います。
モデルファイルでデフォルト値を書かないと
どういう値がいれられるかがモノによってマチマチです。
euslispでは関節リミットのデフォルト値は確か90度とかになっていますが、
VRMLやColladaのModelLoaderは不定値 (なので、概ね1e300とかでかい値)
が入ります。
モデルのチェックだけでなくモデルの変換も
で行われるほうがデフォルト値などが変換時に即値ではいるので、いいと思います。
現状、export-colladaではVRMLで関節limitを書いてない軸は
colladaでも関節limitがかいてないようです。
個人的には、ここはデフォルト値をいれたほうが後々混乱がないように思いますが、
ただ不定値をいれられると困りますね。
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が何個かあったきがします。
http://code.google.com/p/rtm-ros-robotics/source/detail?r=6846
にテストコードをついかしました．sample.wrlとsample.daeを読んできて比較します．試して下さい．
比較が足りないところがあれば教えて（追加して）下さい．
気がついたのは，
１） セグメントの名前が違う問題はキャッチできて上のパッチで直っている．
２） inertiaのパッチも追加されているけど，これが必要な場面sampleモデル，PA10モデルでは見つかっていない
３） ルートリンクの名前が違う．これは治したい．
あ，今気が付きましたが，robot_model_conversion_tester と同じことをやっていたのかな．テストコードとソースコードは近い所においたほうがいいので，openhrp3でexport-collladaのテストをしてcolladaとwrlが同じことを確かめて，euscolladaでeusとcolladaが同じであることを確認するのがいいと思います．
この方法だと、
- euslispフォーマットをeuslispで読み込んだ状態
- urdfフォーマットをurdf_parserで読み込んだ状態
- colladaフォーマットをcollada_parserで読み込んだ状態
...etc
の比較はどうしたらいいでしょうか。
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 <module>
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
（自分の手元はアップデートが足りない気がしますが）
この方法だと、
- euslispフォーマットをeuslispで読み込んだ状態
- urdfフォーマットをurdf_parserで読み込んだ状態
- colladaフォーマットをcollada_parserで読み込んだ状態
...etc
の比較はどうしたらいいでしょうか。
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 <module>
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
（自分の手元はアップデートが足りない気がしますが）
すいません、メッセージがpostできてないとおもい、２回postしてしまいました。
スレッドが増えると別ページになるんですね。。。
確かに、こちらの手元でも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++がうれしいのですが、どうでしょうか。
すいません、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して使うようになっているのがいいのかなぁと思っています
メリットデメリットですが，ｎ個のフォーマットがあった時に，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でもしょうがないだろうか．
https://openrtp.jp/redmine/issues/2170 で openhrp3のidlを <openhrp3>/lib/python2.7/OpenHRPにインストールしていますが，これすると<hrpsys>/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
の４つで、
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フォーマットを書き出すコンバータは
方法１、２どちらでも必要なので、ここでカウントすべきでないと思います。
なので、やはりコードの量・メンテするファイル数は方法１の方が増えると思ってます。
ただ、
おっしゃるとおりyamlもあやしいと思ってるので、方法１で
のように比較が適切なプログラムで行える方でいく、というので賛成です。
ファイル数が多い分も、本当にすべての変換をサポートしないでおくのでもいいのかもしれません。
例えば、n個フォーマットがあれば、ちょっと遠回りになりますが
ホントはn-1個の変換プログラムで全部のフォーマット間で変換ができますね。
上記の例ですと、euslisp->vrmlも環境モデルが吐き出せて便利ですが、
現状rbrainにあって唯一公開されてないプログラムなので、
ここをサポートせず他のファイルから変換していくのでもいいのかもしれません。
これは、（個人的には）普段はModelLoaderをc＋＋から利用するので
それでテストしたほうがわかりやすい、というのと、
リンクローカルな値以外にワールドに直したものを
比較するようなチェックをいれたくて、
そういった計算をするとなるとc++の方が普段使っているので
world_c = link->p + link->R * link->c
みたいにやりやすいのかな、ということでした。
ちなみにこれはpythonのサンプルだとnumpyとかを使うかんじなのでしょうか。
あまりopenhrp3のModelLoader利用時にこのへんの
演算まで行う標準的な方法がよくわかってません。
ここは何回か話題にでていますが，フォーマットの全部の変換は作らずに，決めたパスだけを作って整備するのでいいとおもいます．
そうでないと，このように全ての変換を作って，さらにそのテストをしなければいけなくなって，結局自分の首をしめるということになります．
自分の首を締めないためには，取捨選択する必要があります．
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ロボットモデルフォーマットを管理しなくていいのが嬉しいはずです．
それがしたい場合は，BodyInfoではなくBodyをつかって，比較するんでしょうね．
その場合はCの方が楽ですね．
僕もそうだと思っていて、
それ以外のパスもなくてもいいとは思います。
現状あって、かつjsk-ros-pkgなどでも公開されているので、
どこかの段階でけずっていくのかなと思います。
これもその通りですね。
今更ですが、今思うと方法２で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にしてチェックをしてました。
ただ、根本の原因は
の部分なので、yamlで変感外までトレースするよりここを直すべきでした。
euscolladaはcollada_parserにするのがいいですが、
collada_parserもopenraveの方に追いついていってないきもします。
（上記のバグもyouhei さんに調べてもらっているので、何かフォローお願いします）
openhrp3もcollada_parser的なかんじになるとメンテナンスが
軽くなりますが、難しいでしょうか。
ところで、
の作戦になったのはなんでなんでしたっけ？
僕があまりcolladaのメリットをわかってないだけかもしれませんが、
colladaを中心に回していくのはメリットよりデメリットの方がおおいように感じます。
urdf => urdfのmodel.h
vrml => openhrp3のBody.h
euslisp => euslispのcascaded-link
など、ロボットのモデルフォーマットにはそれを使うオススメソフトウェアや
ロボットのインスタンスがつきものです。
colladaだと、
collada => openraveのロボットクラス
が元来オススメなんだと思いますが、openraveを使わないとすると、例えば
のようにcolladaをよみこんでurdf/model.hで使うのであれば、
この部分はurdfでいいのでは、とも思います。
また新しいROSなどのソフトウェアを利用するときに、urdfだとそのまま使えますが、
colladaだとそのソフトウェアをcollada対応にするという
ワンクッションはいります。
rvizなどもそうしてきて、次は
gazeboもなので大変に思います。
ただ、"urdfだとそのまま使えますが"、もちょっと怪しいきもするので、
何を基準モデルフォーマットとしていくかは難しい問題だとも思います。
colladaも大変ですが、collada以外にしてもホントにラクなのかは判断が難しいと思います。
r6063でEuslispの変換チェックを行うものを、jsk_model_toolsに追加しました。