Sensor Fusion cho ADAS: Camera, Radar, LiDAR 2026

Một camera thấy đèn đỏ và chữ trên biển báo rất tốt, nhưng không tự đo khoảng cách đáng tin cậy trong sương mù. Radar đo vận tốc tương đối và hoạt động khá bền trong mưa, nhưng ảnh phản xạ thưa, độ phân giải góc thấp và dễ có nhiễu đa đường. LiDAR cho hình học 3D chính xác, song đắt hơn, thưa ở xa và cũng suy giảm trong điều kiện bị che khuất hay thời tiết khắc nghiệt. Sensor fusion không phải là phép cộng “càng nhiều cảm biến càng an toàn”; đó là cách biến các quan sát không hoàn hảo, không cùng hệ tọa độ và không cùng nhịp thời gian thành một quyết định có thể kiểm chứng.

Sau bài này, bạn có thể chọn kiến trúc cho một chức năng cụ thể: early fusion khi cần giữ tín hiệu gốc và chấp nhận calibration/compute nặng; late fusion khi ưu tiên mô-đun độc lập và degradation rõ ràng; hoặc deep/BEV fusion khi cần perception 3D giàu ngữ nghĩa với ngân sách GPU, dữ liệu và kiểm thử tương xứng. Đây là quyết định về safety case và vận hành, không phải cuộc thi chọn mô hình mới nhất.

Roadmap series

1. Bài 1 — SAE Level 2 vs 2+ vs 3 vs 4: xác định ai chịu trách nhiệm lái, ODD và fallback.
2. Bài 2 — Sensor fusion: dùng camera, radar và LiDAR để xây dựng perception có thể suy giảm an toàn khi cảm biến không hoàn hảo.

Trước tiên: fusion đang hợp nhất cái gì?

Một pipeline ADAS điển hình nhận frame camera, point cloud LiDAR, radar detections/point cloud, IMU, GNSS và tín hiệu xe. Riêng bài này tập trung perception ngoài xe. Trước khi “fusion”, phải làm ba việc nền tảng:

• Đồng bộ thời gian: một xe đi 20 m/s thì lệch 50 ms đã dịch chuyển khoảng 1 m. Timestamp, latency của mạng cảm biến, rolling shutter camera và việc bù ego-motion đều quan trọng.
• Đăng ký không gian: extrinsic calibration trả lời camera/radar/LiDAR nằm ở đâu, quay thế nào so với thân xe; intrinsic calibration mô tả ống kính. Sai vài pixel hoặc vài centimet có thể ghép nhầm xe với làn bên cạnh.
• Định nghĩa uncertainty: mỗi detector không chỉ nên phát hộp 3D mà còn cần confidence, covariance hoặc ít nhất trạng thái “không chắc”. Fusion không nên biến một quan sát yếu thành một kết luận chắc chắn.

Hãy phân biệt ba cấp dữ liệu. Raw data là pixel, chirp/range-Doppler hoặc điểm 3D. Feature là tensor do encoder học được. Object/track là danh sách xe, người đi bộ, làn đường cùng vị trí, vận tốc, lớp và độ tin cậy. Early, late và deep/BEV fusion khác nhau chủ yếu ở cấp nào được gặp nhau.

Kiến trúc 1: early fusion — hợp nhất sớm ở dữ liệu hoặc feature thấp cấp

Trong nghĩa chặt, early fusion đưa dữ liệu của các cảm biến vào cùng một biểu diễn trước khi detector kết luận. Ví dụ: project màu/feature của camera lên từng điểm LiDAR đã calibration, hoặc rasterize radar và LiDAR thành lưới chung rồi cho một network xử lý. Một biến thể thực dụng gọi là feature-level early fusion: camera encoder và radar/LiDAR encoder vừa trích xuất feature nông đã concatenate/cross-attend, trước detection head.

camera pixels ──┐  calibrate + time align  ┌─ shared encoder ─ detection / segmentation
LiDAR points ──┼───────────────────────────┤
radar returns ─┘                           └─ (một biểu diễn chung)

Điểm mạnh. Model có cơ hội học tương quan rất sớm: texture của đèn giao thông, hình học mép xe từ LiDAR và Doppler từ radar có thể giải thích lẫn nhau. Nếu calibration ổn định, nó giữ được chi tiết mà việc nén thành box ở từng sensor có thể làm mất. Đây là lựa chọn hấp dẫn cho perception chuyên biệt, ví dụ phát hiện vật nhỏ trên một platform có bộ cảm biến cố định và dữ liệu lớn.

Cái giá. Raw modalities không “cùng ngôn ngữ”. Project feature ảnh lên LiDAR phụ thuộc trực tiếp vào điểm LiDAR; nếu LiDAR giảm mạnh, các pixel hữu ích có thể không còn điểm để bám. Paper BEVFusion: A Simple and Robust LiDAR-Camera Fusion Framework nêu rõ hạn chế này của point-level hard association: các phương pháp dựa vào LiDAR queries có thể không xuất prediction khi LiDAR lỗi. Early fusion cũng khuếch đại lỗi calibration/time alignment, khó debug hơn và thường tăng memory bandwidth lẫn latency vì tensor dày phải gặp point cloud thưa ở độ phân giải cao.

