Bringebær PI -kamera og lysstyring Death Star: 5 trinn (med bilder)

2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:24

Som alltid ønsker jeg å bygge enheter som er nyttige, robuste og ofte er forbedringer sammenlignet med dagens hylleløsninger.

Her er enda et flott prosjekt, opprinnelig kalt Shadow 0f Phoenix, et Raspberry PI -skjold i forbindelse med Arduino -basert bevegelsesdeteksjon og lyskontroller.

Trinn 1: Tilstanden for kommersielle IP -kameraer

I tillegg til at det å bygge ditt eget kamera/overvåkingssystem er mer kult, la oss se hvorfor dette er en forbedring fra en hylleløsning.

Jeg vil sammenligne det med NEO COOLCAM Full HD 1080P Wireless IP Camera -serien siden jeg har eid mange av disse forskjellige modellene av neo coolcams (ONVIF) kameraer. De kommer i forskjellige former og størrelser, utendørs og innendørs, de fleste av dem har innebygd wifi -støtte, men la oss se sine forbehold:

• Kinesiske produsenter som selger disse kameraene lyver nesten alltid om den innebygde bildesensoroppløsningen. Når du kjøper et 5MP/8MP kamera på Ebay kan du ende opp med et billig 2MP kamera med dårlig bilde (det fungerer, men kvaliteten er søppel). Når du kjøper 8MP Raspberry PI v2 -kameraet fra den originale forhandleren, får du det du betalte for og den faktiske 8MP -sensoren med en oppløsning på 3280 × 2464 piksler =>
• Sett fra sikkerhet er disse kameraene (selv den dyrere Dlink og andre modeller) forferdelige, de bruker standardpassord som 123456 eller innebygde brukere som admin/admin operatør/operatør, det du kanskje ikke engang kan endre eller endringen er borte etter en omstart. Topp det med mange av disse kameraene som ringer hjem (koble til serverne deres i Kina, noen strømmer til og med tilbake video/bilder uten å be deg bare for å gjøre det lettere hvis du bestemmer deg for å installere Android/Iphone -appen en dag for å sjekke om din hjem). Selv om du setter disse enhetene bak en ruter, er det bare ikke bra nok, det beste er hvis du ikke angir en standard gateway i dem, brannmur dem ut eller setter dem inn i et VLAN for å gjøre det umulig for dem å gå ut til Internett eller enda bedre: ikke bruk dem i det hele tatt.
• Er de mer pålitelige? nei, mange av dem, selv de dyrere DLINK -ene, har muligheten til å starte kameraet på nytt daglig/ukentlig osv. Det alternativet er der av en grunn, fordi de etter X dager ofte mister Wifi -tilkobling eller oppfører seg feil på andre måter. Tenk på dem som gode gamle Win95 -bokser som måtte startes på nytt oftere enn ikke:) Jeg sier ikke at den Raspi -baserte maskinvaren er så bunnsolid at du kan bygge dem inn i kontroll kjernekraftverk, men med riktig maskinvare/programvare konfigurasjon, kjøleribber, automatiske kjølevifter og minimert RW -drift på SDCARD, kan de enkelt oppnå 100+ dagers oppetid uten problemer. Da jeg skrev DeathStar -kjøringen min siden 34 dager, har vært over 100, men noen ganger hacket jeg strømmen som strømmer til noen andre av kretsene mine, så jeg måtte slå den av:(
• Målrettet maskinvare: de er laget for 1 bestemt formål, kommer ofte med et lite nvram -område og busybox, men noen modeller gjør også tilgangen til dette skallet umulig, så alt du kan bruke dem til er hva de mente å brukes til mens du kan bruk ditt Raspi -baserte kamera til alle andre oppgaver: filserver, tftp/dhcp -server, webserver, quake -server … alternativene er ubegrensede.
• Lagringsplass: de har enten ingen eller de bruker microsd -kort med FAT32 -filsystem VS på bringebærpisene. Du kan til og med koble til en 2 TB harddisk hvis du vil.
• Kontrolllys: Noen har en ALARM -utgang der du kanskje kan koble til et lite relé for å få lys utløst. Som jeg vil vise deg i denne opplæringen, er bruk av infrarøde kameraer fullstendig bortkastet tid siden du ikke vil kunne identifisere noen på IR -bildene på grunn av dårlig kvalitet. Hvis du trenger å spille inn en video i mørket, er den beste måten å gjøre det på å tenne litt lys først og deretter ta opp videoen.

Så du kan spørre om det er noen fordeler med å bruke et hyllekamera? Ja for bedrifter der arbeidstiden for å sette den opp ville være dyrere enn å tukle med bringebærpis (ikke for meg uansett:)) og ja, det er toppmoderne kameraer (500 $+ med bedre oppløsning enn pi -kameraet til kurs). Som en annen fordel kan jeg si at kameraene etter ONVIF -standarden gjorde det sentralisert klargjøring enklere. Dette gir et standard grensesnitt for hva som kan brukes til å sende kommandoer til kameraet for å angi IP/nettverksmaske/gateway og andre ting. For dette kan du laste ned Onvif enhetsbehandling fra Sourceforge. Mange av disse enhetene kommer med ødelagte, ødelagte nettfronter, der det for eksempel ikke lar deg sette ip eller nettmaske riktig fordi javascriptet som validerer disse feltene er feil, og din eneste måte å sette disse parameterne riktig er gjennom ONVIF.

Trinn 2: Planer om Death Star

Du kan bygge denne enheten med hvilken som helst av bringebær -PI -ene fra 1 til 3B+. Selv nullen har kameraporter, men siden det er så mange forskjellige raspier på markedet, lurer du kanskje på hvilken som er den mest ideelle for denne bygningen.

Svaret avhenger av hvor du vil behandle videostrømmen.

Det er to valg:

1, Behandle videoene lokalt med bevegelse og videresende en videostrøm når det oppdages bevegelse (merk: bevegelse sender en langsom konstant strøm til serveren uansett hva, dette kan være avhengig av oppløsningen og bildefrekvensen du bruker fra et par hundre megabyte til flere gigabyte om dagen, bare en påminnelse hvis du vil gjøre et oppsett på en målt tilkobling). Her er CPU -en viktig, og dessverre drar ikke bevegelse (i skrivende stund) flere kjerner, men operativsystemet vil prøve å balansere belastningen litt. Du vil alltid ha en av kjernene på 100% bruk.

2, Behandle videoene på en sentral server: her videresender du bare den rå videostrømmen fra kameraet til en ekstern streaming -server (som iSpy som kjører på en x86 -datamaskin eller MotionEyeOS som kjører på en annen dedikert minidatamaskin). Siden det ikke er noen behandling lokalt, spiller ikke PI -modellen du bruker, en PI1 sender den samme strømmen som en PI3B+.

I denne opplæringen vil jeg gå med førstevalget.

Tommelfingerregelen her er at jo raskere CPU du kaster i bevegelse, desto bedre resultater får du. For eksempel tok mitt Raspi 2 -baserte kamera som så på en korridor noen ganger det ikke når noen gikk forbi fort og da det tok opptaket var opptaket tregt, og det falt mange bilder i forhold til modellen 3. Modellen 3 har også 802.11 abgn wifi som er nyttig for å kunne streame video av høyere kvalitet, det fungerer ut av esken og det er ganske pålitelig. I skrivende stund at modellen 3B+ er ute, vil jeg bare anbefale at du får den med 1,4 Ghz Quad Core cpu.

Liste over materialer

• 30 cm plast DeathStar:)
• Bringebær Pi 3 B+
• PiCam v2 (8MP)
• Arduino Pro Micro 5.5v
• 2x SIP-1A05 Reed Switch Relay
• 1x PCS HC-SR501 IR pyroelektrisk infrarød IR PIR bevegelsessensormodul
• 1x 10kohm motstand for LDR
• 1x LDR
• 1x12V 4A likestrømadapter
• 1xWarm White LED 5050 SMD Fleksibel lyslampe Strip 12V DC
• 1xBuck spenningsregulator

Som du kan se det på skjemaene, var dette prosjektet opprinnelig designet for å kontrollere ett enkelt lys med ett relé fordi jeg ikke hadde tenkt å legge til innvendig belysning (noe som er ganske kult), så jeg koblet bare et andre relé til Arduino. Det flotte med SIP-1A05 er at den har intern flyback-diode og forbruket i mA er langt under Arduino's per pin power limit.

Grunnen til at PIR er på skjoldet på bildene fordi S0P i begynnelsen var planlagt å bli satt i en enkel IP -plastboks i stedet for en DeathStar. Som du kanskje gjettet, er kameraet direkte i laserpistolen, og PIR og LDR trengte et nytt hull, og de er limskutt siden jeg ikke har tenkt å fjerne dem.

Det ble boret et hull i bunnen av DeathStar hvor jeg limte inn en stor bolt med et sterkt 2 -komponent lim. Dette kan skrues inn i det originale Neo Coolcams stativet (det var tross alt bra for noe:)). For en ekstra støtte bruker jeg harde kobbertråder for å ha et tak på toppen av stjernen.

Viktig merknad om strømforsyningen: siden den samme forsyningen vil drive både PI, Arduino og LED -stripen, må den være biffig nok til å kunne håndtere dem alle, så den vil være basert på LED -stripen du velger for prosjektet. En kommersiell 5050 12v 3meter LED -stripe drenerer rundt 2A, det er mye. For PI og Arduino må du beregne i +2A (selv om dette er for stort vil det ikke skade). Ved å bruke LED -stripe over standard halogenpærer, neon eller annen kraftig belysning er at du kan sette hele kretsen på et fint 12V@10Ah blybatteri som backup, så det vil til og med fungere i tilfelle strømbrudd.

Bukken vil senke spenningen fra 12-> 5V for å drive Arduino og PI mens den direkte 12V matingen er koblet til reléet for å slå på LED-stripen.

Trinn 3: Programvare Arduino

Du finner hele kildekoden nedenfor som er godt kommentert, men her er en kort forklaring på hvordan det fungerer: I begynnelsen av hver sløyfe kalles den vanlige xcomm () -funksjonen for å se om det kommer en kommando fra Raspberry PI som kan være LIGHT_ON/OFF for å slå korridorlysene PÅ eller DS_ON/OFF for å slå DeathStar -bakgrunnsbelysningen PÅ/AV, jeg har implementert disse bare for over perfeksjon, siden hvis noen passerer PIR skulle plukke den opp og slå på lysene, men kanskje du vil se på stedet av en eller annen grunn, selv når ingen er der.

Etter dette leses fotocelleverdien inn og bevegelsestappen kontrolleres for bevegelse. Hvis det er bevegelse, sjekker koden om den er mørk nok, så sjekker den om vi ikke er på vent. Hvis alt dette går, slår det bare på korridorlyset og sender tilbake PHOENIX_MOTION_DETECTED til Raspberry PI, hvis det ikke er mørkt nok, signalerer det fortsatt tilbake til datamaskinen, men tenner ikke lyset. Når en bevegelse er oppdaget, startes en 5 minutters ventetimer.

Rett etter dette vil den neste kodeseksjonen sjekke om vi er på vent (som burde være tilfelle hvis det bare var en bevegelseshendelse, så la oss anta at de fem minuttene som er gått, slik at denne sjekken kan bekrefte). Koden sjekker for å se om det er bevegelse igjen, hvis ikke slå av lysene. Som du kan se om det ikke er noen bevegelse, vil denne funksjonen gjenta seg igjen og igjen, prøv å slå av lysene, så det er ingen tilbakemelding til PCen.

Vi har en annen holdetidsur for DeathStars interne belysning som bare er avhengig av fotocelllesing <mørkegrense.

Selv om de to rutinene ikke vet om hverandre, vil de fungere perfekt sammen, siden når korridorlyset tennes, gir det så mye lys at LDR vil tro at det er dagtid igjen og det slår av den interne belysningen. Imidlertid var det noen forbehold om denne prosessen som er forklart i koden hvis du er interessert, hvis ikke, så ta Nvidia -svaret at "det bare fungerer!".

Trinn 4: Programvare Raspberry PI

Den siste Raspbian fungerer for meg:

Raspbian GNU/Linux 9.4 (stretch)

Linux Phoenix 4.9.35-v7+ #1014 SMP fre 30. juni 14:47:43 BST 2017 armv7l GNU/Linux ii motion 4.0-1 armhf V4L capture-program som støtter bevegelsesdeteksjon

Selv om du kan bruke andre distroer, får du kun støtte fra teamet hvis du bruker det offisielle operativsystemet hvis du støter på problemer med kameraet. Fjerne uønsket bloatware som systemd er også sterkt anbefalt.

Bevegelse kan også enkelt bygges fra kilde:

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

Jeg anbefaler iSpy som videoopptaker/samlerserver. Dessverre er det i skrivende stund ingen gode alternativer for Linux. Kameraet kan legges til med en MJPEG -url https:// CAMERA_IP: 8081 standardporten.

Bevegelsesbehandlingen kan være nyttig, for eksempel at du ikke trenger å fortsette å se på iSpy -serveren hele dagen. Du kan motta en e -post ved bevegelse. Selv om iSpy har denne funksjonaliteten for å varsle i e -post ved bevegelse, slår den på opptak en gang i blant for diverse hendelser som noe lys reflekteres til området. Med PIR -bevegelsesdeteksjon hadde jeg aldri en falsk alarm. Varslene kan behandles lokalt:

Pir motion -hendelse oppdaget på sensor> Arduino -varsel> Raspberry pi mottar på konsoll> C -behandlingsprogram> Eksternt e -postprogram

Jeg foretrekker imidlertid å behandle både loggene og videoene eksternt, så i dette tilfellet har jeg lagt til en seksjon i C -kontrollprogrammet til mens den logger loggene lokalt i en ren tekstfil, logger den også til syslog og som videresendes til et SIEM for videre bearbeiding.

void logger (char *text) {

FIL *f = fopen ("phoenix.log", "a"); if (f == NULL) {printf ("Feil ved åpning av loggfil! / n"); komme tilbake; } fprintf (f, " %s => %s / n", cur_time (0), tekst); fclose (f); #ifdef SYSLOG char loggy [500]; sprintf (loggy, " %s => %s / n", cur_time (0), tekst); setlogmask (LOG_UPTO (LOG_NOTICE)); openlog ("DeathStar", LOG_CONS | LOG_PID | LOG_NDELAY, LOG_USER); // syslog (LOG_NOTICE, "Program startet av bruker %d", getuid ()); syslog (LOG_NOTICE, loggy); closelog (); #endif retur; }

På mottakerenden kan syslog-ng demux disse hendelsene fra hovedloggstrømmen:

filter f_phx {

match ("DeathStar"); }; destinasjon d_phx {file ("/var/log/phoenix/deathstar.log"); }; logg {kilde (s_net); filter (f_phx); destinasjon (d_phx); };

og den kan sendes til et annet verktøy (motion.php se vedlagt) for analyse og varsling.

I dette skriptet kan du ganske enkelt angi vanlig tid i løpet av uken når du ikke er hjemme:

$ opt ['alert_after'] = '09:00:00'; // Morgen $ opt ['alert_before'] = '17:00:00'; // Kvelder

PHP -programmet bruker det utmerkede logtail -verktøyet til å analysere loggene.

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

Logtail sporer posisjonen i en offset -fil, slik at hovedprogrammet ikke trenger å vite fra hvilket tidspunkt man skal begynne å se på loggene på, det vil bli utstyrt med de siste ubehandlede dataene.

Motion.php kan kjøres fra crontab med et lite triks i helgene, når den skal gå gjennom loggene, men ikke gjøre ytterligere behandling.

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

Trinn 5: Problemer og gjøremålsliste

Hvis du bruker Raspberry pi 3 eller nyere kan du hoppe over denne delen, du vil mest sannsynlig ikke støte på disse problemene lenger.

I løpet av årene hadde jeg noen problemer med Raspberry pi 2 -baserte brett som kan kjøre den samme programvarestakken, men ble kjøpt på forskjellige tidspunkter fra forskjellige steder. Etter en viss tid som kunne være 2 dager eller 20 dager da SSHing inn på enheten SSH bare ville henge, så både bevegelsesdemonen og den lokale C -koden som snakket med Arduino ble lastet opp i ram, derfor fungerte enheten men det var umulig å gjøre noe annet med det lenger i denne tilstanden.

Etter mye feilsøking har jeg funnet en løsning:

homesync.sh

#!/bin/sh -e

### BEGIN INIT INFO # Leverer: homesync # Required-Start: mountkernfs $ local_fs # Required-Stop: camera phoenix # Standard-Start: S # Standard-Stop: 0 6 # Short-Description: Home synchronizer # Description: Home synchronizer av NLD ### END INIT INFO NAME = home DESC = "Ramdisk Home Synchronizer" RAM = "/home/" DISK = "/realhome/" set -e case "$ 1" i start | frem) echo -n "Starter $ DESC: "rsync -az --numeric -ids --delete $ DISK $ RAM &> /dev /null echo" $ NAME. ";; stop | back) echo -n "Stopping $ DESC:" rsync -az --numeric -ids --delete $ RAM $ DISK &> /dev /null echo "$ NAME.";; *) ekko "Bruk: $ 0 {start | stop}" exit 1;; esac exit 0

Skriptet går sammen med en fstab -modifikasjon:

tmpfs /home tmpfs rw, størrelse = 80%, nosuid, nodev 0 0

Hjemmepartisjonen er montert som ramdisk som vil gi ca 600 MB ledig plass på Raspberry pi 2, som er mer enn nok til å lagre noen binære filer og små loggfiler:

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

Det viste seg at PI -hengningen ble tilskrevet skriveoperasjonene på SD -kortet, selv om jeg har prøvd forskjellige kort (Samsung EVO, Sandisk) som ble skannet etter feil flere ganger før og etter, og de hadde ikke noe problem med andre bærbare datamaskiner, dette var bare Kommer opp. Jeg hadde ikke det samme problemet (ennå) med Raspberry PI 3s og høyere maskinvare, så det er også derfor jeg anbefaler dem i denne opplæringen.

Selv om den nåværende bevegelsen på en Raspberry PI 3 bare er god nok for meg, er det noen ideer som er verdt å utforske:

1. Ikke bruk bevegelse, men bruk en raspivid strøm over nettverket og la en kraftig server utføre bevegelsesdeteksjon og videokoding (f.eks. ISpy). -> Problem: konstant nettverksbåndbreddehogging.
2. Bruk bevegelse og la ffmpeg gjøre videokodingen. -> Problem: CPU kan ikke håndtere de høyere oppløsningene
3. Bruk bevegelse, ta opp rå video og la en kraftig server gjøre kodingen. -> CPU -bruken på RPi er lav og nettverksbåndbredden er begrenset til når det er faktisk bevegelse. For dette scenariet kan vi skrive til et SD-kort/ramdisk for maksimal gjennomstrømning og deretter kopiere videoen til en annen server.

Jeg vil også merke til at det er mulig å bygge dette prosjektet uten en Arduino. Alle komponentene (reléer, LDR, PIR) kan kobles til bringebær pi på en eller annen måte, men jeg foretrekker sanntids mikrokontrollere til å samhandle med sensorer og utgangsenheter. I tilfellene der bringebærpien min for eksempel hang eller krasjet, fungerte lysstyringen som ble kjørt av Arduino helt fint.

Hvis du likte dette instruerbare, fortsatte jeg med det, da jeg vil fortsette serien med mitt 360 graders utendørs bringebær pi zero dome kamera neste år.