Vivimos en una época donde las redes sociales cada vez están más presentes y donde los dispositivos cada vez aplican más el concepto de internet de las cosas. En algún momento surge la necesidad de que nuestras creaciones tengan capacidad para conectar a internet y puedan enviar información sobre su estado.
En este artículo explicaré cómo hacer que vuestros dispositivos, si tienen acceso a la red de redes, puedan enviar tweets de una forma sencilla.
Para enviar mensajes en Twitter desde una aplicación distinta a la de la web oficial hay que usar la API (en este momento la 1.1), pero previamente hay que autentificarse usando el protocolo OAuth, que sinceramente es un infierno de implementar en dispositivos.
Para simplificar las cosas hay una página que ofrece de manera sencilla la publicación de tweets: http://arduino-tweet.appspot.com/ . Originalmente está pensada para Arduino con el shield ethernet, pero se puede usar con cualquier dispositivo que tenga acceso a internet.
Con ese token ya puedes acceder a la web de arduino-tweet para publicar tweets desde tu dispositivo. Para ello debes usar el protocolo HTTP. Como cada dispositivo tiene una forma de crear un socket y conectarse, aquí sólo voy a explicar genéricamente cómo se hace:
Conectar a arduino-tweet.appspot.com por el puerto 80
Enviar la cadena:
1
2
3
4
5
6
7
8
POST/update HTTP/1.0
Host:arduino-tweet.appspot.com
Content-Type:application/x-www-form-urlencoded
Content-Length:Z
token=Y&status=X
X es el mensaje que quieres publicar en twitter (p.e: @webdelcire hola #saludos) Y es el token que antes has copiado Z (con su espacio después de «:») es el número de caracteres que componen la línea:
token=Y&status=X
Fijate que entre Content y token hay dos saltos de línea (formados por los códigos ASCII 13 y 10) y después hay otros dos saltos más, esto es así porque el protocolo HTTP obliga a ello.
Finalmente si la respuesta del servidor es
HTTP/1.0 200
o
HTTP/1.1 200
entonces es que ha ido todo bien y el mensaje ha sido publicado.
A continuación pongo un formulario donde puedes probar a publicar un mensaje en twitter con el token que te haya dado. Guárdalo como un fichero html y ábrelo con el navegador.
Ahora tu dispositivo ya es capaz de publicar mensajes y si además tiene su propia cuenta en twitter, animar a tus colegas a que sigan su estado a lo largo del tiempo.
En otro artículo explicaré cómo hacer que tu dispositivo reciba ordenes desde twitter a través de los mensajes.
Ante todo no quiero que penséis que esto es ilegal, puesto que Microsoft en su soporte técnico ya ofrece la posibilidad de quitar el control parental de la XBOX 360 mediante una combinación de botones en el mando única para cada consola. Por supuesto no me hago responsable de los usos que le vayáis a dar puesto que el contenido sólo es divulgativo.
La XBOX 360 tiene control parental, que significa que los padres pueden bloquear mediante contraseña el acceso a determinados juegos, películas, etc. Esta contraseña es de 4 dígitos numéricos, por lo que hay 10000 posibles combinaciones de números (del 0000 al 9999). Normalmente los números se introducen mediante la pulsación de los botones del mando de la consola, pero existe la posibilidad de enchufar un teclado usb a la consola y pulsar las teclas correspondientes.
Con esta idea se me ocurrió como prueba de concepto crear un sistema que pudiese introducir las 10000 contraseñas una por una hasta que diese con la correcta (fuerza bruta), en vez de hacerlo a mano que sería más engorroso :-). Lo que tenía más a mano para emular un teclado usb es la placa Vinciduino, pero perfectamente se puede hacer con otra placa con un microcontrolador Atmega32U4 como Arduino Leonardo o la Teensy 2.0.
Para programar el microcontrolador usé el Atmel Studio 6.1 junto con la librería LUFA en su extensión para Atmel Studio. La librería LUFA contiene múltiples ejemplos de cómo sacar provecho a los microcontroladores AVR con USB embebido.
Yo usé el ejemplo Keyboard HID Device Demo (Class Driver APIs):
Antes de nada hay que cambiar los valores por defecto que tiene el proyecto para adecuarlos a nuestra placa, en mi caso para Vinciduino:
-El tipo de microcontrolador (Vinciduno tiene un Atmega32U4)
-La velocidad del microcontrolador y del USB en todas las configuraciones (Vinciduno corre a 16 Mhz.)
-Después hay que activar el modo Release para cuando se cree el fichero .hex
-Finalmente sustituir el fichero Keyboard.c por este Keyboard
El programa funciona de la siguiente manera:
Se espera 10 segundos hasta empezar a enviar la secuencia de números.
Se emula la pulsación de cada una de las 4 cifras que contiene el número con un intervalo aleatorio entre 0,5 y 1,5 segundos (Esto es así para emular las pulsaciones que haría una persona en un teclado).
Después se espera 1,5 segundos para que dé tiempo a que salga la pantalla de contraseña incorrecta. A continuación se emula la pulsación de la tecla ENTER.
Se esperan otros 1,5 segundos para que dé tiempo a que salga la pantalla de introducción de la contraseña de nuevo.
Se repite el proceso desde el paso 2 hasta que se llegue al número 10000.
Las esperas se realizan mediante el timer0 del microcontrolador. El envío de las pulsaciones del teclado se hacen desde la función de LUFA que genera el informe HID. Cada pulsación enciende el led de la Vinciduino durante 333 ms.
El tiempo máximo entre números es 6 segundos, por lo que en el peor de lo casos se tardaría 6 * 10000 = 60000 segundos (16,7 horas) en encontrar la contraseña correcta.
Como ejemplo pongo un vídeo que he grabado para demostrar el funcionamiento, lo mejor es verlo a 1080 y a pantalla completa. Primero se ve cómo pruebo el sistema en un ordenador donde se ven las pulsaciones en un editor de textos, comprobando así que funciona como si de un teclado se tratase. Después en la XBOX 360 elijo la opción Familia, momento en el que me pide la contraseña, y le enchufo la Vinciduino para que empiece a introducir los diferentes números. La contraseña en esta prueba es 0010 (empezando por el 0000). Cuando se llega a la contraseña correcta no existe una forma de saber si ha sido así, pero como se observa en el vídeo se queda en la opción de menú Activada sin que le afecten las pulsaciones, por lo que se podría dejar corriendo sin estar presente, sabiendo que cuando llegase al número 10000 dejaría de enviar pulsaciones.
Para los que no conozcan qué es una Maker Faire, copio parte de la nota de prensa que lo expresa perfectamente:
Un festival en el que hacer, crear, fabricar, confeccionar, reciclar, construir, pensar, jugar e inspirarse en el arte, la artesanía, la ingeniería, la música, la ciencia y la tecnología con toda la familia. Un escaparate de invenciones y creatividad.
Y así es, es un lugar donde la gente muestra lo que ha creado en su casa o en su empresa, un evento donde cualquiera puede ir y cualquiera puede participar. Puedes asistir como observador para ver qué novedades traen las empresas o ver qué inventos han hecho otras personas, pero si has/habeis hecho algo interesante (DIY y DIWO) y quieres mostrarlo, es el escaparate ideal, puesto que en esta feria tiene cabida de todo: desde unos origamis hasta robots avanzados, pasando por impresión 3d, música con cualquier elemento, hardware libre, corte y confección, etc.
Este fin de semana tenía que ir a Barcelona y en un rato libre aproveché para pasearme por la feria.
Makers of Barcelona fueron los encargados de organizar el evento en su local ubicado en la calle Bailén 11.
Gracias a la colaboración del Ayuntamiento de Barcelona pudieron cortar la calle al tráfico y colocar los stands.
Desde las 10 de la mañana ya hasta las 8 de la tarde el público pudo asistir de manera gratuita.
Había dos zonas diferenciadas: la exterior, donde estaban los stands:
y la interior en las instalaciones del MOB:
Había mucha gente que se acercó al evento y estaba realmente sorprendida por todo lo que veía, y no es para menos, dada la diversidad de expositores y lo que mostraban. Aquí hay una lista de los que acudieron a la Mini Maker Faire.
Unos cuantos proyectos para os hagáis a la idea de lo variopinto que fue:
Electroxoc
Spaii
The Junk Raft Armada
Vectorealism
Ro-botica
I Am Patchwork
Lüme
Bartendro 7
Por supuesto también hubo espacio para las impresoras 3D:
Y para la música:
Sólo me queda dar la enhorabuena a los organizadores y a los makers que asistieron. También recordaros que si os perdisteis esta Mini Maker Faire y os habéis quedado con ganas de ir, aún tenéis otra oportunidad de acudir a la de Bilbao el Sábado 13 y Domingo 14 de Julio de 9 de la mañana a 10 de la noche.
En el anterior artículo hablaba de cómo hacer un robot con el que se pueda hacer vigilancias o inspecciones. El problema que tenía era que la cámara no mostraba las imágenes en tiempo real.
Aprovechando que la fundación Raspberry Pi ha sacado a la venta la nueva cámara que se acopla al dispositivo a través de su propio puerto, he adquirido una para hacer pruebas con ella y ver si era capaz de conseguir la ansiada retransmisión (o streaming) en directo.
Después de varias pruebas con vlc y el protocolo rtsp sólo había conseguido un flujo de imágenes con un retraso de 1 o 2 segundos, pero esto era insuficiente. Por suerte me encontré con este artículo que hablaba de hacerlo con netcat y mplayer. Configurando bien los parámetros se puede tener una secuencia de vídeo muy fluida, o lo que es lo mismo, streaming en tiempo real.
Primero desde el ordenador (ya sea linux, Mac OS o Windows -con este netcat-) ejecuto el siguiente comando:
Mac OS
Shell
1
nc-l5001|mplayer-fps60-cache1024-
Linux y Windows:
Shell
1
nc-l-p5001|mplayer-fps60-cache1024-
Es significado es que netcat escucha por el puerto 5001 y todo lo que reciba se lo pasará al mplayer por la entrada estándar. MPlayer espera una retransmisión de 60 marcos por segundo y guardará el contenido en un buffer de un mega.
Después desde la Raspberry Pi con el sistema operativo Raspbian ejecuto el siguiente comando:
El programa raspivid envía durante 1000 segundos una imágen de 640×480 píxeles volteada horizontal y verticalmente por la salida estándar y sin mostrar la previsualización. El netcat lo envía a la ip 192.168.1.37 por el puerto 5001.
El resultado es este:
Tanto el ordenador como la Raspberry PI están conectados al router y funciona bastante bien, pero para hacerlo mejor lo ideal sería conectar ambos por wifi mediante ad-hoc.
¿Quién no ha tenido alguna vez la necesidad de poder ver nuestra casa desde otro lugar (oficina, hotel, otra casa, etc), o poder hacer inspección de tuberías, respiraderos o sitios inaccesibles? La idea que planteo en este artículo es la de un coche teledirigido al que podemos manejar remotamente mediante wifi y que veamos por donde va.
El funcionamiento es sencillo: Por un lado con un programa en python que se ejecuta en la raspberry pi hacemos un servidor que reciba los comandos por tcp/ip, estos son enviados mediante el puerto serie de la raspberry pi al puerto serie del arduino, que será el encargado de manejar la motorshield para mover el conjunto. Por otro lado en la propia Raspberry Pi hacemos streaming de vídeo para que podamos ver a través de su webcam remotamente.
Todo está alimentado con una batería Lipo 7,4 V. (2S) de 1000 mAh. Por un lado está conectado directamente a arduino y por otro a un regulador UBEC para alimentar a la raspberry pi a través de los pines GPIO de 5v y GND.
La comunicación entre la rasbperry Pi y arduino se hace simplemente con un cable, ya que no es necesario ninguna protección al ser el pin TX de la raspberry pi el que se conecta al pin RX de arduino, y por tanto no hay riesgo con los voltajes diferentes (siempre y cuando no reprogrames arduino, si es así desconecta el cable de RX hasta haber terminado).
El programa de Arduino es bastante simple, sólo comprueba si existe un byte en el puerto serie y si lo hay lo interpreta para saber qué movimiento hay que hacer con los motores. Se parte del byte 0x30 (0 en ASCII) y se comprueban sus bits:
Si el bit 0 está activado el coche va hacia delante.
Si el bit 1 está activado el coche va hacia atrás.
Si los bits anteriores están desactivados entonces el coche no se mueve.
Si el bit 2 está activado gira las ruedas a la izquierda.
Si el bit 3 está activado gira las ruedas a la derecha.
Si los bits anteriores están desactivados entonces la dirección el coche permanece recta.
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
intdirA=12;// sentido
intdirB=13;// direccion
intspeedA=10;// velocidad del motor
intspeedB=11;// parada o encendido de la dirección
intvelocidad=150;// PWM del motor de tracción
// El robot va hacia atrás
voidatras()
{
digitalWrite(dirA,HIGH);
}
// El robot va hacia alante
voidalante()
{
digitalWrite(dirA,LOW);
}
// El robot tuerce a la izquierda
voidizquierda()
{
digitalWrite(dirB,LOW);
}
// El robot tuerce a la derecha
voidderecha()
{
digitalWrite(dirB,HIGH);
}
voidsetup()
{
// Configuración de las comunicaciones
Serial.begin(115200);
// Configuración de los pines de la motorshield
pinMode(dirA,OUTPUT);
pinMode(dirB,OUTPUT);
pinMode(speedA,OUTPUT);
pinMode(speedB,OUTPUT);
digitalWrite(speedA,LOW);
digitalWrite(speedB,LOW);
}
voidloop()
{
while(Serial.available())
{
intcaracter=Serial.read();
caracter-=0x30;
if(caracter==0)
{
digitalWrite(speedA,LOW);
digitalWrite(speedB,LOW);
}
else
{
if(caracter&1)
{
analogWrite(speedA,velocidad);
alante();
}
elseif(caracter&2)
{
analogWrite(speedA,velocidad);
atras();
}
elseif((caracter&3)==0)
{
digitalWrite(speedA,LOW);
}
if(caracter&4)
{
digitalWrite(speedB,HIGH);
izquierda();
}
elseif(caracter&8)
{
digitalWrite(speedB,HIGH);
derecha();
}
elseif((caracter&12)==0)
{
digitalWrite(speedB,LOW);
}
}
}
}
En el lado de la Raspberry Pi hay que instalar primero varias cosas:
Editado 17/04/2014: Desactivar la consola serie que viene por defecto activada:
En el fichero /etc/inittab poner una almohadilla (#) al principio en la línea: T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
En el fichero /boot/cmdline.txt sustituir la línea: dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
por dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
Finalmente hay que reiniciar la Raspberry Pi para que coja los cambios.
Después hay que dar permisos de lectura y escritura al puerto serie:
Shell
1
sudo chmoda+rw/dev/ttyAMA0
A continuación creamos un fichero llamado servidor.py:
Este programa python se encarga de crear un socket tcp/ip que escucha por el puerto 1976 , cuando alguien se conecta a este puerto entonces permanece a la espera de recibir los bytes que posteriormente enviará a Arduino a través del puerto serie.
Finalmente crearemos un fichero llamado webcam.sh con el siguiente contenido (cambiar 192.168.1.133 por la ip que tenga vuestra raspberry pi):
Este programa shell arrancará un servidor de streaming con GStreamer. De momento GStreamer es el software que conozco que funciona más rápido enviando imágenes con un retardo de 2 segundos, ffmpeg tenía un retardo de hasta ¡¡¡ 10 segundos !!!. La idea la cogí de aquí.
Ahora que ya tenemos lo necesario en nuestra parte del coche, necesitamos configurar el router para redirigir los puertos 22, 1976 y 5000 hacía la ip que tenga la Raspberry Pi.
Desde el ordenador remoto necesitaremos tener el programa VLC para el recibir el streaming, un cliente de ssh (en windows el mejor es el putty) y Processing para enviar los comandos.
Los pasos para hacer que nuestro sistema de televigilancia son los siguientes:
Conectar mediante ssh a la raspberry pi y ejecutar el comando:
Shell
1
shwebcam.sh
Abrir otra sesión de ssh y ejecutar el comando:
Shell
1
python servidor.py
Arrancar VLC y abrir una ubicación de red poniendo la siguiente línea, con esto podremos ver lo que hay frente a la webcam (cambiar 192.168.1.133 por la ip que tenga vuestra raspberry pi):
Shell
1
tcp://192.168.1.133:5000
Arrancar el Processing con el siguiente programa y ejecutarlo (cambiar 192.168.1.133 por la ip que tenga vuestra raspberry pi):
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
importprocessing.net.*;
Client myClient;
intvalor;
voidsetup(){
size(200,200);
myClient=newClient(this,"192.168.1.133",1976);
valor=0;
}
voiddraw(){
}
voidkeyReleased()
{
if(key==CODED)
{
if(keyCode==UP)
{
valor&=0xFFFFFFFE;
}
elseif(keyCode==DOWN)
{
valor&=0xFFFFFFFD;
}
elseif(keyCode==LEFT)
{
valor&=0xFFFFFFFB;
}
elseif(keyCode==RIGHT)
{
valor&=0xFFFFFFF7;
}
myClient.write(valor+0x30);
}
}
voidkeyPressed()
{
if(key==CODED)
{
if(keyCode==UP)
{
valor|=1;
}
elseif(keyCode==DOWN)
{
valor|=2;
}
elseif(keyCode==LEFT)
{
valor|=4;
}
elseif(keyCode==RIGHT)
{
valor|=8;
}
myClient.write(valor+0x30);
}
}
Si todo ha ido bien, ponemos la ventana de processing que nos ha abierto como activa cuando hemos lanzado el programa y pulsamos los botones de los cursores del teclado, momento en el cual veremos a través de la webcam (o en local si lo tenemos enfrente) cómo nos desplazamos.
Siguiendo con las calculadoras online, en esta ocasión pongo a vuestra disposición una calculadora para que podáis calcular qué motores necesitáis en vuestro robot velocista o de sumo para que se pueda mover a la velocidad deseada. Está basada en los conceptos de dinámica de la Society Of Robots, más concretamente en la calculadora RMF, pero simplificándolo bastante.
Cantidad de motores
Peso que el robot tiene que mover
Velocidad requerida
Aceleración requerida
Diámetro de la rueda
Velocidad del motor
Eficiencia del motor
%
Torque del motor
Si borráis el campo de velocidad del motor, se recalculará para daros el valor más aproximado.
Cuando queremos comprar un motor para nuestro robot una de las primeras cosas en que nos fijamos es el torque (o par motor), dicho de otro modo queremos saber la fuerza que tiene ese motor para girar un eje con una masa determinada a una distancia concreta. La medida estándar es el newton/metro pero existen otras medidas para representarlo, por eso en este artículo ofrezco un sencillo conversor (o calculadora como prefiráis) para hacer las conversiones entre las medidas más usadas. El uso de la sección de potencia es opcional y afectará directamente a los valores original y resultado. Espero que os sea útil:
Potencia
Velocidad
Masa
Distancia
Original
Resultado
Si veis que falta alguna medida podéis pedirla en los comentarios para incluirla.
Cuando has fabricado un robot velocista y has hecho una pista para probarlo siempre es necesario medir los tiempos que emplea en dar una vuelta a la pista. Así podrás comprobar en cuantas décimas de segundo has mejorado tu robot. Ya sea porque le has cambiado el código de control, has ajustado alguna constante o porque hayas modificado algo de la mecánica; esas décimas que ahorres en dar una vuelta son cruciales para mejorar su rendimiento de cara a las competiciones. Puedes medirlo a mano con un cronómetro, pero nunca tendrás la precisión suficiente y el margen de error cuando quieres medir las mejoras en décimas de segundo es grande. En este artículo voy a explicar cómo fabricar un medidor de vueltas o cuentavueltas sencillo.
El cuentavueltas se compone de dos módulos. El módulo principal contiene los siguientes materiales:
Un microcontrolador PIC16F628A.
Un display HD44780.
Un módulo bluetooth HC06.
Un regulador de tensión 7805.
Un LDR.
Un botón.
Un diodo led.
Un buzzer.
Un cristal de cuarzo de 20Mhz.
Dos condensadores de 22pF.
Un condensador de 0,1uF.
Un condensador de 0,22uF.
Una resistencia variable de 10K Ω.
Una resistencia de 220 Ω.
Una batería Lipo de 7,4V o 5 pilas de 1,5V o una pila de 9V.
El módulo secundario en un puntero laser de 0,5mW. Es importante que su potencia sea de 0,5mW (NO 5mW como muchos) ya que valores mayores son peligrosos para la vista si por algún casual el haz de láser hace contacto con la retina de tus ojos (directamente o por reflejo especular). Úsalo bajo tu responsabilidad y con las medidas de seguridad adecuadas.
La idea es sencilla: el láser está apuntando constantemente hacia el LDR a pie de pista. Cuando el robot velocista pasa por delante corta el haz de láser y se registra en el sistema una vuelta. El sistema puede estar monitorizado tanto desde el propio display del módulo principal como remotamente desde un ordenador a través de bluetooth.
El LDR tiene un caperuzón negro hecho con cartulina negra para que no le afecte la luz de ambiente. El conjunto está pegado a una base de cartón para apoyarlo en el suelo y evitar que se mueva.
El puntero láser tiene otro caperuzón negro hecho con la misma cartulina, pero está completamente tapado excepto por un agujero donde saldrá un haz de laser muy pequeño, pudiendo así ser cortado más fácilmente por el robot cuando pase por delante. El conjunto está igualmente pegado a una base de cartón para apoyarlo en el suelo y evitar que se mueva.
Al principio hay que apuntar el láser hacia el LDR moviendo el puntero. Cada vez que el haz de láser incida sobre el LDR el diodo led se encenderá y se oirá un pitido en el buzzer. Así sabremos que está apuntando correctamente.
Se pulsa el botón, se apaga el led y a continuación muestra los datos de la última carrera que ha grabado en la eeprom del microcontrolador.
De izquierda a derecha y de arriba a abajo:
Tiempo de la vuelta actual (a 0 por que ahora no está corriendo).
Tiempo de la última vuelta dada.
Número de vueltas hechas.
Tiempo total de la carrera.
Se vuelve a pulsar de nuevo el botón, se enciende el led y se ponen los contadores a 0, esperando a que el robot corte por primera vez el haz del láser para empezar la cuenta.
Cuando el robot pasa a través del haz de láser, se apaga el led y empieza a contar automáticamente.
Cada vez que el robot corta el haz de láser, suena un pitido, se pone a 0 el contador de la vuelta actual, se actualiza el valor de la vuelta anterior y se suma 1 al número de vueltas. Así hasta que se pulse el botón o se llegue a la vuelta 10, momento en el que el cronómetro se parará para poder visualizar los resultados y guardarlos en la eeprom del microcontrolador.
Si se quiere volver a medir sólo hay que pulsar el botón de nuevo, se enciende el led, se ponen los contadores a 0 y se espera a que el robot corte el haz de láser de nuevo.
Todos los datos son enviados por bluetooth a 115200 bps, por lo que se puede hacer un seguimiento desde un ordenador usando Processing sin tener que estar cerca del display o para visualizarlo en una pantalla panorámica en un evento con espectadores.
Los que llevamos un tiempo en esto de la robótica para concursos nos vamos dando cuenta que se pierde mucho tiempo en muchas cosas para hacer las pruebas a nuestros robots y dejarlos configurados correctamente. Una de las cosas que lleva más tiempo es reprogramar el robot cada vez que queremos cambiar algo en el firmware que no funciona: tienes que ir a por el robot, cogerlo, pararlo, llevarlo hasta el ordenador, quitarle la batería, ponerle el cable ICSP, seleccionar el fichero .hex, programarlo, ponerle la batería de nuevo, llevarlo a la pista, dejarlo en ella y activarlo.
Con este artículo nos vamos a ahorrar todos los pasos mencionados simplemente programando el firmware del robot mediante bluetooth gracias a un bootloader.
Aunque este artículo esté enfocado a la baby orangutan (atmel328P) y el módulo bluetooth CSR, podría funcionar con otros microcontroladores AVR (incluido Arduino) y otros módulos bluetooth.
Como comentaba antes, la posibilidad de programar el firmware de nuestro microcontrolador AVR mediante bluetooth se basa en un bootloader. Los bootloader permiten reprogramar el microcontrolador sin necesidad de tener que usar siempre un programador ICSP. En realidad no es más que un programa que se carga en la zona alta de la memoria y que cambiando los fuse bits del microcontrolador hacemos que sea el primero que se ejecute. Esta gran ventaja nos permite que el bootloader esté comprobando durante unos segundos si se envía información desde el puerto serie del microcontrolador, si es así, reprograma el microcontolador (excepto la zona de memoria del bootloader) con el código enviado y lo ejecuta, si no es así, entonces pasado un tiempo ejecuta el código que hubiese anteriormente. Como el puerto serie ya ha sido configurado por el bootloader, en nuestro programa ya podremos usar las rutinas de envío y recepción por el puerto serie sin la necesidad de tenerlo que configurar de nuevo.
El objetivo de este artículo no es explicar cómo hacer un bootloader, sino utilizarlo directamente. Por eso voy a usar uno ya hecho: KAVR. Este bootloader espera por el puerto serie que se le envíe el fichero .hex del código a programar, por lo que podríamos usar cualquier programa como Minicom (linux), Hyperterminal (windows xp) o, como en mi caso, Tera Term (windows 7).
Antes de usarlo hay que retocar los fuentes, por lo que debemos bajarnos el código fuente, descomprimirlo, entrar en el directorio bootloaderskavr-0.2_328P-14s y editar el fichero Makefile. Dentro de este hay 3 valores que cambiar dependiendo de nuestro sistema:
F_CPU: La velocidad de nuestro microncontrolador en hertzios, en el caso de la Baby Orangutan es 20000000.
BAUD: La velocidad del puerto serie en bps, en mi caso el bluetooth está configurado a 115200.
TIMEOUT: El tiempo que esperará el bootloader a posibles datos en el puerto serie antes de ejecutar el firmware anterior, en mi caso le he puesto 5000 (5 segundos).
Dentro de la misma carpeta tenemos que editar el fichero kavr.c y añadir a la lista de cabeceras la siguiente:
C
1
#include <avr/wdt.h>
y justo antes de la línea
C
1
UBRR0H=UBRRH_VALUE;
añadir las siguientes dos líneas que desactivan el watchdog (que explicaré más adelante) en el bootloader:
C
1
2
MCUSR=0;
wdt_disable();
Después hay que recompilarlo para que nos genere el fichero kavr.hex Para ello usaremos el toolchain de AVR, que en mi caso está en directorio C:Program Files (x86)AtmelAVR ToolsAVR Toolchainbin:
A continuación debéis activar en el microcontrolador los fuse bits BOOTSZ y BOOTRST para indicarle que va a tener un bootloader, el BOOTSZ debe ser de 512 palabras para que quepa el KAVR:
Finalmente enviamos el fichero kavr.hex mediante ICSP al microcontrolador, esta será la última vez que tengáis que hacerlo 😉 .
Ya tenemos nuestro bootloader activo. Ahora hay que hacer nuestro programa, compilarlo y enviárselo mediante bluetooth a nuestro microcontrolador. Para ello previamente deberemos haber vinculado nuestro dispositivo bluetooth a nuestro PC. Después abriremos el puerto serie que se ha creado en la vinculación con los siguientes parámetros 115200,8N1,XON/XOFF:
Debido a la alta velocidad de transmisión he necesitado poner un retardo en el envío de cada línea de 1 ms, pero este ha sido mi caso y no se si os pasará igual si usáis otro módulo bluetooth (si ponéis todo el conjunto a una velocidad menor, por ejemplo 19200, no será necesario ese retardo en el envío con el módulo CSR). Lo del control de errores XON/XOFF lo implementa el bootloader, permite que el microcontrolador le diga al software de control de puerto serie que pare el flujo de datos mientras escribe en la memoria flash, así no se pierdan bytes por el camino al no poder procesarlos a tiempo.
Una vez abierto el canal de comunicación el bootloader nos enviará el texto KAVR indicando que está esperando a que le enviemos un fichero .hex:
Si no le enviamos el fichero en 5 segundos lanzará el programa que esté en la posición cero de la memoria flash, pero si no existiese tal programa, volvería el bootloader a ejecutarse. El fichero debe enviarse como fichero de texto, en Tera Term se hace en el menú FileSend File…
Si la programación ha ido mal, el bootloader enviará el símbolo ?. Si ha ido bien enviará el carácter S e inmediatamente se ejecutará el código.
Ahora sólo queda conseguir que cuando queramos programar otro firmware no tengamos la necesidad de acercarnos al robot y pulsar el botón de reset para que se resetee el microcontrolador y arranque el bootloader de nuevo. Por desgracia en los AVR no hay posibilidad de resetear mediante software, sin embargo hay un truco para lograrlo: El watchdog es un temporizador que si llega al final de su cuenta resetea el micro, por lo tanto para que no ocurra esto se debe poner a 0 el contador cada poco tiempo. El truco consiste en que cuando el microcontrolador reciba una orden a través del puerto serie, este lance un bucle infinito que no actualice el contador del watchdog, provocando su reseteo y en consecuencia ejecutando el bootloader.
A continuación pongo un ejemplo de código muy sencillo: Lo que hace el programa es activar la interrupción de recepción de carácteres. Después apaga y enciende un led en el pin PD7 cada 500 ms. indefinidatmente, pero cuando recibe una R por el puerto serie, cambia el valor de una variable a 1. Dentro del bucle principal se comprueba si esa variable está a 1, y si es así, envía OK por el puerto serie, activa el watchdog y se mete en un bucle infinito para provocar el reseteo.
C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
#include <avr/io.h>
#include <util/delay.h>
#include <avr/wdt.h>
#include <avr/interrupt.h>
volatilecharreseteo=0;
ISR(USART_RX_vect)
{
if(UDR0=='R')reseteo=1;
}
voidescribe_uart(charcaracter)
{
loop_until_bit_is_set(UCSR0A,UDRE0);
UDR0=caracter;
}
intmain(void)
{
DDRD|=_BV(PD7);
UCSR0B|=_BV(RXCIE0);
sei();
for(;;)
{
PORTD&=~_BV(PD7);
_delay_ms(500);
PORTD|=_BV(PD7);
_delay_ms(500);
if(reseteo)
{
escribe_uart('O');
escribe_uart('K');
wdt_enable(WDTO_15MS);
for(;;);
}
}
return0;
}
En la siguiente imagen podemos ver cómo arranca el bootloader con el texto KAVR, como no hay nada que programar no sale nada más y arranca el programa principal, pero al cabo de poco se le ha enviado al programa una R y este ha respondido con un OK, a continuación el microcontrolador se ha reseteado arrancando de nuevo el bootloader y mostrando otra vez KAVR, se le ha enviado un fichero .hex y el bootloader ha respondido con una S indicando que todo ha ido bien y procediendo a ejecutar el programa principal:
Hace algún tiempo leí un artículo sobre un concurso para crear un robot con un coste de 10$ para el aprendizaje de robótica en escuelas con un coste admisible. Este concurso es el reto AFRON.
Así que me pareció una buena idea participar. Se me ocurrió que un robot muy simple de hacer pero que es un buen punto de partida para aprender es un seguidor de luz, donde los sensores del robot están buscando si hay un foco luz y cuando lo encuentran se dirigen hacia el. Me puse a buscar los componentes, a construir el robot y al final he terminado a L.I.O.S. (Light input output system):
Como se puede ver en el vídeo, las ruedas y el chasis son de cartón de una caja reciclada. Aunque no se aprecie, los sensores son LDR, los motores son dos servos trucados para rotación continua, el cerebro es un microcontrolador PIC 12F683, tiene dos diodos led para indicar el estado y una batería lipo de 3,7V. y 130 mAh para alimentar el sistema.
Funcionamiento:
Nada más enchufar la batería los leds parpadean varias veces. Hay dos LDR que el microcontrolador está comprobando constantemente; si este detecta que en uno de ellos hay una intensidad de luz grande, entonces enciende el led del lado del LDR y activa el servo del lado contrario (si la luz está a la derecha, entonces es la rueda izquierda la que tiene que moverse y viceversa); si ambos sensores detectan luz entonces los dos led se encienden y los dos motores se activan para ir recto; si no detecta suficiente luz entonces permanece parado y los leds apagados.
Consumo
En resposo consume 23 mA.
Cuando sigue una luz puede consumir hasta 300 mA.
La hoja del cutter es afilada, tener cuidado de no cortarse.
La aguja es muy fina, tener cuidado de no pincharse.
El pegamento es muy fuerte, tener cuidado de que no entre en contacto con los ojos y/o la piel.
La termocola está muy caliente, tener cuidado de no tocarla.
El soldador está muy caliente, tener cuidado de no tocarlo, de no ponerlo en contacto con el cartón y de evitar respirar el humo de la soldadura.
La batería lipo no debe cortocircuitarse, ni sobrecargarse por encima de 4,2V. ni descargarse por debajo de 3V.
Servos
Los servos contienen electrónica para manejar su sentido de rotación y tienen engranajes para aumentar su fuerza de tracción, sin embargo sólo pueden rotar 180º, por lo que vamos a modificarlos para que su rotación sea continua como la de cualquier motor.
Lo primero es desmontarlos extrayendo los 4 tornillos de su base y separar las tapas inferior y superior:
Después hay que extraer los engranajes. Uno de ellos contiene una pestaña para que haga de tope y no avance más (marcado con un circulo rojo):
Así es como queda al cortarla:
Por otro lado tenemos el potenciómetro. Aquí debemos desoldar los cables (las flechas verdes) y romper la pared que contiene las dos pestañas que también hacen tope (las fechas rojas):
Así es como quedaría la pared que comentaba:
A continuación debemos soldar las dos resistencias de 10KΩ formando un divisor resistivo en los cables que habíamos desoldado antes (el cable blanco entre las dos resistencias). Para aislar los contactos poner tubo termoretráctil:
También aislar el extremo con tubo termoretráctil:
Finalmente unir todos los engranajes de nuevo, meter la electrónica, poner las tapas y atornillarlas:
Chásis y ruedas
Imprimir en papel esta plantilla en DXF a escala 1:1 (yo he usado el programa de software libre LibreCad):
Pegar el papel con cinta adhesiva al cartón. Agujerear los círculos pequeños con una aguja y cortar las líneas con un cutter:
A continuación poner la aguja en el agujero de una rueda, poner pegamento en el brazo alargado de un servo e introducir el agujero central de este por la aguja hasta pegarlo a la rueda. Repetir el proceso con la otra rueda:
Quitar la pegatina del lateral del servo, poner pegamento en ese lateral y pegarlo en el extremo superior izquierdo de la superficie grande de cartón. Repetir el proceso en el otro lado con el otro servo:
Cortar levemente la superficie pequeña de cartón por el primer tercio, poner pegamento y adherirla a la incisión hecha anteriormente en la superficie grande de cartón (según la plantilla). Colocar las dos ruedas en los ejes del servo:
Agujerear 4 orificios entre los servos, introducir desde abajo los LDR, girarlos 30 grados desde el centro y pegarlos con termocola. Hacer dos orificios a cada lado, introducir desde abajo los diodos led y pegarlos con termocola:
Electrónica
Este es el esquema electrónico:
LDR
Soldar una de las patillas de cada LDR a VCC.
Soldar la otra patilla de cada LDR a un extremo de una resistencia de 10KΩ
Desde la anterior unión izquierda soldar un cable hasta el pin 7 del zócalo y poner tubo termoretráctil.
Desde la anterior unión derecha soldar un cable en hasta el pin 6 del zócalo y poner tubo termoretráctil.
Soldar el otro extremo de cada resistencia a GND.
Pegar las resistencias a la base con termocola.
SERVO
Pelar los cables y soldar el rojo a VCC y el marrón a GND de cada servo.
Soldar el cable naranja del servo izquierdo al pin 3 del zócalo y poner tubo termoretráctil.
Soldar el cable naranja del servo derecho al pin 2 del zócalo y poner tubo termoretráctil.
LED
Soldar un extremo de una resistencia de 180Ω a VCC.
Soldar el otro extremo al de otra resistencia de 180Ω.
Desde la anterior unión soldar un cable hacia la patilla del ánodo del led derecho.
Desde la anterior unión soldar un cable hacia la patilla del cátodo del led izquierdo.
Soldar el extremo restante de la segunda resistencia a GND.
Pegar las resistencias a la base con termocola.
Desde el cátodo del led derecho soldar un cable hacia el ánodo del led izquierdo.
Desde la anterior unión soldar un cable hacia el pin 5 del zócalo y poner tubo termoretráctil.
PIC
Soldar el pin 1 del zócalo a VCC y poner tubo termoretráctil.
Soldar el pin 8 del zócalo a GND y poner tubo termoretráctil.
Pegar el zócalo a la base con termocola.
Batería
Enchufar el conector a la batería y comprobar cual es VCC y cual GND con un polímetro.
Soldar un cable a VCC y otro a GND y juntarlos con el resto del circuito. Poner tubo termoretráctil.
Enrollar un trozo de cinta adhesiva y ponerla en la zona trasera de la base.
Poner la batería encima de la cinta adhesiva y enchufar esta al conector.
El compilador que se ha usado es el SDCC, que es software libre. Para compilarlo he usado el siguiente comando:
Shell
1
sdcc-mpic14-p12f683--use-non-free lios.c
Para subir el fichero .hex al PIC hay que tener un programador de PICs y un software que maneje el programador. Hay mucha variedad. Yo he usado el pickit3 de Microchip y su software para windows, pero hay otras alternativas más baratas que se pueden usar con software libre o gratuitas para linux, mac y windows.
Explicación
A grandes rasgos el funcionamiento es el siguiente:
Al enchufar la batería los leds parpadean 10 veces rápidamente. Los leds están en una configuración determinada para que si el pin del PIC está configurado como salida y la pone en alto luzca un led, si la pone en bajo luce el otro led; si está configurado como entrada (alta impedancia) los leds permanecen apagados.
Se activan las interrupciones del timer0 y del ADC. La interrupción del timer0 está configurada para que salte cada 0,1 ms. y sirve para contabilizar los tiempos en los servos. La interrupción del ADC salta cada vez que un valor ha sido leído en un LDR para activar el led asociado (si se traspasa cierto umbral), poner un valor en una variable de estado, cambiar el canal de ADC y leer el siguiente LDR.
En el bucle principal del programa se comprueba la variable de estado para saber qué servos deben activarse. La activación de los servos es distinta ya que estos están enfrentados y la rotación para ir hacia delante es diferente en cada uno. Para uno supone una señal alta de 1 ms y otra baja de 19 ms., mientras que para el otro supone una señal alta de 2 ms y otra baja de 18 ms.
Modificaciones:
Los sensores del robot son LDR, pero podrían haberse cambiado por dos CNY70 para hacer un robot seguidor de línea con el siguiente esquema:
