servo.setMaximumpulse (pin, pulsomaximo)

Donde pin, es el numero de pin donde tenemos conectado el servo.

y pulsomaximo, es el valor en microsegundos del ancho máximo del pulso que admite nuestro servo. Este valor no puede ser superior a 2500 microsegundos.

servo.setMinimumpulse (pin, pulsominimo)

Donde pin, es el numero de pin donde tenemos conectado el servo.

y pulsominimo, es el valor en microsegundos del ancho máximo del pulso que admite nuestro servo. Este valor no puede ser inferior a 500 microsegundos.

De este modo establecemos cuales serán las posiciones mas extremas de nuestro servo. Si vamos a la hoja del fabricante lo podemos ver, y programarlo de acuerdo a ello.

Así vamos a establecer la siguiente relación:

- El ancho del pulso máximo, para que el servo se posicione a 180 grados.

- El ancho del pulso mínimo, para que el servo se posicione a 0 grados.

Por poner un ejemplo, vamos a utilizar un servo en concreto. Miramos la hoja de datos de un servo (podéis utilizar esta recopilación de datos que tenemos en ARDE: http://wiki.webdearde.com/index.php?title=Actuadores_II#Servomotores), por ejemplo, vemos que el fabricante del TowerPro SG-5010 dice que el mínimo pulso que admite es de 700 microsegundos (posición de 0 grados) y que el máximo es de 2250 microsegundos (posición de 180 grados). De modo que ahora con estas funciones podemos introducir en nuestro programa para pinguino los valores adecuados para dichos extremos de posición del servo.

Imaginemos que queremos conectar nuestro servo al pin 1 de nuestra placa pinguino:

setup {
  servo.attach(1)
  servo.setMaximumpulse (1, 2250);
  servo.setMinimumpulse(1,700);
}

Con eso ya tendríamos el servo correctamente definido para empezar a trabajar con él.

Además de la modificación de esas 2 nuevas funciones, he cambiado la función servo.write, y ahora lo que admite como parámetro de posición del servo son grados. De modo que en el cuerpo de nuestro programa principal podemos seguir con el ejemplo anterior del servo conectado al pin 1 y lo que tendríamos sería algo así:

loop {
  servo.write(1,0); // posicionamos el servo en 0 grados.
  delay(1000);  // retardo de 1 segundo.
  servo.write(1,90);  // movemos el servo a su posición central.
  delay(1000);  // retardo de 1 segundo.
  servo.write(1,180);  // movemos el servo a su posición central.
  delay(1000);  // retardo de 1 segundo.
} // fin del bucle principal.

Además de todo esto, tened en cuenta que podéis utilizar las siguientes Pinguino boards para trabajar con la librería de servos. De momento son todas de 8 bits. Ninguna de 32 bits aún:

• Pinguino generica con 18F2550 (posibilidad de controlar hasta 18 servos simultáneamente)
• Pinguino generica con 18F4550 (posibilidad de controlar hasta 29 servos simultáneamente). Para utilizar todos los pines disponibles tienes que añadir al principio de tu programa la directiva de compilación:

#define 18F4550

• Pinguino PIC UNO EQUO. (posibilidad de controlar hasta 14 servos simultáneamente). Para utilizar todos los pines disponibles tienes que añadir al principio de tu programa la directiva de compilación:

#define PICUNO_EQUO

Con esto creo que podréis sacar partido de las modificaciones de la librería.

¡ Observad que con una Pinguino genérica con 18f4550 disponéis de 29 pines para manejar servos simultáneamente !  Sinceramente estoy tentado de hacerme un hexápodo o un humanoide con esto, porque son muchos servos los que se pueden controlar de este modo. Os animo a que probéis. Si lo hacéis, no dudéis en escribirme.

Saludos!!

Si queréis más información sobre como está hecha la librería, os invito a que miréis directamente el código, que ya está en los repositorios de google code, la he subido a la release 322 del código:
http://code.google.com/p/pinguino32/source/browse/trunk/p8/include/pinguino/libraries/servos.c

Editado el 30 de Agosto del 2012:

Dado que los repositorios no tienen fácil acceso para todos, os lo pongo también en la página de descargas de este blog.

Este concepto, “programación de robots basada en comportamientos”, es aparentemente simple, pero requiere ser explicado con detalle y buenos ejemplos para ser comprendido con facilidad. Y eso es lo que hace Joe Jones, a mi modo de ver, a la perfección, en este libro. Las explicaciones son muy sencillas y claras, y desde el capítulo 1 va introduciendo los conceptos en un orden perfecto para que pueda ser entendido rápidamente y se pueda avanzar hacia conceptos un poco más complejos.
Joseph Jones es uno de los colaboradores en la creación de Roomba, el famoso robot aspiradora que habita ya muchos hogares. Todos los temas que se pueden leer en el libro aseguraría que fueron utilizados de un modo u otro en la programación de ese magnifico robot.

La programación orientada a comportamientos de los robots es, como Joe describe en sus primeros capítulos, un método sencillo que no tiene nada que ver con complicados algoritmos que requieren grandes potencias del calculo (P.ej. PIDs). Se trata de identificar y determinar tareas simples que el robot debe llevar a cabo, y completarlas mediante el uso de ciertos dispositivos de entrada (sensores) para realizar una acción con sus dispositivos actuadores.

La definición de estas tareas simples es básica, puesto que estos son los comportamientos a los que se refiere el título. Estas están latentes en el comportamiento del robot en todo momento. El momento en que estas tareas entran en funcionamiento dependen de las entradas que se definan requeridas para cada tarea(comportamiento). Si para completar la tarea se define en ella el uso de ciertos actuadores del robot, entonces el sistema debe permitir el uso de estos actuadores por parte de la tarea. Pero es posible que más de una tarea compita por el uso de un mismo actuador. En ese caso, en la programación orientada a comportamientos se define en el sistema un elemento llamado arbitro que es quien decide qué tarea de entre todas ellas entra en cada momento a hacer uso del actuador o recurso del robot. Es

Este es el modo en que se generan comportamientos más complejos a partir de un conjunto de comportamientos simples. De este modo, el comportamiento global del robot, el resultado final, podría verse como más complejo, y quizá manifieste ciertos rasgos de inteligencia desde el punto de vista de los seres humanos.

Además de ello,  introduce otros conceptos importantes en este tipo de programación de robots como por ejemplo:

- Sensor quialification ( o lo fiable que puede ser un sensor para nuestro sistema, es decir,  forma en que un comportamiento “no ideal” o erratico de un sensor puede afectar al comportamiento total del sistema )

- Graceful degradation ( o degradación del sistema de manera “elegante”  cuando los sensores y/o actuadores no se comportan como debieran )

- Tipos distintos de árbitros que pueden programarse en un robot cuando utilizamos la programación orientada a comportamientos.

Por supuesto,  el libro es de gran ayuda en la definición de los comportamientos y como programarlos, aunque se mueve a nivel conceptual. La implementación es valida para cualquier sistema controlador en principio. Y en todo caso los ejemplos de código vienen dados en C.

Dentro del libro vienen ejemplos muy clarificadores y de gran ayuda para entenderlo todo. Además podréis encontrar dentro la dirección de una página web, donde mediante un applicativo Java, se puede simular el comportamiento de un robot, seleccionando los tipos de comportamientos predefinidos, y eligiendo el tipo de árbitro que queramos. Y después ver de que forma ese robot virtual se comporta.

Desde mi punto de vista, una joya de libro y un conjunto de magnificas de ideas las que se explican en él. Y aunque algunos de los que me leéis no dominéis el ingles, os aseguro que merece la pena intentar leerlo y comprenderlo.

Disfrutad!

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 ?