Controller trong Nav2: DWB và MPPI bám đường bằng cách khác nhau
Atlasbot · 17/8/2026 · 12 phút đọc
Bài Path Following là gì? giới thiệu Pure Pursuit — đơn giản nhưng không tự nhiên xử lý vật cản động. controller_server trong Nav2 dùng các thuật toán phức tạp hơn: DWB và MPPI — cả hai đều đã được nhắc trong nội dung dự án Atlas A2 ở phần showcase, đây là bài giải thích chi tiết hơn.
Khái niệm chính
Cả hai đều thuộc họ "sampling-based" (lấy mẫu rồi chọn tốt nhất), khác biệt cốt lõi ở đơn vị lấy mẫu:
- DWB (Dynamic Window Approach) — lấy mẫu vận tốc tức thời, nhẹ tính toán
- MPPI (Model Predictive Path Integral) — lấy mẫu cả quỹ đạo tương lai, nặng tính toán hơn nhiều
Nguyên lý hoạt động
DWB thực hiện 4 bước mỗi chu kỳ:
1. Lấy mẫu một tập vận tốc (v, ω) khả thi trong "cửa sổ động"
(giới hạn bởi giới hạn gia tốc — bài Giới hạn gia tốc)
2. Với mỗi mẫu, mô phỏng ngắn hạn (vài giây) quỹ đạo nếu áp dụng vận tốc đó
3. Chấm điểm mỗi quỹ đạo mô phỏng bằng nhiều "critic" (tiêu chí):
khoảng cách tới vật cản, độ lệch khỏi path, tốc độ tiến...
4. Chọn (v, ω) có tổng điểm cao nhất, áp dụng ngay, lặp lại chu kỳ sau
Nhẹ tính toán, chạy tốt trên CPU thuần (Raspberry Pi 4) — đây là lý do các dự án showcase dùng Raspberry Pi 4 (Robot Mecanum, Diff Robot) mặc định dùng DWB.
MPPI thực hiện quy trình phức tạp hơn:
1. Lấy mẫu HÀNG TRĂM quỹ đạo tương lai khả dĩ (không chỉ vận tốc tức thời)
dựa trên mô hình động học robot
2. Chấm điểm mỗi quỹ đạo bằng hàm chi phí (cost function)
3. Tổng hợp (weighted average) các quỹ đạo tốt thành một quỹ đạo tối ưu
4. Lặp lại tối ưu này nhiều vòng trong cùng một chu kỳ điều khiển
Chi phí tính toán cao hơn DWB nhiều (lấy mẫu số lượng lớn, lặp tối ưu nhiều vòng) — cần GPU hoặc CPU nhiều nhân để chạy mượt thời gian thực, đây là lý do dự án Atlas A2 (dùng Jetson Orin Nano) mới đủ khả năng chạy MPPI mượt, trong khi Robot Mecanum/Diff Robot (Raspberry Pi 4) hợp lý hơn với DWB.
Tóm lại: Lấy mẫu quỹ đạo cho phép MPPI "nhìn xa hơn" khi né vật cản (dự đoán trước vài giây thay vì chỉ phản ứng tức thời), đổi lại đòi hỏi tài nguyên tính toán lớn hơn nhiều.
Kiến thức kỹ thuật
Công thức
Số phép mô phỏng cần thực hiện mỗi chu kỳ điều khiển khác nhau đáng kể giữa 2 thuật toán:
DWB: Số_mô_phỏng ≈ Số_mẫu_v × Số_mẫu_ω (thường vài chục tới vài trăm tổ hợp)
MPPI: Số_mô_phỏng ≈ Số_quỹ_đạo_lấy_mẫu × Số_bước_thời_gian_mỗi_quỹ_đạo × Số_vòng_lặp_tối_ưu
(thường hàng trăm quỹ đạo × vài chục bước × vài vòng lặp
= hàng chục nghìn phép mô phỏng mỗi chu kỳ)
Chênh lệch quy mô này (hàng trăm so với hàng chục nghìn phép mô phỏng mỗi chu kỳ) giải thích trực tiếp vì sao MPPI cần phần cứng mạnh hơn nhiều bậc so với DWB để đạt cùng tần số điều khiển thời gian thực.
Thông số
| DWB | MPPI | |
|---|---|---|
| Đơn vị lấy mẫu | Vận tốc (v, ω) | Quỹ đạo tương lai |
| Chi phí tính toán | Thấp | Cao |
| Phù hợp phần cứng | CPU thuần (Raspberry Pi 4) | Cần GPU/nhiều nhân (Jetson) |
| Chất lượng né vật cản động | Tốt, phản ứng tức thời | Mượt hơn, "nhìn xa" hơn |
Ứng dụng thực tế
Critic là thành phần chấm điểm có thể cấu hình riêng trong DWB:
FollowPath:
plugin: "dwb_core::DWBLocalPlanner"
critics: ["ObstacleFootprint", "PathAlign", "GoalAlign", "PathDist", "Oscillation"]
ObstacleFootprint.scale: 0.02
PathAlign.scale: 32.0
Mỗi critic chấm điểm một khía cạnh khác nhau của quỹ đạo ứng viên (khoảng cách vật cản, độ bám path, hướng về đích...) — trọng số (scale) mỗi critic quyết định controller "ưu tiên" khía cạnh nào hơn. Đây chính là phần tham số hay cần tinh chỉnh nhất trong thực tế, bàn kỹ ở bài Tuning Controller (chuyên mục Tuning Nav2).
Ví dụ thực tế
Kịch bản: robot đang bám path, người đột ngột bước vào giữa đường
Với DWB (Raspberry Pi 4):
1. Chu kỳ điều khiển tiếp theo (thường ~10-20Hz), lấy mẫu (v,ω) mới
2. Mô phỏng ngắn hạn phát hiện quỹ đạo va chạm nếu giữ nguyên hướng
3. Critic ObstacleFootprint chấm điểm thấp cho quỹ đạo đó
4. Chọn (v,ω) khác, né sang một bên — phản ứng trong 1 chu kỳ điều khiển
Với MPPI (Jetson Orin Nano):
1. Cùng lúc mô phỏng hàng trăm quỹ đạo tương lai vài giây tới
2. Nhận diện SỚM HƠN rằng người đang di chuyển cắt ngang đường dự kiến
3. Điều chỉnh quỹ đạo mượt mà hơn, tránh né gấp vào phút cuối
nhờ "nhìn thấy trước" xu hướng chuyển động thay vì chỉ phản ứng tức thời
Lỗi thường gặp
- Chạy MPPI trên phần cứng chỉ có CPU thuần (Raspberry Pi 4) — như tính ở mục Công thức, số phép mô phỏng cần thiết vượt xa khả năng CPU thuần, gây độ trễ điều khiển không chấp nhận được.
- Dùng DWB cho môi trường cần né vật cản động phức tạp, nhiều hướng di chuyển giao nhau — DWB chỉ phản ứng tức thời, không "nhìn trước" được xu hướng chuyển động như MPPI, có thể né gấp hơn cần thiết.
- Không tinh chỉnh trọng số critic phù hợp với môi trường vận hành — dùng nguyên trọng số mặc định cho môi trường đặc thù (VD: hành lang rất hẹp cần ưu tiên PathAlign cao hơn) khiến hành vi bám path không tối ưu.
- Chọn controller theo "công nghệ mới hơn" (MPPI) mà không xét khả năng phần cứng thực tế đang có — đúng nguyên tắc đã học ở bài Chọn Computer cho AMR, chọn dư thừa "cho chắc" trả giá bằng chi phí và đôi khi hiệu năng thực tế kém hơn nếu phần cứng không đủ mạnh chạy mượt.
Kết luận
DWB và MPPI đều thuộc họ sampling-based nhưng khác biệt cốt lõi ở việc lấy mẫu vận tốc tức thời hay cả quỹ đạo tương lai — đánh đổi trực tiếp giữa chi phí tính toán và khả năng "nhìn xa" khi né vật cản động. Chọn đúng theo khả năng phần cứng thực tế (đã cân nhắc ở bài Chọn Computer cho AMR) quan trọng hơn chọn theo thuật toán "mạnh nhất". Bài tiếp theo trong chuyên mục đi vào Costmap — bản đồ chi phí mà cả Planner lẫn Controller đều dựa vào để tính toán.
