YDLiDAR: Reality Strikes

GoPiGo
1

Every sensor has personality (reality) that the user must learn to effectively use the information coming from the sensor.

The YDLiDAR personality starts with being a family of LiDARs, each needing specific values for 21 parameters, and in fact some of the parameters have a range of values although the range is different for the particular LiDAR model.

These are what I am trying for the YDLiDAR X4 model:

ydlidar_ros2_driver_node:
  ros__parameters:
    port: /dev/ttyUSB0
    frame_id: laser_frame
    ignore_array: ""
    baudrate: 128000
    lidar_type: 1
    device_type: 6
    sample_rate: 5        <-- This is actually 5000 Hz sample rate
    abnormal_check_count: 4
    fixed_resolution: true
    reversion: false
    inverted: true
    auto_reconnect: true
    isSingleChannel: false
    intensity: false
    support_motor_dtr: true
    angle_max: 180.0
    angle_min: -180.0
    range_max: 10.0
    range_min: 0.12   
    frequency: 7.0     <-- to get roughly 360 degree readings by 1/2 degree on the X4 LiDAR 
    invalid_range_is_inf: false

BUT then there are the mystery personalities that the user must discover … like one of the ranges around the straight ahead direction is always coming in at ZERO - and that just happened to be the direction I initially chose to use as my “front distance”

************* DEBUG 120 **********
*** Entering Scan Client Callback
*** angle_min: -180 max: 180 increment: 0.50
*** range[724] index - left 543 front 361 back 723 right 181
left: 0.290 cnt: 794
front: 0.582 cnt: 849
back: 0.227 cnt: 815
right: 0.494 cnt: 802

scan_msg.ranges[359]: 0.587 always 0? no
scan_msg.ranges[360]: 0.585 always 0? no
scan_msg.ranges[361]: 0.582 always 0? no
scan_msg.ranges[362]: 0.000 always 0? yes
scan_msg.ranges[363]: 0.579 always 0? no
************* DEBUG **********

After roughly two minutes of 8.8 scans per second - each scan supposedly containing 724 ranges in the full circle around the bot, the sensor gave non-zero readings in the four cardinal directions I have chosen about 800 times - or roughly 75% of the time.

BUT I unwisely chose (number of ranges over two) which itself was ignoring the “zero-based arrays”, and unlucky for me - the range on this particular sensor (I can’t speak for anyone else’s sensor) will always be zero…

Reality always strikes me late.

BUT now there is that list of parameters to consider - what happens if I change

frequency: 7.0     <-- to get full circle of readings by roughly 0.5 degree on the X4 LiDAR 

to

frequency: 9.0     <-- to get full circle of readings by roughly 0.6 degree on the X4 LiDAR

Voila! - non-zero readings nearing 100% of the time in all directions

************* DEBUG 120 **********
*** Entering Scan Client Callback
*** angle_min: -180 max: 180 increment: 0.64

*** range[561] index - left 420 front 279 back 560 right 140
left: 0.290 cnt: 1080
front: 0.584 cnt: 1080
back: 0.227 cnt: 1080
right: 0.493 cnt: 1079

scan_msg.ranges[277]: 0.590 always 0? no
scan_msg.ranges[278]: 0.587 always 0? no
scan_msg.ranges[279]: 0.584 always 0? no
scan_msg.ranges[280]: 0.583 always 0? no
scan_msg.ranges[281]: 0.580 always 0? no
************* DEBUG **********

$ ros2 topic hz /scan
average rate: 8.942

So in two minutes my scan_client received 1079 or 1080 non-zero values in two minutes at 8.9 hz:
1079 readings / 120 seconds / 8.9 scans/sec = approximately 100%

Thus for issue:

YDLidar X4 returning zero 25% of readings

Apply fix:

   cd ~/ros2ws/src/ydlidar_ros2_driver/params
   cp ydlidar.yaml ydlidar.yaml.v4
   wget https://raw.githubusercontent.com/slowrunner/ROS2-GoPiGo3/main/updates/ydlidar.yaml
2 Likes
2

I wonder if there is some kind of harmonic relationship between the granularity of the reading and the scanning frequency or rotational rate?

It almost seems like you were “tuned” to the zero-crossings and we’re missing the data by “just a smidge” each time.  That’s great if you’re firing a machine gun through the propeller arc, but stinks when you’re doing data aquisition.

Where did you get those initial parameters anyway?  We’re they “recommended” or did you roll dice for them? :wink:

Anyway, a great find!

Have you considered writing a book containing the distilled essence of your own experience?  I’d get one in a heartbeat!

2 Likes
3

No, ROS2 and Ubuntu, and OpenCV are moving targets. Out of date by the time it would be published.

2 Likes
4

Like everything else technology related?

I used to say to my wife that “falling behind” is inevitable and the best you can hope to do is regulate the speed which you fall behind.

2 Likes
5

I divined them from the documentation, the github examples, blogs on using the X4, and a review of the X4. It seems some people mistook seeing data for working correctly.

“Who needs stinkin’ test?”

2 Likes
6

This reminds me of something that happened a LONG time ago, (early November 1989).

The Atari 8-bit community had recently received a new double sided, double density floppy drive, the Atari 551.

The problem was that it would not boot SpartaDOS, (a very popular CP/M - MS-DOS like O/S for the 8-bit Atari systems, that was especially popular among developers, BBS’s, and advanced users), if the disk was formatted as a double density disk.

In other words, it wouldn’t boot SpartaDOS in double density mode and there was a wailing and gnashing of teeth in the user community about it.

I looked into the problem and developed a 3-byte fix.  (Make that read “kludge” - I didn’t feel like rewriting the entire boot loader from scratch.)

What I did was to change three bytes in the boot sector to allow additional time for the switchover to double density and I had originally hacked the boot sector with a hex editor - then programmed a quick-and-dirty utility in 6502 assembler to automate the task.

My friend Pat, (the president of our local Atari user group), was at a conference hosted by Atari in N.J. when the crowd essentially roasted the Atari rep about it.

He raised his hand and mentioned that a member of “our” user group had found a fix - and was IMMEDIATELY mobbed by people six-deep clamoring for it.  I get a frantic call from Pat begging me to release it and upload it to the BBS.

It took a week or so to do it, and when Pat jumped my bones about why it was taking so long, I told him in no uncertain terms that there was no way in hell I was releasing a kludge like that out into the wild w/o serious and significant testing as, improperly used, it could render a floppy inoperable.

It took a week or so, (I don’t remember exactly how long it took), before I let the fix loose - and not before I programmed in a number of safeguards to prevent ruining potentially valuable disks and software.

Testing? We don’t need no stinkin’ testing!

P.S.
If you look on line for SpartaDOS “Bootfix” and “Initfix” you might still find them.

2 Likes
7

Wow - this is fantastic. As always I’m impressed by your deep dives.
/K

2 Likes