Fotocamera Raspberry PI e Morte Nera per il controllo della luce: 5 passaggi (con immagini)

2024 Autore: John Day | [email protected]. Ultima modifica: 2024-01-30 10:03

Come sempre cerco di costruire dispositivi che siano utili, funzionino in modo robusto e spesso siano anche miglioramenti rispetto alle attuali soluzioni standard.

Ecco un altro grande progetto, originariamente chiamato Shadow 0f Phoenix, uno shield Raspberry PI in combinazione con il rilevamento del movimento basato su Arduino e i controlli della luce.

Passaggio 1: lo stato delle telecamere IP commerciali

Oltre al fatto che costruire il proprio sistema di telecamere/sorveglianza è più interessante, vediamo perché questo è un miglioramento rispetto a una soluzione standard.

Lo confronterò con la serie di telecamere IP wireless NEO COOLCAM Full HD 1080P poiché ho posseduto molti di questi vari modelli di telecamere neo coolcams (ONVIF). Sono disponibili in diverse forme e dimensioni, all'aperto e al chiuso, la maggior parte di loro ha il supporto Wi-Fi integrato, ma vediamo i loro avvertimenti:

• I produttori cinesi che vendono queste fotocamere mentono quasi sempre sulla risoluzione del sensore di immagine integrato, quando acquisti una fotocamera da 5 MP/8 MP su Ebay potresti finire con una fotocamera da 2 MP economica con una brutta immagine (funziona ma la qualità è spazzatura). Quando acquisti la fotocamera Raspberry PI v2 da 8 MP dal rivenditore originale, otterrai ciò per cui hai pagato e un sensore da 8 MP effettivo con la risoluzione 3280 × 2464 pixel =>
• Dal punto di vista della sicurezza, queste telecamere (anche il più costoso Dlink e altri modelli) sono terribili, utilizzano password predefinite come 123456 o utenti integrati come amministratore/operatore/operatore amministratore che potresti non essere nemmeno in grado di modificare o il il cambiamento è andato dopo un riavvio. Completa il tutto con molte di queste fotocamere del telefono di casa (connettiti ai loro server in Cina, alcuni addirittura ritrasmettono video/immagini senza chiederti solo di semplificare nel caso tu decida di installare la loro app Android/Iphone un giorno per controllare il tuo casa). Anche se metti questi dispositivi dietro un router, non è abbastanza buono, la cosa migliore è se non imposti un gateway predefinito in essi, non li metti in un firewall o li metti in una VLAN per rendere impossibile loro l'uscita Internet o meglio: non usarli affatto.
• Sono più affidabili? no, molti di loro, anche i DLINK più costosi, hanno la possibilità di riavviare la telecamera giornalmente/settimanalmente, ecc. Questa opzione c'è per un motivo, perché dopo X giorni spesso perdono la connettività Wifi o si comportano male in altri modi. Pensa a loro come alle buone vecchie scatole Win95 che dovevano essere riavviate il più delle volte:) Non dico che l'hardware basato su Raspi sia così solido come una roccia che puoi costruirle in centrali nucleari di controllo ma con hardware / software appropriato configurazione, dissipatori di calore, ventole di raffreddamento automatiche e funzionamento RW ridotto al minimo sulla SDCARD possono facilmente raggiungere senza problemi oltre 100 giorni di operatività. Al momento in cui scrivo, la mia DeathStar funziona da 34 giorni, più di 100, ma a volte stavo hackerando il feed nella fonte di alimentazione che alimenta altri dei miei circuiti, quindi ho dovuto spegnerlo:(
• Hardware mirato: sono realizzati per uno scopo specifico, spesso sono dotati di una piccola area nvram e di una busybox, ma alcuni modelli rendono impossibile anche l'accesso a questa shell, quindi tutto ciò per cui puoi usarli è quello per cui dovevano essere usati mentre puoi usa la tua fotocamera basata su Raspi per qualsiasi altra attività: file server, server tftp/dhcp, server web, server quake… le opzioni sono illimitate.
• Spazio di archiviazione: o non ne hanno o usano schede microsd con filesystem FAT32 VS sul raspberry pis puoi anche collegare un disco rigido da 2 TB se lo desideri.
• Controllo delle luci: alcuni hanno un'uscita ALARM in cui potresti essere in grado di collegare un piccolo relè per far scattare le luci. Come ti mostrerò in questo tutorial, l'uso di telecamere a infrarossi è una completa perdita di tempo poiché non sarai in grado di identificare nessuno sulle immagini IR a causa della cattiva qualità. Se devi registrare un video al buio, il modo migliore per farlo è accendere prima la luce e poi registrare il video.

Quindi potresti chiedere ci sono dei PRO nell'usare una fotocamera standard? Sì per le aziende in cui le ore di lavoro per configurarlo sarebbero più costose che armeggiare con Raspberry pis (non per me comunque:)) e sì, ci sono fotocamere top di gamma (500 $ + con una risoluzione migliore rispetto alla fotocamera pi di corso). Come altro vantaggio potrei dire che le telecamere che seguono lo standard ONVIF hanno reso più facile il provisioning centralizzato. Ciò fornisce un'interfaccia standard che può essere utilizzata per inviare comandi alla telecamera per impostare il suo IP/maschera di rete/gateway e altre cose. Per questo puoi scaricare il gestore dispositivi Onvif da Sourceforge. Molti di questi dispositivi sono dotati di frontend Web scadenti dove, ad esempio, non ti consente di impostare correttamente l'ip o la maschera di rete perché il javascript che convalida questi campi non funziona correttamente e l'unico modo per impostare correttamente questi parametri è tramite ONVIF.

Fase 2: I piani della Morte Nera

Puoi costruire questo dispositivo con qualsiasi Raspberry PI a partire da 1 a 3B+. Anche lo zero ha porte per fotocamera, ma dal momento che ci sono così tanti diversi raspi di seconda mano sul mercato potresti chiederti quale sia il più ideale per questa build.

La risposta dipende da dove vuoi elaborare il flusso video.

Ci sono due scelte:

1, elabora i video localmente con il movimento e inoltra un flusso video quando viene rilevato un movimento (nota: il movimento inoltra un flusso costante lento al server, non importa quale, questo può dipendere dalla risoluzione e dai frame rate utilizzati passando da un paio di centinaia di megabyte a più gigabyte al giorno, solo un promemoria se si desidera eseguire una configurazione su una connessione a consumo). Qui la CPU conta e sfortunatamente il movimento (al momento della scrittura) non sfrutta i core multipli, tuttavia il sistema operativo cercherà di bilanciare leggermente il carico. Avrai sempre uno dei core con un utilizzo al 100%.

2, Elabora i video su un server centrale: qui devi solo inoltrare il flusso video non elaborato dalla videocamera a un server di streaming esterno (come iSpy in esecuzione su un computer x86 o MotionEyeOS in esecuzione su un altro minicomputer dedicato). Poiché non c'è elaborazione localmente, il modello di PI che usi non ha importanza, un PI1 invierà lo stesso flusso di un PI3B+.

In questo tutorial andrò con la prima scelta.

La regola generale qui è che più veloce è la CPU che metti in movimento, migliori saranno i risultati che otterrai. Ad esempio la mia fotocamera basata su Raspi 2 che guarda un corridoio a volte non la riprende quando qualcuno passa veloce e durante la registrazione la registrazione è lenta, perdendo molti fotogrammi rispetto al modello 3. Il modello 3 ha anche 802.11 abgn wifi che è utile per poter trasmettere video di qualità superiore, funziona immediatamente ed è abbastanza affidabile. Al momento in cui scrivo che il modello 3B+ è uscito, consiglierei solo di ottenerlo con una CPU Quad Core da 1,4 Ghz.

Elenco dei materiali

• Morte Nera in plastica da 30 cm:)
• Raspberry Pi 3 B+
• PiCam v2 (8MP)
• Arduino Pro Micro 5.5v
• 2x relè interruttore reed SIP-1A05
• 1x PCS HC-SR501 Modulo rilevatore di movimento PIR a infrarossi IR piroelettrico IR
• 1x resistore da 10kohm per LDR
• 1x LDR
• Adattatore CC 1x12V 4A
• 1xWarm White LED 5050 SMD Lampada a luce flessibile Striscia 12V DC
• Regolatore di tensione 1xBuck

