Bối cảnh và vấn đề nghiên cứu

Quá trình đô thị hóa diễn ra nhanh chóng tại các đô thị lớn ở Việt Nam kéo theo sự gia tăng áp lực giao thông trên các tuyến đường huyết mạch và nút giao lộ đông đúc. Tình trạng ùn tắc giao thông ảnh hưởng trực tiếp đến sinh hoạt, môi trường sống của người dân và làm chậm sự phát triển kinh tế - xã hội. Bên cạnh hạn chế về hạ tầng kỹ thuật và sự gia tăng số lượng phương tiện, ý thức chấp hành luật giao thông còn tạo thêm nhiều phức tạp cho công tác điều tiết luồng di chuyển. Trong bối cảnh đó, việc phát triển các Hệ thống Giao thông Thông minh (Intelligent Transportation System - ITS) trở thành nhu cầu cấp thiết. Trong ITS, bài toán đếm và thống kê lưu lượng phương tiện từ luồng video của camera giám sát đô thị là tác vụ cốt lõi thuộc lĩnh vực Thị giác máy tính, cung cấp dữ liệu nền tảng phục vụ việc điều tiết đèn tín hiệu và tối ưu hóa hạ tầng.

Bài toán nghiên cứu trong khóa luận được xác định cụ thể với các thành phần dữ liệu vào và ra:

  • Đầu vào: Luồng video hoặc video stream trực tiếp thu từ hệ thống camera giao thông thành phố, kèm theo thông tin về vùng quan sát (Region of Interest - ROI) được định nghĩa dưới dạng đa giác và các hướng di chuyển cần quan tâm (Movement of Interest - MOI).
  • Đầu ra: Số lượng từng loại phương tiện đã di chuyển theo các hướng định trước, ghi nhận chính xác mốc thời gian phương tiện rời khỏi vùng ROI.
  • Phân loại đối tượng: Gồm 4 nhóm phương tiện lưu thông đặc thù tại Việt Nam: (1) Xe đạp, xe máy; (2) Xe ô tô, xe bán tải; (3) Xe buýt, xe khách; (4) Xe tải và container.

Tác giả xác định hai thách thức nghiên cứu lớn:

  1. Thách thức về phương pháp: Hệ thống đếm xe theo quy trình gồm nhiều bước liên tiếp, trong đó độ chính xác của từng mắt xích ảnh hưởng trực tiếp đến kết quả chung. Việc lựa chọn và tối ưu hóa giải pháp cho từng bước là yếu tố quyết định hiệu quả tổng thể.
  2. Thách thức về dữ liệu và tính toán: Bối cảnh giao thông Việt Nam có mật độ phương tiện dày đặc, độ che khuất cao, chất lượng hình ảnh từ camera đô thị không ổn định và tốc độ khung hình thấp (khoảng 10 FPS). Đồng thời, hệ thống cần giải quyết bài toán xử lý dữ liệu lớn theo thời gian thực (real-time) từ hàng trăm camera cùng lúc mà không bị nghẽn tài nguyên phần cứng.

Mục tiêu nghiên cứu của khóa luận được phân định thành ba nhiệm vụ:

  1. Tìm hiểu tổng quan và thực hiện đánh giá toàn diện bài toán thống kê lưu lượng giao thông trên video, tập trung vào ba bài toán con: phát hiện phương tiện, truy vết phương tiện và đếm phương tiện theo hướng di chuyển.
  2. Đánh giá, phân tích và thực nghiệm so sánh các phương pháp học sâu tiên tiến cho bài toán bằng các độ đo tiêu chuẩn học thuật.
  3. Thiết kế và triển khai kiến trúc hệ thống xử lý phân tán có khả năng đáp ứng yêu cầu thời gian thực bằng việc tích hợp công nghệ Apache Kafka.

