[Progetto comune] - Robotica

Giusto, dobbiamo fargli il cul0 :)

E poi siamo il forum italiano. Dobbiamo spaccare. (non per mettere competizione con i forum esteri)

e perchè no? ;) un po' di sana competizione non ha mai fatto male a nessuno, anzi, al massimo ci sprona a dare il nostro meglio :)

A me sono arrivati i sensori di colore, vogliamo farci qualcosa? http://it.mouser.com/ProductDetail/TAOS/TCS3200D-TR/?qs=07cgIB9%2f73FMXjkjs0LJVg%3d%3d Ho scoperto che su mauser.com costano l'imponente cifrone di 2 euri cadauno... alura?

(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? :P 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.

Gio'

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: -http://www.guiott.com/Rino/index.html 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?

materiali necessari: -2 motoriduttori encoder 60 80 rpm -2 arduini -qualche sensore -lettore scrittore SD

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... :D

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.

Complimenti!!

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 (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.

No anzi sei un grande. Suddividere in piu' microprocessori il lavoro è importante per piu' motivi. Si possono creare dei gruppi di lavoro e suddividere la sperimentazione in piu' blocchi inter-dipendenti. uno schema di base potrebbe essere: -un arduino che si fa la parte PID e pilotaggio motori -un arduino che segue input sensori e li pilota (in caso si parli di US) -un arduino che elabora dati spediti dagli altri due e salva su sd. Cosa ne dici?

No anzi sei un grande. Suddividere in piu' microprocessori il lavoro è importante per piu' motivi. Si possono creare dei gruppi di lavoro e suddividere la sperimentazione in piu' blocchi inter-dipendenti. uno schema di base potrebbe essere: -un arduino che si fa la parte PID e pilotaggio motori -un arduino che segue input sensori e li pilota (in caso si parli di US) -un arduino che elabora dati spediti dagli altri due e salva su sd. Cosa ne dite?

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.

Beh qui bisogna valutare il parere comune.
Cosa ne pensate ragazzi?
Chi sarebbe interessato (e a che parte del progetto) ??

Io sono interessato a tutto il progetto chiaramente, però se devo scegliere un "task" su cui lavorere, preferirei dedicarmi al controllo dei motori con encoder e PID.

Anche a me interessa molto quella parte, anche se spero di poter saltare anche nel gruppo del mapping ::)

ciao gente. Noto con piacere che il progetto si sta definendo. @gbm: potresti usare il primo post ti questo thread per sintetizzare il progetto come fanno per il CNC?

Questo permette un più semplice update sui lavori.

Questo trhead verte sulla costruzione di un robot lavapavimenti tipo roomba, completamente costruito da noi sia a livello software che hardware, integrando tutte le funzionalità (volendo anche qualcosa di piu' avanzato) del roomba o degli altri robot lavapavimenti commerciali. Ho proposto questa sfida al forum italiano come esperimento per testare la nostra capacita' organizzativa e le nostre competenze messe non solo in share, ma organizzate verso un fine comune. ;D

i gruppi delineati quindi sono: -azionamento motori Encoder e PID -modulo acquisizione dati dai sensori -modulo di mapping

Io mi inserirei nel gruppo del mapping. C'è qualche altro interessato?