Raspberry PI Camera and Light Control Death Star: 5 hapa (me fotografi)

2024 Autor: John Day | [email protected]. E modifikuara e fundit: 2024-01-30 12:24

Si gjithmonë, unë kërkoj të ndërtoj pajisje që janë të dobishme, punojnë fuqishëm dhe shpesh janë madje përmirësime në krahasim me zgjidhjet aktuale të raftit.

Këtu është një projekt tjetër i mrekullueshëm, i quajtur fillimisht Shadow 0f Phoenix, një mburojë Raspberry PI në lidhje me zbulimin e lëvizjes dhe kontrollet e dritës bazuar në Arduino.

Hapi 1: Gjendja e Kamerave IP Tregtare

Përveç kësaj, ndërtimi i sistemit tuaj të kamerës/vëzhgimit është më i mirë, le të shohim pse është kjo një përmirësim nga një zgjidhje jashtë raftit.

Unë do ta krahasoj atë me serinë NEO COOLCAM Full HD 1080P Wireless IP Camera pasi kam në pronësi shumë nga këto modele të ndryshme të kamerave neo coolcams (ONVIF). Ato vijnë në forma dhe madhësi të ndryshme, jashtë dhe brenda, shumica prej tyre kanë ndërtuar mbështetje wifi, por le të shohim paralajmërimet e tyre:

• Prodhuesit kinezë që shesin këto kamera pothuajse gjithmonë gënjejnë për rezolucionin e sensorit të imazhit të integruar, kur blini një aparat 5MP/8MP në Ebay mund të përfundoni me një aparat të lirë 2MP me fotografi të keqe (funksionon por cilësia është mbeturina). Kur blini kamerën 8MP Raspberry PI v2 nga shitësi origjinal, do të merrni atë për të cilën keni paguar dhe sensorin aktual 8MP me rezolucion 3280 × 2464 piksele =>
• Nga pikëpamja e sigurisë, këto kamera (edhe Dlink më të shtrenjta dhe modele të tjera) janë të tmerrshme, ato përdorin fjalëkalime të paracaktuara si 123456 ose të integruara në përdorues të tillë si administratori/operatori administratori/operatori atë që ju as nuk do të jeni në gjendje të ndryshoni ose ndryshimi është zhdukur pas një rindezje. Përfundojeni me shumë nga këto aparate telefoni në shtëpi (lidheni me serverët e tyre në Kinë, disa transmetojnë video/fotografi pa ju kërkuar vetëm për ta bërë më të lehtë në rast se vendosni të instaloni aplikacionin e tyre Android/Iphone një ditë për të kontrolluar pajisjen tuaj shtëpi). Edhe nëse i vendosni këto pajisje pas një ruteri, thjesht nuk është mjaft mirë, më e mira është nëse nuk vendosni një portë të paracaktuar në to, i fikni ose i vendosni në një VLAN për ta bërë të pamundur që ata të dalin internet ose edhe më mirë: mos i përdorni fare.
• A janë ata më të besueshëm? jo, shumë prej tyre edhe DLINK -të më të shtrenjta kanë mundësinë të rindizin kamerën çdo ditë/javë, etj. Ky opsion ekziston për një arsye, sepse pas ditëve X ata shpesh humbasin lidhjen Wifi ose sillen keq në mënyra të tjera. Thjesht mendojini ato si kuti të vjetra të mira Win95 të cilat duhej të rindizeshin më shpesh sesa jo:) Unë nuk them që pajisjet e bazuara në Raspi janë aq të forta sa ju mund t'i ndërtoni ato në kontrollin e centraleve bërthamore, por me pajisjet/softuerin e duhur konfigurimi, ngrohësit e nxehtësisë, ventilatorët automatikë të ftohjes dhe funksionimi i minimizuar i RW në SDCARD ata lehtë mund të godasin atë 100+ ditë në kohë pa problem. Në kohën e shkrimit të DeathStar funksionon që prej 34 ditësh, ka qenë mbi 100, por nganjëherë po hakoja ushqimin në burimin e energjisë i cili po fuqizon disa nga qarqet e mia, kështu që duhej ta mbyllja atë:(
• Pajisjet kompjuterike të synuara: ato janë bërë për 1 qëllim specifik, shpesh vijnë me një zonë të vogël nvram dhe kuti të zënë, por disa modele e bëjnë të pamundur edhe qasjen në këtë guaskë, kështu që gjithçka për të cilën mund t'i përdorni është ajo për të cilën ata kanë për qëllim të përdoren përderisa ju mundeni përdorni kamerën tuaj të bazuar në Raspi për çfarëdo detyre tjetër: serveri i skedarëve, serveri tftp/dhcp, serveri në internet, serveri i tërmetit … opsionet janë të pakufizuara.
• Hapësira e ruajtjes: ata ose nuk kanë asnjë ose përdorin karta microsd me sistemin e skedarëve FAT32 VS në pis të mjedrës, madje mund të bashkëngjitni një hard disk 2 TB nëse dëshironi.
• Kontrolli i dritave: disa kanë një dalje ALARM ku mund të jeni në gjendje të lidhni një stafetë të vogël për të ndezur dritat. Siç do t'ju tregoj në këtë tutorial, përdorimi i kamerave infra të kuqe është humbje e plotë e kohës pasi nuk do të jeni në gjendje të identifikoni askënd në fotografitë IR për shkak të cilësisë së keqe. Nëse keni nevojë të regjistroni një video në errësirë, mënyra më e mirë për ta bërë këtë është të ndizni dritën së pari, pastaj regjistroni videon.