Phạm vi nghiên cứu:

  • Không gian và dữ liệu: Dữ liệu hình ảnh và video thu thập thực tế tại địa bàn Thành phố Hồ Chí Minh, kết hợp từ nguồn Hội thi Giải pháp Trí tuệ Nhân tạo trên địa bàn TP.HCM năm 2020 (HCMC AI Challenge 2020) và cổng thông tin giao thông trực tuyến của thành phố (giaothong.hochiminhcity.gov.vn).
  • Môi trường thử nghiệm phân tán: Hệ thống truyền tải phân tán được thiết lập và đánh giá trên cụm phần cứng gồm 4 nút CPU (mỗi nút trang bị 8 nhân Intel Xeon Silver 4210).

Cơ sở lý thuyết và phương pháp

Khóa luận tiếp cận bài toán thống kê lưu lượng phương tiện thông qua khuôn khổ Phát hiện - Theo vết - Đếm (Detection - Tracking - Counting, viết tắt là DTC). Khung DTC cho phép khắc phục hạn chế của các phương pháp đếm xe truyền thống trên từng khung hình đơn lẻ (vốn dễ bỏ sót phương tiện do che khuất) bằng cách duy trì định danh của đối tượng qua chuỗi khung hình liên tiếp.

Về mặt lý thuyết, tác giả hệ thống hóa các nhóm mô hình và công nghệ sau:

  • Phát hiện vật thể (Vehicle Detection): Phân tích hai hướng tiếp cận chính:
    • Mô hình hai giai đoạn (Two-stage): Sử dụng Mạng đề xuất vùng (Region Proposal Network - RPN) để định vị đối tượng trước khi phân loại. Khóa luận khảo sát đại diện tiêu biểu là Faster R-CNN với hai cấu trúc mạng xương sống (backbone) ResNet-50 FPN và ResNet-101 FPN.
    • Mô hình một giai đoạn (One-stage): Bỏ qua bước tạo vùng đề xuất riêng biệt, dự đoán trực tiếp tọa độ hộp bao (bounding box) và lớp đối tượng thông qua lưới ô (grid) và neo (anchors). Hai đại diện được đưa vào thử nghiệm là YOLOv4 và YOLOv5s.
  • Theo vết đa đối tượng (Vehicle Tracking): Khảo sát các thuật toán theo vết trực tuyến như SORT (Simple Online and Realtime Tracking), DeepSORT và FairMOT. Trong đó, SORT được lựa chọn làm giải pháp nền tảng kết hợp bộ lọc Kalman Filter và thuật toán Hungarian để liên kết vị trí đối tượng giữa các khung hình liên tiếp.
  • Công nghệ xử lý dữ liệu phân tán: Khảo sát kiến trúc Microservices và hệ thống hàng đợi thông điệp phân tán Apache Kafka. Kafka hoạt động theo mô hình Publisher/Subscriber với cơ chế đẩy (push) từ Producer đến các Kafka Broker và cơ chế kéo (pull) từ Consumer, cho phép điều tiết thông lượng xử lý và mở rộng linh hoạt theo chiều ngang.

Phương pháp nghiên cứu thực nghiệm được tiến hành thông qua các bước:

  1. Xây dựng bộ dữ liệu: Thu thập, trích xuất khung hình và gán nhãn dữ liệu chuẩn hóa theo định dạng Pascal VOC cho bài toán nhận diện xe tại TP.HCM.
  2. Thực nghiệm huấn luyện mô hình: Huấn luyện và tinh chỉnh (fine-tune) các mô hình phát hiện trên phần cứng GPU chuyên dụng với cùng điều kiện tham số cấu hình.
  3. Đo lường và đánh giá:
    • Đánh giá mô-đun phát hiện qua các độ đo: Độ chính xác trung bình (mAP), mAP tại ngưỡng IoU 0.50 (AP50), AP tại ngưỡng 0.75 (AP75) và tốc độ khung hình trên giây (FPS).
    • Đánh giá toàn bộ quy trình đếm xe qua thang đo sai số toàn phương trung bình (Root Mean Square Error - RMSE) trên từng đoạn video thời lượng $A$ giây:

