Topik menggunakan Raspberry pi untuk kontrol FPV dan gerakan pemantauan dalam bingkai sepanjang vektor H.264 bukanlah hal baru. Pengembangannya tidak berpura-pura asli, dan relatif sedikit waktu yang dihabiskan untuk itu (dari Juli pada akhir pekan, kadang-kadang.).

Tapi mungkin pengalaman saya (dan sumbernya) akan bermanfaat bagi siapa saja.

Gagasan bahwa Anda perlu melakukan pengawasan video di apartemen muncul setelah seorang tetangga mengatakan bahwa seseorang sedang menyelidiki kunci pintu.

Hal pertama yang dilakukan adalah pemasangan program gerak terkenal pada Raspberry pi nol dengan kamera v1.3. Pada prinsipnya, itu memecahkan masalah. Jika Anda puas dengan pemberitahuan melalui surat dan fps = 4-5.

Tapi ini sepertinya tidak menarik. Di tangan adalah platform dengan roda dan memanfaatkan dari percobaan lama dan baterai 18650 dari laptop lama.

Hasilnya adalah campuran yang menyenangkan dari pengawasan video seluler dan deteksi gerakan.
Karena saya memiliki VPS sewaan, tidak ada masalah mengakses dari luar (jaringan rumah di belakang NAT). Daya tahan baterai sekitar 4 hari jika Anda tidak menyalahgunakan perjalanan dan lampu.

Anda dapat berkeliling apartemen, mengontrol kamera dan platform dari jarak jauh dan membiarkannya dalam mode deteksi gerak di lokasi yang diinginkan.

Perangkat keras

Semua perangkat keras dapat dibagi menjadi dua bagian, yang pertama tidak tergantung pada yang kedua dan dapat digunakan secara terpisah:

Modul pengawasan video

• Raspberry pi nol
• USB WiFi Dongle
• Kamera raspberry pi v1.3
• 2x motor stepper driver 28BYJ-48 + ULN2003

Platform seluler dikelola melalui SPI dari raspberry

• Papan 4S Li-ion 16x18650 + 4S Li-ion 18650 (BMS) + pengisian DC-DC dengan stabilisasi arus dan tegangan
• dc-dc step down converter (15v -> 5v).
• papan stm32f103c8t6
• Motor roda gigi 4x + papan L298N
• Lampu LED 12v (lampu depan) + kontrol pada IRF3205 (+ smd pnp dan npn)

Gambar Raspbian telah dikonfigurasi dalam mode hanya baca. Dalam konfigurasi seperti itu, raspberry dengan mudah selamat dari pematian daya yang tidak terduga karena mereka tidak menggunakan kartu SD untuk merekam sama sekali.

Perangkat lunak

Perangkat lunak ini terdiri dari 3 komponen terpisah.

Aplikasi Android (diuji pada LG6 Oreo dan Samsung S5 Lollipop lama)

Mode FPV

• Tampilkan streaming video H.264 dari kamera dalam resolusi dan bitrate yang ditentukan
• Kontrol kamera dan platform
• Rekam video dan foto dari aliran.

Mode layanan Android

• Host polling (dengan frekuensi yang ditentukan)
• Memuat foto acara "gerakan" dalam bingkai demi acara.

Tuan rumah Raspberry pi pada python (picamera + spidev + RPi.GPIO)

Mode FPV

• Siaran streaming H.264 (dengan parameter yang ditentukan oleh aplikasi Android)
• penerimaan perintah kontrol untuk motor stepper dan manajemennya.
• Perintah kontrol siaran melalui SPI (jika mode diaktifkan)

Gerakan mode pelacakan di bingkai.

• Deteksi gerak dalam bingkai (sesuai dengan parameter yang ditentukan oleh aplikasi Android)
• Penerimaan permintaan "dan apakah ada pergerakan dalam bingkai" dan mengunggah foto berdasarkan permintaan
• Mengirim ke host (terlepas dari aplikasi) foto gerakan dalam bingkai.

Firmware paling sederhana di stm32f103

• Terima perintah SPI
• Kontrol arah putaran roda dan motor PWM.
• Kontrol lampu.

Pelacakan gerak

Pelacakan pada vektor h.264 ternyata sangat murung dan cenderung positif palsu. Ada beberapa implementasi deteksi gerak untuk H.264 di jaringan. Saya mencoba semuanya.

Opsi yang paling primitif adalah menghitung jumlah vektor yang panjangnya melebihi nilai ambang tertentu. Dan jika ada vektor yang lebih besar dari ambang, maka ini adalah sinyal bahwa ada pergerakan dalam bingkai.

