Packet containing angle overflow

[crankler]

I use ubuntu 16.04 and ros_kinetic
when I use this master package and I found there can ger scan directly,
but when I launch VLP16_points.launch, I get this warning:

Packet containing angle overflow, first angle: 35962 second angle: 0

also I add this topic in rviz, and there have warning as follow:

[ WARN] [1562916979.098222693]: VelodyneLaserScan: PointCloud2 fields in unexpected order. Using slower generic method.

So can someone give me advice ? Thank you!

[kaalessi]

I am also running into this warning, except on ubuntu 18.04 and ros_melodic

[JWhitleyWork]

@crankler / @kaalessi - Try enabling the cut_angle feature by setting it to 2*pi (6.28318530718). Let me know if this fixes the problem.

[kaalessi]

@JWhitleyAStuff Thank you for your response. I have changed the cut_angle in the launch file to 2pi and am still running into the warning "Packet containing angle overflow, first angle: 35979 second angle: 17." What was the reason you recommended 2pi? Is there something else I could change to eliminate this warning? Thanks

[JWhitleyWork]

@kaalessi - It looks like this happens when a packet contains some points at the end of a scan and some points from the beginning of another scan. #285 is attempting to fix this, but only for the VLP-16 and VLP-16 HiRes. However, I believe that the cut_angle feature does this as well, just not at a full rotation. I also believe that something is going on with how cut_angle is being used that is causing a problem. When you set the cut_angle option, where are you changing it? Also, are you launching your launch file with the --screen option? Please do this if you are not because the cut_angle feature will produce warning and error messages which are not seen without this flag.

[kaalessi]

@JWhitleyAStuff Thanks for the explanation. When setting the cut_angle option, I am setting it on line 20 of VLP16_points.launch:
<arg name="cut_angle" default="2*pi" />

When I first noticed this warning, I was running VLP16_points.launch from another launch file with output="screen". For testing of this problem, I have just been running the VLP16_points.launch file with the --screen flag and the output is the same. I get the warning when rosbag starts recording, or rviz is opened. If I try to run rosbag record, I also get the warning:
VelodyneLaserScan: PointCloud2 fields in unexpected order. Using slower generic method.

[JWhitleyWork]

@kaalessi - Sorry, I was not clear about the value for the cut_angle field. I meant to use the actual decimal value for 2*pi - 6.28 should be fine - instead of the text string "2*pi". Try this instead.

[kaalessi]

@JWhitleyAStuff Thanks for the quick reply! I changed the value from 2*pi to 6.28, and am still running into the same warning messages as earlier when running rviz or rosbag record. Do you have any other recommendations?

[JWhitleyWork]

@kaalessi - We are testing a couple of things here to see if we can figure out whether cut_angle will really fix the issue or if we need to implement something like #285.

[doldd]

I think the problem is in line 352 if(raw_azimuth_diff < 0)//raw->blocks[block+1].rotation - raw->blocks[block].rotation < 0) from file rawdata.cc. In my opinion the if statement should check azimuth_diff instead to cover the angle overflow.

[he-guo]

i also have this problem,when I add this topic in rviz, this warning is only available at this time,have you solved it?thinks.

[kaalessi]

@he-guo No, I have not yet been able to solve this problem. I'm getting the same thing as you when rviz is open. changing the cut_angle did not seem to eliminate this error.

[JWhitleyWork]

This error comes from the velodyne_laserscan package, which was created by @kmhallen. This may be due to changes that were made in #214 which remove PCL as a dependency but also change the order of the objects in the point cloud, which may cause a problem for this package. @kmhallen - Would you mind looking into this?

[kmhallen]

I can look into it. If the PointCloud2 structure changed, velodyne_laserscan will take the more generic code path. It should be a simple fix to add a case for the new structure.

[VorpalBlade]

@kmhallen:

I can look into it. If the PointCloud2 structure changed, velodyne_laserscan will take the more generic code path. It should be a simple fix to add a case for the new structure.

That does indeed seem to be the case, see bug #292.

[kmhallen]

See PR #316

[JWhitleyWork]

@crankler @doldd @kaalessi @VorpalBlade @he-guo - #316 has now been merged. Can you please test this from master?

[VorpalBlade]

@JWhitleyAStuff
I'm using a VLP-16 and I'm still getting the "Packet containing angle overflow" message. However, the "VelodyneLaserScan: PointCloud2 fields in unexpected order. Using slower generic method." message mentioned in bug #292 does seems fixed now. Did you by any chance mix up the bug IDs?

