Sensori: perché e meglio usare Arduino

E’ una problematica ben nota, con cui mi sono scontrato anche io i primi tempi che tentavo di usare svariati tipi di sensori con il Raspberry. Mentre lo stesso sensore su Arduino mostrava una affidabilità praticamente ideale, usato con Linux sia su Raspberry che su Banana Pro mi dava una percentuale piuttosto alta (20 – 25%) di letture fallite. Il motivo è piuttosto semplice: il microcontrollore (di qualsiasi tipo sia) presente su una scheda Arduino dedica totale attenzione al codice che sta girando nello sketch e dal momento che molti sensori richiedono timings piuttosto precisi per funzionare (stiamo parlando di microsecondi) questa alta priorità di esecuzione fa sì che praticamente ogni lettura di un qualsiasi sensore vada a buon fine.

Per un sistema operativo complesso come Linux purtroppo le cose non vanno altrettanto bene. Nonostante i kernel per schede come i Raspberry e via dicendo siano compilati generalmente con delle patch di tipo PREEMPTIVE, per gestire appunto processi di tipo real-time, si tratta comunque di un sistema operativo continuamente impegnato a gestire richieste di processi di sistema per controllare l’hardware collegato, la memoria, schedulazioni di vario genere che chiedono senza pausa l’attenzione della CPU (si chiamano interruzioni o interrupt).  Quindi il microprocessore della scheda non è mai a riposo e quando mandiamo in esecuzione il nostro codice di gestione dei sensori, sia esso scritto in Python o in C, non è assolutamente detto che riesca ad ottenere dalla CPU quella continua “attenzione” che servirebbe per gestire temporizzazioni di millisecondi e addirittura microsecondi.

Il risultato all’atto pratico? Ad esempio un normale sensore DHT11 o DHT22 darà letture fallite su Linux con una percentuale di circa il 20-25%, come ho potuto verificare sperimentalmente. Non oso pensare poi ai fatidici 10 microsecondi necessari all’HC SR04 per inviare il segnale di andata, e a tanti altri casi simili. Basta guardare ad esempio il codice della libreria Adafruit per i sensori DHT: è previsto al loro interno un retry delle letture per ben 15 volte prima di far uscire i dati, e nonostante tutto questo è possibile ancora il fallimento della lettura stessa. Niente del genere sulle stesse librerie per Arduino, lì andiamo praticamente a colpo sicuro. Ho il DHT22 sul prototipo della stazione meteo che ha accumulato più di 20000 letture (1 ogni minuto) senza fallire un colpo, ma è pilotato da un Arduino Nano.

Tutto questo discorso ovviamente non per farne una colpa a Linux. E’ un sistema operativo, ha una moltitudine di cose da fare, e per quanto si sforzi non riesce a fare di meglio nei processi di tipo real-time. Almeno con queste piccole schede e senza un kernel fortemente specializzato. Nei processi di controllo industriale la musica cambia, laddove vengono utilizzati altri tipi di macchine.

Concludendo direi che volendo mantenere un livello di affidabilità molto alto farei pilotare a schede come Raspberry e simili solamente attuatori, lasciando il compito delicato di gestire l’acquisizione di grandezze a schede della famiglia di Arduino, evidentemente in colloquio con le prime. Tutto questo mi ha portato a progettare la mia stazione meteo basandosi su Arduino, delegando al Raspberry la sola scrittura delle informazioni su un database MySql. Fare tutto con il Raspberry avrebbe certamente semplificato l’hardware del progetto ma…….

 

Raspbian Wheezy – Se il firewall non funziona

Scaricata ed installata la Raspbian Wheezy dal sito ufficiale del Raspberry ho avuto la necessità di impostare IPTABLES, ovvero il firewall di Linux. Avevo già effettuato i classici comandi < apt-get update > e < apt-get upgrade > per l’aggiornamento della distro ma quando ho chiesto lo stato delle chain con < iptables -vnL > ho ricevuto in risposta questo errore:

Sintomo di un disallineamento tra kernel e iptables stesso. Va dato quindi un comando ulteriore < rpi-update > per sistemare tutto. Dopo questo ulteriore aggiornamento iptables funzionerà correttamente.

Cambio look

GrepPipeLinux cambia aspetto. Questo nuovo tema è un po’ più pesante del precedente, ma pur rimanendo piuttosto essenziale nella grafica mi sembra migliori la leggibilità del sito, soprattutto negli sketches. Stavolta ho dovuto abilitare ZenCache per alleviare un po’ il carico del web server. Ricordo che questo sito gira su un Raspberry Pi2 dedicato con installata RedSleeve 7.1

Sempre a proposito del BMP180

Ho dato un’occhiata alla libreria SparkFun per questo sensore e al relativo sketch di esempio. In effetti mi sembra più logico utilizzare l’altitudine del sito di misura come una costante in entrata (è facile da ricavare con un qualsiasi telefonino dotato di GPS) e ricavare piuttosto la pressione atmosferica traslata sul livello del mare, che può servire come raffronto con i dati pubblicati dai servizi meteo.

Scaricata la libreria alla URL indicata all’inizio dello sketch ho però dovuto prendere i 2 file .cpp e .h, zipparli insieme (sono nella directory src) e darli in pasto alla IDE di Arduino in questo modo, altrimenti la include iniziale non li trovava.

Ecco il nuovo sketch:

Arduino – Sensore barometrico BMP180

20150918_102833

Eccolo qui, il classico sensore di pressione atmosferica. Me ne sono arrivati una coppia, di cui purtroppo uno non funzionante. Generalmente vengono venduti con la strip dei contatti non ancora saldata al sensore, quindi bisogna provvedere da sé alle saldature. Era l’anello mancante alla Stazione Meteo che sto realizzando e di cui parlerò in seguito; effettua una lettura della pressione barometrica e della temperatura e poi calcola in libreria anche la stima dell’altezza sul livello del mare.

Utilizza i pin seriali analogici I2C, quindi richiede la libreria Wire di Arduino (già disponibile nella IDE ufficiale) e una ulteriore libreria esterna specifica del sensore. Ne esistono diverse, ed io andando in giro ne ho scaricata una all’indirizzo http://www.adrirobot.it/sensori/sensore_pressione_BMP180/bmp180.zip, ottimo sito tra l’altro. Volendo si possono utilizzare anche quelle Adafruit o Sparkfun, insomma chi più ne ha più ne metta.

Riguardo l’alimentazione del sensore bisogna stare molto attenti: il datasheet Bosch dice chiaramente che si tratta di un sensore da alimentare a 3.3V. La versione in mio possesso sembra avere un regolatore di tensione per alimentarlo a 5V, ma non mi sono fidato comunque ed ho perciò utilizzato per alimentarlo il pin marcato come 3.3 collegandolo appunto ai 3.3 Volts di Arduino. Forse sono stato eccessivamente prudente, ma dal momento che già uno dei due mi è arrivato non funzionante non volevo rischiare nemmeno lontanamente di mettere fuori uso quello buono.

Ecco i collegamenti ad Arduino ( i colori sono una mia convenzione):

I pin SCL e SDA sono le 2 connessioni I2C. Le due entrate analogiche utilizzate non vengono definite all’interno dello sketch come in altri casi quindi vanno utilizzate necessariamente quelle (A4 e A5). Devo dire che il sensore è stabilissimo (con Arduino, sui Raspberry non ho verificato) e non ha mai fallito letture anche dopo parecchio tempo di utilizzo continuo. Inoltre mi pare vada a regime in tempi molto brevi, qualche minuto al massimo.

Ho cercato di impostare lo sketch come funzione separata di lettura, questo facilita l’inserimento del codice in ambiti multisensore.

SKETCH DI ESEMPIO:

Centos 7 – Togliere firewalld e ripristinare IpTables

Tra le varie novità portate dalla Centos/RedHat 7 c’è anche il nuovo firewall, che si chiama appunto firewalld. La gestione è molto differente dal classico IpTables, per cui potrebbe verificarsi la necessità (o la voglia) di disabilitarlo per gestire il firewall nella maniera classica. Ecco i comandi:

Da questo momento in poi potremo riprendere a gestire “alla vecchia maniera” il nostro firewall.

Proviamo iptables -L per vedere come sono sistemate di default le chain e non dimentichiamoci che se non abbiamo ripristinato il “vecchio” /var/log/messages qualora dovessimo loggare i pacchetti droppati dovremo controllare il log di sistema con il comando journalctl -f

Questa procedura è applicabile anche alla Centos 7 per processori arm e naturalmente a Fedora e RedSleeve 7.

RedSleeve 7.1 – Kernel 4.1.6

Tra i vari repository YUM di cui bisogna cambiare i puntamenti nell’immagine originale c’è anche il raspberry.repo, che contiene solamente il Kernel e il firmware specifico per la scheda, nel mio caso il Rasberry Pi2. Dal momento che contiene un Kernel 4 ho voluto aggiornare la distro per provarlo.

Questo è il file /etc/yum.repos.d/raspberry.repo da sostituire all’originale:

Una volta salvato con il comando yum upgrade viene riletto l’elenco dei repository e quindi si può procedere con lo yum update. E’ richiesto un reboot di siatema.

 

Sensore di temperatura e umidità DHT22

20150909_120750

Oggi mi sono arrivati finalmente la coppia di sensori DHT22 che avevo ordinato (costo circa 6 euro ciascuno). Ne ho messo al lavoro uno e devo dire che le differenze rispetto al fratello minore DHT11 si percepiscono tutte. Al confronto con strumenti ancora più precisi la lettura di temperatura è veramente buona ma soprattutto la lettura igrometrica è finalmente precisa e non sottostimata di parecchio come accade con il DHT11. Un’altra storia insomma. Per pilotarlo con Arduino può essere usato come riferimento il post che ho già pubblicato sul DTH11, utilizzando per la lettura la funzione DHT.read22() disponibile nella libreria esterna che ho indicato. Come si può notare si tratta di un sensore non montato su basetta quindi privo della resistenza di pull-up di cui ha bisogno per stabilizzare il pin del segnale. Quindi consiglio di utilizzare una resistenza da 10KOhm da inserire in parallelo tra il connettore dei +5V e il pin del segnale.

Per le connessioni su Arduino, così come si vede in figura, partendo da sinistra:

Costa circa il triplo del DTH11 (attenzione perché viene proposto anche a prezzi spropositati) ma la differenza di precisione e affidabilità c’è tutta.

RedSleeve 7.1 – Running on GrepPipeLinux :)

Unknown-1

Oggi durante la giornata la “vecchia” Fedora 21 è letteralmente impazzita. Systemd ha cominciato a dare i numeri portando instabilità su MariaDb, Apache (che sono caduti) e perfino l’interprete di comandi. L’ho spazzata via, e ora GrepPipeLinux gira sotto RedSleeve 7.1,

Non sono riuscito a capire cosa sia successo, se un incauto update che è arrivato dai repository ufficiali della distribuzione oppure una interruzione di corrente avvenuta qualche giorno fa. Fatto sta che, data la fretta di rimettere in piedi il sito,  ho colto l’occasione per mettere ulteriormente sotto test la RedSleeve facendogli gestire un sito WordPress. E con questo l’ultima Fedora che utilizzavo se ne va in pensione 🙂