thiết kế hệ thống bãi đỗ xe thông minh

Đây là nơi đặt MQTT broker để giao tiếp giữa khối điều khiển và khối xử lý dữ liệu, cũng như là nơi đặt cơ sở dữ liệu cho hệ thống Nhóm sinh viên tin rằng, với hệ thống bãi đỗ xe thông m

GIỚI THIỆU

ĐẶT VẤN ĐỀ

Theo khảo sát về số lượng và phương tiện đi lại, Việt Nam nằm trong top sáu quốc gia có tỷ lệ sử dụng phương tiện giao thông cá nhân cao nhất thế giới[1] Số lượng phương tiện cá nhân tăng cao dẫn đến nhiều vấn đề trong quản lý giao thông, đặc biệt là quản lý bãi đỗ xe

Mặc dù số lƣợng bãi đỗ xe ở Việt Nam rất lớn, hiệu quả hoạt động của chúng vẫn còn hạn chế, gây ùn tắc giao thông Người dân phải xếp hàng dài để chờ đưa xe vào bãi, đặc biệt trong các khung giờ cao điểm tại trường học, siêu thị, Các bãi giữ xe truyền thống gặp nhiều bất cập nhƣ quản lý lƣợng xe di chuyển ra vào, cấp thẻ giữ xe, ghi biển số xe, Điều này gây khó khăn trong việc quản lý khi lượng phương tiện giao thông lớn, dẫn đến ùn tắc tại các điểm giữ xe

Với sự phát triển của khoa học công nghệ ngày nay, các công nghệ và kỹ thuật hiện đại đang giúp tối ƣu hóa việc quản lý bãi giữ xe Trong đó, công nghệ RFID/NFC và nhận diện biển số xe đóng vai trò quan trọng

Nhiều đề tài, nghiên cứu trong và ngoài nước đã thực hiện liên quan đến hệ thống bãi giữ xe, công nghệ RFID và nhận diện biển số xe Ví dụ, năm 2018, Vũ Tiến Trình và Lê Vũ Khanh thực hiện đề tài "Hệ thống bãi giữ xe ứng dụng công nghệ RFID" sử dụng công nghệ RFID trên nền tảng Arduino UNO để quản lý vào ra bãi giữ xe và kiểm tra số lƣợng chỗ trống hiển thị trên web[2] Năm 2019, Nguyễn Đăng Việt và Trần Trí Đạt đã thực hiện đề tài "Thiết kế, thi công bãi giữ xe ứng dụng công nghệ RFID và xử lý ảnh", kết hợp công nghệ RFID và thuật toán xử lý ảnh để trích xuất hình ảnh[3] Xây dựng hệ thống gửi xe tự động sử dụng thị giác máy tính của tác giả Phạm Văn Khoa, Trần Nhật Quang, Lê Nguyễn Gia Bảo, Nguyễn Quốc Ninh trên tạp chí khoa học và công nghệ - đại học Đà Nẵng[4]

Các đề tài, nghiên cứu trước đây thường sử dụng công nghệ RFID và các kỹ thuật nhận diện nhƣ OpenCV, Tesseract OCR Tuy nhiên, để đạt hiệu quả cao,

2 chất lƣợng hình ảnh đầu vào cần tốt và độ chính xác vẫn chƣa cao Tính thẩm mỹ và khả năng thương mại hóa của các hệ thống này cũng chưa được chú trọng

Từ những khảo sát ban đầu, cùng với những kiến thức và hướng dẫn từ giảng viên, nhóm sinh viên quyết định lựa chọn đề tài "Thiết kế hệ thống bãi đỗ xe thông minh" Đề tài này nhằm khắc phục những thiếu sót và hạn chế của các hệ thống trước đó và nâng cao tính thực tế cũng như khả năng thương mại hóa.

MỤC TIÊU ĐỀ TÀI

Nghiên cứu hệ thống nhận diện bằng sóng vô tuyến (RFID/NFC) và thuật toán YOLO để nhận dạng biển số một cách tự động

Xây dựng Broker MQTT: Tìm hiểu và triển khai Broker MQTT để quản lý việc truyền thông dữ liệu giữa các thiết bị trong hệ thống

Nghiên cứu AWS EC2 và phát triển Broker MQTT cùng với MongoDB trên AWS EC2 để quản lý việc truyền thông dữ liệu giữa các thiết bị trong hệ thống

Xây dựng Web Application quản lý dữ liệu: Triển khai website để quản lý dữ liệu của hệ thống cho phép thêm, xóa biển số xe, số tiền trong mỗi tài khoản, Thiết kế ứng dụng di động cho phép người dùng đăng nhập, nạp tiền, gia hạn đăng kí, đăng kí biển mới…

Phân tích, đánh giá các phương pháp công nghệ được thực hiện có trong quản lý bãi đỗ xe thông minh Đánh giá hiệu suất và tính khả thi của hệ thống qua các thử nghiệm thực tế và phản hồi từ người dùng.

GIỚI HẠN ĐỀ TÀI

Hạn chế về bảo mật: Việc áp dụng công nghệ liên quan đến dịch vụ đám mây, các cơ sở dữ liệu và thẻ RFID/NFC sẽ có nguy cơ bị xâm nhập từ các tác nhân bên ngoài gây ảnh hưởng xấu đến hệ thống

Hạn chế về chi phí: Các yếu tố nhƣ ngân sách, thời gian và nhân lực có thể là các hạn chế đối với việc triển khai và thử nghiệm hệ thống bãi đỗ xe thông minh

Sự phụ thuộc vào internet: Hệ thống bãi đỗ xe thông minh yêu cầu internet để hoạt động, vì vậy nếu mất kết nối hệ thống có thể sẽ gặp sự cố

Khả năng lỗi hệ thống: Hệ thống bãi đỗ xe thông minh có thể gặp lỗi do vấn đề kỹ thuật hoặc phần mềm

Sự phụ thuộc và điều kiện tự nhiên: Việc hình ảnh thiếu ánh sáng, bị mờ, bị hư hỏng cũng làm ảnh hưởng tới việc nhận diện biển số của hệ thống

Phụ thuộc vào hành vi người dùng: Hệ thống có thể gặp trễ khi người dùng cố tình đi ngay sau xe phía trước, khiến hệ thống không thể đóng cửa kịp thời khi xe phía trước đã đi qua.

PHƯƠNG PHÁP NGHIÊN CỨU

Trong suốt quá trình làm đồ án tốt nghiệp, nhóm đã sử dụng các công nghệ và phương pháp sau:

- Nghiên cứu, tìm hiểu các hệ thống nhận diện biển số

- Tìm hiểu các mô hình AI nhận diện biển số, các chuẩn truyền thông giao tiếp thông qua internet

- Thiết kế hệ thống nhận diện biển số

- Thiết kế, xây dựng máy chủ cho hệ thống

- Phân tích hiệu năng đánh giá hệ thống

ĐỐI TƢỢNG VÀ PHẠM VI NGHIÊN CỨU

Đối tượng mà nghiên cứu tập trung vào là các công nghệ và phương pháp đã đƣợc phát triển và áp dụng trong lĩnh vực quản lý bãi đỗ xe thông minh Ví dụ bao gồm:

- Các mô hình đƣợc sử dụng để nhận dạng và phân loại đối tƣợng nhƣ YOLO

- Các công nghệ truyền thông và giao tiếp nhƣ RFID/NFC và MQTT

- Các giải thuật và phương pháp tiếp cận trong xử lý hình ảnh và dữ liệu phức tạp

Phạm vi nghiên cứu bao gồm việc áp dụng các mô hình và công nghệ đã có sẵn vào bài toán quản lý bãi đỗ xe thông minh Nhóm sinh viên sẽ nghiên cứu và

4 phát triển các giải pháp dựa trên các mô hình đã đƣợc công bố và các công nghệ truyền thông hiện đại nhằm tạo ra một hệ thống tự động hoàn chỉnh, có khả năng quản lý thông tin về các phương tiện một cách hiệu quả và với ít sự can thiệp của con người.

BỐ CỤC QUYỂN BÁO CÁO

Nội dung chính được trình bày với 5 chương:

- Chương 1 GIỚI THIỆU: Đặt vấn đề về đề tài, mục tiêu nghiên cứu, giới hạn đề tài, phương pháp nghiên cứu, đối tượng và phạm vi nghiên cứu

- Chương 2 GIỚI THIỆU THUẬT TOÁN NHẬN DIỆN ĐỐI TƯỢNG VÀ KIẾN TRÚC YOLO: Trong chương này sẽ khám phá lý thuyết và cách hoạt động của thuật toán nhận diện đối tƣợng, cùng với việc giới thiệu chi tiết về kiến trúc YOLO

- Chương 3 THIẾT KẾ HỆ THỐNG BÃI ĐỖ XE THÔNG MINH: Đưa ra mô hình chung của toàn hệ thống, các khối của hệ thống, thiết kế từng khối và các thành phần đƣợc sử dụng trong mỗi khối

- Chương 4 KẾT QUẢ: Trình bày kết quả thi công, thử nghiệm và đánh giá mô hình hệ thống

- Chương 5 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN: Rút ra các kết luận, điểm mạnh điểm yếu và hướng phát triển của mô hình

GIỚI THIỆU THUẬT TOÁN NHẬN DIỆN ĐỐI TƯỢNG VÀ KIẾN TRệC YOLO

GIỚI THIỆU TỔNG QUAN VỀ YOLO

Yolo (You only look once) là một mô hình mạng CNN cho việc phát hiện, nhận dạng, phân loại đối tƣợng theo thời gian thực YOLO đƣợc đề xuất bởi Joseph Redmond và cộng sự trong năm 2015 Nó đã đƣợc đề xuất để giải quyết các bất cập mà các mô hình nhận dạng đối tƣợng phải đối mặt tại thời điểm đó Bảng 2.1 Hệ thống thời gian thực trên PASCAL VOC 2007 So sánh hiệu suất và tốc độ của các mô hình nhận diện[5]

Real-Time Detectors Train mAP FPS

Từ bảng dữ liệu trên ta có thể thấy trong các mô hình có thể nhận diện theo thời gian thực từ tốc độ của chúng thì Yolo dường như có hiệu suất tốt nhất mặc dù độ chính xác có thể thấp hơn khi so sánh với một vài mô hình khác Lý do

6 Yolo có thể đạt đƣợc điều này bởi vì nó sử dụng kiến trúc học sâu vô cùng mạnh mẽ đồng thời sử dụng hình ảnh đầu vào theo một cách hiệu quả cao

Hình 2.1 Kiến trúc mạng Yolo[6]

Kiến trúc này nhận một hình ảnh làm đầu vào và thay đổi kích thước của nó thành bằng cách giữ nguyên tỉ lệ khung hình và thực hiện thêm phần đệm Hình ảnh này sau đó đƣợc truyền vào mạng CNN Mô hình này có 24 lớp tích chập, 4 lớp tối đa hóa theo sau bởi 2 lớp kết nối đầy đủ Để giảm số lƣợng lớp (kênh), chúng sử dụng tích chập sau đó là tích chập Từ lớp kết nối đầy đủ cuối cùng và sau đó thay đổi hình dạng của nó thành kích thước (7, 7, 30)

Kiến trúc này sử dụng hàm kích hoạt Leaky ReLU trong toàn bộ kiến trúc trừ lớp cuối cùng, ở đó nó sử dụng hàm kích hoạt tuyến tính Batch normalization cũng giúp điều chỉnh mô hình Kỹ thuật Dropout cũng đƣợc sử dụng để ngăn chặn việc quá mức hóa

CÁCH HOẠT ĐỘNG CỦA YOLO

Hình 2.2 Cách hoạt động của mô hình Yolo[7]

Với đầu vào là một ảnh, bước đầu tiên của quá trình YOLO là phủ một lưới các ô có kích thước lên hình ảnh ban đầu Sau đó, mỗi ô trong lưới tạo ra hai thông tin chính:

- Tạo ra một tập hợp các hộp giới hạn (bounding boxes) có điểm tin cậy, cho biết rằng một đối tƣợng tồn tại bên trong mỗi hộp giới hạn

- Tạo ra một bản đồ xác suất lớp (class probabilities) cho mỗi ô trong lưới, cho biết lớp đối tượng nào có khả năng cao nhất tồn tại trong ô đó trong thực tế, với giả định rằng đối tƣợng hoàn toàn nằm trong ô

Cuối cùng, thông tin này đƣợc kết hợp để tạo ra khả năng nhận diện đối tƣợng trong hình ảnh cuối cùng

Hình 2.3 Phân tích mỗi ô lưới trong ảnh Đối với mỗi ô lưới chúng ta có thể tính toán một tập hợp các vector đầu ra.Vector đầu tiên là một vector xác suất của lớp Vector thứ hai là một tập hợp các hộp giới hạn với các tham số √ √ Trong đó với là tâm của hộp giới hạn w, h lần lƣợt là chiều rộng và chiều cao của hộp C là điểm tin cậy biểu thị điểm tin cậy của mô hình rằng là đối tƣợng trên thực tế hiện tồn tại trong hộp Để giảm hiện tƣợng biến đổi không đồng nhất của các thông số w và h khi sử dụng hàm mất mát, trong thuật toán YOLO, thay vì dự đoán trực tiếp w và h, ta dự đoán căn bậc hai của chúng (đƣợc ký hiệu là √ và √ ) Điều này giúp làm giảm ảnh hưởng của các giá trị w và h lớn đối với hàm mất mát

Trong mỗi ô có thể có nhiều hộp, điều này chỉ cho phép khi ô hiện tại phát hiện nhiều đối tƣợng Thay vì trong thực tế có nhiều vector thì tập hợp chúng lại thành 1 vector lớn có độ dài là B x 5 + n trong đó n là số lớp trên một đối tƣợng và B là đại diện cho số lƣợng các hộp giới hạn Trong bài báo gốc của tác giả sử dụng S = 7, B = 2 và n = 20 vì vậy ta thu đƣợc vector đầu ra có độ dài B x 5 + n

Với đầu vào là một hình ảnh và đầu ra của mô hình là một ma trận 3 chiều với kích thước S×S×(5×B+n), trong đó mỗi ô chứa (5×B+n) tham số Ví dụ, nếu hình ảnh được chia thành lưới 7×7 ô và mỗi ô cần dự đoán 2 hộp giới hạn cùng 3

9 loại đối tƣợng (chó, ô tô, xe đạp), ta có: 5×N+M = 5×2+3 = 13 Vì vậy, đầu ra sẽ có kích thước 7×7×13, với mỗi ô chứa 13 tham số Như vậy, tổng số hộp giới hạn đƣợc dự đoán là 7×7×2 Mỗi hộp giới hạn đƣợc biểu diễn bởi 5 thành phần: , trong đó là tọa độ trung tâm của hộp giới hạn, là chiều rộng và chiều cao, và prediction đƣợc tính bằng Pr(Object)∗ IOU(pred, truth)

Cách tính tọa độ hộp giới hạn

Hình 2.4 Cách chuẩn hóa kích thước x,y,w,h

Với hình ảnh đƣợc chia thành các ô và mỗi ô có 13 tham số, ta có thể hiểu đơn giản nhƣ sau: tham số đầu tiên cho biết liệu ô đó có chứa đối tƣợng hay không (P(Object)) Các tham số từ 2 đến 5 lần lƣợt trả về tọa độ x, y và kích thước w, h của Box1 Các tham số từ 6 đến 10 tương tự cho Box2 Tham số 11,

12, và 13 là xác suất ô đó chứa các đối tƣợng cụ thể: chó (P(chó|object)), ô tô (P(ô tô|object)), và xe đạp (P(xe đạp|object)) Lưu ý rằng, tâm của hộp giới hạn nằm trong ô nào thì ô đó sẽ chứa thông tin về đối tƣợng, dù đối tƣợng có thể mở rộng ra các ô khác Điều này có nghĩa là nếu một ô chứa nhiều tâm của hộp giới hạn hoặc nhiều đối tƣợng thì mô hình sẽ gặp khó khăn trong việc nhận diện, đây là một hạn chế của mô hình YOLO1 Do đó, cần tăng số lƣợng ô trong một hình ảnh để cải thiện khả năng phát hiện đối tƣợng Điều này giải thích lý do vì sao việc chia nhỏ ô có thể ảnh hưởng đến hiệu quả của mô hình phát hiện đối tượng

HÀM TÍNH IOU

IOU là một hàm đánh giá độ chính xác của các bộ phát hiện đối tƣợng trên một tập dữ liệu cụ thể Công thức tính IOU:

Với "Area of Overlap" là diện tích phần giao nhau giữa hộp giới hạn dự đoán và hộp giới hạn thực tế, còn "Area of Union" là diện tích phần hợp giữa hộp giới hạn dự đoán và hộp giới hạn thực tế Các hộp giới hạn này đƣợc đánh nhãn thủ công trong tập huấn luyện và tập kiểm tra Nếu IOU > 0.5 đƣợc đánh giá là tốt Điều này có nghĩa là vùng dự đoán và vùng thực tế có mức độ trùng khớp tương đối cao, giúp xác định độ chính xác của bộ phát hiện đối tƣợng.

HÀM MẤT MÁT

Hàm mất mát trong YOLO đƣợc tính dựa trên sự chênh lệch giữa dự đoán của mô hình và nhãn thực tế Cụ thể, hàm mất mát bao gồm tổng của ba thành phần chính:

- Độ mất mát của việc dự đoán loại nhãn của đối tƣợng - Classifycation loss

- Độ mất mát của dự đoán tọa độ tâm, chiều dài và chiều rộng của hộp giới hạn (x, y, w, h) - Localization loss

- Độ mất mát của việc dự đoán liệu hộp giới hạn đó có chứa đối tƣợng hay không so với nhãn thực tế tại ô vuông đó - Confidence loss

Classifycation loss - độ mất mát của việc dự đoán loại nhãn của đối tƣợng, hàm lỗi này chỉ tính trên những ô vuông có xuất hiện đối tƣợng, còn những ô vuông khác thường không quan tâm Công thức tính classifycation loss:

