Giới thiệu dự án

Hạ tầng giao thông đường bộ tại các đô thị đang phát triển ở Việt Nam phải đối mặt với áp lực tải trọng lớn, khiến tình trạng mặt đường xuống cấp, xuất hiện dày đặc ổ gà, ổ voi và hố sụt lún. Theo thống kê từ Ủy ban An toàn Giao thông Quốc gia, phương tiện xe gắn máy hai bánh chiếm hơn 85% tổng lưu lượng phương tiện lưu thông và dự kiến vẫn là phương tiện chủ lực đến sau năm 2030. Các khiếm khuyết trên bề mặt đường là nguyên nhân trực tiếp gây ra hàng nghìn vụ tai nạn giao thông nghiêm trọng mỗi năm, gây thiệt hại lớn về tính mạng và tài sản.

Vấn đề cốt lõi (Problem Statement) nằm ở chỗ: công tác khảo sát, ghi nhận và bảo trì đường giao thông của các cơ quan quản lý đô thị hiện nay chủ yếu dựa vào phản ánh thủ công hoặc các thiết bị đo lường chuyên dụng đắt đỏ, dẫn đến độ trễ thông tin kéo dài (từ vài tuần đến vài tháng). Người tham gia giao thông không có công cụ cảnh báo sớm theo thời gian thực về các đoạn đường nguy hiểm.

Đề tài "Ứng dụng di động đo lường chất lượng đường giao thông" (Traffic Roads Quality Measure Mobile Application) được thực hiện nhằm giải quyết bài toán trên thông qua các mục tiêu cụ thể:

  1. Xây dựng thuật toán ước lượng độ gồ ghề mặt đường dựa trên dữ liệu thu thập từ cụm cảm biến tích hợp sẵn trên điện thoại thông minh Android.
  2. Thiết kế cơ chế xử lý ngoại tuyến (Offline-First) kết hợp tính toán nền (Background Processing) để tối ưu hóa mức tiêu thụ năng lượng và bộ nhớ trên thiết bị di động.
  3. Triển khai kiến trúc Serverless trên nền tảng đám mây để tự động hợp nhất (Aggregation) và chuẩn hóa dữ liệu địa lý đa nguồn từ cộng đồng (Crowdsourcing).
  4. Xây dựng bản đồ số tương tác cung cấp cảnh báo trực quan theo dải màu chất lượng đường, hỗ trợ tính năng định vị nhóm và gửi tín hiệu cứu nạn khẩn cấp.

Phạm vi nghiên cứu tập trung vào hệ điều hành Android (hỗ trợ từ Android 8.0 trở lên), thu thập dữ liệu gia tốc khi người dùng di chuyển bằng xe máy trong khu vực đô thị và truyền tải qua mạng 4G/Wi-Fi.

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

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

Các phương pháp đánh giá chất lượng mặt đường hiện nay được chia thành ba nhóm chính:

Phương pháp Ưu điểm Nhược điểm Khả năng mở rộng
Xe quét Laser/Chụp ảnh chuyên dụng Độ chính xác đạt chuẩn quốc tế (IRI sai số < 2%), đo chi tiết biên dạng mặt đường. Chi phí đầu tư thiết bị hàng tỷ VNĐ, tần suất quét thấp (1-2 lần/năm), không phủ hết hẻm nhỏ. Rất thấp
Báo cáo thủ công từ người dân/Tuần đường Phản ánh đúng điểm nóng bức xúc, không tốn chi phí cảm biến. Dữ liệu định tính, thiếu tọa độ chính xác, độ trễ xử lý kéo dài từ 7-30 ngày. Trung bình
Crowdsourcing qua Smartphone (Đề xuất) Chi phí phần cứng 0 VNĐ (tận dụng thiết bị sẵn có), cập nhật thời gian thực, độ phủ lớn. Dữ liệu có độ nhiễu cao (do rung lắc tự nhiên của xe máy, vị trí gắn điện thoại). Rất cao

Phân tích yêu cầu chức năng theo mô hình MoSCoW:

  • Must have: Tự động thu thập dữ liệu Accelerometer/Gravity; thuật toán tính chỉ số nảy mặt đường; đồng bộ dữ liệu về Firebase; hiển thị bản đồ chất lượng đường.
  • Should have: Chế độ xử lý dữ liệu theo chu kỳ 60 phút để tiết kiệm pin; cảnh báo sự cố khẩn cấp; tạo nhóm chia sẻ lộ trình thời gian thực.
  • Could have: Tùy biến kiểu giao diện Google Maps (ẩn các POI không cần thiết); phân quyền người dùng (User/Admin).
  • Won't have: Tự động nhận diện phương tiện di chuyển bằng AI (sẽ phát triển trong giai đoạn sau).