[JWhitleyWork]

@VorpalBlade - @crankler originally mentioned both issues. Thanks for testing #316 and reporting that it worked for you. I will leave this open for the remaining error.

[ryanmeasel]

We're running two VLP16s concurrently and we receive the "Packet containing angle overflow" warning on each unit every 60 seconds. It's periodic. And because we launch the nodes at the same time, the warnings happen together as well.

[ajwiley]

Has anyone found a solution to this yet? I'm only running one VLP16 on a Clearpath Husky, but I'm having the exact same thing as @ryanmeasel happen to me.
I run VLP16_points.launch, I open up RViz, and then I start seeing "Packet containing angle overflow, first angle: [big_number] second angle: [small_number]" repeating every 60 seconds.

[kaalessi]

@ajwiley I was working with a VLP16 yesterday and am still receiving an angle overflow warning when I have Rviz open or am recording with rosbag. Earlier this summer, I updated to the most recent package, and am still receiving the warning. Unfortunately, due to COVID-19, I have had limited on-site time working with the lidar unit.

[Timple]

Can anybody already verify that #285 would fix this?

[DarrenWong]

I have a similar issue with VLP 16 (HDL 32 is ok) as @ryanmeasel @ajwiley .with version 1.6.1. As the ROS_WARN is set to print every 60 s, such that we can consider the condition of warning is always true.
Any suggestion? Seems it might drop a few frames if the second condition not match again. I am using Melodic under Ubuntu 18.04 Bionic. I try a few version and set the cut angle to 2*pi

velodyne/velodyne_pointcloud/src/lib/rawdata.cc

