Hindbær PI -kamera og lysstyring Death Star: 5 trin (med billeder)

2024 Forfatter: John Day | [email protected]. Sidst ændret: 2024-01-30 08:29

Som altid ønsker jeg at bygge enheder, der er nyttige, robuste og ofte er endda forbedringer i forhold til de nuværende hyldeløsninger.

Her er endnu et godt projekt, der oprindeligt hed Shadow 0f Phoenix, et Raspberry PI -skjold i forbindelse med Arduino -baseret bevægelsesdetektering og lysstyringer.

Trin 1: Tilstanden for kommercielle IP -kameraer

Udover at det er mere fedt at bygge dit eget kamera/overvågningssystem, lad os se, hvorfor dette er en forbedring fra en hyldeløsning.

Jeg vil sammenligne det med NEO COOLCAM Full HD 1080P Wireless IP Camera -serien, da jeg har ejet mange af disse forskellige modeller af neo coolcams (ONVIF) kameraer. De findes i forskellige former og størrelser, udendørs og indendørs, de fleste af dem har indbygget wifi -understøttelse, men lad os se deres forbehold:

• Kinesiske producenter, der sælger disse kameraer, lyver næsten altid om den indbyggede billedsensoropløsning, når du køber et 5MP/8MP kamera på Ebay, kan du ende med et billigt 2MP kamera med dårligt billede (det virker, men kvaliteten er skrald). Når du køber 8MP Raspberry PI v2 -kameraet fra den originale forhandler, får du det, du har betalt for, og den faktiske 8MP -sensor med en opløsning på 3280 × 2464 pixels =>
• Set fra sikkerhedens synspunkt er disse kameraer (selv de dyrere Dlink og andre modeller) forfærdelige, de bruger standardadgangskoder som 123456 eller indbyggede brugere som f.eks. Admin/admin -operatør/operatør, hvad du måske ikke engang kan ændre eller ændringen er væk efter en genstart. Top det med mange af disse kameraer telefon hjem (opret forbindelse til deres servere i Kina, nogle streamer endda video/billeder tilbage uden at bede dig bare om at gøre det lettere, hvis du beslutter dig for at installere deres Android/Iphone -app en dag for at kontrollere din hjem). Selvom du sætter disse enheder bag en router, er det bare ikke godt nok, det bedste er, hvis du ikke angiver en standardgateway i dem, firewall dem ud eller sætter dem i et VLAN for at gøre det umuligt for dem at gå ud til internettet eller endnu bedre: brug dem slet ikke.
• Er de mere pålidelige? nej, mange af dem, selv de dyrere DLINK'er har mulighed for at genstarte kameraet dagligt/ugentligt osv. Den mulighed er der af en grund, fordi de efter X dage ofte mister Wifi -forbindelse eller opfører sig forkert på andre måder. Tænk bare på dem som gode gamle Win95 -kasser, der skulle genstartes oftere end ikke:) Jeg siger ikke, at den Raspi -baserede hardware er så stensikker, at du kan bygge dem ind i kontrol atomkraftværker, men med ordentlig hardware/software konfiguration, køleplader, automatiske køleventilatorer og minimeret RW -drift på SDCARD'et kan de let ramme den 100+ dages oppetid uden problemer. I skrivende stund kørte mine DeathStar -kørsler siden 34 dage, været over 100, men nogle gange hackede jeg feedet i strømkilden, som driver nogle andre af mine kredsløb, så jeg måtte lukke det ned:(
• Målrettet hardware: de er lavet til 1 specifikt formål, kommer ofte med et lille nvram -område og busybox, men nogle modeller gør adgangen til denne skal også umulig, så alt hvad du kan bruge dem til er, hvad de betød at blive brugt til, mens du kan Brug dit Raspi -baserede kamera til alle andre opgaver: filserver, tftp/dhcp -server, webserver, quake -server … mulighederne er ubegrænsede.
• Lagerplads: de har enten ingen, eller de bruger microsd -kort med FAT32 -filsystem VS på hindbærpis, du kan endda vedhæfte en 2 TB harddisk, hvis du vil.
• Kontrollampe: Nogle har en ALARM -udgang, hvor du muligvis kan tilslutte et lille relæ for at få lys udløst. Som jeg vil vise dig i denne vejledning, er brug af infrarøde kameraer fuldstændig spild af tid, da du ikke vil kunne identificere nogen på IR -billederne på grund af den dårlige kvalitet. Hvis du har brug for at optage en video i mørket, er den bedste måde at tænde noget lys først og derefter optage videoen.

Så du kan spørge, om der er nogen fordele ved at bruge et kamera på hylden? Ja for virksomheder, hvor arbejdstiden for at oprette den ville være dyrere end at pille rundt med hindbærpis (ikke for mig alligevel:)) og ja, der er top of the line -kameraer (500 $+ med bedre opløsning end pi -kameraet på Rute). Som en anden fordel kunne jeg sige, at kameraerne efter ONVIF -standarden gjorde centraliseret klargøring lettere. Dette giver en standardgrænseflade, hvad der kan bruges til at sende kommandoer til kameraet for at indstille IP/netværksmaske/gateway og andre ting. Til dette kunne du downloade Onvif enhedsadministrator fra Sourceforge. Mange af disse enheder leveres med skæve ødelagte webfrontends, hvor det f.eks. Ikke tillader dig at indstille ip eller netmaske korrekt, fordi javascriptet, der validerer disse felter, fungerer ikke, og din eneste måde at indstille disse parametre korrekt er via ONVIF.

