Show Posts
Pages: [1]
1  Forum 2005-2010 (read only) / Bugs & Suggestions / A little, annoying Mac interface bug on: December 02, 2008, 04:31:38 am
I'm using Arduino environment on a Mac. On the same Mac I use Win too with both Bootcamp and Fusion, so common files are stored on a FAT partition visible by both OSs.  
When exchanging projects between office and home Mac via a pen-drive, I can see also the (usually)  hidden "._xxx.pde" resources files (see attached).
This also returns a compilation error on that files, I've to manually delete them continuosly through Arduino interface.
Is there a quick workaround?

thanks in advance


2  Forum 2005-2010 (read only) / Development / Re: ArduinoBotics on: December 04, 2008, 05:13:50 am
As promised here I am. This is one picture of my robot using Arduino diecimila as a sensor board:
http://guiott.com/dsNavCon33/ArduRino.jpg

other pictures showing the home made "shield" for Arduino still not populated:
http://www.guiott.com/dsNavCon33/SensorBoard/Overall.jpg
http://www.guiott.com/dsNavCon33/SensorBoard/OverallTop.jpg
http://www.guiott.com/dsNavCon33/SensorBoard/Sensors1.jpg

ciao
Guido
3  Forum 2005-2010 (read only) / Development / Re: ArduinoBotics on: December 02, 2008, 04:30:56 am
This is the first post for me. I'm approching Arduino for an amateur robotics usage too.
My multiusage, multiboard, multi processor "Rino" robot uses Arduino for a Sensor Board that advise Navigation Board on obstacles and target found in the unknown environment.

I'll post some documentation soon.

I'm glad to be here!
4  Forum 2005-2010 (read only) / Italiano / Re: [Progetto comune] - Robotica on: July 08, 2010, 05:01:09 am
Vedo che ti sei perso il mio topic sul tema (l'ultimo è http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1278511477) ... ho trovato un sensore che ha tutti gli ingredienti che servono ed è tutt'ora in commercio ed in libera vendita (anche a privati... )

rimedio subito smiley grazie
5  Forum 2005-2010 (read only) / Italiano / Re: [Progetto comune] - Robotica on: July 08, 2010, 02:07:19 am
ma cosa ne pensate all'uso di un sensore ottico da mouse (con opportuna lente)

Forse varrebbe la pena fare qualche prova, il problema principale è proprio quello di spostare il fuoco a qualche cm invece che a qualche mm come con la lente originale. Strano che ci siano pochissimi utilizzi in Rete.

Non risolverà eventuali problemi di rotazione sull'asse del sensore (cosa che resta anche nel caso di due encoder)

questa non l'ho capita. Con un unico sensore di mouse non saprai mai di quanto ha girato il bot, con due encoder si. Al limite potrebbe essere usato in aggiunta, facendo una sensor fusion tra encoder e telecamerina per capire se le ruote stanno slittando.

I primissimi sensori avevano anche una uscita diretta della telecamerina con la quale si poteva anche vedere l'immagine a bassissima risoluzione. I modelli intermedi avevano l'uscita X-Y che poi veniva codificata nello standard PS2 per il PC. Ora escono direttamente in USB e non è più facilissimo interfacciarli con una MCU.
6  Forum 2005-2010 (read only) / Italiano / Re: [Progetto comune] - Robotica on: June 30, 2010, 08:47:58 am
se si inclina troppo, l'algo rinuncia al bilanciamento e "spegne" i motori


con conseguente craniata del passeggero? smiley

E pensare che quello usa diversi accelerometri e giroscopi.
7  Forum 2005-2010 (read only) / Italiano / Re: [Progetto comune] - Robotica on: June 30, 2010, 07:19:29 am
Sono la persona meno adatta, non sono mai salito su una moto smiley
Scherzi a parte, secondo me si può anche fare senza muovere un peso, però devi sapere con una buona precisione tutto quello che succede. Come hai detto anche tu, i sensori IR ti fanno stare sempre parallelo al terreno, che non è necessariamente la stessa cosa di stare dritto.
Con un accelerometro puoi bilanciare il tutto, quando freni si inclina automaticamente indietro per compensare la decelerazione, a lui interessa che la somma vettoriale sia = 0. Se si aggiunge il vettore della decelerazione, si inclina per avere  il vettore risultante sempre rivolto verso il centro della terra. Che è poi quello che fa il motociclista con il suo senso dell'equilibrio e i sensori vestibolari.
Questo in teoria, non ho la pratica necessaria per capire quanti accelerometri servono e/o se ci vogliono anche dei giroscopi.
Segaway docet:
http://www.segway.it/default.aspx?tabid=120
8  Forum 2005-2010 (read only) / Italiano / Re: [Progetto comune] - Robotica on: June 29, 2010, 03:03:41 am
Per farlo utilizza due semplicissimi sensori Sharp, che in realtà non sono esattamente studiati per rilevare cosi' brevi distanze (in teoria sono utilizzati per range da 50 a 3cm io li uso tra a 3 e 0 ), ma sembrano fare decisamente bene il loro lavoro

Complimenti per il lavoro. La capacità di fare cose semplici, ben documentate, alla portata di tutti e che funzionano anche bene non è una cosa banale.

Volevo solo chiarire un attimo il discorso degli Sharp. Non è una magia il fatto che funzionino anche da 0 a 3cm.

Se guardate a pag.9 di questo documento, potete vedere la curva di risposta dei sensori.

http://www.acroname.com/robotics/parts/GP2D120_SS.pdf

Sotto la distanza minima dichiarata il comportamento semplicemente si inverte.

Usandoli nel modo giusto, considerando che la tensione di uscita aumenta all'aumentare della distanza, invece che diminuire come nel range di misura di funzionamento normale, funzionano anche abbastanza linearmente. Tenendo conto che tu li stai usando non come misura assoluta ma relativa tra i due, è una furbata niente male.

Attenzione però che vanno usati esattamente esattamente in quel range, diverso da modello a modello come si può vedere in questo documento:

http://www.acroname.com/robotics/info/articles/sharp/sharp.html

Se analizzi la curva sul documento precedente infatti, puoi vedere che non c'è modo di capire se la distanza è, ad esempio, di 2 o di 5cm. La tensione di uscita è la stessa. Quindi: o sei sicuro che la distanza misurata è tra 0 e 3cm o sei sicuro che è tra 3 e 50cm. Non puoi usarli, ad esempio, tra 0 e 10cm.
9  Forum 2005-2010 (read only) / Italiano / Re: [Progetto comune] - Robotica on: March 29, 2010, 01:18:53 am
Per il caster, un'ottima soluzione, se c'è spazio, è quella di usare una omniwheel:
http://www.trossenrobotics.com/store/p/3126-VEX-Omni-Wheel.aspx
http://www.acroname.com/robotics/info/ideas/omnimod/omni_mod.html
http://www.robotexp.com/products/list.asp?id=89
http://sketchup.google.com/3dwarehouse/details?mid=2dc47cfe2678b166ae3f90abcf68560b

io, per questioni di spazio, ho usato un classico caster a sfera:
http://www.robot-italy.com/advanced_search_result.php?search_in_description=1&keywords=ruote&osCsid=b7ea64f9dc42dac485dc0465f4fe7d32&x=0&y=0

da 19mm. Li ho provati entrambi, in plastica e in metallo. Quello in metallo è ottimo per la sfera ma si consuma il supporto. Quello in plastica è ottimo il supporto ma si consuma la sfera. In conclusione: sto usando la sfera in metallo sul supporto per la sfera in plastica (che ha i rullini). Sembra funzionare bene e si consuma poco.

I motori vanno scelti anche in funzione dell'encoder che possono montare.
Per i servi a rotazione continua, ad esempio, si può usare anche questo:
http://www.acroname.com/robotics/parts/R239-WW01.html
10  Forum 2005-2010 (read only) / Italiano / Re: [Progetto comune] - Robotica on: March 17, 2010, 11:30:23 am
Bellissimo! La suddivisione di più task a diversi gruppi di lavoro è molto interessante, ognuno farebbe la parte che gli piace di più.

Bisogna solo definire molto bene il colloquio tra le varie schede prima di partire. Fino a 2 va benissimo la classica seriale, anche a livello TTL. Oltre bisogna usare altri sistemi. Un sistema valido potrebbe essere un collegamento tramite RS485 o I2C. l'RS485 richiederebbe l'aggiunta di un driver in più per ogni scheda ma a quel punto si possono mettere quante schede si vuole e a qualsiasi distanza, poi si vede come una normale seriale. Con l'I2C si possono sfruttare tutte le librerie esistenti e senza aggiunta di HW, però si è più limitati sulla distanza (non è un problema su un robot) e sul numero massimo di device.

Sarebbero entrambi protocolli master/slave, quindi va definito un master che si occupi della supervisione (sconsiglio, almeno per ora, il multimaster). La cosa si complica un po' per la scheda sensori, che già avrebbe diversi dispositivi I2C da gestire come master. Bisogna verificarne la possibile convivenza, oppure usare una scheda con 2 I2C in HW, oppure usare un I2C HW e uno SW in modo che la scheda sia master verso i sensori e slave verso il supervisore.

Insisto sul definire molto bene questo punto, il resto viene poi con il tempo.
11  Forum 2005-2010 (read only) / Italiano / Re: [Progetto comune] - Robotica on: March 17, 2010, 10:17:59 am
Per il controllo di velocità tramite encoder e PID non vedo grossi problemi con un architettura anche a 8bit. Il problema è più che altro la velocità di elaborazione o meglio, la capacità di gestire gli impulsi dagli encoder. Lo avevo già fatto con una MCU a 8 bit PIC18F (http://www.guiott.com/PID/index.html) gestendo ad interrupt i due encoder ricavati dalle rotelle dei mouse, quindi con meno risoluzione rispetto agli encoder che uso ora. Il vantaggio con il dsPIC33F è la presenza di due moduli QEI (quadrature encoder interface) che fanno già gran parte del lavoro in HW.

Ti devi fare bene i conti per i tuoi encoder, magari segui questa traccia:
http://www.guiott.com/dino/swmovimento.html
per capire se hai risorse a sufficienza, ad occhio dovresti farcela.

L'unico dubbio che ho è sulla scrittura del SW, non sono sicuro che basti usare il Wiring per realizzare una cosa del genere. Ho paura che ti debba gestire le cose a livello un po' più basso, ma è solo una sensazione, non conosco così bene gli Atmel, io avevo fatto tutto in C sul PIC, ottimizzando tutto, anche il flow del programma usando una specie di RTOS personalizzato.

Per quanto riguarda l'odometria invece serve un po' più di matematica, e una MCU a 16bit potrebbe fare la differenza.

All'epoca di Dino avevo cominciato a studiare le librerie Cordic per calcolare seni e coseni con gli interi ottimizzando al massimo i calcoli (http://www.guiott.com/dino/swdivide.html), poi ho deviato per la soluzione più facile con un PIC con core DSP che non ha grossi problemi nei calcoli anche di float.
Con un po' di applicazione non dovrebbe essere impossibile, non credo però che basti una sola scheda per controllo velocità, PID, odometria e navigazione.

ciao

P.S.
Scusate se cito così spesso pagine del mio sito, ma ci ho speso molto tempo e li ci sono tutti i miei appunti, credo possano essere utili senza che mi metto a ripetere gli stessi concetti.

12  Forum 2005-2010 (read only) / Italiano / Re: [Progetto comune] - Robotica on: March 17, 2010, 08:41:07 am
Compatibilmente con il poco tempo libero che ho a disposizione, partecipo volentieri a questa discussione, se posso essere utile...

un po' di esperienza sul dead reckoning l'ho fatta anche se, come dicevo in una altro forum, sono passato al lato oscuro della forza ed ho usato un dsPIC per fare tutta la navigazione smiley
L'Arduino mi piace moltissimo come concetto e l'ho usato per la scheda sensori. Ho usato anche Processing per la console di telemetria. Non sono davvero un esperto ma qualcosa so.

Sicuramente una sola scheda non basta. Mi sembra molto corretto l'approccio che state seguendo di separare il progetto in problemi più piccoli. Vi racconto un po' quale è stato il mio iter, non è detto che sia il migliore, ma almeno è una traccia.

Risolto il problema della meccanica, per prima cosa ho affrontato la lettura della velocità tramite gli encoder. Poi mi sono preoccupato di impostare e mantenere la velocità delle ruote per far andare dritto il robot tramite controllo PID. Poi l'odometria e la parte matematica per calcolare la posizione corrente. Poi ho studiato un protocollo di comunicazione tra le schede e verso il PC per la telemetria. Poi la scheda sensori per capire l'ambiente che circonda il robot e mappare gli ostacoli. Ultimamente mi sono occupato molto della taratura dei parametri meccanici in vista delle prossime gare RTC che vorremmo fare (chi sa se ci riusciamo?) con risultati decenti (http://www.guiott.com/Rino/RinoUMBmark.htm). Il prossimo passo che devo affrontare è l'obstacle avoidance, ho studiato un mucchio di teoria, mi manca di metterla in pratica.

Vabbeh... per questo primo post mi sono dilungato anche troppo.
Pages: [1]