.: robotitaly.NET :. - la community italiana sulla robotica - Blogs http://www.robot-italy.net/roboforum/blog.php la community italiana sulla robotica http://www.robot-italy.net - robotitaly tutto per la robotica http://www.robot-italy.com it Fri, 18 May 2012 17:42:24 GMT vBulletin 60 http://www.robot-italy.net/roboforum/images/misc/rss.jpg .: robotitaly.NET :. - la community italiana sulla robotica - Blogs http://www.robot-italy.net/roboforum/blog.php Mezzo fiasco http://www.robot-italy.net/roboforum/blog.php?b=157 Sat, 04 Feb 2012 15:55:05 GMT Ho aggiunto un terzo microfono al robottino della entry precedente. (video) (http://youtu.be/62y8SEzdmUk) Guardando le figure allegate, i microfoni... Ho aggiunto un terzo microfono al robottino della entry precedente. (video)
Guardando le figure allegate, i microfoni sono nei vertici A, B, e C di un triangolo equilatero, inteso solidale col robottino, mentre il punto P rappresenta la posizione della sorgente sonora esterna. Il robottino ha il compito di misurare il segmento r, cioè la distanza della sorgente dal centro del triangolo, e l'angolo f, cioè la sua direzione. I segmenti a, b, c, sono le distanze dei singoli microfoni dalla sorgente.
Il microfono che per primo riceve il suono azzera e fa partire un timer, gli altri due invece quando ricevono il suono leggono lo stesso timer. Queste due letture rappresentano le differenze u e v indicate in figura, tenendo anche conto di un fattore di scala che può essere dedotto dalla velocità di propagazione del suono o meglio sperimentalmente.
Conoscendo r ed f è facile calcolare u e v, ma il nostro problema è l'inverso: conosciamo u e v e vogliamo calcolare r ed f. Il relativo sistema di 2 equazioni in 2 incognite non mi pare facile da risolvere e rappresenta l'intersezione fra due iperboli aventi fuochi nei vertici del triangolo ABC. Infatti la figura caratterizzata dalla differenza costante fra le distanze da due punti fissi, è proprio l'iperbole. In pratica, u e v dipendono molto dalla direzione e poco dalla distanza, tanto più se questa è grande. Il programma assegna un valore di primo tentativo alla distanza r, e provando una serie di direzioni f individua quella che consente di calcolare i valori di u e v più vicini a quelli già misurati. A questo punto ha un valore già un po' attendibile per la direzione, quindi con lo stesso metodo affina la distanza, poi daccapo la direzione e così via. Questo procedimento è un caso particolare di algoritmo di discesa dell'errore, cioè una applicazione abbastanza classica. E' chiaro che durante questi calcoli gli interrupt relativi ai motori vengono disabilitati per non sovraccaricare il dsPic. Ho usato il C alla garibaldina, senza conoscere tutto ciò che avviene in memoria nè cosa significhino tutti quei void e tanti file nelle directory, e adesso uso anche il debug di MPLAB che aiuta splendidamente. Per inciso, ho notato che qualche volta il debug confligge con l'ottimizzazione nel senso che mettiamo un breakpoint in una istruzione che non viene risolta dal compilatore. Inoltre, achtung prima di stoppare un micro che comanda delle protezioni.
Il robottino riesce effettivamente a trovare la direzione in modo abbastanza affidabile mentre la distanza invece va un po' a caso. Pertanto il programma effettua diversi controlli e se i conti non tornano regola soltanto la direzione e avanza di pochi centimetri, in attesa di un nuovo suono che possibilmente chiarisca le cose.
L'azionamento 100% DIY è fatto con 2 motori BLDC per elicotterini come nei 2 post precedenti, non perde il passo (se le batterie non sono scariche, ovviamente) e risulta abbastanza preciso considerando che non dispone di adatti riduttori.

MIGLIORAMENTO:
Ho aggiunto una funzione di auto-calibrazione: basta fare due letture in posizioni prestabilite, e il programma ne deduce l'esatta distanza fra i microfoni e l'eventuale ritardo proprio di ciascun microfono. Inoltre ho realizzato un generatore apposito (vedi commenti) ed ho collegato i preamplificatori dei microfoni direttamente agli ingressi digitali di Input Capture. La precisione è migliorata, adesso vorrei riuscire a memorizzare i dati di calibrazione nella flash memory del dsPic.
Icone allegate
Clicca sull'immagine per ingrandirla Nome: Immag0423.jpg Visite: 63 Dimensione: 54.4 KB ID: 226   Clicca sull'immagine per ingrandirla Nome: triang.jpg Visite: 43 Dimensione: 14.9 KB ID: 227   Clicca sull'immagine per ingrandirla Nome: iperboli.JPG Visite: 51 Dimensione: 87.4 KB ID: 229  
]]> Emanuele Terrasi http://www.robot-italy.net/roboforum/blog.php?b=157 Doppio test http://www.robot-italy.net/roboforum/blog.php?b=144 Mon, 16 Jan 2012 10:11:48 GMT Questo robottino che si muove verso la sorgente di un suono, l'ho fatto per 2 scopi:
-Testare l'azionamento BLDC, già discusso nella precedente entry di questo mio stesso blog
-Testare la fattibilità di un sistemino per "Trovare sorgente di un suono", che è anche il titolo di una discussione di Robotica Generale sul Forum.
Per fare 2 conti, 1 ponte trifase per BLDC ha 3 uscite R, S, T, e ognuna può essere commutata verso il + oppure verso il - oppure nessuno dei due pertanto richiede due comandi separati. Quindi, per 2 motori e 2 microfoni ci vogliono 12 pin di uscita per comandare i ponti +2 pin di ingresso per massima corrente +2 pin di uscita per Led di segnalazione +2 pin di ingresso per i microfoni. Il totale è 18 pin di I/O e il dsPic33 li ha, ma c'è dell'altro. Modulare in PulseWidthModulation un ponte trifase non è la stessa cosa che modulare il solito ponte H. Questo usa il pin di Output Compare di un timer, che va On e Off per conto proprio senza impegnare ogni volta il SoftWare. Invece col BLDC bisogna rispettare un ciclo di commutazione in 6 step che fa R+ T-, S+ T-, S+ R-, T+ R-, T+ S-, R+ S-. Esisteranno soluzioni circuitali o MCU apposite (magari proprio dsPic), ma io per adesso so usare soltanto i già detti pin di Digital Output. Per il PWM a 40 kHz ci sono, da gestire in SW, 80 mila interrupt al secondo per le commutazioni OFF-ON, alternandole fra i due motori, e altri 80 mila per le commutazioni OFF. Ciò serve per farli soltanto girare, ma bisogna anche catturare in tempo reale i segnali dei microfoni, misurarne il ritardo, calcolare l'angolo e la distanza della sorgente sonora, calcolare le rampe di accelerazione dei motori e passarle al relativo SW. Insomma ci vorrebbero due dsPic, uno per il controllo motori e l'altro per la localizzazione del suono. Il problema è che io in elettronica sono bravino, un datasheet lo so consultare, un programmino mi piace farlo, sui calcoli ci posso studiare, per la parte realizzativa ci provo, ma tutto ciò che è connettività a qualsiasi livello mi dà le vertigini. Per il momento ho realizzato una versione semplificata: una sola MCU, suono percussivo e netto, niente calcolo della distanza, calcolo approssimativo della direzione, niente frazioni di step, e parte meccanica appena abbozzata.
Per la futura versione con 2 MCU mi rimarrebbe la soluzione estrema di scambiare i dati tramite pin analogici.. magari andrebbe anche bene, ma io conto invece di approfittare per imparare qualcosa sui protocolli di comunicazione e ricevere aiuto dal Forum.
I motori sono Jem RCSystem con alberino da 3 mm e carcassa rotante, c'è qualcuno che mi suggerisca come metterci una idonea trasmissione a ingranaggi? Avendo questa, potrei aggiungere un telaio, una batteria adatta, una regolazione più spinta e sfruttare molto di più la potenza dei motori anzichè puntare tutto sulla leggerezza.
La velocità di rotazione dei motori risulta 4/7 della velocità calcolata del campo rotante, cosa che mi ha sorpreso. Che mi venisse fuori una specie di stepper lo prevedevo, ma pure un motoriduttore...??
Icone allegate
Clicca sull'immagine per ingrandirla Nome: Immag0406.jpg Visite: 47 Dimensione: 69.4 KB ID: 224   Clicca sull'immagine per ingrandirla Nome: Immag0401.jpg Visite: 43 Dimensione: 50.6 KB ID: 225  
]]> Emanuele Terrasi http://www.robot-italy.net/roboforum/blog.php?b=144 Divagazione brushless http://www.robot-italy.net/roboforum/blog.php?b=143 Thu, 22 Dec 2011 08:23:46 GMT L'intento originario di questo esperimento doveva essere quello di realizzare un azionamento di precisione tramite un motore BLDC e non sono sicuro che sia stato raggiunto, ma poichè un certo risultato è stato ottenuto, voglio comunque riferire. Un ponte trifase DIY a Mosfet è pilotato da un dsPic33 con una modalità di controllo semplificata rispetto ai soliti ESC per modellismo. La frequenza di rotazione delle fasi non viene aggiustata in base alle letture istantanee della tensione di ritorno, ma viene data da un timer. E' chiaro che così non si sfrutta appieno il rendimento nè la potenza meccanica che il motore BLDC sarebbe in grado di dare, ma in compenso si può direttamente modulare il timer (quasi) a piacere. Per fare un ipotetico paragone con un motore passo-passo, il motorino BLDC con 12 espansioni avvolte e carcassa rotante lo ho pagato meno di 20 euro. Il ponte trifase ha 6 finali mentre 2 ponti H per stepper a 4 fili dovrebbero averne 8. La alimentazione va bene a 12 V, mentre gli stepper richiedono tensioni più alte. Però il motore BLDC ha avvolgimenti con poche spire, perciò è tassativa una regolazione PWM ad almeno 10 KHz (40 nel mio caso) con una interruzione per massima corrente. Da questo punto di vista l'uso dei Mosfet non è vantaggioso, perchè obbligano ad usare tensioni piuttosto alte per garantire la saturazione mentre in compenso richiedono meno componenti aggiuntivi rispetto ai transistor bipolari ed inoltre non mi hanno dato problemi per quanto riguarda la velocità di commutazione PWM. Metto in rete questo video per mostrare una rampa di accelerazione a partire da velocità bassissima. La coppia risulta decente benchè il sistema sia largamente cautelativo. ]]> Emanuele Terrasi http://www.robot-italy.net/roboforum/blog.php?b=143 Generatore B.F. http://www.robot-italy.net/roboforum/blog.php?b=142 Wed, 07 Dec 2011 21:13:00 GMT *Generatore B.F.* Avevo la necessita’ di creare un generatore di Bassa Frequenza che avesse come uscite sia onde quadre che sinusoidali e... Generatore B.F.

Avevo la necessita’ di creare un generatore di Bassa Frequenza che avesse come uscite sia onde quadre che sinusoidali e triangolari.
L’onda quadra e’ a livello TTL (5volt) mentre la sinusoidale e’ di circa 4vp.p.
Oltre naturalmente a una buona stabilita’ della frequenza generata.
Il pannello che vedete nella Foto1, da l’idea del generatore, dove manca ancora il frontale serigrafato in maniera casalinga che sara’ pronto a breve.
Dopo aver girato su internet e consultato non pochi progetti,l’idea e’ caduta su un integrato della Exar, il xr-2206.
Il c.s. del generatore invece e’ stato creato da una ditta specializzata utilizzando i dati in formato Eagle presenti su un sito internet.
Con l’aiuto alcuni componenti che avevo gia’ in casa che avevo preso, per altri scopi, da Robot Italy ho assemblato il tutto e funziona egregiamente.
Vedi Foto 2 – 3 - 4.
Il picaxe 28x2 e’ sotto utilizzato, ma e’ stato scelto per sviluppi futuri, come la lettura della tensione sinusoidale in uscita e relativa visualizzazione sul display in volt.
L’alimentatore genera due tensioni: la 9volt per il c.s. del generatore e la 5volt per le rimanenti schede ( multifunzione con PICAXE 28x2, servizi 74LS14).
Il display e’ il kit AXE033 della Picaxe pilotato seriale.
Al momento la tensione in uscita segna zero perche’ non ho trovato e provato una interfaccia semplice che mi converta il valore di picco in digitale.
Se avete domande sono qui!
Saluti
Icone allegate
Clicca sull'immagine per ingrandirla Nome: Foto1.jpg Visite: 32 Dimensione: 49.1 KB ID: 220   Clicca sull'immagine per ingrandirla Nome: Foto2.jpg Visite: 31 Dimensione: 93.6 KB ID: 221   Clicca sull'immagine per ingrandirla Nome: Foto3.jpg Visite: 39 Dimensione: 107.6 KB ID: 222   Clicca sull'immagine per ingrandirla Nome: Foto4.jpg Visite: 30 Dimensione: 88.3 KB ID: 223  
]]> egimil http://www.robot-italy.net/roboforum/blog.php?b=142 <![CDATA[Cos'è un'autobalestra?]]> http://www.robot-italy.net/roboforum/blog.php?b=140 Fri, 18 Nov 2011 11:56:13 GMT Provando e riprovando per completare il mio robottino saltatore, come tipo di molla è stata preferita la classica balestra. Un'unica grande balestra reggeva direttamente le componenti meccaniche ed elettroniche senza autotelaio, donde il nome: un'autobalestra, appunto. In una successiva evoluzione il telaio è ricomparso, sotto forma di scheda millefori, ma il nome può restare. La costruzione risulta leggera (250 grammi) e bassa di baricentro, ma pericolosa perchè se si dovesse spaccare la scheda bisognerebbe rimontare t u t t o daccapo. La MCU è dsPic33, forse un po' sprecata ma non troppo perchè fa di tutto: decodifica il radiocomando, gestisce e sorveglia la sequenza di caricamento e sganciamento della balestra, sorveglia la tensione della batteria LiPo, sorveglia la corrente del verricello, gestisce i blocchi per funzionamento irregolare, riceve il finecorsa, dà il PWM ai motori e controlla la velocità tramite le tensioni di ritorno. Quest'ultima funzione non è molto importante perchè il radiocomando, con le correzioni date istintivamente dal pilota, sarebbe già sufficiente per dare una marcia abbastanza regolare, ma in futuro vorrei realizzare qualche tipo di guida autonoma. Un punto debole è la cordicella del verricello che carica la balestra, che potrebbe spezzarsi all'estremità durante lo strappo finale. Ho provato delle cordicelle di sintonia in seta acquistate presso una bottega di radio surplus, o meglio delle tortiglie in nylon acquistate presso un negozio di forniture nautiche, mentre il filo da pesca comune è troppo rigido e non si svolge bene.
Il radiocomando è dell'età della pietra ma dà quello che serve, cioè un paio di canali a pochissimi metri di distanza. In sostanza il pilota deve dirigere il robottino contro l'ostacolo e dare col giusto anticipo una forte accelerata, che è quella che dà il segnale per saltare. L'esito non è garantito ma un certo gusto sì.
Allego una foto di profilo con la balestra scarica, un'altra con la balestra carica ed una foto da sopra, e questo è il video del salto del salsicciotto.
Forse il termine "balestra" non è proprio correttissimo perchè in questo caso le estremità delle due semi-balestre sono collegate fra loro rigidamente anzichè a cerniera?
Icone allegate
Clicca sull'immagine per ingrandirla Nome: Immag0365.jpg Visite: 42 Dimensione: 30.8 KB ID: 217   Clicca sull'immagine per ingrandirla Nome: Immag0366.jpg Visite: 44 Dimensione: 27.8 KB ID: 218   Clicca sull'immagine per ingrandirla Nome: Immag0368.jpg Visite: 51 Dimensione: 47.8 KB ID: 219  
]]> Emanuele Terrasi http://www.robot-italy.net/roboforum/blog.php?b=140 A cosa servono i condensatori di disaccoppiamento http://www.robot-italy.net/roboforum/blog.php?b=135 Wed, 26 Oct 2011 16:37:07 GMT Ottimo tutorial di Bertho sull'utilizzo e lo scopo dei condensatori di disaccoppiamento.

]]> Robotadmin http://www.robot-italy.net/roboforum/blog.php?b=135 <![CDATA[Makerbot Watch & Chronoduino]]> http://www.robot-italy.net/roboforum/blog.php?b=133 Wed, 24 Aug 2011 14:31:18 GMT Un nuovo tipo di gadget si sta affacciando nel mondo elettronico-sperimentale, caratterizzato dall'utilizzo della piattaforma arduino e completamente open source: l'orologio.

Si tratta di orologi molto miniaturizzati, portabilissimi al polso, oltre alle funzioni di base di un normale orologio, sfoggiano sensori di ogni tipo e porte I/O.

Makerbot Watch probabilmente e' stato il primo:

Clicca sull'immagine per ingrandirla Nome: 4155876231_613a825acb.jpg Visite: 201 Dimensione: 151.9 KB ID: 214

Poi e' nato il Chronoduino:

Clicca sull'immagine per ingrandirla Nome: 450px-Lit_up.jpg Visite: 44 Dimensione: 38.3 KB ID: 213

C'e' molta documentazione, ci sono i files Eagle e il codice, mi sembra un ottimo progetto da seguire, implementare e possibilmente collaborare!! ]]> Robotadmin http://www.robot-italy.net/roboforum/blog.php?b=133 Quattro salti in famiglia http://www.robot-italy.net/roboforum/blog.php?b=132 Fri, 22 Jul 2011 08:47:09 GMT Sto facendo un robottino che dovrebbe saltare almeno qualche piccolo ostacolo, e questo è il videoclip (http://www.youtube.com/watch?v=LkCprt2gtPc)... Sto facendo un robottino che dovrebbe saltare almeno qualche piccolo ostacolo, e questo è il videoclip che mostra i primi salti.
Sotto al telaio sono fissate due molle in policarbonato spesso 3mm, mentre il telaio è spesso 4mm e partecipa anche lui in minor misura alla flessione elastica. Due motoriduttori miniatura 150:1, uno anteriore e uno posteriore, fanno da verricelli avvolgendo due cordicelle di seta che caricano le suddette molle. Il collegamento fra l'estremità di ogni cordicella e l'estremità della rispettiva molla, è dato da un sistema magnetico. Quando le molle sono state caricate fino in fondo, appositi interruttori fine-corsa fermano i verricelli. Quando si vuole spiccare il salto, questi interruttori vengono cortocircuitati quindi i verricelli girano ancora e forzando contro i finecorsa superano la forza di attrazione magnetica, a questo punto i magneti si staccano e le molle vengono rilasciate di scatto. Poi i verricelli invertono il moto e riabbassano i magneti affinchè si colleghino nuovamente alle molle. Le molle debbono restare sempre cariche, altrimenti toccherebbero il suolo e impedirebbero l'avanzamento. In sostituzione del suddetto sistema magnetico, ho provato anche un eccentrico con asta di rinvio, che è più efficace ma richiede un motoriduttore con una coppia molto maggiore e quindi necessariamente più pesante. Attualmente il tutto pesa circa mezzo chilo e come HW manca soltanto il circuito radioricevente e/o un futuro sistema di navigazione "da camera". I motori di trazione e le ruote tornite e alleggerite in alluminio sono già presenti anche se non vengono azionati. ]]> Emanuele Terrasi http://www.robot-italy.net/roboforum/blog.php?b=132 Improving the Beginner’s PID http://www.robot-italy.net/roboforum/blog.php?b=131 Thu, 21 Jul 2011 21:19:01 GMT Ecco un interessante tutorial (http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid-introduction/) che prende spunto dalla nuova... Ecco un interessante tutorial che prende spunto dalla nuova libreria PID Arduino.

Clicca sull'immagine per ingrandirla Nome: pidalgorithm.png Visite: 126 Dimensione: 18.1 KB ID: 212

Spiega in modo abbastanza semplice e scorrevole, cos'e' un controllo PID, a cosa serve e come si implementa.

Da leggere sicuramente per chiunque voglia migliorare un controllo motori o anche per qualsiasi applicazione che possa beneficiare di un PID, un line follower ad esempio.... ]]> Robotadmin http://www.robot-italy.net/roboforum/blog.php?b=131 Autodesk 123D http://www.robot-italy.net/roboforum/blog.php?b=130 Mon, 11 Jul 2011 17:52:01 GMT Sulla scia (probabilmente) di Google Sketchup (http://sketchup.google.com/), anche Autodesk (http://www.autodesk.com), il mostro del CAD e della... Sulla scia (probabilmente) di Google Sketchup, anche Autodesk, il mostro del CAD e della modellazione solida, ha reso disponibile una versione gratuita di un software di modellazione solida.

Si tratta di Autodesk 123D, attualmente in versione Beta.

Sono gia' disponibili librerie di oggetti liberamente scaricabili, tutorials e documentazione. Non poteva mancare un Forum dove discutere con altri utenti.

Ovviamente i file generati sono pronti per essere inviati ai vari service per realizzare un oggetto reale!

Diversamente da Google Sketchup, non e' attualmente disponibile una versione per Mac Os.

[youtube]cI45uDbhaFU[/youtube]

Se qualcuno lo prova sono curioso di conoscere le impressioni.... ]]> Robotadmin http://www.robot-italy.net/roboforum/blog.php?b=130 Android e Microcontrollori ... segue http://www.robot-italy.net/roboforum/blog.php?b=129 Sat, 14 May 2011 01:04:05 GMT Non poteva mancare Microchip, con il suo *Accessory Development Kits for Android™... Non poteva mancare Microchip, con il suo Accessory Development Kits for Android™.

Microchip presenta due dev kit, basati rispettivamente su PIC24F (DM240415) e PIC32 (DM320412), il costo delle schede si aggira sugli 80US$ e la libreria software e' scaricabile direttamente dal sito Microchip.

Ora nessuno ha piu' scuse per non sviluppare sotto Android! :D

[youtube]HXhgJvFQ6v8[/youtube]
]]> Robotadmin http://www.robot-italy.net/roboforum/blog.php?b=129 Android e Microcontrollori http://www.robot-italy.net/roboforum/blog.php?b=128 Wed, 11 May 2011 13:19:08 GMT Android e' uno dei sistemi operativi attualmente piu' diffusi nei dispositivi personali portatili (smartphone, tablets, etc), e' molto potente, e' open source e vanta migliaia di applicazioni.

Perche' non sfruttarlo come logica di controllo di alto livello?

Si stanno diffondendo applicazioni per interfacciare un dispositivo android con il mondo esterno. Tutto fa supporre che, nel breve futuro stia nascendo un nuovo modo di pensare un dispositivo embedded.

I costi contenuti, la grande potenza e la relativa semplicita' di programmazione promettono molto bene.

Alcuni esempi:

Android Open Accessory Development Kit

The Android 3.1 platform (also backported to Android 2.3.4) introduces Android Open Accessory support, which allows external USB hardware (an Android USB accessory) to interact with an Android-powered device in a special "accessory" mode. When an Android-powered powered device is in accessory mode, the connected accessory acts as the USB host (powers the bus and enumerates devices) and the Android-powered device acts as the device. Android USB accessories are specifically designed to attach to Android-powered devices and adhere to a simple protocol (Android accessory protocol) that allows them to detect Android-powered devices that support accessory mode. Accessories must also provide 500mA at 5V for charging power. Many previously released Android-powered devices are only capable of acting as a USB device and cannot initiate connections with external USB devices. Android Open Accessory support overcomes this limitation and allows you to build accessories that can interact with an assortment of Android-powered devices by allowing the accessory initiate the connection.

Questo dev kit si interfaccia direttamente con una scheda basata su Arduino:

Clicca sull'immagine per ingrandirla Nome: 20110511ads-300x214.jpg Visite: 57 Dimensione: 20.5 KB ID: 210


Tra poco sara' disponibile la scheda IOIO, è una scheda progettata per lavorare in abbinamento ad un dispositivo (palmare, tablet pc ecc) funzionante con sistema operativo Android (dalla versione 1.5 in su). La scheda viene collegata al dispositivo Android mediante USB. IOIO è interamente pilotabile dalle applicazioni Android utilizzando delle API scritte in Java semplici ed intuitive. Non è necessario un programmatore esterno ne saper programmare per dispositivi embedded, nemmeno per l'aggiornamento del firmware!

Nome: 710585-1.jpg Visite: 334 Grandezza: 8.5 KB

Specifiche tecniche

Dimensioni: 70x30mm
48 I/O in totale. Tutti gli I/O possono funzionare come ingressi o uscite digitali
Fino a 16 ingressi analogici con risoluzione a 10bit (0-1023)
Fino a 9 uscite PWM
Fino a 4 canali UART
Fino a 3 canali SPI
Fino a 3 canali TWI (compatibile I2C)
Regolatore switching on-board ad alta potenza: 5V 1.5A. Può caricare il dispositivo Android e additittura fornire corrente necessaria per una coppia di piccoli motori
Il Bootloader permette di scaricare/caricare nuovo firmware sul dispositivo Android e di eseguire l'aggiornamento firmware della scheda IOIO
Misurazione impulsi e capacitive sensing disponibili con il primo aggiornamento firmware ]]> Robotadmin http://www.robot-italy.net/roboforum/blog.php?b=128 Un balancing a modo mio http://www.robot-italy.net/roboforum/blog.php?b=127 Sun, 08 May 2011 16:05:46 GMT video di un esperimento che ho fatto l'anno scorso. Questa volta non ci sono accelerometri nè giroscopi bensì una rivelazione diretta dell'inclinazione, ed ottenere l'equilibrio risulta più facile. Allego pure il testo del source che è in Basic.
File allegati
Tipo di file: txt Barbie.txt (2.6 KB, 76 visite)
]]> Emanuele Terrasi http://www.robot-italy.net/roboforum/blog.php?b=127 La nota è giusta? http://www.robot-italy.net/roboforum/blog.php?b=126 Mon, 02 May 2011 14:54:36 GMT In questo blog ho mostrato un paio di embrionali realizzazioni nel campo audio, basate sul dsPic33.
Nella scheda rimaneva un po' di spazio vuoto, appositamente lasciato in previsione di altri sviluppi, e questi non si sono fatti attendere.
Infatti mi è capitata l'esigenza di riaccordare una tastiera di violini analogica. Non mi sono neppure chiesto se i normali accordatori per chitarra fossero adatti allo scopo, e sono partito con una nuova realizzazione. Nella scheda erano già presenti due regolatori di tensione, la capsula microfonica, il preamplificatore e 2 Led, mentre ho aggiunto 2 Led rossi pilotati in analogico dalle uscite DAC con relativi trimmer, e diversi interruttori: do - re - mi - fa - sol - si (il la è per default), poi uno per fare i diesis, uno a 3 posizioni per spostare di una ottava in più o in meno, e infine l'interruttore generale.
Il concetto è quello di simulare 2 risonatori, uno sulla frequenza crescente (del 2%) e l'altro sulla frequenza calante rispetto alla nota esatta desiderata. Dal confronto fra le luminosità dei 2 Led analogici, o fra le persistenze dei 2 Led digitali, un operatore appena un po' pratico riesce ad accordare uno strumento (anche la voce) e non escludo che si possa estendere il discorso alle 7 ottave di un pianoforte. Ho fatto diverse prove, squadrando il segnale in software (tanto, quella che importa è solo la intonazione), oppure squadrandolo in hardware con il Comparator Module dello stesso dsPic, e/o rinunziando ai risonatori e misurando la frequenza con un timer tramite l'interrupt di Input Capture (cercando di scansare le complicazioni dell'accodamento FIFO), o anche cercando di sfruttare gli sfasamenti a cavallo della frequenza di risonanza, ma alla fine il metodo migliore rimane quello dei 2 risonatori lineari, con Q=100 o poco più, anche perchè la pratica è più complicata della teoria, e le corde più gravi della chitarra hanno una prevalenza di seconda armonica pertanto le corde medie possono creare della confusione, per non parlare delle voci delle tastiere. Senza andare fuori tema, per eventuali osservazioni o richieste sono a disposizione.
Icone allegate
Clicca sull'immagine per ingrandirla Nome: Immag0244.jpg Visite: 57 Dimensione: 50.0 KB ID: 208  
File allegati
]]> Emanuele Terrasi http://www.robot-italy.net/roboforum/blog.php?b=126 Vi presento Falken : la MuIn USB nella sua estrema semplicità, con panna e ciliegine http://www.robot-italy.net/roboforum/blog.php?b=124 Sat, 16 Apr 2011 15:51:06 GMT Il mio è un progetto abbastanza semplice dal lato "hardware" in quanto si tratta di un robot teleguidato che fa uso della 990.020 MuIn USB con il suo firmware standard. Si tratta quindi "soltanto" di inviare e ricevere comandi alla 990.020.

Scrivere un software lato pc per comandarlo, invece, si è rivelata un'impresa con numerose complicazioni che non mi aspettavo. Passo alla descrizione di tutto il sistema.

Il robot viene teleguidato dal pc utilizzando un software che ho realizzato con VisualStudio che si connette ad un normale gamepad o un joystick analogico a 4 assi per il controllo. Uno stick (X/Y) controlla movimento/velocità robot e un altro (Z/rZ) controlla il pan/tilt della telecamera. Premendo lo stick di controllo della telecamera, gli assi del sistema pan/tilt vengono riportati al centro.

Lo stick di controllo movimento viene sfruttato in maniera "analogica": più si preme più/meno veloce va il robot. Lo stick pan/tilt anche se analogico viene invece sfruttato in maniera digitale incrementando/decrementando dei counter che eseguono l'impostazione dei valori da dare ai servocomandi. Rilasciando lo stick viene eseguito il posizionamento.

La parte difficoltosa è stata quella di elaborare un modello matematico che potesse far corrispondere al valore analogico degli assi X/Y i valori di PWM indipendenti per i due motori. Sfruttando lo stick analogico quindi si puo far ruotare il robot su se stesso, farlo andare avanti indietro dritto o con una virata proporzionale verso destra/sinistra, tutto con regolazione della velocità agendo in maniera indipendente sui due valori di PWM destro/sinistro solo usando lo stick.



Normalmente non vengono mai raggiunti i valori di PWM "estremi" (0 e 1023) che corrispondono ai valori di massima velocità in un verso e massima velocità nel verso opposto (controllo LAP), ma i valori di PWM sono limitati entro un range impostabile in percentuale del valore massimo, in questo modo la dinamica degli assi del joystick viene distribuita su un range di valori di PWM piu ristretto consentendo una precisione di controllo maggiore. Premendo un pulsante sul gamepad si attiva la modalità che permette di usare i valori estremi ed ottenere quindi velocità più elevate.

In un groupbox sono riportate le letture dei 5 canali analogici in forma grafica e in forma numerica. I nomi dei controlli possono essere personalizzati. In aggiunta due strumenti a lancetta, realizzati con la DLL di cui vi ho parlato tempo fa che ho "costruito" con la collaborazione di un ingegnere indiano, riportano in forma grafica i valori di due canali analogici a scelta opportunamente scalati di un fattore impostabile.


Nella mia applicazione uno riporta il valore di tensione della batteria in Volt e l'altro la somma dei valori di assorbimento in Ampere dei due motori.



Clicca sull'immagine per ingrandirla Nome: 0.jpg Visite: 78 Dimensione: 48.2 KB ID: 207

La connessione alla telecamera viene gestita in maniera separata dalla connessione al robot (si puo attivare solo la telecamera, solo il controllo del robot o entrambi) utilizzando una (purtroppo) vecchia DLL di windows (avicap32.dll) per la quale c'è il vantaggio che di esempi in giro ce ne sono a bizzeffe (in realtà è sempre lo stesso, identico, esempio) e mi ha permesso di implementare questo controllo nel software anche senza conoscenze relative alla cattura video, che è un argomento nient'affatto semplice.


Dall'altra parte questa DLL sembra soffrire di problemi su win vista/xp per cui se non si riesce ad avviare l'acquisizione video la prima volta, è necessario chiudere e riaprire il programma fino a che l'acquisizione video non parte. Spero di riuscire a trovare un sistema migliore. Se qualcuno ha esperienza di cattura video in vb.net, mi contatti pure per discuterne e tirare fuori una cosa migliore.

La telecamera purtroppo è una telecamera cinese wireless che avevo tra le mani e ho sfruttato per le prove, quindi portata e qualità sono ai livelli minimi e provvederò più in là a sostituirla con qualcosa di migliore. La cattura video viene eseguita collegando il ricevitore wireless ad una interfaccia USB molto economica ma che devo dire davvero ottima e funzionante alla perfezione (la famosa e pluricollaudata Syntek EasyCap che si trova 10/20 euro). Il controllo via radio viene eseguito con un XBee Pro montato su una 990.002 Xbee USB Board.

Il resto dell'elettronica sul robot, oltre alla MuIN USB, comprende una scheda di alimentazione che provvede alla ricarica della batteria al piombo/gel e alla fornitura delle alimentazioni ai motori, alla MuIN USB, alla telecamera e ai servocomandi. Ogni utilizzatore ha il suo regolatore dedicato.



Questa scheda è possibile realizzarla normalmente su una millefori, io ho preferito il sistema della fotoincisione.


E' quindi presente un ponte H autocostruito basato sul vecchio, caro, L298N ma potete utilizzare un qualsiasi ponte H dotato di controllo LAP e, se volete, anche il segnale di assorbimento dei motori (io consiglio una coppia di H-Bridge Tank-3A HP).


Ho messo nella parte frontale, inclinato a 45° verso il basso, un sensore IR Sharp 2D120X, che uso per rilevare la presenza di eventuali "mancanze" di pavimento (presenza di scalini verso il basso) prima di andarci a finire con le ruote. Il valore del sensore viene riportato su un indicatore analogico nell'interfaccia di comando.

Riguardo alla meccanica, la telecamera è montata sul sistema Pan/Tilt della Lynxmotion, i motori sono una coppia di GH-12 (12V, 200rpm, fin troppo potenti per questa applicazione) e montano le ruote Banebots 73mm 1/2Hex 30A 1W con i relativi mozzi (vi ricordo che per il montaggio è necessaria una chiave esagonale con misura imperiale da 1/16", che non è una misura affatto comune, e una pinza per anelli elastici). I motori sono fissati al telaio usando una coppia di staffe Lynxmotion MMT-02.

Il telaio è realizzato usando due fogli di PVC espanso nero opportunamente sagomati a cerchio usando un normale taglierino e un po' di cartavetrata fine.
A causa del peso dei motori si è rivelato necessario tenerli uniti mediante una piccola sbarra di alluminio opportunamente tagliata e forata, tenuta con due staffette ad L sulle staffe dei motori, altrimenti il telaio tende a piegarsi al centro verso il basso.
E' quindi presente un ruotino pivotante da ferramenta nella parte posteriore del robot. In pratica la struttura è quella classica dei robot explorer, con le ruote posizionate in maniera tale che il robot possa ruotare su se stesso rimanendo fermo nello stesso punto.


A causa della potenza eccessiva dei motori alla massima velocità, e nonostante il peso della batteria piombo/gel posta sul ruotino, il robot tende comunque ad abbassarsi verso l'avanti nelle fasi di accellerazione/decelerazione e sono quindi stato costretto a mettere un ruotino pivotante più piccolo anche davanti.


La soluzione non mi piace affatto e quindi provvederò a realizzare un altro telaio in cui le ruote motrice sono tutte spostate in avanti anzichè al centro. Perdo la possibilità della rotazione sul posto, ma si tratta di un robot teleguidato e quindi non costituisce un problema.



I sistemi sono agganciati al telaio utilizzando un vasto set di distanziatori esagonali di varie lunghezze e viti 3MA.
Sto ancora sperimentando, quando sarà tutto pronto rilascio una versione del software in maniera che chiunque possa usarlo per realizzare il suo robot teleguidato in maniera semplice.


Clicca sull'immagine per ingrandirla Nome: 1.jpg Visite: 79 Dimensione: 135.8 KB ID: 202Clicca sull'immagine per ingrandirla Nome: 2.jpg Visite: 75 Dimensione: 132.7 KB ID: 203Clicca sull'immagine per ingrandirla Nome: 3.jpg Visite: 71 Dimensione: 130.3 KB ID: 204Clicca sull'immagine per ingrandirla Nome: 4.jpg Visite: 76 Dimensione: 131.4 KB ID: 205Clicca sull'immagine per ingrandirla Nome: 5.jpg Visite: 74 Dimensione: 144.2 KB ID: 206 ]]> CyB3rn0id http://www.robot-italy.net/roboforum/blog.php?b=124