search

SICKAG / sick_scan_xd

Based on the sick_scan drivers for ROS1, sick_scan_xd merges sick_scan, sick_scan2 and sick_scan_base repositories. The driver supports both Linux (native, ROS1, ROS2) and Windows (native and ROS2).
Apache License 2.0
95 stars 85 forks source link

Could we change the protocol type through commands? #226

Closed Phymin closed 8 months ago

Phymin commented 10 months ago

Hi,

We're facing continuous data interruption issue with ASCII protocol on TIM-240(see the picture below), and it's suggested to change to binary protocol to prevent this issue, but now it's burdensome for us to change the protocol type through SOPAS ET, so I'm wondering if there is a way to change the protocol through commands? thanks.

MicrosoftTeams-image (9)

rostest commented 10 months ago

Thanks for your feedback. You can change the protocol type to Cola binary using SOPAS command sWN EIHstCola 1 and write the settings to the EEPROM with command sMN mEEwriteall. See telegram listing https://cdn.sick.com/media/docs/7/27/927/telegram_listing_telegram_listing_ranging_sensors_lms1xx_lms5xx_tim2xx_tim5xx_tim7xx_lms1000_mrs1000_mrs6000_nav310_ld_oem15xx_ld_lrs36xx_lms4000_lrs4000_multiscan100_picoscan100_en_im0045927.pdf for details.

The sick_scan_xd driver should automatically switch to Cola binary and reconnect to the lidar. Did you use the lastest sick_scan_xd release?

According to the messages in the screenshot, the lidar does not respond to the initial SetAccessMode command. Can you check the network settings and tcp ports? If in doubt, you might use wireshark to see the network traffic with the TiM240. If there is no response at all from the lidar, the problem is more likely related to network settings (ip address or tcp port).

Phymin commented 9 months ago

Yes, I tried with sick_scan_xd driver too, but without change the protocol to binary, the driver can't communicate with the lidar, that's the driver is not initialized successfully. Did I miss something, do you mean the sick_scan_xd driver will automatically change the protocol type if it's not the same with the configure file?

The issue on the screen shot is not happened at the beginning, but running for a while or for a long time. And under this situation, we can ping through the ip of the lidar. most of the time, after power cicle it, the lidar will work again.

rostest commented 9 months ago

Thanks for your reply. Yes, the sick_scan_xd driver should automatically switch to the binary protocol after start, using SOPAS command sWN EIHstCola 1. This causes a short delay after startup (a few seconds or less), which can be avoided by storing the binary mode in the lidars EEPROM. Otherwise protocol type switching should be done automatically. Can you post a complete logfile or screenshots from the whole initialization sequence, in case the protocol switching fails?

If the lidar fails to send its scandata after a long time and needs a power down and up cycle to restart, it might be a lidar problem. Please kill and restart sick_scan_xd driver in this error situation. Does the lidar respond after sick_scan_xd restart, or is a power cycle of the lidar (power down and up) required?

Phymin commented 9 months ago

Hi thanks for your timely reply. Sorry, currently, we're still using sick_scan driver for our products. I want to use sick_scan_xd, but from my previous trying, I can't use the binary protocol if it's current ASCII format. I will try your method again to see if it works. BTW, how should I send the command sWN EIHstCola 1, should I modify the driver code to send it or can I send it through command line?

Currently, we haven't tried with restart the driver, every time this issue happens, we either reboot the computer(I think this is similar with restart the driver) or power cycle the whole robot.

rostest commented 9 months ago

Thanks for further information. Note that sick_scan is not supported any longer. Please migrate to sick_scan_xd. The sick_scan_xd monitors the lidar communication and reconnects automatically in case of network or communication problems, incl. switching to the binary protocol.

If you use sick_scan_xd on ROS, you can send SOPAS commands like sWN EIHstCola 1 using ros services, but this should not be necessary in normal operation.

Please do not hesitate to reopen this issue, if the problem remains with the latest sick_scan_xd release.

Phymin commented 9 months ago

This is log from the latest release of sick_scan_xd:

... logging to /root/.ros/log/8192766a-7785-11ee-884f-00e0672f74a2/roslaunch-MS-91-5519.log
Checking log directory for disk usage. This may take a while.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://MS-91:37367/

SUMMARY
========

