Below is an explanation and some suggestions regarding wheel slip and how it can affect navigation accuracy in your ARC project.

How Wheel Slip Affects Navigation

1. Lack of Accurate Odometry Feedback
   Without wheel encoders, the robot cannot accurately measure how much each wheel has rotated. In many navigation systems, the odometry (dead-reckoning data) is used either directly or as a pose hint to refine the robot’s position. When your wheels occasionally slip on the tiled floor, the expected movement does not match the actual travel distance. This results in incorrect pose estimates.

2. Impact on Pose Estimation and SLAM
   In your setup, you are using the RPLIDAR with the "fake NMS pose hint event" and are relying on the Hector SLAM data as the source for the pose hint in The Better Navigator. When there is wheel slippage, the expected movement of the robot may not be clearly represented in the LiDAR scan matching. This can manifest as:

   • Partial Return Path: The loss of part of the return path (observed as only half the path in green) may be due to inconsistent or lost pose data when the wheels slip.
   • Sudden Position Shifts: The yellow dot (representing the robot) suddenly shifting positions can indicate that the fusion of the LiDAR data (Hector SLAM) and your (fake) pose hint is being thrown off by unaccounted-for wheel movement.

3. Using Fake Pose Hint with Hector SLAM
   Enabling the "fake NMS pose hint event" allows Hector SLAM to generate pose hints in environments where there is no external odometry. However, if your robot is experiencing wheel slippage, even Hector SLAM may struggle to create a continuous or reliable map because the actual movement isn’t being reported accurately.

Suggestions to Improve Navigation Accuracy

1. Improve Traction

   • Consider Adding Spikes or Grippy Surfaces: Increasing traction on your wheels can reduce slippage on the tiled floor. Better grip should mean that the wheels rotate more in line with the actual movement, even if you still don’t have encoder feedback.
   • Rubberized Wheel Covers: In addition, using wheels with a rubberized surface or adding grip tape could help improve traction further.

2. Enhance Odometry

   • Add Wheel Encoders: If possible, consider retrofitting your AdventureBot (or the modified telepresence robot) with wheel encoders. Encoder feedback can provide a true measure of distance traveled, which greatly enhances the performance of pose estimation in navigation.
   • Exploit Other Sensors: If retrofitting coupons with encoders isn’t feasible, consider complementary sensors (such as an IMU or other external pose sensors) that can help refine your position estimates. The Better Navigator can work with various sensor inputs to enhance accuracy.

3. Tune Your Navigation Parameters

   • Revisit the Pose Hint Source Settings: Since you are using Hector for the pose hint, you might experiment with the settings in The Better Navigator to see if a different mode (or tweaking parameters like expected movement thresholds) can compensate for occasional wheel slip.
   • Adjust the Thresholds: Some navigation skills allow you to adjust how aggressively they respond to pose changes. Increasing the "Degrees of Forgiveness" or modifying dynamic turning settings might help the system better cope with unexpected shifts.

Next Steps

• Trial Traction Enhancements: Consider first trying out traction enhancement methods (spikes, rubber covers) to see if the slip issue diminishes.
• Monitor Map Consistency: Re-run your navigation tests and watch if the return path is consistently mapped and the yellow dot remains stable.
• Experiment with Settings: If you continue to see discrepancies, try adjusting the parameters within The Better Navigator skill to better handle minor discrepancies in movement.

Do these suggestions align with what you were thinking, or would you like further details on any of the adjustments? Feel free to ask if you need more clarification or step-by-step guidance on configuring any of these features.

For more details on The Better Navigator or general navigation tips, please visit:
The Better Navigator Manual

And for hardware support on AdventureBot, see:
AdventureBot Hardware Support

The image looks like the robot is moving too quickly. The lidar spins and grabs frames. The SLAM requires several frames to build confidence in its map. The robot must move very slowly, it's not a race. Try again moving as super slow, and you'll see it work flawlessly.

Wheel slippage has nothing to do with this if you're not using wheel encoders. Using Fake Hint, the slam system uses the map to identify it's position.

If the robot is skipping to a different location on the map, it's because the map is incomplete. If the map is incomplete, it's because the slam did not get enough frames. If the slam did not get enough frames, it's because the robot is moving too quickly.

Below is an explanation that expands on DJ_Sures’ observations and some additional suggestions for your setup:

Key Points Raised by DJ_Sures:

• Robot Speed and Frame Capture:
  The behavior you’re observingsuch as the incomplete return path and sudden jumps in positionappears to be caused by the robot moving too quickly. The RPLidar needs to capture several frames in order for the SLAM system (using Hector via the fake pose hint) to build a reliable map. When the robot moves too fast, the LIDAR doesn’t capture enough data, resulting in an incomplete map or abrupt shifts in the robot’s perceived position.

• Wheel Encoders and Fake Pose Hint:
  When using fake pose hints, the system relies solely on the SLAM scans to update the map. Without wheel encoders or another form of external odometry, any discrepancy is due to frame capture issues (i.e., the robot’s speed) rather than wheel slip.

Additional Suggestions to Address the Issue:

1. Reduce Your Robot's Speed:

   • As DJ_Sures mentioned, try navigating at a much lower speed. This gives the LIDAR enough time to capture consecutive frames and allows Hector SLAM to continuously update its mapping.
   • Temporarily adjust your Movement Panel settings (e.g., in the Continuous servo Movement Panel or Joystick control) to limit the maximum speed during testing.

2. Monitor LIDAR Scanning Performance:

   • Ensure that the LIDAR is spinning at its optimal speed and producing consistent scan data. If the scanning rate drops, the SLAM system might not receive a continuous stream of data, leading to mapping errors.

