TurtleBot4 Navigation Tuning Result

Projects
, ,
1

I have spent the month of March tuning and testing, (and chasing rabbits down deeper and deeper holes dug by Google Gemini) to optimize Nav2 navigation robustness and reliability for my TB5-WaLI (TurtleBot4 clone on an 8GB Raspberry Pi5, using odometry and LIDAR)

This is TB5-WaLI (TurtleBot4 on Raspberry Pi 5 - Wallfollower Looking for Intelligence)

2026-03-08_TB5-WaLI
2026-03-08_TB5-WaLI1920×2560 382 KB

WaLI runs Jazzy over Ubuntu 24.04 Server with FastDDS, a Discovery Server, the wali_node that keeps him alive 24/7/365, turtlebot4_navigation, and a few convenience nodes.

At the moment:
********** TB5-WaLI MONITOR NODE ******************************

Saturday 03/28/26

15:48:35 up 3 hours, 48 minutes
temp=66.4’C frequency(0)=2000017152 throttled=0x0
Mem: 7.8Gi total, 1.4Gi used, 5.7Gi free
1m load: 4.37 109.1% demand on RPi 5’s four cores

Total CPU Usage: 38.5%

-------------------------------------------------------

Voltage: 14.36 Current: -0.96 Watts: -13.85
Battery: 0.19 Docked: False

*** TB5-WaLI TOTAL LIFE STATISTICS ***

Total Awake: 10434.9 hrs
Total Naps: 0 hrs
Total Life: 10434.9 hrs (since Jan 09, 2025)
“Noticed Dockings”: 29
Playtimes (Undocked-Docked): 2043
Total Dockings: 2072
Average playtime (last five) 1.5 hrs
Average docked time (last two) .9 hrs
Sessions (boot): 84
Average Session: 124.2 hrs
Safety Shutdowns: 4
Total Travel: 2730.4 meters 8958.0 feet

Last Docking: 2026-03-28 09:44|wali_node.py| ** WaLI dock goal result - Docking: success at battery 20% after 1.7 hrs playtime **
Last Recharge: 2026-03-28 14:09|wali_node.py| ** WaLI Undocking: success at battery 100%, docked for 0.9 hrs **
15:49:41 up 3:49, 5 users, load average: 5.11, 4.64, 4.37

Environment

This is the environment in which I have 6 designated goal positions, used to test each parameter change.

WaLI_Environment_rViz2
WaLI_Environment_rViz21920×1347 452 KB

Nav2 investigation results:

  • Using 2D_obstacle_layer showed no visible CPU usage reduction, but navigation reliability was decreased

  • Increasing z_voxels to 20 and z_resolution to 0.1 (2 meters), and lowering max_obstacle_height to 0.40 appears to have eliminated “sensor origin out of map bounds” warnings

  • Increasing inflation_radius from 0.35 to 1.25 combined with lowering the cost_scaling_factor from 4.0 to 1.25 causes nav2 to plan farther from walls and obstacles which lowers the incidence of “side object distractions” during path following.

  • Navigation may still fail when passing through narrow areas with high number of “side object distractions” (clear path on global costmap, but no clear path between on the local costmap). When the goal fails in these locations, issuing the goal again seems to succeed.

  • Laundry room destination was adjusted to not be as deep in the room avoiding the “end of the canyon”

  • Dining room destination was adjusted to not be as deep in the room to avoid traveling with the mirror wall on the right side of WaLI. Navigation was reaching the goal, but the mirror wall prevented final pose planning.

  • Navigation failures mid-travel when checking the /battery_state from the command-line are attributed to a known DDS CPU usage spike reported in CPU spikes of existing nodes when starting new node · Issue #741 · ros2/rmw_fastrtps · GitHub

  • Lowering particles and beams in localization did not visibly reduce CPU usage, but did reduce navigation reliability.

And do not trust Google Gemini - especially do not ask Gemini to fix an error that resulted from the prior Gemini suggestion! You will chase rabbits down holes each one deeper than the prior. Do not believe Gemini if it says this will reduce CPU load. Do not believe Gemini if it says it read a file you gave it a URL to review. (It will confidently hallucinate about what it read at the URL it didn’t visit, and apologize with “You are right. I am wrong. This is embarrassing. I will try to do better.” - but it won’t.)