Table des matières:

Caméra Raspberry PI et contrôle de la lumière Death Star : 5 étapes (avec photos)
Caméra Raspberry PI et contrôle de la lumière Death Star : 5 étapes (avec photos)

Vidéo: Caméra Raspberry PI et contrôle de la lumière Death Star : 5 étapes (avec photos)

Vidéo: Caméra Raspberry PI et contrôle de la lumière Death Star : 5 étapes (avec photos)
Vidéo: Красивая история о настоящей любви! Мелодрама НЕЛЮБОВЬ (Домашний). 2024, Juillet
Anonim
Caméra Raspberry PI et contrôle de la lumière Death Star
Caméra Raspberry PI et contrôle de la lumière Death Star
Caméra Raspberry PI et contrôle de la lumière Death Star
Caméra Raspberry PI et contrôle de la lumière Death Star
Caméra Raspberry PI et contrôle de la lumière Death Star
Caméra Raspberry PI et contrôle de la lumière Death Star

Comme toujours, je cherche à construire des appareils qui sont utiles, qui fonctionnent de manière robuste et qui sont souvent même des améliorations par rapport aux solutions standard actuelles.

Voici encore un autre grand projet, nommé à l'origine Shadow 0f Phoenix, un bouclier Raspberry PI associé à la détection de mouvement et aux commandes de lumière basées sur Arduino.

Étape 1: L'état des caméras IP commerciales

L'état des caméras IP commerciales
L'état des caméras IP commerciales
L'état des caméras IP commerciales
L'état des caméras IP commerciales
L'état des caméras IP commerciales
L'état des caméras IP commerciales

En plus du fait que construire votre propre système de caméra/surveillance est plus cool, voyons pourquoi est-ce une amélioration par rapport à une solution standard.

Je vais le comparer avec la série de caméras IP sans fil NEO COOLCAM Full HD 1080P car j'ai possédé un grand nombre de ces différents modèles de caméras neo coolcams (ONVIF). Ils se présentent sous différentes formes et tailles, à l'extérieur et à l'intérieur, la plupart d'entre eux ont un support wifi intégré, mais voyons leurs mises en garde:

  • Les fabricants chinois qui vendent ces appareils photo mentent presque toujours sur la résolution du capteur d'image intégré, lorsque vous achetez un appareil photo 5MP/8MP sur Ebay, vous pourriez vous retrouver avec un appareil photo 2MP bon marché avec une mauvaise image (cela fonctionne mais la qualité est mauvaise). Lorsque vous achetez la caméra Raspberry PI v2 8MP auprès du revendeur d'origine, vous obtenez ce pour quoi vous avez payé et un capteur 8MP réel avec une résolution de 3280 × 2464 pixels =>
  • Du point de vue de la sécurité, ces caméras (même les plus chères Dlink et d'autres modèles) sont terribles, elles utilisent des mots de passe par défaut tels que 123456 ou des utilisateurs intégrés tels que administrateur/administrateur/opérateur que vous ne pourrez peut-être même pas changer ou le le changement a disparu après un redémarrage. Complétez le tout avec bon nombre de ces appareils photo pour téléphone à la maison (connectez-vous à leurs serveurs en Chine, certains diffusent même des vidéos/images sans vous le demander simplement pour vous faciliter la tâche au cas où vous décideriez d'installer leur application Android/Iphone un jour pour vérifier votre domicile). Même si vous placez ces appareils derrière un routeur, ce n'est tout simplement pas assez bon, le mieux est de ne pas y définir de passerelle par défaut, de les pare-feu ou de les mettre dans un VLAN pour les empêcher de sortir. Internet ou encore mieux: ne les utilisez pas du tout.
  • Sont-ils plus fiables ? non, beaucoup d'entre eux, même les DLINK les plus chers, ont la possibilité de redémarrer la caméra quotidiennement/hebdomadairement, etc. Cette option est là pour une raison, car après X jours, ils perdent souvent la connectivité Wifi ou se comportent mal d'une autre manière. Considérez-les simplement comme de bonnes vieilles boîtes Win95 qui devaient être redémarrées le plus souvent:) Je ne dis pas que le matériel basé sur Raspi est si solide que vous pouvez les intégrer dans des centrales nucléaires de contrôle mais avec le matériel/logiciel approprié configuration, dissipateurs thermiques, ventilateurs de refroidissement automatiques et fonctionnement RW minimisé sur la SDCARD, ils peuvent facilement atteindre plus de 100 jours de disponibilité sans problème. Au moment de la rédaction de cet article, mon DeathStar fonctionne depuis 34 jours, depuis plus de 100, mais parfois je piraté la source d'alimentation qui alimente d'autres de mes circuits, j'ai donc dû l'arrêter:(
  • Matériel ciblé: ils sont conçus pour 1 objectif spécifique, sont souvent livrés avec une petite zone nvram et une boîte de chargement, mais certains modèles rendent également l'accès à ce shell impossible, vous ne pouvez donc les utiliser que pour ce qu'ils sont censés être utilisés pendant que vous le pouvez. utilisez votre caméra basée sur Raspi pour toutes autres tâches: serveur de fichiers, serveur tftp/dhcp, serveur web, serveur quake… les options sont illimitées.
  • Espace de stockage: soit ils n'en ont pas, soit ils utilisent des cartes microsd avec le système de fichiers FAT32 VS sur le Raspberry Pis, vous pouvez même attacher un disque dur de 2 To si vous le souhaitez.
  • Contrôle des lumières: certains ont une sortie ALARME où vous pourrez peut-être connecter un petit relais pour déclencher les lumières. Comme je vais vous le montrer dans ce tutoriel, l'utilisation de caméras infrarouges est une perte de temps totale car vous ne pourrez identifier personne sur les images infrarouges en raison de la mauvaise qualité. Si vous devez enregistrer une vidéo dans l'obscurité, la meilleure façon de le faire est d'allumer d'abord la lumière, puis d'enregistrer la vidéo.

Vous pourriez donc vous demander s'il y a des avantages à utiliser un appareil photo standard ? Oui pour les entreprises où les heures de travail pour l'installer seraient plus chères que de bricoler avec Raspberry pis (pas pour moi en tout cas:)) et oui il y a des caméras haut de gamme (500$+ avec une meilleure résolution que la caméra pi de cours). Comme autre avantage, je pourrais dire que les caméras suivant la norme ONVIF ont facilité le provisionnement centralisé. Cela fournit une interface standard qui peut être utilisée pour envoyer des commandes à la caméra pour définir son IP/masque de réseau/passerelle et d'autres choses. Pour cela, vous pouvez télécharger le gestionnaire de périphériques Onvif depuis Sourceforge. Beaucoup de ces appareils sont livrés avec des frontends Web cassés et merdiques où, par exemple, ils ne vous permettent pas de définir correctement l'adresse IP ou le masque de réseau, car le javascript qui valide ces champs fonctionne mal et votre seul moyen de définir ces paramètres correctement est via ONVIF.

Étape 2: Les plans de l'étoile de la mort

Les plans de l'étoile de la mort
Les plans de l'étoile de la mort
Les plans de l'étoile de la mort
Les plans de l'étoile de la mort
Les plans de l'étoile de la mort
Les plans de l'étoile de la mort

Vous pouvez construire cet appareil avec n'importe lequel des Raspberry PI à partir de 1 à 3B+. Même le zéro a des ports de caméra, mais comme il y a tellement de raspis d'occasion différents sur le marché, vous vous demandez peut-être lequel est le plus idéal pour cette construction.

La réponse dépend de l'endroit où vous souhaitez traiter le flux vidéo.

Il y a deux choix:

