Controllo con microSD

In contemporanea al progetto del WiFi mi è stato suggerito di portarne avanti un altro ovvero programmare le azioni dei dispositivi DMX attraverso un file salvato su una microSD che sarà alloggiata nell’apposito spazio.

Per poter programmare le azioni dei faretti bisogna scrivere le istruzioni secondo un particolare protocollo inventato da me, che  ricorda molto l’XML, quindi si tratta di un linguaggio di markup che basta salvare su un normale file di testo (.txt) e lasciare l’interpretazione al software.

All’interno del file è possibile inserire solamente tre tipi di istruzioni:                                      -L’istruzione per assegnare un valore a un determinato canale:            <_[numero_canale]>[valore]</_[numero_canale]>                                                 Esempio: se voglio dare il valore 200 al canale 3 scriverò nel file: <_3>200</_3> 

-L’istruzione per la pausa, ovvero per mantenere i dispositivi nel loro attuale stato per un determinato tempo.                                                                                                           <_p>[tempo in millisecondi]</_p>                                                                            Esempio: se voglio una pausa di 3 secondi scriverò <_p>3000</_p>

-L’istruzione per ripetere il ciclo di comandi, da porre eventualmente come ultima istruzione.                                                                                                                          <_r></_r>                                                                                                                 Esempio: …[istruzioni precedenti] <_r></_r>;      

Inoltre per consentire la corretta esecuzione bisogna ricordarsi anche alcuni piccoli accorgimenti ovvero:                                                                                                                -su ogni riga si deve scrivere una sola istruzione                                                             -non si devono inserire spazi                                                                                               -al termine dell’ultima riga bisogna inserire il ‘ ; ‘ (punto e virgola) per segnare la fine del file

Ricordo inoltre che il linguaggio è interpretato quindi in caso di errore sintattico, questo non verrà segnalato.

Gps e SD: salvare le coordinate

Come primo passo per realizzare un datalogger mi sono concentrato sul gps ( 8160-EM406A) e salvare le coordinate che esso scarica con le relative informazioni sulla SD card attraverso la SD-Shield ( 7300-GPSSHIELD ).

Prima di tutto mi sono informato sul protocollo di comunicazione utilizzato dal gps, ovvero NMEA. Una celere spiegazione su wikipedia.

 

Per controllare il gps da Arduino bisogna scaricare la libreria TinyGPS.h e studiando un attimo lo sketch di esempio risulta molto semplice il suo utilizzo.

Ci si è posti poi il problema di ogni quanto salvare la coordinata utile a costruire il nostro itinerario finale. Utilizziamo cosi una semplice formula matematica (Pitagora) per calcolare la distanza che vi è tra un punto ed un altro.

d = \sqrt{(x_0 - x_1)^2 + (y_0 - y_1)^2}

Il nostro sketch presentarà quindi le seguenti righe di codice:

rad1 = (previous_flat-flat);
rad1 = pow(rad1,2);
rad2 = (previous_flon-flon);
rad2 = pow(rad2,2);
result = sqrt(rad1+rad2);

previous_flat rappresenta la coordinata precedentemente salvata e flat la coordinata in cui ci si trova al momento. Il discorso è analogo per flon e previous_flon.

Provandolo poi in macchina si è impostata una distanza di 200m circa, pari ad un result=0.00100. Se si ottiene questo valore allora si salva la coordinata sulla SD in un file prova.txt.

myFile=SD.open(“prova.txt”,FILE_WRITE);

myFile.print(flat,5) // il 5 indica il numero di decimali da salvare

myFile.print(flon,5)

myFile.close();

Come lavoro finale mi viene anche chiesto di presentare nell’itinerario il segnapunto con una descrizione contenente orario e data del salvataggio.

Lo sketch lo posterò a lavoro concluso o a fine stage.

Il prossimo passo è studiare il formato kml e gpx per ricreare un itinerario, l’utilizzo di un accelerometro per capire quando si è in movimento ed la produzione del file .kml o .gpx.

Nel prossimo articolo metterò la struttura già trovata dei file e spiegherò i problemi riscontrati fino ad ora.

Quella che pensavo fosse la parte più semplice ( produzione file kml o gpx ) si rivelerà la più difficile e tutt’ora irrisolta.

Daniele Ruffo

Controllo da WiFi

A seguito dei problemi rilevati con la gestione del ricevitore IR ho deciso che il controllo del faro verrà effettuato attraverso una connessione WiFi con Arduino di modo che possa essere controllato sia mediante PC ma anche con qualunque dispositivo che possa connettersi WiFi e che disponga di un browser per la navigazione in Internet, l’unica restrizione è data dal fatto che il dispositivo deve essere connesso alla stessa rete WiFi a cui è connesso Arduino.

Il principio di funzionamento è molto semplice: su Arduino verrà montata una shield WiFi alla quale sarà possibile connettersi dal browser inserendo l’indirizzo IP della shield, successivamente la shield provvederà ad inviare una pagina web che permetterà all’utente di inviare i comandi ad Arduino che a sua volta li inoltrerà al alla shield DMX la quale farà variare lo stato del faretto.

Per cominciare ho iniziato con fare diverse prove sulla shield WiFi come inviare una pagina HTML e usare il metodo GET per passare le informazioni da elaborare.

Purtroppo, giunto il momento di implementare le istruzioni per il controllo del segnale DMX, la shield WiFi smette di funzionare, infatti non viene inviata la pagina web che dovrebbe servire da interfaccia per l’utente, al momento sono alla ricerca di una soluzione.

Claudio Rossi

Watchdog

Molti microcontrollori integrano il sistema denominato watchdog al fine di controllare il programma caricato al suo interno. Esso, infatti, ha il compito di monitorare l’esecuzione del programma e di riavviare il microcontrollore nel momento in cui si verifichino blocchi o loop infiniti.

Di default tale funzionalità è disabilitata poiché si tiene conto del fatto che il programmatore preveda, durante la stesura del codice, la prevenzione di eventuali blocchi o loop infiniti. Spesso però ci si trova in situazioni per cui il nostro programma vada in situazioni di stallo durante l’attesa di eventi esterni che noi non possiamo prevedere o controllare. Proprio per questo ci viene incontro il watchdog

Vediamo come è possibile utilizzarlo all’interno del nostro sketch da caricare su arduino.

Prima di tutto includiamo la libreria #include <avr/wtd.h>.

Nel setup dovremo inizializzare il nostro watchdog attraverso l’istruzione

wdt enable(Parola Chiave);

Questa parola chiave è definita in base al tempo che riteniamo necessario, assunta dalla tabella seguente:

 

Tempo reset Parola Chiave
15mS WDTO_15MS
30mS WDTO_30MS
60mS WDTO_60MS
120mS WDTO_120MS
250mS WDTO_250MS
500mS WDTO_500MS
1S WDTO_1S
2S WDTO_2S
4S WDTO_4S
8S WDTO_8S

 

Supponiamo quindi di impostare il nostro watchdog con l’istruzione

wdt enable(WDTO_4S);

questo significa che se entro 4 secondi non resettiamo il conteggio del watchdog, esso eseguirà automaticamente il reset della cpu.
Per resettarlo impieghiamo la seguente funzione:

wdt reset();

 

Supponiamo ora di avere le seguenti istruzioni all’interno del nostro loop():

void loop(){

delay(3000);

Serial.println(“Ciao”);

wdt reset();

}

In questa situazione il watchdog non riavvierà mai Arduino in quanto passeranno solo 3 secondi prima che venga effettuato un reset.

Supponendo invece di avere l’istruzione delay(5000); al posto del delay(3000); . Di fatto non vedremo mai su seriale stampato il Ciao poichè non andremo mai oltre al delay.

Il funzionamento del watchdog in definitiva è molto semplice e intuibile e soprattutto utile nel momento in cui vogliamo essere sicuri che una determinata istruzione o blocco di istruzioni vengano eseguiti nel tempo preimpostato del watchdog.

Daniele Ruffo

Wifishield: utilizzo del modulo wifi e sd in contemporanea

La shield  8190-WIFI_SHIELD di  Futura Elettronica mette a disposizione assime al modulo wifi una slot per MicroSD, proprio come le recenti ethernet shield (7300-SHIELDETHERNET). Così  come per la ethernet anche per la wifi bisogna prendere degli accorgimenti nell’utilizzare questi due in contemporanea dato che entrambe utilizzano la stessa linea di comunicazione ICPS. Per fare ciò, quindi, bisogna disabilitare la comunicazione sullo stesso bus nel momento in cui uno dei due deve trasferire qualcosa. Questa mutua esclusione viene data dal chip select il quale, lavorando in logica negativa per entrambe, mandato alto disabilita la comunicazione. Per la MicroSD si tratta del pin 4 mentre per il modulo wifi si tratta del pin 10 ( per l’arduno Mega è il pin 52 ). Si tratta di un’operazione relativamente semplice che consiste nell’inserire queste semplice istruzioni nel setup: pinMode(10, OUTPUT);         // Impostare il pin SS come output indispensabile)  digitalWrite(10, HIGH);                          // Disabilito il modulo wifi alla comunicazione

Gli esempi di libreria della SD card sono molto chiari e semplici da capire. Il suo utilizzo non è complesso. Per avvicinarci all’applicazione del datalogger fingiamo di leggere dei valori totalmente casuali da uno dei pin analogigi e scriviamo tale valore in un file all’interno della SD. Qui lo sketch per tale operazione. Ora la pubblicazione di questi dati in una ipotetica pagina web, implementando all’esempio il discorso precedentemente fatto sull’esclusione del modulo sarebbe fattibile ma ecco arrivare un problema piuttosto difficile da risolvere . La libreria WiServer.h della wifishield sviluppata da asynclabs, non prevedeva la lo slot per l’SD card e di conseguenza utilizza probabilmente dei pin essenziali, rendendo così l’utilizzo della SD impossibile. Ci basta includere la libreria perchè lo sketch non funzioni. Testandolo ulteriormente proviamo ad includere la Ethernet.h ( che lavora esattamente con la logica qui descritta ) e con questa nesssun problema. Si evince quindi che il problema deriva dalla libreria della wifishield, scritta senza un minimo di documentazione esterna e quindi difficile trovare il punto da correggere. Si è pensato di conseguenza di proseguire appoggiandosi ad altre memorie su schede esterne  che vedremo in futuro.

Daniele Ruffo

 

DMX e Ricevitore IR

Bene, eccoci qua, sono Claudio Rossi e sono uno studente, ho appena concluso il quarto anno di studi all’ISIS Facchinetti di Castellanza, corso d’informatica.

Al momento sto affrontando un periodo di 3 settimane di stage presso la Futura Elettronica  di Gallarate.

In queste tre settimane dovrò portare avanti un progetto che consiste nello sviluppo di un software che attraverso l’utilizzo di un prototipo di shield DMX  e di Arduino dovrà gestire il funzionamento di un faretto a led.

Per chi non lo sapesse, il DMX è un particolare protocollo per la gestione dell’illuminazione di scena. (Per maggiori informazioni visitate la relativa pagina di Wikipedia)

Dal momento che è la prima volta con cui ho a che fare con Arduino, ho trascorso il primo giorno per capirne le funzionalità di base facendo alcune prove basilari.

Il secondo giorno ho cominciato a lavorare sulla shield che si occupa di gestire il segnale DMX in uscita, subito si è presentato un problema, infatti la shield non inviava alcun segnale e di conseguenza il faro rimaneva spento. Dopo molti tentativi sono riuscito a rilevare la fonte del problema che stava tutto in un integrato difettoso che non convertiva il segnale digitale in segnale DMX.

N.B. La shield DMX da me usata non è ancora in commercio, essa è solamente un prototipo realizzato dalla Futura Elettronica, e a differenza delle normali shield DMX, su questa è stato integrato un ricevitore Infrarossi.