Trin 2: Planer om Death Star

Du kan bygge denne enhed med en hvilken som helst af de Raspberry PI'er, der starter fra 1 til 3B+. Selv nullen har kameraporte, men da der er så mange forskellige brugte raspier på markedet, undrer du dig måske over, hvilken der er den mest ideelle til denne build.

Svaret afhænger af, hvor du vil behandle videostrømmen.

Der er to valgmuligheder:

1, Behandl videoerne lokalt med bevægelse, og videresend en videostrøm, når der registreres bevægelse (bemærk: bevægelse sender en langsom konstant strøm til serveren, uanset hvad, dette kan afhænge af den opløsning og billedhastigheder, du bruger fra et par hundrede megabyte til flere gigabyte om dagen, bare en påmindelse, hvis du vil foretage en opsætning på en afmålt forbindelse). Her er CPU'en vigtig, og desværre drager bevægelse (i skrivende stund) ikke fordel af flere kerner, men operativsystemet vil forsøge at afbalancere belastningen lidt. Du vil altid have en af kernerne ved 100% brug.

2, Behandl videoerne på en central server: her videresender du bare den rå videostream fra kameraet til en ekstern streaming -server (som iSpy, der kører på en x86 -computer eller MotionEyeOS, der kører på en anden dedikeret minicomputer). Da der ikke er nogen lokal behandling, betyder den PI -model, du bruger, ikke noget, en PI1 sender den samme strøm som en PI3B+.

I denne tutorial vil jeg gå med det første valg.

Tommelfingerreglen her er, at jo hurtigere CPU du kaster i bevægelse, jo bedre resultater får du. For eksempel tog mit Raspi 2 -baserede kamera, der kiggede på en korridor, nogle gange ikke det, når nogen gik hurtigt, og da det optog optagelsen var træg, og faldt en masse billeder i forhold til modellen 3. Model 3 har også 802.11 abgn wifi, hvilket er praktisk for at kunne streame video i højere kvalitet, det fungerer ud af boksen, og det er ret pålideligt. I skrivende stund, at modellen 3B+ er ude, vil jeg bare anbefale, at du får den med 1,4 Ghz Quad Core cpu.

Liste over materialer

• 30 cm plast DeathStar:)
• Raspberry 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 Bevægelsessensormodul
• 1x 10kohm modstand til LDR
• 1x LDR
• 1x12V 4A DC adapter
• 1xWarm White LED 5050 SMD Fleksibel lyslampestrimmel 12V DC
• 1xBuck spændingsregulator

Som du kan se det på skemaerne, var dette projekt oprindeligt designet til at styre et enkelt lys med et relæ, fordi jeg ikke havde tænkt mig at tilføje intern belysning (hvilket er ret sejt), så jeg har lige tilsluttet et andet relæ til Arduino. Det gode ved SIP-1A05 er, at den har en intern flyback-diode, og forbruget i mA ligger langt under Arduino's per pin-effektbegrænsning.

Grunden til, at PIR er på skjoldet på billederne, fordi S0P i begyndelsen var planlagt til at blive lagt i en simpel IP -plastkasse i stedet for en DeathStar. Som du måske har gættet, er kameraet direkte i laserpistolen, og PIR og LDR havde brug for endnu et borede huller, og de limes, da jeg ikke planlægger at fjerne dem.

Der blev boret et hul i bunden af DeathStar, hvor jeg limede en stor bolt med en stærk 2 -komponent lim. Dette kan skrues ind i det originale Neo Coolcams stativ (det var trods alt godt til noget:)). For en ekstra støtte bruger jeg hårde kobbertråde til at have fat i toppen af stjernen.

Vigtig bemærkning om strømforsyningen: da den samme forsyning vil drive både PI, Arduino og LED -strimlen, skal den være fed nok til at kunne håndtere dem alle, så den vil være baseret på den LED -strimmel, du vælger til projektet. En kommerciel 5050 12v 3meter LED -strip dræner omkring 2A, det er meget. For PI og Arduino skal du beregne i +2A (selvom dette er for stort, gør det ikke ondt). Brug af LED -strip over standard halogenpærer, neon eller anden højeffektbelysning er, at du kan sætte hele dette kredsløb på et dejligt 12V@10Ah blybatteri som backup, så det endda vil fungere i tilfælde af strømafbrydelse.

Buck vil sænke spændingen fra 12-> 5V til strømforsyning af Arduino og PI, mens den direkte 12V feed er forbundet til relæet for at tænde LED-strimlen.

Trin 3: Software Arduino

Du kan finde den fulde kildekode herunder, som er godt kommenteret, men her er en kort forklaring på, hvordan det fungerer: I begyndelsen af hver sløjfe kaldes den sædvanlige xcomm () -funktion for at se, om der kommer en kommando fra Raspberry PI, som kan være LIGHT_ON/OFF for at tænde for korridorlysene eller DS_ON/OFF for at tænde/deaktivere DeathStar -baggrundsbelysningen, jeg har implementeret disse kun for over perfektion, da hvis nogen passerer PIR skulle tage det op og tænde lysene, men måske vil du se på stedet af en eller anden grund, selv når ingen er der.

Herefter læses fotocelleværdien ind, og bevægelsestappen kontrolleres for bevægelse. Hvis der er bevægelse, kontrollerer koden, om den er mørk nok, så kontrollerer den, om vi ikke er i venteposition. Hvis alt dette passerer, tænder det ganske enkelt korridorlyset og sender PHOENIX_MOTION_DETECTED tilbage til Raspberry PI, hvis det ikke er mørkt nok, signalerer det stadig tilbage til computeren, men tænder ikke lyset. Når en bevægelse er registreret, startes en 5 minutters hold -timer.

Lige efter dette vil den næste kodesektion kontrollere, om vi er i venteposition (hvilket burde være tilfældet, hvis der kun var en bevægelsesbegivenhed, så lad os antage, at de 5 minutter er gået, så denne kontrol kan bekræfte). Koden kontrollerer, om der er bevægelse igen, hvis ikke, sluk derefter lyset. Som du kan se, hvis der ikke er nogen bevægelse, vil denne funktion gentage sig igen og igen ved at prøve at slukke lyset, så der ikke er nogen feedback til pc'en.

Vi har en anden hold -timer til DeathStars interne belysning, som udelukkende afhænger af fotocelllæsning <dark_limit.

Selvom de 2 rutiner ikke kender til hinanden, vil de fungere perfekt sammen, da når korridorlyset tændes, giver det så meget lys, at LDR vil tro, at det er dagtid igen, og det slukker for den interne belysning. Der var dog nogle forbehold om denne proces, som er forklaret i koden, hvis du er interesseret, hvis ikke, så tag Nvidia -svaret om, at "det bare virker!".

Trin 4: Software Raspberry PI

Den nyeste Raspbian virker for mig:

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, der understøtter bevægelsesdetektering

Selvom du kan bruge andre distroer, får du kun support fra teamet, hvis du bruger deres officielle operativsystem, hvis du støder på problemer med kameraet. Fjernelse af uønsket bloatware som systemd anbefales også på det kraftigste.

Bevægelse kan også let bygges fra kilden:

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 videooptager/samler server. Desværre er der i skrivende stund ingen gode alternativer til Linux. Kameraet kan tilføjes med en MJPEG -url https:// CAMERA_IP: 8081 standardporten.

Bevægelsesbehandlingen kan være nyttig, for eksempel behøver du ikke at blive ved med at kigge på din iSpy -server hele dagen lang, du kan modtage en e -mail i tilfælde af bevægelse. Selvom iSpy har denne funktionalitet til at advare i e -mail i tilfælde af bevægelse, aktiverer den optagelse en gang imellem for diverse hændelser, som noget lys reflekteres til området. Med PIR -bevægelsesdetektering havde jeg aldrig en eneste falsk alarm. Advarslerne kan behandles lokalt:

Pir motion -hændelse registreret på sensor> Arduino -advarsel> Raspberry pi modtager på konsol> C -behandlingsprogram> Ekstern postprogram

Jeg foretrækker imidlertid at behandle både logfiler og videoer eksternt, så i dette tilfælde har jeg tilføjet et afsnit til C -kontrolprogrammet til, mens det logger logfilerne lokalt i en ren tekstfil, logger det også til syslog, og det videresendes til et SIEM for videre behandling.

