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
ESPertino è una scheda basata su ESP32, progettata e prodotta in Italia da Elettronica Open Source. Permette di realizzare facilmente qualsiasi tipologia di applicazione e di sistema. Per agevolare ancora di più i progettisti è a disposizione il Kit ESPertino, 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
Il modulo HY-srf05 è un dispositivo per la rilevazione di distanze da oggetti, dotato di cinque pin, che utilizza gli ultrasuoni. E' anche molto economico, tuttavia si tratta di una evoluzione rispetto al precedente modello 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ù importanti:
| 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 |
| Passo dei pin | standard. Può essere innestato direttamente in una breadboard |
| Temperatura di funzionamento | -20°C ~ 60°C |
| Dimensioni | 45mm. x 21mm. |
La figura 1 mostra il modello del sensore, assieme alla disposizione dei suoi terminali.
Figura 1: il sensore di distanza HY-srf05 con il relativo pinout
Come si effettuare la misura della distanza
Il sensore srf05 è costituito da un emettitore di ultrasuoni (il trasmettitore) e da un ricevitore, sempre di ultrasuoni. Essi sono orientati verso la stessa direzione. Per eseguire la misura della distanza di un oggetto dal dispositivo, viene inviato un segnale sonoro dal Tx e ricevuto (di rimbalzo) dall'Rx, come schematizzato nella figura 2. Calcolando opportunamente il tempo intercorso tra i due eventi si può stabilire con precisione la strada percorsa. E' utile rammentare che il segnale sonoro percorre una doppia distanza, in quanto dal trasmettitore arriva all'oggetto interessato e da esso ritorna, di rimbalzo) al ricevitore. Si ricordi anche che la velocità di propagazione del suono ammonta a circa 341 metri al secondo, nell'aria. E' utile dare uno sguardo alla tabella sottostante, per apprezzare i diversi suoi comportamenti a seconda del mezzo di trasporto adottato.
| Sostanza | Velocità di propagazione (metri/secondo) [m/s] |
| Gomma | 50 |
| Aria (15ºC) | 341 |
| Sughero | 500 |
| Idrogeno | 1260 |
| Acqua | 1460 |
| Mattoni | 3650 |
| Marmo | 3800 |
| Ferro | 5000 |
| Vetro | 5200 |
Figura 2: come avviene la misurazione della distanza con gli ultrasuoni
ATTENZIONE: quello che hai appena letto è solo un estratto, l'Articolo Tecnico completo è composto da ben 2244 parole ed è riservato agli ABBONATI. Con l'Abbonamento avrai anche accesso a tutti gli altri Articoli Tecnici che potrai leggere in formato PDF per un anno. ABBONATI ORA, è semplice e sicuro.
Ti potrebbe interessare anche:
Realizziamo un transceiver SSB con GNU Radio
Progetto di una rete mesh di sensori con ESP32, ESP8266 e Arduino
Vibration energy harvesting systems
L’Intelligenza Artificiale e i Robot
All’interno delle reti neurali con l’eXplainable Artificial Intelligence
La semplicità di questa tipologia di sensori è davvero grande, anche se “dietro” esiste una grande tecnologia, sebbene essa non venga direttamente “vista” dal progettista.
L’ultrasuoni trova impiego in molte situazioni robotiche per verificare gli ostacoli. Questo esempio ha molte implementazioni in svariati campi molto più complessi.
Mi sa che questa frase è invertita: “…Inoltre la formula deve restituire lo spazio espresso in metri e non in centimetri, ….”
Perché se invece di dividere per 5800 divido per 58 ottengo un valore più grande quindi invece di 1 (1 metro) ottengo 100 (100 centimetri). La formula restituisce i centimetri non i metri.
Grazie per la segnalazione. Il dato di partenza è la velocità espressa in m/s, quindi la formula con 5800 rappresenta i metri.
Ciao Giovanni, ottimo articolo come sempre. Ho solo un dubbio su questa frase:
Spesso è consigliabile trasformare le moltiplicazioni in divisioni, adottando il calcolo del numero reciproco
Le divisioni appesantiscono moltissimo la FPU del processore, e dovrebbero essere evitate il piu’ possibile. Uno dei trucchi che usiamo che calcolo numerico per i percorsi NC, dove servono routine super tirate e performanti, e’ proprio il contrario: trasformare tutte le divisioni in moltiplicazioni, proprio la FPU richiede meno cicli di clock per questo.
Quindi, ad esempio, se devo fare 50 / 10, e’ meglio fare 50 * 0.1, definendo magari 0.1 come costante in modo che il preparser la inizializzi una sola volta.
Discorso leggermente diverso vale invece con la divisione per 2, dove e’ sempre preferibile usare lo shift logico a destra di 1 bit, che divide appunto per 2. Ma qui si parla gia’ di interi e non di float/double.
Ciao Riccardo grazie del commento.
La tua bellissima osservazione aprirebbe un mondo enorme di discorsi………
I calcoli matematici sono sempre problematici per una povera MCU.
Da un lato le moltiplicazioni restituirebbero cifre che, facilmente, potrebbero andare in overflow…
Dall’altro canto le divisioni costringono la CPU a carichi piu’ pesanti ma gestibili….
Insomma è un vero problema.
Ogni caso dovrebbe essere esaminato a parte e sarebbe utile misurare le performance delle varie metodologie adottate secondo i seguenti criteri:
– lunghezza del codice (ovviamente binario)
– velocita’ di esecuzione
– occupazione codice in RAM
– affidabilita’.
Ciao e grazie
Ciao Giovanni,
capisco quello che dici, ma mi risulta completamente nuovo, e mi piacerebbe capire dove tu abbia trovato indicato come consigliata questa cosa.
L’usare, anzi addirittura il preferire divisioni alle moltiplicazioni e’ assolutamente da evitare, se vuoi avere codice performante e veloce. Questo l’ho imparato sia in Milestone, quando c’era da fare calcoli veloci che fossero peraltro multipiattaforma, cioe’ PS3, XBOX360, Wii, PC. E anche ora, lavorando con Matematici specializzati in Calcolo tutti, ma proprio tutti, da Russi, Francesi, Inglesi usano l’accortezza di non usare MAI divisioni, ove sia possibile.
Io sto guardando la cosa dal punto di vista delle performance (velocità’ di esecuzione fra i tuoi punti), non vedo come sostituire una DIV con una MUL possa allungare il codice binario e quindi occupare piu’ RAM. Per quanto riguarda invece proprio la stabilita’, l’algoritmo di moltiplicazione e’ solitamente molto piu’ stabile di quello di divisione.
Detto questo chiaramente su uno sketch per ino-like, che e’ orientato agli hobbisti che quindi non hanno problemi di performance, sicuramente usare la divisione non da’ problemi, anche se continuo a non vederne la necessita’.
Ciao, grazie
Recentemente ho visto i risultari di un test di performance eseguito su un Raspverry Pi 3: la moltiplicazione era almeno 3 volte piú veloce della divisione. Poi ci sono le architetture dei DSP, nate per macinare enormi volumi di dati, che integrano funzioni MAC (multiply and accumulate) a livello hw. Filtri, FFT e altri algoritmi le uaano pesantemente con benefici enormi sulle performance. Sicueanente la moltiplicazione per unnumero frazionario può aiutare
PS: come ti sei trovato in Milestone?
Grazie Stefano, mi riferivo esattamente a situazioni del genere, ma tu ti sei spiegato molto piu’ esaurientemente.
In Milestone mi sono trovato bene, l’ambiente e’ molto stimolante, pieno di gente giovane con alti profili di C/C++ (soprattutto quelli che fanno la parte di engine cross-platform, che grappa le funzionalità’ base sulle varie piattaforme, astraendo la macchina dallo sviluppatore finale).
Purtroppo io ero piu’ orientato a giochi di azione o altro, perche’ delle moto e delle auto non mi interessa molto. Ma l’ambiente e’ cosi’ appassionante, che alla fine ti appassioni pure tu.
Io ho lavoro su MotoGP 2008, implementando uno scheduler di caricamento risorse multithread. In questo modo si potevano caricare N risorse insieme (piste, moto, etc) contemporaneamente (dove con contemporaneamente intendo con thread paralleli, ovviamente).
Sono dovuto venir via per problemi personali, cmq il ritmo di lavoro e’ molto intenso e bisogna riuscire a starci dietro.
Sto correttore automatico mi fa venir matto: mi ha scritto grappa al posto di wrappa. Che se vuoi, fa anche ridere 🙂
Beh, visto l’imminente periodo di festivitá, la grappa capita a fagiolo..
🙂