search

SICKAG / sick_safetyscanners2

ROS2 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
28 stars 30 forks source link

Setting angle_start is not working as expected #2

Closed SomaGallai closed 3 years ago

SomaGallai commented 3 years ago

I am trying to set a smaller angle for the NanoScan3, changing the values of angle_start and angle_end to 2.0 would be perfect. Changing the values of the variables in the launch file makes angle_end work as expected and changes to 2.0, but angle start set to anything lower than -1.585341453552246 is not changing to the value, it is stuck at this value.

Output of ros2 topic echo /scan :

header:
  stamp:
    sec: 1610446957
    nanosec: 159630037
  frame_id: scan
angle_min: -1.585341453552246
angle_max: 2.0187900066375732
angle_increment: 0.0029088794253766537
time_increment: 1.4000000192027073e-05
scan_time: 0.029999999329447746
range_min: 0.10000000149011612
range_max: 40.0
lenpuc commented 3 years ago

This should not be the case, so your launch file includes the following values?

"angle_start": -2.0,                                                             
"angle_end": 2.0,

For me with a MicroScan3 I then get the following results: image

Since both the nanoScan3 and the MicroScan3 have the same field of view this should work similar. However, if you set values which are outside the range of view, the values will be send to the sensor it will be accepted but nothing will change. Currently there is no check implemented if the angles are inside the allowed range which should be [-2,39, 2.39] in radians.

SomaGallai commented 3 years ago

I am not sure what is causing the issue on my side, I have made sure the launch file includes the values like yours. I have even tried implementing the values in the .cpp and instead of launch using ros2 run. It shows the same issue. The part that really confuses me is when launching/running the program it shows the following:

[INFO] [1610453255.421283806] [SickSafetyscannersRos2]: angle_start: -2.000000
[INFO] [1610453255.421327870] [SickSafetyscannersRos2]: angle_end: 2.000000

As it should be, but running rviz2 or ros2 topic echo /scan proves that the angle_start is not correct for me.

lenpuc commented 3 years ago

Disregard the output in your case. This is what will be sent to the sensor. So basically it means your input is correctly parsed. However, it appears that the sensor does not acknowledge the values. What is the value for the angle min if you set both angles to 0? This should then use to complete field of view

SomaGallai commented 3 years ago

When angle_start and angle_end is set to 0.0 then ros2 topic echo /scan shows: 

angle_min: -2.399827718734741
angle_max: 2.3998663425445557

The maximum value as you said before, but I would need to set it lower, as there is a case around my NanoScan3 and I would like to set up the scan to not recognize that part.

lenpuc commented 3 years ago

Okay. This appears to be exactly right. I don't really know what goes wrong on your end. If that is something in the ROS driver or something in the firmware of the nanoscan3.

Things you can try to resolve it. You can use rqt_recovnfigure to see if you get different results and if other angles work without restarting the driver everytime. ros2 run rqt_reconfigure rqt_reconfigure

Or as a workaround set the desired angles in the safety designer and then set the flag use_persistent_config to true. Then the angles from the sensor should be used. However, beware, that the ROS driver set 0 right at the front of the sensor, whereas the scanner itself has the 0 position shifted by 90°

lenpuc commented 3 years ago

Did you manage to resolve or workaround this issue?

SomaGallai commented 3 years ago

Hey, We were looking in to fixing the angle issue but we have ran in to an other issue regarding the package. We started to see a strange behavior of not being able to publish the /scan topic. We have tried different things to see what is causing the issue, basically none of them were consistent.

  1. We have tried restarting the PC and it did not work.
  2. Rebooting the SICK Nanoscan3 Scanner sometimes made the /scan topic publish.
  3. Changing the network connection has no effect on the results.
  4. The issue usually arises when we step in front of the scanner and trigger a critical safety stop, but after multiple testing it was not consistent.

We tried to find the root cause of not being able to publish the /scan topic , but it's to random as we can see. It seems to be the main issue is when the critical safety zone is triggered.

lenpuc commented 3 years ago

Since this is a different issue, could you please open another issue here on github. So we don't mix different problems in one thread. Thanks

lenpuc commented 3 years ago

For the issue with the angles, I talked to my contact at SICK. Since it only appears with the nanoScan3 and not with the microScan3 it might be something on their side. They will have a look into it. Simultaneously I will have a look if i can find an error on the ROS2 driver side.

IF you have any new knowledge please let me know. It might be beneficial to know your system, could be please provide the following:

SomaGallai commented 3 years ago

We do not have any extra detail at the moment.

lenpuc commented 3 years ago

Hi, I made some modifications to the underlying base library. Could you please check out the fb_fix_start_angle branch in the sick_safetyscanners_base library and test again. https://github.com/SICKAG/sick_safetyscanners_base/tree/fb_fix_start_angle

If this does not help, could you provide a dump udp of the incoming messages, as well as the tcp messages sent to the driver using wireshark or similar.

SomaGallai commented 3 years ago

This seems to have fixed the issue, we are able to change the angle_min properly and the readings are as expected. Thank you very much!

lenpuc commented 3 years ago

Great, then I'll merge it into the base driver

lenpuc commented 3 years ago

Merged into both ros2 and cpp_standalone branch of base driver