Telemetria
Parliamo di collegamenti tra computer e MCU, non mi interessano i computer a bordo dei robot.
Una soluzione piuttosto semplice potrebbe essere un bluetooth direct replacement dell'XBee.
Quasi tutti i sistemi operativi (tranne l'iOS di iPhone e iPad) hanno il profilo SPP (Serial Port Profile) nello stack bluetooth. Quindi, quando si fa il pairing con questo dispositivo, viene visto come una porta seriale virtuale ed è usabile esattamente come un XBee per fare un cable replacement.
Il protocollo Zigbee è nato proprio come concorrente al BlueTooth per dispositivi semplici e che devono consumare poco (sensori autoalimentati o cose del genere) mentre il BT ha molte più possibilità ma consuma molto in termini di risorse computazionali e di energia.
Usandolo con un computer già dotato di BT, costa meno che la somma di due moduli XBee + l'adattatore USB per il computer + cavo, e non si hanno cavi penzoloni.
Non l'ho mai usato e non so quali possano essere i problemi e le performances. Se qualcuno lo conosce... si faccia avanti.
Come dicevo non è però compatibile con l'iOS e quindi ho cercato qualcos'altro che, a parte la mia fissa di questo periodo per l'iPad, potrebbe essere interessante anche per altre applicazioni: il WiFi. Ripeto, non parlo di access point, schede ethernet e protocollo TCP/IP che potrebbe avere un mini computer, parlo di qualcosa di molto più piccolo, che consuma poco e sia collegabile ad una MCU.
Riporto i risultati di un po' di prove. Me lo hanno fatto vedere in un ottica un po' più completa, immaginando possibili soluzioni che vanno ben oltre la semplice telemetria.
Partiamo dai livelli più bassi della pila ISO-OSI.
Il modulo parla in 802.11 b/g quindi può unirsi ad una rete anche a 54Mbps senza costringere gli altri ad abbassarsi alla sua velocità.In un collegamento ad-hoc (punto punto) probabilmente vale la pena di selezionare una velocità inferiore (si può scendere anche ad 1Mbps) per aumentare l'immunità ai disturbi e, di fatto, aumentare la portata.
Io l'ho usato solo in seriale (RX-TX TTL 3.3V) ma funziona anche in SPI. La velocità di trasferimento effettiva ancora non l'ho capita. Sullo stesso manuale trovi a volte "up to 1Mbps" e a volte "Improved performance of the UART receiver. UART is now reliable at up to 460Kpbs with RTS flow control".
Per ora l'ho solo collegato in seriale tramite un USB adapter per cominciare la configurazione:
Non pensate di farci streaming video a velocità normale. L'uscita è comunque seriale ed un throughput di 1Mbps è già difficile da raggiungere, anche se il "coso" viaggia in 802.11 g.
Funziona benissimo il DHCP, in alternativa si può mettere l'IP fisso. Ha anche un IP di backup se non trova la prima lan in un tempo prefissato.
Saliamo ancora nella pila. Ho provato i protocolli Telnet, HTTP, NTP, e FTP.
Attenzione, accetta un'unica connessione per volta, non pensate di usare il terminale in Telnet mentre colloquiate in HTTP, ha una sola seriale.
In Telnet riporta pari pari quello che passa sulla seriale in entrambi i versi. Il traffico può essere ottimizzato incapsulando i singoli byte in pacchetti secondo diverse logiche: carattere terminatore, lunghezza prefissata, timeout di inattività.
Funziona da server HTTP nel senso che accetta il protocollo e riporta tutto sulla seriale, non si può metterci dentro una pagina in HTML. Per fortuna ho trovato un esempio sul (solito) sito Arduino, dal manuale non si capiva niente, se cerchi qualcosa di strano... c'è sicuramente qualcuno che lo ha fatto con un'Arduino. Con le keyword "Arduino e WiFly" su Google si apre un mondo. Ho aperto una connessione dal browser, ho ricevuto tutte le info sulla seriale, dalla seriale ho fatto un upload di una pagina HTML e il browser l'ha visualizzata correttamente. Deve essere l'MCU alla quale è collegato a fornire le pagine o i dati HTML.
Funziona anche da client HTTP, si possono memorizzare, ad esempio, delle query verso siti noti per catturare alcuni valori e riportarli sulla seriale. In maniera completamente autonoma, anche senza MCU, può riportare ad intervalli prefissati lo stato dei suoi input digitali e analogici verso un web server.
Ha un RTC (Real Time Clock) interno, sincronizzabile con un server NTP. Tutte le info sono poi recuperabili dalla seriale con una sintassi molto semplice.
L'FTP serve solamente per scaricare il firmware nella sua flash, ci ho provato a passare dei file miei ma mi hanno solo occupato memoria senza possibilità ne di vederli ne di cancellarli.
La modalità comando può essere avviata sia dalla seriale che dalla rete tramite Telnet.
Veniamo all'HW. Ha diversi pin GPIO, alcuni sono usati per pilotare i LED di segnalazione, altri possono essere letti (digitali e analogici) e i loro valori riportati come ho già detto. Mettendo a GND o a V+ alcuni pin si può farlo partire in modalità network o ad-hoc oppure selezionare alcune modalità di partenza. Alcuni pin sono selezionabili come input o come output. I pin dei led di segnalazione possono essere letti per sapere in HW lo stato della connessione. I pin analogici usano una Vref interna di 1.2V.
Consuma 40mA in RX e 140mA in Tx. Può essere messo in sleep a 4uA con diverse possibilità di auto-wakeup (tempo, seriale, input su pin). Per andare in sleep deve essere usato PER FORZA un protocollo senza connessione come l'UDP.
Il manuale è pessimo. Mancano alcune info, alcune sono date per scontate e per capirci qualcosa bisogna scorrerlo tutto avanti e indietro mille volte, saltando da una parte all'altra.
Realizzare le connessioni tramite WiFly, alza sicuramente il costo rispetto ad una rete di XBee. Neanche per una connessione uno ad uno forse vale la pena, a meno che non si debba collegare con un iPad/iPhone oppure non si vogliano cavi penzolanti, ma allora esiste anche il più economico bluetooth.
Ci possono però essere moltre altre applicazioni possibili. Uno sciame di robot o una gara di calcio robotico nella quale tutti parlano con tutti (credo che Nao già lo faccia). E' sicuramente più facile fare una rete WiFi che una rete XBee (sempre tralasciando i costi).
Un robot che si muove all'interno di una fabbrica, è molto semplice, e magari è già presente per altre ragioni, fare una rete WiFi con dei normali acces point e comandare da qualsiasi parte il mezzo con un computer, un terminale mobile, un PDA, un netbook, un Nintendo DS, un ....
Andando oltre i robot. Un terminalino stand-alone con una piccola MCU ed un display che prende informazioni direttamente da internet (orario, tempo, temperatura, traffico, RSS, borsa, etc.) e le visualizza.
Oppure le info le prende da un sito personale con quello che si vuole.
Queste sono solo le prime cose che mi vengono in mente, di spazio per la fantasia ce n'è molto.