Vì vậy, đừng dùng chữ “early” như đồng nghĩa “tốt nhất”. Nó phù hợp khi sự liên kết pixel–point là tài sản cốt lõi, bạn kiểm soát phần cứng/calibration và đánh giá fault injection đã chứng minh lợi ích. Nó rủi ro cho chức năng cần chạy tiếp có ý nghĩa khi một modality biến mất.

Kiến trúc 2: late fusion — mỗi sensor tự hiểu trước, rồi mới hòa giải

Late fusion cho camera, radar và LiDAR chạy detector/segmenter riêng. Sau đó, một association stage ghép các object candidates theo vị trí, thời gian, class và uncertainty; tracker như Kalman filter hoặc multi-hypothesis tracker duy trì trạng thái qua nhiều frame. Quy tắc có thể là weighted averaging, covariance intersection, learned gating hoặc track-to-track fusion.

camera ─ detector ─ boxes + confidence ─┐
LiDAR ─ detector ─ boxes + covariance ──┼─ association / tracker ─ fused tracks
radar ─ detector ─ range + Doppler ─────┘

Điểm mạnh. Đây là kiến trúc dễ giải thích cho một safety review: radar vẫn tạo track vận tốc khi camera lóa; camera vẫn đọc đèn/làn khi LiDAR tạm mất; LiDAR vẫn định vị 3D khi classifier ảnh không chắc. Mỗi branch có thể được monitor về heartbeat, quality và latency. Nếu LiDAR hỏng, fusion engine giảm trọng số hoặc chuyển sang camera–radar policy thay vì vỡ toàn bộ tensor chung. Nó cũng cho phép thay detector camera mà không train lại toàn bộ stack.

Giới hạn. Mỗi detector đã bỏ mất thông tin trước khi fusion: một object quá mờ để camera detector tạo box sẽ không được LiDAR “gợi ý” nhìn lại vùng ảnh đó. Association trở nên khó ở giao lộ đông xe, occlusion, class không khớp, timestamp lệch hoặc khi hai box gần nhau. Chạy ba detector cũng không miễn phí: compute phân tán, NMS và tracking thêm latency. Đừng cộng confidence ngây thơ—ba camera cùng bị mặt trời chiếu có lỗi tương quan, không phải ba bằng chứng độc lập.

Late fusion thường là lựa chọn khởi đầu tốt cho L2/L2+ production ADAS có deadline chặt, đội nhỏ hoặc nhu cầu traceability cao: AEB/ACC có thể ưu tiên radar range-rate, lane keeping ưu tiên camera, còn LiDAR (nếu có) là kênh xác nhận hình học. “Tốt” ở đây là degradation được thiết kế và test được, không phải chỉ mAP cao trên ngày nắng.

Kiến trúc 3: deep/BEV fusion — học một không gian chung có cấu trúc

Deep fusion không đơn thuần là concatenate. Encoders riêng tạo feature, sau đó network học cách gộp bằng convolution, gating hoặc attention. BEV (bird's-eye view) đặc biệt hợp cho lái xe vì biến mọi modality về lưới nhìn từ trên xuống quanh ego vehicle; 3D boxes, làn đường và planning cùng dùng một hệ tọa độ metric.

TransFusion là ví dụ đáng đọc vì nó không ghép cứng từng điểm LiDAR với đúng một pixel ảnh. Theo paper CVPR 2022 và repo mã nguồn, backbone LiDAR tạo BEV; decoder transformer đầu dùng một tập thưa object queries để đề xuất box từ LiDAR; lớp decoder sau cho các query này attention tới image features. “Soft association” cho phép attention chọn ở đâu và thông tin nào của ảnh đáng dùng, thay vì tin tuyệt đối vào phép chiếu calibration. Paper còn có image-guided query initialization để cứu các object khó thấy trong point cloud.

BEVFusion (bản MIT Han Lab) đi theo trực giác khác: camera đa góc đi qua camera encoder rồi view transform vào BEV; LiDAR qua encoder thành BEV; hai feature map được fuse, rồi task heads phục vụ 3D detection hoặc BEV map segmentation. Paper ICRA 2023 báo cáo optimized BEV pooling giảm latency của view transform hơn 40 lần và đạt chi phí tính toán thấp hơn 1,9 lần so với baseline mà paper so sánh—một con số kiến trúc/dataset cụ thể, không phải cam kết FPS cho xe của bạn.

Điểm hay của BEV là camera mang ngữ nghĩa dày (màu, biển báo, loại vật thể), LiDAR mang hình học metric; cả hai gặp nhau trên cùng lưới. Nhưng view transform camera-to-BEV phải dự đoán/phân bổ depth, nên tốn compute và có sai số xa xe. Transformer/cross-attention thêm linh hoạt, song attention lớn, multi-view high resolution và temporal BEV đều đòi hỏi GPU, memory, quantization và profiling kỹ.

Đừng nhầm hai công trình cùng tên. Repo ADLab-AutoDrive/BEVFusion là NeurIPS 2022, nhấn mạnh camera stream độc lập với LiDAR và báo cáo cải thiện 15,7–28,9 mAP trong thiết lập mô phỏng LiDAR malfunction so với các phương pháp đối chiếu. Repo MIT Han Lab là ICRA 2023, nhấn mạnh unified BEV đa nhiệm và pooling hiệu quả. Cả hai đều là tham chiếu hữu ích, nhưng metric chỉ có nghĩa với split, augmentation, sensor suite và failure model đã công bố.

So sánh để chọn, không phải để xếp hạng

Latency phải đo end-to-end, từ exposure timestamp đến message sẵn cho planner: sensor transfer, preprocess, inference, fusion, tracking và scheduling. Một model 25 FPS không mặc định có latency 40 ms; batching, queue và một camera frame chậm có thể làm tuổi dữ liệu lớn hơn nhiều. Đặt budget theo chức năng: cảnh báo điểm mù, AEB, lane centering và robotaxi perception có hazard, tầm nhìn và thời gian phản ứng khác nhau.

Thiết kế cho lỗi: fusion không tự tạo redundancy

Ba tình huống cần test bằng dữ liệu replay lẫn xe thật: (1) sensor mất hoàn toàn; (2) sensor còn sống nhưng nói sai—mưa, lens bẩn, radar ghost, calibration lệch; (3) sensor chậm hoặc timestamp sai. Tình huống (2) nguy hiểm hơn vì một network tự tin có thể kéo fusion đi sai.

Một policy tối thiểu nên có sensor-health monitor độc lập, score chất lượng theo modality, giới hạn tốc độ/chức năng khi confidence giảm và logging để tái tạo quyết định. Với deep fusion, training phải đưa vào modality dropout, image corruption, LiDAR sparsification/misalignment đại diện cho ODD; sau đó báo cáo performance theo từng failure mode, không chỉ điểm trung bình. Với late fusion, kiểm tra correlation trước khi “vote”; với early fusion, kiểm tra hard dependencies trước khi gọi nó là fault tolerant.

Quan trọng: redundancy ở perception chưa đủ cho Level 3 và Level 4. Safety case còn cần compute, nguồn, lái, phanh, minimal-risk maneuver, ODD và vận hành từ xa. Fusion tốt giúp giảm uncertainty; nó không chuyển trách nhiệm pháp lý hay tạo fail-operational vehicle một mình.

Cây quyết định ngắn cho đội kỹ thuật

1. Chức năng có thể chạy hữu ích khi camera hoặc LiDAR mất không? Nếu có, bắt đầu bằng branch độc lập và late fusion/fallback rõ ràng; deep fusion chỉ được chọn sau khi chứng minh modality dropout.
2. Bài toán cần map BEV, 3D detection dày và ngữ nghĩa nhiều camera không? Nếu có, đánh giá BEVFusion-style với benchmark như nuScenes và OpenDRIVEVLA, nhưng profile trên phần cứng mục tiêu.
3. Lỗi calibration hoặc ánh sáng xấu là rủi ro hàng đầu? So sánh hard projection với soft association kiểu TransFusion và chạy perturbation test; đừng chỉ nhìn clean validation.
4. Bạn có đủ dữ liệu đồng bộ, nhãn 3D, GPU và quy trình replay? Nếu chưa, late fusion có thể tạo giá trị sớm hơn một BEV transformer chưa được hiệu chuẩn/giám sát tốt.

Một roadmap lành mạnh thường là: dựng per-sensor baselines và health metrics; triển khai late fusion để có fallback quan sát được; rồi thử deep/BEV fusion như một module được benchmark cùng latency/fault suite. Chỉ dùng early fusion khi lý do giữ raw correspondence mạnh hơn chi phí coupling của nó.

Kết luận

Camera, radar và LiDAR bổ sung cho nhau, nhưng kiến trúc quyết định cách chúng thất bại cùng nhau. Early fusion giữ chi tiết nhưng chịu calibration và dependency nặng. Late fusion hy sinh một phần thông tin để đổi lấy mô-đun độc lập, audit và degradation dễ hiểu. Deep/BEV fusion như BEVFusion và TransFusion khai thác ngữ nghĩa–hình học tốt hơn, nhưng đòi hỏi dữ liệu, compute và thử nghiệm lỗi nghiêm túc. Hãy chọn theo chức năng, ODD, latency budget và behavior khi sensor nói dối hoặc im lặng—không theo tên model.

Bài viết liên quan

• SAE Level 2 vs 2+ vs 3 vs 4
• End-to-end autonomous driving và taxonomy VLA
• OpenDRIVEVLA và dữ liệu nuScenes cho xe tự hành
• Xem tất cả bài viết chủ đề ADAS & xe tự hành