SICKAG / sick_safetyscanners

ROS driver for SICK safety laser scanners
https://www.sick.com/de/en/opto-electronic-protective-devices/safety-laser-scanners/c/g187225
Apache License 2.0
61 stars 59 forks source link

Difference between angle_start/end and angle_min/max #94

Closed GuyWithCookies closed 2 years ago

GuyWithCookies commented 2 years ago

Hi,

We are seeing a discrepancy between the angle_start/angle_end parameters that we define in our launch files and the angle_min/angle_max values that are published to the /sick_safetyscanners/scan.

We configured the angle_min and angle_max parameters as follows in the launch file:

<arg name="angle_start" value="-1.54462" />
<arg name="angle_end" value="1.46608" />

However, in the topic we got the values that (slightly) differ:

 ---
header: 
  seq: 31290
  stamp: 
    secs: 1642777942
    nsecs: 553113978
  frame_id: "laser_scanner_base_front_link"
angle_min: -1.6118247509002686
angle_max: 1.5312420129776
angle_increment: 0.008954579941928387
time_increment: 4.3000000005122274e-05
scan_time: 0.029999999329447746
range_min: 0.10000000149011612
range_max: 40.0

We use three different safety scanners (microScan3) - for all we have this discrepancy. We use the latest master (commit d4afb838) of this package.

Is this discrepancy expected? If so - what is the differences in the definition of angle_[min|max] and angle_[min|max]?

lenpuc commented 2 years ago

Hi,

thanks for reaching out. I will have a look into it. However, it sounds like this issue might not be driver related and directly in the sensor.

I will have a look if I can find anything.

kalectro commented 2 years ago

Hi,

I found this in the datasheet (https://cdn.sick.com/media/docs/1/01/701/technical_information_microscan3_outdoorscan3_nanoscan3_data_output_via_udp_and_tcp_ip_en_im0083701.pdf)

image-20220123-110850

This could explain deviations of up to 2 degrees for min and max angle but we are seeing almost 4 degrees. It might also explain this https://github.com/SICKAG/sick_safetyscanners/blob/master/src/SickSafetyscannersRos.cpp#L401 I also assume that all of this is happening in the sensor but the driver could crop the range to what is expected. Not sure if this is the prettiest solution though.

kalectro commented 2 years ago

@puck-fzi did you have a chance to look into it yet? What do you think is the best approach to solving this?

lenpuc commented 2 years ago

Hi,

having looked through the whole communications pipeline from launch to sending it to the sensor and and from receiving to ROS topics i couldn't determine any error. The writing into the COLA2 command is done here: https://github.com/SICKAG/sick_safetyscanners/blob/master/src/cola2/ChangeCommSettingsCommand.cpp#L126

And on the other hand the parsing of the derived values is done here: https://github.com/SICKAG/sick_safetyscanners/blob/master/src/data_processing/ParseDerivedValues.cpp#L120

From both sides it looks in my opinion that the driver should parse the correct values.

Maybe you could verify in the SICK safetyscanners software if you get similar discrepancies when configuring the angles. If yes, it might be an issue you need to discuss with SICK directly.

lenpuc commented 2 years ago

For now this is seen as expected behavior of the sensor itself, since the angles are rounded to the nearest 8th beam, as described earlier.

Potential development could be included in the ROS driver to support the precise angles. However, for now it is seen as expected sensor behavior.

Therefore closing the issue