PARAMETERS
 * /rosdistro: melodic
 * /rosversion: 1.14.13
 * /sick_tim_240/add_transform_check_dynamic_updates: False
 * /sick_tim_240/add_transform_xyz_rpy: 0,0,0,0,0,0
 * /sick_tim_240/client_authorization_pw: F4724744
 * /sick_tim_240/cloud_topic: cloud
 * /sick_tim_240/frame_id: cloud
 * /sick_tim_240/hostname: 192.168.3.30
 * /sick_tim_240/intensity: True
 * /sick_tim_240/intensity_resolution_16bit: True
 * /sick_tim_240/max_ang: 2.094395102
 * /sick_tim_240/message_monitoring_enabled: True
 * /sick_tim_240/min_ang: -2.094395102
 * /sick_tim_240/min_intensity: 0.0
 * /sick_tim_240/port: 2111
 * /sick_tim_240/range_filter_handling: 0
 * /sick_tim_240/range_max: 100.0
 * /sick_tim_240/range_min: 0.0
 * /sick_tim_240/read_timeout_millisec_default: 5000
 * /sick_tim_240/read_timeout_millisec_kill_node: 150000
 * /sick_tim_240/read_timeout_millisec_startup: 120000
 * /sick_tim_240/ros_qos: -1
 * /sick_tim_240/scanner_type: sick_tim_240
 * /sick_tim_240/start_services: True
 * /sick_tim_240/sw_pll_only_publish: True
 * /sick_tim_240/time_increment: 0.00019290123
 * /sick_tim_240/timelimit: 5
 * /sick_tim_240/use_binary_protocol: True
 * /sick_tim_240/use_generation_timestamp: True

NODES
  /
    sick_tim_240 (sick_scan_xd/sick_generic_caller)

ROS_MASTER_URI=http://localhost:11311

process[sick_tim_240-1]: started with pid [5536]
[ INFO] [1698712979.004624023]: sick_generic_caller V. 3.0.0
[ INFO] [1698712979.005621772]: Program argument 1: /root/sick_ws/install/lib/sick_scan_xd/sick_generic_caller
[ INFO] [1698712979.005641893]: Program argument 2: __log:=/root/.ros/log/8192766a-7785-11ee-884f-00e0672f74a2/sick_tim_240-1.log
[ INFO] [1698712979.005654445]: Program argument 3: __name:=sick_tim_240
[ INFO] [1698712979.005665449]: ==========================================
[ INFO] [1698712979.010854874]: Range filter configuration: range_min=0, range_max=100, range_filter_handling=0
[ INFO] [1698712979.012126725]: Found sopas_protocol_type param overwriting default protocol:
[ INFO] [1698712979.012156328]: Binary protocol activated
[ INFO] [1698712979.013912717]: PointCloudMonitor started.
[ INFO] [1698712979.013974814]: Start initialising scanner [Ip: 192.168.3.30] [Port:2111]
[ INFO] [1698712979.070594760]: Publishing lidar pointcloud2 to cloud
[ INFO] [1698712979.071099756]: Publishing on topic "/cloud", qos=10
[ INFO] [1698712979.072077162]: Publishing on topic "/sick_tim_240/imu", qos=10
[ INFO] [1698712979.073033331]: Publishing on topic "/sick_tim_240/encoder", qos=10
[ INFO] [1698712979.074023690]: Publishing on topic "/sick_tim_240/scan", qos=10
[ INFO] [1698712979.075438354]: SickCloudTransform: add_transform_xyz_rpy = (0,0,0,0,0,0)
[ INFO] [1698712979.075464503]: SickCloudTransform: azimuth_offset = 0 [deg]
[ INFO] [1698712979.075486611]: SickCloudTransform: additional 3x3 rotation matrix = { (1,0,0), (0,1,0), (0,0,1) }
[ INFO] [1698712979.075503025]: SickCloudTransform: apply 3x3 rotation = false
[ INFO] [1698712979.075532704]: SickCloudTransform: additional translation = (0,0,0)
[ INFO] [1698712979.075547628]: SickCloudTransform: check_dynamic_updates = false
[ INFO] [1698712979.075579116]: sick_scan_xd: Tcp::open: connecting to 192.168.3.30:2111 ...
[ INFO] [1698712979.075866618]: sick_scan_xd Tcp::open: connected to 192.168.3.30:2111
[ INFO] [1698712979.075924256]: SickThread TcpRecvThread started.
[ INFO] [1698712979.079449620]: Parameter setting for <active_echo: 0>
[ INFO] [1698712979.080655798]: Sending  : <STX><STX><STX><STX><Len=0017>sRN SCdevicestate CRC:<0x30>
[ WARN] [1698712984.080844568]: Timeout during waiting for new datagram
[ INFO] [1698712984.080970100]: sendSOPASCommand: no full reply available for read after 5000 ms
[ INFO] [1698712984.081153389]: Receiving: <STX><ETX>
[ INFO] [1698712984.081276236]: SOPAS Communication -Error unexpected Sopas answer for request <STX><STX><STX><STX><Len=0017>sRN SCdevicestate CRC:<0x30>