Localization loss là hàm dùng để tính giá trị sai số của hộp giới hạn dự đoán, bao gồm tọa độ tâm, chiều rộng và chiều cao so với vị trí thực tế từ dữ liệu huấn luyện của mô hình Cần lưu ý rằng không nên tính giá trị sai số này trực tiếp từ kích thước ảnh thực tế mà phải chuẩn hóa về khoảng [0, 1] so với tâm của hộp giới hạn Việc chuẩn hóa này giúp mô hình dự đoán nhanh chóng và chính xác hơn so với việc sử dụng các giá trị ảnh gốc (nó làm giảm độ phức tạp và sự biến thiên, đồng nhất các dữ liệu đầu vào) Để hiểu rõ hơn thì ta xem ví dụ bên dưới:

Hình 2.5 Chuẩn hóa kích thước ảnh đào tạo mô hình Yolo

Giá trị hàm Localization loss đƣợc tính dựa trên tổng mất mát của việc dự đoán tọa độ tâm và kích thước của hộp giới hạn dự đoán so với hộp

12 giới hạn thực tế Tại mỗi ô chứa đối tƣợng, ta chọn hộp giới hạn có chỉ số IOU tốt nhất, rồi tính độ mất mát dựa trên hộp giới hạn này

Giá trị hàm mất mát của việc dự đoán tọa độ tâm của hộp giới hạn dự đoán so với tọa độ tâm thực tế ̂ ̂ của hộp giới hạn thực tế đƣợc tính nhƣ sau:

Giá trị hàm mất mát dự đoán của hộp giới hạn dự đoán so với hộp giới hạn thực tế đƣợc tính nhƣ sau :

∑ ∑ (√ √ ̂ ) (√ √ ̂ ) Ở ví dụ trên thì S =7, B =2, còn là trọng số thành phần với giá trị là 5 Giá trị này đƣợc lấy từ bài báo gốc của tác giả

Confidence loss là độ mất mát giữa dự đoán liệu hộp giới hạn có chứa đối tƣợng hay không so với nhãn thực tế tại ô vuông đó Độ lỗi này đƣợc tính cho cả các ô vuông chứa đối tƣợng và các ô vuông không chứa đối tƣợng Điều này giúp mô hình học cách không chỉ phát hiện chính xác các đối tƣợng mà còn giảm thiểu các dự đoán sai lệch trong các vùng không có đối tƣợng

Với ví dụ trên thì S =7, B =2, còn là trọng số thành phần trong bài báo gốc tác giả lấy giá trị là 0.5 Đối với các hộp j của ô thứ i nếu xuất hiện đối tƣợng thì và ngƣợc lại

13 Tổng kết lại thì có hàm mất mát là tổng của 3 hàm mất mát trên :

THIẾT KẾ HỆ THỐNG BÃI ĐỖ XE THÔNG MINH

MÔ HÌNH CHUNG CỦA TOÀN HỆ THỐNG BÃI ĐỖ XE THÔNG

Với mục tiêu ban đầu là tích hợp công nghệ nhận diện biển số xe kết hợp với công nghệ RFID/NFC trong hệ thống bãi xe thông minh để thời tối ƣu hóa chi phí, giảm thiểu thời gian di chuyển và tăng cường hiệu suất so với các bãi đỗ xe truyền thống Hệ thống đƣợc phân thành bốn thành phần chính:

- Khối máy chủ: sử dụng dịch vụ EC2 AWS đƣợc lập trình bằng Javascript liên kết với cơ sở dữ liệu MongoDB, xuất các API cung cấp cho các khối khác và cũng là nơi lưu trữ broker MQTT

- Khối ứng dụng: bao gồm website và ứng dụng di động dùng để tương tác với người dùng được phát triển và lập trình

- Khối xử lý: xây dựng phần mềm trên máy tính bằng Python và ứng dụng yolo để nhận diện biển số, xác thực thông tin với dữ liệu trong cơ sở dữ liệu, từ đó gửi tín hiệu điều khiển

- Khối điều khiển: sử dụng vi điều khiển STM32F103C8T6 giao tiếp với mô-đun PN532 để đọc RFID/NFC, mô-đun BW16 để giao tiếp MQTT với khối xử lý và sử dụng servo làm barie của hệ thống

Hình 3.1: Sơ đồ khối hệ thống bãi đỗ xe thông minh

Dựa vào hình 3.1 ta thấy hệ thống hoạt động nhƣ sau:

Người dùng di chuyển xe vào vị trí quy định để có hình ảnh tốt nhất và sau đó quét thẻ RFID/NFC vào thiết bị đọc thẻ (khối điều khiển) Sau khi đọc đƣợc mã RFID/NFC từ người dùng thiết bị tự động gửi mã thẻ đó lên máy chủ MQTT Phần mềm trên máy tính(khối xử lý) sử dụng lệnh SUBSCRIBE để nhận dữ liệu mã RFID/NFC cùng với đó là việc nhận diện biển số Sau khi có đầy đủ 2 dữ liệu này phần mềm tiến hành lấy dữ liệu thông qua API từ cơ sở dữ liệu và kiểm tra mã RFID/NFC đó phù hợp với nhau không Sau đó gửi lệnh mở cửa nếu dữ liệu đúng với trong cơ sở dữ liệu gửi lệnh đóng nếu sai và lưu lại dữ liệu vào cơ sở dữ liệu theo phương thức POST Việc gửi lệnh đóng hay mở cửa đều qua giao thức

16 MQTT thông qua lệnh PUBLISH Khối điều khiển có nhiệm vụ nhận lệnh từ máy tính sau đó điều khiển servo theo lệnh đóng mở tương ứng

Hệ thống này tích hợp một website dành cho việc giám sát toàn bộ hoạt động của nó Dữ liệu đƣợc trực quan hóa trên website, giúp quản lý dễ dàng hơn và thuận tiện hơn Quản trị viên cũng có khả năng điều khiển và chỉnh sửa dữ liệu một cách tiện lợi thông qua giao diện web Đồng thời, hệ thống cũng cung cấp một ứng dụng điện thoại cho người sử dụng, giúp họ truy cập vào lịch sử và thực hiện các thao tác nhƣ gia hạn thẻ một cách tiện lợi Điều này đảm bảo rằng người dùng có thể sử dụng toàn bộ các tính năng cần thiết thông qua điện thoại di động của họ, phù hợp với xu hướng và nhu cầu hiện nay Đối với máy chủ đây là nơi cung cấp các API giao tiếp giữa khối ứng dụng và khối xử lý với máy chủ Đây cũng là nơi xử lý backend cho khối ứng dụng xử lý các tính toán logic cho hệ thống và đƣa ra các dữ liệu đã xử lý cho khối ứng dụng thông qua API.

THIẾT KẾ PHẦN CỨNG

3.2.1 Sơ ồ khối khối iều khiển

Trong mọi hệ thống, thiết kế phần cứng đóng một vai trò quan trọng và gần nhƣ không thể thiếu Hình 3.2 Thể hiện sơ đồ khối khối điều khiển của hệ thống

Hình 3.2 Sơ đồ khối khối điều khiển hệ thống bãi đỗ xe thông minh

Hệ thống gồm 5 khối chính:

- Khối vi điều khiển: đây là trung tâm xử lý các hoạt động của thiết bị

- Khối nguồn: đây là nơi cung cấp nguồn cho thiết bị

- Khối giao tiếp RFID/NFC, GPIO, PWM : đây là nơi giao tiếp với module PN532 để đọc thẻ RFID/NFC, tạo xung PWM điều khiển servo mở cửa hoặc đóng cửa và ngõ ra điều khiển đèn, còi

- Khối modbus: dùng để gỡ lỗi trong quá trình viết chương trình cho phần cứng Ngoài ra nó cũng là phương án dự phòng để dùng giao tiếp với các thiết bị khác thông qua modbus với trường hợp sử dụng nhiều hơn 1 thiết bị

- Khối Internet: dùng để truyền và nhận dữ liệu đƣợc truyền qua giao thức MQTT với máy tính

Mỗi khối con trong khối điều khiển đều đóng một vai trò riêng để cùng tạo nên một sản phẩm hoàn thiện Sau đây nhóm thực hiện xin trình bày chi tiết từng phần của khối điều khiển

Khối MCU: Khối MCU (Microcontroller Unit hay là vi điều khiển) là một thành phần quan trọng của khối điều khiển Nó thường được coi là "trái tim" của các thiết bị điện tử vì nó thực hiện nhiều chức năng xử lý và điều khiển thiết bị

Lựa chọn linh kiện: Qua quá trình cân nhắc lựa chọn linh kiện Nhóm quyết định sử dụng STM32F103C8T6 làm vi xử lý trung tâm của thiết bị Bởi vì:

- Hiệu suất và tính linh hoạt

- Tích hợp nhiều tính năng tích hợp nhƣ giao tiếp USART, SPI, I2C, GPIO, ADC và nhiều tính năng khác Điều này giúp giảm số lƣợng linh kiện ngoại vi cần thiết trong dự án

- Tiêu thụ điện năng thấp, kích thước nhỏ gọn

- Cộng đồng hỗ trợ mạnh mẽ

- Giá cả hợp lý so với các dòng vi điều khiển khác[8]

Sơ đồ nguyên lí thiết kế mạch khối MCU:

Hình 3.3: Sơ đồ nguyên lý vi xử lí thiết kế cho mạch