Dopo aver risolto il primo problema ho iniziato ad affrontare il problema di come usare il ricevitore IR per controllare la shield attraverso un comune telecomando universale. Ma anche in questo caso i problemi non hanno tardato ad arrivare infatti inizialmente il ricevitore non interpretava a dovere i segnali, la soluzione stava nel cambiare la posizione del jumper che determina quale pin usare per prelevare il segnale IR.

Successivamente quando ho iniziato a unire i progetti con l’intento di comandare il faro con il telecomando, è risultato che nè il ricevitore IR ne il faro davano segni di vita, quindi facendo delle ricerche su internet, ho scoperto che le due librerie che gestiscono rispettivamente il ricevitore e la shield DMX entrano in conflitto in quanto entrambi usano lo stesso timer per il conteggio del tempo trascorso, purtroppo questo problema non ha ancora trovato una soluzione e per questo mi vedo costretto ad abbandonare l’idea.

Nei prossimi interventi spiegherò come ho deciso di modificare il progetto.

 

 

WiFi shield e riconnessione alla rete

Scusate il ritardo ma il lavoro di certo qui non manca 😉
Prima di tutto mi presento. Mi chiamo Ruffo Daniele e vengo dall’ ISIS Facchinetti di Castellanza ( 4 anno ).

 

Preciso che sono già stato stagista presso Futura Elettronica assieme al mio compagno Speroni Manuel ed abbiamo realizzato un robot LineFollower per permettere all’istituto di partecipare alla robocup. Il robot è attualmente a scuola ed utilizzato da dei ragazzi di 5 come progetto per la maturità. Spero di avere la possibilità di rendervi partecipi di quel progetto non appena mi ricapita sotto le mani. ( Se lo ritrovo, pubblico il video di prova effettuato durante uno dei vari test)

 

Quest’anno invece mi è stato proposto un lavoro di diverso tipo:
Prima di tutto trovare una soluzione ad un problema riscontrato nella nuova WifiShield ( 8190-WIFI_SHIELD ), ovvero ritrovare e riccolegarsi alla rete in caso di perdita del segnale ( derivante da una caduta di rete, spegnimento del modem, perdita del segnale, caduta di corrente o qualsivoglia tipo di situazione).

Risolto questo problema sviluppare diverse applicazioni utilizzando questa shield.

 

Come primo passo aggiorniamo l’idee di Arduino alla versione 1.0.1  ( qui il link per la pagina del download ) e riscontriamo il primo problema.
Alcune delle vecchie librerie sembrerebbero non funzionare su questa nuova versione per cui un consiglio che posso darvi per
N.B. Ci tengo a precisare che tale operazione non risolve il problema per tutte le librerie !!tentare di risolvere questo problema consiste nel aprire il .h che avete incluso e controllare che non ci siano istruzioni del tipo:
#include <wire.h>
In tal caso sostituendole con #include <Arduino.h> dovrebbe risolvere il problema.

Ora scarichiamo la libreria per il  WifiShield ed ecco che purtroppo sorgono ulteriori e gravosi problemi. Purtroppo questa libreria risente di diverse limitazioni, ecco il motivo per cui mi sono permesso di apportare delle modifiche ( Il perchè viene spiegato in seguito ).
Qui il link per il download della libreria aggiornata.

Per la ricerca del problema si è utilizzato uno sketch di esempio, atto a scaricare dei valori

da un sito francese(CO2 presente nell’aria) ed accendere delle lampade di un intensità

pari al valore letto.


Download
sketch di esempio

 

.
Da qui si inizia la ricerca del problema riconnesione wifi. Come prima soluzione si è pensato di effettuare un reset di arduino via software utilizzando una funazione che punta all’indirizzo 0.

void(* Riavvia)(void) = 0;

Questo riavvia appunto arduino e quindi lo sketch ritenta la connessione attraverso l’istruzione nel setup “WiServer.init(NULL);” . I problemi però non sono del tutto risolti utilizzando questo metodo poichè se la rete ritorna in tempi molto brevi la connessione risulta possibile, se però i tempi sono lunghi lo sketch si impalla sull’istruzione di inizializzazione appena citata . Ecco che entra in gioco la modifica apportata alla libreria.
Ad essa, infatti, sono stati aggiunti dei metodi che permettano la connessione asincrona di arduino, permettendo così allo sketch di non bloccarsi durante il tentativo ( sia esito positivo o negativo che sia ) di connessione.