$$\text{RMSE} = \sqrt{\frac{1}{N}\sum_{a,b,c,d} (x_{a,b,c,d} - y_{a,b,c,d})^2}$$

Trong đó, $x_{a,b,c,d}$ là số lượng phương tiện thực tế của loại phương tiện $a$, hướng di chuyển $b$, trong đoạn thời gian $c$ của video $d$; $y_{a,b,c,d}$ là số lượng phương tiện tương ứng do hệ thống dự đoán.

Thiết kế và triển khai

Hệ thống được thiết kế theo kiến trúc Microservices kết hợp tầng trung gian truyền thông điệp Apache Kafka, bao gồm 6 mô-đun độc lập:

  1. Mô-đun tiền xử lý ảnh (Preprocessing): Nhằm giảm tải tính toán cho GPU, mô-đun thực hiện thuật toán tính khung hình trung bình từ 1.000 khung hình đầu tiên của video để xác định nền đường tĩnh lúc vắng xe. Với mỗi khung hình mới, thuật toán tính sai phân giữa khung hình hiện tại và khung hình trung bình; nếu mức chênh lệch nhỏ hơn ngưỡng xác định, khung hình sẽ được gắn nhãn trống và loại bỏ khỏi bước xử lý học sâu.
  2. Mô-đun phát hiện phương tiện (Detection): Đóng gói mô hình YOLOv4 trong môi trường container Docker sử dụng thư viện PyTorch, chịu trách nhiệm nhận khung hình từ hàng đợi, thực thi suy luận để trả về tọa độ hộp bao và nhãn phân loại của 4 nhóm xe.
  3. Mô-đun theo vết phương tiện (Tracking): Triển khai thuật toán SORT với các tinh chỉnh tham số chuyên biệt cho bối cảnh giao thông Việt Nam:
    • Tham số max_iou_distance được điều chỉnh từ giá trị mặc định 0.7 xuống 0.2. Thay đổi này giúp thuật toán thích ứng với luồng camera có FPS thấp (10 FPS) và hiện tượng video bị nhòe, giật, khiến độ dịch chuyển của xe giữa hai khung hình liên tiếp tăng đột biến.
    • Tham số max_age được giảm từ 30 xuống 1. Việc chỉ cho phép thuật toán chờ đối tượng tái xuất hiện trong tối đa 1 khung hình giúp ngăn chặn hiện tượng tráo đổi hoặc gán nhầm định danh (track ID) cho các xe di chuyển sát phía sau trong điều kiện mật độ phương tiện dày đặc.
  4. Mô-đun đếm phương tiện (Counting):
    • Xác định hướng di chuyển (MOI): Thay vì tính khoảng cách Euclide giữa các điểm đầu - cuối của quỹ đạo xe và đường MOI mẫu, tác giả áp dụng phép đo độ tương đồng Cosine (Cosine Similarity) giữa vector quỹ đạo di chuyển thực tế và vector MOI định nghĩa trước.
    • Xác định thời điểm rời vùng ROI: Tác giả thay thế phương pháp kiểm tra tọa độ tâm hộp bao bằng phương pháp tính diện tích phần giao nhau (overlap/intersection) giữa hộp bao phương tiện và đa giác ROI. Giải pháp này khắc phục triệt để tình trạng các phương tiện kích thước lớn (như xe tải, container) bị ghi nhận rời vùng ROI quá sớm khi thân xe vẫn còn nằm trong khu vực quan sát.
  5. Mô-đun tích hợp (Integration Layer): Xây dựng trên nền tảng Flask, đóng vai trò điều phối luồng dữ liệu giữa các dịch vụ xử lý nền tảng và giao diện người dùng, đồng thời tổng hợp kết quả thống kê.
  6. Mô-đun giao diện người dùng (Frontend): Ứng dụng web hiển thị các chỉ số lưu lượng phương tiện theo thời gian thực, trực quan hóa biểu đồ phân bố phương tiện theo từng hướng di chuyển và từng camera cụ thể.

