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

driver cannot receive data #7

Closed kikass13 closed 3 years ago

kikass13 commented 3 years ago

Hello,

i am using two sick lidars (https://cdn.sick.com/media/docs/3/63/763/product_information_outdoorscan3_safety_laser_scanner_en_im0082763.pdf) and the driver crashes with a timeout exception.

I have configured both the sensors (daisy chain) like this:

and the driver wont work accordingly.

I have configured the driver as follows:

from launch import LaunchDescription
from launch_ros.actions import Node

def generate_launch_description():
    return LaunchDescription([
        Node(
            package="sick_safetyscanners2",
            executable="sick_safetyscanners2_node",
            name="sick_safetyscanners2_node",
            output="screen",
            emulate_tty=True,
            parameters=[
                {"frame_id": "scan",
                 "sensor_ip": "192.168.1.2",
                 "host_ip": "192.168.1.1",
                 "interface_ip": "0.0.0.0",
                 "host_udp_port": 6060,
                 "channel": 0,
                 "channel_enabled": True,
                 "skip": 0,
                 "angle_start": 0.0,
                 "angle_end": 0.0,
                 "time_offset": 0.0,
                 "general_system_state": True,
                 "derived_settings": True,
                 "measurement_data": True,
                 "intrusion_data": True,
                 "application_io_data": True,
                 "use_persistent_config": False,
                 "min_intensities": 0.0}
            ]
        )
    ])

and the sensor is sending data on the port i have configured (6060):

#### tshark output of my interface 
 8512 111.221993979  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
 8513 111.252759040  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8514 111.257695481  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8515 111.261943101  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
 8516 111.292731667  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8517 111.297582912  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8518 111.301935686  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
 8519 111.327767422  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8520 111.332730364  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8521 111.336729091  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
 8522 111.367591956  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8523 111.372736211  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8524 111.376712986  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
 8525 111.407558566  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8526 111.412583211  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8527 111.416701650  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
 8528 111.447470300  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8529 111.452560127  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8530 111.456700088  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
 8531 111.487672505  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8532 111.492730868  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8533 111.496738827  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
 8534 111.527689717  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8535 111.532697449  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8536 111.536724959  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
 8537 111.567682010  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8538 111.572718499  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8539 111.576728251  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
 8540 111.607805456  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8541 111.612792144  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8542 111.616720046  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
 8543 111.642705781  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8544 111.647642889  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8545 111.652005421  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
^C 8546 111.682657964  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8547 111.687735569  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8548 111.692053008  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
 8549 111.722469336  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8550 111.727457870  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8551 111.731811968  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
 8552 111.762721228  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8553 111.767495515  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8554 111.771830485  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
 8555 111.802613488  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8556 111.807616933  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8557 111.811845475  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
 8558 111.837647532  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8559 111.842813365  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8560 111.846920517  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
 8561 111.877610025  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8562 111.882619642  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
 8563 111.886887104  192.168.1.2 → 192.168.1.1  UDP 554 6060 → 6060 Len=512

what can I do to troubleshoot this problem?

puck-fzi commented 3 years ago

Hi, it looks like your initial setup seems to be working. You can ping the sensor as well? If there is a timeout exception the TCP connection can not be established. Can you see if the driver is communicating with the sensor via a TCP connection.

And could you post the complete error, including error code which should appear.

Are any firewalls or other things present which might block TCP connections and let UDP connections through?

kikass13 commented 3 years ago

Hi, thanks for the reply

I did 

ufw allow 6060 && ufw allow 6061 && ufw enable

so the ports should be free and there is no other firewall or host in between.

This ICMP package pops up periodically when i start the driver

 3197 41.209861060  192.168.1.1 → 192.168.1.2  ICMP 590 Destination unreachable (Port unreachable)
 3198 41.214809352  192.168.1.2 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460
puck-fzi commented 3 years ago

3197 41.209861060 192.168.1.1 → 192.168.1.2 ICMP 590 Destination unreachable (Port unreachable)

This means the network participant is not reachable for your driver. There should be a few TCP messages popping up at startup since there will be some configs exchanged. without that you will not be able to use the driver.

On the sensor port 2021 will always be used for TCP connections. So I am guessing you can not connect to that port. So yes it sounds like there is an issue with your network or firewall configuration.

If you have more questions please ask, otherwise I would be happy if you could post what the issue was in the end.

kikass13 commented 3 years ago

Hello,

after playing around I can see some messages from the driver (shortly after i start it)

 9389 60.122845684 192.168.1.20 → 192.168.1.1  UDP 554 6060 → 6060 Len=512
 9390 60.124726570 JetwayIn_0d:6d:b3 → Sick_24:16:fd ARP 42 Who has 192.168.1.21? Tell 192.168.1.1
 9391 60.124764050 JetwayIn_0d:6d:b3 → Sick_24:16:f7 ARP 42 Who has 192.168.1.20? Tell 192.168.1.1
 9392 60.125091279 Sick_24:16:f7 → JetwayIn_0d:6d:b3 ARP 60 192.168.1.20 is at 00:06:77:24:16:f7
 9393 60.125344684 Sick_24:16:fd → JetwayIn_0d:6d:b3 ARP 60 192.168.1.21 is at 00:06:77:24:16:fd
 9394 60.137868248 192.168.1.21 → 192.168.1.1  UDP 1502 6061 → 6061 Len=1460
 9395 60.143141848 192.168.1.21 → 192.168.1.1  UDP 1502 6061 → 6061 Len=1460
 9396 60.147229551 192.168.1.21 → 192.168.1.1  UDP 554 6061 → 6061 Len=512
 9397 60.153830802 192.168.1.20 → 192.168.1.1  UDP 1502 6060 → 6060 Len=1460

and the devices already repond to my ping icmp requests. there is nothing in between the host and the devices. I also allowed port 2021 but that should be irrelevant, because it is an outgoing tcp connection (there cannot be a firewall in between). The two sensors a plugged directly into the ethernet port of my host ...

The sensors are configured to "just stream" udp data as soon as they are turned on (which they do), there is no need for the the driver to establish a tcp connection in the first place (only for setting fields and stuff at runtime). Disregarding the fact that tcp should work because there is nothing blocking anything, is there a way to use the decoding part of the driver to just use the udp socket (which already exists) manually?

kikass13 commented 3 years ago

to add to my confusion:

$ nmap -p 2021 192.168.1.20
Nmap scan report for 192.168.1.21
Host is up (0.00069s latency).

PORT     STATE    SERVICE
2021/tcp filtered servexec

Nmap done: 1 IP address (1 host up) scanned in 0.25 seconds
$ nmap -p 2021 192.168.1.21
Starting Nmap 7.80 ( https://nmap.org ) at 2021-05-07 18:12 UTC
Nmap scan report for 192.168.1.21
Host is up (0.0013s latency).

PORT     STATE  SERVICE
2021/tcp closed servexec

Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds

... a telnet connection on that port does nothing as well

$ telnet 192.168.1.20 2021
Trying 192.168.1.20...
telnet: Unable to connect to remote host: Connection refused
kikass13 commented 3 years ago

And the sensors are happy and stream their data:

PXL_20210507_181906958

puck-fzi commented 3 years ago

Okay, if the sensor does not receive anything. are there maybe any configurations you can change in the safety designer? On the sensor side I am not that familiar with all the possible options. But if the sensor does not receive anything on that port that sounds weird. That should not be the case

puck-fzi commented 3 years ago

The sensors are configured to "just stream" udp data as soon as they are turned on (which they do), there is no need for the the driver to establish a tcp connection in the first place (only for setting fields and stuff at runtime). Disregarding the fact that tcp should work because there is nothing blocking anything, is there a way to use the decoding part of the driver to just use the udp socket (which already exists) manually?

For this you need to go in the code and comment out all the command requests. There should be on getting the name, the type code and one passing a configuration in the setup.

kikass13 commented 3 years ago

Okay, if the sensor does not receive anything. are there maybe any configurations you can change in the safety designer? On the sensor side I am not that familiar with all the possible options. But if the sensor does not receive anything on that port that sounds weird. That should not be the case

I am not really sure. All I have done was go through every category in the designer and "tick all the boxes" until I was through all of them. There seems to be a category which defines "inputs"and I have selected "no input" . Is the configuration part of the sensor auch an 'input' ? I am not really sure but I can try it out next week :)

kikass13 commented 3 years ago

The sensors are configured to "just stream" udp data as soon as they are turned on (which they do), there is no need for the the driver to establish a tcp connection in the first place (only for setting fields and stuff at runtime). Disregarding the fact that tcp should work because there is nothing blocking anything, is there a way to use the decoding part of the driver to just use the udp socket (which already exists) manually?

For this you need to go in the code and comment out all the command requests. There should be on getting the name, the type code and one passing a configuration in the setup.

Thanks 👍 I'll take a look next week. Then I can see /usethe data at least, which is fine for now :)

puck-fzi commented 3 years ago

I am not really sure. All I have done was go through every category in the designer and "tick all the boxes" until I was through all of them. There seems to be a category which defines "inputs"and I have selected "no input" . Is the configuration part of the sensor auch an 'input' ? I am not really sure but I can try it out next week :)

As I said, I am not sure about all possible configurations of the SafetyDesigner. However it sounds like it should be working.

I'll take a look next week. Then I can see /usethe data at least, which is fine for now :)

If you need help figuring out which lines exactly let me know and I will have a look

puck-fzi commented 3 years ago

Did you manage to resolve the issue?

kikass13 commented 3 years ago

@puck-fzi I was unable to do something with the driver, because the last week was full of stuff to do :)

If the answer to this problem is to comment out the important part of the driver, you can close this issue. I will probably post my working driver code here later.

But I can probably do that in the coming two weeks :)

puck-fzi commented 3 years ago

Since the sensor does not receive anything on port 2021 as you mentioned, it appears to be more of a network problem then an actual driver problem. So yes I think i Will close it here, but please if you find any solution post it here, maybe it helps others as well. Or maybe you need to contact SICK directly to resolve the non accepting port 2021, since they will have more knowledge on the sensor side.

If there are any other troubles or insights please reopen or open a new issue.