ergoCub 1.1 S/N:001 – RPLIDAR S2 does not start

[SimoneMic]

Robot Name 🤖

ergoCub 1.1 S/N:001

Request/Failure description

When launching the yarprobotinterface that starts the lidar, it core dumps at startup suddenly without any errors. The file used is the same one used for ergocubSN000

Detailed context

For additional information see the following issue opened on yarp-device-rplidar issue: https://github.com/robotology/yarp-device-rplidar/issues/3

The error print on the terminal when launching the YRI is:

ergocub@ergocub-head:/usr/local/src/robot/robotology-superbuild/src/robots-configuration/ergoCubSN001$ yarprobotinterface --config sensors.xml 
[DEBUG] Reading file /usr/local/src/robot/robotology-superbuild/src/robots-configuration/ergoCubSN001/sensors.xml
[DEBUG] yarprobotinterface: using xml parser for DTD v3.x
[DEBUG] Reading file /usr/local/src/robot/robotology-superbuild/src/robots-configuration/ergoCubSN001/sensors.xml
[INFO] Yarprobotinterface was started using the following enable_tags: 
[INFO] Yarprobotinterface was started using the following disable_tags: 
[DEBUG] List of all enable attributes found in the include tags: 
[DEBUG] List of all disable attributes found in the include tags: 
[DEBUG] Preprocessor complete in:  0.000567198 s
[INFO] |yarp.os.Port|/ergocub/yarprobotinterface| Port /ergocub/yarprobotinterface active at tcp://10.0.2.3:10002/
[INFO] startup phase starting...
[INFO] Opening device rpLidarS2 with parameters [("robotName" = "/ergocub"), ("GENERAL" [group] = "(name rpLidar4) (serial_baudrate 1000000) (serial_port /dev/ttyUSB0) (sample_buffer_life 1)"), ("SENSOR" [group] = "(max_distance 30.0) (min_distance 0.1) (max_angle 360) (min_angle 0) (resolution 0.12) (allow_infinity 1)"), ("RPLIDAR" [group] = "(scan_mode DenseBoost)")]
[DEBUG] |yarp.dev.PolyDriver|rpLidarS2| Parameters are (GENERAL (name rpLidar4) (serial_baudrate 1000000) (serial_port "/dev/ttyUSB0") (sample_buffer_life 1)) (RPLIDAR (scan_mode DenseBoost)) (SENSOR (max_distance 30.0) (min_distance 0.100000000000000005551115123125782702) (max_angle 360) (min_angle 0) (resolution 0.119999999999999995559107901499373838) (allow_infinity 1)) (device rpLidar4) (id rpLidarS2) (robotName "/ergocub")
[INFO] |yarp.devices.Lidar2DDeviceBase| Using the following parameters:
[INFO] |yarp.devices.Lidar2DDeviceBase| max_dist: 30  min_dist: 0.1
[INFO] |yarp.devices.Lidar2DDeviceBase| max_angle: 360  min_angle: 0
[INFO] |yarp.devices.Lidar2DDeviceBase| resolution: 0.12
[INFO] |yarp.devices.Lidar2DDeviceBase| sensors: 3000
[INFO] |yarp.devices.Lidar2DDeviceBase| allow_infinity: true
*** buffer overflow detected ***: terminated
Aborted (core dumped)

Additional context

The communication seems to ok (on /dev/ttyUSB0), I can see the port used for the bridge USB to UART used by the lidar (if I am not mistaken) using the command usb-devices:

T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=10c4 ProdID=ea60 Rev=01.00
S:  Manufacturer=Silicon Labs
S:  Product=CP2102N USB to UART Bridge Controller
S:  SerialNumber=62ef2ef3b713ec11a34df2ef7a109228
C:  #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=cp210x

And also from the following command the port of the lidar seems to be present:

ergocub@ergocub-head:~$ sudo dmesg | grep tty
[    0.000000] Kernel command line: root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 rootfstype=ext4 sdhci_tegra.en_boot_part_access=1 
[    0.001887] printk: console [tty0] enabled
[    1.073771] printk: console [ttyTCU0] enabled
[    6.968646] 3100000.serial: ttyTHS0 at MMIO 0x3100000 (irq = 35, base_baud = 0) is a TEGRA_UART
[    6.983343] 3110000.serial: ttyTHS1 at MMIO 0x3110000 (irq = 36, base_baud = 0) is a TEGRA_UART
[    8.912187] systemd[1]: Created slice system-serial\x2dgetty.slice.
[   11.735865] usb 1-4: cp210x converter now attached to ttyUSB0

Could it be a faulty lidar, power supply issue or firmware version? cc @randaz81

How does it affect you?

Unable to navigate

[SimoneMic]

After debugging the code yarp-device-rplidar and the Slamtech SDK, I found that the core dump happens in this line of code from the manufacturer's SDK. When the code tries to get the device info and to communicate with the lidar, it seems that the channel is not able to properly get the data and has a buffer overflow, crashing everything. Since the SDK code is the same used on ergoCubSN000, it is likely an hardware problem. It could be both the lidar or the Serial to USB device converter. Has any of these devices already been tested separately?

I have also tried to check the serial communication on the port /dev/ttyUSB0 using screen or cutecom but both weren't able to open the port. Also using the slamtech frame_grabber for debugging the lidar via terminal gives this error:

ergocub@ergocub-head:/usr/local/src/robot/tmp/rplidar_sdk/output/Linux/Release$ sudo ./ultra_simple --channel --serial /dev/ttyUSB0 1000000
[sudo] password for ergocub: 
Ultra simple LIDAR data grabber for SLAMTEC LIDAR.
Version: 2.1.0
Error, cannot bind to the specified serial port /dev/ttyUSB0.

It would be helpful to have access directly to the lidar to further debug it with another PC

cc @randaz81

[sgiraz]

Has any of these devices already been tested separately?

Hi @SimoneMic,

The Lidar was not tested before the delivery. AMI Research Line was already aware of this and honestly, I don't remember if HSP has been informed or not by @AntonioConsilvio and/or @AntonioAzocar.

Anyway, thank you for your feedback. Once we get the robot back to proto we'll fix/test the Lidar.

cc @Nicogene @mfussi66 @martinaxgloria @Gandoo

[sgiraz]

Hi @SimoneMic,

Is there any news on the RPLIDAR S2? @AntonioConsilvio said to me that yesterday you tested the sensor and it works correctly, right?

[SimoneMic]

Hi,

Yes, yesterday I've launched it more times to see if it was working and the device was loading properly. I was also able to see it on ros2.

Honestly I don't know what changed from last year, but luckily it works now.

I close this issue for now (hopefully forever) if anything else arises I will eventually reopen it

[SimoneMic]

Re-opening this issue since today with @AntonioConsilvio this issue re-emerged.

We also tried to attach a new lidar (the one destined to SN002) to the board and the same behavior occured. For completeness, we tested the second lidar (the one for SN002) on the laptop and it worked fine. We used the same yarprobotinterface config file. The only difference was that, while compiling the yarp-device-rplidar on the laptop, we had two errors on the lidar vendor sdk at this line and this line. After fixing the compile error it was running fine on the laptop. We also tried to port this change to the head, but to no avail.

Actually I don't know what could it be, the lidar and the connections (cables, UART and USB converter) seem fine. The only further test that I can think of is to test the lidar on a new board (maybe we could use the SN002 one, on the bench)

[SimoneMic]

Closing this issue (hopefully forever) since I have found the solution to this. There was a problem with permissions on the port /dev/ttyUSB0. I think that the coredump is due to the code (from vendor or linux library) is trying to read the pointer to the serial buffer, which wasn't having the permission to read the stream, thus returning a null pointer. When trying to access this null pointer, the coredump happens.

I'll post the sequence that I have done for completion, although only the last step is relevant.

• 1) added the user to the dialout group
• 2) modified the permission to the specific port sudo chmod 777 /dev/ttyusb0

As general rule, if the user loses the permissions to read/write ports, the second command solves the issue.