Traffic Monitor Kota Bogor

Bogor Single Window sudah menayangkan CCTV lalu lintas ke publik. Saat membuka kamera CCTV-nya, saya bisa melihat antrean macet, tetapi saya tetap harus membandingkan kondisi antar titik sendiri. Dan disitulah saya memiliki inisiatif untuk mengubah alur itu menjadi lebih mudah dan terukur. Simak penjelasannya..

Peta Traffic Monitor dengan urutan kamera dan status stream.

Masalah yang saya temui

Satu tayangan CCTV cukup untuk melihat keadaan di depan kamera. Koridor SSA membutuhkan konteks lain. Arus bergerak mengelilingi Kebun Raya Bogor, dan antrean dari titik hilir dapat merambat ke titik sebelumnya. Kondisi padat di satu kamera belum menunjukkan letak hambatan.

Saya perlu membuat sistem yang bisa menghitung kendaraan, membandingkan dua titik sesuai arah arus, lalu menjelaskan hasilnya. Pengguna juga perlu melihat dasar diagnosis, karena label “padat” tanpa jumlah kendaraan dan kondisi titik hilir tidak banyak membantu.

Batasan

Saya memakai stream HLS publik. Kualitas gambar, sudut kamera, dan ketersediaan stream berbeda di tiap titik. Karena itu, saya tidak membandingkan jumlah kendaraan mentah antar kamera.

Vertex AI menghitung biaya selama endpoint deteksi aktif. Saya memilih analisis on-demand agar inferensi berjalan saat pengguna meminta hasil. Pilihan ini cocok untuk layanan informasi dengan waktu tunggu beberapa detik. Prototipe ini tidak mengatur lampu lalu lintas atau menghitung rute perjalanan.

Menyiapkan dataset

Saya mengambil frame dari tujuh CCTV pada kondisi siang, malam, lengang, dan padat. Di Roboflow, saya menggambar bounding box untuk motor, mobil, dan kendaraan besar.

Dataset berisi 112 gambar dengan 2.010 anotasi. Saya memakai 78 gambar untuk pelatihan, 22 untuk validasi, dan 12 untuk pengujian. Distribusi kelasnya timpang: 1.189 anotasi mobil, 749 motor, dan 72 kendaraan besar. Saya memakai distribusi ini saat menilai kelas dengan contoh sedikit atau ukuran objek kecil.

Frame siang berisi kendaraan kecil dan beberapa objek yang saling menutup.

Pada malam hari, model harus menghadapi kontras rendah dan pantulan lampu.

Menghitung kondisi per kamera

Vertex AI AutoML Vision mengembalikan kelas, posisi, dan skor kepercayaan untuk setiap kendaraan. Backend menyaring hasil dengan ambang kepercayaan 0,5, lalu menjumlahkan kendaraan per kelas.

Saya menyimpan dua ambang untuk tiap kamera. Ambang pertama memisahkan kondisi lancar dan padat. Ambang kedua menandai kondisi sangat padat. Dengan konfigurasi per kamera, saya mengurangi pengaruh perbedaan perspektif dan luas jalan yang terlihat.

Backend juga menghitung indeks:

indeks kepadatan = jumlah kendaraan / ambang bawah kamera

Saya memakai indeks ini untuk membandingkan kondisi kamera terhadap ambangnya sendiri. Nilainya tidak mewakili satuan kendaraan per kilometer.

Vertex AI mengembalikan bounding box, kelas, dan skor setiap kendaraan.

Membaca hubungan hulu dan hilir

Saya menyimpan tujuh kamera mengikuti arah arus:

Tugu Kujang → Simpang BTM → Depan Kantor Pos → Jl. Juanda Arah Kapten Muslihat → Depan Balaikota → Simpang Denpom → Jalan Pajajaran → Tugu Kujang

Saat pengguna memilih kamera, FastAPI mengambil frame dari titik tersebut dan titik setelahnya. Backend memproses keduanya bersamaan, kemudian membandingkan status kepadatan.

Saya menetapkan tiga hasil diagnosis:

• Backend memberi label bottleneck lokal saat titik hilir lebih padat daripada titik hulu.
• Backend memberi label saturasi volume saat kedua titik padat tanpa satu hambatan yang menonjol.
• Backend memberi label normal untuk pola lain.

Frontend menampilkan status kedua titik, pasangan kritis, dan proporsi titik padat. Pengguna dapat melihat alasan di balik label yang muncul.

Memakai Gemini untuk menulis hasil rekomendasi

FastAPI menetapkan diagnosis sebelum memanggil Gemini. Gemini menerima jumlah kendaraan, status kedua titik, diagnosis, dan nama segmen. Model tersebut menulis ringkasan kondisi, saran tindakan, serta catatan perjalanan.

Saya membatasi respons dengan skema. Frontend mendapat field yang sama pada setiap permintaan, sedangkan PostgreSQL menyimpan respons lengkap dalam kolom JSONB. Dengan susunan ini, aturan hulu-hilir tetap menjadi sumber diagnosis dan Gemini menangani penyajian teks.

Arsitektur sistem

Komponen yang menangani peta, API, stream CCTV, inferensi, teks, cache, dan penyimpanan.

Pengguna membuka peta yang saya bangun dengan Next.js, Leaflet, dan OpenStreetMap. Saat pengguna meminta analisis, FastAPI mengambil dua frame melalui ffmpeg dan mengirimkannya ke Vertex AI. Backend menghitung status, membandingkan pasangan kamera, lalu mengirim hasil diagnosis ke Gemini.

PostgreSQL menyimpan data kamera dan riwayat analisis. Redis mencatat status stream serta menampung cache untuk permintaan berulang. Karena saya memisahkan tanggung jawabnya, saya dapat memeriksa kegagalan pada tiap tahap tanpa menyatukan seluruh proses dalam satu layanan.

Kesimpulan

Saya berhasil menjalankan alur dari pengambilan dua frame CCTV sampai penyajian diagnosis dalam satu permintaan. Sistem memberi diagnosis yang tepat pada 16 dari 18 skenario uji. Dari 30 permintaan, waktu proses rata-ratanya 5,29 detik. Sepuluh skenario uji fungsional juga lulus.

Saya memakai hasil tersebut sebagai bukti awal untuk aturan hulu-hilir dan arsitektur on-demand. Ruang pengujiannya masih terbatas pada 112 gambar dan pasangan kamera yang bersebelahan. Saya juga belum menerapkan ROI, sedangkan ambang kepadatan masih berasal dari konfigurasi per kamera.

Saya menempatkan Traffic Monitor sebagai prototipe yang sudah terukur. Pada tahap lanjutan, saya perlu menambah data historis dan menerapkan ROI. Saya juga perlu menguji diagnosis pada lintasan yang lebih panjang sebelum sistem melayani lebih banyak kamera atau permintaan.