Looking at this clears up one mystery I think. Note the min angle is -180, and max is 180. it’s not 0 to 360. That would explain why my zeroth distance value is straight behind me I think.
When the robot starts it has a message
[YDLidar]: [YDLIDAR INFO] Current Sampling Rate : 4K
[YDLidar]: [YDLIDAR INFO] Now YDLIDAR is scanning ......
But I think that’s coming from the firmware - when I check the rosparameters the values are the ones set in the launch file. Next thing to check is what happens if I fool with those. But they’re the ones that came from the book’s examples, so I assume they’re not entirely arbitrary.
I don’t know how to see all the values of a scan. I did an echo to the console and it prints the first 128 ranges. I am getting 105 to 109 non-zero ranges in the 128 values displayed for about 84% non-zero. Is that approximately what you are seeing - 84% non-zero out of 719 ranges?
The datasheet for my lidar says frequency 5K. Is yours 7K like your config param?
My time_increment in the header of each scan is 0.00200000000 or 0.000019999999 which corresponds to 5k.
The change you did in the code sets the scan_time to 1/freq or 1/7 in your launch config. When you look at the scan data does the scan_time value change or is it constant at 1/7?
My code is the unchanged version, and my scan_time value is steady at 0.0112199… = 1/8.9285 and varies sometimes slightly 0.0112400 = 1/8.896 is the value for the fourth of four scans I looked at.
My little script is on my GitHub test branch for now. I’ve attached it for convenience. laser_logger.py (633 Bytes)
Not that high - I just looked at my spreadsheet (thank god for the COUNTIF function). Looking at the first 50 rows I’m averaging only 366 values (range 357 - 371), so just a hair under 51%.
right now I’ve only captured the ranges. I’ll take a look at the headers to see.
I found a way to generate csv files. I start a bag play in one shell, and then a topic echo in another (must start the play before the echo)
For ROS2:
$ ros2 bag info rosbag2_2021_08_28-18_43_25/
Files: rosbag2_2021_08_28-18_43_25_0.db3
Bag size: 460.8 KiB
Storage id: sqlite3
Duration: 10.69s
Start: Aug 28 2021 18:43:27.995 (1630190607.995)
End: Aug 28 2021 18:43:38.64 (1630190618.64)
Messages: 91
Topic information: Topic: /scan | Type: sensor_msgs/msg/LaserScan | Count: 91 | Serialization Format: cdr
$ ros2 bag play rosbag2_2021_08_28-18_43_25/
[INFO] [1630252505.294131771] [rosbag2_storage]: Opened database 'rosbag2_2021_08_28-18_43_25//rosbag2_2021_08_28-18_43_25_0.db3' for READ_ONLY.
----- And in second shell ----
$ ros2 topic echo --csv --full-length /scan > scan.csv
That method strips off the field identifiers. To keep the field identifiers:
$ ros2 topic echo --full-length /scan > scan.txt
I’m wondering if the discrepancy between the scan time and the rate of spin is contributing to all of the null values? I haven’t had much free time so I haven’t been able to investigate as much as I’d like. But I’ll keep plugging along. I need to think through a structured plan to changing the parameters and seeing what happens.
Rerun your “rosrun tf2_tools view_frames.py” to be sure everything is linked up correct
Redo your “Rviz with AMCL Nav” to see if the localization is still twitchy
Restart your “preparation for nav tests” now that you have changed:
base_link xy is now at the center of rotation between the wheels
LIDAR is using the parameters listed by the manufacturer
ydlidar node is again the manufacturer’s version
URDF uses the same frame_id as the ydlidar node publishes in the joint definition (and link def)
I didn’t look very deep into the ydlidar pull-request - perhaps that is still needed. I just think it is good to let the node set those two values in the header for this round of testing, and then if the original AMCL Nav problem shows up, make the change.
Looking at the two, I see that the last ever commit to ydlidar_ros (the second one) was March 30, 2020, and the initial commit to ydlidar_ros_driver (the first link) was April 7, 2020 (with the last commit a week ago). Some of the commits at least mention the X4. So I think I’ll try the ydlidar_ros_driver.
As I look at this more I realized that the nominal sample rate is 5000 Hz, but mine reports 4K when it starts up. The scan frequency on Finmark is 12 (based on my /scan topic publication rate). This seems to be set by voltage, not the parameter setting (which is set at 7). 5K gives only 417 scans per revolution, 4K gives 333. So there can’t be a measurement at every half degree. Maybe that’s why there are so many zeros in every /scan message???
Doing the math, to get 720 scans per revolution, you’d want the lidar spinning at ~7Hz (so I assume that’s how the book files landed on 7??). But I don’t think I can actually adjust that (there is a comment in one of the commits I looked at to the effect that for the X4 this wasn’t actually controlled by the launch parameter). Ugh - more to look into. And if the navigation stack is just ignoring the zeroes anyway, perhaps it doesn’t matter.
Got the ydlidar_ros_driver compiled (had to first download and install the SDK as the GitHub page suggested I might. Didn’t actually have to change my URDF - I just used base_scan instead of laser_frame as the frame_id in the launch file. Figured I’d try that first, and everything worked. Unfortunately there didn’t seem to be any improvement in the performance when I did the 360 rotation test. I think I’ll just stick with the driver I’ve been using, although I did update the baud rate and a couple of other parameter values based on what they had on the ydlidar git hub luanch file.
Next steps for me are to go back to that trouble-shooting guide and work through some of the other suggestions. Also want to get the IMU running to see if that helps at all.
/K
Addendum:
Was curious about what @cyclicalobsessive had pointed out, that I had made changes to my ydlidar driver
I looked at the new driver I had compiled - it doesn’t have those changes. It has what the original driver had before I changed it:
