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

Unable to Receive Data #16

Closed JWhitleyWork closed 2 years ago

JWhitleyWork commented 2 years ago

When starting this driver with an OutdoorScan3 Pro with the default launch configuration (with changed IPs), the driver appears to start correctly but no data are available on any of the published topics. See the output below from launching the driver.

[INFO] [launch]: All log files can be found below /home/adlink/.ros/log/2022-01-25-10-31-52-029022-comhpcalt-128072
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [sick_safetyscanners2_node-1]: process started with pid [128074]
[sick_safetyscanners2_node-1] [INFO] [1643135512.188900834] [sick_safetyscanners2_node]: Initializing SickSafetyscannersRos2 Node
[sick_safetyscanners2_node-1] [INFO] [1643135512.189349596] [sick_safetyscanners2_node]: frame_id: scan
[sick_safetyscanners2_node-1] [INFO] [1643135512.189382156] [sick_safetyscanners2_node]: sensor_ip: 192.168.1.102
[sick_safetyscanners2_node-1] [INFO] [1643135512.189402956] [sick_safetyscanners2_node]: host_ip: 192.168.1.20
[sick_safetyscanners2_node-1] [INFO] [1643135512.189421436] [sick_safetyscanners2_node]: host_udp_port: 0
[sick_safetyscanners2_node-1] [INFO] [1643135512.189438516] [sick_safetyscanners2_node]: channel: 0
[sick_safetyscanners2_node-1] [INFO] [1643135512.189455956] [sick_safetyscanners2_node]: channel_enabled: true
[sick_safetyscanners2_node-1] [INFO] [1643135512.189472996] [sick_safetyscanners2_node]: skip: 0
[sick_safetyscanners2_node-1] [INFO] [1643135512.189489676] [sick_safetyscanners2_node]: angle_start: 0.000000
[sick_safetyscanners2_node-1] [INFO] [1643135512.189510876] [sick_safetyscanners2_node]: angle_end: 0.000000
[sick_safetyscanners2_node-1] [INFO] [1643135512.189528996] [sick_safetyscanners2_node]: time_offset: 0.000000
[sick_safetyscanners2_node-1] [INFO] [1643135512.189546836] [sick_safetyscanners2_node]: general_system_state: true
[sick_safetyscanners2_node-1] [INFO] [1643135512.189564116] [sick_safetyscanners2_node]: derived_settings: true
[sick_safetyscanners2_node-1] [INFO] [1643135512.189580916] [sick_safetyscanners2_node]: measurement_data: true
[sick_safetyscanners2_node-1] [INFO] [1643135512.189597196] [sick_safetyscanners2_node]: intrusion_data: true
[sick_safetyscanners2_node-1] [INFO] [1643135512.189613636] [sick_safetyscanners2_node]: application_io_data: true
[sick_safetyscanners2_node-1] [INFO] [1643135512.189630237] [sick_safetyscanners2_node]: use_persistent_config: false
[sick_safetyscanners2_node-1] [INFO] [1643135512.189647117] [sick_safetyscanners2_node]: min_intensities: 0.000000
[sick_safetyscanners2_node-1] [INFO]: Command Method Acknowledged.
[sick_safetyscanners2_node-1] [INFO] [1643135512.295665869] [sick_safetyscanners2_node]: Communication to Sensor set up
[sick_safetyscanners2_node-1] [INFO] [1643135512.295752749] [sick_safetyscanners2_node]: Reading Type code settings
[sick_safetyscanners2_node-1] [INFO]: Command Variable Acknowledged.
[sick_safetyscanners2_node-1] [INFO]: Type Code: MICS3-CBUZ40IZ1
[sick_safetyscanners2_node-1] [INFO] [1643135512.405565434] [sick_safetyscanners2_node]: Node Configured and running
JWhitleyWork commented 2 years ago

Additionally, we are unsure of how the OutdoorScan3 Pro is supposed to be configured to work correctly with the driver. We have spoken to the US SICK team but they said that since they did not develop the driver, I would have to contact the maintainer (namely @puck-fzi) but I suspect this particular question will require communication between the driver maintainer and someone at SICK with background in the sensor configuration software.

lenpuc commented 2 years ago

Hi, From the data it looks like the driver start correctly. Can you verify with wireshark or similar tooling that you are receiving UDP data packets on the computer where the driver is running

JWhitleyWork commented 2 years ago

@puck-fzi Thanks for getting back to me. I have verified with Wireshark that UDP data are being sent from the lidar's port 6060 to the PC's port 6060. The IP addresses are confirmed to be correct and I can ping the device. After some reconfiguration (changed the data output to "On Request"), I am now getting output on the /raw_data topic but not on /scan or /extended_scan. Here is an example of the message that I'm getting on /raw_data:

header:
  version_version: 82
  version_major_version: 2
  version_minor_version: 0
  version_release: 0
  serial_number_of_device: 20430241
  serial_number_of_channel_plug: 20430241
  channel_number: 0
  sequence_number: 1622871
  scan_number: 1622967
  timestamp_date: 0
  timestamp_time: 63649042
derived_values:
  multiplication_factor: 0
  number_of_beams: 0
  scan_time: 0
  start_angle: 0.0
  angular_beam_resolution: 0.0
  interbeam_period: 0
general_system_state:
  run_mode_active: false
  standby_mode_active: false
  contamination_warning: false
  contamination_error: false
  reference_contour_status: false
  manipulation_status: false
  safe_cut_off_path: []
  non_safe_cut_off_path: []
  reset_required_cut_off_path: []
  current_monitoring_case_no_table_1: 0
  current_monitoring_case_no_table_2: 0
  current_monitoring_case_no_table_3: 0
  current_monitoring_case_no_table_4: 0
  application_error: false
  device_error: false
measurement_data:
  number_of_beams: 0
  scan_points: []
intrusion_data:
  data: []
application_data:
  inputs:
    unsafe_inputs_input_sources: []
    unsafe_inputs_flags: []
    monitoring_case_number_inputs: []
    monitoring_case_number_inputs_flags: []
    linear_velocity_inputs_velocity_0: 0
    linear_velocity_inputs_velocity_0_valid: false
    linear_velocity_inputs_velocity_0_transmitted_safely: false
    linear_velocity_inputs_velocity_1: 0
    linear_velocity_inputs_velocity_1_valid: false
    linear_velocity_inputs_velocity_1_transmitted_safely: false
    sleep_mode_input: 0
  outputs:
    evaluation_path_outputs_eval_out: []
    evaluation_path_outputs_is_safe: []
    evaluation_path_outputs_is_valid: []
    monitoring_case_number_outputs: []
    monitoring_case_number_outputs_flags: []
    sleep_mode_output: 0
    sleep_mode_output_valid: false
    error_flag_contamination_warning: false
    error_flag_contamination_error: false
    error_flag_manipulation_error: false
    error_flag_glare: false
    error_flag_reference_contour_intruded: false
    error_flag_critical_error: false
    error_flags_are_valid: false
    linear_velocity_outputs_velocity_0: 0
    linear_velocity_outputs_velocity_0_valid: false
    linear_velocity_outputs_velocity_0_transmitted_safely: false
    linear_velocity_outputs_velocity_1: 0
    linear_velocity_outputs_velocity_1_valid: false
    linear_velocity_outputs_velocity_1_transmitted_safely: false
    resulting_velocity: []
    resulting_velocity_flags: []

I get the feeling that run_mode_active: false is probably not ideal but I'm unsure how to change this in the Safety Config software.

lenpuc commented 2 years ago

Hi, regarding the ouput it seems like the communication should be set up properly. You are receiving datagrams from the sensor. I am not sure what is happening though, the commands you send via the driver configuration look valid in my eyes. However as you mentioned there are is no sensor data arriving. Did you verify in the SICK Safety Designer, that you are seeing laserscans there? The raw data message tells you that there are no beams sent to the driver. Hence there will never be a laser_scan message or extended laser_scan messag since they are only published if the vector of beams is >0. However, I am not sure why this is happening. It might be a field in the configuration which is wrongly set up.

yegarti commented 2 years ago

Hi, I had the same issue and I want to share my solution.

The issue in my case was that I didn't select anything in the Safety designer->Configuration->Data output->Selection data content: image

Once I selected some blocks I got messages on '/scan'.

lenpuc commented 2 years ago

Thanks, for sharing your workaround.

However, the configuration should be done by the driver as well. If this is persistent, please reopen the issue