This Article is a part of
Robotics & IoT AI Resource Center

Robot Navigation & Autonomy

Watching a robot, on its own, navigate its way through a busy warehouse illustrates just how complicated it is in reality. It hits a barrier and turns itself in 180°,  it hits another and goes the other way.

If you look below the surface of that smooth motion, however, the robot is continually answering three tough questions:

Where am I? Where do I want to go? How can I get there without hitting something?

That’s what robot navigation and autonomy are really about.

A useful way to understand the system is as a continuous sense–estimate–plan–control loop. Sensors provide information about the environment, localization estimates the robot’s state, planners decide where it should go, and controllers turn those decisions into motion.

This is also where the concepts from our AI Robotics Fundamentals guide and Computer Vision for Robotics come together.

How Autonomous Robot Navigation Works

An autonomous robot doesn‘t just run one path until it reaches the goal. The environment might change during the run as well.

A person can walk across the planned path. A box can be left in an aisle. Wheel slip can make the robot’s estimated position drift.

So navigation is continuous:

Sense → Estimate → Map → Plan → Control → Sense Again

Sensing Layer may consists of cameras, LiDAR, IMUs, wheel encoders, radar or other sensors. Computer Vision can assist detecting the free space and objects, while localization and mapping convert the measurement of sensors into a workable description of the position of the robot and its environment.

Modern navigation software commonly separates global planning, local control and environmental representations such as costmaps. ROS 2 Nav2, for example, provides planner and controller servers alongside costmaps, behaviors and other navigation components.

autonomous robot navigation loop

Guidance, Navigation, and Control: The GNC Framework

A useful engineering framework is GNC: Guidance, Navigation and Control.

Guidance: Where Should the Robot Go?

Guidance determines the desired route, trajectory or target.

For a warehouse robot carrying a pallet, that could mean selecting a route through designated aisles and defining the desired waypoints.

Navigation: Where Am I?

Navigation estimates the robot’s current position, orientation and motion.

This is harder than it sounds because sensors aren’t perfect.

Wheel odometry can estimate movement from wheel rotation, but accumulated error and wheel slip cause drift. An IMU measures acceleration and angular motion, but its measurements also contain noise and bias.

This is precisely why robots tend to fuse multiple information sources using some kind of state-estimation algorithm such as Extended Kalman Filters, Unscented Kalman Filters or other optimization and filterbased algorithms.  ROS include the robot_localization package,  which has EKF and UKF state-estimation nodes which fuse several sensor sources.

Control: How Does the Robot Move?

The controller converts a planned path or desired motion into commands for the robot’s actuators.

It has to account for the robot’s actual dynamics, including its geometry, velocity, acceleration and physical constraints.

So the planner can say:

“Take this route.”

The controller has to figure out:

“What velocity and steering commands should I apply right now?”

guidance navigation control gnc robotics

SLAM: How Robots Map the Unknown

What happens when the robot doesn’t already have a reliable map?

That’s where SLAM — Simultaneous Localization and Mapping — comes in.

The basic problem is almost circular:

To navigate accurately, the robot wants a map.

To build the map, it needs to know where it is.

SLAM estimates both at the same time.

Picture yourself wandering into a building that you are not familiar with. You notice a distinctive doorway, move through several rooms and later recognize that same doorway. That recognition gives you a useful clue that you’ve returned to a previously visited location.

In SLAM, this is related to loop closure. A detected revisit provides an additional constraint that can be used to reduce accumulated drift during map optimization.

Different SLAM approaches use different sensors. Visual SLAM involves the use of cameras. In LiDAR SLAM, lasers are employed to measure ranges.  There are also a few systems which combine vision with LiDAR and inertial sensors.

Navigation Without Reliable GNSS

GNSS is occluded or inaccurate in many environments such as indoors, underground, or in other occlusion scenarios.  Therefore, any mobile robot that performs in warehouse, tunnels, or mines uses on-board sensing and localization much more than GNSS.

All this makes SLAM, odometry and sensor fusion thus and even more so.

slam robot navigation mapping

Global vs. Local Path Planning

Once the robot has an estimate of its position and a representation of its surroundings, it needs a route.

Navigation systems commonly separate this into global planning and local control/planning.

global vs local path planning

Global Path Planning

The global planner takes into the bigger environment and defines a path from the current point to the goal.

Algorithms like A can search through a graph, balancing the cost so far with a heuristic estimate of the remaining distance.

Sampling-based. Sampling-based algorithms like RRT are useful for motion-planning problems that involve more complex or high-dimensional configuration spaces.

The key thing is that there is no single “best” planner. The appropriate algorithm depends on the robot, environment, map representation and task.

Modern navigation frameworks reflect this flexibility. Nav2, for example, supports multiple planner plugins rather than forcing every robot to use the same algorithm.

Local Planning and Obstacle Avoidance

A global route assumes the environment won’t change.

Real environments don’t cooperate.

A person walks into the aisle. A pallet gets moved. Another robot stops directly in front of you.