Lines 672 to 683 in 4462666

	if(raw_azimuth_diff < 0)//raw->blocks[block+1].rotation - raw->blocks[block].rotation < 0)
	{
	ROS_WARN_STREAM_THROTTLE(60, "Packet containing angle overflow, first angle: " << raw->blocks[block].rotation << " second angle: " << raw->blocks[block+1].rotation);
	// if last_azimuth_diff was not zero, we can assume that the velodyne's speed did not change very much and use the same difference
	if(last_azimuth_diff > 0){
	azimuth_diff = last_azimuth_diff;
	}
	// otherwise we are not able to use this data
	// TODO: we might just not use the second 16 firings
	else{
	continue;
	}

[kennedyaidan]

I too am experiencing a 60s periodic "Packet containing angle overflow" warning when running my VLP16. As @DarrenWong points out, it's likely always true and only prints out at that frequency. Any suggestions on how to fix, and/or input on what kind of issues this may have would be appreciated.

[DarrenWong]

@kennedyaidan I just ignore it currently as it still can working on the SLAM method~... But my experiments show that it will skip a few frames (not consecutive ) compare to HDL-32 if collect together.

[happengor]

Can anybody already verify that #285 would fix this?

I have tested it, #285 doenst fix it, but it makes the motion distortion predictable and the motion distortion now looks reasonable, which in my opinion is a great modification.

[GianlucaCerilli]

I am also using a Velodyne (Puck Lite VLP-16) on a robot (it is connected to a Mini PC Intel NUC with Ubuntu 20.04 and ROS Noetic) and I get the same warning "Packet containing angle overflow".

The problem is that, when I get this warning the robot also does some weird movements and this can be dangerous.

Did anyone find a solution for this problem? Thanks in advance

[GianlucaCerilli]

Can anybody already verify that #285 would fix this?

I have tested it, #285 doenst fix it, but it makes the motion distortion predictable and the motion distortion now looks reasonable, which in my opinion is a great modification.

Hi @happengor ,
how did you test the code at #285? Because there are some files/functions that no longer exist in master or that are changed.

[happengor]

Can anybody already verify that #285 would fix this?

I have tested it, #285 doenst fix it, but it makes the motion distortion predictable and the motion distortion now looks reasonable, which in my opinion is a great modification.

Hi @happengor , how did you test the code at #285? Because there are some files/functions that no longer exist in master or that are changed.

hi, i have adjusted the new code base according to https://github.com/ros-drivers/velodyne/pull/285/files . But first u need understand the code structure. U could also git clone this https://github.com/MapIV/velodyne/tree/feature/precise_scan_separation and test it.

[GianlucaCerilli]

Can anybody already verify that #285 would fix this?

I have tested it, #285 doenst fix it, but it makes the motion distortion predictable and the motion distortion now looks reasonable, which in my opinion is a great modification.

Hi @happengor , how did you test the code at #285? Because there are some files/functions that no longer exist in master or that are changed.

hi, i have adjusted the new code base according to https://github.com/ros-drivers/velodyne/pull/285/files . But first u need understand the code structure. U could also git clone this https://github.com/MapIV/velodyne/tree/feature/precise_scan_separation and test it.

There is currently a build error on the "frame_id" when building https://github.com/MapIV/velodyne/tree/feature/precise_scan_separation.
Do you have the code that you have adjusted according to https://github.com/ros-drivers/velodyne/pull/285/files? For example, the conversion files do not exist anymore.

[happengor]

Can anybody already verify that #285 would fix this?

I have tested it, #285 doenst fix it, but it makes the motion distortion predictable and the motion distortion now looks reasonable, which in my opinion is a great modification.

Hi @happengor , how did you test the code at #285? Because there are some files/functions that no longer exist in master or that are changed.

hi, i have adjusted the new code base according to https://github.com/ros-drivers/velodyne/pull/285/files . But first u need understand the code structure. U could also git clone this https://github.com/MapIV/velodyne/tree/feature/precise_scan_separation and test it.

There is currently a build error on the "frame_id" when building https://github.com/MapIV/velodyne/tree/feature/precise_scan_separation. Do you have the code that you have adjusted according to https://github.com/ros-drivers/velodyne/pull/285/files? For example, the conversion files do not exist anymore.

For ur first try, u can hard code it : -->> change config.frame_id to "velodyne" . It's ur definition of frame_id for coordinate transformation .
I think the source code may be redirected to /opt/ros/noetic/include/velodyne_pointcloud/TransformNodeConfig.h during catkin_make .

[kennedyaidan]

I am also using a Velodyne (Puck Lite VLP-16) on a robot (it is connected to a Mini PC Intel NUC with Ubuntu 20.04 and ROS Noetic) and I get the same warning "Packet containing angle overflow".

The problem is that, when I get this warning the robot also does some weird movements and this can be dangerous.

Did anyone find a solution for this problem? Thanks in advance

I'm commenting just to put into question that the "Packet containing angle overflow" warning is causing any sort of weird movement or dangerous behavior. The overflow warning appears to be continuous, and only prints out every 60s or so. I can't see how the printout frequency of a warning could have any effect on the actual behavior of the robot. I'd suggesting looking elsewhere to find the root cause of that "weird" behavior. If you have more data suggesting it is actually causing "weird"' behavior please let me know!

[GianlucaCerilli]

There is currently a build error on the "frame_id" when building https://github.com/MapIV/velodyne/tree/feature/precise_scan_separation. Do you have the code that you have adjusted according to https://github.com/ros-drivers/velodyne/pull/285/files? For example, the conversion files do not exist anymore.

For ur first try, u can hard code it : -->> change config.frame_id to "velodyne" . It's ur definition of frame_id for coordinate transformation . I think the source code may be redirected to /opt/ros/noetic/include/velodyne_pointcloud/TransformNodeConfig.h during catkin_make .

Thank you very much @happengor ,
I have tested the precise_scan_separation code but unfortunately I still have the warning. I also could not see any relevant change...

ros_drivers/Velodyne

precise_scan_separation

Anyway, I tested the ros_drivers/Velodyne on both Kinetic (Ubuntu 16) and Noetic (Ubuntu 20) and I have this warning only on Noetic. Maybe they wrote something to fix this warning for Kinetic in the two years from the opening of this issue.

And the warning happens only when I open the pointcloud in Rviz or when I do "rostopic echo /velodyne_points". Otherwise, it does not happen.

@kennedyaidan
I agree, this is weird and we are investigating more. Maybe there could be some communication problem...I don't know.
I'll write an update If I find something interesting.

[ahmetsaglam]

any updates on how to fix this warning?

[tersite1]

I had an same issue, Ubunto 20.04 , ROS noetic
but I just solved by simply reinstall ROS,
try
sudo apt install ros-noetic-desktop-full

than delete catkin_ws

rm -rf catkin_ws

mkdir catkin_ws
cd catkin_ws
mkdir src

than build catkin again

sudo apt-get install ros-noetic-velodyne
cd catkin_ws/src
git clone https://github.com/ros-drivers/velodyne
cd ..
catkin_make
cd src

roslaunch velodyne_pointcloud VLP16_points.launch
rosrun rviz rviz -f velodyne

hope this can be helpful thx