Fix init-ending overwrite

[snozawa]

#508

@YoheiKakiuchi
please check.

[snozawa]

この直し方じゃない気がしてきました。

[YoheiKakiuchi]

この直し方じゃない気がしてきました。

どうしてかな？

[snozawa]

euslisp/jskeus#428
にPRしてみました。

joint min/max table自体はupstreamのjskeus本体の機能なので、そこを修正すると良い気がしました。
upstreamの:init-endingでdefine-min-max-tableをよぶことで、hrp2jsk.lなどのファイルの中で:init-endingをそもそも定義する必要がなくなり、それに伴うアヤシイコード（このPR）も必要なくなるような気がしました。

[snozawa]

このPRの代わりに、euslisp/jskeus#428 に対応した別途rtmros_tutorials側の修正はいりそうです。
ちなみに、あんまりよくない副作用？ですが、上記別途の対応がなくても euslisp/jskeus#428 が取り込まれれば、#508 の問題は治るっぽいです。
誤って:init-endingが上書きされても、:define-min-max-tableされるのが上の:init-endingなので。

[k-okada]

euslisp/jskeus#428 (comment) > so best way is to set min-max-table when we make each joint,

か #508 でよくないかな．KISS, keep simple and stupid とこれまで思っていたんだけど、wikipediaみるとkeep simple, stupid なんだね．そういうつもりはなくて、http://www.shoeisha.com/book/hp/pc/book/hsl/linus.html 読んで感銘を受けて、いつも心がけていたつもりなんだけど、勘違いだったか．「KISSとは “Keep it Simple, Stupid”、あるいは “Keep it Simple and Small” の略なんだけど」となっている．linuxはstupid なコードは書いていないんだな．ムムム．

長期的には、そもそもstaro/jaxon系で:init-endingに追加している部分がよくなくて、bodyはmodelかえたらいいし、coordsはどうするんだろうね．リンクを作ればいいのかな．というか、別リンクになっていたら、(:hogehoge-link ()) でアクセスできないっけ？

[snozawa]

長期的には、そもそもstaro/jaxon系で:init-endingに追加している部分がよくなくて、bodyはmodelかえたらいいし、coordsはどうするんだろうね．リンクを作ればいいのかな．というか、別リンクになっていたら、(:hogehoge-link ()) でアクセスできないっけ？

そうですね。これはおっしゃるとおりだと思います。
モデル形状は、VRMLでかえるべきですね

他、coordsなどは:init-endingに書く以外のアイデアが浮かんでない状態です。
リンクを作る、は、euslispの段階で追加するのであれば、:init-endingに書くという点では同じっぽいですし、
それ以前（convert前、VRMLなど）で追加すると仮想のリンクが増えることによるキネマティクスやシミュレータの計算が増えそうで、影響が大きくKISSでないかな、とちょっと思いました。

euslisp/jskeus#428 (comment) > so best way is to set min-max-table when we make each joint,

こちらは、もしmake-min-max-tableが超はやければ確かにbest wayだと思います。
モデルのインスタンスを生成するときのjointインスタンス生成時に実行すると、
現状（とrbrainのころから）、やや時間がかかってたようなので、極力モデルインスタンス生成時間を減らすためには
make-min-max-tableを事前にモデルファイルconversion時に行うように、分けるのかなあと思ってます。

一旦#509, #508などをみた挙句、euslisp/jskeus#428 を作ったのもKISSを考えたためです。
:init-endingのoverwriteをたくみにやるよりは、joint-min-max-talbe自体が存在するirteusのレベルで行う方が、
この辺に必要になってくるコードの量、メンテしないといけないファイル数がへるためです。

ただ、#509 (comment)
にコメントいただいて改めて思い返してみると、モデルに:init-endingを追加する部分（https://github.com/start-jsk/rtmros_tutorials/blob/master/hrpsys_ros_bridge_tutorials/euslisp/make-joint-min-max-table.l#L164-L169）をなくして、
#508
のようにutilsでinit-endingを追加するだけにしておけば、
:init-endingが２箇所にバッティングすることもないので、
#508の路線でいくならそれが一番シンプルな気がしました。

なので、#508をちょい修正するPR作ってみようと思います

[k-okada]

他、coordsなどは:init-endingに書く以外のアイデアが浮かんでない状態です。 リンクを作る、は、euslispの段階で追加するのであれば、:init-endingに書くという点では同じっぽいですし、 それ以前（convert前、VRMLなど）で追加すると仮想のリンクが増えることによるキネマティクスやシミュレータの計算が増えそうで、影響が大きくKISSでないかな、とちょっと思いました。

これは以前からある、センサのframeが出ないもんか、という話と似ているんじゃないかな． 確かにシミュレータの中身がどうなっているかだけど、fixedなlinkをつけて、計算が増えるのは、シミュレータを直したいところです．

こちらは、もしmake-min-max-tableが超はやければ確かにbest wayだと思います。

これはインスタンスの生成時にmake-min-max-tableをするのではなくて、min-max-tableをした結果を.ｌにかいておいて、それを、そのままinstance生成時に渡す、といものです． euslisp/jskeus#428 (comment) が:init-endingで全部まとめてやっているのを分散させて、それぞれの関節生成時にやるということです． なので今のやりかたがOKなら、bestwaｙの方法もOKだとおもいます． そうすると、init-endingを上書きする必要はないですが、coords/bodyを:init-endingに書いてあるロボットがある以上、あまり意味はないんだけど．とすると、 最も単純な方法でいいんじゃないか、という結論で #508 でいいかな．と． euslisp/jskeus#428 は一瞬綺麗に見えるけど、新しい暗黙のメンバ関数を定義して、その使い方が、全てのロボットに関係するものではない、という意味であまり良くないと思います．

[snozawa]

Close according to #509.
Moved to #511.