I am not sure if the title correctly summarizes the issue I experience with the VLP-16 simulator, nor am I sure of this issue really pertains to the VLP-16 per se.
I have a simulation of a differential drive robotic vehicle in Gazebo using the standard Gazebo ROS diff drive plugin. The diff drive plugin is producing a tf transform relating the base_footprint with the odom frame, using the "world" setting (i.e. it's not using a simulated wheel encoder, but instead it's using the truth information directly).
My simulated robot description has a VLP-16 attached on top of it (in an upright position) which is linked to the VLP-16 gazebo simulator plugin .
When I visualize the point cloud in RVIZ, (and I set the reference frame to odom), and I move the robot about (translate and rotate), I can see a lot of motion on the point clouds, while I would be expecting no motion on the points at all since I am using truth odometry-to-base_footprint transform : it's almost as if the data is lagging or as if it takes a very long time to resolve the point cloud in the odom frame.
Even when I significantly thin out the data (5Hz, 8 lasers, 100 samples), it doesn't appear to make a difference.
When I replace the VLP-16 with a Hokuyo 2D laser scanner, and leave everything the way it is, I don't have any lag or such issues. If I set the visualization decay of the points to say 1000 seconds, then I don't see any registration error at all - like a perfect SLAM (which is to be expected when using truth odometry data).
I have eliminated everything else and this behavior is only when I use the VLP-16 simulator.
A follow up question, maybe related: when looking at the tf-tree, I notice that the velodyne_base_link transform and the velodyne transform (is updated at 1000Hz. I have my joint publisher run at 50Hz, so I am not clear where this high rate comes from - and I am wondering if perhaps this is the culprit of my problem above?
Thanks in advance and looking forward to your response.