Cấu hình Nav2 cho robot 2 bánh vi sai: từ params.yaml tới launch

Các bài khác trong chuyên mục Nav2 giải thích từng khái niệm riêng lẻ. Bài này là bản ghép nối thực hành — cấu trúc params.yaml tối thiểu để Nav2 chạy được trên một robot vi sai thật, đúng loại robot đã dùng trong dự án Diff Robot ở phần showcase của trang này.

Khái niệm chính

amcl:
  ros__parameters:
    robot_model_type: "nav2_amcl::DifferentialMotionModel"

controller_server:
  ros__parameters:
    controller_plugins: ["FollowPath"]
    FollowPath:
      plugin: "dwb_core::DWBLocalPlanner"
      max_vel_x: 0.3
      max_vel_theta: 1.0

planner_server:
  ros__parameters:
    planner_plugins: ["GridBased"]
    GridBased:
      plugin: "nav2_navfn_planner::NavfnPlanner"

local_costmap:
  local_costmap:
    ros__parameters:
      width: 3
      height: 3
      resolution: 0.05

global_costmap:
  global_costmap:
    ros__parameters:
      resolution: 0.05

Mỗi khối tương ứng đúng một khái niệm đã học ở các bài riêng: amcl (bài AMCL trong Nav2), controller_server/planner_server (bài Controller/Planner), local_costmap/global_costmap (bài Costmap).

Nguyên lý hoạt động

Điểm riêng cho robot vi sai nằm ở robot_model_type: "nav2_amcl::DifferentialMotionModel" — AMCL cần biết mô hình chuyển động robot để dự đoán đúng khi di chuyển hạt (bước Predict, đã học ở bài AMCL là gì?). Robot vi sai không thể đi ngang, mô hình chuyển động phản ánh đúng ràng buộc đó (khác với robot Mecanum cần OmniMotionModel). Chọn sai mô hình chuyển động khiến AMCL dự đoán các khả năng di chuyển mà robot thực tế không làm được, hội tụ kém chính xác hơn.

Trong thực tế, phần lớn dự án dùng sẵn launch file nav2_bringup thay vì viết tay từng Node(), nhưng hiểu được cấu trúc từng node ghép lại giúp đọc/sửa launch file có sẵn dễ dàng hơn nhiều, thay vì coi nó như hộp đen:

Node(package="nav2_amcl", executable="amcl", parameters=[params_file]),
Node(package="nav2_controller", executable="controller_server", parameters=[params_file]),
Node(package="nav2_planner", executable="planner_server", parameters=[params_file]),
Node(package="nav2_lifecycle_manager", executable="lifecycle_manager",
     parameters=[{"autostart": True, "node_names": ["amcl", "controller_server", "planner_server"]}]),

Tóm lại: lifecycle_manager (bài Lifecycle Node) luôn là node cuối cùng cần cấu hình — nó điều phối configure/activate cho tất cả node Nav2 khác theo đúng thứ tự, đảm bảo amcl sẵn sàng trước khi controller_server bắt đầu nhận lệnh.

Kiến thức kỹ thuật

Công thức

max_vel_x/max_vel_theta trong controller_server nên khớp với giới hạn vật lý thực tế đã tính ở bài Chọn Motor cho AMR — đặt cao hơn khả năng thực tế khiến controller yêu cầu tốc độ robot không đạt được:

max_vel_x nên ≤ v_max tính từ RPM động cơ và bán kính bánh (bài Chọn Motor)

VD: động cơ 120 RPM, bánh 65mm -> v_max lý thuyết ≈ 0.41 m/s
Đặt max_vel_x: 0.3 (thay vì 0.41) chừa biên độ an toàn ~27% cho:
  - sụt áp pin khi tải nặng
  - ma sát thực tế cao hơn lý tưởng
  - đảm bảo controller luôn đạt được tốc độ yêu cầu, không "hụt hơi"

Thông số

Triệu chứng	Kiểm tra
Robot không nhận Nav Goal	`lifecycle_manager` đã activate hết các node chưa (`ros2 lifecycle get`)
Robot đứng yên dù có path	Kiểm tra `/cmd_vel` có publisher/subscriber đúng chưa (bài ros2 topic)
"could not transform"	Xem bài TF Tree
Robot đi lệch path	Xem bài Tuning Controller

Ứng dụng thực tế

Sau khi launch, mở RViz2 (bài RViz2), dùng "2D Pose Estimate" để Set Pose ban đầu (bài AMCL trong Nav2), rồi "Nav2 Goal" để gửi thử một điểm đích — nếu mọi cấu hình đúng, robot sẽ tự tính đường đi và di chuyển tới đích. Quy trình khởi động này (nạp map → set pose → gửi goal thử) nên là bước xác nhận chuẩn mỗi khi thay đổi cấu hình lớn trong params.yaml, trước khi tích hợp vào ứng dụng tự động hoá hoàn chỉnh.

Ví dụ thực tế

ros2 launch nav2_bringup bringup_launch.py \
  map:=my_map.yaml \
  params_file:=nav2_params.yaml

Quy trình xác nhận cấu hình đúng, từng bước:

1. Chạy lệnh trên, đợi log báo tất cả node "activate" thành công
2. ros2 lifecycle get /amcl -> nên trả về "active"
3. Mở RViz2, dùng "2D Pose Estimate" click đúng vị trí robot hiện tại
4. Quan sát /particlecloud co cụm (đã học ở bài AMCL trong Nav2)
5. Dùng "Nav2 Goal" click một điểm đích gần, quan sát robot di chuyển

Nếu bước 5 robot không nhúc nhích: theo bảng Thông số, kiểm tra
lifecycle_manager trước tiên -> thường là nguyên nhân phổ biến nhất

Lỗi thường gặp

Đặt max_vel_x cao hơn khả năng vật lý thực tế của động cơ — như tính ở mục Công thức, controller yêu cầu tốc độ robot không đạt được, gây hành vi bám path kém.
Dùng nhầm robot_model_type cho loại hệ truyền động — như đã nêu, DifferentialMotionModel cho robot Mecanum (hoặc ngược lại) khiến AMCL dự đoán sai khả năng di chuyển thực tế.
Không kiểm tra lifecycle_manager trước khi nghi ngờ node khác — như bảng debug, đây thường là nguyên nhân gốc khi robot "không nhận Nav Goal" dù cấu hình từng node riêng lẻ đều đúng.
Copy nguyên params.yaml từ dự án khác mà không điều chỉnh theo phần cứng thực tế — kích thước costmap, tốc độ tối đa, mô hình chuyển động đều cần khớp đúng robot đang cấu hình, không phải giá trị mặc định chung chung.

Kết luận

File params.yaml là nơi mọi khái niệm Nav2 đã học riêng lẻ — AMCL, Planner, Controller, Costmap — hội tụ thành một cấu hình chạy được thực tế, với robot_model_type và max_vel_x/max_vel_theta là hai điểm cần khớp đúng đặc thù robot vi sai. Bài tiếp theo trong chuyên mục đi sâu vào Planner — chi tiết các plugin lập kế hoạch đường đi vừa cấu hình ở đây.