Càmera Raspberry PI i control de llum Estrella de la mort: 5 passos (amb imatges)

2024 Autora: John Day | [email protected]. Última modificació: 2024-01-30 08:15

Com sempre, busco construir dispositius que siguin útils, que funcionin de manera robusta i que sovint siguin fins i tot millores en comparació amb les solucions actuals disponibles.

Aquí hi ha un altre gran projecte, anomenat originalment Shadow 0f Phoenix, un escut Raspberry PI juntament amb controls de llum i detecció de moviment basats en Arduino.

Pas 1: l'estat de les càmeres IP comercials

A més de construir el vostre propi sistema de càmera / vigilància és més interessant, vegem per què és una millora a partir d’una solució fora de la plataforma.

Ho compararé amb la sèrie de càmeres IP sense fils NEO COOLCAM Full HD 1080P, ja que he posseït molts d'aquests diversos models de càmeres neo coolcams (ONVIF). Es presenten en diferents formes i mides, tant a l’aire lliure com a l’interior, la majoria tenen suport wifi però vegem les seves advertències:

• Els fabricants xinesos que venen aquestes càmeres gairebé sempre menten sobre la resolució incorporada del sensor d’imatge, quan compreu una càmera de 5MP / 8MP a Ebay és possible que tingueu una càmera barata de 2MP amb mala imatge (funciona, però la qualitat és una deixalla). Quan compreu la càmera Raspberry PI v2 de 8 MP al minorista original, obtindreu el que heu pagat i el sensor real de 8MP amb la resolució de 3280 × 2464 píxels =>
• Des del punt de vista de la seguretat, aquestes càmeres (fins i tot les Dlink i altres models més cars) són terribles, utilitzen contrasenyes predeterminades com 123456 o usuaris integrats com administrador / administrador / operador / operador, el que fins i tot no podreu canviar o el canvi ha desaparegut després d'un reinici. Per acabar-ho d’adobar, moltes d’aquestes càmeres es poden connectar a casa (connecteu-vos als servidors de la Xina, fins i tot hi ha reproduccions de vídeo / imatges sense demanar-vos que us ho facilitin en cas que decidiu instal·lar la vostra aplicació Android / Iphone algun dia per a casa). Fins i tot si col·loqueu aquests dispositius darrere d’un enrutador, no és prou bo; el millor és que no hi configureu una passarel·la predeterminada, que els feu tallafocs o que els poseu a una VLAN perquè no pugui sortir a Internet o fins i tot millor: no els utilitzeu en absolut.
• Són més fiables? no, molts d'ells, fins i tot els DLINK més cars, tenen l'opció de reiniciar la càmera diàriament / setmanalment, etc. Aquesta opció hi és per un motiu, perquè després de X dies sovint perden la connectivitat Wifi o es comporten malament per altres formes. Penseu en ells com a bones velles caixes Win95 que calia reiniciar amb més freqüència:) No dic que el maquinari basat en Raspi sigui tan sòlid que pugueu convertir-les en centrals nuclears de control, però amb maquinari / programari adequat configuració, dissipadors de calor, ventiladors de refrigeració automàtics i un funcionament al mínim de RW a la targeta SDCARD, poden aconseguir fàcilment aquests 100+ dies d’activitat sense problemes. En el moment d’escriure, la meva DeathStar funcionava des de feia 34 dies, tenia més de 100, però de vegades estava piratejant l’alimentació de la font d’alimentació que alimentava alguns dels meus circuits, així que vaig haver de tancar-la:(
• Maquinari orientat: estan fets per a un propòsit específic, sovint inclouen una petita àrea nvram i busybox, però alguns models també fan impossible l'accés a aquest intèrpret d'ordres, de manera que tot el que pugueu fer servir és per a què es volia utilitzar mentre pugueu utilitzeu la càmera basada en Raspi per a qualsevol altra tasca: servidor de fitxers, servidor tftp / dhcp, servidor web, servidor de terratrèmols … les opcions són il·limitades.
• Espai d'emmagatzematge: o bé no en tenen o utilitzen targetes microsd amb sistema de fitxers FAT32 VS al raspberry pis, fins i tot podeu connectar un disc dur de 2 TB si ho desitgeu.
• Control de llums: alguns tenen una sortida ALARM on és possible que pugueu connectar un petit relé per activar els llums. Com us mostraré en aquest tutorial, l'ús de càmeres d'infrarojos suposa una completa pèrdua de temps, ja que no podreu identificar ningú a les imatges IR a causa de la mala qualitat. Si heu de gravar un vídeo a les fosques, la millor manera de fer-ho és encendre una mica de llum i, a continuació, gravar el vídeo.

Per tant, us podeu preguntar si hi ha algun PRO d’utilitzar una càmera fora de la plataforma? Sí, per a les empreses on l’horari laboral per configurar-lo seria més car que jugar amb Raspberry pis (no per a mi de totes maneres:)) i sí, hi ha càmeres de primera línia (500 $ + amb millor resolució que la càmera pi de curs). Com a avantatge més, podria dir que les càmeres que seguien l'estàndard ONVIF van facilitar el subministrament centralitzat. Això proporciona una interfície estàndard que es pot utilitzar per enviar ordres a la càmera per configurar la seva màscara IP / xarxa / passarel·la i altres coses. Per a això, podeu descarregar el gestor de dispositius Onvif des de Sourceforge. Molts d’aquests dispositius inclouen frontends web trencats i desagradables on, per exemple, no us permet configurar la IP o la màscara de xarxa correctament perquè el javascript que valida aquests camps no funciona i la vostra única manera d’establir aquests paràmetres és mitjançant ONVIF.

Pas 2: Plans de l'estrella de la mort

Podeu construir aquest dispositiu amb qualsevol dels Raspberry PIs a partir de l’1 al 3B +. Fins i tot el zero té ports de càmera, però com que hi ha tants raspis de segona mà diferents al mercat, us podeu preguntar quin és el més ideal per a aquesta versió.

La resposta depèn d'on vulgueu processar el flux de vídeo.

Hi ha dues opcions:

1, processeu els vídeos de manera local amb moviment i reenvieu un flux de vídeo quan es detecta moviment (nota: el moviment reenvia un flux constant lent al servidor, passi el que passi, pot variar en funció de la resolució i la velocitat de fotogrames que utilitzeu cent megabytes a diversos gigabytes al dia, només un recordatori si voleu configurar una connexió mesurada). Aquí la CPU és important i, malauradament, el moviment (en el moment d’escriure) no aprofita molts nuclis, però el sistema operatiu intentarà equilibrar lleugerament la càrrega. Sempre tindreu un dels nuclis amb un ús del 100%.

2, processeu els vídeos en un servidor central: aquí només reenvieu el flux de vídeo brut de la càmera a un servidor extern de transmissió (com ara iSpy que s’executa en un ordinador x86 o MotionEyeOS que s’executa en un altre miniordinador dedicat). Com que no hi ha processament local, el model de PI que feu servir no importa, un PI1 enviarà el mateix flux que un PI3B +.

En aquest tutorial aniré amb la primera opció.

La regla general aquí és que com més ràpida CPU llanci en moviment, millors resultats obtindreu. Per exemple, la meva càmera basada en Raspi 2 que mirava un passadís de vegades no la recollia quan algú passava ràpid i quan estava enregistrant l'enregistrament era lent, deixant caure molts fotogrames en comparació amb el model 3. El model 3 també té el 802.11 abgn wifi, que és útil per poder transmetre vídeos de més qualitat, funciona de manera ràpida i és bastant fiable. En el moment d’escriure que el model 3B + està fora, només us recomanaria que ho obtingueu amb una CPU de 1,4 Ghz Quad Core.

Llista de materials

• DeathStar de plàstic de 30 cm:)
• Raspberry Pi 3 B +
• PiCam v2 (8MP)
• Arduino Pro Micro 5.5v
• 2x relé de commutació de canya SIP-1A05
• 1x PCS HC-SR501 IR Piroelèctric IR infraroig PIR sensor de moviment mòdul de detecció
• 1x resistència de 10 kohm per a LDR
• 1x LDR
• Adaptador CC 1x12V 4A
• 1x llum blanca LED 5050 SMD tira de llum flexible 12V DC
• 1xBuck regulador de tensió

Com es pot veure als esquemes, aquest projecte es va dissenyar originalment per controlar una sola llum amb un relé perquè no tenia previst afegir il·luminació interna (que és bastant genial), així que acabo de connectar un segon relé a l’Arduino. El millor del SIP-1A05 és que té un díode de flyback intern i que el consum en mA està molt per sota de la limitació de potència per pin d'Arduino.

La raó per la qual el PIR apareix a l’escut de les imatges perquè al principi es preveia que S0P es posés en una simple caixa de plàstic IP en lloc d’una DeathStar. Com es pot endevinar, la càmera es troba directament a la pistola làser, el PIR i el LDR necessitaven altres forats i estan armats amb cola ja que no penso treure'ls.

Es va practicar un forat a la part inferior del DeathStar on vaig enganxar en un cargol gran amb una forta cola de dos components. Això es pot cargolar al suport Neo Coolcams original (al cap i a la fi era bo per a alguna cosa:)). Per obtenir un suport addicional, faig servir cables de coure dur per agafar la part superior de l'estrella.

Nota important sobre la font d'alimentació: ja que la mateixa font alimentarà tant el PI, Arduino com la tira LED, ha de ser prou resistent per poder-los manejar, de manera que es basarà en la tira LED que trieu per al projecte. Una tira LED comercial de 5050 12v 3meter drena al voltant de 2A, això és molt. Per al PI i Arduino heu de calcular en + 2A (tot i que això sigui excessiu, no us farà mal). Si utilitzeu una tira LED sobre bombetes halògenes estàndard, neó o una altra il·luminació d’alta potència, podeu posar tot aquest circuit en una bonica bateria de plom àcid de 12V @ 10Ah com a còpia de seguretat, de manera que fins i tot funcionarà en cas d’aparició de corrent.

El dòlar reduirà la tensió de 12-> 5V per alimentar l'Arduino i el PI mentre l'alimentació directa de 12V es connecta al relé per encendre la tira LED.

Pas 3: programari Arduino

Podeu trobar el codi font complet a continuació, que està ben comentat, però aquí teniu una breu explicació del seu funcionament: Al principi de cada bucle es crida a la funció xcomm () habitual per veure si hi ha una ordre provinent del Raspberry PI que pot ser LIGHT_ON / OFF per encendre els llums del passadís o DS_ON / OFF per encendre / apagar la llum de fons DeathStar, els he implementat només per tal de superar la perfecció, ja que si algú passa pel PIR hauria de recollir-lo i encendre'l els llums, però potser voleu mirar el lloc per alguna raó, fins i tot quan ningú no hi és.

Després d'això, es llegeix el valor de la fotocèl·lula i es comprova el moviment del pin de moviment. Si hi ha moviment, el codi comprova si és prou fosc, comprova si no estem en espera. Si tot això passa, simplement encén la llum del passadís i torna a enviar PHOENIX_MOTION_DETECTED al Raspberry PI, si encara no és prou fosc, torna a senyalitzar l’ordinador però no l’encén. Un cop detectat un moviment, s'inicia un temporitzador de retenció de 5 minuts.

Just després d'això, la següent secció de codi comprovarà si estem en espera (que hauria de ser el cas si només hi hagués un esdeveniment de moviment, per tant, suposem que passen els 5 minuts perquè aquesta comprovació pugui confirmar-la). El codi comprova si hi ha moviment de nou, si no, apagueu els llums. Com podeu veure si no hi ha moviment, aquesta funció es repetirà una i altra vegada i intenteu apagar els llums, de manera que no hi hagi comentaris al PC.