The local navigation layer reacts to those changes and computes feasible short-term motion.

Nav2’s controller architecture, for example, uses local environmental information and controllers to follow paths, avoid dynamic obstacles and perform other local navigation tasks.

A costmap is often used to represent this information. Different areas of the environment receive different costs, allowing planners and controllers to prefer safer or more practical routes. Nav2’s costmap system can incorporate information from sources including LiDAR, radar, sonar and depth cameras.

Classical approaches such as the Dynamic Window Approach and Artificial Potential Fields are also used for local motion and obstacle avoidance in appropriate applications.

robot obstacle avoidance costmaps

Why Navigation Is More Than “Finding the Shortest Path”

Just because it‘s the shortest doesn‘t mean it‘s the best

A robot may choose a longer path if:

  • gives pedestrians more space
  • avoids narrow passages
  • reduces sharp turns
  • consumes less energy
  • provides better localization
  • avoids uncertain or poorly mapped areas

Put more simply, navigation is really a constrained optimization problem,  rather than just finding the minimum number of meters.

And safety, kinematics, obstacle clearance, timing and energy may all be dominated by the end decision.

The Sim-to-Real Problem

Machine learning introduces another challenge.

A navigation policy can be trained extensively inside a simulator, where thousands of trials can be run without damaging hardware. But the simulated world is still an approximation of reality.

The physical robot may encounter different:

  • friction
  • lighting
  • sensor noise
  • actuator delays
  • object properties
  • environmental layouts

The difference between simulated and real environments is commonly called the sim-to-real gap or domain gap.

One technique used to reduce it is domain randomization. Instead of training in one perfectly consistent virtual environment, developers deliberately vary properties such as textures, lighting, object positions, friction, actuator behavior and sensor noise. NVIDIA’s current robotics simulation documentation describes domain randomization specifically as a strategy for improving transfer from simulation to real-world systems.

Simulation platforms such as NVIDIA Isaac Sim are also used for robotics simulation, testing and synthetic-data generation.

Deep reinforcement learning can be part of this workflow, particularly for learning navigation or control policies, but it doesn’t replace classical planning and control in every robot. Increasingly, learned methods and traditional robotics algorithms are combined.

We’ll cover the deeper AI-based robot learning, reinforcement learning and Sim-to-Real material in its own cluster.

sim to real robotics domain randomization

Semantic Navigation and Embodied AI

Traditional maps mainly describe geometry: walls, free space and obstacles.

Although the older systems have not really looked at the semantic information they are now becoming interested in this type of information.

Reducing the scope of what the robot is expected to learn, for example: rather then just that an object is in a certain location,  the robot can relate that position to:

“This is a table.”

or:

“The mug is on the table.”

Computer Vision, object detection, scene understanding and other AI techniques can contribute to this richer representation. Foundation models can extend semantic reasoning, but semantic mapping itself does not require an LLM.

This opens the door to more natural instructions such as:

“Go to the kitchen and find the blue mug.”

The difficult part isn’t understanding the sentence alone. The robot must connect language to objects, locations, navigation and eventually physical action.

That’s where Embodied AI starts overlapping with autonomous robotics.

semantic navigation embodied ai robots

Edge Computing in Robot Navigation

Navigation workloads don’t all have to run in the same place.

Some robots perform perception, localization and control directly onboard. Others can offload selected computationally heavy workloads to nearby edge infrastructure when the network and application allow it.

But there’s an important limitation: latency-sensitive and safety-critical functions cannot simply assume a remote server will always be available.

A hybrid design might therefore keep essential navigation and control locally while using edge or cloud resources for less time-critical tasks such as mapping, fleet analytics or model processing.

That’s a much more realistic way to think about Edge Robotics than treating the robot as a thin client connected to a remote “brain.”

Classical and AI-Based Navigation Work Together

The future isn’t necessarily:

Old algorithms → replaced by AI

It’s more complicated — and more interesting.

A modern robot can combine:

  • Classical localization
  • SLAM
  • Costmaps
  • A* or other planners
  • Local controllers
  • Computer Vision
  • Sensor fusion
  • Learned perception
  • Reinforcement learning
  • Semantic understanding

The ROS 2 Nav2 also follows this modular design for example it has separate planner, controller, behavior, and costmap modules that can be configured using different algorithms & plugins.

The result is a hybrid navigation stack whereby each technique takes the part of the problem it is suited to address.

Final Thoughts

Navigation for a robot isn‘t just a matter of having a machine perform A to B.

The robot also needs to map itself in the environment it happens to be in, or use an existing map,  plan a route,  adapt to shifts in the environment and plan and execute movement in the real world.

That‘s also why navigation belongs to the junction of localization, mapping, Computer Vision, planning, control and AI.

And the field is moving toward robots that can do more than follow predefined routes. They are becoming better at understanding environments, responding to uncertainty and interpreting higher-level instructions.

The deeper topics — SLAM, localization, path planning, obstacle avoidance, sensor fusion and autonomous mobile robots — each deserve their own technical treatment. This page provides the foundation that ties them together.