Hệ thống điều phối dữ liệu thông qua 5 chủ đề (Topics) trên cụm Kafka:

  • Raw frames: Lưu trữ các khung hình trích xuất trực tiếp từ luồng stream của camera giao thông, được tiêu thụ bởi mô-đun tiền xử lý.
  • Processed frames: Chứa các khung hình đã qua chọn lọc của mô-đun tiền xử lý, cung cấp cho mô-đun phát hiện và theo vết.
  • Detection results: Chứa tọa độ hộp bao và nhãn phân loại của các phương tiện được phát hiện trong khung hình.
  • Tracking results: Chứa chuỗi định danh và lịch sử tọa độ quỹ đạo của phương tiện qua thời gian, cung cấp cho mô-đun đếm.
  • Counting results: Chứa số lượng phương tiện đã hoàn thành hành trình, phân loại theo nhóm xe, hướng MOI và mốc thời gian rời ROI.

Nội dung chính theo từng chương

Chương 1: Đặt vấn đề

Chương này giới thiệu tổng quan về thực trạng giao thông đô thị tại Việt Nam, nêu bật sự cần thiết của hệ thống quản lý giao thông thông minh và bài toán thống kê lưu lượng xe tự động từ camera. Tác giả định nghĩa bài toán đếm xe theo hướng di chuyển định trước (MOI) và vùng quan sát (ROI), nêu rõ các ràng buộc kỹ thuật tại Việt Nam gồm tốc độ khung hình video thấp (10 FPS) và mật độ phương tiện hỗn hợp dày đặc. Chương này cũng xác định mục tiêu nghiên cứu, phạm vi dữ liệu, cụm phần cứng thử nghiệm và tóm lược các đóng góp khoa học của đề tài.

Chương 2: Cơ sở lý thuyết

Chương 2 phân tích cơ sở khoa học và khảo sát các nghiên cứu liên quan đến bài toán đếm xe. Nội dung tập trung làm rõ:

  • Nguyên lý hoạt động của các mạng nơ-ron phát hiện đối tượng one-stage (YOLO, SSD) và two-stage (R-CNN, Fast R-CNN, Faster R-CNN).
  • Cơ chế của các giải pháp theo vết đa đối tượng (SORT, DeepSORT, FairMOT).
  • Tổng quan về kiến trúc phần mềm hướng dịch vụ siêu nhỏ (Microservices) và hệ thống truyền tải thông điệp phân tán Apache Kafka, phân tích các mô hình giao tiếp đẩy/kéo (push/pull), cấu trúc cụm máy chủ Broker và khái niệm phân vùng (partition).

Chương 3: Phương pháp hoàn chỉnh cho bài toán đếm phương tiện giao thông dựa trên khuôn khổ DTC

Chương 3 trình bày chi tiết quy trình xử lý kỹ thuật đề xuất theo 4 bước liên hoàn:

  • Tiền xử lý: Cơ chế trích xuất nền tĩnh bằng trung bình 1.000 khung hình ban đầu và thuật toán lọc bỏ khung hình không có phương tiện.
  • Phát hiện phương tiện: Quy trình áp dụng các mô hình học sâu đã tiền huấn luyện trên tập dữ liệu COCO và tinh chỉnh trên bộ dữ liệu giao thông thực tế UIT-VD10k.
  • Theo vết phương tiện: Phân tích nguyên nhân các lỗi thực tế (đường vết rối loạn, tráo định danh) và chi tiết việc thiết lập lại các tham số max_iou_distance = 0.2 và max_age = 1 trong SORT.
  • Đếm phương tiện: Kỹ thuật đối sánh quỹ đạo bằng Cosine Similarity và thuật toán kiểm tra phương tiện rời ROI dựa trên tỷ lệ giao cắt diện tích hộp bao.

Chương 4: Đánh giá và phân tích

