Gazebo segfaults when Lidar senses an obstacle

edit

There is something wrong with your macro which prevent you from setting the parameters as desired. At the beginning you define parameters (*origin -> is that a typo ?) and then you don't actually use them.

For example this : <update_rate>1</update_rate>, should be <update_rate>${update_rate}</update_rate>.

So when you call your xacro here :

  <xacro:hokuyo_utm30lx robot_namespace="${namespace}" min_angle="-1.047" max_angle="1.047"
    update_rate="40" ray_count="10">

None of your parameters are actually set to those values (and why is it ${namespace} here ? It should be an actual value).

So you end up with a really odd configuration, I would suggest few things :

• You tried to set the update rate to 40 which is better than 1 because this is an extremely low value for the update rate so just make sure you actually change the parmeter (as the example above).
• You have samples set to 3 with a resolution of 10. The resolution is multiplied by the number of samples to define the number of range data points returned. Moreover, if the resolution is greater than 1 the range data is average so I would suggest to set the resolution to 1 and directly define the samples as the number of data you want. For example if you have a 360° lidar and you want a data every 1° I would just set the samples to 360 and resolution to 1.

Edit :

I found from here that we could insert a block by * prefix

You're right it's possible to do that but when you choose to do this you need to insert the block like this :

<xacro:insert_block name="origin" />

Also there might be another thing wrong here when you call the xacro :

<xacro:hokuyo_utm30lx robot_namespace="${namespace}" min_angle="-1.047" max_angle="1.047"
    update_rate="40" ray_count="10">
    <origin xyz="0 0 0.5" rpy="0 0 0"/>
  </xacro:hokuyo_utm30lx>

I'm not sure what will happen and where the origin tag will end up but following the wiki I would call the xacro like this and define the origin inside the macro :

<xacro:hokuyo_utm30lx robot_namespace="${namespace}" min_angle="-1.047" max_angle="1.047"
update_rate="40" ray_count="10" />

Same issue here. In my case, gzserver crashes with the following stack trace:

> #0  gazebo::sensors::Noise::Apply (this=0x0,
> _in=_in@entry=1.527150313825224) at /build/gazebo-nhSAPd/gazebo-7.0.0+dfsg/gazebo/sensors/Noise.cc:108                                                                                                                            
> #1  0x00007f1376924cf7 in gazebo::sensors::RaySensor::UpdateImpl
> (this=0x7f12e20f3e70) at
> /build/gazebo-nhSAPd/gazebo-7.0.0+dfsg/gazebo/sensors/RaySensor.cc:574
> 
> #2  0x00007f137692c984 in gazebo::sensors::Sensor::Update
> (this=0x7f12e20f3e70,
> _force=_force@entry=false) at /build/gazebo-nhSAPd/gazebo-7.0.0+dfsg/gazebo/sensors/Sensor.cc:250
> 
> #3  0x00007f1376933195 in gazebo::sensors::SensorManager::SensorContainer::Update
> (this=0x2e3d240, _force=<optimized
> out>) at
> /build/gazebo-nhSAPd/gazebo-7.0.0+dfsg/gazebo/sensors/SensorManager.cc:579
> 
> #4  0x00007f1376936d4b in gazebo::sensors::SensorManager::SensorContainer::RunLoop
> (this=0x2e3d240) at
> /build/gazebo-nhSAPd/gazebo-7.0.0+dfsg/gazebo/sensors/SensorManager.cc:534
> 
> #5  0x00007f13741805d5 in ?? () from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0
> 
> #6  0x00007f13766956ba in start_thread (arg=0x7f12fe8ba700) at
> pthread_create.c:333                  
> 
> #7  0x00007f1376c9741d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

After some digging into various sources, it turns out the type specification of <noise> block was causing the problem: in Gazebo's official documentation, its type property is spelled gaussian, not capitalized Gaussian as found in some tutorials. After making this change, I was able to run the simulated 2d sensor without a problem. Hope this will help you out.