Dựa vào sơ đồ nguyên lý vi xử lý thiết kế cho mạch ta sử dụng các chân:

- NRST: Chân này dùng để khởi động lại vi điều khiển về trạng thái ban đầu Chân này ban đầu đƣợc giữ mức cao khi chuyển sang mức thấp thì mạch tự động khởi động lại

- PA1: Đây là chân GPIO thông thường dùng để khởi động lại module WiFi thông qua chân reset của module WiFi

- PA2: Đây là chân UART2_TX dùng để gửi dữ liệu UART tới module WiFi

- PA3: Đây là chân UART2_RX dùng để nhận dữ liệu UART từ module WiFi

- PA4: Đây là chân lựa chọn SPI để giao tiếp với module PN532

- PA5: Đây là SCK để giao tiếp SPI

- PA6: Đây là chân MISO nhận dữ liệu SPI

- PA7: Đây là chân MOSI truyền dữ liệu SPI

- PB0: Đây là chân GPIO thông thường dùng để reset module PN532

- PB1: Đây là chân GPIO thông thường được nối với chân REQ của module PN532 để gửi yêu cầu từ vi xử lý đến PN532

- PB2: Đây là chân GPIO thông thường giao bật tắt còi

- PB6: Đây là chân UART1_TX dùng để gửi dữ liệu UART tới ic MAX485 để giao tiếp modbus

- PB7: Đây là chân UART1_RX dùng để nhận dữ liệu UART từ ic MAX485 để giao tiếp modbus

- PB9: Chân tạo ra xung PWM điều khiển servo

- PB10: Chân GPIO thông thường dùng để bật led xanh

- PB11: Chân GPIO thông thường dùng để bật led đỏ

Khối giao tiếp RFID/NFC, GPIO, PWM: Hệ thống sử dụng module PN532 để đọc ghi thẻ RFID/NFC Servo để điểu khiển barie chắn cửa đi ra vào bãi, còi và led ra tín hiệu cho người dùng

Lựa chọn linh kiện: Qua quá trình cân nhắc lựa chọn linh kiện Nhóm quyết định sử dụng Module PN532 để đọc dữ liệu bên trong thẻ vì có các đặc điểm[9]:

- Khả năng tương thích với bộ xử lý trung tâm thông qua nhiều cổng giao tiếp nhƣ UART, SPI, I2C

- Có thể nhận thẻ với khoảng cách 5~7cm

- Hỗ trợ đọc/ghi các chuẩn thẻ RFID NFC

- Kích thước và phạm vi hoạt động tương thích với mô hình thiết kế

- Khả năng đáp ứng và phản hồi nhanh chóng

Sử dụng servo để điều khiển barie bởi vì servo là phương án tối ưu về giá thành cũng như kích thước, hiệu suất và phù hợp cho mô hình Servo dùng để điều khiển từ xung PWM để điều chỉnh góc quay Điều này đƣợc tận dụng cho việc đóng mở barie với góc 90° và 0°

Vẽ mạch nguyên lí cho khối giao tiếp RFID/NFC, GPIO, PWM:

Hình 3.4 Sơ đồ nguyên lí khối giao tiếp RFID/NFC, GPIO, PWM

Trong mạch thiết kế có thể sử dụng phương thức giao tiếp SPI để giao tiếp với module PN532

Phần tín hiệu led sử dụng led 2 màu xanh đỏ với chân âm chung Sử dụng ngõ ra mức cao thấp để điều khiển led tùy ý

Phần còi chân dương được nối trực tiếp lên 3.3V chân còn lại nối với chân GPIO của vi điều khiển Khi đặt ngõ ra mức thấp thì còi sẽ tạo ra tiếng kêu ngƣợc lại khi ngõ ra mức cao thì còi tắt tiếng Điều khiển servo dùng chân PWM của vi điều khiển để đóng hay mở barie bằng cách điều khiển góc servo 90° hoặc 0°

Khối Modbus: Khối Modbus sử dụng để gỡ lỗi trong quá trình viết mã cho chương trình Chúng ta sử dụng hàm “printf“ để truyền dữ liệu sang khối modbus và sử dụng cổng USB RS485 để đọc dữ liệu này, giúp việc gỡ lỗi trở nên thuận tiện hơn Ngoài ra, khối Modbus còn là phương án dự phòng cho việc truyền nhận dữ liệu giữa các thiết bị khi hệ thống có nhiều thiết bị hơn

Lựa chọn linh kiện: Việc lựa chọn MAX485[10] là một quyết định hợp lý vì nó cung cấp nhiều ƣu điểm cho các ứng dụng RS-485 Nó linh hoạt, tiêu thụ năng lượng thấp, đáng tin cậy trong môi trường khắc nghiệt và giá cả phải chăng Thiết kế mạch nguyên lí của khối modbus:

Hình 3.5 Sơ đồ nguyên lí khối modbus

Mạch đƣợc thiết kế luôn ở chế độ nhận dữ liệu Khi dữ liệu đƣợc truyền đi chân TX đƣợc kéo xuống thấp thì chân điều khiển DE cùng với chân ̅̅̅̅ đẩy xuống mức thấp lúc đó thiết bị đƣợc chuyển sang chế độ truyền dữ liệu Khi không truyền dữ liệu thì chân TX về mức cao dẫn tới chân điều khiển DE cùng với chân ̅̅̅̅ cũng mức cao thiết bị tự động chuyển sang chế độ nhận dữ liệu

THIẾT KẾ PHẦN MỀM

3.3.1 Thiết kế phần mềm trên khối iều khiển

Bước 1: Hệ thống khởi tạo hệ thống

Bước 2: Hệ thống kiểm tra tình trạng kết nối WiFi của thiết bị

Trường hợp có WiFi thì thiết bị tiếp tục thực hiện bước 3

Trường hợp không có wifi thì thiết bị chuyển sang chế độ cấu hình WiFi từ điện thoại Nếu kết nối WiFi bằng điện thoại thành công thì thiết bị tiến hành thực hiện bước 3 Nếu quá thời gian chờ thì thiết bị tự động khởi động lại từ đầu

Bước 3: Thiết bị kết nối với máy chủ

MQTT đƣợc cấu hình sẵn Nếu kết nối thành công thiết bị tiếp tục thực hiện bước

4 Nếu kết nối không thành công thì thiết bị tự khởi động lại

Bước 4: Thiết bị khởi tạo mô-đun PN532 để tiến hành đọc mã thẻ Nếu khởi tạo thành công thì thiết bị thực hiện bước 5 đi vào phần chính của chương trình Nếu khởi tạo thất bại thì thiết bị tự động khởi động lại

Bước 5: Hệ thống bắt đầu với việc đọc thẻ

RFID/ NFC Kiểm tra có thẻ nào đang đƣợc đặt vào đầu đọc không

Hình 3.9 Lưu đồ phần mềm trên khối điều khiển

- Trường hợp có dữ liệu thiết bị sử dụng còi để báo hiệu cho người dùng biết là thẻ đã đƣợc đọc và sau đó gửi mã trong thẻ lên máy tính thông qua MQTT

- Trường hợp không có thẻ nào được đọc thì sẽ bỏ qua bước gửi báo hiệu và gửi dữ liệu lên MQTT

Bước 6: Kiểm tra dữ liệu từ MQTT xuống

- Trường hợp có dữ liệu thì phân tích dữ liệu nếu mở cửa thì bật đèn xanh, điều khiển xung PWM để mở cửa bằng servo

- Trường hợp dữ liệu là đóng cửa thì bật đèn đỏ, khóa cửa bằng servo và kết thúc

Trong quá trình thiết bị hoạt động chương trình sẽ tạo thành một vòng lặp bước 5 đến bước 6 và quay lại để thiết bị hoạt động liên tục trong quá trình sử dụng

3.3.2 Thiết kế phần mềm trên máy tính (khối xử lý)

3.3.2.1 Nhận diện biển số xe sử dụng mô hình Yolo V5

Thu thập tập dữ liệu Để xây dựng một hệ thống nhận diện biển số xe hiệu quả tốt, việc thu thập dữ liệu là bước quan trọng không thể thiếu, quyết định đến hiệu suất và độ chính xác của hệ thống bãi đỗ xe thông minh Bộ dữ liệu hình ảnh dùng để huấn luyện cần phải đa dạng và phong phú, nhằm đảm bảo khả năng phản ánh chân thực các đối tƣợng cần nhận diện Để nhận diện biển số xe ta cần phải có 2 tập dữ liệu bao gồm:

- Dữ liệu về khung biển số xe: giúp hệ thống phát hiện biển số của từng loại xe khác nhau[14]

- Dữ liệu về kí tự: giúp hệ thống nhận diện đƣợc chữ cái trên biển số[15]

Dữ liệu về khung biển số xe:

Hình 3.10 Hình ảnh biển số xe ô tô Việt Nam

Dữ liệu hình ảnh biển số xe Việt Nam đƣợc đánh nhãn bao quanh biển số cung cấp dữ liệu cho việc học sâu

Hình 3.11 Hình ảnh biển số xe ô tô Việt Nam đƣợc dán nhãn khung