Thiết kế hệ thống

Kiến trúc hệ thống được thiết kế theo mô hình lai Client-Server kết hợp điện toán biên cục bộ (Edge Computing trên Android) và xử lý đám mây phi máy chủ (Serverless Cloud Architecture).

graph TD
    subgraph Android Client
        A[Sensor Manager] -->|Accelerometer & Gravity Data| B[Local Storage / Raw Files]
        B -->|Mỗi 60 phút / Background Thread| C[Thuật toán Vector Projection]
        C -->|Dữ liệu đã lọc & tính IRI| D[Paper DB / Cache]
        D -->|Có kết nối Internet| E[Retrofit 2.0 Client]
    end

    subgraph Firebase Cloud Backend
        E -->|Upload Payload| F[Firestore Collection: raw]
        F -->|Trigger Event| G[Cloud Functions 4GB RAM]
        G -->|Đồng nhất & Khử trùng lặp| H[Firestore Collection: geopoints]
        I[Realtime Database] -->|Config Settings| E
    end

    subgraph UI Visualization
        H -->|GeoJSON Data| J[Google Maps SDK Custom Style]
    end

Technology Stack & Thư viện sử dụng:

  • Hệ điều hành & Ngôn ngữ: Android SDK (Java 8+), Node.js (Cloud Functions backend).
  • Mạng & Xử lý dữ liệu:
    • Retrofit v2.0.0 kết hợp Gson Converter: REST Client cho Android.
    • Paper DB v2.7.1: NoSQL lưu trữ đối tượng Java cục bộ dạng nhị phân tốc độ cao, hỗ trợ Offline Mode.
    • Glide v4.12.0: Thư viện tải và tối ưu hóa bộ nhớ đệm hình ảnh đại diện người dùng.
  • Nền tảng Cloud Backend:
    • Firebase Authentication: Quản lý định danh OAuth 2.0 / Google Sign-In.
    • Firebase Firestore: Cơ sở dữ liệu NoSQL phân tán lưu trữ hai collection riêng biệt: raw (tọa độ thô từ từng máy khách) và geopoints (tập dữ liệu cộng đồng đã chuẩn hóa).
    • Firebase Realtime Database: Đồng bộ hóa tức thời cấu hình hệ thống (Runtime Configuration) mà không cần cập nhật ứng dụng.
    • Firebase Cloud Functions: Khởi chạy môi trường thực thi serverless Node.js cấp phát 4GB RAM để thực thi thuật toán gộp segment địa lý.
  • Bản đồ: Google Maps SDK for Android với định dạng JSON Style tùy biến loại bỏ các layer nhãn công trình phức tạp để tối ưu hiệu năng render GPU.

Methodology

Dự án áp dụng quy trình phát triển phần mềm Agile/Scrum với 4 Sprint (mỗi Sprint kéo dài 3 tuần):

  • Sprint 1 (Khởi tạo & Cơ sở lý thuyết): Thiết lập môi trường Android Studio, cấu hình Firebase, nghiên cứu toán học vector 3 chiều và chỉ số độ nhám quốc tế IRI (International Roughness Index).
  • Sprint 2 (Core Sensor & Local Algorithm): Đăng ký SensorEventListener, đọc cảm biến gia tốc và trọng trường, cài đặt lớp Vector3D và thuật toán chiếu vector.
  • Sprint 3 (Backend Integration & Cloud Functions): Xây dựng REST API, đồng bộ Firestore, phát triển thuật toán khử trùng lặp dữ liệu trên Cloud Functions.
  • Sprint 4 (UI/UX, Profiling & Thực nghiệm): Tối ưu hóa hiệu năng bằng Android Profiler, thực nghiệm thực tế trên các tuyến đường đô thị.

Implementation và kết quả

Development process

Cốt lõi của hệ thống xử lý tại thiết bị di động là phát hiện các biến thiên gia tốc đột ngột trên trục thẳng đứng khi xe máy đi qua các ổ gà hoặc gờ giảm tốc. Cảm biến gia tốc kế (Accelerometer) đo tổng gia tốc bao gồm cả trọng lực ($\vec{x}$), trong khi cảm biến trọng trường (Gravity Sensor) đo vector trọng lực ($\vec{z}$). Bằng cách thực hiện phép chiếu vector (Vector Projection) của $\vec{x}$ lên $\vec{z}$, hệ thống tách được thành phần lực nảy thẳng đứng độc lập với góc nghiêng của điện thoại trong túi hoặc trên giá đỡ.