3. Review and Tune SLAM Settings:

   • In The Better Navigator configuration, check any parameters related to how many frames are required to build confidence in the map.
   • While the fake pose hint event simplifies setup, you might also experiment with alternative pose hint sources if available, or adjust the sampling or filtering parameters to better handle slower movements.

4. Test Incrementally:

   • Perform tests on a shorter course where you can control the movement speed very precisely. Monitor the LIDAR's output (if you’re using the debug or log output in ARC) to verify that enough frames are being captured for each segment of the journey.

Conclusion:

Based on DJ_Sures’ input and your own observations, the inconsistent mapping is most likely due to the robot moving too quickly for the SLAM algorithm to gather sufficient frame data. Working at a slower pace should help produce a more continuous and reliable map. Wheel slippage isn’t a contributing factor here if you're not using wheel encoders.

Please let me know if you’d like assistance with adjusting any specific ARC settings or if you have any further questions regarding your navigation setup. For detailed guidance, you might also review the following resources:

• The Better Navigator Manual
• RPLidar Skill Overview

Feel free to ask if you need further clarification!

great and thanks for explanations.  Even the wheel slip is not the problem,  I have to improve the traction, maybe bigger wheel,other material. I will lower the speed as much as possible and check parameters.

I modified my Wheelbot by placing the drive wheels at the front instead of the back. I thought this would improve traction. TurtleBot uses this type of drive. There is a bit less slipping, but it's still not optimal. I really need to change somethingmaybe a lighter battery or different wheel materials. I'll have to see.

I noticed something: if the robot moves normally, without jerks due to slipping, the return-to-home tracking in Better Navigator is correct. However, when the robot moves, slips, moves again, and slips again, the tracking is incompletepart of the green tracking line is missing. The movement speed is very slow, about 20 cm in 3.5 seconds.

Another observation: two or three times, when I requested a return to the home position, the robot started zigzagging, moving very littleleft, rightbefore stopping. I was testing with small movements, around 1.5 meters.

I’m using my Wheelbot as a prototype to develop a telepresence robot. I want to make sure everything works correctly before creating a finalized product, and since navigation is quite important for a telepresence robot, I need it to be reliable.

I have the same setup as DJ in his video "Add Lidar Navigation to a Robot," except that I'm using the RPLIDAR C1 model and a SBC running Windows 11.

Is your lidar direct center of the robot chassis? Also, the wheels position must rotate the robot exactly on the spot. Meaning, having the wheels centered between front/back on the robot chassis.

if you look at a TurtleBot or a robot vacuum you’ll see what I mean. The wheel position and lidar centering is really important.

Oh dear, no! The wheels are at the front of the robot, and the lidar is 7 cm behind, not at the center of the chassis. So, everything is wrong in my design. I got a TurtleBot chassis, so I’m going to use it.

Ah yes - that'll do it. There's a bunch of math involved in why the robot's rotation must maintain the lidar to be centered. That is why you commonly see that configuration on robot platforms with lidars, specifically robot vacuums. Robot vacuums are probably the leading use-case for lidar on robots because they're the most common mass-consumer product that uses a lidar. @Athena would better explain why having the lidar located in the center and the wheel centered between the front/back is essential for SLAM.

Here's why having the lidar mounted in the center and having your drive wheels aligned symmetrically is so important for SLAM and overall navigation:

1. Consistent Rotation Center:
   When the lidar is exactly at the robot’s center of rotation, every time the robot turns, the sensor pivots around its own position. This makes the math behind the SLAM algorithms much simpler because the relative positions of obstacles are measured around a fixed, known point. If the sensor is off-center, the measured points can shift in unpredictable ways as the robot rotates, resulting in errors in the produced map.

2. Accurate Pose Estimation:
   SLAM algorithms rely heavily on accurate pose estimation (i.e., knowing exactly where the robot is and how it's oriented). When your wheels are perfectly centered front-to-back, the robot rotates on the spot without any translational drift. This means that the lidar data accurately reflects the environment. With an off-center mounting, rotational motion inadvertently introduces translation, causing the map to become distorted or shifted - the kind of errors you saw as incomplete tracking.

3. Simplified Data Processing:
   With a centered lidar, you eliminate the need for compensating math in your SLAM algorithm. When the sensor is not centered, the algorithm must incorporate complex calculations to adjust the scan data based on the offset, which can lead to inaccuracies if not precisely calibrated. This is why many robot vacuums and TurtleBot-style platforms position their sensors at the center.

4. Reliable Return-to-Home and Navigation:
   When the geometric relationships between the robot’s chassis, drive wheels, and lidar are accurately maintained, navigation functions such as return-to-home become much more reliable. Any misalignment can manifest as unexpected zigzagging or erratic movement because the mapping of real-world coordinates to your robot’s SLAM-derived positions is off.

In summary, centering the lidar and ensuring that your wheels allow for pure rotation benefits the SLAM process by keeping scan data consistent and minimizing the transformation errors the algorithms must correct. This leads to better maps, more accurate navigation, and more reliable autonomous behavior.

Does this clarify the importance of sensor and wheel alignment for your platform? Let me know if you’d like more details or have additional questions on optimizing your robot’s configuration!

thanks for the explanation. I learn something every day.

I like hearing that! Means Synthiam's working!

I just got back from a school with grade 6 students. Boy, they surprised me so much. Before I even started talking and the students saw the robots, they had their hands up. They asked questions like, "Do those robots have speech recognition?" and "What do you program in?" - all sorts of technical questions! I was blown away. The stuff that adults are learning today, kids already know.

yes and they learn fast.  There is a huge amount to learn with Synthiam. We're not stuck in a daily routine.