1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

#include <i2c.h>
 
#define SRF02   0xE0            // Address of SRF02
 
/**************************************************************************
 * Inizializza la periferica MSSP per il funzionamento in I2C Master
 *************************************************************************/
void srf02_config(void)
{
    OpenI2C(MASTER, SLEW_OFF);
    SSPADD = 0x63;              // 100khz BUS @ 40MHz PIC
}
 
/**************************************************************************
 * Esegue la misurazione tramite il sensore
 *
 * Restituisce la misura effettuata in centimetri
 *************************************************************************/
unsigned int srf02_read(void)
{
    int result=1;
    unsigned int measure=0;
    unsigned char measurement[2];
 
    result = EEByteWrite(SRF02, 0x00, 0x51);
    // Verifica l'esito dell'operazione di avvio della lettura
    if(result==0)
    {
        // Attende il completamento della misurazione del sensore
        Delay10KTCYx(70);
        // Recupera la misurazione fatta dal sensore
        result = EESequentialRead(SRF02, 0x02, measurement, 2);
        // Verifica l'esito dell'operazione di lettura del sensore
        if(result==0)
        {
            // Scrive il valore letto dal sensore
            measure = (measurement[0]<<8);
            measure += measurement[1];
        }
    }
 
    return measure;
}

Di seguito invece la chiamata a questi nuovi metodi:

1
2
3
4
5
6
7
8
9
10
11
12

void main(void)
{
    ...
    srf02_config();
    lcd_clear();
 
    for(;;)
    {
        lcd_put_uint(srf02_read(),0,0);
        Delay10KTCYx(500);
    }
}

Questo sensore può essere controllato sia in I2C che in seriale, la scelta della modalità di controllo avviene tramite uno dei 5 pin, che va collegato a massa se si vuole usare la seriale, o lasciato non collegato se si vuole usare il controllo tramite I2C. In questo articolo parlerò della mia esperienza con il sensore controllato in I2C tramite un PIC 18F2620, e come si potrà vedere la gestione del sensore è identica a quella di una comune EEPROM I2C. I dettagli sul sensore e il suo utilizzo li potete trovare a questo link.

Cominciamo ad analizzare lo schema elettrico del circuito che è quanto di più semplice possa esistere.

Come si può vedere, oltre alla circuiteria di base per il PIC (quarzo, condensatori e resistenza su MCLR) il sensore è collegato ai pin RC3 e RC4 rispettivamente SCL e SDA, utilizzati dal modulo MSSP del PIC per la comunicazione con dispositivi Slave I2C. Entrambi questi pin sono tenuti a livello alto tramite due resistenze di pull-up da 1,8K ohm, così come richiesto dalle specifiche del BUS I2C. Ho aggiunto allo schema anche un display, per poter visualizzare i valori restituiti dal sensore.

Vediamo ora il codice:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

void main(void)
{
unsigned char counter;
unsigned int range=0, autotune=0;
 
    // Configurazione del PIC
    config_system();
    // Esegue 6 letture ravvicinate per l'autotune
    srf02_init();
 
    // Loop infinito
    for(;;)
    {
        // Invia al sensore la richiesta per avviare la misurazione in cm
        srf02_tx(SRF08, 0, 81);
        Delay10KTCYx(70);
        // Legge i sei registri del sensore
        srf02_rx(SRF08, 0, 6);
        lcd_clear();
        // Scrive la versione del software del Sensore
        lcd_put_uchar(srf02_buffer[0],0,0);
        // Scrive il valore del registro non usato (dovrebbe essere 0x80)
        lcd_put_uchar(srf02_buffer[1],0,4);
        // Scrive il valore letto dal sensore
        range = (srf02_buffer[2]<<8);
	range += srf02_buffer[3];
        lcd_put_uint(range,0,8);
        // Scrive il valore di autotune
        autotune = (srf02_buffer[4]<<8);
	autotune += srf02_buffer[5];
        lcd_put_uint(autotune,0,14);
 
        Delay10KTCYx(500);
    }
}

Come si può vedere anche il codice (quello completo è scaricabile da questo link) è molto semplice, alla riga 15 viene chiamata la funzione che avvia la misurazione della distanza in centimetri da parte del sensore. Poi un delay attende che siano passati 70 millisecondi, il tempo necessario per ricevere l’eco più lontana e poi vengono letti i 6 registri del sensore, memorizzando i valori nell’array srf02_buffer. Come indicato nella guida ogni registro del sensore contiene delle informazioni specifiche, come si può facilmente capire dai commenti nel codice, la parte che ci interessa di più è quella alle righe 25 e 26, dove viene letta la distanza misurata tra il sensore e l’oggetto che si trova di fronte. Sul display, a scopo puramente didattico, il codice visualizza tutti gli altri valori, e come si può vedere tutto il ciclo viene ripetuto ogni mezzo secondo. Alla riga 9 viene chiamata la funzione srf02_init(), questa non fa altro che eseguire sei misurazioni in rapida sequenza, come indicato nelle specifiche del sensore le prime 5/6 misurazioni vengono usate per fare un’auto calibrazione del sensore.

In un primo momento, seguendo l’esempio riportato sulle pagine della documentazione, andavo a leggere solamente i due registri che contengono la misura della distanza, facendo in questo modo però avevo delle strane misure che, partendo da un minimo cominciavano ad incrementarsi per dieci letture consecutive per poi ricominciare da capo. La misura più piccola risultava però essere molto più precisa di quella che ottengo leggendo tutti e 6 i registri. Non avendo trovato informazioni utili su questo strano comportamento ho comunque deciso di considerare il metodo della lettura di tutti i registri come più stabile, e quindi come sistema da utilizzare. Se avete delle esperienze diverse sarei curioso di capirne di più quindi non esitate a postare commenti con le vostre esperienze.

Prossimamente voglio provare ad utilizzare anche il modello SRF10, che viene gestito analogamente al SRF02, ma essendo dotato di una capsula US trasmittente ed una ricevente riesce a gestire una misura minima più bassa pari a 6cm.

:: Scarica il codice completo ::

E’ vero che si tratta di un evento dedicato alle scuole, ma ci saranno anche altre iniziative in ambito Robotico, tra le tante cito anche alcune presentazioni su Arduino tenute da un amico di Roboteck, gruppo citato anche nel programma della manifestazione.

Tra le gare in programma ci sono:

• Explorer Junior
• Explorer Senior
• Robocup junior open league
• Robocup junior light weight league
• Robocup junior Dance primary
• Robocup junior Dance secondary
• Robocup junior Rescue primary
• Robocup junior Rescue secondary

Se siete interessati, per maggiori dettagli potete andare sul sito ufficiale della manifestazione il link è il seguente: http://www.romecup.org/

Determinato il sistema di locomozione, bisogna pensare a come alimentare sia i motori che tutta la parte di logica del Robot. Sempre per una questione di spazio la prima idea è stata quella di utilizzare 4 batterie stilo e un porta batterie di quelli con le molle, per avere la possibilità di cambiarle facilmente. Facendo un po’ di calcoli però si vede subito che questa soluzione, così com’è non può andare, infatti se consideriamo 4 comuni batterie stilo da 1,5V abbiamo un totale di 6V che sono un po’ pochi per una logica che funziona a 5V anche utilizzando uno stabilizzatore LDO, perché basta che si scarichino un po’ le batterie per avere problemi. In più c’è da considerare anche il Ponte H che, a causa dei sui circuiti interni, che fanno scendere la tensione applicabile ai motori di 2,5V, andrebbe ad alimentare i motori con 6-2,5=3,5V e una tensione un po’ troppo bassa per dei motori che nascono da 6 Volt equivale a dire perdere molti giri motore, tenendo presente che su un robot da LF la velocità è un fattore importante sicuramente non questa non è una scelta valida. Naturalmente il discorso peggiora pensando di utilizzare delle batterie ricaricabili che sono da 1,2V per elemento.

Ecco quindi il primo problema da affrontare, il ponte H serve anche perchè i motori saranno controllati in PWM, vorrei evitare di scegliere qualcosa di alternativo al L293, almeno per ora, quindi non mi rimane che alzare la tensione. Le possibilità sono due aumentare il numero di batterie, che vorrebbe dire più ingombro e più peso, o aggiungere un circuito elevatore di tensione, che vuol dire aumentare la complessità ed il costo del Robot.
Dopo averci ragionato un po’ chiedo consiglio agli amici di Roboteck per avere un loro parere, che è stato quasi unanime verso l’utilizzo di batterie Li-Po, in effetti era una soluzione che non avevo mai preso in considerazione per via dei costi, che nel tempo sono cambiati, infatti per delle buone batterie NiMH si spendo circa 4€ ad elemento quindi dovendone usare sei il totale fa 24€, mentre guardando tra i negozzi di modellismo si trovano delle buone LiPo da 7,4V (2 celle da 3,7V) 1800mAh (20C) a 20€. Escludendo la piccola differenza di prezzo, quello che cambia notevolmente è l’ingombro e il peso (80g di differenza).

Sulle LiPo va fatta comunque una piccola precisazione, sono delle batterie un po’ delicate, quindi vanno gestite con criterio, per prima cosa necessitano di caritori appositi quindi meglio non improvvisare perchè potrebbero anche esplodere, poi quando vengono utilizzate è bene non scendere mai al disotto di una certa soglia di tensione (3V per cella) oltre la quale la batteria potrebbe anche danneggiarsi.
Fatte tutte queste premesse, dettate anche dai vari consigli ricevuti, sono passato a disegnare lo schema elettrico della sezione di alimentazione che è quello che potete vedere in figura.

Partendo da sinistra i due ingressi X1 e X2 sono per il connettore della batteria LiPo da 7,4V, per prima cosa è presente un partitore resistivo il cui scopo è quello di ridurre la tensione che viene prelevata nel punto indicato da VBAT e inviata ad un ingresso ADC per essere misurata, lo scopo è quello di tenere sotto controllo lo stato di carica della batteria durante il funzionamento del Robot ed eventualmente intervenire nel caso in cui la tensione scenda sotto una certa soglia, il partitore serve per ridurre la tensione che arriverà all’ADC, considerando anche che a batteria carica la tensione sarà anche superiore agli 8Volt. I motori saranno alimentati direttamente dalla batteria, per la parte logica ho aggiunto un regolatore LDO (IC1) con configurazione classica dei condensatori in ingresso ed in uscita. Nel circuito ho aggiunto solamente un diodo (D1) prima del regolatore per evitare inversioni di polarità, qualcuno avrà notato però che ai motori, o meglio al ponte H arriva direttamente la tensione di batteria senza passare per il diodo, questa mia scelta serve per evitare ulteriori cadute di tensione verso i motori, e sono disposto a sacrificare ponte H che tutto il resto dell’elettronica, anche se un danno è quasi impossibile, visto che il connettore della batteria sarà comunque polarizzato.
Il prossimo step sara quello di cominciare a mettere insieme i pezzi, cioè di vedere assemblati i motori sul supporto di vetronite che ospiterà anche i circuiti di alimentazione e controllo motori.

Collegando l’mbed al PC, viene visualizzato un nuovo disco rimovibile, che rappresenta la memoria flash dell’mbed dove andremo a scaricare il nostro programma, naturalmente se vediamo le proprietà si tratta di pochi KB (mai vista una chiavetta così piccola ), come indicato anche nel foglietto delle istruzioni aprendo questo disco c’è dentro un file html che non è altro che un redirect alla pagina di registrazione sul sito dell’mbed.
Poche informazioni da compilare e ci si registra per accedere subito alla parte autenticata del sito, ho visto che da una parte è riportato un numero di serie che dovrebbe essere relativo al proprio mbed, ma non ho indagato se c’è un legame diretto o meno. La sezione autenticata fa molto Social Network, per prima cosa si accede alla propria Home da cui è possibile accedere ad altre pagine, il tutto per condividere progetti, librerie, riferimenti ad altri social network (FB,Twitter,LinkedIn), evidenziare come preferiti altri utenti, e altre funzionalità che ancora non ho avuto modo di esplorare, certo non siamo ai livelli di FB, ma ci sono diverse funzionalità utili, anche se ad un primo sguardo qualcosa manca, come ad esempio potrebbe essere un feed sull’evoluzione di progetti che si stanno seguendo.

Il punto forte è comunque il “Compiler”, cliccando su questo link si apre in una nuova finestra l’ambiente di sviluppo nel browser, da qui si gestiscono i propri progetti, ma è possibile anche cercare, ed importare, nel proprio workspace tutti i progetti/librerie pubbliche realizzate da altri utenti, tanto per segnalare un’altra funzionalità di navigazione, quando si incontrano dei progetti interessanti sono disponibili degli shortcut per accedere al compilatore con la sezione di import già configurata per caricare il progetto che si stava guardando.
Il sito fornisce comunque una buona documentazione, a questo link ci sono le spiegazioni per cominciare ad utilizzare l’ambiente di sviluppo: http://mbed.org/handbook/Creating-a-program.

Quando si crea un nuovo progetto, viene generato subito il codice per eseguire il lampeggio di uno dei 4 led presenti sulla scheda, ma basta fare un giro tra i vari progetti per capire come fare delle semplici modifiche e cominciare a fare dei semplici giochi di luci con i 4 led, magari andando ad importare qualche progetto già presente.
Nel poco tempo che sono riuscito a dedicargli ieri ho visto che esiste anche la possibilità di utilizzare la connessione USB, normalmente usata per programmare la scheda, anche per la comunicazione con il PC, è sufficiente installare un driver (il driver è necessario solo per Windows), e la connessione verrà vista come una Seriale, quindi utilizzando un programma di terminale (tipo Hyper Terminal) e configurandolo come indicato nel sito si può stabilire una comunicazione bidirezionale con il PC.
Per provare come funziona basta aprire la finestra del Compiler, creare un nuovo progetto e scrivere il codice che segue:

1
2
3
4
5
6
7
8
9
10
11
12
13

#include "mbed.h"
DigitalOut myled(LED1);
int main()
{
   while (1)
   {
      myled = 1;
      wait(0.2);
      printf("Hello World!n");
      myled = 0;
      wait(0.2);
   }
}

 Lo standard output, ma anche lo standard input, è la seriale quindi usando la printf scriviamo direttamente sul terminale. A questo punto è sufficiente salvare il progetto e avviare la compilazione, terminata la quale il bowser avvia il download di un file “bin” con il nome del nostro progetto. Questo file, che possiamo scaricare direttamente nella memoria dell’mbed, rappresenta il nostro programma compilato, ora basta avviare il programma di terminale sul PC e poi premere il pulsante di reset sull’mbed, come risultato avremo il solito led lampeggiante, mentre sul terminale comparirà la scritta “Hello World!” che si ripeterà per ogni ciclo del codice.

Devo dire che sono rimasto molto colpito dalla semplicità con cui sono riuscito ad ottenere questo risultato, che in altre condizioni in cui mi sono trovato per fare una cosa simile (PIC<->PC) ho impiegato decisamente molto più tempo ed è stata necessaria una conoscenza molto più approfondita dell’oggetto che stavo utilizzando, mentre in questo caso con un ora di “gioco” sono arrivato a questo risultato.
Certo gli argomenti testati sono molto semplici, invece ero interessato ad utilizzare l’USB come Host e mi sono perso nei meandri dei vari documenti trovati sul sito, ma questo è sicuramente un argomento più complesso che richiede sicuramente uno studio più approfondito, anche perché è la prima volta che lo affronto e mi mancano anche le basi.
Spero quanto prima di avere tempo da dedicarci e cominciare a studiare nuove cose, vi terrò aggiornati sulle varie esperienze, se invece nel frattempo avete qualche domanda o curiosità da chiarire chiedete pure, vediamo se riesco ad aiutarvi

Altri esempi di tracciato li potete trovare allegati al regolamento.

Sempre sul regolamento sono definite la distanza minima tra due righe, il raggio minimo di curvatura e l’angolo minimo in caso di curve angolari, che è di 90°. I segmenti ortogonali alla riga del tracciato servono come punti di rilevamento per i tempi, quindi il Robot deve essere in grado di oltrepassarli senza problemi.

Naturalmente vengono squalificati i Robot che non seguono correttamente il tracciato, ovvero cominciano a girovagare senza meta, maggiori dettagli ed esempi in merito sono riportati nel regolamento, che consiglio comunque di leggere.

Ecco un video di un Robot all’opera, ma fate un giro su YouTube ne trovante molti altri.

In sostanza per realizzare un LF servono un paio di motori, dei sensori in grado di verificare la presenza della riga nera, i circuiti di controllo e tanta fantasia nello scrivere il software, semplice no.

Se avete voglia di cimentarvi e confrontare le vostre capacità, la prossima occasione sarà a Sutri, dove si sta organizzando un evento Robotico in cui ci sarà sia il Line Follower che altre categorie, spero presto di poter dare ulteriori dettagli sulla manifestazione.

Intanto penso che con buona probabilità comincerò la costruzione di un nuovo Robot LF, dopo l’esperienza di Smoke a Pisa, ho capito che bisogna realizzare un progetto specifico, sempre su questo sito quanto prima comincerà la cronologia del progetto.

mbed.org

Come dice la prima riga del sito, mbed è un tool per realizzare velocemente un prototipo con microcontrollore.

Questo piccolo circuitino, contiene tutto il necessario per far funzionare un microcontrollore ARM a 32bit, ci sono due modelli a disposizione con caratteristiche simili, le caratteristiche del modello di punta sono 64KB di RAM, 512KB di flash, un processore ARM Cortex-M3 Core a 96MHz, e molte altre periferiche incluse Ethernet, USB Device e Host, CAN, SPI, I2C, ADC, PWM e altri I/O.
L’immagine che segue mostra tutte le periferiche disponibili da questo sistema.

Come si programma?

Nel modo più semplice che possa esistere, tramite la porta USB presente sulla scheda, e la cosa più interessante è che non si deve installare nulla sul proprio computer, niente compilatori, niente programmatori, ma come va tanto di moda in questo periodo è tutto CLOUD! Mi spiego, una volta che ci si è registrati sul sito si può accedere al nostro workspace direttamente dal browser ed accedere al sistema di sviluppo, quindi non avremo nessun problema di sistema operativo utilizzato e di performance del PC, qui non dobbiamo fare altro che creare il nostro progetto scrivere il codice, che dimenticavo è C++, compilare ed automaticamente il browser ci propone di scaricare un file BIN, che non è altro che il nostro codice. Il sistema operativo vede mbed (collegato alla USB) come un disco esterno guarda caso, e proprio in questo disco che andiamo a copiare il file BIN che poi potremo eseguire. Non è semplicissimo?

Disponibilità di librerie già pronte

Direttamente sul sito di mbed, ma direi anche direttamente nel nostro ambiente di sviluppo, sono disponibili una serie di librerie standard, più tutte quelle realizzate da altri utenti come noi, senza parlare che ci sono anche tutta una serie di progetti già pronti a cui possiamo accedere sempre realizzati dalla comunità.

L’mbed non arriverà da solo ho preso anche un’altra scheda di “espansione” la mbed LPC1768 Workshop Development Board con le seguenti caratteristiche:

• RJ45 Ethernet socket with magnetics and LEDs
• USB A socket
• USB mini-B socket
• uSD card socket
• Double row mbed socket for easy probe access to pins

Ora non mi resta che aspettare di ricevere questo nuovo giocattolo, appena arriva comincio a muovere i primi passi e poi postero qualche articolo sulla mia esperienza in merito.

La scuola ci ha messo disposizione l’aula magna per tutto il pomeriggio, così subito dopo le gare abbiamo consumato un pasto veloce per cominciare ad affrontare i punti che avevamo in programma il prima possibile.

Gli argomenti trattati nel pomeriggio sono stati molto interessanti, ed hanno portato al solito grande interesse da parte di tutti, presentando lavori fatti con vecchie conoscenze e nuovi prodotti che si affacciano nella robotica.

Guido ci ha introdotto prima ad un nuovo sistema di prototipazione veloce l’mbed, basato su un processore ARM a 32-bit facilmente programmabile e con tutta una serie di librerie realizzate da una intera comunità. Poi ci ha parlato del progetto che ha realizzato con lo PSoC (di cui se ne era parlato la prima volta proprio l’anno prima sempre in occasione dell’incontro di Pisa) per il rilevamento del tono a 4KHz per la gara dei Robot Explorer.

L’altro intervento della giornata è stato quello di Sergio che ci ha illustrato le potenzialità di ROS un framework che facilità il lavoro di sviluppo software e di interconnessioni tra i vari sistemi di un Robot.

Il pomeriggio si è concluso con i primi di test di Line Follower, necessari anche per validare i punti del regolamento che verrà utilizzato nelle prossime competizioni. I robot pronti per i test non erano tantissimi, ma si è già visto un buon interesse da parte di molte persone, ci si aspetta quindi una buona partecipazione alla prima gara ufficiale. Buone notizie in tal senso arrivano anche dal Fascetti, che sembrerebbe essere interessata come scuola a ospitare per il prossimo anno anche una competizione di Line Follower.

Vi lascio con un video di Smoke impegnato nell’affrontare il circuito del Line Follower.