Navigation2 single-point navigation avoid

1. Program Functionality

After running the program, a map will load in rviz. In the rviz interface, use the [2D Pose Estimate] tool to set the car's initial pose, and then use the [2D Goal Pose] tool to set a target point. The car will then calculate a path based on its surroundings and move to its destination. If it encounters obstacles, it will automatically avoid them and stop at its destination.

2. Navigation2 Introduction

2.1 Introduction

Navigation2 Overall Architecture

image-20250813100835385

Navigation2 provides the following tools:

Navigation 2 (Nav2) is the native navigation framework in ROS 2. Its purpose is to safely move mobile robots from point A to point B. Nav2 implements behaviors such as dynamic path planning, motor speed calculation, obstacle avoidance, and structure recovery.

Nav2 uses behavior trees (BTs) to call modular servers to perform an action. Actions can include path calculation, control efforts, recovery, or other navigation-related actions. These actions are independent nodes that communicate with the behavior tree (BT) through the action server.

2.2 Related Materials

Navigation2 Documentation: https://navigation.ros.org/index.html

Navigation2 GitHub: https://github.com/ros-planning/navigation2

Navigation2 Paper: https://arxiv.org/pdf/2003.00368.pdf

3. Running Examples

3.1 Pre-use Notes

This lesson uses the Raspberry Pi 5 as an example. For Raspberry Pi 5 and Jetson Nano boards, you need to open a terminal on the host computer and enter the command to enter the Docker container. Once inside the Docker container, enter the commands mentioned in this lesson in the terminal. For instructions on entering the Docker container from the host computer, refer to [01. Robot Configuration and Operation Guide] -- [5.Enter Docker (For JETSON Nano and RPi 5)]. For Orin boards, simply open a terminal and enter the commands mentioned in this lesson.

3.2 Single-Point Navigation

Note:

Robot car terminal launches the underlying sensor command:

image-20250813101450834

Enter this command to start rviz visualization mapping (the rviz visualization function can be started on either the car computer or the virtual machine. Select either method. Do not start both the virtual machine and the car computer simultaneously. ). The following figure shows the command entered on the car computer.

image-20250813101614262

At this point, the map is not loading because the navigation program has not yet been started. Next, run the navigation node by entering **in the terminal (you need to enter the same Docker terminal as above).

image-20250813101906551

You'll see the map loaded. Click [2D Pose Estimate] to set the initial pose for the car. Based on the car's actual position in the environment, click and drag the mouse in rviz to move the car model to the set position. As shown in the figure below, if the lidar scan area roughly overlaps with the actual obstacle, the pose is accurate. After pose initialization is complete, the robot model and expansion region will appear in the RVIZ interface.

image-20250813101950084

For single-point navigation, click the [2D Goal Pose] tool, then use the mouse to select a target point and orientation in RVIZ, then release.

image-20250813102136859

The robot plans a path based on its surroundings and moves along it to the target point.

image-20250813102304651

After the robot successfully reaches the target point, the vehicle terminal will display "Goal succeeded," indicating successful navigation.

image-20250813102420193

4. View the Node Communication Graph

Enter the terminal:

If the graph does not display initially, select [Nodes/Topics (all)] and click the refresh button in the upper left corner. The original graph is too large; you can view it in the current lesson folder.

rosgraph

5. View the TF Tree

Enter the terminal:

If the page doesn't display initially, click the refresh icon in the upper left corner to refresh the page. The original image is too large; you can view it in this lesson's folder.

image-20250813103239919

6. Navigation Explanation

6.1 Core Steps of the Navigation Process

6.1.1 Phase 1: System Initialization and Map Loading

Cost Map Initialization

6.1.2 Phase 2: Sensor Data Processing and Environmental Perception

Sensor Data Access

Cost Map Update

6.1.3 Phase 3: Path Planning (Global and Local Planning)

Global Path Planning

Local Path Planning and Tracking

The local planner, DWBLocalPlanner, generates short-term control commands that the robot can execute based on the global path and the local costmap.

6.1.4 Phase 4: Control Execution and Behavior Decision-Making

Controller Output

Behavior Tree Decision Process

The behavior tree defines the priority and state transition logic for navigation tasks. A typical process is as follows:

  1. Checking if the target is reachable: If global planning fails, trigger a "recovery behavior" (e.g., replanning).
  2. Performing Local Obstacle Avoidance: When an obstacle is detected in the local costmap, temporarily deviate from the global path.
  3. Reaching the Target: When the error between the robot's pose and the target pose is less than a threshold, the task is completed.

Recovery Behavior Mechanism

When navigation encounters an anomaly (such as a completely blocked path), a pre-set recovery strategy (such as rotating to search for a new path or backing off to replan) is triggered.

6.2 Key Technical Principles

6.2.1 Cost Map

A cost map is a two-dimensional or three-dimensional map created and updated by the robot using sensor information. The figure below provides a brief overview.

image-20250813103944590

In the image above, the red area represents obstacles in the costmap, the blue area represents obstacles expanded by the radius of the robot's inscribed circle, and the red polygon represents the footprint (the vertical projection of the robot's outline). To avoid collisions, the footprint should not intersect the red area, and the robot's center should not intersect the blue area.

The ROS costmap uses a grid format, with each cell value (cell cost) ranging from 0 to 255. It is divided into three states: occupied (obstacles present), free area (no obstacles), and unknown area.

The specific states and values ​​are shown in the following figure:

The image above can be divided into five sections, with the red polygon representing the robot's outline:

Global costmap:

image-20250813104151891

Local costmap:

image-20250813104212672

6.2.2 AMCL Localization Algorithm

AMCL (Adaptive Monte Carlo Localization) is a probabilistic localization system for 2D mobile robots. It implements an adaptive (or KLD sampling) Monte Carlo localization method that uses a particle filter to estimate the robot's position based on a given map.

As shown in the figure below, if the odometry is error-free, in a perfect world, we can directly use the odometry information (top half) to infer the robot's (base_frame) position relative to the odometry coordinate system. However, in reality, odometry drift and non-negligible cumulative errors exist. Therefore, AMCL uses the method in the bottom half. This method first uses the odometry information to preliminarily locate the base_frame. Then, using the measurement model, we determine the base_frame's position relative to the map_frame (global map coordinate system), thus determining the robot's position within the map. (Note that while the base-to-map transformation is estimated here, the final published transformation is the map-to-odom transformation, which can be understood as odometry drift.)

image-20250813104236605

In the TF tree during robot navigation, the coordinate transformation between the map (map coordinate system) and the odom (odometry coordinate system) is published by the AMCL localization algorithm, while the coordinate transformation between the odom (odometry coordinate system) and the besel_footprint (robot chassis center projection coordinate system) is published by the ekf_filter_node node in the robot_localization package. Its function is to publish odometry information after fusion of the raw odometry from the IMU sensor and encoder.

image-20250813104411811

In the node communication diagram above, we can see the communication data flow for the ekf_filter_node.

The /driver_node node is the robot chassis node, publishing /imu/data_raw (raw IMU sensor data) and /odom_raw (raw encoder odometry data).

The imu_filter node subscribes to / imu/data_raw (raw IMU sensor data). The imu_filter node filters the raw IMU sensor data and publishes it to the /imu/data topic.

The ekf_filter_node node subscribes to the /odom and /imu/data topics, fuses the multi-sensor data, and publishes it to the /odom topic.

image-20250813104848585

6.3 Path Planning

6.3.1 Global Path Planning

Global path planning calculates an optimal or feasible global path from a start point to a destination within a known environment map, disregarding real-time obstacles. The path from the start point to the destination is calculated with the global optimum as the goal. As shown in the figure below, the path connected by arrows is the global path.

image-20250813105347557

6.3.2 Local Path Planning

Local path planning dynamically adjusts the robot's path based on real-time LiDAR sensor data during movement to avoid obstacles (obstacles are displayed in the costmap). As shown in the figure below, the blue path is the local path.

image-20250813105609389

6.4 Navigation Parameter Configuration

Jetson Nano and Raspberry Pi require Docker first

Configuration file path:

The default configuration parameters for the navigation function are as follows: