Trasteando con la Raspberry Pi - Inicio

Ya esta en casa, después de un tiempo esperando -no puede pedirla en la salida inicial, como tantos otros- me ha llegado la tan esperada Raspberry Pi.
He de decir que el aspecto exterior es el de tantas otras placas de desarrollo, pero destaca que lo que mas espacio ocupa son los conectores -la placa es pequeña pero tiene todos los conectores estándar-

El objetivo de la RPi es, por supuesto, hacer un robot.
Es un procesador de verdad, que corre linux, tiene puertos estándar (usb, ethernet, audio..) que pesa poco, ocupa poco y consume poco. Por tanto es ideal para ponerle ruedas o patas o lo que sea y dejarlo pasear por la casa usando webcams normales, enlazado vía Wifi, etc. Se podría hacer todo eso con otra plataforma, si, tan fácil y por el mismo dinero, no creo.

Ponerla en marcha es inmediato, se baja la imagen de Debian que tienen en la pagina, se graba en una SD, enchufas y listo, tienes un PC en el tamaño de una tarjeta de crédito.

Lo primero ha sido conectar la RaspberryPi a internet. Con cable no hay problema, si hay cable enchufado al arranque lanza todo lo necesario, no hay que tocar nada.
Con Wifi... debe ser que los lapicillos usb-wifi que tengo rondando por casa son de los que dan guerra, porque siempre tengo que bajarme algún firmware y pegarme un rato con el wpa_supplicant -nunca me acuerdo de como lo hice la vez anterior-.

/* voy a dejarlo aqui para la proxima vez
--> Para el firmware
... el lapicillo de belink que al enchufarlo lo identifica como un ZyDAS zd1201 no fona con wpa2 ( bajando y montando el firmware se queja en el momento de conectar )
... el lapicillo de 3COM que se identifica como ZyDAS1211
hay que bajar el firmware, que viene como paquete: $ sudo apt-get install zd1211-firmware
--< hasta aqui el firmware

--> para configurar el wifi con wpa2
modificar /etc/network/interfaces para que la parte de wlan0 quede tal que...
iface wlan0 inet dhcp
        wpa-ssid "ssid"
        wpa-psk "pass"
puede que no sea lo más bonito pero si lo más facil, no hace falta tocar el wpa_supplicant.conf ni na.
--< hasta aqui la config
*/


Además de eso con la RPi hay que poner un cuidado extra con la alimentación del USB. Se puede leer que el uso de un hub-usb con alimentación externa es recomendable ... yo diría que necesario.
Los tres usb-wifi que tengo rondando por casa, una vez instalados sus firmwares y demás requisitos se encienden  al conectarlos a la RPi sin otra alimentación. Se encienden encuanto a que funcionan, linux los reconoce, puedo hacer un scaneado de puntos de acceso disponibles ... pero no se enlazan, ninguno de ellos.
Probablemente sea que tienen potencia para recibir, pero no para emitir, porque fue enchufarlos a un hub-usb con alimentación externa y los tres funcionaban sin problemas.

Nuevo material = Nuevo robot

Yo no quería ... no tenía intención ... pero no pude evitarlo

El otro sábado tocaban compras y, entre otros, pasamos por un LM. Fuí a ver si tenían una plancha de pvc , sin suerte, pero encontré las planchas de metacrilato/plexiglass/-nombre propio de LM- y como no eran muy caras compre la más sencilla para probar -había leído que se podían trabajar con sierra y doblar con el calor de un mechero-

La plancha de 2.5mm que compre es bastante blanda, solo sirve para piezas no muy grandes, pero hay que admitir que se trabaja muy muy bien con una sierra de marquetería y con el calor de una vela y un poco de arte se puede moldear al gusto. Además al doblarla, como con el cartón, puedes darle mucha más solidez.


Aunque no se me había ocurrido de antemano, tene una ventaja sobre otros materiales... es transparente. Eso implica que puedes diseñar en el ordenador, sacar una plantilla de las piezas por la impresora, poner el plexiglass encima y copiar sin ningún esfuerzo :) ideal para transportar formas curvas, posicionar los agujeros, etc.


Y como este invierno se ha abierto la veda de bípedos, pues otro más, aunque este es chiquitín, que el de cartón es muy grande y un poco incomodo de trastear.
Como sigo sin encontrar un material con el que hacer un sensor de presión fácilmente -miento, quiero probar el Velostat, pero no quiero comprar un rollo de 100m- pues mientras hago cuerpos.

Aunque no es tán calido de aspecto como el de cartón, creo que este otro bicho es también bastante agradable, el plexiglass tiene buen aspecto.



