urata_hrpsys_config.pyを分離する #557
Comments
|
いいと思いますが，ただ， |
|
@kyawawa |
|
ロボット毎の継承にすると |
|
今後*_hrpsys_config.pyに書くべき内容のフォーマットに仕様変更があるたびに，それに気づいた人が自分のロボットのコンフィグだけ編集してロボットごとにフォーマットがバラバラになる状況が容易に想像できるので，できる限りそうなりにくいような配慮があるといいと思います．
これは重要だと思います。この瞬間はバラバラになりましたね、でおわりますが、１年たつと、あのファイルは整理されていなくて使いずらい、新しいのを作るべきだ、となって、無限ループに入ります。
URATAHrpsysConfiguratorを継承しているクラスの記述
は何が書いてあるんだろう？ connectConstraintForceLoggerPorts はなんだろう？
一般の二足歩行ロボットに必要なrあ、さらに上流のConfigurator に渡すようなことも視野に入れるとよいと思います。
パット見でabcとrfsensorをここでつなげているのは何か変な気がします。
理想を言うと、ロボット毎に必要な情報は実機が持っているので、そこから必要なソースコード、あるいは、データは作られるべきです。
例えば、簡単なところでは、どのRTCを組み込むかは人が書いてあるとしても、そうだった時の残りの作業は記述のひつようはないですね。
https://github.com/start-jsk/rtmros_choreonoid/blob/master/hrpsys_choreonoid_tutorials/src/hrpsys_choreonoid_tutorials/choreonoid_hrpsys_config.py#L33
あるいは、ロボットのモデルはModelLoaderにはいっているから、コンパイル時にurdfやeuslispのモデルも、本当は作らなくてよいようになっています。
が、あえて、それをやっている、ということは押さえておくとよいと思います。
…--
◉ Kei Okada
--
◉ Kei Okada
2018年12月22日(土) 19:19 Tatsuya Ishikawa <[email protected]>:
ロボット毎の継承にすると
https://github.com/start-jsk/rtmros_choreonoid/blob/master/hrpsys_choreonoid_tutorials/src/hrpsys_choreonoid_tutorials/choreonoid_hrpsys_config.py
など，URATAHrpsysConfiguratorを継承しているクラスの記述が大変になりそうだということに気付いて手が止まりました．
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
はい．この点に関しては気をつけながら作業を進めていきます．
に該当するファイルの中身をあまり理解できておらず，Choreonoidや実機特有の設定が書いていそうだということしか分かっていません．
ここの理解が及ばなかったのですが，例えば今の場合どのような部分が必要のないところに当たるのでしょうか？ |
ログを増やしているだけで制御には関係ないですが，おそらくchoreodnoiの導入当初のデバッグ用とかでしょうか？？
ロボットの歩行制御等の確認用のログとしても必要なさそうなので，上流に流さず消すだけでいいと思います． |
|
何回か、同じ議論をしている気がしていて、少し整理したいので一旦待ってもらえますか。 |
本当にこれが達成されるかほどほどに疑問
これについては賛成 |
整理していただいた後でも構わないですが，過去の議論のスレッドやログがあれば共有していただけると助かります．
if文を消してファイルとクラスを分けるだけで可読性は上がると考えていたのですがイマイチでしょうか．
こちら，該当コミットなどはありますでしょうか． |
https://github.com/jsk-ros-pkg/trans_system/pull/401 パラメータ設定部分が分かりにくいのはそうだろうと思うのですが、pythonまわりのわかりにくさの根本は、
これはこういう流れだね。 pythonの修正 pythonの修正はすべてのロボットに必要となるはず（設定していないパラメータがあれば問題は発覚しないが、隠れているだけ） |
これは僕もそう思います．
これ僕のcommitですね．失礼しました． |
|
dbbf0d5 にてdocstringを書いた上で，今回の変更を適用した場合の継承関係の図も書いてみました．
この構成である理由や注意点などは含められませんでしたが，クラスの関係性や各クラスでどのようなことをやっているのかの簡単な説明は理解できる図になったと思います． |
|
やっぱりこの分離が必要だと感じてきましたが，どうでしょう． 現在，urata_hrpsys_configに各ロボット固有のパラメータが書かれており， そのため，urata系ロボット以外(レポジトリ自体も違う)では上記の(1),(2)をそれぞれ継承してさらにロボット固有のパラメータをそれぞれ設定する必要があります． そこで，#557 (comment) の図のような構成にすると簡潔に解決すると思っています． |
|
継承シンプルにしたいのは僕も賛成です． どう変更するかは置いておいて，こういう大規模な変更の時は，_new.pyとか_2.pyにしてしばらく併設して試験運用する，という形ならマージして貰いやすいのでしょうか？-> @k-okada 変更内容に関しては，
僕はResetPoseや，ST,ABCパラメータや，RTCリスト，ポート接続リスト，などの諸元はデータベースのように一つのcommon_robot_params.pyみたいなものにずらっと書かれていても悪くないと思っています．(これタブーだったりするんでしょうか)
もありますし． 何ならReal/Simでの違いも同じ場所に書いたら，実機ではどうだったっけ/Choreonoidではどうだったっけ，と右往左往しなくて済みますし． |
|
現状の整理ですが
１） RTC（ノード／コネクタ／パラメータについて）
JSKでロボットにかかわらず共通に使っているもの／ロボット毎に共通に使っているもの／個人に依存して使っているもの
２）実機とSim（Choreonoidのこと？）で違う所
はどうなっていますでしょうか．
…--
◉ Kei Okada
2019年3月15日(金) 18:32 Yasuhiro Ishiguro <[email protected]>:
継承シンプルにしたいのは僕も賛成です．
どう変更するかは置いておいて，こういう大規模な変更の時は，*_new.pyとか*_2.pyにしてしばらく併設して試験運用する，という形ならマージして貰いやすいのでしょうか？->
@k-okada <https://github.com/k-okada>
変更内容に関しては，
if文を消してファイルとクラスを分けるだけで可読性は上がると考えていたのですがイマイチでしょうか．
ここの方針が間違っていると全てが無駄なので，何か意見ある方はお願いします．
僕はResetPoseや，ST,ABCパラメータや，RTCリスト，ポート接続リスト，などの諸元はデータベースのように一つのcommon_robot_params.pyみたいなものにずらっと書かれていても悪くないと思っています．(これタブーだったりするんでしょうか)
他のロボットと比較調整することもありますし．
仕様変更があるたびに，それに気づいた人が自分のロボットのコンフィグだけ編集してロボットごとにフォーマットがバラバラになる状況が容易に想像できるので，
もありますし．
何ならReal/Simでの違いも同じ場所に書いたら，実機ではどうだったっけ/Choreonoidではどうだったっけ，と右往左往しなくて済みますし．
依然，クローズドなロボットは別ファイルになりますが，rtmros_tutorial側では引数で自由にclosed_robotA_param.pyを渡せるようにしておくとか．
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#557 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAeG3OTyWDyyzulUpDzsjmscU0rAkah0ks5vW2imgaJpZM4ZfX68>
.
|
|
思いつく範囲でしか列挙できないので補足あればお願いしたいところですが，
|
ほとんどのRTCは全ロボット共通だと思います．
見た感じJAXONとJAXON_REDのエラーリミット以外で異なるパラメータは無さそうですが． |
|
JSKでロボットにかかわらず共通に使っているもの・・・stable的なものからst,abc等々
ロボット毎に共通に使っているもの・・・某ロボットの直動アクチュエータ変換周りのRTC
これだったら，直動アクチューエタロボットだけconfig.pyが必要で後は
https://github.com/fkanehiro/hrpsys-base/blob/master/python/hrpsys_config.py#L734
（に足りないものがあればそれを追加する）でよいのでは？
RTCの有無(Robot_Hardware,VirtualForceSensor, TorqueFilter)
これは，
https://github.com/fkanehiro/hrpsys-base/blob/master/python/hrpsys_config.py#L975
でsimulationのときだけ入れる／入れないをしたらよいのでは？
一部ダンパ係数，エラーリミットなど
ダンパ係数は何の係数でしょうか？制御時のなんかのダンパ係数？ハードウェアに起因するものならモデルファイルに書いていないでしょうか？
エラーリミットはモデルファイルには書いていないでしょうか？
JAXONは関節角数も(multisense,THK_hand)
関節数が違うと何が困るでしょうか？
…--
◉ Kei Okada
--
◉ Kei Okada
2019年3月18日(月) 18:20 Tatsuya Ishikawa <[email protected]>:
１） RTC（ノード／コネクタ／パラメータについて）
ほとんどのRTCは全ロボット共通だと思います．
直動アクチュエータに関してはたしかIOBで吸収しているので，hrpsysのレイヤには出てきていないと思います．
２）実機とSim（Choreonoidのこと？）で違う所
見た感じJAXONとJAXON_REDのエラーリミット以外で異なるパラメータは無さそうですが．
multisenseやハンドの関節に関しては，wrlに追加されてはいますがhrpsysで使用していない(考慮しなくても問題ない)のではないのでしたっけ？
それと，実機の方にはサーボオンなどの関数が追加されていて，Choreonoid用にはデバッグ用のポートの追加などがありますね．
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
はい，今でもロボットの差異，実機/simで微妙に違う部分を，○○_hrpsys_config.pyのように継承を重ねて，RTCListやST,ABCの係数などを上書きしながら使い分けているのですが，共通部分のまとめ方を改良しないと，JSK以外のロボットから継承して使いづらいという話です．
現状，同じようにsetResetPose()を呼んでも，実機用/sim用のどちらのpyを継承したかで関節数の違う実機/simにそれぞれ用に正しい関節角リストが渡るよう工夫されているので，それが崩れてしまうと思います． |
|
現状，同じようにsetResetPose()を呼んでも，実機用/sim用のどちらのpyを継承したかで関節数の違う実機/simにそれぞれ用に正しい関節角リストが渡るよう工夫されているので，それが崩れてしまうと思います．
setResetPose () の中にangle-vector
が直書きになっているなら，実機用/sim用のどちらのpyというものはなくして，同じpyで関数の中でsimulation/実機で分岐させたら良いと思うのと，多分だけど，実機はmultisenseがなく，シミュレータはmultisenseがあるのかな？であればsimulatorを実機に併せて，multisenseはrobot
stateに入れないようにするんじゃないだろうか？実機もそうなっているんだよね？
…--
◉ Kei Okada
2019年3月18日(月) 19:53 Yasuhiro Ishiguro <[email protected]>:
はい，今でもロボットの差異，実機/simで微妙に違う部分を，○○_hrpsys_config.pyのように継承を重ねて，RTCListやST,ABCの係数などを上書きしながら使い分けているのですが，共通部分のまとめ方を改良しないと，JSK以外のロボットから継承して使いづらいという話です．
関節数が違うと何が困るでしょうか？
現状，同じようにsetResetPose()を呼んでも，実機用/sim用のどちらのpyを継承したかで関節数の違う実機/simにそれぞれ用に正しい関節角リストが渡るよう工夫されているので，それが崩れてしまうと思います．
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
直動/回転の変換はそれ用のRTCが外部のレポジトリに存在して，.pyで起動，接続されているはずです．
具体的には把握してないけど，一手間増えたり減ったりしてたと思います |
はい実機はmultisense,hand以外(のはず)です．しかし，本当にmultisense，THK_handの扱いを統一できるかは自信ないです．
僕も割とこちら派です．比較しやすいので． |
|
統合というのは concatenate ではなくて，一般化していく，ということだと考えて，
ー 実機とシミュレータは同じにして，choreonoide xxx というのは無くせないか
ー 必要なRTCは全てrtmros_common にいれて，個別のロボット向けのXXというのはなくせないか？
ー そのパラメータはモデルファイルには書いていないのか？
というのを確認するのがいいんじゃないでしょうか？
話を聞くと，他の人のはよくわからないけど自分のはこうで，，，，とい感じに聞こえて，その自分の部分でファイルなのかクラス構造が肥大化しているように見えるから，まずは他のロボットがどうなっているか知るところからでしょうか．
…--
◉ Kei Okada
2019年3月18日(月) 20:25 Yasuhiro Ishiguro <[email protected]>:
同じpyで関数の中でsimulation/実機で分岐させたら良いと思うのと，多分だけど，実機はmultisenseがなく，シミュレータはmultisenseがあるのかな？であればsimulatorを実機に併せて，multisenseはrobot
stateに入れないようにするんじゃないだろうか？実機もそうなっているんだよね？
はい実機はmultisense,hand以外です．しかし，本当にmultisense，THK_handの扱いを統一できるかは自信ないです．
実機用/sim用のどちらのpyというものはなくして，同じpyで関数の中でsimulation/実機で分岐させたら良いと思うのと
僕も割とこちら派です．比較しやすいので．
しかし，継承でファイルを分化していくのではなく，一つのファイルで統一的に記述する方針をとると，urata_hrpsys_config,
urata_real_hrpsys_config,
choreonoid_hrpsys_config,...などなどを全部統合するような大きな話になりますね・・・
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#557 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAeG3P38L-MknSBTLBZ0N3EDpJpbZAUxks5vX3ekgaJpZM4ZfX68>
.
|
これはそうですね．失礼しました．
これに関しては，実はいらないと思っています． 一つ一つ返信するのは難しいので僕の意見を書きます．
ファイルが膨大になり編集しづらくなる・diffが見づらくなるというこのissueを立てた本来の問題が解決しないだけでなく，
こういった問題が頻発します． また，1つのシミュレーションのみを使っている場合は良いですが，他のシミュレーションを使いたくなって，仮にそれ固有の設定をしなければいけなくなった時に，またif文を増やすか，結局configを継承するかということになると思います．
これは完全におっしゃるとおりなのですが，
という点で，結局僕が以前書いた図のようにするしかないのではと信じています(URATAHrpsysConfiguratorを消したり，2つあるChoreonoidHrpsysConfiguratorを1つにするあたりは残っていますが) |
見づらいのもよくわかるけど，ファイルが増えて管理が行き届かなくなるのも中々の問題では？
外部のロボットがひと手間増えるのはしょうがない気がするけど，うまくいけば，rtmros_commonかrtmros_tutorialsの.pyを一回継承して実機/sim用のパラメータを上書きするような1つのpyだけで済むのでは？
ちょっと先を視過ぎな気がするけど，一時的に使うならchidori_simX_config.pyを作ればいいと思うけど，正式採用する際にまた○○_simX_config.pyがロボットの数だけ発生するのはいかがなものか
これは継承後にconnect関数を上書きすればよいのでは？(正式採用するなら継承元のsim場合のconnectのとこに書く)
できないのは賛成だけど，情報を一元化して管理を容易にすべき，という意味でファイルを分化させるのは大変では？(Pythonライクかどうかという話になると自信ないのだけど) |
|
ファイルが増えるのを嫌うのは分かりますが，同じファイルに複数の異なるロボットの設定があるのは同じくらい嫌ですし，現状起こっているようにどこかで歪が生じるはずです．
これは確かにイマイチな点でした． 結局，「例外的にこうしておいて，後で他と同じようにする」という運用を許してしまうと例外が何ヶ月にもわたって残ることは目に見えるので，始めから統一的な分け方をしておきたい，ということも大きいです． |
論点が 1),2)の２つになってきているように思います。 1)はメリット/デメリットが拮抗しており、変更のメリットが薄そう。 2)は、そもそも特定のロボットのpyが使いにくいだけではないかという考え方はどうだろうか？ |
|
SampleRobotやHRP2といった非URATA系のロボットでも使えるように， |
@YutaKojio さんと話したのですが，ロボット毎の設定が全てurata_hrpsys_config.pyに書かれており，非常に編集しづらいかつ，gitのdiffも見づらい状況になっています．
jaxon_hrpsys_config.pyやchidori_hrpsys_config.pyでURATAHrpsysConfiguratorを継承したクラスを作り，そこで設定を行おうと思うのですが問題のある方はいますでしょうか？ >
@kindsenior @YuyaNagamatsu @shintarokkk
The text was updated successfully, but these errors were encountered: