práctica de laboratorio de sistemas digitales. microbot tritt

Laboratorio de Sistemas Digitales Departamento de Tecnología electrónica

E.T.S. de Ingenieros de Telecomunicaciones

MICROBOT

“Jugador de Golf”

Juan Mahón IglesiasAndrés Sanz Rivas

Félix Navarro Guirado

ÍNDICE:

1.- Objetivos del Sistema ............................................................................ 1 2.- Descripción del Sistema ........................................................................ 2

a) Hardware Empleado ............................................................. 2

b) Software Implementado ....................................................... 9

3.- Pruebas .................................................................................................. 21 4.- Conclusiones ......................................................................................... 25

a) Problemas ............................................................................. 25

a.1) Físicos y Mecánicos ...................................................... 25 a.2) De programación ........................................................... 26

b) Conclusiones ........................................................................ 31

c) Mejoras Posibles .................................................................. 32

Laboratorio de Sistemas Digitales

1

1.- OBJETIVOS DEL SISTEMA:

El objetivo de nuestra práctica es desarrollar un Microbot, el cual, tras situarlo

en un campo de juego junto con una bola y un hoyo, sea capaz de “jugar al golf”. Esto es, el Microbot deberá en primer lugar localizar ambos objetos y conseguir introducir la bola en el hoyo. Para esto deberá, después de localizarlos, situarse tras la bola, en la perpendicular con el hoyo y golpear a esta para conseguir introducirla. Después de golpear, el Microbot comprobará si ha conseguido su objetivo, en el caso en el que no lo haya hecho, volverá a repetir el mismo procedimiento hasta conseguir hacerlo.

La únicas restricciones que pondremos al juego serán restricciones sobre el tamaño de los elementos de juego:

- Usaremos como bola una pelota de tenis. - Usaremos como banderín para el hoyo un lápiz grueso. - El campo de juego tendrá unas dimensiones máximas de 80 cm de diámetro.

Desarrollaremos nuestro proyecto a partir de un Microbot Tritt de Microbótica,

controlado por un microprocesador HC11 de Motorola. A este Microbot inicial le realizaremos una serie de modificaciones con el fin de conseguir nuestros objetivos, como ya contaremos en siguientes apartados.


2

2.- DESCRIPCIÓN DEL SISTEMA:

a) HARDWARE EMPLEADO:

Para el desarrollo de nuestros objetivos, como ya hemos comentado, partiremos de un Microbot Tritt de Microbótica, al cual le realizaremos las modificaciones necesarias para cumplir nuestros objetivos. Las modificaciones Hardwares necesarias que hemos introducido en el Microbot inicial, son las siguientes:

- Sustituir los servo-motores (motores de continua) por motores paso a paso, para así hacer posible controlar los ángulos de giro y las distancias que recorre nuestro Microbot.

- Sustituir los sensores de infrarrojo por sensores de distancia, para así poder

conocer las distancias a la que se encuentran los objetos con los que el robot interactúa para conseguir nuestros objetivos: el hoyo y la bola.

- Sustituir las ruedas delanteras por otras de mayor radio y adherencia, ya que

los nuevos motores son mas grandes que los anteriores y las antiguas ruedas eran demasiado pequeñas y porque al aumentar el peso del Microbot necesitamos mayor adherencia.

- Sustituir la rueda trasera por una “rueda-loca” que nos permita girar en todas

direcciones sin ninguna oposición al movimiento.

- Añadir una superficie frontal sobre la que poder colocar los sensores de distancia.

- Añadir una superficie de golpeo en el frente del robot, para poder,

obviamente, golpear a la bola, con el objetivo de introducirla en el hoyo.

- Añadir una placa donde instalaremos la circuiteria necesaria para poder controlar los nuevos elementos Hardwares añadidos (sensores y motores).

- Añadir una placa de memoria de 32Kbytes para poder almacenar todo el

código de desarrollo del proyecto.

Los elementos Hardware básicos sobre los que se sustenta nuestro diseño son los motores paso a paso y los sensores de distancia. Comentaremos a continuación con mas detalle el funcionamiento de estos:


3

• Motores Paso a Paso (PM35s):

Un motor paso a paso es un tipo de motor especial cuya principal característica es el hecho de poder moverlos de forma incremental (paso a paso, un paso a la vez por cada pulso que se le aplique), donde cada paso representa un desplazamiento angular fijo del eje del motor. Los motores paso a paso son ideales para la construcción de mecanismos en donde se requieren movimientos muy precisos como es nuestro caso.

Nuestro motor es un motor paso a paso unipolar (con seis cables de salida), se llaman así porque la corriente que circula por las diferentes bobinas siempre circula en el mismo sentido.

El principio en el que se basan este tipo de motores para funcionar es básicamente que están constituidos por un rotor sobre el que van aplicados distintos imanes permanentes y por un cierto número de bobinas excitadoras. La excitación de las bobinas deber ser manejada externamente por un controlador, en nuestro caso el 68HC11 de Motorola, y según activemos unas u otras (haciendo pasar corriente a través de ellas) y como las combinemos, conseguiremos que el motor se mueva de distinta forma (mayor o menor velocidad, pasos mas largos o mas cortos...).

Cada inversión de la polaridad en las bobinas del motor provoca el movimiento del eje en un paso, cuyo sentido de giro está determinado por la secuencia seguida.

Presentamos a continuación una serie de tablas con las secuencias posibles para controlar motores paso a paso unipolares:


4

Secuencia Normal: Esta es la secuencia más usada y la que generalmente recomienda el fabricante. Con esta secuencia el motor avanza un paso por vez y debido a que siempre hay al menos dos bobinas activadas (1 vuelta = 4 pasos):

PASO Bobina A Bobina B Bobina C Bobina D

1 ON ON OFF OFF

2 OFF ON ON OFF

3 OFF OFF ON ON

4 ON OFF OFF ON

Secuencia del tipo wave drive: En esta secuencia se activa solo una bobina a la vez. Esto nos permite un funcionamiento mas suave (1 vuelta = 4 pasos):


1 ON OFF OFF OFF

2 OFF ON OFF OFF

3 OFF OFF ON OFF

4 OFF OFF OFF ON


5

Secuencia del tipo medio paso: En esta secuencia se activan las bobinas de tal forma que el paso conseguido es la mitad del paso normal. Para ello se activan primero dos bobinas y luego solo una y así sucesivamente (1 vuelta = 8 pasos):


1 ON OFF OFF OFF

2 ON ON OFF OFF

3 OFF ON OFF OFF

4 OFF ON ON OFF

5 OFF OFF ON OFF

6 OFF OFF ON ON

7 OFF OFF OFF ON

8 ON OFF OFF ON

Para el funcionamiento del un motor hemos utilizado un circuito integrado (ULN2803, es una array de 8 transistores tipo Darlington) con el siguiente esquema de funcionamiento, lógicamente la entrada a este circuito integrado esta controlado por el microcontrolador: las entradas 1,2,3,4 corresponden a los puertos de salida del micro y las salidas denominadas 1, 2, 3 y 4 corresponden a las entradas del motor .


6

• Sensores de Distancia (GP2D12):

Este tipo de sensores nos permiten conocer la distancia que les separa de algún objeto; se basan en el principio de triangulación para realizar las medidas. El elemento a la izquierda del sensor según vemos en la imagen es un led infrarrojo que emite un haz que rebotará en el objeto y posteriormente será recogido por el elemento situado a la derecha. Este último se conoce como PSD (Dispositivo de Percepción de Posición), puede entenderse como una lente situada sobre un array de células sensibles a la luz infrarroja. Dependiendo del ángulo de incidencia del haz rebotado en la lente, se activa una u otra célula del array lo que permite estimar la distancia a la que se encuentra el objeto.

El conexionado de los GP2D12 con al microntrolador requiere únicamente una entrada del conversor analógico-digital a la que se conectará el pin de salida del sensor (Vo). Los otros dos pines corresponden, respectivamente, con GND y con Vcc; nosotros hemos conectado la alimentación del sensor (Vcc), a través de un driver (L293) a una salida del puerto D, de forma que podemos controlar cuando el sensor esta encendido, para así disminuir el consumo cuando no necesitemos estar midiendo.


7

Los valores de salida del sensor están comprendidos entre los 0 y 3 voltios, por lo que para conseguir una mejor exactitud en nuestras medidas, situaremos el nivel de referencia VRH (puerto E) en torno a esos 3 voltios, y dejaremos VRL a 0 voltios. Con estas condiciones conseguimos unos valores entre 25 y F8 a la salida del sensor, por lo que aprovechamos bastante bien el rango de salida.

El mínimo valor devuelto por el sensor (cercano a 0 voltios), se corresponde a su máxima distancia (80 centímetros) y el mayor (unos 3 voltios) con su mínima distancia (8 centímetros). Estos son los valores máximo y mínimo que el sensor es capaz de detectar.

Los valores intermedios no se ajustan linealmente, sino que siguen una curva que hemos obtenido calibrando nuestro sensor; en la siguiente tabla observamos los valores que usaremos para convertir estos valores intermedios y así conocer la distancia a la que están los obstáculos desde nuestro robot.

Distancia

(cm) Salida del

sensor Pasos del

Motor Distancia

(cm) Salida del

sensor Pasos del

Motor

8 F8 13 28 61 45

9 F4 14 30 5B 48

10 EB 16 34 4F 54

11 DD 18 38 48 61

12 CF 19 42 43 67

13 C2 21 46 3E 74

14 B5 22 50 3B 80

15 AC 24 54 38 86

16 A3 26 58 34 93

17 9C 27 62 30 99

18 93 29 66 2D 106

19 8D 30 70 2B 112

20 86 32 74 2A 118

22 7A 35 78 27 125

24 79 38 80 25 128

26 70 41


8

Esta tabla la podemos ver gráficamente en la siguiente curva:

0 10 20 30 40 50 60 70 800

50

100

150

200

250Tabla de Convers ion: sensor - dis tanc ia

Dis tanc ia (cm )

Sal

ida

Sen

sor (

deci

mal

)

Las conexiones de nuestros elementos hardware con el micro las hacemos a través de los puertos A,D y E, como mostramos en la siguiente tabla:

Puerto A Puerto D Puerto E

PA0 Motor Dcho1

PD0

Permiso Sensor

Exterior PE0

PA1 Motor Dcho2

PD1

Permiso Sensor Central

PE1

PA2 PD2 Motor Izqdo4 PE2

PA3 Motor Dcho3

PD3

Motor Izqdo2 PE3

Salida Sensor

Exterior

PA4 Motor Dcho4

PD4 Motor Izqdo3 PE4

PA5 PD5 Motor Izqdo1 PE5

PA6 PD6 PE6

PA7

PD7

PE7 Salida Sensor Central


9

b) SOFTWARE IMPLEMENTADO:

• Diagrama de flujo:

En el siguiente diagrama presentaremos la forma de solucionar el problema a que nos enfrentamos, y así será como programaremos el código que luego ejecutará el Microbot.

Girar hasta encontrar algo

(sensor 1)

Convertir distancia a pasos

¿Muy lejos?

Cambiar Posición

SI

NO

Girar hasta encontrar algo

(sensor 2)

¿Lo ve sensor 1 también?

Calcula distancia (haciendo media)

¿Bola ya?

NO

Calcula distancia (haciendo media)

¿Hoyo ya?

NO

Colocar detrás de la Bola

SISI

Golpear Bola

Calcula la distancia Bola-Hoyo

NOSI

Es Bola Es Hoyo

¿Dentro ya?

NO

FIN

Hemos tenido en cuenta la posibilidad de que solo encuentre uno de los objetos, porque uno este detrás del otro. Esto está incluido dentro del bucle “girar hasta encontrar”, ya que el robot comprueba cada vez que gira si ya ha dado una vuelta completa y si solo ha encontrado un objeto, en este caso el robot gira un número de grados y avanza cierta distancia y vuelve a empezar. El error de que no se encuentre ningún objeto también lo hemos tenido en cuenta, pero esta situación nunca debe producirse, ya que los objetos deben estar situados, al igual que el robot en el campo de juego, que tendrá un máximo de 80 cm de radio.

10 11

12 13

1415 16

18

17

2

3

4

5

6 7

8 9

1


10

• Código del programa:

En este apartado comentaremos detalladamente el código del programa, el cual adjuntamos al final de la memoria, por cuestiones de tamaño y complejidad.

Comenzamos comentando las subrutinas mas frecuentemente utilizadas por el programa principal (comentado en la página 19), para su mejor comprensión:

• Subrutina “Sense”: es la encargada de la toma de distancias a través de los sensores. Los sensores están permitidos por los bits 0 (sensor exterior) y 1 (sensor central) del puerto D. Las salidas de estos se muestran por los bits 3 (sensor exterior) y 7 (sensor central) del Puerto E. Como se observa en el código en caso de que la medida entre dentro del margen la realizamos dos veces, esto sólo sirve para aumentar la fiabilidad de la medida.

Esta subrutina es válida para la medición por ambos sensores, por tanto tenemos que decidir cual de ellos realiza la medición, para ello basta con cargar en el registro ‘y’ la secuencia correspondiente al sensor utilizado, el primer dato de la secuencia se corresponde con el bit del puerto D que vamos a encender y el segundo el bit del puerto E sobre el cual se va a realizar el muestreo. El conversor A/D está programado en modo SCAN y cuatro muestras sobre un solo canal, como se indica en el segundo byte de la secuencia. El valor de la medida se compara con el umbral y si es mayor (ver tabla de los sensores) se devuelve en el registro ‘A’, en caso contrario se devuelve un cero.

sense ldaa #02 staa tempsense sense2 ldx #$1000 ldaa portd,x oraa ,y staa portd,x ldab 1,y stab adctl,x bucle2 brclr adctl,x $80 bucle2 ldaa adr1,x cmpa umbral bhi objeto ldaa #0 objeto ldab tempsense beq finsense cmpa #0 bne otravez1 finsense rts otravez1 dec tempsense bra sense2


11

• Subrutina ‘movmotor’: es la encargada del manejo de los motores paso a paso. Esta subrutina está basada en las secuencias de movimiento de los motores. En cada uno de los bytes de ella se indica que bits del puerto A o D (según movamos el motor derecho o izquierdo) se han de activar para cargar cada una de las bobinas según las secuencias presentadas en el apartado HARDWARE, el procedimiento que usamos para movernos por la tabla no es más que un puntero que se va incrementando y apuntando al valor siguiente de la tabla. Hemos de mencionar que los dos últimos bits del puerto D determinan la activación o desactivación de los sensores, de esta manera conseguimos desactivar los sensores mientras andamos como se describió anteriormente. Para conseguir desplazarnos por la tabla cada vez que vayamos a mover un dato al puerto D lo conseguimos de una dirección con desplazamiento relativo indicado en cont1 o cont2, según el motor, que hacen las veces de puntero.

En la variable motor se carga el tipo de movimiento que queremos realizar, los dos últimos bits indican si el movimiento de el motor es hacia delante o hacia atrás, y combinando estas posibilidades conseguimos movimientos del robot hacia delante (motor = 05), hacia atrás (motor = 00), hacia la derecha girando sobre la rueda izquierda (motor = 02), hacia la izquierda girando sobre la rueda derecha (motor = 01), hacia la derecha sobre el eje central del robot (moto =6), hacia la izquierda sobre el eje central del robot (motor=9).

movmotor psha pshb ldab cont1 ldx #1 brset motor $01 avanza brset motor $02 retroced motor2 stab cont1 dex

ldab cont2 brset motor $04 avanza brset motor $08 retroced (CONTINÚA)

;secuencia wave drive (4 pasos) sec1 fcb %00001000,%00010000,%01000000,%10000000,%00001000,%00010000,%01000000,%10000000 sec2 fcb %00100000,%00000100,%00010000,%00001000,%00100000,%00000100,%00010000,%00001000 ;secuencia medio paso (8 pasos) ;8pasos1 fcb %00001000,%00011000,%00010000,%01010000,%01000000,%11000000,%10000000,%11000000 ;8pasos2 fcb %00100011,%00100111,%00000111,%00010111,%00010011,%00011011,%00001011,%00101011 ;secuencia normal (4 pasos) ;4pasos1 fcb %00011000,%01010000,%11000000,%11000000,%00011000,%01010000,%11000000,%11000000 ;4pasos2 fcb %00100111,%00010111,%00011011,%00101011,%00100111,%00010111,%00011011,%00101011

(CONTINUACIÓN) fin stab cont2 ldx #sec1 ldy #sec2 ldab cont1 abx ldab cont2 aby ldaa 0,x ldab 0,y ldx #$1000 staa porta,x stab portd,x bsr delay pulb pula rts


12

• Subrutinas ‘moverse’, ‘giradcha’ y ‘giraizqda’: se encargan de hacer girar al Microbot hacia la derecha o hacia la izquierda. Cargando el valor adecuado en la variable motor, además de decrementar la variable ‘pasos’ y compararla con vuelta para comprobar si ha dado una vuelta completa (para ver si ha dado una vuelta sin encontrar nada), como los giros hemos mencionado que se pueden realizar de dos modos (sobre una o las dos ruedas) hemos especificado una variable tras bola que indica si nos encontramos en detrás de la bola dispuestos a golpear, pues este es el único momento en el que realizamos un giro sobre las dos ruedas. A la subrutina moverse se le pasa el número de pasos que queremos hacerlo en el registro ‘B’.

giradcha pshx pshy psha pshb ldy pasos cpy vuelta bhi noencuentro dey sty pasos dec distbh ldaa trasbola beq giro_norm ldaa #6 bra salto giro_norm ldaa #$02 salto staa motor jsr movmotor pulb pula puly pulx rts

giraizqda pshx pshy psha pshb ldy pasos cpy vuelta bhi noencuentro iny sty pasos inc distbh ldaa trasbola beq giro_normal ldaa #9 bra salta giro_normal ldaa #01 salta staa motor jsr movmotor pulb pula puly pulx rts

moverse ldab #5 stab motor buclemoverse jsr movmotor deca bne buclemoverse rts

avanza incb cmpb #8 bne siguem ldab #0 bra siguem retroced cmpb #0 bhi sigue1 ldab #8 sigue1 decb siguem cpx #0 bne motor2 bra fin


13

• Subrutinas ‘convierte’: Con esta subrutina pasamos a pasos la medición

indicada por el sensor, la medición debe ser almacenada en “disthex" y el valor convertido queda memorizado en “distpasos”,como en casos anteriores poseemos una tabla que en este caso indica la conversión:

La tabla está dividida en dos campos diferentes, el primero indica el valor en hexadecimal y el segundo su conversión a pasos que indicamos en decimal para una fácil distinción, la búsqueda en la tabla la realizamos de forma secuencial, vamos comparando el valor de “disthex" con el de la tabla hasta que sea mayor que él. Convierte2 hace el proceso inverso.

convierte ldaa #0 staa desp ldaa disthex busca ldx #tabla ldab desp

abx ldab 0,x cba bhi enc inc desp inc desp bra busca enc ldx #tabla ldab desp incb abx ldab 0,x stab distpasos rts

tabla fcb $E8,13,$E5,14,$DD,16,$D0,18,$C3,19,$B7,21,$AB,23,$A2,24,$99,26,$91,27,$8B,29,$85,30 tablab fcb $7E,32,$72,35,$69,38,$62,42,$5B,45,$55,48,$4A,54,$41,61,$3D,67,$39,74,$35,80,$32,86 tablac fcb $30,93,$26,99,$2C,106,$2A,112,$28,118,$27,125,$25,128

convierte2 ldaa #1 staa desp ldaa distpasos busca2 ldx #tabla ldab desp abx ldab 0,x cba blt enc2 inc desp inc desp bra busca2 enc2 ldx #tabla ldab desp decb abx ldab 0,x stab disthex rts


14

• Subrutina ‘medirdist’: Cuando deseamos calcular la distancia que nos

separa de la bola, puesto que ésta no es una superficie perpendicular a nosotros obtenemos valores bastante dispares según la observemos perfectamente en la perpendicular que apunta a su centro o en cualquier otra dirección, pero esto no es debido a que no todos los puntos de la bola distan lo mismo del sensor sino porque el funcionamiento ante superficies no perpendiculares del sensor no es bueno (ver sección Hardware). Por esto es necesario tomar varias medidas, ya sea para la bola o el sensor, para asegurar su fiabilidad tomamos todas las medidas que podamos del objeto almacenándolas en una lista, de todas las medidas tomaremos la que se encuentre en la posición central (si el número de medidas es impar) o la media de las que se encuentren en las 2 posiciones centrales (si el número de muestras es par).

medirdist ldab #0 stab contmed ldy #sensor2 buclemedir psha inc contmed jsr giraizqda ldy #sensor2 jsr sense jsr sense staa dist1 ; jsr mandarhex ; jsr espera ldaa dist1 cmpa #0 beq media bra buclemedir media ldy #calcmedia ;jsr mand_cad ;jsr espera ldaa contmed ;jsr mandarhex ;jsr espera ldab contmed cmpb #1 bne siguemed pula staa distancia rts siguemed ldab contmed ldaa #0 ldx #2 idiv cmpd #0 beq espar inx stx temp ldab contmed ldaa #0 subd temp stab contmed (CONTINÚA)

(CONTINUACIÓN) buclepila pula jsr giradcha dex bne buclepila staa distancia ;jsr mandarhex ;jsr espera ldab contmed vaciar pula decb bne vaciar ldy #valorfinal ;jsr mand_cad ;jsr espera ldaa distancia ;jsr mandarhex ;jsr espera rts espar pulb dey bne espar ldaa #0 std temp pulb addd temp ldx #2 idiv stx temp ldd temp stab distancia ldy #valorfinal ;jsr mand_cad ldaa distancia ;jsr mandarhex ;jsr espera rts


15

• Subrutina ‘posiciona’: Como se muestra en la figura tras determinar la

posición del hoyo y la bola tenemos que ponernos tras esta última para golpear, pero la secuencia de movimientos hacia la derecha e izquierda cambia según lo último que encontremos, puesto que la búsqueda siempre se hace girando hacia la derecha (ver diagrama de flujo del código principal) podemos determinar esta secuencia según terminemos mirando hacia uno u otro, este control se realiza mediante la variable “izqdcha” tomando ésta valor $FF si terminamos mirando hacia la bola o $00 si terminamos orientados hacia el hoyo. En la figura se muestra el caso “izqdcha”=$00

Si se observa el diagrama de flujo podemos ver que siempre finalizamos orientados hacia la bola por lo que esto no es problema, el cálculo del exceso se muestra en el siguiente punto.

Posiciona ldaa #26 staa dist1 ldaa izqdcha jsr compara ;jsr espera ldaa #40 jsr moverse ldaa #26 staa dist1 ldaa izqdcha coma jsr compara ;jsr espera ldab disthoyo jsr convertir stab disthoyo ldab distbola jsr convertir (CONTINÚA)

(CONTINUACIÓN) stab distbola ldaa disthoyo ;jsr mandarhex ldaa distbola ;jsr mandarhex ldaa distbh2 ;jsr mandarhex ;jsr espera jsr cal_exceso ;ldaa exceso ;jsr mandarhex ;jsr espera ldaa exceso jsr moverse jsr buscabola jsr golpear rts


16

• Subrutina ‘calc_exceso’: Como se comenta en el punto anterior en esta

subrutina calculamos el número de pasos que tenemos que dar de más para colocarnos en la línea bola-hoyo, para esto hemos tenido que tabular la función seno y utilizar rutinas en punto flotante cuyo uso se explica en el siguiente apartado. Mostraremos ahora la fórmula que implementa esta subrutina.

Hemos de mencionar que la función ‘convseno’ es la que usamos para manejar la tabla del seno, y que sus valores están ordenados según su argumento estando este medido en pasos de manera que nºpasos · 3’4 = nº grados y su salida es adimensional por lo cual no requiere conversión.

seno fcb 6,12,18,24,29,35,40,46,51,56,61,65,70,74,78,81,85,88,90,93,95,97,98,99,100,100,100,100,99,98,96,95 seno2 fcb 93,90,87,84,81,77,74,69,65,60,56,51,45,40,35,29,23,17,11,6,0

convseno cmpb #53 blt sigueseno cmpb #106 blt signomenos subb #106 bra convseno signomenos subb #53 ldaa #$ff staa signo sigueseno ldy #seno

aby ldab ,y ldaa #0 std fpacc1mn+1 jsr uint2flt ldaa signo staa mantsgn1 jsr fltdiv rts

calc_exceso ldd #100 std fpacc1mn+1 jsr uint2flt jsr tfr1to2 ldaa #00 staa signo ldab distbh2 jsr convseno jsr tfr1to2 ldaa #0 ldab disthoyo std fpacc1mn+1 jsr uint2flt jsr fltmul ldx #temp jsr putfpac1 ldd #100 std fpacc1mn+1 jsr uint2flt jsr tfr1to2 ldab distbh2 fpacc1mn+1 jsr uint2flt jsr fltmul jsr tfr1to2 ldaa #0 ldab distbola std fpacc1mn+1

jsr uint2flt jsr fltsub ;jsr flt2int ldx #temp jsr getfpac2 jsr fltdiv jsr tfr1to2 ldab #40 ldaa #0 std fpacc1mn+1 jsr uint2flt jsr fltmul ldaa mantsgn1 staa signo ldaa #0 staa mantsgn1 jsr flt2int ldab fpacc1mn+2 stab z ldab distbola ldaa signo bne esnegativo addb z bra finseno esnegativo subb z finseno stab exceso rts

( ))(·

2

αα π

senasenabexceso −−−=


17

• Rutinas punto flotante: Para el cálculo de la distancia anterior hemos

utilizado operaciones con decimales de manera que se hace evidente el uso de rutinas en punto flotante (pues redondeando valores no obteníamos resultados demasiado precisos). Las rutinas utilizadas son las proporcionadas por Motorola y por tanto sólo haremos comentarios sobre su uso. El operando se estructura del siguiente modo: 31_______24 23 22_____________________0 exponent s mantissa

De manera que estos datos se almacenan en tres variables: FPACC?EX RMB 1 FPACC?MN RMB 3 MANTSGN? RMB 1

Pudiendo ser ? igual a “1”ó “2” dependiendo del acumulador con el que tratemos pues estos serán los operandos de la operación a realizar, para transformar un numero de su notación normal y sin signo a punto flotante usamos “UINT2FLT” y basta con pasarle el dato de 2 bytes a las posiciones bajas de la mantisa del acumulador 1 y lo devuelve en este mismo. Para las operaciones de suma, resta y multiplicación (“FLTADD”, ”FLTSUB”, ”FLTMUL”, “FLTDIV”) actúa del modo en el que sigue: acum1(operac)acum2 � acum1 dejando el segundo operando sin cambiar, hemos de tener en cuenta que el fallo de división por cero nunca va a suceder debido a la estructura del programa.; para volver el número a su notación normal usaremos “FLT2INT” que hace la operación contraria a la conversión. Mención merecen también las funciones “GETFPAC?” y “PUTFPAC?” que se usan para obtener y almacenar en memoria datos temporales en punto flotante, su uso es sencillo pues basta con poner en el registro X la dirección de memoria inicial donde se desea hacer la operación de manera que con los debidos incrementos y decrementos de este parámetro sería sencillo implementar una pila si la operación a realizar lo requiere. Para transferencias entre uno y otro acumulador se ha de usar “TRFXTOY” donde x e y son los acumuladores 1 o 2.


18

• Subrutina “golpear”: Con esta subrutina elegimos la velocidad con la que

deseamos golpear la bola, tomamos 30 pasos de “carrerilla” y vamos incrementando la velocidad (decrementando la variable “velocidad”) de manera que cada FLOOR [(veloc máxima - veloc inicial) / distancia a la bola] incrementa la velocidad y variando la velocidad máxima de manera que esta sea proporcional a la distancia entre la bola y el hoyo conseguimos el empuje correcto. NOTA: EL funcionamiento de esta rutina está condicionada por el tipo de suelo sobre el que se mueva el robot.

• Subrutrina “dosbolas”: Sólo hacemos uso de esta subrutina en caso de

encontrar una bola cuando ya se había detectado previamente otra, ante esta situación nos acercamos la mitad de la distancia que nos separa del objeto y volvemos a medir, se prevé que podamos desviarnos de la línea que nos dirige hacia la bola, para ello vamos contando el número de giros que hemos de realizar para volver a detectarlo y así poder seguir el mismo camino hacia nuestra posición inicial. Si una vez vuelta a realizar la medida desde la nueva posición decidimos que el nuevo objeto es una bola esto es porque el que se detectó anteriormente era el hoyo por lo que le asignamos la distancia anterior al la distancia que nos separa del hoyo, de lo contrario detectaremos el error y diremos que esta última distancia es la correspondiente al hoyo.

golpear ldaa #10 staa motor ldaa #30 buclegolpear jsr movmotor deca bne buclegolpear

ldaa #5 staa motor ldy #sensor2 jsr sense jsr sense staa disthex jsr convierte ldaa distpasos ldx #$6000 stx velocidad bucle10 ldab #3 ldd velocidad cpd #$1800 blt inf2 subd #$a00 std velocidad (CONTINÚA)

(CONTINUACIÓN) bucle5 jsr movmotor deca beq fingolpeo

decb bne bucle5 bra bucle10 inf2 jsr movmotor deca beq fingolpeo

bra inf2 fingolpeo ldd #$a000 std velocidad jmp comienzo


19

• Subrutina “controlejos”: En caso de que la medida supere un umbral de

lejanía, a partir del cual consideramos que la medida no es fiable, para mejorarla lo que hacemos es acercarnos la mitad de la distancia que suponemos en primera aproximación que nos separa del objeto y volvemos a medir, ahora basta con pasar esta medida a pasos y sumar los pasos que hemos dado y los que hemos medido, una vez hecho esto volvemos a pasarla a las unidades de medida que nos entrega el sensor.

dosbolas ldaa distancia staa disthex jsr convierte ldab distpasos ldaa #0 ldx #2 idiv xgdx stab temp tba jsr moverse ldaa #0 staa contmed bucledosbolas inc contmed jsr giradcha ldy #sensor2 jsr sense cmpa #0 bne bucledosbolas jsr giraizqda ldy #sensor1 jsr sense cmpa #0 beq erahoyo (CONTINÚA)

(CONTINUACIÓN) erabola ldaa distbola staa disthoyo ldaa distancia staa distbola bra saltar erahoyo ldaa distancia staa disthoyo saltar ldaa #10 staa motor ldaa temp bucleatras jsr movmotor deca bne bucleatras ldaa contmed bucleizq jsr giraizqda deca bne bucleizq jmp vueltadosbolas

controlejos ldaa distancia staa disthex jsr convierte ldaa distpasos cmpa #umbralejos bhi siguecontro ldaa distancia rts siguecontro tab ldaa #0 ldx #2 idiv xgdx tba staa temp jsr moverse (CONTUNÚA)

(CONTINUACIÓN) ldy #sensor2 jsr sense staa disthex ldaa #10 staa motor ldaa temp atras jsr movmotor deca bne atras jsr convierte ldaa temp adda distpasos staa distpasos jsr convierte2 ldaa disthex rts


20

• BUCLE PRINCIPAL: EL comportamiento del Microbot se muestra claramente

en el diagrama de flujo, comenzamos a girar hacia la derecha hasta que se encuentre el primer objeto, el modo de determinar si es la bola o el hoyo (chksense) es girar hasta que ya no encuentre nada y entonces mirar por el otro sensor de manera que si detecta algo es la bola (pues es de mayores dimensiones), hecho esto hemos de medir la distancia de un modo fiable como se comenta en la subrutina “medirdist”, después de esto acabamos centrados sobre la bola teniendo entonces que seguir girando hasta que ya no detectemos nada por el sensor exterior (despejar), en estos pasos ya si que hemos de comenzar a incrementar la distancia bola-hoyo, que medirá el ángulo en pasos que los separa, seguiremos girando e incrementando este parámetro hasta que demos con otro objeto (que habrá que, de nuevo, determinar su naturaleza) y en caso de ser el que no hayamos detectado aún seguir con el proceso de posicionamiento y golpeo (subrutinas posiciona y golpeo). Una vez que hemos dado una vuelta competa hemos de considerar 3 errores: que no encontremos la bola, el hoyo o ninguno de los dos, en el primer caso nos colocamos a 8 cm del hoyo y recomenzamos la búsqueda, pues la bola no puede estar a más de 80 cm , si no encontramos el hoyo cambiamos nuestra dirección, nos desplazamos y volvemos a buscar pues lo más probable es que la bola tape al hoyo.

inicio ldy #sensor1 jsr sense staa dist1 ;jsr mandarhex ;jsr espera ldaa dist1 bne sigue (1) jsr giraizqda (1) bra inicio sigue ldaa dist1 staa disthex jsr convierte (2) ldaa distpasos ;jsr mandarhex ;jsr espera ldaa distpasos cmpa #0 cmpa #umbralejos (3) ;bhi muylejos (4) ldy #encsens1 ;jsr mand_cad ;jsr espera ldy #sensor2 (5) jsr sense staa dist2 cmpa #0 bne chksense1 jsr giraizqda bra sigue2 (CONTINÚA)

(CONTINUACIÓN) despejar jsr giraizqda ldy #sensor1 jsr sense staa dist1 ldaa dist1 cmpa #0 bne despejar ldaa #0 (15) staa distbh jmp inicio todoenconh ldaa distbh staa distbh2 clr izqdcha ldaa distbh psha irbola jsr giradcha deca bne irbola com izqdcha pula staa distbh bra siguetodo todoenconb clr izqdcha siguetodo ldaa distbh staa distbh2 (16) jsr posiciona (17) (18)inf bra inf

(CONTINUACIÓN) chksense1 ldy #encsens2 ;jsr mand_cad ;jsr espera ldy #sensor1 jsr sense cmpa #0 staa dist1 bne esbola (6) eshoyo ldy #hoyo (7) ;jsr mand_cad ;jsr espera ldaa dist1 jsr medirdist (8) ldaa distancia staa disthoyo ldaa distbola cmpa #0 (10) bne todoenconh (13) ldaa #0 staa distbh (14) jmp inicio esbola ldy #bola ;jsr mand_cad ;jsr espera ldaa dist1 jsr medirdist ldaa distancia (9) staa distbola ldaa disthoyo cmpa #0 (11) bne todoenconb (12)(CONTINÚA)


21

3.- PRUEBAS: Las distintas pruebas que hemos ido realizando han ido paralelas al diseño del software, por lo que ha sido un proceso progresivo, y siempre pensando en el objetivo final, buscar ambos objetos e introducir la bola en el hoyo.

Las distintas fases por las que hemos ido pasando y pruebas que hemos ido realizando han sido:

1. Manejo de motores, en línea recta y giros: en primer lugar tuvimos que aprender a manejar los motores, por lo que comenzamos diseñando el Software necesario para conseguir moverlos; para esto diseñamos las secuencias que se encargan de ir activando las distintas bobinas, según sea el tipo de paso, como ya hemos descrito en la parte sobre el Hardware. Y una vez diseñadas estas secuencias comenzamos a probar distintos movimientos: hacia delante, hacia atrás, giros a derechas a izquierdas, giros con una sola rueda, moviendo ambas ruedas... (programa ‘Control’)

2. Manejo de sensores, medidas y calibración: una vez controlados los motores,

pasamos a aprender a manejar el otro elemento fundamental de nuestro diseño, los sensores. Para ello realizamos un programa a través del cual, usando el mcboot2, podemos saber las distintas medidas que va realizando el sensor. Y esto lo usamos para realizar la tabla de conversión de valores del sensor, presentada en la parte sobre el Hardware, con la que nuestro Microbot es capaz de conocer a que distancia se encuentran los objetos detectados por el sensor. (programa ‘Comunica’)

3. Detección de un objeto (girar hasta encontrar): una vez controlados ambos

elementos comenzamos a usarlos conjuntamente. La primera prueba que realizamos con ellos, pensando ya en la búsqueda de los elementos de juego es, hacer girar el Microbot hasta que consiga encontrar algo y que en ese momento pare de girar y se mantenga “mirando” dicho elemento.

4. Calcular distancia a un objeto y pararse justo en frente de este: hacemos que

el Microbot, situado en frente de un objeto, calcule la distancia (en pasos, que es lo que entienden nuestros motores, para ello primero hemos tenido que realizar una conversión desde el valor hexadecimal dado por el sensor a número de pasos) hasta este objeto y se mueva en línea recta hasta pararse justo en frente de este, ya que conoce la distancia que le separa de él.

5. Combinar 3 y 4: avanzando un poco mas en la misma línea que las pruebas

anterior, las combinamos. Hacemos que, el Microbot gire hasta encontrar un objeto y una vez encontrado dicho objeto, después de haber calcule la distancia hasta este, se mueva en línea recta hacia él y se coloque justo delante.


22

6. Rodear un objeto: otra prueba que nos va a hacer falta para nuestros objetivos

es conseguir que el Microbot consiga rodear un objeto, por si en algún caso tuviese que hacerlo para golpear la bola.

7. Golpeo de una bola: como no, para conseguir nuestro objetivo final, introducir

la bola en el hoyo, nuestro Microbot tendrá que golpear la bola. Por lo que una de nuestras últimas pruebas será conseguir que el Microbot golpee la bola en línea recta, calculando previamente la fuerza que necesita, esto será “tomando mas o menos carrerilla”, según retroceda mas o menos, podrá acelerar durante mas o menos tiempo, por lo que golpeará con mayor o menor fuerza.

8. Prueba final: ya lo único que nos quedará será combinar todas estas pruebas de

forma secuencial, para que nuestro Microbot consiga su objetivo.

Combinando todas estas pruebas ya conseguimos que nuestro Microbot realice nuestros objetivos: primero girará hasta encontrar un objeto, luego buscará el otro, una vez encontrados ambos, se dirigirá hacia la bola, la rodeará para situarse tras ella y la golpeará para introducirla en el hoyo.

Las pruebas, o sea el diseño de nuestros programas para conseguir solucionar todos estos problemas, no ha sido tan sencillo como aquí parece sino que, cada pequeño programa nos ha llevado tiempo de información sobre todos estos elementos y tiempo en el diseño del software, junto con muchas pruebas fallidas. Para la comprobación del funcionamiento, tanto de los sensores como de los motores, hemos desarrollado una serie de programas:

a) Control: permite realizar cualquier movimiento de los motores en cualquier dirección y sentido.

inicio ldaa #$05 staa motor staa motor bsr movmotor bsr delaylong bsr delaylong bsr delaylong bsr delaylong ldx #$6000 stx velocidad buclex ldab #3 ldd velocidad cpd #$2500 blt inf subd #$900 std velocidad bucle bsr movmotor decb bne bucle bra buclex inf bsr movmotor bra inf


23

b) Comunica: permite conocer el estado de las medidas de los sensores,

realizando diversas medidas y una vez encontrado un objeto se acercara hasta su posición, pudiendo así comprobar si ha realizado la medida correctamente.

Aparte de estos programas, dentro del código principal hemos incluido una serie

de programas que nos han ido permitiendo la depuración de errores en el código, mediante la comunicación con el Microbot a través del programa mcboot2. Estos subrutinas, básicamente, son:

a) Subrutina “espera”: espera a que el usuario presione una tecla antes de continuar con la ejecución normal del programa.

b) Subrutina “mandarhex”: presenta un número hexadecimal por pantalla.

espera ldab #$0c ldx #$1000 stab sccr2,x b_espera brclr scsr,x $10 b_espera ldx #$1000 ldab scdr,x ldab #0 stab sccr2,x

rts

mandarhex ldab #$0c ldx #$1000 stab sccr2,x bra sendhex sendc brclr scsr,x $80 sendc staa scdr,x rts tohex cmpa #$0a blt tohexn adda #55 rts tohexn adda #'0 rts

sendhex tab lsra lsra lsra lsra bsr tohex bsr sendc tba anda #$0f bsr tohex bsr sendc ldaa #' ' bsr sendc ldx #$1000 ldab #0 stab sccr2,x rts

inicio bsr sense ldy #actual jsr mand_cad ldaa dist1 jsr mandar jsr espera ldaa dist1 bne moverse jsr giraizqda bra inicio


24

c) Subrutina “mand_cad”: presenta por pantalla una cadena de caracteres.

mand_cad ldab #$0c ldx #$1000 stab sccr2,x ldaa 0,y iny cmpa #0 beq fin bsr enviar bra mand_cad fin ldx #$1000 ldab #0 stab sccr2,x rts


25

4.- CONCLUSIONES:

PROBLEMAS:

a) PROBLEMAS FÍSICOS Y MECÁNICOS:

La mayoría de los problemas mecánicos que hemos sufrido durante el desarrollo del Microbot han sido fruto de la nueva placa que hemos implementado para el control de los motores y sensores. En general los problemas han sido del tipo de malas conexiones, soldaduras que se sueltan y algún que otro error humano...

Algunos otros problemas que hemos tenido han sido relativos a las ruedas

del Microbot. Hemos tenido que sustituir la rueda trasera por una “rueda loca”, ya que la original no nos permitía realizar los giros de forma suave. Otro problema ha sido como conseguir unir las ruedas delanteras al eje de giro del motor, ya que este tiene un radio muy pequeño; al final la solución que hemos adoptado, es añadir una pieza que se ajusta al eje al final de este (pegándola), para conseguir que sea mas grueso y, sobre esta pieza “enroscar” las ruedas. Además teníamos el problema añadido de conseguir que ambas ruedas quedasen paralelas.

Relativo a los sensores, algunos de los problemas tenido han sido sobre su

colocación, que al final hemos colocado sobre una placa en el frontal del robot, pero el mayor problema ha sido conseguir que ambos sensores queden completamente paralelos, para que los rayos de los sensores no se crucen. Otro problema que hemos sufrido la rotura de unos de los sensores (se ha quemado), por lo que hemos tenido que modificar algunas partes de nuestro código por este motivo.

Respecto a la alimentación, tenemos el problema de la corriente que necesita

nuestro circuito. El Microbot absorbe unos valores próximos a 1.2 A, por lo que necesitamos tenerlo conectado a una fuente de alimentación mediante unos cables, ya que no podemos conseguir esta corriente con unas pilas o una batería. Esto nos da el problema de que los cables oponen resistencia al movimiento del Microbot y en algunos casos no le permiten moverse con soltura. Para esto colocaremos un soporte que mantenga los cables por encima del Microbot.

Otro problema es la distribución del peso del Microbot, la parte delantera

lleva la mayoría del peso (las tres placas, los sensores y la superficie de golpeo) y sobre la parte trasera no recae apenas peso, esto provoca un cierto desequilibrio en el movimiento del Microbot, para solucionarlo hemos fijado las tres placas lo mas próximo posible a la parte trasera y además hemos situado un pequeño peso en la parte trasera.


26

Con la zona de golpeo también hemos tenido problemas, en un principio el

Microbot golpeaba con la misma superficie donde se situaban los sensores, pero nos encontramos con el problema de que a la hora de golpear, la bola quedaba encajada con los sensores, por lo que tuvimos que añadir una nueva superficie, situada un poco por delante de la superficie de los sensores.

La elección de los drivers para el control de los motores y los sensores ha

sido otro problema. Al final hemos elegido el driver L293B para el control de los sensores y el ULN2803 para e control de los motores.

Otro de los problemas que hemos tenido, que podríamos considerar dentro de

los problemas mecánicos, ha sido poder encontrar los elementos necesarios para el desarrollo del proyecto, sobre todo en el caso de los motores y sensores, ya que no estaban disponibles en ninguna tienda malagueña y tras mucho buscar hemos conseguido que nos los envíen desde una tienda de Madrid. En menor medida hemos tenido problemas para encontrar otros elementos como las ruedas y algún otro elemento.

Probablemente el problema mecánico mas grave que hemos sufrido ha sido

cuando sin motivo aparente, la placa del microcontrolador ha dejado de funcionar. Esto nos ha acarreado el problema de no poder continuar durante un tiempo con nuestras pruebas y de tener que buscar nuevos componentes.

b) PROBLEMAS DE PROGRAMACIÓN:

PROBLEMAS DE CÓDIGO: En este apartado nos centraremos en los problemas que hemos encontrado

diseñando el código de nuestro robot, pero solo tendremos en cuenta los problemas específicos surgidos por el hardware nuevo utilizado y por la aplicación que se pretendía.

PUERTOS: El primer problema con el que nos encontramos fue la utilización de los

puertos. Como se comentará más adelante nos vimos obligados a utilizar una placa de memoria externa, por lo que inhabilitamos los puertos B y C. Con los bits de salida del puerto A no teníamos suficientes salidas por los que utilizamos el puerto D también como salida. Tuvimos que configurar por tanto los bits del puerto D como bits de salida pero además tuvimos que deshabilitar las transmisiones series y asíncronas así como configurar las salidas como salida CMOS en vez de colector abierto.


27

MOTORES: El primer problema que nos encontramos fue el control de los motores. Los

motores paso a paso siguen una secuencia predeterminada de activación de bobinas. Queríamos disponer de una subrutina que realizara un paso cada vez que fuera llamada. Además esa subrutina debía permitir hacer avanzar, retroceder, o mantener la posición de cada motor independientemente. La mejor forma que encontramos de controlar dichas secuencias fue guardar en posiciones de memorias consecutivas una tabla con los datos que habría que colocar en los puertos para ir activando las bobinas. Por tanto tendremos dos arrays, uno para cada motor, y una variable que me indica en que posición del array me encuentro. Esta variable consiste simplemente en un offset respecto a la posición original del array. Con esto el control de motores es bien sencillo y tan solo consiste en incrementar, decrementar o no alterar el índice y en colocar el dato que apunta el índice en el puerto correspondiente. Además la subrutina debe tener en cuenta que se tratan de arrays cíclicos y controlar los índices con ese fin. También debemos incluir en esta subrutina una llamada a una rutina de espera, ya que el tiempo que pasa entre paso y paso es el que determina la velocidad de giro y no puede demasiado pequeño ya que en esos casos el motor vibra y no se mueve.

SENSORES: Para la utilización de los sensores tuvimos que emplear el conversor

analógico/discreto del que dispone el microcontrolador. Para nuestra aplicación no era necesario que el robot realizara acción alguna mientras mide la distancia luego realizamos un bucle software esperando que el conversor terminase. Esta rutina no tuvo mayor complicación

CONVERSOR DE DISTANCIA A PASOS: Tras pasar por el conversor el dato que disponemos es un número

hexadecimal. Necesitábamos por tanto una subrutina que nos convirtiera ese numero en un dato que pudiéramos utilizar para controlar nuestro robot. Diseñamos por tanto una subrutina que convierte un número en hexadecimal a un dato q nos indica el número de pasos equivalente. La función consistía en una tabla de dos columnas. Para implementar esta función escribimos en posiciones consecutivas de memoria las parejas de distancia en hexadecimal y distancia en pasos de todas las medidas que realizamos experimentalmente. Después con un contador, que hará la función de índice vamos recorriendo la tabla hasta encontrar el valor en hexadecimal mas adecuado. Para saber la distancia en pasos tan solo teníamos que mirar el valor reservado en memoria en la posición justo siguiente.


28

RECONOCIMIENTO DEL ENTORNO: Esta es la parte principal del código. La mayor complicación con la que nos

encontramos es que en todo momento debemos saber la posición del robot. En realidad no queremos saber la posición absoluta sino la posición relativa respecto a dos puntos, el punto de partida y el punto en el que encontró un objeto. La solución es utilizar dos contadores que indiquen el número de pasos girados. Por tanto cada vez que el robot gira debe incrementar un contador, pero hay que tener en cuenta que en ocasiones gira en el sentido contrario y por tanto debe decrementar ese contador. El programa giro incrementa los dos contadores pero el que marca la distancia objeto-objeto solo tiene sentido a partir de que encontremos el primer objeto. Luego al encontrarlo reseteamos dicho contador y cuando encontremos el segundo objeto tendremos en esa variable el dato que queríamos. El problema de decidir si el objeto que encontramos es un hoyo o una bola no conlleva complicación en el código, una vez realizado el diagrama de flujos la implementación fue relativamente sencilla. La subrutina de centrar y medir distancia fue un poco más complicada. Teníamos que tener en cuenta que no siempre se iban a realizar el mismo número de medidas por lo que tuvimos que utilizar la pila para ir introduciendo las medidas. Después teníamos que cuidar de vaciar la pila antes de salir de la subrutina.

Donde encontramos mayores problemas fue al decidir la actuación del robot.

Para estimar las distancia que tiene que recorrer para colocarse detrás de la bola y en una posición “óptima” para el golpeo tuvimos que recurrir a la trigonometría. Esto conlleva funciones seno, tangentes, raíces cuadradas etc. Por mucho que quisieramos redondear nos vimos obligados a utilizar algún decimal, y por tanto tuvimos que recurrir a la aritmética en punto flotante. En la página oficial de motorla encontramos las rutinas en punto flotante de las operaciones básicas. La precisión utilizada era mucho mayor de la que necesitábamos y comenzamos a diseñar nuestras propias rutinas en punto flotante con tan solo un byte para mantisa y otro para exponente. Más adelante cuando nos vimos obligados a utlizar la memoria externa y ya no teníamos problemas de tamaño del código decidimos utilizar las rutinas tal y como estaban diseñadas. Más tarde nos dimos cuenta de que dichas subrutinas tenían algunos fallos y por tanto buscamos en otras páginas hasta encontrar unas rutinas que si funcionaban a la perfección. Estas últimas tienen una precisión muchísimo mayor de la que necesitábamos pero eso tampoco es un problema así que finalmente son las que hemos utilizado. Los cálculos realizados sobre los triángulos obtenidos de las mediciones nos requerían utilizar funciones seno y coseno. Como el ángulo es un número entero de pasos realizamos una tabla con todos los posibles valores para no tener que implementar la función seno. La función coseno la realizamos aprovechando su relación con el seno.


29

SIMULACIÓN Y DEPURACIÓN: Como tuvimos muchos problemas para encontrar los elementos hardware

que requeríamos quisimos empezar a simular nuestro código. Pare ello buscamos en muchas páginas web algún simulado del microcontrolador 69hc11 de motorola. Encontramos varios, casi todos para ms-dos, y finalmente decidimos utilizamos el “THRsim11 68hc11 simulator, ver. 3.3”. Con dicho programa simulamos y depuramos gran parte del código. Una vez que conseguimos todo el hardware comenzamos las pruebas en el Microbot. Para asegurarnos que el funcionamiento era correcto necesitábamos tener comunicación con el robot para así saber en todo momento en que parte del código se encontraba y que datos estaba entregando los sensores. Para ello implementamos unas cuantas funciones de comunicaciones básicas. Cargando el programa con el “mcboot2” conseguíamos visualizar por pantalla textos mandados por el micro y otros datos. Esto nos resultó imprescindible para descubrir los fallos que tenía el programa a enfrentarse a un entorno real.

USO DE LA MEMORIA EXTERNA: El uso de la memoria externa nos trajo complicaciones imprevisibles. En

realidad su utilización era muy sencilla y bastaba con cambiar la directiva org $0000 por org $8000 y cargar el programa con el “mcboot2” en memoria externa. Pero nos encontramos con que programas que funcionaban perfectamente en memoria interna al cargarlos en memoria externa dejaban de funcionar. En realidad seguían funcionando pero no realizaban exactamente lo que pretendíamos sino algo parecido. Tras muchas pruebas y consultas al grupo de microbótica descubrimos que la reserva de variables debían realizarse antes de la directiva org. En realidad nadie nos supo explicar realmente cual era el problema pero parece ser que de la otra forma las variables toman valores constantes que no pueden ser alterados.

La mayor parte del código dio problemas típicos de cualquier diseño. En

nuestro caso nos ha sido frecuente encontrarnos con los siguientes problemas: - Escasez de registros. El microcontrolador consta tan solo de 3 registros

de 2 bytes, por tanto es muy común que al llamar a una subrutina esta pise algunos registros perdiendo los datos que teníamos en ellos. Esto nos obliga a utilizar en muchas ocasiones la pila y variables auxiliares.

- Saltos fuera de rango. Al aumentar el tamaño del código los saltos que

anteriormente realizamos con “bra” dejan de ser posibles ya que el offset supera los 16 bits permitidos. El problema se soluciona fácilmente cambiando por comandos “jmp”. El problema surge en los saltos condicionales ya que no existen jmp condicionales. La solución conlleva a realizar estos saltos en mas de una sentencia y añadir etiquetas.


30

- Subrutinas generales. El deseo de utilizar subrutinas lo más generales

posibles, es decir, que puedan realizar distintas funciones en función de variables complica bastante el código. El resultado es un código más

compacto, mejor distribuido en módulos pero hace que las subrutinas sean en ocasiones difícilmente comprensibles.

- Variables globales. En nuestro código nos es imprescindible el uso de variables globales. El problema de estas variables reside en el hecho de que pueden ser alteradas en cualquier momento. Esto hace que haya que cuidar todas las subrutinas que son llamadas no alteren su valor cuando no deben. Nuestro código llegar a anidar varias subrutinas luego prestamos mucha atención en este aspecto.

- Inicialización de contadores. Problema típico al utilizar contadores en

subrutinas. Hay que cuidar muy bien donde inicializamos los valores de los contadores ya que puede que haya algunas subrutinas en las que sea necesario resetear los contadores en ciertas ocasiones pero no siempre.

Como hemos visto a la hora de diseñar nuestro código nos encontramos con

problemas causados tanto por la aplicación concreta de nuestro Microbot, como por las limitaciones del microcontrolador, como por el hardware utilizado. Las tácticas utilizadas para solucionar los problemas han sido tan variadas como los problemas que se nos han presentado. Muchas veces nos vimos obligados a aumentar el tamaño y complejidad del código, o aumentar el uso de variables. Otras intentábamos dividir el código en subrutinas que pudieran ser utilizadas con distintos objetivos. Hemos recurrido al uso de tablas y arrays en memoria, variables globales, paso de parámetros por memoria y utilizando la pila. Casi todos los recursos del que dispone el micro han sido utilizados, exceptuando interrupciones, así como la mayoría de las posibilidades del ensamblador. No hemos dudado en pedir ayuda en foros y a particulares (aunque también es cierto que no nos ha sido demasiado provechoso) y nos hemos aprovechado de herramientas de simulación y de la posibilidades de comunicación de las que dispone el micro para depurar y perfeccionar nuestro código. Aun así sabemos que se podría simplificar bastante y hacerlo más eficiente pero muchas veces nos vimos obligado a realizarlo tan complejo debido a los fallos hardware con los que nos encontrábamos continuamente.


31

CONCLUSIONES:

En nuestro diseño, para la implementación de nuestro Microbot, hemos utilizado una arquitectura atendiendo al esquema de la figura:

Hemos utilizado arquitectura reactiva para la percepción y modelado del entorno, sabemos que hay una bola , un hoyo y que no distan más de 80cm, pero a medida que tratamos de decidir en que posición de ellos nos encontramos con diversos problemas que habremos de solucionar, podemos por ejemplo encontrarnos objetos demasiado distantes y deberemos acercarnos para tomar medidas más fiables, o también podemos encontrar objetos repetidos teniendo que verificar nuestra imagen del entorno. Una vez reconocido el entorno en que nos movemos las reacciones obedecen totalmente a una arquitectura deliberada pues es del tipo : “moverse x pasos, girar α grados...” en este aspecto podemos decir que tenemos un nivel de ejecución muy claramente definido con subrutinas de manejo de motores, sensores que nos desinhiben de su complejidad y nos proporciona una base para el comportamiento deliberado.

La parte más complicada del código de debe al comportamiento

deliberado pues la actuación posterior no tiene más que acudir a la una serie de variables que determinan al completo su comportamiento mientras que en la parte reactiva hemos de estar observando el entorno continuamente y verificando que se cumplan condiciones etcétera, es por esto que hemos diseñado un entorno bastante sencillo, pequeñas complicaciones en el entorno causan complicaciones mucho más abultadas en el código, podemos por ejemplo ampliar el campo de juego, una pequeña dificultad que supondría estar desplazándonos por el escenario teniendo posiblemente que esquivar el otro objeto o que realizar rutinas de inspección más sistemáticas, sin embargo una vez construida la imagen del escenario de actuación las rutinas a ejecutar no se complican ni si quiera en la misma medida que el escenario pues la actuación ya está previamente definida.


32

Por tanto una vez creadas las subrutinas que nos facilitan el manejo de

recursos podemos proponer otros escenarios más complicados para posteriores prácticas sin necesidad de comprender el funcionamiento de los dispositivos hardware añadidos al Microbot, bastará con definir una serie de interfaces a las funciones ya creadas y, eso sí, el conocimiento por parte del alumno del funcionamiento del microcontrolador y la disposición de los recursos en los puertos. MEJORAS POSIBLES: En nuestro diseño, hemos conseguido que el Microbot realice la parte básica del juego, introducir la bola en el hoyo, una situación, comparándola con la realidad, como si el jugador estuviese en el “green”. Una posible línea para continuar con este diseño sería, hacer el juego un poco mas real, esto es, podríamos realizar un campo de juego similar a los reales, añadiendo obstáculos (“banquers”, lagos, árboles...) de forma que el Microbot los tuviese que localizar, detectar y saber como actuar ante ellos (golpeando con mayor fuerza, esquivándolos...); también podríamos diseñar un campo de juego más grande y con forma irregular, de forma que el Microbot tuviese que realizar varios golpes de acercamiento a la bandera, en el caso en el que no lo pudiese encontrar, estuviese muy lejos o no estuviese en línea recta con ella... y luego, una vez situado próximo al hoyo, continuase con la parte del diseño ya realizada. Otra mejora que podríamos añadir es, la capacidad de poder jugar un partido contra un oponente. Podríamos programar dos Microbots que fuesen capaces de interactuar en el campo de juego, sabiendo que tienen que golpear una vez cada uno, de forma alternada, que fuesen capaces de ir llevando el tanteo del partido y saber quien es el ganador del juego.

RESUMEN FINAL

Desde que se entregó la memoria hasta que se realizó la prueba del microbot se han realizado una serie de mejoras dirigidas sobre todo a posibles fallos en la detección o a un mayor radio del campo de juego, en cuanto a los posibles errores de detección se ha contemplado un posible paso desapercibido del hoyo, pues debido a su estrechez es posible que entre un paso y el siguiente rebasemos el hoyo, otro caso posible de error es confundir la bola con el hoyo o viceversa, también se han contemplado situaciones complejas como que un objeto nos impida la visión del otro, el error se detecta si hemos dado una vuelta y todavía no hemos encontrado uno o ningún objeto, comentamos ahora más detalladamente el comportamiento en estos casos:

• Sólo se detecta el hoyo: Este caso se puede dar porque nos encontremos en un extremo del campo y la bola en el otro, lo que puede hacer que pase desapercibida entre un paso y el siguiente o que el hoyo nos tape la visión. En este caso nos colocamoe en la posición del hoyo, lo que nos hace colocarnos a, como máximo, 40 cm de la bola por lo que desde esta posición la bola debería ser detectada, una vez detectada nos acercamos a ella, la rodeamos, y golpeamos.

• Sólo se detecta la bola: Este caso se puede dar si el hoyo ha pasado desapercibido o que sea tapado por la bola, en esta situación no colocamos mirando a ella, nos centramos, giramos 45º y andamos el doble de la distancia que nos separa de ella, de esta manera si la bola nos tapaba la visión del hoyo el problema queda solucionado

• Detectamos dos bolas: Este problema sólo se puede producir por un error de los sensores, nos damos cuenta del error en cuanto detectamos el segundo objeto y decidimos que es una bola habiendo ya encontrado otra, la solución es fácil, nos acercamos la mitad de la distancia que nos separa de este último objeto y lo recatalogamos, intercambiando entonces las medidas de distancia hasta la bola o el hoyo si fuese necesario. Una vez tomada la decisión desde una mejor posición nos recolocamos en la posición donde habíamos errado y continuámos con la rutina normal.

Hemos tenido nuevos problemas que merecen ser comentados, por ejemplo tras ver

que obteníamos comportamientos relativamente aleatorios en distintos momentos sin relación aparente y sabiendo que todos los componentes hardware funcionaban correctamente pensamos que la alimentación no era correcta, y hasta cierto punto era correcta nuestra suposición pues la alimentación, en la fuente, si era correcta pero no

ocurre lo mismo en el extremo del cable de alimentación que nos llega al microbot pués es un cable de longitud considerable y durante bastante tiempo la corriente que pasa por el sobrepasa el amperio, con lo que se producía una caída en la tensión con la que alimentámos todo nuestro sistema que hacía que la memoria externa no funcionase tan bien como debiese, tras solucionar este problema comenzamos a obtener comportamientos razonables.

Otro problema que detectamos en estas últimas pruebas fue que los sensores no sólo entregaban pequeñas medidas espúreas (lo que solucionamos estableciendo un umbral de fiabilidad), sino que para que una medida que sobrepase el umbral se comprueba hasta por cinco veces antes de ser aceptada pues los sensores entregaban medidas erróneas de mayor consideración con cierta frecuencia. Una vez decido que la medida es válida no es bastante para determinar la distancia hasta el objeto, pues éste puede que no sea perpendicular a nosotros los que no podemos solucionar con estas medidas, para ello tomamos todas las medidas que nos ofrece el objeto girando y apilando otras medidas de las cuales tomaremos las que se encuentren en la mitad de ella y haremos una media de estos valores. Pero no son estas todas las peculiaridades de los sensores sino que a partir de cierta distancia las medidas arrojan muy poca precisión, ante esta situación nos tenemos que acercar a los objetos y tomamos una nueva medida. Ahora desde más cerca podemos determinar la medida de manera mas fiable y sumarla a la que nos hemos acercado, esta suma se ha de hacer en las unidades que nos movemos con el motor y luego reconvertirla a unidades que nos entrega la digitalización de la señal del sensor (pues al no seguir una escala lineal no pueden ser sumados directamente).

Los motores no fueron una excepción en cuanto a ser fuente de problemas, pues su

manejo ha requerido el uso de tablas para ir entregando una secuencia correcta a los motores, y para desplazarnos por esta hemos requerido un puntero que se desplace de forma cíclica por ella; tampoco ofrecen la precisión que se podía desear para nuestro objetivo pues un paso nos hace girar más de lo que es conveniente. Tampoco la velocidad máxima que ofrece el motor es suficiente para hacer un golpeo eficiente de la bola, lo que sí hemos conseguido es que nuestro microbot no patine en ningún momento pues podemos controlar de manera eficiente la aceleración. Además recordamos que no es posible comenzar el movimiento con la velocidad que deseemos, sino que debemos comenzar con una velocidad reducida e ir acelerando. Esto nos obliga a alejarnos del objeto antes de golpear lo que también trae complicaciones.

El problema principal que se nos ha presentado a la hora de diseñar el código ha

sidio la ausencia de una herramienta de depuración eficiente, pues la que usamos en un

principio (THRSIM 11) no es capaz de simular más de 512 bytes de código y nuestro código ha teminado ocupando alrededor de 3 Kbytes, esto nos ha hecho tener que acudir a otras herramientas en principio no ideadas para este fin, sino para simples comunicaciones con el microcontrolador (MCBOOT 2), con este programa y mediante unas subrutinas que ideamos para poder depurar nuestros programas pudimos ir avanzando en nuestro diseño. El uso en ciertas operaciones trigonométricas de operaciones con decimales nos obligó a usar subrutinas de punto flotante lo que aumentó considerablemente las dimensiones de nuestro código.

A la hora de reconocer el entorno nos hemos encontrado con muchos problemas.

Empezando con los objetos a elegir. Por ejemplo hemos utilizado dos sensores para ayudarnos a decidir sobre si el objeto localizado es un hoyo o una bola. Hay que tener en cuenta que las medidas realizadas en los bordes de los objetos no son de fiar y hay que buscar el punto medio. Las medidas demasiado cercanas tampoco son válidas luego tenemos que evitar estas situaciones. También tenemos que utilizar subrutinas que nos despejen lo que estamos viendo para continuar las medidas y no localizar dos veces el mismo objeto. Los casos problemáticos los describimos arriba pero también hay que añadir casos en los que se detecta todo perfectamente pero la localización de los objetos hace complicados los golpeos, por ejemplo cuando el robot tiene que caminar en línea recta mucha distancia o los ángulos entre distancia y bola son muy pequeños o en torno a 180º. Continuamente nos vemos obligados a centrarnos en los objetos que nos encontramos para considerar las medidas válidas. Hay que destacar la complicación que conlleva contar los pasos que va girando el robot, datos que utilizaremos para determinar la actuación y para detener la exploración. Teniendo en cuenta la cantidad de giros que se van realizando a ambos lados es difícil controlar los contadores.

Hasta hora hemos obviado otros problemas que se alejan un poco de la asignatura

pero que a veces han sido los más importantes. Por ejemplo la dificultad de encontrar los sensores y los motores adecuados, teniendo que acudir a tiendas en Madrid. Sin comentarios sobre la cantidad de dispositivos que se han quemado, microprocesadores, memorias externas, sensores, circuitos integrados; innumerables problemas pare encontrar la disposición de los motores, las ruedas, y la forma de encajar las ruedas con los ejes. Problemas incomprensibles de código, que todavía no entendemos, pero que hemos conseguido solucionar de una manera u otra. Todo esto nos ha convencido de la complejidad que puede alcanzar el problema inicial propuesto y nos hace sentirnos más que satisfechos con los resultados obtenidos.

práctica de laboratorio de sistemas digitales. microbot tritt

Documents