Este chiquitín -poco más de 15cm- tiene 8 grados de libertad  -2 en la cadera, 1 en la rodilla y otro en el tobillo-, dos menos que el guerrero de cartón -que tenía 2 en el tobillo- , pero sigue siendo completamente actuado para suelos horizontales. Eso es gracias a que el eje x -frontal- del plano del pie es siempre paralelo al eje x de la cadera, de ahí esos segundos elementos articulados en la pierna que se pueden ver en la foto de perfil.

Se puede ver esta vez que los pies están mucho mas juntos, por lo que no hay que mover la cadera tanto para mover el centro de masas de pie a pie -sigue siendo equilibrio estático, pero ya tengo la idea para  el equilibrio dinámico .. a ver cuando tengo tiempo-
De nuevo, como en el Guerrero de Cartón, los servos están lo más arriba posible -solo uno en el pie- para que el movimiento de la cadera respecto al movimiento del centro de masas resulte más efectivo.

El principal cuidado que hay que poner en estos montajes son las holguras, tanto por la flexibilidad del material como por el exceso de diámetro o distancia entre los agujeros de las articulaciones, muchas veces es mejor hacer un agujero pequeño y roscarlo -aunque se quiera que gire libre-.

Intento fallido

Una tarde que mejor no salir + 6 mini servos sin usar = un engendro improvisado


La plataforma Steward siempre me ha llamado la atención y con 6 servos a mano esa tarde trate de hacer un híbrido de Steward y bípedo, pero sin gran éxito.

El principio no es malo, pero las articulaciones de las rodillas son chapuceras y tiene mucha holgura -eso pasa la improvisar- además de que los servos son de los mini y bajo par.

Moverse se mueve, pero duele con solo oír como se quejan los servos constantemente, así que este bicho será despedazado y en algún otro momento, con mas planificación, haré uno mejor.

Mientras tanto aquí queda la memoria de un robot efímero.

Guerrero de cartón

Este ha sido mi proyecto de Navidades, llevaba algún tiempo pensando en hacer un bípedo, incluso tenía ya pedidos unos servos de 15Kg-cm de par para tal ocasión, pero claro, siempre falta tiempo, diseño etc.

El diseño lo he ido haciendo a ratos muertos a lo largo de un tiempo .. aunque luego, cuando empece a construir, el diseño cambio según vi como iban encajando las cosas. La adaptación cuando se dispone de herramientas de baja tecnología es fundamental.

Y hablando de baja tecnología, una de las cosas no previstas pero que que he descubierto a lo largo de la construcción de este robot es el uso del cartón.
La idea inicial era hacerlo de aluminio fino ... es durillo de trabajar a mano pero es un buen material.
Antes de ponerme con las piezas finales, como había un par de articulaciones que no terminaba de ver, decidí hacer algún prototipo a escala real y así ver esas piezas en duda. La casualidad quiso que tuviese el fondo de una estantería billy -de las de ikea- en el cuarto en espera de ser tirada a la basura.
Como el fondo es de cartón duro, de unos 3mm, corte un trozo para las pruebas .. y he aquí que me encanto la relación de dureza que se puede alcanzar con lo fácil que es trabajarlo.
Las chapas de aluminio siguen en su balda y el robot entero son 40+cm de cartón y DM -y tornillos, servos, electronica, etc-

Aquí esta la máquina de matar :)



La estructura tiene bastante fuerza -el cartón es débil a la cizalla, pero al doblarlo en angulo recto el resultado es bastante fuerte- pero los puntos débiles son los pies y las caderas.
Los pies porque el cartón, en plano. no es suficientemente fuerte y se deforman un poco con el peso - se puede controlar, pero es un poco inestable-, en algún momento haré unos nuevos pero me esperaré a disponer de algún material que pueda usa como sensor de presión, porque lo realmente interesante es que la posición se ajuste en función de la carga.
Las caderas porque el ángulo de ataque de esos servos de la articulación de arriba no terminan de tener un buen ángulo de ataque, hice varias pruebas pero hay algo que no termino de ajustar ... en algún momento habrá que retocarla .. pero estéticamente me gusta mucho y no quiero desmontarlo :D
Otra de las pegas es la distancia entre pies y el hueco entre piernas. Si bien la mayoría de las medidas las he sacado de un patrón de escalas corporales humanas, a la hora de hacer control, esa separación entre pies supone que hay que desplazar mucho la cadera para mover el centro de masa de un pie al otro.

Ale alguna fotillo más y actualizare esto cuando saque tiempo para retocar algo

aa

Brazo Lápiz

Mas o menos cuando Wabot pasaba a ser Drapa, y al poco de montar las Cámaras Pan-Tilt, como me quedaban bases Pan-Tilt de sobra, pensé en aprovecharlas. El material era de la Universidad y del laboratorio, así que lo propio era que allí se quedase, pero no metido en una caja luego olvidada.

Mirando a Drapa y mirando a los Pan-Tilt sobrantes, pensé que no era difícil convertir un Pan-Tilt en una pata de robot, pero para que fuese útil necesitaba 4 patas y para que se pudiese emplear en el laboratorio tenía que montar al menos 6 plantas... y no había tantos Pan-Tilt. Pero oye! un pata no deja de ser un brazo simple, así que lo que sí podía montar eran 6 brazos.

La siguiente pregunta era que hacer con ellos que fuese útil en el laboratorio. Un poco acerca de brazos robot se veía en la asignatura teórica de robótica, de modo que jugar con un brazo en el laboratorio no quedaba fuera de lugar. Pero limitarse a mover el brazo a un par de posiciones fijas y pulsar un botón o empujar una caja -lo que se veía mediante simulación en la asignatura teórica- no me terminaba de llenar, de hecho me parecía bastante soso, no motivaba. Tras unas cuantas vueltas, traté de montar algún actuador interesante, pero no me terminaban de convencer las cosas que probaba, eran un poco rebuscadas... hasta que se me ocurrió ponerle un lápiz.

La solución del lápiz es sencilla, mecánicamente es muy fácil de montar, y da mucho, mucho juego.
Al mismo tiempo el feedback -la sensación recibida por lo que se está haciendo- del alumno es bastante alta, y el nivel de implicación también, porque aunque dibujar una linea recta en un papel es cosa de niños, convencer a un brazo robot con articulaciones angulares no lo es :)

Pero bueno, al final de la sesión pueden mover el brazo por el espacio alcanzable usando coordenadas cartesianas a las mil maravillas. Son capaces de dibujar cualquier curva tanto en el papel como en el espacio, escribir letras y en definitiva entender como funciona todo el proceso desde tener una estructura mecánica hasta hacerla moverse como uno quiere.

Es una practica que suele gustar y con la que se suelen picar, y, como el brazo es de construcción casera, alguno se ha montado el suyo propio después de pasar por el laboratorio.


Visión

Mas o menos por la época en que andaba haciendo revisiones sobre Wabot, empece el doctorado y
una de las asignaturas era 'Visión por Computador'.
Aunque ya tenia unas nociones básicas, ahí fue donde me empezó a llamar poderosamente el análisis de imágenes para su uso en robots -la asignatura no iba enfocada directamente a eso, pero yo sí :)- especialmente la visión estéreo.
Y, por supuesto, para el trabajo del fin de asignatura monte dos cámaras en una plataforma con ruedas y la conduje por los pasillos de la facultad tomando imágenes estéreo. No las analizaba al vuelo, solo las tomé y luego me dedique a buscar un método de análisis decente, al final terminé usando redes neuronales -otra asignatura de doctorado, junte los trabajos- para localizar la texturas dominantes en una imagen y luego buscarlas en la otra. El resultado era bastante decente, teniendo en cuanta lo malas que eran la imágenes de origen. Y rápido.. bueno, estaba hecho en matlab. rápido no era.

--imagen estereo--


Y como por aquella época ya colaboraba de pleno en la asignatura a la que habían ido a parar los robots Dabot, cuando ya dominé las cámaras, le propuse al profesor que sería interesante añadir una práctica de visión sencilla, con las cosas que se veían antes de los cursos de doctorado.

Ese primer año preparé seis plantas y al siguiente las incluimos en el laboratorio de alumnos -y aun se siguen usando-. Y entre que las puse a punto y se utilizaron en el laboratorio, un estudiante de último curso las usó -y puso a prueba- para un trabajo de fin de carrera.

El montaje se trata de una webcam normal montada sobre dos servos; uno mueve la cámara de lado a lado, y otro que la mueve arriba y abajo. Todo, cámara y servos, se maneja desde Matlab, que resulta más simple.
  El primer día con las cámaras se explica y practica cómo aislar un objeto determinado de la imagen y determinar su posición. Ésto se explica de tres formas: primero restando el fondo, en segundo lugar aislando el color y por último aislando las zonas sólidas entre bordes.

  El segundo día se mueve la cámara. Usando los métodos de la sesión anterior se les pide que analizando la imagen muevan la cámara para que el objeto buscado se sitúe en el centro de la imagen. Ahí los alumnos se enfrentan, muchas veces por primera vez, a un sistema de realimentación aplicado, y descubren una vez más el control PID.

  Por último, si no hay muchas fiestas ese año y hay clases suficientes, se hace una tercera sesión donde se combinan la cámara y un brazo robot con un lápiz -del que hablare en breve-. Se hace que el brazo trace el dibujo descrito al mover el objeto que se rastrea con la cámara y  se hace que el brazo persiga al objeto por encima de la mesa; Y en general se les deja que 'jueguen' y exploren las posibilidades que ofrece el combinar un ojo y una mano.

--imagen cámaras pan-titl--



La USBLab


La USBLab es una tarjeta reprogramable para interfaz de datos entre el ordenador y dispositivos físicos desarrollada por mi departamento en la Universidad. Y es un típico ejemplo de evolución/diseño convergente.

Después de un tiempo colaborando con la Universidad, y después de haber construido ya varios robots regidos por un microcontrolador, conocí de la existencia del micro 18F4550 de Microchip y sus hermanos pequeños.

Me interesó especialmente porque tenía puerto USB -esclavo-, el encapsulado era apto para humanos -DIP28 o DIP40- y era de Microchip -luego no necesitaba gastar un duro, ya tenia el programador y enviaban muestras gratuitas-. Hasta entonces los micros que conocía con USB era de gama alta y de otros fabricantes, de modo que necesitaría aprenderme una nueva arquitectura y comprar un nuevo programador.

Una ventaja de ese puerto USB es que los mismos chicos de Microchip tenían -tienen- un bootloader disponible, lo que implica que una vez cargas el bootloader con el programador normal, luego ya no es necesario el programador. Basta enchufarlo al USB del ordenador para reprogramarlo (con un programita que ellos te dan)... que es mucho menos engorroso que tener que sacar el micro de su zócalo y montarlo en el programador cada vez que que necesitas reprogramarlo.  Además mi programador funcionaba por el puerto serie, y ya había muchos ordenadores que no tenían, por ejemplo mi portátil.

Por aquel entonces cada robot que construía llevaba un micro distinto, o como poco con diseño distinto, según necesitase unas cosas u otras. Pero estaba dándome cuenta de que de esa forma perdía mucho tiempo repitiendo la misma tarea con ligeras variaciones. Necesitaba fijar un micro y usar siempre el mismo, así ahorraría mucho tiempo en no tener que inventar una y otra vez la rueda.

Cuando me llegaron los 18F2550 -el hermano pequeño del 18F4550- que había pedido a Microchip, empleé uno para hacer el control de un pequeño brazo robot comercial -siete grados de libertad, creo- que estaba rondando por el laboratorio. El brazo tenía un controlador propio, pero era cerrado y sólo funcionaba desde su software, cuando lo que a nosotros nos interesaba era manejarlo desde Matlab o algún otro entorno normal.

Así que le cargué el bootloader, instalé el compilador de C de microchip -me pareció más redondo que los compiladores de C que había usado en los 16F- y empecé a adaptar mis rutinas para el control de servos y el puerto serie, que por aquel entonces era la única forma que tenía de hablar entre el PC y el microcontrolador.

La cosa es que me pareció muy cómodo, era rápido y me sentía a gusto con cómo funcionaba el compilador en C. Teniendo ya controlado el brazo, le puse una pantalla lcd de 2x16 caracteres, botones, etc, estaba a gusto. Y claro, empece a explorar el puerto USB, no sólo como forma de programarlo sino como forma de enviar datos entre el PC y el microcontrolador. Las ventajas eran evidentes: un cable menos, alimentación directa desde el PC y usar USB -porque ya no todos los PC tenian serie-.

Junto con el Bootloader y la documentacion disponible del micro, Microchip tenía también unas librerías para usar el USB como puerto de datos, había -al principio- dos formas : usar el puerto USB 'a pelo' como un dispositivo más o usar el USB emulando a un puerto serie.

Empecé con la emulación del puerto serie, con lo que Windows reconocía de inmediato el dispositivo y lo montaba con un puerto serie. 
Para controlar el brazo, yo ya estaba usando un puerto serie desde Matlab, por tanto ahí no tenía que modificar nada. 
En el lado del microcontrolador simplemente usé las librerías disponibles en Microchip y seguí su guía de cómo convertir un sistema usando el puerto serie real en otro usando el puerto serie vía USB. 

Ya tenía comunicación vía USB y sus múltiples ventajas. Pero seguía teniendo un problema. Por algún motivo, el soporte de comunicación vía serie en Matlab no es muy bueno, no consigue abrir siempre los puertos, pierde la conexión y hay que reiniciar Matlab para poder volver a abrir el puerto, ... total, un engorro.

Aunque en parte debo agradecérselo, porque cansado de reiniciar matlab, me puse a estudiar la comunicacion USB 'a pelo'.

Esa parte fue más dura, la librería de Microchip se podía usar con una cierta facilidad, pero como quería entender cómo funcionaba -para saber que estaba pasando en mi micro- empecé a hurgar en los archivos de configuración de la librería, en los estandares del protocolo USB, y demás ... no lo recomiendo, el USB es un puerto muy cómodo a nivel usuario, pero a bajo nivel es un sin fin de estructuras, estados y configuraciones.

Y por supuesto necesitaba también averiguar como hablar con el micro desde el PC.

Al cabo de un tiempo -un par de meses, tenia otras cosas que hacer!- empecé a dominar el intercambio de datos entre el 18F2550 y el PC por USB 'a pelo'. Y una vez ordene las librerías de Microchip de una forma que me resultaba cómoda para trabajar el lado del micro, quedó resuelto -casi hasta hoy, que sigo usando prácticamente lo mismo que entonces monté-.

En el PC disponía de una librería base de Microchip en C, así que mis primeras comunicaciones con el micro eran vía un programa en C. Como lo realmente cómodo para desarrollar y prototipar es Matlab, no tardé en averiguar cómo hacer una librería que pudiese invocar desde Matlab. Así que Matlab habla con mi librería en C, ésta habla vía USB con mi micro y la respuesta sigue el mismo camino.

De esa forma era estable, asquerosamente estable. Matlab no se quedaba pillado, si se desconectaba el micro -por lo que fuese- no era necesario reiniciar Matlab y podía reconectar al vuelo... ni punto de comparación -Hoy es la librería que se usa en el departamento con la USBLab, sustituyendo a todas las implementaciones anteriores que usaban la emulación de puerto serie-.

Pero en aquel momento yo ignoraba que existiese la USBLab, de hecho creo que aun no existía.

Como el 18F2550 me había gustado muy mucho, pedí unos 18F4550 a Microchip -la principal diferencia es que tenían más patitas, por tanto podía conectar más cosas al mismo micro- y los puse en marcha.
Creo recordar que fue en las vacaciones de Semana Santa o un puente largo en primavera que decidí adoptar el 18F4550 como micro base, y el 18F2550 como alternativa de menor tamaño -el código es 100% compatible-. 
Tomada la decisión, diseñe una placa, no muy grande, que contuviese lo mínimo para operar el micro: un conector USB, un botón de programación y otro de reset, toma de alimentación externa y un conector gordo donde sacar todas la señales de las patas del micro -usé un IDE40 porque se encuentra en cualquier tienda-. Monté un prototipo y quedé satisfecho.

La idea era llevar el prototipo a la facultad y convencer a mi director de tesis o a alguno de los profesores con los que colaboraba en todo aquel cacharreo, de que sería útil tener una placa estandarizada y ver si se podía encargar la fabricación de una tanda de ellas -y dejar de usar constantemente placas hechas a mano-
Convencerlos no fue difícil, de hecho no hizo falta, resulta que una compañera del departamento también había cacharreado con el mismo micro, llegado a la misma conclusión y diseñado una placa muy, muy parecida a la que yo tenía. La principal diferencia es que yo incluí alimentación externa mientras que ella incluía un conversor digital-analógico, coincidimos hasta en el conector IDE40 para los pines.

Se me habían adelantado, ya habían hecho el primer pedido a fábrica y acababan de llegar -o les faltaba muy poco-. Como no era cuestión de duplicar el esfuerzo, adopté la USBLab -como bautizaron a la otra placa- como mi placa de trabajo estándar.

Pero no todo ese trabajo fue en vano, de hecho la mayoría fue útil porque la compañera se había quedado en la parte de comunicación por USB emulando el puerto serie, con lo que tenían los mismos problemas de estabilidad que tuve yo. Así que yo usé su placa, pero ellos pasaron a usar mis librerías de comunicaciones.

Al final todos felices, objetivo cumplido: placa de desarrollo estandarizada para todos los que quisiéramos cacharrear - así se podía reutilizar y compartir el código directamente- y comunicaciones sencillas y estables entre el micro y Matlab.

La USBLab se sigue usando en el departamento para todo tipo de fines -debe haber un par de cientas- , se han hecho todo tipo de placas de expansión, se usa en varios laboratorios de alumnos, se han hecho ya un buen número de proyectos de fin de carrera con ella y son las placas que van a bordo de los robots de mi Tesis.
La USBLab

Placa de extensión de la USBLab para la radio MRF24J40MA

Placa de extensión de la USBLab para control de motores Paso a Paso