Robot mapeador autonomo

[Jimmy_pop]

Hola, os voy a soltar mi rollo sobre un pequeño proyecto q estuvimos haciendo el año pasado. La idea era realizar un vehiculo q fuera capaz de moverse por una superficie, evitando obstaculos y paredes y  obteniendo datos de posicion de los sitios por donde pasaba para elaborar un mapa de la superficie. Se nos planteó así y nos lanzamos a la aventura sin saber demasiado en qé marron nos metíamos.

El primer problema, el mayor problema, es q un robot así es muy dificil q obtenga informacion fiable y es q los metodos mas sencillos de obtencion de informacion de trayectoria son de bucle abierto, es decir no hay una compensacion del error q se comete de medida y es algo q se va propagando y se inestabiliza hasta convertir los datos en basura inutil. Los sistemas basados en vision artificial tienen la ventaja de tener una realimentació intrínseca q evita la propagacion de errores, no obstante son los cracks de consumir recursos como ladrones y ser mas complejos q meterla por el agujero de una aguja, otros metodos basados en sonars e historias varias se pueden refinar hasta el punto de elaborar por metodos estadisticos o redes de neuronas y interpoladores de muchas clases dan muy buenos resultados. No obstante nosotros íbamos a hacer algo bastante mas modesto y es q cuando tienes 2 meses para hacer algo... y es la 1a vez q tocas un microcontrolador y es la primera vez q soldas algo y es la primera vez q etc etc no estás para mandangas.

Qué hicimos? Usar un vehiculo con 2 ruedas motrices/directrices, el tipico robot mouse, con 2 motores independientes y dos encoders con una cierta precision. Y usando el microcontrolador Pic16f877 hicimos q se integrara la trayectoria por el metodo de euler (patillero) para saber por donde pasaba nuestro bicho. Esto se hacía con un bucle de control y toda una parafernalia q hacía q nuestro cacharro
se programara en distintas capas de software (siempre he querido tener la oportunidad de hablar de capas de software) hicimos una capa crítica de tiempo real q hacía todo lo serio y lugo una capa de aplicacion con una especie de interprete de logo donde se podia programar los algoritmos q debia seguir el bicho para moverse.

Los mapas consistian simplemente en un log de puntos registrados con informacion sobre colisiones.  Se nos dio des de buen principio la orden de usar eso en un pc y así lo hicimos.

Nuestro robot iba conectado a un pc mediante un cable de serial, llamadle cordon umbilical q subministraba la corriente al bicho y además hacía de soporte de las comunicaciones con el pc. El pc actuaba pasivamente y se limitaba a recibir los datos de posicion q recibia del robot y elaborar un mapa q mostraba graficamente en pantalla.

Hicimos varias pruebas de algoritmos para recorrer el espacio. Y fue bastante guapo poderlo ver en el monitor en tiempo real como se movía (se veía incluso dibujo del robot representado como un rectangulo moviendose y girando en tr,.)

En fin una pijada. Al final se lo quedó mi compañero q era quien pagó la mayor parte del material y yo me quedé con los conocimientos y con ganas de hacer otro mas pequeño y mejor mecanicamente (había algun problemilla con las ruedas.)

Si os interesa ya escribiré otro dia comentando como se integraba la trayectoria pq es bastante interesante (con unos lookup de sin y cos).

Os dejo unas fotos donde se aprecia el bicho en 2 fases de su creacion y un detalle de la rueda y del encoder casero q montamos (solo 2 divisiones pero una reduccion q daba creo q 6 bits por vuelta de rueda).

see ya y hasta otra

foto1 foto2 foto 3

[manex_1987]

Hola

Yo tambien voy a hacer un robot tipo mouse (tengo ciertos problemillas porque no se que material usar, ni la parte mecanica, ni...) . Y el uso, al principio seria simple, pero quiero convertirlo en un robot que mapee un lugar.
Tengo bastante organizadillo el proyecto, y lo unico que me falta es el "empujoncito" con un hada magica que me de la carcasa del robot, y la parte mecanica... aunque no descarto "degollar" un juguete o usar piezas lego...
En mi caso, lo haria usando un 18F458, que, usando Pbplus, me proporciona aritmetica (sin,cos,tan,asin,acos,atan,exp,log,ln,x^y,sqr...) en coma flotante de la buena... con 4 decimales creo... (ni tablas lookup ni nada) y supongo que con 16K de memoria, y a 40mhz (10MIPS) no habra problemas de procesamiento...
Me gustaria poder usar un PIC16 de 18 pines... pero los PIC18 te proporcionan una velocidad y un rendimiento increibles.

Me has dado bastantes ideas al respecto de mi proyecto (que seguramente queda aparcado al empezar el cole, osea ya), espera mis consultas de robotica en este subforo jejeje.

sinmas, un saludo!

[Carlete71]

Interesante proyecto

Yo no he hecho robots, pero me gustaría.

Saludos,

[wofer]

Buenas Jimmy_pop,estoy muy interesado en ke me explicaras un poco como integrabas la trayectoria y para ke usabas el sen. cos. etc.(y ke es eso de "lookup"?)
  He construido un robot de 4 ruedas al ke me gustaria implementarle un programilla para ke pueda rastrear,pero estoy muy verde en ese aspecto.De momento lo unico ke hace es rodar "sin ton ni son" por casa evitando obstaculos.



Saludos!!

[Jimmy_pop]

buenas,

manex, yo tb he pillado una muestra de uno de la serie 18 atraído por la posibilidad de tener mas velocidad y mas intrucciones (yum ) No obstante te advierto que lo unico q haces es tener el doble de instrucciones por unidad de tiempo... eso está bien.. pero hablar del doble no es hablar de 4000 veces mas. Lo digo pq si bien los cacharros estos trabajan a alta velocidad y en algunas aplicaciones hay tiempo de sobras y se pueden hacer maravillas, cuando uno hace una aplicacion de tiempo real como controlar varios motores o hacer una integracion numerica en tiempo real para determinar la trayectoria y todo eso, necesita hacer una operacion ciclica cada cierto tiempo de tiempo pero lo mas rapido posible y muchas veces hay restricciones q te obligan a tener un bucle q dure muy poco y te caben entonces un numero limitado de instrucciones y parece que no pero a veces falta tiempo. Y claro, calcular un seno o un coseno con coma flotante en un bicho de estos, si bien es posible, es una quema de recursos bestial pero bestial de cojones, y yo sinceramente creo q hay q renunciar a eso.. y aun q sea menos comodo usar coma fija y usar alguna tabla.. q si la usas combinada con algo de interpolacion te da una precision bastante buena.

Por otro lado, comentando lo de la integracion de la trayectoria. Yo lo que hice fue plantear la cinematica del vehiculo, es decir, teniendo en cuenta que el aparato se movía con 2 ruedas q podían girar a velocidades angulares distintas, deduje la ecuacion del movimiento q relaciona la velocidad del vehiculo en un momento determinado con la velocidad de rotacion de las dos ruedas. Eso da lugar a una ecuacion relativamente simple q te dice q la velocidad del centro del aparato en un determinado instante es ni mas ni menos q una suma de las velocidades angulares de las dos ruedas multiplicada por el radio de las ruedas y divididas por un factor constante q no recuerdo (la distancia entre ruedas creo). Y esa velocidad hay q proyectarla en una base vectorial solidaria al suelo de la habitacion para saber la velocidad respecto el sueloy poder sacar de ahí la posicion. Una vez obtenida esta expresion, se ve que para conocer la posicion del vehiculo en un determinado momento (aqi empiezan los problemas serios) hay q integrar una expresion q depende en cada instante del seno y coseno del angulo del vehiculo respecto una direccion fija de la referencia del suelo... o dicho en otras palabras para este caso concreto... el vehiculo es no-holonomo y por lo tanto es jodido de cojones saber donde coño está.

FINALMENTE xD esto da lugar al problema en mayúsculas de nuestro amiguito robot y es q para medir la posicion tenemos q basarnos en lecturas indirectas: de rotaciones de las ruedas y estimar así las velocidades angulares y estimar mediante una integracion casera por el metodo de euler la trayectoria del bicho. Esto se puede hacer cogiendo la ecuacion de la velocidad y aproximando las derivadas como si fueran constantes durante el tiempo de un ciclo de integracion y ahí se simplifican cosas. Pero nos da lugar a error.

