enable to read custom limb name from .yaml file #249
Conversation
…other than head,torso,larm,rarm,lleg,rleg, we set limb name to robot models
| // set limb_candidates from yaml fiels | ||
| for(YAML::const_iterator it=doc.begin();it != doc.end();++it) { | ||
| // -end-coords, *-vector | ||
| if ( boost::algorithm::ends_with(it->first.as<std::string>(), "-coords") || | ||
| boost::algorithm::ends_with(it->first.as<std::string>(), "-vector") ) { | ||
| } else { | ||
| limb_candidates.push_back(it->first.as<std::string>()); | ||
| } | ||
| } |
There was a problem hiding this comment.
-coords、-vector以外に、sensors replace_xmlsといったキーがあります。
https://github.com/start-jsk/rtmros_tutorials/blob/303e2bf87d1f6582017c4fe2a145db5d1ce99bca/hrpsys_ros_bridge_tutorials/models/hrp2jsknts.yaml#L73
これらのキーを除かないと、hrpsys_ros_bridge_tutorialsをbuildしたときに、
8: at (write-min-max-table-to-robot-model-file (staro) "/home/hiraoka/hiraoka_ws/ast_ws/src/rtm-ros-robotics/rtmros_tutorials/hrpsys_ros_bridge_tutorials/models/staro.l" :margin 1.0)
/opt/ros/melodic/share/euslisp/jskeus/eus/Linux64/bin/irteusgl FATAL ERROR on make-joint-min-max-table: unbound variable sensor_type_jt in (list rarm_joint0_jt rarm_joint1_jt rarm_joint2_jt rarm_joint3_jt rarm_joint4_jt rarm_joint5_jt rarm_joint6_jt rarm_joint7_jt larm_joint0_jt larm_joint1_jt larm_joint2_jt larm_joint3_jt larm_joint4_jt larm_joint5_jt larm_joint6_jt larm_joint7_jt rleg_joint0_jt rleg_joint1_jt rleg_joint2_jt rleg_joint3_jt rleg_joint4_jt rleg_joint5_jt lleg_joint0_jt lleg_joint1_jt lleg_joint2_jt lleg_joint3_jt lleg_joint4_jt lleg_joint5_jt head_joint0_jt head_joint1_jt chest_joint0_jt chest_joint1_jt sensor_type_jt translate_jt parent_link_jt sensor_name_jt translate_jt parent_link_jt sensor_type_jt sensor_name_jt rotate_jt sensor_name_jt sensor_type_jt parent_link_jt translate_jt rotate_jt sensor_name_jt sensor_type_jt parent_link_jt translate_jt sensor_name_jt rotate_jt sensor_type_jt parent_link_jt translate_jt parent_link_jt sensor_name_jt translate_jt sensor_type_jt rotate_jt), exitting...
Please comment in (load "irteus/irtrobot.l") in make-joint-min-max-table.l for debug
make[2]: *** [staro_joint_minmax_done] Error 1
make[1]: *** [CMakeFiles/staro_hrpsys_ros_bridge_tutorials_compile_joint_minmax.dir/all] Error 2
というエラーがでます。
今後どんなキーが追加されるか分からないので、#232 のようにyamlファイルにlimbs:を追加し、使用するlimbの一覧を取得できるようにした方がよいのではないでしょうか。
limbs: [rleg, lleg, torso, head, rarm, larm, right_hand, left_hand]
rleg:
- RLEG_JOINT0 : rleg-crotch-y
- RLEG_JOINT1 : rleg-crotch-r
- RLEG_JOINT2 : rleg-crotch-p
- RLEG_JOINT3 : rleg-knee-p
- RLEG_JOINT4 : rleg-ankle-p
- RLEG_JOINT5 : rleg-ankle-r
lleg:
- LLEG_JOINT0 : lleg-crotch-y
- LLEG_JOINT1 : lleg-crotch-r
- LLEG_JOINT2 : lleg-crotch-p
- LLEG_JOINT3 : lleg-knee-p
- LLEG_JOINT4 : lleg-ankle-p
- LLEG_JOINT5 : lleg-ankle-r
torso:
- CHEST_JOINT0 : torso-waist-r
- CHEST_JOINT1 : torso-waist-p
- CHEST_JOINT2 : torso-waist-y
head:
- HEAD_JOINT0 : head-neck-y
- HEAD_JOINT1 : head-neck-p
rarm:
- RARM_JOINT0 : rarm-collar-y
- RARM_JOINT1 : rarm-shoulder-p
- RARM_JOINT2 : rarm-shoulder-r
- RARM_JOINT3 : rarm-shoulder-y
- RARM_JOINT4 : rarm-elbow-p
- RARM_JOINT5 : rarm-wrist-y
- RARM_JOINT6 : rarm-wrist-r
- RARM_JOINT7 : rarm-wrist-p
larm:
- LARM_JOINT0 : larm-collar-y
- LARM_JOINT1 : larm-shoulder-p
- LARM_JOINT2 : larm-shoulder-r
- LARM_JOINT3 : larm-shoulder-y
- LARM_JOINT4 : larm-elbow-p
- LARM_JOINT5 : larm-wrist-y
- LARM_JOINT6 : larm-wrist-r
- LARM_JOINT7 : larm-wrist-p
right_hand:
- R_THUMB_JOINT0 : rhand-finger-0
- R_THUMB_JOINT1 : rhand-finger-1
- R_MIDDLE_JOINT0 : rhand-finger-2
left_hand:
- L_THUMB_JOINT0 : lhand-finger-0
- L_THUMB_JOINT1 : lhand-finger-1
- L_MIDDLE_JOINT0 : lhand-finger-2
There was a problem hiding this comment.
k-okada#1 に一つの修正案を作成しました。お役に立てれば幸いです。
There was a problem hiding this comment.
-coords、-vector以外に、sensors replace_xmlsといったキーがあります。
そんなのがあるのね．
それぞれどういう役割になっていますか？
sensors については，eusにセンサモデルを足すものであれば，
https://github.com/jsk-ros-pkg/jsk_pr2eus/blob/master/pr2eus/make-pr2-model-file.l#L36
みたいな方法ではなくて，yamlからセンサを追加できたら嬉しいので，そちらが正攻法かとおもいました．
replace_xmls:
はどういう役割なんだろうか？よいPRだとおもいますが，
１）冗長．larm: を書く場合はlimb: に追加すること，という必要ないルールが追加されている
（現状でlarm-end-coordsにはlarm: を前提にするという必要ないルールがあるから，いまさらなんだけど，なので
:limb
:larm
:links
- LLEG_JOINT0
-...
:end-coords
...
みたいな感じで書いたほうが良かったかな，とかおもいました．今から変えるのはやり過ぎなのでこれは必要ないと思うけど，
２） -coords、-vector以外に、sensors
replace_xmlsといったキーが何か別のプログラムで使われていて，そのプログラムは:larm
などは使わないとすると，一つのファイルに書く必然性はないのかな，とおもいました．
それぞれの役割について.
sensorsは、collada2eusとadd_sensor_to_collada.pyで使われています.
- URDFにはセンサ情報が含まれていませんが、
rosrun euscollada collada2eus -I ./HRP2JSKNTS.urdf -C ./hrp2jsknts.yaml -O /tmp/hrp2jsknts.lとすると、yamlからセンサ情報を読んでセンサ情報を含んだeusモデルが生成されます。(この機能はrtmros系では使用されていません.) - URDFにはセンサ情報やエンドエフェクタの情報が含まれていませんが、
rosrun euscollada add_sensor_to_collada.py ./HRP2JSKNTS_WH.urdf -O /tmp/HRP2JSKNTS_WH_SENSORS.urdf -C ./hrp2jsknts.yamlとすると、yamlからセンサやエンドエフェクタの位置を読んで、センサやエンドエフェクタの位置にセンサの質量0のリンクがついたURDFが生成されます。(この機能はrtmros系でも使用されていますが、https://github.com/start-jsk/rtmros_common/blob/57053f52d7deb5044607ab5ec12843dc6094514c/hrpsys_ros_bridge/src/HrpsysSeqStateROSBridge.cpp#L43 と機能が重複しているので、どちらか一方があれば十分だと思います。)
replace_xmlsは、add_sensor_to_collada.pyで使われています。
- URDFにはgazeboシミュレーション用のパラメータの情報が含まれていませんが、
rosrun euscollada add_sensor_to_collada.py ./HRP2JSKNTS_WH.urdf -O /tmp/HRP2JSKNTS_WH_SENSORS.urdf -C ./hrp2jsknts.yamlとすると、yamlの記述に従ってURDFのxmlのノードを追加・置換することで、gazeboシミュレーション用のパラメータの情報を追加します。(この機能はrtmros系でも使用されていますが、gazeboのシミュレーションを利用している人は少なくなっています)
補足情報として、rarm:等は、https://github.com/start-jsk/rtmros_common/blob/master/hrpsys_ros_bridge/scripts/controller_config_converter.py でも使われています。
rosrun hrpsys_ros_bridge controller_config_converter.py hrp2jsknts.yaml hrp2jsknts_controller_config.yamlとすると、yamlの記述に従ってcontroller_config.yamlを生成します。(この機能はrtmros系でも使用されています)
1)2)について
2点明確化・訂正させていただきます。
-
limbのデフォルト値を
rleg,lleg,rarm,larm,head,torsoとしてあるので、従来通りrleg,lleg,rarm,larm,head,torsoしか使わない場合には、limb:に記述を追加する必要はありません。そのため、larm: を書くだけの場合にはlimb: に追加する必要はありません。hand:等を追加したい場合にはlimb: に追加しないといけないです。 -
add_sensor_to_collada.pyは、sensors:-end-coords:links:relpace_xmls:といったキーを使っているため、一つのファイルに書く必然性はあります。
hand:等を追加したい場合にlimb: に書かないといけないのは冗長だと僕も思います。また、現状の必要ないルール、必然性の無いファイル構成については、僕もB4の頃から同様の感想を抱いていました。そのため、自分は後方互換性等の責任を負う立場ではないこともあり、直して良いのでしたらどんどん直していきたいと思っていますし、自分用の個人ソフトウェアでは既にそうしています。一方で、後方互換性等を考えてなるべく今動いているプログラムをそのまま使えるようにすることを目指すなら、k-okada#1 のようにせざるをえないのかなあと思います。そこは、後方互換性等の責任を負う立場である @k-okada 先生にご判断いただきたいと考えております。
There was a problem hiding this comment.
sensorsについては、rtmros系とは異なる経路でモデルを変換するhttps://github.com/makabe0510/robot_assembler/blob/80fc1577f8ca3e0a684fa8af77dc8ea38b5de0b7/sample/SAMPLE_HUMANOID.urdf.euscollada.yaml#L57-L63 などでも使われています。
There was a problem hiding this comment.
replace_xmlsは、add_sensor_to_collada.pyで使われています。
- URDFにはgazeboシミュレーション用のパラメータの情報が含まれていませんが、
rosrun euscollada add_sensor_to_collada.py ./HRP2JSKNTS_WH.urdf -O /tmp/HRP2JSKNTS_WH_SENSORS.urdf -C ./hrp2jsknts.yamlとすると、yamlの記述に従ってURDFのxmlのノードを追加・置換することで、gazeboシミュレーション用のパラメータの情報を追加します。(この機能はrtmros系でも使用されていますが、gazeboのシミュレーションを利用している人は少なくなっています)
HIRONXJSKのgazeboシミュレーションもこの用途でreplace_xmlsを使っています。
https://github.com/start-jsk/rtmros_tutorials/blob/303e2bf87d1f6582017c4fe2a145db5d1ce99bca/hrpsys_ros_bridge_tutorials/models/hironxjsk.yaml#L92-L223
https://github.com/start-jsk/rtmros_tutorials/blob/master/hironx_tutorial/doc/index.rst#hironxjsk-picking-demo
他のrtmros系ロボットに比べると、比較的最近まで動いていたかと思います（学校来れるようになってからあまり使ってませんが・・・）。
There was a problem hiding this comment.
sensorsは、collada2eusとadd_sensor_to_collada.pyで使われています.
だとすると，yamlにsensors 入っていても問題ないのでは？となると，問題はreplace_xmlsでいいかな．
ちなみにこれは何をしているんだろう？
https://github.com/start-jsk/rtmros_tutorials/blob/303e2bf87d1f6582017c4fe2a145db5d1ce99bca/hrpsys_ros_bridge_tutorials/models/hrp2jsknts.yaml#L158-L167
で，{L,R}LEG_LINK{5,6}のmass/ixx を0にしている？
これはもとのwrlでは1e-03/1e-02とあってコレオノイドはこのパラメータで動くけど，gazeboは0にしているのかな
https://github.com/start-jsk/rtmros_tutorials/blob/303e2bf87d1f6582017c4fe2a145db5d1ce99bca/hrpsys_ros_bridge_tutorials/models/hironxjsk.yaml#L92-L223
みると逆か．コメントは重要だね．
# pr2_mechanism_model -> transmission_interface for gazebo with ros_control (temp patch, should be supported in collada_urdf)
はその通りなので，
ちなみにこの変換は wrl -> collada -> urdf ? wrl -> urdf 誰が8.07e-05の値を入れている collada_urdf か何かで以下のルールを入れると解消する？
- イナーシャの最小値は0でなければ1e-3
２）massの最小値は1e-3
nextageはこれで良さそう．HRP2は
replaced_xml: '<gazebo reference="R_INDEXPIP_R_LINK">\n <kp>140.0</kp>\n <kd>2800.0</kd>\n <mu1>1.5</mu1>\n <mu2>1.5</mu2>\n <fdir1>1 0 0</fdir1>\n <maxVel>10.0</maxVel>\n <minDepth>0.00</minDepth>\n </gazebo>'
はwrlにはない情報なのかな？指みたいに小さい物体の対応なのかな？
必要ないデータを読み込むのはかなり抵抗があるんだけど，add_sensor_to_collada.py -Cの引数を任意個とれるようにして，
rosrun euscollada add_sensor_to_collada.py ./HRP2JSKNTS_WH.urdf -O /tmp/HRP2JSKNTS_WH_SENSORS.urdf -C ./hrp2jsknts.yaml ./hrp2jsknts-replace-xml.yaml
とできると，euscollada 的には嬉しいけど，副作用大きすぎるだろうか？
There was a problem hiding this comment.
# pr2_mechanism_model -> transmission_interface for gazebo with ros_control (temp patch, should be supported in collada_urdf)はその通りなので，
こちらに関しては、ros/collada_urdf#35 でtransmission_interfaceを出力できるようにしたのですが、この時点ではstart-jsk/rtmros_gazebo#247 の問題があって最新のcollada_urdfを使えなかったのと、HIRONXJSK以外のロボットにもtransmission_interfaceを強制するのはアグレッシブすぎると感じたのですがhttps://github.com/start-jsk/rtmros_common/blob/57053f52d7deb5044607ab5ec12843dc6094514c/hrpsys_ros_bridge/cmake/compile_robot_model.cmake#L127 まで引数を渡す方法がすぐには実装できず、力尽きてしまった状態です。
start-jsk/rtmros_gazebo#247 は治っていると思うので、HIRONXJSK以外のロボットにもtransmission_interfaceを強制することにして、collada_urdf_jsk_patchでcollada_urdfの1.12.13を使うようにすれば（今は1.12.12）temp patch消せる気がしますが、そうしてみますか？
ちなみにこの変換は wrl -> collada -> urdf ? wrl -> urdf
wrl -> collada -> urdf だと思います。
誰が8.07e-05の値を入れている
これは、KawadaからもらったCADモデルから入っています。
https://github.com/start-jsk/rtmros_hrp2/blob/3ab613691eb742669c45c11458b95f047e463e63/hrp2_models/HIRONX/HIRONXmain.wrl#L373
真値かと言われると微妙な気もします。
collada_urdf か何かで以下のルールを入れると解消する？
イナーシャの最小値は0でなければ1e-3
２）massの最小値は1e-3
これに関しては、あくまでgazebo用の最小値なので、やるならcollada_urdfに何かの引数を与えるとこのルールが適用されるみたいにするのが適切ですかね。
ただ、この値に関してはかなり怪しくて、ロボット全体の質量によって変わるような気がしていて、この値をロボットに関わらず画一的に適用するのはよくない気がしています。
例えば、https://answers.ros.org/question/288237/robot-arm-is-broken-link-by-link-in-gazebo/ では0.0001で動いたと報告されているのですが、HIRONXJSKでこうすると動きませんでした（ロボットがgazebo上で分解しました）。
必要ないデータを読み込むのはかなり抵抗があるんだけど，
add_sensor_to_collada.py-Cの引数を任意個とれるようにして，rosrun euscollada add_sensor_to_collada.py ./HRP2JSKNTS_WH.urdf -O /tmp/HRP2JSKNTS_WH_SENSORS.urdf -C ./hrp2jsknts.yaml ./hrp2jsknts-replace-xml.yamlとできると，euscollada 的には嬉しいけど，副作用大きすぎるだろうか？
個人的にはこれはありな気がします。何か重大な問題を見落としてるかもしれないですが・・・。
There was a problem hiding this comment.
問題はreplace_xmlsでいいかな．
ちなみにこれは何をしているんだろう？
gazeboのシミュレーションに所望の挙動をさせるためのパラチューンと、gazeboのシミュレーションに必要な設定です。
前者については、シミュレーションに所望の挙動をさせるために必要なパラメータは、シミュレーションアルゴリズムやロボットの形状、行わせる動作ごとに異なることが多いので、大本のwrlファイルを修正したりモデル変換時に一括でルールを入れれば解消するというものではありません。理想的なシミュレータが発明されない限りは、個別に設定してやらざるをえないと思います。後者については、gazebo_ros_controlを使うかrtmros_gazeboを使うのかによって、必要な設定が異なります。
{L,R}LEG_LINK{5,6}のmass/ixx を0にしている？
これはもとのwrlでは1e-03/1e-02とあってコレオノイドはこのパラメータで動くけど，gazeboは0にしているのかな
ここではgazebo用にイナーシャの値を大きくしています。choreonoidでもこのパラメータでは動かないので、別の場所で修正しています。基本的には、もとのwrlには実機の制御用に実機の値を入れるべきだろうと思います。
# pr2_mechanism_model -> transmission_interface for gazebo with ros_control (temp patch, should be supported in collada_urdf)はその通りなので，
HIRONXはgazebo_ros_controlを使うのでその通りですが、https://github.com/start-jsk/rtmros_tutorials/blob/303e2bf87d1f6582017c4fe2a145db5d1ce99bca/hironx_tutorial/models/HIRONXJSK.gazebo.xacro#L8 脚型がある場合はhrpsysをgazeboと使うためにrtmros_gazeboを使うので、設定が異なります。 https://github.com/start-jsk/rtmros_tutorials/blob/303e2bf87d1f6582017c4fe2a145db5d1ce99bca/hrpsys_gazebo_tutorials/robot_models/HRP2JSKNTS/HRP2JSKNTS.urdf.xacro#L5
ちなみにこの変換は wrl -> collada -> urdf ? wrl -> urdf 誰が8.07e-05の値を入れている
replaced_xml: '<gazebo reference="R_INDEXPIP_R_LINK">\n <kp>140.0</kp>\n <kd>2800.0</kd>\n <mu1>1.5</mu1>\n <mu2>1.5</mu2>\n <fdir1>1 0 0</fdir1>\n <maxVel>10.0</maxVel>\n <minDepth>0.00</minDepth>\n </gazebo>'はwrlにはない情報なのかな？指みたいに小さい物体の対応なのかな？
gazeboで、指みたいに小さいリンクが、比較的小さな力で物体と接触するときに、安定してシミュレーションするためのパラメータです。足のようにやや大きいリンクが地面と大きな力で接触するときには、異なるパラメータが必要になります。多点接触のように、指みたいに小さいリンクが、外界と大きな力で接触するときには異なるパラメータが必要になります。odeの限界という感があります。
必要ないデータを読み込むのはかなり抵抗があるんだけど，add_sensor_to_collada.py -Cの引数を任意個とれるようにして，
rosrun euscollada add_sensor_to_collada.py ./HRP2JSKNTS_WH.urdf -O /tmp/HRP2JSKNTS_WH_SENSORS.urdf -C ./hrp2jsknts.yaml ./hrp2jsknts-replace-xml.yaml
とできると，euscollada 的には嬉しいけど，副作用大きすぎるだろうか？
特定のシミュレーター・動作に固有のデータを同じファイルに書くのには違和感を感じるため、./hrp2jsknts.yaml ./hrp2jsknts-replace-xml.yamlと分けるのは嬉しいです。下に書くような懸念点がありますが、どうにかなる範囲だと思います。
https://github.com/search?q=org%3Astart-jsk+replace_xmls%3A&type=code
https://github.com/search?p=1&q=org%3Ajsk-ros-pkg+replace_xmls%3A&type=Code
を検索すると、rtmros_common, rtmros_tutorialsと、腱駆動で使われているようです。僕の知識不足のため、腱駆動は副作用が分かりません。rtmros_common, rtmros_tutorialsについては、全部変えることはそこまで難しくなく、その結果問題が発生した場合に対応するのも難しくありません。ただ、rtmros_commonで定義されているcmakeのマクロをrtmros_tutorialsで使う関係で、過渡期にはrtmros_commonのaptを使うかsourceを使うかによる混乱が予想されます。また、rtmros_common, rtmros_tutorialsはブランチを切っているOBが多いので(僕は切っていません)、それらのブランチのビルドを通すにはgit merge origin masterをしないといけなくなり、そういうブランチはだいたいorigin/masterとconflictしているので十分に理解した人でないとgit merge origin masterができない、という問題もあります。
あと、add_sensor_to_collada.pyはlinks:というキーもとれて、以前は利用されていた形跡があります。今利用しているコードは見つけられませんでした。
https://github.com/start-jsk/rtmros_choreonoid/blob/49da4ca7d8a1b1ad244f28b2ec3859be6f764607/hrpsys_ros_bridge_jvrc/models/jaxon_jvrc.yaml#L118
|
euslisp/jskeus#598 の代わりに、 #249 を使うことによっても、同様にcustom limbが使えるようになることを確認しました。 #232 は |
|
@pazeshun と一緒に、次の2通りの目的と5通りの選択肢に整理してみたのですが、どうしましょうか。
目的1だけを手早く対応させるなら選択肢1、目的1と2を手早く対応させるなら選択肢1+5、目的1と2を丁寧に対応させるなら選択肢3+5、目的1と2を中間くらいで対応させるなら4かと思います。どの選択肢がよろしいでしょうか。
選択肢1-coords、-vector、sensors、 replace_xmls、links以外のキーを見たらlimbとして扱う方法 (このPRを微修正したもの) 選択肢2とする方法 (#249 (comment) の方法) キー 選択肢3とする方法. (k-okada#1 (comment) の方法) キー 選択肢4add_sensor_to_collada.py -Cの引数を任意個とれるようにして， とする方法. (#249 (comment) の方法) 一番目の引数のファイルはlimb, -vector, end-coords専用にする. ファイルが1つしか与えられていない場合は、後方互換性を考えて従来の方法でパースする 選択肢5add_sensor_to_collada.py -Cの引数を任意個とれるようにして， とする方法. (#249 (comment) の方法) 与えられたyamlをconcatenateして一つのyamlとして読んで、選択肢1か2か3と組み合わせる |
|
よく見るとエラーはminmax table のところで出ているので，そこで（sensor_type_jt ）のエラーチェック＆＆ワーニング出すというのは出来ないかな．これで，選択肢１，２でもなくて目的１が達成できないかな． 選択肢4と5の違いがわからないんだけど，というか選択肢５は，それ自体は特に何の副作用もなくて，設定ファイル全部変えてください，というと影響は大きいけど，，，と思うんだけど，，，なのでこっち一択だと思ったんだけど． |
なるほど! となっているときに、 rarmという名前のlimbにRARM_JOINT1という名前の関節を追加するのと同じように、 sensors という名前のlimbにsensor_type という名前の関節を追加してしまうのがエラーの原因になっています。 joint-listなどにsensor_typeという名前の関節が追加されてしまうので、minmax table 以外のあちこちでエラーが発生するので、minmax table の箇所だけをエラーチェックするだけでは厳しいと思われます。 そのため、collada2eusが変換するときに、sensor_type という名前の関節がcolladaモデルに含まれていないことに気づいて、sensorsという名前のlimbをスキップすればいけそうです。(以後、選択肢6と呼びます) ただ、ロボットモデルを利用できる状況でないとこの方法は使えない点が欠点です。yamlファイルのlimb情報を呼んでいるプログラムとして、他にhttps://github.com/start-jsk/rtmros_common/blob/cb56193225f64c25b705a6d2f544e5a5f597e327/hrpsys_ros_bridge/scripts/controller_config_converter.py#L35 があるのですが、このプログラムはロボットモデルを持っていないので、選択肢6が使えないです。 この問題さえなければ、選択肢6 + 5 がよさそうですね。 |
選択肢4は1つめのyamlにはcollada2eusに関係するキーしか入っていないという仮定がありますが、選択肢5にはその仮定が無い、という違いがあります。replace_xmlsが同じファイルに書いてある古いyamlが与えられた場合に、選択肢4はエラーになりますが、選択肢5はなりません。 |
|
@k-okada , @pazeshun とオフラインで話しました。 euscolladaは、選択肢5+6. 選択肢6がどのくらい簡単か?を様子をみたい controller_config_convreter.pyでは、選択肢1でやる.
euscolladaは、eusに必要なやつしか考えないようにしたい。他のキーはあってもいいが、無視。変な仮定はなし hrpsysの世界では、ignoreのリストがあろうが、キーの仮定があろうが、変な仮定があってもよい |
を追加したものを#250 に作成しました。 |
enable to read custom limb name from .yaml file (fix for #249)
this is another imlimentation for supporting non-default limbs, #232
if the limb name is other than head,torso,larm,rarm,lleg,rleg, we set limb name to robot models. So this does not require newer EusLisp/jskeus.