Bumper và Emergency Stop: lớp an toàn cuối cùng khi mọi cảm biến khác đã sai
Atlasbot · 17/8/2026 · 12 phút đọc
Các bài trước — LiDAR, Camera — đều là cảm biến "thông minh", dữ liệu phải qua xử lý phần mềm mới ra được quyết định né tránh. Nhưng phần mềm có thể treo, thuật toán có thể nhận diện sai, và không cảm biến nào phủ được 100% vùng quanh robot. Bumper và Emergency Stop là hai lớp an toàn được thiết kế để hoạt động độc lập hoàn toàn với mọi phần mềm phía trên.
Khái niệm chính
Hai lớp an toàn phần cứng đóng vai trò khác nhau trong chuỗi phòng thủ:
- Bumper — cảm biến va chạm vật lý, phát hiện khi robot thực sự chạm vào vật cản
- Emergency Stop (E-Stop) — mạch cứng cắt trực tiếp nguồn cấp cho driver động cơ, không đi qua bất kỳ đoạn code nào
Nguyên lý hoạt động
Bumper là dải cảm biến cơ khí (thường dùng công tắc vi mô hoặc cảm biến áp lực) chạy dọc theo mép ngoài robot — khi robot chạm vào vật cản (dù LiDAR/camera đã bỏ sót vì lý do gì đó), bumper bị nén và kích hoạt tín hiệu dừng ngay lập tức. Điểm khác biệt cốt lõi so với LiDAR/camera: bumper không cần "hiểu" vật cản là gì, không cần thuật toán xử lý phức tạp — chỉ đơn giản là một công tắc cơ khí đóng/mở. Đây chính xác là loại cảm biến ESP32 xử lý va chạm trong dự án Atlas A2 (phần showcase của trang này) đảm nhiệm, tách biệt hoàn toàn khỏi luồng xử lý LiDAR/Nav2 phức tạp hơn.
E-Stop (thường là nút bấm đỏ nấm, dễ nhận biết, dễ bấm trong tình huống khẩn) khi kích hoạt phải cắt trực tiếp nguồn cấp cho driver động cơ — không đi qua bất kỳ đoạn code nào xử lý logic "nên dừng hay không":
Luồng bình thường: Nav2 tính lệnh → /cmd_vel → firmware → PWM → động cơ
(đi qua rất nhiều lớp phần mềm, mỗi lớp đều có thể lỗi)
Luồng E-Stop: Nút bấm → relay/công tắc cơ khí → cắt nguồn động cơ trực tiếp
(không đi qua lớp phần mềm nào)
Tóm lại: Bumper là lớp an toàn "chạm mới biết" — luôn xảy ra sau khi các cảm biến khoảng cách (LiDAR, ultrasonic) đã có cơ hội phản ứng trước. E-Stop tồn tại để bỏ qua toàn bộ logic giảm tốc "văn minh" của phần mềm, chấp nhận dừng đột ngột để ưu tiên tuyệt đối cho an toàn khi mọi lớp phía trên đã thất bại.
Kiến thức kỹ thuật
Công thức
Bài Sense-Think-Act (chuyên mục Robotics Fundamentals) đã nêu quãng đường phản ứng phụ thuộc trực tiếp vào thời gian phản ứng của hệ thống:
Quãng_đường_phản_ứng = Vận_tốc × Thời_gian_phản_ứng
Luồng phần mềm bình thường: Thời_gian_phản_ứng bao gồm toàn bộ chuỗi
Nav2 → ROS2 → Driver, có thể lên tới hàng chục-trăm ms (đã tính ở bài Kiến trúc AMR)
Luồng E-Stop (mạch cứng): Thời_gian_phản_ứng ≈ thời gian đóng/mở relay cơ khí,
thường dưới vài ms — nhỏ hơn hàng chục lần so với luồng phần mềm
VD: robot chạy 1 m/s, luồng phần mềm phản ứng trong 87ms → quãng đường phản ứng ≈ 8.7cm; luồng E-Stop phản ứng trong 5ms → quãng đường phản ứng ≈ 0.5cm — chênh lệch này chính là lý do E-Stop bắt buộc phải là mạch cứng, không thể chấp nhận đi qua chuỗi phần mềm dù chỉ một lớp.
Thông số
| Lớp | Phát hiện gì | Phản ứng | Phụ thuộc phần mềm? |
|---|---|---|---|
| LiDAR + Nav2 costmap | Vật cản từ xa | Tính lại đường đi, giảm tốc | Có — toàn bộ |
| Camera + YOLO | Phân loại vật cản (người/vật) | Điều chỉnh khoảng cách an toàn | Có — toàn bộ |
| Bumper | Va chạm vật lý thực tế | Dừng khẩn cấp | Một phần (thường vẫn qua firmware, nhưng ưu tiên cao) |
| E-Stop | Người vận hành bấm nút | Cắt nguồn động cơ | Không — mạch cứng thuần tuý |
Ứng dụng thực tế
Cả hai robot Mecanum và Atlas A2 trong phần showcase dự án của trang này đều có nút E-Stop vật lý riêng biệt trên khung — không phải tính năng phần mềm, mà là một mạch điện độc lập nối thẳng vào đường cấp nguồn động cơ. Bài Giới hạn gia tốc đã nói "dừng ngay lập tức" trong phần mềm bình thường có nghĩa là giảm tốc dần theo gia tốc âm tối đa — không phải dừng tức thời. Trong tình huống thực sự nguy hiểm (người đứng ngay trước robot, robot mất kiểm soát), thời gian giảm tốc dần đó — dù chỉ vài trăm mili-giây — vẫn là quá lâu.
Ví dụ thực tế
Kịch bản: robot AMR di chuyển 1.2 m/s trong nhà kho, người đột ngột
bước ra từ góc khuất cách robot 1m, LiDAR bị vùng mù bỏ sót (như đã học ở bài LiDAR)
Robot chạm bumper ngay lập tức khi tiếp xúc:
- Nếu chỉ dựa vào phần mềm xử lý tín hiệu bumper: độ trễ ~50-80ms
→ robot vẫn di chuyển thêm ~6-10cm sau khi chạm trước khi dừng hẳn
- Nếu bumper kích hoạt trực tiếp mạch cắt nguồn (không qua phần mềm):
độ trễ ~5ms → robot chỉ di chuyển thêm ~0.6cm sau khi chạm
Kết luận: thiết kế bumper nối trực tiếp mạch cắt nguồn (không chỉ báo hiệu
qua firmware) giảm đáng kể quãng đường robot còn di chuyển sau va chạm
Lỗi thường gặp
- Thiết kế E-Stop đi qua phần mềm xử lý logic — nếu nút E-Stop chỉ gửi tín hiệu để phần mềm "quyết định" có nên dừng hay không, một phần mềm treo hoặc lỗi logic bất kỳ có thể khiến robot không dừng lại kịp lúc cần thiết nhất.
- Coi bumper là lớp phòng thủ chính thay vì lớp cuối cùng — bumper chỉ phát hiện được khi đã thực sự va chạm, luôn nên là lớp dự phòng sau LiDAR/camera, không phải cơ chế né vật cản chính.
- Không kiểm tra định kỳ mạch E-Stop/bumper hoạt động đúng — vì đây là lớp an toàn hiếm khi kích hoạt trong vận hành bình thường, dễ bị bỏ quên kiểm tra định kỳ cho tới khi thực sự cần dùng thì mới phát hiện hỏng.
- Đặt bumper không phủ đủ toàn bộ mép ngoài robot — để lại góc/cạnh không có bumper là điểm mù vật lý, va chạm ở đúng vị trí đó sẽ không được phát hiện bởi lớp phòng thủ cuối cùng này.
Kết luận
Bốn lớp phòng thủ — LiDAR/Nav2, Camera/YOLO, Bumper, E-Stop — không thay thế nhau mà là các tuyến nối tiếp, lớp sau chỉ cần hoạt động khi lớp trước đã thất bại vì bất kỳ lý do gì. Nguyên tắc cốt lõi: độ trễ phản ứng càng thấp thì quãng đường phản ứng càng ngắn, và E-Stop — với độ trễ gần như bằng 0 nhờ bỏ qua hoàn toàn phần mềm — luôn là lớp bảo vệ cuối cùng đáng tin cậy nhất. Đây cũng là bài cuối của chuyên mục Hardware AMR — chuyên mục AMR Drive System tiếp theo đi sâu vào cách các bánh xe và hệ truyền động biến lệnh điều khiển thành chuyển động thực tế.
