Terza settimana

Nella terza settimana abbiamo aiutato i dipendenti in alcuni lavori uno di questi è la costruzione di un retropie cioè di un vecchio cabinato rimodernizzato (http://www.futurashop.it/videogiochi_arcade_7300-RETROPIEKIT?search=retropie).

Per prima cosa abbiamo saldato i vari componenti sulla shield retropie    (http://www.futurashop.it/shield_retropie_per_raspberrypi_FT1199?search=Shield%20RetroPie%20per%20Raspberry%20Pi), in seguito la abbiamo montata sul RaspberryPi e fissata alla base del nostro gioco

Abbiamo poi montato i vari pulsanti e il joystick sul relativo pannello

e di seguito montato gli speaker sulle spalle laterali

Abbiamo fissato gli speaker alla loro base

insieme ai i pulsanti select start, volume  e il pulsante per il credit.

 

Successivamente sono stati realizzati  la maggior parte dei collegamenti interni

In seguito abbiamo montato il display sul supporto e infine collegato con la board raspberry. Anche i tasti di controllo dell’LCD sono stati fissati al relativo pannello.

Dopo tutto questo abbiamo completato il cabinato montando i pannelli mancanti e il risultato è il seguente. Per testare il dispositivo abbiamo “dovuto” provare qualche gioco per testare il dispositivo.

 

WhatsApp-Image-20160609 (4) WhatsApp-Image-20160609 (5) WhatsApp-Image-20160609 (6)

Prima settimana

Salve,siamo Alessandro e Roberto due studenti della classe 4BI e 4AI dell’istituto ISIS C. Facchinetti di Castellanza.
Nel primo giorno il Signor Boris, il nostro tutor, ci ha fatto visitare l’azienda e ci ha presentato ai vari dipendenti.
Successivamente ci ha dato un Arduino UNO e abbiamo iniziato a familiarizzare con i microcontrollori(Link Ardu: http://www.futurashop.it/libro-labc-di-arduino-board-arduino-uno-rev.3-7300-ardukitbook1?search=arduino%20uno).
Per prendere confidenza abbiamo svolto alcuni esempi predisposti sull’ambiente di sviluppo (link ide: https://www.arduino.cc/en/Main/Software).

In seguito abbiamo cercato sul sito http://www.thingiverse.com/ un progetto fattibile con il nostro Arduino, abbiamo trovato il progetto di un braccio che scrive l’ora (http://www.thingiverse.com/thing:248009).
Il nostro obbiettivo però è quello di modificare il programma in modo tale da fargli scrivere anche le lettere.
Durante tutta la settimana abbiamo stampato i pezzi tramite una stampante 3D.
Abbiamo montato i pezzi

IMG-20160610-WA0035 IMG-20160610-WA0031   IMG-20160610-WA0029

In seguito abbiamo montato i servo (link servo: http://www.futurashop.it/sub-micro-servo-9g-22x11x29-mm-7300-servo206) con le corrispondenti braccia.
Abbiamo iniziato la calibrazione delle braccia tramite del codice preso da internet (https://codebender.cc/sketch:80572#Plotclock%20Final%20Calibrate.ino); è stato un lavoro abbastanza lungo in quanto la calibrazione doveva essere al millimetro altrimenti la scrittura sarebbe risultata sbagliata.

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.