I realized that my original formulation above was a bit misleading. I edited the description. This pull request does not really fix an issue with 1 vertical ray, the new GPU laser plugin just avoids this issue, which I think exists in the normal version (division by zero in line 295/296).
Hi Jacob! I’m testing your plugin and it’s crashing when I use the gpu version. Output:
[gazebo-2] process has died [pid 2146, exit code 255, cmd /home/alex/catkin_ws/src/gazebo_ros_pkgs/gazebo_ros/scripts/gzserver -e ode /home/alex/catkin_ws/src/velodyne_simulator/velodyne_description/world/example.world __name:=gazebo __log:=/home/alex/.ros/log/9d15fa4e-732e-11e8-9296-bcee7b8d9c26/gazebo-2.log].
log file: /home/alex/.ros/log/9d15fa4e-732e-11e8-9296-bcee7b8d9c26/gazebo-2*.log
I haven’t found what caused the crash in any of the output or log files, but researching gazebo exit code 255 suggests that it is a graphics card/driver error. I’ve used your Gazebo branch, removed the ROS default Gazebo packages, and installed ROS gazebo packages from source. I’m using an NVIDIA Quadro M2000 and I’ve tried both the proprietary 384 driver and the open source 390 driver. Everything works fine with the normal CPU velodyne plugin. Are you familiar with this issue? See also https://answers.ros.org/question/259745/gazebo-crashes-when-trying-to-roslaunch-empty_world/
Hm, no sorry I haven’t come across this error. I didn’t have any problems with graphics card drivers and Gazebo so far.
Did you use the default urdf settings, i.e. the normal number of vertical/horizontal samples? In theory there is a graphics card specific limit of the sample size (GPU texture size) but I think most modern GPUs should easily be able to handle at least the sample settings of the velodyne…
@roboterbastler Is there any updates on this? Would you mind sharing your urdf.xacro file for the ROS URDF interface? Thank you so much for putting the effort into this. The CPU velodyne plugin could definitely use a performance upgrade.
@jacob_seibert_ I have copied the code from your latest commit, but get a velodyne pointcloud clover pattern (see attached picture). I am running the attached .urdf.xacro gazebo reference. Is the fault coming from the parameter choices or is there an error in the code? Thanks!
@BjoernLue From your pictures I would suspect you didn’t use the fixed Gazebo version, did you? My pull request that fixed the Gazebo GpuLaserSensor was merged recently so I expect it to be released with the next Gazebo 7 version. Until then you’d still have to compile Gazebo from source to successfully use the GPU laser sensor.
The URDF looks fine, I use the same settings.
@roboterbastler Yes that was it. Thank you a lot! It’s running perfectly and way faster than the CPU version (see attached screenshot). @kmhallen Please merge ASAP into the apt version of velodyne_simulator to avoid the source install. I cannot report any problems so far.
We haven’t been able to test the GPU functionality at Dataspeed, but I can merge if you guys say it works.
I’ll also probably merge CPU/GPU into a single file with ifdefs since they are 98% similar,