add #g read macro for reading binary encoding float/integer array

[YoheiKakiuchi]

バイナリエンコードされたfloat/integer-vector/matrixのリーダーを追加しました。
形式は以下です。
#g( array-dimensions element-type バイナリ文字列 ) の書式です。
#g((4 4) :float "xxx")

[snozawa]

+1
EUslispのfloat/integer-vector/matrixをバイナリでファイルにダンプする関数はあるんでしたっけ？

[garaemon]

これはテストあったほうがいい気がします。

[garaemon]

""の中はバイナリ文字列ということはエディタで見ると"@@@@@@@"みたいになるという事でしょうか?

[YoheiKakiuchi]

ダンプはeuslibにあります、移行する予定ですが書き直したいですね。

テストは以下です。
euslisp/jskeus#271

""の中はバイナリ文字列ということはエディタで見ると"@@@@@@@"みたいになるという事でしょうか?
これはそうです。読める方がいいかな？

[garaemon]

これはそうです。読める方がいいかな？

読めたほうがいいです、が高速化のために導入したいという事だと思うので、読める形(asciiに無理やり収める)にした時にパフォーマンスがどこまで落ちてしまうかがキーな気がします。

euslisp/jskeus#271
を見ると空白の文字列から突如としてベクトルが生成されていて、なんとも言えない感じを受けます。

[garaemon]

機能的には賛成です 👍

そのうちvectorだけじゃなくて#sで表現してる構造体もこっちで表現したほうが効率がいい、とかになりそうですね。

[snozawa]

そのうちvectorだけじゃなくて#sで表現してる構造体もこっちで表現したほうが効率がいい、とかになりそうですね。

+1
せめてcoordinatesはあるとありがたいですね。

[garaemon]

ASCIIでうまく表示できるのは32~127なので、パフォーマンスは最悪半分位になってしまうかもしれません。

[YoheiKakiuchi]

https://ja.wikipedia.org/wiki/Base64
データ量的にはそれほどでも無いけど、変換が手間だなあ

[garaemon]

これでできませんか?
https://github.com/euslisp/EusLisp/blob/master/lib/llib/base64.l

[garaemon]

Cでやるにしても、そこまで大変じゃなさそうです

http://tororo7.jimdo.com/2014/01/09/base64-c/

[YoheiKakiuchi]

Cで書くなら、松井さんコードをCにするのがいい気がする

[YoheiKakiuchi]

base64にしてみました。

[k-okada]

これってcommon-lispにある表記？

2015年9月18日金曜日、Yohei Kakiuchinotifications@github.comさんは書きました:

base64にしてみました。

—
Reply to this email directly or view it on GitHub
#139 (comment).

◉ Kei Okada

[YoheiKakiuchi]

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node191.html#SECTION002614000000000000000
ないですね。

[garaemon]

ここまでくると、#.でも実装できそうな気はしてきました

[garaemon]

#.(instance-array-from-base64 (2 2) integer "892ue92ue3")
みたいなイメージです

[garaemon]

肝心のパフォーマンスが大きく違うかもしれません。

[k-okada]

よくわかっていないですが，array-entity して出てきたバイナリをwrite-byte して書き出すのではダメなんだろうか？

バイナリ文字列，というのは結局プログラムで書き出すとすると，同じことな気がするんですが，

[k-okada]

