Per i Makers, l’hardware

ED IT ORIA LE diventa sempre più semplice

I più giovani probabilmente non lo sanno, ma anni fa, per realizzare un progetto funzionante
di un antifurto, ad esempio, occorreva assemblare uno schema estremamente sofisticato.
Porte logiche, flip flop, contatori, transistor, circuiti RC per le temporizzazioni e quant’altro
contribuivano attivamente al funzionamento del dispositivo. La sua concezione risultava
una vera e propria arte e la percentuale di riuscita era spesso alquanto bassa. Spesso, per
realizzare semplici circuiti occorreva approntare enormi schede e circuiti stampati, stracol-
mi di componenti elettronici, collegati tra loro ad arte. Un eventuale guasto era difficile da
trovare, occorreva ripercorrere manualmente le strade dei vari segnali.
Oggi non è più così, la realizzazione di un circuito elettronico, seppur estremamente sofisticato, è
cosa agevole e semplice per tutti. Una scheda di sviluppo leggera e compatta come, ad esempio,
il nostro ESPertino, mette a disposizione tutto ciò di cui un progettista ha bisogno, in pochissimo
spazio. La logica di funzionamento è basata non più sull’interazione complessa tra i vari componenti
elettronici ma su un firmware appositamente creato. E’ anche possibile realizzare un differente

“ La tecnologia aiuta sicuramente gli hobbisti, alleggerendoli molto dallo

sviluppo dell’hardware

progetto dalle finalità diametralmente opposte senza toccare un solo componente elettronico ma
semplicemente riprogrammando il tutto.
Eh si, oggi i giovani progettisti hanno la vita estremamente comoda e i prototipi che essi creano
sono dei veri e propri capolavori. Ma la realizzazione di un progetto elettrico a componenti discreti,
senza l’ausilio di processori o MCU, inculca maggiormente il concetto di elettronica. E consente di
comprendere a fondo il ruolo dei diversi stadi di un circuito, di capire la migliore soluzione di ottimiz-
zazione da adottare e di creare da sé un dispositivo complesso ma funzionante in tutte le sue parti.
E’ meglio ieri oppure oggi? Penso entrambi i periodi. Il progettista deve conoscere l’arte di costruire
circuiti alla vecchia maniera, pur sapendo programmare i microcontrollori. Il bagaglio culturale deve
essere completo. Non basta saper a menadito tutte le istruzioni dell’Esp32 se poi non si sa realiz-
zare un lampeggiatore a transistor.
Sarebbe opportuno che i ragazzi e gli studenti di oggi approfondiscano molto questo settore dell’e-
lettronica ma sarebbe anche utile che gli appassionati più “datati”, spesso titubanti e contrari ai
nuovi metodi, entrino in contatto con questa meravigliosa tecnologia elettronica, fatta di software e
di programmazione.
Lancio una sfida a chi si voglia mettersi in gioco. Si provi a realizzare, anche solo come idea di
progetto e schema, un sistema che inneschi un allarme quando due porte vengano aperte contem-
poraneamente. Lo stesso si concepisca in due versioni differenti: la prima usando solo ESPertino,
la seconda disegnando lo schematico a componenti discreti. Sarebbe interessante leggere le vostre
riflessioni. A presto.

Giovanni Di Maria

1
EDITORIALE MAKER ROBOT
Per i Makers, l’hardware Termocamera Corso sugli Aeromobili
diventa sempre più
1 3 6
VOLTCRAFT PT-32 a Pilotaggio Remoto
semplice partendo da zero:
Founder & Publisher Avvisatore di opportunità e problematiche
18
Emanuele Bonanni allagamento con
ESPertino IoT
Editor-in-Chief
Near Infra-Red:
Maurizio Di Paolo Emilio Mini registratore 13
33 una originale
allo stato solido con applicazione di IoT
Technical Editor
Giovanni Di Maria ESPertino
BOARD
Marketing Il Kit di ESPertino:
39 Starter Kit TRL 25
Sara Ercolani temperatura e umidità
Funksysteme
sotto controllo con il DHT11
Advertising
Michela Lemma SCI & TECH
WallPi: quando LEGO
michela@emcelettronica.com 46 Bitcoin: la moneta
incontra Raspberry Pi 28
decentralizzata
Circulation
Il Kit di ESPertino:
Users - 129.701 PCB
Social Network - 124.144 misuriamo le distanze 61
con il modulo a Il mercato Italiano dei
78
© Copyright ultrasuoni HY-SRF05 PCB
Tutti i diritti di riproduzione o di traduzione
degli articoli pubblicati sono riservati.
Manoscritti e disegni sono di proprietà di Controllo gestuale e
EMCelettronica Srl. 68
E’ vietata la riproduzione anche ausilio per non vedenti
parziale degli articoli salvo espressa con la scheda Arduino
autorizzazione scritta dell’editore. I
contenuti pubblicitari sono riportati senza [Progetti completi open
responsabilità, a puro titolo informativo. source]
Autorizzazione alla pubblicazione del
Tribunale MI n. 20 del 16/01/2006
 Termocamera
MAKER
VOLTCRAFT PT-32
di Maurizio Di Paolo Emilio

La termocamera permette di ottenere una distribuzione senza contatto della temperatura su superfici,
indicando punto-punto il valore come misurazione diretta. La telecamera Voltcraft può essere impiega-
ta per svariati materiali e superfici in diverse applicazioni.

INTRODUZIONE cazioni. Tramite una scheda SD rimovibile, posso-

U
na fotocamera termografica (chiamata anche no essere salvate le immagini termiche con i dati di
fotocamera a infrarossi o fotocamera termica o temperatura e timestamp. In questo modo è possibile
termocamera) è un dispositivo che forma un’im- una valutazione in un momento successivo dei dati di
magine utilizzando radiazioni a raggi infrarossi, simile misura (figura 1).
a una fotocamera comune che forma un’immagine con Le principali caratteristiche possono essere riassunte
luce visibile. Invece dell’intervallo di 400-700 nanometri nei seguenti punti:
della telecamera a luce visibile, le telecamere a infraros- • Display: 2,2” (5,6 cm), 320 x 240 Pixel.
si funzionano con lunghezze d’onda fino a 14.000 nm • Memorizzazione su schede MicroSDHC.
(14 μm). In linea generale, la radiazione più infrarossa • Valori emissioni regolabili.
viene emessa come radiazione corpo-nero. Una tele- • Unità temperatura ºC / ºF.
camera speciale può rilevare questa radiazione in un • Valori max./min.
modo simile in cui una telecamera normale rileva la luce • Scala cromatica, luminosità LED e temperatura
visibile. Il livello di luce ambientale non influenza la misu- retro regolabili.
ra, ottenendo anche una buona stima della temperatura • Galleria immagini.
in condizioni di oscurità totale. Ciò lo rende utile per le
operazioni di soccorso in edifici
di fumo e sotterranei. Una gran-
de differenza con le telecamere
ottiche sono le lenti di messa a
fuoco che non possono essere
fatte di vetro, devono essere uti-
lizzati materiali speciali come i
cristalli di germanio o zaffiro.
Le lenti al germanio sono anche
piuttosto fragili, quindi spesso
hanno un rivestimento duro per
proteggerle contro il contatto ac-
cidentale.

CARATTERISTICHE
La telecamera termica Voltcraft
consente di visualizzare la distri-
buzione della temperatura sulle
superfici, modificando a piaci-
mento le tavolozze dei colori al
fine di rendere più facile l’analisi.
Con le sue 6 combinazioni di co-
lori selezionabili, la PT-32 offre
una soluzione per tutte le appli- Figura 1: Termocamera Voltcraft

3
 MAKER

Ottica 38° x 38°

Lunghezza - Profondità 125 mm

Livello di emissioni (min.) 0.10

Risoluzione del display 320 x 240 Pixel

Tipo PT-32

Messa a fuoco Fuoco fisso

Frequenza immagine 9 Hz

Peso 494 g

Campo di misurazione temperatura (max.) +300 °C

Campo di misurazione temperatura (min.) -20 °C

Min. distanza di focalizzazione 50 cm

Memorie 24000

Tensione di alimentazione Batteria Li-Ion, 100 - 240 V/AC

Matrice bolometrica 32 x 31 Pixel

Display TFT a colori

Categoria Termocamera

Interfacce microSD

Precisione di base ± °C 2 °C

Livello di emissioni (max.) 1.00

Sensibilità termica 150 mK

Larghezza 58 mm

Combinazioni di colori 6

Altezza 205 mm

Precisione ± 2%

Tabella 1: caratteristiche tecniche della termocamera voltcraft

4
 MAKER
Figura 2: display della termocamera con le varie indicazioni
Incluso nella scatola abbiamo una custodia, la batteria
Li-Ion 3.7V, 1400mA, l’alimentatore USB con cavo, un
treppiede per meglio controllare la postazione fissa, una
SD da 4GB con adattatore SD e il manuale. In tabella 1
riportiamo le principali caratteristiche tecniche: il campo
di misura si estende da +300 °C fino a -20 °C con una
precisione di 2°C e una interfaccia display TFT.
L’immagine termica può essere di 0-100% in fasi del
25%, ottenendo un miglior orientamento e una visua-
lizzazione dei dettagli nei mini particolari. La compen-
sazione delle riflessioni sono rilevati da un sistema di
controllo riducendo così gli errori di misura. Le aree dei
picchi di freddo e caldo appaiono nell’immagine come
marcatore diretto. In questo modo è più veloce avere
una panoramica della distribuzione del calore (figura 2).
TERMOGRAFIA
La quantità di radiazione emessa da un oggetto aumen-
ta con la temperatura; quindi, la termografia permette di
vedere variazioni di temperatura. Gli oggetti caldi si di-
stinguono bene dagli ambienti più freddi; gli esseri uma-
ni e gli altri animali a sangue caldo diventano facilmente
visibili di giorno e notte. Di conseguenza, la termografia
è particolarmente utile per i militari e gli altri utenti delle
telecamere di sorveglianza. La termografia utilizza una
telecamera speciale per misurare la temperatura della
pelle sulla superficie del seno. È un test non invasivo
che non comporta alcuna radiazione. La termografia si
basa su due idee: poiché le cellule tumorali crescono e
5
si moltiplicano molto velocemente,
il flusso di sangue e il metabolismo
sono più elevati in una zona tumo-
rale. Inoltre, mentre il flusso di san-
gue e il metabolismo aumentano, la
temperatura della pelle aumenta.
La American Cancer Society non
raccomanda la termografia in so-
stituzione della mammografia. La
termografia può essere utilizzata
per integrare informazioni da un
mammografo e aiutare a identifica-
re i tumori che sono vicini alla pelle.
CONCLUSIONI
Una termocamera a infrarossi rileva
l’energia emessa da un oggetto, e
converte il tutto in un segnale elet-
tronico visivo affinchè si possa ave-
re una rappresentazione schemati-
ca della distribuzione di calore. Una
termocamera può essere impiegata
per monitorare l’andamento termico di un oggetto ma
anche per valutare problemi legati all’emissione di calo-
re. Una telecamera termica è in grado di eseguire algo-
ritmi per interpretare i dati e costruire un’immagine.
Anche se l’immagine mostra sul display una appros-
simazione della temperatura, la fotocamera utilizza in
realtà più fonti di dati in base alle aree che circondano
l’oggetto per determinare tale valore anziché rilevare la
temperatura effettiva
LA TELECAMERA VOLTCRAT PT-32 E’ DISPONIBILE
A CATALOGO CONRAD CON SPEDIZIONI 24H
L’autore è a disposizione nei commenti per eventuali
approfondimenti sul tema dell’Articolo. Di seguito il link per
accedere direttamente all’articolo sul Blog e partecipare alla
discussione:
https://it.emcelettronica.com/termocamera-voltcraft-pt-32
 Corso sugli Aeromobili a
R O BO T Pilotaggio Remoto partendo
da zero: opportunità e
problematiche
di Giuseppe Silano

Inizia con questo articolo una lunga serie di puntate dedicate agli Aeromobili a Pilotaggio Remoto
(APR). Si tratta, a tutti gli effetti, di un corso completo, pensato e dedicato, soprattutto, ai principianti
ed ai neofiti. Semplici lezioni, esempi e tanto altro chiariranno perfettamente le idee ed illustreranno,
in maniera estremamente semplice e chiara, i fondamenti della tecnologia, i principi di funzionamento,
lo stato dell’arte e la storia di questi magnifici velivoli. Si consiglia vivamente di seguire cronologica-
mente le lezioni che seguiranno, senza fretta ed impazienza nel terminare subito il corso, ma con la
consapevolezza di maturare i concetti presentati gradatamente nel tempo.

INTRODUZIONE dustriale, rendendo possibile la raccolta di misurazioni

N
egli ultimi decenni è molto cresciuto l’interesse
nei confronti della progettazione e dello svi-
luppo di piccoli velivoli sprovvisti di pilota UAV
(Unmanned Aerial Vehicle), più noti come droni, che in
maniera autonoma possano effettuare missioni sia mi-
litari che civili, quali inseguimento (appunto) di obietti-
vi mobili e non, monitoraggio ambientale, del traffico e
della sicurezza nelle città. Gli UAV sono sistemi inte-
grati relativamente complessi, in grado di spostarsi in
modo indipendente all’interno di un ambiente specifico,
equipaggiati con una strumentazione di bordo per la
navigazione e trasmissione dei dati e che, per questo,
hanno suscitato interesse anche nell’ambito della ricer-
ca scientifica, come abbiamo visto in un precedente ar-
ticolo.
STATO DELL’ARTE
La maggior parte delle applicazioni commerciali (alcu-
ne già citate in un precedente articolo) vedono gli UAV
impiegati come dispositivi per lo streaming di dati e vi-
deo ad una stazione centrale, comandi in remoto da un
supervisore (una persona) che sceglie di volta in volta
il prossimo compito da eseguire sulla base delle imma-
gini che vengono raccolte dalla camera presente sul
corpo del drone. La presenza della camera consente di
estendere le scarse capacità sensoriali di quest velivoli,
utilizzando concetti già noti nel campo della robotica in-
passive dell’ambiente circostante. La visione artificiale
consente così di creare un ciclo del tipo “guarda e poi
muovi”, un ciclo di comando dei movimenti del velivolo
con retroazione visiva. In altri termini, utilizzando un ci-
clo chiuso di posizionamento, la camera fornisce tutte
le informazioni necessarie all’aeromobile (vedi nota 1
a fine paragrafo) per l’attuazione della legge di control-
lo, formando un sistema che prende il nome di visual
servoing (asservimento visivo). Ciò consente di sfrut-
tare, nell’ambito più vario, noti nati per scopi commer-
ciali, riducendo notevolmente i costi, rendendo così la
tecnologia facilmente accessibile: tanti sono i modelli a
disposizione, differenti per prestazioni e dimensioni. Tali
caratteristiche li rendono estremamente personalizzabi-
li, quindi facilmente adattabili in funzione della specifica
applicazione di interesse.
Dal primo sistema di asservimento visivo, sviluppato nei
primi anni ‘80, i progressi nel controllo visuale dei robot
- si parla di robot, e non di UAV, perché quanto si sta
affermando abbraccia una più ampia schiera di dispo-
sitivi - sono stati abbastanza lenti, ma negli ultimi anni
grazie all’aumento della potenza computazionale della
scala di integrazione, è stato possibile installare schede
per l’elaborazione dati in real-time. Sistemi in grado di
garantire che un elaborazione (o task) termini entro un
dato vincolo temporale o scadenza (detta in gergo de-
adline). Il tempo per l’elaborazione deve essere minore

6
 ROBOT
Esempio-di-un-modello-visual-servoing
di quello con cui giungono i campioni, dunque il siste-
ma deve permanere in uno stato di hidle (attesa) per un
tempo non nulla tra un campione ed il successivo.
Tanto sono i lavori presenti in letteratura che impiegano
l’asservimento visivo per gli scopi più vari, ad esempio
per il controllo di robot manipolatori, per la pianificazio-
ne di percorsi, etc. Caratteristica comune a tutte le
pubblicazioni è l’utilizzo di paradigmi, quattro i più
diffusi:
• dynamic look and move: la visione fornisce i
punti nel quale il robot si deve portare, mentre
il controllore aziona gli attuatori in modo da as-
sumere la configurazione necessaria per il rag-
giungimento di tali punti;
• direct visual servo: il controllore è completa-
mente eliminato poiché il sistema visivo control-
la direttamente gli attuatori;
• position-based: le informazioni estratte dall’im-
magine (features, saranno approfondite nel cor-
so dei successivi articoli) vengono utilizzate per
ricostruire la posa (posizione/orientamento) 3D
corrente dell’oggetto rispetto alla telecamera. Si
genera un segnale di errore “cartesiano” dato
dalla differenza tra la posa 3D desiderata e quel-
la attuale.
• image-based: l’errore viene calcolato in 2D nel
piano immagine, senza stimare la posizione de-
gli oggetti esaminati. Il robot si muove in modo
da portare le features 2D osservate verso i valori
desiderati.
Per quanto concerne, invece, la telecamera si parla di
sistemi:
• eye to hand: la camera è in grado di muoversi in
completa autonomia rispetto alla posizione del
robot, variando i suoi tre gradi di libertà (yaw,
pitch e roll);
7
• eye in hand: la camera è fissata al corpo del
robot, tramite il suo movimento si cerca di man-
tenere il bersaglio nell’area di visione.
Una variazione a questi modelli include il posizionamen-
to di telecamera multiple, installate negli angoli di una
stanza dunque per applicazioni indoor, in grado di for-
nire una visione stereoscopica dell’ambiente. Tali appli-
cazioni, oltre ad avare un costo più elevato, presentano
anche problemi di gestione ed elaborazione di doppie
immagini. Nel corso di questi articoli ci si focalizzerà sul
modello rappresentato (Figura 1) image based utilizzan-
do la camera nella configurazione eye in hand.
In sintesi, la vetrina di ricerca sull’inseguimento visivo
di oggetti per UAV è molto varia, soprattutto in contesti
suburbani. La progettazione di un sistema di naviga-
zione per un robot volante, rispetto ad un equivalente
a terra, è un obiettivo non da poco perché richiede un
elevato numero di feedback per la stabilizzazione , e
coinvolge sistemi fortemente non lineari.
La capacità di identificare ed inseguire autonomamente
un oggetto arbitrario, oltre ad essere interessante già di
per se, trova facile applicazione negli ambienti civili in
particolare per tutto quello che è il contesto esplorativo.
Ad esempio, nell’ispezione di edifici con pericoli di crollo
o centrali nucleari dismesse, in contesti ambientali, e
così via. La grande forza di questo sistema è la sua at-
tuabilità anche in spazi non noti.
Nota 1: da non confondere con l’aeromodello, che a
differenza del primo è impiegato per scopi hobbistici o
sportivi: il volo avviene sotto il controllo visivo diretto e
costante dell’aeromodellista).
CONFIGURAZIONI PIÙ COMUNI
Si definisce rotorcraft, dall’unione di rotatory-wing ai-
rcraft, o aerogiro, un aeromobile ad ala rotante più pe-
 ROBOT
Figura 2: Distribuzione tipica delle eliche di un multi-rotore.
sante dell’aria che per volare utilizza la portanza gene-
rata da superfici alari dette pale in rotazione attorno ad
un albero. Diverse pale montate su di un unico albero,
in aeronautica, sono definite come un rotore (parte di
questi concetti sono stati affrontati in un altro articolo).
Il modello tipico che rappresenta questa classe di ve-
livoli è certamente l’elicottero che però, a causa delle
sue caratteristiche, è utilizzato soltanto nella sua veste
manned (vedi nota 2 a fine paragrafo).
Un multi-rotore (o multicopter) è un dispositivo in grado
di volare, composto di una parte centrale, che contiene
la maggior parte dell’elettronica, e più eliche a passo
fisso: a differenza dell’elica a passo variabile, non è
possibile agire sull’orientamento delle pale, ruotandole,
perché ancorate al mozzo. Per ragioni prestazionali, le
eliche sono tipicamente posizionate più lontano possibi-
le dal corpo del velivolo, come si può vedere in Figura 2,
mentre la maggior parte del peso è posizionato nel cor-
po (parte centrale). Inoltre, le eliche sono tutte orientate
parallelamente alla forza di gravità in modo che l’aerea
spazzata dalle pale sia perpendicolare, rispetto alla ter-
ra che funge da riferimento, alla forza di gravità.
In funzione del numero di rotori si parla di tricotteri,
quadricotteri, esacotteri ed ottocotteri, che utilizzano ri-
spettivamente un totale di tre, quattro, sei ed otto rotori.
Le versioni più utilizzate prevedono un minimo di quat-
tro rotori disposti in configurazione simmetrica a + o x
come mostrato in Figura 3.
Altre configurazioni, ma non sono poi così comuni, si
prestano al sollevamento di carichi da lavoro pesanti, e
per le principali missioni con esigenti standard di sicu-
rezza. In Figura 2 è riportato un ottocottero a configura-
zione a V, nel quale gli otto rotori sono equamente divisi
in due braccia divergenti.
La differenza principale tra le diverse configurazioni
è il carico di lavoro che esse sono in grado di so-
stenere: maggiore è il numero dei rotori, maggiore è
anche il carico di lavoro. Inoltre, un alto numero di rotori
assicura una maggiore affidabilità: la rottura di un roto-
re, o un suo malfunzionamento, non condiziona il prose-
guo della missione. Nel caso, poi, dei velivolo dotati di
un doppio rotore coassiale, la diminuzione del rapporto
peso/potenza consente, a parità di carico di lavoro, di
avere una maggiore manovrabilità.
Nota 2: Lo svantaggio dell’elicottero tradizionale è rap-
presentato dalla complessità della sua meccanica dif-
ficilmente riproducibile in piccola scala con sufficiente
precisione; i vincoli di peso e costo presenti nella rea-
lizzazione di un mini-UAV impongono, infatti, l’utilizzo di
materiale plastico, meno resistente delle leghe metalli-
che e molto più sensibile alla presenza di giochi mec-
canici.
PRINCIPI DI FUNZIONAMENTO
In questa sezione viene presentato in modo intuitivo il
funzionamento basilare che regola il volo di un si-
stema multi-rotore (sia esso un tri-, quadri-, esa- o
otto-rotore); questi concetti elementari non richiedono
un’approfondita conoscenza dell’hardware o del mo-
dello fisico, ma danno un’appropriata comprensione su
come funziona il velivolo.
Si prenda in considerazione lo schema del quadricotte-
ro in Figura 4, in rosso è rappresentata l’elica principale
8
 ROBOT
Figura 3: UAV a 4, 6, e 8 rotori in configurazioni + e x.
mentre i simboli z, φ, θ, ψ, si riferiscono rispettivamente
alla quota, agli angoli di pitch (beccheggio), roll (rollio) e
yaw (imbardata).
I quattro motori a bordo del velivolo sono comandati se-
paratamente; ogni motore produce una coppia che fa gi-
rare i rotori producendo così una spinta verticale. Come
in un elicottero, la coppia generata dai motori spinge il
corpo del quadri-rotore nella direzione opposta a quel-
la dei rotori: per evitare questo fenomeno i due rotori
presenti sullo stesso braccio ruotano in senso orario,
mentre gli altri due ruotano in senso antiorario. Il dro-
ne, dunque, riesce ad elevarsi da terra quando tutti
i rotori esercitano la stessa spinta: in questo caso il
vettore spinta è perpendicolare alla terra, ed il suo mo-
dulo eguaglia quello della forza di gravità che agisce
sull’UAV. L’aeromobile è in grado così di librarsi ad una
specifica altezza.
I movimenti laterali sono ottenuti, al contrario, dimi-
nuendo il numero di giri dei motori presenti su di un
lato ed incrementando, dello stesso valore, quelli po-
sizionati sul lato opposto. In questo scenario il quadri-
rotore sarà inclinato in avanti nel verso della propulsione
più debole, e continuerà a muoversi lateralmente finché
la spinta del velivolo non subirà variazioni. Questo mo-
vimento è indicato come pitch se il rotore che rallenta
è quello anteriore o posteriore, o roll se il rotore che
rallenta è quello posto sul fianco. Comunque, poiché il
veicolo è simmetrico rispetto al suo centro di gravità, la
9
scelta dell’orientamento è ininfluente per la dinamica.
Per ultimo, i movimenti rotazionali, anche detti di yaw,
possono essere ottenuti rallentando la velocità di rota-
zione delle due eliche opposte, ed aumentando dello
stesso valore quella delle restanti in modo che il vetto-
re spinta non venga influenzato. In questo modo l’UAV
ruoterà nella stessa direzione delle eliche più lente,
producendo una rotazione del corpo nella direzione op-
posta in accordo a quanto afferma la terza legge della
dinamica.
SCHEDE DI VOLO
Il componente principale di un multi-rotore è la
scheda di volo, come la ArduPilot Mega (APM). Si trat-
ta di un sistema di controllo open source (Commercial
Off-the-Shelf Component - COTS) progettato da una
comunità di hobbisti per piccoli aeromobili a pilotaggio
remoto. E’ correlato da una scheda sensori (Figura 5)
che ingloba al suo interno un accelerometro micro elet-
tromeccanico (MEMS), che effettua misure sui tre assi,
un giroscopio ed un pressostato. A corredare la senso-
ristica di bordo ci pensa un ricevitore GPS esterno, il
quale consente il volo anche in applicazioni outdoor.
Il software dell’autopilota, invece, gira su di un cir-
cuito separato (Figura 6) sul quale è installato un mi-
crocontrollore Atmel ATMega 2560, lo stesso che equi-
paggia Arduino. Questa board incorpora una funzione di
sicurezza che provvede a bypassare il sistema di con-
 ROBOT

automatiche in cui la gestio-

