Introducci´ on a la rob´ otica basada en comportamientos Segundo Cuatrimestre de 2004
Departamento de Computaci´on Facultad de Ciencias Exactas y Naturales Universidad de Buenos Aires
Trabajo Pr´ actico Final P´endulo Invertido
Integrante
LU
Correo electr´onico
MORELLI ANDRES, Ariel
090/01
[email protected]
SOULIGNAC, Francisco
796/00
[email protected]
SUEIRO, Gabriel
204/01
[email protected]
´INDICE
2
´Indice 1. Introducci´ on 1.1. Descripci´on del problema a resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. En qu´e consiste el trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Construcci´ on del robot 2.1. Pruebas preliminares 2.2. Dise˜ no . . . . . . . . 2.3. El Chasis . . . . . . 2.4. Las Ruedas . . . . . 2.5. El Motor . . . . . . 2.6. El Encoder . . . . . 2.7. La placa del circuito 2.8. El eje y el p´endulo . 2.9. Cambio de motor . . 2.10. Redise˜ no del robot .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
4 4 4 5
. . . . . . . . . .
6 6 6 7 8 8 8 9 9 11 11
3. Descripci´ on del circuito electr´ onico del robot 3.1. Encoder y Pulsadores . . . . . . . . . . . . . . 3.2. Velocidad del Motor y Sentido de Marcha . . . 3.3. Comunicaci´on con la computadora . . . . . . . 3.4. Reguladores de Tensi´on . . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
13 13 13 14 14
4. Armado del Circuito 4.1. Inconvenientes encontrados y sus soluciones . . 4.1.1. El Microcontrolador no Oscila . . . . . 4.1.2. El Microcontrolador no Oscila 2 . . . . 4.1.3. El motor no funciona . . . . . . . . . . . 4.1.4. El motor va lento y el regulador calienta 4.1.5. El motor funciona en un solo sentido . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
14 14 14 14 15 15 15
5. Programa del Microcontrolador PIC16F73 5.1. Compilador . . . . . . . . . . . . . . . . . . . . . . 5.2. Descripci´on del programa del microcontrolador . . 5.2.1. Protocolo de la primera versi´on . . . . . . . 5.2.2. Decisiones tomadas para la primera versi´on 5.2.3. Inconvenientes encontrados . . . . . . . . . 5.2.4. Decisiones tomadas para la segunda versi´on 5.2.5. Protocolo de la segunda versi´on . . . . . . . 5.3. Programador . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
16 16 16 16 16 17 18 18 18
6. Implementaci´ on del programa de la PC 6.1. Protocolo de comunicaci´on . . . . . . . . 6.2. Algunas definiciones u ´tiles . . . . . . . . 6.3. Acciones del Robot . . . . . . . . . . . . 6.4. Estados del robot . . . . . . . . . . . . . ´ 6.4.1. Angulo . . . . . . . . . . . . . . 6.4.2. Velocidad Angular . . . . . . . . 6.4.3. Velocidad del motor . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
19 19 20 20 20 20 20 21
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
´INDICE
6.4.4. Comparaci´on con simuladores 6.4.5. Posici´on . . . . . . . . . . . . 6.5. Pol´ıtica inicial . . . . . . . . . . . . . 6.6. Estrategia de exploraci´on . . . . . . 6.7. Funci´on de refuerzo . . . . . . . . . .
3 . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
21 21 22 22 22
7. Aprendizaje 7.1. Experimentos . . . . . . . . . . . . . . . . . . 7.1.1. Experimento 1 . . . . . . . . . . . . . 7.1.2. Experimentos de cambio de ambiente 7.2. Resultados . . . . . . . . . . . . . . . . . . . . 7.2.1. Ejecuciones fallidas . . . . . . . . . . . 7.2.2. Primera ejecuci´on del simulador . . . 7.2.3. Primera ejecuci´on del robot . . . . . . 7.2.4. Segunda ejecuci´on del robot . . . . . . 7.2.5. Mas ejecuciones del simulador . . . . . 7.2.6. Tercera ejecuci´on del robot . . . . . . 7.2.7. Ultima ejecuci´on del robot . . . . . . . 7.3. Discusi´on de los resultados . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
23 23 23 23 23 23 24 24 25 26 28 28 30
8. Conclusiones A. Mini-framework de aprendizaje A.1. Requerimientos del framework . . . . . . A.2. Decisiones de dise˜ no . . . . . . . . . . . A.2.1. Algoritmo de aprendizaje . . . . A.2.2. Pol´ıtica . . . . . . . . . . . . . . A.2.3. Sensado de estados . . . . . . . . A.2.4. Ejecuci´on de acciones . . . . . . A.2.5. Definici´on de Acciones y Estados A.2.6. Guardar y cargar aprendizajes . A.2.7. Comunicaci´on con el robot . . . A.2.8. Archivo de configuraci´on . . . . .
32
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
33 33 34 34 34 35 35 36 36 36 36
B. Diagramas del Circuito
37
C. C´ odigo del programa del microcontrolador
39
´ 1 INTRODUCCION
1.
4
Introducci´ on
En este informe contaremos nuestra experiencia en la fabricaci´on de un robot que tiene por objetivo mantener un p´endulo invertido. Nuestro trabajo puede dividirse en cuatro etapas bien marcadas: la fabricaci´on de la parte mec´anica, la parte electr´onica, el programa de aprendizaje y la ejecuci´on del aprendizaje. En cada una de esas etapas tuvimos que planificar el trabajo, realizarlo y experimentar. Luego de experimentar hab´ıa que resolver los problemas suscitados y volver a realizar una iteraci´on de la construcci´on. Este informe lo estructuramos con una secci´on para cada una de las etapas, en la que explicamos en forma cronol´ogica cuales fueron nuestras soluciones iniciales, qu´e problemas surgieron y c´omo los resolvimos (cuando pudimos resolverlos). Antes de continuar con el informe propiamente dicho, vamos a recordar lo que escribimos al presentar el abstract del trabajo. Esto nos permitir´a tomar conclusiones al final del informe sobre el verdadero avance del trabajo, y verificar el cumplimiento de los objetivos que nos hab´ıamos planteado. Esto se detalla en las siguientes tres subsecciones.
1.1.
Descripci´ on del problema a resolver
El problema del P´ endulo Invertido tiene un robot que pude moverse en l´ınea recta en ambos sentidos. En la parte superior del mismo, tiene un p´endulo que posee un grado de libertad (es decir, tiene movilidad en solo una de las dimensiones del espacio) y puede tomar cualquier a´ngulo entre 0 y 180 grados con respecto al techo del veh´ıculo. (Ver figura 1) El objetivo del robot es que el p´endulo no tenga nunca un a´ngulo llano y para esto el robot tiene que moverse de forma “adecuada”. Como restricci´on adicional, el robot no podr´a desplazarse afuera de un segmento previamente fijado, el cual se encuentra delimitado por dos obst´aculos en los extremos del mismo. En el momento inicial, el robot se encuentra en el medio de la zona delimitada por los obst´aculos y el p´endulo del mismo se encuentra en posici´on vertical.
Figura 1: Esquema del robot
1.2.
Objetivos
A lo largo de la materia, en la realizaci´on de los trabajos pr´acticos, utilizamos un simulador y eventualmente probamos el trabajo en el robot Khepera. M´as all´a de los problemas iniciales de conexi´on entre el simulador y el robot, los resultados en la experimentaci´on con el robot no resultaron muy distantes de lo esperado. No tuvimos mayores inconvenientes, pues el robot funcionaba correctamente y adem´as el mismo fue cuidadosamente dise˜ nado por gente experta en el tema. Nosotros, proponemos entonces hacer un trabajo que involucre todas las etapas. Desde el dise˜ no del robot, pasando por la construcci´on del mismo y por u ´ltimo programaci´on de este. Creemos que un
´ 1 INTRODUCCION
5
proyecto integral, nos ayudar´a a afianzar los conocimientos adquiridos, ponerlos en pr´actica y aprender algunas cosas nuevas.
1.3.
En qu´ e consiste el trabajo
El trabajo consta de varias etapas. La primera de ellas es hacer un dise˜ no del robot, en el cual evaluaremos la forma de resolver las cuestiones mec´anicas y electr´onicas del mismo. Entre otras cosas, analizaremos cuantos sensores y de que tipo deber´a poseer el robot para desempe˜ nar su tarea correctamente y de que forma se conectar´an los mismos al microcontrolador del robot. Una vez determinado eso, estaremos en condiciones de elegir el microcontrolador que se adapte a las necesidades Una vez concluida la etapa del dise˜ no, procederemos a la construcci´on del robot. Calculamos que a medida que vayamos armando el mismo, nos iremos encontrando con diversos problemas que no consideramos en la etapa del dise˜ no y en consecuencia iremos modificando el dise˜ no para superar dichos obst´aculos. Por u ´ltimo, mediante la t´ecnica de aprendizaje por refuerzo intentaremos que el robot aprenda un comportamiento que le permita cumplir con su objetivo (evitar que el p´endulo quede en posici´on horizontal, sin llegar a los extremos de su recorrido.) Luego de implementar el algoritmo evaluaremos cu´anto tiempo (en cantidad de episodios) demora el robot en aprender a mantener el p´endulo invertido en los limites establecidos por m´as de una cierta cantidad de tiempo prefijada de antemano. Tambi´en evaluaremos cu´anto tiempo demora el robot en readaptar el comportamiento cuando cambian las condiciones de velocidad y de espacio.
´ DEL ROBOT 2 CONSTRUCCION
2.
6
Construcci´ on del robot
En esta secci´on detallamos como se realiz´o la construcci´on del robot. Teniendo en cuenta que el dise˜ no del robot fue cambiando a medida que lo fuimos haciendo, nos pareci´o buena idea describir la construcci´on en forma cronol´ogica. De esta forma podemos escribir lo que fuimos pensando, las pruebas que hicimos y c´omo afectaron las decisiones que fuimos tomando y los cambios que fuimos haciendo.
2.1.
Pruebas preliminares
Antes de hacer el dise˜ no del robot hicimos algunas pruebas, especialmente relacionadas al motor que ´ıbamos a usar. Pudimos conseguir distintos motores, la mayor´ıa provenientes de autos de juguete. Hicimos pruebas de fuerza y velocidad con cada uno de ellos. Llegamos a la conclusi´on de que era imposible colocar una transmisi´on directa entre el motor y las ruedas, ya que ning´ un motor ten´ıa suficiente fuerza para funcionar de esa forma. Pensamos entonces en utilizar 2 engranajes para hacer la transmisi´on: uno en el eje de las ruedas y otro en el eje del motor. Teniendo en cuenta esto u ´ltimo buscamos un par de ruedas que ya tuvieran un engranaje colocado. Por suerte pudimos encontrarlas en un autito de juguete. Ya que la fuerza del motor era uno de los limitante utilizamos un motor que nos pareci´o adecuado en tama˜ no y que fuera suficientemente fuerte. Para el engranaje del motor no pudimos usar uno com´ un, ya que, por la forma del motor, luego tendr´ıamos problemas para la instalaci´on del motor. Tuvimos que usar un engranaje helicoidal, que permite que el eje del motor est´e en posici´on perpendicular al eje del las ruedas. Adem´as, este engranaje multiplica mucho m´as la fuerza del motor que un engranaje com´ un.
2.2.
Dise˜ no
Para comenzar hicimos un dise˜ no preliminar del robot. Al hacer este dise˜ no tomamos algunas decisiones que orientaron el desarrollo de todo el proyecto. Por ejemplo, nos permiti´o tener una idea de la forma que ten´ıamos que darle el robot, c´omo iba a ser la placa electr´onica y d´onde iban a estar ubicados los distintos elementos del robot. Algo a tener en cuenta es que los componentes principales que integrar´ıan el robot fueron decididos con anticipaci´on a su construcci´on. Estos componentes son: las ruedas, el motor, el encoder, los pulsadores, el eje del p´endulo y el p´endulo. Esencialmente el robot constar´a de dos partes: una superior y una inferior. Cada parte es una chapa plana con los elementos montados sobre la misma (Ver Figuras 2 y 3 para un detalle del dise˜ no). Las dos partes se unir´ıan mediante 4 tornillos largos, uno en cada esquina.
6.000 cm
Eje del motor
Motor
Placa del circuito de control
Chapas sujetadoras de las ruedas. Eje de las ruedas
Engranaje
Ruedas
16.000 cm
Figura 2: Plano de la parte inferior del robot
´ DEL ROBOT 2 CONSTRUCCION
7
Eje del pendulo
6.000 cm
Soporte angular
Placa del encoder
Encoder
16.000 cm
Figura 3: Plano de la parte superior del robot
2.3.
El Chasis
El chasis consideramos primero hacerlo de aluminio. Pero las planchas de aluminio con las que cont´abamos eran demasiado finas y pensamos que iban a doblarse con el peso del motor y de los dem´as elementos. Optamos por hacerlo de chapa galvanizada. Marcamos la forma de las chapas (superior e inferior) con un punz´on y las cortamos usando una caladora. El rect´angulo por donde pasar´ıa el engranaje de las ruedas lo cortamos haciendo primero unos agujeros con la agujereadora, suficientes como para poder luego entrar con la caladora y poder terminarlo. Incluimos los planos detallados del chasis (Figura 4).
6.000 cm
3.000 cm
Rectangulo para el engranaje
6.000 cm
16.000 cm
Figura 4: Chasis del robot
´ DEL ROBOT 2 CONSTRUCCION
2.4.
8
Las Ruedas
Instalamos en el robot el par ruedas descriptas en la secci´on “Pruebas Preliminares”. Tratamos de asegurar que las ruedas pudieran moverse libremente y con el menor rozamiento posibles. Par ello, las afirmamos al chasis utilizando chapas con un pozo en forma de “u” que se adaptara a la forma cil´ındrica de los ejes (Ver Figura 5)
Figura 5: Chapa de aluminio para afirmar las ruedas Los agujeros para los tornillos de las chapas los hicimos con forma ovalada. Eso nos permiti´o ajustar la direcci´on de cada uno de los ejes, para lograr que quedaran paralelos. Estas chapas las hicimos de aluminio para poder darle la forma que dese´abamos f´acilmente. Para hacer la hendidura con la forma del eje colocamos cada chapa sobre el borde superior de una morsa ligeramente abierta. Luego colocamos el eje sobre la chapa (haciendo que coinsida con abertura de la morsa) y golpeamos el eje con un martillo. La abertura de la moza era apenas un poco m´as grande que el di´ametro del eje. De esta forma, a medida que golpe´abamos el eje, ´este y la chapa se fueron hundiendo en la abertura de la morsa, hasta que el eje qued´o apenas por debajo del nivel del borde la morsa.
2.5.
El Motor
El motor que utilizamos fue el que elegimos en las pruebas preliminares. El cuerpo del motor ten´ıa forma de cilindro. Entonces, para instalarlo, utilizamos una chapa de aluminio curva, que envolviera al motor y se fijara por sus extremos al chasis (Ver Figura 6). Vista frontal
Vista superior
Vista Perspectiva
Figura 6: Chapa de fijaci´on del motor Para hacer la chapa, primero cortamos una tira de aluminio de m´as o menos el ancho del motor. Luego la presionamos contra el motor para que tomara una forma cil´ındrica. Intercalamos una l´amina de goma entre el motor y esta chapa para que quede bien afirmado y no llegara a girar el tambor. Para que el engranaje del motor haga contacto con el engranaje de las ruedas tuvimos que elvar el motor un poco por encima de la chapa del chasis. Para lograrlo colocamos el motor sobre unas l´aminas de goma, que permitieron levantar el motor hasta la altura deseada (Ver Figura 7).
2.6.
El Encoder
El encoder que utilizamos lo sacamos de un mouse de computadora. Nos pareci´o buena idea dejar el encoder en la placa del mouse, ya que si lo pas´abamos a otra superficie tendr´ıamos que haber ajustado la posici´on relativa de las distintas partes del encoder. Consideramos que necesitar´ıamos acomodarlas con demasiada precisi´on y por eso preferimos no hacerlo. Quitamos todos los otros componentes de la
´ DEL ROBOT 2 CONSTRUCCION
9
Engranaje del motor Motor
Engranaje de las ruedas
Chasis
Soportes de goma
Figura 7: Corte lateral de la trasmisi´on entre los engranajes
placa del mouse, dejando solo el encoder. Los cables que conectamos al encoder los soldamos en unos agujeros de la placa que pertenec´ıan a otros componentes. Estos componentes se conectaban con las distintas partes del encoder a trav´es de pistas en la placa. De esta forma los cables quedaron conectados al encoder sin necesidad de estar soldados directamente al encoder. Y as´ı tambi´en pudimos mantener las soldaduras originales del encoder en la placa del mouse. Eje
Receptores
Rueda con ranuras
Emisores
Figura 8: Vista superior de las partes del encoder Para afirmar la placa del encoder al chasis lo apoyamos sobre unas l´aminas de goma, tanto para evitar que se produzcan cortocircuitos como para lograr que el eje del encoder no quede tan cerca del nivel de la chapa. La placa y las laminas de goma los fijamos al chasis con tornillos
2.7.
La placa del circuito
Para instalar la placa simplemente hicimos algunos le agujeros y la afirmamos con tornillos. Para que quede levantada y no toque el chasis pusimos unos bujes de pl´astico en los tornillos (Ver Figura 9). A la placa le llegaban varios cables (alimentaci´on y comunicaci´on con el puerto serie). Intentamos usar los cables m´as flexibles que encontramos. Para el cable del puerto serie usamos el cable del mouse que hab´ıamos desarmado. Para los cables de alimentaci´on, que eran 3, simplemente usamos cables comunes.
2.8.
El eje y el p´ endulo
Para afirmar el eje utilizamos soportes angulares hechos de aluminio. Cada soporte ten´ıa un agujero para que pase el eje y un agujero para el tornillo que lo afirmaba al chasis. Para construir los soportes simplemente cortamos una tira de aluminio, la doblamos a 90 grados y hicimos los 2 agujeros. El
´ DEL ROBOT 2 CONSTRUCCION
10 Placa
Buje
Tornillo
Chasis
Tuerca
Figura 9: Acople entre la placa y el chasis
agujero por donde pasar´ıa el eje lo hicimos a la misma altura que el eje del encoder, para luego poder acoplar los dos ejes. Para reducir la fricci´on del eje con los soportes angulares pasamos un buje por el agujero del soporte. El buje lo fijamos con poxipol. Para ver un esquema del soporte ver la Figura 10. "! Buje "! "! "! "! Figura 10: Soporte para el eje del p´endulo Para que el eje no se moviera lateralmente le colocamos unas tuercas dobles a cada lado de los soportes. Pare ver un esquema del montaje del p´endulo, referirse a la Figura 11. Pendulo Eje
Encoder
Tuercas
$$
%% &%% & $ ' ( ' ( ' ( ' ( ' ( ' ( ' ( ' ( ' #$# ( ' ( ' ( ' ( ' ( ' ( ' ( ' ( ' ( ' ( ' & ' &&% ( ' ( ' (' ( %% ( & & # % &%&% & # Buje
Chasis
Soporte
Contrapeso
Figura 11: Diagrama del montaje del p´endulo Probamos varios posibles p´endulos antes de quedarnos con el definitivo. Primero probamos con una varilla de metal agujereada. Lamentablemente era demasiado pesada y se ca´ıa muy r´apido. Luego probamos con una varilla hecha de telgopor, pero segu´ıa cayendo muy r´apido. Pensamos en agregarle una hoja de papel a la varilla para que la resistencia con el aire hiciera que cayera m´as lento. Esta modificaci´on fue muy efectiva, ya que redujo considerablemente la velocidad de ca´ıa. Luego reemplazamos la varilla de telgopor por una de alambre, lo cual nos permiti´o agarrarla mejor al eje. Por u ´ltimo agregamos al eje un contrapeso hecho plomo, para que redujera el momento angular de la varilla y al robot le sea m´as f´acil enderezar la varilla. Todas estas mejoras para lograr que la varilla cayera m´as lento fueron necesarias porque en las sucesivas pruebas vimos que la velocidad del motor no era suficiente como para lograr enderezarla.
´ DEL ROBOT 2 CONSTRUCCION
2.9.
11
Cambio de motor
A pesar de todos nuestros esfuerzos, en las pruebas que hicimos seguimos viendo que la velocidad del motor no era suficiente como para mantener la varilla. Decidimos entonces cambiar el tipo de tracci´on. Por eso, cambiamos el tipo de engranaje del motor. En vez hacer una transmisi´on con un engranaje helicoidal, utilizamos un engranaje com´ un (Ver Figura 12). Por la forma del motor que est´abamos usando, no pod´ıamos ubicarlo de forma paralela al eje de las ruedas, y por lo tanto no pod´ıamos ponerle un engranaje com´ un. Tuvimos entonces que cambiar el motor. Tambi´en huvieron otros motivos de ´ındole el´ectrico para cambiar el motor (Ver la secci´on 4.1.3). Soporte angular Engranaje del motor
- .. Motor
* * * , + , + , + , + , + , + , + , + ,+ + , + , + ,+ , + , + , + , + , + , + , + ,+, + )*) , + , + , + ,+ , + , + , + , + , + , + , + ,+, + ) , + , + , + ,+ , ) Engranaje de las ruedas
Figura 12: Corte lateral de la trasmisi´on entre los engranajes Para afirmar el nuevo motor utilizamos un soporte angular hecho de aluminio. El soporte lo sujetamos al chasis con 2 tornillos. El motor lo fijamos al soporte con otros 2 tornillos. A parte del aujero para que pase el eje del motor, le hicimos un agujero para que pueda pasar por ah´ı el eje de las ruedas (Ver Figura 13). Motor
Tornillos
Agujero para el eje
Figura 13: Vista frontal del soporte angular y el motor
2.10.
Redise˜ no del robot
Lamentablemente el cambio del motor no fue suficiente. La nueva transmisi´on que le colocamos hizo que al motor no le alcance la fuerza para mover al robot con suficiente velocidad. Decidimos entonces redise˜ nar el robot teniendo como objetivo la reducci´on su peso. Lo primero que decidimos fue sacar la placa de control del robot. Lo segundo, fue eliminar la chapa superior. Estas dos modificaciones fueron las m´as importantes. Al eliminar la chapa superior, pasamos el encoder y el p´endulo a la parte inferior. Pero la chapa inferior no era lo suficientemente larga como para tener todos estos elementos. Tuvimos entonces que rehacer el chasis. Una vez que la rehicimos, simplemente afirmamos todos los elementos que ya ten´ıamos hechos (ruedas, motor, encoder, pulsadores y p´endulo); no fue necesario rehacer o modificar ninguno. Incluimos el plano del nuevo dise˜ no del robot (Ver Figura 14).
´ DEL ROBOT 2 CONSTRUCCION
1 21 21 21 2112 1 2 2 2 2 1 11 11 1221 21 2 2 2 1 1 1 1 1 21 2 2 1 1 1 2222 2212
12 Soporte angular
5 65 65 65 6556 5 6 6 6 6 5 55 55 5665 65 6 6 6 5 5 5 5 5 65 6 6 5 5 5 6666 6656
Eje del pendulo Motor Placa del encoder
33434343434343 4
Eje del motor
Engranaje de las ruedas
/ / / / /0 0 0 0 0 / / / / 0/ 0 0 0 / / / / / 0/ 0/ 0/ 00/0/ 0 0 0 0 0 /0 /0 /00/ 0/
7 7 7 7 78 8 8 8 8 7 7 7 7 87 8 8 8 7 7 7 7 7 87 87 87 88787 8 8 8 8 8 78 78 7887 87 Encoder
Figura 14: Plano del nuevo dise˜ no del robot
A parte de redise˜ nar el robot hicimos un cambio en la alimentaci´on del motor, para que tuviera m´as fuerza (Ver secci´on 4.1.4 par m´as detalles). Como en el nuevo dise˜ no la placa la pusimos fuera del robot, tuvimos que instalar los cables que comunican la placa con los elementos del robot (motor, encoder y pulsadores). En total necesit´abamos 9 cables. Utilizamos, entonces, un cable plano de 10 conductores. La ventaja de usar este cable es que todos los conductores est´an juntos y no molestan tanto el movimiento del robot.
´ DEL CIRCUITO ELECTRONICO ´ 3 DESCRIPCION DEL ROBOT
3.
13
Descripci´ on del circuito electr´ onico del robot El robot cuenta con un microcontrolador PIC16F73, que cumple las siguientes funciones:
1. Manejar las entradas del robot (Encoder y Pulsadores) 2. Manejar las salidas del robot (Velocidad del Motor y Direcci´on del mismo) 3. Mantener la comunicaci´on con la computadora que le indica las acciones a tomar En el circuito del robot, pueden distinguirse claramente los componentes que son usados para cada una de estas funciones. Adicionalmente, tiene otro conjunto de componentes que son los encargados de regular la tensi´on de alimentaci´on para todos los otros elementos electr´onicos. A continuaci´on describiremos con m´as detalle cada uno de estos componentes.
3.1.
Encoder y Pulsadores
El encoder utilizado, fue obtenido de un Mouse marca Genius. El mismo cuenta con dos diodos emisores y dos diodos receptores. Los diodos emisores, se alimentan con 8.5 volts (pin 1 de la bornera del encoder) y tienen en serie la resistencia R10 para limitar la corriente. El valor de esta resistencia fue obtenido midiendo la corriente que circulaba por estos diodos cuando el mouse estaba conectado al puerto serie. Los diodos receptores del encoder, se encuentran en inversa. Al recibir luz infrarroja, los mismos var´ıan la tensi´on. Estas variaciones son amplificadas utilizando dos transistores (T1 y T2 para el primer diodo receptor y T3 y T4 para el segundo). De esta forma, conseguimos que cuando el diodo receptor no recibe luz, los transistores no conducen. Por el contrario, cuando el diodo receptor recibe luz infrarroja, los transistores se saturan. Haciendo esto, logramos que el microcontrolador pueda leer el encoder a trav´es de las entradas RB6 y RB7. Por otro lado, tenemos los pulsadores. Mientras que los pulsadores no se encuentren presionados, los capacitores C7 y C8 quedaran cargados. De esta forma, el microcontrolador a trav´es de las entradas RB4 y RB5 sabr´a que los mismos no se encuentran presionados. Cuando un pulsador es presionado, este pone en cortocircuito los bornes del capacitor produciendo su inmediata descarga. De esta forma el microcontrolador sabr´a que pulsador se encuentra presionado. Algo para destacar, es que la decisi´on de utilizar los pines RB4 a RB7 para las entradas se debe a que el microcontrolador cuenta con una interrupci´on que se activa cuando alguna de estas cambia su valor. Esto es muy importante para el encoder, ya que es imprescindible no perder ninguno de los cambios del mismo.
3.2.
Velocidad del Motor y Sentido de Marcha
La velocidad del motor es regulada usando PWM (Pulse Width Modulation). El microcontrolador, cuenta con dos salidas de este estilo. Nosotros usamos una de ellas, cuya salida del microcontrolador es RC2. Esta salida controla al transistor T9, que es el encargado de controlar la velocidad del motor. Ahora bien, dado que el robot requiere moverse hacia adelante y hacia atr´as, es necesario poder invertir la marcha del motor. El circuito de inversi´on de marcha est´a formado por los transistores T5, T6, T7 y T8. Los transistores T6 y T8 se activan juntos con la salida RC4 y los transistores T5 y T7 con la salida RC5. El funcionamiento es el siguiente: RC4 0 0 1 1
RC5 0 1 0 1
Borne 1 Motor Positivo Masa Cortocircuito
Borne 2 Motor Masa Positivo Cortocircuito
Estado Motor Detenido Sentido 1 Sentido 2 Estado Inv´alido
4 ARMADO DEL CIRCUITO
3.3.
14
Comunicaci´ on con la computadora
La comunicaci´on con la computadora se hace mediante el puerto serie (RS232). El microcontrolador ya viene con puerto serie, pero se necesita adaptar los niveles de tensi´on, y por ese motivo es que utilizamos el integrado MAX232. Este integrado requiere ser alimentado con 5 volts y adem´as requiere tensiones de 8.5v y -8.5v.
3.4.
Reguladores de Tensi´ on
La bornera de la alimentaci´on, requiere de una entrada de 12v y otra de -12v. De estos valores, se obtienen los 5 volts utilizando el regulador de tensi´on REG1 (LM7805). Por otro lado, el regulador de tensi´on REG2 (LM7808) en combinaci´on con el diodo D1, permiten obtener 8.5 volts. Por u ´ltimo, el regulador REG2 (7908) y el diodo D2 permiten obtener -8.5 volts. Con estas tensiones alimentamos todos los componentes del circuito.
4.
Armado del Circuito
Lo primero que hicimos fue crear el esquem´atico del circuito, usando el EAGLE versi´on 4.01. A partir del mismo, pasamos al dise˜ no del PCB. Luego tuvimos que acomodar los componentes, de forma tal de evitar que las conexiones se crucen. Una vez acomodados los componentes, comenzamos a rutear la placa. Al principio intentamos usar el “auto-router” que posee el software, pero al ver que el resultado no era bueno, decidimos hacerlo a mano. Una vez realizado el dise˜ no del circuito, procedimos a su fabricaci´on. Para ello, tuvimos que comprar 1 un trozo de FR4 . Luego, copiamos la placa a dicho material, utilizando un papel carb´onico. Una vez copiada la placa, repasamos cada conductor utilizando un marcador indeleble. Con la placa ya dibujada, procedimos a atacar el cobre restante utilizando Cloruro F´errico. Una vez que obtuvimos la placa, tuvimos que hacer los agujeros para los componentes. Si bien, esto parece tarea sencilla, no es tan as´ı, ya que hay que usar mechas muy finitas (en nuestro caso de 0.9 mm). Por u ´ltimo, colocamos todos los componentes en sus respectivos lugares y los soldarlos.
4.1. 4.1.1.
Inconvenientes encontrados y sus soluciones El Microcontrolador no Oscila
Una vez armada la placa, procedimos a probarla y como era de esperarse, no funcionaba nada. As´ı que lo primero que hicimos fue colocarle al micro un programa muy simple, que hiciera funcionar el motor hacia un sentido. Pero ni siquiera este programa tan sencillo funcionaba. Fue entonces, que decidimos medir con un volt´ımetro las salidas del microcontrolador y nos dimos cuenta, que no estaba funcionando. Revisando un poco la placa, nos encontramos que el MCLR2 estaba conectado a masa y eso hac´ıa que est´e continuamente reseteandose. Entonces, corregimos la plaqueta (cortando un par de pistas y soldando cablecitos) para que dicho pin tuviera 5 volts. En el dise˜ no de la plaqueta que entregamos en el presente informe, este error ya se encuentra corregido (tanto en el PCB, como en en esquem´atico). 4.1.2.
El Microcontrolador no Oscila 2
Una vez corregido el error anterior, nos llevamos la sorpresa de que el microcontrolador segu´ıa sin funcionar. El microcontrolador no estaba quemado, ya que se podr´ıa programar, borrar e incluso leer el programa que ten´ıa. Lo que hicimos entonces fue sacarlo de la plaqueta y probarlo afuera. 1 2
El FR4 es el material base de los circuitos impresos Master Clear, pin 1 del microcontrolador
4 ARMADO DEL CIRCUITO
15
Ah´ı descubrimos que el microcontrolador no funcionaba a 20Mhz3 , pero que si lo hac´ıa a 4Mhz. Lo que hicimos entonces fue reemplazar el cristal de 20Mhz por uno de 4Mhz. 4.1.3.
El motor no funciona
Una vez que hicimos funcionar el microcontrolador, nos dimos cuenta que el motor que hab´ıamos elegido no funcionaba. Sin embargo, cuando sac´abamos el motor y mediamos la tensi´on entre los bornes, la misma era correcta. Luego de varios intentos fallidos y de probar con varios motores, encontramos un motor que funcionaba. Sin embargo, a pesar de haber hecho varias pruebas (aumentar la corriente, la tensi´on, etc.) no pudimos hacer funcionar los otros motores. As´ı, que lo u ´nico que pudimos hacer fue elegir ese motor, ya que es el u ´nico que funciona con el circuito. Esto nos llev´o a tener que hacer modificaciones en la parte mec´anica (Ver secci´on 2.9). 4.1.4.
El motor va lento y el regulador calienta
Cuando acoplamos el nuevo motor a las ruedas, nos dimos cuenta que le hac´ıa falta m´as fuerza y que adem´as hac´ıa que el regulador de tensi´on de 5 volts4 calentase. Cuando el regulador calentaba, hac´ıa que la tensi´on caiga y esto produc´ıa que el microcontrolador se reiniciase. Lo que hicimos entonces fue cambiar la alimentaci´on del motor a 8.5 volts. Esto le dio m´as fuerza al motor y adem´as, al utilizar un regulador de tensi´on distinto al del microcontrolador, evitamos que el mismo se reinicie. Otro aspecto interesante, es que como el regulador de tensi´on de 8.5 volts tiene una menor diferencia de potencial entre su entrada y su salida respecto del de 5 volts, la potencia que disipa es mucho menor y en consecuencia, el regulador de 8.5 volts calienta menos que el de 5 volts. Igualmente, para estar m´as tranquilos, decidimos colocarle al regulador de 8.5 volts una chapa delgada de aluminio, para que funcione como disipador. 4.1.5.
El motor funciona en un solo sentido
Luego de utilizar el robot un tiempo cosiderable, se nos present´o el inconveniente de que el motor funcionaba en un sentido pero no en el otro. Lo primero que hicimos fue invertir las conexiones del motor para virificar que el inconveniente no estaba en este. Con las conexiones invertida se comportaba de la misma forma pero girando en la direcci´on opuesta. Al darnos cuenta de que el problema no estaba en el motor, decidimos revisar el circuito. Lo primero que revisamos fue que el micro hac´ıa lo correcto. Luego de ver que el micro funcionaba correctamente, verificamos el funcionamiento de los transistores de la inversi´on de marcha. Encontramos que uno de ellos se hab´ıa desoldado y quedo haciendo falso contacto.
3
En la boleta de compra, figura que el microcontrolador es de 20Mhz, pero como hab´ıa pasado bastante tiempo desde su compra, no fuimos a reclamar 4 En ese momento, el motor se alimentaba con 5 volts, al igual que el microcontrolador
16
5 PROGRAMA DEL MICROCONTROLADOR PIC16F73
5.
Programa del Microcontrolador PIC16F73
5.1.
Compilador
Para hacer el programa del microcontrolador, utilizamos un copilador de C llamado CCSC. El lenguaje C de este compilador no es ANSI, ya que posee funciones y directivas que se mapean directamente con algunas caracter´ısticas del microcontrolador (por ejemplo, el manejo de interrupciones, del puerto serie, etc...) y no tiene algunas otras caracter´ısticas (recursi´on, etc...) que s´ı nos ANSO, pero que no pueden ser soportadas por el microcontrolador.
5.2.
Descripci´ on del programa del microcontrolador
En el presente proyecto, buscamos hacer que el microcontrolador no tomara ning´ un tipo de decisiones, sino que responda a los pedidos del programa de la computadora. Adem´as, busc´abamos que el PIC hiciera transparente para la computadora el manejo de la electr´onica del robot. Bajo estas premisas hicimos una primer versi´on del programa, pero al experimentar un poco, nos dimos cuenta de que era necesario hacerle algunos ajustes y fue as´ı que hicimos una segunda versi´on del programa. 5.2.1.
Protocolo de la primera versi´ on
El protocolo de comunicaci´on entre el microcontrolador y la computadora es muy simple: Enviado por PC B + Velocidad
Respuesta PIC B
Acci´ on Backward
F + Velocidad
F
Forward
I
I + Informaci´ on
Information
R S T
R S T + Puls + Encoder
Reset Encoder Stop Read State
otro
lo mismo
-
Descripci´ on Enciende el motor en sentido inverso a la velocidad indicada Enciende el motor a la velocidad indicada Despliega informaci´on acerca del proyeto Resetea el encoder Detiene el motor Lee el estado del encoder y de los pulsadores
Ahora, en caso de que el microcontrolador estuviera efectuando una tarea y no pudiera atender el pedido de la computadora, el microcontrolador le responder´a a la computadora una “X” por cada caracter enviado 5.2.2.
Decisiones tomadas para la primera versi´ on
El microcontrolador, utiliza para comunicarse con la computadora el puerto serie. El mismo debe ser setado a 19200 baudios, con 8 bits de transmisi´on, sin bit de paridad y sin control de flujo. Dado que el microcontrolador no tiene implementado por hardware la multiplicaci´on de enteros, decidimos que ser´ıa conveniente evitar hacer todo tipo de c´alculos en el mismo. En base a esto, decidimos que cuando la computadora le env´ıa la velocidad al robot (comandos “B” y “F”) debe
17
5 PROGRAMA DEL MICROCONTROLADOR PIC16F73
hacerlo utilizando el caracter cuya numeraci´on en la tabla ASCII coincide con la velocidad deseada. Por ejemplo enviando el comando “FA” estar´ıamos dici´endole al robot que avance a velocidad 65. 5 Cuando la computadora le pregunta el estado al robot (comando “T”) el microcontrolador contesta 3 bytes. El primero es una “T” en confirmaci´on al comando recibido. El segundo es el estado de los pulsadores. El tercer byte es el valor del encoder. Para m´as detalles ver las figuras 15 y 16. 0
5 6 7 0
F B
8
15 Encoder
Figura 15: Descripci´on de los bytes de estado del comando “T”
Valor de los Pulsadores 0 1 2 3
Pulsador 2 Presionado Presionado No Presionado No Presionado
Pulsador 1 Presionado No Presionado Presionado No Presionado
Figura 16: Estado de los pulsadores en funci´on del primer byte de estado El robot no tiene conocimiento de cuando se le cay´o la varilla y deber´a ser la computadora quien interprete la medici´on del encoder para detectar esta situaci´on. Cuando el robot va hacia un lado y la computadora le cambia el sentido, el robot sigue yendo hacia el mismo lado por la inercia. Adem´as, no es conveniente cambiar abruptamente el sentido de marcha del motor, ya que de hacerlo, circular´ıa mucha corriente por el mismo. Estas cuestiones decidimos intentar resolverlas desde el microcontrolador a fin de que sean transparentes para la computadora. Es por ello que decidimos que cuando la computadora env´ıe un comando que cambie el sentido del motor, que el microcontrolador detenga el motor durante 50ms y luego lo acelere a fondo de escala durante 30ms (para intentar recuperar un poco el tiempo perdido) y por u ´ltimo colocar´a la velocidad indicada por la computadora. 5.2.3.
Inconvenientes encontrados
El robot funcion´o bastante bien con la primera versi´on del programa. Sin embargo, en algunas circunstancias cuando el robot chocaba contra alguna de las paredes a gran velocidad, el robot rebotaba y la computadora no llegaba a leer que el pulsador se hab´ıa presionado, pues el tiempo en el cual el pulsador se encuentra presionado es muy peque˜ no. Cuando esto sucede, a pesar de que el robot perdi´o, el mismo sigue movi´endose como si no hubiera chocado. El segundo inconveniente que tuvimos fue que el robot no reaccionaba lo suficientemente r´apido cuando cambiaba el sentido del motor. Esto se debe a que los tiempos fijados en el microcontrolador (mencionados en la secci´on anterior) que se utilizaban cuando la computadora cambiaba el sentido de la marcha. 5
“5”
Si hubi´esemos utilizado los caracteres num´ericos, el microcontrolador deber´ıa multiplicar por 10 al “6” y luego sumarle
18
5 PROGRAMA DEL MICROCONTROLADOR PIC16F73
5.2.4.
Decisiones tomadas para la segunda versi´ on
Para solucionar el problema de los pulsadores, decidimos que el robot cuando env´ıa el estado, en vez de enviar si un pulsador se encuentra presionado, que env´ıe si dicho pulsador fue o est´a siendo presionado. Es decir, que a partir de que el robot detecta que un pulsador se presion´o, entonces siempre que la computadora le pregunte el estado, el robot contestar´a que el pulsador fue presionado (a´ un si el mismo ya no se encuentra presionado). En consecuencia, nos fue necesario agregar un nuevo comando que nos permita resetear el estado de los pulsadores. Adem´as, hicimos que cuando un pulsador se presiona, el microcontrolador detiene autom´aticamente el motor e impide que la computadora vuelva a encenderlo. Para solucionar el problema de los tiempos para la inversi´on de marcha, decidimos hacer que estos tiempos puedan ser fijados mediante un comando que env´ıe la computadora. Haciendo esto, nos evitamos el hecho de tener que reprogramar el microcontrolador cada vez que deseemos ajustar dichos valores. 5.2.5.
Protocolo de la segunda versi´ on
Para corregir los inconvenientes que se nos presentaron, tuvimos que extender el protocolo de comunicaciones con dos nuevos comandos:
5.3.
Enviado por PC V + T.Stop + T.Acel
Respuesta PIC V
Acci´ on Time for Invertion
W
W
Switch Reset
Descripci´ on Setea los tiempos para la inversi´on de marcha del motor Resetea el estado de los pulsadores
Programador
Para programar el microcontrolador, utilizamos el programador “P16PRO” 6 y utilizamos el software “PICALLW” (freeware para windows) porque soporta al microcontrolador y al programador que disponemos.
6
En la p´ agina oficial del programador se encuentran los planos para poder construir el programador
´ DEL PROGRAMA DE LA PC 6 IMPLEMENTACION
6.
19
Implementaci´ on del programa de la PC
En esta secci´on describimos el programa implementado en la PC. El programa se centra principalmente en un mini-framework de aprendizaje al que personalizamos para resolver el problema de p´endulo invertido que se explica en la secci´onsec:framework. Primero explicaremos como es el protocolo de comunicaci´on con el robot. Luego desarrollaremos las partes especificas del problema en cuesti´on: acciones, estados, etc.
6.1.
Protocolo de comunicaci´ on
El protocolo de comunicaci´on que implementamos entre el programa de la PC y el del robot es muy simple. La comunicaci´on se realiza utilizando un puerto serie y asumimos que no existen errores. Si en alg´ un momento detectamos un error en el puerto serie simplemente abortamos el programa. Todas las comunicaciones son iniciadas por el programa de la PC en un modelo similar al de cliente-servidor donde el servidor es el robot. Los mensajes que acepta el robot se resumen en la secci´on anterior en la figura 5.2.1 Cuando el robot recibe un comando, lo procesa y responde devolviendo un byte como ack y en el caso que se solicite el estado 2 bytes mas. El byte de ack es igual al primer byte enviado por el programa de la PC cuando el robot pudo procesarlo. Si el robot no puede procesar el pedido responde con una X. El procesamiento de los estados por parte del robot puede ser de tiempo variable. La respuesta X es utilizada por el programa de la PC para implementar un ”control de flujo”. El programa de la PC solicita continuamente la ejecuci´on de un comando7 hasta que recibe un ack distinto a X. Para finalizar esta secci´on, mostramos las m´aquinas de estado que modelan la comunicaci´on tanto desde el punto de vista de la PC como del robot. Para obtener el estado global del sistema (en lo que respecta a la comunicaci´on) hay que componer las m´aquinas de la figura 17 enviar C genera resp
espera
error error
fin proceso
enviar C
C
espera
inicio
enviar C
X C
comunicarse ejecutar
Diagrama del programa de la PC
procesa X
pide tpo
Diagrama del robot
Figura 17: Maquinas de estados que modelan el protocolo de comunicaci´on entre el programa de la PC y el programa del robot. 7
con un cierto tiempo de espera necesario
´ DEL PROGRAMA DE LA PC 6 IMPLEMENTACION
6.2.
20
Algunas definiciones u ´ tiles
Antes de empezar a definir los estados y las acciones del robot queremos dejar en claro algunas definiciones que vamos a tomar de ahora en m´as. El robot puede moverse en una u ´nica direcci´on en ambos sentidos. A falta de un mejor nombre llamamos “adelante” y “atr´as” a ambos sentidos. A su vez, el p´endulo se balancea en la misma direcci´on que el robot y tambi´en en ambos sentidos, adelante y atr´as. En un instante dado el p´endulo se encuentra en un a´ngulo. Para simplificar la discusi´on, esos a´ngulos los traducimos de grados a ranuras de encoder8 . El a´ngulo de 0 rayas se corresponde con el de 90o . El a´ngulo de 45 rayas (en el sentido adelante) se corresponde aproximadamente a 0 o y el de -45 rayas (45 rayas en el sentido atr´as) se corresponde con el de 180 o . En adelante vamos a omitir la palabra rayas al hablar de los a´ngulos.
6.3.
Acciones del Robot
Las acciones que decidimos que puede realizar el robot son moverse para adelante o para atr´as. El robot debe aprender cuando le conviene moverse para que sentido. La velocidad del movimiento es la m´axima permitida por el microcontrolador. De esta forma, la velocidad en un momento dado depende de la velocidad anterior y la aceleraci´on que se ejerce en el motor para que se desplace.
6.4. 6.4.1.
Estados del robot ´ Angulo
Para ver como discretizar los a´ngulos, estuvimos revisando como se comportaba el robot a velocidad maxima con distintos a´ngulos. En la observaci´on nos dimos cuenta que el robot tiene que reaccionar muy r´apido a peque˜ nos movimientos del p´endulo, ya que pasar de un a´ngulo de 1 a uno de 3 indicaba un grave peligro de que se cayera el p´endulo. Sin embargo para a´ngulos mayores a 3 (aproximadamente 6o ) necesitaba un movimiento brusco para darlo vuelta. En un principio decidimos por esto que ´ıbamos a tener 7 posibles valores del a´ngulo: de -7 a -4, -3 a -2, -1, 0, 2 a 3 y 4 a 7. Mas adelante y en vista de algunos resultados, tambi´en decidimos probar con 6 a´ngulos donde no usamos el a´ngulo 0. Esto se explica mejor en la seccion de aprendizaje. El a´ngulo m´aximo lo fijamos en 7. Esta desici´on se debe a que con un a´ngulo mayor es muy d´ıficil que al robot no se le caiga el p´endulo. Este valor nos ayudaba a que los episodios sean chicos y le permit´ıa obtener refuerzos sin chocarse tanto con las paredes. Salvo que aclaremos otra cosa, la letra θ se usar´a para hablar de a´ngulos. 6.4.2.
Velocidad Angular
La velocidad angular es muy importante para poder distinguir a´ngulos iguales de acuerdo hacia donde y con que velocidad se mueve el p´endulo. No es lo mismo un estado con θ = −1 que tiene velocidad angular 3 que el que tiene velocidad angular -3. El primero esta por cambiar de sentido, y el segundo por perder. La velocidad angular la medimos con el a´ngulo del estado anterior θ 1 y el del a´ngulo actual θ2 con la formula θ2 − θ1 . Por las observaciones realizadas, la velocidad angular se manten´ıa entre 1 y 2. Rara vez se convert´ıa en 3 y ocasionalmente pod´ıa tomar el valor 0. Por esto decidimos que -1, 0 y 1 formaran un estado y 1 los otros dos. A partir de ahora notaremos con θ 0 a la velocidad angular. Mas adelante y en vista de algunos resultados tambi´en probamos discretizando solo con el signo de theta 0 . 8
mas estrictamente 4 veces la cantidad de ranuras, ya que por cada raya se generan 4 interrupciones
´ DEL PROGRAMA DE LA PC 6 IMPLEMENTACION
6.4.3.
21
Velocidad del motor
As´ı como la velocidad del p´endulo es importante, la velocidad del motor tambi´en. No es lo mismo el estado θ = −1, θ 0 = −1 donde el motor tiene velocidad -255 que cuando la velocidad es 255. En un caso estoy enderezando el p´endulo y en el otro lo estoy ayudando a caerse. Por esto creemos necesario mantener la velocidad del m´ovil como parte del estado. El mayor inconveniente de este trabajo ha sido el motor. Esta no es la excepci´on en el aprendizaje. La velocidad del motor no es necesariamente la velocidad que pusimos en el microprocesador. Es decir, el control de la velocidad es a lazo abierto9 . La velocidad real depende del peso del m´ovil y la aceleraci´on. Lamentablemente, no conocemos la aceleraci´on (ni la fuerza del motor). Nosotros podr´ıamos haber medido la velocidad con alg´ un encoder en las ruedas, es decir hacer el control de velocidad a lazo cerrado. Sin embargo, no lo consideramos necesario en un principio (ver Abstract) y no lo hicimos. En este momento nos damos cuenta del error que ello ha significado. Lo que finalmente decidimos hacer es construir un modelo que nos permita estimar a groso modo la velocidad real del veh´ıculo. Incialmente elegimos un conjunto de velocidad y las colocamos en un vector; manteniendo un ´ındice dentro de ese vector que indicaba la velocidad actual. Cada vez que el robot hac´ıa una iteraci´on aument´abamos o reduc´ıamos el ´ındice seg´ un el sentido de la velocidad que decid´ıa utilizar el robot. Este modelo tiene el inconveniente de que supone un MRUV (aceleraci´on constante), lo cual no es cierto en un motor real. Probamos entonces cambiar el modelo por uno en el cual la velocidad se comporta de manera asint´otica (acerc´andose a la velocidad m´axima). Consideramos que este modelo se aproxima mucho m´as a la realidad. Las ecuaci´ones que describen las variaciones de velocidad son: −t
V elactual = (V elf in − V elini ) ∗ (1 − e K ) + V elini La constante K la calculamos en forma emp´ırica. 6.4.4.
Comparaci´ on con simuladores
Buscando en otros trabajos sobre el tema, encontramos algunos simuladores que ten´ıan muy buenos resultados con QLearning. Estos resultados no fueron alcanzados por nosotros (ver 7.2). En esta parte indicamos las diferencias entre la simulaci´on y nuestro robot. En la secci´on de resultados extendemos esta discusi´on. La primera gran diferencia es que en el simulador conocen la aceleraci´on y con eso calculan la velocidad y en nuestro robot, como mencionamos anteriormente, la velocidad no puede ser medida y debe ser estimada. La segunda diferencia es el modelo del movimiento. En el simulador asumen un MRUV donde la velocidad puede tender a infinito. En nuestro modesto robot, la velocidad m´axima esta fija y la aceleraci´on no es constante. El caso mas simple es: estando en velocidad 255, el robot decide mantenerla y por lo tanto la aceleraci´on es 0. De nuevo, un encoder para medir la velocidad habr´ıa sido una buena idea. 6.4.5.
Posici´ on
El robot tiene que evitar chocarse con las paredes. Para aprender donde est´an las paredes la opci´on mas razonable es conocer su posici´on. La ecuaci´on de la posici´on dada la velocidad es trivial. Si p 1 es la posici´on anterior y p2 la actual entonces p2 = p1 ∗ p0 siempre teniendo en cuenta que el tiempo entre mediciones es constante. 9 El control de la velocidad se dice a lazo abierto cuando no es posible medir la velocidad real y realimentar este dato en el sistema
´ DEL PROGRAMA DE LA PC 6 IMPLEMENTACION
22
Con el vector de posiciones magnitud de error al estimar la velocidad es muy grande y por consecuente la posici´on tiene un error muy grande. En cambio utilizando la formula asintotica, la posici´on no ten´ıa tanto error (al menos en los primeros 5’). Para realizar ese calculo, simplemente mediamos la posici´on de la pared cuando el robot chocaba. Las posiciones las discretizamos en tres: atr´as, centro y adelante. Estas se definen mejor en la secci´on 7.2.
6.5.
Pol´ıtica inicial
Dada la complejidad para generar una pol´ıtica inicial decidimos no implementarla.
6.6.
Estrategia de exploraci´ on
Probamos con dos pol´ıticas de exploraci´on a saber: tomando la mejor acci´on conocida para cada estado y tomar la mejor acci´on con 90 % de probabilidad.
6.7.
Funci´ on de refuerzo
La funci´on de refuerzo que implementamos en este trabajo simplemente devuelve un castigo de 1 cuando el robot pierde. En todos los otros casos devuelve 0. Pensamos que con esta funci´on, cuando converja, el robot podr´a mantener el p´endulo invertido por mucho tiempo. Lamentablemente, no por cuestiones temporales no llegamos a hacer que la funci´on converja. Ver seccion 7.2.
7 APRENDIZAJE
7.
23
Aprendizaje
En esta secci´on vamos a describir los experimentos que queremos realizar y los resultados obtenidos. La parte de resultados la vamos a ver en comparaci´on con los resultados de un simulador MRUV. Es muy importante hacer esta comparaci´on para poder luego discutir sobre los resultados. El mayor beneficio de esta comparaci´on es poder distinguir un modelo ideal de uno real e incluso mostrar como en el modelo ideal los resultados dependen de como se “construye” el robot.
7.1.
Experimentos
Los experimentos que ten´ıamos planeados se divid´ıan en dos. Los primeros son simplemente hacerlo aprender en un entorno fijo. Y los segundos consist´ıan en variar el entorno luego de que hubiera aprendido. Debido a las dificultades que tuvimos para hacer que el robot aprenda en un entorno fijo, decidimos no ejecutar los experimentos del segundo tipo. Si no observamos que el robot se comporte adecuadamente en un entorno invariante, observar su aprendizaje cambiando el entorno no tiene sentido. 7.1.1.
Experimento 1
El primer experimento consiste en poner el robot en el medio de dos paredes separadas por un metro (bajas para que no estorben el movimiento del p´endulo). En cada episodio colocamos el p´endulo en el centro haciendo que quede en equilibrio y reseteamos el encoder y la posici´on. En esa posici´on empezamos a correr el aprendizaje. 7.1.2.
Experimentos de cambio de ambiente
Otros experimentos que nos gustar´ıan ejecutar son los de cambios de ambiente. Luego de entrenar al robot en un ambiente con las paredes separadas por x metros, cambiarlo a un ambiente de x + k metros y ver como se adec´ ua.
7.2. 7.2.1.
Resultados Ejecuciones fallidas
En un principio pensamos que solo necesit´abamos la posici´on del robot y el a´ngulo del p´endulo. Nos planteamos la funci´on de refuerzo de la secci´on 6.7 y el resultado no fue bueno. Probamos con otras funciones de refuerzo (que tambi´en resultaron un fracaso) y agregando acciones. Pensab´amos que con m´as acciones el robot podr´ıa tomar mejores decisiones. Despu´es de analizar los resultados vimos que las confusiones del robot se deb´ıan a aliasings entre estados definitivamente distintos. Para solucionarlo incluimos la velocidad angular y luego de otra serie de funciones de refuerzo fallidas decidimos incluir la velocidad a los estados. Las funciones de refuerzo que probamos no eran puramente demoradas. Trataban de premiar al robot por mantener la varilla en un buen a´ngulo o de castigarlo al variar mucho la velocidad. Como primera medida consideramos que la velocidad del estado era la misma velocidad de la acci´on del robot. Esto fue otro fracaso. En este momento nos pusimos a pensar que quiz´a la cantidad de episodios no era suficiente para que aprenda. Dada la falta de ideas, decidimos consultar otra bibliograf´ıa sobre el tema. Encontramos los simuladores y su mapeo de estados y a partir de esto, los experimentos empezaron a mejorar. Ya a esta altura nos d´abamos cuenta que la posici´on del robot no era bien reflejada por la ecuaci´on que consideramos. A partir de ahora vamos a mostrar los resultados del experimento. Estos resultados los comparamos con resultados del simulador.
24
7 APRENDIZAJE γ α exploraci´on τ θ θ0 posiciones
0.85 0.2 mejor acci´on 30 ms [-7,-4],[-3,-2],-1,0,1,[2,3],[4,7] θ0 ≤ −2, −1 ≤ θ 0 ≤ 1, 2 ≤ θ 0 (−∞,-1024],[-1023,-1023],[1024, ∞)
Cuadro 1: Tabla de umbrales de los estados del robot en la primera corrida. 7.2.2.
Primera ejecuci´ on del simulador
El simulador aprend´ıa con un factor de descuento γ = 0,85 y un factor de aprendizaje α = 0,2. La pol´ıtica de exploraci´on era tomar la mejor acci´on. Los estados se median con una separaci´on de τ = 20ms. Los rangos de valores de θ son [-12,-6),[-6,-1),[-1,0),[0,1),[1,6),[6,12). El valor de θ 0 se divid´ıa en tres rangos: menor a 50o por segundo, mayor a 50o por segundo y el medio. Es decir, si el θ 0 esta en el rango de 1o entre mediciones, entonces se mapea a un estado, sino a otros dos. Los resultados eran impresionantes. Estos resultados los mostramos en la figura 18. En esta figura se ve que en la iteraci´on 162 el robot manten´ıa el pendulo al menos 10 6 mediciones.
Figura 18: Primera corrida del simulador. En la iteraci´on 162 consigue el maximo de 10 6 acciones
7.2.3.
Primera ejecuci´ on del robot
Los valores que pusimos en esta primera ejecuci´on se muestran en la tabla 1. Aparte, la primera corrida la ejecutamos con un vector fijo de velocidades. Decidimos que las velocidades del estado eran v = (−255, −192, −96, −32, 0, 32, 96, 192 y 255). Si el robot estaba a una velocidad vi y avanzaba pasaba a la velocidad vi+1 si retroced´ıa iba a la velocidad vi−1 . Esto trataba de simular el efecto de la aceleraci´on. Las posiciones del robot en general variaban de -3000 a 3000 (aunque a veces llegaban a |5000|). El experimento lo corrimos 315 episodios. Nuestra mejora no fue tan buena como la del simulador. Sin embargo, existi´o una mejora. La maxima variaci´on en el valor de las acciones en la iteraci´on 315 segu´ıan siendo significativas (aproximadamente 0.11 cuando lo m´aximo hab´ıa sido 0.2). Esta variaci´on muestra que todav´ıa no
7 APRENDIZAJE
25
estaba ni cerca de converger. Esto puede observarse en la figura 19.
Figura 19: Variaciones de los valores de las acciones en la primera corrida del robot Desde el punto de vista del tiempo de ejecuci´on, se pas´o de realizar 10 acciones por episodio a un promedio 25 acciones por episodio en las u ´ltimas iteraciones del aprendizaje. Esto puede observarse en la figura 20
Figura 20: Tiempo de mantenimiento del pendulo en funci´on de las acciones El error de la posici´on era tan grande que estando en el centro el robot percib´ıa una posici´on atr´as o adelante. Este sensado10 err´oneo confund´ıa mucho al robot. Cuanto mas aguantaba el p´endulo mas error ten´ıa la posici´on y esto generaba una elecci´on de acci´on inadecuada que impon´ıa un limite en el tiempo de ejecuci´on. 7.2.4.
Segunda ejecuci´ on del robot
La falla mas significativa de la primera ejecuci´on result´o sin lugar a dudas el manejo de la posici´on. Muchas veces el robot estaba en el centro del ambiente y cre´ıa estar cerca de una pared. 10
no se sensaba del robot sino que se calculaba, y ahi est´ a el error.
7 APRENDIZAJE
26
Para subsanar estos inconvenientes incluimos la formula asint´otica, con un valor de k medido a ojo (ver 6.4.3). En esta ejecuci´on k = 0,20 . Luego de ejecutar el aprendizaje por 280 iteraciones, decidimos incluir una pol´ıtica de exploraci´on con probabilidad 90 % mejor acci´on, aunque no notamos muchas diferencias. Los resultados se muestran en las figuras 21 y 22. Lamentablemente perdimos las estad´ısticas de las primeras 80 iteraciones.
Figura 21: Variaciones de los valores de las acciones en la segunda corrida del robot
Figura 22: Tiempo de mantenimiento del pendulo en funci´on de las acciones para la segunda corrida En la figura de la variaci´on promedio se ve que no est´a convergiendo la funci´on de aprendizaje. En la figura de la cantidad de iteraciones se ve que el resultado no fue para nada bueno, con lo cual no dice nada. Para la vista de un observador, el robot variaba su comportamiento, pero no quedaba claro que quisiera mantener el p´endulo. 7.2.5.
Mas ejecuciones del simulador
En vista de que la ejecuci´on del aprendizaje del robot no fue satisfactoria en comparaci´on con el del simulador decidimos ajustar los par´ametros del simulador. Los resultados de este proceso fueron alentadores (en alg´ un sentido). El primer par´ametro que modificamos fue el tiempo entre la medici´on de dos estados. Esta modificaci´on oblig´o a cambiar los umbrales de la velocidad angular para que se siguiera discretizando como antes. El resultado se muestra en la figura 23.
27
7 APRENDIZAJE
Figura 23: Segunda corrida del simulador. Cambia τ a 30ms
La mejor iteraci´on en este caso fue la 137 con 1662 acciones ejecutadas. Ya se puede observar que estos resultados no son tan impresionantes como los de la figura 18 habiendo cambiado solo el tiempo entre las mediciones. Adem´as desde la iteraci´on 222 a la iteraci´on 300 se mantuvo estable con una cantidad de 263 acciones. Una gran diferencia entre el simulador y nuestro robot existe en la mediciones de θ y θ 0 . El simulador utiliza variables float de gran precisi´on, mientras que el robot posee un encoder que por cada 2 o de movimiento reconoce 1 raya. Lo que modificamos en la tercer corrida del simulador fue que la velocidad angular se reconociera reci´en cuando el p´endulo se mueve en dos grados. Los resultados en este caso fueron los de la figura 24.
Figura 24: Tercera corrida del simulador. Cambia la discretizacion de θ 0
En este caso se puede observar que el robot nunca llega a mantener mas de 400 acciones el p´endulo. Adem´as durante un largo periodo se mantiene en una meseta de menos de 100 acciones. La siguiente modificaci´on la realizamos para que el simulador mapee los valores de θ como lo hace el robot. Luego, el rango [-1,1] lo consideramos como el a´ngulo 0 del robot. Los resultados se muestran
7 APRENDIZAJE
28
en la figura 25.
Figura 25: Cuarta corrida del simulador. Cambia la discretizacion de θ En este u ´ltimo caso la curva es poco estable, y no se llega a observar ninguna convergencia del aprendizaje. Esto se asemeja m´as a nuestros resultados que los de la corrida 1, a pesar de que el modelo de movimiento no es el mismo. 7.2.6.
Tercera ejecuci´ on del robot
Con los resultados de la corrida 4 del simulador nos pusimos a pensar que pasar´ıa si el a´ngulo 0 se mapeara a estados distintos de acuerdo a la velocidad del robot. Lo que hicimos primero fue ejecutarlo en el simulador. Los par´ametros del simulador eran los mismos que en la corrida 4, con la diferencia de que el rango [-2, -1] y el [-1,1] se consideran iguales cuando el robot avanza, y los rangos rango [1, 2] y el [-1,1] se consideran iguales cuando retrocede. Esto es asumir que el p´endulo esta cayendo para el lado contrario al que va el robot. Los resultados en el simulador son aun mas impresionantes que los de la corrida 1 y se muestran en la figura 26. En este caso, solo necesito 56 iteraciones. En vista de estos resultados, tratamos de hacer lo mismo con nuestro robot. Lo que hicimos fue tener 6 angulos a saber: [-7,-4],[-3,-2],[-1,0],[0,1],[2,3],[4,7] donde el 0 se decide de acuerdo a la velocidad. Esta corrida no fue satisfactoria porque nos encontramos que el τ real del robot era de 40ms. Hab´ıamos cambiado de maquina, y con los 20ms de tiempo de comunicaci´on en esta maquina se necesitaban 20ms de ejecuci´on. Los resultados se muestran en la figura 27 desde la iteraci´on 135 y tambi´en se muestran los resultados del simulador con un τ = 40ms. Uno de los mayores inconvenientes de esta ejecuci´on fue que la posici´on variaba de -4000 a 4000 y el centro lo hab´ıamos definido como -600 a 600. 7.2.7.
Ultima ejecuci´ on del robot
En la u ´ltima ejecuci´on tratamos de modificar el valor de γ a 0.95. Esto funcion´o de forma inestable tanto en el simulador como en el robot. Sin embargo el simulador logr´o muchas buenas marcas. El robot logro aguantar hasta 5 segundos (aprox 80 iteraciones). Nos quedaron muchas dudas de porque si el tiempo de medici´on era de 40ms, 80 iteraciones equival´ıan a 5 segundos, pero eso es lo que indicaba la salida del programa.
7 APRENDIZAJE
29
Figura 26: Quinta corrida del simulador. Cambia la discretizacion de la velocidad. En s´olo 56 iteraciones logra el m´aximo tiempo de mantenimiento de 100000
Figura 27: Sexta corrida del simulador y tercera del robot. El tiempo τ estaba mal y se corrigi´o a 40ms. Los datos del simulador son los de la recta superior.
7 APRENDIZAJE
30
Lo que cambiamos en el robot (adem´as de una constante que indicaba en el robot el tiempo de espera) fueron los rangos de posiciones y el rango de velocidades. El umbral de la posicion era de |1000|, con valores m´aximos de |2500|, el umbral de velocidades era de 40. Los resultados del simulador se muestran en la figura 28. Los resultados del robot se muestran en la figura 29. Las mesetas de valores bajos del simulador rondan entre las 20 y 80 acciones en la mayor´ıa de los casos.
Figura 28: Ultima corrida del simulador. Cambia el valor de γ a 0.95. En la figura se ve que el aprendizaje es inestable. Los valores bajos rondan entre 20 y 80 acciones.
Figura 29: Tiempo de mantenimiento del pendulo en funci´on de las acciones para la ultima corrida del robot. Tambi´en resulta inestable, pero con picos bajos.
7.3.
Discusi´ on de los resultados
En vista de la cantidad de resultados que expusimos en este trabajo, queremos realizar un peque˜ no an´alisis del impacto que tienen las caracter´ısticas f´ısicas del robot. Tanto en las ejecuciones del simulador como las del robot, se observa que peque˜ nos cambios en las condiciones de los experimentos pueden provocar grandes cambios en el aprendizaje.
7 APRENDIZAJE
31
El primer cambio que hicimos fue agrandar el τ del simulador. Esto le dio peor reacci´on a los cambios que se produc´ıan originando un resultado no tan bueno. Sin embargo, con este mismo τ y cambiando otros par´ametros en la corrida 5 logramos que el robot mantenga el p´endulo con incluso menos iteraciones de QLearning. Si tenemos en cuenta la cantidad de par´ametros que se pueden ajustar en el robot, observamos que estos determinan un resultado exitoso o un fracaso. Ahora, si a esto le sumamos el error en la posici´on que ten´ıa nuestro robot f´ısico, en principio no resultan sorpresivos los resultados obtenidos. En el simulador no existe rozamiento, el movimiento sigue un modelo ideal (MRUV), no hay ning´ un ruido y las mediciones poseen mucha presici´on. En cambio nuestro robot sigue un modelo de movimiento con aceleraci´on asintotica; hay ruido en las mediciones porque el p´endulo tiembla y la velocidad se aproxima; y la precisi´on es muy peque˜ na, todo el rango de dos grados del p´endulo poseen el mismo valor y reci´en se detecta el movimiento del p´endulo cuando la velocidad es de dos grados por medici´on. Todas estas diferencias muestran como el pasaje de un mundo ideal con un robot que posee propiedades ideales a un mundo real con un robot en situaci´on no resulta buena. No es que el simulador no refleje alguna realidad, pero claramente asume condiciones que nunca pueden lograrse en el mundo en que vivimos. Nunca un motor puede tener aceleraci´on constante por tiempo infinito. Con todo esto en mente, el problema del p´endulo invertido se convierte en un problema d´ıficil 11 . Hay que ajustar todos los par´ametros que determinan que estados sensa el robot a los valores que permitan obtener buenos resultados (al menos en un tiempo acotado). Y como si eso fuera poco, la seleccion de los valores de α y γ no es tarea trivial, ya que pueden hacer que el aprendizaje converja a o´ptimos locales12 . El tiempo que consume realizar cada experimento es muy grande y por eso decidimos cortar en mas o menos 200 a 300 iteraciones. Quiz´a con un poco mas de paciencia el aprendizaje converg´ıa a algo bueno.
11 12
al menos as´ı fue para nosotros A no ser que se use una pol´ıtica de exploraci´ on buena
8 CONCLUSIONES
8.
32
Conclusiones
En vista de nuestro objetivo que era hacer un robot, creemos que el resultado ha sido m´as que satisfactorio. El trabajo nos ayudo a fortalecer nuestro proceso de aprendizaje en varios de los temas de rob´otica que vimos en la materia. Tuvimos que enfrentarnos a problemas de calibraci´on mec´anica, seleccionar los elementos de electr´onica adecuados para producir los comportamientos que busc´abamos y por u ´ltimo lograr que el robot aprenda a resolver el problema. Como en cualquier trabajo donde uno no tiene la posibilidad de rehacer varias cosas de nuevo, nos encontramos con situaciones inesperadas que tuvimos que resolver con cierta creatividad y dejando ciertos prejuicios de lado. La conclusi´on mas significativa que podemos hacer es que nunca consideramos la posibilidad de que un robot ”relativamente sencillo” fuera tan dif´ıcil de construir. Los factores de esta dificultad son varios. Ninguno de nosotros nunca hab´ıa hecho un robot y no conoc´ıamos qu´e cosas eran mas importantes considerar al principio. Antes de comenzar el trabajo pensabamos que las mayores dificultades iban a estar en la construcci´on del robot y no en el aprendizaje. Cuando nos pusimos a trabajar con QLearning nos dimos cuenta que esto no era as´ı. Por el contrario las decisiones que uno toma al calibrar (tanto la parte mec´anica como los umbrales) el robot tienen un gran impacto en el aprendizaje complic´andolo. Para finalizar, pudimos reconocer la importancia de trabajar con un robot situado en el mundo. Cuando uno trabaja con un simulador termina escondiendo muchas de las complejidades que tiene el robot al interactuar con el entorno. En nuestro caso estas complejidades terminaron determinando la dificultad del trabajo.
A MINI-FRAMEWORK DE APRENDIZAJE
A.
33
Mini-framework de aprendizaje
Cuando empezamos a dise˜ nar el programa de la PC todav´ıa no ten´ıamos un avance significativo del robot. Solo conoc´ıamos algunos datos como la velocidad m´axima del motor (que permit´ıa el microcontrolador). Sin embargo no pod´ıamos calcular cuantas velocidades deb´ıa tener el robot, ni como ´ıbamos a discretizar los estados del robot. Solo sab´ıamos cual era el algoritmo de aprendizaje que ´ıbamos a implementar (QLearning) y como se pod´ıa implementar. Por estos motivos surgi´o la necesidad de hacer que el programa se pudiera ”personalizar” una vez construido. En principio la idea era que se pudieran definir las velocidades del motor, los a´ngulos de la varilla y la posici´on del robot. Al empezar a pensar en la forma de implementar esta idea nos dimos cuenta que no era mucho mas complicado13 implementar un mini-framework de QLearning. En esta secci´on explicamos los requerimientos y el dise˜ no del framework.
A.1.
Requerimientos del framework
Luego de algunas idas y venidas definimos los siguientes requerimientos sobre el futuro framework: 1. El framework debe manejar la ejecuci´on del algoritmo de QLearning, permitiendo definir los “estados finales” de un episodio del experimento. 2. El framework debe poder personalizar las acciones, estados, pol´ıtica inicial, funci´on de refuerzo y estrategia de exploraci´on. En este sentido llegamos a la conclusi´on que los estados y las acciones no deb´ıan estar fijas para el problema de p´endulo invertido sino que se puede definir cualquier estado. 3. El framework debe permitir guardar y recuperar toda la informacion necesaria para continuar un experimento en otro momento. La motivaci´on de este requerimiento es simple: ejecutar un episodio del experimento demora aproximadamente 1 minuto. 4. El framework debe permitir incorporar distintas formas de comunicarse con el robot (puerto serie, puerto paralelo, sockets, archivos, etc). Es decir, el framework no debe depender en cual mecanismo de comunicaci´on se utiliza. 5. Ser´ıa deseable que el framework funcione en los dos sistemas operativos de la facultad: Linux y Windows. 6. Ser´ıa deseable que los archivos generados por la aplicaci´on para guardar el aprendizaje sea legible de forma tal que pueda ser tambi´en escrita por un ser humano. Esta adem´as puede ser una forma de incorporar acciones, estados y escribir una pol´ıtica inicial. A medida que fuimos avanzando con el desarrollo de este mini-framework, surgieron (y a la vez desaparecieron) otros requerimientos. El mas importante fue que ”el framework debe permitir definir estados nuevos (no conocidos) mientras se esta ejecutando el algoritmo de aprendizaje”. Este requerimiento es muy importante, porque el robot se puede encontrar en un ambiente que no conoce y preveer todos los estados que puede experimentar resultar´ıa impracticable. En nuestro caso concreto, el robot puede pasar de un ambiente con paredes cercanas a un ambiente con paredes lejanas. Como tenemos en cuenta la “posici´on”, en un estado es muy probable que surjan nuevos estados (ver 6.4.5). Hubo otros requerimientos que nos planteamos pero que por falta de tiempo no pudimos implementar. Los mas importantes son que el framework tenga un buen manejo de errores/excepciones y que el framework sea aun mas f´acil de usar. 13
utilizando una gran dosis de optimismo
34
A MINI-FRAMEWORK DE APRENDIZAJE
A.2.
Decisiones de dise˜ no
Nunca nos dispusimos a definir un verdadero dise˜ no del framework, sino que este surg´ıo de la codificaci´on directa. En este apartado trataremos de individualizar las decisiones importantes y al final resumir el dise˜ no resultante de la implementaci´on. La primer determinaci´on que tomamos es que el programa en su conjunto deb´ıa implementarse en C++. El objetivo es que se pueda codificar en un lenguaje de medio-alto nivel que fuera a la vez lo suficientemente eficiente. El requerimiento de eficiencia no es estrictamente necesario porque la PC tiene una frecuencia de clock de casi 400 veces mas r´apida que el microcontrolador del robot. Pero como la comunicaci´on con el robot es en tiempo real, no quer´ıamos tener complicaciones al poner el programa en espera. Lamentablemente C++ es un lenguaje no reflexivo y en donde uno no puede crear objetos por el nombre de la clase. Todo esto gu´ıo nuestro dise˜ no, ya que ciertas funcionalidades debimos implementarlas de forma diferente a lo que lo hubi´eramos hecho en otros lenguajes de objetos (Smalltalk, Java, Python, etc.). A continuaci´on vamos a dar una breve descripci´on de cada una de las partes del framework. A.2.1.
Algoritmo de aprendizaje
El algoritmo principal del framework es el de aprendizaje con QLearning que se encuentra en la clase QLearner. Esta clase soporta la ejecuci´on del algoritmo tanto para problemas epis´odicos como no epis´odicos. Para los problemas epis´odicos se definen dos conjuntos de estados: los iniciales (I) y los finales (F). Mientras el robot se encuentra en un estado marcado como inicial el programa de QLearning no se ejecuta. Esto nos permitir´ıa, por ejemplo, manipular el robot para que experimente estados que le permitan tomar decisiones futuras14 . Luego el robot ejecuta el algoritmo de aprendizaje hasta que experimenta un estado marcado como final. En este estado el algoritmo deja de ejecutarse ya que el episodio se considera finalizado. De esta forma podemos parar al robot cuando sensa un pulsador o se cae la varilla. Aparte, se puede definir una cantidad m´axima de acciones (CANT) a ejecutar (tanto para cada episodio como para los problemas no epis´odico) para poder grabar la pol´ıtica. Todo esto se resume en el diagrama de estados de la figura 30.
s∈ /F s∈I
I
s∈ / I ∧s ∈ /F
ejecuta
CANT–
sensa s
s ∈ F∨ CANT = 0
F
s∈ / I ∧s∈F
Figura 30: Diagrama de estados que muestra la ejecuci´on de acciones para un episodio. Si F = ∅∨I = ∅ entonces el problema no es epis´odico y termina con CANT = 0.
A.2.2.
Pol´ıtica
En cada iteraci´on de QLearning es necesario tomar una acci´on de acuerdo al estado sensado y luego setear el nuevo valor de esa acci´on para ese estado. Todos estos valores se guardan en una tabla que 14
Un ejemplo es apretar varias veces el pulsador para dar una noci´ on del tama˜ no del ambiente
35
A MINI-FRAMEWORK DE APRENDIZAJE
QLearner
Usuario
Robot
queryState doQueryState ˆState (Estado discretizado no conocido) guardar State como nuevo estado getValuesFor(State, Actions) ˆValues (Acciones filtradas con valor) ˆState
Figura 31: Diagrama de secuencia mostrando como se obtienen y discretizan los estados del robot para el caso de estados nuevos. la administra la clase Policy. Luego, para cada estado se define el conjunto de acciones factibles y se mantiene su valor. Para elegir que acci´on tomar en cada estado Policy se configura con una estrategia de exploraci´ on (no necesariamente determin´ıstica). A.2.3.
Sensado de estados
Para sensar un estado es imprescindible que el programa se comunique con el robot, el robot le responda su estado y este estado se discretice de alguna forma. El framework no puede realizar ninguna de estas tareas ya que son especificas del problema a resolver. Sin embargo, una vez que el estado es discretizado pueden ocurrir dos cosas. Que el estado ya hubiera sido sensado previamente15 o que no. Si el estado nunca hab´ıa sido sensado, el framework se encarga de guardarlo en la tabla de valores. Mas adelante, si se guarda la configuraci´on del robot, este estado estar´a disponible. Cuando se detecta que un estado es nuevo, puede ser deseable generar una pol´ıtica inicial. Esta pol´ıtica inicial tiene dos objetivos en el framework. El primero es el de dar un valor a cada acci´on posible para este estado. El segundo es el de filtrar aquellas acciones que el robot no puede ejecutar en ese estado. Para generar la pol´ıtica inicial se llama a una funci´on del usuario. En resumen el sensado se muestra en la figura 31 para el caso donde se detecta un estado nuevo. Quien se encarga de resolver la funcionalidad del estado es la clase Robot. A.2.4.
Ejecuci´ on de acciones
La ejecuci´on de una acci´on tambi´en debe hacerse por afuera del framework. Para ejecutar la acci´on el framework le provee a una funci´on un objeto que tiene los par´ametros necesarios de la acci´on. Esta funci´on debe comunicarse con el robot para que efectivamente realice la acci´on. 15
teniendo en cuenta la discretizaci´ on
A MINI-FRAMEWORK DE APRENDIZAJE
36
Como en el caso del sensado, el framework tambi´en realiza operaciones de soporte. Luego de que se ejecuta la acci´on, el framework fuerza una espera (configurable) y retorna a el QLearner el nuevo estado sensado. A.2.5.
Definici´ on de Acciones y Estados
Hasta ahora consideramos a las acciones y estados como entidades con vida propia sin decir que son exactamente. El inconveniente que tenemos para decir que son es que dependen pura y exclusivamente del problema a resolver. Sin embargo el framework necesita que las acciones y estados se definan sobre una clase que provee llamada Bean16 . Los Beans solo conocen el tipo de acci´on/estado17 y los par´ametros de cada objeto. Entonces cuando la clase Robot pide un State al m´etodo del usuario, este debe devolver un Bean con los par´ametros adecuados. Por ejemplo, tipo = ”Boton no presionado”, a´ngulo = 20. A.2.6.
Guardar y cargar aprendizajes
Un tema no menor que soluciona el framework es la definici´on de acciones, estados, pol´ıtica inicial, etc. que son cargados de un archivo (de configuraci´on o generado por el framework) y de guardarlos para continuar luego. Toda esta configuraci´on se guarda en un singleton llamado Configuration. Ni bien inicia la aplicaci´on, la configuraci´on se carga de uno o mas archivos de forma autom´atica. A.2.7.
Comunicaci´ on con el robot
Connection es una interfaz que no es utilizada directamente por el framework. Esta interfaz se basa en el manejo de archivos de los sistemas Unix y se tiene que heredar para implementar distintos mecanismos de comunicaci´on. El u ´nico mecanismo que implementamos es la comunicaci´on por puerto serie (para Linux). A.2.8.
Archivo de configuraci´ on
Un archivo de configuraci´on permite definir las acciones, los estados, cuales estados son finales y cuales iniciales y la pol´ıtica inicial. Es importante aclarar que para el caso de las acciones y el conjunto de estados iniciales y finales, esta es la u ´nica forma de crearlos. Esto se dio as´ı por falta de tiempo y no por una decisi´on de dise˜ no. El formato particular de un archivo de configuraci´on se puede encontrar en los archivos de flex y bison18 .
16
en honor y nostalgia a los beans de java Las acciones y estados se diferencian solo en su uso, y no en su definici´ on 18 aunque quiz´ a est´en un poco desactualizados 17
B DIAGRAMAS DEL CIRCUITO
B.
Diagramas del Circuito
Figura 32: Diagrama esquem´atico del circuito
37
38
B DIAGRAMAS DEL CIRCUITO
Figura 33: Circuito impreso
C
C.
´ CODIGO DEL PROGRAMA DEL MICROCONTROLADOR
C´ odigo del programa del microcontrolador
#include #use delay(clock=4000000) #fuses XT,NOWDT #use rs232(baud=19200,parity=N,xmit=PIN_C6,rcv=PIN_C7) #use fast_io(B) #use fast_io(C) //si se #define #define #define
cambian estos valores, se tiene que cambiar direccion_opuesta FORWARD 1 BACKWARD 2 STOP 3
#define motor_stop() #define motor_forward() #define motor_backward()
{output_bit( PIN_C5, 0); output_bit( PIN_C4, 0);} {output_bit( PIN_C4, 0); output_bit( PIN_C5, 1);} {output_bit( PIN_C5, 0); output_bit( PIN_C4, 1);}
#define pulsador_presionado (botones!=3) #define fclock 20000000 #define prescalerTM1 2 #define TiempoTimerMS(t)
(65536-(((t)*(fclock))/1000)/(4*(prescalerTM1)))
#define NO_WAIT 0 #define STOP_FOR_INVERSION 1 #define SPEED_FOR_INVERSION 2 int16 time_stop_for_invesion; int16 time_speed_for_invesion; int8 estado_encoder_anterior; signed int8 valor_encoder; int8 botones; int8 direccion; int8 velocidad; int8 timer_wait;
#int_RB void RB_isr() { int8 valor; valor = input_b(); valor >>= 4; botones &= (valor & 0b11); valor &= 0x0C; valor |= estado_encoder_anterior; switch(valor){ case 0b0100: case 0b1101:
39
C
´ CODIGO DEL PROGRAMA DEL MICROCONTROLADOR
case 0b0010: case 0b1011: valor_encoder++; break; case 0b1000: case 0b0001: case 0b1110: case 0b0111: valor_encoder--; break; default: break; } estado_encoder_anterior = valor >> 2; //Si se presiono un pulsador, paro el motor if(pulsador_presionado && (direccion != STOP)){ set_pwm1_duty(0); motor_stop(); velocidad = 0; direccion = STOP; } } #int_TIMER1 void TIMER1_isr() { switch(timer_wait){ //case NO_WAIT: break; case STOP_FOR_INVERSION: //Seteo que voy a acelerar por un tiempo timer_wait = SPEED_FOR_INVERSION; //Voy a acelerar por un tiempo (default 30ms) set_timer1(time_speed_for_invesion); if(direccion == FORWARD){ motor_forward(); }else{ motor_backward(); } set_pwm1_duty((int8)255); break; case SPEED_FOR_INVERSION: //Seteo que voy a acelerar por un tiempo timer_wait = NO_WAIT; setup_timer_1 ( T1_DISABLED ); //Coloco la velocidad deseada set_pwm1_duty(velocidad); break; }
40
C
´ CODIGO DEL PROGRAMA DEL MICROCONTROLADOR
41
} void init(){ /********************** * INICIALIZACION ***********************/ //Definimos los pines //1-> Entrada 0-> Salida set_tris_c(0x8B); //RC7->Rx output_c(0x00); set_tris_b(0xFF);
RC6->Tx
RC5->Inv1
RC4->Inv2
RC3->Nada
//No hay conversores AD setup_adc_ports(NO_ANALOGS); //setup_adc(ADC_CLOCK_DIV_2); setup_spi(FALSE); setup_counters(RTCC_INTERNAL,RTCC_DIV_2); //Detengo el Timer1 setup_timer_1 ( T1_DISABLED ); //Seteamos la frecuencia del PWM a 1.2 kHz setup_timer_2(T2_DIV_BY_16,255,16); setup_ccp1(CCP_PWM); setup_ccp2(CCP_OFF); //Habilitamos las interrupciones del portB y del timer1 enable_interrupts(INT_RB); enable_interrupts(INT_TIMER1); //Leo el valor del puerto B antes de habilitar las interrupciones estado_encoder_anterior = input_b(); estado_encoder_anterior >>= 6; botones = 0b11; //Ningun pulsador presionado valor_encoder = 0; velocidad = 0; direccion = STOP; timer_wait = NO_WAIT; time_stop_for_invesion = TiempoTimerMS(50); time_speed_for_invesion = TiempoTimerMS(30); //Habilito las interrupciones enable_interrupts(global); } void set_motor(int8 velocidad_nueva, int8 direccion_nueva) { if(direccion_nueva == STOP) { set_pwm1_duty(0);
RC2->PWM
RC1-0->
C
´ CODIGO DEL PROGRAMA DEL MICROCONTROLADOR
motor_stop(); velocidad = 0; direccion = direccion_nueva; } else if(direccion == direccion_nueva) { //no se necesita cambiar los transistores set_pwm1_duty(velocidad_nueva); velocidad = velocidad_nueva; } else if(direccion == STOP) { //no hace falta pararlo, estaba parado if(direccion_nueva == FORWARD){ motor_forward(); }else{ motor_backward(); } set_pwm1_duty(velocidad_nueva); velocidad = velocidad_nueva; direccion = direccion_nueva; } else { //direccion_anterior != direccion, frenar y reiniciar el motor motor_stop(); set_timer1(time_stop_for_invesion); timer_wait = STOP_FOR_INVERSION; velocidad = velocidad_nueva; direccion = direccion_nueva; setup_timer_1(T1_INTERNAL|T1_DIV_BY_2); } } void main() { char c; int8 speed; init(); while(TRUE){ c = getc(); //Verificamos que no estemos esperando el Timer 1 if(timer_wait != NO_WAIT){ putc(’X’); continue; } putc(c); switch(c){ case ’R’: //Reset encoder valor_encoder = 0; break; case ’W’: //reset sWitch botones = 0b11; break;
42
C
´ CODIGO DEL PROGRAMA DEL MICROCONTROLADOR
case ’V’:
//time for inVertion time_stop_for_invesion = ((int16)getc())