Kiến trúc phần cứng của một robot di động tự hành
Atlasbot · 10/6/2026 · 11 phút đọc
Trước khi viết một dòng code nào, việc đầu tiên khi làm quen với robot di động là hiểu rõ những khối phần cứng nào ghép lại thành một con robot hoàn chỉnh, và tại sao chúng cần tồn tại. Bài này đi từ nguồn điện cho đến bánh xe, theo đúng thứ tự dòng năng lượng và dữ liệu chảy qua robot.
Khái niệm chính
Đây là nơi mọi dữ liệu cảm biến đổ về và mọi lệnh điều khiển được tính toán — "bộ não" của robot, tuỳ độ phức tạp có thể là:
- Vi điều khiển (MCU) như STM32, ESP32 — phù hợp cho vòng điều khiển động cơ tốc độ cao, realtime, giá rẻ
- Máy tính nhúng (SBC) như Jetson, Raspberry Pi — phù hợp chạy Linux, ROS2, các thuật toán SLAM/AI nặng tính toán
Robot AMR thực tế thường dùng cả hai: một MCU lo phần điều khiển động cơ thời gian thực, giao tiếp với một SBC lo phần "trí tuệ".
Robot di động bắt buộc chạy bằng pin (Li-ion/LiPo), đi kèm BMS (Battery Management System) để cân bằng điện áp giữa các cell, bảo vệ chống sạc/xả quá dòng/quá nhiệt, và báo dung lượng còn lại. Thiết kế nguồn sai là nguyên nhân phổ biến nhất khiến robot tự chế "chết" giữa chừng — thường do sụt áp khi động cơ khởi động kéo dòng lớn, không phải lỗi thuật toán.
Nguyên lý hoạt động
Mỗi loại cảm biến trả lời một câu hỏi khác nhau:
| Cảm biến | Trả lời câu hỏi |
|---|---|
| Encoder | Bánh đã quay bao nhiêu vòng? → ước lượng quãng đường đã đi |
| IMU | Robot đang nghiêng/xoay với gia tốc bao nhiêu? |
| LiDAR | Xung quanh robot có vật thể gì, cách bao xa? |
| Ultrasonic/hồng ngoại | Có vật cản gần ngay trước mặt không? |
| Camera | Nhận diện vật thể, đọc vạch kẻ, QR code |
Không robot nào dùng đúng một cảm biến — độ tin cậy đến từ sensor fusion, vì mỗi cảm biến đều có điểm mù riêng.
MCU chỉ xuất ra được tín hiệu điện áp thấp, dòng nhỏ — không đủ để quay động cơ DC cần vài Ampe. Driver động cơ đóng vai trò khuếch đại: nhận tín hiệu điều khiển nhỏ, xuất ra dòng điện lớn để thực sự quay động cơ. Gần như mọi lỗi "robot không nhúc nhích dù code đã đúng" nằm ở khâu này.
MCU, SBC, cảm biến và driver cần một "ngôn ngữ chung" để nói chuyện: UART, I2C, SPI cho khoảng cách ngắn trong board; CAN bus cho môi trường công nghiệp nhiễu điện nhiều; WiFi/Ethernet để robot báo cáo trạng thái ra ngoài.
Kiến thức kỹ thuật
Công thức
Ngân sách công suất tổng của robot là tổng công suất tiêu thụ từng khối, quyết định trực tiếp dung lượng pin cần chọn:
P_tong = P_MCU + P_SBC + P_cam_bien + P_dong_co (khi tai)
VD: MCU ~1W, Jetson Orin Nano ~15W (tải trung bình), LiDAR ~8W,
4 động cơ ~4×15W = 60W khi tải bình thường
P_tong ≈ 1 + 15 + 8 + 60 = 84W
Với pin 12V, dòng tiêu thụ trung bình = 84W / 12V = 7A
Thông số
Lựa chọn giao thức giao tiếp giữa các khối theo đúng đặc tính kết nối:
| Kết nối | Giao thức phù hợp |
|---|---|
| MCU ↔ cảm biến trên cùng board | UART, I2C, SPI |
| MCU ↔ driver động cơ (khoảng cách xa, nhiễu điện) | CAN bus, RS485 |
| MCU ↔ SBC | UART hoặc USB |
| SBC ↔ hệ thống giám sát bên ngoài | WiFi/Ethernet |
Ứng dụng thực tế
Trong kiến trúc thực tế của dự án Atlas A2, ESP32 đảm nhận vai trò MCU phụ trách điều khiển động cơ và xử lý tín hiệu dừng khẩn cấp thời gian thực, giao tiếp với Jetson Orin Nano (đóng vai SBC chạy ROS2, Nav2, AI thị giác) qua UART hoặc USB — đúng mô hình 2 tầng đã nêu ở phần Khái niệm chính. Việc chọn đúng giao thức giữa các khối (CAN cho driver động cơ nhiều dây dẫn dài dễ nhiễu, UART đơn giản cho kết nối MCU-SBC ngắn) trực tiếp ảnh hưởng độ tin cậy vận hành lâu dài của robot ngoài môi trường công nghiệp nhiều nhiễu điện từ.
Ví dụ thực tế
components = {
"MCU": 1,
"SBC (Jetson)": 15,
"LiDAR": 8,
"Camera": 3,
"4x Dong co (tai binh thuong)": 60,
}
tong = sum(components.values())
print(f"Tong cong suat uoc luong: {tong}W")
dien_ap_pin = 12
dong_tieu_thu = tong / dien_ap_pin
print(f"Dong tieu thu trung binh o {dien_ap_pin}V: {dong_tieu_thu:.1f}A")
dung_luong_pin_Ah = 10
thoi_gian_hoat_dong = dung_luong_pin_Ah / dong_tieu_thu
print(f"Uoc luong thoi gian hoat dong voi pin {dung_luong_pin_Ah}Ah: {thoi_gian_hoat_dong:.1f} gio")
Output:
Tong cong suat uoc luong: 87W
Dong tieu thu trung binh o 12V: 7.2A
Uoc luong thoi gian hoat dong voi pin 10Ah: 1.4 gio
Ước lượng này cho thấy ngay từ giai đoạn thiết kế kiến trúc phần cứng, việc cộng dồn công suất từng khối đã cho biết cần dung lượng pin bao nhiêu để đạt thời gian hoạt động mong muốn — bước tính toán cần làm trước khi chọn linh kiện cụ thể, không phải sau khi ráp xong mới phát hiện pin không đủ dùng.
Lỗi thường gặp
- BMS/nguồn không đủ dòng đỉnh khi động cơ khởi động — dòng khởi động động cơ có thể cao hơn nhiều dòng chạy ổn định (đã học ở bài DC Motor, chuyên mục Lập trình nhúng) — tính công suất chỉ theo tải ổn định mà bỏ qua đỉnh khởi động gây sụt áp/reset hệ thống.
- Chọn giao thức giao tiếp không phù hợp khoảng cách/môi trường nhiễu — dùng I2C (thiết kế cho khoảng cách rất ngắn) cho kết nối dài xuyên khung robot gần động cơ công suất lớn, thay vì CAN/RS485 chống nhiễu tốt hơn nhiều.
- Thiết kế 1 điểm lỗi duy nhất (single point of failure) cho chức năng an toàn — để toàn bộ logic dừng khẩn cấp phụ thuộc vào SBC (dễ treo/crash phần mềm) thay vì mạch cứng độc lập trên MCU hoặc mạch riêng biệt hoàn toàn.
- Không cách ly nhiễu điện giữa dây công suất lớn (động cơ) và dây tín hiệu nhạy cảm (cảm biến) — đi chung bó dây nguồn động cơ với dây tín hiệu I2C/SPI của cảm biến gây nhiễu, dữ liệu cảm biến đọc sai ngắt quãng khó chẩn đoán.
Kết luận
Sơ đồ khối phần cứng — nguồn nuôi bộ xử lý trung tâm, cảm biến đổ dữ liệu vào, bộ xử lý ra lệnh cho driver động cơ, mọi thứ giao tiếp qua đúng giao thức phù hợp — là bức tranh cần nắm trước khi đi sâu vào từng linh kiện cụ thể. Luôn tính ngân sách công suất tổng và chọn giao thức giao tiếp đúng đặc tính kết nối ngay từ giai đoạn thiết kế kiến trúc. Bài tiếp theo trong chuyên mục đi sâu vào Motor — thành phần biến năng lượng điện thành chuyển động thực tế của robot.
