Velodyne Simulator

URDF description and Gazebo plugins to simulate Velodyne laser scanners

rviz screenshot



  • *origin URDF transform from parent link.
  • parent URDF parent link name. Default base_link
  • name URDF model name. Also used as tf frame_id for PointCloud2 output. Default velodyne
  • topic PointCloud2 output topic name. Default /velodyne_points
  • hz Update rate in hz. Default 10
  • lasers Number of vertical spinning lasers. Default VLP-16: 16, HDL-32E: 32
  • samples Nuber of horizontal rotating samples. Default VLP-16: 1875, HDL-32E: 2187
  • min_range Minimum range value in meters. Default 0.9
  • max_range Maximum range value in meters. Default 130.0
  • noise Gausian noise value in meters. Default 0.008
  • min_angle Minimum horizontal angle in radians. Default -3.14
  • max_angle Maximum horizontal angle in radians. Default 3.14
  • gpu Use gpu_ray sensor instead of the standard ray sensor. Default false

Known Issues

  • At full sample resolution, Gazebo can take up to 30 seconds to load the VLP-16 pluggin, 60 seconds for the HDL-32E
  • With the default Gazebo version shipped with ROS, ranges are incorrect when accelerated with the GPU option (issue,image)
  • Gazebo cannot maintain 10Hz with large pointclouds
    • Solution: User can reduce number of points (samples) or frequency (hz) in the urdf parameters, see example.urdf.xacro
  • Gazebo crashes when updating HDL-32E sensors with default number of points. "Took over 1.0 seconds to update a sensor."
    • Solution: User can reduce number of points in urdf (same as above)
  • Gazebo versions in indigo and jade have different z orientations
    • Solution: Maintain separate branches for urdf changes (gazebo2 and master)

Example Gazebo Robot

roslaunch velodyne_description example.launch

Example Gazebo Robot (with GPU)

roslaunch velodyne_description example.launch gpu:=true