An autonomous ground robot repeatedly answers four questions: where am I, what is around me, which route can I take, and what motion should I command now? A useful navigation test checks those answers separately. This makes a stopped or wandering robot much easier to diagnose.
This guide is for learners who already understand basic sensors and motor control. The examples use an indoor mobile robot and concepts from Nav2, the ROS 2 navigation framework. They explain system behavior; they are not a ready-to-run vehicle controller. For a first physical project, start with the bounded wheeled-robot build.
Follow the navigation loop
- Estimate a pose. Combine observations into position and orientation, together with an indication of uncertainty. A destination expressed on a map is useful only when the robot can relate itself to that map.
- Represent the surroundings. Distinguish known free space, obstacles, unknown areas and any route restrictions. A floor plan provides prior information; live sensing captures changes.
- Plan a feasible path. Choose a route from the present pose to the goal that suits the robot's shape and motion constraints.
- Follow and reassess. Turn the path into motion commands, observe what actually happened, and update the next decision. A blocked route can lead to replanning, a bounded wait or a request for help.
Nav2's navigation-server documentation gives planners and controllers different jobs: a planner produces a path, while a controller computes the motion needed to follow it using local information. Recovery behavior is another explicit part of the system. That division helps you ask whether a failure began before a path existed, while it was being followed, or during recovery.
Global and local describe scope, not intelligence. A globally reasonable route may temporarily be blocked by a cart. A locally clear direction may lead away from the destination. The system must reconcile both views over time.
Keep position, coordinate frames and maps consistent
Wheel motion can estimate how far the chassis has moved, but slip and small errors accumulate. A camera, lidar, satellite positioning system or other external reference can help anchor that estimate. The suitable combination depends on the environment: a satellite fix alone supplies little information about an indoor doorway or a nearby obstacle.
Nav2's state-estimation explanation separates a smooth local odometry relationship from a global positioning correction. Its typical transform chain is map → odom → base_link → sensor. Each observation must be interpreted in the right frame and at the right time. A sensor mounted facing left but modeled facing forward can produce a convincing-looking, misplaced obstacle.
A costmap assigns values to regions the navigation algorithms consider. Nav2 documents a grid containing free, occupied, unknown and inflated-cost cells, with layers combining information from sensors and other sources. Additional annotations can express keep-out areas or speed restrictions. See its environmental-representation guide.
The robot's physical footprint matters throughout a turn. Draw the chassis, protruding sensors and carried load from above. A path for the center point can still sweep a corner of the load into a wall. Unknown space also deserves an explicit policy; decide what evidence is required before treating it as traversable.
Work through one corridor route
Illustrative geometry, not a clearance specification
Imagine a robot 0.50 m wide entering a straight 1.00 m doorway while centered and square to the opening. The nominal static clearance on each side is (1.00 − 0.50) ÷ 2 = 0.25 m. A 0.10 m lateral position error leaves 0.15 m on one side. A carried tray, rotation, door movement and tracking error would change the usable space. The arithmetic is a reason to inspect uncertainty and swept geometry, not permission to pass through.
Start with a pose near the corridor entrance. A plan passes through the doorway to a marked destination. Now a box appears in the doorway. First inspect whether the live sensor detects the box, then whether the observation reaches the local representation in the correct location. Next inspect the resulting path and motion command. If the box is absent from the map, changing the controller's steering settings addresses the wrong stage.
Once the box is removed, check how the system establishes that the space is clear. Reusing old free-space information or retaining an old obstacle indefinitely can both cause trouble. Record timestamps and the exact configuration so a later replay can explain the transition.
Diagnose the first inconsistent observation
| Observation | Inspect next | Useful evidence |
|---|---|---|
| Robot pose jumps on the map | Localization, frame transforms and timestamps | Pose estimate, uncertainty and observations around the jump |
| Obstacle appears in the wrong place | Sensor mounting transform and data age | Raw measurement overlaid on known geometry |
| No path is produced | Goal location, footprint, restrictions and connectivity | Global representation and planner result |
| Path exists; robot oscillates | Local space, motion limits and controller output | Commanded versus observed motion through time |
| Robot stalls despite a command | Drive interface, power, traction and enabled state | Command, wheel feedback and fault state |
| Repeated recovery never helps | Underlying fault and recovery boundary | Attempt count, cause and operator escalation |
Capture evidence before changing parameters. Change one relevant setting, state the expected effect, and repeat the same scenario. Keep failures in the record; a run that needed intervention has a different outcome from an autonomous completion.
Make a small test informative
Use simulation or a supervised, restricted test area appropriate to the equipment, with an established stop procedure. Begin with a clear route, then a single controlled change such as a stationary obstacle. Test final orientation as well as arrival position when the task includes docking or presenting a load.
Define success before running: accepted goal error, allowed interventions, maximum duration and required behavior when the route is unavailable. Keep the robot, load, map, software version and start pose fixed when comparing configurations. Record completion time, endpoint error and intervention reason separately.
In an invented ten-run example, eight runs meet every criterion and two require help. Autonomous completion is 8 ÷ 10 = 80% for that small test set. Averaging only the eight successful times tells you their speed, while reporting all ten outcomes tells you reliability within the tested conditions. Neither establishes performance in an untested building.
Use the editable navigation test and diagnosis record to preserve the scenario, evidence and next check. For operational coverage and human response, continue with the property-robot pilot guide.
Why this page began with a desert vehicle
Yenra's 2005 article covered CIMAR's NaviGATOR during DARPA qualification. The enduring subject is the combination of positioning and motion decisions. DARPA's official Grand Challenge history records a 132-mile final course on October 8, 2005, completed by five teams. A successful desert demonstration established performance on that event's course; today's indoor example requires its own evidence.