[ WARN] [1698712984.081488167]: ## ERROR SickScanCommon: sendSopasAndCheckAnswer("sRN SCdevicestate") failed
[ WARN] [1698712984.081566202]: checkColaDialect: lidar response not in configured Cola-dialect Cola-B, trying different Cola configuration
[ INFO] [1698712984.081674295]: Sending  : <STX>sRN SCdevicestate<ETX>
[ WARN] [1698712989.081899395]: Timeout during waiting for new datagram
[ INFO] [1698712989.082009426]: sendSOPASCommand: no full reply available for read after 5000 ms
[ INFO] [1698712989.082226017]: Receiving: <STX><ETX>
[ INFO] [1698712989.082343192]: SOPAS Communication -Error unexpected Sopas answer for request <STX>sRN SCdevicestate<ETX>

[ WARN] [1698712989.082920183]: ## ERROR SickScanCommon: sendSopasAndCheckAnswer("sRN SCdevicestate") failed
[ WARN] [1698712989.083177517]: checkColaDialect: no lidar response in any cola configuration, check lidar and network!
[ WARN] [1698712989.083290330]: SickScanCommon::init_scanner() failed, aborting.
[ WARN] [1698712989.083395369]: SickScanCommon::init_scanner(): checkColaDialect failed, restarting.
[ WARN] [1698712989.083497472]: It is recommended to use the binary communication (Cola-B) by:
[ WARN] [1698712989.083565462]: 1. setting parameter use_binary_protocol true in the launch file, and
[ WARN] [1698712989.083653891]: 2. setting the lidar communication mode with the SOPAS ET software to binary and save this setting in the scanner's EEPROM.
[ INFO] [1698712989.083810871]: Failed to init scanner Error Code: 1
Waiting for timeout...
If the communication mode set in the scanner memory is different from that used by the driver, the scanner's communication mode is changed.
This requires a restart of the TCP-IP connection, which can extend the start time by up to 30 seconds. There are two ways to prevent this:
1. [Recommended] Set the communication mode with the SOPAS ET software to binary and save this setting in the scanner's EEPROM.
2. Use the parameter "use_binary_protocol" to overwrite the default settings of the driver.
[ERROR] [1698712989.084034032]: ## ERROR in mainGenericLaser: init failed, retrying...
[ INFO] [1698712989.084180683]: Start initialising scanner [Ip: 192.168.3.30] [Port:2111]
[ WARN] [1698712989.084332849]: Disconnecting TCP-Connection.
[ERROR] [1698712989.084695736]: Tcp::readInputData: Read 0 bytes, connection is lost!
[ INFO] [1698712989.084932064]: SickThread TcpRecvThread finished (flags: threadShouldRun=0, endThread=0).
sick_scan_xd driver closed.
[ INFO] [1698712989.290917176]: Publishing lidar pointcloud2 to cloud
[ INFO] [1698712989.291961203]: Publishing on topic "/cloud", qos=10
[ INFO] [1698712989.294052661]: Publishing on topic "/sick_tim_240/imu", qos=10
[ INFO] [1698712989.296344612]: Publishing on topic "/sick_tim_240/encoder", qos=10
[ INFO] [1698712989.298674077]: Publishing on topic "/sick_tim_240/scan", qos=10
[ INFO] [1698712989.301955724]: SickCloudTransform: add_transform_xyz_rpy = (0,0,0,0,0,0)
[ INFO] [1698712989.302021959]: SickCloudTransform: azimuth_offset = 0 [deg]
[ INFO] [1698712989.302076855]: SickCloudTransform: additional 3x3 rotation matrix = { (1,0,0), (0,1,0), (0,0,1) }
[ INFO] [1698712989.302113657]: SickCloudTransform: apply 3x3 rotation = false
[ INFO] [1698712989.302144376]: SickCloudTransform: additional translation = (0,0,0)
[ INFO] [1698712989.302161688]: SickCloudTransform: check_dynamic_updates = false
[ INFO] [1698712989.302199371]: sick_scan_xd: Tcp::open: connecting to 192.168.3.30:2111 ...
[ INFO] [1698712989.302547971]: sick_scan_xd Tcp::open: connected to 192.168.3.30:2111
[ INFO] [1698712989.302785317]: SickThread TcpRecvThread started.
[ INFO] [1698712989.308578881]: Parameter setting for <active_echo: 0>
[ INFO] [1698712989.311340778]: Sending  : <STX><STX><STX><STX><Len=0017>sRN SCdevicestate CRC:<0x30>
[ WARN] [1698712994.311526048]: Timeout during waiting for new datagram
[ INFO] [1698712994.311651903]: sendSOPASCommand: no full reply available for read after 5000 ms
[ INFO] [1698712994.311926776]: Receiving: <STX><ETX>
[ INFO] [1698712994.312006141]: SOPAS Communication -Error unexpected Sopas answer for request <STX><STX><STX><STX><Len=0017>sRN SCdevicestate CRC:<0x30>

