Music Fingers

Progetto realizzato da Lista Giuseppe e D’Aniello Simone.

Questo progetto nasce dalla passione maturata per la musica di entrambi gli ideatori,unita a quella per l’informatica e l’elettronica.

Il progetto consiste nel far muovere a tempo di musica dodici dita,collegate ognuna ad ogni nota musicale su una pianola con l’aiuto dei servomotori.

Sotto sono allegate varie immagini con relative descrizioni.

 

SAMSUNG

  •  Una panoramica del materiale usato.

SAMSUNG

  • Per il progetto è indispensabile l’utilizzo della scheda Arduino Uno .

SAMSUNG

  • Le canzoni verranno eseguite tramite la lettura dei file RTTTL salvati all’interno di una micro-sd,che è possibile interfacciare con arduino tramite la shield ethernet/SD.

SAMSUNG

  • Mentre per la visualizzazione e la scelta delle canzoni da riprodurre abbiamo utilizzato la shield LCD DisplayTech 162B.
  • Attraverso la pulsantiera situata sopra di essa si potrà decidere di selezionare la canzone successiva o precedente tra le varie disponibili,mentre il primo tasto corrisponde alla conferma della canzone da riprodurre .

SAMSUNG

  • Qui abbiamo un’immagine che mostra il collegamento tra la breadboard e la scheda-SD21

SAMSUNG

  • Qui invece è raffigurato uno dei dodici servi , i quali permettono il movimento delle dita.

SAMSUNG

  • Inizialmente era una mano completa che poi è stata modificata per ottenere le relative dita mostrate in figura,per eseguire questa procedura è stato utilizzato il software SketchUp ed infine stampate con la stampante 3DRAG.

SAMSUNG

  • Questa è la pianola utilizzata dove suoneranno le dita.

SAMSUNG

 

  • Ed infine un’immagine che sintetizza il progetto.

 D’Aniello Simone e Lista Giuseppe.

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

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