ne del motore è lasciata al
pilota, mentre i comandi sui
canali di orientamento sono
interpretati come set-point di
angoli di pitch e roll voluti;
• loiter: l’autopilota
interrompe la manovra in
esecuzione ed entra in una
traiettoria circolare (loiter)
centrata sulla posizione ge-
ografica attuale (ultimo dato
GPS ricevuto), di raggio e
quota predefiniti, con auto-
nomia decisionale sull’ango-
lo di rollio necessario;
• rtl (return to launch):
modalità failsafe in cui l’au-
topilota riporta il velivolo
Figura 4: Movimenti base di un quadri-rotore. Da destra verso sinistra e dall’alto verso il sulle coordinate geografiche
basso, sono rappresentati i movimenti verticali, di pitch, roll e yaw.
dove è stato acceso il siste-
ma, acquisito come “home
trollo automatico, spostandolo sul manuale (il comando location” al primo fix GPS valido, e lo mette in
passa ad una persona fisica grazie al radiocomando di attesa sopra di esso ad una quaota di sicurezza;
cui è dotato l’UAV), nel caso di malfunzionamenti. • auto: modalità completamente automatica, in
Il firmware a bordo della scheda di volo è scritto in C++, cui l’autopilota cerca di seguire dei waypoint
realizzato utilizzando le librerie standard di Arduino (caratterizzati da latitudine, longitudine e quota
(possibile perché entrambi montano lo stesso micro- GPS) pre-programmati in fase di pianificazione
controllore), e progettandone altre ad hoc per l’applica- di volo.
zione. L’intera documentazione, come anche i sorgen-
ti, sono disponibili alla consultazione e l’inserimento di
nuove funzionalità attraverso il portale del produttore
utilizzando il servizio GitHub.
Tante sono le modalità di funzionamento della sche-
da di volo, con gradi crescenti di autonomia, sia a livello
di stabilizzazione automatica del velivolo, sia a quello di
navigazione, secondo i seguenti flight mode predefiniti:
• manual: controlli completamente manuali trami-
te radiocomando (la scheda di volo copia diretta-
mente i segnali ricevuti in ingresso dalla riceven-
te alle uscite dei servocomandi);
• stabilize: il sistema porta automaticamente
l’UAV in volo livellato (roll e pitch nulli) quando gli
stick sul radiocomando sono portati in posizione
neutra (il comando del motore throttle rimane in- Figura 5: ArduPilot Mega IMU Shield.
vece impostato sul manuale);
• circle: il velivolo viene posto ad un angolo di La logica di controllo dell’autopilota nelle modalità di
rollio costante (selezionabile) e tenuto indefini- volo automatiche è basata su un doppio anello PID
tamente in virata, senza però mantenere la posi- (Figura 7), un intero di stabilizzazione ed uno esterno
zione GPS del centro della traiettoria; di navigazione (indicati nel gergo del codice ArduPilot
• fly by wire A e B: si tratta di due modalità semi- Mega rispettivamente come servo-loop e nav-loop).

10
 ROBOT
Figura 6: ArduPilot Mega Main Board.
Molti sono i gruppi o gli istituti di ricerca che han-
no costruito la propria scheda di volo, realizzata per
specifici obiettivi. Il successo accademico riscontrato ha
permesso poi la produzione su grande scale, come nel
caso della X4-flyer, la OS4, la STARMAC, e la Pixhawk,
giusto per citarne alcune.
Nella maggior parte dei casi le OSPs (Open Source
Projects) utilizzano le community presenti in rete (ad
esempio Google Code e GitHub) per distribuire codice,
schematici, mettendoli in rete sotto licenza open souce
(GPL). Ciò consente non solo di velocizzare il processo
di produzione del software inserendo sempre più fun-
zionalità, sviluppate dai tanti che vogliono attivamente
prendere parte al progetto, ma consente anche di te-
starle, liberando gli sviluppatori da questo onere esclu-
sivo consentendo loro, così, di concentrarsi su altro.
Inoltre, i feedback che giungono in tempo reale, di test
condotti in diverse condizioni e configurazioni, permet-
tono di rendere il software più robusto in tempi relativa-
mente brevi.
Oltre alle OSPs, sul mercato sono disponibili tanti
esempi proprietari, come la DJI Wookong sviluppata
dall’omonima azienda, in grado di adattarsi a diversi tipi
Figura 7: Struttura PID in ArduPilot.
11
di hardware a patto che rispettino le caratteristiche for-
nite dal produttore del sistema di controllo. Le aziende
propongono sistemi built-in, pronti per essere utilizzati
da cineamatori oppure inserite all’interno di scenari più
complessi. Alle volte queste schede sono accompagna-
te da apposite SDK (Software Development Kit), le qua-
li consentono l’integrazione con smartphone, tablet, e
l’aggiunta di nuove funzionalità al palinsesto già offerto.
Tali soluzioni, ovviamente, non mettono a disposizione
il codice, né la legge di controllo utilizzata, sono dunque
difficili da integrare all’interno della ricerca, soprattutto
quando l’obiettivo è sviluppare nuovi regolatori.
In sintesi, la scelta non è sempre facile. Si può optare
per schede di volo OSPs, come l’ArduPilot Mega quan-
do l’obiettivo è velocizzare il processo di produzione del
software di applicazioni custom che debbono interfac-
ciarsi con liberie il codice e metodi devono essere quan-
to più chiaro possibile. Al contrario, la scelta migliore è
rivolgersi a soluzioni proprietarie, che presentano un
grado di affidabilità maggiore, quando l’idea è quella di
realizzare applicativi ad un livello più alto.
PROTOCOLLO DI COMUNICAZIONE
ArduPilot, come anche altre OSPs, utilizza MAVLink
come protocollo di comunicazione per lo scambio
dati: sistema a due vie basato sullo standard W-CAN
e SAE AS-4. Sviluppato per il progetto Pixhawk, e poi
divenuto lo standard per UAV di piccole dimensioni per
la sua leggerezza ed efficienza.
MAVLink è una semplice libreria di intestazione (he-
ader file), che implementa diversi messaggi d’uso
comune per l’aggiornamento delle impostazioni, la
lettura dei dati provenienti dai sensori, il cambio dei
modi di volo automatici (vedi paragrafo precedente)
e l’invio dei comandi di controllo. Se necessario, è
possibile generare delle custom message utilizzando C
o Python, nel secondo caso il tool pymavlink ne facilita
 ROBOT
Figura 8: Struttura pacchetto MAVLink.
la creazione.
Un pacchetto di messaggi ha una lunghezza variabile,
compresa tra gli 8 ed i 263 bytes, dove è il tipo di mes-
saggio a determinare la lunghezza del carico di lavoro.
Il formato del pacchetto è mostrato in Figura 8.
Il primo byte (str) rappresenta il segno, a seguire (lgt)
che indica il payload. Il terzo byte, invece, specifica
la sequenza del pacchetto: rappresenta il numero di
messaggi che sono stati generati durante la sessione
corrente. Questo numero viene automaticamente incre-
mentato ad ogni nuovo messaggio.
Il quarto (sys) ed il quinto (msg) byte esprimono l’ID del
componente e quello del sistema: consentono l’invio
del multiplo dello stesso messaggio a più componenti o
sistemi, naturalmente il suo contenuto può essere indi-
rizzato anche ad uno soltanto (componente o sistema).
Il sesto byte (msg) fornisce l’ID del messaggio: determi-
na la funzione che sarà invocata, alla quale saranno poi
passati i dati contenuti nel/i byte/s successivo/i.
Gli ultimi due bytes (cks) si rendono necessari per il
controllo dell’integrità del messaggio: confrontando i
checksum si decide se accedere al contenuto, e con-
seguentemente passare i dati alla funzione indicata
dall’ID. Tutto ciò condiziona il numero di messaggi che
può essere inviato al secondo, determinato dalla veloci-
tà della connessione seriale e dalla grandezza del pay-
load. Tipicamente si preferiscono basse velocità (57600
bps), rispetto alla massime offerte dal canale (115200
bps), per garantire meno errori durante la comunicazio-
ne, scongiurando così un eventuale perdita di pacchetti.
I messaggi possono essere codificati dal Mission
Planner, installato sulla stazione di controllo cen-
trale, inviati via USB-UART oppure attraverso il
sistema di telemetria (non possono essere utilizzati
contemporaneamente, nel caso di simultaneità nella
trasmissione dei dati viene data priorità all’USB igno-
rando completamente il sistema di telemetria).
MAVLink definisce un numero fissato delle informazioni,
conseguentemente dei pacchetti, che è possibile tra-
smettere:
• informazioni in merito all’assetto (ψ, θ, φ, x, y, z);
• informazioni dal GPS (latitudine, longitudine, al-
titudine, percorso, velocità);
• lo stato del sistema (modalità di volo automatica,
carica residua della batteria, etc.).
A conclusione dell’articolo, è utile segnalare
MavProxy: una stazione di controllo centrale open
source multi piattaforma (Windows, Linux e Mac), scrit-
ta in Python, che utilizza il protocollo MAVLink per lo
scambio dati ed il controllo di MUAVs (Micro Unmanned
Aerial Vehicle). La sua struttura minimale, portabile ed
estendibile, ne giustificano l’impiego come strumento
per l’interfacciamento da remoto con le schede di volo
che supportano il protocollo.
CONCLUSIONI
L’interesse cresciuto nell’ultimo decennio nei confronti
della tecnologia, accompagnato dallo sviluppo di piat-
taforme hardware & software sempre più facili da utiliz-
zare e che si avvicinano alle diverse tipologie di utenze
(ludiche e/o commerciali), rendono necessario un ap-
profondimento da qui la nascita del mini corso. Come
abbiamo visto in questo articolo il problema della per-
cezione, che combina camere e sensori di bordo, si mi-
schia a quello del controllo, che varia di complessità a
seconda degli utilizzi e sopratutto dei costi. Dunque,
per orientarsi in questo mercato sempre più frenetico e
ricco di prodotti, è necessario capire quali sono le con-
figurazioni più comuni e cose le differenzia, i principi di
funzionamento, le schede di volo e loro peculiarità, e
non per ultimo il protocollo di comunicazione.
Questa è solo la prima delle quattro puntate che com-
porranno il mini corso. Ogni puntata sarà contraddistinta
da informazioni utili sulla strada su cui si muove la ricer-
ca oltre a concetti chiave per capire e sfruttare al meglio
i velivoli a nostra disposizione.
Non mi resta che augurarvi: buona lettura!
L’autore è a disposizione nei commenti per eventuali
approfondimenti sul tema dell’Articolo. Di seguito il link per
accedere direttamente all’articolo sul Blog e partecipare alla
discussione:
https://it.emcelettronica.com/corso-sugli-aeromobili-a-pilotaggio-
remoto-partendo-da-zero-opportunita-e-problematiche
12
 Near Infra-Red:
IoT una originale
applicazione di IoT
di Giorgio Giaccaglini

Quante volte di fronte a un alimento che stiamo per comprare al supermercato ci siamo domandati di
quali ingredienti sia la sua effettiva composizione oltre a quella indicata sull’etichetta del prodotto? O
quale contenuto di grassi, di zuccheri sia racchiuso nelle appariscenti e allettanti pietanze che stiamo
per mangiare? Un’azienda israeliana ha realizzato uno spettrometro di massa NIR (Near Infra-Red) per
scoprire la composizione molecolare delle sostanze.

L’ACCORDO re degli oggetti che circondano la nostra vita (figura 1).

C
onsumer Physics Inc. è una startup israeliana
nata nel 2011 il cui obiettivo visionario ­– sono
loro parole – era quello di costruire uno spettro-
metro di massa che si potesse tenere nel palmo di una
mano. A giudicare dai lanci pubblicitari e dai riconosci-
menti tecnologici raccolti in questi ultimi mesi, sembra
proprio che la visione dei fondatori sia diventata realtà.
SCiO, questo è il nome del prodotto, è una scatoletta
delle dimensioni di 54 x 36,4 x 15,4 mm (figura 1) e del
peso di 35 grammi capace, secondo le affermazioni del-
la startup, di riconoscere la composizione molecola-
Figura 1: SCiO, lo spettrometro di massa NIR portatile della Consumer
Physics.
L’aspetto innovativo di questo prodotto non risiede in un
originale algoritmo elaborativo o in una tecnologia mai
utilizzata prima. Anzi, il principio di funzionamento dello
spettrometro di massa non è certo una novità. Le ingom-
branti dimensioni degli apparati elettronici con cui viene
realizzato ne confinavano però l’utilizzo in laboratori o in
grossi ambienti industriali (figura 2). La sfida dei tecnici
della Consumer Physics è stata quella di realizzare un
dispositivo dalle misure ridotte sfruttando le tecnologie
più avanzate e aggiornate nel campo dell’ottica e della
microelettronica.
Il fatto di portare a livello consumer, e
quindi a un mercato enorme di potenziali
consumatori, un oggetto dotato di un sen-
sore capace di riconoscere quale sia la
composizione molecolare delle sostanze
che mangiamo, tocchiamo e, in genere,
fanno parte delle nostre vite, ha destato
l’interesse dalla Analog Devices Inc.,
uno tra i maggiori produttori di com-
ponenti elettronici a livello mondiale.
Tra le due aziende, la multinazionale e la
start-up israeliana, è stato stipulato un ac-
cordo di collaborazione. In poche parole,
Analog Device andrà ad utilizzare, con op-
portuni improvement tecnologici, le solu-
zioni implementate su SCiO. È gioco forza
pensare che lo spettrometro di massa non
sarà implementato solo nella scatoletta
mostrata in figura 1, ma è desiderio del-
la Analog Devices inserirne l’applicazio-
ne nel promettente mondo dei sensori e
dell’Internet of Things.

13
 IoT
Figura 2: spettrometro di massa da laboratorio
FUNZIONAMENTO DELLO SPETTROSCO-
PIO NIR (NEAR INFRA-RED)
Ma qual è il principio di funzionamento di uno spettrome-
tro di massa NIR (Near Infra-Red). L’esposizione eviterà
di proposito aspetti e dati accademici allo scopo di non
tediare il lettore su una trattazione che, approfondendo-
la, necessiterebbe pagine e pagine di testi universitari.
Prima di tutto andiamo ad affrontare un piccolo ripasso,
propedeutico per capire il funzionamento dello spettro-
metro di massa, sulle caratteristiche fisiche della luce.
LA DOPPIA PERSONALITÀ DELLA LUCE
Partiamo subito con l’affermazione che la luce ha una
doppia personalità:
• da una parte essa si comporta come un’onda
elettromagnetica;
Figura 3: lunghezze d’onda nello spettro della luce visibile
14
• da un altro punto di vista essa è trasportata da
particelle chiamati fotoni.
Lo spettro elettromagnetico della luce visibile è compo-
sto da una serie di onde la cui frequenza f (o lunghezza
d’onda λ= 1/f) varia a seconda del colore manifestato.
Per esempio la luce blu ha una lunghezza d’onda più
corta rispetto a quella della luce rossa. In figura 3, vie-
ne rappresentato la variazione delle lunghezze d’onda
della luce visibile nelle diverse manifestazioni di colore.
Sotto un altro punto di vista, tuttavia, la luce non si pro-
paga come un’onda, ma è trasportata da particelle chia-
mate fotoni. Ma i due comportamenti della luce, quella
di comportarsi come un’onda (con frequenza e lunghez-
za d’onda) e quelle corpuscolare che gli permette di pro-
pagarsi tramite entità chiamate fotoni, non sono antiteti-
che fra loro. Anzi, sono legate da una relazione che lega
 IoT
l’energia trasportata dal fotone alla frequenza dell’on-
da stessa. Per cui, se con λ indichiamo la lunghezza
d’onda, con f la frequenza e con E l’energia del fotone,
possiamo ripescare dai nostri ricordi scolastici, la ben
nota relazione: E = h f = h c/ λ dove h è la costante di
Planck (la costante che prende il nome del fisico Max
Planck che la scopri nel 1900). Per riassumere all’estre-
mo i concetti espressi poco sopra, possiamo affermare:
quando una onda di luce si propaga con lunghezza
d’onda λ, essa è trasportata da un certo numero di foto-
ni ciascuno dei quali ha una energia pari a hc/ λ.
Ma i fotoni sono, per così dire, esseri bizzarri: prima di
tutto non hanno massa e in secondo luogo sono capaci
di apparire o scomparire nel nulla. Ovviamente nean-
che loro, per i fotoni, il principio di conservazione
dell’energia è una opinione, e se un fotone decide
di scomparire, l’energia da lui posseduta deve essere
ceduta a qualcuno disposto a prenderla. Se un fotone
compare dal nulla, questo avviene se e solo se qualcu-
no è disposto a cedere energia. Ci stiamo avvicinando
al nocciolo del funzionamento del nostro spettrometro di
massa: il fotone che scompare.
UN QUANTUM DI ENERGIA
Ma perché il fotone scompare?
La materia è composta da molecole e le molecole da
gruppi di atomi strettamente connessi tramite legami
chimici. Gli atomi hanno una propria massa, diversa da
atomo ad atomo, e opportunamente sollecitati possono
entrare in vibrazione. Il modo in cui una molecola può
entrare in vibrazione è unico in quanto legato dal tipo
e numero di atomi e dai legami chimici che li tengono
stretti. Insomma, se riuscissimo a mettere in vibrazione
una molecola e ad osservarne il modo in cui essa vi-
bra, avremmo una visione unica per ogni molecola: una
specie di impronta digitale della molecola sotto esame.
Andando poi a ricercare questa impronta digitale in un
enorme database in cui sono memorizzate le vibrazioni
molecolare di tutte le molecole note allo scibile umano,
sarà possibile ricavare informazioni dettagliate sul no-
stro ricercato (avere appunto le generalità della mole-
cola sotto esame). Dobbiamo quindi trovare il modo di
mettere in vibrazione una molecola e catturare la sua
impronta digitale.
DUE PAROLE DI MECCANICA QUANTISTICA
Tranquilli. Non ho intenzione di parlare di formulazione
Lagrangiana o Hamiltoniana della meccanica quantisti-
ca. Due parole solo per capire come il nostro fotone,
possa aiutarci per ricavare l’impronta digitale (la vibra-
zione unica) di una molecola.
Nella fisica “classica” il termine di vibrazione di un siste-
ma è sinonimo di oscillazione armonica rispetto alla sua
posizione di equilibrio e la forza applicata per indurre
tale perturbazione è proporzionale alla perturbazione
stessa (es. un corpo collegato a una molla allontanato
dal suo punto di equilibrio).
Nel caso delle molecole, le vibrazioni non vengono de-
scritte dalla classica oscillazione armonica, bensì tra-
mite una versione per così dire, “quantistica”. Se nella
oscillazione armonica classica la quantità di energia
varia in modo continuo, nel caso della oscillazione ar-
monica quantistica l’energia che entra in gioco varia
solo in quantità discrete e ben definite. In pratica, una
molecola può cambiare la sua energia (acquisirla o per-
derla ed entrare in vibrazione) per quantitativi discreti.
L’insieme di questi quantum di energia di cui è dotata
una molecola, è una specie di patrimonio genetico della
molecola stessa: sono unici e ben definiti. Questi quan-
tum di energia sono le impronte digitali che andavamo
cercando.
E i fotoni cosa c’entrano? Precedentemente abbiamo
affermato che i fotoni hanno la bizzarra abitudine di
scomparire qualora decidessero di cedere la loro ener-
gia a un atomo con cui hanno, lasciatemi passare il
termine, una certa simpatia. Questo avviene qualora il
quantitativo di energia posseduto da un fotone, coinci-
de esattamente con uno dei livelli “discreti” (quantum di
energia) posseduti dall’atomo colpito dal fotone stesso.
A questo punto, dal momento che:
1. Il fotone possiede una energia il cui valore è le-
gato dalla propria lunghezza d’onda (E = h f =
h c/ λ),
2. Il fotone può cedere il suo quantum di energia
ad un atomo che possiede esattamente quel
quantum di energia,
riusciamo a dedurre il principio di funzionamento di
uno spettrometro di massa.
1. viene illuminato il campione sotto esame con
una sorgente di luce visibile a larga banda;
2. la luce riflessa viene raccolta e analizzata nel
suo spettro elettromagnetico;
3. si confronta lo spettro della luce inviata con
quello della luce riflessa e tramite una algorit-
mo comparativo (alcuni fotoni sono scomparsi in
quanto assorbiti dagli atomi) si decifra l’impron-
ta digitale della materia sotto esame.
4. l’impronta digitale molecolare viene inviata a un
database con la quale si va a rintracciare nome
e cognome della sostanza.
15
 IoT

Figura 4: sensore presente in SCiO.

DISPOSITIVO SCIO le sostanze. Una parte delle informazioni sono messe

A questo punto torniamo a SCiO, il dispositivo realizza- a disposizione dalla Consumer Physics. Altri database
to dalla Consumer Physics. Il componente base che si possono essere costruiti dall’utente stesso (ad esempio
preoccupa di inviare il flusso luminoso e catturare quello per una sostanza di suo interesse e non presente nel
riflesso dalla sostanza sotto esame, è mostrato in figura database della Consumer Physics), attraverso un certo
4. numero di misure preventive al fine di raggiungere una
E’ questo il sensore che si preoccupa di:
• inviare fotoni con energie diverse dal momento
che tutto lo spettro del visibile viene inviato;
• di catturare la luce riflessa privata dei fotoni che
hanno ceduto energia alla materia.

Una parte di quella luce incidente verrà assorbita dalle

molecole che sono in “sintonia” con i quantum di ener-
gia incidente. Alcuni fotoni scompariranno (variazione di
energia) e non saranno più presenti nella luce riflessa
che ritorna al dispositivo SCiO. La differenza nell’ana-
lisi spettrale tra la luce riflessa e quella incidente
fornirà l’impronta digitale della sostanza indagata.
Inviando questa impronta digitale a un vasto database
di impronte digitali, ricaveremmo informazioni del ricer-
cato.
Nella figura 5 viene mostrato lo schema complessivo
di funzionamento dell’apparato. Possiamo vedere come
le informazioni decifrate da SCiO vengano trasmesse
a corto raggio a un dispositivo smartphone (bluetooth
è la tecnologia utilizzata), il quale a sua volta esegue
una connessione con il cloud fornito dalla Consumer
Physics. È qui, nei server della azienda israeliana, che
è situato l’enorme database con le impronte digitali del- Figura 5: schema architetturale di funzionamento di SCiO

16
 IoT
sorta di affidabilità statistica.
IL PERCHÉ DI UN ACCORDO
A questo punto è lecito domandarsi perché la Consumer
Physics ha accettato un accordo di collaborazione con
un colosso come Analog Devices nel momento stesso
in cui si presenta sul mercato? Quali sono le sinergie
racchiuse in tale collaborazione?
Per quanto riguarda l’Analog Devices, la risposta è
semplice. Una fetta imponente del portfolio di pro-
dotti della casa di semiconduttori, è rappresentata
dal mercato dei sensori. L’Analog Devices ha pratica-
mente di tutto: dispositivi MEMS (Micro Electro-Mecha-
nical System) per misurare accelerazione e riconoscere
movimenti e vibrazioni, giroscopi per determinare il mo-
vimento angolare di un oggetto, sensori ad effetto Hall
per la misura di un campo magnetico, sensori ottici con
frequenze di utilizzo che vanno dall’ultravioletto all’in-
frarosso, sensori per il rilevamento della temperatura,
dell’umidità e… l’elenco sarebbe ancora lungo. Aggiun-
gere al suo ventaglio di sensori, un spettrometro di mas-
sa NIR miniaturizzato era quasi un obbligo sta nel DNA
dell’azienda
D’altra parte, parlando della Consumer Physics, non
credo che la start-up israeliana potesse accontentarsi
degli incassi provenienti da un dispositivo palmare, inte-
ressante certamente, ma che agli occhi dei non addetti
ai lavori sembra poco più di un giocattolo. Dopo anni di
sviluppo e di investimenti, Consumer Physics doveva
far fare un salto di qualità al proprio prodotto. E l’accor-
do con Analog Devices va in quella direzione.
INCREMENTI TECNOLOGICI
Vediamo come lo Spettrometro di massa della Consu-
mer Physics potrebbe fare un salto tecnologico tramite
l’accordo con l’Analog Device. Come affermato dal di-
rettore degli “emerging business” Alain Guery, il disposi-
tivo della Consumer Physics potrebbe essere ridotto
in un chip dalle dimensioni di 3 millimetri quadrati,
area che lo renderebbe installabile in ogni smart de-
vice. Potrebbe essere quindi inserito in ogni smartpho-
ne e smartwatch alla stregua di quello che oggi si fa con
un ricevitore GPS. Già qui si comprende quanto gran-
de sia la fetta di mercato potenziale per la tecnologia
di Consumer Physics. Ma uno spettrometro di massa
avrebbe senso anche installarlo, a differenza di una an-
tenna GPS, in ogni elettrodomestico. Basti pensare a
un frigorifero capace di rilevare la crescita abnorme di
pericolosi batteri, o bottiglie intelligenti che segnalano la
presenza di liquidi non commestibili al loro interno, o la-
vatrici capaci di verificare la qualità dell’acqua o il livello
dello sporco, o climatizzatori che verificano la presenza
di batteri nei propri filtri. Insomma, un ulteriore shrink
tecnologico del prodotto SCiO da parte dell’Analog De-
vices, potrebbe dare alla Consumer Physics una visibi-
lità e uno sviluppo imponente.
ALCUNE CRITICHE
Ovviamente, ogni medaglia ha una doppia faccia. Se
ridurre le dimensioni del sensore significa fornire un
impulso imponente alle possibilità commerciali del di-
spositivo, il prezzo da pagare per una miniaturizzazione
tecnologica potrebbe essere quello di una minore ac-
curatezza nel comprendere la natura molecolare della
sostanza da analizzare. Alla base di questa osserva-
zione sono le parole di Lawrence Ziegler, professore
alla Boston University impegnato nello studio della
spettroscopia NIR, le quali affermano che l’abilità di
uno spettrometro di massa di selezionare le diverse
caratteristiche di una sostanza dipende dalla sua di-
mensione. In pratica, è molto difficile, secondo il pen-
siero di Ziegler, andare ad operare con il meccanismo
di luce incidente e riflessa, e allo stesso tempo essere
selettivi, con dispositivi molto piccoli come quelli che po-
trebbero essere implementati su un smartphone o un
smartwatch. “Non vedo come si possa ottenere la se-
lettività sufficiente per individuare con correttezza una
sostanza”, sono le sue parole. Per correttezza di infor-
mazione, bisogna aggiungere che in questa agorà di
discussione tecnologica, altri professori, Shyamsunder
Erramilli, professore di fisica e ingegneria biomedica al
Boston University’s Photonics Center, sono più speran-
zosi. Secondo il suo parere, la minore precisione nei
dati raccolti dal dispositivo, potrebbero essere in qual-
che modo compensata da un enorme database delle
“impronte digitale” catturate. In sostanza, una indagine
statistica andrebbe a suggerire, con una certa accura-
tezza, quale, statisticamente parlando, sia la molecola
sotto esame. “Sebbene”, aggiunge lo stesso Erramili,
“ho delle perplessità nel caso delle discriminazione per
contaminazioni batteriche”. Vedremo. Di sicuro, se un
colosso dei semiconduttori come Analog Devices si è
mosso, l’ha fatto perché vede delle notevoli potenzialità
al suo mercato. E la Consumer Physics fa bene ad es-
sere fiera del proprio prodotto.
L’autore è a disposizione nei commenti per eventuali
approfondimenti sul tema dell’Articolo. Di seguito il link per
accedere direttamente all’articolo sul Blog e partecipare alla
discussione:
https://it.emcelettronica.com/near-infra-red-una-originale-
applicazione-di-iot
17
 Avvisatore di allagamento
MAKER
con ESPertino di Giovanni Di Maria

Grazie alle sue possibilità intrinseche di collegarsi a Internet, ESPertino può rivelarsi un utile avvisato-
re di allagamento di un ambiente. Il progetto utilizza anche uno dei relè a bordo per innescare il potente
avviso di una sirena a 12 Volt. L’articolo è molto didattico poiché esplora tante possibilità offerte da
questa magnifica scheda.

INTRODUZIONE qua, tra i due contatti non vi è alcuna continuità elet-

I
l dispositivo presentato in questo articolo è interes-
sante e utile in molte occasioni. Può essere utilizza-
to per la sicurezza negli esercizi pubblici, ristoranti,
alberghi, uffici ma può fornire tutta la sua utilità anche
in ambito casalingo e domestico. Si tratta di un senso-
re di allagamento molto rudimentale quanto efficace
che, in caso d’importanti perdite d’acqua non previste,
provvede subito ad avvertire i proprietari, mediante di-
versi canali di comunicazione. Il tempestivo intervento
dell’uomo, infatti, può scongiurare allagamenti ben più
gravi, permettendo agli operatori di chiudere in tempo
valvole e rubinetti interrompendo, di fatto, il pericoloso
flusso d’acqua.
PRINCIPIO DELLA RILEVAZIONE DELL’ACQUA
Il dispositivo descritto è fornito di due puntali o di due
piastre metalliche e conduttive (vedi figura 1) che sono
poste, praticamente sul pavimento. In mancanza d’ac-
trica. La resistenza risultante è, dunque, quasi infinita.
In presenza d’acqua, invece, si instaura un lieve pas-
saggio di elettroni tra le due parti. Il prezioso liquido,
infatti, presenta una determinata resistenza elettrica
che, seppur abbastanza alta e non matematicamen-
te lineare alle diverse condizioni fisiche e chimiche, è
sufficiente a innescare il circuito di rilevazione. L’acqua
salata riesce a condurre ancora molta più corrente. Per
l’utilizzo continuativo del circuito, non esiste il problema
di una eventuale elettrolisi, in quanto il dispositivo opera
sempre in stato di riposo, ossia senza la presenza del
liquido tra i contatti. I momenti in cui l’acqua si trova a
contatto con le sonde, dunque, sono molto limitati, anzi,
davvero rari (si spera) e corrispondenti esclusivamente
agli accadimenti degli allagamenti.
PROTOTIPO DI PROVA
Prima di proseguire con la realizzazione dello schema

Figura 1: le piastre metalliche per la rilevazione della presenza dell’acqua

18
 MAKER

Figura 2: schema di principio per il test della conducibilità dell’acqua

definitivo, è molto utile e didattico provare, con uno
sketch minimale, la conduttività dell’acqua. Il circuito di
test non ha bisogno di amplificatori di segnali poiché
lo stesso sfrutta l’alta impedenza degli ingressi digi-
tali di ESPertino (HIGHZ). Lo schema di prova è mo-
strato in figura 2.
Come si nota, la porta d’ingresso GPIO34 è collegata
a massa attraverso una resistenza di alto valore (com-
presa tra 100kohm e 1 Megaohm). Questa componen-
te assicura un potenziale basso a riposo (resistenza di
pull-down) quando i due puntali non sono collegati tra
loro e non scorre alcuna corrente tra essi. La presenza
dell’acqua, invece, chiude il circuito, causando un de-
bole passaggio di elettroni e la porta GPIO34 commuta
nettamente e decisamente il suo stato a livello logico
alto, grazie alla sua alta impedenza. Per aumentare
ancor di più la sensibilità della porta è sufficiente alzare
il valore della resistenza anche a 3-4 Mohm. Cos’è che
fornisce la tensione positiva per alimentare il circuito di
rilevazione? Lo stesso ESPertino, tramite il suo pin di
alimentazione etichettato con 3.3V. Senza la resistenza
di pull-down le rilevazioni potrebbero risultare casuali e
impreviste, per cui la sua presenza è obbligatoria.
Il seguente sketch di prova serve per effettuare il test. E’

void setup() {

pinMode(34,INPUT); // Ingresso digitale per il sensore (1/0)

pinMode(13,OUTPUT); // Uscita per il diodo Led

void loop() {

bool stato=digitalRead(34); // Legge l’ingresso digitale

digitalWrite(13,!stato); // Visualizza lo stato in negazione

delay(100); // Pausa di attesa

19
 MAKER

sufficiente riempire un bicchiere d’acqua dal rubinetto. passare a descrivere il prototipo definitivo, assieme alle
Se i due terminali non sono immersi, il diodo Led onbo- sue funzionalità. In caso di rilevazione di perdita d’ac-
ard, collegato alla porta 13 di ESPertino, resta spento. qua da parte del sensore, il prototipo eseguirà i seguenti
Non appena i puntali sono sommersi dal liquido, si otter- compiti d’informazione, come mostrato in figura 3:
rà la netta e immediata illuminazione del semicondut- • Illumina il diodo Led presente sulla scheda
tore. Si ricorda altresì che in presenza di acqua salata ESPertino;
il passaggio degli elettroni è di gran lunga superiore. Il • Attiva il relè a bordo della scheda. Esso può pi-
diodo Led onboard ha un funzionamento “al contrario”. lotare piccoli carichi come sirene, avvisatori acu-
Per illuminarlo, infatti, occorre portare il suo catodo a stici e luminosi, elettrovalvole o elettroserrature
livello logico basso. oppure ulteriori relè per comandare utilizzatori
Il listato è semplicissimo. La porta 34 è posta in ingresso ancora più grossi;
mentre la porta 13 è configurata in uscita per il pilotaggio • Invia un messaggio SMS a uno o più numeri di
del diodo Led. La funzione loop() legge ciclicamente lo telefono programmati;
stato logico della porta 34. Il relativo stato è “riversato”
e assegnato alla porta 13 per la relativa illuminazione. Leggi anche: Realizziamo un sistema di monitorag-
Questa operazione è effettuata in forma negata poiché gio grafico delle temperature con ESPertino
il catodo del Led è collegato alla porta di uscita dell’E-
SP32 (vedi schema elettrico ufficiale di ESPertino). IL CABLAGGIO DEL SISTEMA
Esaminiamo, adesso, lo schema elettrico di cablaggio,
IL PROTOTIPO molto simile a quello di principio visto nel precedente
Bene, dopo che la teoria è stata esaminata e che il fun- paragrafo e mostrato in figura 4. In aggiunta è stato uti-
zionamento di principio è stato ben compreso, si può lizzato uno dei due relè presenti sulla scheda. Il fatto
che ESPertino disponga
di tali componenti mec-
canici costituisce indub-
biamente una estrema co-
modità. A essi può essere
connesso davvero di tutto,
purché non vengano su-
perate importanti coeffi-
cienti di potenze. Il colle-
gamento del carico (sirena
o avvisatore luminoso) fa
capo al contatto N.A. (nor-
malmente aperto) del relè,
ossia il contatto centrale e
quello superiore. In caso
di sua eccitazione, il cir-
cuito viene chiuso e l’uti-
lizzatore a esso collegato
è attivato. Se il progetto lo
richiede, è possibile usa-
re anche il contatto N.C.
(normalmente chiuso).
Per l’allestimento dei
due sensori del liquido è
possibile adottare diversi
metodi. Uno dei più
validi è quello proposto
precedentemente in
Figura 3: le attivazioni del sistema, in caso di allagamento [segue a pag. 32]

20
 MAKER

//------------------------------------------

// Avvisatore di ALLAGAMENTO con ESPertino

// by Giovanni Di Maria

//------------------------------------------

#include <WiFi.h>

char* ssid = “NETGEAR-gio22”;

const char* password = “marcella”;

const char* host = “adminsms.aruba.it”;

int ACQUA = 34; // Pin del sensore

int RELE = 12; // Pin del rele’

int LED = 13; // Pin del diodo Led

long secondi_per_sms = 0;

bool stato;

void setup() {

Serial.begin(9600); // Comunicazione seriale a 9600 baud

pinMode(ACQUA,INPUT); // Pin 34 in ingresso

pinMode(RELE,OUTPUT); // Pin 12 in uscita

pinMode(LED,OUTPUT); // Pin 13 in uscita

//----------Aspetta 10 secondi per sincronizzare il WiFi----------

Serial.println();

Serial.println(“Attesa per il WiFi 10 secondi...”);

digitalWrite(LED,LOW); // Accende diodo Led

WiFi.begin(ssid, password);

delay(10000);

digitalWrite(LED,HIGH); // Spegne diodo Led

Serial.println(WiFi.localIP()); // Visualizza l’indirizzo IP di ESPertino

void loop() {

stato=digitalRead(ACQUA); // Legge il sensore d’acqua

//---------Se c’è allagamento-----------------

if(stato==1) { // Se E’ stata rilevata presenza di acqua

21
 MAKER

digitalWrite(LED,LOW); // Accende diodo Led

digitalWrite(RELE,HIGH); // Attiva il rele’

secondi_per_sms++; // Incrementa di 1 i secondi trascorsi

if(secondi_per_sms == 900) { // Ogni 15 minuti invia SMS

WiFiClient client; // Crea oggetto client

client.connect(host, 80); // Si collega all’host

String url = “/Aruba/SENDSMS?login=sms99999&password=miapassword&message_type=LL&recipient=%2

b393289999999&message=Allagamento+in+corso”;

client.print(String(“GET “) + url + “ HTTP/1.1\r\n” + “Host: “ + host + “\r\n” + “Connection: close\r\n\r\n”); //

Invia stringa GET per protocollo HTTP

client.stop();

Serial.println(“SMS inviato “); // Messaggio su monitor seriale per verifica

secondi_per_sms=0; // Azzera i secondi conteggiati e riparte da capo

//-------Lampeggio del diodo Led per l’attesa per permettere al messaggio di partire----------

for(int i=1;i<=40;i++) {

digitalWrite(LED,LOW); // Accende diodo Led

delay(125);

digitalWrite(LED,HIGH); // Spegne diodo Led

delay(125);

//---------Se NON c’è allagamento-----------------

if(stato==0) { // Se non c’e’ acqua...

digitalWrite(LED,HIGH); // Spegne diodo Led

digitalWrite(RELE,LOW); // Disattiva il rele’

secondi_per_sms=0; // Non conteggia il tempo trascorso

delay(1000); // Pausa generale di un secondo. NON MODIFICARE

22
 MAKER

Figura 4: il cablaggio completo del sistema

Figura 5: un altro metodo per realizzare il sensore d’acqua. I dadi sono avvitati a terra e le connessioni elettriche sono nascoste
sotto il pavimento

figura 1. In alternativa, per occultare alla perfezione
i collegamenti elettrici e i fili di cablaggio, è possibile
far fuoriuscire dal pavimento solamente due contatti
metallici, ad esempio due viti, che fungono, così, da
puntali, come mostrato in figura 5. I due puntali di
pescaggio possono anche trovarsi parecchio distanti tra
loro, purché non ostacolino il normale transito di persone
o di cose. Inoltre essi non costituiscono minimamente un
pericolo, in quanto risultano interessati a una tensione
di solo 3.3V.
COME ESPERTINO INVIA GLI SMS
Di metodi per inviare gli SMS ne esistono parecchi.
Quello adottato nel presente progetto si avvale dei ser-
vizi online preposti alla gestione di messaggi. Le solu-
zioni sono molte e diversificate. Alcune di queste, deci-
sa mente buone, prevedono l’acquisto di un pacchetto
di SMS dal costo davvero irrisorio. Ad esempio Aruba o
Skebby forniscono un ottimo servizio a prezzi molto
bassi e contenuti. Anche l’affidabilità della spedizione
è importante e queste due aziende la garantiscono al
cento per cento.
Per inviare con Aruba, via protocollo HTTP con metodo
GET, un SMS a un determinato numero di telefono cel-

23
 MAKER
https://adminsms.aruba.it/Aruba/SENDSMS?login=s
ms99999&password=miapassword&message_type=
LL&recipient=%2b393289999999&message=hello
lulare, si può inoltrare la seguente URL:
http://gateway.skebby.it/api/send/smseasy/
advanced/http.php?method=send_sms_
classic&username=nome_utente&password=mia_pa
ssword&recipients[]=393389999999&text=messaggi
o+da+spedire
mentre per farlo con Skebby si usi il seguente indirizzo:
In caso di mancato invio dei messaggi si ricordi sempre
di verificare il proprio credito. Si sarebbe potuto anche
utilizzare una shield GSM con una Sim in abbonamento
e restare, in questo modo, totalmente indipendenti da
altri servizi. Ma per questo progetto abbiamo scelto tale
soluzione, anche per alleggerire, di tanto, l’hardware
utilizzato. E’ semplice, eventualmente, implementare e
adottare quest’ultimo metodo.
LO SKETCH
Il listato, proposto più sotto, è semplice e non particolar-
mente lungo. La parte iniziale è dedicata all’inclusione
del file per il funzionamento del WiFi e alla dichiarazione
delle variabili. Nella funzione setup() viene impostata
la velocità della comunicazione seriale (usata qui solo
come monitoraggio e debug del sistema). Inoltre viene
determinata la funzionalità del pin ACQUA (porta 34)
come ingresso, RELE (porta 12) e LED (porta 13) come
uscita. Quindi, si instaura la comunicazione con il WiFi,
rispettando la importante e consigliata pausa di attesa
di 10 secondi. La funzione loop() inizia subito con la
determinazione dell’eventuale allagamento, leggendo lo
stato logico del sensore di presenza d’acqua. La porta
in questione, come visto prima, fornisce un segnale di
“vero” logico (3.3V) in caso di presenza d’acqua e un
segnale di “falso” logico (0V) nel caso contrario.
Se c’è un allagamento si verificano diversi fatti, tutti de-
dicati all’avvertimento dell’utente. Innanzitutto si eccita
il relè (per l’attivazione di una eventuale sirena o altro
dispositivo) e il diodo Led presente sulla scheda si il-
lumina. Il programma, quindi, conta per quanti secondi
persiste la presenza di acqua nell’ambiente monitora-
to. Se essi raggiungono i 900 secondi, equivalenti a 15
minuti (tale tempistica si può modificare), e che quindi
24
si sta trattando di qualche grave evento, si stabilisce
una comunicazione con il server, preposto all’invio de-
gli SMS. Essa si attua tramite apposita richiesta di tipo
HTTP e viene spedito immediatamente un SMS al nu-
mero di telefono programmato (quest’ultimo è presente,
come si può notare, all’interno della stessa stringa “url”).
Il processo si ripete all’infinito. La rilevazione dello stato
del sensore è effettuata ogni secondo (non modificate
tale tempistica). In caso d’invio di un SMS è effettuata
anche una visualizzazione sul monitor seriale dell’IDE
di Arduino.
Lo sketch è stato realizzato per la spedizione di SMS
con servizio acquistato da Aruba.it. Per adottare altre
soluzioni occorre modificare il contenuto del puntatore a
carattere “host” nonché quello della stringa “url”.
UTILIZZO
L’uso del dispositivo è estremamente semplice e non ha
bisogno di manutenzione alcuna. E’ sufficiente disporre
i due terminali per terra, in una posizione non fastidiosa,
e accendere il circuito. La scheda resta in attesa finché
un eventuale strato d’acqua inneschi il contatto tra i due
puntali. L’allagamento può essere davvero scongiurato
con un tempistico intervento dell’uomo.
CONCLUSIONI
Il progetto presentato è di notevole importanza poiché
utilizza il relè e il modulo WiFi, tutti a bordo di ESPer-
tino. Senza l’aggiunta di shields esterne è stato possi-
bile realizzare un dispositivo particolare e utilizzabile in
diverse occasioni. Ad esempio, potrebbe essere usato
come avvisatore di vasca piena. Nel qual caso è possi-
bile eliminare la parte relativa all’invio degli SMS e del
collegamento Wireless. Oppure potrebbe essere usato
per controllare gli argini di un fiume. Si potrebbe modifi-
care anche la sua finalità allestendo, per esempio, un si-
stema antincendio e cambiare le tempistiche di avviso.
Le idee possibili sono tante. Le potenzialità di ESPer-
tino, come si vede, aiutano molto il progettista e il fatto
che esso abbia a già bordo diverse soluzioni semplifica
notevolmente il lavoro da svolgere e dimezza gli spazi
occupati dal prototipo. Inoltre l’articolo è estremamente
didattico e contribuisce a prendere ancora di più confi-
denza con questa meravigliosa scheda di sviluppo.
L’autore è a disposizione nei commenti per eventuali
approfondimenti sul tema dell’Articolo. Di seguito il link per
accedere direttamente all’articolo sul Blog e partecipare alla
discussione:
https://it.emcelettronica.com/avvisatore-di-allagamento-con-
espertino
 Starter Kit TRL
BO AR D Funksysteme
Il kit IRIS Starter TRL Funksysteme è stato sviluppato per essere un’introduzione ai moduli radio e un
veloce sistema di prototipazione. Ci sono due unità IRIS Starter kit pre-programmate in una configura-
zione di test. Basta collegare i cavi di alimentazione e il sistema IRIS è pronto per un nuovo progetto.
INTRODUZIONE
U
n sistema IRIS è costituito da un gruppo di unità
disposte in una struttura ad albero collegate tra
loro (figura 1). L’unità master determina la con-
nessione all’utente finale tramite, ad esempio, un’inter-
faccia seriale, un modulo web o un modulo GSM. Le
altre unità del sistema sono collegate a varie apparec-
chiature elettroniche o agiscono come ripetitori per con-
sentire la comunicazione su lunghe distanze. Esistono
diversi tipi di unità IRIS con diverse funzioni. Gli ingressi
digitali e analogici, le uscite digitali, l’interfaccia seriale,
i timer e i contatori sono esempi di alcune delle funzioni
disponibili. È possibile configurare le unità IRIS prima
di impostare il sistema in posizione o dopo l’utilizzo del
collegamento radio o dell’interfaccia seriale.
Figura 1: esempi di collegamento di varie unità IRIS, la prima
sulla sinistra è l’unità Master e poi a seguire le restanti Slave
Lo starter kit include (figura 2):
• 2 IRIS starter kit units:
• Evaluation board.
• IRIS base: fa parte della serie di prodotti
IRIS ed è sviluppata per l’integrazione in altri
sistemi. La serie IRIS contiene diversi mo-
delli che forniscono soluzioni per varie
di Maurizio Di Paolo Emilio
applicazioni. Ci sono due tipi di IRIS-Base:
la versione standard utilizza un’alimenta-
zione a 5 volt, mentre la versione a bassa
potenza utilizza 3 volt. Tutti i modelli IRIS
possono comunicare tra loro tramite coppie
di moduli radio o in reti radio più complesse.
• Antenna.
• 2 cavi seriali.
• 2 adattatori AC/DC.
• 1 CD.
CARATTERISTICHE
Il kit contiene due unità IRIS Starter kit. Un’unità Starter
Kit è composta da due parti: un modulo IRIS Base che
gestisce tutte le funzionalità e una scheda di valutazio-
ne IRIS che gestisce la connessione all’utente.
Ci sono sei ingressi, quattro uscite, un modulo di co-
municazione radio e una porta di comunicazione seriale
disponibili su ciascuna unità IRIS Starter kit. Con queste
soluzioni e la possibilità di reagire con diverse azioni su
eventi diversi, IRIS rende il sistema da realizzare molto
flessibile. La prima cosa da fare, dopo aver collegato
le unità, è controllare la comunicazione, assicurandosi
che entrambe le unità siano collegate correttamente. Le
unità IRIS Starter sono pre-programmate con una
configurazione di test.
Le unità IRIS possono essere utilizzate per la supervi-
sione e il controllo di dispositivi esterni. È fondamentale
che le unità siano configurate attentamente per una fun-
zione ottimale. Le unità IRIS comunicano tra loro tramite
reti radio e con altri dispositivi sfruttando gli ingressi, le
uscite e le interfacce seriali. L’unità IRIS Starter kit di-
spone di sei ingressi che possono essere analogici o di-
gitali a seconda della configurazione. Ogni ingresso ha
un pulsante per simulare i valori di input e una connes-
sione per collegare dispositivi esterni come switch, sen-
sori e trasduttori. L’unità IRIS Starter kit dispone di
quattro uscite digitali. Ogni uscita dispone di un diodo
e una connessione per collegare l’unità IRIS ad altri di-
25
 BOARD

Figura 4: esempio di applicazione di un IRIS base

Categoria Starter Kit

Tipo 60901

Frequenza radio 433 MHz

Tensione di esercizio 3.3 V/DC, 5 V/DC

Max. assorbimento di corrente 50 mA

Altezza 11 mm

Larghezza 51 mm

Raggio azione Max. 1000 m

Frequenza di trasmissione 433,050 - 434,775 MHz

Modello Componente sfuso

Tabella 1: caratteristiche del kit IRIS starter

spositivi. Le unità IRIS Starter kit gestiscono RS-232 e
RS-485, sia half-duplex che full-duplex, a seconda della
configurazione. È possibile impostare le unità IRIS in
modo che corrispondano all’interfaccia delle unità ester-
ne. Le unità IRIS Starter Kit comunicano tra loro tramite
collegamenti radio sulla banda di 433Mhz e in alcuni
paesi della banda di 439 MHz. È possibile modificare le
frequenze in modo che diversi sistemi IRIS nella stessa
area non interferiscano tra loro (figura 3).
IRIS-Base dispone di interfaccia seriale, ingressi e usci-
te, che lo rendono adatto ad interagire con la maggior
parte dei sistemi. Per collegare IRIS-Base ad altre ap-
parecchiature potrebbe essere necessario un certo nu-
mero di circuiti aggiuntivi a seconda dell’applicazione.
L’uso più comune di IRIS-Base è come un collega-
mento radio tra sistemi che sono distanti o mobili.
I dati possono essere indirizzati a un PC tramite IRIS-
RS232 o IRIS-USB, in un database su Internet trami-
te IRIS-CUW o può essere utilizzato per controllare le
uscite su un IRIS-IO. Con funzioni quali timer e conta-

26
 BOARD

dei valori misurati, logi-

stica di magazzino. L’in-
tervallo di temperatura è
compreso tra -10 e +55
°C, offrendo sensibilità in
ingresso di -112 dBm (@
50 Ω) con una velocità di
trasmissione pari a 4800
bps (in aria).

LO STARTER KIT TRL

FUNKSYSTEME 60901
CON RAGGIO DI AZIO-
NE MAX. (CAMPO LIBE-
RO) DI 1000 M È DISPO-
NIBILE A CATALOGO
CONRAD CON SPEDI-
ZIONE 24H
Figura 2: il kit TRL Funksysteme

tori, è possibile configurarli al fine di adattarsi a molte

applicazioni diverse tra loro (figura 4).
In tabella 1 riportiamo alcune caratteristiche principali.

CONCLUSIONI
Il kit Starter IRIS permette un rapido design dei mo-
duli radio utilizzati anche come schede di valutazione.
Esempi di applicazioni sono: lettura remota del conta-
tore, M2M (Machine to Machine), macchinette auto-
matiche e slot machine, sistemi di controllo remoto e
di misurazione remota, registratore di dati, trasmissione
L’autore è a disposizione nei commenti per eventuali
approfondimenti sul tema dell’Articolo. Di seguito il link per
accedere direttamente all’articolo sul Blog e partecipare alla
discussione:
https://it.emcelettronica.com/starter-kit-trl-funksysteme

Figura 3: collegamento dell’unità

27
 Bitcoin: la moneta
TECH
S C I&
decentralizzata
Con il termine Bitcoin si intende un tipo di moneta utilizzata a livello globale, e che, come ogni altra
moneta, può essere convertita in un’altra valuta, ad esempio il dollaro statunitense. L’aspetto interes-
sante del Bitcoin è che con la sua nascita è stato introdotto un sistema monetario che opera in modo
decentralizzato, come vedremo meglio e più in dettaglio nell’articolo.
INTRODUZIONE
I
due aspetti fondamentali che rendono la moneta
Bitcoin diversa da un qualunque altro tipo di sistema
monetario moderno, come il dollaro oppure l’euro,
sono i seguenti:
1. la decentralizzazione: in questo tipo di sistema
monetario non esiste alcun organismo centra-
le che conia la moneta, e potremmo piuttosto
dire che la moneta viene coniata dal popolo (il
“crowd”). Il Bitcoin è pertanto un sistema mone-
tario decentralizzato;
2. l’anonimato: le persone che utilizzano la mone-
ta Bitcoin assumono che la propria identità non
venga mai rilevata. Ciò si differenzia dal modo
comune con cui eseguiamo acquisti su internet,
utilizzando tipicamente una carta di credito, e
fornendo i nostri dati personali affinchè possano
essere verificati dalla banca presso la quale ab-
biamo la disponibilità di denaro.
Nel corso dell’articolo ci soffermeremo soltanto sul pri-
mo dei due aspetti menzionati in precedenza, ovvero la
decentralizzazione del Bitcoin, lasciando aperto l’aspet-
to relativo all’anonimato per eventuali commenti.
LA DECENTRALIZZAZIONE
Per assimilare a fondo il concetto di “sistema moneta-
rio decentralizzato”, dobbiamo anzitutto capire cosa si
intende per sistema monetario “centralizzato”. In ter-
mini semplificati, per sistema monetario centralizzato si
intende un sistema in cui l’autorità centrale, tipicamente
il governo, è responsabile di tutti gli aspetti legati alla
sfera economica, inclusa la stampa delle banconote e il
conio delle monete, la riscossione delle tasse sui profitti,
la regolamentazione delle banche e del credito in gene-
rale, e così via. In questo tipo di sistema, quasi ogni
aspetto è regolato da leggi e politiche approvati dal
governo. La maggiorparte delle transazioni di denaro
passano attraverso terze parti, tipicamente le banche, le
28
di Stefano Lovati
quali devono controllare e memorizzare tutte le informa-
zioni relative a ogni transazione monetaria, per evitare
future controversie e perchè richiesto per legge.
Una volta premesso cosa si intende per sistema mone-
tario centralizzato, possiamo a questo punto affermare
che un sistema decentralizzato differisce da quest’ul-
timo soprattutto per la mancanza di un’autorità cen-
trale. Nonostante ciò, un sistema decentralizzato è in
grado di operare correttamente, proprio come se dietro
di esso vi fosse un’autorità centrale.
Il concetto di “operare correttamente” è tuttavia abba-
stanza vago, e dipende strettamente dalle leggi e dalle
norme in ambito finanziario che ogni paese applica a
questo tipo di sistema. In generale, nella maggior parte
dei paesi, un sistema monetario che operi correttamen-
te dovrebbe applicare qualche forma di tassazione, e
queste regole potrebbero differire tra un paese e l’al-
tro. Tuttavia, in tutti i paesi (o federazioni), deve neces-
sariamente essere attuata una procedura, efficace e
controllabile, per la stampa della moneta. Possiamo
affermare con certezza che il sistema Bitcoin soddisfa
quest’ultimo requisito, mentre per quanto riguarda altri
aspetti (come quelli legati alla tassazione e alla regola-
mentazione) , il giudizio è soggetto alla libera interpre-
tazione.
Prima di illustrare come venga generato questo nuo-
vo tipo di moneta (il bit-coin), è utile analizzare più in
dettaglio il modo in cui la moneta è stata percepita dal-
le popolazioni nel corso della storia. Se prendiamo in
considerazione i sistemi monetari utilizzati nel corso dei
secoli passati, possiamo osservare come, con l’instau-
rarsi delle prime attività commerciali, le popolazioni uti-
lizzassero un sistema decentralizzato, per poi passare,
successivamente, a un sistema di tipo centralizzato. Si
arriva così ai nostri giorni, in cui la comunità crittogra-
fica sta compiendo enormi sforzi affinchè si ritorni
a un sistema decentralizzato, anche se in una forma
più moderna ed attuale. Vediamo ora più in dettaglio i
diversi approcci al sistema monetario che si sono sus-
 TECH

seguiti nella storia. posto protetto dei lingotti d’oro per la propria clientela,
e apponendo la propria firma sulle corrispondenti note
L’ANTICHITÀ: IL SISTEMA DECENTRALIZZATO emesse. Il ruolo della banca era ovviamente cruciale: in
Il primo tipo di sistema monetario messo in atto era mol- questo tipo di sistema era necessario avere fiducia nelle
to semplice: un grammo d’oro valeva semplicemente banche, ed essere in grado di riconoscere se una nota
e soltanto un grammo d’oro. L’oro era infatti il metallo utilizzata da un cliente per un pagamento aveva appo-
prezioso utilizzato come strumento basilare di scambio, sta una firma valida oppure falsificata (figura 1).
anche se successivamente venne utilizzato l’argen-
to, oppure entrambi. Esisteva inoltre un vero e proprio L’ERA MODERNA: LA MONETA CENTRALIZ-
tasso di scambio tra un qualunque tipo di merce e l’o- ZATA
ro, e viceversa. In questo modo, le persone potevano Quello creato nell’era moderna è il sistema monetario
acquistare ciò di cui avevano particolarmente bisogno che tutti noi siamo abituati a conoscere e utilizzare nella
semplicemente scambiando la merce desiderata con la vita quotidiana. Anche questo tipo di sistema moneta-
corrispondente quantità di oro, oppure con un altro tipo rio, come quello menzionato nel precedente paragrafo,
di merce, a condizione però che avesse lo stesso valore si basa sull’utilizzo di appositi certificati e monete. La
equivalente in oro. Questo tipo di sistema era comune- differenza è che ora i certificati e la moneta non rappre-
mente accettato, in quanti tutti sapevano quanto l’oro sentano un bene materiale concreto e prezioso, come
fosse raro, e perciò prezioso. Non c’era alcun bisogno di l’oro o l’argento, ma piuttosto hanno valore solo in vir-
un’autorità centrale che stabilisse l’esatta equivalenza tù di un decreto governativo.
tra una certa quantità di oro e una determinata quantità Se, ad esempio, volessimo vendere degli hot-dog per le
di merce (ad esempio, di legno). Il valore dei prodotti strade di New York, dovremmo necessariamente accet-
era invece determinato dal loro valore fisico reale, e si tare i dollari statunitensi come merce di scambio per i
trattava pertanto di un sistema decentralizzato. panini venduti. I dollari statunitensi non verrebbero però
accettati in virtù del loro valore intrinseco (dopo tutto, si
LA PRIMA INTRODUZIONE DELLA MONETA tratta semplicemente di un pezzo di carta), ma perchè
Il primo passo verso l’introduzione del sistema moneta- sono le regole stabilite dal governo che ci obbligano a
rio che tutti oggi conosciamo, si verificò con la creazione farlo. Il governo ha fatto sì che i dollari diventassero oggi
di un sistema centralizzato merce-denaro. In questo tipo il bene più fungibile (persino più utile dei lingotti d’oro).
di sistema, l’acquirente non com-
prava la merce (ad esempio il cibo)
dando in cambio al venditore una
certa quantità di oro, ma piuttosto
consegnava una nota rilasciata e
firmata da una banca. Questa nota,
o certificato, attestava che la ban-
ca avrebbe riservato nelle proprie
casseforti una quantità di oro cor-
rispondente al valore del certificato
emesso. Chiunque fosse entrato
in possesso di questo certificato,
avrebbe potuto riscuoterlo in ogni
momento consegnandolo alla ban-
ca. Si trattava quindi di una vera e
propria moneta (o se si preferisce,
di una banco-nota), che poteva es-
sere trasferita di mano in mano e
utilizzata per acquistare cibo o altri
generi di merce. In questo tipo di
sistema, la banca rappresentava
il punto centralizzato, la cui fun-
zione era quella di conservare in un Figura 1: i lingotti d’oro custoditi dalle banche

29
 TECH
Come già accennato, queste banconote, di per sè, non
hanno alcun valore, ma come conseguenza del regola-
mento messo in atto posseggono esattamente il valore
stampato su di esse (questo numero viene anche indi-
cato dagli esperti di economia con il termine di “valore
facciale”). Per identificare questo tipo di moneta si usa
anche spesso il termine latino “Fiat”, che potremmo tra-
durre in italiano con “sia fatta”, intendendo con questa
accezione il significato di un ordine, o decreto, stabilito
da un governo.
IL FUTURO: TRA DECENTRALIZZAZIONE E
BLOCKCHAIN
Blockchain, la tecnologia che sta dietro la moneta Bit-
coin, rappresenta un concetto molto più semplice di
quanto si possa immaginare.
Possiamo capire facilmente in cosa consiste la
blockchain e come essa funziona, facendo un’analogia
con il conto corrente bancario. Chiunque abbia un conto
corrente in una banca, sa come sia possibile conoscere
il saldo del conto, e come ottenere la lista delle transa-
zioni inerenti quel conto riferita a un certo periodo (tran-
sazioni sia in uscita che in entrata). La banca memo-
rizza tutte queste informazioni in un proprio database
privato e protetto, permettendo ai propri clienti di ese-
guire delle interrogazioni su di esso (come sappiamo,
Figura 2: nell’era moderna internet abilita nuove forme di pagamento
30
il termine corretto in questo ambito è quello di “query”).
L’accesso a queste informazioni è inoltre riservato, oltre
che alla banca, ai soli titolari del conto, in modo tale da
garantire la riservatezza dei dati.
Supponiamo ora che il database utilizzato dalla banca
possa contenere un numero illimitato di record, e che
quindi non vi sia un limite al numero di transazioni re-
gistrabili. Supponiamo inoltre che la banca inizi a popo-
lare il database per un certo cliente scrivendo il record
numero 1, e continui seguendo un numero crescente di
record. Possiamo a questo punto individuare due rego-
le fondamentali che la banca deve seguire scrupolo-
samente:
1. irreversibilità – se in un dato momento la banca
sta scrivendo la transazione associata al record
numero X, non dovrà mai tornare indietro, mo-
dificando ad esempio le transazioni con indice
inferiore a X;
2. latenza – se in un certo istante la banca sta
scrivendo il record numero X, la corrispondente
transazione (in quel frangente) non può anco-
ra essere ritenuta valida, e non si può fare affi-
damento su di essa quando il cliente chiede ad
esempio il saldo del proprio conto. Ciò avviene
anche con l’esperienza quotidiana che ognu-
no di noi può avere nel gestire il proprio conto
 TECH
corrente: non sempre le transazioni si riflettono
immediatamente sullo stato del conto corrente
(vengono cioè “contabilizzate”), può essere in
generale richiesto un certo tempo prima che ciò
avvenga, e che il saldo del conto assuma per-
tanto il valore effettivo.
Queste due regole indicano che il record X è l’unico
che può essere scritto, ma non può ancora essere letto,
mentre i record 1, 2, .., (X-1) possono tutti essere letti,
ma non sono più scrivibili (figura 2).
Un’altra questione importante riguarda le spese asso-
ciate alla transazione. Ogni volta in cui la banca registra
una transazione che ha come origine Alice e come de-
stinatario Bob, addebiterà ad Alice una certa somma di
denaro come commissione per il servizio svolto dalla
banca. L’importo di questa commissione non è fisso, ma
ogni banca opera in una sorta di mercato libero.
DECENTRALIZZIAMO!
I concetti esposti nel paragrafo precedente indicano
come si dovrebbe comportare un sistema centralizzato.
Vediamo ora, invece, come si dovrebbe comportare un
sistema decentralizzato.
La decentralizzazione del sistema implica comunque la
necessità di memorizzare in modo efficiente e affidabile
ogni transazione, ma senza richiedere per questa ope-
razione il controllo di una banca centrale. Inoltre, è
importante notare come, nel caso non esistesse un’au-
torità centrale riconosciuta da tutti (come la banca, op-
pure il governo stesso), occorrerebbe comunque met-
tere in atto un meccanismo in base al quale chiunque
possa riconoscere il valore di un oggetto, sia che si tratti
di una banconota o di una moneta. Nel nostro caso, tut-
tavia, estendiamo quest’ultimo aspetto, assegnando un
valore anche a un certo tipo di informazione digitale.
Nel seguito dell’articolo parleremo di decentralizzazione
dell’archivio delle transazioni, e successivamente ve-
dremo come questi “oggetti digitali” (ai quali è assegna-
to un determinato valore) vengono creati nel sistema.
Supponiamo ora che, anzichè una banca, abbiamo a
disposizione un gruppo di impiegati in grado di proces-
sare le transazioni di Alice. Alice, però, non conosce
tutti questi impiegati, ma soltanto alcuni. Quando Alice
vuole inviare una somma di denaro a Bob, fornisce le
informazioni relative alla transazione ad ogni impiegato
che conosce. Queste informazioni contengono il nume-
ro di conto di Bob, la cifra da trasferire, e l’importo delle
commissioni che Alice è disposta a pagare in cambio
del servizio. Almeno uno di questi impiegati (supponia-
mo che si chiami Clair) riceverà il messaggio di Alice,
verificando che sul suo conto vi siano fondi sufficienti
per onorare la transazione. Clair, per guadagnarsi la
commissione associata alla transazione, non devrà fare
altro che creare una nuova transazione (creare cioè un
nuovo record nel database), e aggiungerla al database
comune condiviso tra tutti gli impiegati. Ciò è necessa-
rio, in quanto Clair deve assicurarsi che ogni altro impie-
gato possa convenire sul fatto che la transazione è già
stata processata da Clair, e che pertanto soltanto a lei
spettino le commissioni relative all’operazione. Quan-
do tutti gli impiegati sono d’accordo su questo punto,
la transazione è dichiarata valida, e a Clair può essere
accreditata la commissione.
Come è facile comprendere, la necessità di aggiungere
una transazione al database comune, e far sì che tutti
gli impiegati approvino ogni operazione, non è un com-
pito semplice. Supponiamo infatti che Dan, un altro im-
piegato che come Clair abbia ricevuto le stesse informa-
zioni sulla transazione da processare, cerchi anche lui
di aggiungere un nuovo record con la transazione al da-
tabase condiviso. La transazione di Alice, ovviamente,
non può essere processata due volte, poichè in tal caso
Alice dovrebbe pagare due volte le commissioni sulla
stessa transazione. A chi allora spettano le commissioni
per la transazione di Alice? A Clair oppure a Dan? La
risposta è molto semplice: le commissioni spetteranno
a chi tra i due impiegati si dimostrerà più veloce nel pro-
cessare la transazione.
Nel mondo reale, processare una transazione tramite
un computer è un’operazione molto semplice, e può
richiedere soltanto alcuni millisecondi (o persino un
tempo inferiore). Ciò potrebbe instaurare un clima di
competizione tra Clair e Dan, ciascuno nel tentativo di
processare il più velocemente la transazione e accap-
pararsi le commissioni. Non solo, si potrebbe anche
creare una situazione in cui (nel decidere a chi tra i due
debbano essere accreditate le commiissioni) parte degli
impiegati sostiene Clair, mentre un’altra parte sostiene
Dan. Esiste tuttavia un modo per far sì che tutti gli impie-
gati concordino su chi abbia processato la transazione,
e a chi, di conseguenza, andranno accreditate le com-
missioni. La soluzione consiste nell’utilizzare un puzzle:
per ogni transazione che può essere processata da ogni
impiegato, e aggiunta al database comune e condiviso,
viene generato in modo del tutto casuale un puzzle uni-
co, molto difficile da risolvere. Il fatto che ogni puzzle
venga generato in modo casuale e sia diverso da tutti gli
altri creati in precedenza è molto importante: con riferi-
mento al nostro esempio, ciò implica che la transazione
che sta per essere processata da Clair contiene un puz-
zle differente da quello della transazione di Dan, nono-
31
 TECH
stante gli altri dati della trnasazione siano gli stessi (si
tratta per entrambi dell’operazione richiesta da Alice).
Essendo i puzzle molto complessi, la loro risoluzione
richiederà un certo tempo, ed è pertanto plausibile che
uno degli impiegati arrivi alla soluzione prima degli altri,
avendo a disposizione un tempo sufficiente per convin-
cerli di essere arrivato per primo.
A questo punto sappiamo come la moneta viene tra-
sferita, e come gli impiegati possano guadagnarsi dei
soldi processando le transazioni in cambio delle relative
commissioni. Ma che cos’è realmente questa moneta,
e come ha ottenuto Alice la quantità di denaro poi tra-
sferita a Bob?
Possiamo senz’altro dire che questa moneta non è di-
sponibile in una forma fisica, dal momento che non
abbiamo dato mandato ad alcuna entità centrale affin-
chè crei la moneta e la diffonda tra il popolo. Per rispon-
dere alla domanda, possiamo prendere ancora come
riferimento gli impiegati dell’esempio precedente, chia-
mandoli ora “minatori”. Queste termine riflette il duro
lavoro da essi compiuto, che consiste nel trovare una
soluzione a un problema di complessità elevatissima,
un compito analogo a quello svolto da un minatore re-
ale, alla ricerca di minerali o pietre preziose nascosti
dietro spessi strati di roccia.
Resta da capire come venga generata la moneta.
Come è facile intuire, i minatori sono proprio coloro
che danno origine alla nuova moneta. Essi investono
un’enorme quantità di tempo e lavoro, incentivati dal-
la ricompensa offerta dal sistema. I minatori, infatti,
guadagnano sia attraverso le commissioni legate alle
transazioni processate, sia con ogni record creato lo-
calmente e assegnato a una transazione da processare
(con riferimento all’esempio precedente, sia Clair che
Dan avrebbero creato un record simile). Occorre pre-
stare attenzione a una proprietà molto importante
del Bitcoin: un minatore, anche lavorando duramente,
potrebbe non guadagnare nulla. Tutti i minatori concor-
dano su questa regola fondamentale: a chi tra loro trovi
per primo la soluzione a un puzzle, verranno non solo
accreditate le commissioni relative alla transazione, ma
anche un ammontare fisso di nuove monete digitali, cre-
ate in quel momento appositamente per questo scopo.
RIASSUMIAMO IL TUTTO
Alice, che vuole trasferire una certa somma di denaro
a Bob, potrebbe rappresentare una qualunque perso-
na che utilizzi un’applicazione di portafoglio elettronico
installata sul proprio smartphone o PC. Questa appli-
cazione non è altro che un programma in grado di me-
morizzare i bitcoin sul dispositivo elettronico, tenendo
32
traccia degli indirizzi IP dei minatori. I minatori associa-
ti a questi indirizzi IP vengono notificati ogni volta che
chiediamo al nostro portafoglio elettronico di trasferire
a qualcuno del denaro, cioè ogni volta che creiamo una
transazione da processare. Inoltre, l’applicazione inter-
roga periodicamente i minatori per verificare se qualcu-
no ha ordinato un trasferimento di denaro verso di noi
(se cioè, abbiamo ricevuto una qualche forma di paga-
mento).
Una volta che i minatori sono stati notificati circa la tran-
sazione che intendiamo eseguire, essi la processeran-
no cercando una soluzione al puzzle ad essa associato.
Il minatore che troverà per primo la soluzione al puzzle
si guadagnerà la commissione, oltre a un ammontare
fisso di denaro (in Bitcoin, o frazioni di esso).
Vediamo ora di dare a tutti gli “oggetti” sopra menzionati
i nomi corretti scelti dalla comunità Bitcoin. L’insieme di
transazioni (processabili da ogni minatore) viene chia-
mato “block”, e un insieme di transazioni viene perciò
detto “blocco” di transazioni. Il database comune e con-
diviso viene chiamato “block-chain”, dal momento che
si tratta di una catena di blocchi ordinati, ciascuno dei
quali contiene un insieme di transazioni già processate
e validate. Il puzzle di elevata complessità che i mina-
tori devono cercare di risolvere è in sostanza rappre-
sentato dall’output prodotto da una funzione di hash
crittografico.
Inoltre, dal momento che ai minatori è richiesto di ese-
guire un numero elevato di tentativi al fine di trovare una
soluzione al puzzle, si dice che essi stanno dimostran-
do (“provando”) di avere lavorato duramente; in inglese
questo termine prende il nome di “proof of work”, o
semplicemente PoW.
LINK
L’articolo originale, “Bitcoin – Money Decentralization”
apparso sul blog vpnMentor, ha come Autore Avishay
Yanay, appartenente al gruppo di ricerca crittografico
presso il Bar-Ilan Cyber Center. Come l’Autore stesso
precisa, l’articolo è stato scritto da un esperto di infor-
matica e non da un esperto di economia, pertanto alcuni
concetti inerenti il mondo economico e il sistema mone-
tario sono stati volutamente semplificati.
L’autore è a disposizione nei commenti per eventuali
approfondimenti sul tema dell’Articolo. Di seguito il link per
accedere direttamente all’articolo sul Blog e partecipare alla
discussione:
https://it.emcelettronica.com/bitcoin-la-moneta-decentralizzata
 Mini registratore
MAK ER allo stato solido con
ESPertino
di Giovanni Di Maria

A grande richiesta pubblichiamo una semplice e didattica applicazione audio. Molti lettori ci hanno
chiesto, infatti, se era possibile registrare o riprodurre dei suoni audio con ESPertino. La risposta è
si. La durata del campionamento dipende, ovviamente, dalla memoria RAM disponibile nella MCU. Per
grosse quantità di dati è conveniente utilizzare le SD esterne. Il dispositivo presentato in questo artico-
lo usa la memoria interna dell’ESP32 e si avvale dell’ADC e del DAC.

INTRODUZIONE è digitale.

O
ggi si sente molto parlare di registratori allo
stato solido. Si tratta di dispositivi che usano la
tecnologia a stato solido per registrare e con-
servare le informazioni audio. Tale modalità permette di
acquisire e riprodurre i segnali audio sotto forma di dati
digitali, consentendo una successiva e semplice gestio-
ne. Tale tecnologia, se ci pensiamo bene, è più alla por-
tata di mano di quella analogica. E’ sufficiente, infatti,
memorizzare il segnale audio in tante celle di memoria,
campione per campione, tramite acquisizione ADC, per
poi riprodurle dallo stesso supporto con una riproduzio-
ne DAC, senza utilizzare supporti meccanici in movi-
mento o in rotazione. L’insieme delle informazioni viene
letto e riprodotto, cella per cella, come avviene per un
nastro magnetico, ma in questo caso l’intero processo
ADC E DAC
Il concetto di ADC e DAC è chiaramente illustrato in fi-
gura 1. Se parliamo attraverso un microfono, il segnale
prelevato alla sua uscita è caratterizzato da una forma
elettrica analogica. Le varie parole o musiche acquisi-
te dal trasduttore sono convertite in equivalenti segna-
li elettrici di diversa entità. La conversione analogico-
digitale, l’ADC, consiste nel trasformare tale segnale
analogico, continuo nel tempo e con infiniti valori, in
una sequenza di dati numerici, gestibili e memorizzabili
facilmente nella memoria di elaboratore. Purtroppo c’è
una piccola perdita d’informazione, in quanto la memo-
ria non è infinita e la bontà del segnale deve essere ne-
cessariamente ridotta. Il DAC si comporta esattamente

Figura 1: ADC e DAC

33
 MAKER
Figura 2: il microfono a condensatore e suo funzionamento a riposo e a regime
al contrario. Converte, infatti, un segnale digitale in uno
analogico. La rete è stracolma di letteratura a riguardo
e una semplice ricerca su Internet consente di trovare
migliaia di argomentazioni. E’ inutile, pertanto, ripetere
gli stessi concetti, in questa sede.
IL REGISTRATORE CON ESPERTINO
Nel corso dei precedenti articoli basati sulla scheda
ESPertino, molti lettori hanno espresso il desiderio di
vedere pubblicati consigli o istruzioni che dessero la
possibilità, quanto meno, d’iniziare a trattare questo im-
portante argomento dell’elettronica. Il nostro registrato-
re, come dice il titolo, è realmente minimale. Lo scopo
della presente pubblicazione è, infatti, esclusivamente
quello didattico. E, inoltre, costituisce una delle tante
idee che si possono seguire per lo scopo prefissato. Le
caratteristiche del recorder sono le seguenti:
• Uso di microfono a condensatore;
• Durata della registrazione: 1,35 secondi;
• Risoluzione della riproduzione: 8 bit (è la risolu-
zione del DAC dell’ESP32);
• Frequenza di campionamento: 22 Khz.
IL MICROFONO
Per il progetto si è utilizzato un piccolo microfono a con-
34
densatore, provvisto di due terminali. Il suo costo è dav-
vero irrisorio, si trova anche per meno di due euro. Lo
schema di cablaggio prevede la connessione a una
fonte di alimentazione. I 3.3V di ESPertino vanno più
che bene per lo scopo. Il microfono deve essere prece-
duto da una resistenza di polarizzazione in modo da
limitare il flusso di corrente e porre a metà quadrante
di lavoro la sua tensione di uscita, a riposo. Nel nostro
caso abbiamo utilizzato una resistenza da 10 kohm ma
è bene controllare effettivamente la tensione a riposo,
da caso a caso. Essa può, infatti, risultare diversa a
seconda del tipo di microfono in possesso. La figura 2
mostra tale dispositivo, assieme al relativo schema di
collegamento e ai due grafici della risposta, sia in re-
gime statico che dinamico. Si preferisce, solitamente,
collocare la tensione del segnale audio a riposo a metà
strada (ossia tra 0V e VCC) in modo che esso possa
oscillare liberamente senza eventuali clipping che po-
trebbero produrre indesiderate distorsioni. Le misure
dei dati e dei relativi grafici sono stati prodotti con il Po-
Scope Mega1.
CABLAGGIO DI PRINCIPIO
Lo schema di collegamento dell’intero sistema risulta
estremamente semplice e, soprattutto, utilizza esclu-
 MAKER
sivamente la scheda ESPertino, almeno nella sua
configurazione minimale. Esso è visibile in figura 3. Il
progettista, in seguito, potrà scegliere, eventualmente,
di aggiungere amplificatori, filtri, microfoni preamplificati
e quant’altro che possa aumentare il livello qualitativo di
registrazione e di riproduzione. Esaminiamo i collega-
menti salienti dello schema elettrico:
• Il microfono, come detto prima, è collegato alla
porta 35 di ESPertino, trattata come ingresso
analogico. A riposo si deve misurare la tensione
di VCC/2, ossia di circa 1.6V. Qualche percento
in più o in meno non è assolutamente critico;
• L’uscita audio fa capo al pin della scheda con-
trassegnato con x2. Si tratta della GPIO25, fa-
cente capo al pin 14 dell’ESP32 e relativa al
canale 1 del DAC. Si consiglia di aggiungere un
condensatore elettrolitico di pochi microfarad,
per attuare un disaccoppiamento in continua.
Il terminale positivo va collegato verso la scheda
Figura 3: il cablaggio per il mini registratore vocale
ESPertino.
IL DAC DELL’ESP32
Il microcontrollore dispone di due canali DAC per con-
vertire due segnali digitali in altrettanti analogici. La sua
struttura interna è composta da una stringa integrata di
resistori e da un buffer. I due canali effettuano delle con-
versioni indipendenti tra loro. Purtroppo essi hanno una
risoluzione di soli 8 bit ma la loro velocità operativa non
fa rimpiangere minimamente altre configurazioni più
elevate. Esse fanno capo alle porte GPIO25 e GPIO26
dell’ESP32 (rispettivamente i pin 14 e 15). Per produr-
re un segnale analogico si deve utilizzare la seguente
funzione:
esp_err_t dac_out_voltage(dac_channel_t channel,
uint8_t dac_value);
Tale funzione produce una tensione elettrica analogi-
ca sulla porta specificata, che risulta compresa tra oV
35
 MAKER
e VDD, a seconda del parametro passato “dac_value”
(0~255). Non è necessario configurare la porta in uscita
poiché quando la funzione viene invocata, essa è auto-
maticamente settata con funzionalità di RTC DAC.
I parametri da passare, come si vede, sono due:
• channel: che costituisce il canale DAC scelto;
• dac_value: che rappresenta il livello di tensione
da generare, compreso tra 0 e 255 (0V~VDD).
La funzione ritorna ESP_OK, se l’operazione è andata a
buon fine, oppure ESP_ERR_INVALID_ARG, quando si
verifica un errore di parametro.
E’ necessario far seguire a essa una pausa di attesa del
corretto tempo calcolato, in quanto la sua esecuzione
risulta estremamente veloce.
In alternativa si può anche usare la funzione:
dacWrite(port, dac_value).
Leggi anche: Corso di programmazione Python
su Flip&Click: ADC e DAC
IL DISPOSITIVO DI RIPRODUZIONE AUDIO
Per le prime prove e sperimentazioni si può tranquilla-
mente utilizzare un piccolo altoparlante dal diametro di
5 cm. oppure un riproduttore piezo. Il volume di riprodu-
zione sarà, ovviamente, estremamente basso ma co-
munque sufficiente per percepire chiaramente il parlato.
Anche una piccola cuffia va senz’altro bene. In seguito
sarà possibile aggiungere un piccolo amplificatore au-
dio, magari realizzato con un transistor o con l’integra-
to LM386 o, addirittura, con un semplice operazionale
(741 o TL081).
LO SKETCH
Il listato proposto, ovviamente di principio, non è parti-
colarmente complicato e dovrebbe risultare abbastanza
comprensibile anche per i principianti e i programmatori
alle prime armi. L’importante è capire bene il suo con-
cetto di funzionamento. La sua filosofia è la seguente:
• Deve acquisire un certo numero di campioni dal
microfono e li deve memorizzare, in forma digi-
tale, all’interno di un array in memoria RAM. Tale
acquisizione è effettuata a 12 bit;
• Deve adeguare (trasformare) tutti i campioni a 8
bit per poterli consegnare al DAC, che lavora a
tale risoluzione. L’adeguamento viene effettua-
to semplicemente dividendo i valori per sedi-
ci. Oppure, in alternativa, si può effettuare uno
shift di bit di 4 posti a destra, per ottenere il
medesimo risultato;
• Deve riprodurre i campioni “scorrendo” l’array e
36
inoltrandolo verso la porta DAC.
In questa fase è importante gestire correttamente
la temporizzazione tra un campione e il successivo.
Cambiandola, è possibile creare effetti di rallentamento
o accelerazione della voce, ottenendo interessanti truc-
chi audio. Ecco di seguito lo sketch, con le varie righe
numerate progressivamente per poter spiegare e chia-
rire, in dettaglio, le funzioni più critiche e maggiormente
importanti.
• Riga 1: è necessario includere questo file di he-
ader per gestire le funzioni e le costanti per il
trattamento del DAC. Si invita il lettore anche a
dargli una occhiata. E’ memorizzato all’interno
della cartella ..\arduino-1.8.4\hardware\espres-
sif\esp32\tools\sdk\include\driver\driver;
• Riga 2: il programma può gestire fino a 30000
campioni. Purtroppo la memoria RAM dell’E-
SP32 è abbastanza limitata e un incremento di
tale numero lo potrebbe facilmente mandare in
crash;
• Riga 3: tra un campione e il successivo viene
rispettata una pausa di attesa di 45 microsecon-
di. Con tale configurazione la registrazione ha
una durata di 30000*(45/1000000)=1.35 secon-
di e la riproduzione avviene alla frequenza di
1000000/45=circa 22 Khz;
• Riga 8: viene dichiarato l’array d’interi che ospi-
terà tutti i campioni sonori. La gestione di tale
array avviene per suo scorrimento;
• Righe 14~15: vengono predisposti i parametri
operativi per l’ADC, ossia un fondo scala di 3.3V
e una risoluzione di acquisizione pari a 12 bit;
• Righe 18~26: si accende il diodo Led che avvi-
sa della registrazione in corso ed ESPertino
inizia ad acquisire la voce dal microfono (vedi
figura 4). Si ricorda che i diodi Led a bordo della
scheda hanno l’anodo a VCC il catodo collegato
verso le porte di I/O per cui, gioco forza, si devo-
no pilotare tramite uno stato logico invertito;
• Righe 27~30: adegua l’intero array dei campioni
a 8 bit per il DAC, dividendo semplicemente i
valori per 16;
• Righe 31~38: riproduce la forma d’onda memo-
rizzata all’interno dell’array, inviando ogni singo-
lo campione alla porta DAC. In questo modo, in
uscita, sarà riprodotto l’esatto (quasi) segnale e,
quindi, inoltrato successivamente all’altoparlan-
te.
COME SI USA
Il dispositivo inizia subito a funzionare non appena si
 MAKER

1 #include <driver/dac.h>
2 #define SAMPLES 30000
3 #define PAUSA 45
4 int LED1=13; // Led acceso durante la registrazione
5 int LED2=5; // Led acceso durante la riproduzione
6 int digitale; // Variabile che contiene un solo campione microfonico acquisito
7 int k;
8 int campioni[SAMPLES]; // Vettore contenente tutta la registrazione
9 void setup() {
10 pinMode(LED1,OUTPUT); // Porta in uscita
11 pinMode(LED2,OUTPUT); // Porta in uscita
12 digitalWrite(LED1,HIGH); // Spegne Led
13 digitalWrite(LED2,HIGH); // Spegne Led
14 analogSetAttenuation(ADC_11db); // Fondo scala ADC: 3.3V
15 analogReadResolution(12); // Risoluzione ADC a 12 bit
16 }
17 void loop() {
18 //-----Inizia la registrazione e memorizza in array-----------------
19 digitalWrite(LED1,LOW); // Accende Led
20 for(k=0;k<SAMPLES;k++) {
21 digitale=analogRead(35); // Legge il microfono
22 campioni[k]=digitale; // Memorizza segnale in array
23 delayMicroseconds(PAUSA); // Aspetta
24 }
25 digitalWrite(LED1,HIGH); // Spegne Led
26 delay(200);
27 //-----Divide i campioni per 16 per riportarli a 8 bit per il DAC-------
28 for(k=0;k<SAMPLES;k++) {
29 campioni[k]=campioni[k]/16; // Adeguamento per DAC
30 }
31 //-----------Riproduce la registrazione in altoparlante-------
32 digitalWrite(LED2,LOW); // Accende Led
33 for(k=0;k<SAMPLES;k++) {
34 dac_out_voltage(DAC_CHANNEL_1, campioni[k]); // Invia il segnale al DAC
35 delayMicroseconds(PAUSA);
36 }
37 digitalWrite(LED2,HIGH); // Spegne Led
38 delay(2000);
39 }

37
 MAKER
Figura 4: il segnale proveniente dal microfono a condensatore, registrato con il PoScope Mega1
applica l’alimentazione elettrica a ESPertino. Esso non
ha bisogno di alcuna taratura o regolazione, se non
quella di controllare la tensione a riposo del microfono,
che deve risultare circa VCC/2. Le sue fasi operative,
appena avviato, sono le seguenti:
1. Il Led 1 resta illuminato per i primi 1.35 secondi.
In questa frazione di tempo si deve iniziare subi-
to a parlare, posizionandosi molto vicini al micro-
fono. Dobbiamo ricordare, infatti, che quest’ulti-
mo non è preamplificato e la voce prodotta deve
risultare abbastanza robusta;
2. Quindi, trascorsi i primi 1.35 secondi, la registra-
zione termina e il Led 1 si spegne. Si illumina,
così, il Led 2 che testimonia l’inizio della ripro-
duzione su altoparlante. Il tutto avviene con il
medesimo tempo;
3. Dopo di ciò, la riproduzione ha termine e anche
il secondo Led si spegne. Dopo una pausa di 2
secondi l’intero processo si ripete da capo, all’in-
finito.
CONCLUSIONI
Quello presentato nell’articolo è solo un prototipo spe-
rimentale (ma d’importanza notevole) che illustra come
registrare e riprodurre un breve segnale audio. Si può
considerare, a tutti gli effetti, un fedele pappagallo elet-
tronico, che ripete ciò che viene pronunciato al micro-
38
fono. A pensarci bene, la maggior parte del carico svolto
è determinato dal firmware creato. La soddisfazione nel
realizzare tali tipologie di applicazioni è davvero tanta.
Con opportuni accorgimenti è possibile salvare le pro-
prie parole e creare, in tal modo, una sorta di piccola li-
breria composta da suoni e da messaggi, per poi essere
utilizzati all’occorrenza. Si ricordi, però, che la memoria
RAM nativa dell’ESP32 è molto ridotta e non permette
grosse memorizzazioni di dati e d’informazioni.
Durante la riproduzione potrebbe udirsi un leggero fru-
scio (molto simile al rumore bianco) che si riduce di tan-
to alla presenza fisica della voce. Si può tentare di atte-
nuarlo con l’adozione di filtri in entrata e utilizzando dei
dispositivi di registrazione migliori, magari coadiuvati da
cavetti schermati.
Nei nostri futuri articoli approfondiremo di più la gestio-
ne dei segnali audio, proponendo altre interessantissi-
me applicazioni con la scheda ESPertino.
Alle prossime.
L’autore è a disposizione nei commenti per eventuali
approfondimenti sul tema dell’Articolo. Di seguito il link per
accedere direttamente all’articolo sul Blog e partecipare alla
discussione:
https://it.emcelettronica.com/mini-registratore-allo-stato-solido-
con-espertino
 Il Kit di ESPertino:
MAK ER temperatura e umidità
sotto controllo con il
DHT11 di Giovanni Di Maria

Il kit di ESPertino prevede, tra gli altri, il sensore di umidità e di pressione DHT11. Vediamo come uti-
lizzarlo al meglio con la nostra scheda, ricordando che i dati da esso misurati e restituiti sono di tipo
digitali e non è necessario alcun ingresso analogico. Utilizzando delle apposite librerie , la gestione del
modulo è ancora più semplice.

IL SENSORE

S
i tratta di un dispositivo per rilevare la
temperatura e l’umidità (vedi figura 1).
Può essere adottato in tanti ambiti di-
versi come, ad esempio, deumidificatori, con-
trolli automatici, stazioni meteo, domotica, ecc.
Le sue misure risultano molto ridotte e, non
considerando i piedini di connessione, sono di
12mm. x 5.5mm. x 15.5mm. E’ dotato di un sen-
sore di umidità e di un termistore di tipo NTC.
Come detto nell’introduzione, esso fornisce le
elaborazioni tramite un segnale digitale e non
analogico. E’ necessario, pertanto, predisporre
un adeguato algoritmo di acquisizione e deco-
difica. La lettura delle informazioni acquisite,
per la sua conformazione elettronica, può es-
sere effettuata, come affermato dal datasheet,
almeno ogni sei secondi. Letture consecutive
più ravvicinate potrebbero influire negativamen-
te sulla bontà delle misurazioni. Al di la di tale Figura 1: il sensore di temperatura e di umidità DHT11
aspetto esso può essere considerato un com-
ponente esente da interferenze, molto affidabile non deve essere collegato.
e preciso, anche a lungo termine. Il datasheet fornisce
preziose informazioni in merito. CARATTERISTICHE TECNICHE
Ogni esemplare del sensore è stato accuratamente Il DHT11 misura l’umidità all’interno dell’intervallo 20-
calibrato in laboratorio. I coefficienti della calibrazione 90%RH, con una precisione del +/-5%. La temperatura,
eseguita vengono memorizzati nella sua memoria e invece, è rilevata in un range compreso tra 0°C e 50°C,
utilizzati successivamente dal processo di misurazio- con una accuratezza di +/-2°C. Il dispositivo è, dunque,
ne delle due grandezze fisiche. Il componente riesce a adatto per la maggior parte delle applicazioni.
trasmettere i dati fino a una distanza di 20 metri, con il
cavo naturalmente. La sua piedinatura prevede il colle- LA COMUNICAZIONE DEI DATI
gamento con quattro piedini, anche se il pin numero tre Il DHT11 utilizza una semplificata comunicazione su un

39
 MAKER
solo bus di dati. Essi transitano su una sequenza com-
pleta di 40 bit e precisamente:
• 8 bit per la parte intera dell’umidità;
• 8 bit per la parte decimale dell’umidità;
• 8 bit per la parte intera della temperatura;
• 8 bit per la parte frazionaria della temperatura;
• 8 bit per il checksum.
Qualche esempio chiarirà meglio il concetto. Si suppon-
ga che il sensore spedisca la seguente sequenza di 40
bit:
00110101 00000000 00011000 00000000 01001101
Si può calcolare manualmente il checksum in maniera
estremamente semplice, sommando i primi 4 bytes e
confrontando la somma con il quinto byte:
00110101+
00000000+
00011000+
00000000=
---------
01001101
La somma è equivalente al checksum dell’esempio,
pertanto il pacchetto è stato spedito correttamente. Se
la somma risultasse differente dal quinto byte il dato
finale non sarebbe attendibile. Sempre relativamente
all’esempio di cui sopra, possiamo leggere le seguenti
informazioni sulle due grandezze fisiche:
• l’umidità è pari a (00110101)2=(53%RH)10
• la temperatura è pari a (00011000)2=(24°C)10
SCHEMA DI PRINCIPIO
Lo schema di principio di collegamento è visibile in figu-
ra 2. La sua semplicità, come si può notare, è estrema.
Le informazioni, circa le grandezze fisiche misurate,
viaggiano su una sola linea di dati, bit dopo bit. La resi-
stenza di pull-up da 5K sulla linea dei dati è consigliata
se il cavo risulta più corto di 20 metri. Per lunghezze
maggiori occorrerà scegliere valori differenti. Il modu-
lo del sensore può essere alimentato con una tensio-
ne compresa tra 3.5V e 5.5V. Una raccomandazione
per i programmatori è la seguente: dopo aver fornito
tensione al DHT11 occorre aspettare almeno un se-
condo, prima d’inoltrare qualsiasi comando. In caso
40
contrario si potrebbe verificare una instabilità di funzio-
namento del sistema. E’ caldamente consigliato, altresì,
l’adozione di un condensatore da 100nF collegato tra
l’alimentazione del sensore e la massa, con funzione
di filtro. Può essere montato vicino a esso. Inoltre se il
sensore viene alimentato con una tensione di 3.5VDC, i
relativi cavi di collegamento non dovrebbero superare la
lunghezza di 20cm. In caso contrario, l’inevitabile cadu-
ta di tensione della linea abbasserà l’alimentazione del
sensore causando, molto probabilmente, errori di misu-
ra. Il sensore dovrebbe essere anche montato distante
da altri componenti elettronici “caldi” e non esposto a
luce ultravioletta, pena il degrado delle prestazioni.
LA LIBRERIA PER LA GESTIONE DEL SEN-
SORE DHT11
Sebbene la programmazione “grezza” e a basso livello,
per la comunicazione di ESPertino con il sensore, possa
essere effettuata con un po’ di difficoltà, essa potrebbe
costituire una sfida molto didattica e utile per il program-
matore e lo sviluppatore. Ne verrebbe fuori, tuttavia, un
codice un po’ più lungo ma estremamente riutilizzabile.
In ogni caso esistono tante librerie che gestiscono egre-
giamente il DHT11 e con un minimo sforzo e di tempo si
possono scrivere programmi molto complessi, con po-
che righe di codice. Tutto il funzionamento del sensore
si basa sulla sua restituzione delle informazioni in un
pacchetto composto da 40 bit.
Il metodo proposto dall’articolo installa la libreria in ma-
niera estremamente semplice e trasparente. Non occor-
re installare nulla ma si deve solo accedere alla gestio-
ne delle librerie sull’IDE di Arduino, come mostrato in
figura 3, e scegliere la SimpleDHT.
Dopo la sua selezione essa sarà automaticamente
installata nella cartella C:\Users\NomeUtente\Docu-
ments\Arduino\libraries. Se ciò dovesse risultare un
problema logistico, si può tranquillamente “spostare” la
cartella SimpleDHT nel percorso più comodo ..\ardui-
no-1.8.5\libraries. In questo modo tutte le librerie saran-
no allocate nel medesimo posto, ottenendo un ordine
maggiore delle directory. E’ consigliabile esplorare un
po’ tale cartella, come mostrato in figura 4. Essa contie-
ne anche tanti utilissimi esempi, che possono costituire
un passo iniziale per iniziare a scrivere i propri progetti.
Inoltre, in essa troviamo anche un utile file “readme”, il
file d’inclusione “SimpleDHT.h” e il sorgente della libre-
ria “SimpleDHT.cpp”.
APPROCCIO INIZIALE CON IL MODULO
DHT11
Bene, dopo aver predisposto l’ambiente operativo, sia-
 MAKER

Figura 2: schema di principio

Figura 3: la scelta della libreria SimpleDHT direttamente dall’IDE di Arduino

mo pronti per conoscere il sensore DHT11 e vederne il
suo funzionamento sul campo. Colleghiamolo, dunque,
al nostro ESPertino con dei cavi abbastanza corti, se-
guendo il semplice cablaggio di cui alla figura 5.
La porta 2 di ESPertino è collegata al pin 2 del sensore.
Tale linea costituisce il trasporto dei dati. Come si può
notare, essa è anche collegata a VCC tramite la resi-
stenza di pull-up da 5Kohm. Ovviamente si può utiliz-
zarne anche una dal valore commerciale di 4.7Kohm.
Il sensore è alimentato direttamente dalla VCC della
scheda e la massa, ovviamente, deve essere in comu-
ne ai due dispositivi. Il pin 3 del DHT11 non deve essere

41
 MAKER

Figura 4: gli esempi contenuti nella cartella della libreria SimpleDHT

Figura 5: cablaggio del sistema e pinout del sensore DHT11

utilizzato, secondo le specifiche del suo datasheet. Il
condensatore poliestere da 100nF è collegato tra VCC
e GND per garantire un buon filtraggio da eventuali in-
terferenze esterne.
LO SKETCH DI PROVA
Dopo aver connesso fisicamente i due dispositivi tra di
loro possiamo passare, finalmente, alla parte software
del progetto. Come esperimento per rompere il ghiac-
cio, proviamo semplicemente a far colloquiare ESPer-
tino e il sensore, realizzando un semplice sketch che
visualizzi, sul monitor seriale, la temperatura e l’umidità
dell’ambiente in cui si effettua la misura. Il listato è molto
leggero ma serve per comprendere la filosofia di funzio-

42
 MAKER

01 #include <SimpleDHT.h>

02 int pinDHT11 = 2; // Pin di collegamento

03 SimpleDHT11 dht11; // Oggetto dht11

04 void setup() {

05 Serial.begin(9600);

06 delay(1000); // Pausa iniziale di almeno un secondo

07 }

08 void loop() {

09 byte temperature = 0;

10 byte humidity = 0;

11 dht11.read(pinDHT11, &temperature, &humidity, NULL); // Legge il sensore

12 //---------Visualizza temperatura-------------

13 Serial.print(“Temperature: “);

14 Serial.print((int)temperature);

15 Serial.print(“ °C, “);

16 //---------Visualizza umidita’-------------

17 Serial.print(“Umidita’: “);

18 Serial.print((int)humidity);

19 Serial.println(“ H”);

20 delay(6000);

21 }

namento della libreria SimpleDHT. Esso e riportato sot-
to. Lo commenteremo insieme tra poco. I numeri di linea
progressivi non devono, naturalmente, essere digitati,
e servono solamente come riferimento per i commenti.
Descriviamo, adesso, in dettaglio le linee di programma
più significative, in modo da comprenderne a fondo il
principio di funzionamento.
• Linea 1: il file di header SimpleDHT.h deve essere
incluso nel programma. Si consiglia, anche, di dare
un’occhiata a tale file, per studiare i metodi, i proto-
tipi di funzioni e le costanti in esso contenute;
• Linea 2: la variabile pinDHT11 contiene il numero
del pin al quale fa capo la linea dei dati del sensore.
Ovviamente è possibile utilizzare qualunque altro
nome di variabile e qualsiasi altra porta di ESPer-
tino;
• Linea 3: il funzionamento del programma si basa
sull’utilizzo della classe SimpleDHT11, sulla quale
creiamo l’istanza dell’oggetto “dht11” (o altro nome,
secondo le proprie esigenze);
• Linee 4÷7: la funzione setup() configura la comuni-
cazione seriale a 9600 baud (per la visualizzazione
dei risultati al PC o altri dispositivi equivalenti) e,
soprattutto, imposta una pausa di attesa minima
di un secondo, per dare modo al sensore di essere
operativo. Tale concetto è stato spiegato anche in
precedenza;
• Linee 9÷10: vengono definite, come tipo byte, le va-
riabili “temperature” e “humidity”. Esse conterranno
le rispettive grandezze fisiche, dopo aver effettuato
la lettura dal sensore;
• Linea 11: questa è la riga più importante di tutto

43
 MAKER
• il programma. Essa effettua fisicamente la lettura
delle informazioni dal sensore. Il programmatore
non si accorge minimamente di quanto succede
“dietro le quinte”, in quanto la sequenza di opera-
zioni svolte è davvero abbastanza complessa. Le
funzioni della libreria sono scritte in linguaggio C++
ed eseguono, a basso livello, l’intera gestione del
modulo DHT11. Con questa funzione si prendono
due piccioni con una fava. Essendo le variabili della
temperatura e dell’umidità passate per riferimento
(ossia per indirizzo) e non per valore, la loro resti-
tuzione avviene in un colpo solo. In pratica si tratta
di una funzione che ritorna due valori, per dirla in
maniera molto approssimata;
• Linee 12÷19: con queste linee di codice avviene
semplicemente la visualizzazione dei valori di tem-
peratura e di umidità sul monitor seriale dell’IDE di
Arduino, come mostrato in figura 6;
• Linea 20: il DHT11 è un sensore molto lento. Oc-
corre, dunque, prevedere un lungo lasso di tempo
tra una lettura e la successiva. Nell’esempio ogni
loop attende sei secondi, prima di essere ripetuto.
In ogni caso, sia la temperatura che l’umidità sono
grandezze fisiche molto lente, dotate d’inerzia, per-
tanto il lungo tempo di attesa non costituisce affatto
un problema.
Figura 6: la misurazione della temperatura e dell’umidità con il monitor seriale dell’IDE di Arduino
44
IL FILE DI INTESTAZIONE SIMPLEDHT.H
Andiamo, adesso, a dare un’occhiata al file d’intestazio-
ne SimpleDHT.h. Esso è contenuto nella cartella Sim-
pleDHT della libreria. Può essere aperto con un normale
editor di testo. Nella parte iniziale del contenuto sono
definite alcune costanti, secondo la tabella 1.
Nello stesso file viene definita la classe SimpleDHT
con i seguenti metodi pubblici:
virtual int read(int pin, byte* ptemperature, byte*
phumidity, byte pdata[40]);
dove:
• pin è la porta su cui transitano i dati del sensore;
• ptemperature è la temperatura, in Celsius. Si
può ignorare, passando NULL;
• phumidity è l’umidità. Si può ignorare, passando
NULL;
• pdata è l’insieme dei 40 bit letti dal sensore. Si
può ignorare, passando NULL;
Il parametro dell’umidità subisce qualche modifica a se-
conda del tipo di sensore utilizzato. Se si usa il DHT11
l’umidità sarà restituita in H (esempio: 40H). Se si usa il
DHT22, invece, l’umidità sarà restituita in RH% (esem-
pio: 37%RH). Sempre per quest’ultimo modello si può
utilizzare anche il metodo read2(), che consente di otte-
 MAKER

Costante Valore Significato

SimpleDHTErrSuccess 0 Success

SimpleDHTErrStartLow 100 Error to wait for start low signal

SimpleDHTErrStartHigh 101 Error to wait for start high signal

SimpleDHTErrDataLow 102 Error to wait for data start low signal

SimpleDHTErrDataRead 103 Error to wait for data read signal

SimpleDHTErrDataEOF 104 Error to wait for data EOF signal

SimpleDHTErrDataChecksum 105 Error to validate the checksum

Error when temperature and humidity are zero, it shouldn’t

SimpleDHTErrZeroSamples 106
happen

Tabella 1: costanti

nere dei dati più accurati, in quanto di tipo float:
virtual int read2(int pin, float* ptemperature, float*
phumidity, byte pdata[40]);
Per altri metodi si consiglia di studiare più approfondita-
mente il file SimpleDHT.h.
Leggi anche: Monitoraggio della temperatura con
ESPertino in WiFi con consultazione su Internet
CONCLUSIONI
Con ESPertino e il sensore DHT11 il programmatore
ha la vita abbastanza facile nel realizzare i suoi proget-
ti. Ovviamente le librerie agevolano di tanto il lavoro e
permettono di dedicarsi ad altri aspetti del sistema, ri-
sparmiando tanto tempo. L’ideale, ovviamente, sarebbe
quello di realizzare da sé le proprie librerie, in modo da
riutilizzarle secondo l’esigenze (vedi temporizzazione
del segnale in figura 7). Almeno si saprebbe cosa c’è
“dentro” il programma e in caso di problemi sarebbe
possibile intervenire immediatamente. Le informazioni
acquisite dal sensore, nell’esempio proposto, sono sta-
te visualizzate sul monitor seriale dell’IDE di Arduino.
Ovviamente il loro fine ultimo può essere qualsiasi altro
dispositivo grafico come, ad esempio, un display LCD,
un visualizzatore a diodi Led o trasmessi, addirittura, su
Internet, con funzionamento di Web Server.
L’autore è a disposizione nei commenti per eventuali
approfondimenti sul tema dell’Articolo. Di seguito il link per
accedere direttamente all’articolo sul Blog e partecipare alla
discussione:
https://it.emcelettronica.com/il-kit-di-espertino-temperatura-e-
umidita-sotto-controllo-con-il-dht11

Figura 7: sincronizzazione e comunicazione tra MCU e DHT11

45
 WallPi: quando LEGO
MAK ER incontra Raspberry Pi
di Lorenzo Columbo

LEGO è sicuramente uno dei marchi più noti al mondo. Tra le numerose serie prodotte dalla casa da-
nese, una che suscita particolare interesse tra gli hobbisti è LEGO Technic, che consente di realizzare
piccoli veicoli in plastica. C’è poi un altro marchio che piace tanto a noi, ovvero Raspberry Pi. Ma cosa
succede quando si mettono insieme le enormi potenzialità di queste due realtà? Una delle infinite rispo-
ste possibili è WallPi, un veicolo cingolato dotato di webcam e controllabile over IP.

INTRODUZIONE za: mentre sono stati mantenuti, seppure con qualche

Q
uando si acquista un kit LEGO Technic, il gioco
consiste nell’assemblare un veicolo seguendo
un libretto di istruzioni che descrive l’esatta
sequenza di step partendo da una collezione di pezzi
elementari, dai semplici mattoncini alle meccaniche e
agli snodi, tutto rigorosamente in plastica. Una volta che
il veicolo è stato assemblato, il gioco prosegue appor-
tando modifiche al modello di base realizzato in maniera
del tutto libera, eliminando alcune parti del veicolo che
ci interessano meno e assemblandone di nuove. I vei-
coli sono poi spesso associati a kit di estensione che
includono specifici motorini, di vario tipo e formato, che
consentono di movimentare la struttura meccanica as-
semblata. Per la realizzazione di WallPi è stato scelto
il kit 42038, mostrato in Figura 1, sulla base di raf-
finatissime considerazioni di alta ingegneria: il case
del Raspberry Pi si adattava perfettamente, per forma e
dimensioni, al suo vagone posteriore!
Il modello finale di WallPi, mostrato in copertina, è evi-
dentemente una semplificazione del veicolo di parten-
Figura 1: manuale del kit LEGO Techinc 42038. Il modello rappresentato,
detto “Arctic Truck”, è stato il punto di partenza per la realizzazione di WallPi.
modifica, il vagone posteriore e la cabina di controllo,
la struttura dei cingolati è stata semplificata ai minimi
termini e resa rigida (nel senso che non è più possibile
sterzare), molti dettagli puramente estetici, così come
tutta la parte di trasmissione, sono stati rimossi per ri-
ciclarne i componenti o anche solo per alleggerire la
struttura. Nel modello finale di WallPi, i cingolati vengo-
no movimentati a partire dalle ruote anteriori cui sono
direttamente applicati i due motorini DC, particolarmen-
te evidenti in Figure 2 e 3: la rotazione del veicolo su
sé stesso viene quindi ottenuta movimentando in senso
opposto i due cingolati. Nella parte alta del veicolo, nella
stessa Figura, è poi riconoscibile una struttura realizzata
con lo scopo di consentire una ampia movimentazione
verticale (tilt) della webcam: il servomotore è ben fissato
al veicolo e i suoi terminali di controllo sono anch’essi,
come quelli dei motori DC, riportati su un circuito con-
trollato da Raspberry Pi.
ELENCO DEI COMPONENTI
A questo punto, facciamo un elenco dei
principali componenti, di qualunque natu-
ra, che sono stati necessari alla realizza-
zione di WallPi:
• LEGO 42038 – Arctic Truck;
• LEGO 88003 – Power Functions L-
Motor (2x);
• LEGO 88004 – Power Functions Ser-
vo Motor;
• LEGO 8886 – Power Functions Exten-
sion Wire (2x);
• Raspberry Pi 2 Starter Kit (comprensi-
vo di case e WiFi dongle, O.S. Raspbian
Jessie);
• Webcam Logitech C170;
• USB Power Bank;

46

Figura 2: modello finale di WallPi, vista frontale. I motorini,
riconoscibili in basso, sono applicati direttamente alle ruote
anteriori del cingolato.
• Portabatterie per 8 Stilo AA;
• Breadboard a 300 fori;
• STMicroelectronics L298 - Dual Full Bridge Dri-
ver;
• Vishay Siliconix DG419 – Precision CMOS Ana-
log Switches.
Come si può evincere facilmen-
te, anche soltanto guardando i
costi dei componenti LEGO,
WallPi non è propriamente un
campione di economia: con
cifre paragonabili o addirittura
più basse sono già disponibili
sul mercato piattaforme roboti-
che di funzionalità pari o supe-
riori. Come altri progetti open-
source disponibili online, anche
WallPi ha più senso come
esperienza ludica e formativa
che come prodotto finito.
CIRCUITO DI CONTROL-
LO DEI MOTORINI
In Figura 4 è riportato lo sche-
matico KiCad del circuito per il
MAKER
controllo dei motorini.
Dei 40 pin di GPIO del Raspberry Pi 2, soltanto 6 sono
realmente utilizzati da WallPi. Oltre al riferimento di
massa e a quello a 3.3 V, due pin general-purpose
vengono impiegati per l’azionamento (diretto e in-
verso) di ciascuno dei due motorini DC; un pin do-
tato di circuiteria per la PWM è invece dedicato al
controllo del servo.
Il pilotaggio dei motorini DC avviene, in particolare, tra-
mite l’integrato a ponte H della ST, che richiede, su cia-
scuna delle sue porte di uscita, un ponte di diodi esterno
che fornisca un percorso di scarica a bassa impedenza
al carico induttivo costituito dal motorino stesso: i due
pin di uscita dedicati al pilotaggio del motorino vengo-
no allora collegati ai due pin più esterni del connettore
proprietario LEGO a quattro pin (si tratta, in particolare,
dei pin dedicati all’alimentazione, quindi a 0 V e 10 V). Il
pilotaggio del servomotore è invece ottenuto collegando
i due pin di alimentazione a 0 V e 10 V e i due pin cen-
trali di controllo ai due contatti dello switch SPDT della
Vishay, il cui polo è collegato appunto all’uscita PWM
del Raspberry Pi.
La realizzazione su breadboard del circuito descrit-
to pone ovviamente un problema di carattere pratico:
come colleghiamo il circuito ai connettori proprietari
LEGO? Poiché non sono disponibili in commercio con-
nettori LEGO con montaggio a foro passante, ci tocca
armarci di saldatore e termorestringenti: una volta ta-
gliato un cavo di estensione LEGO a metà, si tratta di
separare e spellare ciascuno dei quattro conduttori che
Figura 3: modello finale di WallPi, vista laterale. Il servomotore, riconoscibile in alto, è
dedicato al tilt di una struttura meccanica solidale alla webcam.
47
 MAKER
Figura 4: schematico KiCad del circuito per il controllo dei motorini di WallPi.
lo costituiscono, quindi saldare alla estremità di ciascu-
no di essi un cavo unipolare. Il punto di saldatura sarà
ricoperto con la guaina termorestringente. Il risultato fi-
nale, rappresentato in Figura 5, è un cavo LEGO final-
mente adatto alla connessione su breadboard.
CONTROLLO TRAMITE PYTHON 3, WIRING
PI E GSTREAMER
A questo punto, l’hardware di WallPi è completo e si
tratta di individuare gli strumenti di sviluppo SW che
rendano semplice l’implementazione della funzionalità
di controllo del veicolo over IP.
48
L’applicazione sarà distribuita tra due terminali, un
server costituito appunto dal veicolo, nonché dal
Raspberry Pi di cui è dotato, e un client che potrà ot-
tenere il controllo delle funzionalità del veicolo tra-
mite connessione ad uno specifico indirizzo IP e ad
una specifica porta. Naturalmente, tutto potrà avvenire
all’interno di una WLAN o, previa opportuna configura-
zione del router cui il server è collegato, tra due nodi IP
dislocati in qualunque parte del mondo.
La scelta per l’implementazione della parte di acquisi-
zione e trasmissione dello streaming audio/video è ri-
caduta su una eccellente libreria C open-source appo-
 MAKER
Figura 5: cavo LEGO modificato per un uso agevole con la breadboard. I quattro terminali sono prolungati tramite altrettanti sem-
plici cavetti unipolari, saldati ad essi e mantenuti in posizione tramite una guaina termorestringente.
sitamente pensata per semplificare la realizzazione di
applicazioni che trattano dati multimediali: GStreamer
definisce un’architettura a pipeline che consente di con-
nettere in pochissimo tempo una serie di componenti
software virtualmente per qualunque tipo di elaborazio-
ne di dati multimediali. La libreria include già compo-
nenti ampiamente collaudati e utili per esempio all’ac-
quisizione e alla riproduzione di streaming audio/video,
alla realizzazione di vari tipi di filtraggio, all’encoding e
decoding nei formati audio/video più diffusi.
Per quanto riguarda il controllo dei GPIO del Raspberry
Pi in WallPi, l’utilizzo del modulo RPi.GPIO pone un pro-
blema non trascurabile: la sua release più recente non
fornisce ancora il supporto per l’hardware PWM, di cui
WallPi ha bisogno per il controllo del servomotore. Per
questo motivo, è stato necessario impiegare un’altra li-
breria open-source per il controllo dei GPIO di Raspber-
ry Pi: la scelta è ricaduta su Wiring Pi, una libreria C in
grado di sfruttare l’hardware PWM sui pin del BCM2835
che prevedono la circuiteria dedicata a questo scopo e
che offre anche un controllo da linea di comando.
L’APPLICAZIONE WALLPI: IL SORGENTE
COMPLETO
Analizziamo quindi il sorgente Python 3 che implementa
le funzionalità descritte.
Lato server, l’applicazione dovrà essenzialmente aprire
una porta TCP/IP in attesa di connessioni dall’esterno:
come si evince dalle definizioni di righe 32-35, oltre a
questa porta sarà necessario definire altre tre porte
per lo streaming dei dati audio e video che viaggeran-
no tramite UDP/IP. Dopo la definizione iniziale di questi
parametri e l’import di alcuni package standard, viene
eseguito uno script che definisce una classe WallPiStre-
amer: come vedremo in seguito, tale classe incapsula
le funzionalità di GStreamer richieste dall’applicazione,
fornendo un comodo layer intermedio per il loro utilizzo.
Le righe 50-59 verificano che il sistema operativo in uso
sia basato su Linux ed eseguono il parsing degli argo-
menti specificati al lancio dello script: in particolare, l’ap-
plicazione server può essere lanciata abilitando seletti-
vamente gli streaming audio e video verso il client e lo
streaming audio proveniente da client. Una nota su que-
sto aspetto: sul veicolo, come anticipato, lo streaming
audio e video viene catturato dalla webcam dedicata; la
riproduzione audio, invece, dovrebbe avvenire tramite
l’uscita mini-jack resa disponibile dal Raspberry Pi 2.
L’istruzione a riga 66 estrae l’indirizzo IP del server ese-
guendo un comando shell: tale indirizzo è necessario
a realizzare il setup del server socket alle righe 77-81.
Successivamente, si procede al setup dei GPIO neces-
sari alla movimentazione del veicolo tramite comandi
shell che richiamano le funzioni della già citata libreria
Wiring Pi. Quindi, alla riga 98, il server socket viene po-
sto in attesa di una singola connessione entrante: da
questo momento in poi, l’applicazione WallPi sul nodo
di client che raggiunga la porta TCP/IP corretta potrà
guadagnare il controllo del veicolo. In corrispondenza
delle righe 103-108, viene quindi abilitata la trasmis-
sione/ricezione degli streaming audio/video tramite co-
struzione di appositi oggetti WallPiStreamer: al termine
[segue a pag. 60]
49
 MAKER

###############################################################################
## Project : WallPi
## Module : wallpi_server
## Language : Python3
##
## Filename : wallpi_server.py
##
## Created by : Lorenzo Columbo
## Created at : 03.07.16
## Revision : 1.0.0
##
## ++
## Description : WallPi Application - Server Side
## This script allows to prepare for and serve an incoming
## TCP/IP connection request from the WallPi client, in order
## to provide all available remote control features.
## By executing this script, the following information is sent
## over the network towards the WallPi client:
## 1) video streaming captured from the local webcam, in order
## to reproduce it remotely;
## 2) audio streaming captured from the local microphone, in
## order to reproduce it remotely.
## At the same time, the following information is received over
## the network from the WallPi client:
## 1) controls for the motors available on the WallPi machine;
## 2) audio streaming captured from the remote microphone, in
## order to reproduce it on the WallPi machine.
## ++
###############################################################################

# Specify TCP/IP connection parameters

WALLPI_CTRL_PORT = 10000
WALLPI_AUDIO_S2C_PORT = 10010
WALLPI_VIDEO_S2C_PORT = 10011
WALLPI_AUDIO_C2S_PORT = 10012

# Import needed packages and recall general utility modules

import os, sys, socket
import subprocess
import argparse

with open(“WallPiStreamer.py”) as fid:

50
 MAKER

exec(fid.read())

# Specify some WallPi machine specific constants

PWM_VALUES = [ 0, 64, 128, 192, 256, 320, 384, 512, \
640, 704, 768, 832, 896, 960, 1024]

# Check current operating system (only Linux-based operating systems are allowed)
if(sys.platform != “linux”):
print(“Can’t start WallPi on “ + sys.platform + “ platform. Only linux-based platforms are allowed. Exiting.”)
sys.exit()

# Parse command-line arguments

parser = argparse.ArgumentParser(description=”WallPi application - server side: provide the control of the WallPi
machine.”)
parser.add_argument(‘--s2c_aud’, help=’enable sending audio streaming from server to client’, action=’store_
true’)
parser.add_argument(‘--s2c_vid’, help=’enable sending video streaming from server to client’, action=’store_true’)
parser.add_argument(‘--c2s_aud’, help=’enable receiving audio streaming from client to server’, action=’store_
true’)
args = parser.parse_args()

s2c_aud_en = args.s2c_aud
s2c_vid_en = args.s2c_vid
c2s_aud_en = args.c2s_aud

# Get local IP address

wallpi_server_addr = str(subprocess.check_output(“hostname -I”, shell=True))[2:-4]

# Print a welcome message, introducing the application interactive usage

print(“--------------------------------------------------------------------------------” + “\n” + \
“WallPi server will now open a server socket to accept incoming connections: “ + “\n” + \
“when this will be done, an audio streaming will be received and an audio/video “ + “\n” + \
“streaming will be sent; moreover, the client side user will be able to control “ + “\n” + \
“the movement of the WallPi machine using the numeric pad.” + “\n” + \
“--------------------------------------------------------------------------------” + “\n”)

# Setup a server socket waiting for a single incoming TCP/IP connection request
serversocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
serversocket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
serversocket.bind((wallpi_server_addr, WALLPI_CTRL_PORT))

# Setup the WallPi servo-motor control pin (BCM number) to PWM mark-space mode

51
 MAKER

os.system(“gpio -g mode 13 pwm”)

os.system(“gpio -g pwm-ms”)
pwm_index = int(len(PWM_VALUES)/2)
os.system(“gpio -g pwm 13 “ + str(PWM_VALUES[pwm_index]))

# Setup the WallPi DC-motor control pins (BCM number)

os.system(“gpio -g mode 5 out”)
os.system(“gpio -g mode 6 out”)
os.system(“gpio -g mode 9 out”)
os.system(“gpio -g mode 11 out”)

# Open a client socket towards the IP address specified by the server socket and accept only
# an incoming connection from the specified client address; handle a single client connection
# at time; to break the infinite loop, use Ctrl-C key (raising Keyboard Interrupt)
address = (0, 0);
while (True):
serversocket.listen(1)
(clientsocket, address) = serversocket.accept()
wallpi_client_addr = address[0]

# Start to send the audio/video streaming

if (s2c_aud_en == True):
audio_sender = WallPiStreamer(“audio”, “send”, wallpi_client_addr, WALLPI_AUDIO_S2C_PORT)
if (s2c_vid_en == True):
video_sender = WallPiStreamer(“video”, “send”, wallpi_client_addr, WALLPI_VIDEO_S2C_PORT)
if (c2s_aud_en == True):
audio_recver = WallPiStreamer(“audio”, “recv”, wallpi_server_addr, WALLPI_AUDIO_C2S_PORT)

# Provide the motor control functionality to the client

ctrl_char = ‘\x00’
while (ctrl_char != ‘-’):
ctrl_char = clientsocket.recv(1).decode()
if (ctrl_char == ‘9’):
if pwm_index < len(PWM_VALUES)-1: pwm_index = pwm_index + 1 os.system(“gpio -g pwm 13 “ +
str(PWM_VALUES[pwm_index])) elif (ctrl_char == ‘3’): if pwm_index > 0:
pwm_index = pwm_index - 1
os.system(“gpio -g pwm 13 “ + str(PWM_VALUES[pwm_index]))
elif (ctrl_char == ‘8’):
os.system(“gpio -g write 5 0”)
os.system(“gpio -g write 6 1”)
os.system(“gpio -g write 9 0”)
os.system(“gpio -g write 11 1”)

52
 MAKER

elif (ctrl_char == ‘2’):

os.system(“gpio -g write 5 1”)
os.system(“gpio -g write 6 0”)
os.system(“gpio -g write 9 1”)
os.system(“gpio -g write 11 0”)
elif (ctrl_char == ‘5’):
os.system(“gpio -g write 5 0”)
os.system(“gpio -g write 6 0”)
os.system(“gpio -g write 9 0”)
os.system(“gpio -g write 11 0”)
elif (ctrl_char == ‘6’):
os.system(“gpio -g write 5 1”)
os.system(“gpio -g write 6 0”)
os.system(“gpio -g write 9 0”)
os.system(“gpio -g write 11 1”)
elif (ctrl_char == ‘4’):
os.system(“gpio -g write 5 0”)
os.system(“gpio -g write 6 1”)
os.system(“gpio -g write 9 1”)
os.system(“gpio -g write 11 0”)
else :
pass

# End to send the audio/video streaming

if (s2c_aud_en == True):
del(audio_sender)
if (s2c_vid_en == True):
del(video_sender)
if (c2s_aud_en == True):
del(audio_recver)

# Close the client socket

clientsocket.shutdown(socket.SHUT_RDWR)
clientsocket.close()

# Close the server socket

serversocket.shutdown(socket.SHUT_RDWR)
serversocket.close()

53
 MAKER

della connessione, l’eliminazione di tali oggetti consenti-
rà di interrompere gli streaming e liberare quindi le porte
UDP che erano state ad essi associate.
Resta quindi da implementare unicamente il controllo
del movimento del veicolo sulla base dei caratteri che
il server riceve dal client tramite la connessione TCP/IP
precedentemente realizzata: il codice alle righe 111-148
esegue un semplice ciclo while che, sulla base del ca-
rattere ricevuto, pilota le GPIO dedicate al controllo del
servomotore e dei motorini DC (i caratteri usati a questo
scopo sono quelli del tastierino numerico). Alla ricezione
del carattere speciale ‘-‘, il ciclo viene interrotto e l’ap-
plicazione server procede alla chiusura degli streaming
audio/video, per portarsi nuovamente nella condizione
di attesa di un’eventuale connessione da parte di un al-
tro client.
Passiamo quindi al commento del sorgente relativo
all’applicazione client. In questo caso, dopo la necessa-
ria definizione delle porte IP (che dovranno ovviamente
matchare quelle specificate nell’applicazione server),
l’import dei package standard e il parsing degli argo-
menti specificati da linea di comando, tra i quali compa-
re l’indirizzo IP del server che deve naturalmente essere
noto al momento del lancio della applicazione, si proce-
de all’apertura di un client socket verso il server. Se tale
operazione va a buon fine, si costruiscono gli oggetti
WallPiStreamer che consentono di trasmettere e riceve-
re gli streaming audio/video previsti dalla applicazione,
ammesso che l’utente abbia richiesto la loro abilitazione
al lancio della applicazione.
Le righe 101-108 eseguono un ciclo while che consente
[segue a pag. 63]

###############################################################################
## Project : WallPi
## Module : wallpi_client
## Language : Python3
##
## Filename : wallpi_client.py
##
## Created by : Lorenzo Columbo
## Created at : 03.07.16
## Revision : 1.0.0
##
## ++
## Description : WallPi Application - Client Side
## This script allows to establish a TCP/IP connection with the
## WallPi server, in order to access to all of its remote
## control features.
## By executing this script, the following information is sent
## over the network towards the WallPi server:
## 1) controls for the motors available on the WallPi machine;
## 2) audio streaming captured from the local microphone, in
## order to reproduce it on the WallPi machine.
## At the same time, the following information is received over
## the network from the WallPi server:
## 1) video streaming captured from the remote webcam, in order
## to reproduce it locally;
## 2) audio streaming captured from the remote microphone, in
## order to reproduce it locally.
## ++
###############################################################################

# Specify IP connection ports

54
 MAKER

WALLPI_CTRL_PORT = 10000
WALLPI_AUDIO_S2C_PORT = 10010
WALLPI_VIDEO_S2C_PORT = 10011
WALLPI_AUDIO_C2S_PORT = 10012

# Import needed packages and recall general utility modules

import sys, socket
import subprocess
import argparse
import threading
import gi
gi.require_version(‘Gtk’, ‘3.0’)
from gi.repository import Gtk

with open(“getch.py”) as fid:

exec(fid.read())
with open(“WallPiStreamer.py”) as fid:
exec(fid.read())

# Check current operating system (only Linux-based operating systems are allowed)
if(sys.platform != “linux”):
print(“Can’t start WallPi on “ + sys.platform + “ platform. Only linux-based platforms are allowed. Exiting.”)
sys.exit()

# Parse command-line arguments

parser = argparse.ArgumentParser(description=”WallPi application - client side: get the control of the WallPi
machine.”)
parser.add_argument(‘-H’, ‘--host’, required=False, default=’127.0.0.1’, help=’host address of the WallPi server’)
parser.add_argument(‘--s2c_aud’, help=’enable receiving audio streaming from server to client’, action=’store_
true’)
parser.add_argument(‘--s2c_vid’, help=’enable receiving video streaming from server to client’, action=’store_
true’)
parser.add_argument(‘--c2s_aud’, help=’enable sending audio streaming from client to server’, action=’store_
true’)
args = parser.parse_args()

wallpi_server_addr = args.host
s2c_aud_en = args.s2c_aud
s2c_vid_en = args.s2c_vid
c2s_aud_en = args.c2s_aud

# Get local IP address

wallpi_client_addr = str(subprocess.check_output(“hostname -I”, shell=True))[2:-4]

# Print a welcome message, introducing the application interactive usage

print(“--------------------------------------------------------------------------------” + “\n” + \
“WallPi client will now connect to the specified WallPi server address: when “ + “\n” + \
“this will be done, an audio/video streaming will be received and an audio “ + “\n” + \

55
 MAKER

“streaming will be sent; moreover, the client side user will be able to control “ + “\n” + \
“the movement of the WallPi machine using the following numeric pad keys:” + “\n” + \
“8 => move forward” + “\n” + \
“2 => move backward” + “\n” + \
“6 => turn right” + “\n” + \
“4 => turn left” + “\n” + \
“5 => stop” + “\n” + \
“9 => raise camera vertical angle” + “\n” + \
“3 => lower camera vertical angle” + “\n” + \
“- => close connection” + “\n” + \
“--------------------------------------------------------------------------------” + “\n”)

# Open a client socket towards specified TCP/IP address:port

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((wallpi_server_addr, WALLPI_CTRL_PORT))

# Start the requested media streaming

if (s2c_aud_en == True):
audio_recver = WallPiStreamer(“audio”, “recv”, wallpi_client_addr, WALLPI_AUDIO_S2C_PORT)
if (s2c_vid_en == True):
video_recver = WallPiStreamer(“video”, “recv”, wallpi_client_addr, WALLPI_VIDEO_S2C_PORT)
if (c2s_aud_en == True):
audio_sender = WallPiStreamer(“audio”, “send”, wallpi_server_addr, WALLPI_AUDIO_C2S_PORT)

# Continuously get single control characters from the stdin and send it to sock
ctrl_char = ‘\x00’
while ctrl_char != ‘-’:
ctrl_char = getch()
sent = sock.send(ctrl_char.encode())
if sent == 0:
raise RunTimeError(“Socket connection broken!”)
else:
pass

# End the started media streaming

if (s2c_aud_en == True):
del(audio_recver)
if (s2c_vid_en == True):
del(video_recver)
if (c2s_aud_en == True):
del(audio_sender)

# Close the client socket

sock.shutdown(socket.SHUT_RDWR)
sock.close()

56
 MAKER

all’utente di immettere un carattere alla volta, tramite
esecuzione della funzione getch: tale funzione è definita
tramite lo script eseguito in precedenza, in righe 46-47,
e se ne può recuperare il sorgente in rete. Alla pressio-
ne del carattere speciale ‘-‘, il ciclo while viene interrotto
e l’applicazione client termina, dopo tutte le necessarie
operazioni di chiusura e rilascio delle risorse allocate.
Infine, diamo uno sguardo al sorgente della classe
WallPiStreamer, la cui responsabilità è quella di forni-
re le funzionalità di audio/video streaming necessarie
all’applicazione WallPi in maniera del tutto trasparente
ad essa: come già discusso, l’implementazione di tali
funzionalità è stata ottenuta tramite utilizzo della libreria
GStreamer.
Alla costruzione dell’oggetto WallPiStreamer, vengono
eseguite tutte le operazioni necessarie alla creazione
e inizializzazione della pipe per la ricezione o trasmis-
sione (send/recv) di un certo tipo di streaming (audio/
video) da o verso un certo indirizzo e una certa por-
ta IP (ip_addr e ip_port). Dopo il necessario parsing
dei suoi argomenti (righe 16-47), il costruttore crea
la pipeline GStreamer e ne inizializza il bus per il
reporting dei messaggi provenienti dai componen-
ti che saranno istanziati all’interno di essa. Quindi
(righe 55-89), sulla base del tipo di streaming richiesto,
viene creato il set di tutti i componenti necessari alla
sua trasmissione e ricezione: di questi componenti,
[segue a pag. 66]

import gi
gi.require_version(‘Gst’, ‘1.0’)
gi.require_version(‘GstBase’, ‘1.0’)
gi.require_version(‘Gtk’, ‘3.0’)
from gi.repository import GObject, Gst, GstBase, Gtk, GObject

import re

class WallPiStreamer:

def __init__(self, audio_video, send_recv, ip_addr, ip_port):

Gst.init(None)

# Check input arguments correctness

if (isinstance(audio_video, str)):
if (re.match(“^(audio|video)$”, audio_video)):
self.audio_video = audio_video
else:
raise ValueError(“For argument audio_video, specify one value among {‘audio’, ‘video’}.”)
else:
raise TypeError(“For argument audio_video, specify a string value.”)

if (isinstance(send_recv, str)):
if (re.match(“^(send|recv)$”, send_recv)):
self.send_recv = send_recv
else:
raise ValueError(“For argument send_recv, specify one value among {‘send’, ‘recv’}.”)
else:
raise TypeError(“For argument send_recv, specify a string value.”)

if (isinstance(ip_addr, str)):
if (re.match(“^(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-
5])$”, ip_addr)):

57
 MAKER

self.ip_addr = ip_addr
else:
raise ValueError(“For argument ip_addr, specify one properly formatted IP address (e.g., ‘127.0.0.1’).”)
else:
raise TypeError(“For argument ip_addr, specify a string value.”)

if (isinstance(ip_port, int)):
if (ip_port >= 0 and ip_port <= 65535):
self.ip_port = ip_port
else:
raise ValueError(“For argument ip_port, specify one value in the range 0-65535.”)
else:
raise TypeError(“For argument ip_port, specify an integer value.”)

# Create the pipeline and add a watch to the message bus

self.pipeline = Gst.Pipeline()
bus = self.pipeline.get_bus()
bus.add_signal_watch()
bus.connect(“message”, lambda b,m : print(“ERROR from {}: {}”.format(m.src, m.parse_error())) if (m.type ==
Gst.MessageType.ERROR) else m)

# Create gst elements needed for all usage scenarios of this class
if (audio_video == “audio”):
mediasrc = Gst.ElementFactory.make(“alsasrc”, “gst4rtp_audiosrc” )
mediasrc.set_property(“device”, “hw:CARD=C170,DEV=0”)
mediasrccaps = Gst.ElementFactory.make(“capsfilter”, “gst4rtp_audiosrccaps”)
mediasrccaps.set_property(“caps”, Gst.Caps.from_string(“audio/x-raw, format=(string)S16LE, layout=(string)
interleaved”))
mediasink = Gst.ElementFactory.make(“autoaudiosink”, “gst4rtp_audiosink” )
mediaenc = Gst.ElementFactory.make(“mulawenc”, “gst4rtp_mulawenc” )
mediadec = Gst.ElementFactory.make(“mulawdec”, “gst4rtp_mulawdec” )
mediapay = Gst.ElementFactory.make(“rtppcmupay”, “gst4rtp_rtppcmupay” )
mediadepay = Gst.ElementFactory.make(“rtppcmudepay”, “gst4rtp_rtppcmudepay”)
udpsink = Gst.ElementFactory.make(“udpsink”, “gst4rtp_udpsink”)
udpsink.set_property(“host”, ip_addr)
udpsink.set_property(“port”, ip_port)
udpsrc = Gst.ElementFactory.make(“udpsrc”, “gst4rtp_udpsrc”)
udpsrc.set_property(“address”, ip_addr)
udpsrc.set_property(“port”, ip_port)
udpsrc.set_property(“caps”, Gst.Caps.from_string(“application/x-rtp”))
else:
mediasrc = Gst.ElementFactory.make(“v4l2src”, “gst4rtp_videosrc” )
mediasrc.set_property(“device”, “/dev/video0”)
mediasrccaps = Gst.ElementFactory.make(“capsfilter”, “gst4rtp_videosrccaps”)
mediasrccaps.set_property(“caps”, Gst.Caps.from_string(“video/x-raw, width=(int)640, height=(int)480, pixel-
aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, framerate=(fraction)15/1”))
mediasink = Gst.ElementFactory.make(“autovideosink”, “gst4rtp_videosink” )

58
 MAKER

mediaenc = Gst.ElementFactory.make(“jpegenc”, “gst4rtp_jpegenc” )

mediadec = Gst.ElementFactory.make(“jpegdec”, “gst4rtp_jpegdec” )
mediapay = Gst.ElementFactory.make(“rtpjpegpay”, “gst4rtp_rtpjpegpay” )
mediadepay = Gst.ElementFactory.make(“rtpjpegdepay”, “gst4rtp_rtpjpegdepay”)
udpsink = Gst.ElementFactory.make(“udpsink”, “gst4rtp_udpsink”)
udpsink.set_property(“host”, ip_addr)
udpsink.set_property(“port”, ip_port)
udpsrc = Gst.ElementFactory.make(“udpsrc”, “gst4rtp_udpsrc”)
udpsrc.set_property(“address”, ip_addr)
udpsrc.set_property(“port”, ip_port)
udpsrc.set_property(“caps”, Gst.Caps.from_string(“application/x-rtp, media=(string)video, clock-
rate=(int)90000, encoding-name=(string)JPEG, a-framerate=(string)15.000000, a-framesize=(string)640-480,
payload=(int)26, ssrc=(uint)3843998606, timestamp-offset=(uint)1259879843, seqnum-offset=(uint)970”))

# Add to the pipeline all elements needed by the specific chosen configuration and link them properly
if (send_recv == “send”):
self.pipeline.add(mediasrc)
self.pipeline.add(mediasrccaps)
self.pipeline.add(mediaenc)
self.pipeline.add(mediapay)
self.pipeline.add(udpsink)
mediasrc.link(mediasrccaps)
mediasrccaps.link(mediaenc)
mediaenc.link(mediapay)
mediapay.link(udpsink)
else:
self.pipeline.add(udpsrc)
self.pipeline.add(mediadepay)
self.pipeline.add(mediadec)
self.pipeline.add(mediasink)
udpsrc.link(mediadepay)
mediadepay.link(mediadec)
mediadec.link(mediasink)

# Start the media streaming

self.pipeline.set_state(Gst.State.PLAYING)

def __del__(self):
# Stop the media streaming
self.pipeline.set_state(Gst.State.NULL)

59
 MAKER
Figura 6: Screenshot dell’applicazione WallPi in esecuzione (lato client).
naturalmente, soltanto una parte verrà realmente istan-
ziata nella pipe, a seconda della direzione dello strea-
ming specificata. La costruzione della pipe viene quindi
ottenuta dalle righe 93-101 per la trasmissione e 103-
109 per la ricezione. Infine, il costruttore avvia lo strea-
ming ponendo la pipe nello stato di riproduzione.
ESECUZIONE DELL’APPLICAZIONE WALLPI
Una volta lanciata l’applicazione server sul Raspberry
Pi che controlla il veicolo, è possibile lanciare in maniera
analoga l’applicazione client su una qualunque macchi-
na sulla stessa rete IP, eseguendo il comando:
A questo punto, lo streaming audio e video in ricezione
verrà riprodotto e si otterrà il controllo remoto del veico-
lo, come mostrato nello screenshot di Figura 6.
Al lancio dell’applicazione client, un messaggio descri-
ve in maniera chiara i comandi di movimento: la pres-
sione dei pulsanti 8 e 2 comporterà la movimentazione
del veicolo rispettivamente in avanti e indietro, mentre
i pulsanti 4 e 6 determineranno la rotazione del veico-
lo su sé stesso rispettivamente verso sinistra e verso
60
destra; la pressione del pulsante 5 fermerà il veicolo;
infine, la pressione dei pulsanti 9 e 3 comporterà l’in-
clinazione della webcam rispettivamente verso l’alto e
verso il basso.
CONCLUSIONE
WallPi è niente più che un giocattolo, privo di qualunque
utilità che non sia il mero divertimento. D’altra parte, tra-
mite la sua realizzazione, si è potuto mettere in luce an-
cora una volta la versatilità della piattaforma Raspberry
Pi e soprattutto cominciare a sperimentare le enormi po-
tenzialità della libreria GStreamer, estremamente utile
in tutte quelle applicazioni che richiedono un qualunque
tipo di manipolazione di dati multimediali.
L’autore è a disposizione nei commenti per eventuali
approfondimenti sul tema dell’Articolo. Di seguito il link per
accedere direttamente all’articolo sul Blog e partecipare alla
discussione:
https://it.emcelettronica.com/wallpi-quando-lego-incontra-
raspberry-pi
 Il Kit di ESPertino:
MAK ER
misuriamo le distanze
con il modulo a
ultrasuoni HY-SRF05
di Giovanni Di Maria

Il kit di ESPertino comprende anche un modulo a ultrasuoni per la rilevazione di distanze da oggetti.
Con esso, la nostra scheda può contare su un ulteriore sistema sensoriale, per la realizzazione di robot,
automatismi e circuiti di rilevazione intelligente.

INTRODUZIONE Il modulo HY-srf05 è un dispositivo per la rilevazione

E
SPertino è una scheda basata su ESP32, pro-
gettata e prodotta in Italia da Elettronica Open
Source. Permette di realizzare facilmente qualsi-
asi tipologia di applicazione e di sistema. Per agevolare
ancora di più i progettisti è a disposizione il Kit ESPerti-
no, una fantastica raccolta di componenti elettronici tra
i quali sono presenti sensori, componentistica attiva e
passiva e altre grandi utilità per l’elettronica.
IL SENSORE DI DISTANZE HY-SRF05
di distanze da oggetti, dotato di cinque pin, che utiliz-
za gli ultrasuoni. E’ anche molto economico, tuttavia si
tratta di una evoluzione rispetto al precedente mo-
dello HC-SR04, in quanto riesce a coprire una distanza
maggiore, fino a 4.5 metri. Inoltre, per il suo cablaggio
con la MCU, si può anche unificare il pin del trigger e
dell’echo, consentendo un risparmio di porte di I/O per
le unità intelligenti.
La seguente tabella riporta le caratteristiche più impor-
tanti:

Tensione di alimentazione compresa tra 4.5V e 5V

Consumo di corrente tra 10mA e 40mA

Angolo di copertura <15°

Intervallo di distanza misurabile compreso tra 2 cm. e 4.5 m.

Risoluzione circa 0.2 cm (2 mm.)

Frequenza degli ultrasuoni emessi 40 Khz

Pin Vcc, Trig (T), Echo (R), Out, GND

Segnale del trigger impulso digitale di 10uS

Output digitale, direttamente proporzionale con la misura

standard. Può essere innestato direttamente in una bre-

Passo dei pin
adboard

Temperatura di funzionamento -20°C ~ 60°C

Dimensioni 45mm. x 21mm.

61
 MAKER

ziare a trasmettere un brevissimo treno d’impulsi

dalla frequenza di 40 kHz (per la precisione otto
impulsi);
3. Si inizi, quindi, a controllare lo stato logico del pin
“Echo”. Inizialmente esso risulterà basso;
4. Non appena lo stato logico del pin “Echo” commuta
a livello alto, occorre iniziare a misurare il tempo nel
quale perdura tale stato logico;
5. Finalmente, quando lo stato logico del pin “Echo”
ritorna basso, si calcoli il tempo totale e si ricavi la
distanza utilizzando la formula: cm=tempo_livello_
alto*(341/100)/2.

Il coefficiente 341, come visto prima, è la velocità di pro-

pagazione del suono nell’aria.
Lasciando il pin “out” inutilizzato si attiva la modalità
“standard” di funzionamento del sensore, detta anche
Figura 1: il sensore di distanza HY-srf05 con il relativo pinout dual-pin, compatibile con il SRF04. Essa implica l’uti-
lizzo dei due pin Trigger e Echo. Se, invece, si collega
La figura 1 mostra il modello del sensore, assieme alla il pin OUT a massa, il pin numero due non è utilizzato e
disposizione dei suoi terminali. viene attivata la modalità single-pin. In questo caso il
sensore utilizza un’unica linea, facente parte al pin tre,
COME SI EFFETTUARE LA MISURA DELLA facendo transitare sulla stessa linea sia il segnale di
DISTANZA eco che quello del trigger e riducendo, di fatto, il nume-
Il sensore srf05 è costituito da un emettitore di ultra- ro di linee necessarie alla comunicazione. Per questa
suoni (il trasmettitore) e da un ricevitore, sempre di ul- eventualità, una singola porta dovrà lavorare prima con
trasuoni. Essi sono orientati verso la stessa direzione. funzionalità di uscita, per poter generare il segnale ini-
Per eseguire la misura della distanza di un oggetto dal ziale di trigger da 10uS, e poi andrà a porsi in funzione
dispositivo, viene inviato un segnale sonoro dal Tx e ri- d’ingresso, per mettersi “in ascolto” e ricevere l’eco ge-
cevuto (di rimbalzo) dall’Rx, come schematizzato nella nerato dal sensore
figura 2. Calcolando opportunamente il tempo intercor-
so tra i due eventi si può stabilire con precisione la stra- COLLEGAMENTI ELETTRICI
da percorsa. E’ utile rammentare che il segnale sonoro Il cablaggio del sensore e di ESPertino risulta mol-
percorre una doppia distanza, in quanto dal trasmetti- to semplice e bastano pochissime connessioni, come
tore arriva all’oggetto interessato e da esso ritorna, di mostra lo schema di cui alla figura 4. L’alimentazione
rimbalzo) al ricevitore. Si ricordi anche che la velocità dell’HY-SRF05 è collegata direttamente a quella della
di propagazione del suono ammonta a circa 341 metri scheda, come pure la massa. Un aspetto a cui occor-
al secondo, nell’aria. E’ utile dare
uno sguardo alla tabella sotto-
stante, per apprezzare i diversi
suoi comportamenti a seconda
del mezzo di trasporto adottato.
In particolare, il proprio algoritmo
deve effettuare i seguenti passi,
come anche evidenziato in figura
3:
1. Si invii un impulso “alto” dalla
lunghezza temporale di al-
meno 10us. sul pin “Trigger”.
2. Tale invio di segnale indica
al sensore che esso può ini- Figura 2: come avviene la misurazione della distanza con gli ultrasuoni

62
 MAKER

Velocità di propagazione
Sostanza
(metri/secondo) [m/s]

Gomma 50

Aria (15ºC) 341

Sughero 500

Idrogeno 1260

Acqua 1460

Mattoni 3650

Marmo 3800

Ferro 5000

Vetro 5200

re prestare molta attenzione è quello della tensione
elettrica erogata dal piedino “Echo”, che equivale a 5V,
non compatibile con quella dell’Esp32. Per “traslare” il
livello e abbassarlo ai fatidici 3.3V è sufficiente adotta-
re un partitore resistivo, formato dai valori di 1Kohm e
2.2Kohm. Le informazione di tale pin, pertanto, sono in-
viate alla porta 16 di ESPertino mentre la linea del “Trig-
ger” fa capo alla porta 17 della stessa scheda.
Per calcolare i valori delle due resistenze del partitore
è stata utilizzata, ovviamente, la legge di Ohm. Esisto-
no tantissime combinazioni di resistori per ottenere la
medesima tensione in uscita. Si potrebbero, per esem-
pio, utilizzare anche due resistenze, rispettivamente dal
valore di 470 ohm e 1000 ohm. Per questa tipologia di
calcolo, con Vcc pari a 5V, una regola da seguire af-
ferma che la resistenza collegata a massa deve avere
un valore ohmico doppio a quello dell’altra resistenza.
Valori commerciali corretti e ammessi potrebbero esse-
re, pertanto, i seguenti: 470 ohm e 1000 ohm, 560 ohm
e 1200 ohm, 1000 ohm e 2200 ohm, 2200 ohm e 4700
ohm, e così via. Per effettuare il calcolo si proceda nel
seguente modo:

Figura 3: come utilizzare il sensore di distanza

63
 MAKER
Figura 4: il cablagio di ESPertino con il sensore di distanza
1. Si stabilisca la corrente di transito nella linea
dell’Echo, in caso di uscita a livello logico alto,
per esempio si assuma un valore di 1.5mA (an-
che altri bassi valori vanno bene);
2. Per calcolare la prima resistenza (quella in alto
verso il pin “Echo”) si utilizzi la formula R=V/I,
ossia R=(5-3.3)/0.0015, che restituisce il valore
1133, assimilabile al valore commerciale di 1K
oppure di 1.2K;
3. Per calcolare la seconda resistenza (quella in
basso verso massa) si esegua la formula R=V/I,
ossia R=3.3/0.0015, che restituisce il valore
2200 esatti.
4. La dissipazione di tali resistenze è estremamen-
64
te bassa, nell’ordine dei millesimi di Watt. Pos-
sono andare bene, dunque, anche le resistenze
di 1/4 di Watt.
Leggi anche: Distanza: sensore ultrasuoni HC-
SR04 e Arduino
LA PROGRAMMAZIONE
Come detto in precedenza il sensore deve essere ali-
mentato con una tensione di 5V sull’omonimo pin Vcc
e la massa su GND. L’attivazione della emissione de-
gli ultrasuoni è effettuata inviando un impulso sul pin
“Trigger” dell’HY-SRF05 della durata di almeno 10
microsecondi. Sul fronte di discesa di tale segnale il
 MAKER

sensore inizia a emettere un “treno” di 8 brevi impulsi
della frequenza di 40KHz. Subito dopo, lo stato logico
del pin “Echo” si porta a livello alto. Occorre aspettare e
misurare la durata di tale impulso, fino a quando il suo
livello logico commuta in basso, segno della ricezione
del suono di ritorno. Se il sensore non capta tale suono
di rimbalzo, dopo qualche istante si pone in stato di ti-
meout. Con queste specifiche e la potenza del linguag-
gio di programmazione, legata anche alla gestione delle
porte digitali, è molto semplice realizzare uno sketch su
misura.
L’esempio che segue utilizza le due linee di dati (echo
e trigger) indipendenti tra loro, anche per una più sem-
plice programmazione. Come si evince dal flusso dei
dati in figura 5, il pin echo del sensore invia un segnale
digitale al pin 16 di ESPertino, quindi quest’ultima deve
essere configurata come ingresso, mentre il pin trigger
del sensore riceverà l’impulso di start dalla MCU attra-
verso la porta numero 17, pertanto essa deve essere
configurata come uscita.
Lo sketch proposto sotto implementa una sorta di metro
elettronico ed esegue le seguenti funzionalità:
• Configura le porte coinvolte nelle operazioni;
• Invia il segnale di trigger (di 10 microsecondi)
per fare iniziare l’emissione degli impulsi ultra-
sonici;
• Misura la durata dell’impulso di eco ricevuto;
• Calcola la corrispondente distanza, in centimetri;
• Effettua una piccola pausa di attesa pari a un
quarto di secondo e reinizia l’intero processo.
zare, ancor di più, le potenzialità di alcune funzioni di
libreria, che rendono il lavoro di programmazione più
snello e affidabile.
LA FUNZIONE PULSEIN()
Con l’utilizzo di tale funzione si riesce, in un unico sta-
tement, a controllare e a misurare l’impulso di eco, pro-
veniente dal sensore di distanza. Cosa fa tale funzione?
Essa legge un impulso digitale (alto o basso) da un pin
della MCU. Per esempio, se il contenuto del parametro
“value” passatole è HIGH, la funzione attende che lo
stato logico del pin esaminato diventi ALTO, quindi ini-
zia a misurarne il tempo e, quando lo stato logico della
porta passa a BASSO, arresta il cronometraggio, resti-
tuendolo al programma. Si potrebbe fare a meno della
funzione pulseIn() e creare, ex novo, tutto il prototipo da
sé. La sua sintassi di utilizzo è la seguente:
dove:
• pin è il numero della porta sulla quale si intende
leggere l’impulso;
• value è il tipo d’impulso che si vuole leggere e
può essere HIGH o LOW;
• timeout, opzionale, è il numero di microsecondi
di attesa per l’inizio dell’impulso.
Se il timeout non è specificato esso, per default, equi-
vale alla pausa di un secondo. La funzione restituisce la
durata dell’impulso misurato, espresso in microsecondi
oppure il valore 0 se nessun impulso è iniziato entro il
timeout impostato.

La figura 6 mostra l’output del

monitor seriale dell’IDE di Ar-
duino, durante il collaudo del
sistema. Un oggetto posto di-
nanzi al sensore viene avvici-
nato e allontanato.

ALCUNI ELEMENTI DE-

GNI DI ATTENZIONE
DELLO SKETCH
Lo sketch, come si vede, è
di una semplicità disarman-
te e anche i principianti non
dovrebbero faticare per com-
prenderlo e per modificarlo,
secondo le proprie esigenze.
Tuttavia vi sono due punti
fondamentali che dovrebbe-
ro essere un tantino appro-
fonditi soprattutto per apprez- Figura 5: la direzione dei segnali di trigger e di eco

65
 MAKER

#define PIN_ECHO 16 // Pin per gli impulsi dell’eco

#define PIN_TRIG 17 // Pin per l’invio del segnale di Trigger

void setup()

Serial.begin(9600);

pinMode(PIN_ECHO, INPUT); // Il pin di echo e’ in ingresso sulla MCU

pinMode(PIN_TRIG, OUTPUT); // Il pin di trigger e’ in uscita sulla MCU

void loop()

//--------- Invio del segnale iniziale di trigger della lunghezza di 10us (Low, High, Low)

digitalWrite(PIN_TRIG, LOW);

delayMicroseconds(2);

digitalWrite(PIN_TRIG, HIGH); // Inpulso effettivo di Trigger

delayMicroseconds(10);

digitalWrite(PIN_TRIG, LOW);

//--------- Calcolo della distanza

float distanza = pulseIn(PIN_ECHO, HIGH); // Misura la lunghezza dell’impulso di eco in microsecondi

distanza=distanza/58; // L’impulso ultrasonico viene inviato e rimbalza indietro. Calcolo di conversione da tempo

a distanza

Serial.print(distanza);

Serial.println(“ cm”);

delay(250);

CONVERSIONE DA TEMPO A DISTANZA Spazio = Velocità * Tempo

Probabilmente i neofiti e i principianti non avranno chia-
ro lo statement che riporta la seguente codifica:
distanza=distanza/58;
dove:
• la velocità del suono, nell’aria, è espressa in me-
tri al secondo ed equivale a circa 341 m/s. La
temperatura influisce su di essa;
• il tempo impiegato dall’onda sonora per compie-
re il tragitto completo è espresso in secondi.

pulseIn(pin, value, [timeout]); Pertanto la formula generica dovrebbe essere la se-

Tale calcolo è frutto di una serie di semplificazioni e di
equivalenze, a dir la verità neanche troppo complesse.
Si deve partire l’analisi osservando l’equazione:
guente:
Spazio = 341 * Tempo
Il sensore, come si è potuto comprendere in preceden-
za, lavora per rimbalzo del segnale audio sull’ostacolo.
Infatti esso emette una frequenza ultrasonica che rag-
giunge l’oggetto di destinazione e ritorna indietro. Il cal-

66
 MAKER
Figura 6: il collaudo del sistema durante le prove di avvicinamento e di allontanamento di un oggetto posto dinanzi al sensore
colo effettivo della distanza percorsa restituirebbe, per-
tanto, un valore doppio. Quindi, si preferisce dividere
per due il risultato di cui sopra:
Spazio = (341 * Tempo)/2
da cui:
Spazio = 170.5 * Tempo
Spesso è consigliabile trasformare le moltiplicazioni in
divisioni, adottando il calcolo del numero reciproco.
L’equivalente formula di cui sopra diventa, quindi:
Spazio = Tempo / (1/170.5)
Spazio = Tempo / 0.0058
Dal momento che il tempo misurato da ESPertino non è
espresso in secondi ma in microsecondi, occorre cam-
biare la formula in:
Spazio = Tempo / 5800
Inoltre la formula deve restituire lo spazio espresso in
metri e non in centimetri, per cui quella definitiva è:
Spazio = Tempo / 58
Se si riscontrano piccole differenze nei risultati si può
ritoccare leggermente il valore della costante, maga-
ri aggiungendo qualche cifra decimale. La velocità del
suono, infatti, potrebbe cambiare in dipendenza della
temperatura.
CONCLUSIONI
Sperimentare con i sensori di distanza a ultrasuoni è
sempre molto interessante. La loro implementazione nei
propri sistemi consente di realizzare dispositivi in grado
d’interagire con il mondo esterno. Un sistema sensoria-
le che accresce le capacità del circuito, consentendogli
di rilevare gli oggetti nelle immediate vicinanze, è sem-
pre il primo passo per realizzare progetti di robotica e di
automazione. In rete vi sono anche alcune librerie per
la gestione ottimale del sensore di distanza. Personal-
mente, l’ultima fornitura richiesta da un cliente, dotata
di sensore di distanza a ultrasuoni, comprendeva un
sistema idraulico per piegare i tubi di ferro. La corsa del-
la piegatrice teneva conto, appunto, della distanza del
sensore da un ostacolo di riferimento e l’entità della pie-
ga era programmata attraverso la scheda ESPertino. Le
applicazioni pratiche sono infinite. Si va dal sensore
di retromarcia per automobile al contametri elettronico,
dal sistema robotizzato per evitare gli ostacoli alla guida
automatica di un piccolo modellino di veicolo, e così via.
L’autore è a disposizione nei commenti per eventuali
approfondimenti sul tema dell’Articolo. Di seguito il link per
accedere direttamente all’articolo sul Blog e partecipare alla
discussione:
https://it.emcelettronica.com/il-kit-di-espertino-misuriamo-le-
distanze-con-il-modulo-a-ultrasuoni-hy-srf05
67
 Controllo gestuale e
MAK ER
ausilio per non vedenti
con la scheda Arduino
[Progetti completi
open source]
In questo articolo presentiamo due progetti innovativi open source, entrambi basati sulla piattaforma
di prototipazione rapida Arduino, le cui finalità non sono soltanto didattiche, ma anche pratiche, con la
possibilità di migliorare la qualità della vita di molte persone.
INTRODUZIONE
I
l primo progetto permetterà infatti di controllare remo-
tamente un piccolo robot o veicolo radiocomandato
tramite il movimento (gestualità) della mano. Il secon-
do progetto consentirà invece di realizzare un vero e
proprio bastone elettronico per non vedenti, in grado di
segnalare la presenza di ostacoli lungo il cammino tra-
mite vibrazione tattile e segnalazione acustica.
PRIMO PROGETTO: CONTROLLO GESTUA-
LE PER ROBOT
Aggiungere a un piccolo robot una funzionalità avanza-
ta come il controllo gestuale è più semplice di quan-
to si possa immaginare. Il progetto si compone di due
parti: un trasmettitore e un ricevitore. Il trasmettitore
andrà opportunamente modificato in modo tale da in-
viare i controli gestuali sotto forma di comandi. Come
piattaforma di sviluppo verrà utilizzato Arduino, il quale
riconoscerà i gesti e i movimenti della mano utilizzando
come sensore un comune accelerometro.
MATERIALE RICHIESTO
I componenti richiesti per la realizzazione del progetto
sono elencati di seguito:
1. accelerometro ADXL335;
2. scheda Arduino;
2. modulo ricetrasmittente RF Module 434-MHz;
3. circuito integrato encoder HT12E;
4. circuito integrato decoder HT12D;
5. circuito integrato per il pilotaggio dei motori;
68
di Stefano Lovati
6. basetta general purpose;
7. motore elettrico a 12v/9v;
8. alimentazione 12/9v;
9. regolatore di tensione 7805;
10. telaio per robot (opzionale), eventualmente au-
tocostruito. Al seguente link una panoramica di
articoli sui robot e le relative tecnologie.
PRINCIPIO DI FUNZIONAMENTO
Il principale sensore utilizzato in questo progetto è rappre-
sentato da un accelerometro a tre assi di tipo ADXL335.
Accelerometri di questo tipo (si osservi la Figura 1) sono
ampiamente utilizzati sui dispositivi mobile (smartphone
e tablet) per numerose applicazioni, tra cui le notifiche e i
giochi (ad esempio Temple Run).
Il cervello del robot è rappresentato dalla board Arduino
Uno (Atmega32) che, accompagnata da un opportuno
software (sketch), è in grado di riconoscere il movimen-
to gestuale in base ai dati forniti dall’accelerometro. Lo
schema a blocchi dell’applicazione è visibile in Figura 2.
L’accelerometro legge le cooordinate X Y Z associate
ai movimenti della mano, e le invia ad Arduino. In que-
sta applicazione non siamo interessati ai valori misurati
lungo l’asse Z, per cui utilizzeremo soltanto i valori re-
lativi alle coordinate X e Y. Lo sketch Arduino controlla i
valori delle coordinate ricevuti, e invia un’informazione
composta da 4 bit (funzione dei valori di X e Y) all’en-
coder. L’encoder, a sua volta, inoltra i dati verso il tra-
smettitore RF. I dati trasmessi da quest’ultimo vengono
ricevuti dal ricevitore RF, che invia i 4 bit dati al circuito
 MAKER
Figura 1: l’accelerometro ADXL335
decoder. Questo esegue la decodifica dei dati e inoltra
la corrispondente informazione decodificata al circuito
del driver per motore. Infine, il driver per i motori decide
in quale direzione devono essere azionati i motori.
Vediamo ora di analizzare i vari passi su cui si articola la
realizzazione del progetto.
STEP 1 – IL CIRCUITO DI ALIMENTAZIONE
Avremo bisogno di due circuiti di alimentazione, uno per
Figura 2: schema a blocchi del progetto
il trasmettitore, e uno per il ricevitore. Il circuito del rice-
vitore richiede di essere alimentato con una tensione di
12 V (necessaria per muovere i motori a 12 V), mentre
il trasmettitore può essere alimentato con una normale
batteria a 9 V (Figura 3).
Figura 3: il circuito di alimentazione
E’ anche possibile aggiungere un led con una resisten-
za da 1 kΩ in modo tale da indicare lo stato attivo o
meno dell’alimentazione.
I componenti utilizzati nel progetto sono i seguenti:
• integrato 7805 che regola la tensione esterna di
12 V al valore di 5 V (se non è possibile disporre
di una tensione esterna da 12 V, si può utilizzar-
ne una a 9 V);
• condensatori da 1 µF e da 470 µF ;
• resistenza da 1 kΩ per il led di stato dell’alimen-
tazione.
Si consiglia inoltre di utilizzare un radiatore per dissi-
pare il calore prodotto dall’integrato 7805 (stiamo infatti
69
 MAKER

Figura 4: schema elettrico del trasmettitore

riducendo una tensione da 12 V a 5 V). senza di due led: uno si accende quando al ricevitore
viene fornita l’alimentazione, mentre l’altro quando l’ali-
STEP 2 – IL TRASMETTITORE mentazione viene fornita al trasmettitore.
Il trasmettitore comprende il sensore accelerometro, Il led vicino all’integrato HT12D si accende quando l’a-
la cui funzione è quella di rilevare i gesti della mano e limentazione viene fornita al trasmettitore, indicando di
inviare l’informazione ad Arduino. Succes-
sivamente, i dati verranno inoltrati all’enco-
der, per essere poi trasmessi verso il ricevi-
tore (Figura 4).
Una volta assemblato, il circuito dovrebbe
essere simile a quello visibile in Figura 5.

STEP 3 – UPLOAD DEL CODICE SU

ARDUINO
Questo step consiste nell’upload del codi-
ce su Arduino, tramite l’ambiente di svilup-
po integrato (IDE).

STEP 4 – IL RICEVITORE
Il circuito del ricevitore comprende due cir-
cuiti integrati (il decoder HT12D e il driver
per motori L293D), e il modulo ricevitore RF.
Il circuito deve essere assemblato come in-
dicato in Figura 6. Notiamo subito la pre- Figura 5: il circuito per il controllo gestuale assemblato

70
 MAKER
Figura 6: schema elettrico del ricevitore
conseguenza la condizione di stato trasmissione valido.
Se ciò non avviene, c’è probabilmente qualcosa da con-
trollare e sistemare nei cablaggi.
Quali tipi di movimenti della mano possono essere
riconosciuti dal robot? Il robot è stato progettato per
riconoscere cinque diverse tipologie di gesti: avanti,
indietro, sinistra, destra, e stop (si osservi la Figura 7).
STEP 5 – APPRONTAMENTO DEL PCB (OP-
ZIONALE)
La scheda Arduino Uno presenta degli ingombri non tra-
scurabili, a maggior ragione se la si vuole impugnare
per rilevare le gestualità manuali. Inoltre, se si in futuro
si vuole realizzare un altro progetto con la stessa sche-
da, occorre rimuoverla dal circuito proposto in questo
articolo ed eliminare tutti i collegamenti, perdendo di
fatto il lavoro compiuto in quell’occasione. Ciò non è
sempre accettabile, ed è stata pertanto sviluppata una
Figura 7: il sistema riconosce cinque diversi tipi di gesti
soluzione che rende permanente il progetto qui descrit-
to. Il layout del PCB associato alla versione standalone
del progetto è visibile in Figura 8.
SECONDO PROGETTO: BASTONE ELET-
TRONICO PER NON VEDENTI
L’obiettivo di questo progetto è stato quello di realizzare
uno strumento in grado di assistere i non vedenti, mi-
gliorando possibilmente la qualità della loro vita e ren-
dendoli più indipendenti negli spostamenti. Il risultato
è stato la realizzazione di un bastone elettronico, o
bastone “intelligente” se vogliamo chiamarlo così, ba-
sato sulla piattaforma di prototipazione rapida Arduino.
Questo progetto open source ha lo scopo di assistere i
non vedenti quando camminano da soli, in autonomia,
in ambienti per loro nuovi e inesplorati. Un sensore ad
ultrasuoni rileva infatti la presenza di ostacoli lungo il
cammino, fornendo un feedback sia di tipo tattile (pro-
71
 MAKER

del progetto è il seguente:

1. una board Arduino Uno;
2. un sensore ad ultrasuoni (HCSR04);
3. una scheda di prototipazione (bre-
adboard);
4. una batteria 9 V;
5. un connettore per batteria a 9 V;
6. un jack maschio per alimentazione
DC;
7. un cicalino (buzzer);
8. alcuni cavetti jumper per i collegamen-
ti elettrici;
9. un cellulare rotto, oppure obsoleto (dal
quale recuperare il motorino per la vibra-
zione);
10. un microswitch.

In Figura 9 possiamo osservare i princi-

pali componenti richiesti per il progetto.
Oltre ai componenti elettronici sopra
menzionati, è necessario procurarsi il se-
guente materiale:
Figura 8: layout del PCB per la versione standalone
1. tubo in PVC con diametro pari a 3/4 di
pollice (necessario per realizzare il basto-
dotto dalla vibrazione di un piccolo motore, analogo a ne da passeggio);
quelli utilizzati sui comuni cellulari), che di tipo acustico. 2. una curva a gomito in PVC da 3/4 di pollice;
Un giorno, l’Autore del progetto [4], mentre stava recan- 3. nastro isolante;
dosi a scuola a piedi, notò una persona non vedente 4. alcune piccole viti per il montaggio della board
che stava camminando sulla stessa strada, incontrando Arduino;
qualche difficoltà dovute soprattutto al numero elevato 5. un cacciavite;
di persone e veicoli che percorrevano quel tratto. For- 6. un coltellino o seghetto;
tunatamente, in quell’occasione, l’Autore fu in grado di 7. colla adesiva instantanea;
assistere il non vedente. Quell’incontro fece balenare 8. una scatola o centenitore in cui collocare la
nella mente dell’Autore l’idea di realizzare un bastone scheda Arduino e il resto dell’elettronica.
per non vedenti “intelligen-
te”, mettendo la tecnologia
al servizio dell’uomo.
I principali requisiti del pro-
getto dovevano essere il
l’economicità (il prototipo
completo è costato solo 10
dollari), e la possibilità di
essere facilmente realiz-
zato (anche dai principian-
ti di elettronica) in poco
tempo, partendo da zero.

MATERIALE RICHIE-
STO
L’elenco dei componenti ri-
chiesti per la realizzazione Figura 9: componenti necessari per realizzare il progetto

72
 MAKER
PRINCIPIO DI FUNZIONAMENTO
Lo schema a blocchi relativo al progetto è evidenziato
dalla Figura 10. Come si può osservare, il principio di
funzionamento è relativamente semplice.
Si possono individuare tre blocchi principali:
1. blocco di input - è composto dal sensore ad
ultrasuoni, in grado di rilevare gli ostacoli posti di
fronte al bastone, con un raggio di azione fino a
400 cm;
2. blocco controllore – è rappresentato dalla
scheda Arduino, il cui software è in grado di de-
terminare se l’ostacolo è troppo vicino al basto-
ne e, nel caso, attivare le corrispondenti segna-
lazioni per l’utente;
3. blocco di output – è composto dal piccolo mo-
tore che genera la vibrazione riconoscibile trami-
te il tatto, e da un buzzer piezoelettrico.
STEP 1 – RECUPERO DEL MOTORE DA UN
CELLULARE DISMESSO
Quest’operazione non è particolarmente complessa,
ma richiede comunque una buona dose di attenzione e
pazienza. Il piccolo motore a vibrazione andrà recu-
perato da un vecchio e inutilizzato cellulare, spesse
volte abbandonato in qualche angolo della casa. Il van-
taggio di questo dispositivo (oltre al costo zero) è quello
di avere delle dimensioni estremamente compatte, e di
richiedere una bassa tensione di alimentazione.
Occorre anzitutto rimuovere dal cellulare le viti che
chiudono il suo guscio, rimuovendo tutte le parti interne
come visibile in Figura 11. Possiamo a questo punto
individuare il motore a vibrazione, situato in prossimità
di un lato del contenitore del telefono. Rimuovete con
attenzione il motorino.
Si noti inoltre come il motorino possa avere forma ed
aspetto differenti, a seconda del modello e del produt-
tore del dispositivo (un altro tipico modello è mostrato
nella Figura 12).
Il motorino andrà poi saldato su una piccola striscia di
basetta millefori, con due spezzoni di filo elettrico colle-
Figura 10: schema a blocchi del progetto
gati ai suoi terminali (Figura 12).
STEP 2 – INTERFACCIAMENTO CON ARDUINO
In Figura 13 sono indicate le connessioni che interes-
sano la board Arduino. Si può utilizzare una piccola bre-
adboard per collegare il sensore ultrasonico ad Arduino,
utilizzando dei normali cavetti jumper. Sia il buzzer che
il motorino possono essere collegati direttamente alla
board.
L’elenco completo dei collegamenti elettrici richiesti
è il seguente:
• il pin VCC del sensore ultrasonico va collegato
al pin 5V di Arduino;
• il pin GND del sensore ultrasonico va collegato
al pin GND di Arduino;
• il pin TRIG del sensore ultrasonico va collegato
al pin D12 di Arduino;
• il pin ECHO del sensore ultrasonico va collegato
al pin D11 di Arduino;
• il filo rosso del buzzer va collegato al pin D8 di
Arduino;
• il filo nero del buzzer va collegato al pin GND di
Arduino;
• il pin 1 del motorino a vibrazione va collegato al
pin D7 di Arduino;
• il pin 2 del motorino a vibrazione va collegato al
pin GND di Arduino;
• il filo rosso della batteria a 9 V va collegato al pin
del microswitch;
• il filo nero della batteria a 9 V va collegato al polo
negativo del jack dell’alimentazione;
• il pin 2 del microswitch va collegato al polo posi-
tivo del jack dell’alimentazione.
In Figura 14 possiamo osservare il risultato ottenuto al
termine dell’assemblaggio.
STEP 3 – UPLOAD DELLO SKETCH SU AR-
DUINO
E’ giunto ora il momento di occuparsi della componen-
73
 MAKER

Figura 11: estrazione del motorino dal cellulare

Figura 12: un altro tipo comune di motorino a vibrazione

Figura 13: i collegamenti elettrici con Arduino

74
 MAKER

Figura 14: assemblaggio completo della parte elettrica

te software del progetto. Lo sketch, riportato qui sotto,

va caricato nell’IDE Arduino, compilato, e programmato
sulla board Arduino. digitalWrite(trigPin, LOW);

#define trigPin 13
#define echoPin 12
duration = pulseIn(echoPin, HIGH);
#define motor 7
distance = (duration/2) / 29.1;
#define buzzer 6

if (distance < 70) // Checking the distance, you

void setup()
can change the value
{
{
pinMode(trigPin, OUTPUT);
digitalWrite(motor,HIGH); // When the the
pinMode(echoPin, INPUT);
distance below 100cm
pinMode(motor, OUTPUT);
digitalWrite(buzzer,HIGH);
pinMode(buzzer,OUTPUT);
}
}
else
{
void loop()
digitalWrite(motor,LOW); // when greater
{
than 100cm
long duration, distance;
digitalWrite(buzzer,LOW);
}
digitalWrite(trigPin, LOW);
delay(500);
delayMicroseconds(2);
}
digitalWrite(trigPin, HIGH);
delayMicroseconds(10);

75
 MAKER

Figura 15: assemblaggio del bastone

Figura 16: assemblaggio finale

STEP 4 – REALIZZAZIONE DEL BASTONE l’impugnatura del bastone.

Per costruire il bastone va benissimo un tubo di PVC Le operazioni da compiere per l’assemblaggio del ba-
con diametro pari a 3/4 di pollice. Servirà inoltre una stone sono le seguenti (si osservi la Figura 15):
curva a gomito, dello stesso diametro, per realizzare • prendete il tubo di PVC, e tagliatene un pezzo

76
 MAKER

o contenitore in cui collocare tutte le

parti elettriche (Figura 16).
La board Arduino andrà fissata all’in-
terno del contenitore utilizzando del-
le apposite viti. Occorre poi praticare
due fori per il fissaggio del sensore
ad ultrasuoni, come indicato in Fi-
gura 16. Il buzzer è stato installato
all’esterno della scatola in modo tale
da non attenuare il suono prodotto.
Il microswitch è stato posizionato
su un lato della scatola, ed è sta-
to praticato un ulteriore piccolo
foro per collegare il motorino a
vibrazione alla board Arduino. La
batteria andrà posizionata anch’es-
sa all’interno del contenitore, e il suo
jack andrà inserito nell’apposita pre-
sa di alimentazione disponibile sulla
scheda Arduino. A questo punto, la
scatola può essere attaccata al ba-
stone da passeggio, utilizzando del-
le viti oppure del collante. Il motore
a vibrazione va infine fissato sotto il
bastone, utilizzando del nastro iso-
lante. Il risultato finale del bastone
da passeggio elettronico per non ve-
denti è visibile in Figura 17.

BIBLIOGRAFIA
1. From Mayoogh Girish, Con-
trol your robot using hand gestures
Figura 17: assemblaggio finale - Maker at DIY Hacking
2. From Suhail, Arduino smart
lungo circa un metro e mezzo; cane for the visually impaired: best Arduino
• prendete la curva a gomito, e attaccatela a una project - Maker at DIY Hacking
delle estremità del bastone;
• prendete un altro tratto di tubo di PVC, lungo
circa 10 cm, e attaccatelo all’altra estremità del
bastone;
• fissate tutti i pezzi con della colla o mastice ade-
sivo.

Se si desidera, si può poi dipingere il bastone con il co-

lore desiderato, oppure avvolgerlo con del nastro iso-
L’autore è a disposizione nei commenti per eventuali
lante. approfondimenti sul tema dell’Articolo. Di seguito il link per
accedere direttamente all’articolo sul Blog e partecipare alla
STEP 5 – METTIAMO TUTTO ASSIEME discussione:
https://it.emcelettronica.com/controllo-gestuale-e-ausilio-per-non-
Questa è sicuramente la parte più critica dell’intero pro-
vedenti-con-la-scheda-arduino-progetti-completi-open-source
getto. Occorre anzitutto procurarsi una piccola scatola

77
 Il mercato Italiano
PCB
dei PCB
di Maurizio Di Paolo Emilio

La crescente complessità e la miniaturizzazione dei dispositivi elettronici sono il catalizzatore per l’e-
voluzione continua della progettazione e produzione di PCB. Ma come le aziende possono far fronte a
questa evoluzione? I produttori hanno necessità di campionare immediatamente fornendo un deciso
time-to-market per la realizzazione del prodotto e arrivare prima di tutti quanti sul mercato. In questo
contesto è indispensabile disporre di aziende dinamiche che offrono non solo innovazione tecnologica
ma anche un processo lavorativo flessibile e veloce.

G
INTRODUZIONE
li analisti di mercato hanno stimato una crescita
del mercato PCB con un CAGR di circa il 3% entro
il 2020. Dal momento che questo mercato è una
parte integrante della produzione di smartphone e altri
dispositivi intelligenti, il recente aumento della domanda
porterà ad una decisa crescita. Inoltre, l’avvento delle
tecnologie avanzate, come IoT, IIoT e Wearable, con-
tribuiranno a favorire la domanda di PCB durante i pros-
simi anni (figura 1).
L’industria PCB europea serve principalmente i mercati
europei, ma esporta anche prodotti di fascia alta in Asia e
Nord America. I mercati principali serviti sono quelli indu-
striali, strumentazione e controllo, medicale, militare, aero-
spaziale e automotive. Le prospettive per l’industria PCB
europea dipendono dalla salute degli OEM che compon-
gono i mercati chiave, e tutto ciò che è valore aggiunto in
grado di compensare la concorrenza off-shore. Di seguito
riportiamo un elenco di principali aziende che operano nel
settore PCB.

Figura 1: il mercato PCB in funzione delle applicazioni (a) e del settore geografico (b)

78
 PCB

KEY ELECTRONIC SYSTEM di Frediano Carlevato Via

Pascoli, 16 - 10072 Mappano di Caselle (TO)
http://www.keymicro.net

Aiutiamo le aziende e le persone a creare prodotti elettronici in modo più semplice per insediare prima il mercato ed
aumentare i loro profitti. Servizi offerti: sviluppo prodotto, montaggio schede, gestione prodotto. Valore aggiunto: pro-
dotti funzionanti, prodotti funzionanti nel tempo, consegne immediate, massima collaborazione. “Se hai intenzione di
lanciare il tuo prodotto innovativo nel mercato, possiamo lavorare insieme per farlo al meglio”.

PCB Project Srl Via dei Gheghi n° 65 Segromigno in

Monte - 55018 Lucca - http://www.pcbproject.it/

La produzione è principalmente indirizzata ai prototipi intesi più nel senso di piccolissime produzioni, anche ricorrenti
che "materiale da test". PCB Project srl produce circuiti stampati Singola Faccia, Doppia Faccia, Multistrato princi-
palmente in FR4 e circuiti stampati Metal Core (IMS) su base alluminio; con tecnologia tradizionale a foro passante,
SMD o mista. Alcune delle principali lavorazioni sono: Foratura CNC, Solder mask fotografico, Finitura H.A.L. o
Argento Chimico, Test elettrico.

Safe-PCB Via Bartolomeo Bosco 57/2 16121 GENOVA

http://www.safe-pcb.com/

Safe-PCB è un produttore internazionale di circuiti stampati specializzato in prototipi e medie serie per consegna ra-
pida. I punti di forza sono: fabbrica ultra-moderna nel cuore di Shenzhen, la più grande area al mondo di produzione
di PCB; sito intuitivo per configurare, preventivare, ordinare e controllare la produzione e la spedizione dei tuoi PCB;
prezzi chiari che includono attrezzatura, test elettrico, oneri doganali e spedizione per corriere; supporto tecnico e
commerciale in Italia per rispondere a tutte le vostre domande. Safe-PCB produce come standard PCB rigidi con le
seguenti caratteristiche: FR4, IMS, CEM3, Poliimmide (PI) (SUBSTRATO FR4 MARCHIO VENTEC); da 2 a 12 facce
e risoluzione 0,1 mm; spessore totale da 0,2 a 3,2 millimetri; finitura HAL, NiAu, Argento, OSP, Carbonio; spessore
rame da 17 a 140 micron; solder resist verde, bianco, nero, blu, rosso.

CUSTOM SOLUTION S.R.L. Via Artigianato 3 43022

Montechiarugolo (PARMA) - http://www.customsolution.it

CUSTOM SOLUTION S.R.L. ha come attività principale l'assemblaggio delle schede elettroniche per conto terzi e
la progettazione hardware e firmware di schede dedicate alle esigenze del cliente. La storia professionale dei soci,
è tale da assicurare alla CUSTOM SOLUTION una elevata esperienza in molti ambiti progettuali, con particolare
propensione alla progettazione dei prodotti con comunicazione a radiofrequenza. CUSTOM SOLUTION si propone
come partner a qualsiasi livello del progetto: assemblaggio schede elettroniche per conto terzi in conto pieno o conto
lavoro per produzione da pochi pezzi e decina di migliaia di pezzi, collaudati ed inscatolati; progettazione completa
di hardware e firmware.

79
 PCB

BIANCHI MASTER S.a.s. Via C.Belgioioso 70/28 20157

MILANO - http://www.bianchimaster.it

Bianchi Master offre un servizio a “360 gradi” partendo dalla masterizzazione del circuito fino ad arrivare alla sua
costruzione. Avvalendoci della nostra trentennale esperienza nel campo siamo in grado di eseguire masterizzazioni
di qualsiasi tipologia (dai “monofaccia” ai “multistrati” ,alimentatori , schede ad impedenza controllata , ecc.). Grazie a
selezionati partner siamo in grado di fornire PCB di varie tipologie , dal monofaccia ai multilayer , circuiti in alluminio,
finiture in oro chimico e coperture per pannelli in vetroresina. Al cliente finale proponiamo anche l’assemblaggio delle
schede , con kit componenti di nostra fornitura oppure con fornitura parziale o totale da parte del cliente stesso. L’as-
semblaggio viene eseguito da noi direttamente per quanto riguarda le campionature e le piccole produzioni, mentre
per le grosse produzioni ci affidiamo a nostri partner consolidati da anni e di grande esperienza nel settore. Assicuria-
mo al cliente tempi brevi in base al lavoro da eseguire , la nostra priorità e di soddisfare le richieste del cliente parten-
do dalla precisione del lavoro, passando per tutti i controlli sulla masterizzazione , assicurando materiali certificati e
verificati con test di controllo automatizzati in fase di realizzazione del PCB e consegnando il tutto nei tempi richiesti.

Esseti Circuiti Stampati Srl Via del Lavoro, 90, 40050 Zona
Artigianale Argelato BO - http://www.circuiti-stampati.com

Nel 1979 a Bologna, grazie alla passione per l’elettronica e l’innovazione, due amici posarono le basi di quella che
sarebbe diventata una grande azienda: Esseti Srl, che da oltre 35 anni produce e trasforma circuiti stampati ed è in
grado di assicurare qualità, disponibilità, competitività, flessibilità produttiva e supporto tecnico. Esseti Srl produce
ed importa circuiti stampati (PCB) per applicazioni nei settori dell’elettronica di consumo, industriale e di potenza,
broadcasting, lighting, elettromedicale e automotive.

DROMO ELETTRONICA SRL VIA ANDREA CANGITANO 15A 00043

CIAMPINO (ROMA) - www.dromoelettronica.com

Azienda Flessibile e Dinamica, formata da periti elettronici con esperienza pluriennale nei seguenti settori: Montag-
gio SMD e PTH di schede elettroniche tramite macchine industriali pick&place e saldatrici ( sia ad onda che selettive
); assemblaggio, cablaggio di apparecchiature elettroniche generiche; taratura e collaudo di apparecchiature elet-
troniche e schede stand alone; specializzazione nell'assemblaggio della micro elettronica.

P.A.C. DI BEZZETTO SANDRO & C. S.N.C. Via del lavoro, 271 37050
- Angiari - Verona Italia - http://www.pacpcb.it

Dal 1973 P.A.C. è tra i leader nel mercato dei circuiti stampati (C.S.) o PCB (Printed Circuit Board). E' più di trent’anni
che si interessa alle varie richieste dei settori di elettronica, automazione, potenza, robotica, telecomunicazioni, illu-
minotecnica, ecc. per potersi arricchire di quell'esperienza che ha permesso di assistere e far parte dell’evoluzione
di questo mercato, sviluppando direttamente nuovi processi e sistemi produttivi finalizzati a realizzare piccole, medie
e grandi serie di circuiti stampati di altissima qualità.

80
 PCB

Cistelaier S.p.A. Via Gandhi, 1 41122 Modena

http://www.cistelaier.it/

Cistelaier si propone di affiancare il Cliente già a inizio progetto contribuendo, quando richiesto, al miglioramento del
progetto stesso attraverso analisi del tipo "Design forManufacturing” (DFM), per ottimizzare affidabilità in uso e per
minimizzare i costi del dispositivo. Il servizio di prototipazione veloce (QTA) completa l’offerta di supporto al Cliente
in fase di progettazione. Cistelaier S.p.A. è in grado di offrire una vasta gamma di circuiti stampati, caratterizzati
dall’elevata tecnologia. L’attenzione prestata nei processi di produzione, dalla scelta delle materie prime utilizzate
alla consegna del prodotto finito, garantita dalle diverse certificazioni in nostro possesso, permette a Cistelaier S.p.A.
di garantire ai propri Clienti un’apprezzata rapidità nelle forniture abbinata a un’elevata qualità del prodotto.

Lorj s.r.l. Via Fr. Camazzole, 21 Carmignano di

Brenta 35010 - (PD) - http://www.lorj.it

L'azienda Lorj s.r.l. opera nel settore della produzione di circuiti stampati (PCB) da più di 40 anni ed è specializzata
nella produzione, civile e professionale, di mono e multistrati, flessibili e su base di alluminio, con consegne brevi e
veloci sia per piccole che per medie produzioni. Le continue ricerche e aggiornamenti della parte tecnica per man-
tenere sempre i più alti standard qualitativi, hanno contribuito ad ottenere altre certificazioni come l' ISO 9001, ISO
14001 - 2004. Oggi in ottemperanza alla normativa RoHS tutto il processo produttivo è stato rivisto e modificato
adeguandolo anche all'utilizzo delle leghe Lead Free.

Millennium Dataware Srl Sede legale / Sede operativa

Strada Prov. Castelnuovo Scrivia, snc 15057 Tortona (AL)
http://www.mdsrl.it/

MD collabora con le più grandi aziende fornitrici di processi chimici e di semilavorati per il settore dei circuiti stampati
(Atotech, Panasonic, Sun Chemicals, Union Tool, ...). Per garantire la qualità promessa, MD collauda ogni circuito
con una macchina per il test elettrico a sonde mobili di nuova generazione, e allega il referto al prodotto finito. Que-
ste, oltre a fornirle i loro prodotti di gamma superiore, controllano la qualità dei circuiti ottenuti intervenendo, quando
necessario, per apportare migliorie al processo produttivo. Il prodotto di punta è ovviamente il multistrato, ma una
delle ragioni del successo è la gamma estesa, che comprende circuiti stampati IMS (Insulated Metal Substrate),
mono e doppio strato tradizionali, lamine SMD in acciaio, circuiti per alte frequenze e, ultimo ma non meno importan-
te, l'Assemblaggio dei componenti!

Baselectron s.r.l. - Circuiti Stampati Sede operativa: Via M.

Angelini, 18 27028 San Martino Siccomario (PV)
http://www.baselectron.com

I punti di forza di Baselectron sono sempre stati la velocità di produzione, la flessibilità nell'andare incontro alle più
svariate richieste e la costante attenzione all'innovazione in un settore che non smette mai di proporre soluzioni
all'avanguardia. I PCB prodotti da Baselectron sono per questi motivi diretti a soddisfare le più svariate esigenze,
trattandosi di circuti stampati a singola faccia o a doppia faccia, multistrato (fino a ventiquattro strati) o speciali, flessi-
bili e rigid-flex, eccetera. La costante attenzione alle più moderne tecnologie permette a Baselectron di offrire anche
la campionatura in tempi ridottissimi (anche in sole 24/48 ore per le richieste più urgenti), spesso improponibili per le
altre imprese del settore; il tutto, offrendo sempre un prodotto dall'elevato standard qualitativo.

81