Devo ammettere che la webcam, quando mi è arrivata a casa, pensavo fosse più piccola !
Dalle foto online mi era apparsa più minuscola, ma non mi sono scoraggiato e ho trovato il metodo per montarla sul mio BigWheely !

Sono stato felice anche di apprendere, dopo le dovute misurazioni, che il consumo medio della webcam si aggira sui 300 mA e non necessariamente i 1000 mA come dalle specifiche. Ho potuto sfruttare il regolatore di tensione già presente nel circuito della web cam e collegarlo direttamente alle batterie (4 batterie tipo AA ricaricabili).

Questa è la prima immagine trasmessa dal dispositivo, alimentato interamente a batterie:

E questo invece è il primo video trasmesso da BigWheely intanto che è in movimento:

 

 

NOTA BENE: L'ordine di muoversi non è impartito in modalità remota ma bensì da un semplice sketch che ho caricato su Arduino che muove le ruote a intervalli regolari !!!

 

Ora che ho definito e testato il protocollo di trasmissione creato ad HOC per il mio progetto sarebbe interessante poter comunicare tra Arduino (client) e computer (host) in modalità senza fili (wireless).

Per farlo ho acquistato delle schedine XBee già presentate e descritte in precedenza.
Io, non so per quale malaugurata idea, ho deciso di acquistare delle schedine di tipo Serie 2, che visivamente sono piuttosto simili tra loro, ma che presentano una complessità maggiore in fase di programmazione.

Ho trovato molti tutorial o istruzioni per le schedine Serie 1 (802.15.4) che vengono solitamente  già fornite con un firmware adatto a creare connessioni punto-punto.
Più difficile trovare guide per la programmazione delle schede XBee Series 2. Attenzione a non lasciarvi confondere da queste differenze perchè le due serie funzionano in modo differente e NON sono compatibili tra loro.

Ancora un precisazione sulla differenza tra XBee e XBee PRO, entrambi si trovano sul mercato, ma hanno prezzi decisamente differenti. La differenza principale tra le due famiglie è quella della potenza di trasmissione, mentre le XBee raggiungono solitamente 50-100 metri di distanza, mentre le versioni PRO coprono anche alcuni chilometri di distanza. 

Questa tabella comparativa spiega piuttosto bene le differenze tra tutti i modelli della famiglia XBee.

 

NOTA: I tutorial e le guide che si trovano sul web spesso non hanno funzionato perchè i modelli di XBee non sono esattamente quelli che avevo io, con conseguenti problemi di comunicazioni o una perdita consistente di dati.

 

In base al modello di schede che ho comperato io (XB24-BCIT-004 revE) e ai test che ho fatto, vi riporto i passi fondamentali per una programmazione funzionante:

1) Identificare e annotare il tipo di schede

Queste sono le schede che ho acquistato io:

 

Nelle foto è rappresentato anche il lettore di schede XBee (UartSBee V4) collegabile al computer tramite USB. Utilizzeremo proprio questo modulino per leggere e caricare il firmware adatto su entrambe le schede XBee. 

Innanzitutto leggete i dati riportati sul retro delle schedine XBee e riportatele su un foglio:

 

Per chiarezza l'ho riportato su questo schema:

 

2) Installazione driver e software X-CTU

Ora che abbiamo tutte le informazioni delle schede possiamo montare la prima schedina e collegare il tutto alla porta USB del computer. Attenzione al senso in cui montate la scheda XBee (il socket permette di inserirla in entrambi i sensi).

Prima di proseguire è necessario che sul computer sia installato il software X-CTU che è possibile scaricare da qui.

Dopo l'installazione può essere necessario scaricare le ultime versioni dei vari firmware delle schede XBee. È possibile effettuare questa operazione manualmente installando soltanto il firmware che ci interessa, ma se avete un po' di pazienza è più semplice attendere che vengano aggiornati tutti i firmware (questa operazione può impiegare parecchi minuti).