Chương 4 công bố kết quả thực nghiệm chi tiết:

  • Phân tích đặc điểm của bộ dữ liệu thực nghiệm UIT-VD10k với 10.000 ảnh gán nhãn chuẩn Pascal VOC. Số liệu thống kê cho thấy sự mất cân bằng nghiêm trọng giữa các lớp đối tượng khi nhóm xe đạp, xe máy chiếm tới 121.814 nhãn (gần 80%), trong khi ô tô chiếm 37.370 nhãn và xe tải/container chỉ có 12.187 nhãn.
  • Đánh giá so sánh hiệu năng giữa các kiến trúc phát hiện (YOLOv4, YOLOv5s, Faster R-CNN R50 FPN, Faster R-CNN R101 FPN) trên tập kiểm thử 1.200 ảnh.
  • Phân tích mối tương quan giữa độ chính xác và tốc độ thực thi (FPS), qua đó chứng minh tính tối ưu của mô hình YOLOv4 đối với yêu cầu thời gian thực.
  • Đánh giá độ chính xác tổng thể của quy trình DTC thông qua kết quả xếp hạng sai số RMSE tại cuộc thi HCMC AI Challenge 2020.

Chương 5: Xây dựng hệ thống thống kê lưu lượng giao thông

Chương này tập trung vào thiết kế kỹ thuật và đo lường tải của hệ thống hoàn chỉnh:

  • Mô tả kiến trúc tích hợp các container Microservices với cụm phân tán Apache Kafka.
  • Quy định cấu trúc dữ liệu truyền tải trên 5 chủ đề Kafka (Topics).
  • Trình bày thiết kế giao diện web frontend hỗ trợ theo dõi trực quan dữ liệu đếm xe.
  • Đánh giá hiệu năng chịu tải: Thực nghiệm chứng minh giải pháp sử dụng Apache Kafka làm tầng đệm thông điệp giúp loại bỏ độ trễ bắt tay của REST API, tăng tốc độ xử lý tổng thể lên 3,55 lần so với kiến trúc Microservices truyền thống.

Chương 6: Kết luận và hướng phát triển

Chương cuối cùng tổng kết các kết quả đạt được về mặt phương pháp thuật toán, bộ dữ liệu và kiến trúc phân tán. Đồng thời, tác giả chỉ ra các hạn chế còn tồn đọng liên quan đến dữ liệu mất cân bằng và chất lượng video đô thị, từ đó phác thảo các định hướng nghiên cứu tiếp theo nhằm nâng cấp hệ thống.

Kết quả và đóng góp

Khóa luận đã tiến hành các thực nghiệm định lượng trên tập dữ liệu UIT-VD10k (chia theo tỷ lệ 8.800 ảnh huấn luyện và 1.200 ảnh kiểm thử). Các mô hình được huấn luyện trên 1 GPU NVIDIA GTX-2080 12GB trong 300 epoch, kích thước batch-size 64, tốc độ học (learning rate) 0.0000125, số lượng luồng nạp dữ liệu (workers) là 8, kích thước ảnh đầu vào 640x640.

Bảng 1: Thông số cấu hình và quy mô các mô hình phát hiện đối tượng

Thông số YOLOv4 YOLOv5s Faster R-CNN
Số lượng tham số 27 triệu 7,5 triệu 60 triệu
Kích thước đầu vào 640x640 640x640 640x640
Tốc độ học (Lr) 0.0000125 0.0000125 0.0000125
Batch size 64 64 64
Số Epoch 300 300 300
Số Workers 8 8 8

Bảng 2: Kết quả thực nghiệm của các mô hình phát hiện phương tiện trên tập kiểm thử

Phương pháp mAP mAP@50 Tốc độ xử lý (FPS)
Faster R-CNN R50 FPN 58,5 73,0 6
Faster R-CNN R101 FPN 47,8 Chưa công bố 4
YOLOv4 Tiệm cận Faster R-CNN Cao hơn YOLOv5s 104
YOLOv5s Thấp hơn YOLOv4 Thấp hơn YOLOv4 109

Kết quả chi tiết về độ chính xác trung bình (AP) theo từng lớp của mô hình Faster R-CNN R50 FPN đạt mức cao nhất ở nhóm Xe máy (86,4%) và Xe hơi (64,1%), trong khi Faster R-CNN R101 FPN chỉ đạt lần lượt 46,3% và 44,8%.

Mặc dù Faster R-CNN R50 FPN đạt độ chính xác mAP cao nhất (58,5%), tốc độ thực thi chỉ đạt 6 FPS, không đáp ứng yêu cầu xử lý thời gian thực đối với mặt bằng luồng camera (chuẩn 10 FPS). Ngược lại, YOLOv4 đạt tốc độ 104 FPS với kích thước mô hình 27 triệu tham số, dung hòa tốt nhất giữa độ chính xác và tốc độ thực thi, do đó được chọn làm mô hình triển khai chính thức.

Về mặt đánh giá toàn diện hệ thống đếm xe trên dữ liệu video thực tế, phương pháp dựa trên khuôn khổ DTC của tác giả đã được kiểm nghiệm trên tập kiểm thử Test Set B của cuộc thi HCMC AI Challenge 2020.

Bảng 3: Kết quả sai số RMSE trên Test Set B tại HCMC AI Challenge 2020

Thứ tự Đội thi Đơn vị Điểm sai số (RMSE)
1 Team036 (Đề tài khóa luận) Trường ĐH Công nghệ Thông tin - ĐHQG-HCM 1,39
2 Team056 Trường ĐH Khoa học Tự nhiên - ĐHQG-HCM 1,60
3 Team006 Trường ĐH Quốc tế - ĐHQG-HCM 1,85
4 Team111 Trường ĐH Khoa học Tự nhiên - ĐHQG-HCM 2,10
5 Team015 VinAI 2,19

Phương pháp của tác giả đạt sai số RMSE thấp nhất (1,39), giành giải Nhì chung cuộc và đạt độ chính xác cao nhất trong toàn bộ các đội tham gia.

Các đóng góp chính được tác giả công bố bao gồm:

  1. Xây dựng bộ dữ liệu UIT-VD10k gồm 10.000 ảnh độ phân giải 1080x720 trích xuất từ 10 góc quay camera tại TP.HCM, được gán nhãn chi tiết theo định dạng Pascal VOC cho 4 nhóm phương tiện.
  2. Đề xuất quy trình đếm xe hoàn chỉnh dựa trên khung DTC với các cải tiến về ngưỡng lọc SORT, đối sánh MOI bằng Cosine Similarity và thuật toán thoát ROI theo diện tích giao cắt. Giải pháp đạt giải Nhì HCMC AI Challenge 2020, đạt giải Ba tại Giải thưởng Sinh viên Nghiên cứu khoa học - Euréka năm 2021 và được chấp nhận công bố tại hội nghị quốc tế MAPR 2021.
  3. Thiết kế kiến trúc phân tán tích hợp Apache Kafka với 4 nút CPU Intel Xeon Silver 4210, giúp tăng tốc độ xử lý dữ liệu luồng lên gấp 3,55 lần so với kiến trúc Microservices truyền thống sử dụng REST API.

Hạn chế và hướng nghiên cứu tiếp

Khóa luận ghi nhận các hạn chế kỹ thuật xuất phát từ phạm vi nghiên cứu và đặc thù dữ liệu thực tế:

  • Bộ dữ liệu UIT-VD10k ghi nhận sự mất cân bằng dữ liệu nghiêm trọng giữa các nhóm phương tiện, trong đó lớp xe đạp và xe máy chiếm gần 80% tổng số lượng mẫu (121.814 nhãn). Tình trạng này tạo ra thách thức lớn cho việc tối ưu hóa độ chính xác đối với các lớp phương tiện có tần suất xuất hiện thấp như xe buýt, xe khách và xe container.
  • Chất lượng luồng video từ hệ thống camera giao thông đô thị thực tế có độ phân giải và độ ổn định không đồng đều, tốc độ khung hình thấp (chỉ đạt 10 FPS), xuất hiện nhiều hiện tượng rung lắc, nhòe ảnh và giật khung hình, ảnh hưởng trực tiếp đến độ ổn định của các đường truy vết quỹ đạo.
  • Cụm phần cứng thử nghiệm phân tán mới dừng lại ở quy mô 4 nút tính toán CPU mô phỏng.

