Navigation Stack
A navigation stack bundles localization, mapping, path planning and motion control into one software framework (e.g. ROS move_base or Nav2); upper layers just send a target coordinate and the stack navigates automatically.
What problem it solves
The navigation stack is the full pipeline of localization + planning + control. Developers don't assemble SLAM, avoidance and PID themselves; they send a goal pose through a standard interface.
Tbot exposes standard ROS/Nav2 interfaces: upper-layer business (fleet scheduling, elevator, door) connects once, and changing chassis model needs no framework rewrite.
How to read the key specs
- Framework version: move_base (ROS1) vs Nav2 (ROS2) — match your team's stack.
- Interface standard: standard messages like nav_msgs/Odometry and MoveBaseAction.
- Replaceability: can the localizer, planner and controller be swapped independently?
- Compute footprint: CPU/memory the stack uses on the on-board PC.
Common myths
Myth: the stack is a ready-made navigation solution. It is a framework; results depend on tuning and sensors.
Myth: changing chassis means rewriting software. With an open ROS interface, upper-layer business migrates smoothly.
Myth: Nav2 is always better than move_base. It depends on the team's stack and ecosystem maturity.
Related models
The whole Tbot lineup exposes ROS and supports move_base/Nav2. See the Tbot platform and full spec table.
Related articles
Need a chassis with an open ROS interface?
Tell us your dev scenario and secondary-development needs; our pre-sales team replies within one business day.
Get a Quote