Ejemplo Robot - Open - Softwear-Beta090712

Laboratorio de Sistemas Electrónicos Digitales
ROBOT CON CONTROL REMOTO

Y CÁMARA DE VÍDEO INTEGRADA
AUTORES
PABLO RODRÍGUEZ CABELLOS
EUGENIO SILLERO HERRERO
Robot con control remoto y cámara de vídeo integrada
ÍNDICE
1. INTRODUCCIÓN ....................................................................... 7
1.1. OBJETIVOS .........................................................................................7
1.2. DESCRIPCIÓN DEL ROBOT ...............................................................7
2. PROTOCOLOS DE COMUNICACIONES ............................... 14
2.1. EL NIVEL FÍSICO: ENLACE RADIOFRECUENCIA ............................14
2.2. NIVEL DE ENLACE: LAPR .................................................................16
2.3. PROTOCOLO DE COMANDOS .........................................................18
2.3.1. ÓRDENES DE MOTORES ...............................................................................19
2.3.2. ÓRDENES DEL SISTEMA ...............................................................................20
2.3.3. ÓRDENES DE IMAGEN ...................................................................................20
2.4. PROTOCOLO DE DATOS..................................................................21
2.4.1. ESTADO DEL ROBOT .....................................................................................21
2.4.2. RECOMPONIENDO LA IMAGEN.....................................................................21
3. TARJETA DE CONTROL DE MOTORES ............................... 24

3.1. DESCRIPCIÓN DEL HARDWARE .....................................................24
3.1.1. ALIMENTACIÓN ...............................................................................................24
3.1.2. SENSORES ......................................................................................................25
3.1.3. DRIVER DE MOTORES ...................................................................................27
3.1.4. PROCESADO ...................................................................................................29
3.2. DESCRIPCIÓN DEL SOFTWARE. .....................................................32
3.2.1. EQUIVALENCIAS Y VECTORES DE INTERRUPCIÓN ..................................32
3.2.2. RUTINA DE RESET..........................................................................................35
3.2.3. MODO AUTOMÁTICO ......................................................................................37
3.2.4. MODO MANUAL ...............................................................................................41
3.2.5. INTERRUPCIONES ..........................................................................................44
3.2.6. SUBRUTINAS ...................................................................................................47
4. TARJETA DE CONTROL PRINCIPAL.................................... 54

4.1. DESCRIPCIÓN DEL HARDWARE .....................................................54
4.1.1. ALIMENTACIÓN ...............................................................................................55
4.1.2. CONTROL DE ORIENTACIÓN DE LA CÁMARA ............................................55
4.1.3. INTERFAZ DE LA CÁMARA.............................................................................56
4.1.4. PROCESADO ...................................................................................................58
4.2. DESCRIPCIÓN DEL SOFTWARE ......................................................60
4.2.1. EQUIVALENCIAS Y VECTORES DE INTERRUPCIÓN ..................................60
4.2.2. RUTINA DE RESET..........................................................................................62
4.2.3. RUTINAS DE CONFIGURACIÓN DE CÁMARA ..............................................64
4.2.4. EL PROGRAMA PRINCIPAL............................................................................68
4.2.5. ADQUISICIÓN DE DATOS...............................................................................69
4.2.6. LAS RUTINAS DE ENLACE .............................................................................70
4.2.7. EL NIVEL FÍSICO .............................................................................................78
5. HOST DE CONTROL REMOTO.............................................. 82

5.1. PLACA DE CONTROL........................................................................82
5.2. EL SOFTWARE ..................................................................................85
5.3. PAQUETE COM.THEEXBTEAM.COMM............................................86
5.4. PAQUETE COM.THEEXBTEAM.ROBOTS ........................................88
6. APÉNDICE A: INSTALACIÓN DEL SOFTWARE................... 92
-2-
6.1. INSTALACIÓN DEL ENTORNO JAVA................................................92

6.2. INSTALACIÓN DE LAS LIBRERÍAS JAVAX.COMM...........................93
6.3. INSTALACIÓN DE LA APLICACIÓN DE CONTROL ..........................94
6.4. INSTALACIÓN DE JAKARTA-ANT.....................................................94
7. APÉNDICE B ESQUEMÁTICOS DE LAS PLACAS ............... 96
8. APÉNDICE F: AVISOS LEGALES.......................................... 99
8.1. PAQUETES COM.THEEXBTEAM.* ...................................................99
8.2. LIBRERÍAS JAVAX.COMM ................................................................99
8.3. TERCERAS PARTES .......................................................................100
9. BIBLIOGRAFÍA ..................................................................... 101
9.1. REFERENCIAS BIBLIOGRÁFICAS (POR HACER) .........................101
9.2. HOJAS DE CARACTERÍSTICAS Y RECURSOS EN LA RED ..........101
9.3. DIRECCIONES DE FABRICANTES Y PROVEEDORES..................102
-3-
ÍNDICE DE ILUSTRACIONES
Figura 1 Vista general del prototipo en madera del robot .............................8
Figura 2 Vista lateral del robot ......................................................................8
Figura 3 Detalle de la batería del robot.........................................................9
Figura 4 Tarjeta de control del robot y radio enlace......................................9
Figura 5 Frontal del robot con los bumpers de colisión .............................. 10
Figura 6 Parte inferior del robot. ................................................................. 11
Figura 7 Detalle del bastidor delantero ....................................................... 11
Figura 8 Detalle de los sensores CNY70 del robot. .................................... 12
Figura 9 Tarjeta de control de motores con todos los sensores
conectados ................................................................................... 12
Figura 10 Comunicación serie un bit de arranque, 8 de datos y uno de
parada. ......................................................................................... 14
Figura 11 Módulo de radio frecuencia WIZ-434-SML-IA de Auriel ............... 15
Figura 12 Esquema de las tramas de comandos. ........................................ 17
Figura 13 Esquema de las tramas de ACK de comando. ............................. 17
Figura 14 Esquema de las tramas de estado ............................................... 18
Figura 15 Esquema de las tramas de píxeles de imágenes. ........................ 18
Figura 16 Detalle de la trama de datos de estado ........................................ 21
Figura 17 Gráfico del proceso de cálculo de la fila y columna de imagen.
..................................................................................................... 22
Figura 18 Esquema de la tarjeta de control de motores. .............................. 24
Figura 19 Sistema de alimentación de la tarjeta de control de motores. ...... 25
Figura 20 Polarización de los sensores CNY70. .......................................... 26
Figura 21 Conexión de los sensores CNY70................................................ 26
Figura 22 Polarización de los bumpers......................................................... 27
Figura 23 Conexión de los bumpers. ............................................................ 27
Figura 24 Esquema del driver de motores.................................................... 28
Figura 25 Conexiones del microcontrolador. ................................................ 29
Figura 26 Interfaz del programación AVR..................................................... 30
Figura 27 Circuito de reset. .......................................................................... 30
Figura 28 Lógica de adaptación para la interrupción mecánica.................... 31
Figura 29 Esquema de la tarjeta de control principal.................................... 54
Figura 30 Sistema de orientación de la cámara. .......................................... 56
Figura 31 Cámara digital M64282FP ............................................................ 57
-4-
Figura 32 Interfaz de la tarjeta principal con la cámara. ............................... 57

Figura 33 Asignación de terminales de la cámara digital al bus de datos .... 58
Figura 34 Conexiones del microcontrolador. ................................................ 58
Figura 35 Detalle del registro de estado COMM........................................... 69
Figura 36 Esquema de funcionamiento de los codificadores de enlace ....... 72
Figura 37 Placa de control del host .............................................................. 82
Figura 38 Detalle del adaptador MAX232..................................................... 83
Figura 39 Detalle de la conexión con la tarjeta de radio frecuencia ............. 83
Figura 40 LEDs de la placa de control.......................................................... 84
Figura 41 Pines de contacto de la tarjeta de radiofrecuencia WIZ-434-
SML-IA.......................................................................................... 85
Figura 42 Diagrama UML del paquete com.theexbteam.comm.................... 87
Figura 43 Diagrama UML del paquete com.theexbteam.robots ................... 89
Figura 44 Aspecto de la interface gráfica de usuario.................................... 91
Figura 45 Logotipo del lenguaje de programación Java de Sun
Microsystems................................................................................ 92
Figura 46 Logotipo del proyecto APACHE ANT ........................................... 92
-5-
ÍNDICE DE TABLAS
Tabla 1. Pila de protocolos. ........................................................................ 14
Tabla 2. Configuración de velocidad de las tarjetas WIZ-SML-IA. ............. 15
Tabla 3. Comandos de motores ................................................................. 19
Tabla 4. Comandos del sistema ................................................................. 20
Tabla 5. Comandos de imagen .................................................................. 20
-6-
1. INTRODUCCIÓN
1.1. OBJETIVOS
La práctica se compone de un robot motorizado con dos
servomotores, manipulados para funcionar como motores de continua con
caja reductora, y un sistema de adquisición de vídeo usando una cámara
CCD de 128x128 píxeles monocroma. El sistema está controlado
remotamente por un PC y una aplicación que recibirá las imágenes
capturadas por la cámara del robot y transmitirá las órdenes de
desplazamiento al robot.
El enlace se realiza mediante una tarjeta de radiofrecuencia half-

duplex de 100 kbps de la casa AURºEL. El enlace se controla desde un
PC por el puerto serie, estableciendo una comunicación directa con el
robot.
El robot está gobernado por una tarjeta con un microcontrolador

ATMEL AT90S8515 que se comunica con el PC del usuario, adquiere
datos desde la cámara y puede controlar otra tarjeta similar que conforma
el sistema de control motriz. Esta segunda tarjeta hace funcionar al robot
como un seguidor de línea al incorporar los sensores necesarios. Sin
embargo, el sistema motriz puede ser controlado por el usuario en un
modo de ejecución especial.
La microcámara que se emplea es el modelo M64282FP Artificial

Retina de Mitsubishi Electric o similares. Se orienta mediante un
servomotor a pesar de que el sistema tiene capacidad para controlar dos.
El objetivo buscado es la creación de un robot multifunción,

fácilmente reprogramable. Para ello se ha querido desarrollar una
plataforma multiuso con varios modos de ejecución, así cómo unas
librerías software para la comunicación vía radio y control del sistema.
1.2. DESCRIPCIÓN DEL ROBOT

Como se ha descrito antes el robot consta de distintas placas que se
montan sobre una estructura común. Se ha buscado crear un soporte
robusto y compacto para albergar los distintos sistemas del robot.
-7-
La estructura es de madera por su fácil manejo y poco peso. En la

parte superior del robot se colocan la batería, la tarjeta de radio, la tarjeta
principal y el sistema de la cámara. En la parte inferior se colocan los
motores y soportes necesarios así como la tarjeta de control de motores y
un bastidor en el que se hayan los sensores CNY70 encargados de la
detección de la línea.
Figura 1 Vista general del prototipo en madera del robot
Figura 2 Vista lateral del robot
-8-
La batería utilizada es una batería típica para aplicaciones de

radiocontrol. Es una batería de Ni-Ca con una tensión nominal de 7,2V.
Se ha elegido esta batería por su tamaño y por su durabilidad.
Proporciona potencia suficiente para alimentar todos los sistemas del
robot.
Figura 3 Detalle de la batería del robot
La tarjeta de radio, la cámara y la tarjeta de control principal forman

el cerebro del robot y se describen intensivamente en otros apartados.
Ocupan la parte superior del robot para facilitar el acceso a ellas. La
tarjeta de control tiene varias interfaces. A parte de los distintos
conectores para comunicarse con la tarjeta de radio, la de control de
motores y la cámara dispone de una interfaz de programación integrada.
Figura 4 Tarjeta de control del robot y radio enlace
-9-
También dispone de unos LEDs de indicación y un pulsador de reset.

Los LEDs se utilizan para notificar que la alimentación está encendida,
que la programación del microcontrolador está en curso o que se ha
activado una traza de depuración.
En la parte superior delantera también se colocan los sensores de

detección de colisión frontal.
Figura 5 Frontal del robot con los bumpers de colisión
En la parte inferior se colocan los motores sujetos por abrazaderas.

Son dos servomotores manipulados para funcionar como motores de
corriente continua con caja reductora. Los dos motores junto con una
rótula adherida a un zócalo forman el sistema motriz y de apoyo de robot.
- 10 -
Figura 6 Parte inferior del robot.
En la parte inferior también se colocan los sensores de colisión

trasera y los de detección de línea. Los sensores de detección de línea se
colocan en un bastidor ajustable en altura mediante unas gomas. Esto se
debe a que estos sensores tienen que estar cerca de la superficie a
explorar para proporcionar medidas fiables. Además el bastidor impide
que una luz ambiente excesiva induzca ruido en las lecturas.
Figura 7 Detalle del bastidor delantero
La colocación de los sensores se hace de forma que haya dos

sensores centrales que deben estar al mismo tiempo sobre la línea. Los
dos sensores laterales se colocan ligeramente retrasados con respecto a
los otros. Con esta colocación se consigue que si el robot se sale en una
- 11 -
curva por la inercia los sensores laterales sigan detectando la línea. En

este caso el robot deberá intensificar el giro para volver a la situación
deseada. Al estar estos dos sensores retrasados se maximiza la
probabilidad de que sigan detectando la línea si el robot se sale en una
cuerva.
Figura 8 Detalle de los sensores CNY70 del robot.
La tarjeta de control de motores se coloca en el espacio libre bajo el

robot. Consta de dos puertos de sensores, uno para los CNY70 (sensores
de línea) y otro para los bumpers (sensores de colisión). También dispone
de puertos para los motores y para comunicarse con la tarjeta principal.
Los otros dos puertos son el de programación y el de expansión. Este
último no se usa en esta aplicación y el primero es exactamente igual al
de la tarjeta principal.
Figura 9 Tarjeta de control de motores con todos los sensores conectados
En cuanto a la interfaz con el usuario se refiere, a los LEDs de

indicación de la otra tarjeta se añade uno más. También incorpora un
nuevo pulsador, el de marcha. El nuevo LED indica que el sistema motriz
se ha iniciado y está listo para arrancar. Cuando se enciende este LED el
- 12 -
robot espera a que el usuario pulse el botón de marcha para arrancar. El

sistema aplica un retardo antes de moverse para que el usuario pueda
apartar la mano.
- 13 -
2. PROTOCOLOS DE COMUNICACIONES
Se han definido dos protocolos de comunicaciones: uno para cada una de
las funciones principales del sistema, el control remoto del robot y el envío de
los datos al control remoto.
La pila de protocolos empleada es la siguiente:
Niveles Protocolos
RESTO END TO END APPLICATION
ENLACE LAPR
FÍSICO RS-232/TTLoRF
Tabla 1. Pila de protocolos.
Dado que solamente existe comunicación con una única unidad remota y
un único host controlador no hace falta especificar ningún sistema de
direccionamiento.
El nivel de enlace lleva a cabo las tareas de entramado, separación de los

distintos protocolos de comunicaciones y en el caso del protocolo de
comandos, asegurar que todos los datos enviados llegan a su destino, tal
como se detalla seguidamente.
2.1. EL NIVEL FÍSICO: ENLACE RADIOFRECUENCIA

La comunicación se lleva a cabo mediante una interface serie con
ocho bits de datos, uno de inicio y otro de parada a través de un enlace
de radiofrecuencia.
Figura 10 Comunicación serie un bit de arranque, 8 de datos y uno de parada.
Este enlace lo realizan las tarjetas Auriel WIZ-434-SML-IA y exige

una fragmentación de datos de 96 bytes por paquete, brindando un canal
de comunicaciones half-duplex de cadencia 100 kbps. Emplea la banda
- 14 -
libre de los 433 MHz para mandar los datos mediante una modulación 2-
FSK.
Figura 11 Módulo de radio frecuencia WIZ-434-SML-IA de Auriel
La interface entre la tarjeta de radiofrecuencia y el host destinatario

se realiza a una tasa binaria configurable entre los 9600 bps y los 115200
bps, siendo esta última cifra la empleada en nuestro sistema dada la alta
tasa de datos que se envían desde la unidad remota hacia el host de
control. La tasa binaria se configura mediante los switches 1 y 2 según la
tabla siguiente:
DS1 DS2 VELOCIDAD (bps)
Abierto Abierto 9600
Abierto Cerrado 19200
Cerrado Abierto 57600
Cerrado Cerrado 115200
Tabla 2. Configuración de velocidad de las tarjetas WIZ-SML-IA.
La tarjeta de radiofrecuencia se pone automáticamente a modular la

información a transmitir transcurrido un tiempo igual a 1,5 veces el
período de byte, T:
3 3 2+8
Tout = ·T = ·
2 2 vb
Para nuestro caso, dado que transmitimos a una cadencia de

115200 bps, resulta:
Tout ≈ 130µs
- 15 -
Sin embargo, según indican las hojas de características del

fabricante, el mínimo tiempo de guarda es de 500µs, que es el Tout que se
usará.
Finalmente, la tarjeta de radiofrecuencia tarda un tiempo Tmod en

modular un paquete de N bytes igual a:
Tmod = 3.6ms + ( N + 2)·0.156ms,
durante el cual no se puede mandar ningún dato a la tarjeta, pues

ésta los descarga automáticamente. El fabricante recomienda guardar
como precaución unos pocos milisegundos más antes de mandar el
siguiente paquete de datos, por lo que se ha tomado un valor de tiempo
de seguridad adicional de 2ms.
El módulo WIZ-SML-IA proporciona además capacidad de detección

de errores, activando el switch 3, entrega únicamente los datos si éstos
han pasado satisfactoriamente el checksum al que son sometidos. Para
nuestro caso, hemos usado esta característica para evitar sobrecargar el
microprocesador principal.
2.2. NIVEL DE ENLACE: LAPR

La información que se debe transferir a través del enlace
radiofrecuencia puede ser de dos tipos: órdenes o comandos y datos de
estado o imágenes. Dado que sólo se dispone de un único canal se
precisa de una multiplexación en el tiempo para poder transmitir toda esta
información y no tener problemas de mala interpretación.
Por ello se define el protocolo de enlace LAPR (Link Access Protocol

for Robots.) Este protocolo ofrece dos tipos de servicio, cada uno
orientado a cubrir las necesidades de envío de comandos o de datos. Las
tramas de bits se transmiten con un separador de trama, que es el byte
01111110 (126 en decimal) seguido de la cabecera identificadora de
servicio, la cabecera de control y los datos a enviar.
Cada servicio se identifica a través de un único bit LSAPID (Link

Service Access Point Identifider.) Así:
- 16 -
• LSAPID 0 Servicio de Comandos. Este servicio es un servicio

