meshデータの軽量化について

[pazeshun]

@wkentaro
現在、 #1224 に基づいてURDFデータの作成を進めています。去年のURDFを見ていた時、meshデータが軽量化されていることに気づきました。
この軽量化は、モデルの表示を軽くするためのものなのでしょうか。それとも、もっと必然性があって、軽量化しないと動かないみたいな問題があるのでしょうか。

去年のmeshデータを見ると、軽量化のしすぎでモデルが若干崩れてしまっていて、ここまで軽量化する理由がわからなかったのでご質問しました。もし必然性があるなら、MeshLabで去年と同レベルの軽量化を行います。そうでなければ、もうちょっとモデルをきれいに保ちたいと思うので、若干データサイズが増えると思います。

[k-okada]

Rvizの表示としてはほとんど変わらないですが、eusに変換した時に、生成されるbaxter.lに全てのメッシュ情報が含まれて、ファイルサイズが大きくなるにでloadした時にめっちゃ時間かかるという問題があります。

◉ Kei Okada

2016/04/12 9:39、pazeshun [email protected] のメッセージ:

@wkentaro
現在、 #1224 に基づいてURDFデータの作成を進めています。去年のURDFを見ていた時、meshデータが軽量化されていることに気づきました。
この軽量化は、モデルの表示を軽くするためのものなのでしょうか。それとも、もっと必然性があって、軽量化しないと動かないみたいな問題があるのでしょうか。

去年のmeshデータを見ると、軽量化のしすぎでモデルが若干崩れてしまっていて、ここまで軽量化する理由がわからなかったのでご質問しました。もし必然性があるなら、MeshLabで去年と同レベルの軽量化を行います。そうでなければ、もうちょっとモデルをきれいに保ちたいと思うので、若干データサイズが増えると思います。

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[pazeshun]

なるほど。つまり、モデルの見栄えを犠牲にしてでも軽量化しないと、loadに無駄な時間がかかってしまうってことですね。loadに無駄な時間がかかるのは生産性を大きく下げる気がするので、見栄えを犠牲にしてでも軽量化します。

ありがとうございました。

[wkentaro]

ちなみにbaxterusにあるbaxter.lのロード時間: 4s
baxter_descriptionから直接作ったbaxter.lのロード時間: 5sだったので、baxterのモデルに関しては時間の問題はあまり問題なさそうです。

# load.l
(load "baxter.l")
(setq *baxter* (instance baxter-robot :init))
(exit)

[k-okada]

おや，
baxter.lのファイルのサイズはどれぐらい違うかな．baxter_descriptionそのものが軽量になったのかな？

◉ Kei Okada

On Wed, Apr 13, 2016 at 5:57 PM, Kentaro Wada [email protected]
wrote:

baxterusにあるbaxter.lのロード時間: 4s
baxter_descriptionから直接作ったbaxter.lのロード時間:
5sだったので、baxterのモデルに関しては時間の問題はあまり問題なさそうです。

load.l

(load "baxter.l")
(setq baxter (instance baxter-robot :init))
(exit)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#1269 (comment)

[wkentaro]

17MBと88MBくらいだったと思います。

和田 健太郎 / Kentaro Wada
http://wkentaro.com/

2016年4月14日 19:35 +0900 に Kei [email protected]は書きました:

おや，
baxter.lのファイルのサイズはどれぐらい違うかな．baxter_descriptionそのものが軽量になったのかな？

◉ Kei Okada

On Wed, Apr 13, 2016 at 5:57 PM, Kentaro [email protected]
wrote:

baxterusにあるbaxter.lのロード時間: 4s
baxter_descriptionから直接作ったbaxter.lのロード時間:
5sだったので、baxterのモデルに関しては時間の問題はあまり問題なさそうです。

load.l

(load "baxter.l")
(setq baxter (instance baxter-robot :init))
(exit)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#1269 (comment)

—
You are receiving this because you were mentioned.
Reply to this email directly orview it on GitHub(#1269 (comment))

[k-okada]

遅くなりましたが，実害がなければわざわざリポジトリを変えなくてもいいですね．baxter_descriptionが軽くなったのかな？
わかっていないけど，以下のcollioisn_stl が使われたようになったのかな．
RethinkRobotics/baxter_common@231edd6

◉ Kei Okada

2016-04-14 20:01 GMT+09:00 Kentaro Wada [email protected]:

17MBと88MBくらいだったと思います。

和田 健太郎 / Kentaro Wada
http://wkentaro.com/

2016年4月14日 19:35 +0900 に Kei [email protected]は書きました:

おや，
baxter.lのファイルのサイズはどれぐらい違うかな．baxter_descriptionそのものが軽量になったのかな？

◉ Kei Okada

On Wed, Apr 13, 2016 at 5:57 PM, Kentaro [email protected]
wrote:

baxterusにあるbaxter.lのロード時間: 4s
baxter_descriptionから直接作ったbaxter.lのロード時間:
5sだったので、baxterのモデルに関しては時間の問題はあまり問題なさそうです。

load.l

(load "baxter.l")
(setq baxter (instance baxter-robot :init))
(exit)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
<
https://github.com/start-jsk/jsk_apc/issues/1269#issuecomment-209314774>

—
You are receiving this because you were mentioned.
Reply to this email directly orview it on GitHub(
#1269 (comment))

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#1269 (comment)

[wkentaro]

レポジトリを変えなくていいというのは、
自動生成しなくていいという意味ですか。

[k-okada]

今はbaxter.lを（手元でbaxter_descriptionのbranchを切り替えてmakeして生成して，そのファイルを）コミットしているけど，
それはしなくてよくて，makeしたとき，debをつくるときにオンラインで生成される形が可能になった（やらなくてよい），という理解なんだけどあってる？

◉ Kei Okada

2016-04-18 21:09 GMT+09:00 Kentaro Wada [email protected]:

レポジトリを変えなくていいというのは、
自動生成しなくていいという意味ですか。

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#1269 (comment)

[wkentaro]

はい、僕もそう思っています。
ただ、baxtereusのbaxter.lへの変更履歴で関節のリミットを変更している所があり、理由がわかってなくて保留にしている段階です。

和田 健太郎 / Kentaro Wada
http://wkentaro.com/

2016年4月18日 21:30 +0900 に Kei [email protected]は書きました:

今はbaxter.lを（手元でbaxter_descriptionのbranchを切り替えてmakeして生成して，そのファイルを）コミットしているけど，
それはしなくてよくて，makeしたとき，debをつくるときにオンラインで生成される形が可能になった（やらなくてよい），という理解なんだけどあってる？

◉ Kei Okada

2016-04-18 21:09 GMT+09:00 Kentaro [email protected]:

レポジトリを変えなくていいというのは、
自動生成しなくていいという意味ですか。

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#1269 (comment)

—
You are receiving this because you were mentioned.
Reply to this email directly orview it on GitHub(#1269 (comment))

[wkentaro]

これが関係あるでしょうか。
jsk-ros-pkg/jsk_model_tools#28

[k-okada]

https://github.com/jsk-ros-pkg/jsk_robot/pull/337/files
の変更は可動範囲を広げる方向にとっているんだよね．一方
jsk-ros-pkg/jsk_model_tools#28
はURDFの範囲はハードリミット，euslispはソフトリミットとして可動範囲を狭める方向に持って行きたい
という希望で逆になります．

実機の可動範囲をちょっと調べてみて，上のjsk-ros-pkg/jsk_robot#337 と比較してみるのがいい気がする

[wkentaro]

jsk-ros-pkg/jsk_robot#592