[ WARN] [1698712994.312166247]: ## ERROR SickScanCommon: sendSopasAndCheckAnswer("sRN SCdevicestate") failed
[ WARN] [1698712994.312249799]: checkColaDialect: lidar response not in configured Cola-dialect Cola-B, trying different Cola configuration
[ INFO] [1698712994.312345414]: Sending  : <STX>sRN SCdevicestate<ETX>
[ WARN] [1698712999.312540904]: Timeout during waiting for new datagram
[ INFO] [1698712999.312638826]: sendSOPASCommand: no full reply available for read after 5000 ms
[ INFO] [1698712999.312754047]: Receiving: <STX><ETX>
[ INFO] [1698712999.312827215]: SOPAS Communication -Error unexpected Sopas answer for request <STX>sRN SCdevicestate<ETX>

[ WARN] [1698712999.312947647]: ## ERROR SickScanCommon: sendSopasAndCheckAnswer("sRN SCdevicestate") failed
[ WARN] [1698712999.313011933]: checkColaDialect: no lidar response in any cola configuration, check lidar and network!
[ WARN] [1698712999.313053640]: SickScanCommon::init_scanner() failed, aborting.
[ WARN] [1698712999.313110438]: SickScanCommon::init_scanner(): checkColaDialect failed, restarting.
[ WARN] [1698712999.313164150]: It is recommended to use the binary communication (Cola-B) by:
[ WARN] [1698712999.313227368]: 1. setting parameter use_binary_protocol true in the launch file, and
[ WARN] [1698712999.313297391]: 2. setting the lidar communication mode with the SOPAS ET software to binary and save this setting in the scanner's EEPROM.
[ INFO] [1698712999.313424947]: Failed to init scanner Error Code: 1
Waiting for timeout...
If the communication mode set in the scanner memory is different from that used by the driver, the scanner's communication mode is changed.
This requires a restart of the TCP-IP connection, which can extend the start time by up to 30 seconds. There are two ways to prevent this:
1. [Recommended] Set the communication mode with the SOPAS ET software to binary and save this setting in the scanner's EEPROM.
2. Use the parameter "use_binary_protocol" to overwrite the default settings of the driver.
[ERROR] [1698712999.313533119]: ## ERROR in mainGenericLaser: init failed, retrying...
[ INFO] [1698712999.313624626]: Start initialising scanner [Ip: 192.168.3.30] [Port:2111]
[ WARN] [1698712999.313702398]: Disconnecting TCP-Connection.
[ERROR] [1698712999.313839052]: Tcp::readInputData: Read 0 bytes, connection is lost!
[ INFO] [1698712999.313969047]: SickThread TcpRecvThread finished (flags: threadShouldRun=0, endThread=0).
sick_scan_xd driver closed.
[ INFO] [1698712999.573380024]: Publishing lidar pointcloud2 to cloud
[ INFO] [1698712999.575685086]: Publishing on topic "/cloud", qos=10
[ INFO] [1698712999.579906442]: Publishing on topic "/sick_tim_240/imu", qos=10
[ INFO] [1698712999.585361729]: Publishing on topic "/sick_tim_240/encoder", qos=10
[ INFO] [1698712999.590406296]: Publishing on topic "/sick_tim_240/scan", qos=10
[ INFO] [1698712999.597666542]: SickCloudTransform: add_transform_xyz_rpy = (0,0,0,0,0,0)
[ INFO] [1698712999.597766830]: SickCloudTransform: azimuth_offset = 0 [deg]
[ INFO] [1698712999.597910181]: SickCloudTransform: additional 3x3 rotation matrix = { (1,0,0), (0,1,0), (0,0,1) }
[ INFO] [1698712999.597981371]: SickCloudTransform: apply 3x3 rotation = false
[ INFO] [1698712999.598115261]: SickCloudTransform: additional translation = (0,0,0)
[ INFO] [1698712999.598177111]: SickCloudTransform: check_dynamic_updates = false
[ INFO] [1698712999.598266670]: sick_scan_xd: Tcp::open: connecting to 192.168.3.30:2111 ...
[ INFO] [1698712999.600209897]: sick_scan_xd Tcp::open: connected to 192.168.3.30:2111
[ INFO] [1698712999.600615368]: SickThread TcpRecvThread started.
[ INFO] [1698712999.613647268]: Parameter setting for <active_echo: 0>
[ INFO] [1698712999.620274035]: Sending  : <STX><STX><STX><STX><Len=0017>sRN SCdevicestate CRC:<0x30>
[ WARN] [1698713004.620741785]: Timeout during waiting for new datagram
[ INFO] [1698713004.620844090]: sendSOPASCommand: no full reply available for read after 5000 ms
[ INFO] [1698713004.621006375]: Receiving: <STX><ETX>
[ INFO] [1698713004.621077054]: SOPAS Communication -Error unexpected Sopas answer for request <STX><STX><STX><STX><Len=0017>sRN SCdevicestate CRC:<0x30>

[ WARN] [1698713004.621159386]: ## ERROR SickScanCommon: sendSopasAndCheckAnswer("sRN SCdevicestate") failed
[ WARN] [1698713004.621206443]: checkColaDialect: lidar response not in configured Cola-dialect Cola-B, trying different Cola configuration
[ INFO] [1698713004.621274311]: Sending  : <STX>sRN SCdevicestate<ETX>
[ WARN] [1698713009.621500098]: Timeout during waiting for new datagram
[ INFO] [1698713009.621631284]: sendSOPASCommand: no full reply available for read after 5000 ms
[ INFO] [1698713009.621756987]: Receiving: <STX><ETX>
[ INFO] [1698713009.621828437]: SOPAS Communication -Error unexpected Sopas answer for request <STX>sRN SCdevicestate<ETX>

[ WARN] [1698713009.621910040]: ## ERROR SickScanCommon: sendSopasAndCheckAnswer("sRN SCdevicestate") failed
[ WARN] [1698713009.622001573]: checkColaDialect: no lidar response in any cola configuration, check lidar and network!
[ WARN] [1698713009.622062147]: SickScanCommon::init_scanner() failed, aborting.
[ WARN] [1698713009.622115312]: SickScanCommon::init_scanner(): checkColaDialect failed, restarting.
[ WARN] [1698713009.622157203]: It is recommended to use the binary communication (Cola-B) by:
[ WARN] [1698713009.622202500]: 1. setting parameter use_binary_protocol true in the launch file, and
[ WARN] [1698713009.622252763]: 2. setting the lidar communication mode with the SOPAS ET software to binary and save this setting in the scanner's EEPROM.
[ INFO] [1698713009.622365950]: Failed to init scanner Error Code: 1
Waiting for timeout...

What do you think the problem is?

Phymin commented 9 months ago

@rostest could you reopen this issue, because I can't do it, thanks

rostest commented 9 months ago

Thanks for further information and logfile. sick_scan_xd establishes a tcp connection to the lidar, but the lidar does not respond to any requests. This error might be related to a network/firewall problem or to the communication protocol type. Please check the two following settings:

Phymin commented 9 months ago

Is the lidar working with SOPAS ET in both binary and ascii communication? Can you switch between both protocol types in SOPAS ET without restart?

A: yes, it working in both binary and ascii communication, and can switch both protocol types in SOPAS ET without restart. But the default format is ascii, as the screen shot shows.

微信图片_20231101174954

Please set binary communication mode in SOPAS ET and start sick_scan_xd in binary mode (default settings or in the launchfile). Does sick_scan_xd receive now any answers from the lidar? Does sick_scan_xd receive any answers, if the lidar has been set to ascii communication mode by SOPAS ET before?

A: After set to binary protocol without restart the lidar, the launch file with use_binary_protocol to True works.

... logging to /root/.ros/log/26f33f82-7898-11ee-bfc7-ede1e364f3ba/roslaunch-mp-104-4654.log
Checking log directory for disk usage. This may take a while.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://mp-104:42563/

SUMMARY
========