@YoheiKakiuchi 先生．7年遅れでようやくこの問題にたどり着きました．
１）YoheiKakiuchi/jsk_model_tools@504cb1e を見ていますが，このバージョン（直接バイナリを"@@@"みたいに書き出す）だと，バイナリの中に偶然 \"=0x22 が入ってきた場合に上手く扱えない，という理解は正しいですか？
２）このPRだとbase64で書き出していますが，それに対応する jsk_model_tools のブランチはありますか？
３） collada2eusに--simple_geometry オプションがありますが，これを機能させたものはありますか？ ( jsk-ros-pkg/jsk_model_tools#244 )
４）hrp2/jaxon は結構重そうだけどどうしているのでしょうか？元のモデルのメッシュをへらしているんでしょうか? @kindsenior @Naoki-Hiraoka

[Naoki-Hiraoka]

hrp2/jaxon は結構重そうだけどどうしているのでしょうか？元のモデルのメッシュをへらしているんでしょうか?

hrp2/jaxonはVRMLモデルに対してopenhrp-export-colladaとcollada2eusを(特にメッシュ削減に関するオプションはつけずに)作用させてeusモデルを生成しています。

HRP2のVRMLモデルは元のモデルのメッシュをそのまま使っています。元のモデルのメッシュが十分削減されているのか、ロード時間はそこまで気になりません

$ roseus ./hrp2jsk.l
$ (bench (hrp2jsk))
;; time -> 0.276349[s]
#<hrp2jsk-robot #X5653bfc33f90 HRP2JSK  0.0 0.0 0.0 / 0.0 0.0 0.0>

JAXONやTABLISはのVRMLモデルは、CADのモデルのメッシュを削減したものを使っています。

参考

• https://github.com/start-jsk/rtmros_hrp2/pull/594
• https://github.com/start-jsk/rtmros_hrp2/blob/master/jsk_models/README.md
• https://github.com/start-jsk/rtmros_hrp2/blob/master/jsk_models/TABLIS/readme.md

全身のリンクのメッシュを削減している場合

$roseus ./tablis.l
$ (bench (tablis))
;; time -> 0.596054[s]
#<tablis-robot #X559384801640 TABLIS  0.0 0.0 0.0 / 0.0 0.0 0.0>

BASE_LINKとCHEST_LINK0だけCADのモデルのメッシュをそのまま使った場合

$ roseus ./tablis.l
$ (bench (tablis))
;; time -> 1.82508[s]
#<tablis-robot #X5652b119ddf0 TABLIS  0.0 0.0 0.0 / 0.0 0.0 0.0>

TABLIS全身のリンクをCADのメッシュをそのまま使った場合

;;openhrp-export-collada時に128Gのメモリを使い切ってしまってeusモデルを生成できず計測不能

[k-okada]

モデル作成時ではなくて，ファイルロードの時間が問題になっているのかな，という理解なんだけど，jsk-ros-pkg/jsk_model_tools#244 (comment) の以下のような結果を知りたいです．

$ ls -al unitreeeus/go1.l
-rw-rw-r-- 1 k-okada k-okada 57518932 Apr  1 14:40 unitreeeus/go1.l
$ time irteusgl unitreeeus/go1.l '(exit)'

real	0m3.116s
user	0m3.038s
sys	0m0.072s

[Naoki-Hiraoka]

すみません。誤解していました。以下のようになります。

HRP2の場合

$ ls -al hrp2jsk.l 
-rw-rw-r-- 1 hiraoka hiraoka 2106005  4月 22 16:48 hrp2jsk.l
$ time irteusgl hrp2jsk.l '(exit)'
real	0m0.216s
user	0m0.199s
sys	0m0.004s

全身のメッシュを削減しているTABLISの場合

$ ls -al tablis.l 
-rw-rw-r-- 1 hiraoka hiraoka 6123785  4月 22 18:15 tablis.l
$ time irteusgl tablis.l '(exit)'
real	0m0.385s
user	0m0.348s
sys	0m0.024s

BASE_LINKとCHEST_LINK0だけCADのモデルのメッシュをそのまま使ったTABLISの場合

$  ls -al tablis.l 
-rw-rw-r-- 1 hiraoka hiraoka 25093510  4月 22 16:49 tablis.l
$ time irteusgl tablis.l '(exit)'
real	0m1.135s
user	0m1.122s
sys	0m0.008s

[k-okada]

@Naoki-Hiraoka このときのファイルサイズはどれぐらいなんだろう．．．

[Naoki-Hiraoka]

追記しました。

[YoheiKakiuchi]

１）YoheiKakiuchi/jsk_model_tools@504cb1e を見ていますが，このバージョン（直接バイナリを"@@@"みたいに書き出す）だと，バイナリの中に偶然 "=0x22 が入ってきた場合に上手く扱えない，という理解は正しいですか？

はい、そのままのバイナリダンプは、バグの可能性があると思います。

２）このPRだとbase64で書き出していますが，それに対応する jsk_model_tools のブランチはありますか？

ないです。

３） collada2eusに--simple_geometry オプションがありますが，これを機能させたものはありますか？ ( jsk-ros-pkg/jsk_model_tools#244 )

ないように思います。

４）hrp2/jaxon は結構重そうだけどどうしているのでしょうか？元のモデルのメッシュをへらしているんでしょうか? @kindsenior @Naoki-Hiraoka

#g の件が jaxonかjaxon_redの読み込みが遅いための解決策だったと思うのですが、
jsk-ros-pkg/jsk_model_tools#148 こちらのhotfixで、
我慢できる程度の時間になって今に至っています。