Pra, ju mund të pyesni a ka ndonjë PRO të përdorimit të një kamere jashtë raftit? Po për bizneset ku orët e punës për ta vendosur atë do të ishin më të shtrenjta sesa të punosh me Raspberry pis (jo për mua gjithsesi:)) dhe po ka kamerat kryesore të linjës (500 $+ me rezolucion më të mirë se kamera pi e kurs). Si një avantazh tjetër mund të them se kamerat që ndjekin standardin ONVIF e bënë furnizimin e centralizuar më të lehtë. Kjo siguron një ndërfaqe standarde se çfarë mund të përdoret për të dërguar komanda në kamerë për të vendosur IP/maskën e rrjetit/Gateway dhe gjëra të tjera. Për këtë ju mund të shkarkoni menaxherin e pajisjes Onvif nga Sourceforge. Shumë nga këto pajisje vijnë me frontends të prishur të uebit, për shembull, nuk ju lejon të vendosni ip ose maskë në internet në mënyrë korrekte, sepse javascript që vërteton këto fusha nuk funksionon dhe mënyra juaj e vetme për t'i vendosur këto parametra në mënyrë korrekte është përmes ONVIF.

Hapi 2: Planet e Yllit të Vdekjes

Ju mund ta ndërtoni këtë pajisje me ndonjë nga PI -të e Mjedrës duke filluar nga 1 në 3B+. Edhe zeroja ka porte kamerash, por meqë ka kaq shumë raspis të ndryshëm të dorës së dytë në treg, mund të pyesni se cila është më ideale për këtë ndërtim.

Përgjigja varet nga vendi ku dëshironi të përpunoni transmetimin e videos.

Ka dy zgjedhje:

1, Përpunoni videot në vend me lëvizje dhe përcillni një transmetim video kur zbulohet lëvizje (shënim: lëvizja përcjell një rrjedhë të ngadaltë konstante në server pa marrë parasysh çfarë, kjo mund të jetë në varësi të rezolucionit dhe shkallës së kornizës që përdorni duke shkuar nga disa qindra megabajt në gigabajt të shumtë në ditë, vetëm një kujtesë nëse doni të bëni një konfigurim në një lidhje të matur). Këtu CPU ka rëndësi dhe për fat të keq lëvizja (në kohën e shkrimit) nuk përfiton nga bërthama të shumta, megjithatë OS do të përpiqet të balancojë ngarkesën pak. Ju gjithmonë do të keni një nga bërthamat në përdorim 100%.

2, Përpunoni videot në një server qendror: këtu ju thjesht përcillni transmetimin e papërpunuar të videove nga kamera në një ndarje të jashtme të transmetimit (si iSpy që funksionon në një kompjuter x86 ose MotionEyeOS që funksionon në një minikompjuter tjetër të dedikuar). Meqenëse nuk ka asnjë përpunim në vend, modeli i PI që përdorni nuk ka rëndësi, një PI1 do të dërgojë të njëjtën rrjedhë si një PI3B+.

Në këtë tutorial do të shkoj me zgjedhjen e parë.

Rregulli i përgjithshëm këtu është që sa më shpejt CPU të hidhni në lëvizje aq më shumë rezultate do të merrni. Për shembull kamera ime e bazuar në Raspi 2 duke parë një korridor ndonjëherë nuk e merrte kur dikush kalonte shpejt dhe kur po regjistronte regjistrimi ishte i ngadaltë, duke rënë shumë korniza në krahasim me modelin 3. Modeli 3 gjithashtu ka 802.11 abgn wifi i cili është i dobishëm për të qenë në gjendje të transmetoni video me cilësi më të lartë, funksionon jashtë kutisë dhe është mjaft i besueshëm. Në kohën e shkrimit që modeli 3B+ është jashtë, unë thjesht do t'ju rekomandoja që ta merrni atë me 1.4 Ghz Quad Core CPU.

Lista e materialeve

• 30 cm plastike DeathStar:)
• Raspberry Pi 3 B+
• PiCam v2 (8MP)
• Arduino Pro Micro 5.5v
• 2x Stafetë kalimi kallami SIP-1A05
• 1x PCS HC-SR501 IR Pirolelektrike Infra të kuqe IR PIR Motori Sensor Detektor Moduli
• Rezistencë 1x 10kohm për LDR
• 1x LDR
• Përshtatës DC 1x12V 4A
• 1xWarm White LED 5050 SMD Fleksibël Drita Rrip Llambë 12V DC
• 1xBug rregullator i tensionit

Siç mund ta shihni në skematik, ky projekt u krijua fillimisht për të kontrolluar një dritë të vetme me një stafetë, sepse nuk kam planifikuar të shtoj ndriçim të brendshëm (i cili është mjaft i ftohtë) kështu që unë thjesht lidhja një stafetë të dytë në Arduino. Gjëja e shkëlqyeshme për SIP-1A05 është se ka diodë të brendshme kthyese dhe konsumi në mA është nën kufizimin e fuqisë së Arduino për pin.

Arsyeja pse PIR është në mburojën në fotografi sepse në fillim S0P ishte planifikuar të vendoset në një kuti të thjeshtë plastike IP në vend të një DeathStar. Siç mund ta mendoni, kamera është drejtpërdrejt në armën lazer, PIR dhe LDR kishin nevojë për një vrimë tjetër të shpuar dhe ato janë të ngjitura me armë pasi nuk kam në plan t'i heq ato.

Një vrimë u shpua në fund të DeathStar ku u ngjita në një rrufe në qiell të madh me një zam të fortë 2 përbërës. Kjo mund të jetë e dehur në stendën origjinale të Neo Coolcams (ishte mirë për diçka në fund të fundit:)). Për një mbështetje shtesë, unë përdor tela bakri të fortë për të mbajtur në majë të yllit.

Shënim i rëndësishëm në lidhje me furnizimin me energji elektrike: meqenëse i njëjti furnizim do të fuqizojë si PI, Arduino dhe shiritin LED, duhet të jetë mjaft i fortë për të qenë në gjendje t'i trajtojë të gjitha, kështu që do të bazohet në shiritin LED që zgjidhni për projektin. Një shirit LED komercial 5050 12v 3metër kullon rreth 2A, kjo është shumë. Për PI dhe Arduino ju duhet të llogaritni në +2A (edhe pse kjo është e tepërt nuk do të dëmtojë). Përdorimi i shiritit LED mbi llamba standarde halogjene, neoni ose ndriçim tjetër me fuqi të lartë është që ju mund ta vendosni të gjithë këtë qark në një bateri të mirë të acidit prej plumbi 12V@10Ah si rezervë, kështu që do të funksionojë edhe në rast të ndërprerjes së energjisë.

Monedha do të ulë tensionin nga 12-> 5V për fuqizimin e Arduino dhe PI ndërsa ushqimi i drejtpërdrejtë 12V është i lidhur në stafetë për të ndezur shiritin LED.

Hapi 3: Softueri Arduino

Ju mund të gjeni kodin e plotë burimor poshtë i cili është komentuar mirë, por këtu është një shpjegim i shkurtër se si funksionon: Në fillim të secilit lak funksioni i zakonshëm xcomm () thirret për të parë nëse ka një komandë të ardhur nga Raspberry PI e cila mund të jetë LIGHT_ON/OFF për të ndezur dritat e korridorit ose DS_ON/OFF për të ndezur/fikur ndriçimin e DeathStar, unë i kam zbatuar këto vetëm për hir të përsosmërisë së tepërt pasi që nëse dikush kalon pranë PIR -it duhet ta marrë dhe ndezë dritat por ndoshta ju doni të shikoni vendin për ndonjë arsye edhe kur askush nuk është atje.

Pas kësaj vlera e fotocelës lexohet dhe kunja e lëvizjes kontrollohet për lëvizje. Nëse ka lëvizje, kodi kontrollon nëse është mjaft i errët, atëherë kontrollon nëse nuk jemi në pritje. Nëse e gjithë kjo kalon atëherë thjesht ndez dritën e korridorit dhe dërgon PHOENIX_MOTION_DETECTED në Raspberry PI, nëse nuk është mjaft e errët ai përsëri sinjalizon në kompjuter, por nuk e ndez dritën. Pasi zbulohet një lëvizje, fillon një kohëmatës 5 minutësh.

Menjëherë pas kësaj, pjesa tjetër e kodit do të kontrollojë për të parë nëse jemi në pritje (gjë që duhet të ndodhë nëse ka pasur vetëm një ngjarje lëvizjeje, kështu që le të supozojmë se kanë kaluar 5 minutat në mënyrë që ky kontroll të konfirmojë). Kodi kontrollon për të parë nëse ka lëvizje përsëri, nëse jo atëherë fikni dritat. Siç mund ta shihni nëse nuk ka lëvizje, ky funksion do të përsëritet vazhdimisht duke u përpjekur të fikni dritat në mënyrë që të mos ketë reagime në kompjuter.

Ne kemi një tjetër kohëmatës mbajtës për ndriçimin e brendshëm të DeathStar i cili varet thjesht nga leximi i fotocelës <dark_limit.

Edhe pse 2 rutinat nuk dinë për njëri -tjetrin, ata do të punojnë në mënyrë perfekte së bashku pasi që kur ndizet drita e korridorit siguron aq shumë dritë sa LDR do të mendojë se është përsëri ditë dhe fik dritën e brendshme. Sidoqoftë, kishte disa paralajmërime në lidhje me këtë proces i cili shpjegohet në kod nëse jeni të interesuar, nëse jo atëherë merrni përgjigjen e Nvidia se "thjesht funksionon!".

Hapi 4: Softueri i mjedrës PI

Punimet më të fundit Raspbian për mua:

Raspbian GNU/Linux 9.4 (shtrirje)

Linux Phoenix 4.9.35-v7+ #1014 SMP E Premte 30 Qershor 14:47:43 BST 2017 armv7l GNU/Linux ii motion 4.0-1 programi i kapjes së armhf V4L që mbështet zbulimin e lëvizjes

Ndërsa mund të përdorni shpërndarje të tjera, nëse hasni në ndonjë problem me kamerën, do të merrni mbështetje nga ekipi vetëm nëse përdorni OS -në e tyre zyrtare. Heqja e bloatware -it të padëshirueshëm siç është systemd është gjithashtu shumë e rekomandueshme.

Lëvizja gjithashtu mund të ndërtohet nga burimi lehtë:

apt-get -y install autoconf automake pkgconf libtool libjpeg8-dev build-thelbësor 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

Unë rekomandoj iSpy si regjistrues video/server kolektori. Fatkeqësisht në kohën e shkrimit nuk ka alternativa të mira për Linux. Kamera mund të shtohet me një url MJPEG https:// CAMERA_IP: 8081 porta e paracaktuar.