tomrumslogger (tegn *tekst) {

FIL *f = fopen ("phoenix.log", "a"); hvis (f == NULL) {printf ("Fejl ved åbning af logfil! / n"); Vend tilbage; } 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 af bruger %d", getuid ()); syslog (LOG_NOTICE, loggy); closelog (); #endif return; }

På den modtagende ende kan syslog-ng demux disse hændelser fra hovedlogstrømmen:

filtrer f_phx {

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

og det kan sendes til et andet værktøj (motion.php se vedhæftet) til analyse og advarsel.

I dette script kan du ganske enkelt indstille den sædvanlige tid i løbet af ugen, når du ikke er hjemme:

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

PHP -programmet bruger det fremragende logtail -værktøj til at analysere logfilerne.

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

Logtail sporer positionen i en offset -fil, så hovedprogrammet ikke behøver at vide, fra hvilket tidspunkt man skal begynde at kigge på logfilerne på, det vil blive forsynet med de nyeste ubehandlede data.

Motion.php kan køres fra crontab med et lille trick i weekenderne, når det vil gå gennem logs, men ikke foretage yderligere behandling.

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

Trin 5: Problemer og opgaveliste

Hvis du bruger Raspberry pi 3 eller nyere, kan du springe dette afsnit over, du vil sandsynligvis ikke støde på disse problemer længere.

I løbet af årene havde jeg nogle problemer med Raspberry pi 2 -baserede tavler, hvad der kunne køre den samme softwarestak, men blev købt på forskellige tidspunkter fra forskellige steder. Efter en vis periode, der kunne være 2 dage eller 20 dage, hvor SSHing på enheden, SSH bare ville hænge, så både bevægelsesdæmonen og den lokale C -kode, der talte til Arduino, blev indlæst i ram, derfor fungerede enheden men det var umuligt at gøre noget andet med det længere i denne tilstand.

Efter en masse fejlfinding er jeg kommet frem til 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 # Beskrivelse: Home synchronizer af NLD ### END INIT INFO NAME = home DESC = "Ramdisk Home Synchronizer" RAM = "/home/" DISK = "/realhome/" set -e case "$ 1" i start | frem) echo -n "Start $ DESC: "rsync -az --numeric -ids --delete $ DISK $ RAM &> /dev /null echo" $ NAME. ";; stop | tilbage) echo -n "Stop $ DESC:" rsync -az --numeric -ids --delete $ RAM $ DISK &> /dev /null echo "$ NAME.";; *) ekko "Brug: $ 0 {start | stop}" exit 1;; esac exit 0

Scriptet går sammen med en fstab -ændring:

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

Hjemmepartitionen er monteret som ramdisk, hvilket ville give cirka 600 MB ledig plads på Raspberry pi 2, hvilket er mere end nok til at gemme nogle binære filer og små logfiler:

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

Det viste sig, at PI -hængningen blev tilskrevet skriveoperationer på SD -kortet, selvom jeg har prøvet forskellige kort (Samsung EVO, Sandisk), som blev scannet for fejl flere gange før og efter, og de ikke havde noget problem i andre bærbare computere, dette var bare kommer op. Jeg havde ikke det samme problem (endnu) med Raspberry PI 3'er og højere hardware, så det er også derfor, jeg anbefaler dem i denne vejledning.

Selvom den aktuelle bevægelse på en Raspberry PI 3 bare er god nok for mig, er der her nogle ideer, der er værd at undersøge:

1. Brug ikke bevægelse, men brug en raspivid strøm over netværket, og lad en kraftfuld server udføre bevægelsesdetektering og videokodning (f.eks. ISpy). -> Problem: konstant netværk båndbredde hogging.
2. Brug bevægelse og lad ffmpeg lave videokodningen. -> Problem: CPU kan ikke klare de højere opløsninger
3. Brug bevægelse, optag rå video, og lad en kraftfuld server udføre kodningen. -> CPU -brug på RPi er lav, og netværksbåndbredde er begrænset til, når der er faktisk bevægelse. I dette scenario kunne vi skrive til et SD-kort/ramdisk for maksimal gennemløb og derefter kopiere videoen til en anden server.

Jeg vil også bemærke, at det er muligt at bygge dette projekt uden en Arduino. Alle komponenter (relæer, LDR, PIR) kunne tilsluttes hindbær pi på en eller anden måde, men jeg foretrækker mikrokontroller i realtid til at interagere med sensorer og outputenheder. I de tilfælde, hvor min hindbærpi f.eks. Hængte eller styrtede ned, fungerede lysstyringen fra Arduino fint.

Hvis du kunne lide dette instruerbare, blev der fulgt med, da jeg vil fortsætte serien med mit 360 graders udendørs hindbær pi zero dome kamera næste år.