PARAMETERS
 * /rosdistro: melodic
 * /rosversion: 1.14.13
 * /sick_tim_240/add_transform_check_dynamic_updates: False
 * /sick_tim_240/add_transform_xyz_rpy: 0,0,0,0,0,0
 * /sick_tim_240/client_authorization_pw: F4724744
 * /sick_tim_240/cloud_topic: cloud
 * /sick_tim_240/frame_id: cloud
 * /sick_tim_240/hostname: 192.168.3.30
 * /sick_tim_240/intensity: True
 * /sick_tim_240/intensity_resolution_16bit: True
 * /sick_tim_240/max_ang: 2.094395102
 * /sick_tim_240/message_monitoring_enabled: True
 * /sick_tim_240/min_ang: -2.094395102
 * /sick_tim_240/min_intensity: 0.0
 * /sick_tim_240/port: 2111
 * /sick_tim_240/range_filter_handling: 0
 * /sick_tim_240/range_max: 100.0
 * /sick_tim_240/range_min: 0.0
 * /sick_tim_240/read_timeout_millisec_default: 5000
 * /sick_tim_240/read_timeout_millisec_kill_node: 150000
 * /sick_tim_240/read_timeout_millisec_startup: 120000
 * /sick_tim_240/ros_qos: -1
 * /sick_tim_240/scanner_type: sick_tim_240
 * /sick_tim_240/start_services: True
 * /sick_tim_240/sw_pll_only_publish: True
 * /sick_tim_240/time_increment: 0.00019290123
 * /sick_tim_240/timelimit: 5
 * /sick_tim_240/use_binary_protocol: True
 * /sick_tim_240/use_generation_timestamp: True

NODES
  /
    sick_tim_240 (sick_scan_xd/sick_generic_caller)

auto-starting new master
process[master]: started with pid [4664]
ROS_MASTER_URI=http://localhost:11311