Përpunimi i lëvizjes mund të jetë i dobishëm, për shembull, nuk keni nevojë të shikoni serverin tuaj iSpy gjatë gjithë ditës, mund të merrni një email në rast lëvizjeje. Edhe pse iSpy ka këtë funksionalitet për të paralajmëruar në email në rast të lëvizjes, ai ndez regjistrimin herë pas here për ngjarje të ndryshme, siqë pak dritë reflektohet në zonë. Me zbulimin e lëvizjes PIR unë kurrë nuk kam pasur një alarm të vetëm të rremë. Sinjalizimet mund të përpunohen në vend:

Ngjarja e lëvizjes Pir u zbulua në sensorin> Alarmi Arduino> Raspberry pi merr në tastierë> Programi i përpunimit C> Aplikacioni i postës së jashtme

Sidoqoftë, unë preferoj të përpunoj regjistrat dhe videot nga distanca, kështu që në këtë rast kam shtuar një seksion në programin e kontrollit C, ndërsa ai i regjistron regjistrat në një skedar teksti të thjeshtë, gjithashtu i regjistron ato në syslog dhe që përcillet në një SIEM për përpunim i mëtejshëm.

void logger (char *text) {

DOSJA *f = hapet ("phoenix.log", "a"); if (f == NULL) {printf ("Gabim në hapjen e skedarit të regjistrit! / n"); kthim; } fprintf (f, " %s => %s / n", koha e_curimit (0), tekst); mbyll (f); #ifdef SYSLOG char loggy [500]; sprintf (loggy, " %s => %s / n", cur_time (0), tekst); maskë e vendosur (LOG_UPTO (LOG_NOTICE)); openlog ("DeathStar", LOG_CONS | LOG_PID | LOG_NDELAY, LOG_USER); // syslog (LOG_NOTICE, "Programi i filluar nga Përdoruesi %d", getuid ()); syslog (LOG_NOTICE, loggy); mbyllës (); #ndif kthimi; }

Në anën marrëse syslog-ng mund t'i demuxojë këto ngjarje nga rryma kryesore e regjistrit:

filtri f_phx {

ndeshje ("DeathStar"); }; destinacioni d_phx {file ("/var/log/phoenix/deathstar.log"); }; log {burimi (s_net); filtër (f_phx); destinacioni (d_phx); };

dhe mund t'i kalohet një mjeti tjetër (motion.php shih bashkangjitur) për analiza dhe paralajmërim.

Në këtë skenar ju thjesht mund të vendosni kohën e zakonshme gjatë javës kur nuk jeni në shtëpi:

$ opt ['alert_after'] = '09:00:00'; // Mëngjeset $ opt ['alert_before'] = '17:00:00'; // Mbrëmjet

Programi php përdor mjetin e shkëlqyer logtail për të analizuar regjistrat.

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

Logtail gjurmon pozicionin në një skedar të kompensuar, kështu që programi kryesor nuk duhet të dijë se nga cila kohë të filloni të shikoni regjistrat, do të pajiset me të dhënat më të fundit të papërpunuara.

Motion.php mund të ekzekutohet nga crontab me një truk të vogël për fundjavat, kur do të kalojë nëpër regjistra, por mos bëni asnjë përpunim të mëtejshëm.

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

Hapi 5: Çështjet dhe lista e veprimeve

Nëse jeni duke përdorur Raspberry pi 3 ose më të reja, mund ta kaloni këtë seksion, me shumë mundësi nuk do të hasni më në këto probleme.

Gjatë viteve unë kisha disa probleme me bordet e bazuara në Raspberry pi 2, të cilat mund të funksiononin me të njëjtin grup softuerësh, por që ishin blerë në kohë të ndryshme nga vende të ndryshme. Pas një periudhe të caktuar kohore e cila mund të jetë 2 ditë ose 20 ditë kur SSH duke u futur në pajisje, SSH thjesht do të varej, kështu që si demoni i lëvizjes ashtu edhe kodi C lokal që fliste me Arduino u ngarkuan në dash, prandaj pajisja po funksiononte por ishte e pamundur të bësh asgjë tjetër me të më në këtë gjendje.

Pas shumë zgjidhjes së problemeve, unë kam gjetur një zgjidhje:

homesync.sh

#!/bin/sh -e

### FILLONI INFO INFORMACION # Siguron: homesync # Kërkohet-Filloni: mountkernfs $ local_fs # Kërkohet-Ndaloni: kamera feniks # Default-Start: S # Default-Stop: 0 6 # Përshkrimi i shkurtër: Sinkronizuesi i shtëpisë # Përshkrimi: Sinkronizuesi i shtëpisë nga NLD ### END INIT INFO NAME = home DESC = "Ramdisk Home Synchronizer" RAM = "/home/" DISK = "/realhome/" set -e rast "$ 1" në fillim | me radhë) jehonë -n "Duke filluar $ DESC: "rsync -az --numeric -ids -fshij $ DISK $ RAM &> /dev /null jehonë" $ NAME. ";; stop | back) jehonë -n "Ndalimi i $ DESC:" rsync -az --numeric -ids -fshini $ RAM $ DISK &> /dev /ncho echo "$ NAME.";; *) jehonë "Përdorimi: $ 0 {start | stop}" dalja 1;; dalja esac 0

Skenari shkon së bashku me një modifikim fstab:

tmpfs /shtëpi tmpfs rw, madhësia = 80%, nosuid, nodev 0 0

Ndarja e shtëpisë është montuar si ramdisk i cili do të jepte përafërsisht 600MB hapësirë të lirë në Raspberry pi 2 e cila është më se e mjaftueshme për të ruajtur disa binare dhe skedarë të vegjël log:

tmpfs 690M 8.6M 682M 2% /shtëpi

Doli se varja PI i atribuohej operacioneve të shkrimit në SDcard, megjithëse kam provuar karta të ndryshme (Samsung EVO, Sandisk) të cilat janë skanuar për gabime disa herë para dhe pas dhe nuk kishin asnjë problem në laptopët e tjerë, kjo ishte vetëm po vjen. Unë nuk kisha të njëjtën çështje (akoma) me Raspberry PI 3s dhe pajisjet më të larta, kështu që është edhe arsyeja pse i rekomandoj ato në këtë tutorial.

Edhe pse lëvizja aktuale në një Raspberry PI 3 është mjaft e mirë për mua, këtu janë disa ide që ia vlen të eksplorohen:

1. Mos përdorni lëvizje, por përdorni një rrjedhë të madhe mbi rrjetin dhe lërini një server të fuqishëm të bëjë zbulimin e lëvizjes dhe kodimin e videos (p.sh. iSpy). -> Problem: rrotullimi i vazhdueshëm i brezit të rrjetit.
2. Përdorni lëvizjen dhe lërini ffmpeg të bëjë kodimin e videos. -> Problem: CPU nuk mund të trajtojë rezolucionet më të larta
3. Përdorni lëvizjen, regjistroni video të papërpunuara dhe lërini një server të fuqishëm të bëjë kodimin. -> Përdorimi i CPU në RPi është i ulët dhe brezi i brezit të rrjetit është i kufizuar vetëm kur ka lëvizje aktuale. Për këtë skenar ne mund të shkruajmë në një kartë SD/ramdisk për xhiros maksimale dhe më pas të kontrollojmë një kopje të videos në një server tjetër.

Do të theksoja gjithashtu se ndërtimi i këtij projekti është i mundur të ndërtohet pa një Arduino. Të gjithë përbërësit (stafetat, LDR, PIR) mund të lidhen me mjedrën pi në një farë mënyre, por unë preferoj që mikrokontrolluesit në kohë reale të ndërveprojnë me sensorë dhe pajisje dalëse. Në rastet kur pi mjedra ime ishte varur për shembull ose u rrëzua, kontrolli i dritës i drejtuar nga Arduino funksionoi mirë.

Nëse ju pëlqeu ky udhëzues qëndroi i akorduar pasi unë do të vazhdoj serinë me kamerën time 360 gradë në natyrë me mjedër pi zero vitin e ardhshëm.