Die Themen der Verwendung von Raspberry pi zur FPV-Steuerung und Überwachung der Bewegung in einem Frame entlang von H.264-Vektoren sind nicht neu. Die Entwicklung gibt nicht vor, originell zu sein, und es wurde relativ wenig Zeit dafür aufgewendet (ab Juli manchmal an Wochenenden).
Aber vielleicht ist meine Erfahrung (und die Quelle) für jeden nützlich.
Die Idee, dass Sie eine Videoüberwachung in der Wohnung durchführen müssen, entstand, nachdem ein Nachbar sagte, dass jemand in das Türschloss eintauchte.
Das erste, was ausgepeitscht wurde, war die Installation des berühmten Bewegungsprogramms auf dem Raspberry Pi Zero mit einer Kamera v1.3. Im Prinzip löst es das Problem. Wenn Sie mit der Benachrichtigung per Mail und fps = 4-5 zufrieden sind.
Das schien aber nicht interessant zu sein. Zur Hand war eine Plattform mit Rädern und Gurtzeug aus alten Experimenten und 18650 Batterien aus alten Laptops.
Das Ergebnis ist eine unterhaltsame Mischung aus mobiler Videoüberwachung und Bewegungserkennung.
Da ich einen gemieteten VPS habe, gab es keine Probleme beim Zugriff von außen (Heimnetzwerk hinter NAT). Die Akkulaufzeit beträgt ca. 4 Tage, wenn Sie die Fahrt und den Scheinwerfer nicht missbrauchen.
Sie können durch die Wohnung fahren, die Kamera und die Plattform fernsteuern und sie an jedem gewünschten Ort im Bewegungserkennungsmodus belassen.
Hardware
Die gesamte Hardware kann in zwei Teile unterteilt werden, von denen der erste nicht vom zweiten abhängt und separat verwendet werden kann:
Videoüberwachungsmodul
- Himbeer pi Null
- USB WiFi Dongle
- Himbeer-Pi-Kamera v1.3
- 2x Schrittmotoren 28BYJ-48 + ULN2003 Treiber
Mobile Plattform über SPI aus Himbeeren verwaltet
- 4S 16x18650 Li-Ion + 4S 30A Li-Ion 18650 (BMS) Karte + DC-DC-Aufladung mit Strom- und Spannungsstabilisierung
- DC / DC-Abwärtswandler (15 V -> 5 V).
- stm32f103c8t6 Karte
- 4x Getriebemotoren + L298N Platine
- 12V LED Lampe (Scheinwerfer) + Steuerung am IRF3205 (+ smd pnp und npn)
Das Raspbian-Image wurde im schreibgeschützten Modus konfiguriert. In einer solchen Konfiguration überleben Himbeeren leicht unerwartete Abschaltungen, da sie überhaupt keine SD-Karten für die Aufnahme verwenden.
Software
Die Software besteht aus 3 separaten Komponenten.
Android App (getestet auf LG6 Oreo und altem Samsung S5 Lollipop)
FPV-Modus- Zeigen Sie den H.264-Videostream von der Kamera in der angegebenen Auflösung und Bitrate an
- Kamera- und Plattformsteuerung
- Nehmen Sie Videos und Fotos aus dem Stream auf.
Android-Servicemodus- Host-Umfrage (mit angegebener Häufigkeit)
- Laden eines Ereignisfotos von „Bewegung“ in den Rahmen nach Ereignis.
Himbeer-Pi-Host auf Python (Picamera + Spidev + RPi.GPIO)
FPV-Modus- Broadcast H.264-Stream (mit den von der Android-Anwendung angegebenen Parametern)
- Empfang von Steuerbefehlen für Schrittmotoren und deren Verwaltung.
- Broadcast-Steuerbefehle über SPI (wenn der Modus aktiviert ist)
Tracking-Modus Bewegung im Frame.- Bewegungserkennung im Frame (gemäß den von der Android-Anwendung angegebenen Parametern)
- Empfang von Anfragen "und ob sich im Rahmen etwas bewegt" und Hochladen von Fotos auf Anfrage
- Senden von Fotos im Rahmen (unabhängig von der Anwendung) an den Host.
Die einfachste Firmware auf stm32f103- SPI-Befehle empfangen
- Steuern Sie die Drehrichtung der Räder und PWM-Motoren.
- Scheinwerfersteuerung.
Bewegungsverfolgung
Das Verfolgen der h.264-Vektoren erwies sich als sehr launisch und anfällig für falsch positive Ergebnisse. Es gibt nur sehr wenige Bewegungserkennungsimplementierungen für H.264 im Netzwerk. Ich habe sie alle ausprobiert.
Die primitivste Option besteht darin, die Anzahl der Vektoren zu zählen, deren Länge einen bestimmten Schwellenwert überschreitet. Und wenn Vektoren größer als der Schwellenwert sind, ist dies ein Signal dafür, dass sich im Rahmen eine Bewegung befindet.
Leider. Diese Option ist nur zur Demonstration des Prinzips geeignet. Es gibt zu viele Fehlalarme. Besonders auf Oberflächen mit einheitlicher Farbe und Textur.
Alle anderen Optionen ergeben entweder zu viele Fehlalarme oder erfüllen einfach nicht das Leistungskriterium: „sollten innerhalb der Frame-Zeit verarbeitet werden“.
Infolgedessen habe ich meine Option gewählt. Obwohl es praktisch keine Fehlalarme gibt, erfordert es eine Bewegung in mehreren Frames hintereinander. Dies ist jedoch besser als mehrmals täglich Fehlalarme aufgrund von Beleuchtungsänderungen oder allgemein aufgrund unverständlicher „Bewegungen“ im Rahmen durch die „Entscheidung“ der Kamera. Das Thema zuverlässige Erkennungsalgorithmen für MV H.264 ist im Allgemeinen ein separates und komplexes Thema. Algorithmen benötigen viel Zeit für das praktische Debuggen und ich habe strenge Laufzeitbeschränkungen.
Beispiel für Bewegungsvektoren (Snapshot-Dienstprogrammmodi):
Bei den Ereignissen „Bewegung im Rahmen“ werden Benachrichtigungen generiert.
Für meine Zwecke stellte sich heraus, dass es im Prinzip garantiert ist, dass es ausgelöst wird, wenn sich eine menschliche Figur (> 15% des Rahmens) mindestens 2 Sekunden lang bewegt. Bei einer solchen Vergröberung der Empfindlichkeit habe ich einfach überhaupt keine falsch positiven Ergebnisse gesehen.
Bewegungssteuerung.
Plattformmanagement "per Traktor". Das heißt, PWM-Steuerung und Drehrichtung der linken und rechten Seite. Bedienelemente (Streifen) unter den Daumen beider Hände. Es stellte sich als das Natürlichste für mich heraus.
Kamerasteuerung - zwei Streifen, die sich berühren, geben den Befehl, einen bestimmten Winkel zu drehen (je weiter von der Mitte des Streifens entfernt - desto größer der Winkel). Die kontinuierliche Steuerung der Motoren war unangenehm (wieder subjektiv für mich).
Verzögerungen FPV
Videoverzögerungen waren relativ klein (<1 Sek.).
Die Steuerung einer Plattform mit Rädern mit einer Höchstgeschwindigkeit von 3-4 km / h für eine 100% ige PWM-Verzögerung in 0,6 Sekunden ist ganz normal und wird fast nicht bemerkt.
Es scheint mir jedoch, dass sogar 0,3 Sekunden Verzögerung zum Beispiel für einen Quadrocopter viel sind.
Tests haben gezeigt, dass die Implementierung der Übersetzung in Python die Verzögerung um 50-70 ms verzögert, verglichen mit der Ausgabe desselben H.264-Streams über Rapivid. Für mich sind diese 70ms nicht wichtig. Aber wenn jemand das Maximum herausholen will, muss er dies berücksichtigen.
Bei der Arbeit über "lokales WLAN" (das Telefon als Zugangspunkt) beträgt die Verzögerung 350..600 ms. Aber nicht mehr als 0,6 Sekunden und stabil in diesem Bereich. Obwohl 50-70 Meter in offenen Bereichen - dies ist nur zum Herumspielen. In größerer Entfernung funktioniert WLAN vom Telefon nicht.
Es ist erwähnenswert, dass dies in einer sehr "RF-lauten" Umgebung von Wohngebäuden mit vielen WiFi-Netzwerken in der Umgebung ist.
Ich war überrascht über das Ergebnis in der Konfiguration „WLAN-Router -> Twisted Pair-Anbieter -> VPS -> MTC 4G am Telefon“ über die Weiterleitung des SSH-Ports von Himbeeren an VPS.
Eine typische Verzögerung erwies sich sogar als etwas besser als über lokales WLAN (!)
Selbst unterwegs im Auto oder in der Nähe eines großen Lag-Hypermarktes sind es nur 300ms.
Manchmal (ziemlich selten und unvorhersehbar) betrug die Verzögerung jedoch bis zu mehreren Sekunden. Rekontext hilft. Wahrscheinlich sind dies einige Merkmale von 4G / MTS / Anbietern in der Kette usw.
Nachdem alles funktioniert hatte, bestand der Wunsch, den Tonkanal in beide Richtungen anzuschließen. Technisch ist dies möglich und nicht einmal sehr schwierig. Aber ich habe keine Lust, mit einem Lötkolben herumzuspielen.
Ohne das "zusätzliche" Rasberry Pi wäre es einfacher, das alte Telefon als Host für die Videoüberwachung und das Plattformmanagement zu verwenden. Der einzige Vorteil von Himbeeren gegenüber einem alten Telefon ist das geringere Gewicht. Und vielleicht weniger Stromverbrauch (nicht vergleichbar).
Alle Quellen