Nav2

Nav2 – definition

Nav2, short for Navigation 2, is the ROS 2 navigation framework used to move a mobile robot from its current pose to a goal pose while avoiding obstacles and respecting platform kinematics. In ROS terminology, Nav2 is a set of lifecycle-managed nodes, servers, behavior trees, planners, controllers, recovery behaviors, costmaps, and interfaces built for autonomous navigation in ROS 2. It is the successor to the ROS 1 navigation stack, but it is not a direct one-to-one port. Its architecture, APIs, lifecycle model, and execution logic follow ROS 2 design patterns.

In mobile robotics and UGV work, Nav2 is usually the software layer between localization, mapping, perception, and low-level motion control. It consumes a robot pose in a global frame, obstacle data from sensors such as LiDAR or depth cameras, and a map or local environment representation. It then computes a path and generates velocity commands, typically as geometry_msgs/msg/Twist, for a differential-drive or other supported mobile base.

For platforms such as Leo Rover and Raph Rover, Nav2 is a common ROS 2 choice for indoor and outdoor waypoint navigation, teleoperation-assisted autonomy, and autonomous traversal in research workflows. It does not make the robot autonomous by itself. A full deployment still requires working odometry, TF tree compliance, calibrated sensors, a valid robot model, and tuned planners and controllers.

How Nav2 works in ROS 2

Nav2 is organized as cooperating ROS 2 nodes. In typical deployments, the system uses a map server, an AMCL or SLAM-based localization source, global and local costmaps, a planner server, a controller server, a behavior server, a BT navigator, and optional waypoint or velocity smoothing components. ROS 2 lifecycle nodes are central to this design. They support deterministic startup and state transitions such as unconfigured, inactive, and active.

The navigation loop on a UGV usually follows this sequence:

A pose estimate is published in the map frame, often by AMCL or SLAM.
TF provides frame transforms such as map -> odom -> base_link, consistent with REP 105 frame conventions.
The planner computes a global path from the current pose to the goal pose.
The controller tracks that path and outputs commanded velocity.
Costmaps update obstacle information from LiDAR, depth camera, or point cloud topics.
Behavior tree logic handles replanning, stuck detection, recovery, and task flow.

For a differential-drive rover, the controller must respect non-holonomic constraints. This matters directly on Leo Rover, which uses differential drive, and on larger skid-steer or differential UGV configurations derived from similar motion assumptions.

Core Nav2 components

Nav2 is modular. The exact plugin set depends on ROS 2 distribution and project requirements, but several components appear in most deployments.

Component	Function	Typical ROS 2 interface
Planner Server	Computes global path on a static or dynamic costmap	Action and plugin interfaces
Controller Server	Tracks path and generates velocity commands	`cmd_vel`, controller plugins
BT Navigator	Executes navigation behavior trees	`NavigateToPose`, `NavigateThroughPoses`
Costmap 2D	Represents obstacles and inflation zones	Occupancy and obstacle layers
Behavior Server	Recovery and auxiliary actions	Spin, backup, wait, drive-on-heading, assisted behaviors
Smoother Server	Smooths planned paths	Path plugin interface
Velocity Smoother	Limits acceleration and command changes	`cmd_vel` filtering

Required inputs on a UGV platform

Nav2 depends on a valid navigation stack around it. On Leo Rover or Raph Rover, the minimum usable setup is not just a package installation. The robot needs coherent transforms, odometry, and obstacle sensing with stable timing.

The most common required inputs are:

TF tree following REP 103 and REP 105 naming and frame semantics, especially map, odom, base_link, and sensor frames.
Odometry as nav_msgs/msg/Odometry, often from wheel encoders, visual odometry, fused IMU, or EKF.
Obstacle data from sensor_msgs/msg/LaserScan or sensor_msgs/msg/PointCloud2.
Robot footprint or radius for collision checking.
Map or localization source, either a static occupancy grid or online SLAM.

