Les sujets de l'utilisation de Raspberry pi pour le contrôle FPV et la surveillance du mouvement dans une trame le long des vecteurs H.264 ne sont pas nouveaux. Le développement ne prétend pas être original, et relativement peu de temps y a été consacré (à partir de juillet le week-end, parfois.).
Mais peut-être que mon expérience (et la source) sera utile à n'importe qui.
L'idée que vous devez faire de la vidéosurveillance dans l'appartement est apparue après qu'un voisin a dit que quelqu'un plongeait dans la serrure de la porte.
La première chose qui a été fouettée a été l'installation du célèbre programme Motion sur le Raspberry Pi Zero avec une caméra v1.3. En principe, cela résout le problème. Si vous êtes satisfait de la notification par e-mail et fps = 4-5.
Mais cela ne semblait pas intéressant. À portée de main était une plate-forme avec des roues et un harnais d'anciennes expériences et des batteries 18650 d'anciens ordinateurs portables.
Le résultat est un mélange amusant de vidéosurveillance mobile et de détection de mouvement.
Puisque j'ai un VPS loué, il n'y a eu aucun problème d'accès depuis l'extérieur (réseau domestique derrière NAT). La durée de vie de la batterie est d'environ 4 jours si vous n'abusez pas de la suspension et du phare.
Vous pouvez vous déplacer dans l'appartement, contrôler à distance la caméra et la plate-forme et le laisser en mode détection de mouvement à n'importe quel endroit souhaité.
Matériel informatique
Tout le matériel peut être divisé en deux parties, dont la première ne dépend pas de la seconde et peut être utilisée séparément:
Module de vidéosurveillance
- Raspberry pi zero
- Clé USB WiFi
- Appareil photo Raspberry Pi v1.3
- 2x moteurs pas à pas 28BYJ-48 + driver ULN2003
Plateforme mobile gérée via SPI à partir de framboises
- 4S 16x18650 Li-ion + carte 4S 30A Li-ion 18650 (BMS) + charge DC-DC avec stabilisation de courant et de tension
- convertisseur abaisseur cc-cc (15v -> 5v).
- carte stm32f103c8t6
- 4x motoréducteurs + carte L298N
- Lampe LED 12v (phare) + contrôle sur IRF3205 (+ smd pnp et npn)
L'image Raspbian a été configurée en mode lecture seule. Dans une telle configuration, les framboises survivent facilement aux coupures de courant inattendues car elles n'utilisent pas du tout de cartes SD pour l'enregistrement.
Logiciels
Le logiciel se compose de 3 composants distincts.
Application Android (testée sur LG6 Oreo et ancien Samsung S5 Lollipop)
Mode FPV- Afficher le flux vidéo H.264 de la caméra dans la résolution et le débit binaires spécifiés
- Commandes de la caméra et de la plateforme
- Enregistrez des vidéos et des photos du flux.
Mode de service Android- Sondage de l'hôte (avec fréquence spécifiée)
- Chargement de la photo d'événement du «mouvement» dans le cadre par événement.
Hôte Raspberry Pi sur Python (Picamera + Spidev + RPi.GPIO)
Mode FPV- Diffusion de flux H.264 (avec les paramètres spécifiés par l'application Android)
- réception des commandes de contrôle des moteurs pas à pas et de leur gestion.
- Commandes de contrôle de diffusion via SPI (si le mode est activé)
Mouvement du mode de suivi dans le cadre.- Détection de mouvement dans le cadre (selon les paramètres spécifiés par l'application Android)
- Réception des demandes "et s'il y a du mouvement dans le cadre" et téléchargement de photos sur demande
- Envoi à l'hôte (quelle que soit l'application) photo de mouvements dans le cadre.
Le micrologiciel le plus simple sur stm32f103- Recevoir des commandes SPI
- Contrôlez le sens de rotation des roues et des moteurs PWM.
- Contrôle des phares.
Suivi de mouvement
Le suivi sur les vecteurs h.264 s'est révélé très morose et sujet aux faux positifs. Il existe très peu d'implémentations de détection de mouvement pour H.264 sur le réseau. Je les ai tous essayés.
L'option la plus primitive consiste à compter le nombre de vecteurs dont la longueur dépasse une certaine valeur de seuil. Et si des vecteurs sont supérieurs au seuil, alors c'est un signal qu'il y a du mouvement dans la trame.
Hélas. Cette option ne convient que pour démontrer le principe. Il y a trop de faux positifs. Surtout sur des surfaces de couleur et de texture uniformes.
Toutes les autres options donnent soit trop de faux positifs, soit ne répondent tout simplement pas au critère de performance: "doivent être traitées dans le délai de trame".
En conséquence, j'ai choisi mon option. Bien qu'il ne donne pratiquement pas de faux positifs, il nécessite un mouvement dans plusieurs images consécutives. Mais c'est mieux ainsi que les fausses alarmes plusieurs fois par jour en raison de changements d'éclairage ou en général en raison de «mouvements» incompréhensibles dans le cadre par la «décision» de la caméra. Le sujet des algorithmes de détection fiables pour mv H.264 est généralement un sujet séparé et complexe. Les algorithmes nécessitent beaucoup de temps pour le débogage pratique et j'ai des limites strictes sur l'exécution.
Exemple de vecteurs de mouvement (modes utilitaires d'instantané):
Sur les événements «mouvement dans le cadre», des notifications sont générées.
en principe, pour mes besoins, il s'est avéré être tout à fait garanti de se déclencher lorsqu'une figure humaine (> 15% de l'image) se déplace pendant au moins 2 secondes. Avec un tel grossissement de la sensibilité, je n'ai tout simplement pas vu de faux positifs du tout.
Contrôle de mouvement.
Gestion de la plate-forme "par tracteur". C'est-à-dire Contrôle PWM et sens de rotation des côtés gauche et droit. Éléments de contrôle (bandes) sous les pouces des deux mains. Cela s'est avéré être le plus naturel pour moi.
Contrôle de la caméra - deux bandes qui se touchent donnent l'ordre de faire pivoter un certain angle (plus le centre de la bande est éloigné - plus l'angle est grand). Le contrôle continu des moteurs était inconfortable (encore une fois subjectif pour moi).
Lags FPV
Les décalages vidéo étaient relativement petits (<1 sec).
Contrôler une plate-forme à roues avec une vitesse maximale de 3-4 km / h pour un décalage de 100% PWM en 0,6 sec - c'est tout à fait normal et presque pas remarqué.
Cependant, il me semble que même 0,3 seconde de retard pour, par exemple, un quadricoptère, c'est beaucoup.
Des tests ont montré que l'implémentation de la traduction en python apporte environ 50 à 70 ms de retard, en comparaison avec la sortie du même flux H.264 via rapivid. Pour moi, ces 70ms ne sont pas importants. Mais si quelqu'un veut presser le maximum, il doit en tenir compte.
Lorsque vous utilisez le "WiFi local" (le téléphone comme point d'accès), le décalage est de 350..600ms. Mais pas plus de 0,6 seconde et stable dans cette gamme. Bien que, 50-70 mètres dans les zones ouvertes - c'est juste pour jouer. Et à une plus grande distance, le WiFi du téléphone ne fonctionne pas.
Il convient de noter que cela se trouve dans un environnement très "RF bruyant" des immeubles à appartements, avec de nombreux réseaux WiFi dans la région.
J'ai été surpris par le résultat de la configuration «Routeur WiFi -> fournisseur de paires torsadées -> VPS -> MTC 4G sur le téléphone» via la redirection de port ssh des framboises vers VPS.
Un décalage typique s'est avéré même légèrement meilleur que via le WiFi local (!)
Même en déplacement dans une voiture ou à proximité d'un hypermarché à grand décalage est à seulement 300 ms.
Cependant, parfois (assez rarement et de façon imprévisible), le décalage est devenu jusqu'à plusieurs secondes. Le recontexte aide. Probablement, ce sont certaines caractéristiques de la 4G / MTS / fournisseurs de la chaîne, etc.
Après que tout a fonctionné, il y avait un désir de connecter le canal sonore dans les deux sens. Techniquement, cela est possible et même pas très difficile. Mais je n'ai pas envie de jouer avec un fer à souder.
S'il n'y avait pas le «extra» Rasberry pi, il serait plus facile d'utiliser l'ancien téléphone comme hôte pour la surveillance vidéo et la gestion de la plate-forme. Le seul avantage des framboises sur un vieux téléphone est son poids réduit. Et, peut-être, moins de consommation d'énergie (ne se compare pas).
Toutes les sources