1, traitez les vidéos localement avec le mouvement et transférez un flux vidéo lorsqu'un mouvement est détecté (remarque: le mouvement transmet un flux constant lent au serveur quoi qu'il arrive, cela peut dépendre de la résolution et des fréquences d'images que vous utilisez allant de quelques cent mégaoctets à plusieurs gigaoctets par jour, juste un rappel si vous souhaitez effectuer une configuration sur une connexion mesurée). Ici, le processeur est important et, malheureusement, le mouvement (au moment de la rédaction) ne profite pas de plusieurs cœurs, mais le système d'exploitation essaiera d'équilibrer légèrement la charge. Vous aurez toujours l'un des cœurs à 100% d'utilisation.

2, Traitez les vidéos sur un serveur central: ici, vous transférez simplement le flux vidéo brut de la caméra vers un serveur de streaming externe (comme iSpy exécuté sur un ordinateur x86 ou MotionEyeOS exécuté sur un autre mini-ordinateur dédié). Puisqu'il n'y a pas de traitement local, le modèle de PI que vous utilisez n'a pas d'importance, un PI1 enverra le même flux qu'un PI3B+.

Dans ce tutoriel, je vais aller avec le premier choix.

La règle de base ici est que plus le processeur est rapide, meilleurs sont les résultats. Par exemple, ma caméra basée sur Raspi 2 regardant un couloir ne le captait parfois pas lorsque quelqu'un passait rapidement et lors de l'enregistrement, l'enregistrement était lent, perdant beaucoup d'images par rapport au modèle 3. Le modèle 3 a également le 802.11 abgn wifi qui est pratique pour pouvoir diffuser des vidéos de meilleure qualité, il fonctionne immédiatement et il est assez fiable. Au moment d'écrire que le modèle 3B+ est sorti, je vous recommanderais simplement de l'obtenir avec un processeur Quad Core de 1,4 Ghz.

Liste des matériaux

  • Étoile de la mort en plastique 30 cm:)
  • Framboise Pi 3 B+
  • PiCam v2 (8MP)
  • Arduino Pro Micro 5.5v
  • 2x SIP-1A05 Reed Switch Relais
  • 1x PCS HC-SR501 IR Pyroélectrique Infrarouge IR PIR Module Détecteur de Mouvement
  • 1x résistance 10kohm pour LDR
  • 1x LDR
  • Adaptateur CC 1x12V 4A
  • 1xWarm White LED 5050 SMD Bande de lampe flexible 12V DC
  • 1xBuck régulateur de tension

Comme vous pouvez le voir sur les schémas, ce projet a été conçu à l'origine pour contrôler une seule lumière avec un seul relais car je n'avais pas prévu d'ajouter un éclairage interne (ce qui est plutôt cool) alors j'ai juste câblé un deuxième relais à l'Arduino. L'avantage du SIP-1A05 est qu'il possède une diode flyback interne et que la consommation en mA est bien inférieure à la limitation de puissance par broche de l'Arduino.

La raison pour laquelle le PIR est sur le bouclier sur les photos car au début S0P était prévu pour être mis dans une simple boîte en plastique IP au lieu d'un DeathStar. Comme vous pouvez le deviner, la caméra est directement dans le pistolet laser, le PIR et le LDR avaient besoin d'autres trous percés et ils sont collés car je ne prévois pas de les retirer.

Un trou a été percé au bas de la DeathStar où j'ai collé un gros boulon avec une colle forte à 2 composants. Cela peut être vissé dans le support Neo Coolcams d'origine (c'était bon pour quelque chose après tout:)). Pour un support supplémentaire j'utilise des fils de cuivre dur pour avoir une prise sur le dessus de l'étoile.

Remarque importante concernant l'alimentation: étant donné que la même alimentation alimentera à la fois le PI, l'Arduino et la bande LED, elle doit être suffisamment robuste pour pouvoir les gérer toutes, elle sera donc basée sur la bande LED que vous choisissez pour le projet. Une bande LED commerciale 5050 12v 3 mètres draine environ 2A, c'est beaucoup. Pour le PI et l'Arduino il faut calculer en +2A (même si c'est surdimensionné ça ne fera pas de mal). En utilisant une bande LED sur des ampoules halogènes standard, des néons ou d'autres éclairages haute puissance, vous pouvez mettre tout ce circuit sur une belle batterie au plomb 12V @ 10Ah comme sauvegarde afin qu'elle fonctionne même en cas de panne de courant.

Le buck abaissera la tension de 12-> 5V pour alimenter l'Arduino et le PI tandis que l'alimentation directe 12V est câblée sur le relais pour allumer la bande LED.

Étape 3: Logiciel Arduino

Logiciel Arduino
Logiciel Arduino

Vous pouvez trouver le code source complet ci-dessous qui est bien commenté mais voici une brève explication de son fonctionnement: Au début de chaque boucle, la fonction habituelle xcomm() est appelée pour voir s'il existe une commande provenant du Raspberry PI qui peut être LIGHT_ON/OFF pour allumer les lumières du couloir ou DS_ON/OFF pour allumer/éteindre le rétroéclairage DeathStar, je les ai mis en œuvre juste pour la perfection car si quelqu'un passe par le PIR devrait le ramasser et allumer les lumières mais peut-être que vous voulez regarder l'endroit pour une raison quelconque, même quand il n'y a personne.

Après cela, la valeur de la cellule photoélectrique lue et la broche de mouvement est vérifiée pour le mouvement. S'il y a du mouvement, le code vérifie s'il fait assez sombre, puis il vérifie si nous ne sommes pas en attente. Si tout cela passe, il allume simplement la lumière du couloir et renvoie PHOENIX_MOTION_DETECTED au Raspberry PI, s'il ne fait pas assez sombre, il renvoie toujours un signal à l'ordinateur mais n'allume pas la lumière. Une fois qu'un mouvement est détecté, une minuterie de maintien de 5 minutes est lancée.

Juste après cela, la section de code suivante vérifiera si nous sommes en attente (ce qui devrait être le cas s'il n'y a eu qu'un événement de mouvement, supposons donc que les 5 minutes se sont écoulées pour que cette vérification puisse confirmer). Le code vérifie s'il y a à nouveau du mouvement, sinon éteignez les lumières. Comme vous pouvez le voir, s'il n'y a pas de mouvement, cette fonction se répétera encore et encore en essayant d'éteindre les lumières afin qu'il n'y ait pas de retour vers le PC.

Nous avons une autre minuterie d'attente pour l'éclairage interne de l'Étoile de la mort qui dépend uniquement de la lecture de la cellule photoélectrique < dark_limit.

Bien que les 2 routines ne se connaissent pas, elles fonctionneront parfaitement ensemble puisque lorsque la lumière du couloir s'allume, elle fournit tellement de lumière que le LDR pensera qu'il fait de nouveau jour et il éteint l'éclairage interne. Cependant, il y avait quelques mises en garde à propos de ce processus qui sont expliquées dans le code si vous êtes intéressé, sinon prenez la réponse Nvidia que "ça marche juste!".

Étape 4: Logiciel Raspberry PI

Logiciel Raspberry PI
Logiciel Raspberry PI
Logiciel Raspberry PI
Logiciel Raspberry PI
Logiciel Raspberry PI
Logiciel Raspberry PI

Le dernier Raspbian fonctionne pour moi:

Raspbian GNU/Linux 9.4 (stretch)

Linux Phoenix 4.9.35-v7+ #1014 SMP Ven 30 juin 14:47:43 BST 2017 armv7l GNU/Linux ii motion 4.0-1 programme de capture armhf V4L prenant en charge la détection de mouvement

Bien que vous puissiez utiliser d'autres distributions, si vous rencontrez des problèmes avec l'appareil photo, vous n'obtiendrez l'assistance de l'équipe que si vous utilisez leur système d'exploitation officiel. La suppression des bloatwares indésirables tels que systemd est également fortement recommandée.

Motion peut également être construit à partir de la source facilement:

apt-get -y install autoconf automake pkgconf libtool libjpeg8-dev build-essential libzip-dev apt-get install libavformat-dev libavcodec-dev libavutil-dev libswscale-dev libavdevice-dev

apt-get -y install libavformat-dev libavcodec-dev libavutil-dev libswscale-dev libavdevice-dev apt-get -y install git git clone https://github.com/Motion-Project/motion cd motion/ autoreconf -fiv. /configure --prefix=/usr/motion make && make install /usr/motion/bin/motion -v

Je recommande iSpy comme enregistreur vidéo/serveur collecteur. Malheureusement, au moment d'écrire ces lignes, il n'y a pas de bonnes alternatives pour Linux. La caméra peut être ajoutée avec une URL MJPEG https://CAMERA_IP:8081 le port par défaut.

Le traitement de mouvement peut être utile par exemple vous n'avez pas à regarder votre serveur iSpy toute la journée, vous pouvez recevoir un email en cas de mouvement. Bien qu'iSpy ait cette fonctionnalité pour alerter par e-mail en cas de mouvement, il active l'enregistrement de temps en temps pour divers événements, comme une lumière réfléchie dans la zone. Avec la détection de mouvement PIR, je n'ai jamais eu une seule fausse alarme. Les alertes peuvent être traitées localement:

Événement de mouvement Pir détecté sur le capteur > Alerte Arduino > Raspberry pi reçoit sur la console > Programme de traitement C > Application de messagerie externe

Cependant, je préfère traiter à la fois les journaux et les vidéos à distance. traitement ultérieur.

void logger(char *text) {

FICHIER *f = fopen("phoenix.log", "a"); if (f == NULL) { printf("Erreur d'ouverture du fichier journal !\n"); revenir; } fprintf(f, "%s => %s\n", cur_time(0), text); fferme(f); #ifdef SYSLOG char loggy[500]; sprintf(loggy, "%s => %s\n", cur_time(0), text); setlogmask (LOG_UPTO (LOG_NOTICE)); openlog ("DeathStar", LOG_CONS | LOG_PID | LOG_NDELAY, LOG_USER); //syslog (LOG_NOTICE, "Programme démarré par l'utilisateur %d", getuid ()); syslog (LOG_NOTICE, journalisation); closelog (); #endif retour; }

Du côté de la réception, syslog-ng peut démultiplexer ces événements à partir du flux de journal principal:

filtre f_phx{

match("Étoile de la Mort"); }; destination d_phx { file("/var/log/phoenix/deathstar.log"); }; log { source(s_net); filtre(f_phx); destination(d_phx); };

et il peut être transmis à un autre outil (motion.php voir ci-joint) pour analyse et alerte.

Dans ce script, vous pouvez simplement définir l'heure habituelle de la semaine lorsque vous n'êtes pas à la maison:

$opt['alert_after']='09:00:00'; // Matins$opt['alert_before']='17:00:00'; // Soirées

Le programme php utilise l'excellent utilitaire logtail pour analyser les journaux.

$cmd = "logtail -o".$offsetfile.' '.$logfile.'>'.$logfile2;

Logtail suit la position dans un fichier de décalage afin que le programme principal n'ait pas à savoir à partir de quel moment commencer à regarder les journaux, il recevra les dernières données non traitées.

Motion.php peut être exécuté à partir de crontab avec une petite astuce pour les week-ends, lorsqu'il parcourra les journaux, mais ne fera aucun autre traitement.

*/5 * * * 1-5 /usr/local/bin/php ~/motion.php &>/dev/null*/5 * * * 6-7 /usr/local/bin/php ~/motion.php week-end &>/dev/null

Étape 5: Problèmes et liste des tâches

Problèmes et liste de tâches
Problèmes et liste de tâches
Problèmes et liste de tâches
Problèmes et liste de tâches

Si vous utilisez Raspberry pi 3 ou une version plus récente, vous pouvez ignorer cette section, vous ne rencontrerez probablement plus ces problèmes.

Au fil des ans, j'ai eu quelques problèmes avec les cartes basées sur Raspberry pi 2 qui pouvaient exécuter la même pile logicielle mais qui étaient achetées à des moments différents et à des endroits différents. Après une certaine période de temps qui pourrait être de 2 jours ou 20 jours lorsque SSH sur l'appareil, le SSH se bloquerait, de sorte que le démon de mouvement et le code C local qui parlaient à l'Arduino étaient chargés dans la RAM, donc l'appareil fonctionnait mais il était impossible d'en faire autre chose dans cet état.

Après de nombreux dépannages, j'ai trouvé une solution:

homesync.sh

#!/bin/sh -e

### BEGIN INIT INFO # Fournit: homesync # Démarrage requis: mountkernfs $local_fs # Arrêt requis: camera phoenix # Démarrage par défaut: S # Arrêt par défaut: 0 6 # Description courte: Synchroniseur domestique # Description: Synchroniseur domestique par NLD ### END INIT INFO NAME=home DESC="Ramdisk Home Synchronizer" RAM="/home/" DISK="/realhome/" set -e case "$1" in start|forth) echo -n "Démarrage $ DESC: " rsync -az --numeric-ids --delete $DISK $RAM &> /dev/null echo "$NAME.";; stop|back) echo -n "Arrêt de $DESC: " rsync -az --numeric-ids --delete $RAM $DISK &> /dev/null echo "$NAME.";; *) echo "Utilisation: $0 {start|stop}" exit 1;; esac sortie 0

Le script s'accompagne d'une modification fstab:

tmpfs /home tmpfs rw, size=80%, nosuid, nodev 0 0

La partition home est montée en tant que disque virtuel, ce qui donnerait environ 600 Mo d'espace libre sur le Raspberry pi 2, ce qui est plus que suffisant pour stocker des binaires et de petits fichiers journaux:

tmpfs 690M 8,6M 682M 2% /maison

Il s'est avéré que le blocage PI était attribué aux opérations d'écriture sur la carte SD, bien que j'aie essayé différentes cartes (Samsung EVO, Sandisk) qui ont été analysées à la recherche d'erreurs plusieurs fois avant et après et elles n'ont eu aucun problème avec d'autres ordinateurs portables. à venir. Je n'ai pas (encore) eu le même problème avec les Raspberry PI 3 et le matériel supérieur, c'est donc aussi pourquoi je les recommande dans ce tutoriel.

Bien que le mouvement actuel sur un Raspberry PI 3 soit juste assez bon pour moi, voici quelques idées qui méritent d'être explorées:

  1. N'utilisez pas de mouvement, mais utilisez un flux raspivid sur le réseau et laissez un serveur puissant effectuer la détection de mouvement et l'encodage vidéo (par exemple iSpy). -> Problème: monopolisation constante de la bande passante du réseau.
  2. Utilisez motion et laissez ffmpeg faire l'encodage vidéo. -> Problème: le processeur ne peut pas gérer les résolutions plus élevées
  3. Utilisez le mouvement, enregistrez des vidéos brutes et laissez un serveur puissant s'occuper de l'encodage. -> L'utilisation du processeur sur RPi est faible et la bande passante du réseau est limitée lorsqu'il y a un mouvement réel. Pour ce scénario, nous pourrions écrire sur une carte SD/un disque RAM pour un débit maximal, puis copier la vidéo sur un autre serveur.

Je voudrais également noter que la construction de ce projet est possible de construire sans Arduino. Tous les composants (relais, LDR, PIR) pourraient être connectés au raspberry pi d'une manière ou d'une autre, mais je préfère les microcontrôleurs en temps réel pour interagir avec les capteurs et les périphériques de sortie. Dans les cas où mon raspberry pi pendait par exemple ou s'écrasait, le contrôle de la lumière géré par l'Arduino fonctionnait très bien.

Si vous avez aimé cette instructable, restez à l'écoute car je continuerai la série avec ma caméra dôme extérieure raspberry pi zéro à 360 degrés l'année prochaine.

Conseillé: