www.errorediridondanzaciclicodotcom

  • Home
  • bodycam
  • BACK P.P.

  • una BodyCam con il pi Zero

    Qui vi mostro come realizzare una bodycam con il pi zero. Ovviamente non è una cosa nuova di per sè ma quello che propongo è una camera che portata addosso permette di mostrare in remoto il video, tutto tramite una connessione 3G/4G/xG.

    HARDWARE:

    Raspberry Pi zero W: modello con il wifi integrato (solo 2.4Ghz)
    PiCamera per PiZero: la versione più piccola, apposta per il pizero
    Un pulsante: per lo spegnimento non traumatico del pizero
    Battery Pack: serve per alimentare la bodycam quando indossata
    Mobile Router/Modem: per la connessione, preferibilmente 4G


    Preparazione Hardware

    Una BodyCam non deve essere molto ingombrante, perciò ho utilizzato un case piccolo con lo spazio per la camera e i connettori della GPIO. Quest'ultima poteva anche non avere i pin classici perchè utilizzerò solo gli ultimi due per il pulsante ma ormai avevo già saldato la rastrelliera di pin.

    Nella foto in alto vedete la camera con il pulsante di spegnimento.
    Questo serve per spengere la camera in maniera corretta. Si tratta di un normale pulsante che andrà collegato al pin 39 e 40 della GPIO.
    A livello di software è molto semplice, basta creare un file.py con le seguenti istruzioni:


    Dalla gpio dello zero si importa Button, si importa pause e si importano i classici os e sys. Si crea una funzione che scrive "sudo poweroff" nel terminale in background. Si assegna a btn la classe Button con 21 come numero di GPIO (il pin 40) e si utilizza la funzione "hold_time" per evitare di premere inavvertitamente il pulsante e spengere il pi (io ho impostato il tempo a 6"). Il neo creato btn, quando premuto per 6 secondi lancia la funzione di shutdown. La "pause" serve a mettere in attesa questa funzione fino a quando arriva il segnale (il pulsante premuto).
    Per far sì che questo programmino in python parta ad ogni boot, si deve aggiungere al file rc.local (sudo nano /etc/rc.local) l'istruzione necessaria:


    vedete la riga con scritto:

    python /home/pi/Documents/shutdownButton.py &

    da mettere prima di exit 0 (il pi scriverà poi da solo la parte RASIMJPEG SECTION subito dopo).

    Preparazione PIZero

    Partiamo dalla preparazione dell'OS. Installiamo su una microSd Debian Jessie (penso vada bene anche Stretch), ricordando, dopo il solito update/dist-upgrade, di lanciare il raspi-config e di installare la camera, abilitare SSH, espandere il filesystem e di aggiornare il firmware (sudo raspi-update). Non sono sicuro che c'entri ma prima di espandere il filesystem ho avuto continui blocchi (cursore lampeggiante a sx in alto e comparsa per un attimo di un command prompt premendo alt+Fqualcosa). Poiché avevo anche dei blocchi del topo elettronico e della tastiera, con questo accorgimento sono spariti.

    Ora si deve installare il sistema per utilizzare la piCamera. Utilizzo l'RPi-Cam-Web-Interface del sito eLinux.org. Si tratta di un programma fatto per gestire la piCamera ma anche per accedere dall'esterno tramite un server (Apache2, nel mio caso ma si può sceglierne un altro).
    Attenzione: potete lasciare la porta 80 e la password vuota se non avete problemi di sicurezza ma se volete maggiore protezione dovete scegliere una porta diversa e utilizzare i campi username e password.
    Una volta fatto, provate ad accedere mettendo nel browser l'indirizzo ip del pizero seguito da due punti e il numero di porta (se non utilizzate la 80). Dovrebbe comparire l'interfaccia grafica della camera. Non vado oltre per i settaggi della camera, eccetto per il discorso Motion perchè può interessare allo scopo di questo tutorial.
    La funzione di Motion Detection Autostart non dovrebbe essere automatica ma, dopo il primo avvio, può succedere, come a me, che si autosetti da sola. Per togliere la partenza automatica del motion detection non si riesce dalla GUI, bisogna modificare il file:

    sudo nano /etc/default/motion

    e mettere la riga:

    start_motion_daemon = no

    Le righe prima avvertono rigidamente che se il demone è su "standard" la riga sopra dovrebbe essere su yes ma per evitare che questo demone parta ad ogni boot non c'è alternativa.
    A questo punto, quando, durante l'utilizzo, vorrete mettere la picam in motion detection, dovrete semplicemente clikkare sul pulsante nella GUI "motion detection start".

    Problema RETE

    Il concetto di BodyCamera è quello che deve essere indossata ed utilizzata in giro ovunque. Per trasmettere i video delle riprese si deve utilizzare qualcosa di portatile. Nel mio caso ho pensato di utilizzare un Mobile Router/Modem già in mio possesso. Tuttavia questa soluzione presenta delle problematiche in quanto questi affarini non danno la possibilità del port forwarding nè dei DDNS, oltre all'eventuale problema delle reti Nattate, tipiche degli ISP in 3G/xG.
    Infine la connessione alle reti deve essere automatico perchè non si può utilizzare schermo, tastiera e topo elettronico.

    Quello che segue è la configurazione di una connessione wifi con reti multiple e ip statici VALIDA PER IL RASBIAN JESSIE E STRETCH (o altre distro recenti), non per Wheezy.

    Partiamo dall'inserimento delle reti a cui ci potremmo dover connettere (per test o per altro motivo può essere necessario utilizzare altre reti oltre la 4G). Si edita il file:

    pi@pizero:/etc/wpa_supplicant $ sudo nano wpa_supplicant.conf

    in cui andremo ad inserire i nostri network. Normalmente se accendete il pi e guardate il file suddetto trovate già le informazioni normali. Tuttavia può mancare la rete che volete (copy&paste e modifica) e comunque dovrete mettere le priorità.


    Vedete che per la prima rete ho messo priority=100 e per la seconda priority=1. Più alta è la priorità maggiore la precedenza per la connessione. Nel caso fossero accese tutte e due le mie reti, il wpa sceglierà prima quella con priorità maggiore.
    Attenzione a non lasciare spazi prima e dopo l"="!!
    Questo sistema non è proprio perfetto se abbinato ad ip statici. A volte succede che si connette fisicamente alla rete ma non viene assegnato nessun indirizzo ip e nella GUI del piZero vedete le x rosse e la scritta: "no wlan0 interface found". Dalle mie impressioni si tratta di conflitti tra ip statici multipli e dhcp.
    Normalmente ho risolto con un reboot.

    A questo punto si deve assegnare un ip statico per ogni rete. Con il sistema che utilizzerò dopo, per l'accesso remoto, non sarebbe necessario un indirizzo ip statico, tuttavia è importante per l'SSH, per la visualizzazione interna della camera e per accedere da remoto con il classico port forwarding. Sui vari siti si trova spesso il riferimento al file /etc/network/interfaces che era giusto per il vecchio OS. Da un pò di tempo questo file NON DEVE ESSERE TOCCATO (è utile solo per controllare come si sono settati i comandi di rete) e si deve agire su dhcpcd.conf.

    pi@pizero:/etc $ sudo nano dhcpcd.conf


    Vedete che il tutto si riferisce alla wlan0, essendoci connessioni wifi in essere. Le righe con "arping" servono ad istruire il pi a trovare i router che rispondono alle richieste (se sono accesi tutti e due le rispettive priorità determineranno a quale connettersi).
    Poi si scrive per ogni "profile" quale indirizzo statico assegnare, quale è il router, il router statico del DNS e su quale ricercare i domini. A parte l'indirizzo statico che deciderete voi, il resto è una ripetizione del router a cui ci si connette.
    Attenzione a non lasciare spazi, anche in questo caso, prima e dopo gli "=" altrimenti l'indirizzo ip statico non funzionerà!

    Problema CONNESSIONE DA REMOTO

    Per visualizzare una camera da remoto il concetto è sempre lo stesso:
    abbiamo la nostra picamera sulla nostra rete di casa con indirizzo qualsiasi ma sempre interno (LAN). Per vederla dall'esterno (posto di avere già installato programmi come sopra per vedere uno streaming) dobbiamo per forza entrare nel nostro router per mezzo di una connessione internet e lì chiedere al router di instradarci verso il pizero. I problemi possono essere due: il primo, sempre presente, è che dobbiamo "aprire la porta" che fa arrivare alla camera. Ricordate che questa porta serve ad identificare il servizio interno (la camera) quando lo facciamo comunicare (in entrata e in uscita) con l'esterno (internet). Infatti il nostro indirizzo esterno (quello che ci concede l'ISP) è unico ma molti pc e device possono utilizzarlo contemporaneamente. Per accedere ad un device interno metteremo nel browser del pc fuori casa l'indirizzo ip dell'ISP seguito da : e dal numero di porta che abbiamo assegnato facendo il port forwarding sul nostro router per questo device.
    Il secondo problema è che l'indirizzo ip dell'ISP è spesso nattato. Significa che l'ISP, avendo pochi indirizzi pubblici (quelli che ci vengono assegnati e che sono visibili su internet), a volte, ci assegna un indirizzo interno alla sua rete che, grazie al Network Address Translation (NAT), viene, durante ogni comunicazione, tradotto nell'indirizzo ip pubblico e identificato con una porta. Esattamente quello che succede nella nostra rete interna lo fanno gli ISP a corto di indirizzi pubblici. Se fate uno speedtest (o interrogate con whoami) e vedete il vostro indirizzo pubblico di internet, vedrete che può essere del tipo 10.x.x.x. (il 10 significa che non è pubblico ma privato). Se vorrete accedere da remoto ad un vostro pc non potete utilizzare questo indirizzo perchè non è quello reale pubblico dell'ISP, è come se tentaste di accedere da remoto ad un pc di un'altra persona interno alla sua rete domestica!

    Per il primo problema si usa spesso una VPN. Senza dilungarmi si tratta di un sistema con il quale si crea una sorta di tunnel (chiuso, cioè criptato) tra un nostro device interno ed un device esterno via internet. Un device funge da server ed uno da client. Ciò significa che il device che sarà il server deve poter essere raggiungibile quindi necessita di port forwarding. Se da una parte la VPN risolve il problema degli indirizzi nattati, non risolve però il problema del port forwarding che i router portatili non permettono.
    Per ovviare a ciò si può ricorrere anche (ci sono sistemi che non ho provato come il reverse tunneling) ad una VPN esterna, cioè un servizio di accesso remoto tramite VPN a noleggio. Il sistema che ho sperimentato è quello offerto da REMOTE3.IT.

    Si tratta di un servizio anche specifico per il raspberry che permette l'accesso da remoto del pi senza port forwarding e senza bisogno di conoscere l'ip dell'ISP.
    Prima si crea un account (gratuito se non a scopi commerciali) poi si installa sul device (il pizero) il software che permette di essere raggiunto tramite VPN. Nel mio caso ho proceduto così:
    pi@pizero:~ $ sudo apt-get install weavedconnected

    questo sopra installa il software.

    pi@pizero:~ $ sudo weavedinstaller

    questo invece permette di configurare la nuova connessione che si vuole utilizzare.

    Vi troverete di fronte un menu dove potrete accedere al vostro account o crearne uno nuovo. Metterete la vostra mail (username) con cui vi siete registrati e la password scelta (che non vedrete durante la digitazione). Dovrete poi scegliere ed immettere il nome del dispositivo (es. PiZero_Mio). Quindi vi sarà chiesto di attaccare un servizio al vostro nuovo device (selezione 1, altrimenti altre opzioni). Ora dovete scegliere tra:


    Io ho scelto il 2 (Web on port 80, avendo lasciato questa porta), altrimenti dovete scegliere il 4 e mettere la porta che avete scelto durante l'installazione dell'interfaccia Web di elinux.

    Ora è tutto pronto per accedere dall'esterno alla vostra picamera sullo Zero. Da qualsiasi pc o smartphone, dovete andare sul browser, accedere a remote3.it con il vostro account (abilitando le finestre popup) e vedrete i vostri device. Clikkando sul device vedrete i servizi abilitati e clikkando su di essi avrete la visione di ciò a cui sono collegati, nel caso come il mio vedrete la pagine dell'interfaccia web della picamera con html e, quindi, da lì potrete accedere al vostro streaming.
    L'unico problema è che la connessione è attiva per 8 ore (anche quella a pagamento). Per una connessione da rete mobile penso che sia più che sufficiente visto che pochi minuti vi mangiano già parecchi MB!

    Diverso il discorso se utilizzate remote3 con un'adsl senza limiti. In questo caso però avreste potuto sicuramente aprire una porta ed accedere senza problemi semplicemente digitando nel browser: "Ip pubblico:porta" oppure, senza ip pubblico statico e con DDNS abilitato sul router: "DDNSDominio:porta".

    Nella foto sotto vedete uno screenshot di un collegamento tramite remote3 su iPhone: