search

SICKAG / sick_scan

sick_scan is an open-source project to support the laser scanner of the company SICK using the ROS-framework
Apache License 2.0
130 stars 104 forks source link

Auto detect ethernet #24

Closed eraserpencil closed 5 years ago

eraserpencil commented 5 years ago

Am currently using a Sick_Tim 571. Each time I restart the robot, I'd have to unplug and plug back in the ethernet to my computer, select the ethernet connection in Network Manager before I can get it working. Is there something like a udev rule I can have to ensure that I can run the sick lidar on start up?

I am on Ros Kinetic and the connection to my laptop is via a usb-ethernet adapter

michael1309 commented 5 years ago

Hello, Ryan,

When you restart the robotor, do you interrupt the power supply? The problem sounds to me like a problem with the link detection of the USB ethernet adapter which seems to be executed only once after the start of your system. If you unplug the adapter and replug it, the link detection will be executed again. To solve this problem I spontaneously think of two possibilities:

  1. use another usb-ethernet adapter that better supports link detection (this is the best option) console 
    #!/bin/bash
ifdown $usbethname   
ifup $usbethname

    This is what you do manually in the network manager. You can use this script as workauround and start it in a launchfile with see:https://answers.ros.org/question/51474/can-i-run-a-bash-script-using-roslaunch/

eraserpencil commented 5 years ago

I have tried manually resetting the network manager, even doing a sudo systemctl restart network-manager.service, but it didnt work. Am trying to find a pc with an ethernet port to test out.

I probably should have attached my error message in the original post. Here's it. Is there a mismatch between the mode of the scanner and my launch params? Would changing the parameters affect my the results that I have been using previously?

ROS_MASTER_URI=http://localhost:11311

process[sick_tim_5xx-1]: started with pid [2929]
[ INFO] [1545098264.586708176]: sick_generic_caller V. 001.002.005
[ INFO] [1545098264.586758451]: Program arguments: /home/movel/mov/catkin_ws/devel/lib/sick_scan/sick_generic_caller
[ INFO] [1545098264.586772190]: Program arguments: __name:=sick_tim_5xx
[ INFO] [1545098264.586782356]: Program arguments: __log:=/home/movel/.ros/log/daec5700-0267-11e9-9d7a-9cb6d0de9ec1/sick_tim_5xx-1.log
process[base_link_to_laser_transform-2]: started with pid [2930]
[ INFO] [1545098264.598850776]: Found sopas_protocol_type param overwriting default protocol:
[ INFO] [1545098264.598884066]: Binary protocol activated
[ INFO] [1545098264.598901984]: Start initialising scanner ...
[ INFO] [1545098264.735166763]: Parameter setting for <active_echo: 0>
[ INFO] [1545098264.935682560]: Sending  : sMN SetAccessMode \x03\xf4\x72\x47\x44
[ERROR] [1545098269.986172176]: no answer received after 5000 ms. Maybe sopas mode is wrong.

[ERROR] [1545098269.986282598]: sendSOPASCommand: no full reply available for read after 5000 ms
[ INFO] [1545098269.986403901]: Receiving: <STX><ETX>
[ERROR] [1545098269.986458796]: SOPAS Communication -Error unexpected Sopas Answer for request <STX><STX><STX><STX>sMN SetAccessMode <ETX>rGD

[ INFO] [1545098269.986627024]: Sending  : sMN SetAccessMode 3 F4724744
[ INFO] [1545098269.996961573]: Receiving: <STX>sAN SetAccessMode 1<ETX>
[ INFO] [1545098270.197358707]: Sending  : sWN EIHstCola 1
[ INFO] [1545098270.207745304]: Receiving: <STX>sWA EIHstCola<ETX>
[ERROR] [1545098270.207950347]: 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.
michael1309 commented 5 years ago

Hi Ryan,

all in all, the starting procedure doesn't look wrong. The scanner tries to start the communication in binary mode. Since this does not work, it switches to ASCII mode. In Ascii mode the binary communication is then set. After that the scanner runs into a timeout as expected and should start then. If this behavior annoys you, please set the following in the launch file:

<param name="use_binary_protocol" type="bool" value="false" />

This causes the scanner to communicate directly in ASCII mode. Then the mentioned communication behavior will no longer exist after startup. Before testing, please perform a cold start of the scanner so that it forgets the setting "binary communication" if necessary.

eraserpencil commented 5 years ago

Hey Michael,

Could you elaborate on the cold start?

michael1309 commented 5 years ago

It just means "repowering" the system due to bring the system in a default state. Power off - wait 10 secs. - Power on. That is all.