melodic環境でcollada_urdfで変換したロボットモデルをspawnするとgazeboがsegmentation faultする．

[Naoki-Hiraoka]

Please see
ros/collada_urdf#34
https://bitbucket.org/osrf/gazebo/issues/2682
gazebosim/gazebo-classic#2682

[Naoki-Hiraoka]

assimp v4.1.0とgazeboの相性が悪く、
melodic環境のcollada_urdfが依存しているassimpはmelodic環境ではaptでv4.1.0が入るため、
melodic環境でcollada_urdfで変換したロボットモデルをspawnするとgazeboがsegmentation faultします。

一方、
melodic環境のcollada_urdf_jsk_patchはassimp-devel 2.1.13に依存しており、
assimp-devel 2.1.13はassimp v3.1.1にpatchを当てたものであるため、
melodic環境でcollada_urdf_jsk_patchで変換したロボットモデルをspawnしてもgazeboはsegmentation faultしません。

従って、rtmros系の多くのロボットはcollada_urdf_jsk_patchで変換されているので、melodic環境では問題なくgazeboが使えます。

[pazeshun]

従って、rtmros系の多くのロボットはcollada_urdf_jsk_patchで変換されているので、

これはどこを見るとわかるでしょうか。

[Naoki-Hiraoka]

こちらです。
https://github.com/start-jsk/rtmros_common/blob/481dec748084d7149c7d16efc1ccb4101e1a5275/hrpsys_ros_bridge/cmake/compile_robot_model.cmake#L319

collada_urdf_jsk_patchがインストールされている場合はcollada_urdf_jsk_patchを使い、そうでない場合はcollada_urdfを使います。
collada_urdf_jsk_patchは、hrpsys_gazebo_general( https://github.com/start-jsk/rtmros_gazebo/blob/master/hrpsys_gazebo_general/package.xml ), hrpsys_gazebo_tutorials( https://github.com/start-jsk/rtmros_tutorials/blob/master/hrpsys_gazebo_tutorials/package.xml )のpackage.xmlに書かれています。

[YoheiKakiuchi]

@Naoki-Hiraoka

assimp v4.1.0とgazeboの相性が悪く、
melodic環境のcollada_urdfが依存しているassimpはmelodic環境ではaptでv4.1.0が入るため、
melodic環境でcollada_urdfで変換したロボットモデルをspawnするとgazeboがsegmentation faultします。

assimpで出した.dae の読み込みでsegmentation faultするということかな？

[Naoki-Hiraoka]

assimpで出した.dae の読み込みでsegmentation faultするということかな？

はい。
こちらのcommit assimp/assimp@36e53b7#diff-758737a587ca204dec82e47c452466d2 の前後でassimpで出した.daeの表現が変わったために、gazeboで読み込む際にsegmentation faultするようになったと考えています。

[pazeshun]

collada_urdf_jsk_patchがインストールされている場合はcollada_urdf_jsk_patchを使い、そうでない場合はcollada_urdfを使います。
collada_urdf_jsk_patchは、hrpsys_gazebo_general( https://github.com/start-jsk/rtmros_gazebo/blob/master/hrpsys_gazebo_general/package.xml ), hrpsys_gazebo_tutorials( https://github.com/start-jsk/rtmros_tutorials/blob/master/hrpsys_gazebo_tutorials/package.xml )のpackage.xmlに書かれています。

なるほど、では注意事項としては、gazeboを使いたければ、collada_urdf_jsk_patchがrosdepなどで入った後にモデルを作った（hrpsys_ros_bridge_tutorialsをビルドした等）かどうかを確認する必要がある、ということでしょうか。
というのは、hrpsys_ros_bridge_tutorialsをビルドするだけなら、hrpsys_gazebo_generalやhrpsys_gazebo_tutorialsの依存関係を満たさなくてもできてしまうので。
collada_urdf_jsk_patchを入れた後にビルドし直しても、git clean -fdxとかでモデルを一度消さない限り更新されない気がするので、READMEかどこかに書いておいた方がいいかもしれません。

[Naoki-Hiraoka]

collada_urdf_jsk_patchを入れた後にビルドし直しても、git clean -fdxとかでモデルを一度消さない限り更新されない気がするので、READMEかどこかに書いておいた方がいいかもしれません。

start-jsk/rtmros_tutorials#569 に書きました

[k-okada]

@YoheiKakiuchi @Naoki-Hiraoka

これ，確認したいんだけど，そもそもsegmentation fault しないんだけど，どうやって確認出来るんだろう？
とりあえず，

git clone https://gist.github.com/d917b82418dcbcbdb478bb106f7ae0ff.git test
cd test
bash ./test.sh

として試しています．

試したのは，

1. collada_urdf
2. collada_urdf_jsk_patch (最近のjsk_3rdpartyの変更がだめかとおもって2.1.17を利用）
3. assimp_devel
4. assimp
   で1)2)は box.urdf をdaeに変換，3)4)はbox.stlをdaeに変換