WiServer.async_init(sendMyPage, NULL);

Anche questo presenta degli svantaggi ma non del tutto impossibili da ovviare. Il difetto principale è che anch’esso non riesce a collegarsi se la rete ritorna ad essere disponibile dopo tempi lunghi e a volte dopo una riconnessione parte dopo molto a scaricare gli eventuali dati dal sito richiesto. Di conseguenza si è trovato una via di mezzo tra queste due soluzioni per ovviare qualsivoglia tipo di problema ( mostrerò dopo il codice e la spiegazione di questa soluzione ). Come ultimo tentativo di soluzione si è provato a collegare il pin di reset del modulo wifi ad un pin di arduino per mandarlo basso (lavora in logica negativa) e vedere se la riconnessione era possibile attraverso il suo riavvio.Si è constatato che questo metodo porta gli stessi svantaggi dei metodi precedenti se non in aggiunta una modifica hardware allo shield.

Si è anche guardato un possibile utilizzo del watchdog ma essendo risultato inutile rimando la spiegazione a questo articolo di cosa consiste.

 

Ora la soluzione trovata è stata idealizzata pensando allo sviluppo di un datalogger ma può benissimo essere modificata per le proprie esigenze. Nella spegazione seguente non mi riferisco al datalogger ma semplicemente alla riconnessione dopo una perdita della rete.

Nel setup è stata sostituita l’istruzione WiServer.init(NULL); con questo ciclo ( si suppone che nel monento in cui avvio lo sketch  sono in presenza del wifi, altrimenti va modificata la partenza ) :

while(!WiServer.connection_up()){           
    WiServer.async_init(sendMyPage, NULL);     
if(WiServer.connection_up())
        WiServer.init(NULL);
    }

Finchè non mi collego veramente, tento la connessione attraverso il metodo asincrono async_init(sendaMyPage, NULL) così da evitare un eventuale blocco dello sketch derivante dalla init(NULL). Per ovviare la possibilità che avvenga la connessione attraverso tale metodo ma che non parti immediatamente il downliad effettuo una init(NULL) essendo sicuro che la connessione esiste davvero e che non si bloccherà lo sketch.

Nel loop(), nel momento in cui viene a mancare il segnale, si ha questo tipo di controllo:

if(!WiServer.connection_up()) {
    int i;
    for(i=0;i<300 && !WiServer.connection_up();i++){
        Serial.println(“Cerco di ricollegarmi”);
        server_up = WiServer.async_init(sendMyPage, NULL);
        delay(1000);
        Serial.println(i);
      }
   if(WiServer.connection_up() || i==300){
       Serial.println(“Riavvio i=” +i);
       delay(1000);
       Riavvia();}
}

Il ciclo for prosegue finchè o non trovo la connessione e quindi posso ricollegarmi ( viene effettuato un riavvio software precedentemente citato così da riportarsi nel setup ed escludere tutti i problemi ) oppure se sono passati 5 minuti.

Il riavvio effettuato dopo il passaggio dei 5 minuti ci solleva dal problema della connessione che ritorna dopo un tempo lungo ( o che non torna proprio). In sintesi se io provo a collegarmi ma la rete torna dopo molto che io proseguo con questi tentativi il modulo non riesce in ogni caso a collegarsi. Per effetto del riavvio, invece, il modulo torna ad essere in grado di effettuare un collegamento.

Qui il download dello sketch di esempio modificato in modo tale da presentare le diverse opzioni possibili per la connessione alla rete caduta. Spero sia abbastanza chiara.

Nel caso di un datalogger l’operazione di connessione e upload dei dati salvati su un sito viene effettuato solo nel momento in cui un eventuale sensore di movimento ci avvisa che siamo fermi. La ricerca della rete wifi continua finchè il movimento non riparte oppure finchè non mi collego veramente.

Ai prossimi articoli la spiegazione dei problemi e delle scelte effettuate per lo sviluppo di un datalogger.

 

 

Daniele Ruffo