Typical update rates depend on the hardware and environment. In practice, local costmap updates are often configured around 5-20 Hz, controller loops around 10-30 Hz, and LiDAR scan rates around 5-15 Hz, depending on the sensor model and onboard compute budget. On Raspberry Pi-based systems such as a default Leo Rover configuration, these values must be selected conservatively if additional perception workloads are running.

Nav2 on Leo Rover and Raph Rover

On Leo Rover, Nav2 is commonly used with a 2D LiDAR, wheel odometry, and optionally IMU fusion. Since Leo Rover supports ROS 2, a practical setup usually focuses on lightweight localization and 2D navigation first. A depth camera can be integrated, but point cloud processing may require optimization, downsampling, or offloading to a more capable compute unit.

A typical Leo Rover research configuration includes:

Differential-drive kinematics.
ROS 2 Humble or newer.
2D LiDAR for obstacle detection and AMCL or SLAM.
URDF-based robot model with accurate footprint and sensor offsets.
Nav2 tuned for lower top speed and narrow indoor or semi-structured outdoor paths.

On Raph Rover, the larger payload capacity makes Nav2 integration more flexible. The platform can host higher-grade LiDAR, GNSS/RTK, industrial IMU, or a GPU-capable computer. This supports larger maps, denser costmaps, and multi-sensor fusion for field robotics. However, the tuning burden also increases. A heavier platform needs braking distance, controller limits, and terrain-dependent inflation settings adjusted more carefully than on a small rover.

Example Nav2 configuration elements

In ROS 2 deployments, Nav2 is usually configured through YAML and launch files. The exact plugin names vary by distribution, but the structure is stable.

controller_server:
  ros__parameters:
    use_sim_time: false
    controller_frequency: 20.0
    min_x_velocity_threshold: 0.001
    progress_checker_plugins: ["progress_checker"]
    goal_checker_plugins: ["goal_checker"]
    controller_plugins: ["FollowPath"]

    FollowPath:
      plugin: "dwb_core::DWBLocalPlanner"
      max_vel_x: 0.25
      min_vel_x: 0.0
      max_vel_theta: 1.0
      acc_lim_x: 0.5
      acc_lim_theta: 1.5

local_costmap:
  local_costmap:
    ros__parameters:
      update_frequency: 10.0
      publish_frequency: 5.0
      global_frame: odom
      robot_base_frame: base_link
      rolling_window: true
      width: 4
      height: 4
      resolution: 0.05

ros2 launch nav2_bringup navigation_launch.py \
  use_sim_time:=false \
  map:=/path/to/map.yaml

Key limitations and trade-offs

Nav2 is mature, but its performance depends strongly on localization quality, sensor placement, and parameter tuning. It is not a black-box autonomy module. On UGV platforms, three issues appear often: poor odometry, unstable TF, and misconfigured footprints. Any of these can produce oscillation, false obstacle inflation, or path tracking failure.

Important trade-offs include:

2D vs 3D perception – 2D LiDAR is lighter and simpler, but limited for negative obstacles and overhanging geometry.
Compute load vs map fidelity – finer costmap resolution increases CPU and memory use.
Reactive control vs path optimality – aggressive replanning can improve obstacle avoidance but increase command instability.
Indoor vs outdoor navigation – outdoor UGV use often needs GNSS fusion, terrain-aware perception, and more robust localization than standard indoor AMCL setups.

Normative references and standards

Nav2 itself is documented within the ROS 2 ecosystem, but its correct use relies on ROS conventions and message standards. The most relevant references are the ROS 2 Nav2 documentation, REP 103 for standard units and coordinate conventions, and REP 105 for mobile platform coordinate frames. Message types such as nav_msgs/msg/Odometry, nav_msgs/msg/OccupancyGrid, sensor_msgs/msg/LaserScan, and geometry_msgs/msg/Twist define the data contracts used by the stack.

For Fictionlab platforms, implementation details should also be validated against the official technical documentation at docs.fictionlab.pl/leo-rover, especially when configuring base controllers, TF frame names, and sensor integration pipelines.