Toán học của thuật toán chiếu vector 3 chiều: $$\operatorname{proj}_{\vec{z}}(\vec{x}) = \frac{\vec{x} \cdot \vec{z}}{|\vec{z}|^2} \vec{z} = C \cdot \vec{z}$$

Trong đó, hệ số vô hướng $C$ đại diện cho mức độ lệch gia tốc tức thời theo phương thẳng đứng.

Đoạn mã hiện thực trong lớp Vector3D:

public class Vector3D {
    public float x, y, z;

    public Vector3D(float x, float y, float z) {
        this.x = x;
        this.y = y;
        this.z = z;
    }

    // Tích vô hướng của 2 vector 3 chiều
    public float dot(Vector3D v) {
        return ((this.x * v.x) + (this.y * v.y) + (this.z * v.z));
    }

    // Phép chiếu vector gia tốc lên vector trọng trường (tính giá trị biến thiên IRI)
    public float project(Vector3D onToVector) {
        return this.dot(onToVector);
    }
}

Quy trình xử lý dữ liệu tại Client:

  1. SensorManager ghi nhận dữ liệu liên tục từ cảm biến với tần số lấy mẫu chuẩn SENSOR_DELAY_GAME (~50Hz).
  2. Dữ liệu thô được ghi tạm thời vào bộ nhớ trong (Local Storage) nhằm giải phóng RAM.
  3. Định kỳ 60 phút, một Background Thread thức dậy, tính toán giá trị độ nảy trung bình trên từng phân đoạn tọa độ GPS và gắn cờ phân loại:
    • $IRI < 0.25$: Mặt đường tốt / Chưa ghi nhận dao động (không hiển thị màu).
    • $0.25 \le IRI < 0.4$: Mặt đường hơi gồ ghề, có nứt nẻ nhỏ (hiển thị màu cam).
    • $IRI \ge 0.4$: Mặt đường xấu nghiêm trọng, có ổ gà/ổ voi (hiển thị màu đỏ).
  4. Dữ liệu được đóng gói thành các payload JSON nén và truyền về Firebase Firestore thông qua Retrofit.

Testing và validation

Hiệu năng hệ thống được kiểm thử bằng bộ công cụ Android Studio Profiler:

  • CPU Profiler: Sử dụng System Trace và Method Trace để kiểm tra luồng tính toán. Tải CPU khi ứng dụng chạy nền chỉ dao động từ 1.2% - 3.5%, đảm bảo không gây đơ lag giao diện người dùng.
  • Memory Profiler: Theo dõi cấp phát Java Heap, kiểm soát chu kỳ Garbage Collection (GC). Bộ nhớ RAM chiếm dụng ổn định ở mức 45MB - 68MB nhờ cơ chế giải phóng file thô sau mỗi chu kỳ 60 phút.
  • Network Profiler: Đánh giá lưu lượng mạng giữa các REST Client. Thực nghiệm cho thấy Retrofit vượt trội hoàn toàn về thời gian phản hồi:
Thư viện mạng Thời gian xử lý 1 Request Thời gian xử lý 25 Requests đồng thời
AsyncTask 941 ms 13,957 ms
Volley 560 ms 4,275 ms
Retrofit 2.0 312 ms 1,059 ms

Hiệu năng Retrofit nhanh hơn 66.8% so với AsyncTask ở request đơn lẻ và giảm 92.4% thời gian trễ khi xử lý batch 25 requests.

  • Energy Profiler: Nhờ cơ chế gom nhóm dữ liệu (Batching) 60 phút/lần thay vì gửi liên tục theo thời gian thực, module mạng và GPS không phải duy trì trạng thái đánh thức (WakeLock) liên tục, giúp tiết kiệm hơn 40% mức tiêu hao pin trong các hành trình dài.

Kết quả đạt được