Khi ta khoanh vùng biển số cần phải chuyển đổi nhãn khoanh vùng sang các điểm trong không gian để phù hợp với việc học sâu Dữ liệu thu đƣợc trong tệp txt từ nhãn trên cho việc đào tạo mô hình lần lƣợt là 0, 0.62900, 0.778449, 0.167500, 0.075941 tương ứng với thứ tự lớp, tọa độ tâm theo trục x, tọa độ tâm

28 theo trục y, độ rộng, chiều cao.Ở trong thứ tự lớp bởi vì ở tập dữ liệu chỉ phân biệt là khung biển số xe nên mặc định chỉ có một lớp là “0” Vì vậy tổng số lớp trong nhận diện bằng 1

Dữ liệu về kí tự của biển số xe:

Hình 3.12 Hình ảnh biển số xe Việt Nam

Hình ảnh trên là ví dụ về biển số xe ở Việt Nam Tuy nhiên để đào tạo cho việc học sâu chúng ta cần 2 tệp đó là hình ảnh và nhãn

Hình 3.13 Hình ảnh biển số xe Việt Nam đƣợc dán nhãn cho kí tự

29 Phần nhãn sẽ được lưu vào tệp txt lần lượt là ghi lớp đối tượng, vị trí trục x, y của tâm, độ rộng và độ cao của nhãn Tuy nhiên so với tập dữ liệu của khung biển số thì số lớp của việc nhận diện kí tự cần nhiều lớp hơn để đại diện cho các đối tƣợng cần nhận diện là các chữ số và chữ cái trong biển số xe Tổng số lớp cần nhận diện là 30 gồm tất cả kí tự và chữ số

Phân chia tập dữ liệu: nhóm thực hiện phân chia tập dữ liệu thành tập train và valid theo tỷ lệ 70-30: Đảm bảo đủ dữ liệu cho quá trình huấn luyện: Sử dụng 70% dữ liệu để huấn luyện giúp mô hình học đƣợc nhiều hơn từ dữ liệu Đảm bảo độ chính xác của mô hình: Sử dụng 30% dữ liệu để kiểm tra giúp đánh giá độ chính xác và hiệu suất mô hình

Hình 3.14 Phân chia tập dữ liệu khung biển số và kí tự trên biển số

Quá trình o tạo cho model nhận diện khung biển số

Ta tiến hành tải mô hình Yolov5 Ở đây nhóm sinh viên đã lấy mã nguồn yolov5 tải lên github sẵn để chỉnh sửa đường dẫn tới tập dữ liệu cho việc đào tạo mô hình

Hình 3.15 Tải mô hình yolo được chỉnh sửa file đường dẫn tới tập dữ liệu

30 Khi đào tạo mô hình cần thiết lập môi trường và cài đặt các thư viện cần thiết Để thuận tiện cho việc cài đặt các thƣ viện cần thiết khi đào tạo mô hình học sâu, ta có thể lưu tên các thư viện này vào một tệp requirements.txt Điều này cho phép dễ dàng tái tạo môi trường bằng cách cài đặt tất cả các thư viện từ tệp này Hình dưới đây minh họa quá trình cài đặt này

Hình 3.16 Cài đặt các thƣ viện cần thiết cho mô hình

Nhóm tiến hành huấn luyện lại mô hình với các tham số gốc nhƣ sau: kích thước ảnh là 320x320 pixel, batch size là 32, và số lượng epochs là 30.

Hình 3.17 Mã lệnh dùng để thực hiện đào tạo mô hình nhận diện khung biển số

Kết quả đào tạo của mô hình:

Hình 3.18 Kết quả đào tạo của mô hình nhận diện khung biển số xe

Từ hình ảnh ta có tóm tắt kết quả mô hình:

Thông số mô hình: Số tầng (layers): 212, Số tham số (parameters):

20,852,934 , GFLOPs: 47.9 Đánh giá hiệu suất: Số hình ảnh: 1652 Số đối tƣợng: 1667 Độ chính xác

(Precision): 0.996 Tỷ lệ hồi nhớ (Recall): 0.995 mAP@50: 0.994 mAP@50-95: 0.73

Nhận xét: Mô hình đạt hiệu suất xuất sắc với độ chính xác và tỷ lệ hồi nhớ cao mAP@50-95 thấp hơn, cho thấy khó khăn trong việc duy trì hiệu suất qua các ngƣỡng IoU nghiêm ngặt hơn

Hình 3.19 Kết quả dự đoán khung biển số xe của mô hình

Sau khi hoàn thành quá trình đào tạo mô hình, nhóm thực hiện dự đoán trên một tập hình ảnh mới, trong đó có hình ảnh của khung biển số xe nhƣ đƣợc minh họa trong hình 3.19 Kết quả dự đoán cho thấy rằng mô hình có khả năng nhận diện kí tự trên biển số với mức độ chính xác khá cao

Quá trình o tạo cho mô hình nhận diện kí tự

Sau khi đánh giá và điều chỉnh tham số, nhóm quyết định tiến hành huấn luyện lại mô hình với các tham số mới như sau: kích thước ảnh là 640x640 pixel, batch size là 32, và số lượng epochs là 30 Bước này là quan trọng để cải thiện hiệu suất và chất lƣợng của mô hình nhận diện

Hình 3.20 Mã lệnh đào tạo mô hình nhận diện kí tự trên biển số xe

32 Kết quả đào tạo của mô hình:

Hình 3.21 Kết quả đào tạo của mô hình nhận diện kí tự biển số xe

Từ hình ảnh ta có tóm tắt kết quả mô hình:

Tổng quan mô hình: Số tầng (layers): 212, Số tham số (parameters):

Hiệu suất mô hình chung: Số lƣợng hình ảnh: 767 Số lƣợng đối tƣợng:

6236 Độ chính xác (Precision): 0.973 Tỷ lệ hồi nhớ (Recall): 0.970 mAP@50: 0.984 mAP@50-95: 0.763

Nhận xét: - Mô hình đạt hiệu suất cao với Precision và Recall đều xấp xỉ

THIẾT KẾ HỆ THỐNG SERVER

3 4.1 Sử dụng dịch vụ Amazon EC2 v lựa chọn cấu hình phù hợp cho hệ thống bãi ỗ xe

Amazon Elastic Compute Cloud (Amazon EC2) là một dịch vụ web cung cấp khả năng tính toán linh hoạt và an toàn trên nền tảng đám mây EC2 cung cấp các máy ảo có thể mở rộng, bao gồm CPU, bộ nhớ (RAM), và các thành

38 phần phần cứng ảo khác nhƣ bộ nhớ đĩa (EBS), card mạng, và hệ điều hành (AMI)

Với EC2, người sử dụng có thể thuê các cấu hình RAM và CPU khác nhau Ví dụ, các instance loại T2, T3 và T4g phù hợp cho các tác vụ có yêu cầu tài nguyên biến đổi, trong khi các instance loại M5 và C6g dành cho các ứng dụng cần hiệu năng cao và ổn định Ở dự án này, nhóm thực hiện sử dụng T2.micro cho server Cấu hình của server này bao gồm:

Phù hợp với các ứng dụng IoT có nhu cầu tài nguyên thấp, chẳng hạn nhƣ các thiết bị IoT gửi dữ liệu cảm biến định kỳ hoặc các dịch vụ web nhỏ Với chi phí thấp, T2.micro là lựa chọn kinh tế cho các dự án IoT có ngân sách hạn chế hoặc không yêu cầu tài nguyên tính toán lớn T2.micro là một lựa chọn khởi đầu tốt cho các dự án IoT nhỏ hoặc thử nghiệm Để duy trì hiệu suất và độ tin cậy của server IoT, hãy chú ý đến việc quản lý tài nguyên và sẵn sàng nâng cấp lên các instance mạnh hơn nếu cần thiết Điều này sẽ giúp tận dụng tối đa các dịch vụ và tính năng của Amazon EC2 một cách hiệu quả

3.4.2 Sử dụng MQTT ể truyền nhận dữ liệu giữa các thiết bị IoT v server

Trong hệ thống bãi đỗ xe thông minh, nhóm thực hiện ứng dụng giao thức MQTT để truyền nhận dữ liệu giữa các thiết bị IoT (khối điều khiển) và server MQTT là một giao thức nhắn tin nhẹ, lý tưởng cho các kết nối từ xa yêu cầu ít băng thông và độ tin cậy cao Các thiết bị IoT sẽ gửi dữ liệu qua MQTT đến server, nơi dữ liệu sẽ được xử lý và lưu trữ trong MongoDB

Xây dựng và cấu hình MQTT Broker Để hiện thực hóa việc này, cần thiết lập một MQTT broker trên máy chủ ảo sử dụng thƣ viện Mosca và server MQTT broker đƣợc viết bằng ngôn ngữ Node.js MQTT Broker sẽ đóng vai trò trung tâm trong hệ thống nhắn tin

39 publish/subscribe, nhận tin nhắn từ các publishers và phân phối chúng đến các subscribers

Vai trò của MQTT Broker

MQTT broker đóng vai trò then chốt trong việc quản lý luồng liên lạc giữa các máy khách MQTT, đảm bảo tin nhắn đƣợc gửi và nhận một cách đáng tin cậy Trong hệ thống bãi đỗ xe thông minh, broker MQTT hoạt động nhƣ một trung gian giao tiếp giữa khối điều khiển và khối xử lý của hệ thống, đảm bảo khả năng truyền nhận dữ liệu một cách hiệu quả và ổn định

