Robust Odometry and Fully Autonomous Driving Robot | ATCrawler x FAST-LIO x Navigation2 

Hope it will be useful information 😁

@@stepbystep-robotics6881 it definitely is 👍👍

Thank you to PCBWay for the nice 3D printed part. It’s really neat and fast delivery!

I have seen it couple times, but after restart it and place on proper vehicle, it works most of the time.

I am glad it useful somehow 😊

The laserscan is extract from a package called poiontcloud_to_laserscan package. The term “relay” on my package is just to repeat the Odometry topic from FastLio but replace the frame_id to “odom” and also publish the odom to base_link TF.

Min. FOV angle is -2degree. The lidar is placed in flat, and yes with this min FOV angle, meaning it will see ground with farther away from the robot.

if that pointcloud from depth camera is fast enough, I think it might work. And you still need IMU too.

Do you want to use RGBD point cloud instead of lidar? But the lidar has a large field of view of 360 degrees versus 90 for the camera, and most importantly, its accuracy is the same at 40 meters or 10 centimeters and is approximately equal to +/- 2 centimeters, the accuracy of the RGBD camera decreases with distance and is comparable with the lidar up to about 5 meters, which quite small, also computer vision algorithms like SGM in realsense cameras allow more errors in image triangulation than lidar physically measures the time of flight of light?

@@sencis9367 That what I already had. Also It's depth only. So the visual odometry was not available here. I have a plan to mount the camera on the front and back of the robot, as I have two of then. And then write a CPP ros2 node to combine the Point cloud into a single cloud message.

@TiNredstoner As far as I understand, the key condition for the operation of lidar odometry is the correlation of the visible lidar pointcloud and points on the map. Those in contrast to visual odometry, which is oriented by the ORB, KLT, SURF descriptors, by the coincidence of their PIDs, the lidar is oriented solely by the shape of objects around it, and for greater matching of the shapes of objects visible by the lidar, measurement accuracy plays a key role, and range affects reliability in rarefied environments and in open space, it turns out that theoretically you can count on working inside small rooms with the camera's IR projector turned on in case there are no visual signs for triangulation , also the camera will generate a very dense cloud in comparison with the lidar, one camera can create up to 1,000,000 points every 33.3 milliseconds in 1280x720 resolution & 30 fps, which will require a lot of computing power.

@@sencis9367 I have tested the Asus Xtion (640x480 depth resolution) with various Laser Odometry SLAM but not all of them. I ported the SSL_SLAM to ros2 and this seems to give the best result. Still, the problem remains when the robot rotates. The estimated odometry just fly off as the robot start to rotate. My guess was that the narrow horizontal FoV compared to 3D LiDAR, But something like Livox Horizon, MID-40 seems to works despite the similar narrow FoV. I yet to test it with KISS-ICP and another IMU coupled SLAM.

Max speed with 18V battery is 1.3m/s It’s DC brushed motors, so if higher voltage it could go faster. The AT Motor Driver that I am using could go up to 24V or 6 cells battery. I have trie run that with full speed outdoor, the Odometry from FAST-LIO still pretty reliable :) they really made a good work.

@@stepbystep-robotics6881 Thank you for your answer. In addition to the robot depending on the battery voltage, does it also depend on the ROS processing speed? If I'm not mistaken, robots developed on ROS only have a maximum speed of about 3m/s?

@@mr2tot I don’t think any ROS robot will be limited as 3m/s because robot’s physical speed doesn’t relate to ROS processing speed. The vehicle physical speed should be depending on ESC or motor driver. From my point of view, I don’t use ROS for all of control level, sometime we need realtime data in low level then better to use RTOS. ROS is better from middle to higher level software I feel.

@stepbystep-robotics6881 Am I understanding this correctly, the lidar is highly susceptible to the rolling shutter effect due to the slow mechanical sweep (rotation mirror livox mid 360 only 10Hz), which may require an accurate imu sensor or wheel odometry for predict the displacement of the point cloud on the moving platform thus obtain an accurate lidar odometry xyz position and quat position? Perhaps in this case, wheel odometry can help determine the exact position of the robot on the move. Have you tried solutions like LIW-OAM to obtain a more accurate position?

Fast-Lio only works with 3D lidar. But Nav2 just 2D laserscan is enough.

I believe the wire mesh could be detected by the MID-360. It could detect some of power line, so in case of planar fence, it might be no problem. The lidar itself is not too expensive, you better to give a try on it. 🙂