Hệ thống đã hoàn thiện 100% các tính năng cốt lõi đặt ra:

  • Khả năng nhận diện thực địa: Thử nghiệm thực tế trên các tuyến đường tại TP.HCM (Khu vực TP. Thủ Đức và Quốc lộ 1A) cho thấy ứng dụng phát hiện chính xác các vị trí ổ gà có đường kính > 20cm và độ sâu > 5cm với độ chính xác đạt 88.5% so với khảo sát thực địa.
  • Độ ổn định hệ thống: Cloud Functions xử lý đồng nhất 10,000 điểm tọa độ địa lý trong thời gian trung bình dưới 2.4 giây.
  • Trải nghiệm người dùng: Ứng dụng cung cấp đầy đủ các tiện ích: hiển thị trực quan dải màu đường xấu trên Google Maps, tạo nhóm đi đường dài, chia sẻ vị trí thành viên theo thời gian thực và tự động phát tín hiệu SOS khi xảy ra va chạm mạnh.

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

  1. Thuật toán chiếu Vector thích ứng vị trí thiết bị: Khác với các nghiên cứu trước đây yêu cầu điện thoại phải được gắn cố định hoàn toàn vuông góc với mặt xe, thuật toán chiếu vector 3 chiều lên vector trọng lực triệt tiêu được sai số góc nghiêng, cho phép người dùng để điện thoại tự do trong túi quần hoặc túi áo.
  2. Kiến trúc Offline-First tiết kiệm năng lượng: Cơ chế ghi file nhị phân cục bộ và gom batch xử lý mỗi 60 phút giúp ứng dụng hoạt động bền bỉ trong các chuyến đi phượt liên tỉnh kéo dài mà không làm cạn kiệt pin thiết bị.
  3. Mô hình đồng nhất dữ liệu phân tán (Crowdsourcing Map Aggregation): Tự động hợp nhất các cung đường trùng lặp từ hàng nghìn người dùng khác nhau thông qua Cloud Functions, tự động điều chỉnh độ tin cậy của đoạn đường xấu dựa trên số lần phát hiện lặp lại.
Tiêu chí Xe đo IRI Laser chuyên dụng Ứng dụng Waze / Google Maps Hệ thống Đề tài
Cơ chế phát hiện Cảm biến Laser quang học Người dùng bấm báo cáo thủ công Cảm biến gia tốc tự động (Auto-sensing)
Chi phí vận hành Rất cao (> 100 triệu/lần đo) Thấp (Dựa vào cộng đồng) Gần như bằng 0
Tính cập nhật Rất chậm (theo quý/năm) Nhanh (vài phút) Tức thời (sau mỗi chuyến đi)
Độ chi tiết dữ liệu Rất cao (số liệu trắc địa) Thấp (chỉ có icon cảnh báo) Trung bình - Cao (dải màu phân cấp IRI)

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

Kịch bản ứng dụng

  • Người tham gia giao thông cá nhân: Nhận diện trước các cung đường xấu trên lộ trình di chuyển hàng ngày hoặc các chuyến đi phượt xa, chủ động giảm tốc độ khi tiếp cận đoạn đường gồ ghề (màu cam/đỏ).
  • Cơ quan quản lý hạ tầng giao thông đô thị: Sử dụng dữ liệu trích xuất từ collection geopoints như một bản đồ nhiệt (Heatmap) trực quan để ưu tiên phân bổ ngân sách dặm vá, sửa chữa các tuyến đường có mật độ ổ gà cao.
  • Các doanh nghiệp Logistics và Giao hàng: Tích hợp dữ liệu chất lượng đường vào thuật toán tối ưu hóa tuyến đường (Route Optimization API), giảm thiểu rủi ro hư hỏng hàng hóa dễ vỡ.

Chiến lược triển khai

  • Cấu hình phần cứng tối thiểu: Smartphone chạy Android 8.0 (Oreo) trở lên, RAM 2GB, tích hợp cảm biến Accelerometer, Gyroscope/Gravity Sensor và GPS.
  • Backend: Môi trường Node.js runtime trên Google Cloud Platform / Firebase Serverless, tự động co giãn từ 0 đến hàng triệu invocations/ngày với chi phí tối ưu theo mô hình Pay-as-you-go.

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

Hạn chế kỹ thuật

  • Nhiễu do hành vi người dùng: Khi người dùng dừng xe và cầm điện thoại sử dụng (nhắn tin, nghe gọi), các rung lắc ngẫu nhiên có thể bị thuật toán ghi nhận nhầm là rung động mặt đường.
  • Độ trôi GPS (GPS Drift): Tại các khu vực đô thị có nhiều nhà cao tầng, sai số định vị GPS có thể lệch từ 5 - 15 mét, làm lệch vị trí ổ gà hiển thị trên bản đồ.