Sayang Opsi ini hanya cocok untuk menunjukkan prinsip. Terlalu banyak kesalahan positif. Terutama pada permukaan warna dan tekstur yang seragam.

Semua opsi lain memberikan terlalu banyak false positive, atau tidak memenuhi kriteria kinerja: “harus diproses dalam jangka waktu yang ditentukan”.

Akibatnya, saya memilih opsi saya. Meskipun secara praktis tidak memberikan positif palsu, itu membutuhkan gerakan di beberapa frame berturut-turut. Tetapi itu lebih baik daripada alarm palsu beberapa kali sehari karena perubahan penerangan atau secara umum karena "gerakan" yang tidak dapat dipahami dalam bingkai oleh "keputusan" kamera. Topik algoritma pendeteksian andal untuk mv H.264 umumnya merupakan topik yang terpisah dan kompleks. Algoritma memerlukan banyak waktu untuk debugging praktis dan saya memiliki batasan ketat pada runtime.

Contoh vektor gerakan (mode utilitas foto):





Pada acara "pergerakan dalam bingkai", pemberitahuan dihasilkan.



pada prinsipnya, untuk tujuan saya ternyata cukup dijamin untuk memicu ketika sosok manusia (> 15% dari frame) bergerak setidaknya 2 detik. Dengan sensitivitas yang kasar seperti itu, saya sama sekali tidak melihat positif yang salah sama sekali.

Kontrol gerak.

Manajemen platform "oleh traktor." Yaitu Kontrol PWM dan arah rotasi sisi kiri dan kanan. Elemen kontrol (strip) di bawah ibu jari kedua tangan. Ternyata itu yang paling alami bagi saya.



Kontrol kamera - dua strip yang disentuh memberikan perintah untuk memutar sudut tertentu (semakin jauh dari pusat strip - semakin besar sudutnya). Kontrol terus menerus untuk motor tidak nyaman (lagi subjektif bagi saya).

Tertunda FPV

Kelambatan video relatif kecil (<1 detik).

Untuk mengontrol platform beroda dengan kecepatan maksimum 3-4 km / jam untuk 100% PWM lag dalam 0,6 detik - ini cukup normal dan hampir tidak diperhatikan.

Namun, bagi saya kelambatan 0,3 detik untuk, misalnya, quadrocopter banyak.

Pengujian telah menunjukkan bahwa implementasi terjemahan dalam python membawa sekitar 50-70ms ke lag, dibandingkan dengan output dari aliran H.264 yang sama melalui rapivid. Bagi saya, 70ms ini tidak penting. Tetapi jika ada yang ingin memeras maksimal, maka ia harus memperhitungkannya.

Saat bekerja melalui "WiFi lokal" (telepon sebagai titik akses), jeda adalah 350..600ms. Tapi tidak lebih dari 0,6 detik dan stabil di kisaran ini. Meskipun, 50-70 meter di area terbuka - ini hanya untuk bermain-main. Dan pada jarak yang lebih jauh, WiFi dari ponsel tidak berfungsi.
Perlu dicatat bahwa ini berada di lingkungan yang sangat "bising RF" dari gedung apartemen, dengan banyak jaringan WiFi di daerah tersebut.



Saya terkejut dengan hasil dalam konfigurasi "router WiFi -> penyedia twisted pair -> VPS -> MTC 4G di ponsel" melalui ssh port forwarding dari raspberry ke VPS.
Kelambatan tipikal ternyata bahkan sedikit lebih baik daripada melalui WiFi lokal (!)
Bahkan saat bepergian dalam mobil atau dekat hypermarket lag besar hanya 300 ms.

Namun, kadang-kadang (sangat jarang dan tidak terduga), lag menjadi beberapa detik. Rekonteks membantu. Mungkin, ini adalah beberapa fitur 4G / MTS / penyedia dalam rantai, dll.



Setelah semuanya bekerja, ada keinginan untuk menghubungkan saluran suara di kedua arah. Secara teknis, ini mungkin dan bahkan tidak terlalu sulit. Tapi saya tidak ingin mengutak-atik besi solder.

Jika itu bukan untuk Rasberry pi "ekstra", akan lebih mudah menggunakan telepon lama sebagai tuan rumah untuk pengawasan video dan manajemen platform. Satu-satunya keuntungan raspberry di ponsel lama adalah lebih sedikit. Dan, mungkin, konsumsi daya yang lebih sedikit (tidak membandingkan).

Semua sumber