3.4.3 Quá trình phát triển v xây dựng backend:

Trong dự án này môi trường node.js và ngôn ngữ javascript sẽ được sử dụng để phát triển phía server cũng như trong việc lưu dữ liệu dạng NoSQL (MongoDB) Để đáp ứng việc đồng bộ hóa dữ liệu giữa server, ứng dụng di động và website và toàn bộ hệ thống hoạt động một cách ổn định nên cả MongoDB và backend đều đƣợc chạy chung một server và các dữ liệu đƣợc gửi vào server được lưu trực tiếp vào database nhằm đảm bảo sự ổn định và có tính liên kết

Hình 3.25 Sơ đồ các lớp cơ sở dữ liệu hệ thống

Dựa vào hình 3.25 các model được dùng để lưu trữ và triển khai các dữ liệu được cập nhật thông qua việc đăng ký tài khoản người dùng tại ứng dụng di

40 động và dữ liệu đƣợc gửi từ các ngoại vi thông qua MQTT cụ thể là từ quá trình nhận diện biển số và tín hiệu sóng RFID/NFC

Các dữ liệu đƣợc triển khai thông qua các đầu API:

- Phần ứng dụng di động:

Model Login gồm 2 thông tin đăng nhập là gmail và password kiểu dữ liệu là String, dữ liệu được truyền qua API theo phương thức post(/login): dùng để kiểm tra và xử lí đăng nhập tài khoản người dùng

Model Register gồm 3 thông chuyển tiền là gmail và password kiểu dữ liệu là String, dữ liệu được truyền qua API theo phương thức post(/register): dùng để kiểm tra và cập nhật thông tin vừa đăng ký vào cơ sở dữ liệu

Model Transfer gồm 3 thông tin đăng ký là senderMoney, receiverMoney và money, trường senderMoney được mặc định là gmail tài khoản đăng nhập, receiverMoney là gmail người được nhận và money là số tiền cần chuyển Dữ liệu được truyền qua API theo phương thức post(/transfer): dùng để chuyển tiền qua lại giữa các người dùng trong hệ thống

Model Datauser gồm 10 thông tin của users đây đƣợc xem là model quan trọng nhất của toàn bộ hệ thống dùng để lưu trữ các id “user” và các trường liên kết với các model khác Dữ liệu được truyền qua API theo phương thức get(/datauser) nhằm thực hiện các chứng năng dùng để hiển thị các thông tin của user đến website ngoài ra còn có thể dùng để hiển thị dữ liệu của từng users theo id thông qua API get(/datauser/:id), dùng để cập nhật lại thông tin users sau khi chỉnh sửa và lưu vào cơ sở dữ liệu thông qua API put(/datauser/:id), dùng để xóa các thông tin của users theo id tương ứng thông qua API delete(/datauser/:id)

Model Statistic gồm 5 trường thông tin dữ liệu được truyền qua API theo phương thức get(/Statistic): ở API này dùng để hiển thị các thông số của trạng thái xe ra vào trong một ngày bao gồm: số xe vào = tổng các trạng thái indoor từ Stateuser (tính theo ngày), số xe ra = tổng các trạngthasi outdoor từ Stateuser (tính theo ngày) Số xe còn lại trong bãi = tổng các trạng thái indoor của users trong model datauser thay vì sử dụng trạng thái ở model Stateuser để tránh tình

41 trạng lỗi khi xe để qua ngày Lợi nhuận = trạng thái outdoor (đƣợc tính trong một ngày) nhân với giá tiền

Model Topuser gồm 2 trường thông tin dữ liệu được truyền qua API theo phương thức get(/TopUser):dùng để hiển thị top 10 users sử dụng dịch vụ nhiều nhất tháng dựa vào id “user” và trạng thái “indoor” để thực hiện số lần sử dụng dịch vụ và reset sau mỗi tháng

Model StatisticMonth gồm 3 trường thông tin dữ liệu là users, count và được truyền qua API theo phương thức get(/StatisticByMonth): dùng hiển thị số lƣợt mà các users đã ra vào mỗi ngày và thống kê số lƣợt của các ngày trong 1 tháng

THIẾT KẾ HỆ THỐNG FRONT-END

3.5.1 Thiết kế website quản lý

3.5.1.1 Thiết kế giao diện website

Giao diện website cũng là một yếu tố một yếu tố then chốt định sự thành công của trang web, đặc biệt là trong việc cung cấp trải nghiệm người dùng thân thiện và dễ sử dụng Việc thiết kế giao diện không chỉ đòi hỏi sự tinh tế về mặt thẩm mỹ mà còn phải đảm bảo tính năng và chức năng hoạt động hiệu quả

Hình 3.26 Giao diện thiết kế của website

Dưới đây là bản thiết kế giao diện của website:

1 - Thông tin đăng nhập của quản trị viên: Khu vực này cho phép quản trị viên đăng nhập để truy cập vào chức năng quản lý của website

2 - Menu của trang web: Menu bao gồm các phần nhƣ phân tích tổng quan và danh sách tài khoản, giúp quản trị viên dễ dàng điều hướng và truy cập vào các chức năng khác nhau

3 - Biểu đồ phân tích lưu lượng xe: Khu vực này hiển thị biểu đồ phân tích lưu lượng xe theo ngày và theo tháng Tổng số xe ra vào mỗi ngày trong một tháng sẽ được thể hiện dưới dạng biểu đồ tại đây

4 - Danh sách người dùng ra vào nhiều nhất: Khu vực này hiển thị các người dùng ra vào nhiều nhất trong tháng Dựa vào thông tin này, quản trị viên có thể cung cấp các ưu đãi đặc biệt cho các người dùng này

5 - Thống kê số lƣợng xe và lợi nhuận: Khu vực này hiển thị số lƣợng xe vào, ra và số xe còn lại trong bãi Ngoài ra, còn thể hiện tổng số lợi nhuận, giúp quản trị viên dễ dàng thống kê và kiểm soát lƣợng xe trong một ngày

Việc bố trí các thành phần này một cách khoa học và trực quan không chỉ giúp quản trị viên thao tác dễ dàng mà còn nâng cao hiệu quả quản lý.

3.5.1.2 Sơ ồ dữ liệu của website

Hình 3.27 Sơ đồ dữ liệu website

Dữ liệu từ backend đến frontend của trang web này di chuyển theo một luồng logic cụ thể nhằm để đảm bảo rằng các thành phần của giao diện người dùng đƣợc xử lý theo trình tự và nhanh nhất Đầu tiên, dữ liệu đƣợc truy vấn từ backend thông qua các yêu cầu HTTP Backend đƣợc cung cấp thông qua một API RESTful, vì vậy các yêu cầu đƣợc gửi đến các endpoint API tương ứng để lấy dữ liệu Khi dữ liệu được trả về từ backend, nó đƣợc xử lý bằng JavaScript trên frontend để hiển thị trên giao diện người dùng Dữ liệu thường được hiển thị dưới dạng các biểu đồ, bảng dữ liệu và các phần tử khác của giao diện

Các phần tử HTML đƣợc cập nhật bằng dữ liệu mới đƣợc nhận từ backend, như văn bản, số liệu thống kê, và danh sách người dùng Cập nhật các phần tử này giúp đƣa ra các thông tin mới nhất và phản ánh các thay đổi trong dữ liệu từ backend Cuối cùng, dữ liệu được hiển thị trên website để người dùng xem cũng như tương tác với thông tin được cung cấp từ backend Quá trình này giúp đảm bảo rằng dữ liệu đƣợc truyền từ backend đến frontend hiệu quả và chính xác, đồng thời cung cấp trải nghiệm người dùng mượt mà và tương tác

3.5.1.3 Quá trình phát triển v xây dựng website Ở website này toàn bộ tính năng xử lí logic sẽ đƣợc xử lí backend ở server và chỉ get dữ liệu thông qua API từ đó trên website sẽ lấy dữ liệu đó xử lí lại theo đúng formart và hiển thị

Phía front-end website đƣợc sử dụng ReactJS và kết hợp cả html, css đây là hai ngôn ngữ tuy lâu đời nhƣng vẫn còn đƣợc ứng dụng rất phổ biến có các ứng dụng website

Phần xử lý sự kiện trên website đƣợc sử dụng hoàn toàn bằng JavaScript và một thƣ viện quan trọng đó là Axios.js là một thƣ viện HTTP client phổ biến đƣợc sử dụng trong các ứng dụng JavaScript để gửi các yêu cầu HTTP từ một máy khách (client) đến một máy chủ (server) và xử lý các phản hồi từ máy chủ

Nó hoạt động trên cả môi trường trình duyệt và Node.js Axios cung cấp một cách giao tiếp dễ sử dụng và linh hoạt, cho phép bạn thực hiện các yêu cầu HTTP GET, POST, PUT, DELETE và các phương thức khác một cách dễ dàng Nó cũng hỗ trợ các tính năng nhƣ gửi dữ liệu biểu mẫu, xác thực, xử lý lỗi và hủy yêu cầu Một trong những lợi ích chính của Axios là khả năng xử lý promise một cách thuận tiện Điều này cho phép bạn sử dụng cú pháp async/await để viết mã không đồng bộ một cách dễ dàng và rõ ràng hơn