Tenim un altre temporitzador de retenció per a la il·luminació interna del DeathStar, que depèn purament de la lectura de fotocèl·lules <dark_limit.

Tot i que les dues rutines no es coneixen, funcionaran perfectament juntes, ja que quan s’encén la llum del passadís proporciona tanta llum que el LDR pensarà que és de dia i torna a apagar la il·luminació interna. Tanmateix, hi va haver algunes advertències sobre aquest procés que s'explica al codi si esteu interessat, si no, responeu a Nvidia que "només funciona!".

Pas 4: programari Raspberry PI

Les darreres obres de Raspbian per a mi:

Raspbian GNU / Linux 9.4 (extensió)

Linux Phoenix 4.9.35-v7 + # 1014 SMP Div 30 de juny 14:47:43 BST 2017 armv7l GNU / Linux ii motion 4.0-1 programa de captura armhf V4L compatible amb la detecció de moviment

Tot i que podeu utilitzar altres distribucions, si teniu problemes amb la càmera, només obtindreu assistència de l’equip si utilitzeu el seu sistema operatiu oficial. També és altament recomanable eliminar els programes inflables no desitjats, com ara systemd.

El moviment també es pot crear des de la font fàcilment:

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

Recomano iSpy com a servidor de gravació / col·lecció de vídeo. Malauradament, en el moment d’escriure això, no hi ha bones alternatives per a Linux. La càmera es pot afegir amb un URL MJPEG https:// CAMERA_IP: 8081, el port per defecte.

El processament del moviment pot ser útil, per exemple, que no haureu de seguir mirant el vostre servidor iSpy durant tot el dia; podeu rebre un correu electrònic en cas de moviment. Tot i que iSpy té aquesta funcionalitat per alertar al correu electrònic en cas de moviment, activa la gravació de tant en tant per a esdeveniments diversos, com ara que es reflecteixi una mica de llum a la zona. Amb la detecció de moviment PIR mai no vaig tenir una sola alarma falsa. Les alertes es poden processar localment:

Esdeveniment de moviment Pir detectat al sensor> Alerta Arduino> Raspberry pi rep a la consola> Programa de processament C> Aplicació de correu extern

No obstant això, prefereixo processar tant els registres com els vídeos de manera remota, de manera que en aquest cas he afegit una secció al programa de control C mentre registra localment els registres en un fitxer de text pla, també els registra a syslog i es reenvia a un SIEM per processament posterior.

