Müşteriye ilk sorduğumuz şey kamera markası değil, kameranın ne verdiği. ONVIF uyumlu, H.264 ya da H.265 çıkan bir IP kamera varsa işin yüzde doksanı hazır demektir. Beş yıldır kurduğumuz sistemlerin tamamı bu varsayımla çalışıyor: yeni kamera satmıyoruz, mevcut kameranın görüntüsünü karar veren bir şeye çeviriyoruz.
Zincir beş halkadan oluşuyor. Her halkanın kendine ait bir darboğazı var ve projelerde sorun çıkan yer genellikle tahmin edilen yer değil.
1. Akışı almak
Kameradan RTSP ile akış çekiyoruz. Burada iki pratik karar var: ana akış mı, alt akış mı; TCP mi, UDP mi. Ana akış 1080p ve üstü, alt akış genelde 640×360 ya da 704×576. Kişi sayma ve alan ihlali gibi işler alt akışla rahat çalışıyor, plaka ve KKD tespiti ana akışı istiyor. UDP daha az gecikme verir ama paket kaybında kare bozulur; fabrika ağlarında hep TCP kullanıyoruz, gecikme farkı birkaç yüz milisaniyeyi geçmiyor ve bozuk kare problemi ortadan kalkıyor.
Sahada en çok vakit yediren konu NVR'ın kendisi. Bazı NVR'lar kameraya doğrudan erişimi kapatıyor, akışı NVR üzerinden almak zorunda kalıyorsunuz. NVR'ın RTSP sunucusu 8 kamerayı aynı anda verirken kanal başına düşürülmüş bir bit hızı uyguluyorsa görüntü kalitesi düşüyor. Bunu keşifte ölçmeden teklif vermiyoruz artık.
2. Kareyi çözmek
H.264/H.265 çözme işini CPU'ya bırakırsanız sunucu 3–4 kamerada tıkanır. Çözmeyi GPU'nun donanım kod çözücüsüne (NVDEC) veriyoruz. 25 fps'te 8–16 kamera tek GPU sunucuda işlenebiliyor; sayı kameranın çözünürlüğüne ve kaç modelin aynı anda koştuğuna bağlı. Bu aralığı tekliflerde de aynen yazıyoruz, "sınırsız kamera" diye bir şey yok.
Her kareyi işlemek gerekmiyor. Kişi sayma için saniyede 8–10 kare yeter, düşme algılama 15 kare ister, forklift yakınlaşması 20 karenin altına inmemeli. Kare atlama oranı kamera başına ayarlanır; bu ayar GPU bütçesini doğrudan belirler.
3. Tespit ve takip
Tespit tarafında CNN tabanlı tek aşamalı modeller kullanıyoruz, YOLO ailesi sahada en az sürprizi çıkaran mimari oldu. Kare başına tespit süresi 40 milisaniyenin altında; bu sayı 1080p giriş ve TensorRT ile derlenmiş model için geçerli. Model ne kadar iyi olursa olsun, takip olmadan sayım yapılamaz: aynı kişi 30 karede 30 kez sayılır. Çoklu nesne takibi (ByteTrack benzeri) her tespite bir kimlik verir, kimlik bir çizgiyi geçtiğinde sayım gerçekleşir.
Takipte iki klasik hata var. Kimlik değişimi: iki kişi çakışıp ayrıldığında kimlikler yer değiştirir. Kimlik kaybı: kişi bir sütunun arkasına girip 2 saniye sonra çıktığında yeni kimlik alır ve çift sayılır. İkisinin de çaresi model değil, kamera yerleşimi. Bu konuyu ayrı bir yazıda anlatacağım; kısaca, kamera tavanda ve tepeden bakıyorsa problemlerin çoğu kendiliğinden çözülüyor.
4. Kural motoru
Tespit edilen nesne tek başına hiçbir şey ifade etmez. "İnsan var" bilgisini olaya çeviren şey uzamsal ve zamansal kurallar. Uzamsal kural: bu poligonun içinde. Zamansal kural: 10 saniyeden uzun süredir. İkisini birleştirince "kısıtlı alanda 10 saniyeden fazla kalan kişi" olayı çıkıyor. Kuyruk uzunluğu, bekleme süresi, forklift ile yaya arasındaki mesafe, baretsiz geçen operatör; hepsi aynı motorun farklı kural setleri.
Kural motorunu modelden ayrı tutmanın nedeni basit: müşteri kuralı değiştirmek istediğinde model yeniden eğitilmesin. Alan poligonu, eşik süresi, mesafe sınırı arayüzden değişiyor, model hiç dokunulmadan çalışmaya devam ediyor.
5. Olay ve metrik çıkışı
Çıkış iki türlü. Olay: anlık, tekil, genellikle bir alarm ya da bildirim (webhook, e-posta, MQTT). Metrik: toplanmış, zaman serisi, dashboard ve BI araçları için (JSON, CSV, REST API). Perakende müşterisi metriği ister, İSG müşterisi olayı. Üretim müşterisi ikisini birden ister ve MES ile konuşmasını bekler.
Olay şemasını ilk günden sabitlemek gerekiyor. Bizim şemada her olayda kamera kimliği, zaman damgası, olay tipi, güven skoru, ilgili kare (isteğe bağlı, KVKK ayarına göre) ve kural kimliği var. Bu şema değişmediği sürece müşteri tarafındaki entegrasyon da bozulmuyor.
Nerede sorun çıkıyor
- Ağ, model değil. Projelerin yarısında ilk hafta ağ anahtarı, VLAN ve NVR ayarlarıyla geçiyor. Kamera ağı ile sunucunun aynı segmentte olmaması başlı başına iş.
- Gece görüntüsü. IR moduna geçen kamera siyah-beyaz verir, gündüz verisiyle eğitilmiş model gece düşer. Gece verisi eğitim setine eklenmeden kabul testi yapılmaz.
- Saat. Kamera, NVR ve sunucu farklı saatlerdeyse olayları POS ya da MES kaydıyla eşleştiremezsiniz. NTP zorunlu.
- Bant genişliği. 16 kamera × 4 Mbps = 64 Mbps sürekli trafik. Mağazanın 20 Mbps hattı üzerinden buluta göndermeye çalışan projeler ilk ay ölüyor. Bu yüzden işlemeyi sahada yapıyoruz; buluta yalnızca olay ve metrik çıkıyor.
Bu zincirin tamamı bir GPU sunucuda, mağazanın ya da fabrikanın içinde çalışıyor. Görüntü dışarı çıkmıyor. Çıkan şey "saat 14:32'de 3 numaralı kasada kuyruk 6 kişiyi geçti" gibi bir satır. Kameranın kaydetmeyi bırakıp karar vermeye başlaması dediğimiz şey tam olarak bu.