Come puoi vedere dagli schemi, questo progetto è stato originariamente progettato per controllare una singola luce con un relè perché non avevo intenzione di aggiungere l'illuminazione interna (che è piuttosto interessante), quindi ho appena cablato un secondo relè all'Arduino. La cosa grandiosa del SIP-1A05 è che ha un diodo flyback interno e il consumo in mA è molto al di sotto della limitazione di potenza per pin di Arduino.

Il motivo per cui il PIR è sullo scudo nelle immagini perché all'inizio S0P è stato progettato per essere inserito in una semplice scatola di plastica IP invece di una DeathStar. Come avrai intuito, la fotocamera è direttamente nella pistola laser, il PIR e l'LDR avevano bisogno di altri fori e sono stati incollati con la pistola poiché non ho intenzione di rimuoverli.

È stato praticato un foro nella parte inferiore della DeathStar dove ho incollato un grosso bullone con una forte colla bicomponente. Questo può essere avvitato nel supporto originale di Neo Coolcams (dopotutto era buono per qualcosa:)). Per un supporto aggiuntivo ho usato dei fili di rame duro per avere una presa sulla parte superiore della stella.

Nota importante sull'alimentatore: poiché lo stesso alimentatore alimenterà sia il PI, l'Arduino che la striscia LED, deve essere abbastanza robusto da poterli gestire tutti, quindi sarà basato sulla striscia LED che scegli per il progetto. Una striscia LED commerciale 5050 12v 3 metri scarica circa 2A, è molto. Per il PI e Arduino devi calcolare in +2A (anche se questo è sovradimensionato non farà male). L'uso di strisce LED su lampadine alogene standard, neon o altre luci ad alta potenza è che puoi mettere l'intero circuito su una bella batteria al piombo da 12 V @ 10 Ah come backup in modo che funzioni anche in caso di interruzione di corrente.

Il buck ridurrà la tensione da 12-> 5V per alimentare Arduino e PI mentre l'alimentazione diretta a 12V è cablata sul relè per accendere la striscia LED.

Passaggio 3: software Arduino

Puoi trovare il codice sorgente completo in basso che è ben commentato ma ecco una breve spiegazione di come funziona: All'inizio di ogni ciclo viene chiamata la solita funzione xcomm() per vedere se c'è un comando proveniente dal Raspberry PI che può essere LIGHT_ON/OFF per accendere o spegnere le luci del corridoio o DS_ON/OFF per accendere/spegnere la retroilluminazione di DeathStar, li ho implementati solo per motivi di perfezione poiché se qualcuno passa vicino al PIR dovrebbe prenderlo e accenderlo le luci ma forse vuoi guardare il posto per qualche motivo anche quando non c'è nessuno.

Successivamente viene letto il valore della fotocellula e viene verificato il movimento del pin di movimento. Se c'è movimento, il codice controlla se è abbastanza buio, quindi controlla se non siamo in attesa. Se tutto questo passa allora semplicemente accende la luce del corridoio e rimanda PHOENIX_MOTION_DETECTED al Raspberry PI, se non è abbastanza buio segnala ancora al computer ma non accende la luce. Una volta rilevato un movimento, viene avviato un timer di attesa di 5 minuti.

Subito dopo, la prossima sezione del codice controllerà se siamo in attesa (come dovrebbe essere il caso se ci fosse solo un evento di movimento, quindi supponiamo che siano trascorsi 5 minuti in modo che questo controllo possa confermare). Il codice controlla se c'è di nuovo movimento, in caso contrario spegni le luci. Come puoi vedere se non c'è movimento, questa funzione si ripeterà più e più volte, continua a provare a spegnere le luci in modo che non ci sia feedback al PC.

Abbiamo un altro timer di attesa per l'illuminazione interna della Morte Nera che dipende esclusivamente dalla lettura della fotocellula < dark_limit.

Sebbene le 2 routine non si conoscano l'una dell'altra, funzioneranno perfettamente insieme poiché quando la luce del corridoio si accende fornisce così tanta luce che l'LDR penserà che sia di nuovo giorno e spegne l'illuminazione interna. Tuttavia c'erano alcuni avvertimenti su questo processo che è spiegato nel codice se sei interessato, in caso contrario prendi la risposta di Nvidia che "funziona e basta!".

Passaggio 4: software Raspberry PI

L'ultimo Raspbian funziona per me:

Raspbian GNU/Linux 9.4 (allungamento)

Linux Phoenix 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux ii motion 4.0-1 armhf Programma di acquisizione V4L che supporta il rilevamento del movimento

Sebbene tu possa utilizzare altre distro, se riscontri problemi con la fotocamera riceverai supporto dal team solo se stai utilizzando il loro sistema operativo ufficiale. Anche la rimozione di bloatware indesiderati come systemd è altamente raccomandata.

Il movimento può anche essere costruito facilmente dalla sorgente:

apt-get -y install 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 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

Raccomando iSpy come videoregistratore/server di raccolta. Sfortunatamente al momento in cui scrivo non ci sono buone alternative per Linux. La telecamera può essere aggiunta con un URL MJPEG https://CAMERA_IP:8081 come porta predefinita.

L'elaborazione del movimento può essere utile per esempio non devi continuare a guardare il tuo server iSpy tutto il giorno, puoi ricevere un'e-mail in caso di movimento. Sebbene iSpy disponga di questa funzionalità per avvisare via e-mail in caso di movimento, di tanto in tanto attiva la registrazione per eventi vari come la luce riflessa nell'area. Con il rilevamento del movimento PIR non ho mai avuto un solo falso allarme. Gli avvisi possono essere elaborati localmente:

Evento di movimento Pir rilevato sul sensore > Avviso Arduino > Raspberry pi riceve su console > Programma di elaborazione C > Applicazione di posta esterna

Tuttavia preferisco elaborare sia i registri che i video in remoto, quindi in questo caso ho aggiunto una sezione al programma di controllo C mentre registra i registri localmente in un file di testo normale, lo registra anche su syslog e questo viene inoltrato a un SIEM per ulteriore elaborazione.

void logger (carattere *testo) {

FILE *f = fopen("phoenix.log", "a"); if (f == NULL) { printf("Errore durante l'apertura del file di registro!\n"); Restituzione; } fprintf(f, "%s => %s\n", cur_time(0), testo); fchiudi(f); #ifdef SYSLOG char log[500]; sprintf(loggy, "%s => %s\n", cur_time(0), testo); setlogmask (LOG_UPTO (LOG_NOTICE)); openlog ("DeathStar", LOG_CONS | LOG_PID | LOG_NDELAY, LOG_USER); //syslog (LOG_NOTICE, "Programma avviato dall'utente %d", getuid()); syslog (LOG_NOTICE, log); closelog (); #endif ritorno; }

Sul lato ricevente syslog-ng può demuxare questi eventi dal flusso di log principale:

filtro f_phx{

match("Stella Morte"); }; destinazione d_phx { file("/var/log/phoenix/deathstar.log"); }; log { source(s_net); filtro(f_phx); destinazione(d_phx); };

e può essere passato a un altro strumento (motion.php vedi allegato) per analisi e avvisi.

In questo script puoi semplicemente impostare il solito orario durante la settimana quando non sei a casa:

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

Il programma php utilizza l'eccellente utility logtail per analizzare i log.

$cmd = "logtail -o".$offsetfile.' '.$fileregistro.'>'.$fileregistro2;

Logtail tiene traccia della posizione in un file offset in modo che il programma principale non debba sapere da quale momento iniziare a guardare i registri, gli verranno forniti gli ultimi dati non elaborati.

Motion.php può essere eseguito da crontab con un piccolo trucco per i fine settimana, quando passerà attraverso i log, ma senza ulteriori elaborazioni.

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

Passaggio 5: problemi e lista delle cose da fare

Se stai utilizzando Raspberry pi 3 o versioni successive, puoi saltare questa sezione, molto probabilmente non incontrerai più questi problemi.

Nel corso degli anni ho avuto alcuni problemi con le schede basate su Raspberry pi 2 che potrebbero eseguire lo stesso stack software ma sono state acquistate in momenti diversi da luoghi diversi. Dopo un certo periodo di tempo che potrebbe essere di 2 giorni o 20 giorni in cui SSH si collega al dispositivo, SSH si blocca, quindi sia il demone di movimento che il codice C locale che ha parlato con Arduino sono stati caricati nella ram, quindi il dispositivo funzionava ma era impossibile farne altro in quello stato.

Dopo un sacco di risoluzione dei problemi ho trovato una soluzione:

homesync.sh

#!/bin/sh -e

### BEGIN INIT INFO # Fornisce: homesync # Avvio richiesto: mountkernfs $local_fs # Stop richiesto: camera phoenix # Avvio predefinito: S # Stop predefinito: 0 6 # Descrizione breve: Sincronizzatore domestico # Descrizione: Sincronizzatore domestico by NLD ### END INIT INFO NAME=home DESC="Ramdisk Home Synchronizer" RAM="/home/" DISK="/realhome/" set -e case "$1" in start|forth) echo -n "Inizio $ DESC: " rsync -az --numeric-ids --delete $DISK $RAM &> /dev/null echo "$NAME.";; stop|back) echo -n "Arresto di $DESC: " rsync -az --numeric-ids --delete $RAM $DISK &> /dev/null echo "$NAME.";; *) echo "Utilizzo: $0 {start|stop}" exit 1;; esac uscita 0

Lo script va insieme a una modifica fstab:

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

La partizione home è montata come ramdisk che produrrebbe circa 600 MB di spazio libero sul Raspberry pi 2 che è più che sufficiente per memorizzare alcuni binari e piccoli file di registro:

tmpfs 690M 8.6M 682M 2% /home

Si è scoperto che il blocco PI è stato attribuito alle operazioni di scrittura sulla scheda SD, anche se ho provato diverse schede (Samsung EVO, Sandisk) che sono state scansionate per errori più volte prima e dopo e non hanno avuto problemi in altri laptop questo era solo in arrivo. Non ho avuto lo stesso problema (ancora) con Raspberry PI 3 e hardware superiore, quindi è anche per questo che li consiglio in questo tutorial.

Sebbene l'attuale movimento su un Raspberry PI 3 sia abbastanza buono per me, ecco alcune idee che vale la pena esplorare:

1. Non usare il movimento, ma usa un flusso raspivid sulla rete e lascia che un server potente esegua il rilevamento del movimento e la codifica video (ad esempio iSpy). -> Problema: hogging costante della larghezza di banda della rete.
2. Usa il movimento e lascia che ffmpeg esegua la codifica video. -> Problema: la CPU non può gestire le risoluzioni più alte
3. Usa il movimento, registra video non elaborati e lascia che un potente server esegua la codifica. -> L'utilizzo della CPU su RPi è basso e la larghezza di banda della rete è limitata a quando c'è movimento effettivo. Per questo scenario potremmo scrivere su una scheda SD/ramdisk per il massimo throughput e quindi crontab una copia del video su un altro server.

Vorrei anche notare che costruire questo progetto è possibile costruire senza un Arduino. Tutti i componenti (relè, LDR, PIR) potrebbero essere collegati in qualche modo al raspberry pi, ma preferisco i microcontrollori in tempo reale per interagire con sensori e dispositivi di uscita. Nei casi in cui il mio Raspberry Pi era appeso, ad esempio, o si è bloccato, il controllo della luce gestito da Arduino ha funzionato bene.

Se ti è piaciuto questo istruttivo, resta sintonizzato perché continuerò la serie con la mia fotocamera dome a 360 gradi per esterni lampone pi zero l'anno prossimo.