Kiến trúc AMR: 5 tầng từ phần cứng tới ứng dụng
Atlasbot · 22/8/2026 · 11 phút đọc
Nhìn vào code của một AMR thật lần đầu, dễ choáng ngợp vì số lượng package, node, và tầng trừu tượng chồng lên nhau. Nhưng nhìn tổng thể, kiến trúc phần mềm AMR gần như luôn tuân theo đúng một mô hình phân tầng — hiểu mô hình này trước khi đọc code cụ thể giúp định hướng rất nhiều.
Khái niệm chính
Năm tầng từ thấp lên cao, mỗi tầng có trách nhiệm rõ ràng:
- Hardware Layer — phần cứng vật lý: motor, encoder, LiDAR, camera, IMU, các board MCU/MPU
- Driver Layer — code đọc/ghi trực tiếp phần cứng, chuyển đổi dữ liệu thô (tín hiệu encoder, byte UART) thành message chuẩn ROS2
- ROS2 Layer — hạ tầng giao tiếp (node, topic, service) kết nối mọi thành phần phần mềm lại với nhau
- Navigation + Localization — Nav2, AMCL/SLAM — "bộ não" quyết định robot đi đâu, đang ở đâu
- Application Layer — logic nghiệp vụ cấp cao nhất: điều phối nhiệm vụ, giao diện người dùng, quản lý đội robot (fleet management)
Tóm lại: Mỗi tầng chỉ nên giao tiếp với tầng liền kề — Application không nên "nhảy cóc" xuống điều khiển trực tiếp Hardware, mà phải đi qua đúng chuỗi Navigation → ROS2 → Driver → Hardware. Vi phạm nguyên tắc này khiến hệ thống khó bảo trì và khó thay thế từng phần độc lập.
Nguyên lý hoạt động
Dữ liệu chảy theo 2 chiều ngược nhau qua 5 tầng:
Chiều dữ liệu cảm biến (bottom-up):
Hardware (LiDAR quét) → Driver (parse thành LaserScan) → ROS2 (/scan topic)
→ Navigation (AMCL dùng để định vị) → Application (hiển thị trạng thái robot)
Chiều lệnh điều khiển (top-down):
Application ("đi tới điểm B") → Navigation (Nav2 tính path + velocity)
→ ROS2 (/cmd_vel topic) → Driver (chuyển thành PWM) → Hardware (động cơ quay)
Ranh giới giữa các tầng thường trùng với ranh giới phần cứng thực tế — Hardware/Driver Layer chạy trên MCU (cần thời gian thực), ROS2/Navigation/Application Layer chạy trên MPU (cần sức mạnh tính toán).
Kiến thức kỹ thuật
Công thức
Độ trễ tổng của một lệnh đi từ Application xuống tới khi động cơ thực sự phản ứng là tổng độ trễ từng tầng cộng lại:
Độ_trễ_tổng = Δt_Application + Δt_Navigation + Δt_ROS2 + Δt_Driver + Δt_Hardware
VD: Application ~10ms, Nav2 tính path ~50ms, ROS2 truyền message ~5ms,
Driver xử lý ~2ms, phản hồi động cơ vật lý ~20ms
Độ_trễ_tổng ≈ 10+50+5+2+20 = 87ms
Tầng nào chậm nhất quyết định giới hạn tần số phản ứng tổng thể của hệ thống — đây là lý do Navigation (tầng nặng tính toán nhất) thường là "nút thắt cổ chai" chính khi cần cải thiện độ phản ứng của robot.
Thông số
| Tầng | Chạy trên | Yêu cầu thời gian thực |
|---|---|---|
| Hardware + Driver | MCU (STM32/Arduino/ESP32) | Bắt buộc, độ trễ thấp/xác định |
| ROS2 + Navigation + Application | MPU (Jetson/Raspberry Pi) | Mềm dẻo hơn, ưu tiên sức mạnh tính toán |
Ứng dụng thực tế
Trong kiến trúc thực tế của dự án Atlas A2, Hardware và Driver Layer chạy trên ESP32/STM32 (đọc encoder, điều khiển động cơ, xử lý tín hiệu dừng khẩn cấp thời gian thực), trong khi ROS2, Navigation, và Application Layer chạy trên Jetson Orin Nano (đủ sức mạnh cho Nav2, AMCL, và xử lý AI thị giác). Sự phân tách rõ ràng này không chỉ là lựa chọn thiết kế đẹp về mặt lý thuyết — nó phản ánh đúng giới hạn vật lý thực tế: MCU không đủ mạnh chạy ROS2/Nav2, còn MPU chạy Ubuntu đầy đủ không đảm bảo được độ trễ xác định mà vòng an toàn/động cơ cần.
Ví dụ thực tế
Theo dấu 1 lệnh "đi tới điểm (5, 3)" qua toàn bộ 5 tầng:
1. Application: người dùng nhấn nút trên app, gửi goal (5,3) tới hệ thống
2. Navigation: Nav2 nhận goal, AMCL xác nhận vị trí hiện tại, planner tính path
3. ROS2: controller_server publish vận tốc (v, ω) lên /cmd_vel mỗi chu kỳ
4. Driver: node driver động cơ subscribe /cmd_vel, tính PWM cho từng bánh
5. Hardware: động cơ nhận PWM, thực sự quay, robot bắt đầu di chuyển
Đồng thời, dữ liệu encoder chảy NGƯỢC LẠI từ Hardware lên Application
để cập nhật vị trí hiển thị trên giao diện người dùng theo thời gian thực
Toàn bộ 5 bước này diễn ra liên tục, lặp lại nhiều lần mỗi giây — không phải "chạy 1 lần rồi xong" mà là vòng lặp Sense-Think-Act ở quy mô toàn hệ thống.
Lỗi thường gặp
- Tầng cấp cao "nhảy cóc" xuống điều khiển trực tiếp phần cứng — VD: code Application gọi thẳng driver động cơ bỏ qua Navigation/ROS2 — phá vỡ tính module hoá, khiến thay thế/nâng cấp từng tầng độc lập trở nên khó khăn hơn nhiều.
- Đặt logic thời gian thực ở tầng không phù hợp — chạy vòng điều khiển động cơ tần số cao trên MPU (qua ROS2, có độ trễ mạng/lịch trình không xác định) thay vì trên MCU — vi phạm nguyên tắc "vòng nhanh nằm gần phần cứng" đã học ở bài Sense-Think-Act.
- Driver Layer chứa logic nghiệp vụ phức tạp — Driver Layer chỉ nên "dịch" dữ liệu thô sang message chuẩn, không nên chứa quyết định logic phức tạp (VD: path planning) — nhầm vai trò từng tầng khiến code khó bảo trì và khó test độc lập.
- Không tính độ trễ tích luỹ qua nhiều tầng khi thiết kế vòng an toàn — như đã tính ở mục Công thức, độ trễ tổng cộng dồn qua 5 tầng có thể lớn hơn nhiều so với độ trễ của riêng 1 tầng — vòng an toàn (emergency stop) luôn nên bỏ qua toàn bộ 5 tầng phần mềm, xử lý trực tiếp ở tầng phần cứng/MCU thấp nhất.
Kết luận
Kiến trúc 5 tầng (Hardware → Driver → ROS2 → Navigation → Application) là mô hình chung của hầu hết AMR thực tế, với ranh giới MCU/MPU thường trùng khớp ranh giới Driver/ROS2 Layer. Hiểu đúng trách nhiệm từng tầng giúp định vị nhanh vấn đề khi debug, và tránh vi phạm nguyên tắc phân tầng khi mở rộng hệ thống. Chuyên mục AMR Software Architecture sẽ đi sâu vào từng tầng cụ thể. Bài tiếp theo trong chuyên mục Tổng quan AMR/AGV nói về Các loại AMR — phân loại theo cấu hình bánh xe và mục đích sử dụng.