Hình 3.28 Lưu đồ giải thuật request và response dữ liệu

Hình 3.28 Lưu đồ 1 mô tả quy trình từ khi bắt đầu đến khi kết thúc việc hiển thị dữ liệu lên website Quá trình bắt đầu bằng việc hệ thống khởi động và sẵn sàng để lấy dữ liệu từ API Ở bước này, hệ thống gửi yêu cầu đến API để lấy dữ liệu, thường dưới dạng JSON Sau khi nhận được phản hồi từ API, dữ liệu thô sẽ đƣợc định dạng lại để đúng định dạng với yêu cầu của hệ thống Quá trình định dạng này bao gồm chuyển đổi định dạng dữ liệu, lọc thông tin không cần thiết và xử lý các thông tin thô Sau khi dữ liệu đã đƣợc định dạng, nó hiển thị dữ liệu trên website thông qua HTML, CSS và JavaScript JavaScript sẽ đƣợc sử dụng để cập nhật lại tự động, đảm bảo dữ liệu đƣợc biểu diễn rõ ràng và trực quan dưới dạng bảng, biểu đồ hoặc danh sách Cuối cùng, sau khi dữ liệu đã đƣợc hiển thị thành công trên website, quá trình kết thúc Tuy nhiên, nếu cần cập nhật dữ liệu liên tục, quy trình này có thể đƣợc lặp lại nhiều lần theo chu kỳ định sẵn

Lưu đồ 2 của mô tả quy trình từ khi bắt đầu đến khi kết thúc việc xử lý yêu cầu của người dùng và cập nhật dữ liệu vào cơ sở dữ liệu Quá trình bắt đầu

46 bằng việc hệ thống khởi động và sẵn sàng nhận yêu cầu từ người dùng Khi người dùng gửi yêu cầu, hệ thống sẽ tiếp nhận và bắt đầu xử lý yêu cầu đó Việc xử lý yêu cầu có thể bao gồm xác thực thông tin người dùng, kiểm tra các điều kiện liên quan, và thực hiện các tính toán cần thiết Sau khi yêu cầu đƣợc xử lý, hệ thống sẽ cập nhật dữ liệu vào cơ sở dữ liệu, đảm bảo rằng thông tin mới nhất được lưu trữ một cách chính xác và an toàn Cuối cùng, sau khi dữ liệu đã được cập nhật thành công, quy trình kết thúc Hệ thống sau đó sẽ sẵn sàng để tiếp nhận các yêu cầu tiếp theo từ người dùng

3.5.2 Thiết kế ứng dụng di ộng

3.5.2.1 Thiết kế giao diện ứng dụng di ộng

KẾT QUẢ

KẾT QUẢ THỰC HIỆN MÔ HÌNH

Sau quá trình triển khai, nhóm đã thực hiện một mô hình hệ thống bãi giữ xe thông minh và kết quả đƣợc thể hiện qua các hình ảnh chi tiết Mô hình đã đƣợc hoàn thiện không chỉ về mặt tính thẩm mỹ mà còn về mặt hiệu suất hoạt động và đáp ứng chính xác với yêu cầu mà nhóm đã đặt ra từ đầu

Hình 4.1 Khu vực đặt mạch vào trong hộp

Trong Hình 4.1, chúng ta thấy khu vực đặt mạch vào trong hộp Việc thiết kế vỏ hộp này không chỉ nhằm bảo vệ mạch mà còn để tăng tuổi thọ của thiết bị

Vỏ hộp đƣợc thiết kế với tính thẩm mỹ cao, đảm bảo rằng sản phẩm không chỉ bền bỉ mà còn đẹp mắt và chuyên nghiệp Chất liệu và cấu trúc của vỏ hộp đã đƣợc chọn lựa kỹ càng để đảm bảo mạch điện bên trong không bị hƣ hại do các yếu tố bên ngoài nhƣ bụi, độ ẩm hay va đập

Hình 4.2 Công tắc nguồn và jack cắm nguồn của thiết bị

Hình 4.2 mô tả công tắc nguồn và jack cắm nguồn của thiết bị Các thành phần này là một phần gần nhƣ bắt buộc trong mọi sản phẩm điện tử Công tắc nguồn cho phép người dùng bật tắt thiết bị, trong khi jack cắm nguồn từ adapter cung cấp nguồn điện ổn định, đảm bảo thiết bị hoạt động liên tục trong quá trình sử dụng Việc bố trí công tắc và jack cắm một cách hợp lý hỗ trợ người dùng dễ dàng tiếp cận và sử dụng, cũng nhƣ giảm bớt sự rủi ro hỏng hóc do việc cắm rút thường xuyên

Hình 4.3 Khu vực đặt thẻ RFID/NFC

53 Hình 4.3 chỉ ra khu vực đặt thẻ RFID/NFC Thiết bị đƣợc thiết kế để đọc mã thẻ RFID/NFC, vì vậy việc tạo ra một khu vực riêng cho thẻ là rất quan trọng Khu vực này được thiết kế với kích thước phù hợp để thẻ có thể được đặt gọn gàng và chính xác, đảm bảo khả năng đọc thẻ nhanh chóng và hiệu quả Vị trí đặt thẻ cũng được tối ưu hóa để người dùng không gặp khó khăn khi sử dụng

Hình 4.4 Thẻ đƣợc đặt lên hộp

Trong Hình 4.4, chúng ta thấy hình ảnh của thẻ từ đƣợc đặt vừa vặn trên hộp Điều này thể hiện sự linh hoạt và tiện lợi trong việc sử dụng thiết bị Thẻ từ được thiết kế để dễ dàng tương tác với đầu đọc, giúp quá trình kiểm tra và xác nhận diễn ra trong thời gian ngắn, tiết kiệm thời gian cho người sử dụng và đảm bảo an ninh

Hình 4.5 Mặt trước hệ thống bãi đỗ xe thông minh

Mặt trước của hệ thống bãi đỗ xe thông minh được thiết kế để tối ưu hóa việc nhận diện và quản lý phương tiện Tại đây, khu vực đọc thẻ RFID/NFC được đặt ngay trước lối vào, giúp người lái xe dễ dàng quẹt thẻ để đăng ký vào bãi đỗ Ngay sau khu vực đọc thẻ, camera nhận diện đƣợc bố trí ở vị trí thuận lợi để quét biển số xe khi phương tiện tiến vào Camera này được cài đặt ở góc độ tối ưu đã được xác định qua các thực nghiệm trước đó, nhằm đảm bảo khả năng nhận dạng biển số cao nhất Hệ thống barie tự động sẽ mở khi thông tin từ thẻ RFID/NFC và biển số xe đƣợc xác thực thành công

Hình 4.6 Mặt sau hệ thống bãi đỗ xe thông minh

55 Mặt sau của hệ thống chủ yếu là khu vực bãi đỗ xe, nơi các phương tiện đƣợc sắp xếp một cách có trật tự Tại đây, các camera giám sát đƣợc bố trí ở các vị trí chiến lƣợc để quan sát toàn bộ khu vực đỗ xe, đảm bảo an ninh và hỗ trợ quản lý phương tiện Khu vực này không có các thiết bị đọc thẻ RFID/NFC hay barie, chỉ tập trung vào việc cung cấp không gian đỗ xe an toàn và hiệu quả

Hình 4.7 Hình ảnh bãi đỗ xe từ trên cao xuống

Hình ảnh từ trên cao xuống cung cấp cái nhìn toàn cảnh về bãi đỗ xe thông minh Trong hình ảnh này, có thể thấy rõ các khu vực đỗ xe đƣợc sắp xếp khoa học và hiệu quả, với các vạch kẻ rõ ràng để hướng dẫn người lái xe Các camera nhận diện và giám sát đƣợc bố trí sao cho có thể quét toàn bộ khu vực bãi đỗ, đảm bảo an ninh và hỗ trợ quản lý phương tiện Khu vực barie được đặt ở lối vào và lối ra, giúp kiểm soát việc ra vào của các phương tiện một cách tự động và hiệu quả

Hình 4.8 Lối vào của xe khu vực nhận diện biển số

Hình 4.8 mô tả khu vực nhận diện biển số xe Khi xe dừng lại tại khu vực này, hệ thống sẽ thu đƣợc hình ảnh biển số xe rõ ràng, hỗ trợ cho quá trình nhận diện Thẻ từ được đặt lên phần đọc thẻ, giúp xác thực thông tin xe và người sử dụng nhanh chóng và chính xác Khu vực này đƣợc thiết lập nhằm nâng cao việc nhận diện và đảm bảo lưu thông không bị gián đoạn

Hình 4.9 Nhận diện biển số xe phù hợp và không phù hợp với mã RFID/NFC từ khối xử lý

Hình 4.9 mô tả quá trình nhận diện biển số xe phù hợp và không phù hợp với mã RFID/NFC từ khối xử lý Bên trái hình 4.9, khi người dùng quét mã thẻ và có biển số xe phù hợp, phần mềm sẽ hiện thông tin người dùng và truyền lệnh mở cửa cho khối xử lý Bên phải hình 4.9 cho thấy khi người dùng quét sai mã thẻ, phần mềm sẽ thông báo sai thông tin và gửi lệnh đóng cửa Quá trình này đảm bảo rằng chỉ những xe có thông tin chính xác mới đƣợc phép vào bãi, tăng cường an ninh và hiệu quả quản lý

