Tralasciando le premesse storiche, e passando a qualcosa di più concreto, ho cominciato un progettino giocando con i vari metodi messi a disposizione della libreria e sono arrivato a realizzare un’applicazione che evidenzia i volti ripresi dalla WebCam e scattando una foto campione è in grado di analizzarla con ciò che si vede a video e stabilire se si tratta dello stesso soggetto.

Di seguito il codice del metodo richiamato al caricamenteo dell’applicazione.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

private void Window_Loaded(object sender, RoutedEventArgs e)
{
   capture = new Capture(0);
   Risoluzione = String.Format("Risoluzione: {0}x{1} ({2})\n\r", 
          capture.Width, capture.Height, capture.CaptureSource);
   haarCascade = new HaarCascade(@"haarcascade_frontalface_default.xml");
   // Check if foto file is present
   if (File.Exists(FOTO_FILE))
   {
      Bitmap pictureFace = new Bitmap(FOTO_FILE);
      image3.Source = _bitmapToSource(pictureFace);
      txtbMessaggi.Text = "Pronto per l'analisi del soggetto ...";
   }
   else
   {
      txtbMessaggi.Text = "Scattare una foto prima di procedere con l'analisi ...";
   }
 
   // Start timer
   timer = new DispatcherTimer();
   timer.Tick += new EventHandler(timer_Tick);
   timer.Interval = new TimeSpan(0, 0, 0, 0, 1);
   timer.Start();
}

L’oggetto principale è il Capture, in pratica è quello che cattura i frame dalla WebCam, è possibile anche definire alcuni parametri supplementari, ma in questo caso prende le impostazioni base. Da notare il numero 0 tra le parentesi quando instanzia l’oggetto, serve ad identificare quale Web Cam utilizzare, nell’ipotesi che ne abbiate più di una disponibile, naturalmente il primo pensiero va alla possibilità di utilizarne due contemporaneamente per la visione stereoscopica.
Altro oggetto importante è l’HaarCascade tramite il quale è indicato un file XML, dove sono definite le regole per il riconoscimento dei volti. Tra i vari file delle OpenCV che si scaricano, c’è anche un eseguibile per creare questi file XML, ma non ho ancora provato ad utilizzarlo.
Il resto del codice è per controllare se è gia stata scattata una foto, la parte importante è quella relativa alla definizione del Timer che ad ogni Tick richiamerà il metodo associato, visibile nel codice che segue.

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

void timer_Tick(object sender, EventArgs e)
{
   Image currentFrame = capture.QueryFrame();
 
   if (currentFrame != null)
   {
      String Coordinate = "";
      int counterFace = 0;
      Image grayFrame = currentFrame.Convert();
 
      var detectedFaces = haarCascade.Detect(grayFrame);
 
      foreach (var face in detectedFaces)
      {
         int xCenter = face.rect.X + (face.rect.Width / 2);
         int yCenter = face.rect.Y + (face.rect.Height / 2);
         Coordinate += String.Format("Face {0} - X:{1},Y:{2} - ({3})\r\n", counterFace, xCenter, yCenter, face.neighbors);
         // Filtro per non vedere quadrati di facce sovrapposte
         if (face.neighbors > 20)
         {
            // Rettangolo che evidenzia il volto
            currentFrame.Draw(face.rect, new Bgr(0, counterFace * 100, 255), 3);
            // Crocetta al centro del rettangolo
            currentFrame.Draw(new Cross2DF(new System.Drawing.PointF(xCenter, yCenter),
               10, 10), new Bgr(System.Drawing.Color.DarkGray), 1);
            // Aggiunto per scattare la foto solo se ha inquadrato un volto e per recuperare solo la porzione del volto
            if (scatta)
            {
               Bitmap pictureFace = currentFrame.ToBitmap().Clone(new Rectangle(face.rect.X, 
                  face.rect.Y, face.rect.Width, face.rect.Height), currentFrame.ToBitmap().PixelFormat);
               pictureFace.Save(FOTO_FILE);
               image3.Source = _bitmapToSource(pictureFace);
               scatta = false;
               txtbMessaggi.Text = "Foto scattata.";
            }
         }
         counterFace++;
      }
      image1.Source = ToBitmapSource(currentFrame);
      txtbCoordinate.Text = Risoluzione + Coordinate;
   }
}

La prima operazione che viene eseguita è la cattura di una “istantanea” tramite il metodo QueryFrame dell’oggetto Capture, l’oggetto Image restituito viene poi elaborato per essere convertito in una immagine in scala di grigi e poi dato in pasto al metodo Detect dell’oggeto HaarCascade di cui parlavo prima. Il risultato è un oggetto che rappresenta tutte le facce, e le loro proprietà, che il metodo è riuscito ad identificare nell’istantanea. Il ciclo foreach serve per elaborare i dati “di ogni” faccia riconosciuta.
In pratica per ogni faccia viene identificata un area rettangolare dell’istantanea che la contiene, recupero queste informazioni per mostrarle poi a video sia sotto forma di coordinate che di rettangolo che evidenzia il volto. Il controllo “if(face.neighbors>20)” l’ho usato per evitare che venissero disegnati quadrati sovrapposti, può capitare un po’ di tutto anche che riconosca cose strane come volti. Il controllo sulla variabile “scatta” serve a fare in modo che l’immagine da usare come campione per l’analisi venga scattata, dopo la pressione dell’apposito pulsante, solo quando è evidenziato almeno un volto.

Il metodo btnAnalizza_Click è quello che si occupa di analizzare l’immagine del volto salvata precedentemente con quella che viene catturata dopo la pressione del pulsante per l’analisi, non riporto tutto il codice, ma in fondo alla pagina si può scaricare tutto il progetto. Uno degli oggetti fondamentali è il SURFDetector che viene inzializzato con l’oggetto MCvSURFParams dove è indicata la soglia di keypoint di uguaglianza tra le due immagini, necessari per decretare che si tratta dello stesso soggetto. Vengono creati due oggetti ImageFeature per le due immagini da campionare a cui vengono poi applicati i metodi dell’oggetto Features2DTracker. Infine ho usato l’oggetto HomographyMatrix per determinare il piano prospettico del volto cercato nell’immagine analizzata, questo oggetto viene definito solo se l’algoritmo riesce a definire una corrispondenza. Il resto del codice serve a concatenare le due immagini in una, unire i punti di corrispondenza delle due immagini ed evidenziare il piano della HomographyMatrix.
Se siete arrivati a leggere fin qui e siete a digiuno degli argomenti trattati, vi sembrerà qualcosa di complicato, ma vorrei tranquillizzarvi che sono arrivato a completare questo programma semplicemente mettendo insieme vari esempi e cercando di capire, anche se con i miei limiti, come funzionano le cose. Se invece pensate che abbia scritto cavolate non esitate a corregermi. Di seguito trovate il link al codice sorgente e quello per l’eseguibile se siete solo curiosi di provare il programma, per essere eseguito richiede comunque il .Net Framework 4 perchè ho voluto usare WPF per realizzare l’interfaccia.

:: Face Detection Code ::

:: Face Detection ::

Per chi fosse interessato segnalo un articolo simile “Riconoscimento facce con OpenCV“ dell’amico Walter, che in merito a questi argomenti ha più conoscenze di me, scritto in C++. Sul suo sito potete trovare altri Tutorial molto interessanti.

Analizziamo lo schema a partire dal blocco in alto a sinistra, il Battery Monitor, come avevo scritto in un altro post, i tempi sono maturi per passare ad utilizzare batterie LiPo senza spendere una fortuna sui nostri Robot, ma per non rovinare questo tipo di batterie è meglio tenere sotto controllo il loro livello di carica, per farlo pensavo di utilizzare un PIC che potesse segnalare lo stato di carica tramite un LED e staccare l’alimentazione a tutto il sistema se si scende sotto la la soglia minima, poi visto che c’è il PIC perché non permettere al sistema centrale di controllare il livello di carica? Per questa sezione ho già uno schema di massima e idee su come realizzarlo, ma ancora non ho realizzato un circuito per effettuare i primi test.
Continuando verso destra dello schema, c’è il secondo blocco dell’alimentazione, si tratta di un circuito Switching Step Down per l’alimentazione, il cui scopo è quello di ridurre la tensione che arriverà sugli stabilizzatori a 5V delle altre schede. Questo perché l’alimentazione principale sarà fornita da una batteria da 14,4V, tensione che sarà applicata direttamente al Ponte H per pilotare i motori che sono da 12V, mentre per gli stabilizzatori che devono ridurre i 14,4V della batteria a 5V, sono costretti a dissipare tanta energia in calore, con conseguente scarica della batteria più rapida. Per ottimizzare i consumi utilizzerò lo Step Down, grazie anche all’esperienza e il supporto di Guido, in questo modo la tensione che arriverà in ingresso agli stabilizzatori sarà di 7V riducendo al minimo le perdite di energia sotto forma di calore.
Il punto fondamentale dello schema è il BUS RS485 che ho scelto per l’interconessione tra i vari sistemi, il motivo che mi ha orientato su questa soluzione rispetto ad altre tipologie di BUS è dovuta anche al fatto che ultimamente altri amici Robottari lo stanno utilizzando per i loro progetti, e mi è sembrata da subito una buona idea realizzare qualcosa che potesse in qualche modo essere comune ad altri progetti, per permettere oltre allo scambio di esperienze anche la possibilità di utilizzare soluzioni circuitali di altri con il minimo sforzo. In fin dei conti questo per me è un hobby non un lavoro (purtroppo), quindi se qualcuno realizza qualcosa che può tornarmi utile, mi permette di perdere meno tempo e raggiungere prima il risultato che mi sono prefissato.
Passando ai blocchi nella parte bassa dello schema, la Sensor Board come dice il nome stesso, è quella che si occuperà della gestione di tutti i sensori telemetrici e di rilevazione ostacoli. Nell’ottica di realizzare qualcosa che potesse tornare utile anche ad altri sto cercando di progettarla in modo da renderla più versatile possibile, anche se per questioni di costo sono costretto a limitarmi all’utilizzo dei sensori che avevo nei cassetti a prendere polvere. Questa è anche la scheda che al momento si trova in una fase di sviluppo più avanzata, ma ne parlerò più in dettaglio in un prossimo post.
Il controllo motori sarà affidato al blocco Motor Control, tramite una scheda realizzata dall’amico Stefano, con cui collaborerò per lo sviluppo del software per il controllo PID, tale progetto segue le linee di quello di Guido. Dimenticavo di dire che questa scheda è un altro motivo che mi ha spinto verso l’utilizzo del BUS 485, visto che Stefano l’ha progettata e realizzata così (fortunatamente).
Infine la scheda di controllo del Robot, come anticipato prima, sarà basata su mbed, almeno per il momento, dotata di un modulo WiFly per la trasmissione di dati telemetrici verso un PC. Su questa parte al momento ho poche idee, ma ben confuse, non credo che farà cose molto complesse oltre a orchestrare il funzionamento delle varie periferiche.

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.