Raspberry PI -kamera och ljusstyrning Death Star: 5 steg (med bilder)

2024 Författare: John Day | [email protected]. Senast ändrad: 2024-01-30 12:45

Som alltid vill jag bygga enheter som är användbara, fungerar robust och ofta är till och med förbättringar jämfört med de nuvarande lösningarna.

Här är ännu ett bra projekt, som ursprungligen hette Shadow 0f Phoenix, en Raspberry PI -sköld i kombination med Arduino -baserad rörelsedetektering och ljuskontroller.

Steg 1: Status för kommersiella IP -kameror

Förutom att bygga din egen kamera/övervakningssystem är mer coolt låt oss se varför är detta en förbättring från en hylla lösning.

Jag kommer att jämföra det med NEO COOLCAM Full HD 1080P Wireless IP Camera -serien eftersom jag har ägt många av dessa olika modeller av neo coolcams (ONVIF) kameror. De finns i olika former och storlekar, utomhus och inomhus, de flesta av dem har inbyggt wifi -stöd men låt oss se deras varningar:

• Kinesiska tillverkare som säljer dessa kameror ljuger nästan alltid om den inbyggda bildsensorupplösningen, när du köper en 5MP/8MP kamera på Ebay kan du sluta med en billig 2MP kamera med dålig bild (det fungerar men kvaliteten är skräp). När du köper 8MP Raspberry PI v2 -kameran från den ursprungliga återförsäljaren får du vad du betalat för och den faktiska 8MP -sensorn med upplösningen 3280 × 2464 pixlar =>
• Ur säkerhetssynpunkt är dessa kameror (även den dyrare Dlink och andra modeller) fruktansvärda, de använder standardlösenord som 123456 eller inbyggda användare som admin/admin operatör/operatör vad du kanske inte ens kommer att kunna ändra eller ändringen är borta efter en omstart. Komplettera med många av dessa kameror och ring hem. Hem). Även om du lägger dessa enheter bakom en router är det bara inte tillräckligt bra, det bästa är om du inte ställer in en standardgateway i dem, brandväggar dem eller sätter dem i ett VLAN för att göra det omöjligt för dem att gå ut till Internet eller ännu bättre: använd dem inte alls.
• Är de mer pålitliga? nej, många av dem, även de dyrare DLINK -enheterna, har möjlighet att starta om kameran dagligen/veckovis etc. Det alternativet finns av en anledning, för efter X dagar förlorar de ofta Wifi -anslutning eller uppför sig illa på andra sätt. Tänk bara på dem som gamla gamla Win95 -lådor som behövde startas om oftare än inte:) Jag säger inte att den Raspi -baserade hårdvaran är så stenhård att du kan bygga in dem i kontrollerade kärnkraftverk men med rätt hårdvara/mjukvara konfiguration, kylflänsar, automatiska kylfläktar och minimerad RW -drift på SDCARD kan de enkelt nå 100+ dagars drifttid utan problem. När jag skrev mina DeathStar -körningar sedan 34 dagar, varit över 100 men ibland hackade jag på flödet i strömkällan som driver några andra av mina kretsar så jag fick stänga av det:(
• Riktad hårdvara: de är gjorda för 1 specifikt ändamål, kommer ofta med ett litet nvram -område och upptagen box, men vissa modeller gör det också omöjligt att komma åt detta skal så allt du kan använda dem till är vad de menade att användas för medan du kan använd din Raspi -baserade kamera till alla andra uppgifter: filserver, tftp/dhcp -server, webbserver, quake -server … alternativen är obegränsade.
• Lagringsutrymme: de har antingen inga eller så använder de microsd -kort med FAT32 -filsystem VS på hallonpis, du kan till och med ansluta en 2 TB hårddisk om du vill.
• Kontrollampor: vissa har en ALARM -utgång där du kanske kan ansluta ett litet relä för att få lampor att aktiveras. Som jag kommer att visa dig i denna handledning är användning av infraröda kameror helt slöseri med tid eftersom du inte kommer att kunna identifiera någon på IR -bilderna på grund av den dåliga kvaliteten. Om du behöver spela in en video i mörkret är det bästa sättet att tända lite ljus först och sedan spela in videon.

Så du kanske frågar om det finns några proffs för att använda en hyllkamera? Ja för företag där arbetstiden för att ställa in det skulle vara dyrare än att pyssla med hallonpis (inte för mig i alla fall:)) och ja det finns toppkameror (500 $+ med bättre upplösning än pi -kameran på kurs). Som en annan fördel kan jag säga att kamerorna som följer ONVIF -standarden underlättade centraliserad administration. Detta ger ett standardgränssnitt vad som kan användas för att skicka kommandon till kameran för att ställa in dess IP/nätverksmask/gateway och andra saker. För detta kan du ladda ner Onvif -enhetshanteraren från Sourceforge. Många av dessa enheter har skitbrutna webbgränser där det till exempel inte tillåter dig att ställa in ip eller nätmask korrekt eftersom javascriptet som validerar dessa fält fungerar inte och ditt enda sätt att ställa in dessa parametrar korrekt är via ONVIF.

Steg 2: Planer om Death Star

Du kan bygga denna enhet med vilken som helst av Raspberry PI från 1 till 3B+. Även nollan har kameraporter, men eftersom det finns så många olika begagnade raspis på marknaden kanske du undrar vilken som är den mest idealiska för den här byggnaden.

Svaret beror på var du vill bearbeta videoströmmen.

Det finns två val:

1, Bearbeta videoklippen lokalt med rörelse och vidarebefordra en videoström när det upptäcks rörelse (observera: rörelse vidarebefordrar en långsam konstant ström till servern oavsett vad, detta kan bero på upplösningen och bildhastigheterna du använder från några hundra megabyte till flera gigabyte om dagen, bara en påminnelse om du vill göra en installation på en uppmätt anslutning). Här spelar CPU: n tyvärr inte rörelse (i skrivande stund) fördel av flera kärnor, men operativsystemet kommer att försöka balansera belastningen något. Du kommer alltid att ha en av kärnorna vid 100% användning.

2, Bearbeta videoklippen på en central server: här vidarebefordrar du bara den råa videoströmmen från kameran till en extern strömningsserver (som iSpy som körs på en x86 -dator eller MotionEyeOS som körs på en annan dedikerad minidator). Eftersom det inte finns någon lokal bearbetning spelar PI -modellen du spelar ingen roll, en PI1 skickar samma ström som en PI3B+.

I denna handledning kommer jag att gå med det första valet.

Tumregeln här är att ju snabbare CPU du kastar i rörelse desto bättre resultat får du. Till exempel min Raspi 2 -baserade kamera som tittade på en korridor tog ibland inte upp den när någon åkte förbi snabbt och när den spelade in var inspelningen trög och tappade många bilder jämfört med modellen 3. Modellen 3 har också 802.11 abgn wifi som är praktiskt för att kunna strömma video av högre kvalitet, det fungerar ur lådan och det är ganska pålitligt. I skrivande stund att modellen 3B+ är ute skulle jag bara rekommendera att du får den med 1,4 Ghz Quad Core cpu.

Materialförteckning

• 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-rörelsessensormodul
• 1x 10kohm motstånd för LDR
• 1x LDR
• 1x12V 4A DC -adapter
• 1xWarm White LED 5050 SMD Flexibel Light Lamp Strip 12V DC
• 1xBuck spänningsregulator

Som du kan se på schemat var detta projekt ursprungligen utformat för att styra ett enda ljus med ett relä eftersom jag inte hade tänkt lägga till intern belysning (vilket är ganska coolt) så jag kopplade bara ett andra relä till Arduino. Det fina med SIP-1A05 är att den har en intern flyback-diod och förbrukningen i mA ligger långt under Arduinos effekt per stift.

Anledningen till att PIR är på skärmen på bilderna eftersom S0P i början var planerat att läggas i en enkel IP -plastlåda istället för en DeathStar. Som du kanske gissar är kameran direkt i laserpistolen, PIR och LDR behövde ytterligare ett borrade hål och de är limskyddade eftersom jag inte planerar att ta bort dem.

Ett hål borrades längst ner på DeathStar där jag limmade i en stor bult med ett starkt 2 -komponentlim. Detta kan skruvas in i det ursprungliga Neo Coolcams -stativet (det var bra för något trots allt:)). För ett extra stöd använder jag hårda koppartrådar för att hålla fast på toppen av stjärnan.

Viktig anmärkning om strömförsörjningen: eftersom samma strömförsörjning kommer att driva både PI, Arduino och LED -remsan måste den vara biffig nog för att kunna hantera dem alla så den kommer att baseras på den LED -remsa du väljer för projektet. En kommersiell 5050 12v 3meter LED -remsa dränerar runt 2A, det är mycket. För PI och Arduino måste du beräkna i +2A (även om detta är för stort kommer det inte att skada). Att använda LED -remsa över vanliga halogenlampor, neon eller annan högeffektbelysning är att du kan lägga hela kretsen på ett fint 12V@10Ah blybatteri som backup så att det till och med fungerar vid strömavbrott.

