Lo scopo dell’articolo è illustrare, con il maggior livello di dettaglio possibile, la realizzazione di un rilevatore SONAR con Arduino. Allo scopo verrà dapprima definita l’idea alla base del progetto, illustrando le possibili soluzioni al problema, e le criticità realizzative. Successivamente saranno chiarite le differenze che intercorrono tra un sistema RADAR ed uno SONAR, il perché si è preferito optare per il secondo e quali sono le limitazioni nell'utilizzo della tecnologia. Verranno, poi, presentati i componenti, discussi i principi di funzionamento, e le accortezze da seguire quando si utilizza un sensore ad ultrasuoni come rilevatore di distanza. Ampio sguardo sarà dato anche al comparto elettronico, capendo il perché sia necessario alimentare singolarmente i dispositivi evitando di collegarli al microcontrollore, e quali sono le modifiche da apportare alla Motor Shield di Infineon. Infine, verrà presentato il software di controllo realizzato in ambiente Matlab-Simulink, e la soluzione alternativa ottenuta combinando lo sketch di Arduino con script Python.

L’idea alla base del progetto

L’idea alla base del progetto è tanto semplice quanto ingegnosa: utilizzare un sensore ad ultrasuoni, nello specifico un HC-SR04, per rilevare la distanza da un oggetto, con l’ausilio di Arduino, e scansionare l’area circostante utilizzando un motore in continua, attraverso la Motor Shield di Infineon. L’elaborazione avviene in ambiente Matlab Simulink, lo stesso utilizzato per programmare il microcontrollore, dove vengono raccolte le misure temporali, convertite poi in distanza, e visualizzato un grafico che mostra la sagoma di eventuali oggetti presenti. Ovviamente, l’ambiente Matlab Simulink non è l’unico spendibile sia per la programmazione, sia per l’acquisizione e l’elaborazione delle informazioni. Soluzione alternativa è realizzare uno script in Python, che acquisisce le misure di distanza (la conversione tempo-distanza viene gestita in Arduino, anche se formalmente l’operazione non è corretta) e visualizza il grafico aggiornandolo di volta in volta con le nuove misure. Si tratta di una valida alternativa, ma che necessita, al contempo, di spendere maggior tempo nella stesura del codice.

Parliamo di operazione non corretta perché è buona norma deputare al microcontrollore il minor numero di operazioni possibili, in modo che l’hardware sia quanto più possibile dedicato alla gestione delle attività essenziali. Eventuali elaborazioni, all’interno dello sketch (nome dato al software realizzato per Arduino), potrebbero far “perdere” tempo al microcontrollore in attività svolgibili tranquillamente in fase di elaborazione dati da un processore general purpose, dalle frequenze di clock più elevate, dunque riducendo la possibilità di misure falsate o perdita di informazione.

All'interno di questo articolo verranno presentate entrambe le soluzioni, allo scopo di fornire un’informazione quanto più completa possibile, lasciando poi al lettore la facoltà di decidere quale soluzione adottare nel caso voglia realizzare il progetto, valutando con mano le differenze tra le due alternative descritte.

In sintesi, l’utilizzo di Matlab potrebbe essere la soluzione migliore per chi mastica poco i linguaggi di programmazione, mentre scrivere uno sketch per Arduino potrebbe essere la soluzione più adeguata per coordinare motore, sensore, acquisizione ed elaborazione.

Criticità alla base del progetto sono:

• Gestione del tempo minimo in cui il sensore deve sostare in una specifica posizione, affinché la misura avvenga correttamente e non venga falsata dal ritorno di altri segnali (sarà più chiaro quando si analizzerà il funzionamento del sensore ad ultrasuoni, in particolare l'HC-SR04);
• Calibrazione della velocità del motore in continua per la rotazione del sensore, capace di scansionare l’area con una angolo che spazia tra gli 0° ed i 180°, ed inversione della rotazione;
• Dimensionamento dell’alimentazione necessaria a garantire il funzionamento dell’intero sistema, e sua interconnessione con l’apparato sensoristico e di movimentazione.

RADAR o SONAR: le differenze

Prima di addentrarci e capire nel dettaglio quali sono stati i passi che hanno portato alla realizzazione del rilevatore SONAR con Arduino, è bene definire quali sono le differenze tra un sistema SONAR ed uno RADAR. Indagare sulle differenze è fondamentale per comprendere il perché della scelta fatta, le limitazioni che essa comporta ed i possibili problemi realizzativi.

Il termine RADAR è l’acronimo di Radio Detection And Ranging, e denota i sistemi capaci di rilevare e localizzare oggetti a mezzo di onde elettromagnetiche. Schematicamente in un sistema radar un trasmettitore invia nello spazio energia elettromagnetica sotto forma di impulsi a microonde, di frequenza tra le onde radio e la radiazione infrarossa; tale energia viene riflessa da eventuali bersagli, catturata da un’antenna ed elaborata dal ricevitore al fine di determinare la presenza o meno del bersaglio (Detection=rivelazione) e di misurare la distanza dal ricevitore (Ranging=localizzazione in distanza). Di norma trasmettitore e ricevitore sono collocati e condividono lo stesso sistema d’antenna (come nel progetto in esame), si parla di radar monostatico. Al contrario, in applicazioni belliche si separa il trasmittente dal ricevente, per evitare l’individuazione dell’antenna, realizzando il cosiddetto radar bistatico. Giusto per completezza, in questi ambienti la rivelazione è un problema di classificazione binaria, mentre la localizzazione è un problema di stima.

Il SONAR, l’acronimo di SOund Navigation And Ranging, essenzialmente si comporta come un sistema radar, ovvero è in grado di determinare la presenza o meno di un bersaglio e di misurarne la distanza. Al contrario del sistema radar, il sonar utilizza onde acustiche e non elettromagnetiche, che meglio si propagano in materiali rigidi come i liquidi, e di meno nell'aria, con un comportamento del tutto duale rispetto alle onde elettromagnetiche. Tali caratteristiche fanno del sonar lo strumento più indicato in ambienti marini, o dove in generale bisogna attraversare dei liquidi, mentre il radar è utile quando è necessario misurare distanze nell'etere. In generale, possiamo affermare che più è rigido il mezzo meglio le onde sonore si propagano, raggiungendo distanze più elevate, al contrario di ciò che accade con quelle elettromagnetiche.

Le onde, siano esse sonore o elettromagnetiche, possono essere inviate come la modulazione di un’onda continua oppure ad impulsi, la seconda soluzione è la più efficiente da un punto di vista energetico quando si intende raggiungere grandi distanze.

Capite le differenze, per sommi capi, verrebbe da pensare: perché è stato realizzato un sistema SONAR di rivelazione nell'etere con Arduino piuttosto che uno RADAR? Il motivo è semplicissimo: i costi. Il sensore utilizzato allo scopo (lo analizzeremo a breve) ha un costo decisamente ridotto rispetto ad un’equivalente che lavora alle microonde. Dunque, questa è la ragione che ne hanno decretato la scelta, ritenendolo il più giusto da utilizzare per la realizzazione del progetto.

Ricordiamo, infatti, che l’intento non è realizzare un sistema vendibile ma progettare e, soprattutto, costruire un dispositivo embedded capace di chiarire i passi che separano la teoria dalla pratica, capendo quali possono essere i problemi in corsa d’opera. Arduino – secondo l’opinione di chi scrive – è un ottimo strumento didattico ed utile per le aziende, per tutto quello che è il discorso prototipizzazione rapida.

I componenti

Definita l’idea alla base del progetto, le limitazioni e le motivazioni che hanno portato alla scelta di un sensore ad ultrasuoni, piuttosto che uno a microonde, per la rivelazione di un oggetto nell'etere, si può tranquillamente passare a quelli che saranno i componenti che verranno utilizzati, da qui a poco, per la realizzazione del sistema. Capire l’hardware a disposizione è un passaggio chiave per farsi un’idea degli eventuali problemi che possono sorgere in corsa d’opera e, soprattutto, come evitarli.

Poche ma essenziali sono le unità utilizzate:

1. Arduino Uno: sistema di controllo con il quale viene acquisita la distanza rilevata dal sensore ad ultrasuoni, ed inviato il comando per la movimentazione del motore in continua;
2. Motor Shield di Infineon: necessaria per comandare il motore in continua, regolandone velocità e direzione. Il tutto è possibile grazie alla presenza di un H-Bridge (ricevuta grazie al contest);
3. Un motore in continua da 9 V: deputato alla rotazione della base su cui è installato il sensore;
4. Un sensore ad ultrasuoni, l’HC-SR04: attraverso il quale vengono acquisite le misure di distanza.

Arduino (Figura 1.3.1) è una scheda elettronica di piccole dimensioni con un microcontrollore ed una circuiteria di contorno, utilizzata per la realizzazione di prototipi, per scopi hobbistici e didattici.

Figura 1.3.1: Sistema di controllo, Arduino UNO.

La forza di Arduino risiede nell'essere Open Source: sia l’ambiente di sviluppo che il software di corredo, come anche lo stesso schema hardware, sono liberi ed aperti a tutti. Volendo fare un’analogia, si tratta della stessa filosofia utilizzata dalle distribuzioni Linux. Per di più, la presenza di interfaccia di comunicazione USB (necessaria per lo scambio dati con il PC, utilizzabile anche come alimentazione), di un regolatore di tensione (maggiore flessibilità nella scelta del sistema di alimentazione) e pin per l’interfacciamento I/O (possibilità di collegare dispositivi analogici e/o digitali, sia in input che in output), lo rendono molto versatile.

All'hardware viene affiancato un ambiente di sviluppo integrato (IDE) multipiattaforma (Macintosh, Linux e Windows), che richiama la stessa struttura del C e C++ (noti linguaggi di programmazione) e consente, anche a chi di elettronica ne sa ben poco, di cimentarsi nella realizzazione di progetti scrivendo da se gli sketch. Altro punto a favore di Arduino, è la possibilità di interagire con i sistemi operativi e con i software ivi installati, ad esempio Adobe Flash.

Tutte queste caratteristiche hanno consentito lo sviluppo, da parte di aziende e di privati, di librerie che facilitano sempre di più i neofiti nella realizzazione di sistemi abbastanza evoluti, riducendo i tempi ed i costi di progetto. Inoltre, la possibilità di collegarlo addirittura ad un LCD (Liquid Cristal Display, Schermo a Cristalli Liquidi) lo rende un dispositivo completamente autonomo. Avviato il software, il sistema lavora in maniera del tutto indipendente acquisendo i dati che si trovano sul campo, elaborandoli ed intraprendendo azioni sulla base del sistema di controllo implementato. Si rimanda il lettore ad ulteriori approfondimenti al riguardo.

Figura 1.3.2: Motor Shield di Infineon.

La Motor Shield (Figura 1.3.2) è unità fondamentale per il controllo di un motore DC (DirectCurrent, Corrente in Continua), senza la quale non sarebbe possibile regolarne né la velocità, né la direzione. Inoltre, consente di alimentare il motore con una sorgente di tensione differente da quella che alimenta l’unità di controllo, evitando così possibili danneggiamenti del microcontrollore, incapace di fornire una corrente sufficiente a pilotarlo.

Componente fondamentale, deputato al pilotaggio del motore, è il Ponte-H (H-Bridge), saldato sulla scheda, circuito responsabile della modulazione della corrente media che scorre ai capi del motore. Senza entrare in inutili tecnicismi, ripetendo qualcosa di già noto a molti, la shield utilizza il segnale proveniente dal pin PWM (Pulse Width Modulation, Modulazione ad Ampiezza di Impulsi) di Arduino per modulare l’apertura e la chiusura dei MOSFET di potenza all'interno del ponte, modificano la corrente media e dunque la sua velocità.

Volutamente non si è voluti entrare nel dettaglio di funzionamento del ponte, né sulla tecnica di modulazione per il comando dei MOSFET (PWM o PLL, acronimo di Phased Locked Loop ovvero Anello ad Aggancio di Fase), si rimanda il lettore più curioso a successivi approfondimenti al riguardo.

Figura 1.3.3: Sensore ad ultrasuoni HC-SR04.

Il sensore ad ultrasuoni (HC-SR04, Figura 1.3.3) è l’aspetto che merita un maggiore livello di dettaglio, essendo il cuore dell’intero sistema. Come già detto in precedenza, utilizza le onde sonore per la rilevazione della distanza da un oggetto. A tale proposito, è fondamentale sapere che le onde sonore quando incontrano l’interfaccia di separazione tra due mezzi materiali danno luogo a fenomeni quali rifrazione e riflessione.

Si parla di rifrazione (Figura 1.3.4) quando l’onda incontra la superficie di separazione tra due mezzi aventi impedenza acustica differente, parte dell’onda viene riflessa, l’altra parte continua la propagazione all'interno del mezzo con un angolo di propagazione differente da quello di incidenza. Il fenomeno causa una perdita di energia, dunque riduce la distanza di propagazione dell’onda acustica. Si tratta di un fenomeno da evitare, perché non consente la misura della distanza da un oggetto.

Figura 1.3.4: Schema riassuntivo del fenomeno della rifrazione.

La riflessione, al contrario, è un fenomeno che ben si presta alle operazioni di misura. A tale proposito, quando si parla di riflessione è importante distinguere tra due fenomeni riflessivi (Figura 1.3.5):

1. Riflessione speculare: l’onda sonora impatta con l’interfaccia di separazione di due mezzi materiali e si riflette, dirigendosi nuovamente verso la sorgente. Le onde riflesse si propagano in un’unica direzione;
2. Scattering o diffusione: fenomeno funzione del rapporto delle lunghezze d’onda sonore e della dimensione media delle particelle. Le onde riflesse si propagano in tutte le direzioni. Se l’energia delle onde riflesse non è sufficientemente elevata non è possibile individuare un picco d’energia, e quindi non sarà possibile effettuare la misura di distanza.

Figura 1.3.5: Differenza tra riflessione speculare e scattering.

Un sensore ad ultrasuoni come l’HC-SR04 misura il tempo impiegato (ms) dalla onde sonore (Figura 1.3.6), emesse da una sorgente, a tornare indietro, a seguito dello scontro con un ostacolo in grado di rifletterle. La limitazione nell'utilizzo del sensore risiede nell'impossibilità d’impiego con oggetti in grado di assorbire le onde acustiche. Nonostante ciò, riesce ad offrire una buona accuratezza ed una stabile lettura della distanza nell'intervallo dai 2 ai 400 cm, tenuto in considerazione anche il costo (tra i 2/3 €).

Figura 1.3.6: Schema di funzionamento sensore ad ultrasuoni.

Il fascio di onde sonore (Figura 1.3.7), emesse dalla sorgente situata di fianco al ricevitore, ha forma conica, la stessa forma delle onde riflesse da un ostacolo. La forma del fascio fa sì che il sensore riceva molte riflessioni, dai diversi oggetti presenti all'interno dell’ambiente, ciò rende il sensore, da solo, incapace di distinguere un oggetto da un altro o aperture negli oggetti troppo piccole. Per sopperire a tale problema, il sensore è dotato di un’apposita circuiteria di controllo.

Figura 7: Fascio di onde emesse e ricevute dal sensore ad ultrasuoni.

Il principio di funzionamento (Figura 1.3.8) è abbastanza semplice:

1. Si porta al valore logico alto il pin di trigger del sensore per un tempo di almeno 10 μs;
2. Il modulo automaticamente invia un’onda acustica alla frequenza di 40 kHz e si pone in ascolto di un segnale ad onda quadra di ritorno;
3. Se il segnale torna alla sorgente, in uscita viene restituito il tempo che è intercorso tra l’invio e la ricezione del segnale, da qui si procede al calcolo della distanza utilizzando la formula:

Figura 8: Logica dei segnali dal/al HC-SR04.

Lo schema Circuitale

Dopo aver capito quali sono i componenti del progetto, come funzionano, e quali sono i vincoli fisici che ne condizionano l’operatività, non resta altro da fare che interconnetterli tra loro, alimentandoli secondo quanto specificato all’interno dei datasheet.

Al fine di mantenere livelli di tensione di alimentazione stabili, quanto più possibile, è stato utilizzato un regolatore di tensione (Figura 1.4.1), in particolare il L7805CV , capace di ricevere in ingresso una tensione continua fino a 35 V e di produrre in uscita una tensione continua di 5 V , la stessa utilizzata per alimentare il sensore ad ultrasuoni HC-SR04.

Il regolatore di tensione, presente in qualunque circuito elettronico, ha lo scopo di fornire le precise tensioni di alimentazione necessarie per il funzionamento dei circuiti elettronici analogici e digitali presenti all'interno di una rete, evitando così malfunzionamenti e danneggiamenti del sistema dovuti a bruschi sbalzi di tensione. Tali sono le ragioni per cui si è preferito non collegare il sensore ai pin di alimentazione forniti dal sistema di controllo (Arduino UNO), ma attraverso il regolatore di tensione direttamente al package di batterie garantendo che l’HC-SR04 funzioni sempre con un alimentazioni pari a 5 V.

Figura 1.4.1: Schema circuitale del rilevatore sonar.

Inoltre, particolare attenzione è stata posta nel collegare tutti i dispositivi allo stesso riferimento (ground, massa), con il fine di evitare misurazioni errate dovute a riferimenti diversi. Come mostrato in Figura 1.4.1, i riferimenti delle batterie, come quelli del regolatore di tensione, del sistema di controllo e della motor shield, sono tutti cortocircuitati tra loro.

Nello schema circuitale (Figura 1.4.1), realizzato utilizzando il software open source Fritzing, sono evidenziate le interconnessioni tra i dispositivi e l’alimentazione:

• I pin del sensore ad ultrasuoni, in particolare ECHO e TRIGGER, sono collegati rispettivamente a pin digitali 2 e 4 di Arduino;
• Il motore in continua è collegato alla morsettiera montata sulla motor shield.

Motor Shield di Infineon: le modifiche

Prima di passare all'implementazione del sistema di rivelazione in ambiente Matlab Simulink verranno illustrate le modifiche apportate alla motor shield di Infineon.

Figura 1.4.2: Motor Shield di Infineon a seguito delle modifiche.

Per prima cosa, è stato necessario dissaldare il condensatore elettrolitico per poi rimontarlo in maniera orizzontale, con il fine di ridurre quanto più possibile l’ingombro consentendo così il montaggio di altri moduli al sistema di controllo come ad esempio un display LCD.

Successivamente, sono state montate delle morsettiere sia sulle piazzole per il pilotaggio dei motori, sia su quelle per il collegamento della sorgente di alimentazione supplementare, il tutto allo scopo di renderne più agevole l’utilizzo piuttosto che montare le boccole a cui poi collegare le relative banane (Figura 1.4.3).

Figura 1.4.3: Connettori, in gergo banane.

Infine sono stati saldati i connettori fondamentali per il montaggio impilato con il sistema di controllo. Il circuito ottenuto è mostrato in Figura 1.4.2.

Rilevatore in ambiente Matlab-Simulink

Passiamo ora al vivo della trattazione, illustrando il software implementato in ambiente Matlab-Simulink per la realizzazione del rivelatore sonar con Arduino.

Matlab, per chi non lo conoscesse, è ambiente di lavoro molto utilizzato in ambito ingegneristico, e non solo, per il calcolo numerico e l’analisi statistica. Consente di manipolare matrici, visualizzare funzioni e dati, implementare algoritmi, e interfacciarsi con altri programmi. Questi sono soltanto alcuni degli innumerevoli vantaggi che il software mette a disposizione dei propri utenti, e che ne hanno decretato la diffusione.

Figura 1.5.1: Support Package Installer di Matlab.

Data la moltitudine di utilizzatori, ed appurate le potenzialità del sistema di controllo Arduino, gli sviluppatori hanno pensato di agevolare il lavoro dei progettisti fornendo un ambiente grafico che consentisse la programmazione del microcontrollore e l’utilizzo di tutti gli strumenti che Matlab mette a disposizione. A tale proposito è stato sviluppata un’apposita libreria, installabile direttamente dal promt dei comandi digitando “supportPackageInstaller” (Figura 1.5.1), per poi scegliere il device di interesse (funzione disponibile dalla 2012b e successive).

Figura 1.5.2: Software del rivelatore sonar realizzato in Matlab.

L’ausilio del supporto IDE di Arduino per Matlab, e di s-function ad hoc (appositi blocchetti, disponibili nella libreria di default di Simulink, per l’utilizzo di codice C in Matlab) per l’interfacciamento dei sensori e della motor shield all’ambiente di sviluppo, hanno consentito la realizzazione del software di controllo per il rivelatore sonar riportato in Figura 1.5.2. Si tratta di un software modulare, composto da un blocco

• SONAR: misura la distanza da un oggetto;
• MOTOR: gestisce il motore in continua (velocità e cambio direzione);
• XY GRAPH: realizza lo schermo del rivelatore mostrando, in maniera approssimativa (dovuta alla bassa risoluzione del sensore), la sagoma dell’oggetto di fronte al rivelatore.

Il blocco SONAR (Figura 1.5.3) integra la libreria NewPing di Arduino, utilizzata per la sua affidabilità ed ottima struttura, per la misurazione della distanza da un oggetto. Inoltre, il blocco saturazione evita che malfunzionamenti del sensore possano restituire valori numerici fisicamente non misurabili, perché al di fuori dell’intervallo di misurazione descritto dal datasheet.

Figura 1.5.3: Blocchetto SONAR in Matlab.

Osservando l’andamento delle misure di distanza, si è notata però la presenza di misure falsate (fluttuazioni su valori continui) dovute a fault del sensore: mancato ritorno dell’onda acustica, causato dall'irregolare superficie dell’oggetto, che porta a misure di distanza pari a quella massima misurabile (400 cm). Ragion per cui si optato per la diminuzione del ping intervall (distanza temporale tra l’impulso di TRIGGER ed il successivo), fino a raggiungere il minimo possibile, in modo da acquisire il maggior numero di misure date poi in ingresso ad un filtro FIR a media mobile. Il numero di coefficienti utilizzati per il filtro è pari a 10. Questo riceve in ingresso un array contenente le misure di distanza e sostituisce a ciascuna misura la media di quelle vicine, in modo da eliminare le fluttuazioni (spike) nelle misure.

Figura 1.5.4: Blocchetto MOTOR in Matlab.

Il blocco MOTOR (Figura 1.5.4), al contrario, è responsabile della movimentazione del motore in continua. La velocità, durante l’intero processo di rilevazione, assume un valore costante pari a 95, scelto sperimentalmente tra il set di valori ammissibili (0 − 255). Per quanto concerne, invece, la direzione essa varia secondo la logica riportata in Figura 1.5.5.

Figura 1.5.5: Logica cambio direzione del blocco MOTOR.

Il motore ruota in senso orario, spostando il sensore da sinistra verso destra, fino a che il segnale che condiziona la direzione (DIR) assume valore pari a 2, ovvero fino al fronte di discesa del segnale PULSE (segnale che si somma al valore all'unità nel software riportato in Figura 1.5.2). Trascorsi 1.35 secondi (metà periodo dell’onda quadra, anch'esso valore sperimentale) dal fronte di salita di PULSE, il segnale DIR assume nuovamente valore pari 1, conseguentemente il motore cambia verso di rotazione da orario ad antiorario (da destra verso sinistra) fino al prossimo fronte di salita.

Infine, il software si compone di un ultimo blocco che converte le misure realizzando lo schermo del rilevatore. La distanza viene scomposta luongo le componenti x e y, per poi essere inviata al blocco XY GRAPH che provvede a rappresentarle, utilizzando l’espressione

dove

• d: è la distanza dall'oggetto rilevata dal sensore ad ultrasuoni;
• t: è la generica variabile tempo;
• T_P : è il periodo del segnale PULSE.

Rilevatore in Python e Sketch Arduino

Seguendo quanto realizzato in ambiente Matlab-Simulink è stato implementato lo Sketch in Arduino (riportato di seguito) per il controllo del motore in continua, e l’acquisizione delle misure di distanza dall’oggetto. Come nelle s-function realizzate in Matlab, per il sensore ad ultrasuoni (HC-SR04) è stata utilizzata la libreria NewPing, mentre per il controllo di velocità e direzione del motore sono stati utilizzate le funzioni analogWrite e digitalWrite. L’autore non intende entrare nei dettagli, commentando riga per riga il codice prodotto, perché ritiene che il lettore abbia una conoscenza minima di tale linguaggio, in caso contrario rimanda il lettore ad ulteriori approfondimenti al riguardo.

#include <NewPing.h>
// Pin assignment for first half-bridge 
const int IN_1 = 3; // input (PWM) 
const int INH_1 = 12; // inhibit (low = sleep)

// Pin assignment for second half-bridge 
const int IN_2 = 11; // input (PWM) 
const int INH_2 = 13; // inhibit (low = sleep)

//Variabile to change the motor direction
int timer; 
float constant, interval;

#define TRIGGER_PIN 4 // Arduino pin tied to trigger pin on the ultrasonic sensor. 
#define ECHO_PIN 2 // Arduino pin tied to echo pin on the ultrasonic sensor. 
#define MAX_DISTANCE 400 // Maximum distance we want to ping for (in centimeters). Maximum sensor distance is rated at 400 cm.

NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE); // NewPing setup of pins and maximum distance.

void setup() {
 
 // Set correct input/output state 
 pinMode(IN_1, OUTPUT); 
 pinMode(INH_1, OUTPUT);
 pinMode(IN_2, OUTPUT); 
 pinMode(INH_2, OUTPUT);
 
 // Set initial output states 
 analogWrite(IN_1, 95); // set motor speed to 0 
 digitalWrite(INH_1, HIGH); // enable OUT1 
 analogWrite(IN_2, 95); // set motor speed to 0 
 digitalWrite(INH_2, LOW); // disable OUT2
 
 //Variabile to change direction 
 constant=2.7; interval=constant; 
 
 // initialize serial communication: 
 Serial.begin(115200); 
 while (!Serial) { 
 ; // wait for serial port to connect. Needed for Leonardo only 
 } 
}

void loop() {
 
 timer=millis(); 
 delay(50); // Wait 50ms between pings (about 20 pings/sec). 29ms should be the shortest delay between pings. 
 unsigned int uS = sonar.ping(); // Send ping, get ping time in microseconds (uS). 
 Serial.println(uS / US_ROUNDTRIP_CM); // Convert ping time to distance in cm and print result (0 = outside set distance range)

 /* half bridge mode, two unidirectional motors motor 1 connected to OUT1 and GND motor 2 connected to OUT2 and GND */
 
 //Change motor direction 
 if(timer>=interval){ 
 digitalWrite(INH_1, LOW); // disable OUT1 
 digitalWrite(INH_2, HIGH); // enable OUT2 
 interval=interval+constant; 
 } 
}

Di seguito è riportato lo script Python per l'acquisizione delle misure distanze su seriale e la realizzazione del grafico XY.

import math 
import os 
import matplotlib.pyplot as plt

serialFromArduino = serial.Serial("/dev/ttyACM4",115200) 
serialFromArduino.flush()

plt.figure(1) 
plt.xlabel('Graphic')

while True: 
 try: 
 val = ord(serialFromArduino.read()) 
 time=tm_sec(5) 
 x=val*sin((2*pi*time)/2.7) 
 y=val*cos((2*pi*time)/2.7) 
 plt.plot(x, y, 'r--', linewidth=2.0) 
 plt.show()

except KeyboardInterrupt: 
 exit()

serialFromArduino.close()

Conclusioni

La realizzazione di un rilevatore SONAR con Arduino, progetto di relativa semplicità, ha consentito di affrontare concetti chiave come la differenza tra un sistema RADAR ed uno SONAR, il dimensionamento dell’alimentazione, per poi passare ai problemi ed alle relative soluzioni legate all’utilizzo di un sensore ad ultrasuoni low cost come il HC-SR04. Si tratta di know how che fanno la differenza tra un progetto “funzionante” ed uno “fatto bene”, consentendo all’applicazione di operare anche in condizioni diverse da quelle dell’esperimento.

Inoltre, l’implementazione del software con due strumenti diversi (Matlab-Simulink e Sketch-Python) ha consentito di delineare vantaggi/svantaggi derivanti dai due ambienti di sviluppo, aprendo le porte anche a chi di programmazione sa ben poco con tutti gli annessi e connessi.

In tema di sviluppi futuri si potrebbe pensare all'integrazione del sistema all'interno di piccoli robot, realizzati utilizzando sempre Arduino, combinando così la parte di sensing con quella di controllo.

Ti potrebbe interessare anche:

E’ disponibile il datasheet di ESPertino in italiano

Una soluzione per sensori d’immagini 3D di prima qualità dalla Infineon

Intervista a Gianluca Martino, creatore del progetto Jolly Device

Articoli Correlati

Il Cane Elettronico (dall’idea al progetto… di massima!!)