El error en éste problema proviene de muchas fuentes. Hay error en el calculo, hay error en el modelo (las ruedas nunca seran perfectamente circulares, la distancia no es lo q nosotros llamamos distancia etcetcetc) Hay tantas fuentes de errores, q por mucho q refinemos la precision de nuestros calculos.. siempre tendremos un error q se nos irá a infinito y por lo tanto el mapa será tarde o temprano una mierda. El problema es insalvable por este camino y la unica solucion es tener una realimentacion des de fuera q nos dé algo sobre lo q corregir este error. Y  la idea mas simple q se me ocurre (aun q pueden haber mil inventos) es tener un punto o mas de referencia en el suelo q nos diga algo. Esto es, una base q esté quieta q nos diga cada cierto tiempo a qé distancia estamos de ella o alguna historia así. Con esto se puede compensar el error de calculo y los errores inevitables en el modelo mecanico y  elaborar un mapa tan grande como deseemos.

No sé si me he explicado bien. La verdad es q tengo la impresion q doy una imagen de hcer dificil lo q es facil pero yo creo q justamente lo erróneo es considerarlo simple. El tema éste es jodido pero bien jodido, yo recomiendo tragarse algun libro de control o leer por internet (pq hay informacion en muchos sitios) sobre control, para tener una idea de los conceptos estos de realimentacion y propagacion de error.


xcierto, para empezar a abordar el problema antes q hacer prototipos e historias yo recomiendo pillar lapiz y papel y estudiar la cinematica del vehiculo y sacar estas ecuaciones, es la mejor forma de saber a qé nos enfrentamos y empezar a hacer cálculos. Yo tuve un modelo cinematico y dinamico del bicho y me propuse controlarlo... al ver q mi modelo pecaba de no-lineal demasiado dejé de lado el intentar hacer un estudio de control muy analítico pero conservé las ecuaciones para tener una noción de como funcionaba el bicho, a partir de allí en paralelo elaboré el prototipo y desarollé el software mas simple para luego volver a la cinematica y desarrollar el algoritmo de integracion (q es muy simple de implementar).

en fin, hasta otra ;D

pd. por si estais muy locos, os dejo aqí algo de mi mierda por si quereis darle una ojeada, ya aviso q no es ninguna maravilla, pero sé q da rabia cuando lees por ahi q la gente hace cosas y cuenta cosas y no da nada a lo q agarrrarse xD Hay 2 imagenes donde sale un diagrama del bicho y las ecuaciones de la cinematica de éste (la aceleracion es util para desarrollar la dinamica) y luego hay el programa en asm del robot... es largo y coñazo y con comentarios y nombres en catalán... q dios os pille confesados xD



zip con estas 3 cosas

[manex_1987]

Bueno, es realmente interesante el proyecto... no obstante yo en mi proyecto no habia pensado en los giros por diferenciales de velocidad entre los dos motores... pensaba hacer tan solo giros estacionarios, es decir, girar quieto. Asi parece mas facil.

Bien, me has metido la mosca, y en el proteus estoy realizando una prueba con un 18f458 a 40mhz. Someto el numero 54.63 a diversas operaciones aritmeticas:

COS 54.63  = 0.4637ms de ejecucion = 463us

SIN 54.63  = 0.4256ms de ejecucion = 425us

TAN 54.63 =  0.9367ms de ejecucion = 936us

LOG10 54.63 = 0.451ms de ejecucion = 451us

LN 54.63 = 0.414ms de ejecucion = 414us

SQR 54.63 = 0.345ms de ejecucion = 345us

------------

Es una perdida bastante de tiempo (aunque para operaciones puntuales no es mucha), pero la precision que brinda el seno en coma flotante de este micro es impresionante. Hice un programa que enviara una onda completa de seno al ordenador, y luego en excel la comparé con la onda que genera el mismo PC. Son absolutamente iguales! Me agradaria colgar el documento en el foro pero no me deja...

Ayer probé las interrupciones multiples del 18F458, y consegui manejar los pines INT0 e INT1 con facilidad... se me ocurre que estos serian las entradas de los encoders...

Ah, y quien quiera rendimiento de verdad, que salte al barco de los DSP...

salu2!

[Jimmy_pop]

Hola

lo de girar en quieto yo tambien lo hice porque implementé de mala manera unas rutinas q hacían una realimentacion negativa con solo 3 niveles de actuacion en los motores (aun disponiendo de un conversor D/A de pwm digno y puentes en H para gobernar los motores DC) y punto, pero no tiene porqué ser mucho mas dificil de implementar un control de angulo y avance al mismo tiempo; si hubiera tenido tiempo hubiera intentado hacer lo q quería en un principio que era desarrollar dignamente un estudio de control del vehiculo y hacer un algoritmo de control serio basado en la descripcion q tenía en espacio de estados de la dinamica del mismo... pero bueno 2 piedras tuve q apresurarme y sudar de esto.

lo de los tiempos me ha dejado un poco frito,  segun estos datos  el chip calcula un seno en 4500 instrucciones (segun mis calculos caseros), me gustaría q me linkaras alguna web de esta librería q usas pq stoy flipando que se pueda hacer eso en coma flotante... no digo q no eh, pero quisiera verlo pq me interesa .

y lo del dsp... tengo ganas de probar algun dia de programar un bicho así.... no he tenido la oportunidad de realizar demasiados proyectos de electronica pero estos chips tienen muy pero q muy buena y pinta para cosas de control como éstas tienen q ser brutales.

see ya

[navi84]

Aunque ya sé que ha pasado mucho tiempo desde que se ha publicado este tema quiero dejar algo de lo que sé para a quien le haga falta ya que veo que alguno de los "electronicos" le tienen algo de miedo al hardware y a las ecuaciones de movimiento, etc...
Para muchos será una chorrada pero para los que no, se lo explico, es algo básico de dinámica pero yo lo explico como puedo:

ADJUNTO IMAGEN DE EXPLICACIÓN

Cuando en nuestro robot conocemos la velocidad de dos puntos del mismo podemos conocer en este caso la de cualquier punto de él (interesa la del centro del eje que une las ruedas en la mayoria de los casos). Es muy sencillo, conocemos la velocidad de las ruedas que es igual a su velocidad angular (velocidad con que giran (rad/s) o bien en rpm, Hz, o cualquier otra...) multiplicada por el radio (como ya han explicado anteriormente).

Entonces [V = w * r] para cada rueda que seran distintas si son giros abiertos o iguales y contrarias si giran sobre el centro del eje (ojo porque para poder multiplicar a machada hay que estar en rad).

Si unimos vectorialmente estas velocidades y hacemos que esta linea corte a la perpendicular a la misma obtenemos el centro instantaneo de rotacion (CIR) respecto al que gira el conjunto del robot describiendo una circunferencia (centro de la curva).
Analiticamente y para implementar el software ¿cómo calculamos esto y la velocidad del centro?

Pues dado el angulo "beta" su tangente es la velocidad de cada rueda dividida por la distancia de cada una al CIR, tg"beta"=V_a/dist_(a-CIR)=V_b/dist_(b-CIR) y asi para cualquier punto de la linea que los une como P.(la tangente es la velocidad angular tambien).

Por lo tanto V_a/V_b=dist_a/dist_b

y como la distancia (a-CIR)= dist(b-CIR) + distancia entre ruedas(D) podemos calcular el CIR. En principio no interesa.

Facil, ¿no?

Pues venga que acabo, si ahora situamos un punto de referencia en la rueda B existe la relacion de que (V_a-V_b)/D=(V_p-V_b)/0.5D por lo que despejando obtenemos que V_p=2V_a-V_b entonces ya conocemos la velocidad del centro de nuestro robot.

Ahora dejo caer algo más sobre velocidades, desplazamientos, etc. Con cualquiera de estas velocidades podemos calcular la velocidad angular con que gira el "bicho" alrededor de su CIR, cualquier velocidad dividida entre su distancia al CIR. De esta manera podemos conocer el arco que describe si la multiplicamos por ejemplo por el tiempo y asi sabemos cuantos radianes o grados hemos girado (es el mismo angulo). La distancia que recorre la tomamos respecto al punto P (centro) bien con el arco o con la V_p multiplicada por el tiempo (ojo porque no es lineal).

Pues bien, si estamos utilizando encoders, por ejemplo, podemos adaptar lo explicado para saber cuanto recorre cada rueda, de aqui sacar su velocidad y luego el arco que ha descrito para saber lo que ha girado... a darle imaginación.

Yo lo utilizo en una plataforma robot (todavia no autonoma) y creo que va bien y es sencillo aunque yo no lo haya explicado del todo bien, sobretodo al final, pero bueno hay queda la cosa y si alguien tiene dudas pues que pregunte, que somos muchos los que podemos responder.

No puedo subir la imagen y eso que pesa 39 KB pero bueno, seguiré probando

[Nocturno]

Oye Jimmy, veo que en tu robotito en lugar de rueda delantera tienes un tornillo. ¿así quedó finalmente?, ¿no se enganchaba en ningún sitio?

Interesante la explicación física que has dado sobre el movimiento del robot, se ve que te lo curraste, monstruo.

[Jimmy_pop]

saludos ;D

Bueno navi, lo q has dicho está bien, la verdad es q hay poca información sobre mecanica en la red o por lo menos es mucho mas dificil encontrarla que encontrar buenas webs con circuitos y tonterias varias para hacer robots. Un dia podemos currarnos si estamos muy aburridos algun texto mas o menos digno para explicar 4 cosas. Por otro lado quisiera añadir que estas operaciones se pueden hacer de forma exageradamente simple y que si se eligen adecuadamente los radios y las distancias entre las ruedas se puede lograr que las multiplicaciones y divisiones pasen a ser bitshifts y el resultado es gloria.

Y bueno nocturno, que ejem :$ uno de los fallos que tenía el robot era en la parte mecanica, que dejaba un poco que desear. Como se ve, había una rueda detrás y delante no tenía rueda... y pusimos un clavo ¬¬. Efectivamente se quedaba atascado y daba problemas :C Pero bueno ese es un tema que no nos preocupaba en exceso porque para las demostraciones teníamos una sala con un suelo muy liso y tiraba bien. De todos modos, si hicieramos ahora un robot seguramente puliríamos ese tipo de detalles como tambien buscaríamos otros motores mas dignos.. pq los que tiene q son como de juguete y llevan engranajes cutrisimos hacen un ruido de la ostia.

cya

[manex_1987]

Yo personalmente, creo que tanta informacion sugiere una pagina web explicativa... el dia que haga un bot pienso hacer una, aunque ahora con el bachiller... me da que va a ser cosa de fines de semana...

Muy buena la explicacion!

salu2

[navi84]

Que hay Jimmy_pop?

Tanto estudiar algo tendria que aprender... Si creo que a muchos de los que empiezan a construir bots o no se atreven o se quedan atascados con la parte mecánica, tanto a nivel estructura por no saber por donde empezar como a nivel de dinámica. Muchos se complican demasiado con la primera cuando realmente para empezar solo es necesaria una estructura simple, bien alineada y dejarse de florituras si no eres un manitas. Para lo del movimiento solo hay que saber un par de cosas básicas, como las que he intentado explicar (aunque no del todo bien) y ser capaz de desarrollarlas para sacar resultados más que decentes.

Me apunto a lo del tutorial

Yo estoy en camino de conseguirlo, despacio pero con buena letra

[manex_1987]

Hola gente!

Era para deciros que mi proyecto ya ha empezado, la base, en contrachapado 7mm, ya esta hecha, y ahora me falta acoplarle los motores.

No se como acoplar el eje del motor con un eje lego, se os ocurre alguna idea????

[Nocturno]

¿Son ejes de distinto tamaño o iguales?.
Si son de distinto tamaño, hay un rudimentario sistema que funciona bastante bien, y además te permitirá funcionar aún cuando no estén situados en una posición perfectamente alineada. Se trata de buscar un trozo de macarrón de goma cuyo hueco interior ajuste más o menos bien en los dos ejes. Le echas un poco de pegamento rápido y metes los dos ejes dentro del macarrón de manera que quede un poco de espacio del macarrón sin nada dentro en la parte central, unos 3 o 4 mm. De esta manera, el movimiento giratorio del eje del motor se transmite al macarrón y de este al otro eje, pero con la flexibilidad de la goma se corrigen defectos en la alineación de los ejes.

El otro método que he utilizado a veces, y también es muy barato, aunque sólo válido para ejes iguales es utilizar la parte interior de una "ficha de empalme" de las que se usan en las instalalaciones eléctricas. Las hay de calibres importantes, hasta de 8 mm. por lo menos. Es muy simple, alineas los ejes y atornillas cada uno a una entrada de la ficha de empalme, a la que habrás liberado de toda su parte plástica.

Supongo que habrá métodos más eficaces y profesionales, pero segúramente serán más caros que estos. Ya me contarás cómo te ha ido.

[manex_1987]

El problema radica en que, usando los macarrones de goma que mencionas, habria una holgura , y no despreciable en este caso, porque pienso usar CDs como ruedas...

Aun asi igual uso ruedas normales... que me recomendais para un motor con reduccion 1:192? Una rueda grande (un CD) le daria velocidad...

saludos!