registre buit (caràcter * text) {

FITXA * f = fopen ("phoenix.log", "a"); if (f == NULL) {printf ("Error en obrir el fitxer de registre! / n"); tornar; } fprintf (f, "% s =>% s / n", cur_time (0), text); fclose (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, "Programa iniciat per l'usuari% d", getuid ()); syslog (LOG_NOTICE, loggy); closelog (); #endif tornar; }

Al final receptor syslog-ng pot desmuntar aquests esdeveniments del flux de registre principal:

filtre f_phx {

match ("DeathStar"); }; destinació d_phx {fitxer ("/ var / log / phoenix / deathstar.log"); }; registre {font (s_net); filtre (f_phx); destinació (d_phx); };

i es pot passar a una altra eina (motion.php vegeu adjunt) per analitzar-la i alertar-la.

En aquest script només podeu establir l’hora habitual durant la setmana quan no esteu a casa:

$ opt ['alert_after'] = '09:00:00'; // Matins $ opt ['alert_before'] = '17:00:00'; // Vespres

El programa php utilitza l’excel·lent utilitat de registre de registre per analitzar els registres.

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

Logtail fa un seguiment de la posició en un fitxer desplaçat, de manera que el programa principal no ha de saber a partir de quin moment ha de començar a mirar els registres, sinó que es proporcionaran les darreres dades no processades.

Motion.php es pot executar des de crontab amb un petit truc per als caps de setmana, quan passarà pels registres, però no es processarà més.

* / 5 * * * 1-5 / usr / local / bin / php ~ / motion.php &> / dev / null * / 5 * * * 6-7 / usr / local / bin / php ~ / motion.php cap de setmana &> / dev / null

Pas 5: Problemes i llista de tasques

Si utilitzeu Raspberry pi 3 o versions posteriors, podeu ometre aquesta secció, és probable que ja no tingueu aquests problemes.

Durant els anys vaig tenir alguns problemes amb les plaques basades en Raspberry pi 2, que podrien executar la mateixa pila de programari, però que es van comprar en diferents moments des de llocs diferents. Després d'un període de temps determinat, que podria ser de 2 dies o 20 dies quan SSH s'iniciava al dispositiu, el SSH només penjaria, de manera que tant el dimoni de moviment com el codi C local que parlava amb l'Arduino es carregaven al RAM, per tant, el dispositiu funcionava però era impossible fer res més amb aquest estat.

Després de moltes solucions de problemes, he trobat una solució:

homesync.sh

#! / bin / sh -e

### BEGIN INIT INFO # Ofereix: homesync # Required-Start: mountkernfs $ local_fs # Required-Stop: camera phoenix # Default-Start: S # Default-Stop: 0 6 # Short-Description: Home synchronizer # Description: Home synchronizer per NLD ### END INIT INFO NAME = home DESC = "Ramdisk Home Synchronizer" RAM = "/ home /" DISK = "/ realhome /" set -e case "$ 1" in start | forth) echo -n "Starting $ DESC: "rsync -az --numeric-ids --delete $ DISK $ RAM &> / dev / null echo" $ NAME ".;; stop | back) echo -n "Aturar $ DESC:" rsync -az --numeric-ids --delete $ RAM $ DISK &> / dev / null echo "$ NAME".;; *) eco "Ús: $ 0 {start | stop}" sortida 1;; sortida 0 d'esac

El guió combina amb una modificació fstab:

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

La partició inicial es munta com a disc ram que donaria aproximadament 600 MB d'espai lliure al Raspberry pi 2, que és més que suficient per emmagatzemar alguns fitxers binaris i petits registres:

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

Va resultar que el bloqueig de PI es va atribuir a les operacions d’escriptura de la targeta SD, tot i que he provat diferents targetes (Samsung EVO, Sandisk) que es van analitzar per detectar errors diverses vegades abans i després i no tenien cap problema en altres ordinadors portàtils. pujant. No tenia el mateix problema (encara) amb el Raspberry PI 3s i el maquinari superior, de manera que també és per això que els recomano en aquest tutorial.

Tot i que el moviment actual d’un Raspberry PI 3 és prou bo per a mi, aquí teniu algunes idees que val la pena explorar:

1. No utilitzeu moviment, sinó que utilitzeu un flux fluït a la xarxa i deixeu que un servidor potent faci la detecció de moviment i la codificació de vídeo (per exemple, iSpy). -> Problema: captació d'amplada de banda de xarxa constant.
2. Utilitzeu el moviment i deixeu que ffmpeg faci la codificació del vídeo. -> Problema: la CPU no pot gestionar les resolucions més altes
3. Utilitzeu motion, enregistreu vídeo en brut i deixeu que un servidor potent faci la codificació. -> L'ús de la CPU a RPi és baix i l'ample de banda de la xarxa es limita a quan hi ha moviment real. Per a aquest escenari, podríem escriure a una targeta SD / disc ram per obtenir un rendiment màxim i, a continuació, redactar una còpia del vídeo a un altre servidor.

També recordo que la construcció d’aquest projecte és possible construir sense Arduino. Tots els components (relés, LDR, PIR) es podrien connectar al raspberry pi d'alguna manera, però prefereixo que els microcontroladors en temps real interaccionin amb els sensors i els dispositius de sortida. En els casos en què el meu raspberry pi estava penjat o es va estavellar, el control de llum de l'Arduino funcionava bé.

Si us ha agradat aquest instructiu, estigueu atent, ja que continuaré la sèrie amb la meva càmera de cúpula zero raspberry pi zero de 360 graus l’any vinent.