Tuning Controller: quy trình chỉnh trọng số Critic của DWB
Atlasbot · 17/8/2026 · 12 phút đọc
Bài Controller đã giới thiệu các critic (ObstacleFootprint, PathAlign, GoalAlign...) chấm điểm quỹ đạo ứng viên trong DWB. Đây là bài cuối chuyên mục Tuning Nav2 — tổng hợp lại toàn bộ tham số đã học ở các bài trước thành một quy trình chỉnh sửa có hệ thống.
Khái niệm chính
FollowPath:
critics: ["ObstacleFootprint", "PathAlign", "GoalAlign", "PathDist", "GoalDist", "Oscillation"]
ObstacleFootprint.scale: 0.02
PathAlign.scale: 32.0
GoalAlign.scale: 24.0
PathDist.scale: 32.0
GoalDist.scale: 24.0
ObstacleFootprint — phạt quỹ đạo tiến gần vật cản (kết hợp với Costmap)
PathAlign — thưởng quỹ đạo có HƯỚNG khớp với hướng path tại điểm gần nhất
PathDist — thưởng quỹ đạo có VỊ TRÍ gần path
GoalAlign — thưởng quỹ đạo hướng thẳng về goal cuối
GoalDist — thưởng quỹ đạo tiến gần goal cuối
Oscillation — phạt hành vi đổi chiều liên tục (đã nhắc ở bài Tuning Rotation)
Mỗi critic "kéo" lựa chọn quỹ đạo theo một hướng ưu tiên khác nhau — tổng điểm là tổ hợp có trọng số của tất cả, scale càng cao thì critic đó càng có tiếng nói quyết định.
Nguyên lý hoạt động
Quy trình chỉnh trọng số có hệ thống:
1. Bắt đầu với bộ trọng số mặc định của Nav2 (đã kiểm chứng rộng rãi)
2. Quan sát hành vi thực tế — ghi lại RÕ triệu chứng cụ thể
(không phải "chạy chưa tốt" chung chung)
3. Xác định critic nào liên quan trực tiếp tới triệu chứng đó
4. Chỉ chỉnh MỘT critic một lần, thay đổi nhỏ (ví dụ ±20%)
5. Test lại, quan sát, lặp lại bước 3
Tóm lại: Chỉnh nhiều critic cùng lúc là sai lầm phổ biến nhất — khi hành vi thay đổi, không thể biết chính xác critic nào gây ra hiệu ứng đó, dễ rơi vào vòng lặp thử-sai không có hệ thống. Luôn chỉnh một tham số, quan sát rõ ràng, rồi mới chuyển sang tham số tiếp theo — đúng nguyên tắc khoa học cơ bản khi thực nghiệm, không riêng gì Nav2.
Kiến thức kỹ thuật
Công thức
Tổng điểm quỹ đạo ứng viên là tổ hợp tuyến tính có trọng số của mọi critic — hiểu công thức này giúp dự đoán được hướng ảnh hưởng khi chỉnh một scale:
Điểm_tổng(quỹ_đạo) = Σ (scale_i × điểm_critic_i(quỹ_đạo))
Tăng scale của 1 critic → tăng "trọng lượng" của critic đó trong tổng điểm
→ quỹ đạo được chọn bị "kéo" mạnh hơn theo hướng critic đó ưu tiên,
tương đối so với các critic còn lại (không đổi giá trị tuyệt đối)
Đây là lý do "chỉnh tương đối" quan trọng hơn "chỉnh tuyệt đối" — giảm PathAlign.scale cũng tạo hiệu ứng tương tự tăng ObstacleFootprint.scale (đều làm ObstacleFootprint có tiếng nói tương đối mạnh hơn), dù về bản chất là 2 thao tác khác nhau.
Thông số
| Triệu chứng | Critic cần xem lại |
|---|---|
| Robot cắt góc, không bám sát path | Tăng PathAlign.scale, PathDist.scale |
| Robot đi quá sát vật cản | Tăng ObstacleFootprint.scale, hoặc xem lại inflation_radius (bài Tuning Costmap) |
| Robot ưu tiên bám path hơn cả khi path dẫn qua vùng nguy hiểm | Giảm PathAlign.scale tương đối so với ObstacleFootprint.scale |
| Lắc lư khi gần đích | Xem bài Tuning Rotation, tăng Oscillation.scale |
| Chọn quỹ đạo "hợp lý" nhưng không tới đích nhanh nhất | Tăng GoalDist.scale, GoalAlign.scale |
Ứng dụng thực tế
Test có kiểm soát: để so sánh công bằng hiệu ứng của từng thay đổi tham số, nên test trên cùng một kịch bản cố định mỗi lần (cùng bản đồ, cùng điểm xuất phát, cùng điểm đích, lý tưởng nhất là dùng ros2 bag — bài ros2 bag — ghi lại một kịch bản LiDAR/odometry thật rồi phát lại nhiều lần) — thay đổi môi trường test giữa các lần thử khiến không thể phân biệt được hiệu ứng do tham số mới hay do điều kiện môi trường khác đi. Đây là kỷ luật thực nghiệm quan trọng không kém việc hiểu đúng ý nghĩa từng critic.
Ví dụ thực tế
Kịch bản debug thực tế: robot cắt góc quá sát ở các khúc cua trong kho hàng,
dù đường path do planner tính ra đã đủ rộng rãi
Bước 1: ghi lại triệu chứng cụ thể — "cắt góc" nghĩa là robot đi tắt qua
góc trong của khúc cua thay vì bám theo đúng đường path đã vạch
Bước 2: theo bảng Thông số, đây là dấu hiệu PathAlign/PathDist scale
chưa đủ mạnh so với GoalDist/GoalAlign (robot ưu tiên "tới đích
nhanh" hơn "bám đúng path")
Bước 3: chỉnh MỘT tham số — tăng PathAlign.scale từ 32.0 lên 38.0 (+~20%)
Bước 4: test lại đúng cùng kịch bản (cùng bag file ghi sẵn)
Bước 5: quan sát: robot bám path tốt hơn rõ rệt -> giữ thay đổi này
Nếu cắt góc vẫn còn: tiếp tục tăng thêm ~20% nữa, lặp lại quy trình
Lỗi thường gặp
- Chỉnh nhiều critic cùng lúc — như đã nêu ở phần Tóm lại, không thể xác định chính xác critic nào gây ra hiệu ứng quan sát được, dễ rơi vào vòng lặp thử-sai vô định hướng.
- Test trên môi trường/kịch bản khác nhau giữa các lần thử — không thể so sánh công bằng hiệu ứng của thay đổi tham số, dễ kết luận sai do nhiễu từ điều kiện môi trường thay đổi.
- Ghi lại triệu chứng chung chung ("chạy chưa tốt") thay vì cụ thể — không đủ thông tin để xác định đúng critic liên quan, dẫn tới chỉnh sai tham số không giải quyết đúng vấn đề gốc.
- Không hiểu công thức tổ hợp tuyến tính, chỉnh scale theo cảm tính "càng cao càng tốt" — như ở mục Công thức, tăng vô tội vạ một scale mà không cân nhắc ảnh hưởng tương đối tới các critic khác dễ gây mất cân bằng hành vi tổng thể.
Kết luận
Chỉnh trọng số critic là bước tinh chỉnh cuối cùng, tinh tế nhất trong chuỗi Tuning Nav2 — chỉ nên thực hiện sau khi các giới hạn vật lý cơ bản (velocity, acceleration, footprint) đã đúng. Quy trình có hệ thống — một tham số một lần, test trên kịch bản cố định, ghi lại triệu chứng cụ thể — là kỷ luật quan trọng hơn việc thuộc lòng ý nghĩa từng critic. Chuyên mục Tuning Nav2 đã đi qua đủ các tham số: Velocity, Acceleration, Rotation, Footprint, Costmap, và Controller — đúng thứ tự nên tinh chỉnh khi triển khai Nav2 lên một robot thật: từ giới hạn vật lý cơ bản tới các tham số hành vi tinh tế hơn. Đây cũng là bài khép lại toàn bộ chuyên mục ROS2 Navigation / Nav2, từ khái niệm nền tảng, SLAM, Localization, framework Nav2, tới tinh chỉnh thực tế hoàn chỉnh.