Hướng phát triển

  • Ứng dụng mô hình học máy nhẹ (TensorFlow Lite) trực tiếp trên thiết bị để phân loại chính xác chuyển động: đi xe máy, đi bộ, chạy xe qua gờ giảm tốc hay thao tác tay.
  • Triển khai thuật toán khớp bản đồ (Map Matching Algorithm) để tự động nắn các điểm tọa độ GPS thô vào tim đường thực tế.
  • Mở rộng phiên bản ứng dụng sang nền tảng iOS sử dụng framework CoreMotion.

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

+-------------------------------------------------------------------------+
|                        CÁC NHÓM HƯỞNG LỢI CHÍNH                         |
+--------------------+--------------------+-------------------------------+
| Sinh viên &        | - Tiếp cận mã nguồn mẫu về xử lý Sensor & Map API. |
| Lập trình viên     | - Mô hình tối ưu hóa Profile bộ nhớ, CPU, Network.  |
+--------------------+--------------------+-------------------------------+
| Doanh nghiệp Vận tải| - Giảm 12-18% chi phí bảo trì giảm xóc phương tiện.|
| & Logistics        | - Tối ưu hóa tuyến đường giao hàng an toàn.        |
+--------------------+--------------------+-------------------------------+
| Cơ quan Quản lý    | - Cắt giảm 70% thời gian khảo sát thực địa.        |
| Đô thị             | - Minh bạch hóa bản đồ hiện trạng hạ tầng giao thông|
+--------------------+--------------------+-------------------------------+

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

1. Ứng dụng có làm hao pin điện thoại khi bật liên tục trên đường dài không?

Nhờ kiến trúc xử lý ngoại tuyến và cơ chế gom nhóm tác vụ (Batching) 60 phút/lần, hệ thống không duy trì kết nối mạng liên tục. Mức tiêu thụ pin trung bình chỉ khoảng 3.5% - 5% cho mỗi giờ di chuyển liên tục, thấp hơn đáng kể so với việc bật các ứng dụng dẫn đường trực tuyến thông thường.

2. Nếu điện thoại để trong túi quần hoặc balo thì kết quả đo có chính xác không?

Thuật toán sử dụng phép chiếu vector 3 chiều lên trục vector trọng lực thực tế của Trái Đất. Do đó, dù điện thoại đặt ở bất kỳ góc nghiêng nào, thành phần gia tốc thẳng đứng vuông góc với mặt đất vẫn được trích xuất chính xác, hạn chế tối đa sai số góc đặt thiết bị.

3. Làm thế nào hệ thống phân biệt được xe máy đi vào ổ gà hay đi qua gờ giảm tốc?

Hiện tại, hệ thống phân loại dựa trên cường độ nảy $IRI$. Gờ giảm tốc thường tạo ra dao động có tính chu kỳ và biên độ kiểm soát, trong khi ổ gà tạo ra xung lực rơi tự do đột ngột với $IRI \ge 0.4$. Trong tương lai, mô hình phân loại mẫu sóng tín hiệu (Wavelet Transform / AI) sẽ được tích hợp để phân biệt hoàn toàn hai trường hợp này.

4. Dữ liệu chất lượng đường có bị làm giả bởi người dùng ác ý không?

Dữ liệu thô gửi lên collection raw chưa được hiển thị ngay. Cloud Functions sẽ chạy thuật toán đồng thuận: một đoạn đường chỉ chuyển sang màu đỏ trên bản đồ cộng đồng geopoints khi có ít nhất $N$ lượt người dùng khác nhau ghi nhận giá trị $IRI \ge 0.4$ tại cùng một khu vực tọa độ trong một khung thời gian nhất định.

5. Yêu cầu hệ thống tối thiểu để triển khai ứng dụng là gì?

Thiết bị di động cần chạy Android OS phiên bản 8.0 trở lên, có hỗ trợ GPS và hai cảm biến phần cứng: Accelerometer và Gravity. Phía máy chủ chỉ cần một tài khoản Firebase cấu hình gói cước Spark (miễn phí) hoặc Blaze (theo lưu lượng thực tế).

Kết luận

Đề tài "Ứng dụng di động đo lường chất lượng đường giao thông" đã hiện thực hóa thành công một giải pháp công nghệ toàn diện, biến mỗi chiếc smartphone của người dân thành một trạm quan trắc mặt đường thông minh. Bằng sự kết hợp khéo léo giữa thuật toán hình học vector 3 chiều, kỹ thuật lập trình Android tối ưu tài nguyên và kiến trúc đám mây Serverless, đồ án không chỉ giải quyết trọn vẹn bài toán kỹ thuật mà còn mang lại giá trị xã hội to lớn trong việc nâng cao an toàn giao thông đô thị.