setting /run_id to 26f33f82-7898-11ee-bfc7-ede1e364f3ba
process[rosout-1]: started with pid [4677]
started core service [/rosout]
process[sick_tim_240-2]: started with pid [4684]
[ INFO] [1698830538.340981049]: sick_generic_caller V. 3.0.0
[ INFO] [1698830538.342381547]: Program argument 1: /root/sick_ws/install/lib/sick_scan_xd/sick_generic_caller
[ INFO] [1698830538.342411733]: Program argument 2: __log:=/root/.ros/log/26f33f82-7898-11ee-bfc7-ede1e364f3ba/sick_tim_240-2.log
[ INFO] [1698830538.342436268]: Program argument 3: __name:=sick_tim_240
[ INFO] [1698830538.342459114]: ==========================================
[ INFO] [1698830538.349571250]: Range filter configuration: range_min=0, range_max=100, range_filter_handling=0
[ INFO] [1698830538.351236990]: Found sopas_protocol_type param overwriting default protocol:
[ INFO] [1698830538.351271222]: Binary protocol activated
[ INFO] [1698830538.353722728]: PointCloudMonitor started.
[ INFO] [1698830538.353765904]: Start initialising scanner [Ip: 192.168.3.30] [Port:2111]
[ INFO] [1698830538.417367825]: Publishing lidar pointcloud2 to cloud
[ INFO] [1698830538.418002829]: Publishing on topic "/cloud", qos=10
[ INFO] [1698830538.419496997]: Publishing on topic "/sick_tim_240/imu", qos=10
[ INFO] [1698830538.420968695]: Publishing on topic "/sick_tim_240/encoder", qos=10
[ INFO] [1698830538.422317062]: Publishing on topic "/sick_tim_240/scan", qos=10
[ INFO] [1698830538.424346557]: SickCloudTransform: add_transform_xyz_rpy = (0,0,0,0,0,0)
[ INFO] [1698830538.424384793]: SickCloudTransform: azimuth_offset = 0 [deg]
[ INFO] [1698830538.424420422]: SickCloudTransform: additional 3x3 rotation matrix = { (1,0,0), (0,1,0), (0,0,1) }
[ INFO] [1698830538.424443526]: SickCloudTransform: apply 3x3 rotation = false
[ INFO] [1698830538.424475156]: SickCloudTransform: additional translation = (0,0,0)
[ INFO] [1698830538.424498279]: SickCloudTransform: check_dynamic_updates = false
[ INFO] [1698830538.424555318]: sick_scan_xd: Tcp::open: connecting to 192.168.3.30:2111 ...
[ INFO] [1698830538.425141804]: sick_scan_xd Tcp::open: connected to 192.168.3.30:2111
[ INFO] [1698830538.425178623]: SickThread TcpRecvThread started.
[ INFO] [1698830538.428529780]: Parameter setting for <active_echo: 0>
[ INFO] [1698830538.430252701]: Sending  : <STX><STX><STX><STX><Len=0017>sRN SCdevicestate CRC:<0x30>
[ INFO] [1698830538.430920788]: Receiving: <STX>sRA SCdevicestate \x01<ETX>
[ INFO] [1698830538.430969179]: checkColaDialect: lidar response in configured Cola-dialect Cola-B
[ INFO] [1698830538.631359594]: Sending  : <STX><STX><STX><STX><Len=0023>sMN SetAccessMode 0x03 0xf4 0x72 0x47 0x44 CRC:<0xb3>
[ INFO] [1698830538.632669120]: Receiving: <STX>sAN SetAccessMode \x01<ETX>
[ INFO] [1698830538.833150460]: Sending  : <STX><STX><STX><STX><Len=0015>sWN EIHstCola 0x01 CRC:<0x09>
[ INFO] [1698830538.834169559]: Receiving: <STX>sWA EIHstCola <ETX>
[ INFO] [1698830539.034666031]: Sending  : <STX><STX><STX><STX><Len=0019>sRN FirmwareVersion CRC:<0x24>
[ INFO] [1698830539.035704109]: Receiving: <STX>sRA FirmwareVersion \x00\x13\x56\x30\x30\x31\x2e\x30\x30\x30\x2e\x30\x30\x34\x2e\x30\x30\x3...
[ INFO] [1698830539.236111338]: Sending  : <STX><STX><STX><STX><Len=0017>sRN SCdevicestate CRC:<0x30>
[ INFO] [1698830539.237334626]: Receiving: <STX>sRA SCdevicestate \x00<ETX>
[ INFO] [1698830539.437749335]: Sending  : <STX><STX><STX><STX><Len=0010>sRN ODoprh CRC:<0x41>
[ INFO] [1698830539.438838307]: Receiving: <STX>sRA ODoprh \x00\x00\x22\x00<ETX>
[ INFO] [1698830539.642372075]: Sending  : <STX><STX><STX><STX><Len=0010>sRN ODpwrc CRC:<0x52>
[ INFO] [1698830539.643354887]: Receiving: <STX>sRA ODpwrc \x00\x00\x02\x5c<ETX>
[ INFO] [1698830539.846210289]: Sending  : <STX><STX><STX><STX><Len=0016>sRN LocationName CRC:<0x55>
[ INFO] [1698830539.847338147]: Receiving: <STX>sRA LocationName \x00\x0b\x53\x4e\x20\x31\x32\x33\x34\x35\x36\x37\x38<ETX>
[ INFO] [1698830539.850193979]: Sending  : <STX><STX><STX><STX><Len=0018>sRN LMPoutputRange CRC:<0x5e>
[ INFO] [1698830539.851121945]: Receiving: <STX>sRA LMPoutputRange \x00\x01\x00\x00\x27\x10\xff\xed\xb0\x80\x00\x12\x4f\x80<ETX>
[ INFO] [1698830539.851303001]: Angle resolution of scanner is 1 [deg]  (in 1/10000th deg: 10000)
[ INFO] [1698830539.851403037]: [From:To] -120 [deg] to 120 [deg] (in 1/10000th deg: from -1200000 to 1200000)
[ INFO] [1698830539.851493980]: MIN_ANG: -2.0944 [rad] -120 [deg]
[ INFO] [1698830539.851578045]: MAX_ANG: 2.0944 [rad] 120 [deg]
[ INFO] [1698830539.851777630]: Sending  : <STX><STX><STX><STX><Len=0033>sWN LMPoutputRange 0x00 0x01 0x00 0x00 0x27 0x10 0xff 0xed 0xb0 0x80 0x00 0x12 0x4f 0x80 CRC:<0xb2>
[ INFO] [1698830539.852803914]: Receiving: <STX>sWA LMPoutputRange <ETX>
[ INFO] [1698830539.852990122]: Sending  : <STX><STX><STX><STX><Len=0018>sRN LMPoutputRange CRC:<0x5e>
[ INFO] [1698830539.854596609]: Receiving: <STX>sRA LMPoutputRange \x00\x01\x00\x00\x27\x10\xff\xed\xb0\x80\x00\x12\x4f\x80<ETX>
[ INFO] [1698830539.854738049]: Angle resolution of scanner is 1 [deg]  (in 1/10000th deg: 10000)
[ INFO] [1698830539.863250639]: MIN_ANG (after command verification): -2.0944 [rad] -120 [deg]
[ INFO] [1698830539.863370900]: MAX_ANG (after command verification): 2.0944 [rad] 120 [deg]
[ INFO] [1698830539.863567661]: Sending  : <STX><STX><STX><STX><Len=0032>sWN LMDscandatacfg 0x01 0x00 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x01 CRC:<0x43>
[ INFO] [1698830539.864542775]: Receiving: <STX>sWA LMDscandatacfg <ETX>
[ INFO] [1698830539.864718009]: Sending  : <STX><STX><STX><STX><Len=0018>sRN LMDscandatacfg CRC:<0x67>
[ INFO] [1698830539.866634229]: Receiving: <STX>sRA LMDscandatacfg \x01\x00\x01\x01\x00\x00\x00\x00\x00\x00\x01\x00\x01<ETX>
[ INFO] [1698830539.870656587]: Sending  : <STX><STX><STX><STX><Len=0007>sMN Run CRC:<0x19>
[ INFO] [1698830539.871680613]: Receiving: <STX>sAN Run \x01<ETX>
[ INFO] [1698830539.871861210]: Sending  : <STX><STX><STX><STX><Len=0017>sEN LMDscandata 0x01 CRC:<0x33>
[ INFO] [1698830539.874138545]: Receiving: <STX>sEA LMDscandata \x01<ETX>
[ INFO] [1698830539.880348911]: SickScanServices: service "/sick_tim_240/ColaMsg" created ("/sick_tim_240/ColaMsg")
[ INFO] [1698830539.882927021]: SickScanServices: service "/sick_tim_240/ECRChangeArr" created ("/sick_tim_240/ECRChangeArr")
[ INFO] [1698830539.885329215]: SickScanServices: service "/sick_tim_240/LIDoutputstate" created ("/sick_tim_240/LIDoutputstate")
[ INFO] [1698830539.887887376]: SickScanServices: service "/sick_tim_240/SCdevicestate" created ("/sick_tim_240/SCdevicestate")
[ INFO] [1698830539.890329540]: SickScanServices: service "/sick_tim_240/SCreboot" created ("/sick_tim_240/SCreboot")
[ INFO] [1698830539.892484887]: SickScanServices: service "/sick_tim_240/SCsoftreset" created ("/sick_tim_240/SCsoftreset")
[ INFO] [1698830539.894443919]: SickScanServices: service "/sick_tim_240/SickScanExit" created ("/sick_tim_240/SickScanExit")
[ INFO] [1698830539.894546478]: SickScanServices: ros services initialized
[ INFO] [1698830539.894627718]: Setup completed, sick_scan_xd is up and running. Pointcloud is published on topic "cloud"
[ INFO] [1698830539.917652413]: Software PLL locking started, mapping ticks to system time.
[ INFO] [1698830539.917767934]: 1 / 6 packets dropped. Software PLL not yet locked.
[ INFO] [1698830539.987180704]: 2 / 6 packets dropped. Software PLL not yet locked.
[ INFO] [1698830540.057017939]: 3 / 6 packets dropped. Software PLL not yet locked.
[ INFO] [1698830540.126656651]: 4 / 6 packets dropped. Software PLL not yet locked.
[ INFO] [1698830540.196409274]: 5 / 6 packets dropped. Software PLL not yet locked.
[ INFO] [1698830540.266048638]: Software PLL is ready and locked now!

