Đang chạy mực qua máy in — từng lớp màu một, kiên nhẫn nhé!
№ 01
№ 02
№ 03
№ 04
№ 05
№ 06
Driver Guard - DMS · AI·20K Demo Day Zine
№ 42
Driver Guard - DMS
Hệ thống theo dõi trạng thái buồn ngủ của tài xế và cảnh báo theo thời gian thực tại thiết bị biên.
Lưu trữ và theo dõi đội xe của người quản lý và cá nhân tài xế.
Fig. 01 · Ảnh dự án
Mô tả tóm tắt dự án DriverGuard Edge
DriverGuard Edge là hệ thống dùng Edge AI để phát hiện dấu hiệu mệt mỏi và mất tập trung của tài xế ngay trong cabin. Hệ thống cảnh báo cục bộ, lưu sự kiện khi offline và chỉ đồng bộ metadata cần thiết lên nền tảng quản lý đội xe khi có mạng.
1. Bài toán và mục tiêu
Tài xế xe khách, xe tải đường dài và xe vận tải thường phải làm việc nhiều giờ, ban đêm hoặc trên tuyến đường đơn điệu. Mệt mỏi, ngủ gật và mất tập trung có thể khiến người lái phản ứng chậm, đi sai làn hoặc không xử lý kịp tình huống bất ngờ. Với doanh nghiệp, rủi ro kéo theo thiệt hại về người, tài sản, hoạt động, bảo hiểm và uy tín.
Theo số liệu trong slide dự án, 11,59% tai nạn liên hoàn liên quan đến xe khách và xe tải đường dài tại Việt Nam có liên quan đến lái xe liên tục, thiếu quan sát, mệt mỏi hoặc ngủ gật; thiệt hại kinh tế do tai nạn giao thông được ước tính khoảng 5% GDP/năm. Slide cũng dẫn số liệu hơn 3.200 người tử vong mỗi năm tại Hoa Kỳ trong các tai nạn liên quan đến mất tập trung. Khi dùng trong hồ sơ chính thức, cần bổ sung nguồn và năm công bố cho các số liệu này.
Giải pháp Cloud hoặc truyền video liên tục có ba hạn chế: phụ thuộc mạng và tạo độ trễ; làm tăng rủi ro quyền riêng tư; chi phí thiết bị, băng thông và lưu trữ cao. Người quản lý đội xe cũng thường chỉ biết sự cố sau khi hành trình kết thúc, thiếu dữ liệu tập trung để theo dõi xu hướng rủi ro.
Đối tượng sử dụng gồm tài xế, doanh nghiệp vận tải/Fleet Manager, bộ phận an toàn, điều hành, bảo trì và lãnh đạo doanh nghiệp. Mục tiêu của dự án là:
Phát hiện sớm dấu hiệu nhắm mắt kéo dài, PERCLOS cao và quay đầu/mất tập trung.
Cảnh báo ngay tại cabin, kể cả khi không có Internet.
Chỉ đồng bộ metadata sự kiện thay vì video khuôn mặt liên tục.
Cung cấp dữ liệu có cấu trúc để theo dõi và cải thiện an toàn đội xe.
Hệ thống chỉ hỗ trợ an toàn, không phải thiết bị y tế và không thay thế trách nhiệm quan sát, nghỉ ngơi hay quyết định của tài xế.
2. Giải pháp kỹ thuật
2.1. Kiến trúc tổng thể
Giải pháp sử dụng kiến trúc Edge-to-Cloud, offline-first. Nhận diện và quyết định cảnh báo quan trọng chạy trên thiết bị trong xe; Cloud chỉ nhận sự kiện đã rút gọn để phục vụ giám sát đội xe.
Camera NoIR/IR → YuNet + 5 landmarks
├→ Eye CNN → lọc temporal → PERCLOS
└→ solvePnP → head pose
↓
Decision Agent
↓
Buzzer/LED cảnh báo tại cabin
↓
Local Event Store
↓ khi có mạng
Backend Cloud → Fleet Dashboard
§
Phụ lục — Demo & Slides
Video demo
Bản demo trực tiếp
Slide trình bày
2.2. Xử lý tại Edge
YuNet: phát hiện khuôn mặt và năm landmarks (hai mắt, mũi, hai khóe miệng).
Eye CNN/TinyEyeNet: cắt hai vùng mắt 64×64, chạy mô hình ONNX để ước lượng mắt mở/nhắm.
Temporal filter: dùng EMA và hysteresis để giảm nhiễu, cảnh báo nhấp nháy và ảnh hưởng của phản sáng.
PERCLOS: tính tỷ lệ thời gian mắt nhắm trong một cửa sổ, loại trừ chớp mắt ngắn để đánh giá xu hướng mệt mỏi.
Head pose: dùng solvePnP để ước lượng yaw/pitch/roll và phát hiện quay đầu, cúi hoặc ngẩng kéo dài.
MVP chỉ phát ra các tín hiệu quan sát được (trạng thái mắt, PERCLOS, hướng đầu và độ tin cậy), không chẩn đoán buồn ngủ theo nghĩa y tế, không suy diễn việc dùng điện thoại từ head pose và chưa hỗ trợ phát hiện điện thoại hoặc ngáp.
2.3. Decision Agent và cảnh báo
Decision Agent áp dụng các ngưỡng và quy tắc thời gian để tạo ba sự kiện MVP:
EYES_CLOSED_LONG: mắt nhắm liên tục quá ngưỡng;
HIGH_PERCLOS: tỷ lệ nhắm mắt trong cửa sổ vượt ngưỡng;
HEAD_AWAY_LONG: đầu lệch khỏi hướng an toàn quá lâu.
Agent quản lý thời điểm bắt đầu/kết thúc, cooldown và mức rủi ro normal, warning, danger. Khi cần cảnh báo, buzzer/LED hoạt động độc lập với Internet. Sự kiện được lưu cục bộ với mã xe/thiết bị, loại sự kiện, thời gian, mức độ, chỉ số liên quan và trạng thái đồng bộ. Cơ chế store-and-forward, retry và idempotency giúp không mất hoặc tạo trùng dữ liệu khi mất mạng.
2.4. Cloud, Dashboard và quyền riêng tư
Backend xác thực thiết bị, tiếp nhận metadata qua HTTPS hoặc MQTT bảo mật, kiểm tra timestamp/chữ ký, chống gửi trùng, quản lý trạng thái online/offline, tổng hợp KPI và phát sự kiện realtime.
Dashboard cung cấp tổng quan đội xe, số xe online/offline, cảnh báo theo xe/tài xế/thời gian/mức độ, bộ lọc, biểu đồ xu hướng mệt mỏi và trạng thái xử lý. Dữ liệu cảnh báo được chuyển thành khuyến nghị vận hành như bố trí nghỉ, đổi ca hoặc kiểm tra thiết bị.
Privacy by Design là yêu cầu kiến trúc:
frame, bounding box, landmarks và ảnh crop mắt không được gửi khỏi Edge theo mặc định;
Cloud chỉ nhận metadata cần thiết, truyền qua TLS và phân quyền theo vai trò;
không cần stream video 24/7 vì cảnh báo vẫn hoạt động offline;
nếu cần lưu ảnh điều tra, phải là tùy chọn có đồng ý, mã hóa, phân quyền và chính sách tự động xóa;
dữ liệu trạng thái tài xế không nên được dùng để kỷ luật tự động chỉ dựa trên một cảnh báo đơn lẻ.
3. Tính khả thi và kết quả hiện có
Các thành phần cốt lõi đã được tích hợp: pipeline YuNet, crop mắt, mô hình ONNX, lọc temporal/PERCLOS, head pose, Decision Agent, hợp đồng JSON CVState/AgentDecision, gói chạy Raspberry Pi 4, benchmark và service systemd.
Các kết quả trên mới là bằng chứng ban đầu, chưa thay thế kiểm thử ngoài thực địa. Benchmark chạy trên Windows cũng không được dùng để tuyên bố hiệu năng trên Raspberry Pi. Kết luận hiện tại: MVP và luồng end-to-end khả thi, nhưng phiên bản Pi 4 chưa sẵn sàng sản xuất; tối ưu hiệu năng và kiểm thử thực tế là ưu tiên cao nhất.
Về vận hành, thiết bị có thể gồm Raspberry Pi/Edge board, camera NoIR, đèn IR, buzzer/LED, bộ nhớ cục bộ và nguồn ổn định. Cần bổ sung watchdog, tự khôi phục camera, giới hạn/xoay vòng log, kiểm tra sức khỏe, cập nhật OTA có chữ ký và bảo vệ nguồn điện.
Về kinh tế, phần cứng phổ thông, xử lý Edge và không truyền video có thể giảm chi phí. Tuy nhiên cần lập BOM và tính tổng chi phí sở hữu gồm phần cứng, lắp đặt, SIM, Cloud, bảo hành, bảo trì và thay thế; hiệu quả nên đo bằng chi phí/xe/tháng, mức giảm rủi ro và thời gian hoàn vốn.
4. Rủi ro chính và giảm thiểu
Rủi ro
Biện pháp
Kính, phản sáng, thiếu sáng, che khuất mặt
Camera IR phù hợp, dữ liệu thực tế, quality gate, trạng thái unknown, hiệu chỉnh ngưỡng
YuNet chậm trên Pi 4
Giảm kích thước detector, detect theo chu kỳ kết hợp tracking, tối ưu/quantize hoặc dùng accelerator/Pi 5
Camera rung hoặc lệch
Giá đỡ cố định, lắp đặt chuẩn, calibration và phát hiện dịch chuyển
Quá nhiều cảnh báo
Hysteresis, cooldown, phân cấp và đánh giá false alarm theo giờ lái
Mất mạng/mất điện
Hàng đợi bền vững, idempotency, retry backoff và nguồn dự phòng ngắn hạn
Lộ dữ liệu tài xế
Metadata-only, TLS, RBAC, audit log, chính sách lưu/xóa và đồng ý minh bạch
5. Lộ trình phát triển
Giai đoạn 1 — Hoàn thiện Edge MVP
Tối ưu face detection bằng input nhỏ hơn, detect theo chu kỳ và tracking; benchmark FP32/INT8 trên đúng Pi 4; hướng tới tối thiểu 15 FPS, p95 latency phù hợp và soak test 45–60 phút. Hoàn thiện buzzer/LED, watchdog, queue cục bộ và kiểm thử ngày/đêm, kính, rung xe, góc camera và nhiều sắc độ da.
Giai đoạn 2 — Pilot Edge-to-Cloud
Chuẩn hóa API/MQTT, TLS, xác thực thiết bị, chống trùng, store-and-forward, quản lý phiên bản và Dashboard đa người dùng. Pilot trên 5–10 xe trong 4–8 tuần, đo uptime, cảnh báo giả/giờ, độ nhạy sự kiện, độ trễ, tỷ lệ đồng bộ và phỏng vấn tài xế/Fleet Manager.
Giai đoạn 3 — Mở rộng nhận diện
Bổ sung module phát hiện ngáp và dùng điện thoại sau khi có dữ liệu đánh giá độc lập; kết hợp thời lượng lái, thời gian trong ngày và lịch nghỉ; cá nhân hóa baseline không lưu ảnh; nghiên cứu NPU/Coral/Pi 5 và OTA model có chữ ký, rollback, giám sát drift.
Giai đoạn 4 — Sản phẩm hóa
Hoàn thiện phần cứng chịu rung/nhiệt/bụi/dao động điện áp, quy trình lắp đặt và bảo trì; đánh giá an toàn điện, tương thích điện từ, an ninh mạng và pháp lý; xây dựng mô hình thương mại; mở rộng pilot theo phương tiện, tuyến đường, khí hậu và tích hợp GPS/telematics qua API.
6. Tiêu chí sẵn sàng pilot
Nhánh mắt/head pose đạt tối thiểu 15 FPS trên thiết bị mục tiêu, không tích tụ frame cũ và không suy giảm trong soak test.
Có báo cáo precision, recall, F1, độ nhạy sự kiện và cảnh báo giả theo điều kiện ánh sáng/kính.
Tự khởi động sau mất điện, tự phục hồi camera, không mất hoặc trùng sự kiện khi mất mạng.
Không gửi ảnh/video mặc định; dữ liệu được mã hóa, phân quyền và có thời hạn lưu rõ ràng.
Cảnh báo đủ rõ nhưng không gây giật mình; Dashboard xác định được xe, thời điểm, loại và mức độ sự kiện.
Có BOM, tổng chi phí sở hữu và bằng chứng pilot cho thấy khả năng giảm rủi ro hoặc chi phí vận hành.
7. Kết luận
DriverGuard Edge đưa quyết định an toàn về ngay trong cabin, không phụ thuộc Internet, giảm xâm phạm riêng tư và hỗ trợ quản lý rủi ro ở quy mô đội xe. MVP hiện đã chứng minh được kiến trúc và luồng hoạt động. Để chuyển thành sản phẩm cần ưu tiên tối ưu Raspberry Pi, kiểm thử dài hạn ngoài thực địa, hoàn thiện phần cứng/cảnh báo/Cloud, chính sách dữ liệu và xác nhận chi phí triển khai. Với một pilot có chỉ số đo lường rõ ràng, dự án có cơ sở để phát triển thành hệ thống hỗ trợ an toàn giao thông triển khai thực tế.
Note:
Tài khoản sử dụng web quản lý : quenten9212@gmail.com Mật khẩu: 9212
Tài khoản sử dụng web kỹ thuật viên : trang12345dt@gmail.com Mật khẩu: 12345
Tài khoản sử dụng tài xế được tạo trong trang của người quản lý đội xe.
