SLAM là gì? Bài toán con gà quả trứng của robot học
Atlasbot · 17/8/2026 · 12 phút đọc
Bài Localization trong Navigation giả định đã có sẵn bản đồ. Nhưng bản đồ đó từ đâu ra? SLAM (Simultaneous Localization and Mapping) là câu trả lời — và cái tên đã nói lên bản chất vấn đề: định vị và dựng bản đồ phải giải đồng thời, không thể tách rời.
Khái niệm chính
Cần bản đồ ĐÃ CÓ để định vị chính xác (như AMCL đã học)
nhưng
Cần vị trí CHÍNH XÁC để dựng bản đồ đúng (mỗi lần đo LiDAR phải biết
đang đo từ đâu mới ghép đúng vào bản đồ)
Đây là vòng lặp phụ thuộc kinh điển — không có điểm khởi đầu "sạch" nào để bắt đầu. SLAM giải quyết bằng cách ước lượng đồng thời cả hai, chấp nhận cả hai đều có sai số ban đầu, rồi liên tục tinh chỉnh chúng cùng nhau khi có thêm dữ liệu.
Nguyên lý hoạt động
Mọi hệ SLAM hiện đại, bất kể thuật toán cụ thể (slam_toolbox, Cartographer — hai bài tiếp theo), đều tách xử lý thành hai tầng:
- Front-end — Scan Matching — khớp lần quét LiDAR hiện tại với bản đồ cục bộ đã dựng được, ước lượng vị trí tức thời. Đây là công việc "thời gian thực", chạy mỗi khi có scan mới
- Back-end — Tối ưu toàn cục — định kỳ nhìn lại toàn bộ quỹ đạo đã đi qua và các ràng buộc đã thu thập, điều chỉnh lại để mọi thứ nhất quán với nhau — đặc biệt quan trọng khi có loop closure
Khi robot đi một vòng và quay lại đúng vị trí đã từng đi qua, hệ SLAM nhận diện lại được điểm đó (so khớp scan hiện tại với scan cũ đã lưu) — đây gọi là loop closure. Phát hiện được loop closure cho phép back-end "kéo" toàn bộ quỹ đạo đã đi qua về đúng vị trí thực, triệt tiêu phần lớn sai số trôi đã tích luỹ suốt quãng đường vừa đi.
Tóm lại: Front-end trả lời "vị trí ngay bây giờ là gì" nhanh nhưng có thể sai lệch tích luỹ; Back-end trả lời "toàn bộ quỹ đạo từ trước tới giờ có nhất quán không" chậm hơn nhưng sửa được sai lệch đó. Hai tầng bổ trợ nhau — chỉ front-end thì trôi dần như odometry thuần (bài Odometry), chỉ back-end thì không đủ nhanh để dùng thời gian thực.
Kiến thức kỹ thuật
Công thức
Không có loop closure: sai số trôi tích luỹ không giới hạn, bản đồ méo dần
Có loop closure: sai số được "chốt lại" mỗi khi quay lại điểm cũ
Chi phí tính toán của back-end tăng theo số ràng buộc (constraint) đã thu thập, gần như tỉ lệ với bình phương số pose trong đồ thị tối ưu (pose-graph) ở trường hợp xấu nhất — đây là lý do bản đồ càng lớn, càng đi lâu, back-end càng cần nhiều thời gian xử lý mỗi lần tối ưu toàn cục, dù front-end vẫn chạy nhanh và ổn định ở tần số cố định.
Thông số
| Tầng | Tần số | Phạm vi xử lý | Sửa được gì |
|---|---|---|---|
| Front-end (scan matching) | Mỗi scan mới (thường 5-10Hz) | Cục bộ, so với bản đồ/scan gần nhất | Vị trí tức thời |
| Back-end (tối ưu toàn cục) | Định kỳ, khi có đủ ràng buộc mới | Toàn bộ quỹ đạo đã đi | Sai số trôi tích luỹ, đặc biệt khi có loop closure |
Ứng dụng thực tế
Đây là lý do quy trình quét bản đồ thực tế (bài Mapping thực tế) luôn khuyến khích đi thành các vòng khép kín thay vì chỉ đi các đường thẳng một chiều — càng nhiều cơ hội loop closure, bản đồ cuối cùng càng chính xác. Trong triển khai AMR thực tế ở nhà kho, việc lên kế hoạch tuyến quét ban đầu (đi hết các hành lang rồi quay lại điểm xuất phát theo một vòng khép kín) không chỉ tiết kiệm thời gian mà còn trực tiếp cải thiện chất lượng bản đồ cuối cùng dùng cho AMCL về sau.
Ví dụ thực tế
So sánh 2 kịch bản quét cùng một khu vực hình chữ nhật 20m x 15m:
Kịch bản A — đi theo đường zíc-zắc một chiều, không quay lại điểm đầu:
→ không có loop closure nào
→ sai số trôi tích luỹ suốt quãng đường ~150m đã đi
→ bản đồ cuối có thể méo nhẹ, đặc biệt ở đầu xa điểm xuất phát
Kịch bản B — đi theo đường bao quanh khu vực, quay về đúng điểm xuất phát:
→ có ít nhất 1 loop closure lớn khi quay lại điểm đầu
→ back-end "kéo" toàn bộ quỹ đạo về nhất quán với ràng buộc loop closure đó
→ bản đồ cuối chính xác hơn đáng kể dù quãng đường đi tương đương
Lỗi thường gặp
- Chỉ quan tâm front-end (vị trí tức thời) mà bỏ qua vai trò back-end — dẫn tới hiểu sai rằng SLAM chỉ là "scan matching liên tục", trong khi chất lượng bản đồ cuối cùng phụ thuộc rất nhiều vào bước tối ưu toàn cục.
- Quét bản đồ theo đường thẳng một chiều, không chủ đích tạo loop closure — như ví dụ Kịch bản A ở trên, bỏ lỡ cơ hội sửa sai số trôi tích luỹ, dù không phải lỗi kỹ thuật mà là lỗi quy trình vận hành.
- Kỳ vọng SLAM sửa được sai số tức thời như back-end đang chạy liên tục — back-end chạy định kỳ, không phải mỗi scan, nên vị trí tức thời vẫn có thể trôi nhẹ giữa các lần tối ưu.
- Không phân biệt giai đoạn SLAM (chưa có map) với giai đoạn AMCL (map đã có) — như đã học ở bài Localization trong Navigation, hai giai đoạn có chi phí tính toán và cách vận hành khác nhau đáng kể.
Kết luận
SLAM giải quyết bài toán con gà quả trứng bằng kiến trúc hai tầng Front-end/Back-end, với loop closure là cơ chế then chốt triệt tiêu sai số trôi tích luỹ. Hiểu đúng khung này trước khi học cụ thể slam_toolbox hay Cartographer giúp phân biệt "đây là nguyên lý chung mọi hệ SLAM đều có" với "đây là cách một package cụ thể triển khai nó". Chuyên mục này tiếp tục với hai hệ SLAM phổ biến nhất trong ROS2 — slam_toolbox và Cartographer — cả hai đều hiện thực hoá đúng khung vừa nói, chỉ khác nhau ở chi tiết thuật toán và trải nghiệm sử dụng.
