Volevo una fresa a controllo, mi serviva per cominciare a capire il mondo del 3D, ma quella parte di mondo che va al di là delle stamapanti treddì che lavorano con una tecnica detta "additiva", ovvero aggiungengdo materiale, dove questo materiale sia ABS o PLA entramvi materiali troppo deboli per i miei scopi. Io voglio modellare il legno, il metallo e se un giorno dovesse essere necessario i sassi.
Quindi mi metto in cerca di una fresa, chiedo un pochino in giro e risponde all'appello l'unico dei miei amici che ci capisce qualcosa; Matteo.
Vado a trovarlo a The FabLab e mi recupero 9iin prestito questa piccola fresa giocattolo, una Roland mdx 20, taglia circa 20x30x6, poca roba ma almeno mi serve a capire come funziona e quali siano le potenzialità di una fresa con soli tre assi.
Grande fatica per connetterla al pc, serve un adattatore per la sua porta seriale, scopro con l'aiuto del Gavez che un adattatore qualunque Seriale/Usb non funziona, ci vuole un tipo particolare di adattatore FTDI, lo stesso che usa Arduino per intenderci.
Disinstallo quindi Arduino, tutti i driver e collego l'adattatore, sì perché ci vogliono i driver proprietari di Roland da installare, ci perdo dietro qualche ora e mollo il colpo.
Non c'è verso. Alla fine recupero un vecchio portaile, mezzo scassato, ma con almeno la seriale funzionante. Installo tutto il software Roland, driver compresi, collego il cavo ed ecco fatto; funziona tutto al primo colpo.
Traffico un pochino e poi comincio ad occuparmi dell'hardware, manca un mandrino e alla macchina serve un pochino di pulizia e manutenzione.
Dopo varie prove e tentativi decido per una scelta drastica; smonto il suo motore per la parte del taglio e lo sostituisco con una torretta fatta a posta, da me a mano, per alloggiare il Dremel ed ecco che cambia tutto: utensili in widia a 30.000 giri, ergo posso tagliare tutto.
Con questa piccola fresa posso sicuramente crearmi in casa, in pochi minuti, complicati pcb; posso intagliare scritte su qualunque oggetto di qualsiasi materiale, sagomare fogli di materiale plastico e legno compensato... insomma, devo solo capire bene il disegno 3D perché vorrei proseguire col creare qualche oggetto meccanico ricavato dal pieno (avete presente con la moto che razza di divertimento?!?)
ficco qualche foto qui sotto, poi implemento il post
Versione attuale, in soggiorno perché porca puttana non ho più un laboratorio mio dove lavorare (in attesa della costruzione del nuovo spazio).
Impiega un po' di più ad avviarsi ma poi va tranquillamente!
Ma non potevi usare una distro live?
no, in questo caso ubuntu è proprio installato, ha il suo terminale, i suoi software etc... tutto il lavoro resta salvato, così come le impostazioni etc, è proprio come avere una partizione sul pc, perché in fin dei conti è esattamente così che stanno le cose! ;)
Bon, ti porti sempre dietro il "tuo pc" su chiavetta, dove serve la inserisci in una porta, riavvii e ti trovi a casa.
Come si installa?
Normalmente, con un altro ubuntu ed il programma unetbootin crei un avviabile, tipo una chiavetta, poi la metti in qualunque pc e fai partire il boot da questa. Dal momento in cui si avvia la live non resta che installare il sistema operativo nel disco che, precedentemente formattato, abbiamo predisposto: la chiavetta usb!
Ho acquistato il connettore bluetooth. ELM327, il solito insomma, funziona.
Cosa fa?
Intanto stiamo parlando di un arnese che si collega alla macchina, più precisamente al connettore che va alla centralina, da questa riceve alcune informazioni.
Associando il connettore al proprio smartphone Android per esempio, dopo aver scaricato una App (come Torque per intenderci) , questo risulta essere in grado di restituire alcune importanti informazioni dalla centralina dell'automobile... ad esempio la temperatura del liquido di raffreddamento, la pressione e la temperatura dell'olio, i gas di scarico, le prestazioni del motore, la presenza di allarmi vari e tra questi la possibilità di cancellare gli allarmi inerenti il motore, ad esempio.
Dua informazioni più dettagliate le trovate su wikipedia QUI,
oppure un articolo interessante, che riporto in parte in seguito, lo trovate QUI
CAN (Controller Area Network) e OBD-II (On Board Diagnostics) sono due standard di comunicazione (il termine corretto sarebbe "protocolli di comunicazione"). Le centraline dell'automobile che rispettano questi standard parlano tutte la stessa lingua e quindi possono comunicare tra di loro. La comunicazione avviene attraverso una sorta di "linea telefonica" che tecnicamente si chiama "bus".
Nella pratica, il bus non è altro che una coppia di fili che passa da una centralina all'altra, proprio come la linea telefonica passa di casa in casa formando una lunga catena. Anche il motivo del nome "bus" è molto semplice: esso è il "mezzo di trasporto" per i dati: li porta da una centralina all'altra, un po' come un vero bus porta le persone da una fermata all'altra.
Una cosa fondamentale è distinguere i ruoli dei due protocolli CAN e OBD-II. Il CAN definisce un generico standard di comunicazione tramite bus: permette a due o più dispositivi elettronici di scambiarsi dei dati inviandoli e ricevendoli sotto forma di messaggi. In pratica grazie al CAN una centralina A è in grado di inviare dati ad una centralina B, ma questo da solo non basta a realizzare la comunicazione: occorre anche che la centralina B sia in grado di riconoscere ed utilizzare i dati ricevuti, è necessario cioè che le due centraline "parlino la stessa lingua". A questo ci pensa l'OBD-II che definisce una sorta di linguaggio con cui le varie centraline possono finalmente comunicare.
Facciamo un esempio pratico:
La centralina di controllo del motore rileva che il motore è a 2500 giri/minuto
La centralina inserisce tale informazione in un messaggio conforme al protocollo OBD-II
Grazie al protocollo CAN la centralina trasmette il messaggio per mezzo del bus
La centralina di controllo del quadro strumenti, anch'essa collegata al bus, rileva il messaggio
Grazie all'OBD-II la centralina è in grado di comprendere il contenuto del messaggio: "motore a 2500 giri/minuto"
La centralina reagisce spostando l'indicatore del contagiri su 2500 giri/minuto.
Una cosa che può trarre in inganno quando si studiano CAN e OBD-II è che entrambi definiscono una struttura specifica per i loro messaggi e questo può confondere il lettore. Grazie all'esempio precedente abbiamo capito che i due messaggi si fondono l'uno nell'altro: prima viene creato il messaggio OBD-II, dopo di che tale messaggio diventa il contenuto del messaggio CAN che viene inviato sul bus. La centralina che riceve il messaggio CAN fa il processo inverso: elabora il messaggio CAN estraendone il messaggio OBD-II originale e lo processa.
CAN
Come detto in precedenza, il protocollo CAN definisce il linguaggio che le varie centraline devono usare per comunicare tra di loro tramite il bus. Siccome i due elementi sono strettamente legati si parla spesso di "CAN bus", Infatti il bus di per se è un normalissimo paio di fili che passa di centralina in centralina, è solo grazie alle regole definite dal CAN che le centraline sono in grado di utilizzare il bus come un potente ed affidabile mezzo di comunicazione.
Il protocollo CAN è molto generico: definisce solo il metodo e le regole per l'invio e la ricezione di dati usando il bus, ma non dice nulla in merito ai dati che devono essere scambiati, al loro formato ecc. Per questo motivo il CAN non viene impiegato esclusivamente nei mezzi di trasporto, ma per esempio anche in macchinari industriali.
In passato alcune case automobilistiche utilizzavano protocolli diversi dal CAN. L'OBD-II invece è uno standard pressoché unico che è diventato obbligatorio sulle automobili a partire dal 1996. Per questo motivo si possono trovare automobili le cui centraline comunicano secondo il protocollo OBD-II, ma si scambiano i messaggi sul bus usando un protocollo che non è il CAN.
Per come è studiato il CAN, quando una centralina invia un messaggio sul bus tale messaggio viene ricevuto da tutte le altre centraline collegate, ogni singola centralina poi analizza il messaggio e decide se è di suo interesse (e in tal caso lo processa) oppure no (in tal caso semplicemente lo ignora).
Abbiamo detto in precedenza che il bus è una sorta di linea telefonica attraverso la quale le centraline dell'auto comunicano tra di loro. Ebbene è molto semplice aggiungere una nuova centralina e farla comunicare con le altre: basta "allacciare" anch'essa alla linea telefonica, ovvero collegarla ai fili del bus. Una volta collegata la nuova centralina comincerà a ricevere tutti i messaggi delle altre centraline (decidendo quali le interessano e quali no) e potrà trasmettere i propri.
Il lettore di questo documento potrebbe voler collegare un'interfaccia OBD-II alla propria auto ed usarla per ricevere dei dati relativi allo stato del veicolo; ebbene quando l'interfaccia OBD-II è inserita, essa è semplicemente collegata al CAN bus come tutte le altre centraline, ed è così in grado di fare sostanzialmente due cose:
"ascoltare" in maniera passiva tutti i messaggi che le centraline inviano sul bus e trasmetterli al computer (o altro dispositivo) dell'utente.
dialogare attivamente con le centraline, richiedendo dei dati e trasmettendo al computer dell'utente le risposte ricevute.
Per quanto riguarda il secondo punto occorre fare una precisazione per comprendere il potenziale rischio della comunicazione tramite CAN bus: il dialogo con le centraline spesso ha lo scopo di richiedere informazioni, ma non dobbiamo dimenticare che allo stesso modo è possibile inviare dei comandi che hanno l'effetto di modificare dei parametri di funzionamento. È consigliabile quindi limitarsi ad inviare i messaggi di cui si conosce l'effetto, perché messaggi diversi potrebbero alterare il funzionamento dell'auto e ciò può costituire un pericolo.
OBD-II
Il protocollo OBD-II è più specifico del CAN ed è nato espressamente come standard per i mezzi di trasporto, è diventato obbligatorio in America nei veicoli prodotti a partire dal 1996. La versione europea di questo standard si chiama EOBD, esso è sostanzialmente identico all'OBD-II ed è obbligatorio dal 2001.
Quanto ho scritto fin qui dell'OBD-II non è completo: l'OBD-II non è solo uno standard di comunicazione, in particolare definisce anche il connettore che deve essere presente nell'abitacolo del veicolo per il collegamento degli strumenti OBD-II compatibili. Tale connettore è sostanzialmente una porta di collegamento al bus CAN (o altro bus presente sul veicolo). Quando a questo connettore viene collegato uno strumento con interfaccia OBD-II esso viene praticamente collegato al bus CAN ed è quindi in grado di ascoltare e comunicare con le centraline come ho spiegato nel capitolo relativo al CAN.
Il connettore OBD-II prevede anche una linea che fornisce energia al dispositivo collegato. È importante sapere che il connettore fornisce sempre energia, anche quando il veicolo è spento. Se uno strumento viene lasciato collegato al veicolo per troppo tempo a motore spento, questo potrebbe facilmente scaricarne la batteria (il dispositivo potrebbe anche consumare poca energia, ma la sua attività sul bus potrebbe "tenere sveglie" varie centraline provocando un consumo di energia elevato). Per questi motivi è importante che i dispositivi OBD-II usati quotidianamente abbiano un buon sistema di risparmio energetico, altrimenti l'utente sarà costretto a scollegarli dopo ogni utilizzo per preservare la carica della batteria dell'auto.
Infine lo standard OBD-II definisce anche alcuni comandi per la richiesta delle informazioni principali relative al veicolo. Tutti i veicoli dovrebbero supportare tali comandi, ma in realtà non è obbligatorio.
la cosa che mi chiedo ora è "ma se posso cancellare un dato, posso anche scriverlo?"
Adoperando un makeymakey ho progettato per i colleghi un controlller per videogame molto elaborato;
Adoperando come si vede dal filmato uno sgabello Ikea con due pulsanti bticino avvitati male sotto comando gli spostamenti destra/sinistra del coniglio drogato, il tubo di alluminio che reggo nella mano sinistra serve, picchiandolo verso l'alto, a far saltare il coniglio per evitare le siringhe tossiche, ovviamente la lampada da scrivania lancia le carote.
Cos'è un makeymakey? nient'altro che un arduino Leonardo leggermente pimpato, lo colleghi al pc e toccando con le mani i contatti invii tramite seriale dei comandi semplici al pc (tipo i tasti "asdf" "space bar" oppure le freccette o i comandi mouse).
Il monitor LCD del vostro computer funziona più o meno così
C'è una illuminazione omogenea sul fondo, questa luce viene polarizzata (da un POLARIZZATORE) per passare poi attraverso i cristalli liquidi ed infine in un polarizzatore opposto al primo. I cristalli liquidi non fanno altro che variare la polarizzazione del fascio luminoso in relazione alla quantità di tensione applicata. Posso quindi decidere che un pixel sia più o meno luminoso in base a quanto "inclino" il cristallo liquido che gli sta davanti. Ora è facile intuire che così abbiamo costruito un bel sistema a scala di grigi. E per fare i colori? Semplice, si aggiungono dei pixel con un filtro colorato RGB e per ognuno di questi filtri regolo l'intensità luminosa miscelandoli e componendo i vari colori.
Di seguito un filmato in cui due persone adulte si divertono davvero con poco
Ok, e sticazzi? Come funziona il monitor "Cieco"?
A quasto vecchio monitor ho fatto una piccola modifica, l'ho smontato tutto ed ho rimosso l'ultimo filtro polarizzatore. così il fascio luminoso passa sempre tutto attraverso lo schermo, risultato? Schermo tutto bianco. Ma se adesso, alla fine di questo processo incompleto, aggiungo un polarizzatore per esempio di un paio di occhiali da sole cosa accade? Accade che per magia le immagini compaiono nuovamente e perfettamente nitide!
Battue a parte...
sto progettando un dispositivo che comanderà un videoplayer in base alle informazioni ricevute da più emettitori infrarossi, un telecomando al contrario insomma.
Quindi ecco che comincio a capire come funzioni un telecomando "normale".
Le librerie IR per Arduino IRremote le trovate QUI, ovviamente dovete impazzire per caricarle, un giorno scriverò due righe in merito...
Per quanto riguarda lo schema elettrico ho adoperato come ricevitore IR uno di quegli extender per i tv (il più del lavoro è stato individuare i pin giusti...), va bene qualunque ricevitore Infrarossi a tre pin, se volete saperne di più cliccate QUI.
Poi ho collegato i tre Led alle prime tre uscite non PWM, ho messo una resistenza a casaccio come al solito ed il gioco è fatto. Ho caricato lo sketch, che trovate in fondo, ho aperto il monitor seriale ed ho letto i valori dei primi tre tasti di un telecomando Samsung per poterli riportare correttamente nel programmino. A quasto punto, avendo associato ad ogni pulsante l'accensione di un led, non restava che fare il test, lo trovate in questo filmato, non male come inizio!
#include <IRremote.h>
int RECV_PIN = 3; // il pin del ricevitore
int led1 = 2;
int led2 = 4;
int led3 = 7;
int itsONled[] = {0,0,0,0};
/* the initial state of LEDs is OFF (zero)
the first zero must remain zero but you can
change the others to 1's if you want a certain
led to light when the board is powered */
#define code1 55848 // codice primo pulsante
#define code2 26210 // codice secondo pulsante
#define code3 2500 // codice terzo pulsante
void loop() {
if (irrecv.decode(&results)) {
unsigned int value = results.value;
switch(value) {
case code1:
if(itsONled[1] == 1) { // if first led is on then
digitalWrite(led1, LOW); // turn it off when button is pressed
itsONled[1] = 0; // and set its state as off
} else { // else if first led is off
digitalWrite(led1, HIGH); // turn it on when the button is pressed
itsONled[1] = 1; // and set its state as on
}
break;
case code2:
if(itsONled[2] == 1) {
digitalWrite(led2, LOW);
itsONled[2] = 0;
} else {
digitalWrite(led2, HIGH);
itsONled[2] = 1;
}
break;
case code3:
if(itsONled[3] == 1) {
digitalWrite(led3, LOW);
itsONled[3] = 0;
} else {
digitalWrite(led3, HIGH);
itsONled[3] = 1;
}
break;
}
Serial.println(value);
irrecv.resume(); // Receive the next value
}
}
Cara Lady Ada, amore segreto della mia vita, stavolta ho vinto io! ;)
Mi sembrava fosse davvero impossibile che la Waveshield di Adafruit non fosse in nessun modo compatibile con Arduino Mega 2560, Ho cercato qui e la su internet ed ho trovato delle immagini che ritraevano i due dispositivi felicemente accoppiati. Dopo aver spulciato un altro po' il mondo dell' Internet scopro che forse ci vogliono delle altre librerie, prendo le Wave HC originali, le modifico un po', le carico e niente, non funziona,
Mi prodigo in un'attività di " Rubber Ducking" (come a lui piace chiamarla ) con Dario, risulta che la soluzione non si trova nel software, altrimenti lui lo saprebbe, giuro.
Niente la soluzione è hardware, c'è un problema con le porte SPI, sul Mega sono diverse!!
Allora via i piedi dalla shield e faccio un nuovo "connettore" che collegherà il
pin della shield con quello del Mega
10 ................. 53
11 ................. 50
12 ................. 51
13 ................. 52
Di seguito riporto la tabella SPI da Arduino Reference
Arduino Board
MOSI
MISO
SCK
SS (slave)
SS (master)
Uno or Duemilanove
11 or ICSP-4
12 or ICSP-1
13 or ICSP-3
10
-
Mega1280 or Mega2560
51 or ICSP-4
50 or ICSP-1
52 or ICSP-3
53
-
Leonardo
ICSP-4
ICSP-1
ICSP-3
-
-
Due
ICSP-4
ICSP-1
ICSP-3
-
4, 10, 52
Qui sotto pubblico qualche foto del lavoro degno del MerdLab, con lo spostamento dei collegamenti dei pin ed il relativo connettore adattatore.
Allora innanzitutto vedendo il filmato si comincia a capire di cosa si stia parlando. Il programmetto l'ho trovato QUI, Le librerie per Arduino le trovate QUI, La sezione di pitches da aggiungere come nuova tab (per esempio) la trovate QUI. Cos'altro?
"Non è che c'è tanto da vedere, con uno stile di led così belli come vedete qua c'è uno stile di programma del genere può accompagnare solo."
La vicenda vede come protagonisti questi cinque led rgb, 4 piedi ognuno, due dei quali - quelli più interni - fanno l'alimentazione (anodo e catodo segnati come al solito) quelli esterni si occupano del comando seriale, nella foto qui sotto si capisce bene anche il collegamento. Ad ogni led, in qualunque momento, può essere assegnato un colore ed una intensità indipendentemente dagli altri. Bella figata.
La Vodafone resta l'unico operatore ad aver mantenuto questa politica, il pagamento del servizio di "Tethering" non includendolo nelle offerte internet.
due righe da wikipedia in merito le trovate QUI
Come fare quindi per non pagare a parte il traffico dati quando si adopera il tethering vodafone?
La risposta è semplicissima e si riassume in pochi passi ( di seguito le immagini passo passo prese dal mio samsung s4, per tutti gli altri telefoni android sarà comunque molto simile) :
Ovviamente entriamo nel menù impostazioni, selezioniamo la voce "altre reti"
Allinterno del menù "Altre reti" selezionare la voce "Reti mobili"
In "Reti mobili" selezionare "Profili"
Ed Ecco che qui si compie la magia: All'interno della voce "Tethering Internet" sarà sufficiente sostituire la vecchia voce "web.omnitel.it" con "mobile.vodafone.it"
lo scorso anno mi sono cimentato in una divertente attività con l'oscilloscopio, per il periodo natalizio avevo fatto un addobbo particolare che trovate QUI!
quest'anno avendo qualche difficoltà a riprodurre l'esperimento mi sono messo a studiare e sono andato un po' oltre, e ho fatto questo:
Il circuito è lo stesso del progetto analogo dello scorso anno
Per poter disegnare e scrivere sono necessari dei punti X Y, potete trovare questi punti da dare in pasto all'oscilloscopio tramite arduino utilizzando un semplice programma che trovate QUI!
Come programmare un Attiny 85 lo potete scoprire QUI
L'attino ha un pallino, quello è il pin numero 1, gli altri pin fino al numero 8 si contano in senso antiorario. Lo schema è così composto:
pin 4 gnd
pin 8 vcc
pin 6 spk
come speaker ho adoperato un comune piezo elettrico
l'alimentazione è a 3 Volt con una 2032
lo scketch che ho caricato sull'attiny è questo qui sotto,
(come sempre prima sparare il bootloade, se restituisce errore riprovare all'inifinito, l'attino è impostato a 8mega)
___________________________________________________________
const int Note_C = 239;
const int Note_CS = 225;
const int Note_D = 213;
const int Note_DS = 201;
const int Note_E = 190;
const int Note_F = 179;
const int Note_FS = 169;
const int Note_G = 159;
const int Note_GS = 150;
const int Note_A = 142;
const int Note_AS = 134;
const int Note_B = 127;
int Speaker = 1;
void setup()
{
pinMode(Speaker, OUTPUT);
}
void loop()
{
playTune();
delay(10000);
}
void TinyTone(unsigned char divisor, unsigned char octave, unsigned long duration)
{
// TCCR1 = 0x90 | (8-octave); // for 1MHz clock
TCCR1 = 0x90 | (11-octave); // for 8MHz clock
OCR1C = divisor-1; // set the OCR
delay(duration);
TCCR1 = 0x90; // stop the counter
}
Per muovere un servomotore ci vuole una libreria apposta per Attiny, la Softwareservo.h,
per la programmazione dell'Attiny vi rimando qui.
Lo schema qui sotto:
POV: Persistence of Vision
è quel fenomeno per cui, se vi sventolate una mano davanti alla faccia, vedete un sacco di dita...
lo state facendo adesso vero?
sfruttando questo fenomeno possiamo per esempio riprodurre dei caratteri grafici componendoli "una colonna alla volta" e spostandoci poi di un'altra colonna...
Chi fa questa cosa? Questo arnese qui:
Da sinistra: le batterie (3V sono sufficienti) l'interruttore, l'attiny 85 e i 5 led collegati.
che post di merda che sto scrivendo.
La scritta "Ciao belli!" manca la lettera C, c'era un piccolo bug risolto...
Questo è lo schema, sotto aggiungo il codice. ciao, arrangiatevi.
