Durante la OSHWCon se ofrecieron charlas, talleres, mesas redondas, exposición de proyectos personales. Pero principalmente fue un lugar de encuentro para profesionales y aficionados al mundo de la electrónica. La asistencia fue libre y gratuita, con lo cual ¡¡¡ cualquiera os podíais haber arrimado !!! Tenedlo en cuenta para años posteriores u os perderéis una de las, que yo creo que va a ser, más importantes convenciones que se realicen periódicamente en España sobre estos temas.

Destacar la presencia de David Cuartielles (co-fundador del proyecto Arduino) entre otras importantes presencias que pudimos disfrutar durante el evento.

Os recomiendo que echéis un vistazo a las ponencias que tuvieron lugar allí porque como os decía hubo algunas muy interesantes. Personalmente os recomiendo la de nuestro compañero de ARDE, Juan González, y su charla Robots libres e imprimibles.

Y tampoco quiero olvidar el magnifico taller de Pingubot que tuvo lugar en el evento, patrocinado por ARDE y dirigido por David Carmona y Fransico Reinoso (furri).

Mi compañero en el proyecto ROV/AUV y yo mismo asistimos como ponentes para mostrar a todos nuestro proyecto. Lo cierto es que la organización fue fantástica y nos trataron de maravilla. Aquí os ponemos el enlace de nuestra ponencia:

Todas las ponencias fueron grabadas, incluida la nuestra, y las podéis encontrar en :

- Charlas del Viernes 23

- Charlas del Sábado 24 (las de la mañana)

- Charlas del Sábado 24 (las de la tarde)

Muchas gracias a los chicos de Synusia por todo el esfuerzo y el magnifico despliegue de medios que realizaron.  Espero personalmente poder participar e incluso contribuir el año que viene de nuevo en el OSHWCon 2012.

En esta ocasión, pude disfrutar de la semana completa en el evento y fue  una experiencia realmente impresionante.

El espacio donde nos ubicamos los campuseros que íbamos a Campusbot estaba situado en el Agora. Que en general estuvo bastante bien, aunque de vez en cuando sufrimos problemas de climatización e incluso goteras que pudieron poner en peligro nuestros equipos el par de días que llovió torrencialmente en Valencia. Por lo demás, el espacio era realmente amplio y el edificio muy bonito. Mucho más, a mi modo de ver, que el Museo Principe Felipe donde se concentraron los modders y los gamers.

Una vista del interior del Agora y la zona Campusbot

Dos proyectos me acompañaron al evento, y fueron :

PartyBot: Que ya lo conocéis porque lo he comentado en algún post anterior y lo tengo listado entre mis proyectos. Que no pude exhibir todo lo que me hubiese gustado, dado que aún le falta algo de programación.

ROV/AUV subacuatico: Un proyecto que nació de una idea el año pasado en la Campus Party VLC 2010, y que ha nacido este año y empezamos a materializar. No he querido durante todo este tiempo comentarlo aquí, porque lo llevábamos medio en secreto, y las personas que formábamos el equipo han cambiado. Hoy dia ya es un proyecto abierto, y tenemos página web donde incluimos toda la documentación. Aún así, lo incorporaré a mi blog y a mi lista de proyectos en marcha a partir de ahora.

Si queréis más detalles sobre el proyecto, os aconsejo que os dirijáis directamente a la página.

Ignacio (derecha) y yo (izquierda) trabajando en el ROV/AUV en el area de CampusBot

Fueron muchas las personas que nos preguntaron, comentaron y aconsejaron como seguir adelante con el proyecto, a las cuales les agradecemos su apoyo y el haberse acercado a conversar con nosotros.

También tuvimos la oportunidad de mostrarlo ligeramente justo después de la magnífica ponencia de Pere Ridao, investigador de la universidad de Girona, que nos presentó el Proyecto RAUVI principalmente de entre otros varios proyectos desarrollados allí sobre ROVs. Realmente impresionante. Evidentemente para nosotros porque estamos muy metidos en todo esto de la robótica submarina últimamente.

Por supuesto, tengo que destacar la presencia de J.P. Mandon durante la mayor parte del evento, y los talleres entorno a Pinguino. Que fueron, yo creo, una de las estrellas del evento. Muy interesante todo lo que se mostró y las nuevas placas de Pinguino 32 bits.

Interesantisima la presencia de los chicos de Willow Garage. Tuve la oportunidad de charlar un rato con Melony Wise, y fue muy interesante escuchar de primera mano opiniones sobre ROS.

Además de esto, hubo innumerables charlas, talleres y exhibiciones, a cual más interesante sobre robótica y otras campos de la ciencia que yo recomiendo ver, aunque sea en los vídeos disponibles en la página de contenidos de CP. Tristemente la charla de Pere Ridao no fue grabada, por lo que no podemos verla allí.

Espero volver el año que viene, aunque no sé si podré estar durante todo el evento como hice este año.

¡Realmente constructivo!

Aquellos gráficos están creados en Google SketchUp, y por tanto he creado el modelo de Pinguino en ese formato.

La escala a la que he creado el modelo es 1:1.

Para aquellos que necesitéis generar algún modelo en 3D que incluya Pinguino, podéis ir a la galería de modelos de Google, y allí encontrareis este componente.

Aquí van un par de imágenes del modelo 3D:

Enviadme vuestros comentarios si deseais.

Saludos.

Este año vamos a tener la posibilidad de exponer, los socios que lo deseen, los proyectos que estamos llevando a cabo. Lo cual, desde mi punto de vista es una oportunidad de interacción muy buena para todos nosotros. Nos hace sentirnos parte y creadores de la propia asociación. Así que por mi parte, un aplauso para los organizadores y la junta directiva.

Personalmente, voy a intentar llevar alguna exposición sobre un par de proyectos con los que ando liado.

No, PRIS aún no. PRIS es la principal motivación de este blog, pero me van surgiendo muchos escollos por el camino, y otras oportunidades de proyectos, que me hacen desviarme del objetivo de crear PRIS. Pero por otro lado, creo que me van a aportar la experiencia necesaria para continuar con PRIS más adelante.

Los proyectos sobre los que hablaré serán:

- ROV/UAV subacuático: este es un proyecto que inicié el año pasado con un compañero, y cuyo objetivo es llevarlo a la Campus Party de este año 2011. Se trata de un vehículo autónomo/remotamente comandado (no teledirigido) para misiones submarinas. De momento no cuento nada en este blog, porque estamos haciendo una página aparte que de momento no está abierta a la web, donde contaremos todo. Y cuando digo todo, me refiero también a qué resistencias, condensadores y micros vamos a utilizar. Con todo detalle, vamos. Queremos que sea un proyecto abierto, que sirva de base para que otras personas interesadas en el tema. Y que con ello puedan desarrollar vehículos mejorados o los suyos propios, con las ideas que daremos al respecto.

- PartyBot: Este si lo he comentado aquí ya, y es parte de este blog. Aunque como ya sabréis, la documentación está en la wiki de ARDE, y el blog principal de los comentarios está en este otro sitio. Está prácticamente terminado. Como era un proyecto para ARDE, creo que será interesante contar lo que hay hecho, para que todos nos pongamos al día, por si también surgen nuevas inspiraciones al respecto.

En caso de falta de tiempo, mis prioridades sobre qué exponer, irán en ese mismo orden. Aunque espero tener tiempo para ambos.

Espero ver muchos robots, socios y no socios en el evento. Nos vemos allí.

Para más información sobre ello, podéis consultar el hilo público que hay en los foros de ARDE.

Hasta pronto.

En el artículo explico la causa del problema, y la solución. Si solo te interesa parchear tu IDE para que los retardos sean correctos ve directamente a la solución.

Problema con las funciones de retardos

Las funciones que existen para generar retados son 2 actualmente:

delay – Para generar retardos de milisegundos.

delayMicroseconds – Para generar retardos de microsegundos.

Estas funciones están codificadas en la librería <carpeta de pinguino>/tools/share/sdcc/include/pic16/arduinodelay.c , y producen los retardos debido a que iteran n veces la función delay100tcy(100), en el caso de delay, y delay10tcy(1), en el caso de delayMicroseconds. Ambas dos, están codificadas en el fichero delay.h y accesibles a través de la librería libpuf.lib.

La que establece la base de retardos es delay10tcy(), puesto que delay100tcy(100) itera 1000 veces la anterior.

delay10tcy() lo que hace es consumir exactamente 10 ciclos de instrucción.

Para Arduino esto es válido. Si tenemos un reloj de CPU de 10 MIPS (Mega Instrucciones Por Segundo), y llamamos a la función delay10tcy() generaremos un retardo de 10/ 10.000.000 = 1 microsegundo.

Sin embargo, el reloj de CPU de Pinguino no es de 10 MIPS. Pinguino trabaja con el xtal de 20MHz, pero el prescaler lo divide entre 5, lo cual da 4 Mhz, el PLL interno lo convierten en 48Mhz. Ese sería el reloj del sistema (CLK).

Para calcular el ciclo de instrucción tenemos que tener en cuenta que dada una de ellas llevará 4 ciclos de reloj del sistema, por lo que CLK / 4 = 48 / 4 = 12 MIPS.

Es decir, que cada ciclo de instrucción tarda en ejecutarse 83,333333 nanosegundos = 0,083333 us.

Si volvemos a tener en cuenta que la función delay10tcy(), veremos que esta genera 10 tcy X 0,083333 us = 0,8333 microsegundos. Es decir, que en lugar de tener un microsegundo de retardo, obtendremos mucho menos tiempo. ¡ Aquí tenemos el fallo en la precisión !

Solución, librería nueva de retardos.

La solución es simplemente recodificar la función delay10tcy() para que en lugar de consumir 10 ciclos de instrucción, consuma 12. La llamaremos delay12tcy(). De este modo, esta función generará 1 microsegundo exacto de retardo.

La función que itera 1000 veces a delay12tcy(), ahora se llamará delay120tcy(100), puesto que consumirá el tiempo de 12000 instrucciones, y así generará 1 milisegundo.

Estas dos funciones, codificadas en ASM, las compilo, y genero con los objetos creados un nuevo fichero de librería que llamo pinguinodelay.lib

Los nuevos ficheros de retardos, ahora son : pinguinodelay.h y arduinodelay.c (modificado para que incluya el fichero pinguinodelay.h).

Para habilitar estas funciones en el IDE:

En Linux:

Estos son las rutas de ubicación de estos ficheros:

    /tools/share/sdcc/lib/pic16/pinguinodelay.lib
    /tools/share/sdcc/include/pic16/pinguinodelay.h
    /tools/share/sdcc/include/pic16/arduinodelay.c

Los ficheros fuente asm no son necesarios pero es interesante guardarlos por si acaso:

    /tools/share/sdcc/lib/src/pic16/pinguinodelay/delay12tcy.S
    /tools/share/sdcc/lib/src/pic16/pinguinodelay/delay120tcy.S

Ve al apartado de descargas al final de este artículo para obtener todos estos ficheros.