La prima volta sarà inoltre necessario scaricare il driver per il lettore di schede, vedi la pagina hardware per i dettagli.

 

 3) Configurare il COORDINATOR

Le due schede vanno configurate in modo differente. La prima scheda va configurata in modalità COORDINATOR.

Avviare X-CTU, scegliere la porta COM e quindi premere il tasto "Test/Query"

Se il baudrate e la porta COM sono corretti, X-CTU mostrerà alcune semplici informazioni riguardanti la scheda come il tipo di modem, la versione del firmware e il numero di serie. Se invece non c'è risposta, conviene provare a selezionare un'altra porta COM e assicurarsi che il baudrate è importato su 9600.
NOTA: il baudrate di default solitamente è 9600, ma se avete in precedenza caricato firmware e importato baudrate differenti è possibile che la scheda non riuscirà a collegarsi, o che vengano visualizzati dei strani valori (sporchi).

Se la comunicazione con la schedina XBee è avvenuta selezionare il tab Modem Configuration, e impostare i dati indicati nell'immagine seguente:

Procedere alla scrittura del firmware premendo il tasto Write.

 

 3) Configurare il ROUTER

Si può chiudere X-CTU, quindi scollegare la porta USB e rimuovere la schedina XBee, inserire quindi l'altra scheda.

Ricollegare l'USB e lanciare di nuovo X-CTU, selezionare la porta COM, (il numero della porta potrebbe essere differente dalla precedente). Eseguire di nuovo il test premendo "Test/Query". Come prima, vengono letti i dati della scheda inserita. Se funziona, possiamo continuare.

Procedere con la configurazione sul tab "Modem Configuration" come indicato nell'immagine seguente:

 

Completare il caricamento del firmware con il tasto Write.

 

Ora entrambi le schede sono configurate e dovrebbero essere in grado di "vedersi" tra loro.

 

4) Testare la comunicazione

Per testare se funzionano, nel mio caso ho provato a montare una scheda su Arduino, l'altra scheda collegarla al computer e quindi aprire un terminale sul PC. Non importa quale schedina viene montata dove, esse sono ora intercambiabili dato che è un collegamento punto-punto. È fondamentale invece che su Arduino stia girando uno scketchin grado di generare dell'output sulla porta seriale in modo che possa essere trasmesso e ricevuto dal terminale aperto su PC.
Siccome ci si potrebbe ingannare, consiglio di scollegare la presa USB da Arduino durante questo test (è necessario alimentarlo esternamente), in modo da assicurarsi che i dati vengano trasferiti wireless (tramite XBee) e non sul cavo USB !

NOTA: Come terminale su PC è possibile utilizzare quello integrato in X-CTU, quello di Realterm, o un qualsiasi terminale (in Windows XP ne esisteva uno integrato che si chiamava Hyperterminal, in Windows 7 non viene più installato di default. Uffa!) 

Ho allegato il backup della configurazione del firmware per le mie schede XBee, eventualmente utilizzare questi files per caricare direttamente la configurazione al posto di doverla importare manualmente. I files vanno rinominati con l'estensione ".pro"

Per il mio progetto mi sono ispirato dal protocollo denominato PlainProtocol descritto in precedenza e ho apportato delle semplificazioni e adattamenti. Ecco i risultati:

La sintassi:

La tramissione dei dati si basa sulle seguenti semplici regole:

• tutti i dati sono trasmessi mediante stringhe di caratteri
• i comandi vengono racchiusi tra "< >"
• il valore è aggiunto immediatamente dopo ">"
• il carattere ";" indica che il messaggio è finito

 

La sintassi è composta nel seguente modo:

<comando1>valore1;<comando2>valore2; ...

 

Ho definito una serie di comandi (generalmente lunghi 3 caratteri) che identificano il tipo di valore che viene trasferito. L'elenco completo è il seguente:

Come si può notare, ho indicato anche la direzione in cui viene trasferito il valore, il range minimo e massimo e l'unità di misura del valore.

 

