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:

plainProtocol commands v0.72

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.

 

Allegati:
Scarica questo file (Protocoll_command.xlsx)Protocoll_command (Ver. 0.72)[ ]11 kB

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 !!
ArdFirmVB 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.

TestProtocolloSeriale25-05-2013

 

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:

 

icona protocollo

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:

plainProtocol original frame

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

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

 

Una delle funzionalità al quale non sono disposto a rinunciare e la possibilità di ricevere e inviare le informazioni tra l'unità mobile BigWheely e un computer.

schema client server

Ho iniziato a informarmi sulle possibilità e i limiti per la comunicazione client - server, questa parte del progetto è molto importante in quanto sono consapevole dei limiti di calcolo di Arduino e per questo ho pensato che alcune parti di "intelligenza" potrei trasferirla e gestirla nel lato host, in modo da alleggerire i compiti di Arduino.

Per poter risolvere questo problema ci sono principalmente 3 aspetti da risolvere:

  • definire un protocollo di comunicazione
  • sviluppare il software lato client e lato server
  • predisporre l'hardware client / server

 

Quindi prima di lanciarsi alla programmazione spietata era necessario capire quali sono i dati che devono essere trasmessi e ricevuti tra i dispositivi:

schema comunicazione IO r

Il tipo di dati da trasmettere possono essere di tipo unidirezionale, oppure bidirezionale.
Per il tipo unidirezionale, il flusso dei dati percorre sempre lo stesso senso, ad esempio i dati del sensore di distanza sono di tipo unidirezionale in quanto esso trasmette la distanza rilevata, ma non è previsto in alcun modo (e non avrebbe alcun senso) che il sensore riceva dei dati da fonti remote.
Le comunicazioni bidirezionali sono invece previste ad esempio per i segnali di direzione dei motori (DIR), in questo caso la Motor Shield attraverso Arduino può ricevere il comando che definisca la direzione di un motore, ma Arduino ha la possibilità anche di leggerne l'attuale stato e trasmettere questa informazione al lato server.

Dopo aver studiato diverse possibilità di comunicazione e avere individuato quali informazioni sono da trasmettere è necessario definirne anche il tipo.
Teoricamente è possibile ad esempio trasmettere lo stato della direzione di un motore utilizzando un solo bit, il range di valori possibili sono sempre e solo 2 ovvero AVANTI oppure INDIETRO (nel caso del motore per lo sterzo SINISTRA oppure DESTRA).
Per trasmettere invece il valore del sensore di distanze è invece necessario prevedere almeno 2 byte in quanto il range espresso in centimetri può variare da 0 a circa 3-4 metri (dalle specifiche del sensore). Un byte (8 bit) può contenere valori interi che variano da 0 a 255, il rischio di overflow è probabile, per questo motivo è meglio prevedere almeno 2 byte per trasmettere questo valore; in questo caso il range di valori possibili varia da 0 a 255^2 ovvero 65535.

calcolatrice binaria

Un utile strumento per comprendere questi concetti fondamentali è la calcolatrice di Windows, questa utility è spesso sottovalutata ma offre tra le scelte possibili anche la modalità "Programmatore" con la quale è possibile svolgere il calcolo binario o esadecimale.

Basandomi su queste teorie ho provato a buttare giù la struttura di un possibile pacchetto di questo protocollo:

idea protocollo r

Con questa soluzione servono circa 19 bytes per trasmettere tutti i valori. Decisamente pochi !

 

A questo punto basta semplicemente sviluppare il software lato client e lato server !!! Ma questa è un'altra storia!

Software-icon vs hardware-icon

Fino ad ora ho discusso e trattato molto gli aspetti hardware del progetto, ma ora è tempo di iniziare a scrivere qualche riga di codice per far si che l'ammasso di fili che ho creato fino ad ora non rimanga inanimato !

È quindi tempo di affrontare un po' di analisi per capire da che parte cominciare.
L'approcio che ho usato è quello di suddividere il problema o l'obiettivo in pezzi più piccoli più facili da capire e affrontare.

In seguito affronterò piccoli test, tutorial e programmi che mi hanno aiutato a prendere conoscenza dei vari componenti che compongono BigWheely project.

A questo proposito consiglio di approfondire le risorse già presenti sul web, di seguito riporto una selezione decisamente utili e interessanti:

 

 

Ogni componente è stato fissato e i collegamenti sono stati fatti, possiamo ora dare un'occhiata all'intero progetto, ecco alcune foto di come si presenta oggi BigWheely !

IMG 0097 r

IMG 0098 r

IMG 0091 r

IMG 0089 r

Un grande lavoro è stato fatto per arrivare fino a qui, haimè però la strada è ancora lunga, forse l'hardware è anche stato sistemato correttamente, ma ora è necessario dedicarsi al software, molti ostacoli sono ancora alle porte!