My Raspberry Pi 5 powered TurtleBot4 (clone) TB5-WaLI has been “alive” for 11108 hours since January 9, 2025.
It has undocked, navigated around my home 6226 meters (almost 4 miles), and redocked by itself 2137 times (well I did have to help it 5 times after safety shutdowns).
It has built a good map of the house, and with LIDAR seems to never lose localization anywhere in the map.
I have found a set of Turtlebot4_navigation parameters that will give 90% reliable navigation to 10 carefully chose goals in my home, but don’t try to check the battery_state from the command line, or write a node that subscribes to BT Log Events to collect statistics, and don’t expect reliable navigation in complex, tight areas of the house (even when it appears there is a very clear path available).
My “Raspberry Pi home/educational robot” philosophy has always been, “I’m not in a hurry, so my robot should be able to do anything (that fits in 8GB of memory), albeit the bot may need to go very slow or think for a while before acting or answering.”
My hope for ROS TurtleBot4_navigation has been along this same line - WaLI may need to go slow, or even stop to rethink a plan, but nothing short of a localization failure should prevent him from navigating.
I understand there are several path planners, several plan critics, and several recovery planners, each with a bevy of parameters to tweak, but for the life of me I cannot find a set that provide robust, reliable navigation in my home.
From the start my hope was that there are some nav2 parameters that would make nav2 robust and reliable.
Many times navigation decides to fail because WaLI happens to be in a tight spot, and it seems like it doesn’t wait for recoveries. I see “spin failed” but the bot never rotated. Or “Spin 1.57” which is way too much more than needed.
A simple DDS discovery server query can cause turtlebot_navigation to fail. Shouldn’t such “resource starvation” events be possible to handle by stopping the bot, or pausing the planning?
Introducing anything external that monitors the navigation BT Events, or my node collecting statistics during the navigation should not kill everything. If the control loops are only able to run at 10Hz, can’t all the nodes slow their expectations, can’t the bot crawl slowly enough or stop while it is thinking?
For all the flexibility of Nav2 and the infinite parameterization, suite of planners and critics, and adaptable sensor inputs, TurtleBot4_navigation just seems to be a “house of cards” for me.
ROS 2 Jazzy, Turtlebot_navigation (Derivative of Nav2), Raspberry Pi 5 8GB, Ubuntu 24.04
(No temp or voltage throttling ever, Idle CPU 35%, navigating CPU 75%)