orientado a conexión fiable y confirmado. Se emplea para transmitir
desde el host de control a la unidad remota las órdenes, y por ello cada
orden es confirmada por el robot enviando una trama de ACK de
Comando:
Envío de Comando:
01111110 LSAPID 0 C FR ID COMANDO
7 0 7 6 5 0 7 0
Byte 0 Byte 1 Byte 2
Figura 12 Esquema de las tramas de comandos.
Para enviar un comando, la cabecera de control deberá incluir

su bit más significativo puesto a cero, seguido de cinco bits que
indican el identificador de trama (C FR ID.) El siguiente byte es el
comando a transmitir. Los dos últimos bytes, al ser ‘datos’, son
codificados para evitar que cadenas de la forma 01111110 se
confundan con separadores de trama, pudiendo llegar a ocupar, a
nivel físico 4 bytes el envío (sin contar con los bits de arranque y
parada.) Así, la ventana de transmisión de comandos queda con un
tamaño de 64 comandos, permitiendo ráfagas de hasta 64 órdenes.
En la implementación del software de control, la ventana no se
desplaza hasta haber recibido los ACKs de todos los comandos
recibidos.
Este servicio reenvía automáticamente los comandos no

confirmados hasta que sean confirmados, o bien se envíe el
comando reservado 0xFF de sincronización (función de
inicio/sincronización de la conexión.)
Envío de ACK de Comando:

01111110 LSAPID 1 C FR ID
7 0 7 6 5 4
Byte 0 Byte 1
Figura 13 Esquema de las tramas de ACK de comando.
Para confirmar un comando, el servicio 0 de enlace manda

automáticamente una trama compuesta por el separador de trama,
el LSAPID 0 y en la cabecera de control, el bit más significativo (ACK)
- 17 -
activo, seguido de los cinco bits del ID de trama. Los ACKs se

envían siempre que, o bien se haya recibido un comando con
FRAME ID igual al esperado o bien se haya recibido un comando ya
recibido anteriormente, y que por tanto, el hueco de la ventana de
recepción correspondiente a su FRAME ID contenga dicho comando.
• LSAPID 1 Servicio de Datos. Este servicio es un servicio no

orientado a conexión fiable y no confirmado. Independientemente de
que el host remoto esté escuchando, el robot transmite continuamente
el estado de la unidad y, salvo orden expresa del host de control, los
datos de la cámara. Como se puede transmitir tanto el estado como
píxeles de la cámara se sigue el siguiente criterio:
Envío de Estado:
01111110 LSAPID 0 IHB GL
7 0 7 6 5 4 3 2 1 0
Byte 0 Byte 1
Figura 14 Esquema de las tramas de estado
Donde se disponen de seis bits para los datos de estado. En el

apartado “Protocolo de datos” se explica detalladamente el uso de
cada uno de ellos.
Envío de Píxeles de Imágenes:

01111110 LSAPID 1 I ROW# PIXELES(…)
7 0 7 6 5 0 7 0
Byte 0 Byte 1 Byte 2,3…
Figura 15 Esquema de las tramas de píxeles de imágenes.
La cabecera de control incluye en sus seis bits menos

significativos los seis menos significativos de la fila a la que
pertenecen los píxeles que se reciben. La recomposición de la
imagen se detalla en el apartado “Protocolo de datos.”
2.3. PROTOCOLO DE COMANDOS

La implementación del protocolo de comandos destina un byte para
el envío de comandos, permitiendo el uso de hasta 256 órdenes distintas.
Las órdenes se dividen en tres tipos: mecánicas o de motores, de sistema
o de imagen.
- 18 -
2.3.1. ÓRDENES DE MOTORES

Las órdenes de motores se enmascaran con los dos bit más
significativos puestos a cero (00xxxxxx.) Se han definido catorce
órdenes de movimiento distintas que recogen todas las posibilidades
que se pueden realizar con los dos motores principales del robot.
Estas órdenes, con la máscara 0000xxxx se envían directamente
desde la tarjeta de control principal del robot hacia la tarjeta de
control de motores, que automáticamente pasa al modo manual.
Asimismo, la orden 1410 = 0x0E, de ‘MODO_AUTOMÁTICO’

no se envía a la tarjeta de control de motores. En vez de ello, lo que
se hace es poner el bit “MODE” (PC5) a 0 (automático.)
El conjunto de comandos de motores es el siguiente:
Nombre HEX Descripción

Recto 0x00 Desplazamiento hacia delante.
Giro Derecha 0x01 Gira a la derecha.
Giro Izquierda 0x02 Gira a la izquierda.
Marcha Atrás 0x03 Desplazamiento hacia atrás.
Desvío Derecha 0x04 Desplazamiento hacia delante y la
derecha.
Desvío Izquierda 0x05 Desplazamiento hacia delante y la
izquierda.
Gira Derecha Trasero 0x06 Desplazamiento hacia atrás y la
derecha.
Gira Izquierda Trasero 0x07 Desplazamiento hacia atrás y la
izquierda.
Acelerar 0x08 Aumentar la velocidad global.
Reducir 0x09 Decrementar la velocidad global.
Busca Línea Y Para 0x0a Busca la línea y para los motores.
Rota Derecha 0x0b Rotación (mueve dos motores) a la
derecha
Rota Izquierda 0x0c Rotación (mueve dos motores) a la
izquierda
No Definido 0x0d No definido
Modo Automático 0x0e Pasa a modo automático de
seguimiento de líneas.
Paro Total 0x0f Paro completo de los motores
Tabla 3. Comandos de motores
Todas las órdenes con máscara 00XXyyyy, con XX distinto de

00 e ‘y’ 0 ó 1 indistintamente no son procesadas actualmente, pero
se pueden implementar nuevos movimientos del robot.
- 19 -
2.3.2. ÓRDENES DEL SISTEMA

Actualmente existen únicamente dos comandos de sistema a
parte del comando reservado 0xff:

Ping 0xC1 Petición de respuesta, para comprobar
si la unidad remota responde.
System Reset 0xCF Reset completo de la tarjeta de control
del robot.
RESERVADO 0xFF Conexión interna, no permitido su
envío.
Tabla 4. Comandos del sistema
Las órdenes de sistema se enmascaran con los dos bits más

significativos puestos a uno.
2.3.3. ÓRDENES DE IMAGEN

Las órdenes de imagen se emplean para controlar la cámara
digital basada en el chip M64282FP de Mitsubishi. Con estos
comandos se puede iniciar o detener la captura de imágenes,
cambiar los modos de captura o alterar el tiempo de exposición.
También gestiona los movimientos los servos de la cámara para
orientar la vista del robot. Se emplea la máscara 01xxxxxx para
diferenciarlos del resto de comandos.

Mira Al Frente 0x40 Centra la vista al frente
Mira a la derecha 0x41 Gira el servo horizontal a la derecha
Mira a la izquierda 0x42 Gira el servo horizontal a la izquierda
Mira arriba 0x43 Gira el servo vertical hacia arriba
Mira abajo 0x44 Gira el servo vertical hacia abajo
Inicia captura Activa la señal START de inicio de
captura.
Reset cámara Reinicia la cámara con los valores por
defecto de la misma.
Carga Registros 0x59 Carga los ocho registros de
configuración de la cámara.
Fija Registro xxx 0x50-57 Fija como registro activo el contenido en
los tres bits menos significativos.
Fija Dato Bajo xxxx 0x70-7f Fija los cuatro bits menos significativos
del registro activo como los cuatro bits
menos significativos del comando
Fija Dato Alto xxxx 0x60-6f Fija los cuatro bits más significativos del
registro activo como los cuatro bits
menos significativos del comando.
Tabla 5. Comandos de imagen
- 20 -
Las primeras cinco órdenes se envían directamente al

microcontrolador de servos basado en un PIC16F84. Se envían a
través de cuatro pines, soportando el PIC16F84 ampliaciones de
funciones con el puerto de expansión de cuatro contactos.
Para cargar un registro de la cámara con un byte dado,

primeramente se deberá fijar el registro activo mediante ‘Fija
Registro xxx.’ Seguidamente, se cargan, en orden indistinto la parte
baja y la parte alta del byte a cargar mediante ‘Fija Dato Bajo xxxx’ y
‘Fija Dato Alto xxxx.’ Finalmente se manda el comando ‘Carga
Registros’ para que se actualicen todos los registros de la cámara.
2.4. PROTOCOLO DE DATOS

2.4.1. ESTADO DEL ROBOT
Los seis bits menos significativos del segundo byte de la trama
de datos de estado contienen distintos parámetros que monitorizan
el estado del robot:
01111110 LSAPID 0 IHB GL

7 0 7 6 5 4 3 2 1 0
Byte 0 Byte 1
Figura 16 Detalle de la trama de datos de estado
• IHB: bit 6, se pone a uno cuando el robot está transmitiendo las

filas mayores o iguales a 64 (64-127) de la imagen. Se emplea en
el gestor de imágenes para determinar la fila en la que almacenar
los datos de píxeles recibidos.
• 5-1: No usados en la implementación actual
• GL: bit 0, indica cuando está a uno que los sensores CNY70 de
la tarjeta controladora de motores han detectado la presencia de
la línea guía.
2.4.2. RECOMPONIENDO LA IMAGEN

El software de gestión de imagen deberá encargarse de la
tarea de recomposición de la imagen a partir de los píxeles que
reciba del robot.
- 21 -
Las tramas de datos de imagen son de longitud variable de

como mucho 96 bytes, y la cabecera contiene los seis bits menos
significativos de la fila a la que pertenecen los píxeles recibidos. La
cámara digital tiene una resolución de 128x128 píxeles y cada uno
de ellos se lee con una resolución de 256 niveles de gris. Al recibir
los datos, el software de gestión de cámara deberá ir alojando
consecutivamente los píxeles que reciba a partir de la posición de
columna cero y hasta alcanzar la posición de columna 127. La fila en
la que deberá guardar los datos se calcula tomando el bit de estado
IHB como bit más significativo y sumándole los seis bits menos
significativos contenidos en la cabecera de la trama de imagen:
n fila = IHB·2 6 + CABECERA[5..0]
Para evitar problemas de desincronización entre el píxel

mandado por la unidad remota y el software de control se envía
siempre que se inicia la trama la información necesaria para poder
determinar si se ha pasado a enviar la información de la siguiente fila.
FILA
COLUMNA
FILA
COLUMNA
LSAPID 1 I ROW# Aplicación de control

7 6 5 0
Byte 1
*26
LSAPID 0 IHB GL
7 6 5 4 3 2 1 0
Byte 1
Figura 17 Gráfico del proceso de cálculo de la fila y columna de imagen.
Finalmente, aunque la aplicación de control reciba más datos,

si alcanza la columna 127, pasará automáticamente a la siguiente
línea, descartando todos los datos que reciba hasta que vuelva a
- 22 -
encontrar un inicio de trama de imagen con un valor de línea de

imagen válido.
Todas estas tareas las realiza de forma automática la clase

ImageCore del paquete com.theexbteam.robots que se describe en
la parte de la aplicación de control remoto.
- 23 -
3. TARJETA DE CONTROL DE MOTORES

3.1. DESCRIPCIÓN DEL HARDWARE
Esta tarjeta fue creada con la idea de independizar los sistemas
motrices y de detección de línea del control de la cámara y de la tarjeta
de radio. Esta tarjeta es como la de cualquier microrobot seguidor. Se
pueden diferenciar cuatro bloques en la tarjeta, alimentación, sensores,
driver de motores y procesado. El esquema de la tarjeta es el que
muestra la figura.
U1 L7805/TO220
+7,2V +5V U2 L293
1 2
VIN VOUT MOT1_DIR0 2 3 D3 D4
1A 1Y
2
3 D1 MOT1_DIR1 7 6 1N4001 1N4001
GND 2A 2Y
1
1
+ C3 C1 C4 + C2 PWR_ON MOT2_DIR0 10 11 J6 C6
J5 220uF 100nF 100uF 100nF J4 MOT2_DIR1 15 3A 3Y 14 MOT1 100nF
PWR_IN PWR_OUT 4A 4Y
1
EN_MOT1 1 +7,2V
1/2EN
2
R3 EN_MOT2 9
470 3/4EN
+5V 16 D6 D5
8 VCC1
+7,2V VCC2 D9 D10 1N4001 1N4001
2
C9 + 1N4001
Y1 100uF J7 +7,2V
MOT2 1N4001 C10
XTAL1 XTAL2 100nF
1
U3 AT90S8515 +7,2V
C7 8MHz C8
GOT_LINE 39 21 CNY 1 15pF 15pF
MOTAC3 38 PA0/AD0 PC0/A8 22 CNY 2 D7 D8
MOTAC2 37 PA1/AD1 PC1/A9 23 CNY 3 +5V
MOTAC1 36 PA2/AD2 PC2/A10 24 CNY 4 1N4001 1N4001
MOTAC0 35 PA3/AD3 PC3/A11 25 BUMPER1 R21 470
MODE 34 PA4/AD4 PC4/A12 26 BUMPER2 +7,2V
MARCHA 33 PA5/AD5 PC5/A13 27 BUMPER3 D12
32 PA6/AD6 PC6/A14 28 BUMPER4 J16 +5V
PA7/AD7 PC7/A15 PROG
+5V +5V
MOT1_DIR0 1 10 EXP1 MOSI 1 2
D11 MOT1_DIR1 2 PB0/T0 PD0/RXD 11 EXP2 3 4
READY MOT2_DIR0 3 PB1/T1 PD1/TXD 12 MODE R22 10K RST 5 6 R14 R16
MOT2_DIR1 4 PB2/AIN0 PD2/INT0 13 INT_MEC SCK 7 8 10K 10K
5 PB3/AIN1 PD3/INT1 14 BUMP_TRAS MISO 9 10
MOSI 6 PB4/SS PD4 15 EN_MOT1 D13 RESET MARCHA
MISO 7 PB5/MOSI PD5/OC1A 16 EXP3 DIODO_RST
D14 SCK 8 PB6/MISO PD6/WR 17 EXP4 PROGRAMADOR SW1 SW2
R18 PB7/SCK PD7/RD RESET C12 C11
DEP RESET MARCHA
470 XTAL1 19 30 100nF 100nF
XTAL2 18 XTAL1 ALE 29 EN_MOT2 +5V U4A
XTAL2 OC1B
1
31 3 R15 R17
14
RESET 9 ICP U4C 2 1K 1K

RST
9
R1
GND
470 40 INT_MEC 8 7432

+5V VCC U4B
10
4
20
7432 6
7
5 J12 J14
7432 BUMPER1 4 BUMPER3 4

R10 10K 3 R19 10K 3
+5V 2 +5V 2
J3 J1 +5V +5V 1 1
8
GOT_LINE 7 EXP1 1
MOTAC3 6 EXP2 2 R12 R13 BUMPER1 BUMPER3
MOTAC2 EXP3 J8 J9
5 3 220 220
MOTAC1 4 EXP4 4
MOTAC0 3 CNY 1 4 CNY 2 4 J13 J15
MODE 2 3 3 BUMPER4 4
1 EXPAN R4 47K 2 R5 47K 2 BUMPER2 4 R20 10K 3
+5V 1 +5V 1 R11 10K 3 +5V 2
R23 +5V 2 1
1K +5V +5V 1
TARJ_PPAL U4D
12
BUMPER3 CNY 1 CNY2 BUMPER4

BUMP_TRAS 11 R6 R8 BUMPER2
J10 J11
13 BUMPER4 220 220
7432 CNY 3 4 CNY 4 4

3 3
R7 47K 2 R9 47K 2 Title
1 1 Tarjeta de control de motores para Robot LSED
+5V +5V
Size Document Number Rev
A4 1 4.0
CNY 3 CNY4
Date: Monday , June 23, 2003 Sheet 1 of 1
Figura 18 Esquema de la tarjeta de control de motores.
Para un mayor detalle, véase la figura 2 del apéndice B.
3.1.1. ALIMENTACIÓN
Este es un bloque fundamental pues la alimentación tiene que
estar muy estabilizada porque los motores son una fuente de ruido
impulsivo en las líneas de alimentación. La estabilización se
consigue separando la alimentación de los motores de la del resto
de la tarjeta.
- 24 -
Los motores se alimentan directamente desde la batería de

7,2V. El resto de la tarjeta necesita una tensión de alimentación de
5V, lo que se consigue mediante el regulador L7805. La
estabilización se realiza filtrando la alimentación con unos
condensadores de capacidad elevada. Los filtrados críticos se han
de realizar antes y después del regulador y en la entrada de potencia
de los drivers de motores. Con este montaje el ruido impulsivo no
afecta al correcto funcionamiento del sistema. Los motores toman la
carga almacenada en los condensadores en los picos de tensión y
no de la batería por lo que se evitan caídas de tensión en la
alimentación de a lógica de control.
U1 L7805/TO220
+7,2V +5V
1 2
VIN VOUT
3 D1
GND
1
1
+ C3 C1 C4 + C2 PWR_ON
J5 220uF 100nF 100uF 100nF J4
PWR_IN PWR_OUT
2
2
R3
470
Figura 19 Sistema de alimentación de la tarjeta de control de motores.
3.1.2. SENSORES
El robot ha de ser capaz de orientarse automáticamente. Para
la orientación deberá seguir una línea negra sobre un fondo blanco.
Adicionalmente se han de poder detectar posibles colisiones con
obstáculos.
Para poder seguir la línea se utilizan unos sensores de

infrarrojos tipo CNY70. Estos sensores integran un fotodiodo que
emite radiación infrarroja y un fototransistor que se polariza en
función de la radiación recibida. Si el sensor está sobre una
superficie negra la radiación emitida por el fotodiodo no se refleja y
el fototransistor está en situación de corte. Por el contrario, si el
sensor se posiciona sobre una superficie blanca el fototransistor
capta la radiación emitida por el fotodiodo.
La red para poder usar estos transistores es muy simple. Se

ha de polarizar el fotodiodo para que emita siempre con una
- 25 -
potencia lo suficientemente alta para que la radiación pueda ser

detectada. El fototransistor también se ha de polarizar para que este
en la zona activa o en corte dependiendo de la luz incidente en la
base. Los niveles entregados por el transistor han de ser
compatibles con la lógica empleada. El esquema de polarización es
el que se muestra en la siguiente figura.
+5V
R2 R1
220 47K
1
CNY 70
+5V
2
Figura 20 Polarización de los sensores CNY70.
Con esta red se satisfacen los requisitos mencionados. Hay

que tener cuidado al conectar los sensores a la placa. El usuario se
ha de cerciorar de que la conexión al molex verifica el esquema de la
siguiente.
+5V
R2
J1
220
4
OUT
4
3
R1 47K 2 CNY 70
+5V 1
CNY x
2
Figura 21 Conexión de los sensores CNY70.
La lectura del valor del CNY por el microcontrolador se realiza

por la línea out. Un valor 0 indica que el sensor está sobre la línea
negra, un valor 1 indica todo lo contrario.
Como medida de seguridad, para evitar dañar el sensor o

lecturas erróneas, las conexiones se han de aislar bien. En nuestro
caso se usó un aislante termoretráctil para aislar cada una de las
patas del sensor de las demás. También hay que destacar que los
- 26 -
sensores se colocan en una pieza de madera que no deja pasar la

luz. Esto es importante porque contribuye a eliminar la luz ambiental
haciendo las lecturas más fiables.
Para poder detectar obstáculos en el camino se usaron unos

sensores tipo bumper. Estos elementos no son en realidad sensores
sino pulsadores en un encapsulado especial. La red de polarización
será por lo tanto muy simple y se corresponde a la mostrada en la
siguiente figura.
+5V
+5V
R1
10K
BUMPER NO
NC
Figura 22 Polarización de los bumpers.
La conexión con los molex ha de ajustarse el esquema que se

muestra a continuación para que las lecturas sean correctas.
J1
OUT
4 BUMPER NO
+5V R1 10K 3
2
1 NC
BUMPERx
Figura 23 Conexión de los bumpers.
3.1.3. DRIVER DE MOTORES

La tarjeta de control incluye el circuito de potencia necesario
para atacar el sistema motriz del robot. Los dos motores que
conforman este sistema se excitan a través de un circuito
denominado puente en H. Este tipo de circuitos permiten que los
niveles lógicos de la tarjeta controlen las grandes corrientes que
circulan por los devanados de los motores.
Se ha optado por un puente en H integrado que permite la

rotación en ambos sentidos de los dos motores, el L293. La
configuración elegida hace que cada motor se controla con tres bits,
dos para seleccionar el sentido de giro y otro para arrancarlo. Los
- 27 -
bits para seleccionar el sentido de giro pueden parar el motor si

toman el mismo valor. Si toman distintos valores estos bits los
motores girarán en distintos sentidos. Para la misma combinación
cada uno de los motores gira en sentidos contrarios debido a su
orientación. El tercer bit se conecta a uno de los canales PWM del
microcontrolador para poder controlar la velocidad de giro. Este
control se realiza variando el ciclo de trabajo del PWM. El esquema
de este bloque es el de la figura siguiente.
U2 L293
MOT1_DIR0 2 3 D3 D4
1A 1Y
2
MOT1_DIR1 7 6 1N4001 1N4001
MOT2_DIR0 10 2A 2Y 11 J6 C6
MOT2_DIR1 15 3A 3Y 14 MOT1 100nF
4A 4Y
1
EN_MOT1 1 +7,2V
EN_MOT2 9 1/2EN
3/4EN
+5V 16 D6 D5
8 VCC1
+7,2V VCC2 D9 D10 1N4001 1N4001
2
C9 + 1N4001
100uF J7 +7,2V
MOT2 1N4001 C10
100nF
1
+7,2V
D7 D8
1N4001 1N4001
+7,2V
Figura 24 Esquema del driver de motores.
En el esquema se puede observar que la lógica se alimenta a

5 voltios mientras que los devanados de los motores se alimentan
directamente de las baterías. Se ha comentado ya que los motores
producen un ruido impulsivo por lo que hay que tener en cuenta esto.
Para este fin hay que filtrar la alimentación de la línea de potencia
del puente en H (condensador 9 en el esquema) y las conexiones de
los motores (condensadores 6 y 10 en el esquema).
Este ruido impulsivo puede además dañar los motores puesto

que la tensión de trabajo está ligeramente por encima de la nominal
de los motores. Esta situación provoca que los devanados de los
motores se puedan fundir si el ruido es demasiado fuerte. Para evitar
esto es necesario conectar unos diodos de protección que eviten las
oscilaciones de la tensión de alimentación y absorban los excesos
de corriente que dañarían los motores.
- 28 -
3.1.4. PROCESADO
Este bloque de la tarjeta tiene como finalidad coordinar el
funcionamiento de los bloques de sensores y driver de motores
además de realizar las órdenes recibidas de la tarjeta principal.
El núcleo de este bloque es el microcontrolador, como era de

esperar. Este se encarga de todo el procesado. En la figura 2.7 se
puede ver la disposición de los puertos.
U3 AT90S8515
GOT_LINE 39 21 CNY 1
MOTAC3 38 PA0/AD0 PC0/A8 22 CNY 2
MOTAC0 35 PA3/AD3 PC3/A11 25 BUMPER1
MODE 34 PA4/AD4 PC4/A12 26 BUMPER2
MARCHA 33 PA5/AD5 PC5/A13 27 BUMPER3
32 PA6/AD6 PC6/A14 28 BUMPER4
PA7/AD7 PC7/A15
MOT1_DIR0 1 10 EXP1
D11 MOT1_DIR1 2 PB0/T0 PD0/RXD 11 EXP2
READY MOT2_DIR0 3 PB1/T1 PD1/TXD 12 MODE
MOT2_DIR1 4 PB2/AIN0 PD2/INT0 13 INT_MEC
5 PB3/AIN1 PD3/INT1 14 BUMP_TRAS
MOSI 6 PB4/SS PD4 15 EN_MOT1
MISO 7 PB5/MOSI PD5/OC1A 16 EXP3
D14 SCK 8 PB6/MISO PD6/WR 17 EXP4
R18 PB7/SCK PD7/RD
DEP
470 XTAL1 19 30
XTAL2 18 XTAL1 ALE 29 EN_MOT2
XTAL2 OC1B
31
RESET 9 ICP
R1 RST
470 40
20
+5V VCC
GND
Figura 25 Conexiones del microcontrolador.
Los sensores se conectan al puerto C. Este puerto no tiene

ninguna funcionalidad adicional por lo que no se sacrifican recursos
en la lectura de los sensores.
El control de la dirección de los motores se hace con los cuatro

bits menos significativos del puerto B. El bit 5 se usa como traza de
depuración, se le conecta un LED que el usuario puede encender
por software para controlar la ejecución del programa. El resto de los
bits de este puerto se utilizan para el programador serie. La interfaz
de este programador es la que especifica el fabricante para este
modelo. Su esquema se puede ver en la figura.
- 29 -
+5V
R21 470
D12
PROG J16 +5V
MOSI 1 2
3 4
R22 10K RST 5 6
SCK 7 8
MISO 9 10
D13
DIODO_RST
PROGRAMADOR
RESET
Figura 26 Interfaz del programación AVR.
El LED PROG se ilumina mientras se esté programando el

microcontrolador. El otro diodo sirve para que el programador pueda
forzar un reset si pone RST a cero. Sin embargo en condiciones
normales el reset estará a nivel alto. El circuito completo que se
conecta a la pata de reset del microcontrolador es el que muestra la
siguiente figura.
RST
+5V
R22 10K +5V
D13 R14
DIODO_RST 10K
RESET
SW1
C12 RESET
100nF
R15
1K
Figura 27 Circuito de reset.
Como se puede observar, mientras que el pulsador no se

presione o no se fuerce externamente RST a 0V, la señal de reset
estará a nivel alto. Sin embargo, en el momento en el que se pulse el
botón de reset hardware o se fuerce RST a 0V, la línea RESET
tomará un voltaje que el microcontrolador interpretará como nivel
bajo, ejecutándose la rutina de reset.
El puerto A se destina a la interacción con agentes exteriores.

Por agentes exteriores nos referimos al usuario o a la tarjeta
principal. Los dos bits más significativos se destinan a interactuar
con el usuario.
- 30 -
Una vez se ha ejecutado la rutina de reset el robot queda en

espera hasta que la línea MARCHA (bit 6 del puerto A) toma un 0
lógico. Esta situación de espera se indica encendiendo el LED
READY (bit 7 del puerto A). Cuando el usuario presione el pulsador
MARCHA (ver figura 2.1) el robot empezará la ejecución del
programa de modo automático tras aplicar un retardo.
Los otros seis bits se utilizan para la comunicación entre

tarjetas. El bit cinco indica el modo en el que se tiene que ejecutar el
programa de motores. Si está a nivel alto el modo será el automático,
sino, será manual. El bit menos significativo lo activa el
microprocesador cuando se coloca sobre la línea al ejecutar la orden
de buscar y parar. El resto de los bits determinan el código de la
orden que debe ejecutar el robot en modo manual.
Al puerto D se conectan otras señales de control. Los bits 0, 1,

6 y 7 son bits de expansión y no se usan en esta aplicación. Los bits
2 y 3 son las interrupciones externas.
La interrupción 0 es la de modo, cuando MODE conmuta a

cero se dispara la interrupción y se pasa a ejecutar el modo manual.
La interrupción 1 se dispara cuando alguno de los dos bumpers
delanteros detecta un choque o el robot se separa de la línea. Sin
embargo, en esta aplicación en la tarjeta se a cortado la pista que
detecta que se ha separado de la línea. Para que la interrupción 1
funcione como se ha descrito es necesario añadir la siguiente lógica
de adaptación.
+5V U4A
1
BUMPER1
3
14
U4C
2
BUMPER2
9
INT_MEC 8 7432
10
U4B
4
CNY 1
7432 6
7
CNY 2
7432
Figura 28 Lógica de adaptación para la interrupción mecánica.
- 31 -
El bit 4 le indica al microprocesador si ha habido una colisión

por detrás. Los otros dos bits que faltan por comentar son las salidas
de los canales PWM que son OC1A y OC1B.
3.2. DESCRIPCIÓN DEL SOFTWARE.

El microcontrolador se ha programado íntegramente en lenguaje
ensamblador. El ensamblador elegido es el suministrado por ATMEL para
su familia de controladores AVR. En los siguientes apartados se
describen los distintos módulos del software de la tarjeta de control.
3.2.1. EQUIVALENCIAS Y VECTORES DE INTERRUPCIÓN

Para poder variar los parámetros del programa cómodamente
sin producir errores se definen unas variables globales. Para esto se
definen distintos grupos de equivalencias.
El primer grupo de equivalencias se usa para poder trabajar

con los registros de entrada salida y configuración del
microcontrolador usando sus nombres y no sus direcciones. El
código es el sigue a continuación.
; Registros de entrada y salida

.EQU SREG = 0x3f
.EQU SPH = 0x3e
.EQU SPL = 0x3d
.EQU GIMSK = 0x3b
.EQU GIFR = 0x3a
.EQU TIMSK = 0x39
.EQU TIFR = 0x38
.EQU MCUCR = 0x35
.EQU TCCR0 = 0x33
.EQU TCNT0 = 0x32
.EQU TCCR1A = 0x2f
.EQU TCCR1B = 0x2e
.EQU TCNT1H = 0x2d
.EQU TCNT1L = 0x2c
.EQU OCR1AH = 0x2b
.EQU OCR1AL = 0x2a
.EQU OCR1BH = 0x29
.EQU OCR1BL = 0x28
- 32 -
.EQU ICR1H = 0x25

.EQU ICR1L = 0x24
.EQU WDTCR = 0x21
.EQU PORTA = 0x1b
.EQU DDRA = 0x1a
.EQU PINA = 0x19
.EQU PORTB = 0x18
.EQU DDRB = 0x17
.EQU PINB = 0x16
.EQU PORTC = 0x15
.EQU DDRC = 0x14
.EQU PINC = 0x13
.EQU PORTD = 0x12
.EQU DDRD = 0x11
.EQU PIND = 0x10
Los parámetros principales con los que trabaja la tarjeta son
los ciclos de trabajo de los PWM y los bits de dirección de los
motores. Para poder ajustar fácilmente los valores de estos
parámetros se usa otro grupo de equivalencias.
;Constantes de velocidad y dirección para los motores

;Duty cycle = 80%
.EQU VEL_MAX = 0x0332
;Duty cycle = 40%
.EQU VEL_MED = 0x0199
;Duty cycle = 60%
.EQU VEL_MAX2 = 0x0266
;Duty cycle = 20%
.EQU VEL_MED2 = 0x0133
;Parada rápida
.EQU STOP = 0x00
;Marcha directa
.EQU GO = 0x06
;Giro a la izquierda
.EQU LEFT = 0x02
;Giro a la derecha
.EQU RIGHT = 0x04
;Marcha inversa
.EQU BACK = 0x09
;Rotación a la izquierda
- 33 -
.EQU RLEFT = 0x0a

;Rotación a la derecha
.EQU RRIGHT = 0x05
Los últimos parámetros que conviene poder ajustar son los de
la rutina de retardo. Esto es necesario para controlar la distancia que
recorre el robot durante la interrupción de choque tal y como se verá
más adelante. Las equivalencias mencionadas se listan a
continuación.
;Constantes para la rutina de retardo

;Retardo por vuelta
.EQU RET_V = 0xff
;Número de vueltas
.EQU VUELTAS = 0xff
En el mismo archivo se incluye la tabla de vectores de
interrupción. Esta tarjeta solo debe procesar tres fuentes de
interrupción, que son la de reset y las dos externas. Si se dispara
cualquier otra interrupción se debe a un error por lo que el
microprocesador ha de ejecutar la rutina de reset para que el usuario
se percate de ello y depure el programa. La tabla se describe a
continuación.
.ORG 0x000
;Salto a rutina de reset
rjmp RESET
;Salto a rutina de cambio de modo
rjmp INT_MODE
;Salto a rutina de desvío o colisión
rjmp INT_MEC
;Si saltan estas interrupciones se debe a un error
rjmp RESET
rjmp RESET
rjmp RESET
rjmp RESET
rjmp RESET
rjmp RESET
rjmp RESET
rjmp RESET
rjmp RESET
- 34 -
rjmp RESET
3.2.2. RUTINA DE RESET

Esta rutina debe configurar el timer 1 para funcionar como un
PWM de dos canales, los sentidos (entrada o salida) de los puertos,
las fuentes de interrupción y el puntero de pila. Para esto el código a
ejecutar se puede consultar en las hojas del fabricante. El código
que se le ha cargado al robot es el aquí listado.
;Código de la rutina de reset

RESET:
clr r16
;Interrup. deshabilitadas
out SREG,r16
;Interrup. de los contadores deshabilitadas
out TIMSK,r16
ldi r16,0xc0
;Interrup. externas permitidas
out GIMSK,r16
ldi r16,0x0f
;Sin RAM externa ni modo SLEEP e interrup. por flanco
positivo
out MCUCR,r16
ldi r16,0xa3
;Timer1 como PWM 10-bit no invertido
out TCCR1A,r16
ldi r16,0x02
;Frecuencia del timer1 es CLK/8
out TCCR1B,r16
clr r16
out OCR1AH,r16
out OCR1AL,r16
out OCR1BH,r16
;Ambos canales del PWM siempre a cero (Motores
parados)
out OCR1BL,r16
;Timer0 parado
out TCCR0,r16
ldi r16,0x02
out SPH,r16
ldi r16,0x5f
- 35 -
;SP al final de la RAM

out SPL,r16
ldi r16,0x81
ldi r17,0x5f
clr r18
ldi r19,0x20
;Configuración del puerto A
out DDRA,r16
;Configuración del puerto B
out DDRB,r17
;Configuración del puerto C
out DDRC,r18
;Configuración del puerto D
out DDRD,r19
Después de haber configurado el microcontrolador de acuerdo
con nuestras necesidades hay que notificárselo al usuario. Para esto
la tarjeta debe encender el LED de READY y quedarse en espera
hasta que se pulse el botón de MARCHA. Una vez pulsado se aplica
un retardo y comienza la ejecución del modo automático.
;Encendemos el LED de READY

sbi PORTA,7
ESP:
;Si MARCHA no está pulsado esperamos
sbic PINA,6
rjmp ESP
;Apagamos el LED de READY
cbi PORTA,7
;Aplicamos un retardo antes de arrancar
rcall RETARDO
rcall RETARDO
rcall RETARDO
;El robot siempre empieza en modo automático
rjmp AUTOMAT
En el momento en el que el robot se queda en espera activa
ejecuta dos instrucciones. La segunda de ellas, la que cierra el bucle,
se salta cuando la pista de marcha se pone a cero.
- 36 -
3.2.3. MODO AUTOMÁTICO

El modo automático es el modo de ejecución por defecto.
Cuando la tarjeta de control se haya en este modo el robot se
comporta como un microrobot seguidor normal. Esto quiere decir
que sigue un camino definido por una línea negra sobre un fondo
blanco.
Como se ha visto en los apartados anteriores el robot dispone

de cuatro sensores capaces de distinguir un fondo negro de otro
blanco. Estos sensores se disponen de tal forma que dos de ellos,
los centrales, deben estar siempre sobre la línea negra. Cuando se
produce alguna desviación se debe modificar la marcha de los
motores para recuperar la situación ideal. Adicionalmente, si se
detecta alguna colisión se ejecuta una interrupción que hace que el
robot rodee el obstáculo que la provocó. Sin embargo el código de
esta instrucción se explica en un apartado posterior.
El software correspondiente a este modo se divide en varios

sectores. El primero de ellos es el que se encarga de cargar lo
registros de velocidades con los valores que se van a utilizar,
habilitar las interrupciones y arrancar los motores. Los registros 20 y
21 tienen el valor de configuración del PWM para velocidad media y
los 22 y 23 para la rápida.
AUTOMAT:
ldi r20,HIGH(VEL_MED)
ldi r21,LOW(VEL_MED)
ldi r22,HIGH(VEL_MAX2)
ldi r23,LOW(VEL_MAX2)
;Habilitamos las interrupciones
sei
;Los registros 20 y 21 tienen el valor VEL_MED
;Los registros 22 y 23 tienen el valor VEL_MAX
;Arrancamos ambos PWM a velocidad media
out OCR1AH,r20
out OCR1AL,r21
out OCR1BH,r20
out OCR1BL,r21
- 37 -
Después de haber hecho estos ajustes iniciales comienza el

bucle central del programa que lo único que hace es comprobar una
y otra vez lo que leen los sensores y actúa en consecuencia.
Primero se miran los dos sensores centrales.
BAUT:
;Leemos el puerto C
in r18,PINC
;Operaremos sobre el registro 24
mov r24,r18
;Ponemos a cero todos los bits menos el bit0 y el
bit1
andi r24,0x03
;Si no estamos sobre la línea hay que girar
brne GIR1
ldi r17,GO
;Si estamos sobre la línea seguimos recto
out PORTB,r17
out OCR1AH,r22
out OCR1AL,r23
out OCR1BH,r22
;Fijamos la velocidad al máximo
out OCR1BL,r23
rjmp BAUT
GIR1:
;Ponemos a cero todos los bits menos el bit1
andi r24,0x02
;Si el bit1 no es cero hay que mirar el bit0
brne GIR2
;Si el bit1 es cero es que el bit 0 es 1
ldi r17,GO
;Seguimos hacia delante
out PORTB,r17
out OCR1AH,r20
out OCR1AL,r21
;El lado de la derecha se ha quedado fuera de la
línea
out OCR1BH,r22
;por lo que el motor izquierdo tiene que reducir
out OCR1BL,r23
;Ponemos el flag T a uno (desviados por la derecha)
- 38 -
set
rjmp BAUT
GIR2:
mov r24,r18
;Ponemos a cero todos los bits menos el bit0
andi r24,0x01
;Si los bits 0 y 1 estaban a uno hemos perdido la
línea
brne GIR3
;Si estamos aquí es que el bit0 era 0 y el bit1 era 1
ldi r17,GO
;Esto quiere decir que nos hemos desviado por la
izquierda
out PORTB,r17
out OCR1AH,r22
out OCR1AL,r23
out OCR1BH,r20
;El motor derecho tiene que reducir
out OCR1BL,r21
;Ponemos el flag T a cero (desviados por la izquierda)
clt
rjmp BAUT
Se puede ver que si alguno de los dos sensores centrales veía
a la línea no se hacen más comprobaciones y se vuelve al bucle. En
el caso de que los sensores centrales hayan perdido la línea se
consultan los laterales.
GIR3:
;Tenemos que comprobar los CNY secundarios
mov r24,r18
;Comprobamos el valor del CNY4
andi r24,0x08
;Si este CNY no está sobre la línea seguimos
comprobando
brne GIR4
;Si tenemos la línea bajo el CNY4 hay que girar a la
izquierda
ldi r17,RIGHT
out PORTB,r17
out OCR1AH,r20
out OCR1AL,r21
out OCR1BH,r20
- 39 -
;Ambos motores reducen la marcha

out OCR1BL,r21
;Ponemos el flag T a uno (desviados por la derecha)
set
rjmp BAUT
GIR4:
mov r24,r18
;Comprobamos el valor del CNY3
andi r24,0x04
;Si no tenemos línea en ningún CNY hay que buscarla
brne ROT
;Si tenemos la línea bajo el CNY3 hay que girar a la
derecha
ldi r17,LEFT
out PORTB,r17
out OCR1AH,r20
out OCR1AL,r21
out OCR1BH,r20
out OCR1BL,r21
;Ponemos el flag T a cero (desviados por la izquierda)
clt
rjmp BAUT
Puede parecer cuando se quiere girar a la derecha se use la
variable LEFT es una incongruencia. Sin embargo, la variable LEFT
indica que el motor derecho se para y el izquierdo sigue avanzando.
Finalmente si se ha perdido la línea por completo se debe parar el
robot y girar sobre sí mismo hasta encontrarla. Es posible que el
lector se haya percatado que en las comprobaciones anteriores se
almacena en el bit T del registro de estado el flanco bajo el cual fue
vista la línea por última vez. El robot rotará en el sentido que indique
este bit.
ROT:
;Antes de invertir los motores hay que pararlos
ldi r17,STOP
;(1 useg aprox.)
out PORTB,r17
brtc ROT2
- 40 -
;Si estamos desviados por la derecha hay que rotar

hacia la izquierda
ldi r17,RRIGHT
rjmp RT
ROT2:
;Si no hay que rotar hacia la derecha
ldi r17,RLEFT
RT:
out PORTB,r17
out OCR1AH,r20
out OCR1AL,r21
out OCR1BH,r20
out OCR1BL,r21
rjmp BAUT
Algo que es muy importante y que el usuario ha de tener en
cuenta es que hay que parar los motores antes de invertirlos.
Aunque en el momento de invertir los motores estos sigan girando
en la dirección anterior no es problemático. En este caso se
produciría un pico de tensión, que es lo que queremos evitar, pero
será mucho menos intenso que si invertimos la marcha con los
motores alimentados. Por este motivo es de gran importancia pasar
por el estado de parada rápida antes de cambiar el sentido de giro
de los motores.
Otro comentario de utilidad e que al leer de los puertos

externos (in rxx,PINX) hay que usar el registro PINX porque si se
usara PORTX la lectura sería incorrecta. Este detalle no viene
especificado en la descripción del microcontrolador y supuso un fallo
en tiempo de ejecución que nos hizo perder mucho tiempo hasta dar
con él .
3.2.4. MODO MANUAL

La rutina de motores del robot se puede ejecutar en modo
manual. El usuario envía órdenes que decodifica la tarjeta principal y
se lo notifica a la de control.
- 41 -
La tarjeta de control sabe en qué modo está por el estado de la

pista MODE. Si esta pata está a cero el modo ha de ser el
automático. Un flanco de subida en esta pata provoca una
interrupción de cambio de modo. En la rutina manual el
microcontrolador ha de leer constantemente el puerto A para ver la
instrucción a ejecutar. Al final del bucle ha de comprobar el estado
de MODE para seguir en modo manual o cambiar al modo
automático.
Antes de ejecutar el bucle central de la rutina no hay que hacer

ningún ajuste puesto que todos los cambios los controla el usuario.
Primero se ha de leer la orden y calcular la posición de la tabla de
órdenes a la que se ha de saltar. Como el microcontrolador no tiene
modo indexado hay que sumar el índice, multiplicado por dos, a la
base de la tabla antes del salto.
;Código para el modo manual

MANUAL:
in r16,PINA
lsr r16
;Leemos la orden a los motores
andi r16,0x0f
;Multiplicamos por dos
lsl r16
;Utilizamos el registro z para guardar un offset al
que sumamos el número de orden multiplicado por dos
para calcular la siguiente instrucción a procesar
ldi r30,LOW(OFFST)
ldi r31,HIGH(OFFST)
add r30,r16
ijmp
Cada celda de la tabla contiene dos instrucciones, por eso hay
que multiplicar el índice por dos. Estas instrucciones son una
llamada a la subrutina asociada a cada orden y un salto a las
comprobaciones finales.
OFFST:
;La orden 0x0 es seguir recto
rcall RECTO
- 42 -
rjmp CMD
;La orden 0x1 es giro derecha
rcall GD1
rjmp CMD
;La orden 0x2 es giro izquierda
rcall GI1
rjmp CMD
;La orden 0x3 es dar marcha atrás
rcall ATRAS
rjmp CMD
;La orden 0x4 es desvio derecha
rcall GD0
rjmp CMD
;La orden 0x5 es desvio izquierda
rcall GI0
rjmp CMD
;La orden 0x6 es giro derecha trasero
rcall GD2
rjmp CMD
;La orden 0x7 es giro izquierda trasero
rcall GI2
rjmp CMD
;La orden 0x8 es acelerar
rcall ACLR
rjmp CMD
;La orden 0x9 es reducir
rcall FRNR
rjmp CMD
;La orden 0xa es buscar línea y parar
rcall BUSCL
rjmp CMD
;La orden 0xb es rotar hacia la izquierda
rcall ROTI
rjmp CMD
;La orden 0xc es rotar hacia la derecha
rcall ROTD
rjmp CMD
;La orden 0xd no está definida
rcall ERR
rjmp CMD
- 43 -
;La orden 0xe no está definida

rcall ERR
rjmp CMD
;La orden 0xf es parar el robot
rcall PARA
Al final del bucle se actualiza el bit T tal y como se explica en
la rutina automática. Esto se hace para mantener una referencia de
la línea. Finalmente, tras comprobar el estado de MODE se vuelve a
saltar al programa correspondiente.
CMD:
in r16,PINA
;Actualizamos el flag T
rcall FLG
;Comprobamos el flag de MODE (PA5)
andi r16,0x20
;Si seguimos en modo manual volvemos al bucle
brne MANUAL
rjmp AUTOMAT
3.2.5. INTERRUPCIONES
Las dos interrupciones que se han de comentar son las
debidas a fuentes externas puesto que la de reset se explica en otro
apartado. Estas fuentes pueden indicar un cambio de modo o una
colisión.
El código de la interrupción de cambio de modo es muy

sencillo. Simplemente saca de la pila la dirección de retorno y la
cambia por la de la rutina manual. También para el motor para que
se ejecute la orden que ha provocado la interrupción.
;Código de la interrupción de cambio de modo

INT_MODE:
ldi r17,STOP
;Paramos el robot
out PORTB,r17
pop r27
pop r28
;Modificamos la dirección de retorno para que se
ejecute el programa manual
ldi r27,HIGH(MANUAL)
- 44 -
ldi r28,LOW(MANUAL)
push r28
push r27
reti
La otra interrupción es un poco más complicada. Primero se
comprueba que los bumpers siguen presionados, no sea que el
obstáculo se ha desplazado y ha liberado a los bumpers. De todas
formas esta situación es poco probable puesto que entre la
activación de la interrupción y la comprobación pasa un tiempo muy
pequeño. Después de esto, el robot da marcha atrás y aplica un
retardo suficiente para apartarse del obstáculo.
;Código de la interrupción de colisión

INT_MEC:
push r24
push r18
in r18,PINC
mov r24,r18
;Si los bumpers delanteros están sin presionar
andi r24,0x30
;Terminamos con la interrupción
breq FIN
push r17
ldi r17,STOP
;Paramos antes de invertir
out PORTB,r17
push r20
push r21
;Damos marcha atrás
ldi r17,BACK
out PORTB,r17
;Ponemos los motores a velocidad alta
out OCR1AH,r22
out OCR1AL,r23
out OCR1BH,r22
out OCR1BL,r23
rcall RETARDO
rcall RETARDO
- 45 -
rcall RETARDO
rcall RETARDO
rcall RETARDO
rcall RETARDO
rcall RETARDO
rcall RETARDO
rcall RETARDO
rcall RETARDO
;Paramos antes de invertir
ldi r17,STOP
out PORTB,r17
Después de esto comprueba cual de los dos bumpers golpeó
el obstáculo y gira en consecuencia. Si fueron ambos bumpers los
que golpearon lo que hace es rotar. Después de esto el robot que da
parado. La rutina principal, sea la manual o automática, se
encargará de determinar el siguiente movimiento del robot.
;Comprobamos el valor del bumper1

andi r24,0x10
;Si está a cero el bumper2 está pulsado
brne BP1
;Si hemos chocado por la izquierda giramos a la
derecha
ldi r17,RIGHT
out PORTB,r17
rcall RETARDO
ldi r17,STOP
;Paramos después de esquivar
out PORTB,r17
;Hemos terminado
rjmp TER
BP1:
mov r24,r18
;Comprobamos el valor del bumper 2
andi r24,0x20
;si está a cero bumper1 está pulsado
brne BP2
;Si hemos chocado por la derecha giramos a la
izquierda
ldi r17,LEFT
out PORTB,r17
- 46 -
rcall RETARDO
ldi r17,STOP
;Paramos después de esquivar
out PORTB,r17
;Hemos terminado
rjmp TER
BP2:
;Colisión frontal
brtc ESQ2
hacia la izquierda
ldi r17,RLEFT
rjmp ESQ
ESQ2:
ldi r17,RRIGHT
ESQ:
out PORTB,r17
rcall RETARDO
ldi r17,STOP
;Paramos después de esquivar y terminamos
out PORTB,r17
TER:
pop r21
pop r20
pop r17
FIN:
;Recuperamos registros y terminamos
pop r18
pop r24
reti
3.2.6. SUBRUTINAS
Las subrutinas asociadas a las órdenes del modo manual se
agrupan en un archivo. Estas subrutinas son, en su mayoría, para
avanzar, parar o girar y su código es el mismo que se utiliza en el
resto del programa. Por esta razón no hay mucho que comentar
sobre estas subrutinas. Su código se muestra a continuación.
RECTO:
ldi r17,GO
- 47 -
;El robot irá recto a toda velocidad

out PORTB,r17
out OCR1AH,r22
out OCR1AL,r23
out OCR1BH,r22
out OCR1BL,r23
ret
GD1:
ldi r17,RIGHT
;El robot girará a la izquierda a velocidad media
out PORTB,r17
out OCR1AH,r20
out OCR1AL,r21
out OCR1BH,r20
out OCR1BL,r21
ret
GI1:
ldi r17,LEFT
;El robot girará a la derecha a velocidad media
out PORTB,r17
out OCR1AH,r20
out OCR1AL,r21
out OCR1BH,r20
out OCR1BL,r21
ret
ATRAS:
;Hay que parar antes de invertir los motores
rcall PARA
ldi r17,BACK
;El robot irá marcha atrás a velocidad media
out PORTB,r17
out OCR1AH,r20
out OCR1AL,r21
out OCR1BH,r20
out OCR1BL,r21
ret
- 48 -
GD0:
ldi r17,GO
;El robot se desviará a la derecha
out PORTB,r17
out OCR1AH,r20
out OCR1AL,r21
out OCR1BH,r22
out OCR1BL,r23
ret
GI0:
ldi r17,GO
;El robot se desviará a la izquierda
out PORTB,r17
out OCR1AH,r22
out OCR1AL,r23
out OCR1BH,r20
out OCR1BL,r21
ret
GD2:
rcall PARA
ldi r17,BACK
;El robot se desviará a la derecha marcha atrás
out PORTB,r17
out OCR1AH,r20
out OCR1AL,r21
out OCR1BH,r22
out OCR1BL,r23
ret
GI2:
rcall PARA
ldi r17,BACK
;El robot se desviará a la izquierda marcha atrás
out PORTB,r17
out OCR1AH,r22
out OCR1AL,r23
- 49 -
out OCR1BH,r20
out OCR1BL,r21
ret
ROTI:
;Hay que parar antes de invertir motores
rcall PARA
;Rotamos hacia la izquierda
ldi r17,RLEFT
out PORTB,r17
out OCR1AH,r20
out OCR1AL,r21
out OCR1BH,r20
out OCR1BL,r21
ret
ROTD:
;Hay que parar antes de invertir motores
rcall PARA
;Rotamos hacia la derecha
ldi r17,RRIGHT
out PORTB,r17
out OCR1AH,r20
out OCR1AL,r21
out OCR1BH,r20
out OCR1BL,r21
ret
PARA:
ldi r17,STOP
;Paramos los motores
out PORTB,r17
out OCR1AH,r20
out OCR1AL,r21
out OCR1BH,r20
out OCR1BL,r21
ret
Sin embargo, hay algunas subrutinas especiales. Unas de
estas son las de cambio de velocidad global. Lo que hacen es
cambiar los valores almacenados en los registros de velocidad de
- 50 -
acuerdo con los deseos del usuario. Como es lógico estas

subrutinas van asociadas a las ordenes de acelerar y parar.
ACLR:
cpi r22,HIGH(VEL_MAX)
;Si la velocidad no es la normal la aumentamos
brne ACB
ret
ACB:
ldi r22,HIGH(VEL_MAX)
ldi r23,LOW(VEL_MAX)
ret
FRNR:
cpi r22,HIGH(VEL_MAX2)
;Si la velocidad no es la reducida la reducimos
brne FCB
ret
FCB:
ldi r20,HIGH(VEL_MED2)
ldi r21,LOW(VEL_MED2)
ldi r22,HIGH(VEL_MAX2)
ldi r23,LOW(VEL_MAX2)
ret
Otra subrutina especial es la de buscar y parar. Esta subrutina
hace que el robot gire sobre sí mismo hasta encontrar la línea. Una
vez encontrada se queda parado. Para determinar el sentido de giro
hace uso del bit T.
BUSCL:
;Comprobamos los CNY 1 y 2 si no están ambos a cero
hay que seguir buscando
in r18,PORTC
andi r18,0x03
brne NOLN
;Si tenemos la línea paramos y lo indicamos en PA0
rcall PARA
sbi PORTA,0
ret
- 51 -
NOLN:
brtc CGIR
hacia la izquierda
ldi r17,LEFT
rjmp SGIR
CGIR:
ldi r17,RIGHT
SGIR:
out PORTB,r17
out OCR1AH,r20
out OCR1AL,r21
out OCR1BH,r20
out OCR1BL,r21
ret
La subrutina de error se asocia a instrucciones reservadas y lo
que hace es encender el LED de depuración para notificar el error.
ERR:
;Encendemos el LED de depuración
sbi PORTB,4
ret
La última subrutina que queda por explicar es la de
actualización del bit T. Esta rutina comprueba las lecturas de los
CNY70 y asigna un valor al bit T del registro de estado dependiendo
de en qué flanco se encuentre la línea.
FLG:
;Leemos el puerto C
in r18,PORTC
;Operaremos sobre el registro 24
mov r24,r18
andi r24,0x03
brne FLG1
;Si estamos sobre la línea el flag no cambia
ret
FLG1:
andi r24,0x01
brne FLG2
- 52 -
;Si el bit0 es cero el bit1 es uno y T se pone a cero

(desviados por la izquierda)
clt
ret
FLG2:
mov r24,r18
andi r24,0x02
brne FLG3
;Si el bit1 es cero y el bit1 era 1 T se pone a uno
(desviados por la derecha)
set
ret
FLG3:
mov r24,r18
andi r24,0x04
brne FLG4
;Si el CNY3 (bit2) está sobre la línea estamos
desviados por la izquierda (T=0)
clt
ret
FLG4:
mov r24,r18
andi r24,0x08
;Si el CNY4 (bit3) está sobre la línea estamos
desviados por la derecha (T=1)
brne SAL
set
SAL:
;Si hemos perdido la línea no cambiamos T
ret
- 53 -
4. TARJETA DE CONTROL PRINCIPAL

La tarjeta principal se tiene que ocupar de coordinar la cámara, la tarjeta
de radiofrecuencia y la tarjeta de control de motores. Su función principal es
convertir, formatear y agrupar la señal leída por la cámara para su envío por el
enlace de radiofrecuencia. Se tiene que ocupar tanto de la señalización del
canal como de la adquisición de datos.
Eventualmente, recibirá alguna orden que tendrá que decodificar. Estas

órdenes pueden ir dirigidas a la tarjeta de control de motores, a la cámara o al
sistema de orientación de la cámara. Esta tarjeta incorpora también la
circuitería necesaria para orientar la cámara mediante servomotores tipo
FUTTABA.
4.1. DESCRIPCIÓN DEL HARDWARE

El hardware que se ajusta a las funciones que ha de desempeñar la
tarjeta se puede ver en el siguiente esquema.
U1 L7805/TO220
J3 +5V J10 J4
1 3 1 2 8
VIN VOUT GOT_LINE 7 1
2 REGULADOR D1 MOTAC3 6 2
GND +5V
1
+ C1 C2 C3 + C4 PWR_ON MOTAC2 5 SRV1 3

J1 220uF 100nF 100uF 100nF J2 R7 MOTAC1 4
PWR_IN PWR_OUT 1K MOTAC0 3
MODE 2 SERVO1
2
R1 1
470
U2 AT90S8515 TARJ_CTRL J5
PIX0 39 21 GOT_LINE 1
PIX1 38 PA0/AD0 PC0/A8 22 MOTAC3 2
PA1/AD1 PC1/A9 +5V
PIX2 37 23 MOTAC2 Y1 SRV2 3
PIX3 36 PA2/AD2 PC2/A10 24 MOTAC1
PIX4 35 PA3/AD3 PC3/A11 25 MOTAC0 XTAL1 XTAL2
PIX5 34 PA4/AD4 PC4/A12 26 MODE SERVO2
PIX6 33 PA5/AD5 PC5/A13 27 INCAM C5 8MHz C6
PIX7 32 PA6/AD6 PC6/A14 28 ADCSTR 15pF 15pF +5V
PA7/AD7 PC7/A15
CAM1 1 10 RX U3 PIC16F84
CAM2 2 PB0/T0 PD0/RXD 11 TX R2
CAM3 3 PB1/T1 PD1/TXD 12 XRESET SRV1 17 6 CAM1 10K
CAM4 4 PB2/AIN0 PD2/INT0 13 SIN Y2 SRV2 18 RA0 RB0/INT 7 CAM2
PB3/AIN1 PD3/INT1 LOAD RA1 RB1 CAM3 J17 RESET
5 14 1 8
MOSI 6 PB4/SS PD4 15 XCLK OSC2 OSC1 2 RA2 RB2 9 CAM4
MISO 7 PB5/MOSI PD5/OC1A 16 START 3 RA3 RB3 10 EXP0 4 SW1
D14 SCK 8 PB6/MISO PD6/WR 17 READ C8 20MHz C9 RA4/TOCKI RB4 11 EXP1 3 C7
PB7/SCK PD7/RD RB5 RESET
DEP 15pF 15pF OSC1 16 12 EXP2 2 100nF
XTAL1 19 30 OSC2 15 OSC1/CLKIN RB6 13 EXP3 1
XTAL2 18 XTAL1 ALE 29 OSC2/CLKOUT RB7
XTAL2 OC1B RESET 4 R3
31 MCLR 1K
R4 RESET 9 ICP 14 EXPANS
RST +5V VDD 5
470
GND
40 GND
+5V VCC
20
+5V
R5 1.2K U4 J7
+5V VOUT 1 2 PIX0

VIN D0 3 PIX1 1
D1 +5V
2
R21 470 12 4 PIX2 XRESET 2

U5 +5V 11 REF+ D2 5 PIX3 SIN 3
D12 REF- D3 14 PIX4 LOAD 4
LM385-2.5/TO D4
PROG J16 +5V 7 15 PIX5 XCLK 5
MODE D5
1
8 16 PIX6 START 6
MOSI 1 2 13 RD D6 17 PIX7 READ 7
3 4 CS D7 VOUT 8
R22 10K RST 5 6 ADCSTR 6 9 INCAM 9
SCK 7 8 WR/RDY INT 18 10
GND
MISO 9 10 20 OFL 11
+5V VCC
D13 12
DIODO_RST
10
PROGRAMADOR1 ADC0820
RESET
CAMARA
J8
TX 1 2
3 4
RX 5 6
7 8
9 10 +5V
Title
AURIEL Tarjeta Principal para Robot LSED

A4 1 1.2
Date: Monday , May 19, 2003 Sheet 1 of 1
Figura 29 Esquema de la tarjeta de control principal.
Para un mayor detalle, véase la figura 1 del apéndice B.
- 54 -
Se puede ver que la tarjeta se puede descomponer en varios

sectores. Estos sectores son alimentación, control de orientación de la
cámara, interfaz de la cámara y procesado.
4.1.1. ALIMENTACIÓN
La tarjeta principal se puede alimentar de dos formas distintas.
Las distintas formas se seleccionan abriendo o cerrando un jumper.
Una forma que tiene de alimentación de la tarjeta principal es

suministrando directamente una tensión estabilizada de 5V a la
entrada pertinente. De esta forma se puede hacer que ambas
tarjetas compartan fuente de alimentación. La tarjeta de control de
motores tiene una salida después del regulador que se puede utilizar
para alimentar la tarjeta principal de esta forma. Para seleccionar
este modo de alimentación hay que dejar abierto el jumper
REGULADOR.
Sin embargo, la tarjeta también cuenta con un sistema de

alimentación autónomo que se utilizará cuando el jumper
REGULADOR esté cerrado. El sistema de alimentación mencionado
es idéntico al de la tarjeta de control de motores (ver apartado 2.1.1).
Conviene señalar que no es conveniente utilizar la

alimentación de la tarjeta de control de motores si el jumper
REGULADOR está cerrado. Esto se debe a que no conviene
cortocircuitar directamente las salidas de los dos reguladores para
no dañarlos.
4.1.2. CONTROL DE ORIENTACIÓN DE LA CÁMARA

Como se ha explicado antes, la tarjeta principal puede
controlar dos servomotores para orientar la cámara.
- 55 -
J4
1
2 +5V U3 PIC16F84
3
SRV1 17 6 CAM1
SRV2 18 RA0 RB0/INT 7 CAM2
RA1 RB1 CAM3 J17
SERVO1 1 8
J5 2 RA2 RB2 9 CAM4
3 RA3 RB3 10 EXP0 4
1 RA4/TOCKI RB4 11 EXP1 3
2 OSC1 16 RB5 12 EXP2 2
+5V OSC1/CLKIN RB6
3 OSC2 15 13 EXP3 1
OSC2/CLKOUT RB7
RESET 4
SERVO2 MCLR
14 EXPANS
+5V VDD 5
GND
Figura 30 Sistema de orientación de la cámara.
En la figura se puede ver que el elemento central de este

sistema es un microcontrolador PIC. Este microcontrolador se usa
exclusivamente para generar las dos señales PWM necesarias para
orientar los servomotores. Los servomotores se conectan
directamente a la alimentación porque incorporan una lógica que
reduce el ruido impulsivo, por eso no se filtra su alimentación.
El microcontrolador PIC lee la orientación que le da el

microcontrolador principal por las líneas CAM1:4 y varia los ciclos de
trabajo de los servomotores en consecuencia. También consta de un
puerto de cuatro bit s de expansión por si se quisiera aprovechar la
capacidad de procesamiento sobrante para alguna otra tarea.
4.1.3. INTERFAZ DE LA CÁMARA

El chip de la cámara es un MITSUBISHI M64282FP. Este CDC,
pese a estar descatalogado actualmente, se puede encontrar
fácilmente en el periférico GameBoy Camera para la video consola
portátil GameBoy de Nintendo, que se puede adquirir de segunda
mano a través de servicios de subasta on-line como e-Bay por
menos de 10$ USD.
La cámara se conecta directamente al microcontrolador a

excepción de la señal de píxel. Esta señal es analógica por lo que es
necesario intercalar un conversor analógico digital para que el
microcontrolador pueda procesar el píxel.
- 56 -
Figura 31 Cámara digital M64282FP
J7
+5V 1
XRESET 2
SIN 3
LOAD 4
XCLK 5
START 6
READ 7
VOUT 8
9
10
11
12
CAMARA +5V
U4 1.2K R5
PIX0 2 1
PIX1 3 D0 VIN
D1
2
PIX2 4 12
PIX3 5 D2 REF+ 11 +5V U5
PIX4 14 D3 REF-
D4 LM385-2.5/TO
PIX5 15 7
D5 MODE
1
PIX6 16 8
PIX7 17 D6 RD 13
D7 CS
INCAM 9 6 ADCSTR
18 INT WR/RDY
OFL 20
VCC +5V
10
GND
ADC0820
Figura 32 Interfaz de la tarjeta principal con la cámara.
Los bits que se conectan desde la cámara directamente al

microcontrolador son los bits de configuración y control de ejecución.
- 57 -
La línea de datos de la cámara tiene que sufrir una conversión

analógico-digital.
Figura 33 Asignación de terminales de la cámara digital al bus de datos
La configuración del conversor ha sido extraída de las hojas

del fabricante, Se ha configurado para ser controlado con solo dos
líneas, la INCAM y la ADCSTR. El conversor es de ocho bits y el
rango de conversión se ajusta de 0V a 2,5V. Este rango es
adecuado porque la cámara entrega una señal de 1V pico a pico con
un offset configurable.
4.1.4. PROCESADO
La configuración de este sector es análoga a la del mismo
sector en la otra tarjeta. La disposición de señales en el
microcontrolador es la siguiente.
U2 AT90S8515
PIX0 39 21 GOT_LINE
PIX5 34 PA4/AD4 PC4/A12 26 MODE
PIX6 33 PA5/AD5 PC5/A13 27 INCAM
PIX7 32 PA6/AD6 PC6/A14 28 ADCSTR
PA7/AD7 PC7/A15
CAM1 1 10 RX
CAM2 2 PB0/T0 PD0/RXD 11 TX
CAM3 3 PB1/T1 PD1/TXD 12 XRESET
CAM4 4 PB2/AIN0 PD2/INT0 13 SIN
5 PB3/AIN1 PD3/INT1 14 LOAD
MOSI 6 PB4/SS PD4 15 XCLK
MISO 7 PB5/MOSI PD5/OC1A 16 START
D14 SCK 8 PB6/MISO PD6/WR 17 READ
PB7/SCK PD7/RD
DEP
XTAL1 19 30
XTAL2 18 XTAL1 ALE 29
XTAL2 OC1B
31
R4 RESET 9 ICP
470 RST
+5V 40
VCC20
GND
Figura 34 Conexiones del microcontrolador.
El puerto A del microcontrolador se destina íntegramente a la

adquisición de los datos convertidos a digital de la cámara. Este
puerto no tenía ninguna otra funcionalidad por lo que no se sacrifica
ningún recurso en la lectura de los datos de la cámara.
El puerto B se divide en dos partes. Los cuatro bits menos

significativos son los que se usan para comunicarle al
- 58 -
microcontrolador PIC la orientación deseada de la cámara. El bit 5,

como pasaba en la otra tarjeta, se destina a un LED de depuración
que ayude a la detección de errores en el software de la tarjeta.
Puede parecer absurdo malgastar una pata para este fin pero
nosotros lo hemos encontrado de vital importancia. La ayuda del
LED de depuración hace que la detección de errores se pueda
realizar de forma empírica, más cómoda, y nos evita tener que
desentrañar el código ejecutado por el microcontrolador.
Por último, los otros tres bits se destinan al programador AVR.

Las conexiones son idénticas a la de la otra tarjeta, así como el
circuito de reset. Por lo que para su consulta remitimos al lector al
apartado de procesado de la tarjeta de control de motores.
Nótese que el microcontrolador PIC carece de programador

integrado en la tarjeta principal. Por consiguiente, se hace
indispensable el uso de un programador PIC independiente.
El puerto C se destina a la comunicación entre tarjetas y al

control del conversor analógico digital. Los seis bits menos
significativos constituyen el otro extremo del bus que se conecta al
puerto A del microcontrolador de la tarjeta de control de motores.
Los dos bits más significativos son los que se utilizan para controlar
la conversión a digital de los datos de la cámara.
Finalmente el puerto D se usa para configurar y controlar la

cámara y para la comunicación con la tarjeta de radio. Los dos bits
menos significativos son los de transmisión y recepción de la UART.
Estos bits se conectan directamente a la tarjeta de radio y no hace
falta ninguna pista adicional. El control de la comunicación serie por
el enlace radio se hace íntegramente vía software ayudándose de
los registros internos de la UART.
Los otros seis bits se utilizan para encender la cámara

(START), temporizarla (XCLK) y configurarla. Al iniciar la cámara es
necesario cargar unos registros internos que tiene para que funcione
de la forma deseada. Esto se consigue mediante una transmisión
- 59 -
serie por SIN, temporizada por XCLK y validada por LOAD. La pista
READ es la notificación de la cámara de que tiene un píxel nuevo
preparado para la conversión.
4.2. DESCRIPCIÓN DEL SOFTWARE

La tarjeta de control principal ha de gobernar todo el robot,
recibiendo las órdenes del host remoto, decodificándolas y ejecutándolas.
Además, debe recopilar la información del estado del robot y los datos de
la cámara y enviarlos a través del enlace de radio frecuencia,
implementando las rutinas necesarias para la separación de tramas y la
temporización que exige la tarjeta de radio frecuencia.
Una vez ejecutada la rutina primera de reset y habilitadas las

interrupciones, el programa principal entra en un bucle continuo de
espera activa aguardando a que se produzcan las interrupciones
programadas:
• Interrupción del Timer0, que da lugar a la recopilación de datos y

su envío a través de la radio frecuencia.
• Interrupción por llegada de nuevos datos desde el enlace radio

frecuencia, que lanza el proceso de descodificación del tipo de dato
recibido y el procesado del comando en caso de que se trate de datos
del servicio de comandos.
4.2.1. EQUIVALENCIAS Y VECTORES DE INTERRUPCIÓN

Al igual que con el otro programa se define un primer archivo
en el que se especifican unas equivalencias para facilitar la
programación.
;Registros de entrada y salida

.EQU SREG = 0x3f
.EQU SPH = 0x3e
.EQU SPL = 0x3d
.EQU GIMSK = 0x3b
.EQU GIFR = 0x3a
.EQU TIMSK = 0x39
.EQU TIFR = 0x38
.EQU MCUCR = 0x35
- 60 -
.EQU TCCR0 = 0x33

.EQU TCNT0 = 0x32
.EQU TCCR1A = 0x2f
.EQU TCCR1B = 0x2e
.EQU TCNT1H = 0x2d
.EQU TCNT1L = 0x2c
.EQU OCR1AH = 0x2b
.EQU OCR1AL = 0x2a
.EQU OCR1BH = 0x29
.EQU OCR1BL = 0x28
.EQU ICR1H = 0x25
.EQU ICR1L = 0x24
.EQU WDTCR = 0x21
.EQU PORTA = 0x1b
.EQU DDRA = 0x1a
.EQU PINA = 0x19
.EQU PORTB = 0x18
.EQU DDRB = 0x17
.EQU PINB = 0x16
.EQU PORTC = 0x15
.EQU DDRC = 0x14
.EQU PINC = 0x13
.EQU PORTD = 0x12
.EQU DDRD = 0x11
.EQU PIND = 0x10
.EQU UDR = 0x0C

.EQU USR = 0x0B
.EQU UCR = 0x0A
.EQU UBRR = 0x09
Se han añadido las equivalencias necesarias para manejar la
UART y se ha prescindido del resto de equivalencias pues no tenía
sentido mantenerlas. Sin embargo, más adelante se definirán
nombres simbólicos de registros.
La tabla de vectores de interrupción también sufre

modificaciones porque las fuentes de interrupción son distintas. En
este programa interrumpen los timers y la UART.
CSEG
- 61 -
.ORG 0x000
;Salto a rutina de reset
rjmp RESET
;Si saltan estas interrupciónes se debe a un error
rjmp RESET
rjmp RESET
rjmp RESET
rjmp RESET
rjmp RESET
;TIMER asociado a la RF
rjmp IRQ_TIMER1
;TIMER asociado a rutina de captura de datos
rjmp IRQ_TIMER0
;Si salta esta interrupción se debe a un error
rjmp RESET
;Tenemos datos del control remoto!
rjmp IRQ_RX
;Se puede enviar el siguiente dato
rjmp IRQ_UOBE
;Si saltan estas interrupciónes se debe a un error
rjmp RESET
rjmp RESET
4.2.2. RUTINA DE RESET

Esta rutina se encarga, entre otras cosas, de configurar al
microcontrolador como queremos. Hay que configurar las interrupciones
de los timer y ajustar sus tiempos. También tiene que fijar los parámetros
de la UART y de los puertos de entrada y salida además de las tareas
típicas de configuración.
;Rutina de reset
RESET:
ldi r16,0x02
out SPH,r16
ldi r16,0x5f
;SP al final de la RAM
out SPL,r16
clr r16
;Interrup. deshabilitadas
out SREG,r16
- 62 -
;Interrup. externas deshabilitadas

out GIMSK,r16
;Sin RAM externa
out MCUCR,r16
ldi r16,0x82
;Interrup. por overflow
out TIMSK,r16
ldi r16,0xb8
;Configuración de la UART
out UCR,r16
ldi r16,0x03
;Baud rate = 115200
out UBRR,r16
ldi r16,0xb7
;Interrup cada 10us
out TCNT0,r16
clr r16
;Reloj parado
out TCCR0,r16
out TCCR1A,r16
out TCCR1B,r16
ldi r16,0x00
out TCNT1L,r16
ldi r16,0xb8
;Máximo retardo de 20us
out TCNT1H,r16
clr r16
;Configuración del puerto A
out DDRA,r16
ldi r16,0x5f
;Configuración del puerto B
out DDRB,r16
ldi r16,0xbe
;Configuración del puerto C
out DDRC,r16
ldi r16,0x7e
;Configuración del puerto D
out DDRD,r16
Después de haber realizado las tareas de configuración del
sistema se procede a inicializar la cámara y otras variables.
- 63 -
;Reset de la cámara
rcall RCAM
;Tamaño del buffer
ldi r16,96
ldi r30,0x02
ldi r31,0x01
;Guardamos en la dirección 0x0102
st z,r16
;Capacidad del acumulador inicialmente al maximo
ldi r16,8
mov enACUav, r16
mov deACUav, r16
;Empieza el programa
rjmp PROG
4.2.3. RUTINAS DE CONFIGURACIÓN DE CÁMARA

En este apartado se incluye la subrutina que carga los
registros de la cámara y la rutina de reset de cámara. La rutina de
reset de cámara lo que hace es que guarda en las posiciones de
memoria asociadas a la cámara unos valores por defecto y llama a
la subrutina de carga.
RCAM:
;primero reseteamos la camara
;poner a cero reloj
cbi PORTD, XCLK
cbi PORTD, XRESET
sbi PORTD, XCLK
sbi PORTD, XRESET
;Cargamos valores por defecto
ldi mierda1, 0x3f
sts CAMDATA, mierda1
ldi mierda1, 0x04

sts CAMDATA+1, mierda1
ldi mierda1, 0x0a

ldi mierda1, 0xff
- 64 -
ldi mierda1, 0x01

ldi mierda1, 0x00

ldi mierda1, 0x01

ldi mierda1, 0x02

rcall CAM_LOAD_REGISTERS
ret
Estos valores por defecto ajustan el tiempo de exposición, la
ganancia, la luminancia a unos valores típicos. También se aseguran
de que el rango dinámico de la señal esta de acuerdo con lo que
espera el conversor analógico-digital. Es decir, 1V pico a pico más
1V de continua.
La rutina de carga lo que hace es ir cogiendo cada uno de los

valores asociados a los registros y cargarlos en la cámara. La
cámara recibe bit a bit por la pata SIN. El reloj tiene que ir
sincronizado con la transmisión. Primero se transmiten tres bits de
dirección de registro (hay 8 registros) a cargar y luego el byte de
dato. Una vez terminada la transmisión hay que validarla con la
señal LOAD.
La subrutina primero guarda el contexto y calcula la dirección

del dato a cargar. Hecho esto lee el dato de la memoria y lo deja en
un registro.
CAM_LOAD_REGISTERS:
push sucio
push ocho
push mierda1
- 65 -
push r30
push r31
;contador de 0 a 7 para los registros
clr sucio
bucleCarga:
mov r5,sucio
;Calculamos dirección y leemos dato
ldi mierda1, LOW(CAMDATA)
add ocho, mierda1
ldi mierda1, HIGH(CAMDATA)
adc r5,mierda1
mov r30, ocho
mov r31, r5
ld ocho, z
Se han definido nombres simbólicos para algunos registros y
pines para hacer el programa más legible. Hecho esto entra en un
bucle que manda bit a bit la dirección y el dato. Esto se hace
mediante rotaciones.
;mandar primero los tres bits del registro

;bucle contando con mierda1
ldi mierda1, 3
cargaDirReg:
;poner a cero el reloj de la camara
cbi PORTD, XCLK
sbrs sucio, 2
rjmp manda_cero
rcall CAM_SIN_1
decB1:
;poner a uno
sbi PORTD, XCLK
;mover a la izq sucio para mandar el siguiente bit
lsl sucio
dec mierda1
brne cargaDirReg
;xSSSxxxx
lsl sucio
;volvemos a colocar sucio en su posicion original
xxxxxSSS
- 66 -
swap sucio
rjmp masDat
manda_cero:
rcall CAM_SIN_0
rjmp decB1
masDat:
;ahora metemos los ocho bits de datos
ldi mierda1, 8
cargaDatReg:
;poner a cero el reloj
cbi PORTD, XCLK
sbrs ocho, 7
rjmp manda_cero_
rcall CAM_SIN_1
decB2:
;poner a uno
sbi PORTD, XCLK
;mover a la izq sucio para mandar el siguiente bit
lsl ocho
dec mierda1
brne cargaDatReg
;terminado el registro se manda el siguiente
inc sucio
cpi sucio, 8
breq finCargaS
;mandar la señal de carga
sbi PORTD, LOAD
;reloj de camara a cero
cbi PORTD, XCLK
cbi PORTD, LOAD;
rjmp bucleCarga
manda_cero_:
rcall CAM_SIN_0
rjmp decB2
Se recupera el contexto y se termina con la subrutina.
finCargaS:
pop r31
- 67 -
pop r30
pop mierda1
pop ocho
pop sucio
ret
Se han utilizado dos subrutinas que lo que hacen es activar o
desactivar la pata SIN del microcontrolador.
CAM_SIN_1:
;poner un 1 a Serial IN de la Camara
sbi PORTD, SIN
ret
CAM_SIN_0:
;poner a 0 la serial in de la camara
cbi PORTD, SIN
ret
4.2.4. EL PROGRAMA PRINCIPAL

Simplemente realiza la habilitación de contadores, cámara e
interrupciones, para acabar en el bucle de espera activa:
PROG:
;activar contador TIMER0
clr mierda1
out TCCR0,mierda1
;activar la camara
cbi PORTD, XCLK
sbi PORTD, START;-------------------
sbi PORTD, XCLK
cbi PORTD, START
;habilitar interrupciones
sei
mainloop:
nop
rjmp mainloop
- 68 -
4.2.5. ADQUISICIÓN DE DATOS

La adquisición de datos la lleva a cabo como se indicó
anteriormente la rutina de atención a la interrupción periódica del
contador 0, IRQ_TIMER0.
Para evitar problemas de desbordamiento del buffer de salida

de datos hacia el enlace de radio frecuencia, si el bit de Transmisión
Enabled de la UART del Atmel está a cero, la rutina simplemente
devolverá el estado a la espera activa. Si por el contrario sí que se
pueden transmitir datos, la rutina primeramente determina si debe
añadir las cabeceras de datos, tanto de Estado como de Imagen,
con los correspondientes seis bits menos significativos de la fila a la
que pertenecen los píxeles a enviar. Para ello se han habilitado los
bits 4 y 3 del byte del registro COMM que mantiene el estado de las
comunicaciones:
registro COMM FR VD WC NIF NSF TE

7 6 5 4 3 2 1 0
Byte 1
Figura 35 Detalle del registro de estado COMM
Así el bit 4 estará a uno siempre que se deban incluir las

cabeceras de trama de imagen (‘New Image Frame’) y el 3 indica si
se debe mandar el estado o no (‘New Status Frame’) Estos bits se
ponen automáticamente a uno en la rutina de atención a la
interrupción del TIMER 1, que se lanza cuando ha transcurrido el
tiempo de guarda necesario que impone la tarjeta de radio
frecuencia para modular los paquetes de 96 bytes que se le han
mandado.
Tras incluir, si procede, las cabeceras de trama, la rutina

verifica si el bit DATA (PD7) está a uno, en cuyo caso deberá, por un
lado mandar un uno a la señal de reloj XCLK (PD5) para que la
cámara cargue a la su salida de datos analógica el siguiente píxel y
por otro, activar la señal ADCSTR poniendo el bit PC7 a cero para
que el conversor A/D inicie la conversión del dato que viene de la
- 69 -
cámara. En la siguiente ejecución de la rutina periódica, la señal

INCAM (PC6) estará a cero, indicando que el conversor A/D ha
finalizado la conversión y en el puerto A se dispondrá del píxel en
formato digital. Tras poner a cero el reloj de la cámara XCLK, el byte
se envía por el canal de comunicaciones y se actualizan los registros
en los que se almacenan la fila y la columna por la que se va. En
caso de alcanzar la columna 127, se pasa a la línea siguiente y en
caso de alcanzar la línea 127, los contadores se ponen a cero y se
queda en estado de espera hasta, transcurrido el tiempo de
exposición, la señal READ vuelva a estar activa indicando que la
nueva imagen está lista para ser leía píxel a pixel. Para determinar si
se está en la primera fase de conversión A/D o en la segunda se usa
el bit T del registro de estado del Atmel, que a su vez controla el reloj
XCLK.
4.2.6. LAS RUTINAS DE ENLACE

Antes de mandar ningún dato por el canal de comunicaciones
es preciso incluir las cabeceras de tramas, los separadores y evitar
los datos 01111110 para que no se confundan con los separadores
de trama.
Las rutinas DEL_ENLACE, AL_ENLACE, METE_FR_SP,

PROCESA_BYTE y SEND_ACK cubren todas las tareas del nivel
de enlace.
Los decodificadores de datos que vienen desde el canal y los

codificadores de datos hacia el canal usan tres registros cada uno
para mantener el estado interno de los bits que todavía no se han
enviado o decodificado al haberse eliminado bits de cero de
redundancia impuestos por los separadores de trama 01111110. Así
se han asignado los siguientes registros, tanto inmediatos como no
inmediatos:
.DEF enACU = r18

.DEF enACUav = r15
.DEF enCount1 = r20
.DEF deACU = r21
- 70 -
.DEF deACUav = r14

.DEF deCount1 = r23
.DEF ocho = r24 ;registro de sucio

.DEF sucio = r25 ;registro de guarreo
.DEF toSend = r16
.DEF toRec = r17
.DEF mierda1 = r19
.DEF COMM = r26
.DEF enDATA = r27

.DEF deDATA = r22
También se han definido los siguientes EQU que contienen las
direcciones de la memoria de datos del Atmel que almacenan los IDs
de tramas esperados, recibidos y la ventana de recepción de
comandos de 64 bytes.
.EQU expFRID = $00

.EQU curFRID = $01
.EQU buffFR = $02 ;esto mas 63 es la ventana
Las rutinas codificadoras y decodificadoras del enlace se
basan en desplazamientos lógicos con arreo y comprobación bit a bit
de si es un cero o un uno. En caso de que sea un uno, los
contadores enCount1 o deCount1 se incrementan, y si se trata de un
cero, los contadores se resetean. Para el caso del codificador, al
recibir cinco unos seguidos, automáticamente introduce un cero para
evitar que otro uno más lo confunda por un separador de trama.
Para el decodificador, si se recibe un cero y el número de unos es
igual a 6, entonces se tiene un separador de trama, activando el bit
más significativo del registro de comunicaciones COMM. Si por el
contrario son 5 el número de unos recibido, entonces se trata de un
cero redundante, que es eliminado automáticamente. Finalmente, si
es inferior a cinco el número de unos, el cero es válido.
◄ C ◄
- 71 -
ACUMULADOR DATO COD/DEC
Figura 36 Esquema de funcionamiento de los codificadores de enlace
Así se tiene el codificador de enlace
AL_ENLACE:
ldi toSend, 0x08
loop1:
lsl enDATA ;BMS del enDATA al C
brcs send1 ;si C==1 enviamos 1
ldi enCount1, $06 ;como es 0, se resetea el contador
alAcu:
rol enACU ;al acu por la derecha el C que es
el dato que queremos
rjmp chkAcu;
send1:
dec enCount1
brne alAcu ;no se han mandado mas de 5 unos
ror enDATA ;volvemos a meter a enDATA el BMS
lsl enACU ;metemos al acumulador un 0 por la
derecha
inc toSend;
chkAcu:
dec enACUav ;
brne sig1 ;
;ENVIO A LA UART DEL BYTE SI PROCEDE (AL_CANAL)
del enACU
rcall AL_CANAL
sig1:
clr enACU;
ldi ocho, 0x08
mov enACUav, ocho;
dec toSend
brne loop1;
ret
Y el decodificador de enlace
- 72 -
;Decodifica un byte recibido de la RF, quitando

adecuadamente la sobrecarga
;introducida por el uso de los separadores de trama
DEL_ENLACE:
ldi toRec, 8
in deDATA,UDR
loop2:
lsl deDATA
brcc rx0
inc deCount1
alACU2:
rol deACU ;se meten los datos por la derecha
del C
dec deACUav
brne deACUChk
sbr COMM, 6 ;x1xxxxxx, dato valido
;SALTO POR HACER AL PROCESADOR DE BYTES
rcall PROCESA_BYTE
clr deACU
ldi ocho, 0x08
mov deACUav, ocho;
rjmp deACUChk
rx0:
cpi deCount1, $05
breq rx02 ;esto si tenemos un cero que sobra
brmi rx01 ;cero legal, se mete al acu
;eso es una bonita trama
;y se indica en el BMS del byte COMM
cbr COMM, 6 ;x0xxxxxx, dato no valido
sbr COMM, 7 ;1xxxxxxx, frame separator
clr deACU ;
mov deACUav, ocho;
rjmp deACUChk
rx01:
clr deCount1
clc ;poner a cero el C para que
el rol meta un cero
rjmp alACU2
- 73 -
rx02:
clr deCount1
deACUChk:
dec toRec
brne loop2
Que también hace uso de la subrutina de envío de
confirmaciones de comando y de la subrutina de procesado de bytes:
;procesa el byte recibido

;usa como entrada el deACU
.DEF backup = r2
PROCESA_BYTE:
mov backup, deACU
sbrs COMM, 6 ;x1xxxxxx ¿byte valido?
rjmp finpro
sbrs COMM, 7 ;1xxxxxxx ¿nueva trama?
rjmp sigue5
;aqui tenemos un inicio de trama
;el dato del acu es el frame ID si es comando
andi deACU, $C0
brne finpro
sbr COMM, 5 ;xx1xxxxx, en espera de comando
cbr COMM, 7 ;0xxxxxxx, ya no es inicio de trama
sts curFRID, backup
rjmp finpro
sigue5:
;comprobar si estamos en espera de comando
sbrs COMM, 5
rjmp finpro
cbr COMM, 5 ;ya lo atendemos y pasamos a modo de
espera general
;comprobar si es el RESERVADO antes de nada, que
tiene prioridad
cpi deACU, 0xff
breq COM_VALID
lds ocho, curFRID

lds sucio, expFRID
- 74 -
cp ocho, sucio
brne yaenviado
COM_VALID:
;comando valido
push ocho
rcall SEND_ACK
;almacenamos el comando valido en la ventana de
recepcion
;para mandar ACKs de paquetes ya recibidos
ldi mierda1, buffFR
add ocho, mierda1;ocho contiene la pos de memoria
RAM donde guardar
push r30
push r31
mov r30, ocho
st z, backup
pop r31
pop r30
inc sucio
andi sucio, $3F
sts expFRID, sucio
;SALTO A PROCESAR COMANDO

rcall PROC_COM
rjmp finpro
yaenviado:
mov sucio, ocho
ldi mierda1, buffFR
add sucio, mierda1; tenemos la pos de memoria
ande mirar
push r30
push r31
ld sucio, z
pop r31
pop r30
cp sucio, deACU
brne finpro
;MANDAR ACK DEL FR ID que esta en ocho
- 75 -
push ocho;el FR ID esta en la pila

rcall SEND_ACK
finpro:
mov deACU, backup
ret
SEND_ACK:
;primerito de todo, meter el FR SP
rcall METE_FR_SP
;ahorita meter el ACK
push enDATA
push sucio
push r30;
push r31;
in r30, SPL
in r31, SPH
adiw r30, 4
ld sucio, z
;sucio tiene ahora el FR ID a mandar
ori sucio, 0x40 ;enmascarar con 01xxxxxx, que
indica ACK de comando
mov enDATA, sucio
rcall AL_ENLACE
pop r31;
pop r30;
pop sucio;
pop enDATA
ret
La rutina encargada de procesar bytes se fija, primeramente si
está activado el bit de trama nueva (FR, 7) de COMM, y en caso
contrario, si está activado el bit de dato válido (VD, 6) del registro
COMM. En este último caso recoge el byte decodificado y determina
si se trata de un inicio de trama de comando, en cuyo caso
almacena el ID de la trama en la posición de memoria de currFRID y
activa el bit 5 del COMM, indicando que esta a la espera de nuevo
comando (WC).
- 76 -
Si PROCESA_BYTE determina que está a la espera de un

byte y el byte disponible en deACU es válido (bit 6 de COMM),
entonces, cargará el valor almacenado en currFRID y en expFRID y
los comparará, si son iguales, el comando es válido. En este caso,
se almacena en la posición de memoria (buffFR + <frame actual>) el
valor del comando recibido, se envía un ACK para el comando y se
llama a la subrutina PROC_COM que se encarga de procesar el
comando.
En caso de que el comando recibido no tenga el identificador

de trama esperado y el valor del comando sea igual al dato
almacenado en la posición de memoria de datos buffRF + <frame
recibido>, se trata de un comando reenviado por error, y se manda
un ACK del comando. En caso de que no coincida con el valor
registrado, no se hace nada y se sigue esperando a recibir una
trama con el Identificador de Trama de Comando válido o bien un
comando reservado para resincronizar con el host remoto.
Finalmente, este módulo de rutinas de enlace dispone de la

rutina METE_FR_SP encargada de introducir sin sobrecarga alguna
de ceros un separador de trama 01111110 al canal:
;envia un separador de trama

METE_FR_SP:
ldi enDATA, 126; la trama
mov toSend, ocho ;
loop123:
lsl enDATA ;BMS del enDATA al C
ror enACU ;al acu por la derecha el C que es el
dato que queremos
dec enACUav ;
brne sig123 ;
;ENVIO AL CANAL (AL_CANAL)
rcall AL_CANAL
sig123:
clr enACU;
mov enACUav, ocho;
dec toSend
- 77 -
brne loop123;
ret
4.2.7. EL NIVEL FÍSICO

Las rutinas del nivel físico comprenden a AL_CANAL,
ENVIA_SERIE y actTIMER. Dado que las tarjetas de radio
frecuencia exigen un tamaño máximo de ráfagas de 96 bytes y un
tiempo de guarda entre ráfagas fijado por la expresión
estas rutinas deberán respetar estas limitaciones. Para ello lo

que se hace es almacenar los datos a enviar en un búfer auxliar de
192 bytes de capacidad y se activa el TIMER1 que, al lanzarse su
interrupción TIMER1 lo que hace es transmitir de golpe hasta un
máximo de 96 bytes almacenados en el búfer y esperar el tiempo de
guarda máximo antes de volverse a ejecutar hasta vaciar el búfer de
salida.
Las posiciones de memoria de datos empleadas son:
;nivel fisico
.EQU iniBuffer = 0x42

.EQU capBuffer = 0xC0
.DEF puntEnvio = r28 ;registro inmediato
.DEF puntMete = r29 ;registro inmediato
.EQU serieAVA = 0x102 ;pos de memoria donde

esta la capacidad de las RF
Asimismo se definen los punteros de Envío y Mete que
apuntan respectivamente a las posiciones de memoria de datos con
el byte a enviar la siguiente vez que se ejecute la rutina de
interrupción IRQ_UBOE y el hueco en el búfer para el siguiente byte
a enviar.
AL_CANAL:
cpi puntMete, capBuffer
breq fincanal
mov ocho, puntMete
clr sucio
- 78 -
ldi mierda1, LOW(iniBuffer)

add ocho, mierda1
ldi mierda1, HIGH(iniBuffer)
adc sucio,mierda1
push r30
push r31
mov r30, ocho
mov r31, sucio
st z, enACU
pop r31
pop r30
inc puntMete
;ACTIVAR LA TAREA DE ENVIO

in sucio, TCCR1B
cpi sucio, 0x00
brne fincanal
;la tarea no esta activada, la activamos
ldi sucio, 0x01;modo NO PREESCALADO!!!
out TCCR1B, sucio
fincanal:
ret
ENVIA_SERIE:
;metemos el byte SOLO si ya esta vacio el UDRE
sbic USR, 5
rjmp etiqueta
rcall actTIMER
rjmp finEnvia
;decrementar la capacidad del buffer

etiqueta:
push r30
push r31
ldi r30, LOW(serieAVA)
ldi r31, HIGH(serieAVA)
ld sucio, z
- 79 -
;ahora sucio tiene la capacidad del buffer

dec sucio
brne otro
rcall actTIMER
otro:
st z, sucio
mov ocho, puntEnvio

clr sucio
ldi mierda1, LOW(iniBuffer)
add ocho, mierda1
ldi mierda1, HIGH(iniBuffer)
adc sucio,mierda1
mov r30, ocho
mov r31, sucio
ld sucio, z
pop r31
pop r30
out UDR, sucio
inc puntEnvio
cpi puntEnvio, capBuffer
brne finEnvia
clr puntEnvio
clr puntMete
finEnvia:
ret
actTIMER:
;activar tempo 1
ldi ocho,0x00
out TCNT1L,ocho
ldi ocho,0xb8
out TCNT1H,ocho ;Máximo retardo de 20us
ldi ocho,0x02
out TCCR1B,ocho
cbi UCR,3 ;deshabilitamos la TX de la UART
ret
- 80 -
La rutina actTIMER es la encargada de activar el contador 1,

cargándole además el retardo máximo de tiempo de guarda como
valor iniciar.
Para enviar datos al canal se usa la rutina AL_CANAL, que

guarda en el búfer auxiliar el byte contenido en el registro enACU
Como el canal es half-duplex, no se envían datos cuando se

están recibiendo datos. De este modo, la rutina de atención a la
interrupción de recepción de datos desde la UART deshabilita la
transmisión poniendo el bit 3 del registro I/O UCR a cero al entrar en
la rutina y restaurando su valor a uno tras la ejecución de la misma,
justo antes del reti. También mientras está el TIMER1 activado no se
permite la transmisión.
- 81 -
5. HOST DE CONTROL REMOTO

Este host se encarga de controlar a la unidad móvil, recibiendo por una
parte los datos que recopile ésta, y por otra parte, mandándole las órdenes
pertinentes para su funcionamiento en modo manual.
5.1. PLACA DE CONTROL

La comunicación se realiza a través de las tarjetas de
radiofrecuencia de Auriel WIZ-434-SML-IA que se conectan al equipo vía
puerto Serie. Estas tarjetas trabajan con señales TTL, mientras que los
puertos Serie, típicamente, ‘COM’, de los ordenadores trabajan con
señales en RS232. Para llevar a cabo la adaptación de niveles se hace
uso de la siguiente placa que dispone de un conversor MAX232 de Maxim.
Figura 37 Placa de control del host
Este circuito integrado dispone de dos entradas TTL con sus

correspondientes salidas en RS232 y dos entradas RS232 y sus salidas
convertidas en TTL. En la placa adaptadora se ha hecho uso de
únicamente un par de entradas, quedando el otro libre.
- 82 -
Figura 38 Detalle del adaptador MAX232
La placa puede ser alimentada directamente con una pila de 9

voltios o bien usando una fuente de alimentación y los conectores hembra
de tipo banana. El circuito dispone de un regulador de tensión de 5 voltios
L7805 para poder usar distintas alimentaciones.
La conexión con el PC se realiza mediante el conector DB9 hembra

incorporado, y la tarjeta de radio frecuencia se conecta mediante un bus
de 10 hilos al conector.
PIN 1
Figura 39 Detalle de la conexión con la tarjeta de radio frecuencia
Cuando el circuito está correctamente alimentado, el LED rojo de la

placa y el LED POW de la placa de radiofrecuencia se encenderán. Al
- 83 -
abrirse el puerto por la aplicación de control, el LED Verde la placa se

iluminará. Este LED corresponde a la señal DTR del puerto serie COM, y
se alimenta de la propia señal que recibe desde el equipo PC, por lo que
puede estar perfectamente encendido sin tener el circuito alimentado, en
cuyo caso el enlace RF no funcionará. Cuando se transmiten o reciben
datos por la radiofrecuencia, el led RTX se encenderá.
DTR
POWER
POWER
RTX
Figura 40 LEDs de la placa de control
De los nueve pines de la conexión DB9 serie sólo se emplean los

cinco primeros:
• Pin 1 DCD, Data Carrier Detect, activo a nivel bajo, se pone a

cero cuando se detecta portadora. Está conectado al pin 6 de la tarjeta
de radio frecuencia (XTR Carrier Detect.)
• Pin 2 TXD, Transmitted Data, los datos a transmitir por radio

enlace.
• Pin 3 RXD, Received Data, los datos recibidos desde el radio

enlace.
- 84 -
• Pin 4 DTR, Data Terminal Ready, se activa cuando el equipo

terminal, es decir, el PC está listo, que se produce cuando se abre el
puerto de comunicaciones.
• Pin 5 GND, Signal Ground, la tierra del PC y que se usa en toda

la placa como tierra. Está conectada internamente a los pines 3 y 4 de
la tarjeta de radiofrecuencia.
Los pines usados de la tarjeta de radio frecuencia están marcados

en rojo en la siguiente ilustración:
Figura 41 Pines de contacto de la tarjeta de radiofrecuencia WIZ-434-SML-IA
5.2. EL SOFTWARE
El software del equipo de control está escrito en el lenguaje Java de
Sun Microsystems, concretamente, para su versión de JSDK 1.4.1_02. La
elección de este lenguaje se ha debido a su práctica independencia de la
plataforma en que se ejecute la máquina virtual de Java. Asimismo, para
poder compilar el proyecto entero, se ha usado la herramienta ANT del
grupo Jakarta de la Apache Foundation. Para más información acerca de
la instalación de ANT, vea el apéndice A ‘Instalación del Software.’
El acceso a los puertos de comunicaciones serie se realiza a través

del paquete javax.comm que Sun Microsystems distribuye de forma
separada al JSDK. Nuevamente, para su descarga e instalación, vea el
apéndice A.
El software de control se compone básicamente de tres módulos o

paquetes de Java:
- 85 -
• Paquete com.theexbteam.comm, que proporciona las clases

necesarias para establecer una conexión serie a través de las tarjetas
de radio frecuencia.
• Paquete com.theexbteam.robots, que incluye las clases de

gestión y control del robot.
• Paquete com.theexbteam.robots.ui, que reúne las clases de la

interface de usuario, tanto en línea de comandos como las gráficas.
El último paquete precisa del segundo, y el segundo paquete hace

uso de las clases del primero. No obstante, el paquete de
comunicaciones se puede utilizar para desarrollar cualquier otra
aplicación que precise de acceso a los puertos de comunicaciones serie o
paralelo. Para un mayor detalle de la API de cada paquete, vea la
documentación generada por la herramienta javadoc que incluye precisas
descripciones de los métodos más importantes de cada clase.
5.3. PAQUETE COM.THEEXBTEAM.COMM

Como ya se indicó, este paquete de clases permite transmitir datos a
través de un puerto de comunicaciones del equipo PC. Sus clases hacen
uso de las clases de javax.comm para abrir primeramente los puertos,
activar los eventos pertinentes de aviso de llegada de datos y resolver los
posibles conflictos que puedan surgir entre dos aplicaciones que intenten
acceder al mismo puerto.
La clase AurielWiz434SerialConnection, que deriva de la

SerialConnection, es la encargada de gestionar el uso del canal half-
duplex que proporcionan las tarjetas de radio frecuencia Auriel WIZ-434-
SML-IA. Permite a las aplicaciones que la usen mandar y recibir de forma
transparente datos, sin tener que preocuparse éstas por el acceso al
canal, la fragmentación de paquetes de 96 bytes que imponen las tarjetas,
o de guardar los tiempos especificados en las hojas del fabricante.
Internamente esta clase lo que hace es almacenar en un buffer
secundario los datos a enviar y proceder a su transmisión a la tarjeta de
radio frecuencia transcurrido los tiempos de guarda, fragmentando
- 86 -
además el buffer en segmentos de 96 bytes. Finalmente, y mientras está

recibiendo datos, la salida de datos hacia la radio frecuencia se inhabilita
para evitar colisiones al estar los dos extremos usando el canal de forma
simultánea.
La clase AurielWiz434SerialConnection, por defecto, y a diferencia

de su padre, SerialConnection, no atiende los eventos ‘Output Buffer
Empty’, Buffer de Salida Vacío. En caso de que se desee recibir
notificaciones de este tipo, se debe usar la función
setPortEventOutputEmptyEnabled(true).
Figura 42 Diagrama UML del paquete com.theexbteam.comm
Este paquete incluye además un subpaquete llamado

com.theexbteam.comm.util, que implementa las funciones necesarias
para la creación de los delimitadores de trama 01111110 usados en el
nivel de enlace del protocolo de comunicaciones. Así, intercalará
automáticamente a toda secuencia de datos de cinco unos seguidos un
- 87 -
cero, independientemente de que el siguiente bit sea uno o cero, para así
evitar que los datos se confundan con los separadores de tramas. Cabe
destacar que el método getFrameDecoded(byte) de la clase
FrameEncoder puede devolver tres tipos de datos:
• Un byte con el valor decodificado resultado de concatenar el

acumulador interno de la clase que contiene bytes incompletos con el
último byte introducido, eliminando pertinentemente la sobrecarga de
ceros introducida tras cinco unos consecutivos. En este caso, el
método isDecodedValid() deberá devolver true.
• Un objeto FrameSeparator, arrojado por el método, en cuyo caso

tanto isDecodedValid() devolverá false, que indica el comienzo de una
nueva trama.
• Un byte no válido, al devolver isDecodedValid() false. Esto se

debe a que se ha eliminado una sobrecarga de ceros y no se ha
llegado a completar los ocho bits del acumulador interno y por tanto no
se puede procesar el byte recibido hasta que llegue el siguiente.
5.4. PAQUETE COM.THEEXBTEAM.ROBOTS

La misión de este paquete es controlar la unidad remota, recibir los
datos que ésta le transmita y transmitir las órdenes pertinentes de
movimiento, ajuste de cámara o de sistema.
El siguiente diagrama UML muestra las clases principales del

paquete así como su interrelación:
- 88 -
Figura 43 Diagrama UML del paquete com.theexbteam.robots
La clase Kernel es el núcleo del sistema de control. Ella alberga las

clases CommunicationsCore, ImageCore, StatusMonitor y
CommandCore, encargadas de las tareas de comunicaciones,
procesado de imágenes, monitor de estado del robot y control de órdenes
del robot respectivamente:
• CommunicationsCore: implementa el nivel físico y de aplicación

de la pila de protocolos de comunicaciones y realiza las conexiones
con los puertos de comunicaciones serie según los parámetros que se
le pasen al crear una instancia de ella. Los bytes que recibe desde el
nivel físico a través de las clases del paquete com.theexbteam.comm
son decodificados, separando cada trama de la anterior, determinando
si pertenecen al servicio de datos o al de comandos, y, en este último
caso, enviando los paquetes de confirmaciones pertinentes. Una vez
extraído el servicio al que pertenece la información recibida, propaga
los eventos resultantes a las clases de gestión de datos y comandos:
ImageCore y StatusMonitor por un lado y CommandCore por el otro.
- 89 -
Además recoge estadísticas de uso del radio enlace que pueden ser
consultadas a través de la función getStats() que devuelve un objeto de
la clase java.util.Map con diversos valores, como son los bytes
enviados y recibidos, comandos y confirmaciones enviados y recibidos
y estado de las ventanas de envío y recepción del protocolo confirmado
de comandos. Los comandos de sistema PING no lanzan eventos
CommandEvent de tipo COMMAND_RECEIVED o COMMAND_
ACKNOWLEDGE, sino que se generan de tipo
PING_ECHO_REQUESTED cuando se reciben en la unidad remota y
PING_ECHO_RECEIVED cuando se recibe en la unidad que envió el
comando original el ACK del mismo.
• ImageCore: atiende los eventos de datos de imagen que la

unidad remota transmite al host controlador así como mantiene la
configuración de la cámara del robot. Así, permite variar los diversos
modos de adquisición de la cámara, el tiempo de exposición o la
ganancia de salida de la señal de la cámara. Las modificaciones en los
registros de la cámara sólo se mandan a la unidad remota cuando se
llama al método loadSettings(), no cuando se modifican los valores.
Para más información acerca de los valores que se pueden configurar,
vea la documentación de la clase o bien el apartado dedicado a la
cámara de la memoria.
• StatusMonitor se encarga de controlar el estado general del

robot. Toma los datos de tipo ‘status’ que se reciben desde el enlace de
radio frecuencia. Actualmente sólo se mantiene el estado ‘hay línea’
que indica que la unidad remota en modo automático está siguiendo
con éxito un camino marcado.
• CommandCore. Esta clase facilita a la interface con el usuario el

conjunto necesario de métodos para gobernar el robot en modo manual,
enviando al CommunicationsCore las órdenes de comando necesarias
para realizar los movimientos que se le indiquen.
Para interactuar con el Kernel de la aplicación se dispone de la clase

abstracta UserInterface, que se encarga de ejecutar los métodos
- 90 -
pertinentes de Kernel y sus elementos de acuerdo con las acciones que

realice el usuario o la aplicación final. Se disponen de dos clases que
heredan de UserInterface:
• CommandLineInterface, interface de línea de comandos,

orientada a interpretar cadenas de comandos que se le pasen desde
eventos de teclado.
• GraphicalUserInterface, orientada a interfaces gráficas,

proporciona los métodos de escucha de los eventos principales de
java.awt como son los MouseEvents.
Figura 44 Aspecto de la interface gráfica de usuario
- 91 -
6. APÉNDICE A: INSTALACIÓN DEL SOFTWARE

El software ha sido desarrollado y probado con éxito en un entorno
Windows NT5 (2000/Xp Home y Pro), usando para su edición JBuilder 8
Enterprise de Borland y compilando satisfactoriamente tanto con los
compiladores de Borland como los del JSDK 1.4.1_2.
Figura 45 Logotipo del lenguaje de programación Java de Sun Microsystems
El entorno Jakarta-ANT proporciona una forma rápida de compilar y

generar de forma automatizada la documentación de las librerías creadas, que
es, además, y a diferencia de ‘make’ independiente de la plataforma en que se
ejecute. Jakarta-ANT pertenece al grupo de desarrollo Jakarta de la Apache
Software Foundation.
Figura 46 Logotipo del proyecto APACHE ANT
A continuación se describe el procedimiento para instalar y ejecutar las

clases compiladas distribuidas.
6.1. INSTALACIÓN DEL ENTORNO JAVA

Si solamente desea ejecutar las clases previamente compiladas y no
tiene intención de recompilar los fuentes, deberá contar con el entorno de
ejecución de Java (JRE, Java Runtime Environment), en su versión, como
mínimo 1.4.1_2, disponible gratuitamente en:
http://java.sun.com/j2se/downloads.html
Si por el contrario desea compilar los fuentes deberá instalar el

entrono de desarrollo estándar de Java (J2SE-SDK, Java 2 Standar
Edition Software Development Kit), en su versión, como mínimo, 1.4.1_2,
también disponible desde el enlace anterior para su descarga gratuita.
- 92 -
Una vez descargado al equipo local la versión de Java, ejecute el

archivo que iniciará el proceso automático de instalación del entorne
elegido de Java.
6.2. INSTALACIÓN DE LAS LIBRERÍAS JAVAX.COMM

Para instalar correctamente las librerías de comunicaciones de Sun
Microsystem siga los siguientes pasos:
• Descargue de http://java.sun.com/products/javacomm/ la última

versión para la plataforma que use. Actualmente hay versiones
disponibles para plataformas Microsoft Windows y Sun Solares, tanto
para SPARC como para x86.
• Descomprima el contenido del archivo comprimido a una carpeta

temporal si sólo va a ejecutar el programa o bien a una carpeta de
desarrollo de su conveniencia para el caso de que prefiera compilar o
modificar los fuentes.
• Revise antes de seguir los documentos README.HTML y

jdk1.2.html por si difiriera la instalación con el procedimiento aquí
descrito para la versión 2.0 de la API de comunicaciones javax.comm.
• Localice el directorio de instalación del Java Runtime Environment,

JRE en su equipo, por defecto instalado en la subcarpeta <jdk>\jre si
instaló conjuntamente el JSDK y el JRE o en la carpeta \jre si instaló
únicamente el JRE.
• En la subcarpeta <jdk>\jre\lib\ext, copie el archivo comm.jar

que encontrará entre los archivos comprimidos.
• En la subcarpeta <jdk>\jre\lib, copie el archivo

javax.comm.properties. Si no va a compilar el proyecto, puede borrar
ya la carpeta temporal en la que descomprimió los archivos.
• Si va a compilar el proyecto deberá agregar a la variable de

entono CLASSPATH del sistema el archivo comm.jar, indicando tanto
la ruta de acceso como el nombre del mismo. Para entornos Windows
puede usar la directiva:
- 93 -
SET CLASSPATH=%CLASSPATH%;<PATH_COMM.JAR>\comm.jar
6.3. INSTALACIÓN DE LA APLICACIÓN DE CONTROL

Los archivos necesarios para ejecutar la aplicación de control así
como toda la documentación y los archivos fuentes de la aplicación se
encuentran disponibles para su descarga desde la URL
http://www.theexbteam.com/robots
Descomprima el archivo y agregue a la variable de entorno

CLASSPATH la carpeta “classes” que contiene la distribución con todas
las clases compiladas de la forma:
SET CLASSPATH=%CLASSPATH%;<PATH_CARPETA_INSTALACIÓN>\
Para ejecutar las distintas Interfaces de Usuario o programas de
diagnóstico, refiérase al fichero README.TXT de la distribución, en la
que encontrará detallada información acerca de los programas incluidos.
6.4. INSTALACIÓN DE JAKARTA-ANT

La instalación del entorno Jakarta-ANT comprende los siguientes
pasos:
• Descargue la última distribución de Jakarta-ANT desde la página

del proyecto http://ant.apache.org/.
• Descomprima el contenido de la distribución. Asumiremos aquí

<ant> como la ruta a la carpeta en la que descomprimió ANT.
• Agregue a la variable de entorno PATH en los sistemas Windows

o su equivalente para otras plataformas o sistemas operativos la
carpeta <ant>\bin. Para sistemas Windows:
SET PATH=%PATH%;<ant>\bin\
• Cree la variable de entorno ANT_HOME con la ruta a la carpeta

de instalación de ANT:
SET ANT_HOME=<ant>
• Opcionalmente, y si tiene problemas para ejecutar ANT, cree la

variable de entorno JAVA_HOME que debe apuntar a la carpeta de
instalación del JSDK:
- 94 -
SET JAVA_HOME=<PATH_JSDK>\
• Para poder ejecutar correctamente los build.xml de los paquetes

de la aplicación, deberá crear además dos variables de entorno
llamadas JAVA_LIBS y JAVA_DOC. La primera variable deberá
contener la carpeta en la que se colocarán las clases compiladas y en
la que se buscará a la hora de compilar el proyecto las clases
dependientes (CLASSPATH) y la segunda indicará la ruta donde se
copiará la documentación generada automáticamente por la tarea
‘documentar’ de que cuenta cada build.xml.
• Adicionalmente se disponen de las tareas ‘compilar’ para compilar

(tarea por defecto), ‘documentar’ para generar la documentación,
‘empaquetar’ para generar un archivo comprimido .JAR con todas las
clases, ‘limpiar’ para eliminar las clases y la documentación y
‘limpiarDoc’ para eliminar sólo la documentación generada.
- 95 -
7. APÉNDICE B ESQUEMÁTICOS DE LAS PLACAS

En las siguientes dos páginas se han recogido a gran tamaño los
esquemáticos detallados de las dos placas de control de la unidad remota.
- 96 -
U1 L7805/TO220
J3 +5V J10 J4
1 3 1 2 8
VIN VOUT GOT_LINE 7 1
2 REGULADOR D1 MOTAC3 6 2
1
1
GND +5V
+ C1 C2 C3 + C4 PWR_ON MOTAC2 5 SRV1 3
J1 220uF 100nF 100uF 100nF J2 R7 MOTAC1 4
PWR_IN PWR_OUT 1K MOTAC0 3
MODE 2 SERVO1
2
2
R1 1
470
U2 AT90S8515 TARJ_CTRL J5
PIX0 39 21 GOT_LINE 1
PIX1 38 PA0/AD0 PC0/A8 22 MOTAC3 2
PA1/AD1 PC1/A9 +5V
PIX2 37 23 MOTAC2 Y1 SRV2 3
PIX4 35 PA3/AD3 PC3/A11 25 MOTAC0 XTAL1 XTAL2
PIX5 34 PA4/AD4 PC4/A12 26 MODE SERVO2
PIX6 33 PA5/AD5 PC5/A13 27 INCAM C5 8MHz C6
PIX7 32 PA6/AD6 PC6/A14 28 ADCSTR 15pF 15pF +5V
PA7/AD7 PC7/A15
CAM1 1 10 RX U3 PIC16F84
CAM2 2 PB0/T0 PD0/RXD 11 TX R2
CAM3 3 PB1/T1 PD1/TXD 12 XRESET SRV1 17 6 CAM1 10K
CAM4 4 PB2/AIN0 PD2/INT0 13 SIN Y2 SRV2 18 RA0 RB0/INT 7 CAM2
PB3/AIN1 PD3/INT1 LOAD RA1 RB1 CAM3 J17 RESET
5 14 1 8
MOSI 6 PB4/SS PD4 15 XCLK OSC2 OSC1 2 RA2 RB2 9 CAM4
MISO 7 PB5/MOSI PD5/OC1A 16 START 3 RA3 RB3 10 EXP0 4 SW1
D14 SCK 8 PB6/MISO PD6/WR 17 READ C8 20MHz C9 RA4/TOCKI RB4 11 EXP1 3 C7
PB7/SCK PD7/RD RB5 RESET
DEP 15pF 15pF OSC1 16 12 EXP2 2 100nF
XTAL1 19 30 OSC2 15 OSC1/CLKIN RB6 13 EXP3 1
XTAL2 18 XTAL1 ALE 29 OSC2/CLKOUT RB7
XTAL2 OC1B RESET 4 R3
31 MCLR 1K
R4 RESET 9 ICP 14 EXPANS
RST +5V
470 VDD 5
40 GND
+5V
GND
VCC
20
+5V
R5 1.2K U4 J7
- 97 -
+5V VOUT 1 2 PIX0
VIN D0 3 PIX1 1
2
D1 +5V
R21 470 12 4 PIX2 XRESET 2
U5 +5V 11 REF+ D2 5 PIX3 SIN 3
D12 REF- D3 14 PIX4 LOAD 4
LM385-2.5/TO D4
J16 +5V 7 15 PIX5 XCLK 5
1
PROG MODE D5
8 16 PIX6 START 6
MOSI 1 2 13 RD D6 17 PIX7 READ 7
3 4 CS D7 VOUT 8
R22 10K RST 5 6 ADCSTR 6 9 INCAM 9
SCK 7 8 WR/RDY INT 18 10
MISO 9 10 20 OFL 11
+5V
GND
D13 VCC 12
DIODO_RST
10
PROGRAMADOR1 ADC0820
RESET
CAMARA
J8
TX 1 2
3 4
RX 5 6
7 8
9 10 +5V
Title
AURIEL Tarjeta Principal para Robot LSED

A4 1 1.2
Date: Monday , May 19, 2003 Sheet 1 of 1

U1 L7805/TO220
+7,2V +5V U2 L293
1 2
VIN VOUT MOT1_DIR0 2 3 D3 D4
2
3 D1 MOT1_DIR1 7 1A 1Y 6 1N4001 1N4001
1
1
+ C3 C1 GND C4 + C2 MOT2_DIR0 10 2A 2Y 11 J6 C6
PWR_ON 3A 3Y
J5 220uF 100nF 100uF 100nF J4 MOT2_DIR1 15 14 MOT1 100nF
PWR_IN PWR_OUT 4A 4Y
1
EN_MOT1 1 +7,2V
2
2
R3 EN_MOT2 9 1/2EN
470 3/4EN
+5V 16 D6 D5
8 VCC1
+7,2V VCC2 D9 D10 1N4001 1N4001
2
C9 + 1N 4001
Y1 100uF J7 +7,2V
MOT2 1N 4001 C10
XTAL1 XTAL2 100nF
1
U3 AT90S8515 +7,2V
C7 8MHz C8
GOT_LINE 39 21 CNY 1 15pF 15pF
MOTAC3 38 PA0/AD0 PC0/A8 22 CNY 2 D7 D8
MOTAC2 37 PA1/AD1 PC1/A9 23 CNY 3 +5V
MOTAC1 36 PA2/AD2 PC2/A10 24 CNY 4 1N4001 1N4001
MOTAC0 35 PA3/AD3 PC3/A11 25 BUMPER1 R21 470
MODE 34 PA4/AD4 PC4/A12 26 BUMPER2 +7,2V
MARCHA 33 PA5/AD5 PC5/A13 27 BUMPER3 D12
32 PA6/AD6 PC6/A14 28 BUMPER4 J16 +5V
PA7/AD7 PC7/A15 PROG
+5V +5V
MOT1_DIR0 1 10 EXP1 MOSI 1 2
D11 MOT1_DIR1 2 PB0/T0 PD0/RXD 11 EXP2 3 4
READY MOT2_DIR0 3 PB1/T1 PD1/TXD 12 MODE R22 10K RST 5 6 R14 R16
MOT2_DIR1 4 PB2/AIN0 PD2/INT0 13 INT_MEC SCK 7 8 10K 10K
5 PB3/AIN1 PD3/INT1 14 BUMP_TRAS MISO 9 10
MOSI 6 PB4/SS PD4 15 EN_MOT1 D13 RESET MARCHA
MISO 7 PB5/MOSI PD5/OC1A 16 EXP3 DIODO_RST
D14 SCK 8 PB6/MISO PD6/WR 17 EXP4 PROGRAMADOR SW1 SW2
R18 PB7/SCK PD7/RD RESET C12 C11
DEP RESET MARCHA
470 XTAL1 19 30 100nF 100nF
XTAL2 18 XTAL1 ALE 29 EN_MOT2 +5V U4A
1
XTAL2 OC1B
31 3 R15 R17
14
- 98 -
RESET 9 ICP U4C 2 1K 1K
9
R1 RST
470 +5V 40 INT_MEC 8 7432
GND
VCC 10 U4B
4
20
7432 6
7
5 J12 J14
7432 BUMPER1 4 BUMPER3 4

R10 10K 3 R19 10K 3
+5V 2 +5V 2
J3 J1 +5V +5V 1 1
8
GOT_LINE 7 EXP1 1
MOTAC3 6 EXP2 2 R12 R13 BUMPER1 BUMPER3
MOTAC2 EXP3 J8 J9
5 3 220 220
MOTAC1 4 EXP4 4
MOTAC0 3 CNY 1 4 CNY 2 4 J13 J15
MODE 2 3 3 BUMPER4 4
1 EXPAN R4 47K 2 R5 47K 2 BUMPER2 4 R20 10K 3
+5V 1 +5V 1 R11 10K 3 +5V 2
R23 +5V 2 1
1K +5V +5V 1
TARJ_PPAL U4D
12
BUMPER3 CNY 1 CNY 2 BUMPER4
BUMP_TRAS 11 R6 R8 BUMPER2
J10 J11
13 BUMPER4 220 220
7432 CNY 3 4 CNY 4 4

3 3
R7 47K 2 R9 47K 2 Title
1 1 Tarjeta de control de motores para Robot LSED
+5V +5V
A4 1 4.0
CNY 3 CNY 4
Date: Monday , June 23, 2003 Sheet 1 of 1
8. APÉNDICE F: AVISOS LEGALES

8.1. PAQUETES COM.THEEXBTEAM.*
Las librerías pertenecientes a los paquetes com.theexbteam.* se
distribuyen bajo licencia de fuente abierta u open source. Esta licencia es
la siguiente:
Copyright © 2003 The EXB Team. Todos los derechos reservados.
The EXB Team (‘EXB’) garantiza al usuario una licencia de uso, modificación y
redistribución del software tanto en forma de código fuente o binario, no exclusiva y libre de
royalties, siempre que se mantenga:
i) este aviso de copyright aparezca en todas las copias del software.
ii) El código fuente de este software se incluya en la distribución o al menos se

indique de dónde se pueda obtener dichos fuentes.
iii) El usuario licenciado no utilice el software en manera alguna que perjudique a

EXB
Este software se distribuye “tal cual”, sin garantía alguna de cualquier tipo. Toda condición
explícita o implícita, representaciones y garantías, incluyendo aquellas que impliquen
garantías comerciales están excluidas. EXB y sus usuarios licenciados no serán
responsables por cual daño que sufran los usuarios licenciados como resultado del uso,
modificación o distribución del software o sus derivados. En ningún caso EXB o sus
usuarios licenciados serán responsables por cualquier pérdida de rédito, beneficio o datos
derivados del uso de este software.
El uso de este software implica la aceptación de estos términos de uso.
Esta licencia de uso puede cambiar en versiones futuras del

software. En cualquier caso, revise la licencia que se incluya en las
distribuciones.
8.2. LIBRERÍAS JAVAX.COMM

Las librerías javax.comm de la API de comunicaciones de Java
proporcionadas por Sun Microsystems se licencian según el acuerdo de
uso descrito en el formulario Form ID#011801/LFI#123979 disponible en
el paquete de las librerías y desde la URL
http://java.sun.com/products/javacomm/COMM2.0.3_license.txt.
- 99 -
Sun Microsystems no ofrece ningún tipo de garantía de

funcionamiento del software, proveyéndolo “tal cual” y su única
responsabilidad se limita al reemplazo del Software.
8.3. TERCERAS PARTES

Microsoft Windows es una marca registrada de Microsoft
Corporation.
Java, JSDK, JRE y J2SE son marcas registradas de Sun

Microsystems. El logotipo de Java pertenece a Sun Microsystems.
Apache, Jakarta-ANT y ANT son marcas registradas de la Apache

Software Foundation. El paquete ANT se distribuye bajo licencia Apache
Software License, Version 1.1, disponible desde la URL
http://ant.apache.org/manual/LICENSE. El logotipo de Apache-ANT y
Apache pertenecen a la Apache Software Foundation.
- 100 -
9. BIBLIOGRAFÍA
Para más información sobre este y otros proyectos, versiones
actualizaciones del software y firmware del robot así como la API detallada de
las librerías empleadas, consulte
http://www.theexbteam.com/robots
9.1. REFERENCIAS BIBLIOGRÁFICAS (POR HACER)

• [FRA88] Sergio Franco, “Operational Amplifiers and Analog Integrated
Circuits”, McGraw-Hill International Editions, Electrical & Electronic
Engineering Series. International edition 1988.
• [FER et al. 2002] J. Ferreiros, J. Macías, et al. “Aspectos prácticos de

diseño y medida en laboratorios de electrónica”, Servicio de
publicaciones, E.T.S.I. Telecomunicación. UPM, 2002.
• [MAL98] N. R. Malik. “Circuitos electrónicos. Análisis, diseño y

simulación”, Prentice Hall, Madrid, 1998
• [SAN01] Jesús Sanz Maudes et al. “Manual de prácticas de

Laboratorios de Electrónica Básica y Componentes, 2ª Parte”
(simulaciones PSPICE), Servicio de publicaciones, E.T.S.I.
Telecomunicación UPM, 2001.
• [WAK01] John F. Wakerly. “Diseño digital”, Prentice Hall, México,01.
• [TAN03] Andrew S. Tanenbaum, “Computer Networks”, fourth

international edition, Prentice Hall, Upper Saddle River (NJ), 2003.
• [HER97] Guillermo Herranz Acebo, “Ingeniería Eléctrico”, 1997,

Madrid, Departamento de Publicaciones de la E.T.S.I
Telecomunicación UPM.
9.2. HOJAS DE CARACTERÍSTICAS Y RECURSOS EN LA

RED
Se han empleado las siguientes hojas de características disponibles
en Internet:
- 101 -
• Philips Semiconductors, http://semiconductors.philips.com, para

los componentes digitales.
• Maxim, http://www.maxim-ic.com, para los conversores RS232 a

TTL MAX232.
• Atmel, http://www.atmel.com, para los microcontroladores.
• Nacional Semiconductors, http://www.national.com, para el

ADC0820.
• Microchip, http://www.microchip.com, para el PIC16F84.
• Timming tool, http://timingtool.com/, para los cronogramas.
9.3. DIRECCIONES DE FABRICANTES Y PROVEEDORES

A continuación se facilitan las siguientes direcciones de los
fabricantes y proveedores del material necesario para fabricar el
hardware del robot y el control remoto:
• AUR°EL S.p.A., Via Foro dei Tigli, 4 - 47015 Modigliana [FC] –

ITALY, Tel.: (+39) 0546941124, Fax: +390546941660. Fabrica los
enlaces radio frecuencia empleados. Para más información,
http://www.aurel.it.
• ENDRICH Bauelemente S.L., c/ Balmes 243. – 08006

BARCELONA, Tel. (+34) 93 217 31 44, Fax. (+34) 93 217 97 20,
e-Mail: endrich@intercom.es, suministrador oficial de AUR°EL en
España. Para más información y pedidos,
http://www.endrich.net/.
• eBay, http://www.ebay.com, para la cámara digital.
- 102 -

Ejemplo Robot - Open - Softwear-Beta090712

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ejemplo Robot - Open - Softwear-Beta090712

Cargado por

Copyright:

Formatos disponibles

Laboratorio de Sistemas Electrónicos Digitales

ROBOT CON CONTROL REMOTO

3. TARJETA DE CONTROL DE MOTORES ............................... 24

4. TARJETA DE CONTROL PRINCIPAL.................................... 54

5. HOST DE CONTROL REMOTO.............................................. 82

6.1. INSTALACIÓN DEL ENTORNO JAVA................................................92

Figura 32 Interfaz de la tarjeta principal con la cámara. ............................... 57

El enlace se realiza mediante una tarjeta de radiofrecuencia half-

El robot está gobernado por una tarjeta con un microcontrolador

La microcámara que se emplea es el modelo M64282FP Artificial

El objetivo buscado es la creación de un robot multifunción,

1.2. DESCRIPCIÓN DEL ROBOT

La estructura es de madera por su fácil manejo y poco peso. En la

Figura 1 Vista general del prototipo en madera del robot

Figura 2 Vista lateral del robot

La batería utilizada es una batería típica para aplicaciones de

Figura 3 Detalle de la batería del robot

La tarjeta de radio, la cámara y la tarjeta de control principal forman

Figura 4 Tarjeta de control del robot y radio enlace

También dispone de unos LEDs de indicación y un pulsador de reset.

En la parte superior delantera también se colocan los sensores de

Figura 5 Frontal del robot con los bumpers de colisión

En la parte inferior se colocan los motores sujetos por abrazaderas.

Figura 6 Parte inferior del robot.

En la parte inferior también se colocan los sensores de colisión

Figura 7 Detalle del bastidor delantero

La colocación de los sensores se hace de forma que haya dos

curva por la inercia los sensores laterales sigan detectando la línea. En

Figura 8 Detalle de los sensores CNY70 del robot.

La tarjeta de control de motores se coloca en el espacio libre bajo el

Figura 9 Tarjeta de control de motores con todos los sensores conectados

En cuanto a la interfaz con el usuario se refiere, a los LEDs de

robot espera a que el usuario pulse el botón de marcha para arrancar. El

La pila de protocolos empleada es la siguiente:

RESTO END TO END APPLICATION

Tabla 1. Pila de protocolos.

El nivel de enlace lleva a cabo las tareas de entramado, separación de los

2.1. EL NIVEL FÍSICO: ENLACE RADIOFRECUENCIA

Figura 10 Comunicación serie un bit de arranque, 8 de datos y uno de parada.

Este enlace lo realizan las tarjetas Auriel WIZ-434-SML-IA y exige

Figura 11 Módulo de radio frecuencia WIZ-434-SML-IA de Auriel

La interface entre la tarjeta de radiofrecuencia y el host destinatario

La tarjeta de radiofrecuencia se pone automáticamente a modular la

Para nuestro caso, dado que transmitimos a una cadencia de

Sin embargo, según indican las hojas de características del

Finalmente, la tarjeta de radiofrecuencia tarda un tiempo Tmod en

Tmod = 3.6ms + ( N + 2)·0.156ms,

durante el cual no se puede mandar ningún dato a la tarjeta, pues

El módulo WIZ-SML-IA proporciona además capacidad de detección

2.2. NIVEL DE ENLACE: LAPR

Por ello se define el protocolo de enlace LAPR (Link Access Protocol

Cada servicio se identifica a través de un único bit LSAPID (Link

• LSAPID 0 Servicio de Comandos. Este servicio es un servicio

Para enviar un comando, la cabecera de control deberá incluir

Este servicio reenvía automáticamente los comandos no

Envío de ACK de Comando:

Para confirmar un comando, el servicio 0 de enlace manda

activo, seguido de los cinco bits del ID de trama. Los ACKs se

• LSAPID 1 Servicio de Datos. Este servicio es un servicio no

Donde se disponen de seis bits para los datos de estado. En el

Envío de Píxeles de Imágenes:

La cabecera de control incluye en sus seis bits menos

2.3. PROTOCOLO DE COMANDOS