cut_angle default behavior is not as expected
cjffly opened this issue · comments
Please complete the following information:
- OS and Version: Ubuntu 22.04
- ROS Version: Humble
- Downloaded from Official Repository:
- Version: f149faf
I had a working pipeline that using the velodyne_pointclouds to present data on rviz in ros1 (kinetic) environment, And the pointcloud shown in rviz normal. Recently I migrate from ros1 to ros2 (Humble), using the same pipeline, the pointcloud shown in rviz2 is broken. (Video shown below)
To Reproduce
ros2 launch velodyne velodyne-all-nodes-VLP32C-launch.py
rviz2
change the Fixed Frame to velodyne
One thing I notice is that, with kinetic, in the /velodyne_points topic returned data's header section, the height and width is different than that returned by humble /velodyne_points:
In kinetic:
...
height: 1
width: 21360
...
while in humble:
...
height: 12
width: 32
...
I wonder what is the decision factor of this height and width?
To further help describe my issue, I recorded a short clip of what the Rviz2 shown the pointcloud.
On the left is using VeloView showing the data from VLP-32C, and it forwarded the Lidar data to a different port so the ROS2 velodyne driver can read it. On the right side is launch the node using
ros2 launch velodyne velodyne-all-nodes-VLP32C-launch.py
and rviz2
showing the data.
Is this a velodyne driver issue, or it is rviz configuration issue?
2022-12-07.14-59-21.mp4
Try changing from Reliable to Best Effort. That being said, I have not seen this issue before. Is your Velodyne set for First Return, Strongest Return, or Dual Return?
The Lidar data is not from an physical VLP-32C, but rather simulation lidar data and modified to replica the velodyne data format.
I Changed to Best Effort but nothing rviz still show broken points. The Velodyne is set to Strongest Return since that Factory byte is set to 0x37.
If the VeloView can render the pointcloud, I believe my simulation data is the same as a real data from VLP-32C, right?
I changed some rviz2 settings, the Frame rate from 30 to 1000, and the Decay Time from 0 to 0.8, it now can show at least something on the screen. Still not as good as the VeloView result though...
2022-12-07.19-10-29.mp4
[Update]
This seem to be related to parameter cut_angle issue. By default it is set to 2*Pi. I have to set it to a negative number to make it work, according to the instruction here
Although, I am not entirely sure how the cut_angle works, if someone could explain it, that would be very helpful.
Honestly, the default value for cut_angle
should probably be a negative value to revert to the default behavior from before this feature was introduced. However, I don't believe this should cause issues with your particular setup because the feature should just "cut" the scan per ring at the given angle if it's less than the desired value. There are other things which can affect how this function works, though. I'll introduce a PR to revert that default.
@cjffly The cut_angle
feature is now disabled by default in the ros2
branch. Please confirm that this resolves your issue.
Closing as #497 should fix.