[Progetto comune] - Robotica

Credevo che la computazione non la facesse arduino ma jmyron

ad oggi non conoscevo ancora il progetto Myron (http://webcamxtra.sourceforge.net/) .. interessante: appena avrò un pochino di tempo gli darò uno sguardo più attento ;)

@Calamaro:

si si è lui

Grande! Eheh, solo che non credo si sia accorto dei messaggi.. ;)

@Tutti: Io riapro il discorso robot hoover.. il sistema di controllo procede.. con una piantina di una stanza simulata (disegno su foglio di carta ;) ), con colori netti, il sistema isola il pavimento e ne risolve il perimetro, tracciando il percorso, ha bisogno di qualche ritoccata perchè è troppo sensibile e non ha calcolo sugli errori e le fluttuazioni dei pixel, ma tra poco riuscirà ad individuare se un "buco" nel pavimento è un errore o un oggetto. (in realtà sto ancora decidendo quale tecnica sia migliore per isolare il pavimento, per ora ho fatto un algoritmo mio, ma pensavo di usa un normalissimo filtro.. devo vedere cosa richiede meno aggiustamenti e meno approssimazioni).

Rilancio la richiesta.. se qualcuno fosse interessato a darmi una mano con la realizzazione del robot, magari che abbia un po' d'esperienza con motori e comandi via radio/bluetooth/wifi/quello che volete, è il benvenuto!! Così apriamo un topic ad hoc con le fasi!

Ciao Saki. Scusa non avevo letto. Si credo di essere io, o almeno un tempo avevo contattato un ragazzo per l'acquisto di una kawa 250sm?? Ma si parla di anni fa!!!! ;) ;) ;) Eri tu?

Io sono piu' che felice di aiutarti. E sono sicuro che molti del forum faranno lo stesso. Il mapping è davvero intrigante e ci ho lavorato decisamente poco. Quindi SI, ti do tutto il mio appoggio.

Allora, partendo dall'inizio, devi decidere il grado di precisione del tuo sistema, che è dato unicamente dagli encoder. Piu' utilizzi encoder precisi piu' il progetto cambia la sua forma e realizzazione.

Se punti a un robot che abbia una risoluzione di 1stepencoder/cm è una cosa (la mappa servirebbe poco, o quantomeno servirebbe a poco per evitare gli ostacoli, ci sarebbe un elevato rischio di collisione).

Io se fossi in te utilizzerei una risoluzione minima di 1stepencoder/mm di avanzamento che cmq alla lunga potrebbe rischiare di portare il robot in errore rispetto alla mappa. In piu' sarebbe carino come dicevi computare encoder e sensori di prossimità per "disegnare" la forma degli oggetti all'interno della mappa. X disegnare mappa partirei da processing connesso ad arduino via seriale. Altra possibilità è salvare direttamente su memoria/sd sul robot. Oppure ulteriore possibilità puoi portarti dietro il computer ;).

Poi sara' da pensare alla base di ricarica. Credo serva un sistema emettitore (su base) ricevitore su robot per trovarla (puoi scegliere tra ir / ultrasonici se vuoi un metodo semplice). Volendo potrebbe essere un modo che ha il robot per, se posizionato perfettamente sulla base, di resettare la sua posizione e cancellare l'errore accumulato dal periodo di roving precedente. 8-)

Domanda, effettivamente cosa dovrà saper fare?? Vuoi inventare qualcosa di nuovo o vuoi costruirti un roomba ben funzionante da solo?? (non è una critica vorrei solo inquadrare effettivamente i tuoi intenti).

Mm.. no nessuna kawa 250sm, la mia era un ktm 400 sm!.. ma sono sicurissimo che ci fossimo sentiti, ma ero ancora in dubbio se venderla.. va bè roba troppo remota! ;)

Allora, le tue domande e un po' di prove pratiche sul campo mi hanno indirizzato su un altro binario..

Prendo buono come punto di partenza 1stepencoder/mm, in effetti a senso mi pare ottimo per evitare ostacoli in maniera sufficientemente precisa arrivando però proprio vicino all'oggetto (per poterlo pulire). Anche se forse non sarebbe necessario per il futuro essere così precisi, ora vedo un po'.

Per il sistema di guida ho appena "finito" (è in versione alpha) un sistema che si basa sul gioco per cellulari snake.. ;) Praticamente con le frecce della tastiera si ci può muovere su una superficie e registrare movimenti eseguiti per fare quel tragitto e coordinate cartesiane rispetto la mappa, con la possibilità di graficarle. Una volta sostituito l'input delle frecce della tastiera con un radiocomando il gioco è fatto.

Tutto questo perchè l'attuale idea è di memorizzare il percorso da fare guidando il robot la prima volta che entra in una stanza, poi salvare quel percorso associandolo ad un'etichetta, da richiamare ogni volta che si voglia compiere quel percorso. In parallelo sul robot sensori di prossimità individuano ostacoli inattesi, ed il sistema di CV/shape detection ne individua forma e dimensioni.

Tutto questo dovrebbe tradursi in un'efficienza elevate in termini di superficie realmente pulita e garantire al tempo stesso sufficiente autonomia del robot per gironzolare per casa senza perdersi.

Per la base di ricarica in effetti bisogna pensarci bene, non se ne può mettere una in ogni stanza, come bisogna fare per gli attuali roomba, quindi pensavo quasi di creare una "super mappa" della casa, unendo le varie mappe delle stanze, di modo che il robot possa sfruttare i percorsi accessibili su ogni mappa per arrivare alla posizione della base.. probabilmente è più facile a farsi che a dirsi.

Per cancellare gli errori io pensavo di usare due sistemi, o il solito sistema CV dall'alto, che identifica il robot e controlla che la sua posizione sia corretta rispetto al sua mappa, oppure sfruttare il sistema in parallelo sul robot che identifica gli ostacoli inattesi per capire se si tratta di un ostacolo inatteso o proprio un errore sullo spostamento, anche qui è più facile farlo che spiegarlo. Tanto l'errore sarà di qualche millimetro ad ogni ostacolo, se viene di volta in volta corretto.. spero..

Ci mancherebbe, anche fosse una critica non ci sarebbero problemi, potrebbe servirmi per riflettere bene, come tutte le altre domande. L'idea è creare qualcosa per me innanzi tutto.. per pulire la mia stanza senza dovermene preoccupare, ma pulirmela bene (rapidamente e senza dispersioni di tempo ed energia), non come il roomba. :D :D ;D Vorrei dare all'idea del roomba, cioè del robot che gira per la casa e pulisce, un senso più pratico ed efficiente, meno giocoso e casuale.

Dato che mi piace sperimentare, senza stare a teorizzare per giorni.. parto con le prime domande pratiche: - che tipo di motore usare (non sò proprio nulla di questo argomento)? Alla luce del fatto che devono essere economici e con velocità relativamente basse. (Contando che in casa ho qualche motore sparso qua e la, di mini 4wd, registratori, stampanti, macchine telecomandate, ecc, e vorrei capire se potrei usarli per un prototipo oppure mi conviene investire in prodotti nuovi ad hoc) - come fare per trasmettere dati via radio/bluetooth/ir tra arduino ed un pc con processing, o un telecomando (magari di una macchina telecomandata che ho già)? Il modo più economico finanziariamente! ;) - come realizzare il chassis o lo scheletro? Materiali, persone a cui rivolgersi.. io per un prototipo pensavo a del cartoncino spesso.. ;D ;D Sono al risparmio assoluto!.. e poi sarebbe anche riciclabile e modellabile!

P.S.: meglio aprire un nuovo topic? O possiamo usare questo?

Come preferisci. Puoi scrivere anche qui, visto che stiamo parlando di robotica ;). Allora: - Se il robot è acceso sempre, credo che l'errore si sommi senza fine. Quindi questa è una delle prime cose da prendere in considerazione. Devi trovare il modo di cancellare questo errore. Utilizzando i sensori, puoi evitare gli ostacoli inattesi e evitare gli ostacoli che invece sono attesi (ma da un'atra parte) cioè errore. Ma devi capire che piu' passera' il tempo meno il robot utilizzera' la mappa, perchè sara' sempre piu' spesso in errore. Dovresti trovare un modo per azzerare questo errore, come ti dicevo per esempio trovando la base di ricarica e resettandosi quando sopra di essa, o qualcosa del genere. La cosa di fare piu' stanze inizia ad essere piu' complessa per vari motivi, uno dei quali sono le porte :D. Per la computer vision se ti diverte ti consiglio di dare un occhio a Roborealm. Davvero facilissimo da usare, se devi sperimentare un programmino semplice è davvero comodo. Si avendo una webcam ben posizionata (sarebbe meglio esattamente perpendicolare al terreno al centro della stanza (con obiettivo piu' grandangolare possibile) puoi ottenere ottimi risultati e pilotare direttamente tramite PC il robot. Puoi pilotarlo con una semplicissima ricevente RC e suo telecomando. Come? recupera la tua macchinina RC. Falla a pezzi ed estrai la ricevente. Se è una buona macchina RC, utilizzera' dei servi per sterzare. Questi servi vengono pilotati dal solito cavo bianco/giallo PWM. Se prendi questo cavo e lo connetti ad arduino, puoi "sentire" quali comando vengono dati tramite la funzione pulseIn(). A quel punto servirebbe un secondo arduino connesso via usb all computer e via PWM al posto dei potenziometri del telecomando, per spedire le info all'arduino sul robot. A questo punto se ti scrivi una sorta di protocollo di comunicazione hai fatto ;) http://www.gioblu.com/index.php?option=com_content&view=article&id=71:da-ricevente-rc-ad-arduino&catid=39:comunicazione&Itemid=6 (da rc ad arduino) http://www.gioblu.com/index.php?option=com_content&view=article&id=60:leggere-dati-servo&catid=39:comunicazione&Itemid=6 (pulseIn())

Scusa la risposta frettolosa ma sono in viaggio :(

Scusa la risposta frettolosa ma sono in viaggio

Figurati, no problem! :wink:

Allora:

  • Se il robot è acceso sempre, credo che l’errore si sommi senza fine. […]

Per questo pensavo di usare una mappa, così mappa + sensore di prossimità, posso azzerare l’errore: il sensore mi da la misura esatta, mentre la mappa quella approssimativa per sapere la direzione (ho già in mente il codice per farglielo fare).

La cosa di fare piu’ stanze inizia ad essere piu’ complessa per vari motivi, uno dei quali sono le porte.

Già! Avere porte chiuse potrebbe essere un problema… ma sto valutando di lasciare stare la base di ricarica per ora, una volta scarico potrei caricarlo io a mano, almeno all’inizio…
Anche perchè vorrei fare un sistema di ricarica totalmente autonomo, dalla normale 220, senza base… vediamo cosa uscirà fuori… :wink:

Per la computer vision se ti diverte ti consiglio di dare un occhio a Roborealm. Davvero facilissimo da usare, se devi sperimentare un programmino semplice è davvero comodo.
Si avendo una webcam ben posizionata (sarebbe meglio esattamente perpendicolare al terreno al centro della stanza (con obiettivo piu’ grandangolare possibile) puoi ottenere ottimi risultati e pilotare direttamente tramite PC il robot.

Eh me lo avevate già consigliato precedentemente roborealm… ma costicchia… e usare la versione di prova che dopo 30 giorni finisce non mi ispira molto… così anche per un altro progetto ho realizzato tutto da me (filtri, riconoscimento colori, tracking di colori, conteggio ed identificazione di shape, densità colore, ecc).
Per la webcam ho fatto un po’ di prove, avevo già praticamente finito la prima parte del prog in processing per guidare il robot totalmente dall’alto, ma per ora sono sprovvisto di webcam grandangolare, e le ombre degli oggetti viste dall’alto sono un vero disastro per riconoscere il pavimento… l’esempio fatto con roborealm sul loro sito è piuttosto banale, dato che il robot si muove in un campo uniforme sia di colori che di luci.

Puoi pilotarlo con una semplicissima ricevente RC e suo telecomando. Come? recupera la tua macchinina RC. Falla a pezzi ed estrai la ricevente. Se è una buona macchina RC, utilizzera’ dei servi per sterzare. Questi servi vengono pilotati dal solito cavo bianco/giallo PWM. Se prendi questo cavo e lo connetti ad arduino, puoi “sentire” quali comando vengono dati tramite la funzione pulseIn(). A quel punto servirebbe un secondo arduino connesso via usb all computer e via PWM al posto dei potenziometri del telecomando, per spedire le info all’arduino sul robot. A questo punto se ti scrivi una sorta di protocollo di comunicazione hai fatto
Gioblu robotics | Da ricevente R/C ad arduino | Rightval, Ricevente, Leftval, Write, Motore… (da rc ad arduino)
Gioblu robotics | Leggere dati servo | Pin, Esempio, Pulsazione, High, Tutorial… (pulseIn())

Mm… bene bene, almeno sò da dove iniziare ora!! :wink:
Grazie mille!! Proprio quello che mi serviva!!

…anche se mentre scrivo mi è venuta un’altra idea… perchè non fare a pezzi il telecomando??.. alla fine sono già lì tutti i potenziometri che mi servono… basta simularli con arduino e così dovrei risparmiarmi un arduino e la lettura dei protocolli originali… dovrebbe funzionare! :wink:
…sempre che riesca a regolare bene i singoli impulsi per comandare precisamente il moto.
Bene bene, questa sera mi armo di cacciavite e inizio ad operare i trapianti nella macchina RC! Grazie!

Ehila Saki. Non ho capito bene cosa intendi con "risparmiare un arduino", se vuoi poter spedire tramite un computer comandi a un arduino via radio, hai per forza bisogno di: - smontare il telecomando scollegare i potenziometri e collegare delle uscite pwm arduino e (con il pwm) produrre una tensione "analogica", con cui sostituire l'azione della variazione di tensione dei potenziometri. Collegare l'arduino al computer via usb / wifi / bluetooth - collegare arduino del robot a ricevente rc, e interpretare segnali con funzione pulseIn().

Scrivendo il tutorial che ti ho linkato e facendo dei test, ho notato che il valore analogico ricevuto da arduino utilizzando pulseIn(), varia in rapporto alla distanza dal telecomando (emettitore), quindi per ottenere un funzionamento corretto ho dovuto applicare la media che puoi vedere nel codice che ho postato (che rallenta decisamente tutto, dato che gia pulseIn è pesante da eseguire). Non ho avuto la possibilità di provare con altri sistemi di trasmittente/ricevente, quindi non ho chiaro se fosse la mia ricevente un po' cotta o è un problema che affligge tutti questi sistemi. Sarei curioso di vedere i tuoi progressi e la tua sperimentazione. Tra poco avro' sotto mano una nuova trasmittente(telecomando) - ricevente 2.4 ghz, sono curioso di vedere cosa succederà. Sarebbe carino scrivere una libreria per interfacciare questi sistemi in modo piu' o meno user-friendly.

per il problema dei segnali variabili secondo la distanza, si potrebbe interporre un trigger di schmitt che "ripulirebbe" il segnale e gli darebbe un'ampiezza costante (o quasi). http://it.wikipedia.org/wiki/Trigger_di_Schmitt

@gbm: intendo che se interfaccio un arduino direttamente sull'integrato (o al posto dei potenziometri, come dici tu) del trasmettitore, poi non mi serve un arduino anche sul robot, dato che ha già la sua bella scheda che elabora i segnali del telecomando.. in teoria dovrebbe funzionare.. sto proprio per provare, appena ho fatto, e se funziona, faccio un video o qualche foto!

@brainbooster: Quel trigger sembra tanto un comparatore o un filtro anti rumore con feedback, anzi sono quasi sicuro che gli integrati che montano i ricevitori ne abbiano uno all'interno.. vado a vedere su qualche datasheet se lo trovo! Ma forse non basterebbe un amp-op con un bel guadagno? Si perde qualcosa in ampiezza, quando il segnale va in tensione di saturazione, ma tanto a noi interessa la frequenza del segnale se non sbaglio.. spero di non dire castronerie.. ;)

Ah Saki ora capisco. Attento (so che sono pignolo) ma a questo punto, non stai parlando di robot, ma di "remoto", cioè un esserino completamente telecomandato e privo di logica, la logica sarebbe sul pc. Non che non sia un'idea intelligente, anzi, trovo che sia un'ottima idea e permetterebbe al robot una maggiori possibilità di computazione.

Grazie Brain per il consiglio sto proprio leggendo e cercando di farmi una cultura, questi cosi sono una figata!!

per il trigger di solito si usano dei "dozzinalissimi" ne555 :) e ti fà da squardatore ed in un certo senso da ripetitore del segnale, inquanto quello in uscita ha la tensione di alimentazione del 555 e non quella del segnale di ingresso.

Belin son un pirla.. l'ho anche realizzato un trigger del genere con un 555, solo che non sapevo si chiamasse Schmitt!

Comunque confermo, in alcuni integrati (almeno in un vecchio L9362 che ho in un vecchissimo radiocomando) c'è questo trigger, o comunque è molto simile a quanto pare, dato che fa la stessa cosa! ;)

@gbm: Eh sì hai ragione, non è più nè un drone nè un robot! Ma solo per ora! ;) Dato che poi un Arduino per gestire sensori di prossimità, correzione mappa e altre faccende servirà.. solo che credo di appoggiarmi sempre sugli integrati presenti per farlo, almeno all'inizio, poi vorrei sostituire tutto con moduli xbee, molto più efficienti, versatili e facili da gestire! Conta che la mia idea è collegare questo robot al mainframe che mi sto creando in casa.. si chiama Mambo, è un DLA (Digital Life Assistant) comandato vocalmente, sarà lui a pilotare tutto.. appena sarà un po' più presentabile (leggere: avrà tutte le funzioncine che sto creando per lui) posterò qualcosa.. per ora mi da la sveglia, mi dice se un mezzo è parcheggiato sotto casa o è in uso da qualcuno, mi dice che tempo fa, accende e spegne le luci (anche se il sistema è da rifare un po' meglio).. ;)

Questo è stra interessante: http://www.jonh.net/~jonh/robots/mapping/submitted-paper.html Qui il PDF scaricabile (per iscritti) http://www.gioblu.com/index.php?option=com_content&view=category&id=38&Itemid=7

Altro ebook sicuramente inerente: http://iopscience.iop.org/1742-6596/90/1/012088/pdf/jpconf7_90_012088.pdf

Society of robots come al solito chiarissimo: http://www.societyofrobots.com/programming_wavefront.shtml

Altro pdf un pochettino piu' complesso ma sicuramente utile: http://www2.itu.edu.tr/~altuger/Documents/Papers/IECON2009.pdf

Belin il primo articolo fa duemila parole e poi il risultato non è così esaltante.. allora il mio prog è ben ben più avanti.. almeno traccia già una mappa definita, manca il sistema di correzioni tramite sonar (che non ho ancora), ma è più preciso in origine come idea.. IMHO! ;) Bello però l'approccio "robotcentrico" e le coordinate polari.. anche se diventa un macello poi poter gestire delle coordinate assolute, il piano cartesiano rimane lo standard secondo me.

Il mio progetto è davvero simile a quello su Society of Robots. Davvero un bell'articolo quello, mi ha dato anche due nuovi spunti!

Thanks gbm!

Figurati Saki. Appena torno in quel di Milano sperimentero' alcune idee che sto buttando giu da qui. Sono curioso di vedere come si evolverà la tua sperimentazione. Gio.

;) Mi sta prendendo proprio questa cosa e sfruttando il tempo libero sto andando abbastanza spedito.. Oggi ho adattato un vecchio mouse a pallina per contare al centimetro.. ora vedo se riesco ad arrivare anche al mezzo centimetro, non sò come possa risultare l'errore alla fine con il lasco della pallina se scendo troppo. L'obiettivo è attaccarlo sotto alla macchina RC e contare effettivamente lo spazio percorso, così da avere una mappa il più possibile precisa..

C'è un piccolo problema, per ora il prog è stato realizzato pensando ad un robot che potesse ruotare su se stesso, mentre la mia macchina ha uno sterzo classico, quindi sballerà un po' tutto, ma almeno mi darà un indice di massima.. fatto questo si monta il sonar (qui mi servirebbe un bel consiglio, meglio IR o ultrasuoni?? Esperienze al riguardo?).. e poi realizzazione vera e propria del robot, compresa la parte sugli studi di fluidodinamica per dare un po' di potenza a basso consumo al piccolino!

Piccolo aggiornamento!!

Ok che è arrivato il progetto comune sulla domotica, ok che arriva l'estate e siamo tutti più propensi ad andare al mare, piuttosto che leggere e sperimentare, ma cerco di tenere vivo questo thread!

Ecco la descrizione del mio progetto, i passaggi e l'aggiornamento degli step fino a qualche giorno fa.

Si chiama Roombot, nuovo nome, e dovrebbe diventare la base per vari robot domestici.

Vi lascio al link, se volete chiedere qualcosa fatelo qui o sul forum di Gioblu, come preferite.

http://www.gioblu.com/index.php?option=com_agora&task=topic&id=10&Itemid=39

Per ora c'è la descrizione dei passaggi iniziali e le prove che hanno portato a rami abbandonati, ma presto ci saranno i test con encoder e sensore di distanza, oltre il pre-codice del sistema di mapping!

Sono curioso, vorrei vedere qualche aggiornamento :) @Saki linka qualche foto!

Ciao Brain!!! Scusa il ritardo nella risposta, ma l'uni mi sta assorbendo al 200%!!

Ecco alcuni aggiornamenti!

Prima di tutto l'interfacciamento tra Arduino e un radiocomando Tamiya, per vedere se era fattibile usare una vecchia macchina telecomandata come piattaforma per il Roombot. http://www.gioblu.com/community/forum/topic?id=10&p=1#p54

Tutto funzionava alla perfezione, salvo che poi avrei avuto bisogno di un DAC per simulare i potenziometri sul telecomando e decidere via software anche le velocità di avanzamento. Cosa fattibilissima comunque, ci ho scritto anche un tutorial: http://www.gioblu.com/tutorials/elettronica/139-tensione-analogica-da-un-circuito-digitale-con-i-pwm

Poi mi sono dedicato all'odometro per poter mappare le dimensioni della stanza mentre si pilota il Roombot. Ho preso un mouse, l'ho un po' smembrato ;) :D, ho aggiunto un sensore IR smd preso dal meccanismo di una macchina fotografica e ne ho fatto un conta centimetri: http://www.gioblu.com/community/forum/topic?id=10&p=1#p64

Funzionava bene, ma non riuscivo ad individuare il verso di rotazione.

Così ho deciso di usare un encoder di una rotella per mouse.

Nel prossimo post metterò foto e test di questo encoder.

Per ora sono un po' fermo a causa dello studio, ma appena ho un po' di tempo mi sto dedicando al programma di mapping!

A presto con altri aggiornamenti!!

A me sembra che il maze solver sia una buona base di partenza per poter poi passare a qualcosa di più complesso. In fondo la robotica con Arduino è fatta per puro piacere più che per utilità.