Si beh, effettivamente l'unica utilità sarebbe quella di riuscire a farlo funzionare!
L'unica cosa utile è che la struttura e il concetto di fondo del codice sarebbero le stesse...per le mie capacità è più fattibile e potrei contribuire, mentre il progettone "aspirapolvere" lo seguirei comunque ma sarei più passivo.
Dico questo perchè non credo che tutte le 11 persone che hanno votato robotica al poll e che vorrebbero partecipare attivamente al progetto abbiano capacità di modellizzazione e creazione di algoritmi complessi.
mi ricordo che per far esaminare uno spazio a un robot si doveva fargli fare delle specie di chiocciole quadrate sul terreno... ora non ricordo se sta tecnica ha un nome però potrete evitare particolari algoritmi...
Il sistema di mappatura potrebbe essere valido anche per altri tipi di robot, non solo per gli aspirapolveri
Potrebbe essere interessante anche, prima della mappatura, scrivere un sistema veramente efficace di navigazione e decisione via sonar + servo motore. Due componenti che e' sempre figo avere e che se devi muovere un robot ti fanno comodo.
da quello che ho capito possiamo usare delle matrici ma occupano un sacco di mem e operazioni/secondo, oppure algoritmi un po' piu' complessi ma leggeri da far girare
Dico questo perchè non credo che tutte le 11 persone che hanno votato robotica al poll e che vorrebbero partecipare attivamente al progetto abbiano capacità di modellizzazione e creazione di algoritmi complessi.
io arrivo a malapena alle equazioni di primo livello... :-? :o :-[ :-/
Massi' non è cosi problematico come sembra.
E poi siamo il forum italiano. Dobbiamo spaccare.
(non per mettere competizione con i forum esteri) pero' dovremmo tirare fuori qualcosa di interessante, avete visto in america cosa fanno?
Non possiamo farci surclassare cosi'
(piccola precisazione, porca miseria, non abbiamo mai nominato la cosa più interessante nel poll: creare un nuovo shield!! e pensare che doveva essere la prima cosa a venirci in mente ;D ;D)
sai che non lo trovo? Mi mandi il link?
Beh io stavo pensando di utilizzare una bussola per rilevare l'orientamento del robot rispetto al mondo. Si potrebbe pensare a uno shield del genere, e risulterebbe anche utile per il progetto del mapping. In teoria se scegliamo decentemente il componente possiamo spendere davvero poco, vedendo in giro.
Ciao
Pensavo a come centrare il progetto, l'obieettivo è quello di usare solo Arduino, oppure anche di basarci su calcoli effettuati dsa Pc che appoggiano Arduino sulla parte di calcolo ?
Nel frattempo ho costruito un rover che puo' portare a spasso un netbook, funziona abbastanza bene. ...e risolve anche problemi di eventuali calcoli on site.
Se si potesse fare solo con arduino porebbe essere meglio, metti che un robot possa arrampicarsi o camminare su una griglia, potrebbe essere difficile portarsi a spasso un chilo di netbook...
ho sperimentato anche io in quella direzione tempo fa e mi son reso conto che non ha alcun senso portarsi dietro il pc soprattutto per robot casalinghi quando esiste il wireless.
Cmq si potrebbe essere carino magari rappresentare graficamente con processing la mappa creata dal robot.
Ok mi sono fatto una cultura. Sembra che possiamo ispirarci molto da:
-Rino
questo è un ottimo lavoro, davvero complimenti al realizzatore. Nel sito trovate tutta la parte di mapping spiegata.
Savo ragionando a sviluppare un arduino dedicato solo a ricevere dati da un altro arduino, computare e salvare la mappa su SD. Questo perchè un solo arduino faticherebbe a fare tutto, e quindi con due possiamo anche scrivere una cosa pesantina e non troppo elegante che pero' funzioni.
In questo caso una volta fatta la mappa puo' per assurdo essere inserita in qualsiasi altro robot che conosca il linguaggio utilizzato.
Che ne dite?
Spettacolo!!!
Ho letto un po' qua e un po' la e mi sembra di capire che il cuore del problema è definire quali sono i colli di bottiglia del problema.
Ad esempio un microcontrollore si occupa solo degli encoder e dei motori, uno della navigazione, uno dei sensori, ecc... e poi ha creato un protocollo di comunicazione su seriale per farli parlare tra di loro, così che si genera una sorta di multitasking su più microcontrollori.
Ho visto che ogni tanto cita anche Arduino, potremmo cercare di coinvolgerlo nel progetto no?
Comunque mi sa che il primo passo è quello di risolvere il problema motori+encoder, è un po' che ho il pallino per questa cosa, ma ci sono troppi argomenti che non conosco bene, magari collaborando se ci riusciamo potremmo anche produrre uno shield...
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
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.
Io sono sempre più intenzionato a cimentarmi nel controllo motori con encoder e PID.
Visto che probabilmente hai un bel po' di esperienza, come lo vedi un ATMega328 per questo uso?
Secondo i ragionamenti che mi sono fatto, dovrebbe andare più che bene per leggere bene un encoder ed elaborare un PID, però non sono dei ragionamenti spannometrici dato che conosco poco le architetture dei microcontrollori. Che vantaggi in più mi darebbe in questo caso un architettura a 16bit rispetto a quella a 8bit?
Perdonami l'abbondanza di domande, ma non ho inquadrato ancora bene il problema!
il problema principale è il consumo di potenza di calcolo da parte del mapping software. credo che un 168 basti e avanzi per il PID!!
Questo progetto è una figata contiene tutto quello che serve imparare, cioè:
-interazione tra piu' arduini
-applicazione e sviluppo di un software complesso
-applicazione e acquisizione sensori
-una applicazione vera e sensata per il risultato finale (aspirapolvere diy)
ve li immaginate finalmente i nostri robot che dopo un po' di musate iniziano a filare veloci come fusi in casa senza sbattere da nessuna parte?
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 (PID) 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 (Ottimizzazione), 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.