Hướng phát triển tiếp theo được tác giả đề xuất:

  • Mở rộng quy mô thử nghiệm phân tán với số lượng lớn hơn các nút Broker và nút tính toán GPU để kiểm tra giới hạn chịu tải của hệ thống trước hàng trăm luồng camera thực tế.
  • Bổ sung và cân bằng dữ liệu cho các nhóm phương tiện kích thước lớn nhằm cải thiện độ chính xác phân loại của mô hình phát hiện.

Giá trị tham khảo

Báo cáo khóa luận cung cấp tài liệu tham khảo cho sinh viên, học viên cao học và kỹ sư thuộc các chuyên ngành Khoa học máy tính, Công nghệ thông tin, Trí tuệ nhân tạo và Kỹ thuật phần mềm:

  • Tài liệu phương pháp thực tế: Cung cấp thông số cấu hình thực nghiệm chi tiết và các kỹ thuật xử lý thích ứng cho bài toán theo vết SORT khi làm việc với dữ liệu video FPS thấp và mật độ che khuất cao.
  • Tài liệu kiến trúc hệ thống: Cung cấp mô hình tham chiếu về việc tích hợp Apache Kafka vào quy trình xử lý thị giác máy tính, giải quyết vấn đề nghẽn cổ chai trong giao tiếp liên dịch vụ (inter-service communication) của kiến trúc Microservices xử lý video.
  • Tài nguyên dữ liệu: Bộ dữ liệu UIT-VD10k với 10.000 ảnh gán nhãn là nguồn tham khảo phục vụ các nghiên cứu tiếp theo về nhận diện phương tiện trong điều kiện giao thông tại các đô thị Việt Nam.

Câu hỏi thường gặp

1. Tại sao tác giả phải điều chỉnh tham số max_iou_distance từ 0.7 xuống 0.2 và max_age từ 30 xuống 1 trong thuật toán SORT?

Giá trị mặc định của SORT (max_iou_distance = 0.7 và max_age = 30) được thiết kế cho video tiêu chuẩn (từ 24 FPS trở lên). Video camera giao thông tại TP.HCM chỉ đạt 10 FPS, hình ảnh hay bị nhòe và giật, khiến khoảng cách của đối tượng giữa hai khung hình liên tiếp chênh lệch lớn; việc giảm max_iou_distance xuống 0.2 giúp siết chặt điều kiện ghép nối, tránh hiện tượng đường quỹ đạo bị rối loạn. Đồng thời, do mật độ giao thông dày đặc, việc để max_age = 30 khiến thuật toán chờ đợi quá lâu khi một phương tiện bị mất dấu, dẫn đến lỗi gán nhầm định danh (track ID) của phương tiện đó cho một phương tiện khác di chuyển ngay phía sau. Việc hạ max_age = 1 giúp triệt tiêu hiện tượng truyền nhầm định danh này.

2. Vì sao Faster R-CNN đạt độ chính xác mAP cao nhất nhưng không được chọn làm mô hình triển khai chính cho hệ thống?

Trong kết quả thực nghiệm, mô hình Faster R-CNN R50 FPN đạt mAP cao nhất (58,5%), tuy nhiên tốc độ xử lý chỉ đạt 6 FPS (và bản R101 FPN chỉ đạt 4 FPS). Mặt bằng chung tốc độ ghi hình của camera giao thông TP.HCM là 10 FPS. Do đó, Faster R-CNN không đáp ứng được điều kiện tiên quyết của đề tài là xử lý theo thời gian thực. Tác giả lựa chọn YOLOv4 vì mô hình này đạt tốc độ 104 FPS, có độ chính xác tiệm cận mô hình hai giai đoạn và kích thước tham số cân bằng (27 triệu tham số).

3. Bộ dữ liệu UIT-VD10k được xây dựng từ những nguồn nào và có đặc điểm phân bố dữ liệu ra sao?

Bộ dữ liệu gồm 10.000 ảnh độ phân giải 1080x720, được tổng hợp từ hai nguồn: trích xuất từ 25 video (tổng thời lượng hơn 9 giờ) của cuộc thi HCMC AI Challenge 2020 và ảnh thu thập từ cổng thông tin giao thông TP.HCM (giaothong.hochiminhcity.gov.vn). Dữ liệu bị mất cân bằng lớn: nhóm xe đạp, xe máy chiếm gần 80% (121.814 nhãn), nhóm ô tô và bán tải chiếm 37.370 nhãn, nhóm xe tải và container chiếm 12.187 nhãn.

4. Apache Kafka giải quyết hạn chế gì của kiến trúc Microservices truyền thống sử dụng REST API trong khóa luận?

Kiến trúc Microservices giao tiếp qua các điểm cuối REST API thông thường có nhược điểm là không bảo toàn trạng thái, mỗi thông điệp gửi đi đều phải thực hiện lại quá trình bắt tay ba bước, đồng thời chịu ảnh hưởng bởi thời gian đọc/ghi ổ cứng và độ trễ khứ hồi (round-trip time). Khi xử lý luồng video liên tục từ nhiều camera, giao tiếp REST API gây nghẽn hệ thống. Apache Kafka đóng vai trò hàng đợi đệm phân tán giữa luồng video camera và các mô-đun phân tích, cho phép các tiến trình đẩy/kéo dữ liệu bất đồng bộ với thông lượng cao, giúp tăng tốc độ xử lý của hệ thống lên gấp 3,55 lần.

5. Cách xác định phương tiện rời khỏi vùng quan sát (ROI) được tác giả cải tiến như thế nào?

Ban đầu, tác giả kiểm tra xem tọa độ tâm của hộp bao (bounding box) có nằm trong vùng ROI hay không. Tuy nhiên, cách tiếp cận này gây ra sự bất bình đẳng giữa các loại phương tiện: khoảng cách từ tâm đến mép hộp bao của xe container lớn hơn rất nhiều so với xe máy, dẫn đến việc các xe container bị hệ thống đếm sớm ngay khi phần đuôi xe vẫn chưa ra khỏi ROI. Tác giả đã cải tiến bằng cách tính toán tỷ lệ diện tích phần giao nhau giữa hộp bao và đa giác ROI, chỉ xác nhận phương tiện đã thoát khi toàn bộ thân xe rời khỏi vùng quan sát.

Kết luận

Khóa luận tốt nghiệp của sinh viên Nguyễn Văn Khoa đã xây dựng một giải pháp toàn diện cho bài toán thống kê lưu lượng giao thông theo thời gian thực tại đô thị Việt Nam dựa trên khuôn khổ Phát hiện - Theo vết - Đếm (DTC). Bằng việc tinh chỉnh các thuật toán thị giác máy tính phù hợp với điều kiện video tốc độ khung hình thấp và kết hợp hệ thống truyền tải phân tán Apache Kafka trên kiến trúc Microservices, hệ thống đã giải quyết đồng thời hai thách thức về độ chính xác đếm xe và năng lực chịu tải luồng dữ liệu lớn. Kết quả nghiên cứu được bảo chứng thực nghiệm thông qua giải Nhì tại HCMC AI Challenge 2020 với sai số RMSE 1,39, giải Ba Giải thưởng Euréka 2021 và một công bố khoa học tại hội nghị quốc tế MAPR 2021.