You are on page 1of 64

Proyecto Final Robot recolector de residuos Arquitectura de Comportamientos y Algoritmos

Guillermo Campelo Juan Ignacio Go˜ ni Diego Nul 27 de septiembre de 2010
Resumen Palabras clave: Robot, recolector, residuos, rob´ otica, comportamientos, visi´ on, MR-2FA, L298, FR304, HX5010, GP2D120, BC327, SRF05, CNY70, motor, servo, tel´ emetro, daisy chain, RS232, subsumption, Webots, OpenCV, detecci´ on, objetos, contornos, hsv

1

´ Indice
1. Arquitectura de Comportamientos 1.1. Introducci´ on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Investigaciones previas . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1. Desarrollo de comportamientos no triviales en robots reales : Robot recolector de basura - Stefano Nolfi [6] . . . . . . 1.2.2. Arquitectura de control para un Robot Aut´ onomo M´ ovil - Neves And Oliveira [5] . . . . . . . . . . . . . . . . . . . 1.2.3. Path Planning usando Algoritmos Gen´ eticos - Salvatore Candido [2] . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.4. Navegaci´ on predictiva de un robot aut´ onomo - Foka And Trahanias [3] . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.5. Algoritmo de navegaci´ on y evitamiento de obst´ aculos en un entorno desconocido - Clark Et. al [7] . . . . . . . . . . 1.3. Arquitectura propuesta . . . . . . . . . . . . . . . . . . . . . . . 1.4. Comportamientos e implementaciones . . . . . . . . . . . . . . . 1.4.1. Wandering . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1.1. Detalle del comportamiento . . . . . . . . . . . . 1.4.1.2. Implementaci´ on del comportamiento . . . . . . . 1.4.2. Enfocar Basura . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2.1. Detalle del comportamiento . . . . . . . . . . . . 1.4.2.2. Implementaci´ on del comportamiento . . . . . . . 1.4.3. Ir a Basura . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.3.1. Detalle del comportamiento . . . . . . . . . . . . 1.4.3.2. Implementaci´ on del comportamiento . . . . . . . 1.4.4. Recolectar Basura . . . . . . . . . . . . . . . . . . . . . . 1.4.4.1. Detalle del comportamiento . . . . . . . . . . . . 1.4.4.2. Implementaci´ on del comportamiento . . . . . . . 1.4.5. Ir a zona de descarga de basura . . . . . . . . . . . . . . . 1.4.5.1. Buscar l´ ınea . . . . . . . . . . . . . . . . . . . . 1.4.5.1.1. Detalle del comportamiento . . . . . . . 1.4.5.1.2. Implementaci´ on del comportamiento . . 1.4.5.2. Entrar a l´ ınea . . . . . . . . . . . . . . . . . . . 1.4.5.2.1. Detalle del comportamiento . . . . . . . 1.4.5.2.2. Implementaci´ on del comportamiento . . 1.4.5.3. Seguir l´ ınea . . . . . . . . . . . . . . . . . . . . . 1.4.5.3.1. Detalle del comportamiento . . . . . . . 1.4.5.3.2. Implementaci´ on del comportamiento . . 1.4.6. Descargar Basura . . . . . . . . . . . . . . . . . . . . . . . 1.4.6.1. Detalle del comportamiento . . . . . . . . . . . . 1.4.6.2. Implementaci´ on del comportamiento . . . . . . . 1.4.7. Ir a base de recarga de bater´ ıa . . . . . . . . . . . . . . . 1.4.8. Cargar Bater´ ıa . . . . . . . . . . . . . . . . . . . . . . . . 1.4.8.1. Detalle del comportamiento . . . . . . . . . . . . 1.4.8.2. Implementaci´ on del comportamiento . . . . . . . 1.4.9. Evitar Obst´ aculos . . . . . . . . . . . . . . . . . . . . . . 1.4.9.1. Detalle del comportamiento . . . . . . . . . . . . 1.4.9.2. Implementaci´ on del comportamiento . . . . . . . 4 4 5 5 6 7 7 8 9 11 12 12 13 14 16 16 18 18 19 20 21 21 21 22 23 23 25 25 25 25 27 27 27 27 27 28 28 28 28 28 28 29

2

1.5. 1.6.

1.7.

1.8.

1.4.10. Salir de situaciones no deseadas . . . . . . . . . . . . . . . 1.4.10.1. Detalle del comportamiento . . . . . . . . . . . . 1.4.10.2. Implementaci´ on del comportamiento . . . . . . . Odometr´ ıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1. Problemas con la odometr´ ıa . . . . . . . . . . . . . . . . . Interfaces con hardware y m´ odulo de reconocimiento de objetos . 1.6.1. Interfaz con hardware . . . . . . . . . . . . . . . . . . . . 1.6.2. Interfaz con m´ odulo de reconocimiento de objetos usando Visi´ on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resultados obtenidos . . . . . . . . . . . . . . . . . . . . . . . . . 1.7.1. Distribuci´ on y progreso de comportamientos . . . . . . . . 1.7.2. Tiempos en caa y cai de comportamientos . . . . . . . . . 1.7.3. Transiciones entre comportamientos . . . . . . . . . . . . 1.7.4. Arena recorrida . . . . . . . . . . . . . . . . . . . . . . . . Conclusi´ on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.8.1. Posibles extensiones . . . . . . . . . . . . . . . . . . . . . de . . . . . . software del . . . . . . . . . . . . . . . . . . . . . . . .

30 30 30 31 32 34 34 34 36 37 40 41 43 45 48

A. Implementaci´ on de arquitectura A.1. Comportamientos . . . . . . . . A.2. Dispositivos del robot . . . . . A.3. Reconocimiento de objetos . . .

controlador 49 . . . . . . . . . 51 . . . . . . . . . 53 . . . . . . . . . 55 57 57 57 58 59

B. Implementaci´ on del protocolo en PC B.1. Packet Server . . . . . . . . . . . . . B.2. Packets . . . . . . . . . . . . . . . . B.3. Handlers . . . . . . . . . . . . . . . . B.4. Modificaci´ on del protocolo . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

3

desde la forma de organizar los comportamientos.2 analizamos papers relacionados con este desarrollo. en la secci´ on 1. decidir por s´ ı mismo las acciones a realizar en cada momento y ser capaz de mantenerse cargado para poder continuar recolectando. 1.5 explicamos que es la odometr´ ıa.6 describimos c´ omo estructuramos el controlador del robot para que podamos ir desarrollando y probando el mismo con un simulador y minimizar el trabajo al pasarlo a el robot f´ ısico. y los mostramos en la secci´ on 1.4 detallamos uno por uno los comportamientos que elegimos para que posea el robot. En esta secci´ on de Arquitecturas de Comportamientos detallamos las acciones que deber´ ıa llevar a cabo el robot y c´ omo organizar las mismas para cumplir la meta de recolectar basura y ser aut´ onomo. la definici´ on y composici´ on de los mismos.7. En la secci´ on 1.3 detallamos la arquitectura elegida para llevar a cabo y organizar los comportamientos elegidos.8 sacamos conclusiones de los resultados obtenidos y las dificultades encontradas a lo largo del desarrollo de ´ este proyecto final.1. para qu´ e sirve y qu´ e ventajas y desventajas tiene usarla. En la secci´ on 1. y las ventajas y desventajas de usar la misma. 4 . y sus correspondientes implementaciones en pseudo-c´ odigo. En la secci´ on 1. es decir. debido a que la arena (lugar donde se mueve el robot) es transitado por personas y est´ a al aire libre. Arquitectura de Comportamientos Introducci´ on Como mencionamos en las secciones anteriores.1. Los resultados de performance y eficiencia del controlador desarrollado los obtuvimos de la simulaci´ on. Tambi´ en detallamos el test utilizado para mejorar la eficiencia de la misma. En la secci´ on 1. En la secci´ on 1. el objetivo de ´ este trabajo es desarrollar un robot aut´ onomo y reactivo que recolecte basura en un entorno estructurado pero din´ amico. hasta su implementaci´ on. Finalmente.

al llegar al final de una l´ ınea marcada sobre la arena. Nolfi no explicita 5 .2. analizando similitudes y diferencias entre ambos. Comparando el trabajo de Stefano Nolfi con el nuestro podemos realizar las siguientes comparaciones: Existencia de un dep´ osito: Ambos tienen un dep´ osito en el cual dejar la basura recogida y una forma de identificarla: una fuente de luz usada por Nolfi y en nuestro trabajo.2. Investigaciones previas A continuaci´ on presentamos trabajos realizados por otros autores relacionados en alguna forma con el nuestro.1. La base tiene una fuente de luz asociada y el objetivo Figura 1: Robot Khepera con el m´ odulo Gripper del robot es llevar peque˜ nos objetos a un lugar de dep´ osito. En cuanto a la recarga de la bater´ ıa.1. Una vez obtenido el mismo mediante simulaci´ on en Webots.Stefano Nolfi [6] En este paper se muestra el uso de un Khepera con el m´ odulo Gripper en una arena delimitada por paredes para la recolecci´ on de ”basura”. Para obtener el comportamiento deseado se hace uso de algoritmos gen´ eticos y redes neuronales. Autonom´ ıa: Ambos son aut´ onomos en el sentido que no son manejados por un humano. 1. Se utiliza aprendizaje por refuerzo para asociar las velocidades angulares de las ruedas a los diferentes tama˜ nos de las ”basuras”. Desarrollo de comportamientos no triviales en robots reales : Robot recolector de basura . Dicho robot se puede ver en la figura 1. se lo prob´ o en el Khepera f´ ısico. Primero damos una breve descripci´ on del trabajo del otro autor y luego lo comparamos con nuestro trabajo.

Figura 2: Robot E-puck Reconocimiento del objeto a recolectar: 1. una versi´ on nueva del Khepera. o Control System Arquitecture. La arquitectura propuesta en el paper. Arquitectura de control para un Robot Aut´ onomo M´ ovil Neves And Oliveira [5] Neves y Oliveira describen en su trabajo una arquitectura de control basada en comportamientos para un robot m´ ovil en un ambiente din´ amico. En nuestro trabajo utilizamos un E-puck para la simulaci´ on.2.si es asistida o no. M´ etodo de Recolecci´ on: En el trabajo de Nolfi se utiliza el m´ odulo Gripper” agregado al Khepera. ya que podr´ ıa compararse con un recolector de basura que usa una pala para guardar el residuo en su tacho. De ´ esta forma. el robot se encarga de ir a la base de recarga una vez detectada la falta de energ´ ıa. en nuestro caso. la recolecci´ on se realiza junt´ andolos y la liberaci´ on se realiza ´ separ´ andolos.3) propuesta por Brooks y que usamos al realizar ´ este proyecto. No es el caso de Nolfi. se basa 6 . M´ etodo de aprendizaje: En nuestro trabajo no utilizamos aprendizaje por refuerzo o algoritmos evolutivos. Esta forma de recolectar est´ a basada en el comportamiento humano. Robot Utilizado: Como mencionamos anteriormente. Este m´ odulo simula un brazo con dos dedos.2. pero sin el m´ odulo Gripper. que utiliza ambas t´ ecnicas para evolucionar el comportamiento deseado. utilizando muchos aspectos de la arquitectura Subsumption (Ver secci´ on 1. Nolfi utiliz´ o un Khepera en la simulaci´ on. Nuestro trabajo se basa m´ as en la actividad humana para realizar la recolecci´ on.

donde el sistema es visto como una sociedad de agentes. 7 . La forma en que es implementada por los autores es mediante un POMDP.2. tal como lo es el ambiente en el cual navegar´ a nuestro robot. Sin embargo. una secuencia de acciones de forma tal que a partir de un punto de origen se llegue al punto de destino. La arquitectura est´ a compuesta por tres niveles: un nivel reflexivo. como por ejemplo el evitamiento de obst´ aculos y otros podr´ ıan incluirse en la segunda capa de comportamientos reactivos. siempre tratamos de mantener los comportamientos del robot lo m´ as reactivos posibles. escrita por Minsky [4]. Navegaci´ on predictiva de un robot aut´ onomo . Por el contrario. en el nivel cognitivo. act´ uan directamente como est´ ımulo-respuesta.3.2. que es tratar el wandering de forma separada del comportamiento de ´ evitamiento de obst´ aculos. 1. en parte. Debido a la componente din´ amica de nuestro trabajo. no utilizamos ´ esta organizaci´ on de los comportamientos en capas. se encuentran los agentes encargados de guiar y administrar los comportamientos reactivos de forma tal que el robot muestre un comportamiento orientado.tambi´ en en la teor´ ıa de The Society of Mind.Foka And Trahanias [3] La navegaci´ on predictiva nace como una posible soluci´ on al problema de un robot navegando en un ambiente con muchas personas y obst´ aculos. El nivel reflexivo incluye aquellos comportamientos innatos. Cabe destacar estas dos u ´ltimas palabras. cada uno con una competencia particular y que colaboran entre ellos para ayudar a la sociedad a alcanzar su meta. Esto. ambos comportamientos tienen niveles de jerarqu´ ıa muy diferentes como se puede ver en la figura 6. Path Planning usando Algoritmos Gen´ eticos .Salvatore Candido [2] En este paper se describe la utilizaci´ on de algor´ ıtmos gen´ eticos para resolver ´ el problema de Path Planning. siguiendo ese plan. En este caso. 1. el uso de algor´ ıtmos gen´ eticos puede ser una herramienta que se podr´ ıa llegar a usar en una futura continuaci´ on de nuestro trabajo. se utiliza el POMDP para manejar tanto la navegaci´ on del robot como el evitamiento de obst´ aculos. Finalmente en la u ´ltima capa estar´ ıa el reconocimiento de objectos debido a su gran demanda de procesamiento. Finalmente. un punto en que se diferencia de lo que propusimos nosotros. uno reactivo. ya que indican la naturaleza del ambiente: hay incertidumbre o falta de informaci´ on acerca de ciertas variables del entorno.4. como ser´ ıa deambular. El segundo nivel. un proceso de decisi´ on de markov parcialmente observable. es decir. Aunque la arquitectura explicada es similar a la utilizada en nuestro trabajo. por lo que armar un plan no ser´ ıa la mejor opci´ on a utilizar. est´ a compuesto por agentes que responden r´ apidamente a los est´ ımulos ya que requieren poco nivel de procesamiento. el reactivo. Este consiste en armar un plan. se debi´ o a causa de la arquitectura utilizada ya que desde ese punto de vista. podemos divisar que algunos de los comportamientos que propusimos corresponden a la primera capa de reflexi´ on. y otro cognitivo. aumentando la complejidad al igual que el orden en que fueron presentados. es decir.

1.2.5.

Algoritmo de navegaci´ on y evitamiento de obst´ aculos en un entorno desconocido - Clark Et. al [7]

En este paper se presentan dos algoritmos complementarios para la navegaci´ on en ese tipo de entornos. El primero consiste en la navegaci´ on y un mapeo del entorno que garantiza una cobertura completa de una arena cuyas ubicaciones de la paredes no se conocen a priori. Consiste b´ asicamente en un seguimiento de las paredes complementado por una variaci´ on de flood filling para asesgurarse la cobertura completa de la arena. El algoritmo completo se puede apreciar en la figura 3.

Figura 3: Algoritmo propuesto por Clark Et. al Un aut´ omata con aprendizaje estoc´ astico es el algoritmo que complementa al primero, y su objetivo es el evitamiento de obst´ aculos. Para ´ esto, se utiliza un mecanismo de recompensa/castigo de forma tal que se adapten las probabilidades de las acciones a tomar. En relaci´ on con nuestro trabajo, hay ciertas similitudes y diferencias, enumeradas a continuaci´ on: Ambos presentan un mecanismo de “seguimiento de”, en nuestro caso lo hacemos con l´ ıneas, en el paper se utiliza con paredes. Sin embargo, se utilizan para objetivos diferentes. Nosotros lo usamos para dirigirnos a la base ya que tratamos de mantener el conocimiento que el robot tiene sobre el mundo lo m´ as acotado posible. En el paper se utiliza el mecanismo de seguir las l´ ıneas para obtener un modelo del mundo, algo que puede llegar a servir mucho en ambientes no tan din´ amicos como el nuestro, raz´ on por la cual no elegimos implementarlo. Tambi´ en coincidimos con la existencia de un m´ etodo para evitar obst´ aculos. En el paper se implementa como un aut´ omata que va aprendiendo seg´ un los premios o castigos que recibe. En nuestro caso el comportamiento es puramente reactivo y reacciona en base a los valores de los sensores de distancia y no tiene memoria.

8

1.3.

Arquitectura propuesta

Una arquitectura basada en comportamientos define la forma en que los mismos son especificados, desde su granularidad (qu´ e tan complejo o simple es un comportamiento), la base para su especificaci´ on, el tipo de respuesta y la forma en que se coordinan. La arquitectura que elegimos para desarrollar nuestro trabajo es Subsumption, desarrollada por Rodney Brooks[1] en 1985. Esta arquitectura est´ a basada en comportamientos puramente reactivos, rompiendo as´ ı con el esquema que estaba de moda en la ´ epoca de sensar-planear-actuar. Algunos de los principios propuestos que tuvimos en cuenta durante el desarrollo de nuestro trabajo son: Un comportamiento complejo no es necesariamente el producto de un complejo sistema de control, El mundo es el mejor modelo de ´ el mismo, La simplicidad es una virtud, Los sistemas deben ser construidos incrementalmente. Cada comportamiento es un conjunto de pares est´ ımulo-respuesta. Tal como mostramos en la figura 4, cada est´ ımulo o respuesta puede ser inhibido o suprimida por otros comportamientos activos. Adem´ as cada comportamiento recibe una se˜ nal de reset, que lo devuelve a su estado original. El nombre Subsump-

Figura 4: Esquema de comportamiento

tion proviene de la forma en que los comportamientos son coordinados entre s´ ı. Hay una jerarqu´ ıa donde los comportamientos de la arquitectura tienen mayor o menor prioridad seg´ un su posici´ on. Los comportamientos de los niveles inferiores no tienen conocimiento de los comportamientos de las capas superiores. Gracias a ´ esto, se puede plantear un dise˜ no incremental, brindando flexibilidad, adaptaci´ on y paralelismo al desarrollo e implementaci´ on de los comportamientos. La idea a seguir es que el mundo sea el principal medio de comunicaci´ on entre los ´ comportamientos. Esto se debe a que la respuesta de un comportamiento ante un est´ ımulo resulta en un cambio en el mundo y, por lo tanto, en la relaci´ on del 9

robot con el mismo. De ´ esta manera, el robot en su pr´ oximo paso sensar´ a otro estado del mundo. El procedimiento b´ asico para dise˜ nar y desarrollar comportamientos para robots con esta arquitectura es sencillo: 1. Especificar cualitativamente la forma en que el robot responde al mundo, es decir, el comportamiento que realizar´ a. 2. Descomponer la especificaci´ on como un conjunto de acciones disjuntas. 3. Determinar la granularidad del comportamiento, analizando en que nivel de la jerarqu´ ıa existente se encontrar´ a y cuantas acciones disjuntas es necesario llevar a cabo para el cumplimiento de la tarea. Un ejemplo de esta arquitectura se puede observar en la figura 5. En la misma hay 4 comportamientos: Homing, Pickup, Avoiding y Wandering. Las l´ ıneas que entran a cada comportamiento son los est´ ımulos ante los cuales se activan y las salidas son las se˜ nales de respuesta correspondientes. La se˜ nal de respuesta de la arquitectura es la l´ ınea que sale por la derecha de la caja (Arquitectura) que contiene la relaci´ on entre los comportamientos. Puede verse como Homing inhibe la salida de Pickup ya que su salida entra al supresor (denotado con un c´ ırculo con una S dentro) de la salida de Pickup y por lo tanto, las salidas de los dem´ as comportamientos, ya que su prioridad es mayor al resto. En el caso que no est´ en presentes los est´ ımulos de Homing, Pickup y Avoiding, no hay inhibici´ on en la salida de Wandering, y por lo tanto se lleva a cabo el comportamiento de Wandering.

Figura 5: Ejemplo de la arquitectura Subsumption

10

al ser aut´ onomo. a su sencillez. Comportamientos e implementaciones Una vez que decidimos utilizar la arquitectura explicada en la secci´ on 1.4. Tambi´ en tomamos la decisi´ on de elegir como comportamiento activo en el instante t.6) e Ir hacia basura (1. Primero implementamos Wandering debido. Como el comportamiento de recolectar e ir hacia la basura dependend´ ıa del m´ odulo de reconocimiento de objetos y el mismo estaba siendo desarrollado en paralelo.3 para nuestro proyecto. En la figura 6 mostramos los comportamientos implementados y su orden de jerarqu´ ıa.4. Se puede ver que hay m´ as comportamientos de los detallados anteriormente ya que la forma en que implementamos los comportamientos b´ asicos del robot requiri´ o el desarrollo de otros auxiliares. Comportamientos a realizar.4. debe poder ser capaz de recargarse solo para poder continuar con su actividad. Ordenes de inhibici´ on y supresi´ on entre los mismos. el robot debe ser capaz de navegar sin chocarse contra las paredes ni con las personas que circulan por el mismo.4. aquel comportamiento que est´ e activo en ese instante y tenga mayor ID.4) Recargar bater´ ıa (1.8): Por ser aut´ onomo. Orden de implementaci´ on Para implementar la arquitectura decidimos asignarle un ID num´ erico diferente a cada comportamiento. Wandering (1. De aqu´ ı se infieren algunos de los comportamientos que debe tener el robot: Recolectar basura (1. Luego implementamos Evitamiento de obst´ aculos para lograr que el robot pueda navegar sin problemas por el entorno. en una primera aproximaci´ on.4.4.4.1.3). Como requerimiento de nuestro proyecto ten´ ıamos la realizaci´ on de un robot aut´ onomo que recolecte basura de su entorno din´ amico1 pero estructuralmente est´ atico2 .1): El robot. El comportamiento de recolectar basura y el requerimiento de la autonom´ ıa llevan a su vez a la aparici´ on de m´ as comportamientos: Descargar basura (1. decidimos implementar el comportamiento de Recargar bater´ ıa y Descargar basura. no es radio-controlado y debe poder recorrer el entorno por s´ ı mismo. Una vez 1 Con entorno din´ amico nos refererimos a que es concurrido por personas y es al aire libre.9): Debido a la naturaleza din´ amica del entorno. Forma de implementaci´ on de los mismos. suprimiendo as´ ı el resto de los comportamientos (con un ID menor) que podr´ ıan estar activos. tuvimos que analizar: Forma de implementaci´ on de la arquitectura en c´ odigo. Evitamiento de obst´ aculos (1. por lo que el viento puede mover ciertos objetos 2 Con estructuralmente es´ atico nos referimos a que sus l´ ımites no var´ ıan ya que est´ a rodeado por paredes 11 .

Wandering Detalle del comportamiento Por ser el comportamiento que menor jerarqu´ ıa tiene (Ver figura 6).4. por cada zona de la arena s´ olo mantenemos el timestamp de la u ´ltima vez que el robot la visit´ o.1.1. hicimos uso de la c´ amara para redefinir la idea de zona recorrida. 1.4.3. decidimos mantener al m´ ınimo la informaci´ on almacenada para el funcionamiento del algoritmo. s´ olo nos preocupamos por ir hacia adelante ya que eventualmente. 1. en cierta forma. Los resultados de la simulaci´ on nos indicaron que el robot no recorr´ ıa ciertas zonas o las recorr´ ıa despu´ es de un largo tiempo. La misma lleva un seguimiento de los lugares que m´ as recientemente recorri´ o el robot. es decir. En una primera aproximaci´ on de Wandering. 12 . genera un modelo del mundo. asegur´ andonos que siempre haya por lo menos un comportamiento activo. o La zona fue alcanzada por la imagen que se ve en la c´ amara (Ver figura 8) ´ Esto. Para minimizar el conflicto.Figura 6: Arquitectura de comportamientos implementada que tuvimos la primera implementaci´ on funcional del reconomiento de objetos. procedimos a desarrollar Ir hacia basura y Recolectar Basura. un hecho que conflict´ ua con uno de los principios propuestos a seguir en la secci´ on 1. Decimos que el robot recorri´ o cierta zona si: Estuvo f´ ısicamente en ella. el robot encuentra un obst´ aculo y realiza un giro cambiando su direcci´ on. es el u ´nico comportamiento que est´ a activo ante la ausencia de un est´ ımulo. as´ ı como su implementaci´ on en pseudo-c´ odigo y detalles tenidos en cuenta para su realizaci´ on. Adem´ as. A continuaci´ on detallamos los comportamientos indicados en la figura 6.1. lo que nos llev´ o a una segunda implementaci´ on.

2. necesitamos de la altura Ch a la cual est´ a ubicada la c´ amara en el robot.zona) ultima_zona_visitada = pedir_ultima_zona_visitada(modelo_del_mundo) velocidades = calcular_velocidades_de_ruedas(ultima_zona_visitada) poner_velocidades_en_ruedas(velocidades) Para obtener la zona vista por la c´ amara.4. el campo de visi´ on (de ahora en adelante Field of View o FOV ) horizontal F OVh o vertical F OVv y el ´ angulo de inclinaci´ on de la c´ amara ac.1.1. Analizando la figura 7 podemos ver que: Figura 7: Diagrama de posici´ on de la c´ amara F OVv +θ 2 π γ + F OVv + θ = 2 d tan(γ ) = Ch d+h tan(γ + F OVv ) = Ch ac = Organizando las ecuaciones. Implementaci´ on del comportamiento La implementaci´ on en pseudo-c´ odigo es la siguiente: por cada paso zona = pedir_zona_vista(camara) marcar_zona_como_vista(modelo_del_mundo. podemos deducir que: π F OVv − ac − 2 2 d = tan(γ ) ∗ Ch (1) (2) (3) (4) γ= (5) (6) (7) d + h = tan(γ + F OVv ) ∗ Ch 13 .

y teniendo en cuenta el principio enunciado en la secci´ on 1. sin desaprovechar la oportunidad de recogerla. podemos obtener los puntos A. De aqu´ ı surge el comportamiento Enfocar Basura. la posici´ on del robot P y bas´ andonos en la figura 8.2. C y D del trapezoide que determina la zona que ve la c´ amara. Esto se debe a que la distancia hacia dichas esquinas es mayor a la distancia hacia el centro del borde superior de la imagen (ver figura 8). hay que elegir la forma en que el robot se dirige hacia la basura. Una segunda forma de lograr ´ esto (figura 10) no consiste en enfocar la ba´ sura.3 “La simplicidad es una virtud”. elegimos implementarlo. Figura 8: Zona vista por la c´ amara 1. como mostramos en la figura 11. ya que una vez que se pierde de vista la basura. Esto requiere que se establezcan las velocidades correspondientes a las ruedas de forma tal que la trayectoria del robot describa dicho arco. sino que se marca un arco hacia la misma. a pesar de tener un posible inconveniente. Enfocar Basura Una vez que el m´ odulo de detecci´ on de objetos reconoce algo como basura (ver secci´ on ??). En la figura 9 mostramos una aproximaci´ on. la basura volver´ a a aparecer en la imagen. pero si luego se dirige hacia adelante (por la activaci´ on de alg´ un otro comportamiento). la distancia desde la posici´ on de la c´ amara hasta el final de la im´ agen. Cuando hay una basura en alguna esquina superior de la imagen de la c´ amara. Dado que la primera aproximaci´ on es m´ as simple de implementar.Por lo que obtenemos el ´ angulo hasta el inicio de la im´ agen de la c´ amara γ y como consecuencia. y el robot gira sobre s´ ı mismo para enfocarla. Decimos que es un “posible” problema. el robot no enfocar´ a m´ as debido a que el est´ ımulo desapareci´ o. la distancia d desde la posici´ on de la c´ amara hasta el inicio de la im´ agen y d + h. la basura puede lle´ gar a perderse por el fondo de la imagen. Consiste en primero enfocar la basura de forma tal que la misma quede en el centro de la imagen de la c´ amara. 14 . B . Con esta alternativa no har´ ıa falta un comportamiento para que el robot enfoque la basura. Usando estos datos.4.

Figura 10: Segunda aproximaci´ on de “Ir a la basura”. Figura 11: Posible inconveniente con la primera aproximac´ ıon de “Ir a la basura”. Inicialmente el objeto reconocido como basura se encuentra a un costado del eje vertical de la imagen. El robot la enfoca. La basura se encuentra en una de las esquinas superiores de la im´ agen. Se traza un arco hacia el objetivo de forma tal que no sea necesario enfocar la basura.Figura 9: Primera aproximaci´ on de “Ir a la basura”. girando hacia la derecha y la basura desaparece de la imagen. la basura volver´ a a aparecer en la im´ agen. Luego el robot gira de forma tal que el objeto quede sobre el eje vertical. 15 . En el caso que el robot se dirija hacia adelante.

Implementaci´ on del comportamiento Para la implementaci´ on se sigue el siguiente pseudo-c´ odigo : por cada paso lista_de_basuras = obtener_lista_de_basuras(modulo_de_reconocimiento) basura_mas_cercana = elijo_basura_mas_cercana(lista_de_basuras) angulo_a_basura = obtener_angulo(basura_mas_cercana) velocidad = VELOCIDAD_BASE * (abs(angulo_a_basura) / (PI/2)) + VELOCIDAD_BASE_MINIMA si angulo_a_basura < 0 entonces veloc_izq = -velocidad veloc_der = velocidad sino veloc_izq = velocidad veloc_der = -velocidad fin_si poner_velocidades_en_ruedas(veloc_izq.4. veloc_der) Se puede ver que la velocidad de giro del robot es proporcional al m´ odulo del a ´ngulo que hay hacia la basura. derecha y centro inferior de la im´ agen.1. Para ´ esto realiza una transformaci´ on en la cual obtiene la distancia al objeto seg´ un su coordenada (x.2. a su vez. logrando enfocar m´ as r´ apido cuando el ´ angulo es mayor y tener mayor precisi´ on cuando el ´ angulo es m´ as chico. lo calculamos como: b= dy 2 + Ch2 16 (10) (9) . puede calcularse mediante la siguiente ecuaci´ on: db = dx2 + dy 2 (8) Dado que los valores de dx y dy no son conocidos. Esta. Como observamos. Las verdes indican lo mismo pero para la parte superior de la im´ agen. Detalle del comportamiento La primer aproximaci´ on se puede describir como: Si la basura est´ a a la izquierda de la im´ agen. el algoritmo enfoca la basura que se encuentra m´ as cerca del robot. adem´ as de tener mayor rapidez de enfoque y precisi´ on que si la velocidad de giro fuera constante. nos ayudamos con la figura 13. En la figura 12 podemos apreciar mejor el ´ area vista por la c´ amara.2. Las l´ ıneas azules marcan los segmentos hacia las esquinas izquierda. y ) en la im´ agen. se debe girar hacia la derecha Si la basura est´ a en el centro. ya est´ a enfocada 1.2. delimitada por el trapecio gris. se debe girar hacia la izquierda Si la basura est´ a a la derecha de la im´ agen.1. podemos afirmar que: α dx = 2b sin( ) 2 donde b. En rojo se pueden ver los tri´ angulos formados hacia una basura ´ a distancia db.4. Descomponiendo la misma en la figura 14.

reemplazamos en 8 y obtenemos la distancia hacia el objeto. Este se obtiene como β = kF OVv donde k = Crhy que se corresponden con la distancia en pixels sobre el eje y y la resoluci´ on vertical de la imagen respectivamente. estamos en condiciones de calcular tanto la ecuaci´ on 10 como 9 y finalmente. Para el c´ alculo de la ecuaci´ on 9 tambi´ en es necesario el valor de α el cual h x obtenemos como α = k F OV donde en este caso k = 0dist 2 .5Crh y F OVh se corresponden con la distancia en pixeles sobre el eje x y el field of view horizontal de la c´ amara imagen. En la figura 15 17 . El c´ alculo de k puede apreciarse mejor en la figura 17.donde Ch representa la altura de la c´ amara y es un valor conocido. Habiendo obtenido estos valores. utilizando estos resultados. ´ Figura 12: Area vista por la c´ amara y distancias y ´ angulos Para el c´ alculo de dy tenemos que recurrir a la ecuaci´ on 7 donde reemplazamos F OVv por β que es el ´ angulo vertical que forma la c´ amara con el dist ´ objeto en cuesti´ on.

Detalle del comportamiento El est´ ımulo necesario para que este comportamiento est´ e presente. 1. 18 . ya que luego de ser enfocada. El m´ etodo de reconocimiento de objetos encontr´ o una basura 2. Ir a Basura Luego de la elecci´ on de la forma en que se resuelve el problema de encontrar una basura (ver figura 1.4.1.4. La basura se encuentra en un entorno del centro del eje vertical de la im´ agen obtenida de la c´ amara. la basura est´ a delante del robot y s´ olo basta ir hacia adelante. Figura 14: Descomposici´ on de figura 13 1. el comportamiento de ir a basura resulta trivial.3.3.Figura 13: Caso particular de distancia hacia una basura a distancia db podemos observar los arcos de distancia hacia cada punto de la im´ agen.2). est´ a dado por dos condiciones: 1.4.

En la figura 16 se pueden ver 2 valores distintos para el umbral.DIST_MIN) veloc_der = VELOCIDAD_MIN*(1 . entonces se la toma como enfocada.Crh ) es γ + F OVv y hacia el m´ as bajo. m´ as lejana est´ a.2. Como mostramos en las figuras 17 y 7. Cuanto m´ as clara la zona.3.2.4. Para decidir si una basura se encuentra en un entorno del eje vertical. Implementaci´ on del comportamiento por cada paso distancia = obtener_distancia_a_basura(modulo_de_reconocimiento) coeff = (distancia . el ´ angulo vertical hacia el punto m´ as alto de la imagen (0.Figura 15: Distancias a pixeles en imagen seg´ un la variaci´ on de color. vaya disminuyendo linealmente.4.2. las velocidades que se le otorgan a las ruedas dependen de la distancia hacia la basura. 19 . 1. utilizamos un umbral δf que determina el ´ angulo de abertura. de forma tal que si una basura est´ a muy lejos. la velocidad sea mayor y a medida que se va acercando. veloc_der) Al igual que en la implementaci´ on del comportamiento 1. Si una basura se encuentra en la zona.coeff) + coeff*VELOCIDAD_MAX veloc_izq = veloc_der poner_velocidades_en_ruedas(veloc_izq.0).DIST_MIN)/(DIST_MAX . Los arcos marcan distancias dentro de un mismo rango de valores. (0. Dado que la basura se encuentra en un entorno del eje Y en la imagen (Ver figura 17b) cometemos un error muy peque˜ no al estimar la distancia a la basura como si estuviera sobre el mismo (asumiendo que la coordenada X de la basura en la imagen es 0). el ´ angulo es γ .

Por problemas con la simulaci´ on de este procedimiento. su nueva coordenada est´ a dada por (x − Crw/2. (11) (12) Figura 17: Conversi´ on de coordenadas de imagen de c´ amara. buscamos otro mecanismo.Crh − y ) 1.4.x).Figura 16: Distintos δf De las ecuaciones (6) y (7) sabemos las distancias a los puntos (0.4. En un principio pensamos en usar una rampa interna dentro del robot. Entonces. Recolectar Basura Una vez que el robot lleg´ o a estar posicionado para recolectar la basura deseada. de forma tal que la basura suba esa rampa para luego caer en un dep´ osito interno. el comportamiento de recolectar basura se activa. 20 . El mecanismo para lograr ´ esto fue cambiando a lo largo del desarrollo del proyecto.y ) basta con calcular: y h dy = tan(γ + yangle ) ∗ Ch yangle = F OVv ∗ donde yangle es la proporci´ on de F OVv hacia y .Crh ) son (DIST MIN) y (DIST MAX) respectivamente. para obtener la distancia dy hacia el punto (0. El mecanismo que elegimos para usar en la simulaci´ on tiene estas componentes: El robot tiene un servo en su parte posterior (debajo de la c´ amara) Dos paredes delimitan el espacio a lo largo de la direcci´ on que une el centro del robot con el servo anteriormente mencionado. Dado un pixel (y .0) y (0.

4.4. surge como necesidad que el robot sea capaz de ir hacia una zona donde descargar´ a la basura que contiene. Entonces. Es importante la elecci´ on del umbral: un valor muy chico. al llenarse el dep´ osito surge el est´ ımulo 21 . Pr (t) y el instante t + 1.4.2. cercano a DIST MAX.3. Ir a zona de descarga de basura Como la capacidad del dep´ osito interno de basura del robot tiene un l´ ımite. Implementaci´ on del comportamiento El pseudo-c´ odigo de este comportamiento es el siguiente: distancia = obtener_distancia_a_basura(modulo_de_reconocimiento) levantar(servo_delantero) recorrer_distancia(distancia) cerrar(servo_delantero) La distancia hacia la basura es obtenida de la misma forma que en la secci´ on 1. 1. Las diferentes etapas de la recolecci´ on de una basura las detallamos en la figura 18. Detalle del comportamiento La activaci´ on de recolectar basura depende de 3 condiciones: Las dos condiciones impuestas para ir a basura La distancia a la basura elegida para ser recolectada debe ser menor a un umbral. un valor muy grande.1.1. puede llevar a que el comportamiento no se active porque la basura ya no est´ a m´ as en la imagen. Levantar y cerrar el servo consiste en establecer su posici´ on en π 2 y 0 respectivamente.5).2.4. Por otro lado. cercano a DIST MIN.5. causar´ ıa que el robot se disponga a recolectar una basura que est´ a muy lejos y podr´ ıa llegar a moverse por cuestiones propias del ambiente. Para calcular la distancia recorrida utilizamos la distancia entre la posici´ on del robot en el instante t.4.4. llevando as´ ı a una innecesaria activaci´ on del comportamiento. Aqu´ ı se puede observar que tan importantes son los comportamientos anteriores para que el robot logre recolectar la basura. ambas dadas por la odometr´ ıa (Ver secci´ on 1. Figura 18: Etapas de recolecci´ on de basura 1. Pr (t + 1).

Entrar a la l´ ınea y finalmente Seguir la l´ ınea.1. es necesario: Buscar la l´ ınea e ir a la misma Entrar a la l´ ınea de forma tal que el robot y la l´ ınea queden alineados Seguir la l´ ınea Siguiendo con la idea que es mejor descomponer un comportamiento complejo en otros m´ as simples. Por lo tanto para dirigirse a la zona de descarga de basura. por lo que decidimos dejar s´ olo 2 las l´ ıneas que se encuentran a la misma distancia. Esta implementaci´ on. Un ejemplo de ´ esta situaci´ on se puede observar en la figura 19. La zona de descarga 22 . Buscar l´ ınea Inicialmente hab´ ıamos dispuesto las l´ ıneas de forma tal que sigan los l´ ımites de la arena.4.5. el robot recorr´ ıa m´ as distancia para llegar a la zona de recarga que si hubiera elegido otra l´ ınea. decidimos separar el comportamiento de Ir a zona de descarga de basura en 3 comportamientos m´ as simples: Buscar l´ ınea. Figura 19: Primer aproximaci´ on de la arena de simulaci´ on Luego repensamos el problema y nos dimos cuenta que el objetivo era llegar a la zona de descarga. como se puede apreciar en la figura 20. Entonces para buscar la l´ ınea tuvimos que calcular para cada una cu´ al es la distancia hacia la misma y luego elegir ir a la que menor distancia se ´ encontraba. ten´ ıa un problema: a veces suced´ ıa que al elegir ir hacia la l´ ınea m´ as cercana. lo lleve a la zona de descarga.necesario para la activaci´ on de este comportamiento. adem´ as de ser costosa. 1. Esta condici´ on consiste en poner l´ ıneas de forma tal que si el robot la sigue. Para ir hacia dicha zona decidimos imponerle una condici´ on al entorno donde el robot actuar´ a.

La distancia desde el sensor del medio hacia el centro √ del robot es a.4.4. nos facilit´ o la composici´ on de ´ este comportamiento.1. Para distinguir si el robot est´ a en una l´ ınea o no.1.5. para ir a la l´ ınea se debemos girar hasta tener un ´ angulo de π 2 y luego ir hacia adelante. Como mostramos en la figura 20. 1. PI/2) entonces si angulo_actual > PI/2 && angulo_actual < 3PI/2 entonces giro_sentido_horario sino giro_sentido_antihorario fin si sino 23 . mientras que la distancia hacia un sensor del costado es F sl = F sd2 + F ss2 . Detalle del comportamiento La decisi´ on de dejar s´ olo dos l´ ıneas. Los sensores se encuentran a una distancia F sd del centro del robot sobre el eje Y y aquellos de los costados a una distancia F ss del eje Y .se ubica cerca de donde se encuentra el cilindro de color verde. acompa˜ nada por la elecci´ on de la ubicaci´ on de la zona de descarga.2. ya que no requiere c´ alculos extras: por cada paso angulo_actual = obtener_angulo_actual(odometria) si esta_en_un_entorno_de(angulo_actual.1.5. Figura 20: Arena de simulaci´ on y ejes de coordenadas 1. Implementaci´ on del comportamiento El pseudo-c´ odigo de este comportamiento es sencillo. utilizamos sensores de piso dispuestos como se muestra en la figura 21.

girando a la izquierda o a la derecha dependiendo cual sea el caso. debido a esa magnitud. En principio esto requiere que el robot tenga conocimiento acerca de la ubicaci´ on de la base. ¿ porqu´ e no se usaron los datos de la misma para ir hacia la base?”. cuando en realidad girando para el sentido contrario s´ olo tendr´ ıa que girar π . Para ver esto m´ as claramente. 24 . en este caso.1 se puede ver la incidencia de un error grande de la odometr´ ıa en el comportamiento emergente del robot.Figura 21: Disposici´ on de sensores de piso voy_hacia_linea fin si 3π Hicimos la verificaci´ on de que el ´ angulo est´ e entre π 2 y 2 para evitar girar m´ as de π .PI/2) entonces giro_sentido_antihorario sino π En el caso que el angulo actual sea π . algo que no concuerda con la arquitectura elegida. Es importante destacar el uso de datos calculados por la odometr´ ıa porque si la misma llega a tener un error grande. 2 Se puede observar en el c´ odigo que usamos datos calculados por la odometr´ ıa. En la secci´ on 1.5. el robot girar´ ıa un total de 32 hasta llegar π al ´ angulo destino 2 . Decimos que la odometr´ ıa tiene un error grande cuando. Por otro lado. El lector se podr´ ıa preguntar: “Si la odometr´ ıa tiene la posici´ on actual del robot. la orientaci´ on actual del robot. puede llevar a una activaci´ on err´ onea de comportamientos. el robot no toma las decisiones correctas debido al error en la informaci´ on en la cual se bas´ o. veamos que sucediese si no estuviera: si esta_en_un_entorno_de(angulo_actual. se hubiera tenido que utilizar alg´ un algoritmo de Path Planning para realizar el recorrido.

4. 1.5. cualquiera sea el estado de los sensores de los costados.2. entonces el robot no gira.2. 25 . Implementaci´ on del comportamiento angulo_final = obtener_angulo_final(obtener_linea(odometria)) tita = atan(dist_sens_piso_X.5.1.1. Luego del posible giro para lograr que el sensor de piso del medio quede sobre la l´ ınea. De ´ esta forma s´ olo queda girar nuevamente hacia el ´ angulo que se quiera.4. 1. el robot deber´ a girar dependiendo de que lado se encuentre la misma (Ver figura 20).5. dist_sens_piso_Y) si (esta_en_la_linea(sensor_piso(DERECHA))) entonces tita = -tita fin si si (esta_en_la_linea(sensor_piso(MEDIO))) entonces tita = 0 fin si si (tita != 0) entonces girar(tita) fin si distancia_a_recorrer = dist_sens_piso_Y.angulo_final)) El primer giro del robot es para lograr que el segmento que une el sensor de piso del medio con el centro del robot quede ortogonal al segmento de l´ ınea.4. El ´ angulo que debe girar est´ a dado F ss por θ = arctan( F sd ) (Ver figura 21) si debe girar hacia la izquierda. o −θ en el otro caso. Notar que si el sensor del medio est´ a en la l´ ınea. Entrar a l´ ınea Detalle del comportamiento Para seguir la l´ ınea es necesario que primero el robot est´ e posicionado sobre ella y alineado con la misma. Una vez en la l´ ınea.2.2.4. s´ olo basta con seguirla para llegar hacia la zona deseada.5. como es el caso de la figura 22c. si (tita != 0) entonces distancia_a_recorrer = sqrt(dist_sens_piso_X^2 + dist_sens_piso_Y^2) fin si recorrer(distancia_a_recorrer) angulo_actual = obtener_angulo(odometria) girar(normalizar(angulo_actual .3. Como mostramos en la figura 22. en el caso (a) y (b) el robot girar´ a de forma tal que llegue un caso parecido al que mostramos en la figura 23 ya posiblemente el sensor del medio no estar´ a en la l´ ınea. Seguir l´ ınea Una vez que el robot est´ a posicionado y con el sensor del medio sobre la l´ ınea. se recorre una distancia de F sd en el caso que el robot no haya girado anteriormente o F sl en el caso que s´ ı lo haya hecho. Si la l´ ınea est´ a marcada a la izquierda en la arena (Ver figura 20) entonces el robot deber´ a girar hasta que su orientaci´ on sea 0 o π en el caso que la l´ ınea sea la derecha. Tambi´ en se necesita que la direcci´ on del robot sea la que lo lleve hacia la zona de descarga. El motivo de realizar este trayecto es que el centro del robot quede sobre la l´ ınea. 1. Este comportamiento es sencillo de desarrollar. como muestra la figura 24.

Figura 22: Posibles estados iniciales de “Entrar a la l´ ınea”. el robot debe girar en sentido anti-horario. En el caso (c) el robot no debe girar Figura 23: Posible estado final luego del primer giro del comportamiento “Entrar a la l´ ınea” Figura 24: Centro del robot sobre la l´ ınea y posibles giros 26 . En el caso (a) el robot debe girar en sentido horario. En el caso (b).

veloc_der) 1. El segundo caso es an´ alogo: para sacar el sensor de la izquierda de la l´ ınea se debe seguir una trayectoria con un peque˜ no angulo hacia la izquierda.FACTOR_DE_GIRO) veloc_der *= (1 + FACTOR_DE_GIRO) fin si si (esta_en_la_linea(sensor_piso(DERECHA))) entonces veloc_izq *= (1 + FACTOR_DE_GIRO) veloc_der *= (1 .3.FACTOR_DE_GIRO) fin si poner_velocidades_en_ruedas(veloc_izq. Para hacer ´ esto decidimos ubicar un servo en la parte trasera del robot.3. El sensor de la izquierda est´ a sobre la l´ ınea En el primer caso se debe lograr sacar el sensor de la derecha de la l´ ınea describiendo un peque˜ no arco hacia ese lado. Implementaci´ on del comportamiento El pseudo-c´ odigo es simple: por cada paso veloc_izq = veloc_der = VELOC_SEGUIR_LINEA si (esta_en_la_linea(sensor_piso(IZQUIERDA))) entonces veloc_izq *= (1 .2.4. 1. deber´ a realizar un giro de π para luego poder descargar la basura.1.2.5.1. El sensor de la derecha est´ a sobre la l´ ınea 2.4. Como el servo de descarga 2 se encuentra en la parte trasera.4. con la misma idea del servo en el frente utilizado para recolectar.1. Detalle del comportamiento Para lograr que el robot siga la l´ ınea debemos tratar de mantener s´ olo el sensor del medio sobre la l´ nea. debe descargarla. Detalle del comportamiento Para descargar la basura el robot debe posicionarse de forma tal que la compuerta de descarga quede adyacente a la zona. ´ 1.6. 1. Descargar Basura Una vez que el robot logr´ o llegar a la zona de descarga de basura.6. al finalizar va a estar orientado con un ´ angulo en un entorno de π mirando la zona de descarga.4. Dado que para llegar a la misma el robot sigui´ o la l´ ınea. Entonces. Implementaci´ on del comportamiento posicionarse() levantar(servo_trasero) recorrerdistancia(ANCHO_ROBOT) cerrar(servo_trasero) 27 .4.6.5. basta con analizar que se debe hacer en los siguientes casos: 1.

El sensor de la computadora que corre el controlador. Su nivel se debe a la importancia que tiene en un ambiente estructurado pero din´ amico como es el nuestro.4. Ir a base de recarga de bater´ ıa Ayudados por la elecci´ on que tomamos de poner la zona de descarga de basura muy cercana a la zona donde se recarga la bater´ ıa.7. debe posicionarse para lograr ubicarse el cargador y esperar hasta que la bater´ ıa alcance un valor de carga tal que le permita seguir buscando basura sin problemas de bater´ ıa.4. En el caso de ir a la zona de descarga. 1. Implementaci´ on del comportamiento posicionarse() mientras(bateria_no_llena(BATERIA_ROBOT) o bateria_no_llena(BATERIA_PC)) hacer esperar(time_step) fin mientras 1. el est´ ımulo proviene del sensor del dep´ osito interno de basura que indica que el mismo est´ a lleno. En el caso de ir a la base de recarga de bater´ ıa.8. Para ´ esto. de donde se alimentan los sensores.8.1. debe recargarse. utilizamos sensores de proximidad explicados en ??. La diferencia entre ambos casos es el est´ ımulo ante el cual se activan. La activaci´ on del comportamiento depender´ a entonces del valor sensado tal que la distancia hacia un obst´ aculo lleve al robot a una colisi´ on o le imposibilite moverse. el est´ ımulo para la activaci´ on depende de los valores de dos sensores de bater´ ıa que indican bater´ ıa baja: El sensor de la bater´ ıa del robot. Cargar Bater´ ıa Detalle del comportamiento Una vez que el robot logr´ o llegar a la zona de recarga de bater´ ıa.9. 1.1.9.4. El objetivo del robot es facilitar una tarea sin entorpecer el tr´ ansito de personas. 1. 28 . decidimos utilizar la misma estrategia de seguir la l´ ınea para llegar hacia la misma.1. el robot deber´ a alejarse de ese lado para evitar un posible choque. Detalle del comportamiento Para lograr tener conocimiento sobre la proximidad de un obst´ aculo. Evitar Obst´ aculos Evitar obst´ aculos es uno de los comportamientos con mayor jerarqu´ ıa en la arquitectura que elegimos.4.4. 1.8. Dependiendo de la proximidad indicada por un determinado sensor.2. actuadores y motores.4.

8 -0. Luego de entrenar la red.6 -0. SENSOR_I) * VALOR(SENSOR_I)) veloc_der *= FACTOR_DE INCIDENCIA poner_velocidades_en_ruedas(veloc_izq. 1 y 2) ubicados en el costado derecho del robot. Implementaci´ on del comportamiento La implementaci´ on de este comportamiento la hicimos utilizando una red neuronal sin capas ocultas (ver figura 25) usando los sensores de distancia como entradas y 2 neuronas de salida indicando los valores a ser seteados en los motores de las ruedas.35 -0.9 W1 -0.1. Este comportamiento. ambos sensores traseros (4 y 5) exitan a ambos motores.6 W4 0.85 0.2 0. Distinto es el caso de los sensores del lado izquierdo (5. veloc_der) Figura 25: Red neuronal entre los sensores de distancia y los motores 29 . SENSOR_I) * VALOR(SENSOR_I)) veloc_izq *= FACTOR_DE INCIDENCIA veloc_der = suma(coeficiente(RUEDA_DER.6 Cuadro 1: Asignaci´ on de pesos para evitar obst´ aculos Se puede ver que los pesos que influyen en el motor de una rueda influyen con igual fuerza pero distinto signo en el motor de la rueda contraria. en pseudo-c´ odigo puede verse como: por cada paso veloc_izq = suma(coeficiente(RUEDA_IZQ.35 W6 0. 6 y 7) que exitan el motor ubicado de su lado e inhiben el motor del lado opuesto.6 0. de forma tal que el robot gire para el lado opuesto de la ubicaci´ on de los sensores. Debemos notar que hay conexiones tanto inhibitorias como excitatorias.2. La misma idea se sigue con los sensores (0.5 W5 0.85 W2 -0.2 W3 0. obtuvimos los siguientes valores para los pesos de la misma: Rueda Izquierda Derecha W0 -0.8 W7 0.5 0.9. Como es de esperarse.4.9 0.

4. Un ejemplo de estas situaciones es el caso donde dos comportamientos se “activan mutuamente”.1.4. Detalle del comportamiento Las situaciones no deseadas se dan la mayor´ ıa de los casos cuando un comportamiento hace girar al robot hacia un lado y el otro comportamiento hacia ´ el lado contrario. Implementaci´ on del comportamiento angulo_actual = obtener_angulo_actual(odometria) nuevo_angulo = angulo_actual + ANGULO_A_SUMAR girar(nuevo_angulo) 30 . La respuesta de salir de situaciones no deseadas es girar un ´ angulo π .4. Con las sucesivas simulaciones observamos que hab´ ıa situaciones donde corr´ ıa peligro la autonom´ ıa del robot. supongamos dos comportamientos A y B con nivel en la jerarqu´ ıa N (A) y N (B ). podr´ ıa llegar a entrarse en un ciclo si es que esta situaci´ on se da por un tiempo prolongado o indeterminado. 1. aproximadamente en la misma magnitud. Los comportamientos C y D se “activan mutuamente” cuando la orientaci´ on del robot es π .10.10. 1. La respuesta del comportamiento es.1. Salir de situaciones no deseadas Salir de situaciones no deseadas surgi´ o como un comportamiento para ayudar al objetivo de crear un robot aut´ onomo.2. por lo que decidimos tomar este hecho como est´ ımulo para la activaci´ on de este comportamiento. Esta u Los comportamientos A y B se “activan mutuamente” cuando la orientaci´ on del robot es 0. Si la respuesta a un est´ ımulo de A lleva a la activaci´ on de B y a la desactivaci´ on de A y luego la respuesta de B lleva a la activaci´ on de A. siendo N (A) > N (B ). El mayor peligro para la autonom´ ıa ocurre cuando A es el comportamiento de evitar obst´ aculos y B es el comportamiento de ir a zona de recarga de bater´ ıa ya que el robot podr´ ıa terminar qued´ andose sin bater´ ıa en ese ciclo. Esto quiere decir que la posici´ on del robot se mantiene alrededor de un punto por un per´ ıodo prolongado de tiempo. girar un ´ angulo que cambie la direcci´ on del robot y adem´ as que la suma de ese ´ angulo repetidas veces no sea peri´ odica o lo sea luego de una gran cantidad de giros como por ejemplo.10. un valor de π ´ltima condici´ on se pide por el siguiente escenario: 4 + 0. Para ver esto m´ as claramente.1.

decidimos realizar el test sobre un e-puck simulado en Webots. usamos las siguientes f´ ormulas: (el (n) − el (n − 1)) ∗ Rl EncRes (er (n) − er (n − 1)) ∗ Rr dr = EncRes dr + dl lc = 2 Pn = Pn−1 + (lc ∗ cos On−1 . la resoluci´ on del encoder EncRes y es la distancia entre ruedas dbw. utilizamos el test del camino bidireccional describiendo un cuadrado (UMBmark) 3 .pdf 31 .umich. Esta t´ ecnica se basa en la medici´ on del encoder en cuentas realizadas por cada motor para obtener el desplazamiento realizado por la rueda asociada.edu/ johannb/Papers/umbmark. Los errores que influyen en el c´ alculo de la odometr´ ıa pueden ser de dos tipos: Sistem´ aticos: Son aquellos que pueden ser corregidos o tenidos en cuenta para disminuir el error. 3 http://www-personal.1. Para calcular la posici´ on Pn en el instante de tiempo n y la orientaci´ on On en base a la posici´ on Pn−1 en el instante (n-1) y la correspondiente orientaci´ on On−1 . As´ ı fuimos obteniendo los valores de correcci´ on para los di´ ametros de las ruedas ci y la correci´ on sobre la distancia entre las ruedas cdbw hasta que el error sistem´ atico m´ aximo dejara de disminuir. la odometr´ ıa da una estimaci´ on del desplazamiento local a la ubicaci´ on anterior del robot. A diferencia de los m´ etodos de posicionamiento absoluto. Ambas son calculadas teniendo en cuenta los valores anteriores y actuales de los encoders ei (n). por lo cual un error en una estimaci´ on se propaga hacia las siguientes estimaciones. En la figura 26 mostramos c´ omo disminuye el error a lo largo de las iteraciones. el radio de la rueda Ri .lc ∗ sin On−1 ) dr − dl On = On−1 + dbw dl = (13) (14) (15) (16) (17) donde dl y dr son las distancias recorridas por las ruedas izquierda y derecha respectivamente. Decidimos tener en cuenta dos errores sistem´ aticos para disminuir el error en la odometr´ ıa : Incerteza sobre la distancia entre las ruedas (dbw) Ruedas con radios diferentes (Rl y Rr ) Tuvimos en cuenta estos errores dado que son los que m´ as contribuyen al error acumulado a lo largo del trayecto del robot.5. Odometr´ ıa Para saber donde se encuentra el robot en cierto momento utilizamos odometr´ ıa. Para corregir estas fuentes de error. Dado que en el momento de realizar el test no ten´ ıamos un robot f´ ısico. No sistem´ aticos: Son aquellos que pueden intentarse corregir pero no eliminar.

205. El resultado esperado era que la odometr´ ıa inicie con un error cercano a 0 y vaya creciendo constantemente a medida que avanzaba la simulaci´ on. 32 . Decidimos entonces simular nuevamente y ver que comportamiento estaba activo en dichos momentos. Fue entonces que decidimos agregar un GPS(con error m´ ınimo y que luego eliminamos) al e-puck en la simulaci´ on con Webots.052 y una resoluci´ on de encoder EncRes = 159.99998703. Problemas con la odometr´ ıa En las simulaciones previas a la presentada en la secci´ on 1. Viendo m´ as en detalle.092171094 para ruedas con radio Rl = Rr = 0. cr = 1. Despu´ es de una extensiva revisi´ on de c´ odigo. una distancia entre ruedas de 0. Nuevamente revisamos el c´ odigo. El resultado no fue el esperado pero si iluminativo: el crecimiento era en partes constante.7 observamos que el comportamiento emergente del robot no era el esperado. con el objetivo de obtener un gr´ afico que indique el error en la odometr´ ıa a lo largo de la simulaci´ on.1. Nos sorprendi´ o ver que en esos momentos el comportamiento activo era Evitar obst´ aculos ya que era uno de los m´ as simples y de los que m´ as ten´ ıamos confianza que no haya un error de l´ ogica de c´ odigo.23. llegamos a la conclusi´ on que el mismo no ten´ ıa problemas. sin encontrar problemas.Figura 26: Error Sistem´ atico M´ aximo a lo largo de las iteraciones En la u ´ltima iteraci´ on obtuvimos los coeficientes de correcci´ on cl = 0. pero hab´ ıa momentos en los cuales crec´ ıa abruptamente.5.00001297 y cdbw = 1. el robot tomaba decisiones err´ oneas en los comportamientos que utilizaban la odometr´ ıa. 1.

Revisando las ecuaci´ ones 13 y 14 nos dimos cuenta de lo siguiente: dado que las correcciones cl y cr de los radios Rl y Rr de las ruedas minimizan el error pero no lo eliminan. de forma tal que no haya saltos de ordenes de magnitud.´ Esto nos llev´ o a pensar qu´ e relaci´ on hab´ ıa entre Evitar obst´ aculos y la odometr´ ıa. 33 . el error de las ecuaciones aumenta proporcionalmente a la diferencia entre ei (n) y ei (n − 1). ya que sirve para cualquier comportamiento. ´ Por el tiempo que dispon´ ıamos en ese momento y por simplicidad y r´ apidez de implementaci´ on. que haya ese tipo de variaciones y no va a poder lograrlo. se haga un c´ alculo con la velocidad seteada anteriormente. dividi´ endolas por una cte. teniamos que buscar una soluci´ on a ´ este problema. es invasiva en parte ya que puede que el desarrollador quiera. Pensamos en dos opciones: 1. Hacer que cada vez que se setee una velocidad. Sin embargo. Finalmente. Cabe aclarar que la segunda opci´ on es m´ as abarcativa y robusta. El comportamiento setea velocidades en las ruedas y la odometr´ ıa utiliza los valores de los encoders de las ruedas. elegimos la primer opci´ on. Y ´ esto suced´ ıa cuando se activaba el evitamiento de obst´ aculos ya que daba velocidades a las ruedas de un orden de magnitud mayor a los que ten´ ıan anteriormente. ya sabiendo la verdadera causa del mismo. por alg´ un motivo. 2. Disminuir las velocidades que Evitar obst´ aculos asignada a las ruedas.

Interfaces con hardware y m´ odulo de reconocimiento de objetos Decidimos hacer que el controlador encargado de realizar los comportamientos sea independiente de la forma con la que se implemente el hardware y el reconocimiento de los objetos. En la implementaci´ on que se comunica con el robot f´ ısico. Esta decisi´ on nos posibilit´ o realizar un controlador que sea capaz de ser ejecutado tanto en Webots. que objetos est´ an siendo reconocidos. necesita conocer en el instante de tiempo t. En la implementaci´ on de la interfaz que corrimos en Webots. y no se estar´ ıa equivocado. Si hubi´ esemos usado alg´ un tipo de conjunto de sensores t´ actiles para reconocer objetos (mano). una c´ amara usada para Visi´ on. De esta forma es cuesti´ on de decidir que implementaci´ on se usa en base a si se quiere correr en un simulador como Webots o en el robot f´ ısico. como en la base real del robot. 1. en nuestro caso. La raz´ on por la cual el m´ odulo de visi´ on est´ a sepa- 34 .1. entre otras cosas.1. s´ olo har´ ıa falta que implementemos la interfaz que cumpla con lo establecido e indicarle a la capa de comportamientos que la utilice para realizar su ejecuci´ on. hicimos llamadas al controlador del simulador. las llamadas las hicimos a un servidor encargado de enviar y recibir paquetes del protocolo descripto en la secci´ on ?? a trav´ es del puerto serial.6. en vez de visi´ on. pero el trabajo demandado es mucho menor ya que una correcci´ on en la l´ ogica de los comportamientos se puede observar tanto en un simulador como en la realidad. Para esto el m´ odulo debe tener una fuente de informaci´ on.6. el m´ odulo de reconocimiento de objetos bien podr´ ıa analizar la informaci´ on que ellos proveen e informar al controlador sobre su an´ alisis. Para ´ esto definimos interfaces para la comunicaci´ on entre el controlador y el hardware y el m´ odulo de reconocimiento de objetos de forma tal que los dos u ´ltimos puedan cambiar su implementaci´ on pero brindando siempre la informaci´ on que necesita el controlador para poder realizar los comportamientos. Desde el punto de vista anat´ omico. Interfaz con m´ odulo de reconocimiento de objetos usando Visi´ on Como el controlador de comportamientos es cliente del m´ odulo de reconocimiento. donde se hizo el desarrollo. Cabe aclarar que el traspaso de la simulaci´ on a la realidad no es instant´ anea. Si quisi´ eramos usar otro simulador u otro tipo de hardware. que utiliza sensores y actuadores simulados. la parte del cerebro encargada de analizar el est´ ımulo recibido (im´ agenes) por los mismos (m´ odulo de reconocimiento) y la parte del cerebro encargada de analizar los est´ ımulos recibidos y realizar las acciones (controlador de comportamientos).6. ´ esto se puede ver como los ojos (c´ amara). ya que hay que calibrar los dispositivos y realizar nuevamente la odometr´ ıa.2. 1. Esta analog´ ıa puede llevar a pensar que los sensores de distancia u otros dispositivos que usamos en este desarrollo bien podr´ ıan formar parte de otro m´ odulo. Interfaz con hardware La interfaz con el hardware se basa en tener clases encargadas de obtener los valores de los sensores o del accionar de los actuadores.

35 .rado y el resto de los sensores no. es que el procesamiento de una secuencia de im´ agenes es muy complejo y demandante. tal como detallamos en la secci´ on ??.

A lo largo del proceso de desarrollo fuimos realizando diferentes simulaciones. Los valores de los par´ ametros que utilizamos los detallamos en el cuadro 2.03 0. correcciones y separaciones.de piso del medio al centro del robot Separaci´ on entre sensores de piso ´ Angulo umbral de basura enfocada Time Step Valor (-0.01 0. un ´ area de recarga de bater´ ıa y un ´ area de descarga de basura.026 0.2 100 38 0.295. as´ ı como tambi´ en los radios.4) 0 0.09217109 0.7. de las cuales observamos defectos en las implementaciones de los comportamientos as´ ı como retardos y detalles que pod´ ıamos mejorar en algunos y que fuimos corregiendo. Par´ ametro Pr (0) Or (0) Rr dbw cdbw Rl Rr cl cr EncRes Cd Ch ´ o Ch F OVh ac Crw Crh Aw Ah Arw Arh F sd F ss δf Ts Descripci´ on del par´ ametro Posici´ on Inicial del robot Orientaci´ on Inicial del robot Radio del robot Distancia entre ruedas Correcci´ on de la distancia entre ruedas Radio de la rueda izquierda Radio de la rueda derecha Correcci´ on del radio de la rueda izquierda Correcci´ on del radio de la rueda derecha Resoluci´ on del encoder Distancia de la c´ amara al centro del robot Altura de la c´ amara Field of view horizontal ´ Angulo de la c´ amara Ancho de la im´ agen obtenida de la c´ amara Alto de la im´ agen obtenida de la c´ amara Ancho del arena Alto del arena Ancho de la grilla Alto de la grilla Dist. A lo largo de la misma hay ubicados 15 objetos que simulan ser basuras.00001297 159.052 1.5 640 480 2 1. Luego presentamos dichos resultados y extraemos conclusiones sobre los mismos.0205 0. La resoluci´ on de la c´ amara la expresamos en pixeles.1 32 Cuadro 2: Par´ ametros utilizados para las simulaciones 36 . la de la grilla en unidades y los tiempos est´ an en milisegundos.-0. s. Resultados obtenidos En esta secci´ on describimos los par´ ametros que utilizamos en la simulaci´ on para obtener los resultados sobre los diferentes comportamientos. marcadas por el cilindro naranja.23 0.038 1.1 -0. La arena utilizada en dichas simulaciones la mostramos en la figura 27.1.99998702 1.0355 0. Los ´ angulos los expresamos en radianes y las distancias las expresamos en metros.0205 0.

El 35.Figura 27: Arena que utilizamos para las simulaciones 1. Distribuci´ on de tiempos y progreso de comportamientos en la simulaci´ on En la figura 28 mostramos la distribuci´ on de time steps en la simulaci´ on de cada comportamiento. Recolectar basura. El progreso describe mesetas cuyas duraciones se 4t es el n´ umero de time step de la simulaci´ on 37 . salvando la cantidad de steps que est´ an activos.5 % del tiempo total de simulaci´ on.1. Ir a basura y Recolectar basura a lo largo de la simulaci´ on es muy similar. Tambi´ en se puede observar que el comportamiento que mayor tiempo est´ a activo a lo largo de la simulaci´ on es Descargar basura y el que menor tiempo est´ a activo es Salir de situaciones no deseadas. salvando el caso de Descargar Basura. Podemos ver que Recargar bater´ ıa y Descargar basura en conjunto est´ an activos el 54 % de la simulaci´ on. La evoluci´ on de Recargar bater´ ıa es peri´ odica: inicia con una meseta de time steps en los cuales no est´ a activo y luego tiene una pendiente pronunciada.7. el comportamiento Wandering alcanza a estar activo la misma cantidad de steps que Ir a basura. Observamos que en el comienzo (0 < t < 10000) 4 la mayor´ ıa de los comportamientos est´ a activo aproximadamente la misma cantidad de time steps. Diferente es el progreso de Evitamiento de obst´ aculos ya que sus mesetas son las menos prolongadas y sus pendientes son poco abruptas. Los comportamientos involucrados en la recolecci´ on de basura (Enfocar basura.5 % restante est´ a repartido en los comportamientos encargados de una navegaci´ on libre de obst´ aculos y situaciones peligrosas (Wandering. Todos los comportamientos relacionados con la basura(desde que se detecta hasta que se descarga) abarcan un 43 % del tiempo total de simulaci´ on. Evitar obst´ aculos y Salir de situaciones no deseadas ). Podemos ver tambi´ en que la forma en que evolucionan Enfocar basura. En la figura 30 mostramos m´ as en detalle el comportamiento vital para nuestro proyecto. Podemos ver que en el per´ ıodo (0 < t < 50000) acumula aproximadamente la misma cantidad de steps hechos que en el per´ ıodo (50000 < t < 150000). En la figura 29 mostramos el progreso a lo largo de la simulaci´ on de todos los comportamientos. Ir a basura y Recolectar basura ) abarcan el 10. En el per´ ıodo (40000 < t < 50000).

Figura 28: Distribuci´ on de los tiempos de los comportamientos en la simulaci´ on Figura 29: Evoluci´ on de los comportamientos a lo largo de la simulaci´ on 38 .

obtuvimos la cantidad de veces que cada uno se activ´ o (Ver cuadro 3). 39 . Figura 30: Progreso del comportamiento Recolectar Basura Para que pudieramos ver m´ as en detalle lo que sucedi´ o con los comportamientos. seguido por Enfocar basura y Wandering. En un orden de magnitud menor est´ an Ir a descargar basura e Ir a recargar bater´ ıa. En el mismo observamos que el comportamiento que m´ as veces se activ´ o fue Evitar obst´ aculos. Finalmente.van prolongando a medida que se avanza la simulaci´ on y las pendientes tienen aproximadamente la misma magnitud a lo largo de la misma. Recolectar basura se activ´ o 15 veces y Salir de situaciones indeseadas nunca.

44 1. segundo en promedio en estar cai y con el menor desv´ ıo. adem´ as. tienen los m´ ınimos m´ aximos en estar cai. Ir a descargar basura e Ir a recargar bater´ ıa son de los que mayor promedio y desv´ ıo tienen tanto en estar caa como en estar cai. Por continuamente activo se entiende que estuvo activo en el time step t − 1 y en el t 6 cai: continuamente inactivo.07 3. Sucede lo mismo con Evitar obst´ aculos.2.73 237. con una diferencia de un orden de magnitud con respecto al resto de los comportamientos. Wandering es en promedio el que menor tiempo est´ a cai.7.44 0. respectivamente. con el segundo menor desv´ ıo. Comportamiento Wandering Enfocar basura Ir a basura Recolectar basura Ir a descargar basura Ir a recargar bater´ ıa Evitar obst´ aculos Salir situaciones indeseadas Promedio 48.25 178.Comportamiento Wandering Enfocar basura Ir a basura Recolectar basura Ir a descargar basura Ir a recargar bater´ ıa Evitar obst´ aculos Salir situaciones indeseadas # total de steps activo 64476 2057 14832 7166 76160 47188 16843 0 # veces que se activ´ o 1330 1384 1218 15 321 265 1507 0 Cuadro 3: Resultados sobre steps en los cuales los comportamientos est´ an activos 1.27 58.70 840.17 477.39 54. Tiempos en que los comportamientos est´ an continuamente activos e inactivos En los cuadros 4 y 5 mostramos c´ alculos sobre los steps que cada comportamiento estuvo caa 5 y cai 6 . Por continuamente inactivo se entiende que no estuvo activo en el timestep t − 1 ni en el t 40 .06 11.17 Desv´ ıo Est´ andard 225.49 647.72 # m´ aximo 2212 67 1222 478 6012 3950 1386 - Cuadro 4: Resultados sobre steps que los comportamientos est´ an continuamente activos 5 caa: continuamente activo. Ambos. Los comportamientos de Enfocar basura y Ir a basura tienen un promedio y desv´ ıo est´ andar de los m´ as bajos en estar caa. Podemos ver que Recolectar basura es en promedio el mayor en ambos cuadros y que tiene el menor desv´ ıo est´ andar en caa.48 12.

4 163.3 - # m´ aximo 8351 38000 38040 38400 30520 23270 9485 - Cuadro 5: Resultados sobre steps que los comportamientos est´ an continuamente inactivos 1. Transiciones hacia y desde un comportamiento a otro ´ En el cuadro 6 mostramos las transiciones entre los comportamientos.5 13850 473. En segundo lugar se ubican las transiciones desde Enfocar basura hacia Ir a basura y el rec´ ıproco. El valor en la posici´ on (i.5 - Desv´ ıo Est´ andard 754. Enfocar basura a Descargar basura e Ir a basura a Recargar bater´ ıa Mostramos tambi´ en las transiciones en forma de porcentajes en los cuadros 7 y 8.7.Comportamiento Wandering Enfocar basura Ir a basura Recolectar basura Ir a descargar basura Ir a recargar bater´ ıa Evitar obst´ aculos Salir situaciones indeseadas Promedio 123. Tambi´ en se puede leer como: “el comportamiento j se activ´ o tij veces siendo el comportamiento i el que anteriormente estaba activo”. activando a Ir a basura. con porcentajes de 95 % y 97 % respectivamente. Algo parecido sucede en el segundo cuadro. por lo que tii = 0. 41 . Una transici´ on de i a j con i > j puede ser porque el est´ ımulo necesario para la activaci´ on del comportamiento i ya no est´ a presente.4. Estos est´ an abreviados y presentados en el mismo orden que en la secci´ on 1. En el primero detallamos las transiciones desde i hacia j y en el segundo.7 175. y que el segundo tambi´ en es la causa principal de la activaci´ on de los primeros. con valores cercanos al 75 %. con un porcentaje mayor al 95 %. El comportamiento que m´ as veces “activ´ o” a otro comportamiento es Enfocar basura. Una transici´ on de i a j con i < j puede ser porque el est´ ımulo necesario para la activaci´ on del comportamiento j pas´ o a ser sensado. Se puede ver que las transiciones que m´ as sucedieron fueron desde Descargar basura y Recargar bater´ ıa hacia Evitar obst´ aculos. Estas son: Wandering a Recolectar basura.3. Observamos tambi´ en que el caso contrario es la 2da transici´ on m´ as hecha y ambos valores est´ an relativamente cercanos. ´ Podemos ver que hay transiciones que s´ olo se dan 1 sola vez. El 80 % de las veces que estuvo activo Recolectar basura luego se activ´ o Wandering y el 80 % de las veces que se activ´ o el primero fue por parte de Ir a basura. El caso que los valores de tij y tji est´ en cercanos tambi´ en sucede con Evitar obst´ aculos y el resto de los comportamientos. aunque en estos casos la diferencia es mucho menor.4 1766 1811 9479 2689 3322 724.8 682.j ) = tij . Consideramos que hay una transici´ on cuando i = j . se lee como: “desde el comportamiento i se pas´ o tij veces al comportamiento j ”.5 140. siendo i y j el n´ umero de fila y columna respectivamente. transiciones de j hacia i.

145 % 0.003 % 0% 0.179 % 0% 0.004 % 0.188 % 0.794 % 0.001 % 0.962 % 0% Cuadro 7: Transiciones desde i hacia j en porcentajes W EB IAB RB DB R EO W 0% 0.2 % 0% 0% 0.009 % 0.202 % R 0.002 % 0.006 % 0% 0.004 % RB 0.97 % 0% Cuadro 8: Transiciones desde j hacia i en porcentajes 42 .951 % 0.003 % 0.019 % 0.172 % 0.8 % 0.95 % 0.034 % 0.002 % 0% 0% 0.172 % 0.227 % 0% 0.008 % 0.08 % 0.074 % IAB 0.003 % 0% 0.553 % EB 0.132 % 0.004 % RB 0.699 % 0% 0.851 % 0.001 % 0% 0.003 % 0% 0.W EB IAB RB DB R EO W 0 238 229 12 14 9 828 EB 303 0 967 3 0 0 111 IAB 176 1036 0 0 0 0 6 RB 1 2 12 0 0 0 0 DB 12 1 2 0 0 1 305 R 5 0 1 0 2 0 257 EO 833 107 7 0 305 255 0 Cuadro 6: Transiciones entre comportamientos W EB IAB RB DB R EO W 0% 0.748 % 0% 0% 0% 0% 0.037 % 0.134 % 0.077 % 0.626 % 0.002 % 0% 0% 0% 0% 0% DB 0.8 % 0.170 % EO 0.001 % 0.071 % IAB 0.01 % 0% 0% 0% 0% DB 0.623 % 0.006 % 0.55 % EB 0.011 % 0% 0% 0% 0% 0.219 % 0.202 % R 0.066 % 0.170 % EO 0.007 % 0% 0% 0% 0.004 % 0% 0.009 % 0.006 % 0% 0.043 % 0.

Dado que la duraci´ on de la simulaci´ on fue de tf s = 228721.4.Arh = 3800 slots. Como es de esperarse. El tiempo en que se lleg´ o a recorrer todo el arena fue tf v = 95241. con mesetas de pocos steps.42 % del tiempo total de simulaci´ on. Luego las pendientes tienen menor valor y las mesetas son m´ as prolongadas. salvando el caso del intervalo (35000 < t < 40000). la suma de cantidad de slots vistos y slots restantes en un instante de tiempo t es cte = 3800. el arena se recorri´ o en el 0. El arena estaba dividida en Arw . Progreso de recorrido de la arena a lo largo de la simulaci´ on En la figura 31 mostramos el progreso del ´ area recorrida por el robot a lo largo de la simulaci´ on.7. ´ Figura 31: Area visualizada y ´ area no visualizada a lo largo de la simulaci´ on En el cuadro 9 vemos m´ as en detalle el progreso del porcentaje de arena 43 .1. Se puede ver que al principio de la simulaci´ on (0 < t < 17000) hay pendientes abruptas.

N ◦ muestra 1 2 3 4 5 6 7 8 9 10 ( %) 0.246 0.869 1 Cuadro 9: Porcentaje de arena cubierta 44 . En la primer muestra el robot recorri´ o aproximadamente el 25 % de la arena.505 0.011 0.038 0.044 0.167 0.017 0.cubierto.586 0.809 0.754 0. en la segunda el 50 % y en la cuarta el 75 %. Tomamos 10 muestras uniformes en el per´ ıodo (0 < t < tf v ) y obtuvimos el porcentaje cubierto en esa muestra.246 0.042tf s . salvando el caso de la cuarta y u ´ltima muestra. Despu´ es los incrementos son m´ as peque˜ nos en comparaci´ on a los primeros.830 0.258 0. as´ ı como tambi´ en el acumulado la misma. se alcanza a recorrer el 50 % del total del arena. 0 < t < 0.081 0.827 0.798 0.130 ( %) Acumulado 0. Podemos ver que ya en la 2da muestra.003 0.

Un valor muy grande del mismo. Dado que en la simulaci´ on hab´ ıa 15 basuras. En promedio. Los comportamientos ´ ıntimamente relacionados. disminuyendo el tiempo en que el comportamiento est´ a activo. ya que son de los que m´ as jerarqu´ ıa tienen y por lo tanto inhibir´ ıan innecesariamente y por un tiempo relativamente prolongado a otros.1. cubre m´ as porcentaje de la im´ agen. figura (a). El promedio en estar cai de Ir a descargar basura depende directamente de la cantidad de basuras que haya en la arena y la efectividad del m´ odulo de reconocimiento. ya que va a ocasionar que se tenga que enfocar nuevamente. 1 basura cada 8 minutos. y el comportamiento de Ir a basura s´ olo va hacia adelante. El gran desvi´ o est´ andar en estar cai se debe a que al 45 . el robot recolect´ o 1. El mayor tiempo que pas´ o entre entre una recolecci´ on y otra fue de 38400T s = 20m28s. lo que nos lleva a pensar que una activaci´ on incorrecta de los mismos es indeseable. Esto pudo haber sido causado debido al umbral δf en el cual se decide si una basura est´ a enfocada o no(ver figura 16). provocando ´ un bajo promedio de steps caa.52x105 T s tf s = 15basuras basura es decir. Este caso es m´ as sensible a la situaci´ on en la que la basura se mueve. Como ya mencionamos. Enfocar basura e Ir a basura se activaron m´ as de 15 veces. Conclusi´ on En ´ esta secci´ on sacamos conclusiones sobre los resultados obtenidos en la secci´ on 1. aumentar´ a el promedio de time steps en ´ los cuales tiene que enfocar. y la distancia y el recorrido por las mismas var´ ıa seg´ un la posici´ on del robot cuando se hizo presente el est´ ımulo correspondiente. El primer caso es menos sensible al movimiento de la basura. Una activaci´ on incorrecta puede estar dada por: Mal funcionamiento de los sensores Haber juntado un objeto que no era basura Una falla en la l´ ogica de activaci´ on de comportamientos El gran desv´ ıo est´ andar de ambos en caa se debe a que su acci´ on es llevar al robot hacia las l´ ıneas. En los cuadros de transiciones 7 y 8 podemos ver que ambos comportamientos son los mayores proveedores de transiciones de dichos estados al otro. Ir a descargar basura e Ir a recargar bater´ ıa en conjunto abarcan el 54 % del tiempo total de simulaci´ on. har´ a que la mayor cantidad de veces que se detecte una basura. ocasionando que la basura pase a no estar enfocada y una nueva activaci´ on de Enfocar basura. por lo que va a llevar a indicar que la basura se enfoca m´ as r´ apido. suponiendo que la basura se encuentra frente al robot. lo ideal es que el comportamiento nunca se active. la misma NO est´ a frente al robot.8. Adem´ as son de los que mayor promedio est´ an caa. as´ ı como dar posibles explicaciones a los mismos. Un valor chico (figura (b)). En el caso que no haya basuras en la arena. Ambos comportamientos tuvieron un nivel de activac´ ıon parecido a la cantidad de steps que estuvieron activos.7. pero tiene el siguiente defecto: cuando la basura se sensa como enfocada. la misma no est´ e enfocada y al cubrir menos porci´ on de la im´ agen. aunque ´ esto depende de las posibles activaciones incorrectas. era esperado que Recolectar basura se activase la misma cantidad de veces.

A continuaci´ on detallamos posibles causas de las mismas: 1.principio de la simulaci´ on hab´ ıa m´ as basuras para recolectar. disminuyendo el tiempo entre activaci´ ones. que causa el 62 % de activaciones) hasta que desaparece el est´ ımulo que lo activ´ o y el robot vuelve a hacer Wandering. Enfocar basura a Descargar basura e 3. estuvo activo un 28 % del tiempo de simulaci´ on. Evitar obst´ aculos. disminuyendo la probabilidad que el robot las encuentre y aumentando el tiempo entre activaciones. Ir a basura a Recargar bater´ ıa El primer caso puede estar dado por el siguiente escenario: 46 . Teniendo en cuenta que los comportamientos relacionados con las basuras abarcaron un 43 % de tf s . y llegando al final de la simulaci´ on hab´ ıa menos basuras. 1 2 siendo t y t transiciones de los cuadros 7 y 8 respectivamente. ´ Esto da la siguiente idea: hay un comportamiento activo A y sus respuestas est´ an llevando al robot a una posible colisi´ on. El comportamiento de Salir de situaciones no deseadas no se activ´ o nunca. Este pensamiento es totalmente err´ oneo ya que uno de nuestros objetivos era que la autonom´ ıa del robot no corra riesgo bajo ning´ un concepto. un comportamiento pasa a estar activo por un per´ ıodo corto de tiempo(por ejemplo. saca al robot de la posible colisi´ on y vuelve a activar a A. El poder de detener a otros comportamientos est´ a dado por su nivel en la arquitectura. Cabe aclarar que hay situaciones que escapan al alcance de este proyecto. reflejados en la duraci´ on muy corta de las mesetas. En la misma figura se puede observar el efecto de tener un promedio y desv´ ıo estandar bajos. Una de ellas se puede ver en los cuadros de transiciones. ´ Este hecho es muy importante: indica que el resto de los comportamientos nunca se “activaron mutuamente” y por lo tanto no hubo situaciones que puedan llevar al robot a quedarse sin carga en la bater´ ıa. Las transiciones hacia ´ el y desde ´ el se dan en proporciones muy parecidas. y en el caso de haber utilizado otra arquitectura. es de esperarse que en una simulaci´ on sin basuras el protagonismo de Wandering sea el mayor de todos superando el 70 %. ya que est´ a activo si y s´ olo si ning´ un otro est´ a activo. 2. Su promedio y desv´ ıo estandar de caa son bajos y se ven reflejados en la figura 29. Wandering a Recolectar basura. En ese momento se activa Evitar obst´ aculos. por ejemplo. Cabe aclarar que en realidad no lo activa a A. Es importante resaltar que este beneficio viene solo por el hecho de usar Subsumption. El hecho que no se active nunca el comportamiento puede llevar a pensar que no es nece´ sario tenerlo. detiene A. Evitar obst´ aculos es un comportamiento que tiene ciertas cualidades. En un arena con 15 basuras. En la secci´ on 1. El funcionamiento de Salir de situaciones no deseadas lo probamos en diferentes simulaciones anteriores a la que presentamos y el resultado fue el esperado.7 vimos que algunas transiciones suced´ ıan s´ olo una vez. nos hubiese demandado trabajo. que se rompa una rueda. esto quiere decir que t1 ≈ t2 7j 7j . sino que desaparece el est´ ımulo de Evitar obst´ aculos y A toma el control nuevamente. En la mayor parte de los casos entre una activaci´ on y otra de Wandering no hay muchos comportamientos que se activan. arriesgando su autonom´ ıa. Los valores de Wandering dependen totalmente de las activaciones de los otros comportamientos. Su bajo promedio y desv´ ıo est´ andar en estar cai puede estar dado por situaciones en que est´ a activo.

Est´ o llev´ o a la activaci´ on de Enfocar basura. En el time step que se desactiv´ o la recolecci´ on. En dicho time step. El tercer caso es m´ as sencillo de explicar: En el time step t el robot se dirig´ ıa hacia una basura. Adem´ as. es de esperarse que luego de recolectar. hab´ ıa otra basura en la imagen detectada por la c´ amara y por el sistema de reconocimiento que era necesario enfocar para que sea recolectada. Otro factor importante para destacar es que el 75 % del ´ area se recorri´ o en un cuarto del tiempo en cuesti´ on. Teniendo un almacenamiento m´ aximo de 1 basura. activa el comportamiento Descargar basura. lo importante no es el porcentaje del tiempo total. En el siguiente time step. Es decir. Este porcentaje disminuye o aumenta dependiendo de si aumenta el tiempo de simulaci´ on o disminuye. sino que recolect´ o 9 basuras de las 15 que hab´ ıa en la arena y fue a descargarlas(uno de los comportamientos que m´ as tiempo lleva). Finalmente. pero la basura recolectada no hab´ ıa llegado a activar el sensor del dep´ osito de basura. En el time step que desapareci´ o ese est´ ımulo. Por todo ´ esto. se active ´ Descargar basura. activando Wandering. En el siguiente time step. la basura recolectada activa el sensor del dep´ osito y por ende. hay un per´ ıodo de time steps en los cuales la basura recolectada est´ a yendo hacia el sensor del dep´ osito. Esto no sucede ya que. Otro dato curioso es que el 80 % de las veces que estuvo activo Recolectar basura luego se activ´ o Wandering y el restante a Enfocar basura. 47 . se recarg´ o 3 veces en ese per´ ıodo. El segundo caso puede estar dado por el siguiente escenario: El robot recolect´ o una basura. En el time step t + 1. como explicamos en el escenario del segundo caso. el sistema de reconocimiento detecta la basura. Dicho tiempo fue de 95241T s = 50m47s. y adem´ as se encuentra enfocada y a una distancia en la cual puede activarse el comportamiento de Recolectar basura. permitiendo la activaci´ on de otros comportamientos. hab´ ıa una basura en la imagen detectada por la c´ amara.El robot esquiv´ o un obst´ aculo. Esto es posible debido a que el u ´ltimo tiene mayor nivel en la arquitectura que el primero. como dijimos anteriormente. el sistema de reconocimiento no la detect´ o. es otro de los comportamientos que m´ as tiempo demanda. el robot recorri´ o toda la arena en el 42 % del tiempo total de ´ simulaci´ on. es decir. en aproximadamente 13mins. sino el tiempo en que recorri´ o el ´ area en su totalidad. el valor de la bater´ ıa hizo que se active el compor´ tamiento de Recargar bater´ ıa. Durante ´ este tiempo el robot no s´ olo recorri´ o un poco menos de 200m2 (la escala es 10:1). concluimos que el recorrido de la arena es muy eficiente.

Posibles extensiones Una de las posibles extensiones del trabajo puede ser minimizar el tiempo consumido por los comportamientos de Ir a zona de descarga de basura y Ir a zona de recarga de bater´ ıa. Adem´ as podr´ ıa ver el estado actual del sistema de predicci´ on y la imagen vista por la c´ amara. Cabe aclarar que no es el seguimiento de la l´ ınea lo que m´ as tiempo demora sino ir hacia la misma. Entre ellos se encuentran: Seguir la pared.1. Subir estad´ ısticas a un servidor central de forma tal que se pueda analizar qu´ e cambios se podr´ ıan hacer en el controlador para mejorar la efectividad y eficiencia de la recolecci´ on o de otros comportamientos. agregar m´ as l´ ıneas o cambiar las formas de las mismas. podemos pensar en algunas formas para minimizar este tiempo.8. Dado que ambos van hacia la l´ ınea. Notificar a una central sobre sucesos inesperados o dif´ ıciles de que sucedan. Mover una basura hacia un ´ area.1. Interactuar con las personas. o lo use en menor tiempo. Agregar un mecanismo que le permita recolectar basuras que est´ an pegadas o en lugares no alcanzables por el robot por la presencia de obst´ aculos. 48 . con un objetivo a pensar. Proveer una interfaz web que permita ver el estado de los sensores y actuadores del robot en forma on-line. mediante sonidos o reconociemiento visual. En cuanto a los comportamientos que posee el robot podemos pensar en agregar algunos para ampliar las prestaciones que puede brindar el robot. Otra alternativa podr´ ıa ser utilizar otro mecanismo para ir hacia dichas zonas que no use el seguimiento de l´ ınea. en caso que no pueda recolectarla. as´ ı como tambi´ en gr´ aficos mostrando los u ´ltimos comportamientos activos. Entre las mismas est´ an: cambiar las ubicaciones de las l´ ıneas.

A. Mostramos en la figura 33 que GarbageCleaner posee comportamientos. tal como se ve en la figura 34. brind´ andoles los sensores. los comportamientos y el sistema de reconocimiento se puede ver m´ as claramente en la figura 32. La relaci´ on explicada en dicha secci´ on entre el robot (con sus dispositivos). ya que debe: Obtener los sensores y actuadores del robot. Instanciar los comportamientos.6. tal como explicamos en la secci´ on 1. En la misma tambi´ en est´ a el main-loop. utilizando la arquitectura de comportamientos elegida (Subsumption ). Tambi´ en posee el m´ odulo de reconocimiento de objetos. as´ ı como tambi´ en un robot y el mismo posee dispositivos que pueden ser sensores o actuadores. 49 . Implementaci´ on de arquitectura de software del controlador La implementaci´ on de la arquitectura de software del controlador la hicimos en C++. unidos por la clase GarbageCleaner. Correr el main-loop. actuadores y eventualmente el m´ odulo de reconocimiento. haciendo actuar al comportamiento cuyo est´ ımulo est´ e activo en ese instante de tiempo y tenga mayor nivel en la arquitectura. que implementa la arquitectura Subsumption. La implementaci´ on de GarbageCleaner es simple. Inicializar el m´ odulo de reconocimiento de basuras. mostrado en la figura 35. necesarios para saber si su est´ ımulo est´ a activo y para poder interactuar con el entorno.

Relaci´ on entre las 3 grandes componentes del proyecto .50 Figura 32: Diagrama de clases de la arquitectura de sofware.

Para agregar un comportamiento. hay que instanciarlo y agregarlo a la lista de comportamientos que posee GarbageCleaner. En el segundo se debe implementar la respuesta del comportamiento en el caso que est´ e activo. en la figura 33 mostramos la relaci´ on de GarbageCleaner con los comportamientos.A. El u ´ltimo m´ etodo provee una descripci´ on del comportamiento implementado.1. En el primero el comportamiento debe indicar si est´ a activo o no en base a la informaci´ on de los sensores que utilice. Podemos ver que m´ as precisa´ mente posee AbstractBehaviours. Comportamientos Como ya mencionamos anteriormente. Esto se debe a que la u ´nica informaci´ on que necesita para coordinarlos es saber si est´ an activos (m´ etodo sense ) y luego poder indicarles que den su respuesta (m´ etodo act ). 51 . es necesario que extienda de AbstractBehaviour e implemente los m´ etodos abstractos de la clase: sense. Finalmente. action y toString.

52 Figura 33: Diagrama de clases de la arquitectura de sofware. Paquete de comportamientos .

como getDifferentialWheels. La implementaci´ on para el robot real. Luego de crear la interfaz. y cada motor posee una placa que lo controla. el mismo posee dos handlers. la mayor cantidad de llamadas a ´ estos m´ etodos son simples wrappers de una invocaci´ on al dispositivo virtual del programa de simulaci´ on. posee un mapa que relaciona los nombres de los dispositivos ´ con instancias de implementaciones de los mismos. como por ejemplo un GPS. 53 . En la implementaci´ on de la interfaz para la simulaci´ on con Webots (WebotsRobot ). Despu´ es es necesario implementar ´ este m´ etodo en las clases WebotsRobot y RealRobot. correr en la realidad o ambos. Como se puede observar. En el caso que se quiera agregar un sensor nuevo a la api. la interfaz que representa al robot provee m´ etodos de obtenci´ on de sensores como getDistanceSensor y de actuadores. RealRobot. con m´ etodos de obtenci´ on de valores de los sensores o establecimiento de valores para los actuadores. Estos u ´ltimos forman parte del IRobot que le es entregado a GarbageCleaner para que instancie los comportamientos. como por ejemplo RealDistanceSensor. es necesario agregar un m´ etodo a la interfaz de IRobot para poder obtener una instancia del dispositivo en cuesti´ on. es necesario crear la interfaz que represente el mismo. debe disponer de dispositivos que le permita hacerlo. hicimos que los dispositivos sean pedidos por un nombre que los representa.A. tienen los handlers necesarios para poder enviar y recibir informaci´ on de los sensores y actuadores de los cuales son responsables. Estas implementaciones. Para el desarrollo de la arquitectura nos basamos fuertemente en la api que provee Webots para interactuar con su robot simulado. En el caso de RealDifferentialWheels.2. Para minimizar el acoplamiento entre IRobot y GarbageCleaner. dado que cada handler es capaz de interactuar con una placa con determinado groupid y boardid. dependiendo si se va a querer simular con Webots. se deben realizar las implementaciones correspondientes de la interfaz creada para el dispositivo. Dispositivos del robot Para que el robot sense y act´ ue en el entorno a trav´ es de sus comportamien´ tos. Finalmente.

Paquete de api de l robot .54 Figura 34: Diagrama de clases de la arquitectura de sofware.

Esto se debe a que OpenCV y Webots codifican las im´ agenes de maneras distintas y tuvimos que implementar sus respectivas clases. se pide la imagen a webots mientras que en la segunda se toma una imagen del mundo real. Reconocimiento de objetos La figura 35 exhibe la relaci´ on entre el m´ odulo de reconocimiento de objetos y el m´ odulo de comportamientos. El comportamiento de las clases WebotsCamera y RealCamera es el mismo pero sus implementaciones difieren en que. en el caso de la primera. El m´ odulo de visi´ on queda encapsulado dentro de la clase de GarbageRecognition. Por motivos similares utilizamos una interfaz para la representaci´ on de ´ las im´ agenes.3. La creaci´ on de una interfaz para la c´ amara nos permite alternar entre el entorno de webots y el mundo real. permitiendo que el m´ odulo de comportamientos funcione en forma independiente a ´ este. 55 .A.

Paquete de reconocimiento de basuras .56 Figura 35: Diagrama de clases de la arquitectura de software.

espec´ ıficos para cada sensor o actuador que pueda haber en una placa. El mismo se encarga de establecer 57 . La clase packet provee funciones de utilidad para cualquier tipo de paquete. A continuaci´ on damos un ejemplo de uso de un paquete. al igual que el controlador y el m´ odulo de reconocimiento de basuras. sin inspeccionar de qu´ e tipo de paquete se trata. Lo mismo sucede con board packet. el servidor invoca el m´ etodo handlePacket() del handler registrado. Como mencionamos anteriormente. cada paquete espec´ ıfico tiene funciones que permiten obtener y establecer informaci´ on propia del sensor/actuador en cuesti´ on. Packets Como indicamos en la figura 37. registerHandler: Registra un handler para un paquete enviado desde una placa con grupo groupid e id de placa boardid. Mostramos el diagrama de ´ esta relaci´ on en la figura 36. as´ ı como tambi´ en de recibir los paquetes de respuesta que le incumben y proveerlos a la api de una forma que ´ esta los entienda. El servidor s´ olo se encarga de mandar una serie de bytes y de recibir los mismos. Supongamos que se quiere saber la carga de la bater´ ıa. Cuando llega un paquete de dicha placa. entre otras.B. hay un servidor que denominamos packet server encargado del env´ ıo y recepci´ on de paquetes. quienes son los responsables de convertir los comandos de la api del robot en paquetes y enviarlos al servidor. no se interrumpe la recepci´ on o env´ ıo de paquetes. Implementaci´ on del protocolo de comunicaci´ on del lado de la PC Packet Server La implementaci´ on del protocolo en la PC la hicimos en C++. Adem´ as permite obtener el valor de carga de la bater´ ıa.1. group packet extiende a packet. Por ejemplo. En las figuras 38 y 39 mostramos los paquetes que extienden de board packet.2. B. agreg´ ando m´ etodos de utilidad para los comandos que todos los grupos son capaces de recibir. Provee dos m´ etodos para realizar el env´ ıo y recepci´ on: sendPacket: Su funci´ on es recibir un paquete y encolarlo para que el servidor lo env´ ıe. extendiendo de group packet ya que es m´ as espec´ ıfico que este u ´ltimo. seteo y obtenci´ on de valores de los campos del paquete. Como se puede observar. respetando el protocolo que propusimos. B. Tambi´ en implementamos lo que llamamos handlers. tales como c´ alculo y verificaci´ on de CRC. La idea del m´ etodo handlePacket es que se limite s´ olo a guardar los nuevos valores recibidos. Para ´ esto instanciamos un BatteryPacket con el id de grupo y placa correspondientes. Como el servidor es un thread diferente al de la api. ya que durante la invocaci´ on del mismo el server no recibe ni env´ ıa paquetes. respectivamente. BatteryPacket permite establecer los umbrales a los cuales informar´ a que la bater´ ıa se encuentra cargada o en estado cr´ ıtico. Para la misma implementamos los paquetes descriptos en el protocolo y un servidor de env´ ıo y recepci´ on de los mismos a trav´ es del puerto serial.

3. Le indicamos que queremos el valor de carga con senseBattery(). Una vez que tenemos el paquete armado. instanciamos un BatteryPacket y llamamos a la funci´ on analysePacket() con el paquete que recibimos. sin tener conocimiento sobre el protocolo. tama˜ no del paquete y comando. hay m´ etodos que en el otro no est´ an. B. Finalmente. llamamos a la funci´ on sendPacket() del packet server. los campos de grupo y placa de origen y destino.Figura 36: Diagrama de clases. Handlers En las figuras 40 y 41 mostramos los handlers implementados para que las implementaciones de los sensores de la api del robot pudieran manejar los mismos. 58 . En la funci´ on. Estructura general del servidor de paquetes e interfaz para los handlers. que pone el comando correspondiente en el campo del paquete. nos queda invocar al m´ etodo getBatteryValue() de este paquete. cuando el server reciba la respuesta de la placa va a llamar al m´ etodo handlePacket() del handler. Suponiendo que registramos un handler para ese id de grupo y de placa. y en algunos casos. La funci´ on handlePacket del mismo se encarga de imprimir por salida est´ andar cada campo del paquete en formato hexadecimal. Hay un handler por default. DefaultBoardPacketHandler. para el caso en que no haya registrado un handler para determinado id de grupo y placa. Se puede observar que la cantidad de m´ etodos en los paquetes y en los handlers no es la misma.

el protocolo brinda m´ as opciones de las que realmente utiliza el controlador para funcionar. aislando a la api del controlador de posibles cambios. es necesario modificar el packet y handler asociados a los mismos. los handlers correspondientes. Este cambio. Es decir. En el caso que se ampl´ ıe el set de comandos de un determinado sensor o actuador. se deber´ an actualizar las clases afectadas por los cambios. En algunos casos.Figura 37: Diagrama de clases. En el caso que el campo indique algo sobre el grupo o placa. ´ Esto se debe a que los handlers son intermediarios entre el protocolo y la api del controlador encargado de la ejecuci´ on de los comportamientos. tambi´ en afectar´ a a group packet o board packet. 59 . en principio. B. Supongamos el caso en el que se agrega un campo de 1 byte luego del tama˜ no ´ total del paquete. un cambio en el protocolo llega como mucho hasta los handlers. Modificaci´ on del protocolo En el caso que haya una modificaci´ on en el protocolo. Estructura general de los paquetes. Lo importante de ´ esto es que los cambios est´ an localizados. respectivamente.4. y eventualmente. s´ olo afecta la clase Packet.

A control architecture for an autonomous mobile robot. December 2004. Neves and R. A. Clark. [3] Amalia F. 1986. [7] K. Simon & Schuster. Predictive autonomous robot navigation. [5] Maria C. USA. In In Proc. 2002. Robotics and Autonomous Systems. [6] Stefano Nolfi. Wedeward R. Brooks. The society of mind. 1997. Autonomous robot path planning using a genetic algorithm. A navigation and obstacle avoidance algorithm for mobile robots operating in unknown. In Proceedings of Autonomous Agents. A robust layered control system for a mobile robot. [4] Marvin Minsky.. S.Referencias [1] Rodney A. NY. of the IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS). Cambridge. maze-type environments. MA. Evolving non-trivial behaviors on real robots: A garbage collecting robot. Technical report. Foka and Panos E. [2] Salvatore Candido. USA. Tome. ACM. Trahanias. El-Osery and S. pages 490–495. Bruder. 1985. Inc. 60 . New York.

servos y bater´ ıa. Estructura de los paquetes de motor. recipiente de basura.Figura 38: Diagrama de clases. 61 .

Figura 39: Diagrama de clases. 62 . Estructura general de los paquetes para sensores de distancia.

Handlers de paquetes default y para las placas de motor y bater´ ıa. 63 .Figura 40: Diagrama de clases.

64 . servos y recipiente de residuos.Figura 41: Diagrama de clases. Handlers de paquetes para las placas de sensores de distancia.