Edita el fichero principal de python pinguinobeta9-05.py, y dentro del “def link(self)”, incluir una línea nueva (que puede ir justo debajo de la ya existente : “-llibm18f,” y añadir otra línea con “-lpinguinodelay.lib”, . Hay que respetar el indentado, y colocarla a la misma altura que la anterior.

Así es como quedaría el código de la función:

    def link(self,filename):
        # bug 02 replaced sys.path[0] by sys.path[0].replace(" ","\\ ") for path with spaces
        # jean-pierre mandon / guillaume stagnaro 2008/09/06
        # only for the linker !!
        if (self.debug_output==1):
            print("link "+self.processor)
        else:
            fichier = open(sys.path[0]+"/tmp/stdout", 'w+')
            sortie=Popen([sys.path[0]+"/tools/bin/sdcc",
                        "-o"+sys.path[0].replace(" ","\\ ")+"/source/main.hex",
                        "--denable-peeps",
                        "--obanksel=9",
                        "--opt-code-size",
                        "--optimize-cmp",
                        "--optimize-df",
                        "--no-crt",
                        "-Wl-s"+sys.path[0].replace(" ","\\ ")+"/lkr/18f2550.lkr,-m",
                        "-mpic16",
                        "-p"+self.processor,
                        "-l"+sys.path[0].replace(" ","\\ ")+"/lib/libpuf.lib",
                        "-llibio"+self.processor+".lib",
                        "-llibc18f.lib",
                        "-llibm18f.lib",
                        "-lpinguinodelay.lib",
                        sys.path[0].replace(" ","\\ ")+"/obj/application_iface.o",
                        sys.path[0].replace(" ","\\ ")+"/obj/usb_descriptors.o",
                        sys.path[0].replace(" ","\\ ")+"/obj/crt0ipinguino.o",
                        sys.path[0].replace(" ","\\ ")+"/source/main.o"],
                        stdout=fichier,stderr=STDOUT)
            sortie.communicate()
            fichier.seek(0)
            self.displaymsg(fichier.read(),0)
            fichier.close()
            return sortie.poll()

Ahora cuando se llame a las funciones delay y delaymicroseconds desde tu código y se compile, puede que aparezca el siguiente mensaje en la ventana de depuración:

link library pinguinodelay.lib
compilation done.

Lo cual es correcto.

En Windows:

En Windows es distinto que en Linux. Esto al menos lo he probado en la versión Beta 9.05.

Hay que copiar los ficheros a los siguientes directorios:

El fichero pinguino.lib:

    \tools\bin\lib\pic16\pinguinodelay.lib

Los ficheros arduinodelay.c y pinguinodelay.h :

    \tools\include\pic16\pinguinodelay.h
    \tools\include\pic16\arduinodelay.c

Y finalmente editar al fichero :

    \tools\link.bat

que es un fichero de una sola linea, y añadir el path de la librería (.lib), es decir el ya mencionado:

    %1\tools\share\sdcc\lib\pic16\pinguinodelay.lib

El contenido de este fichero debería ser exactamente este:

%1\tools\bin\gplink.exe -o %1\source\main.hex -I%1\tools\bin\lib\pic16 %1\lib\libpuf.lib %1\tools\bin\lib\pic16\libio%2.lib %1\tools\bin\lib\pic16\libc18f.lib %1\tools\bin\lib\pic16\pic%2.lib libsdcc.lib %1\tools\bin\lib\pic16\pinguinodelay.lib -w -s%1\lkr\18f2550.lkr %1\obj\application_iface.o %1\obj\usb_descriptors.o %1\obj\crt0ipinguino.o %1\source\main.o

De este modo los ficheros compilarán sin problemas.

Notas de uso de las nuevas funciones:

Si miras el fichero de definiciones, pinguinodelay.h, notarás que la función delayMicroseconds solo acepta valores de 1 a 255. Esto es porque el tamaño maximo del parámetro que se le pasa a la rutina en asm es de 1 byte. Así que si quieres conseguir un retardo de más de 255 microsegundos, debes de llamar a esta función varias veces seguidas en tu código. Por ejemplo, supongamos que necesitamos generar un retardo de 780 microsegundos. Lo más fácil sería hacer lo siguiente:

....
delayMicroseconds(250);  // un cuarto de milisegundo.
delayMicroseconds(250);  // segundo cuarto de milisegundo
delayMicroseconds(250);  // hasta aquí irían 750 microsegundos.
delayMicroseconds(30);   // y aquí el total de 780 microsegundos.
....

Para retardos mayores a 1 milisegundo, se puede utilizar la ya conocida función delay, ya que el parámetro de entrada de la misma es un unsigned long que nos permite un valor de hasta 4.294.967.295 milisegundos.

Tan pronto como este código se incluya en el IDE, no será necesario parchearlo de este modo.

Descargas:

Para descargar el fichero comprimido que contiene todos los ficheros mencionados en este artículo, visitad esta página de descargas.

Espero que os sea útil mientras no se integre esta librería en el IDE oficial de Pinguino.

Ha publicado las bases del concurso en su blog de momento en castellano. Pero el concurso es de alcance internacional, así que cualquier persona del mundo puede presentarse. Las reglas serán traducidas y publicadas en ingles también.No es necesario tener una PCB Pinguino para crear el proyecto, se admiten proyectos desarrollados sobre placas de prototipos o placas de pruebas. Lo importante es desarrollar un proyecto original, documentarlo y enviarlo para el concurso. Entre los premios, están PCB Pinguino completamente montadas y listas para usar diseñadas por ARDE, como la que aparece en la fotografía del blog de BoOps.

Puede que haya mejoras en los premios que se han propuesto de momento. Así que os aconsejo que no desestiméis la oportunidad de participar por el valor de los mismos.

Espero poder participar en este, porque al menos si que he desarrollado cosas últimamente con Pinguino.
A todos los que me leéis y/o seguís la evolución de Pinguino, os reto a que presentéis algo realmente interesante. Animo, que tenemos poco tiempo.

Por si alguien, aún no conoce lo que es una placa Pinguino, podéis visitar este enlace para haceros una idea.

De todos modos, en ARDE existe el blog de la Evolución del PartyBot que he ido alimentando personalmente con los pequeños pasos que hemos ido dando para su creación.

En un momento inicial, la idea para el sistema de control se quiso hacer entorno al PIC18F4550. Más tarde se crearon las PCBs donde se incluyó un dsPIC  24F. Pero se me hacía un poco cuesta arriba el programar este último microcontrolador, sobre todo porque necesitaba herramientas software y hardware que no tengo. En ese momento fue cuando conocí Pinguino, y se me ocurrió que sería una buena idea intentar adaptarlo para montarlo como controlador del PartyBot de ARDE.

Creo que el resultado es bastante interesante, y hace del PartyBot un robot que realmente puede ser utilizado para enseñar sobre robótica. Pinguino es muy fácil de programar en C, y permite que cambiemos el programa del robot con a penas 2 clicks. Es decir, rápido y sencillo.

Para los que estéis interesados en cómo lo hemos creado y queráis ver más datos sobre el robot, podéis ir a la Wiki de ARDE donde estamos documentandolo : Wiki del PartyBot.

Dado que recientemente he terminado de ensamblarlo, y ya está listo para jugar con el software,  he creado un par de vídeos de una serie que servirá para ilustrar lo que es el PartyBot y lo que se puede hacer con él.

Aquí os muestro el primero de ellos, sobre la estructura del robot:

Y este segundo vídeo muestra como empezar a programarlo, utilizado de momento tan solo los bumpers y los servomotores, para crear una rutina muy simple de movimiento del robot:

Espero que os guste, y que podáis al menos sacar alguna idea para vuestros robots.

Zenta Robotic Creations es como llama a su blog. Ahí podréis ver sus ingenios. Desde mi punto de vista, lo más impresionante de sus robots es la suavidad y elegancia de los movimientos de todos ellos. Solo hay que ver los vídeos de A-Pod para darse cuenta del trabajo que hay detrás.

Los sistemas de control remoto están muy bien elaborados, a la vista de lo que se puede ver en los vídeos de Zenta, y permiten manejar los robots de manera que son capaces de hacer esos movimientos tan naturales que podéis ver.

El caso de ARCher me ha impresionado mucho, porque como decía, andaba buscando ejemplos de robots bípedos, me encontré con él, y sus movimientos me dejaron boquiabierto. Había visto otros bípedos incluso en directo, pero la forma en que camina este prototipo es totalmente diferente.

La idea principal que saco de su arquitectura es el sistema de equilibrio, que se basa en el desplazamiento de una parte del peso del robot (se trata del peso de la electrónica de control y la batería) hacia los lados de su cuerpo. De este modo puede descargar una de sus piernas cada vez, levantarla del suelo y avanzarla, sin perder el equilibrio. Un servo que se encuentra bajo la plataforma de aluminio es el que posiciona ese peso sobre el lado izquierdo o el derecho. No se si me he explicado, pero como un vídeo vale más que mil palabras aquí tenéis la demostración de sus movimientos.

Impresionante, ¿ no ?

Como ya sabéis URBI es una librería que se puede utilizar con un sistema operativo robótico como ROS, y de la que se puede sacar mucho partido. Ver el articulo de este mismo blog: “URBI : Un API para robótica”.

Pues ahora Gostai ha decidido crear un concurso donde podéis presentar proyectos que hagan uso de URBI.

Para participar tan solo hay que rellenar un formulario gratuitamente, y enviarles la descripción de vuestro proyecto, junto con un vídeo(obligatorio) u otras referencias, además, por supuesto, del código que se haya creado para dicho proyecto, que utilice las librerías de URBI.

Los proyectos no tienen que ser dedicados exclusivamente a aplicaciones robóticas. Y si lo estuviesen tampoco tienen porqué estar destinados a robots reales, sino que pueden hacerse sobre simuladores. Aquí tenéis los robots y simuladores que actualmente usan URBI.

Gostai remarca que preferiblemente el proyecto no debe estar apoyado en software de pago.

Y según describen te permiten utilizar gratuitamente  Gostai Studio Suite hasta el final del concurso. Que incluye las herramientas gráficas Gostai Studio y Gostai Lab.

El plazo de inscripción es del 15 de Septiembre al 15 de Diciembre.

Los premios son los siguientes:

1er puesto:

• Un vale de 400€ para compras en Robopolis.
• Una licencia completa para Gostai studio suite valorada en 2990€
• Una licencia Pro Webots que incluye Urbi para Webots valorada en  2990€
• Un descuento de 500€ en Nao Developer Program y acceso a Developer Program
• Una camiseta Gostai valorada en 15€
• La publicación del proyecto en www.urbiforge.org
• Una suscripción gratuita por un año a la revista Planète Robots (6 números)

2do puesto:

• Una licencia completa para Gostai studio suite valorada en 2990€
• Una licencia para URBI de Edu Webots valorada en 399€
• Acceso a Nao Developer Program
• Una camiseta Gostai valorada en 15€
• La publicación del proyecto en www.urbiforge.org
• Una suscripción gratuita por un año a la revista Planète Robots (6 números)

3er puesto:

• Una licencia completa para Gostai studio suite valorada en 2990€
• Acceso a Nao Developer Program
• Una camiseta Gostai valorada en 15€
• La publicación del proyecto en www.urbiforge.org
• Una suscripción gratuita por un año a la revista Planète Robots (6 números)

Y aquí van las bases del concurso en francés e inglés.

No sé si me dará lugar a intentarlo. Tengo muy poco tiempo libre de aquí al 15 Diciembre.

Pero seguro que alguno de los que leéis esto tenéis algo que presentar.

¡¡ Ánimo !!

Me ha resultado interesante, sobre todo, después de haberme planteado mis propias dudas sobre robots móviles debido a mi trabajo en el proyecto PartyBot, y también después de haber leído el interesantísimo libro Robot Programming de Joseph Jones (del que dentro de poco escribiré un articulo también en este blog).

Estasis (que no éxtasis), traducido del termino ingles “stasis“.
Porque según la RAE:

Estasis .- (en Medicina) Estancamiento de sangre o de otro líquido en alguna parte del cuerpo.

Éxtasis .- 1. Estado del alma enteramente embargada por un sentimiento de admiración, alegría, etc. 2. m. Rel. Estado del alma caracterizado por cierta unión mística con Dios mediante la contemplación y el amor, y por la suspensión del ejercicio de los sentidos. << esta no es la definición que nos aplica.

…porque el detector de estasis o detector de estancamiento (otra acepción valida de traducir “stasis” al castellano) pretende proporcionar al robot la capacidad de detectar cuando se ha quedado atrancado o estancado, cuando el resto de sus sensores no le da ninguna información al robot sobre esta situación, y “engañado por sus sentidos” sigue intentando ejecutar una tarea que nunca conseguirá cumplir.

Pongamos por ejemplo un caso extremo, un robot móvil de dos ruedas (similar al PartyBot). Este en su actividad normal de desplazarse por una habitación, podría quedarse enganchado en una alfombra o similar, de modo que ninguna de sus ruedas tocase el suelo. Y podría ser que siguiera energizando sus motores, creyendo que está avanzando, porque sus sensores de giro de las propias ruedas le informan de que estas siguen girando normalmente. Y tampoco los sensores de proximidad de infrarrojos o los detectores de colisión (bumpers) le informarían de cambios en el entorno, puesto que no se mueve. Así que lo que el robot entiende es que estaría avanzando con normalidad. Luego con este conjunto de sensores no habría posibilidad de detectar la situación real de estancamiento en la que se encuentra el robot. Finalmente, no conseguirá completar su tarea, a pesar de que “él lo cree” así, sino que lo que realmente conseguirá será agotar sus baterías sin haberse movido ni un ápice.

Me he puesto en contacto con Chris Dawn, el autor del articulo sobre “la lógica del estasis”, y me ha concedido permiso para traducirlo al castellano y reeditarlo aquí, en mi blog junto con sus fotos. De modo que muchas gracias desde aquí a Chris, y no dudéis en dirigios a su web en caso de que queráis ver la versión original en ingles, u otros artículos interesantes sobre robótica.

Lógica del Estasis

por Chris Dawn.

PicBot IV en la arena robótica, lista para la prueba y la programación del estasis. Mi gato T'Pring se divierte mirando al pequeño robot como se mueve y salta de vez en cuando en él.

Introducción

En el entorno de un hogar un robot encontrará muchos obstáculos que podrá detectar y evitar fácilmente con los sensores de proximidad estándar de IR, o si va equipado con un sistema de detectores de colisión. Sin embargo, hay numerosas situaciones en las cuales el robot se atascará o se enredará, que no detectarán estos sensores. Los sensores de estasis cubren este vacío de información sensorial tan importante, y permitirán al robot intentar escapar para liberarse a si mismo y continuar con la tarea asignada. En este articulo, discutiremos métodos para la detección de estasis, y la programación de comportamientos asociados para su uso en un robot para el entorno de un hogar.

Uso detallado

En nuestra experiencia, cada robot para el hogar que hemos construido que no tenía un sensor de estasis, en cuestión de unas horas se quedaba atascado en las esquinas de los muebles, en una alfombra o en un simple cable eléctrico, sin importar lo bien construido que estuviese. La propia naturaleza del entorno del hogar presenta dificultades que no siempre podemos prever para todos los casos. Los robots para el hogar tienen generalmente dos modos de operación: Ejecución de una tarea, y desplazamiento hasta la localización donde tiene que realizar esa tarea. Éstas pueden definirse como una arquitectura de comportamientos en capas, tales que al desplazamiento hacia y desde un objetivo se puede acoplar en capas con el comportamiento del estasis en el nivel oportuno. Un ejemplo simplificado de esta arquitectura puede ser un comportamiento para “Deambular” en la capa inferior, en el nivel superior a este, el comportamiento para el “detector de colisión”, después un comportamiento para el “estasis”, y finalmente, la tarea primaria tal como agarrar una lata de bebida del refrigerador como capa superior. Con este tipo de arquitectura, si el robot se queda atrapado de camino al refrigerador y los sensores de colisión no detectan un impacto, el comportamiento de estasis entrará en juego e intentará para liberar al robot.

Técnicas para detectar el estasis

Aquí discutiremos diversas técnicas para detectar el estasis, y los problemas que aparecen con cada método.

Rueda de estasis

Éste es nuestro método preferido de detección de estasis. El concepto implica colocar una pequeña rueda en la parte inferior o detrás del robot, con un sensor óptico o mecánico para detectar la rotación. Según el robot ruede hacia su objetivo, la rueda también dará vueltas midiendo la distancia de desplazamiento y el sentido de la marcha. Codificando la rueda con líneas blancas y negras o agujeros podemos especificar mecánicamente la distancia mínima que la rueda debe girar para indicar una detección. Por ejemplo, para una rueda de 1 pulgada de diámetro con una circunferencia de 3 pulgadas, poner dos agujeros a 180 grados indicará que se desplazó una distancia mínima de 1.5 pulgadas. Esta táctica llegará a ser importante más adelante en nuestra discusión.

Sensor óptico de suelo

Un método obvio para la detección de movimiento es medir simplemente el brillo de un haz de luz reflejado sobre el suelo directamente debajo del robot. Esto se puede lograr fácilmente con un LED rojo que proyecta un círculo de una pulgada de diámetro encendido hacia el suelo, y mirando hacia esa área un fototransistor. Mientras que el robot se mueve sobre un suelo con cierto patrón tal como un suelo de madera o una alfombra, la reflectividad cambiará. Una gran desventaja de este método es que si el suelo es homogéneo o sin rasgos distinguibles, el sensor de estasis reportará una condición de estancamiento. También, incluso con un suelo irregular, se tendrá que utilizar de cierta forma un tiempo de integración para modelar los datos y sacar un patrón de variación continua sin picos. También ocurre muchas veces que el robot se enreda en un cable eléctrico, y el cuerpo entero del robot oscila hacia adelante y hacia atrás según intenta moverse. En estas condiciones el sensor óptico detectará que el robot sigue estando en movimiento, y no una condición de estancamiento.

Sensores de distancia IR

Otro método interesante es monitorizar la distancia a los objetos y a las paredes próximas. Si la distancia está cambiando constantemente, es porque el robot está en movimiento. Pero, sin embargo, además del problema de oscilación en el caso de enredo con el cable que comentábamos antes, en habitaciones más grandes el sensor podría no ver las paredes, e intentar escapar de … nada.

Sensores de distancia por sonar

Similar al caso del sensor de distancia IR, pero con mucho de más alcance. La mayoría de las habitaciones no serían un problema para este método de detección, y además puede proporcionar una cierta capacidad para evitar colisiones. El principal problema con este método es que su coste es alto.

Detectores visuales

Se puede utilizar una CMU Cam como detector del estasis, mientras haya suficiente contraste en la habitación para ver los objetivos móviles. Según el robot se acerque a una pared o a un obstáculo distante, el histograma cambiará continuamente. Esto también se puede utilizar para la detección del estasis, sin embargo el cómo fijar el umbral para establecer la condición de escape no está claro en absoluto. Éste es probablemente el método más costoso y complejo de los comentados.

Fotocélulas de luz visible

Pon un fototransistor en un tubo corto, y haz que apunte hacia delante. Según el robot se mueva, la salida variará. La integración de tal señal puede ser problemática, no obstante en una habitación con suficientes contrastes esta sería la solución sería viable y mas barata.

Sensor de campo magnético

Utilizar una brújula electrónica puede funcionar especialmente bien en un ambiente al aire libre. De precio moderado, según el robot se mueve, la brújula variará su ángulo de la salida. Un trayecto en línea recta naturalmente sería un problema, no obstante los pequeños cambios que ocurran mientras el robot se desplaza sobre rocas y otros obstáculos podrían ser detectados por el robot.

Detección de estasis mediante programa

Ésta es la solución más barata de todas, no obstante tiene un tiempo de reacción extraordinariamente lento. Aquí el área de trabajo del robot tiene un tamaño limitado, y por lo tanto si el robot no choca con ningún obstáculo al cabo de varios minutos de desplazamiento, pues se asume que probablemente esté atascado. Se puede basar en cualquier otro sensor que detecte una condición de impacto. Si no hay impactos durante un tiempo, se asume la condición de estasis. Aunque aparentemente sea barato y sencillo, el robot podría quemar sus motores durante los minutos que se tarde en entrar en la condición de estasis y ejecutar la rutina de escape.
Los robots aspiradoras baratos utilizan este método y pasan más tiempo atascados ¡que haciendo su trabajo!

Rueda de estasis: Diseño mecánico

El diseño mecánico básico es sencillo en si mismo, como se ha comentado. Hay varias maneras de implementar este diseño mecánicamente. Una técnica usada en nuestros robots Ostracode y PAAMI es un puntal en voladizo que sujeta a una rueda y la mantiene en contacto con el suelo, permitiendo el movimiento arriba y abajo de manera que en superficies desiguales el brazo pivote. Se monta un fotointerruptor en el brazo, para captar los sectores oscuros de la superficie de la rueda transparente. En PicBot IV, implementamos este concepto de una manera mucho más simple y una escala más pequeña para que se ajustase a los parámetros físicos del pequeño diseño del robot. Aquí, según se puede ver en las imágenes (ver más abajo), la rueda de fricción se monta directamente sobre un soporte con el optointerruptor muy cerca de ella, y con una hoja curvada de lexan como brazo, que actúa como resorte y presiona la rueda firmemente sobre el suelo. Este diseño fue fácil de montar, el brazo curvado era una tira de lexan doblada con los pequeños alicates con la forma requerida, dado que el lexan se puede doblar y no se rompe como el acrílico.

Aquí se pueden ver mecánica básica del sensor de estasis de PicBot IV. Esta es una vista frontal que muestra la rueda en contacto con el piso entre las ruedas motrices.

Aquí vista lateral muestra el puntal curvado de lexan el cuál lleva el optointerruptor, y aplica a una presión constante la rueda sobre el piso.

Vista frontal que muestra la fina rueda de estasis en contacto con el suelo.

Aquí estoy presionando sobre la rueda para mostrar que es el soporte curvado de lexan el que actúa como un resorte y hace que la rueda estén continuamente en contacto con el suelo.

Aquí está la rueda de estasis de nuestro robot de Ostracode. En ella utilizamos un disco negro con los agujeros perforados para que el sensor los detecte.

El sensor de estasis de Pammi es del tipo reflexivo y utiliza un sensor reflexivo de IR con una onda de salida de forma sinusoidal. Esta salida lo llevamos a un una puerta Schmidt para dar forma a la onda.

En el banco de prueba, hicimos girar la rueda de estasis a aproximadamente la tasa de rotación prevista con un pequeño motor para probar la forma de onda y su frecuencia de la salida.

Aquí se ve la señal de salida que practicamente va de 0V a 5V (2v/div.).

Dependiendo de cómo detectes la rotación de la rueda de estasis, se determinará la electrónica del interfaz. En Paami, utilizamos un módulo optoreflector de Fairchild QRB1114 y detectamos la reflexión del IR sobre una rueda codificada en sectores blanco y negro impresos. Esto requirió no sólo un amplificador operacional LM324 como buffer de la señal, sino que fue seguido de un disparador de Schmidt para conformar la onda antes de enviarla al procesador. Puedes hacerlo así porque ofrece una gran flexibilidad o como alternativa mucho más simple, hacer tu rueda de estasis fina y transparente de manera que puedas utilizar un fotointerruptor que quepa en la rueda. Utilizamos este método con PicBot IV, y con una resistencia de pull-up para la unidad NTE 3100 que proporcione niveles TTL sin buffering. Lo mejor es que con la mayoría de los procesadores PIC, tienen entradas con disparador de Schmidt ya incorporado, y conformarán automáticamente este tipo de forma de onda en una casi cuadrada para facilitar la interconexión. Para otros procesadores, sin entradas de Schmidt trigger, puedes agregar un circuito integrado 7414 con puertas Schmidt triggers, utilizar una de ellas y aprovecha las otras para otros usos.

Consideraciones de programación.

Afortunadamente, programar la detección de estasis es bastante directa. Esencialmente consiste en un autómata finito con dos estados primarios: Exploración y Escape. Durante el estado de la exploración, el sensor de estasis es interrogado continuamente para determinar una condición atasco. Esto se hace simplemente contando las transiciones durante un pequeño intervalo de por ejemplo 5 segundos. Si durante ese tiempo, la cuenta cae por debajo del valor previsto o es cero, se cumple la condición de atasco, y ésta es la condición de disparo para ir al estado de escape del estasis.

Para escapar del estasis, la idea general es invertir el sentido de movimiento durante una pequeña cantidad de tiempo y girar lejos del punto de disparo. La rutina más acertada que hemos utilizado en el ambiente de una casa es hacer un movimiento alternado de cada rueda hacia atrás. Aquí, movemos una rueda por vez de manera sucesiva, para escapar del cable de la lampara o del hilo de la alfombra en el que estamos atascados. Después de unos cuantos centímetros hacemos que el robot rote un angulo aleatorio para no reentrar en la condición de atasco de nuevo. Si el sensor de estasis se dispara una vez más en un margen de tiempo pequeño, podemos intentar escapar de nuevo o pedir ayuda y hacer que el robot se autodesconecte. Además, podemos añadir al procesador encargado del estasis una salida para informar de la condición de estasis a otros procesadores, tal que otros procesadores superiores de la arquitectura puedan utilizar esta información sensorial para tomar decisiones a más alto nivel.

Pruebas y evaluación

Nuestro campo de pruebas se utilizó para para la evaluación preliminar, y después el entorno de una casa real, tanto con suelos irregulares como suelos alfombrados. Aquí va un video del entorno de pruebas. Aquí puedes ver a PicBot funcionando sobre obstáculo muy fino (tablero de la espuma) y quedarse parado aunque las ruedas siguen girando a toda velocidad. Después de 3 segundos, el robot decide que está en una condición del estasis, y se parada, hace el sonido correspondiente, y después se aleja del obstáculo con movimientos alternos y hacia atrás de cada rueda. Entonces gira aleatoriamente, y continua moviéndose.

En el entorno de la casa, el robot funcionó muy bien tanto en suelos de azulejos, madera y alfombra. Al contrario que sobre superficies lisas en las que las ruedas se deslizan más fácilmente, en las alfombras se quedan atascadas casi inmediatamente tras impactar, así que podría ser interesante acortar el tiempo de 3 segundos para la condición de estasis.

Conclusión

Nuestra prueba y los datos a partir de nuestros dos robots caseros Ostracode y PAAMI fueron muy positivas anteriores, y han demostrado sin lugar a duda que un sensor del estasis es absolutamente esencial para hacer que el robot consiga salir de diversas situaciones en las cuales ningún otro sensor detectaría un problema. Es una añadido muy simple a considerar para tu propio robot, y con el cual obtendrás un robot que andará por tu hogar durante horas, o más bien durante días sin acabar atascado en cualquier alfombra, cable o la esquina de un mueble.