sábado, 27 de junio de 2009

Vehiculo que aparca sólo (SPC, Self Parking Car)

Uno de los robotos hechos con el nxt más recurrentes que podemos encontrar por youtube (fuente inagotable de inspiración), son los llamados SPC.

He modificado un poco el siguiente diseño de nxtPrograms, y he obtenido lo siguiente, un pequeño coche con dirección.

Lo importante de este diseño es la dirección, que nos permitirá girar para aparcar el coche. Además de ya por fin ver cumplido mi sueño de construir un vehículo con dirección)


Y el sensor de ultrasonidos, que nos permitirá encontrar huecos en la carretera o sobre una mesa con libros, donde podamos aparcar el lego.


El resultado que he obtenido es el siguiente.


El resultado es medianamente aceptable. He tenido que recordarme a mi mismo que tengo que hacer prácticas de aparcar con el coche de nuevo, y comprarme coche ya de una vez también.

El sensor de ultrasonidos, tan sólo se usa para encontrar un hueco para aparcar, los demás giros que hace el lego, están metidos a capón en el código del programa. Ha sido un caso de programación por prueba y error. Como veis no entra mucho en el hueco, se queda más bien fuera, sospecho que es probelma de que la dirección no gira tanto como debería.

Esto es un modelo muy sencillo, pero ya que estamos, voy a ver si lo mejoro un poco. He visto en youtube dos videos realmente interesantes.

Este lego me ha gustado mucho porque creo que se asemeja mucho a lo que hace un conductor real cuando aparca, una vez que el coche está medio metido, avanza hacia delanta y atrás mirando hasta que el coche esté bien encajado.

No parece muy complicado añadir esta modificación al lego que tenemos entre manos, aunque eso será otro día.

Este video se lleva la palma, especialmente los últimos segundos, cuando se vé quien hace realmente toda la chicha. El autor no da ninguna información sobre el proceso o que usa para hacer ese gráfico tan bonito que da la ruta que debe tomar el robot. Sólo que está hecho con .net.

Parece un caso para matlab y alguna de sus toolbox. Investigaré un poco y veré que puedo encontrar.

Me he puesto dos objetivos de tarea, a ver si cumplo alguno.

lunes, 9 de marzo de 2009

Rotar 360 grados sobre si mismo

Hoy voy a dar una solución a un problema que creo que todos los que jugamos con nuestro lego nos hemos encontrado alguna vez. Hacer una rotación completa en el sitio.

Es una situación bastante común
  • Un robot que analice el entorno para detectar algo. Como el ball hunter de nxtprograms, o mi fallido intento de hacer un mapa del entorno.
  • Un robot que vea algo que no le guste y de media vuelta. Como por ejemplo la demo del nxt.
Para hacer que el tribot gire sobre si mismo, lo que todos hemos hecho alguna vez ha sido poner que los motores giren 360º cada uno, pero en sentido contrario. Pero ... ¡¡¡ se queda corto, no gira más !!! ... ¿Nos suena esto verdad? algo no cuadra.


Un poco de geometría, nos dará no sólo la solución sino que nos ayudará a comprender el problema. Lo principal es recordar que el perímetro de una circunferencia es pi * diámetro ó pi * 2 * diámetro.


Pongamos de ejemplo la vuelta de una rueda de bicicleta (el reflectante empiece en el punto más bajo y vuelva a estarlo). La distancia que ha recorrido la bicicleta es pi*diámetro. También, la rueda de la bicicleta, ha girado 360 grados. Es decir, para girar 360º hace falta recorrer el perímetro completo.


Ahora mirad el siguiente dibujo. Es nuestro tribot visto desde arriba y dibujado por un pintor abstracto. Los rectángulos de los lados son las dos ruedas del tribot y la circunferencia sobre las que están, es lo que tienen que girar para hacer un giro completo. Para que el tribot gire completamente sobre sí mismo, cada rueda tiene que girar volviendo a su posición original.



Nuestro fallo, es que hacemos que cada rueda gire 360º, es decir, pi*diámetro, cuando en realidad lo que tienen que recorrer es pi*distancia entre las dos ruedas,que es el diámetro de la circuferencia grande.

Ahora unas fórmulas que nos harán la vida más fácil y también la correspondencia entre grados, radianes y coordenadas polares.

Las veces que tiene que girar la rueda para volver al origen, o para recorrer 360º pi*distancia entre ruedas / pi * diametro rueda = distancia entre ruedas / diametro rueda.

Si queremos que el giro no sea de 360º sino de un número de grados en concreto, pues una regla de tres. Dividimos entre 360º para sacar lo que recorre en un grado y multiplicamos por n, número de grados. (distancia entre ruedas * número de grados) / (diámetro ruedas * 360º)

Sobre radianes y grados. En este enlace de la wikipedia, os lo contarán mucho mejor que yo. Pero recordad que pi radianes son 180º.

viernes, 30 de enero de 2009

derrotado otra vez

Retomando mi última creación.

Estaba totalmente seguro de que el problema era que las paredes estaban muy lejos, por lo que situaba al nxt en un entorno mucho más reducido (un "corral" hecho con libros), obtendría mejores resultados. También incluí algunas mejoras en el programa, como por ejemplo la normalización de datos

Nada más lejos de la realidad.

Esto es lo que detectaba si el robot estaba totalmente encerrado dentro de un cuadrado hecho de libros. Hay puntos repartidos por todo el contorno. ¡¡¡ Pero no equidistantes del centro !!!



Y esto lo que detectaba si quitaba una pared del cuadrado. En la parte de abajo de la gráfica no hay ningún punto detectado.



Como veis con mucha mucha imaginación ... algo se puede sacar. Pero visto que rodeando al robot con libros tampoco obtengo buenos resultados, voy a desistir de este modelo y cambiar la construcción del robot.

Lo único que girará será el sensor de rotación y extremadamente lento.

No obstante, esto me ha servido para probar la facilidad con que en matlab puedo representar gráficas, eliminar ruido, calcular medias ...

A ver si tengo tiempo y pongo un pequeño video del robot dando vueltas ... no hace nada, casi me da verguenza enseñarlo.



domingo, 18 de enero de 2009

primera aproximación a un robot que detecta su entorno

En este nuevo proyecto, quiero abordar la construcción de un robot que "vea" el entorno en el que se encuentra, e intente alejarse lo más posible de su punto de partida. Para ello aprovecharé el modelo de robot que presenté en este mismo blog y sustituiré el sensor de intensidad de luz por el sensor de ultrasonidos. El modelo resultante lo podeis ver aquí mismo.




El funcionamiento que tengo en mente es el siguiente: que el robot gire 360º sobre sí mismo a la vez que recopila información sobre su entorno mediante el sensor. Esta información es la distancia a los objetos que existen a su alrededor. 

Lo que pretendo es averiguar el punto que más alejado esté del origen y desplazar el robot hacía allí, y repetir el proceso otra vez. Teniendo en cuenta de que no vuelva por donde haya venido.

Este proyecto en nxtprograms hace algo muy similar a lo que yo quiero, por lo que bajaré el programa para el nxt-g y estudiaré las partes que me puedan venir bien.

Lo más interesante del programa es lo siguiente. Se puede ver que si se encuentra un objeto, a una distancia menor que un objeto que ya tuvieramos localizado, guardamos este nuevo objeto como el más cercano, a la vez que también guardamos la nueva posición.

Es interesante ver como la posición se guarda reseteando la cuenta de grados recorridos por el motor, de este modo al rotar el motor a su posición inicial tendremos el objeto más cercano delante.

También se puede ver como no hay ninguna medida estándar para que el robot gire 360º sobre si mismo. Haciendo pruebas he calculado que unos 600º de giro de una rueda equivalen a 360º del robot.





A continuación esbozo un pseudocódigo de lo que hace el robot mientras gira

variable distanciaMasLejana <- 0
variable gradosDistanciaMasLejana <- 0 

mientras el robot gira
variable valorRecogido <- recojo medición del sensor de ultrasonidos
si valorRecogido > distanciaMasLejana // es decir, hay un punto más lejano al que puedo ir que el que tenía almacenado
distanciaMasLejana <- valorRecogido
reseteamos motor
fin si
fin mientras el robot gira

Una vez que haya finalizado el giro del robot, en la posición inicial de giro tendremos el camino más largo para andar.

Teniendo en cuenta todo lo anterior ... vamos a entrar en harina. Un poco de matlab por aquí y por allá, un par de maldiciones ... y más o menos ya lo tengo. Antes de todo unas consideraciones

  • Como he hecho en robots anteriores, tomar varias medidas y luego hacer la media, no funciona aquí. Se podría pensar que si el robot en vez de dar una vuelta, diera cinco se tendría mucha más precisión. Se obtiene todo lo contrario. Como los grados que se recorren no son exactamente múltiplos de 360º, y el sensor está moviéndose contínuamente mientrasa hace mediciones ... a más vueltas, lo que se obtiene el que es robot está rodeado de todos los obstáculos.



  • Es bastante complicado interpretar el dibujo resultante. El que se ve a continuación es el del robot situado en medio de un pasillo. Con paredes cerca a los lados y paredes al principio y al final del pasillo que no se ven. Se puede ver que con cada ejecución del programa, obtenemos un resultado bastante diferente.




  • Voy a filtrar en el resultado los valores muy altos, para ello no voy a mostrar en el resultado aquellos valores que estén muy por encima de la media. Se puede ver como ahora el resultado es un poco más intuitivo.



  • Aqui vemos el resultado con una botella. La verdad es que no se ve nada ... por lo que deduzco que sólo podrá detectar objetos pequeños.



Más que suficiente para una entrada en el blog. Voy a titularla primera aproximación a un robot que detecta su entorno. Es una primera aproximación por que intuyo que esto no va a funcionar realmente.

  • Es incapaz de localizar objetos pequeños en distancias medias.
  • Los gráficos resultantes son extremadamente dificiles de interpretar.
  • A parte que hay como dos tipos de gráficos: unos con los puntos bien delineados y otros con grupitos curvados. Ignoro a qué se debe eso todavía.
  • El robot no puede girar excesivamente lento, ya que necesita algo de potencia para mover todo su peso. Esa es la razón de los gráficos tan extraños.

La solución podría ser cambiar totalmente el diseño del robot. Montando el sensor sobre un servo, que gire extremadamente lento y consiga unos resultados más precisos con muchas más mediciones por giro. Pero eso ya será en otra ocasión.

También este robot podría tener otro ámbito de actuación, como por ejemplo un laberinto de paredes estrechas. Sería interesante probar su desarrollo en un campo de esas características.

En la próxima entrada acabaré el programa, probaré el robot en varios entornos y subiré algún video.

Un saludo a todos.