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

[Naoki-Hiraoka]

Please see https://github.com/ros/collada_urdf/issues/34 ~https://bitbucket.org/osrf/gazebo/issues/2682~ https://github.com/osrf/gazebo/issues/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 https://github.com/assimp/assimp/commit/36e53b75fa24b9286a57c1e1eaaf25a9427da26b#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かどこかに書いておいた方がいいかもしれません。

https://github.com/start-jsk/rtmros_tutorials/pull/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などを上手く書き出すことができずに、添付の写真のようになります。

https://github.com/ros/collada_urdf/issues/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限定ですが，，，https://github.com/jsk-ros-pkg/jsk_3rdparty/pull/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 の https://github.com/Naoki-Hiraoka/collada_urdf/commit/c37592e86af2d949479e3db9e271e34ff8eff189 を追加する．

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

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

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

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

＝＝

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

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

[k-okada]

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

[Naoki-Hiraoka]

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

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

https://github.com/osrf/gazebo/pull/2811 のbranchでそのまま試そうとしたのですが、gazebo11のソースのビルドはできたもののgazebo11がうまく立ち上がらず、断念しました。

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