Actually, we don't set the communication intentionally, because it's default communication protocol is ascii (if binary is better, why the default is ascii?). And if it's in ascii communication, the 'use_binary_protocol` set to True doesn't work.

What we want is don't use SOPAS ET to set the communication type, because it's burdonsome to do this in the customer side, do you have any suggestions? Thanks

rostest commented 9 months ago

Thank you for your feedback and testing. The TiM240 seems to use a slightly different logic compared to other lidars for switching from ASCII mode to binary mode. We are clarifying with SICK support and management how to proceed. In the short term, we recommend using SOPAS ET to preset the lidars to binary mode.

rostest commented 8 months ago

We updated the protocol switching for the TiM-240 in branch feature/tim240_protocol_switch. Please checkout https://github.com/SICKAG/sick_scan_xd/tree/feature/tim240_protocol_switch, rebuild and try again using binary protocol. If the TiM-240 is in Cola-Ascii mode, it will be switched to Cola-B (binary protocol) and restarted after a few seconds.

Phymin commented 8 months ago

After testing, it's confirmed it's working to change the ascii protocol to binary protocol, but after it's changed to binary mode, if I change use_binary_protocol to false, though at the begining from the output log, there is no error out, but there is also no data published. and after about 150s, there is error out which says there is no data published after about 150s and the driver shutdown automatically.

rostest commented 8 months ago

Thanks for your feedback. Support for the ascii communication protocol is being phased out. Please use the binary communication mode with default setting <param name="use_binary_protocol" type="bool" value="true"/>.