Bocken kommer att minska spänningen från 12-> 5V för att driva Arduino och PI medan den direkta 12V-matningen är kopplad på reläet för att slå på LED-remsan.

Steg 3: Programvara Arduino

Du kan hitta hela källkoden nedan som är välkommenterad men här är en kort förklaring hur det fungerar: I början av varje loop kallas den vanliga xcomm () -funktionen för att se om det finns ett kommando från Raspberry PI som kan vara LIGHT_ON/OFF för att slå på korridorslampor eller DS_ON/OFF för att slå på/av DeathStar -bakgrundsbelysningen, jag har implementerat dessa bara för över perfektion eftersom om någon passerar PIR: en skulle hämta den och slå på lamporna men kanske vill du titta på platsen av någon anledning även när ingen är där.

Efter detta läste fotocellvärdet in och rörelsestiftet kontrolleras för rörelse. Om det finns rörelse kontrollerar koden om den är tillräckligt mörk så kontrollerar den om vi inte är i vänteläge. Om allt detta passerar tänds helt enkelt korridorsljuset och skickar tillbaka PHOENIX_MOTION_DETECTED till Raspberry PI, om det inte är tillräckligt mörkt signalerar det fortfarande tillbaka till datorn men tänder inte lampan. När en rörelse detekterats startas en 5 minuters väntetimer.

Strax efter detta kommer nästa kodavsnitt att kontrollera om vi är i vänteläge (vilket borde vara fallet om det bara var en rörelsehändelse, så låt oss anta att de fem minuter som gått så den här kontrollen kan bekräfta). Koden kontrollerar om det finns rörelse igen, om inte, släck sedan lamporna. Som du kan se om det inte finns någon rörelse kommer den här funktionen att upprepa sig om och om igen, försök att släcka lamporna så att det inte finns någon feedback till datorn.

Vi har en annan hålltimer för DeathStars interna belysning som enbart beror på fotocellläsning <dark_limit.

Även om de två rutinerna inte känner till varandra, kommer de att fungera perfekt tillsammans, eftersom när korridorljuset tänds ger det så mycket ljus att LDR kommer att tro att det är dagtid igen och det stänger av den inre belysningen. Det fanns dock några varningar om denna process som förklaras i koden om du är intresserad, om inte så ta Nvidia -svaret att "det bara fungerar!".

Steg 4: Programvara Raspberry PI

Den senaste Raspbian fungerar för 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 som stöder rörelsedetektering

Även om du kan använda andra distros, om du stöter på problem med kameran får du bara support från teamet om du använder deras officiella operativsystem. Att ta bort oönskade bloatware som systemd rekommenderas också starkt.

Rörelse kan också enkelt byggas från källan:

apt-get -y installera 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 installera libavformat-dev libavcodec-dev libavutil-dev libswscale-dev libavdevice-dev apt-get -y installera 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

Jag rekommenderar iSpy som videoinspelare/samlarserver. Tyvärr finns det i skrivande stund inga bra alternativ för Linux. Kameran kan läggas till med en MJPEG -URL https:// CAMERA_IP: 8081 standardporten.

Rörelsebearbetningen kan vara användbar, till exempel behöver du inte fortsätta titta på din iSpy -server hela dagen, du kan få ett e -postmeddelande vid rörelse. Även om iSpy har den här funktionen för att varna i e -post vid rörelse, aktiverar den inspelning då och då för diverse händelser som att lite ljus reflekteras till området. Med PIR -rörelsedetektering hade jag aldrig ett enda falsklarm. Varningarna kan bearbetas lokalt:

Pir motion -händelse upptäckt på sensor> Arduino -varning> Raspberry pi tar emot på konsolen> C -bearbetningsprogram> Externt postprogram

Jag föredrar dock att bearbeta både loggar och videor på distans så i det här fallet har jag lagt till en sektion i C -kontrollprogrammet till medan det loggar loggarna lokalt i en vanlig textfil, loggar det också till syslog och som vidarebefordras till ett SIEM för ytterligare bearbetning.

void logger (char *text) {

FIL *f = fopen ("phoenix.log", "a"); if (f == NULL) {printf ("Fel vid öppning av loggfil! / n"); lämna tillbaka; } 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, "Program startat av användare %d", getuid ()); syslog (LOG_NOTICE, loggy); closelog (); #endif retur; }

På mottagaränden kan syslog-ng demux dessa händelser från huvudloggströmmen:

filtrera f_phx {

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

och den kan skickas till ett annat verktyg (motion.php se bifogad) för analys och varning.

I detta manus kan du helt enkelt ställa in den vanliga tiden under veckan när du inte är hemma:

$ opt ['alert_after'] = '09:00:00'; // Morgnar $ opt ['alert_before'] = '17:00:00'; // Kvällar

PHP -programmet använder det utmärkta logtail -verktyget för att analysera loggarna.

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

Logtail spårar positionen i en offset -fil så att huvudprogrammet inte behöver veta om från vilken tid man ska börja titta på loggarna, det kommer att förses med de senaste obearbetade data.

Motion.php kan köras från crontab med ett litet trick för helgerna, när det kommer att gå igenom loggarna, men gör ingen vidare bearbetning.

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

Steg 5: Problem och att göra -lista

Om du använder Raspberry pi 3 eller nyare kan du hoppa över det här avsnittet, du kommer sannolikt inte att stöta på dessa problem längre.

Under åren hade jag några problem med Raspberry pi 2 -baserade kort som kunde köra samma programvarustack men köptes vid olika tidpunkter från olika platser. Efter en viss tid som kan vara 2 dagar eller 20 dagar när SSHing in på enheten skulle SSH bara hänga, så både rörelsedemon och lokal C -kod som talade med Arduino laddades upp i ram därför fungerade enheten men det var omöjligt att göra något annat med det längre i detta tillstånd.

Efter mycket felsökning har jag kommit fram till en lösning:

homesync.sh

#!/bin/sh -e

### BEGIN INIT INFO # Ger: homesync # Required-Start: mountkernfs $ local_fs # Required-Stop: camera phoenix # Standard-Start: S # Standard-Stop: 0 6 # Short-Description: Home synchronizer # Beskrivning: Hemsynkroniserare av NLD ### END INIT INFO NAME = home DESC = "Ramdisk Home Synchronizer" RAM = "/home/" DISK = "/realhome/" set -e case "$ 1" i start | fram) echo -n "Startar $ DESC: "rsync -az --numeric -ids --delete $ DISK $ RAM &> /dev /null echo" $ NAME. ";; stop | back) echo -n "Stoppar $ DESC:" rsync -az --numeric -ids --delete $ RAM $ DISK &> /dev /null echo "$ NAME.";; *) eko "Användning: $ 0 {start | stop}" avsluta 1;; esac exit 0

Skriptet går tillsammans med en fstab -modifiering:

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

Hemmapartitionen är monterad som ramdisk vilket skulle ge cirka 600 MB ledigt utrymme på Raspberry pi 2 vilket är mer än tillräckligt för att lagra några binärer och små loggfiler:

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

Det visade sig att PI -hängningen hänfördes till skrivoperationerna på SD -kortet, även om jag har provat olika kort (Samsung EVO, Sandisk) som skannades efter fel flera gånger före och efter och de hade inga problem i andra bärbara datorer var detta bara kommer upp. Jag hade inte samma problem (ännu) med Raspberry PI 3s och högre hårdvara så det är också därför jag rekommenderar dem i den här självstudien.

Även om den aktuella rörelsen på en Raspberry PI 3 bara är tillräckligt bra för mig, här är några idéer som är värda att utforska:

1. Använd inte rörelse, utan använd en raspivid ström över nätverket och låt en kraftfull server göra rörelsedetektering och videokodning (t.ex. iSpy). -> Problem: konstant nätverksbandbredd.
2. Använd rörelse och låt ffmpeg göra videokodningen. -> Problem: CPU klarar inte de högre upplösningarna
3. Använd rörelse, spela in rå video och låt en kraftfull server göra kodningen. -> CPU -användningen på RPi är låg och nätverksbandbredden är begränsad till när det finns verklig rörelse. För detta scenario kan vi skriva till ett SD-kort/ramdisk för maximal genomströmning och sedan kopiera videon till en annan server.

Jag vill också notera att byggandet av detta projekt är möjligt att bygga utan en Arduino. Alla komponenter (reläer, LDR, PIR) skulle kunna anslutas till hallon pi på något sätt men jag föredrar realtid mikrokontroller för att interagera med sensorer och utmatningsenheter. I de fall där min hallonpi hängde till exempel eller kraschade fungerade ljuskontrollen som kördes av Arduino alldeles utmärkt.

Om du gillade den här instruerbara stannade jag, eftersom jag kommer att fortsätta serien med min 360 graders utomhus hallon pi zero dome kamera nästa år.