Hình 4.10 Giao diện trang chủ của website thống kê lƣợt xe theo ngày

Giao diện trang chủ thể hiện các thông tin cần thiết giúp quản trị viên có thể theo dõi và tính toán một cách phù hợp Đầu tiên là hiển thị biểu đồ thống kê số lƣợt xe đã vào theo từng ngày của một tháng Tiếp theo thống kê số lƣợng xe đã ra vào của ngày hôm đó và số xe còn lại trong bãi, bên cạnh đó còn hiển thị đƣợc lợi nhuận của ngày hôm đó dựa vào số xe vào và số xe ra Ngoài ra còn thống kê được top 10 khách hàng gửi xe nhiều nhất của tháng từ đó người quản trị viên có thể tri ân bằng cách tích lũy điểm thưởng cho top 10 này để tri ân khách hàng

Hình 4.11 Giao diện trang chủ của website thống kê lƣợt xe theo Tháng

58 Hình 4.11 tương tự như biểu đồ ngày khi chuyển sang tháng thì biểu đồ sẽ hiển thị tổng số lượt xe trong 12 tháng của một năm từ đó người quản trị sẽ có sự so sánh giữa các tháng và kịp thời thay đổi để có lƣợng khách hàng ổn định

Hình 4.12 Giao diện danh sách các tài khoản trên hệ thống

Hình 4.12 là giao diện các tài khoản trên hệ thống, các tài khoản này đƣợc khách hàng đăng ký qua ứng dụng di động ở đây quảng trị viên có thể theo dõi các trạng thái ra vào của xe và chỉnh sửa các thông tin và xóa tài khoản

Hình 4.13 Giao diện chỉnh sửa và cập nhật thông tin khách hàng

59 Hình 4.13 Người quản trị viên có thể trực tiếp chỉnh sửa các thông tin người dùng khi xảy ra sai sót hoặc lỗi và sau đó dữ liệu sẽ được cập nhật vào lại cơ sở dữ liệu của hệ thống

THỬ NGHIỆM VÀ ĐÁNH GIÁ MÔ HÌNH

Để đánh giá mô hình một cách chính xác nhất về hệ thống đã đảm bảo các yêu cầu đặt ra nhóm đã tiến hành các bài thử nghiệm đánh giá dựa trên các đặc tính của hệ thống nhƣ sau

4.2.1 Thử nghiệm 1: Khả năng ọc thẻ RFID/NFC v gửi mã lên MQTT Broker

Trong thử nghiệm đầu tiên, nhóm đã kiểm tra khả năng đọc thẻ RFID/NFC và gửi mã lên MQTT Broker Kết quả đƣợc ghi nhận với thời gian phản hồi của từng lần thử nhƣ sau:

Bảng 4.1 Kết quả thử nghiệm phản hồi đọc thẻ RFID/NFC và truyền tin lên MQTT Broker

Lần thử Thời gian phản hồi (giây)

Ta có độ lệch chuẩn:

- Với thời gian phản hồi trung bình 1.23 giây cho thấy thời gian phản hồi có độ trễ, nguyên nhân từ tốc độ trường truyền internet và tốc độ đọc thẻ từ của thiết bị

- Độ lệch chuẩn bằng 0.2 giây ta có thể đánh giá hệ thống hoạt động ổn định với biến động thời gian phản hồi ở mức thấp, đảm bảo hiệu suất một cách nhất quán

Dựa trên các kết quả này, có thể kết luận rằng mặc dù hệ thống có chút trễ trong thời gian phản hồi, nhƣng với tốc độ 1.23 giây và độ lệch chuẩn 0.2 giây, hệ thống vẫn đáp ứng yêu cầu thực tế với hoạt động ổn định và lâu dài

4.2.2 Thử nghiệm 2: Khả năng nhận diện biển số trong iều kiện lý tưởng

Trong thử nghiệm thứ hai, nhóm đã kiểm tra khả năng nhận diện biển số xe trong điều kiện lý tưởng Điều kiện lý tưởng ở đây là khi biển số xe rõ ràng, không bị che khuất, không có vết bẩn, hoặc biến dạng

Hình 4.23 Kết quả nhận diện biển số trong điều kiện lý tưởng

Bảng 4.2 Kết quả nhận diện biển số trong điều kiện lý tưởng

Nhận diện ƣợc biển số

Nhận diện ƣợc các kí tự trong biển số

Nhận xét: Tất cả các lần thử đều cho thấy hệ thống nhận diện đƣợc biển số và các ký tự trong biển số với độ chính xác 100% Điều này là một kết quả rất

66 tích cực và làm tăng sự tin cậy của hệ thống trong việc nhận diện biển số trong điều kiện lý tưởng

4.2.3 Thử nghiệm 3: Khả năng nhận diện biển số lỗi

Trong thử nghiệm thứ ba, nhóm đã kiểm tra khả năng nhận diện biển số khi có lỗi Biển số lỗi ở đây có thể là những biển số bị mờ, che khuất một phần, bị biến dạng, hoặc trong điều kiện ánh sáng thiếu

Hình 4.24 Kết quả nhận diện biển số lỗi

Bảng 4.3 Kết quả nhận diện biển số lỗi

Nhận diện ƣợc biển số

Nhận diện ƣợc các kí tự trong biển số

Trong thử nghiệm này, nhóm đã tiến hành 5 lần thử:

Lần thử 1: Biển số 51T3-2000, mặc dù biển số cũ và có dấu hiệu bị lem chữ, tuy nhiên, hệ thống nhận diện đạt 100%

Lần thử 2: Biển số 51S1-5494, bị thiếu chữ số 1 Lỗi này cực kỳ khó nhận diện ngay cả với mắt thường, dẫn đến việc hệ thống không thể nhận diện đúng Lần thử 3: Biển số 30A-42512, hệ thống vẫn nhận diện đúng 100% Mặc dù có biển số cũ và bị che khuất kí tự, nhƣng hệ thống vẫn hoạt động hiệu quả Lần thử 4: Hệ thống chỉ nhận diện đƣợc 7 trên 9 ký tự của biển số Nguyên nhân chính là chất lƣợng hình ảnh không đủ tốt, cùng với việc biển số không rõ chữ, gần nhƣ mất hoàn toàn, dẫn đến giảm khả năng nhận diện của hệ thống

67 Lần thử 5: Hệ thống nhận diện đạt 7 trên 8 kí tự Tuy nhiên kí tự đầu tiên bị mất do phai màu làm hệ thống không thể nhận diện

Nhận xét: Mặc dù không đạt đƣợc độ chính xác tuyệt đối nhƣ trong điều kiện lý tưởng, nhưng hệ thống vẫn nhận diện được biển số và các ký tự trong biển số với tỉ lệ cao Điều này cho thấy tính linh hoạt và đáng tin cậy của hệ thống trong việc xử lý các tình huống có sự cố Tuy nhiên, việc không đạt đƣợc độ chính xác tuyệt đối cũng chỉ ra một hạn chế của mô hình Điều này gợi ý rằng vẫn còn những yếu tố cần cải thiện để mô hình có thể hoạt động hiệu quả hơn trong các tình huống phức tạp hoặc không lý tưởng, chẳng hạn như trong điều kiện ánh sáng kém, biển số bị mờ hoặc bị che khuất một phần

4.2.4 Thử nghiệm 4: Khả năng truyền nhận API ( POST/GET) Để thử nghiệm khả năng truyền nhận dữ liệu qua API nhóm tiến hành thao tác cho xe ra vào bãi với 10 lần thử

Bảng 4.4 kết quả truyền nhận API ( POST/GET)

Lần thử Thời gian phản hồi lối v o ( giây) Thời gian phản hồi lối ra ( giây)

Nhận xét: Qua các số liệu cho thấy thời gian thời gian phản hồi trung bình cho POST (lối vào) là 0.354 giây Thời gian phản hồi trung bình cho GET (lối ra)

68 là 0.258 giây Nhƣ vậy, yêu cầu POST mất nhiều thời gian hơn so với yêu cầu GET

Các giá trị thời gian phản hồi POST có sự dao động tương đối lớn, với lần thử thấp nhất là 0.322 giây và cao nhất là 0.387 giây Mức dao động này có thể ảnh hưởng đến trải nghiệm người dùng nếu độ trễ lớn hơn mức chấp nhận được

Các giá trị thời gian phản hồi GET tương đối ổn định, dao động từ 0.237 giây đến 0.299 giây Sự ổn định này là điểm tích cực, cho thấy hệ thống có khả năng phản hồi nhanh và nhất quán khi xử lý các yêu cầu GET

Từ bảng dữ liệu trên ta có thể kết luận API có hiệu suất tốt hơn khi xử lý các yêu cầu GET so với POST Thời gian phản hồi GET trung bình thấp hơn và ổn định hơn so với POST Mặc dù thời gian phản hồi POST có sự biến động, nhƣng sự khác biệt không quá lớn để gây ra vấn đề nghiêm trọng

4.2.5 Thử nghiệm 5: Khả năng vận h nh của hệ thống trong iều kiện tự nhiên