Object Detection On-Device Trên Android: Pipeline Sáu Chặng

Bạn gắn camera điện thoại Android lên con robot, model detect chạy ngọt trong demo, rồi ra môi trường thật thì frame trễ thấy rõ và bounding box nhảy loạn giữa các khung. Phần lớn thời gian lỗi không nằm ở model, nó nằm ở pipeline quanh model. Dưới đây là đường đi từ frame CameraX tới lệnh điều khiển, theo hướng dẫn on-device mới trên Dev.to, kèm những chỗ bắt buộc phải chặn dữ liệu rác.

Chạy local được gì so với gọi API

Lý do kỹ thuật rất thẳng: theo bài gốc, "Android can perform edge inference locally, reducing dependency on network connectivity" — inference nằm ngay trên máy nên pipeline không chết theo chất lượng mạng. Với robot hoặc camera đặt ngoài xưởng, đó là khác biệt giữa "chậm một nhịp" và "mất perception hoàn toàn".

Sáu chặng, đừng gộp

Kiến trúc bài gốc đề xuất: CameraX → Preprocessing → Object Detection Model → Postprocessing → Detection Results → Robot Perception Gateway. Gộp preprocessing vào analyzer hay để navigation đọc thẳng output model là hai lỗi làm bạn không debug được chặng nào đang chậm.

Đóng detector sau một interface

Bài gốc định nghĩa một data class Detection gồm label, confidence và bốn cạnh box, với lý do rõ ràng: "This keeps the rest of the application independent from a particular model runtime". Runtime thì để mở — "Possible mobile inference approaches include TensorFlow Lite or ONNX Runtime, depending on the model and deployment requirements". Ví dụ minh hoạ:

interface ObjectDetector {
    suspend fun detect(frame: ImageFrame): List<Detection>
}

Analyzer phải chạy async, và khi ưu tiên độ phản hồi thì bỏ frame cũ thay vì xử lý cho đủ: bài gốc gọi đây là "latest-frame strategy when real-time responsiveness is more important than processing every frame".

Lọc trước khi navigation nhìn thấy dữ liệu

Hai bộ lọc bắt buộc. Thứ nhất là ngưỡng confidence — bài gốc lọc ở confidence >= 0.6f nhưng nói thẳng rằng ngưỡng "should be evaluated against the target environment rather than chosen arbitrarily", tức 0.6 là điểm khởi đầu để đo, không phải hằng số chép về. Thứ hai là NMS, vì "Detection models may produce overlapping predictions" — và phải dùng đúng hàm postprocessing mà model của bạn kỳ vọng.

Perception tách khỏi control

Chuỗi mà bài gốc khuyến nghị là Camera → Object Detection → Perception State → Navigation/Behavior → Safety Controller → Robot, với lập luận "This separation makes the system easier to test and safer to operate". Detection gửi sang robot dưới dạng payload gọn, ví dụ {"label":"person","confidence":0.94,"bbox":[120,80,350,500]}. Lưu ý quan trọng cho ai định điều hướng bằng box: bài gốc nhắc phải kết hợp đo vật lý như depth hoặc LiDAR "when distance matters" — bounding box không phải cảm biến khoảng cách.

Thêm một tầng tracking giữ object ID qua các frame sẽ "reduce redundant processing and provide temporal context" — đỡ được cả CPU lẫn hiện tượng ID nhảy.

Tối ưu và test cái thực sự làm pipeline vỡ

Danh sách tối ưu trong bài gốc đáng dán lên tường: chọn model đúng kích cỡ, giảm input resolution khi chấp nhận được, reuse buffer, tránh copy bitmap, đẩy inference khỏi main thread, drop frame cũ, và đo end-to-end latency. Bộ test thì đi theo điều kiện thật: vật tĩnh, người di chuyển, nhiều vật, sáng gắt, tối, che một phần, camera rung, và device thermal throttling — hạng mục cuối là thứ hay giết demo mobile sau vài phút chạy liên tục.

Làm gì trước

Đo end-to-end latency trước khi đổi model: nếu chưa có số, mọi tối ưu chỉ là cảm giác. Sau khi pipeline ổn định, nền Kotlin + CameraX + mobile runtime này có thể nối tiếp sang ROS 2, sensor fusion và navigation theo đúng hướng bài gốc mô tả.