Come visto in precedenza la costruzione del protocollo può rivelarsi piuttosto articolato, anche perchè ora è arrivato il momento di implementarlo davvero!

Ho incontrato molti problemi nella comunicazione client - server tramite porta seriale, in particolare nella manipolazione dei dati.
Ho trovato sul sito ufficiale di Arduino delle librerie dedicate alla comunicazione tra microcontroller e un host computer.

Protocollo "Firmata"

Firmata sembra proprio essere un protocollo di comunicazione fatto apposta per il mio progetto, il sito ufficiale di questo protocollo offre inoltre una ricca spiegazione di come è strutturato e alcuni esempi pratici che dopo parecchie ore di analisi sono anche riuscito a comprendere !!
 Ho provato gli esempi messi a disposizione ed alcuni esempi sviluppati in Visual Basic .NET che permettono subito di poter avere un ottimo controllo di arduino tramite interfaccia grafica su PC.

La particolarità di questo protocollo è la "leggerezza" ! Sì, infatti è molto ottimizzato in modo da trasferire il minor numero di dati possibile. Offre librerie per poter essere integrate con qualsiasi linguaggio di programmazione.

Questa soluzione è pensata però per comandare e gestire in modo integrale la scheda Arduino mediante host computer. Se invece volete delegare al lato host soltanto alcune logiche e mantenere un firmware "pensante" anche nel microcontrollore (Arduino), allora qui iniziano i primi grattacapi!!

Io ho provato a modificare il protocollo (sia lato Arduino che lato host) in modo da introdurre comandi e variabili specifici per il mio progetto ma ho dovuto abbandonare l'idea dopo parecchie serate di studio e tests.

Ora non voglio entrare troppo nei dettagli sui problemi che ho incontrato, voglio citarne soltanto uno che mi ha fatto piuttosto impazzire! Era una mia esigenza quella di leggere variabili (e non segnali) da Arduino e trasmetterli al computer host.
La computazione di byte e bit è stata una bella complicazione siccome alla base del protocollo il trasferimento su basa su singoli bytes, valori interi più grandi di 255 devono essere gestiti con pacchetti "multi-bytes" per poi essere ricomposti dall'altra parte (in questo caso sul PC).
Dopo numerosi test e tentativi sono riuscito in questo intento, utilizzando appunto il calcolo binario (in Visual Basic ad esempio il simbolo "<<" è il corrispondente della funzione "shift", ovvero la proprietà di spostare a sinistra tutti i bit.

 

Niente di male comunque, questo test mi ha permesso di capire in modo piuttosto approfondito la struttura di questo protocollo e affermare la manipolazione dei flussi di dati binari.

Per chi volesse approfondire questo protocollo suggerisco alcune fonti:

• Pagina principale del protocollo Firmata (Wiki)
• Definizione dei metodi e funzioni della libreria Firmata
• Sito dedicato ad una apposita DLL per l'integrazione con Visual Basic .NET
• Elenco e riferimenti a tutorial per la comunicazione con ogni tipo di linguaggio
• Interessante Tutorial VIDEO in italiano sull'integrazione del firmware Firmata e VB.NET

 

PlainProtocol - un protocollo più semplice da capire

Dopo lunghe peripezie ho quindi deciso di abbandonare il protocollo Firmata, altamente performante e ottimizzato, ma altrettanto complesso e articolato da adattare, e quindi cercare altre soluzioni.

Dopo lunghe ricerche ho finalmente trovato un'idea piuttosto semplice che poteva essere utilizzato per il mio progetto.

Anche questo protocollo è pensato per essere utilizzato per la trasmissione seriale wireless (Zigbee, Wi-Fi, BlueTooth, ...) e ha una sintassi piuttosto semplice.

La struttura originale di questo protocollo è la seguente:

Se volete approfondire questo protocollo, a me hanno aiutato parecchio questi riferimenti:

• PlainProtocol - esempio di implementazione
• PlainProtocol - sorgenti libreria C++

Infine allego i file con la libreria originale e alcuni esempi per arduino.