Framboos PI -kamera en Light Control Death Star: 5 stappe (met foto's)

2024 Outeur: John Day | [email protected]. Laas verander: 2024-01-30 07:26

Soos altyd wil ek toestelle bou wat nuttig is, robuust werk en dikwels selfs verbeterings is in vergelyking met die huidige oplossings.

Hier is nog 'n wonderlike projek, oorspronklik genaamd Shadow 0f Phoenix, 'n Framboos PI -skild in samewerking met op Arduino gebaseerde bewegingsopsporing en ligkontroles.

Stap 1: Die toestand van kommersiële IP -kameras

Behalwe dat die bou van u eie kamera/toesigstelsel meer gaaf is, laat ons kyk hoekom is dit 'n verbetering van 'n standaard oplossing.

Ek sal dit vergelyk met die NEO COOLCAM Full HD 1080P Wireless IP Camera -reeks, aangesien ek baie van hierdie verskillende modelle neo coolcams (ONVIF) kameras besit het. Hulle kom in verskillende vorms en groottes, buite en binne, die meeste van hulle het ingeboude wifi -ondersteuning, maar kom ons kyk na hul voorbehoud:

• Chinese vervaardigers wat hierdie kameras verkoop, lieg byna altyd oor die ingeboude beeldsensorresolusie. As u 'n 5MP/8MP -kamera op Ebay koop, kan u 'n goedkoop 2MP -kamera met 'n slegte beeld kry (dit werk, maar die kwaliteit is vullis). As u die 8MP Raspberry PI v2 -kamera by die oorspronklike handelaar koop, kry u waarvoor u betaal het en die werklike 8MP -sensor met 'n resolusie van 3280 × 2464 pixels =>
• Vanuit sekuriteitsoogpunt is hierdie kameras (selfs die duurder Dlink en ander modelle) verskriklik; dit gebruik standaard wagwoorde soos 123456 of ingeboude gebruikers soos admin/admin operateur/operateur, wat u moontlik nie eers sal kan verander nie, of die verandering is weg na 'n herlaai. Maak 'n goeie idee met baie van hierdie kameras om tuis te skakel (maak verbinding met hul bedieners in China, sommige stroom selfs video/foto's terug sonder om u te vra net om dit makliker te maak as u besluit om eendag hul Android/Iphone -app te installeer om na u huis). Selfs as u hierdie toestelle agter 'n router plaas, is dit net nie goed genoeg nie, maar die beste is as u nie 'n standaardpoort daarin instel, dit firewall of in 'n VLAN sit nie, sodat dit onmoontlik is om uit te gaan na die internet of selfs beter: gebruik dit glad nie.
• Is hulle meer betroubaar? nee, baie van hulle, selfs die duurder DLINK's, het die opsie om die kamera daagliks/weekliks te herlaai, ens. Die opsie is daar om 'n rede, want na X dae verloor hulle Wifi -verbinding of misbruik hulle op ander maniere. Dink net daaraan dat hulle goeie ou Win95 -bokse is wat meer gereeld as herbegin moet word:) konfigurasie, koellinks, outomatiese koelwaaiers en minimale RW -werking op die SDCARD, kan hulle die 100+ dae uptyd sonder probleme bereik. By die skryf hiervan was my DeathStar sedert 34 dae al meer as 100, maar soms het ek 'n stroombron ingevoer, wat 'n paar ander kringe van my dryf, sodat ek dit moes afskakel:(
• Gerigte hardeware: hulle is gemaak vir 1 spesifieke doel, kom gereeld met 'n klein nvram -area en 'n besige boks, maar sommige modelle maak die toegang tot hierdie dop ook onmoontlik, en al waarvoor u dit kan gebruik, is waarvoor dit bedoel is om te gebruik terwyl u kan Gebruik u Raspi -kamera vir alle ander take: lêerbediener, tftp/dhcp -bediener, webbediener, aardbewingsbediener … die opsies is onbeperk.
• Stoorplek: hulle het nie een nie, of hulle gebruik microsd -kaarte met FAT32 -lêerstelsel VS op die framboospis, u kan selfs 'n 2 TB -hardeskyf aanheg as u wil.
• Beheerligte: sommige het wel 'n ALARM -uitset, waar u moontlik 'n klein relais kan aansluit om ligte aan te skakel. Soos ek u in hierdie tutoriaal sal wys, is dit 'n vermorsing van tyd om infrarooi kameras te gebruik, aangesien u weens die swak kwaliteit niemand op die IR -foto's kan identifiseer nie. As u 'n video in die donker wil opneem, is dit die beste manier om eers 'n bietjie lig aan te skakel, en dan die video op te neem.

U kan dus vra of daar enige voordele is om 'n kamera op die rak te gebruik? Ja vir besighede waar die werksure om dit op te stel duurder sou wees as om met framboospis te peuter (in elk geval nie vir my nie:)) en ja, daar is top -kameras (500 $+ met 'n beter resolusie as die pi -kamera van kursus). As 'n ander voordeel kan ek sê dat die kameras wat die ONVIF -standaard volg, gesentraliseerde verskaffing vergemaklik het. Dit bied 'n standaard koppelvlak wat gebruik kan word om opdragte na die kamera te stuur om die IP/netwerkmasker/gateway en ander dinge in te stel. Hiervoor kan u die Onvif -toestelbestuurder van Sourceforge aflaai. Baie van hierdie toestelle het 'n baie gebroke webfront, waar dit byvoorbeeld nie toelaat dat u die ip of netmasker korrek instel nie, want die javascript wat hierdie velde valideer, funksioneer nie en u enigste manier om hierdie parameters korrek in te stel, is deur ONVIF.

Stap 2: Planne van die Death Star

U kan hierdie toestel bou met enige van die Framboos -PI's vanaf 1 tot 3B+. Selfs die nul het kamera -poorte, maar aangesien daar soveel verskillende tweedehandse raspies op die mark is, wonder u miskien wat die ideaal is vir hierdie konstruksie.

Die antwoord hang af van waar u die videostroom wil verwerk.

Daar is twee keuses:

1, Verwerk die video's plaaslik met beweging en stuur 'n videostroom deur as daar beweging opgespoor word (let op: beweging stuur 'n stadige, konstante stroom na die bediener, ongeag wat dit kan wees, dit kan afhang van die resolusie en raamkoerse wat u gebruik, vanaf 'n paar honderd megagrepe tot verskeie gigabyte per dag, net 'n herinnering as u 'n opstelling met 'n meterverbinding wil instel). Hier is die SVE van belang, en ongelukkig trek beweging (op die oomblik van skryf) nie voordeel uit verskeie kerns nie, maar die bedryfstelsel sal die las effens probeer balanseer. U sal altyd een van die kerns vir 100% gebruik hê.

2, Verwerk die video's op 'n sentrale bediener: hier stuur u die rou videostroom net van die kamera na 'n eksterne streaming -skeerder (soos iSpy wat op 'n x86 -rekenaar werk of MotionEyeOS wat op 'n ander spesiale rekenaar werk). Aangesien daar nie plaaslik verwerk word nie, maak die PI -model wat u gebruik nie saak nie, stuur 'n PI1 dieselfde stroom as 'n PI3B+.

In hierdie tutoriaal gaan ek met die eerste keuse.

Die duimreël hier is dat hoe vinniger die SVE wat u aan die gang sit, hoe beter resultate sal u kry. Byvoorbeeld, my Raspi 2 -kamera wat na 'n gang kyk, het dit soms nie opgetel as iemand vinnig verbygegaan het nie en die opname was traag, wat baie rame laat val in vergelyking met die model 3. Die model 3 het ook die 802.11 abgn wifi wat handig is om video van hoër gehalte te kan stroom, dit werk uit die boks en is redelik betroubaar. Op die oomblik dat ek skryf dat die model 3B+ uit is, sou ek net aanbeveel dat u dit kry met 'n 1,4 Ghz Quad Core -cpu.

Lys van materiale

• 30 cm plastiek DeathStar:)
• Framboos Pi 3 B+
• PiCam v2 (8MP)
• Arduino Pro Micro 5.5v
• 2x SIP-1A05 Rietskakelaarrelais
• 1x PCS HC-SR501 IR Pyro-elektriese infrarooi IR PIR bewegingsensor detector module
• 1x 10kohm weerstand vir LDR
• 1x LDR
• 1x12V 4A DC -adapter
• 1xWarm wit LED 5050 SMD buigsame ligstrook 12V DC
• 1xBuck spanningsreguleerder

Soos u op die skemas kan sien, is hierdie projek oorspronklik ontwerp om 'n enkele lig met een relais te beheer, want ek was nie van plan om interne beligting by te voeg nie (wat redelik cool is), en ek het net 'n tweede relais aan die Arduino gekoppel. Die wonderlike van die SIP-1A05 is dat dit 'n interne terugdraaidiode het, en die verbruik in mA is ver onder die beperking van die krag per Arduino.

Die rede waarom die PIR op die foto's op die skerm is, omdat S0P in die begin beplan is om in 'n eenvoudige IP -plastiekboks te plaas in plaas van 'n DeathStar. Soos u dalk raai, is die kamera direk in die lasergeweer, maar die PIR en LDR het nog 'n gat geboor, en dit word met gom vasgemaak, aangesien ek nie van plan was om dit te verwyder nie.

Aan die onderkant van die DeathStar is 'n gat geboor, waar ek 'n groot bout met 'n sterk 2 -komponent gom vasgeplak het. Dit kan in die oorspronklike Neo Coolcams -staander vasgeskroef word (dit was tog goed vir iets:)). Vir 'n ekstra ondersteuning gebruik ek harde koperdrade om die bokant van die ster vas te hou.

Belangrike opmerking oor die kragtoevoer: aangesien dieselfde toevoer beide die PI, Arduino en die LED -strook sal aandryf, moet dit stewig genoeg wees om dit alles te kan hanteer, sodat dit gebaseer sal wees op die LED -strook wat u vir die projek kies. 'N Kommersiële 5050 12v 3 meter LED -strook dreineer ongeveer 2A, dit is baie. Vir die PI en Arduino moet u in +2A bereken (alhoewel dit te groot is, sal dit nie skade doen nie). Deur LED -strook oor standaard halogeen gloeilampe, neon of ander hoë krag beligting te gebruik, kan u die hele kring op 'n goeie 12V@10Ah loodsuurbattery as rugsteun plaas, sodat dit selfs werk as daar 'n kragonderbreking is.

Die boks verlaag die spanning van 12-> 5V om die Arduino en die PI aan te skakel, terwyl die direkte 12V-voeding op die relais bedraad is om die LED-strook aan te skakel.

Stap 3: sagteware Arduino

U kan die volledige bronkode hieronder vind wat goed kommentaar lewer, maar hier is 'n kort verduideliking hoe dit werk: Aan die begin van elke lus word die gewone xcomm () -funksie gebel om te sien of daar 'n opdrag van die Raspberry PI kom kan LIGHT_ON/OFF wees om die gangligte AAN te skakel of DS_ON/OFF om die DeathStar -agtergrond AAN/UIT te skakel; ek het dit geïmplementeer net vir oorvolmaaktheid, want as iemand by die PIR verbygaan, dit moet optel en aanskakel die ligte, maar miskien wil u om een of ander rede na die plek kyk, selfs al is niemand daar nie.

Hierna lees die fotoselwaarde in en die bewegingspen word op beweging nagegaan. As daar beweging is, kyk die kode of dit donker genoeg is, dan kyk dit of ons nie opgehou is nie. As dit alles verbygaan, skakel dit net die ganglig aan en stuur dit PHOENIX_MOTION_DETECTED terug na die Raspberry PI, as dit nie donker genoeg is nie, gee dit steeds 'n teken terug na die rekenaar, maar skakel die lig nie aan nie. Sodra 'n beweging opgespoor word, word 'n tydhouer van 5 minute begin.

Hierna sal die volgende kode -afdeling kyk of ons opgehou is (wat die geval moet wees as daar net 'n bewegingsgebeurtenis was, so laat ons aanvaar dat die 5 minute verloop het, sodat hierdie tjek kan bevestig). Die kode kyk of daar weer beweging is, indien nie, skakel dan die ligte af. Soos u kan sien as daar geen beweging is nie, sal hierdie funksie homself keer op keer herhaal, en probeer om die ligte af te skakel, sodat daar geen terugvoer op die rekenaar is nie.

Ons het 'n ander tydteller vir die interne beligting van die DeathStar, wat uitsluitlik afhang van fotocelllees <donker_limiet.

Alhoewel die twee roetines nie van mekaar weet nie, werk dit perfek saam, want as die ganglig aangaan, gee dit soveel lig dat die LDR weer sal dink dat dit weer bedags is en die interne beligting afskakel. Daar was egter 'n paar voorbehoude oor hierdie proses, wat in die kode uiteengesit word as u belangstel, indien nie, neem dan die Nvidia -antwoord dat 'dit werk net!'.

Stap 4: sagteware Framboos PI

Die nuutste Raspbian werk vir my:

Raspbian GNU/Linux 9.4 (rek)

Linux Phoenix 4.9.35-v7+ #1014 SMP Vr 30 Junie 14:47:43 BST 2017 armv7l GNU/Linux ii motion 4.0-1 armhf V4L-opnameprogram wat bewegingsopsporing ondersteun

Alhoewel u ander distros kan gebruik, kry u slegs ondersteuning van die span as u hul amptelike bedryfstelsel gebruik as u probleme met die kamera ondervind. Dit word ook sterk aanbeveel om ongewenste bloatware soos systemd te verwyder.

Beweging kan ook maklik uit die bron gebou word:

apt-get -y installeer 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 installeer libavformat-dev libavcodec-dev libavutil-dev libswscale-dev libavdevice-dev apt-get -y installeer git git kloon https://github.com/Motion-Project/motion cd motion/autoreconf -fiv. /configure --prefix =/usr/motion make && make install/usr/motion/bin/motion -v

Ek beveel iSpy aan as video -opnemer/versamelaarbediener. Ongelukkig is daar op die oomblik van skryf geen goeie alternatiewe vir Linux nie. Die kamera kan bygevoeg word met 'n MJPEG -url https:// CAMERA_IP: 8081 die standaardpoort.

Die bewegingsbeweging kan nuttig wees, byvoorbeeld dat u nie die hele dag na u iSpy -bediener hoef te kyk nie; u kan 'n e -pos ontvang in geval van beweging. Alhoewel iSpy hierdie funksie het om in beweging te stuur in e -pos, word die opname af en toe aangeskakel vir verskillende gebeurtenisse, soos dat lig in die gebied weerkaats word. Met die PIR -bewegingsopsporing het ek nooit 'n enkele vals alarm gehad nie. Die waarskuwings kan plaaslik verwerk word:

Pir -bewegingsgebeurtenis op sensor waargeneem> Arduino -waarskuwing> Framboos -pi ontvang op konsole> C -verwerkingsprogram> Eksterne posprogram

Ek verkies egter om die logboeke en video's op afstand te verwerk, so in hierdie geval het ek 'n afdeling by die C -beheerprogram gevoeg, terwyl dit die logs plaaslik in 'n gewone tekslêer aanmeld, dit ook by syslog aanmeld en dit word na 'n SIEM gestuur verdere verwerking.

leegte logger (teken *teks) {

LêER *f = fopen ("phoenix.log", "a"); if (f == NULL) {printf ("Kon nie die loglêer oopmaak nie! / n"); terugkeer; } fprintf (f, " %s => %s / n", cur_time (0), teks); fclose (f); #ifdef SYSLOG char loggy [500]; sprintf (loggy, " %s => %s / n", cur_time (0), teks); setlogmasker (LOG_UPTO (LOG_NOTICE)); openlog ("DeathStar", LOG_CONS | LOG_PID | LOG_NDELAY, LOG_USER); // syslog (LOG_NOTICE, "Program begin deur gebruiker %d", getuid ()); syslog (LOG_NOTICE, loggy); slotboek (); #endif terugkeer; }

Aan die ontvangkant kan syslog-ng hierdie gebeurtenisse van die hoofstroomstroom afneem:

filter f_phx {

wedstryd ("DeathStar"); }; bestemming d_phx {file ("/var/log/phoenix/deathstar.log"); }; log {bron (s_net); filter (f_phx); bestemming (d_phx); };

en dit kan na 'n ander hulpmiddel (motion.php, aangeheg) oorgedra word vir analise en waarskuwing.

In hierdie skrif kan u die gewone tyd gedurende die week instel as u nie tuis is nie:

$ opt ['alert_after'] = '09:00:00'; // Mornings $ opt ['alert_before'] = '17:00:00'; // Aande

Die php -program maak gebruik van die uitstekende logtail -nut om die logboeke te ontleed.

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

Logtail volg die posisie in 'n offsetlêer, sodat die hoofprogram nie hoef te weet van watter tyd af na die logboeke moet begin kyk nie; dit sal voorsien word van die nuutste onverwerkte data.

Motion.php kan vanaf die crontab uitgevoer word met 'n klein truuk vir die naweke, as dit deur die logboeke gaan, maar geen verdere verwerking nie.

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

Stap 5: Kwessies en taaklys

As u Raspberry pi 3 of nuwer gebruik, kan u hierdie afdeling oorslaan, waarskynlik sal u nie meer probleme ondervind nie.

Gedurende die jare het ek probleme ondervind met Raspberry pi 2 -borde wat dieselfde sagteware -stapel kan gebruik, maar op verskillende tye op verskillende plekke gekoop is. Na 'n sekere tydperk, wat 2 dae of 20 dae kan duur wanneer SSH op die toestel ingaan, sal die SSH net hang, sodat beide die bewegingsdemoon en die plaaslike C -kode wat met die Arduino gepraat het, in die ram gelaai word, dus werk die toestel maar in hierdie toestand was dit onmoontlik om iets anders daarmee te doen.

Na baie probleemoplossing het ek 'n oplossing gekry:

homesync.sh

#!/bin/sh -e

### BEGIN INIT INFO # Bied: tuis-sinchroniseer # Vereiste-begin: mountkernfs $ local_fs # Vereiste-stop: kamera phoenix # standaard-begin: S # standaard-stop: 0 6 # kort beskrywing: tuissynchronisator # beskrywing: tuissinkroniseerder deur NLD ### END INIT INFO NAME = home DESC = "Ramdisk Home Synchronizer" RAM = "/home/" DISK = "/realhome/" set -e case "$ 1" in start | forward) echo -n "Begin $ DESC: "rsync -az --numeric -ids -delete $ DISK $ RAM &> /dev /null echo" $ NAME. ";; stop | terug) echo -n "Stop $ DESC:" rsync -az --numeric -ids -delete $ RAM $ DISK &> /dev /null echo "$ NAME.";; *) eggo "Gebruik: $ 0 {begin | stop}" afrit 1;; esac afrit 0

Die draaiboek gaan saam met 'n fstab -wysiging:

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

Die huispartisie is gemonteer as ramdisk, wat ongeveer 600 MB vrye ruimte op die Raspberry pi 2 oplewer, wat meer as genoeg is om 'n paar binaries en klein loglêers te stoor:

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

Dit het geblyk dat die PI -hang toegeskryf word aan die skryfbewerkings op die SD -kaart, hoewel ek verskillende kaarte (Samsung EVO, Sandisk) probeer het, wat verskeie kere voor en daarna op foute gesoek is, en dit was geen probleem met ander skootrekenaars nie. opkom. Ek het (nog) nie dieselfde probleem gehad met Raspberry PI 3's en hoër hardeware nie, en daarom beveel ek dit ook aan in hierdie tutoriaal.

Alhoewel die huidige beweging op 'n Raspberry PI 3 net goed genoeg is vir my, is hier 'n paar idees wat die moeite werd is om te ondersoek:

1. Moenie beweging gebruik nie, maar gebruik 'n skerp stroom oor die netwerk en laat 'n kragtige bediener bewegingsopsporing en videokodering doen (bv. ISpy). -> Probleem: konstante netwerkbandwydte.
2. Gebruik beweging en laat ffmpeg die videokodering doen. -> Probleem: CPU kan nie die hoër resolusies hanteer nie
3. Gebruik beweging, neem rou video op en laat 'n kragtige bediener die kodering doen. -> CPU -gebruik op RPi is laag en netwerkbandbreedte is beperk tot wanneer daar werklike beweging is. Vir hierdie scenario kan ons na 'n SD-kaart/ramdisk skryf vir 'n maksimum deurset, en dan 'n kopie van die video na 'n ander bediener afskryf.

Ek sou ook daarop let dat die bou van hierdie projek moontlik is sonder 'n Arduino. Al die komponente (relais, LDR, PIR) kan op een of ander manier aan die framboos -pi gekoppel word, maar ek verkies dat mikro -beheerders in real -time met sensore en afvoertoestelle omgaan. In die gevalle waar my framboos pi byvoorbeeld gehang het of neergestort het, werk die ligbediening deur die Arduino goed.

As u van hierdie instruksies hou, bly ek op die hoogte, want ek sal die reeks voortgaan met my 360 grade buite framboos pi nul koepel kamera volgende jaar.