Planner trong Nav2: NavFn, SmacPlanner, ThetaStar
Atlasbot · 17/8/2026 · 11 phút đọc
Bài Path Planning là gì? giải thích Dijkstra và A* ở mức thuật toán. planner_server là node ROS2 hiện thực hoá các thuật toán đó — kiến trúc plugin, cho phép đổi thuật toán tìm đường mà không cần đổi bất kỳ node nào khác trong hệ thống.
Khái niệm chính
planner_server không tự chứa thuật toán — nó nạp một plugin cụ thể lúc runtime:
planner_server:
ros__parameters:
planner_plugins: ["GridBased"]
GridBased:
plugin: "nav2_navfn_planner::NavfnPlanner"
Bốn plugin phổ biến: NavFn (A* cổ điển), SmacPlanner2D (A* tối ưu hơn), SmacPlannerHybrid (tôn trọng ràng buộc động học), và ThetaStar (đường mượt hơn).
Nguyên lý hoạt động
Kiến trúc plugin đúng kiểu đã thấy ở bài Composition (dù đây là plugin-loading qua pluginlib, cơ chế khác composition nhưng cùng triết lý: tách interface khỏi implementation cụ thể).
NavFn triển khai A*/Dijkstra thuần tuý trên costmap (bài Costmap) — nhanh, đáng tin cậy, đã được kiểm chứng qua nhiều năm sử dụng trong ROS1/ROS2. Nhược điểm: đường đi sinh ra có thể có góc gấp khúc không tự nhiên (đặc trưng của tìm kiếm trên lưới ô vuông), cần smoother_server xử lý hậu kỳ trước khi giao cho controller bám theo.
SmacPlanner có 2 biến thể: SmacPlanner2D — A* trên lưới, tương tự NavFn nhưng tối ưu hơn; SmacPlannerHybrid — tìm kiếm trong không gian trạng thái (x, y, θ), tôn trọng bán kính quay tối thiểu của robot. Biến thể Hybrid quan trọng với robot có ràng buộc động học chặt (như Ackermann, bài Chọn hệ truyền động) — không thể xoay tại chỗ, đường đi sinh ra phải khả thi về mặt vật lý ngay từ bước lập kế hoạch, không chỉ đẹp trên lý thuyết đồ thị.
ThetaStar là biến thể A* cho phép đường nối giữa các ô không nhất thiết phải theo 8 hướng cố định (ngang/dọc/chéo như A* lưới thuần) — kết quả là đường đi thẳng hơn, ít điểm gấp khúc hơn, gần với đường đi tối ưu hình học thực sự hơn NavFn/SmacPlanner2D, đổi lại chi phí tính toán cao hơn một chút.
Tóm lại: NavFn và SmacPlanner2D phù hợp cho robot có thể xoay tại chỗ (differential, mecanum, omni — đa số AMR trong nhà); SmacPlannerHybrid cần thiết khi robot có ràng buộc kiểu Ackermann không xoay tại chỗ được. Chọn sai plugin (ví dụ dùng NavFn cho robot Ackermann) sinh ra đường đi robot vật lý không thể đi theo được.
Kiến thức kỹ thuật
Công thức
Không gian trạng thái mà mỗi plugin tìm kiếm khác nhau về số chiều, ảnh hưởng trực tiếp chi phí tính toán:
NavFn/SmacPlanner2D: tìm kiếm trên (x, y) — 2 chiều
Số trạng thái ≈ Số_ô_grid
SmacPlannerHybrid: tìm kiếm trên (x, y, θ) — 3 chiều
Số trạng thái ≈ Số_ô_grid × Số_góc_rời_rạc_hoá
VD: grid 800x600 ô, rời rạc hoá góc thành 16 hướng
NavFn: ~480,000 trạng thái
SmacPlannerHybrid: ~480,000 × 16 ≈ 7,680,000 trạng thái
Thông số
| Plugin | Ràng buộc động học | Chất lượng đường đi | Chi phí tính toán |
|---|---|---|---|
| NavfnPlanner | Không | Có gấp khúc, cần smoother | Thấp |
| SmacPlanner2D | Không | Tốt hơn NavFn | Trung bình |
| SmacPlannerHybrid | Có (bán kính quay) | Khả thi vật lý cho Ackermann | Cao |
| ThetaStar | Không | Mượt, ít gấp khúc | Trung bình-cao |
Ứng dụng thực tế
Với đa số AMR trong nhà kho (differential drive hoặc Mecanum, đã học ở chuyên mục AMR Drive System), NavFn hoặc SmacPlanner2D là lựa chọn mặc định hợp lý — robot có thể xoay tại chỗ nên không cần trả chi phí tính toán cao hơn của SmacPlannerHybrid. SmacPlannerHybrid chỉ thực sự cần thiết khi robot dùng cấu hình Ackermann (phổ biến hơn ở xe tự hành ngoài trời, ít gặp trong AMR nhà kho) — chọn đúng plugin theo đúng ràng buộc động học thực tế của robot tránh lãng phí tài nguyên tính toán không cần thiết.
Ví dụ thực tế
# Đổi plugin planner mà không cần sửa bất kỳ node nào khác
ros2 param set /planner_server GridBased.plugin nav2_smac_planner::SmacPlanner2D
# So sánh thời gian tính toán giữa các plugin
ros2 action send_goal /compute_path_to_pose nav2_msgs/action/ComputePathToPose \
"{goal: {pose: {position: {x: 5.0, y: 3.0}}}}" --feedback
Kết quả điển hình khi so sánh trên cùng bản đồ 40x30m, resolution 0.05m:
NavFn: ~50-100ms, đường đi có vài điểm gấp khúc nhẹ
SmacPlanner2D: ~80-150ms, đường đi mượt hơn NavFn
ThetaStar: ~100-200ms, đường đi mượt nhất trong 3 loại không ràng buộc động học
SmacPlannerHybrid: ~300-600ms (chậm hơn đáng kể do không gian trạng thái lớn hơn),
nhưng đường đi khả thi cho robot không xoay tại chỗ được
Lỗi thường gặp
- Dùng SmacPlannerHybrid cho robot có thể xoay tại chỗ — như tính ở mục Công thức, trả chi phí tính toán cao hơn nhiều lần mà không thu được lợi ích tương xứng, vì robot không cần ràng buộc bán kính quay.
- Dùng NavFn cho robot Ackermann — như đã nêu ở phần Tóm lại, sinh ra đường đi robot vật lý không thể đi theo được (yêu cầu xoay tại chỗ mà robot không làm được).
- Không xử lý hậu kỳ đường đi từ NavFn/SmacPlanner2D bằng smoother — để nguyên góc gấp khúc từ tìm kiếm trên lưới khiến controller phải bám theo đường không tự nhiên, ảnh hưởng chất lượng chuyển động thực tế.
- Đổi plugin mà không kiểm tra lại
max_vel_theta/ràng buộc liên quan — mỗi plugin có giả định khác nhau về khả năng robot, cần kiểm tra lại toàn bộ tham số liên quan sau khi đổi, không chỉ đổi mỗi dòngplugin:.
Kết luận
Kiến trúc plugin của planner_server cho phép đổi thuật toán tìm đường mà không đổi bất kỳ node nào khác — chọn đúng plugin theo ràng buộc động học thực tế của robot (xoay tại chỗ được hay không) là quyết định quan trọng hơn việc chọn "thuật toán mạnh nhất" một cách chung chung. Bài tiếp theo trong chuyên mục đi vào Controller — bước bám theo đường đi mà planner vừa tính ra.