で，1) 2)は

[Err] [ColladaLoader.cc:886] Unable to find vertices[#gkmodel0_link_box_geom0/vertices] in collada file
[Wrn] [Event.cc:61] Warning: Deleting a connection right after creation. Make sure to save the ConnectionPtr from a Connect call
[Err] [Connection.cc:546] Connection[3] Closed during Read
[Err] [TransportIface.cc:375] Unable to read from master
[Err] [GLWidget.cc:881] Unable to connect to a running Gazebo master.

4)は

[Wrn] [Event.cc:61] Warning: Deleting a connection right after creation. Make sure to save the ConnectionPtr from a Connect call
[Err] [Connection.cc:546] Connection[5] Closed during Read
[Err] [TransportIface.cc:375] Unable to read from master
[Err] [GLWidget.cc:881] Unable to connect to a running Gazebo master.

とエラーになる．（３）は動きます．

幾つか問題がある気がするんだけど，

k-okada@p51s:~/catkin_ws/ws_assimp$ ldd devel/lib/collada_urdf_jsk_patch/collada_to_urdf | grep assimp
	libassimp_devel.so.3 => /home/k-okada/catkin_ws/ws_assimp/devel/lib/libassimp_devel.so.3 (0x00007f55a6b16000)
k-okada@p51s:~/catkin_ws/ws_assimp$ ldd devel/lib/collada_urdf_jsk_patch/urdf_to_collada | grep assimp
	libassimp.so.4 => /usr/lib/x86_64-linux-gnu/libassimp.so.4 (0x00007f68dd429000)

みたいにそもそも，ちゃんとassimpにリンクされていないレベルなんだけど，このへんは他の人はちゃんとコンパイル出来ているのかな．
追記：これはこれでいいのか．urdf書き出し時にassimpを使う．urdf_to_colladaはgeometry_shapesがassimpに依存している．

[k-okada]

あれ？assimpを使ってモデルファイルをdaeにしてsdfのgeometryで読み込ませているんだけど，
問題になっているのはdaeをurdfに変換したとき？？？？
いや、リンク先はcolladaのファイル書き方が変わった話をしているよね

[YoheiKakiuchi]

@k-okada
collada_to_urdfを使うときに、-A オプション(assimpを使ってメッシュを出力する)を使っていて、これを使うとassimpを使うメッシュになって、落ちると思います。
https://github.com/start-jsk/rtmros_common/blob/master/hrpsys_ros_bridge/cmake/compile_robot_model.cmake#L127

これを使わないと、collada_to_urdf内のメッシュ書き出しで書き出されるのですが、この時は、色違いの複数のメッシュが一つになったdaeなどを上手く書き出すことができずに、添付の写真のようになります。

assimpを使わずに、こちらをデバッグする作戦もありえますね。

[Naoki-Hiraoka]

こちらでassimp3.1.1で出力したdaeは正しく表示され，assimp4.1.0で出力したdaeはエラーになるサンプルを作成しました.
https://gist.github.com/Naoki-Hiraoka/4e0a5c41227f161cf5b081459bdfb5cc
自分のubuntu16.04の環境では，segmentation faultで終了するのではなく，ターミナルにスペース文字が無数に出力され続けるような挙動になりました．

collada_to_urdf内のメッシュ書き出しで書き出されるのですが、この時は、色違いの複数のメッシュが一つになったdaeなどを上手く書き出すことができずに、添付の写真のようになります。

ros/collada_urdf#18 の問題については，直し方が汚いためプルリクエストは出せていませんが，以前，https://github.com/Naoki-Hiraoka/collada_urdf/tree/fix-issue18 を用いると直りました．
他にも色々な問題があるようですね．

[k-okada]

こちらでassimp3.1.1で出力したdaeは正しく表示され，assimp4.1.0で出力したdaeはエラーになるサンプルを作成しました.

これは，僕の環境(18.04)で

(3) assimp_devel (3.1.1)
(4) assimp (4.1)

で，(4)がエラーで(3)はエラーがでない，とホボ同じ結果，という理解でいいかな．

ちなみに，色は微妙に違いますね．．．

collada_to_urdfを使うときに、-A オプション(assimpを使ってメッシュを出力する)を使っていて、これを使うとassimpを使うメッシュになって、落ちると思います。

というのは，やっぱりurdf_to_colladaの話ではなくて，collada_to_urdf のはなしで，urdfするときに各linkを書き出すときのmeshモデルがdaeででてくる話か．．

ということで，
https://gist.github.com/d917b82418dcbcbdb478bb106f7ae0ff.git
を更新しました．

ちなみに試してみると，meshlab では落ちるけどblenderだと動くので，assimpのバグ，と言うよりローダの問題ですかね．．．．
＝＝
で，meloidc限定ですが，，，jsk-ros-pkg/jsk_3rdparty#209
でcollada_urdf_jsk_patch で

1. collada_to_urdf で assimp-devel を使う．ただしassimp のバージョンは 3.1
2. collada_urdf_jsk_patch は（今まで1.11.13だったが）1.12.12に対するパッチとする．（現状はassimp-develを使うパッチしか入れていない）
3. collada_urdf_jsk_patch に @Naoki-Hiraoka の Naoki-Hiraoka/collada_urdf@c37592e を追加する．

というものを作りました．意味あるだろうか，上の、色違いの複数のメッシュが一つになったdaeの問題のテストは出来ていないんだけど，簡単なサンプルはあるだろうか．

これで，少なくともassimp-devel 3.1 を使うから，dae　でsegfault する問題は回避されている．
ただ，jsk-ros-pkg/jsk_3rdparty#207 (comment) の @YoheiKakiuchi のコメントをみると，

kineticになったら消していいとなっている記録があって、手元のSampleRobotはkineticで問題なさそうに見えます。

なので，assimp-develを3.1では意味ないのかな？

＝＝

https://github.com/Naoki-Hiraoka/collada_urdf/tree/fix-issue18

プルリクエストは送りましょう．それがきれいか汚いか判断するのは向こうだし，汚いコード＜＜＜＜＜＜変更点を報告，です．

[k-okada]

@Naoki-Hiraoka gazebosim/gazebo-classic#2811 で治っているかな？もし手元で直しました，というのがあれば教えてください．

[Naoki-Hiraoka]

@Naoki-Hiraoka osrf/gazebo#2811 で治っているかな？もし手元で直しました，というのがあれば教えてください．

Ubuntu18.04で、gazebo9に該当のcommitをmergeして試したところ、直っていることが確認できました。ありがとうございます。

gazebosim/gazebo-classic#2811 のbranchでそのまま試そうとしたのですが、gazebo11のソースのビルドはできたもののgazebo11がうまく立ち上がらず、断念しました。

手元で直しているものはありません。