A robot has a detailed map of a room. Someone moves a trolley into the aisle. The map can still be accurate about the walls while being wrong about the next few metres of travel.
A useful navigation system must distinguish where the robot is, what the environment usually looks like and what its sensors are seeing now. Nav2, an open-source robotics navigation system, makes those responsibilities easier to understand. Its documentation describes software capabilities, not proof that any particular robot can operate safely in a workplace.
Three questions, not one map
Localization estimates the robot's position and orientation relative to a map. Obstacle representation describes the space that navigation should avoid. Planning then uses that representation to choose a route. A map image alone does not show whether those jobs are working together.
Nav2's mapping guide describes a layered costmap: a grid of travel costs. A static layer supplies mapped surroundings, obstacle layers incorporate sensor observations, and inflation adds costs around obstacles to account for clearance and robot geometry. The guide separates a global costmap for longer-range planning from a local costmap for near-term motion.1
Think of the saved layout as context, not a live clearance certificate. In the trolley example, the important question is whether current observations reach the navigation system in time, not whether the old drawing still looks neat.
What a sensor sees is not automatically what a planner gets
Nav2's obstacle layer accepts laser scans or point-cloud data. Its configuration includes observation sources, height and range limits, and separate controls for marking obstacles and clearing previously marked space. It also defines how observations combine with the other costmap layers.2
That distinction matters when interpreting a demonstration. An object appearing in a camera view does not by itself establish that the navigation costmap contains it. A sensor reading still has to pass through the configured representation. This is an engineering inference from the documented pipeline, not a measured failure rate.
For a supplier review, ask to see the raw observations and the resulting costmap together. Include a description of the sensor arrangement, accepted obstacle heights and ranges, and how removed objects are cleared. A colourful map screenshot without those conditions is difficult to interpret.
A collision monitor is another layer, not a certification
Nav2's Collision Monitor can consume sensor data outside the normal costmap and trajectory-planning path. Depending on its configured zones and behaviour, it can stop or limit motion when observations indicate a nearby obstacle. Its documentation also describes a timeout response when fresh sensor data stops arriving.3
The same documentation explicitly says the node does not provide hard real-time safety certification. A successful software stop demonstration must not be presented as certification of the complete robot. Suitable protective measures and a qualified, application-specific safety assessment remain separate requirements.
For a purchasing decision, keep the claims separate: what the software is designed to do, what this particular machine has demonstrably done, and what safety evidence applies to the complete installation. None can be inferred solely from a navigation animation.
Ask for a changed-room demonstration
Our recommendation is to request an evaluation plan that changes the environment, rather than replaying one tidy route. In simulation first, compare a clear aisle, a newly introduced obstruction and the same obstruction removed. Separately examine loss of fresh sensor data and uncertainty in the robot's location. Physical trials should be designed and supervised by qualified personnel with appropriate safeguards; do not place people in a robot's path as a test.
Keep the map version, software version, configuration, sensor timestamps, commanded motion and human interventions with the recording. Ask what counts as a successful response before running the trial. These are proposed evidence requirements, not results from a BIGFOOT experiment.
The practical conclusion is simple: judge navigation by how it handles a changed space, not just how well it draws a familiar one. A good map is valuable. It is not the whole navigation system.
References
- Open Navigation / Nav2. Mapping and Localization. Jazzy documentation, including Costmap 2D. Publication and revision dates not stated; accessed October 19, 2026. Developer documentation, not an independent performance evaluation.
- Open Navigation / Nav2. Obstacle Layer Parameters. Jazzy documentation. Publication and revision dates not stated; accessed October 19, 2026. Configuration capabilities do not establish real-world detection performance.
- Open Navigation / Nav2. Collision Monitor Node. Jazzy documentation, introduction, features and source-timeout description. Publication and revision dates not stated; accessed October 19, 2026. The documented software is not hard real-time safety-certified.