Gazebo crashes without throwing any error if we add the accelerometers to the URDF

[nunoguedelha]

This issue occurred while testing updates not yet released to the model generator toolchain (#49, #52).

Conditions for reproducing the issue

The initial URDF model that could be loaded successfully in Gazebo was in the commit nunoguedelha/icub-models@6b74550 (branch feature/updateModels). This commit includes :

• the initial URDF generated from the CAD model iCub 2.5 (except the inertial sensors tags)
• updated link inertias for avoiding numerical instabilities
• updated ankle and hip joints limits
• blobs under gazebo tag for tuning the sole bounce on the ground

We then merged the changes from robotology/icub-models#2:

• initial URDF generated from the CAD model iCub 2.5, including the inertial sensors tags

Symptoms

The resulting URDF (nunoguedelha/icub-models@3aab750) is making Gazebo crash.

We are using Gazebo version 8. No error is apparently thrown by the simulator, but a crash report is saved when testing on Mac OSX environment.

[nunoguedelha]

Crash report:

Process:               gzclient-8.0.0 [4926]
Path:                  /usr/local/bin/gzclient
Identifier:            gzclient-8.0.0
Version:               0
Code Type:             X86-64 (Native)
Parent Process:        gazebo-8.0.0 [4924]
Responsible:           Terminal [248]
User ID:               501

Date/Time:             2017-07-15 19:43:45.080 +0200
OS Version:            Mac OS X 10.10.5 (14F2411)
Report Version:        11
Anonymous UUID:        ...

Sleep/Wake UUID:       ...

Time Awake Since Boot: 57000 seconds
Time Since Wake:       14000 seconds

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000058

VM Regions Near 0x58:
--> 
    __TEXT                 00000001007d9000-0000000100e02000 [ 6308K] r-x/rwx SM=COW  /usr/local/Cellar/gazebo8/8.0.0_6/bin/gzclient-8.0.0

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsdformat.5.dylib           	0x00000001027e2b6e InsertSDFExtensionCollision(TiXmlElement*, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 3115
1   libsdformat.5.dylib           	0x00000001027edeed CreateCollision(TiXmlElement*, boost::shared_ptr<urdf::Link const>, boost::shared_ptr<urdf::Collision>, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 849
2   libsdformat.5.dylib           	0x00000001027ec2c4 CreateCollisions(TiXmlElement*, boost::shared_ptr<urdf::Link const>) + 1160
3   libsdformat.5.dylib           	0x00000001027eb850 CreateLink(TiXmlElement*, boost::shared_ptr<urdf::Link const>, ignition::math::Pose3<double>&) + 621
4   libsdformat.5.dylib           	0x00000001027eb436 CreateSDF(TiXmlElement*, boost::shared_ptr<urdf::Link const>, ignition::math::Pose3<double> const&) + 1456
5   libsdformat.5.dylib           	0x00000001027eb4a8 CreateSDF(TiXmlElement*, boost::shared_ptr<urdf::Link const>, ignition::math::Pose3<double> const&) + 1570
6   libsdformat.5.dylib           	0x00000001027eb4a8 CreateSDF(TiXmlElement*, boost::shared_ptr<urdf::Link const>, ignition::math::Pose3<double> const&) + 1570
7   libsdformat.5.dylib           	0x00000001027eb4a8 CreateSDF(TiXmlElement*, boost::shared_ptr<urdf::Link const>, i

As we can see, Gazebo is crashing when converting the loaded urdf to the sdf format, and apparently when processing a "collision" tag.

The issue occurs even without adding the plugins responsible for collecting the inertial sensors data (libgazebo_yarp_distributedinertials.so). Actually, we just add the sensor information under the tags <gazebo> and <sensor>.

When adding the sensors one by one we can reproduce the issue as soon as we add an accelerometer on the left or right foot. If the same sensor is attached to any other link, the problem doesn't occur.

Note: Actually the issue can be easily observed by using the urdf->sdf converting tool from Gazebo directly on a terminal:

gz sdf -p model.urdf > icub.sdf

This command will fail with a segmentation fault 11 in the same conditions as the main application Gazebo.

[nunoguedelha]

So, to sum up, adding a single accelerometer wrapped as follows causes the crash:

  <gazebo reference="l_foot">
    <sensor name="l_foot_mtb_acc_10b12" type="imu">
      <always_on>1</always_on>
      <update_rate>100</update_rate>
      <pose>0.1055224 0.0008072 -0.001215 0.0 -0.0 1.57079632679</pose>
      <plugin name="iCub_yarp_gazebo_plugin_ACC" filename="libgazebo_yarp_inertial.so"/>
    </sensor>
  </gazebo>

The issue disappears again if remove the blob setting the bounce parameters on the same foot:

<gazebo reference="l_foot">
  <collision> <surface> <bounce>
    <restitution_coefficient>0</restitution_coefficient>
    <threshold>100000</threshold>
  </bounce> </surface> </collision>
  <maxContacts>4</maxContacts>
  <kp>18000000</kp>
  <kd>100</kd>
  <maxVel>100</maxVel>
  <minDepth>0.0001</minDepth>
  <mu1>1</mu1>
  <mu2>1</mu2>
  <fdir1>0 0 0</fdir1>
</gazebo>

So the issue is caused by a conflict between the <sensor> and the <bounce> tags.

[nunoguedelha]

We would like to use the debug information from gz using the --verbose option, but it doesn't seem to be working. No additional information can be collected on the error without debugging the Gazebo source code.
Anyway, the issue is resolved by simply moving the bouncing and friction parameters of the foot sole before the inertial sensors parameters.

[nunoguedelha]

This looks like a bug in Gazebo. Fixed by moving the bouncing and friction parameters of the foot sole before the inertial sensors parameters: nunoguedelha/icub-models@868a19f
I will add here later a reference to the official fix.

[nunoguedelha]

I Had to rename the model back to iCub for aligning it to the one used in the .ini config files, otherwise Gazebo crashes.

[nunoguedelha]

@diegoferigo @traversaro

[diegoferigo]

Good catch and great work @nunoguedelha! Let's wait @traversaro for the merge.

[traversaro]

Great job @nunoguedelha . Do you have a minimal example for reproducing this issue? If it is easy to reproduce with gz sdf -p model.urdf > modle.sdf, it is worth to post an issue to https://bitbucket.org/osrf/sdformat/issues?status=new&status=open (the urdf --> sdf conversion code is contained in the sdformat library, in particular in https://bitbucket.org/osrf/sdformat/src/bac3dfb42cc72cb609c0bcdbef2064326f5061dd/src/parser_urdf.cc?at=default&fileviewer=file-view-default .

[nunoguedelha]

@traversaro @diegoferigo I opened the issue on bitbucket sdformat repo:
https://bitbucket.org/osrf/sdformat/issues/164/gz-sdf-segmentation-fault-11-due-to

Didn't have time to replace the meshes my simple shapes but it shouldn't be problem for them.

[nunoguedelha]

Fixed by PR robotology/simmechanics-to-urdf#25 instead of waiting for sdformat issue resolution. The fix results in generating a URDF model file where the bouncing and friction parameters of the foot sole are defined before the inertial sensors parameters.