Ciao ragazzi!
Benvenuti nella seconda puntata di questa
nuova serie di focus dedicati al robottino
#Ro-Pi. Se vi foste persi la prima puntata
la trovate linkata in descrizione e nelle
schede qui alto, e vi consiglio di darci un'occhiata
poiché è da lì che ripartiremo.
Facciamo comunque un velocissimo recap: nella
prima puntata vi ho spiegato a grandi linee
che cos'è #Ro-Pi e vi ho elencato le componenti
principali di cui è composto.
Già che ci sono apro una veloce parentesi corregendo
il nome del componente che permette di controllare
i motori: non si tratta di uno step-motor
(perdonate ma era davvero tardi quando ho
registrato il video) quanto più di un L298N
Dual H-Bridge... pardon.
Comunque, come abbiamo visto questo componente
permette di farci controllare via Raspberry Pi
i due motori e quindi le due ruote ad esso
collegate. Nella prima puntata, perciò, vi
ho mostrato come trasformare il piccolo robottino
praticamente in una automobile a guida controllata
dall'utente oppure in grado di disegnare figure
geometriche predeterminate
(ad esempio un rettangolo) in modo autonomo.
Una volta realizzata quella base, nei giorni
seguenti sono andato avanti con gli esperimenti
ed ho aggiunto al progetto due nuove componenti,
oltre che sistemato un piccolo inghippo che
non vi avevo segnalato. Partiamo proprio da
quest'ultimo.
In pratica il raspberry pi quando viene avviato
attiva automaticamente alcuni PIN del GPIO
(cioè li imposta ad accesi). Questo significa
ad esempio che il bridge riceverà il segnale
di attivare una o entrambe le ruote fin da
subito ed il robottino inizierà a muoversi
casualmente. Per evitare o comunque limitare
questo problema ho scritto un semplicissimo
programmino python da mandare in esecuzione
all'avvio del sistema operativo che non fa
altro che spegnere tutti i PIN. L'esecuzione
di questo codice va indicata nell'rc.local,
ma c'è un problemino: purtroppo l'rc.local
viene richiamato dal sistema operativo qualche
secondo dopo l'effettivo startup del Raspberry Pi.
In parole povere quel che succede è che
comunque, per qualche secondo, qualsiasi sensore,
motore o quant'altro collegato al GPIO riceverà
segnale di accensione. L'idea, quindi, è
di sfruttare questo lasso di tempo a mo' di
feedback che il sistema abbia effettivamente
completato il suo avvio e che tutto stia funzionando
correttamente. E fra poco vi dirò come.
Le due componenti che ho aggiunto questa volta
a #Ro-Pi sono: un LED RGB posto sulla breadboard
e tramite essa collegato al pi zero, e due
sensori di distanza sempre collegati al Raspberry Pi
tramite l'uso della breadboard, la quale breadboard
è stata già oggetto della prima puntata.
Dunque il LED RGB ha principalmente lo scopo
di feedback per l'utente, cioè possiamo sfruttarne
i vari colori che è in grado di mostrare
per segnalare eventuali operazioni o problemi
a chi sta utilizzando il robottino. Banalmente
quello che vi dicevo poc'anzi riguardo il
feedback di avvio è che quando si accende
il raspberry pi il LED sarà acceso in uno
stato particolare che mostra sia una luce
verde sia una luce blu, proprio perché i
PIN GPIO a cui il LED RGB è collegato sono
tra quelli attivi di default all'avvio del Pi.
L'idea è che quando il LED sarà automaticamente
spento dal codice inserito nell'rc.local che
viene eseguito in automatico dopo il caricamento
del sistema operativo, allora sarà possibile
per noi accendere l'H-Bridge poiché saremo
certi che le ruote non gireranno all'impazzata.
E' chiaramente una soluzione di ripiego, ma
neanche così assurda... Ma aldilà di questo,
comunque, il LED servirà da indicatore per
tante altre operazioni, soprattutto quelle
legate ai sensori di distanza.
Proprio i sensori di distanza, che potete
acquistare per circa 2€ l'uno, permettono
di rilevare la presenza o meno di un ostacolo
davanti al robottino. L'idea, infatti, è
quella di calcolare quanto spazio rimane tra
#Ro-Pi e un eventuale ostacolo, così da fermare
automaticamente la corsa del robot stesso
se si supera una determinata distanza di sicurezza,
ed evitare che la macchinina vada ad urtare
qualcosa.
Prima di addentrarci vi ricordo che, come
per la prima puntata, anche il focus di oggi
ha abbinato un articolo sul blog (linkato
in descrizione e nelle schede qui in alto)
in cui trovate spiegato più nel dettaglio
il funzionamento di ogni componente, nonché
ci sono i pezzi di codice che ho utilizzato
per far funzionare il tutto.
Bene: come si fa a controllare un LED RGB?
Il LED RGB ha 4 pin che permettono di attivare
il colore rosso, quello verde, quello blu,
ed ovviamente uno di essi è dedicato al ground
(ed è quello più lungo). Non è possibile
collegare direttamente il LED al Raspberry Pi
(e questo vale per qualsiasi LED utilizziate)
poiché il pi stesso può erogare soltanto
poca corrente (circa 60 mA) mentre il LED
ne vorrà molta di più causando possibili
problemi al GPIO (se non peggio) oppure rischiando
di bruciarsi. Quindi occorre sfruttare dei
resistori per assicurare che solo una piccola
quantità di tensione fluisca. Io avevo solo
resistori da 220 ohm quindi ho usato quelli,
ma dovrebbero andar bene anche uno da 100
(da collegare al PIN rosso) e due da 150 (per
il verde e il blu).
Lo schema è semplicissimo: il LED va inserito
nella breadboard (in un punto interno qualsiasi)
ed i resistori vanno inseriti su righe differenti
in modo che da un lato coincidano con la riga
in cui è presente il PIN del colore rosso,
blu o verde, e dall'altro quella in cui è
infilato il cavo che parte dal Raspberry Pi.
Io ho utilizzato 4 PIN GPIO del Raspberry Pi
che sono il 29, 31 e 36 per i tre colori
ed il 34 per il ground.
A questo punto ho scritto un semplicissimo
programma di test che non fa altro che settare
i PIN del GPIO come output (cioè che attivino
la rispettiva riga della breadboard), ed una
alla volta vengono richiamate delle semplicissime
funzioni che accendono o spengono tali PIN
così da far brillare il LED del colore desiderato:
rosso, verde, blu, magenta, ciano, giallo
o bianco. Chiaramente si può considerare anche il
LED spento come ottavo possibile stato di colore.
Perfetto. Una volta verificato che il LED
funzioni correttamente, possiamo passare ai
sensori di distanza.
Come è fatto un sensore di distanza?
Qui la questione è un po' più complessa... Ogni
sensore ha 4 PIN che sono: 1 ground, ovviamente,
1 per la tensione, 1 per attivare il sensore
stesso ed 1 per inviare indietro il segnale
di rilevamento completato. In pratica quello
che fa questo chip non è altro che inviare
un segnale sonoro e attivare il rilevatore
per avvertire quando lo stesso segnale torna
indietro poiché ha rimbalzato da qualche
parte. E fra poco vedremo come sfruttare questa
peculiarità per verificare la presenza o
meno di un ostacolo e la sua distanza dal
robottino.
Anche in questo caso non è possibile collegare
il sensore direttamente al Raspberry Pi poiché
esso per mandare il segnale di avvenuta cattura
lo farà con corrente a 5V che i PIN GPIO
del Raspberry Pi non possono tollerare. Quindi
anche in questo caso è necessario separare
la tensione con dei resistori. L'idea è quella
di inserire un resistore da 1000 ohm tra il
cavo collegato al PIN del sensore ed il rispettivo
collegato al PIN del Raspberry Pi, ed uno
da 2000 ohm tra quest'ultimo ed il ground
che chiude il circuito. Ciò permette effettivamente
di scendere da 5V a circa 3.3V, tollerati
dai PIN GPIO. Nel mio caso, non avendo a disposizione
resistori da 2000 ohm, per un sensore ho collegato
due resistori da 1000 ohm in serie ottenendo
lo stesso risultato, mentre per l'altro sensore
ne ho collegati sempre in serie 5 da 220 ohm.
A questo punto: il ground del sensore ed un
PIN ground del pi vanno inseriti su una delle
due file esterne della breadboard (ovviamente
in una di quelle con il segno "-"), così
come i PIN della tensione (in una di quelle
con il segno "+"): io ho scelto per un sensore
i PIN Ground 6 e Power 2, e per l'altro Ground
14 e Power 4. Continuando il giro, i PIN che
attivano i sensori potrebbero essere collegati
direttamente al pi, ma ho preferito comunque
passare per la breadboard così ho scelto
il PIN 16 per un sensore ed il 37 per l'altro.
Infine, ho sfruttato i PIN 18 per un sensore
e 22 per l'altro per accoppiarli con i PIN
che restituiscono il segnale di rilevamento
completato.
Ho scritto, quindi, un altro programmino di
test che non fa altro che settare i PIN del
GPIO come output per risvegliare i sensori,
e gli altri come input per ricevere la risposta
catturata. Ora ci sono una serie di passi
da compiere per effettivamente calcolare la
distanza: tanto per cominciare è bene spegnere
i PIN che attivano i sensori di distanza,
quindi dar loro un piccolo impulso della durata
di circa 10 microsecondi per risvegliarli.
Quindi quello che succederà è che il sensore
invierà un segnale sonoro e resterà attivo
finché non lo riceverà indietro. Questo
significa che il PIN che segnala la risposta
rimane fisso sul valore 1 fintanto che esso
non riceve indietro il segnale inviato.
Se memorizziamo l'istante in cui il processo
inizia e quello in cui il processo termina,
sapremo l'effetiva durata di tutto l'impulso, cioè quanto
tempo il suono ha impiegato a tornare indietro.
Sfruttando la semplice formula "velocità
= distanza / tempo" potremmo calcolare il
dato che a noi interessa: cioè la distanza.
Il tempo lo riusciamo a rilevare con questi
sensori; quello che manca è la velocità.
Fortunatamente, seppur la velocità del suono
sia variabile poiché dipende da ciò che
attraversa e dalla sua temperatura, si può
approssimare che la velocità del suono in
aria al livello del mare sia di circa 343m/s
o 34300 cm/s.
A noi, tra l'altro, interessa sapere la distanza
tra il robottino e l'eventuale ostacolo: il
tempo che sarà intercorso tra l'invio del
suono ed il suo ritorno sarà effettivamente
il doppio di quello impiegato per raggiungere
l'ostacolo. Quindi la formula che abbiamo
detto poc'anzi diventerà "34300 = distanza
/ tempo calcolato / 2", altresì detto "17150
= distanza / tempo calcolato", altresì detto
"distanza = 17150 * tempo calcolato". Abbiamo
quindi tutte le informazioni necessarie per
sapere la distanza in centimetri tra il sensore
e l'eventuale ostacolo.
Ed infatti avviando più volte questo script
di test possiamo vedere come posizionando
ad esempio una mano o un altro oggetto a distanze
differenti dal sensore, ci venga ogni volta
restituita la distanza approssimativa calcolata.
Dico approssimativa poiché sensori come questi,
molto economici, a volte non restituiscono
valori al 100% corretti...
Perfetto, a questo punto perché non unire
tutto quello sviluppato finora in un unico
test generale? E infatti è proprio quello
che ho fatto: fare in modo che il robottino
si muova ad esempio in automatico in una direzione,
e incontrato un ostacolo si fermi autonomamente
senza il nostro intervento. In più, con l'ausilio
del LED indicare all'utilizzatore che cosa
sta succedendo con i vari colori a disposizione.
Ho preso i vari pezzettini di codice scritti
per controllare i motori, controllare i LED
e controllare i sensori di distanza, ed ho
creato un ultimo programmino test che non
fa altro che: attivare il sensore di distanza,
verificare che ci siano almeno 25 cm di spazio
a disposizione, quindi accelerare per 1 secondo
e ½, e ripetere l'operazione finché il robottino
non si trovi ad una distanza inferiore a quella
di sicurezza rispetto ad un ostacolo.
Ci sono alcune considerazioni da fare: l'esecuzione
del codice è sufficientemente veloce e, seppur
i motori vengano attivati, poi fermati e poi
riattivati e così via, non c'è mai la sensazione
di un movimento a scatti, e questo è chiaramente
positivo. Provando a diminuire il tempo tra
un controllo della distanza e l'altro (scendendo
sotto il secondo e ½), il sensore inizia
a generare errori di calcolo rischiando di
far collidere il robot. Quindi va trovata
una giusta proporzione tra il tempo di accelerazione
e quello di distanza di sicurezza: allungando
i tempi di accelerazione si dovrà aumentare
la distanza di sicurezza poiché il robottino
si avvicinerà all'eventuale ostacolo molto
più in fretta. Al contrario accorciando i
tempi di accelerazione si potrà diminuire
la distanza di sicurezza poiché verranno
effettuati controlli più rapidi e quindi
il robottino si troverà più difficilmente
"in pericolo". Purtroppo come detto scendere
sotto al secondo e ½ rende le misurazioni
meno affidabili ed è per questo motivo che
proverò a migliorare l'algoritmo sfruttando
entrambi i sensori... Vi farò sapere!
Ricapitolando brevemente: in aggiunta a quanto
visto nella prima puntata, abbiamo arricchito
#Ro-Pi con un LED RGB di feedback utilizzabile
per segnalare operazioni o problemi all'utilizzatore,
e dei sensori di distanza da sfruttare --in
realtà per tante cose-- ma principalmente
per rilevare la presenza o meno di ostacoli
davanti al robottino.
Direi che di carne al fuoco per oggi ne abbiamo
aggiunta anche troppa, quindi fermiamoci
qui per ora... Nelle prossime puntate continueremo
ad arricchire #Ro-Pi così da potenziarlo.
Se avete suggerimenti, domande, consigli o
qualsiasi altra cosa da segnalare vi aspetto
nei commenti. Se il video vi è piaciuto e
se trovate interessante questa serie di focus
fatemelo sapere con un bel like. E chiaramente
se ancora non lo foste iscrivetevi al canale
attivando le notifiche per essere subito avvisati
quando pubblicherò la prossima puntata!
Ci sentiamo quindi presto. Ciao!!
