Giới thiệu dự án

Sự gia tăng nhanh chóng của mật độ phương tiện cơ giới tại các đô thị hiện đại đặt ra thách thức nghiêm trọng đối với công tác giám sát, điều phối và đảm bảo an toàn giao thông. Theo thống kê từ Ủy ban An toàn Giao thông Quốc gia và các báo cáo ITS (Intelligent Transportation Systems), việc giám sát thủ công hoặc sử dụng hệ thống ghi hình thụ động không còn đáp ứng được nhu cầu xử lý tức thời các hành vi vi phạm như lấn làn, vượt đèn đỏ, đi sai tốc độ hay tắc nghẽn cục bộ.

Hầu hết các giải pháp thị giác máy tính hiện đại dựa trên mô hình học sâu (Deep Learning) đòi hỏi năng lực tính toán rất lớn, phụ thuộc vào các trạm máy chủ CPU hiệu năng cao hoặc GPU chuyên dụng tiêu tốn công suất từ 150W đến hơn 300W. Việc triển khai các thiết bị này dày đặc tại các nút giao thông ngoài trời gây áp lực lớn về tiêu thụ điện năng, độ tản nhiệt và chi phí hạ tầng. Ngược lại, các vi điều khiển hoặc máy tính nhúng tiêu chuẩn lại thiếu khả năng tính toán song song, dẫn đến độ trễ cao và tỷ lệ khung hình thấp.

+-------------------------------------------------------------------------------+
|                             KIẾN TRÚC TỔNG THỂ HỆ THỐNG                      |
+-------------------------------------------------------------------------------+
|  +---------------------------+             +-------------------------------+  |
|  |     HPS (ARM Cortex-A9)   |  AXI Bridge |      FPGA Fabric (Cyclone V)  |  |
|  | - Linux OS (Kernel 4.1)   | <---------> | - OpenCL Accelerator Kernel   |  |
|  | - Host App (C/C++)        |             | - Custom Tinier YOLO Pipeline |  |
|  | - Pre-processing (Gray)   |             | - GEMM Computing Engine       |  |
|  | - Bounding Box & NMS      |             | - On-chip Memory (M10K/SDRAM) |  |
|  +---------------------------+             +-------------------------------+  |
+-------------------------------------------------------------------------------+

Đề tài "Hệ thống nhận diện phương tiện giao thông trên FPGA" được thực hiện nhằm giải quyết triệt để bài toán tối ưu hóa giữa hiệu năng nhận diện, độ trễ xử lý và mức tiêu thụ năng lượng bằng cách đưa giải thuật học sâu lên nền tảng phần cứng tái cấu trúc SoC-FPGA.

Mục tiêu cụ thể của dự án:

  1. Nghiên cứu, tinh chỉnh và đề xuất kiến trúc mạng nơ-ron tích chập rút gọn Custom Tinier YOLO tối ưu hóa tài nguyên cho thiết bị phần cứng giới hạn.
  2. Xây dựng môi trường nhúng Linux và tích hợp hệ thống điều khiển Heterogeneous Computing thông qua Intel FPGA SDK for OpenCL.
  3. Thu thập, chuẩn hóa và xử lý tập dữ liệu gồm hơn 30.000 ảnh về 3 lớp phương tiện chính tại Việt Nam: xe hơi (Car), xe máy (Motorbike), xe tải (Truck).
  4. Hiện thực hóa giải thuật nhân ma trận tổng quát (GEMM) kết hợp biến đổi im2col/im2row trên logic fabric của kit Terasic DE1-SoC (Cyclone V).
  5. Đạt độ chính xác nhận diện trung bình (AP) từ 80% đến 90% trên tập dữ liệu thực nghiệm với thời gian đáp ứng thời gian thực và công suất tiêu thụ toàn bo mạch dưới 10W.

Phạm vi và giới hạn: Hệ thống tập trung nhận diện 3 nhóm phương tiện phổ biến; dữ liệu ảnh đầu vào được chuyển đổi về kênh xám (Grayscale) kích thước $224 \times 224$ pixel nhằm cắt giảm băng thông truyền nhận bộ nhớ và tối ưu hóa số phép tính dấu chấm động.


Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Các giải pháp nhận diện đối tượng biên (Edge AI) hiện nay trên thị trường phân hóa rõ rệt giữa các nền tảng:

Tiêu chí Máy trạm GPU (NVIDIA RTX) Máy tính nhúng (Jetson Nano) Vi xử lý nhúng (Raspberry Pi 4) Giải pháp SoC-FPGA (DE1-SoC)
Thông lượng (Throughput) Rất cao (>60 FPS) Trung bình (15–25 FPS) Thấp (<5 FPS) Cao (Tối ưu theo pipeline)
Công suất tiêu thụ Rất cao (150W – 350W) Trung bình (5W – 10W) Thấp (3W – 5W) Rất thấp (3W – 8W)
Độ trễ xử lý (Latency) Phụ thuộc truyền dữ liệu Trung bình Rất cao Cực thấp (Xử lý phần cứng trực tiếp)
Khả năng tùy biến phần cứng Không (Cố định ASIC) Không (Cố định GPU core) Không (Cố định CPU core) Rất cao (Lập trình mức logic cell)
Độ tin cậy môi trường khắc nghiệt Kém (Quạt tản nhiệt, nhiệt cao) Trung bình Trung bình Rất cao (Tiêu chuẩn công nghiệp)

Phân loại yêu cầu hệ thống theo mô hình MoSCoW:

  • Must Have: Phát hiện chính xác 3 loại phương tiện (xe hơi, xe máy, xe tải); nạp bitstream .aocx và thực thi kernel OpenCL trơn tru trên Cyclone V; độ chính xác AP $> 80%$.
  • Should Have: Áp dụng biến đổi im2col/im2row để ánh xạ tích chập thành nhân ma trận GEMM; hỗ trợ định dạng số chấm động IEEE 754 Single/Half-Precision; thời gian khởi động Linux nhúng nhanh dưới 15 giây.
  • Could Have: Xử lý luồng video trực tiếp từ camera qua giao tiếp Ethernet/USB Host; cơ chế tự động giải phóng bộ nhớ đệm DMA giữa HPS và FPGA.
  • Won't Have (Giai đoạn này): Nhận diện biển số xe (ALPR); theo dõi đối tượng đa mục tiêu (DeepSORT) trên FPGA Fabric.

Thiết kế hệ thống

Hệ thống được thiết kế theo kiến trúc dị thể Heterogeneous System-on-Chip bao gồm hai khối cốt lõi:

graph TD
    A[Camera / Input Image] --> B[HPS: ARM Cortex-A9 Dual Core]
    subgraph HPS_Linux [HPS - Hệ điều hành Linux]
        B --> C[Pre-processing: Grayscale 224x224]
        C --> D[Host Application C/C++]
        D --> E[OpenCL Runtime / Driver]
    end
    E -- AXI Bus Interface --> F[FPGA Global Memory SDRAM 64MB]
    subgraph FPGA_Fabric [FPGA Fabric - Cyclone V]
        F --> G[OpenCL Compute Unit / Worker Threads]
        G --> H[Processing Element Array: GEMM Engine]
        H --> I[Fire Modules & Passthrough Pipeline]
        I --> G
    end
    G -- Readback Features --> E
    D --> J[Post-processing: Bounding Box & Class Output]

Thông số cấu hình phần cứng và Tech Stack:

  • Bo mạch phần cứng: Terasic DE1-SoC tích hợp SoC Altera Cyclone V 5CSEMA5F31C6.
    • Hard Processor System (HPS): Dual-core ARM Cortex-A9 MPCore @ 800MHz, 1GB DDR3 SDRAM, bộ điều khiển ngoại vi tích hợp.
    • FPGA Fabric: 85,000 Programmable Logic Elements (32,075 ALMs), 4,450 Kbits Embedded Memory (M10K blocks), 87 DSP Blocks hỗ trợ nhân $18 \times 18$ hoặc $27 \times 27$ bit.
  • Môi trường phần mềm và công cụ:
    • OS: Linux Kernel 4.1.22-ltsi xây dựng riêng cho kiến trúc ARMv7.
    • HLS / OpenCL: Intel FPGA SDK for OpenCL version 16.1 / Quartus Prime Standard Edition.
    • Mạng nơ-ron: Darknet Framework hiệu chỉnh, OpenBLAS, OpenCV 3.4.

Phương pháp luận (Methodology)

Dự án áp dụng quy trình phát triển lặp kết hợp phần cứng - phần mềm (Hardware/Software Co-design):

+---------------------------------------------------------------------------------------+
| SPRINT 1: Dữ liệu & Huấn luyện   ==> Thu thập 30K ảnh, gắn nhãn, huấn luyện Darknet   |
| SPRINT 2: Rút gọn mô hình        ==> Thiết kế Custom Tinier YOLO, giảm xuống 18 lớp   |
| SPRINT 3: Xây dựng Linux & BSP   ==> Build U-Boot, Device Tree Blob, RootFS, Driver   |
| SPRINT 4: Tối ưu OpenCL Kernel   ==> Áp dụng GEMM, im2col, tổng hợp bitstream .aocx   |
| SPRINT 5: Kiểm thử & Đánh giá    ==> Benchmark độ trễ, tài nguyên ALM/DSP, độ chính xác|
+---------------------------------------------------------------------------------------+

Implementation và kết quả

Quá trình phát triển và thuật toán cốt lõi

Mô hình Custom Tinier YOLO được phát triển bằng cách loại bỏ các tầng tích chập dư thừa từ YOLOv2-Tiny và chèn kiến trúc Fire Module (kế thừa từ SqueezeNet) nhằm nén tối đa tham số:

  1. Squeeze Layer: Sử dụng bộ lọc tích chập $1 \times 1$ để nén số lượng kênh (channels), giảm thiểu đột biến phép tính nhân ma trận.
  2. Expand Layer: Kết hợp song song các bộ lọc $1 \times 1$ và $3 \times 3$, sau đó nối (concatenate) dữ liệu đầu ra để duy trì trường tiếp nhận đặc trưng (receptive field).
                +---------------------------------+
                |   Input Feature Map (H x W x C) |
                +---------------------------------+
                                |
                                v
                +---------------------------------+
                |   Squeeze: Conv 1x1 (C / 4)     |
                +---------------------------------+
                                |
                +---------------+---------------+
                |                               |
                v                               v
+-------------------------------+ +-------------------------------+
| Expand 1: Conv 1x1 (C / 2)    | | Expand 2: Conv 3x3 (C / 2)    |
+-------------------------------+ +-------------------------------+
                |                               |
                +---------------+---------------+
                                |
                                v
                +---------------------------------+
                | Concatenation: Output (H x W x C)|
                +---------------------------------+

Kiến trúc 18 lớp của Custom Tinier YOLO:

Lớp (Layer) Loại (Type) Bộ lọc (Filters) Kích thước/Bước nhảy (Size/Stride) Kích thước đầu vào Kích thước đầu ra
0 Input - - - $224 \times 224 \times 1$
1 Convolutional 16 $3 \times 3 / 1$ $224 \times 224 \times 1$ $224 \times 224 \times 16$
2 Maxpool - $2 \times 2 / 2$ $224 \times 224 \times 16$ $112 \times 112 \times 16$
3 Convolutional 64 $3 \times 3 / 1$ $112 \times 112 \times 16$ $112 \times 112 \times 64$
4 Maxpool - $4 \times 4 / 4$ $112 \times 112 \times 64$ $28 \times 28 \times 64$
5 Convolutional 256 $3 \times 3 / 1$ $28 \times 28 \times 64$ $28 \times 28 \times 256$
6 Maxpool - $4 \times 4 / 4$ $28 \times 28 \times 256$ $7 \times 7 \times 256$
7 Conv (Fire Squeeze) 64 $1 \times 1 / 1$ $7 \times 7 \times 256$ $7 \times 7 \times 64$
8 Conv (Fire Expand) 256 $1 \times 1 / 1$ $7 \times 7 \times 64$ $7 \times 7 \times 256$
9 Route (Layer 7) - - - $7 \times 7 \times 64$
10 Conv (Fire Expand) 256 $3 \times 3 / 1$ $7 \times 7 \times 64$ $7 \times 7 \times 256$
... ... ... ... ... ...
17 Convolutional 24 $1 \times 1 / 1$ $7 \times 7 \times 512$ $7 \times 7 \times 24$
18 Detection (YOLO) Anchor: 5 Grid: $7 \times 7$ $7 \times 7 \times 24$ Bounding Boxes

Chuyển đổi tích chập sang phép nhân ma trận GEMM (im2col):

Phép tính tích chập truyền thống đòi hỏi vòng lặp lồng 6 tầng rất khó tổng hợp phần cứng. Thuật toán im2col trải phẳng các ma trận con trên ảnh thành các cột ma trận, đưa bài toán về phép nhân $C = \alpha (A \times B) + \beta C$:

// Đoạn mã C++ minh họa thuật toán im2col phục vụ nhân GEMM
void im2col_cpu(const float* data_im, const int channels,
    const int height, const int width, const int ksize,
    const int stride, const int pad, float* data_col) {
    int c, h, w;
    int height_col = (height + 2 * pad - ksize) / stride + 1;
    int width_col = (width + 2 * pad - ksize) / stride + 1;
    int channels_col = channels * ksize * ksize;

    for (c = 0; c < channels_col; ++c) {
        int w_offset = c % ksize;
        int h_offset = (c / ksize) % ksize;
        int c_im = c / ksize / ksize;
        for (h = 0; h < height_col; ++h) {
            for (w = 0; w < width_col; ++w) {
                int im_row = h_offset + h * stride - pad;
                int im_col = w_offset + w * stride - pad;
                int col_index = (c * height_col + h) * width_col + w;
                if (im_row >= 0 && im_row < height && im_col >= 0 && im_col < width)
                    data_col[col_index] = data_im[(c_im * height + im_row) * width + im_col];
                else
                    data_col[col_index] = 0.0f; // Zero-padding
            }
        }
    }
}

OpenCL Accelerator Kernel trên FPGA:

Kernel thực thi nhân ma trận GEMM được cấu hình song song hóa mức Work-item và Work-group tận dụng tối đa pipeline execution:

__kernel void gemm_nn(
    const int M, const int N, const int K,
    const float ALPHA,
    __global const float *restrict A,
    __global const float *restrict B,
    __global float *restrict C) 
{
    // Xác định chỉ số work-item toàn cục
    int row = get_global_id(1);
    int col = get_global_id(0);

    if (row < M && col < N) {
        float sum = 0.0f;
        #pragma unroll 8
        for (int i = 0; i < K; ++i) {
            sum += A[row * K + i] * B[i * N + col];
        }
        C[row * N + col] = ALPHA * sum;
    }
}

Thử nghiệm và Đánh giá

Mô hình được huấn luyện trên framework Darknet với bộ dữ liệu hơn 30.000 ảnh sau khi lọc trùng lặp và phân bổ cân bằng: $40%$ Xe hơi, $40%$ Xe máy, $20%$ Xe tải.

                                  KẾT QUẢ ĐỘ CHÍNH XÁC (AP / mAP)
    100% +-----------------------------------------------------------------------+
         |                                                                       |
     80% |   +-----------------+   +-----------------+   +-----------------+     |
         |   |      88.5%      |   |      84.2%      |   |      81.7%      |     |
     60% |   |     (Xe hơi)    |   |    (Xe máy)     |   |    (Xe tải)     |     |
         |   |                 |   |                 |   |                 |     |
     40% |   |                 |   |                 |   |                 |     |
         |   |                 |   |                 |   |                 |     |
      0% +---+-----------------+---+-----------------+---+-----------------+-----+
                                  mAP Trung Bình: 84.8%

Bảng so sánh tài nguyên tính toán và hiệu năng:

Mô hình Số tầng (Layers) Kích thước ảnh BFLOPs mAP (%) Mức tiêu thụ logic (ALM/BRAM)
YOLOv2 gốc 32 $416 \times 416 \times 3$ 62.20 76.8% Vượt dung lượng DE1-SoC
YOLOv2-Tiny 16 $416 \times 416 \times 3$ 5.60 57.1% Chiếm ~92% Logic Elements
Custom YOLO 15 $224 \times 224 \times 3$ 2.15 68.3% Chiếm ~74% Logic Elements
Custom Tinier YOLO (Đề tài) 18 $\mathbf{224 \times 224 \times 1}$ 0.86 84.8% Chiếm ~48% ALM, 52% DSP

Ghi chú: Nhờ sử dụng ảnh xám và tập trung nhận diện chuyên biệt 3 lớp đối tượng trong bối cảnh giao thông thực tế, mAP của Custom Tinier YOLO đạt $84.8%$, vượt trội rõ rệt so với việc huấn luyện mô hình gốc trên 80 lớp tổng quát.


Đổi mới và đóng góp

  1. Thu gọn không gian tính toán: Giảm kích thước đầu vào từ $416 \times 416 \times 3$ xuống $224 \times 224 \times 1$ (Grayscale), giúp cắt giảm $66.7%$ băng thông bộ nhớ truyền tải qua AXI Bus và giảm hơn $80%$ số lượng phép tính dấu chấm động so với kiến trúc YOLOv2-Tiny tiêu chuẩn.
  2. Tích hợp cấu trúc Fire Module trong YOLO: Khai thác cơ chế kết hợp Squeeze-Expand giúp nén sâu các kênh đặc trưng mà không làm mất thông tin không gian, giúp mô hình chỉ có 18 tầng nhưng đạt độ chính xác phát hiện phương tiện tương đương các mô hình lớn.
  3. Tăng tốc phần cứng bằng OpenCL HLS: Thay vì thiết kế RTL bằng VHDL/Verilog phức tạp, giải pháp sử dụng OpenCL cho phép triển khai kiến trúc tính toán song song NDRange linh hoạt, dễ dàng mở rộng quy mô Work-group phù hợp với số lượng DSP Block trên chip FPGA.
  4. Hệ thống nhúng tích hợp hoàn chỉnh (SoC Pipeline): Xây dựng luồng xử lý khép kín từ khâu nạp ảnh, tiền xử lý trên HPS (ARM Cortex-A9), tăng tốc ma trận trên FPGA Fabric và trích xuất Bounding Box trả lời thời gian thực.

Ứng dụng thực tế và triển khai

Tình huống ứng dụng thực tế

  • Hệ thống camera phạt nguội thông minh: Tích hợp trực tiếp vào các điểm camera giao thông độc lập để nhận diện, phân loại phương tiện vi phạm làn đường hoặc dừng đỗ sai quy định mà không cần truyền video thô về trung tâm điều hành.
  • Điều tiết tín hiệu đèn giao thông thích ứng (Adaptive Traffic Light): Đếm lưu lượng thực tế của từng loại phương tiện (ô tô, xe máy, xe tải) theo từng nhánh đường để tự động điều chỉnh chu kỳ đèn xanh/đèn đỏ theo thời gian thực.
[Camera ngoài trời] ===> [Hộp điều khiển SoC-FPGA DE1-SoC] ===> [Dữ liệu JSON: Tọa độ / Loại xe]
                                 (Công suất: 6.5W)                        ||
                                                                          \/
                                                              [Trung tâm điều hành ITS]

Kế hoạch và Yêu cầu triển khai:

  • Phần cứng: Bo mạch SoC FPGA (Cyclone V hoặc tương đương), nguồn DC 12V-2A, thẻ nhớ MicroSD tối thiểu 8GB Class 10 (chứa U-Boot, Device Tree, Kernel Linux và RootFS).
  • Hiệu quả kinh tế (ROI): Cắt giảm đến $70%$ chi phí điện năng tiêu thụ và chi phí bảo trì so với máy trạm GPU truyền thống; hoạt động bền bỉ, không cần hệ thống làm mát bằng chất lỏng hay quạt công suất lớn.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật

  • Mô hình hiện xử lý trên ảnh xám đơn kênh ($224 \times 224 \times 1$) nên có thể giảm độ nhạy trong điều kiện ban đêm hoặc ánh sáng cực yếu.
  • Phần thuật toán triệt tiêu phi cực đại (Non-Maximum Suppression - NMS) và phân tích Bounding Box cuối cùng vẫn do CPU ARM trên HPS đảm nhiệm, chưa chuyển hoàn toàn xuống mạch logic phần cứng.

Hướng phát triển tiếp theo

  • Áp dụng kỹ thuật lượng tử hóa trọng số (Quantization) từ 32-bit Floating Point xuống 8-bit Integer (INT8) hoặc Binary Neural Networks (BNN) để tăng tốc độ xử lý lên gấp 3–4 lần trên FPGA.
  • Thiết kế khối tính toán chuyên biệt (Custom IP Core) bằng SystemVerilog cho khâu NMS và trích xuất đặc trưng màu trực tiếp.
  • Thử nghiệm trên các dòng FPGA cao cấp hơn như Intel Arria 10 hoặc Agilex để xử lý song song đa luồng video chuẩn Full HD / 4K.

Đối tượng hưởng lợi

  • Sinh viên & Học viên chuyên ngành: Cung cấp tài liệu thực chứng toàn diện về quy trình thiết kế đồng phần cứng/phần mềm (Hardware/Software Co-design), luồng Boot Linux nhúng và lập trình OpenCL trên SoC-FPGA.
  • Kỹ sư nhúng & AI Edge: Tham khảo phương pháp tối ưu hóa mạng CNN (Fire Modules, im2col, GEMM Kernel) để triển khai trên các thiết bị hạn chế tài nguyên.
  • Doanh nghiệp giải pháp ITS: Nắm bắt mô hình kiến trúc phần cứng tiết kiệm chi phí, tiêu thụ năng lượng thấp để xây dựng các thiết bị Edge AI giám sát giao thông thông minh.
  • Nhà nghiên cứu: Cơ sở dữ liệu và phương pháp luận mở rộng cho các bài toán phát hiện đối tượng chuyên dụng trên nền tảng điện toán tái cấu trúc.

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

1. Yêu cầu kỹ thuật tối thiểu để triển khai hệ thống trên bo mạch là gì?

Hệ thống yêu cầu bo mạch SoC-FPGA có tối thiểu 85K Logic Elements, 4Mbit On-chip Memory, 80+ DSP Blocks, HPS ARM Dual-Core chạy Linux Kernel có hỗ trợ trình điều khiển Intel FPGA OpenCL Driver, cùng bộ nhớ SDRAM tối thiểu 64MB cho phần cứng FPGA.

2. Tại sao lại chọn chuyển đổi ảnh đầu vào sang Grayscale thay vì giữ nguyên hệ màu RGB?

Chuyển đổi sang ảnh xám ($224 \times 224 \times 1$) giúp giảm kích thước tensor đầu vào xuống 3 lần so với RGB ($224 \times 224 \times 3$). Việc này cắt giảm trực tiếp $66.7%$ lưu lượng dữ liệu qua bus AXI và giảm mạnh số phép nhân tích chập ở tầng đầu tiên, trong khi đặc trưng hình thái của phương tiện giao thông (khung xe, bánh xe, đầu cabin) vẫn được bảo toàn trọn vẹn.

3. Hệ thống có thể tích hợp với các luồng camera giám sát hiện có không?

Có. Nhờ HPS chạy hệ điều hành Linux đầy đủ, chương trình Host C++ có thể giải mã luồng RTSP từ IP Camera thông qua cổng Gigabit Ethernet hoặc chuẩn USB Video Class (UVC) qua cổng USB Host, sau đó nạp frame ảnh trực tiếp vào bộ nhớ dùng chung với FPGA.

4. Quá trình bảo trì và cập nhật mô hình AI mới diễn ra như thế nào?

Nhờ sử dụng OpenCL framework, khi cần nâng cấp mô hình, nhà phát triển chỉ cần huấn luyện lại trọng số mạng, cấu hình lại các tham số trong file host hoặc tổng hợp lại file .aocx mà không cần phải can thiệp thiết kế lại toàn bộ sơ đồ phần cứng logic từ đầu.

5. Chi phí đầu tư phần cứng và tỷ suất hoàn vốn (ROI) được đánh giá ra sao?

So với máy chủ GPU tiêu thụ điện năng lớn và cần phòng điều hòa, giải pháp SoC-FPGA tiết kiệm hơn $70%$ điện năng vận hành, có tuổi thọ phần cứng cao (>50.000 giờ MTBF) trong môi trường ngoài trời, giúp hoàn vốn đầu tư hạ tầng giám sát chỉ sau 12–18 tháng vận hành.


Kết luận

Đề tài "Hệ thống nhận diện phương tiện giao thông trên FPGA" đã chứng minh tính khả thi và hiệu quả vượt trội của việc kết hợp giữa giải thuật học sâu rút gọn (Custom Tinier YOLO) và công nghệ tăng tốc phần cứng dị thể SoC-FPGA.

Bằng việc làm chủ quy trình phát triển từ chuẩn bị dữ liệu, tinh chỉnh mạng nơ-ron, xây dựng hệ điều hành nhúng đến tối ưu hóa kernel tính toán ma trận OpenCL, nghiên cứu đã mang lại một giải pháp cân bằng hoàn hảo giữa độ chính xác nhận diện ($84.8%$ mAP), thông lượng xử lý và hiệu suất năng lượng. Đây là nền tảng vững chắc để tiếp tục phát triển thành các vi mạch chuyên dụng (ASIC/IC) phục vụ cho hệ sinh thái đô thị thông minh và giao thông tương lai.