Proyecto Fin de Carrera

T tulo: lisis y disen o de un robot mo vil auto nomo Ana y de su localizacion e integracion en un ambiente inteligente Marina Zapater Sancho Manuel Moya Ferna ndez D. Jose nica Departamento de Ingenier a Electro

Autor: Tutor: Departamento:

Miembros del tribunal

Presidente: Vocal: Secretario: Suplente:

D. Octavio Nieto-Taladriz Garc a D. Alvaro Araujo Pinto Manuel Moya Ferna ndez D. Jose rrez Mart D. Alvaro Gutie n

Los miembros del tribunal arriba nombrados acuerdan otorgar la calicaci on de:

Madrid, a

de

de 2010

cnica de Madrid Universidad Polite

cnica Superior Escuela Te n de Ingenieros de Telecomunicacio

Proyecto Fin de Carrera An alisis y dise no de un robot m ovil aut onomo y de su localizaci on e integraci on en un ambiente inteligente

Marina Zapater Sancho

Marzo de 2010

Resumen del proyecto

El presente Proyecto Fin de Carrera se haya dividido en dos partes diferenciadas y correspondientes a: An alisis y dise no de un Robot m ovil aut onomo para un entorno inteligente: en esta parte se parte del prototipo de un robot comercial, el robot X80 de Dr. Robot Inc. y, aprovechando su estructura y algunos de los sensores de la red, se construye desde cero un robot m ovil aut onomo con una red de cerca de 40 sensores encuestados por I2C. El robot estar a basado en un agente reactivo con arquitectura de subsunci on y se comunicar a con el ambiente inteligente del Laboratorio de Sistemas Integrados mediante un m odulo Wi USB. La comunicaci on le permitir a intercambiar con el entorno informaci on acerca de su estado y recibir ordenes del mismo. An alisis y dise no de la localizaci on e integraci on de un robot m ovil en un entorno inteligente: en esta segunda parte se partir a del prototipo del robot creado en la primera. Al robot se le a nadir a, por encima de la capa reactiva, una capa deliberativa basada en la arquitectura AuRA que le permita llevar a cabo funciones de alto nivel. De toda la arquitectura se dise nar a la parte de la localizaci on y mapeado simult aneo del robot en su entorno, as como la planicaci on de rutas sencillas (b usqueda de caminos entre dos puntos de un mapa). Tambi en se dise nar a un sistema simple para llevar a cabo el reconocimiento de los usuarios que se mueven por el entorno inteligente, mediante la c amara de a bordo preinstalada en el robot X80. En este proyecto se prestar a especial atenci on a la utilizaci on de los recursos del sistema del robot, que utilizar a como placa de inteligencia b asica un System on Module (SoM) con un kernel linux. Uno de los requisitos principales ser a el de mantener siempre la reactividad de robot y su buena adaptaci on del entorno, evitando que los programas puedan sobrecargar el sistema.

Palabras clave
Robots m oviles aut onomos, red de sensores, agente reactivo, agente deliberativo, entorno inteligente, localizaci on y mapeado simult aneo, planicaci on de rutas, identicaci on de usuarios. i

ii

iii

A mis padres.

iv

Agradecimientos
Es curioso. Casi 7 a nos y 2 carreras de por medio me han tra do hasta este momento, justo aqu , cuando uno tiene ya acabada toda (o casi toda) la memoria del proyecto y decide que ya va siendo hora de rellenar una de las primeras p aginas. La u ltima p agina que uno escribe y la primera (y a veces la u nica...) que los dem as leen. Por alguna raz on todos acabamos dejando esta parte para el nal, pensando aquello de si todav a me queda mucho tiempo hasta que acabe el proyecto, y la memoria, y la carrera.... Y cuando uno quiere darse cuenta, resulta que el tiempo ha pasado y toca poner punto y nal a una etapa m as de la vida. Ha llovido mucho desde aquel primer d a de carrera, en que uno no conoc a a nadie. Desde aquella primera clase de c alculo en que no me enter e de nada, aquella primera elecci on de delegados que marc o mi estancia en la universidad, aquel primer examen que suspend ... Y gracias a dios hace mucho tambi en que tripit PiPE, pensando que jam as aprobar a. Pero aprob e, y el tiempo pas o y la carrera se acaba, y en el fondo, no habr a llegado hasta aqu de no haber sido por todas las personas que han formado parte de mi vida en estos a nos: aquellos a los que ya conoc a y aquellos a los que conoc ; la familia, los amigos y, en ocasiones, incluso los no tan amigos. A todos ellos, les dedico estas l neas. Tendr eis que perdonarme si no os nombro a todos, pero el espacio es reducido. En primer lugar, quiero darles las gracias a mis padres. Por todo. A mi padre, porque viv a como si fueran suyos tanto mis logros como los obst aculos que me encontraba por el camino. A mi madre, porque ya era hora de que me viera suspender una asignatura, verdad?. Y en el fondo, a los dos, por su paciencia conmigo. En segundo lugar, a Josem, mi tutor del proyecto, y a todo el B-105, porque no me conoc an de nada, pero me acogieron como a una m as. Empezamos siendo compa neros, pero en alg un momento hab eis pasado a ser amigos. A Octavio, Alvaro y David, por los t tulos del futbol n dignamente merecidos de los que me han hecho entrega (cuando uno lee PFC hay un reset del n umero de t tulos... verdad?). A Juan-Mariano (porque ya le tengo medio convencido de que Catalunya se escribe con ny), a Juan Carlos (si yo s olo he tocado el bot on rojo!), Pedro (estamos locos o qu e?), Dani (en la vida...), Rover y Zorana, Javi, Elena, Andr es, Paco, Oscar (reparaz), Alvarito el Invencible y dem as peritas (entre las que me incluyo, claro) del peral. A Curro, por todas las veces que me has hecho pasar por debajo del futbol n (las que ibas conmigo y las que ibas contra m ) y a Mariano, por sus cr onicas inigualables y sus comentarios sin igual (esto antes lo hac an los druidas). A Oscar, por recordarme algunos temazos que ten a olvidados y porque todos los d as en el B-105 puede ser invierno con el cerca. v

vi

AGRADECIMIENTOS

A toda la gente que he conocido aqu en Madrid y que, de un modo u otro, han contribuido a hacer que me sienta m as como en casa. E incluso a los de Talavera de la Reina! Que son castellano-manchegos, pero son majos. A todos los compa neros del tiro con arco de Legan es y en especial a Pablo, por su paciencia, ilusi on y apoyo. A los amigos del CEET, a los compa neros de las comisiones permanentes en las que estuve: Almo (siempre ser as mi presidente), Dei, Jordi, Paula y Natalia, Pablo, Vicente (es un se nor) y Merce. Y a los que no estuvieron en la permanente, pero que son unos currantes y adem as de compa neros son amigos: Rubenci no (me echaron droja en el cola-cao), Jorge UVA (que ya no es UVA, que es UAB)... Y ahora, volvamos hacia la UPC. A todos aquellos que empezamos juntos nuestra andanza por telecos all a por el 1A: al Toniet, perqu` e des del primer dia ja vam ser amics, a lAlbert A. per tots aquells caf` es que ens hem pres (tot i que a mi no magradava el caf` e), a lI naki, els dos Jordis, Ivan, Ricard, Maria, Laia, Aida... A las diversas generaciones de DAT, desde los dinosaurios, pasando por mi generaci on, y por aquellos que ahora me ven a m como un dinosaurio. A Manch on (sab eis que le han cogido en McKinsey?), Mundet, Salazar y Marta Serrabou. A mi primera junta: a Oscar, porque siempre ser a mi coordinador favorito, y a V ctor, porque de no ser por ti (y BlackOps), yo no habr a sido tesorera ni junta (un momento, no tengo claro que te tenga que agradecer los marrones!). A Albert (hac amos un buen equipo, no?), a Manolo (porque si nos sentamos en el bar con un caf e nos convertimos en dos abuelitos cebolleta), Marta, Manel (est` as boig, per` o ets un crack i ho saps) y a todos los dem as. A toda la gente del Omega, porque sin el Casal, la universidad no habr a sido lo mismo. A Pako, por todas aquellas pr acticas de electr onica, en especial aquella ALU de 32bits a partir de la cual empec e a consumir caf e. Sense tu, tio, hagu es estat un infern (m es infern, vull dir). A en Xavi, perqu` e en el fons vas canviar la meva forma de veure la vida. No puedo dejar de mencionar aqu a todo el equipo directivo de la ETSETB (Elisa Sayrol, Lluis Prat, Josep Pegueroles, Anna Calveras, German Saez...), por su trabajo y porque gracias a ellos nuestra escuela es cada d a una escuela mejor. A todo el personal del B3, desde la planta -2 hasta la primera planta, y en especial a Elisa Pla (pel teu suport des del principi), Rosa Ma , Asun y Anna, porque sin vosotras la escuela no ser a la misma. Gracias a todos porque me ense nasteis que en la universidad no s olo se forman ingenieros, sino tambi en personas. A lEric. Tot i que no fa falta que et digui res, xiti, tu que has estat en gaireb e totes les p` agines de la meva vida, ja saps que no podies faltar en aquesta. A Lara, Javi, Carmen y Germ an, porque de ellos he aprendido muchas cosas (a parte de que las zanahorias no crecen de una en una) y porque ya les considero parte de la familia. A F elix, por aquel d a de septiembre de 2006 en Valencia que cambi o nuestras vidas y nos ha tra do hasta aqu .

vii

Este proyecto ha sido nanciado parcialmente por: Miniterio de Industria, Turismo y Comercio, proyecto TSI-020301-2009-18 (eCID) Ministerio de Ciencia e Innovaci on, proyecto TEC2009-14595-C02-01 (AMILCAR) Proyecto CENIT Segur@.

viii

AGRADECIMIENTOS

Lista de Acr onimos

ADC Conversor Anal ogico-Digital - Analog to Digital Converter AmiBot Robot para Ambientes Inteligentes - Ambient Intelligence Robot AmiCam C amara para robot de Ambientes Inteligente - Ambient Intelligence Camera AmiMap Mapeado para Ambientes Inteligente - Ambient Intelligence Mapping AmiServer Servidor para robot de Ambiente Inteligente - Ambient Intelligence Server AMISEC Seguridad en Ambientes Inteligentes - Ambient Intelligence Security CMRR Raz on de Rechazo al Modo Com un - Common Mode Rejection Ratio DSP Procesador Digital de Se nal - Digital Signal Processor E/S Entrada/Salida FTP Protocolo de Transferencia de Archivod - File Transfer Protocol GPIO Entrada/Salida de Prop osito General - General Purpose Input/Output GUI Interfaz Gr aca de Usuario - Graphic User Interface IA Inteligencia Articial - Articial Intelligence I2C (Bus de) Circuitos Integrados - Inter-Integrated Circuit JCBB Joint Compatibility Branch and Bound algorithm JTAG Joint Test Action Group MIPS Mega-Instruccions por Segundo Mega Instructions Per Second MMU Unidad de Manejo de Memoria - Memory Management Unit MVC Modelo Vista Controlador NN Algoritmo del Vecino m as cercano Nearest Neighbor algorithm PIC Controlador de Interfaz Perif erico - Peripheral Interface Controller ix

LISTA DE ACRONIMOS

PID Proporcional-Integral-Derivativo - Proportional-Integrative-Derivative PCB Placa de Circuito Impreso - Printed Circuit Board SLAM Localizaci on y Mapeado Simult aneo Simultaneous Localization and Map Building SMBUS Bus de Administraci on del Sistema - System Management Bus SoM System on Module SPI (Bus SPI) - Serial Peripheral Interface SSH Int erprete de ordenes seguro - Secure Shell SWT Standard Widget Toolkit TIC Tecnolog as de la Informaci on y la Comunicaci on

 Indice general

Resumen del proyecto Agradecimientos Lista de Acr onimos Lista de Acr onimos

IX

IX

I An alisis y dise no de un Robot m ovil aut onomo para un entorno inteligente 1

1. Introducci on 1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Fases del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Estado del Arte 2.1. Ambientes Inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Robots m oviles Aut onomos . . . . . . . . . . . . . . . . . . . . . . . 2.2.1. Evoluci on y estado actual . . . . . . . . . . . . . . . . . . . . 2.2.2. Sensado del ambiente . . . . . . . . . . . . . . . . . . . . . . 2.2.3. Modelos de comportamiento . . . . . . . . . . . . . . . . . . . 2.2.4. Proyectos de desarrollo software . . . . . . . . . . . . . . . . 2.3. Experiencia previa del laboratorio . . . . . . . . . . . . . . . . . . . 3. An alisis 3.1. La plataforma de trabajo . . . . . . . . . . . . . . . . . . . . . . . . xi 3 5 5 7 7 9 9 13 14 17 18 19 19

xii

INDICE GENERAL 3.1.1. El robot X80 de Dr. Robot Inc. . . . . . . . . . . . . . . . . . 3.1.2. Limitaciones y ventajas de la plataforma . . . . . . . . . . . . 3.2. Componentes del robot m ovil . . . . . . . . . . . . . . . . . . . . . . 3.2.1. Sensado e interacci on con el entorno . . . . . . . . . . . . . . 3.2.2. Inteligencia del robot . . . . . . . . . . . . . . . . . . . . . . . 3.3. Comunicaci on con el ambiente inteligente . . . . . . . . . . . . . . . 3.4. Requisitos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1. Requisitos asociados al robot . . . . . . . . . . . . . . . . . . 3.4.2. Requisitos asociados al ambiente inteligente . . . . . . . . . . 19 20 23 23 26 29 30 30 31 33 33 33 34 36 37 38 38 42 44 44 51 53 56 59 59 59 65 68 68 72

4. Dise no 4.1. Denici on de Hardware y Software . . . . . . . . . . . . . . . . . . . 4.1.1. Elecci on de la red de sensores . . . . . . . . . . . . . . . . . . 4.1.2. Elecci on de la placa de procesado . . . . . . . . . . . . . . . . 4.1.3. Decisiones Software . . . . . . . . . . . . . . . . . . . . . . .

4.1.4. Denici on de la comunicaci on con el ambiente inteligente . . 4.2. Arquitectura del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1. Arquitectura Hardware . . . . . . . . . . . . . . . . . . . . . 4.2.2. Arquitectura Software . . . . . . . . . . . . . . . . . . . . . . 4.3. Dise no del Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1. La red de sensores . . . . . . . . . . . . . . . . . . . . . . . . 4.3.2. Los motores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.3. La alimentaci on del robot . . . . . . . . . . . . . . . . . . . . 4.4. Dise no del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Implementaci on 5.1. Implementaci on Hardware . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1. La red de sensores y actuadores . . . . . . . . . . . . . . . . . 5.1.2. La placa base y el m odulo WiFi . . . . . . . . . . . . . . . .

5.2. Implementaci on Software . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1. Agente reactivo AmiBot . . . . . . . . . . . . . . . . . . . . . 5.2.2. Demostrador AmiServer . . . . . . . . . . . . . . . . . . . . .

 INDICE GENERAL 5.3. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1. Pruebas de hardware . . . . . . . . . . . . . . . . . . . . . . . 5.3.2. Pruebas de software . . . . . . . . . . . . . . . . . . . . . . . 5.3.3. Pruebas de conjunto del sistema . . . . . . . . . . . . . . . . 6. Resultados 7. Conclusiones y l neas futuras 7.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2. Limitaciones de AmiBot . . . . . . . . . . . . . . . . . . . . . . . . . 7.3. Mejoras y l neas futuras . . . . . . . . . . . . . . . . . . . . . . . . .

xiii 75 75 77 77 79 83 83 85 86

II An alisis y dise no de la localizaci on e integraci on de un robot m ovil en un entorno inteligente 89

8. Introducci on 8.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2. Fases del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. Estado del arte 9.1. Arquitecturas de Robots Aut onomos . . . . . . . . . . . . . . . . . . 9.2. T ecnicas de Mapeado y Localizaci on de Robots . . . . . . . . . . . . 9.3. Planicaci on de rutas . . . . . . . . . . . . . . . . . . . . . . . . . . 10.An alisis 91 92 92 95 95 97 99 105

10.1. An alisis de la Arquitectura del robot . . . . . . . . . . . . . . . . . . 105 10.1.1. La Arquitectura AURA . . . . . . . . . . . . . . . . . . . . . 105 10.1.2. Recursos disponibles del sistema . . . . . . . . . . . . . . . . 107 10.2. Necesidades de la localizaci on y mapeado . . . . . . . . . . . . . . . 109 10.2.1. Odometr a del robot . . . . . . . . . . . . . . . . . . . . . . . 110 10.2.2. Datos de los sensores . . . . . . . . . . . . . . . . . . . . . . . 111 10.2.3. Necesidades de los mapas . . . . . . . . . . . . . . . . . . . . 115 10.2.4. Pasos para la localizaci on y mapeado simult aneo . . . . . . . 118 10.3. La planicaci on de rutas . . . . . . . . . . . . . . . . . . . . . . . . . 119

xiv

INDICE GENERAL

10.4. Sistema de identicaci on de usuarios del entorno . . . . . . . . . . . 120 10.5. Resumen de los Requisitos del Sistema . . . . . . . . . . . . . . . . . 122 11.Dise no 123

11.1. Dise no de la Arquitectura del Sistema . . . . . . . . . . . . . . . . . 123 11.1.1. La capa reactiva: el Agente Reactivo AmiBot . . . . . . . . . 126 11.1.2. La capa deliberativa . . . . . . . . . . . . . . . . . . . . . . . 127 11.1.3. Comunicaci on entre capas y agentes . . . . . . . . . . . . . . 132 11.2. Localizaci on y mapeado simult aneo . . . . . . . . . . . . . . . . . . . 135 11.2.1. El mapa local . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 11.2.2. El mapa global . . . . . . . . . . . . . . . . . . . . . . . . . . 144 11.3. El planicador de rutas/secuencias . . . . . . . . . . . . . . . . . . . 145 11.3.1. C alculo del mejor camino entre mapas . . . . . . . . . . . . . 146 11.3.2. C alculo de la ruta dentro del mapa local . . . . . . . . . . . . 147 12.Implementaci on 151

12.1. El programa de mapeado AmiMap . . . . . . . . . . . . . . . . . . . 152 12.2. El demostrador AmiServer mejorado . . . . . . . . . . . . . . . . . . 154 12.3. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 12.3.1. Pruebas de Mapeado y localizaci on . . . . . . . . . . . . . . . 158 12.3.2. Pruebas de identicaci on de usuarios . . . . . . . . . . . . . . 160 12.3.3. Pruebas de comunicaci on de los datos con el ambiente inteligente e interacci on con los usuarios . . . . . . . . . . . . 161 12.3.4. Utilizaci on de los recursos del sistema . . . . . . . . . . . . . 161 13.Resultados 14.Conclusiones y l neas futuras 163 167

14.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 14.2. Limitaciones del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 168 14.3. Mejoras y l neas futuras . . . . . . . . . . . . . . . . . . . . . . . . . 169

 INDICE GENERAL

xv

III

S ntesis de resultados

173
175

15.S ntesis de resultados

15.1. Conclusiones de funcionamiento . . . . . . . . . . . . . . . . . . . . . 175 15.2. Experiencia Personal . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 15.3. Limitaciones y mejoras. L neas futuras. . . . . . . . . . . . . . . . . . 177

Bibliograf a

181

IV

Ap endices

183
185 187 191 197

A. Pliego de condiciones B. El est andar SMBUS C. Lista de materiales D. Planos

D.1. Red de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 D.1.1. Sensores piroel ectricos . . . . . . . . . . . . . . . . . . . . . . 197 D.1.2. Encoders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 D.1.3. ADC con interfaz I2C . . . . . . . . . . . . . . . . . . . . . . 201 D.1.4. Expansores I2C . . . . . . . . . . . . . . . . . . . . . . . . . . 203 D.2. Placa base de AmiBot . . . . . . . . . . . . . . . . . . . . . . . . . . 205 D.3. Actuadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 E. Diagramas de clases 213

E.1. Diagramas UML de AmiServer . . . . . . . . . . . . . . . . . . . . . 213 F. Presupuesto F.1. Presupuesto de ejecuci on material 219 . . . . . . . . . . . . . . . . . . . 219

F.1.1. Presupuesto de recursos software . . . . . . . . . . . . . . . . 219 F.1.2. Presupuesto de recursos hardware . . . . . . . . . . . . . . . 219 F.1.3. Costes de mano de obra . . . . . . . . . . . . . . . . . . . . . 221

xvi

INDICE GENERAL F.1.4. Coste total de los recursos . . . . . . . . . . . . . . . . . . . . 221

F.2. Gastos generales y benecio industrial . . . . . . . . . . . . . . . . . 222 F.3. Honorarios y presupuesto total . . . . . . . . . . . . . . . . . . . . . 222

 Indice de guras

1.1. Red de Sensores Multimedia Tradicional . . . . . . . . . . . . . . . . 2.1. Flujo de proceso de datos en la arquitectura AMISEC . . . . . . . . 2.2. Robot Shakey, del Stanford Research Institute . . . . . . . . . . . .

4 8 10 11 12 12 15 16 17 20 21 23 27 28 30 36 39 40 41 43 45

2.3. Robot Aibo, inteligencia individual y cooperativa . . . . . . . . . . . 2.4. Robot Asimo de Honda . . . . . . . . . . . . . . . . . . . . . . . . . 2.5. Robot BigDog, creado en 2005 para aplicaciones militares . . . . . . 2.6. Comportamiento reactivo y arquitectura de subsunci on . . . . . . . . 2.7. Comportamiento deliberativo: Modelo BDI . . . . . . . . . . . . . . 2.8. Arquitecturas H bridas . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1. Robot X80 Dr.Robot Inc. . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Esquema de conexi on y funcionamiento de la placa controladora de expansi on de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3. Sensores originales del robot X80 . . . . . . . . . . . . . . . . . . . . 3.4. Artila M-501 SoM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5. Artila M-501 Starter Kit . . . . . . . . . . . . . . . . . . . . . . . . . 3.6. Comunicaci on del robot con el ambiente inteligente . . . . . . . . . . 4.1. Distribuci on de los sensores de AmiBot . . . . . . . . . . . . . . . .

4.2. Arquitectura Hardware: diagrama de bloques . . . . . . . . . . . . . 4.3. Agrupaci on de los sensores por direcci on I2C . . . . . . . . . . . . . 4.4. Diagrama de bloques de la placa de inteligencia de AmiBot . . . . . 4.5. Malla de reacci on de AmiBot . . . . . . . . . . . . . . . . . . . . . . 4.6. Esquem atico del circuito de los bumpers y sensores infrarrojos xvii . . .

xviii

INDICE DE FIGURAS 46 46 47 48 49 50 50 53 54 55 56 57 58 60 61 61 62 63 65 66 66 68 70 71 73 80 98 99

4.7. Teor a de operaci on del multivibrador monoestable . . . . . . . . . . 4.8. Se nal de salida de los sensores piroel ectricos . . . . . . . . . . . . . . 4.9. Circuito de acondicionamiento de los sensores piroel ectricos . . . . . 4.10. Funcionamiento de los codicadores opticos . . . . . . . . . . . . . . 4.11. Circuito de acondicionamiento de los encoders . . . . . . . . . . . . . 4.12. Diagrama del bloque QEI del PIC18F2331 . . . . . . . . . . . . . . . 4.13. Diagrama temporal del bloque QEI del PIC18F2331 . . . . . . . . . 4.14. Dise no de los actuadores para las ruedas motrices de AmiBot . . . . 4.15. Control de los actuadores de AmiBot . . . . . . . . . . . . . . . . . . 4.16. Estrategia de alimentaci on del sistema - Separaci on por bloques . . . 4.17. Circuito de regulaci on de la alimentaci on . . . . . . . . . . . . . . .

4.18. Principio de funcionamiento del comportamiento reactivo . . . . . . 4.19. Sincronizaci on del sistema del agente reactivo . . . . . . . . . . . . . 5.1. Disposici on redundante de los sensores de AmiBot . . . . . . . . . . 5.2. PCB para los ADC con interfaz I2C . . . . . . . . . . . . . . . . . . 5.3. PCB para los expansores I2C . . . . . . . . . . . . . . . . . . . . . . 5.4. PCB para el acondicionamiento de los sensores piroel ectricos . . . . 5.5. La br ujula y el aceler ometro de 3 ejes de AmiBot . . . . . . . . . . . 5.6. PCB de acondicionamiento de los motores de las ruedas de AmiBot . 5.7. Bloques del PCB de la placa base de AmiBot . . . . . . . . . . . . . 5.8. PCB de la placa base de AmiBot montada con el SoM de Artila . .

5.9. Distribuci on de los PCBs sobre la cubierta de AmiBot . . . . . . . . 5.10. Diagramas de ujo de los comportamientos de AmiBot . . . . . . . . 5.11. Diagramas de ujo de los comportamientos de AmiBot (II) . . . . . 5.12. Interfaz gr aca del demostrador del servidor AmiServer . . . . . . . 6.1. Prototipo nal del robot AmiBot . . . . . . . . . . . . . . . . . . . . 9.1. Ejemplo de un mapa geom etrico . . . . . . . . . . . . . . . . . . . . 9.2. Ejemplo de mapa topol ogico . . . . . . . . . . . . . . . . . . . . . . .

9.3. Construcci on de un mapa geom etrico . . . . . . . . . . . . . . . . . . 100 9.4. Resultados del algoritmo de ltrado de part culas . . . . . . . . . . . 100

 INDICE DE FIGURAS

xix

9.5. Diagrama de Voronoi de un conjunto aleatorio de puntos . . . . . . . 102 9.6. Ejemplo de conguraci on bidimensional de los campos de potencial. a)Conguraci on del espacio con dos objetos. b) Atracci on generada por el destino. c) Repulsi on generada por los objetos. d) Suma de potenciales. e) L neas equipotenciales. f) Orientaciones del gradiente negativo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 10.1. Estructura detallada de la arquitectura AuRA . . . . . . . . . . . . . 106 10.2. Estructura de alto nivel de la arquitectura AuRA . . . . . . . . . . . 108 10.3. Ejemplo del error acumulado en el c alculo de la odometr a . . . . . . 110 10.4. Matriz de contribuci on de los sensores IR y USR . . . . . . . . . . . 113 10.5. Caracterizaci on de los sensores Infrarrojos . . . . . . . . . . . . . . . 114 10.6. Estrategia de creaci on de un mapa global y varios mapas locales . . 116 10.7. Plano del Laboratorio de Sistemas Integrados y divisi on en mapas . 117 10.8. Plano del Laboratorio de Sistemas Integrados y divisi on en mapas . 117 10.9. C amara CMOS del Robot X80 . . . . . . . . . . . . . . . . . . . . . 121 10.10. Servomotores Hitec HS-475HB . . . . . . . . . . . . . . . . . . . . . 122 11.1. Dise no de la arquitectura de AmiBot adaptada a la arquitectura AuRA124 11.2. Arquitectura del sistema completo . . . . . . . . . . . . . . . . . . . 125 11.3. Funcionamiento de la capa reactiva AmiBot . . . . . . . . . . . . . . 128 11.4. Estructura del m odulo de mapeado AmiMap . . . . . . . . . . . . . 130 11.5. Estructura del m odulo de identicaci on AmiCam . . . . . . . . . . . 133 11.6. Estructura de comunicaci on entre capas del sistema completo . . . . 134 11.7. Variables geom etricas en el c alculo de la odometr a . . . . . . . . . . 136 11.8. Caracterizaci on emp rica del movimiento del robot . . . . . . . . . . 138 11.9. Limitaciones del Algoritmo Nearest Neighbor . . . . . . . . . . . . 139

11.10. Ejemplo de creaci on de un Interpretation Tree . . . . . . . . . . . . . 140 11.11. Algoritmo JCBB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 11.12. Caso pr actico de reposicionamiento de un robot en el mapa . . . . . 142 11.13. Ejemplo de planicaci on de rutas entre mapas locales . . . . . . . . 146 11.14. Matriz de Dijkstra y Algoritmo de Floyd . . . . . . . . . . . . . . . . 147 11.15. Errores en la generaci on de rutas mediante Descomposici on de Celdas 148

xx

INDICE DE FIGURAS 11.16. Errores en la planicaci on de rutas mediante el algoritmo de Fast Marching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 11.17. Pasos en la planicaci on de rutas del robot. . . . . . . . . . . . . . . 149 12.1. Compartici on de la memoria de datos de AmiMap . . . . . . . . . . 156 12.2. Demostrador AmiServer con integraci on de los mapas del entorno . . 157 13.1. Prototipo nal del sistema AmiBot + AmiMap + AmiServer . . . . 163 B.1. Diagrama del protocolo de paquetes SMBus . . . . . . . . . . . . . . 188 B.2. Diagrama del protocolo Send Byte . . . . . . . . . . . . . . . . . . . 188 B.3. Diagrama del protocolo Receive Byte . . . . . . . . . . . . . . . . . . 188 B.4. Diagrama del protocolo Write Byte . . . . . . . . . . . . . . . . . . . 189 B.5. Diagrama del protocolo Read Byte . . . . . . . . . . . . . . . . . . . 189 D.1. Top Layer PCB Piroel ectrico (Zoom 2x) . . . . . . . . . . . . . . . . 197 D.2. Bottom Layer PCB Piroel ectrico (Zoom 2x) . . . . . . . . . . . . . . 197 D.3. Top y Bottom Layer PCB ADC por I2C (Zoom 2x) . . . . . . . . . 201

D.4. Top y Bottom Layer PCB Expander I2C (Zoom 1x) . . . . . . . . . 203 D.5. Top Layer PCB Placa base de AmiBot (Zoom 1x) . . . . . . . . . . 205 D.6. Bottom Layer PCB Placa base de AmiBot (Zoom 1x) . . . . . . . . 205 D.7. Top y Bottom Layer PCB Motores (Zoom 1.5x) . . . . . . . . . . . . 210 E.1. Diagrama de clases del paquete amiserver . . . . . . . . . . . . . . 214 E.2. Diagrama de relaciones del paquete amiserver.server . . . . . . . 215 E.3. Diagrama de clases del paquete amiserver.server . . . . . . . . . . 215 E.4. Diagrama de clases del paquete amiserver.amigui . . . . . . . . . . 216 E.5. Diagrama de clases del paquete amiserver.amigui.controller . . 217 E.6. Diagrama de clases del paquete amiserver.iface . . . . . . . . . . 217

 Indice de cuadros

3.1. Caracter sticas de los sensores del robot X80 original y mejorado . . 4.1. Dise no de la red de sensores de AmiBot . . . . . . . . . . . . . . . . 4.2. Integraci on de sensores en el bus I2C . . . . . . . . . . . . . . . . . . 4.3. Consumo estimado del sistema . . . . . . . . . . . . . . . . . . . . . 5.1. Analog Gain de los sensores de ultrasonidos . . . . . . . . . . . . . . 5.2. Direcciones de esclavo I2C de la red de sensores de AmiBot . . . . . 5.3. Estructura de archivos del agente reactivo AmiBot . . . . . . . . . . 5.4. Estructura de archivos del servidor AmiServer . . . . . . . . . . . . .

25 35 44 56 62 64 72 74

10.1. Tabla de ajuste de los sensores Infrarrojos . . . . . . . . . . . . . . . 114 10.2. Tabla de ajuste de los sensores Ultrasonidos . . . . . . . . . . . . . . 115 12.1. Estructura de archivos del agente reactivo modicado AmiBot . . . . 153 12.2. Estructura de archivos del programa AmiMap . . . . . . . . . . . . . 155 12.3. Estructura de archivos del servidor AmiServer mejorado . . . . . . . 159 12.4. Utilizaci on de los recursos del sistema . . . . . . . . . . . . . . . . . 162 C.1. Lista de materiales para la Red de Sensores, ADC y Expansores I2C 192

C.2. Lista de materiales para el Acondicionamiento de los sensores Piroel ectricos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 C.3. Lista de materiales para la Placa base de AmiBot(1) . . . . . . . . . 194 C.4. Lista de materiales para la Placa base de AmiBot (2) . . . . . . . . . 195 C.5. Lista de materiales para el acondicionamiento de los motores . . . . 196 F.1. Presupuesto de los recursos software . . . . . . . . . . . . . . . . . . 220 xxi

xxii

INDICE DE CUADROS

F.2. Presupuesto de los recursos hardware . . . . . . . . . . . . . . . . . . 220 F.3. Costes de mano de obra . . . . . . . . . . . . . . . . . . . . . . . . . 221 F.4. Coste total de los recursos . . . . . . . . . . . . . . . . . . . . . . . . 221 F.5. Gastos generales y benecio industrial . . . . . . . . . . . . . . . . . 222 F.6. Honorarios y presupuesto total . . . . . . . . . . . . . . . . . . . . . 222

Parte I

An alisis y dise no de un Robot m ovil aut onomo para un entorno inteligente

Cap tulo 1 Introducci on

La inteligencia ambiental, tal y como la conocemos hoy en d a, es un concepto que naci o en la d ecada de los 90, con el n de centrar todo el proceso de dise no de productos en los usuarios, aport andoles experiencias y usabilidad. Desde entonces y hasta nuestros d as, se han mantenido como requisitos b asicos de un ambiente inteligente los siguientes puntos: La necesidad de un hardware asociado no intrusivo, que forme parte del ambiente sin molestar al usuario. La adaptaci on y personalizaci on del ambiente a las preferencias del usuario. El reconocimiento de los usuarios y la anticipaci on a sus deseos. Los ambientes inteligentes estar an formados por una extensa y compleja red de sensores capaces de monitorizar a los usuarios o bien de interactuar con ellos para la creaci on del propio entorno inteligente (ver gura 1.1). En una primera iteraci on, tendemos a pensar que esta red de sensores estar a formada por c amaras, sensores de presencia, alarmas y, en general, todo tipo de sensores jos, que en s mismos y aislados del entorno carecen de inteligencia, pero que en conjunto a naden informaci on al ambiente y permiten una computaci on ubicua. Este tipo de estructura de red de sensores, sin embargo, presenta diversas debilidades. Entre ellas, se halla el hecho de que una red de sensores ja puede y suele tener una serie de zonas muertas, a las que no llega ning un sensor o no lo hace con suciente precisi on. Pese a que aumentemos el n umero de sensores, es muy posible que esas zonas muertas sigan existiendo, sobretodo cuando entramos en temas de reconocimiento de im agenes mediante c amaras. Sin embargo, si ampliamos el concepto de la red de sensores, podemos pensar en otro tipo de sensor, un sensor m ovil con la suciente inteligencia como para recorrer el entorno, llegando a los puntos donde el resto de sensores no llegan, y cumpliendo tambi en parte de la funci on de reconocimiento de usuarios. Nuestra propuesta es implementar este sensor m ovil mediante un robot m ovil capaz de recorrer el ambiente inteligente de forma aut onoma, a nadiendo la informaci on al 3

CAP ITULO 1. INTRODUCCION

Figura 1.1: Red de Sensores Multimedia Tradicional Fuente: Georgia Institute of Technology. Wireless Networking Lab. entorno que sea necesaria, cumpliendo con una m axima: estar en el lugar adecuado en el momento oportuno. Los robots m oviles surgieron a partir de los avances tecnol ogicos producidos durante la Segunda Guerra Mundial, y la investigaci on en este campo se fue extendiendo con el paso de los a nos, cobrando cada vez mayor importancia. En la d ecada de los 80 el Massachusetts Institute of Technology [26] comenz o a investigar con robots aut onomos que presentaban comportamientos reactivos (Behaviourbased robotics ) y que eran capaces de reaccionar a cambios en su entorno con una inteligencia relativamente sencilla, mediante el uso de una gran cantidad de sensores. Hoy en d a, coexisten diversos modelos a la hora de programar la inteligencia de un robot: desde los modelos proactivos, basados en esquemas de comportamiento, pasando por los modelos BDI (en que s olo unos par ametros son esquematizados) hasta los modelos reactivos, adem as de los h bridos de todos los anteriores. En general, sin embargo, son los modelos reactivos los que permiten una mayor adaptaci on a los cambios del entorno. Debemos tener en cuenta, sin embargo, que para poder tener un robot totalmente aut onomo e integrado en el ambiente, este deber a ser capaz de localizarse y de reconocer a los usuarios que le rodean. El tratamiento de estos dos temas quedar a pospuesto hasta la segunda parte de este Proyecto Final de Carrera. La primera parte de este Proyecto Final de Carrera est a dedicada al An alisis y Dise no de un robot m ovil aut onomo para un entorno inteligente. Para ello trataremos en primer lugar los conceptos b asicos de los ambientes inteligentes, con el n de poder dise nar un robot que sea capaz, desde un principio, no s olo de ser compatible con su entorno, sino de enriquecerlo sem anticamente. A continuaci on, nos introduciremos

1.1. OBJETIVOS

de lleno en el an alisis de los robots m oviles y, una vez reunidas las herramientas necesarias, se dise nar a (e implementar a) un prototipo de robot m ovil aut onomo integrado en el ambiente inteligente del Laboratorio de Sistemas Integrados del Departamento de Ingenier a Electr onica. Antes de empezar realizaremos una breve introducci on a los ambientes inteligentes y a los robots m oviles aut onomos, que nos servir a para realizar una justicaci on del proyecto y nos permitir a entender en qu e es beneciosa la acci on de un robot m ovil en un entorno.

1.1.

Objetivos
Los objetivos de esta primera parte ser an: An alisis del soporte hardware y software m as adecuado para el robot m ovil, as como de la capacidad de procesado necesaria del robot, partiendo del actual robot del laboratorio X80 Robot de Dr. Robot Inc. An alisis de las diferentes metodolog as de dise no de los robots m oviles actuales, centr andose en metodolog as de comportamiento reactivo. Dise no del comportamiento reactivo. An alisis de los sensores a utilizar para interaccionar con el entorno, y dise no de la red de sensores del robot m ovil. Dise no de un robot m ovil, capaz de desplazarse por el entorno de forma aut onoma, detectando obst aculos y personas y reaccionando adecuadamente ante ellos. Habilitar la comunicaci on del robot con el exterior por una interfaz inal ambrica (WiFi).

1.2.

Fases del trabajo

Con el n de cumplir los objetivos m as arriba mencionados, dividiremos esta parte del proyecto en las siguientes fases: 1. An alisis del estado del Robot X80, en especial de la red de sensores. Estudio de las necesidades de dicha red, as como de los requisitos del software para poder tener un comportamiento aut onomo. Estudio de los requisitos gen ericos del sistema. 2. Elecci on de los elementos hardware, tanto de la red de sensores como del procesador principal, y del modelo software de comportamiento. 3. Dise no del acondicionamiento de los sensores, de su comunicaci on con la placa, de la alimentaci on del robot y de los motores.

6 4. Dise no del comportamiento reactivo.

CAP ITULO 1. INTRODUCCION

5. Dise no de la comunicaci on con el ambiente inteligente. 6. Implementaci on de la red de sensores, realizando los montajes necesarios mediante PCBs (Printed Circuit Boards) y de una red de comunicaci on b asica robot-ambiente. Realizaci on de pruebas de conjunto para comprobar el comportamiento reactivo del robot y su reacci on ante el ambiente. En los siguientes cap tulos, se desarrollar an en detalle las fases del trabajo expuestas.

Cap tulo 2 Estado del Arte

En este cap tulo veremos el estado del arte tanto de los ambientes inteligentes, como de los robots m oviles aut onomos. De este modo podremos tener una percepci on clara sobre cu ales han sido sus evoluciones a lo largo de la historia, e intuir cu ales ser an las tendencias de futuro. Tambi en estudiaremos con detalle la experiencia previa que el Laboratorio de Sistemas Integrados ha tenido, tanto en el tema de ambientes inteligentes, como en el de robots m oviles. As podremos, en los pr oximos cap tulos, desarrollar un an alisis y dise no inteligente y actualizado, que procurar a aprovechar las ventajas de las tendencias actuales, implementando las mejoras necesarias.

2.1.

Ambientes Inteligentes

El concepto de Ambiente Inteligente surgi o a partir de los a nos 90, coincidiendo hist oricamente con un cambio de visi on en la producci on industrial. Se pasaba de un modelo de producci on centrado exclusivamente en el producto nal, a un modelo en el que lo m as importante era el usuario. As , podemos entender un ambiente inteligente como un entorno dotado con una tecnolog a capaz de sentir a los usuarios y responder a sus necesidades, anticip andose a ellos. Los fundamentos de los ambientes inteligentes se remontan al concepto creado por Weiser en 1991 [34] sobre computaci on ubicua, y se desarrollaron sobre una gran base multidisciplinar, mezcla de inform atica, electr onica, dom otica y comunicaciones, entre otras. La computaci on ubicua, tambi en llamada pervasive computing o everyware, puede entenderse como un modelo de interacci on persona-ordenador en el que la tecnolog a ha sido tan sumamente integrada en el entorno, que el usuario podr a interaccionar con ella, pero no ser a consciente de d onde reside la inteligencia. A el s olo le ser a accesible la interfaz nal. La computaci on la llevar an a cabo cada uno de los diferentes dispositivos del ambiente inteligente, por separado o conjuntamente, de forma que desde el exterior ser a indistinguible qui en ha realizado cada parte. De acuerdo con el p arrafo anterior, los ambientes inteligentes estar an formados por una gran red de sensores y dispositivos capaces tanto de sensar 7

CAP ITULO 2. ESTADO DEL ARTE

como de interaccionar con los usuarios. Este sensado deber a ser no intrusivo y estar a distribuido por todo el ambiente. La interacci on deber a realizarse a trav es de interfaces lo m as amigables posible, teniendo siempre presente que el usuario es el centro de todo. Adem as, ser a muy importante dotar de seguridad al ambiente inteligente.

Figura 2.1: Flujo de proceso de datos en la arquitectura AMISEC Fuente: [13] En los entornos inteligentes, tanto o m as que otros entornos, deberemos tener en cuenta la seguridad, dado que son sistemas susceptibles de ser atacados. Estos ataques ir an dirigidos a la obtenci on de datos privados, ya sea de los usuarios o del propio ambiente, y es importante interponer medidas para evitarlos. Los ambientes inteligentes son entornos inseguros de por s a causa de tres factores b asicos. En primer lugar porque muchos de los nodos de la red de sensores tienen recursos muy limitados. En segundo lugar, porque si se quieren abarcar todas las areas posibles para el sensado, algunos nodos se colocar an en lugares a los que puedan acceder intrusos y manipularlos; y en tercer lugar, dado que todos los servidores estar an interconectados, es relativamente sencillo propagar los ataques paso a paso, desde las m aquinas menos protegidas hacia las m as seguras. Por contra, un ambiente inteligente cuenta con dos factores que s favorecen a poder crear un entorno seguro: la redundancia de la red de sensores, que nos permitir a detectar nodos defectuosos o comprometidos; y la continua adaptaci on y evoluci on de los ambientes, que fuerzan cambios en el comportamiento de los nodos. Explotando estas dos capacidades mediante la arquitectura AMISEC[13] (ver gura 2.1), se puede generar un ujo de datos que permite enriquecer sem anticamente el ambiente sin comprometer el

 2.2. ROBOTS MOVILES AUTONOMOS sistema.

La primera parte de este Proyecto Final de Carrera, tal y como se ha visto en la introducci on, plantea la creaci on de un nuevo nodo m ovil en la red de sensores. Hasta ahora se hab an planteado las contribuciones de este nuevo sensor m ovil desde dos puntos de vista: por una parte con la funci on de cubrir las zonas muertas del entorno, a las que no llegan los sensores jos; y por otra la de realizar una parte importante del reconocimiento de usuarios. A todo ello podemos a nadir la contribuci on de un sensor m ovil a la seguridad del entorno inteligente. Un sensor m ovil, capaz de estar donde deba estar en el momento adecuado, puede a nadir la redundancia necesaria al sistema para ayudar a determinar si otro nodo est a comprometido o presenta un mal funcionamiento. En los u ltimos a nos, y a causa de todos los campos de estudio implicados, los Ambientes Inteligentes han supuesto una modicaci on de la visi on m as tradicional de las tic (Tecnolog as de la Informaci on y Comunicaci on). Los entornos inteligentes permiten a los usuarios interactuar con ellos de forma intuitiva y sencilla, abriendo todo un abanico de nuevas posibilidades, tanto a la imaginaci on como a la implementaci on real. Poco a poco, los ambiente inteligentes van estando m as presentes en la vida cotidiana de las personas y cada vez existe un mayor volumen de investigaci on sobre este tema [25].

2.2.
2.2.1.

Robots m oviles Aut onomos

Evoluci on y estado actual

La rob otica hizo su primera aparici on en la historia, no como descubrimiento cient co, sino como palabra en la novela Runaround del cient co y escritor americano Issac Asimov en 1941. De hecho la palabra robot deriva del checo robota, que viene a signicar tarea forzada. La evoluci on de la rob otica tuvo lugar a ra z de los avances t ecnicos llevados a cabo durante la Segunda Guerra Mundial, si bien los primeros robots m oviles dise nados con nes militares, eran poco m as que bombas voladoras, predecesoras de los misiles. Desde un inicio, sin embargo, la rob otica como ciencia siempre ha estado ntimamente ligada con la inteligencia articial. Los primeros robots m oviles capaces de aprender tareas como detectar obst aculos datan de los a nos 50, y llamaron la atenci on enseguida de los pioneros de la inteligencia articial. Estos robots tan tempranos, sin embargo, pese a querer realizar tareas sencillas, ten an estaban limitados por el hardware, dado que las grandes dicultades consist an en su capacidad de movilidad y sensado del entorno. De hecho, el primer robot con un hardware sucientemente desarrollado como para ser capaz de mostrar un comportamiento aut onomo fue Shackey (ver gura 2.2), en 1970. Este robot ten a una c amara, sensores de distancia, sensores de choque y un enlace radio. Poco despu es, en 1974, se lanz o al mercado Silver Arm , un brazo rob otico capaz de ensamblar peque nas piezas utilizando sensores de contacto. Entre los a nos 50 y 70, sin embargo, la limitaci on pas o a estar en las teor as de la inteligencia articial. Se pretend a dotar a los robots, primero de redes neuronales

10

CAP ITULO 2. ESTADO DEL ARTE

Figura 2.2: Robot Shakey, del Stanford Research Institute Fuente: The Field Robotics Center, Courtesy of SRI International

y despu es de l ogicas complejas, abstractas y desconectadas del mundo, con el n de asemejar la inteligencia del robot a la ser humano, dot andole de un cerebro con cualidades semejantes. Este tipo de IA funcionalista vio su fracaso al inicio de los a nos ochenta con el surgimiento de otras teor as, como la rob otica aut onoma de Rodney Brooks que propon a acabar con las teor as extremadamente complicadas de la IA cl asica y empezar por lo m as sencillo. As , propon a dotar a los robots de una inteligencia b asica, semejante a la de los insectos, que les permitiera reaccionar frente a su entorno e ir avanzando poco a poco. Es as como nacieron las teor as multiagentes. Los agentes son cualquier ente capaz de obtener informaci on del entorno, procesarla y actuar sobre el. La uni on de muchos agentes simples, seg un Brooks, permit a crear robots m as inteligentes. Era el nacimiento de los robots aut onomos, tal y como los conocemos en la actualidad. El avance en paralelo de las teor as de la inteligencia y la microelectr onica llev o a que a partir de los a nos 80 y 90 se produjera un periodo de auge de la rob otica. Este se produjo tanto por parte de cineastas y escritores, que utilizaban la rob otica como punto central en sus historias de ciencia cci on (como la saga de pel culas Star Wars, de George Lucas), como por parte de institutos de investigaci on y universidades. Este auge se dio sobretodo en la vertiente de la rob otica dedicada al ambito industrial y de la medicina, mediante la creaci on de brazos m oviles que realizaban tareas peligrosas, repetitivas o desagradables para las personas. En el a no 1995 funcionaban unos 700.000 robots en el mundo industrializado. M as de 500.000 se empleaban en Jap on, unos 120.000 en Europa Occidental y unos 60.000

 2.2. ROBOTS MOVILES AUTONOMOS

11

en Estados Unidos. Paralelamente a los robots para la industria, se desarrollaron robots educacionales, como es el caso de la uni on entre la empresa LEGO y el MIT Media Lab en el a no 86 para llevar a las aulas de los colegios su proyecto de Lego tc Logo. La empresa LEGO continuar a en los a nos posteriores investigando en el campo de la rob otica, lanzando en 1998 su gama de productos Lego Mindstorms. Pero sin duda, la revoluci on en el campo de los robots m oviles aut onomos y la inteligencia articial se produjo en 1999 cuando SONY introdujo en el mercado su robot-mascota AIBO (g. 2.3), y al a no siguiente cuando Honda sac o al mercado su robot humanoide ASIMO (g. 2.4). Aibo es un robot-mascota con forma de perro, y constituye uno de los juguetes m as sosticados del mercado. Mediante una red de sensores y una cola que funciona de antena, Aibo genera su interacci on con el mundo exterior. Reconoce gestos y la actitud corporal de su due no, presenta emociones e instintos. Este robot ha sido utilizado para la investigaci on en inteligencia articial tanto aisladamente como en conjunto con otros robots, en todo tipos de pruebas de inteligencia cooperativa. En concreto, Aibo ha sido presentado varias veces a las competiciones RoboCup[18], en concreto la RoboCupSoccer, en la que varios robot Aibo colaboran entre ellos para jugar (y tratar de ganar) un partido de f utbol. Pese a que en sus inicios Aibo se comercializaba, en el a no 2003, dej o de comercializarse, pese a que siguieron fabricando nuevas generaciones del robot.

Figura 2.3: Robot Aibo, inteligencia individual y cooperativa Fuente: International Journal of Industrial Robot Asimo (ver gura 2.4) es un robot humanoide creado por Honda. Con una altura de 133 cm y un peso de 54Kg el robot se asemeja a un astronauta. Asimo es capaz de caminar, subir y bajar escaleras, reconocer objetos en movimiento, gestos, personas y sonidos, e incluso conectarse a Internet. Es capaz de moverse de forma aut onoma durante cerca de 40 minutos mediante un pack de bater as de Li-ion de 51.8V y 6Kg de peso, y tambi en de cooperar con otros robots Asimo. Sin embargo, uno de los robots m as novedosos de la actualidad es el BigDog (g. 2.5), un robot con forma de perro grande utilizado para aplicaciones militares y capaz de moverse por todo tipo de terrenos, incluyendo el hielo o las rocas.

12

CAP ITULO 2. ESTADO DEL ARTE

Figura 2.4: Robot Asimo de Honda Fuente: Blog www.conectarnos.com Este robot, adem as de un gran esfuerzo de inteligencia articial, demuestra un enorme esfuerzo de hardware. El control de los servo-motores de las patas del robot constituye un problema de ingenier a de dif cil soluci on. El robot BigDog fue creado en el a no 2005 por una colaboraci on entre Boston Dynamics con Foster-Miller, el Laboratorio de Propulsi on de Jets de la NASA y la Universidad de Harvard.

Figura 2.5: Robot BigDog, creado en 2005 para aplicaciones militares Fuente: Blog www.unsayablejazer.com Por u ltimo, no podemos dejar de mencionar el robot m as vendido de la actualidad: el robot aspirador Roomba, lanzado en 2002. La empresa iRobot ha lanzado ya tres generaciones distintas de este robot, y tiene una implantaci on real en muchos hogares, en los que empieza a convertirse en un electrodom estico m as. En la actualidad, la rob otica sigue avanzando como un campo multidisciplinar, bas andose en los robots aut onomos de Brooks, a nadi endoles grados de inteligencia sin que ello empeore su autonom a. Las limitaciones de hardware e inteligencia

 2.2. ROBOTS MOVILES AUTONOMOS

13

intentan avanzar paralelamente para conseguir los mejores resultados, con robots cuyo comportamiento imita cada vez mejor el de animales y personas. Nos hallamos ante el surgimiento de la rob otica evolutiva basada en algoritmos gen eticos.

2.2.2.

Sensado del ambiente

El sensado del entorno constituye uno de los puntos clave de los robots m oviles aut onomos que vayan a desplazarse en un ambiente desconocido. El sensado proporciona conocimiento sobre el exterior y permite al robot no s olo moverse esquivando objetos, detectando paredes, desniveles o personas, sino obtener un conocimiento real del mapa del entorno. Con el n de conocer el ambiente, los robots m oviles disponen de una red de sensores que ofrece resultados ables basados en la redundancia de sensores y en la comparaci on entre medidas. Dependiendo del tipo de robot, de su forma de moverse por el entorno (mediante ruedas, piernas m oviles, o incluso por el aire, como los robots m oviles en forma de peque nos helic opteros aut onomos) y de su utilizaci on, esta red de sensores sufrir a modicaciones para permitir al robot m ovil detectar mejor los par ametros concluyentes del entorno. En general, sin embargo, los sensores m as comunes en los robots m oviles aut onomos son los siguientes: Sensores de ultrasonidos: utilizados para detectar objetos y la distancia a la que se encuentran. Constan de un emisor de ondas a 40KHz y de un receptor. En funci on de si la onda emitida es recibida y del tiempo transcurrido entre emisi on y recepci on, puede calcularse la distancia a la que se encuentran diversos objetos. Estos sensores presentan un funcionamiento err oneo frente a objetos con poca reexi on o con demasiada reexi on. Estos sensores pueden tener un alcance de hasta los 10 o 12 metros. Algunos robots m oviles navegan u nicamente mediante la utilizaci on de un array de 20 o 25 de estos sensores. Sensores Infrarrojos: basados en el mismo principio que los sensores de ultrasonidos, si bien en este caso se emite un infrarrojo que es capaz de medir objetos s olo hasta distancias menores (de entorno a 1 metro). La ventaja de estos sensores con respecto a los anteriores es que se comportan mejor frente a algunos materiales que los sensores de ultrasonidos. Bumpers o sensores de choque: la mayor a de los robots m oviles incorporan sensores de choque, dado que en los entornos reales existen gran cantidad de objetos que, ya sea por su tama no o posici on (patas de mesas, sillas, obst aculos del terreno) los sensores de ultrasonidos o infrarrojos son incapaces de detectar. Sensores piroel ectricos: estos sensores son capaces de detectar el movimiento de cuerpos que emiten radiaci on infrarroja, y su aplicaci on es la detecci on de personas en movimiento. Este tipo de sensores son utilizados para seguir movimientos y detectar presencia, distinguiendo personas de objetos en un entorno. Otros sensores: nivel de bater as, nivel de corriente en motores, sensores de luz, ruido ambiental. . .

14

CAP ITULO 2. ESTADO DEL ARTE

La mayor a de robots m oviles utilizan algunos o todos de los sensores arriba mencionados. En los u ltimos a nos, sin embargo, adem as de redes de sensores los robots tienden a utilizar cada vez con mayor frecuencia c amaras de a bordo que, mediante un procesado de imagen, les permitan reconocer los objetos del entorno con una mayor abilidad. Conforme avanzan las capacidades de los dispositivos empotrados y por tanto su rapidez de c alculo, cada vez se tiende a utilizar m as el reconocimiento de imagen. Es habitual, por tanto, que la mayor a de los robots m oviles dispongan de una c amara adem as de su red de sensores, que a nade informaci on al conocimiento del entorno que tiene el robot. Pese a que el reconocimiento de caras puede ser actualmente sucientemente simple como para poderse llevar a cabo en el propio robot, el reconocimiento de objetos, por su complejidad, todav a resulta dif cil de integrar en un robot m ovil. Por ello actualmente es muy com un ver t ecnicas h bridas de reconocimiento del entorno, que combinan el reconocimiento de personas y objetos mediante c amaras con el sensado del entorno mediante redes formadas por un gran n umero de sensores.

2.2.3.

Modelos de comportamiento

El segundo punto clave de los robots m oviles aut onomos es el modelo de comportamiento que seguir an a la hora de interactuar con su entorno. El comportamiento de un robot m ovil viene determinado por el software que gobierna sus actuaciones y le transforma en un agente inteligente. En funci on del modelo utilizado para denir el comportamiento del robot podremos distinguir entre Agentes Reactivos, Agentes Deliberativos y Arquitecturas H bridas. Los Agentes Reactivos En los agentes reactivos el comportamiento sigue un ciclo simple de percepci on-acci on (tambi en entendido como est mulo-respuesta). En un sistema reactivo puro las acciones no tienen en cuenta ni el pasado ni el futuro, sino s olo la percepci on del entorno, dado que este puede haber variado con el tiempo. Dado que este modelo puede resultar muy austero, algunos agentes reactivos incorporan memoria sobre su estado interno, es decir, tienen en cuenta las reacciones anteriores que han tenido frente al entorno. Sin embargo, este hecho de a nadir memoria al sistema, les hace m as incapaces de reaccionar frente a los cambios del entorno. Es por ello que, en general, los agentes reactivos optan por una arquitectura de subsunci on (ver gura 2.6). Las arquitecturas de subsunci on est an formadas por un conjunto de comportamientos que realizan tareas simult aneamente. Los comportamientos toman decisiones en base a la percepci on del entorno, sin modicarla ni realizar ning un tipo de transformaci on. Todos los comportamientos est an situados jer arquicamente y ordenados por capas, de forma que las capas m as bajas inhiban a las superiores en la toma de decisiones. En general, podemos decir que los agentes reactivos est an constituidos de numerosos agentes que constituyen unidades sencillas, exibles y robustas a

 2.2. ROBOTS MOVILES AUTONOMOS

15

Figura 2.6: Comportamiento reactivo y arquitectura de subsunci on Fuente: Agentes Inteligentes. Juan Pav on Mestras. UCM. fallos, r apidamente programables mediante comportamientos simples. Sin embargo, presentan algunos inconvenientes, como la necesidad de tener suciente informaci on del entorno como para comportarse adecuadamente y su visi on a corto plazo y dif cil aprendizaje. La arquitectura est a pensada para un n umero reducido de comportamientos sin m as metodolog a para su creaci on que el ensayo y error. La dicultad en la programaci on crece exponencialmente con el n umero de comportamientos, dado que la interacci on entre ellos se convierte en una malla cada vez m as complicada.

Los Agentes Deliberativos Los agentes deliberativos, por contraposici on con los reactivos, proceden de arquitecturas cognitivas utilizadas en la inteligencia articial. A naden un paso m as entre la percepci on y la acci on que es la deliberaci on, con el n de elegir la acci on correcta. Esta deliberaci on requiere de dos procesos: en primer lugar una decisi on sobre qu e objetivo se quiere perseguir y, en segundo lugar, con qu e acci on se va a alcanzar ese objetivo. La estructura obliga a la realizaci on de un razonamiento pr actico, en cada momento las acciones nos llevan a cumplir los objetivos. Los Agentes Deliberativos siguen el modelo BDI: Beliefs, Desires, Intentions (creencias, deseos e intenciones, ver gura 2.7). Las intenciones son un conjunto de reglas que dirigen el razonamiento, y por tanto a naden una restricci on a cu ando y c omo se van a conseguir los objetivos. Las intenciones no son est aticas, sino que deben ser revisadas cada cierto tiempo para ver cu ales siguen siendo v alidas, cu ales nunca se van a alcanzar y cu ales se han alcanzado ya. En funci on de la tasa de actualizaci on de estas intenciones, tendremos dos tipos de agentes BDI: los atrevidos, que actualizan las intenciones cada largos periodos de tiempo y que por tanto tienden a la consecuci on r apida de los objetivos, equivoc andose en ocasiones; y los reactivos, que revisan muy a menudo

16

CAP ITULO 2. ESTADO DEL ARTE

Figura 2.7: Comportamiento deliberativo: Modelo BDI Fuente: Agentes Inteligentes. Juan Pav on Mestras. UCM. sus intenciones con el n de reaccionar a los cambios del entorno. Es complicado encontrar un equilibrio en los agentes BDI. Las creencias son los par ametros jos que el agente conoce con respecto al entorno. Las creencias pueden ser actualizadas cuando las intenciones cambian o cambia la percepci on del entorno. Las creencias generan una serie de opciones de actuaci on que luego ser an ltradas por los Deseos, que guardan qu e acciones quieren que cumpla el agente en el futuro. Es posible que existan deseos que en cierto momento sean contradictorios o presenten alg un tipo de conicto. Con el tiempo se ha extendido el modelo BDI, a nadi endole Objetivos, Intenciones y Planes. La dicultad de los agentes BDI consiste en encontrar implementaciones que sean ecientes, dado que todo el proceso de planicaci on del agente ser a altamente dependiente de la velocidad de variaci on del entorno. Esto complica la utilizaci on de arquitecturas BDI para entornos altamente susceptibles a cambios.

Las Arquitecturas H bridas Las Arquitecturas H bridas (ver gura 2.8) surgen como una soluci on a los problemas de la arquitectura reactiva y la arquitectura BDI. Intentan paliar, a la vez, los problemas de un agente reactivo, que se halla demasiado ocupado por el entorno como para llegar a cumplir un objetivo, y los de un agente BDI, cuya denici on del equilibrio entre reacci on y atrevimiento suele ser muy delicado. Para conseguirlo dividen el sistema en capas. El nivel de capa m as bajo corresponde al reactivo, en el que se toman decisiones en funci on del entorno. Por encima de esta capa tendremos la planicaci on y modelado del entorno. De esta forma no se pierde la simplicidad del nivel reactivo, pero a este se a naden la

 2.2. ROBOTS MOVILES AUTONOMOS

17

Figura 2.8: Arquitecturas H bridas Fuente: Agentes Inteligentes. Juan Pav on Mestras. UCM. planicaci on necesaria como para llegar a la consecuci on de acciones. Las arquitecturas h bridas son las que mejor resultado dan hoy en d a cuando se quiere dotar de cierta complejidad a un robot m ovil que, a la vez, deba ser capaz de reaccionar en entornos cambiantes. Esta es la arquitectura apuntada por Ronald Arkin [5] en la mayor a de sus libros.

2.2.4.

Proyectos de desarrollo software

Existen en la actualidad un gran n umero de proyectos de desarrollo de software para robots, que ofrecen librer as o toolkits que facilitan la programaci on de los mismos. Los toolkits suelen utilizar un lenguaje de programaci on propio para la descripci on del robot y la programaci on de su comportamiento. Act uan como una capa de traducci on, pasando de los comandos b asicos de descripci on y comportamiento a funciones complejas que ejecutan una serie de par ametros. Las librer as suelen utilizar como soporte lenguajes de programaci on ampliamente conocidos, de forma que los programadores puedan utilizar esas librer as para hacer m as f acil su labor con el robot. Algunos de estos proyectos software son propietarios, mientras que otros son abiertos. Algunos de los proyectos de desarrollo software de la actualidad son: Actin: toolkit basado en software patentado por la NASA, que permite describir mediante un lenguaje sencillo un robot y su comportamiento deseado. Actin producir a entonces los algoritmos de tiempo real necesarios para que el robot tenga el comportamiento deseado. Lego Mindstorms NXT: plataforma software que permite la programaci on de robots de un modo totalmente gr aco. Est a escrito en Labview, y su interfaz y forma de programar los robots es muy semejante a la utilizada en Labview. Proyecto Oroco: este proyecto desarrolla software libre de uso gen erico y modular para el control de robots (tanto m oviles como industriales). Ofrece toda una serie de librer as (en C++, generalmente) que pueden utilizarse en cualquier programa, divididas en toolkits seg un su funci on (librer as de tiempo real, ltrado bayesiano, kinem atica, etc.)

18

CAP ITULO 2. ESTADO DEL ARTE RoboMind: Robomind es un toolkit para el aprendizaje sencillo del mundo de la rob otica y de la programaci on de robots en general. Dispone de una interfaz gr aca amigable y es software libre.

Estas plataformas de desarrollo software permiten aplicar soluciones gen ericas a robots gen ericos, que compartan las caracter sticas b asicas y las necesidades propias de un robot aut onomo para aplicaciones de uso general (desplazamiento por el entorno, localizaci on, etc.). Con el tiempo se han ido perfeccionando e incorporan algoritmos m as complejos que permiten dotar al robot de una gran inteligencia. La arquitectura software y el modelado del comportamiento, sin embargo, quedar a oculto bajo esta capa de interfaz.

2.3.

Experiencia previa del laboratorio

La experiencia del Laboratorio de Sistemas Integrados en cuanto a ambientes inteligentes se reere es extremadamente amplia. Durante los u ltimos a nos se han dedicado bastantes proyectos, tanto de estudiantes como de doctorandos, al estudio de este campo. En concreto, disponen de un sistema de comunicaci on inal ambrica entre dispositivos inteligentes mediante Zigbee, as como de diversas aplicaciones nales que lo utilizan; entre ellas un sistema de reconocimiento de caras y gestos, y un sistema de localizaci on de personas en interiores. Adem as, la plataforma de seguridad AMISEC, explicada anteriormente, fue dise nada en este laboratorio. El Laboratorio de Sistemas Integrados contaba tambi en con experiencia en el campo de los robots m oviles. En concreto, el laboratorio cuenta con una unidad del robot m ovil X-80 de Dr.Robot Inc., que fue sujeto de estudio y mejora de un Proyecto Fin de Carrera anterior [30]. El robot X-80, junto con las mejoras que le fueron implementadas y que concretaremos m as adelante, ser a el punto de partida para este proyecto. La experiencia previa de este grupo de investigaci on, tanto en temas de ambientes inteligentes como de robots m oviles, as como los medios materiales de que dispone, hacen posible la consecuci on de este Proyecto Fin de Carrera.

Cap tulo 3 An alisis

3.1. La plataforma de trabajo

A continuaci on realizaremos un an alisis de la plataforma de trabajo para este Proyecto Fin de Carrera, que ser a el robot X80[19] de Doctor Robot Inc. Veremos sus caracter sticas b asicas, as como las mejoras de implementaci on que presenta frente al robot original, y analizaremos sus limitaciones y ventajas.

3.1.1.

El robot X80 de Dr. Robot Inc.

El robot X80 (ver gura 3.1) es un robot con ruedas de 3Kg de peso que pretende ser a la vez robusto y r apido, con la suciente movilidad como para desplazarse por entornos complicados. El robot dispone de dos motores de 12V DC (uno para cada rueda motriz) que le permiten desplazarse a una velocidad m axima de hasta 1m/s. Adem as, una tercera rueda da estabilidad al robot y le permite cargar con hasta 10Kg de peso adicional colocados sobre su plataforma superior. El robot original contaba con una red de sensores formada por 7 sensores infrarrojos (de salida anal ogica), 3 sensores de ultrasonidos (de salida digital), 2 sensores piroel ectricos de salida digital, 2 encoders digitales para saber la velocidad de giro de las ruedas, un micr ofono, un altavoz y una c amara CMOS de 352x288 p xeles. Adem as, incorporaba un m odulo Wi-Fi 802.11b para su comunicaci on con un ordenador que tuviera instalado el control Active X y el software adecuado de Dr. Robot Inc. que ven a de serie con el robot. El robot ofrec a la posibilidad, adem as, de conexi on de un display LCD, as como de ampliar de forma sencilla el n umero de sensores o de a nadir otros nuevos. Como alimentaci on utilizaba un pack de bater as de 7.2Vdc y 3700mAh, que le proporcionaban una autonom a aproximada de 3 horas de funcionamiento continuo. En cuanto a la arquitectura, el robot X80 contaba con un DSP para realizar el procesado interno de los sensores y las funciones de bajo nivel. Las funciones complejas y de m as alto nivel se realizaban o-board, en el ordenador al cual estuviera conectado el robot. El software de desarrollo inclu a herramientas para desarrollar 19

20

CAP ITULO 3. ANALISIS

Figura 3.1: Robot X80 Dr.Robot Inc. Fuente: Dr Robot Inc: www.drrobot.com nuevos programas y en general dotar al robot del comportamiento deseado. La c amara CMOS pose a su propia tarjeta controladora, para realizar las funciones de captura y tratamiento de imagen b asicas para poder enviar al PC destino los datos adecuados. A ra z de la realizaci on del proyecto nal de carrera de Dise no e implementaci on de una plataforma para dom otica y seguridad basada en un robot asistente [30], se a nadi o al robot una placa controladora que permit a a nadir hasta 10 sensores digitales conectados por bus I2C y 6 sensores anal ogicos m as que se conectaban a 6 ADC (ver gura 3.2). A esta controladora se conectaron tres sensores de luminosidad y un sensor de temperatura. Adem as, se dot o al robot de 10 parachoques de goma para protegerlo de los posibles golpes en su exploraci on del entorno. Tambi en se trabaj o sobre el modelo de comportamiento del robot, convirti endolo en un agente inteligente. En su momento, se opt o por un comportamiento deliberativo basado en un modelo BDI. Este comportamiento permit a al robot desplazarse de forma aut onoma por el entorno, siempre y cuando estuviera disponible su conexi on Wi-Fi con la que se comunicaba con el exterior. En este proyecto nal de carrera se tom o como punto de partida el robot X80 con las mejoras implementadas.

3.1.2.

Limitaciones y ventajas de la plataforma

Al trabajar sobre la plataforma anterior, surgieron toda una serie de inconvenientes, limitaciones y l neas de mejora futuras que fueron las que dieron lugar, en gran parte, a la realizaci on de este proyecto. A continuaci on, se listan las m as importantes: Limitaciones debidas a un sistema propietario: el gran inconveniente del robot

3.1. LA PLATAFORMA DE TRABAJO

21

Figura 3.2: Esquema de conexi on y funcionamiento de la placa controladora de expansi on de sensores Fuente: [30] X80 consist a en que todos sus componentes ten an licencias propietarias. Muchos de los sensores eran propietarios de Dr. Robot Inc., y por tanto s olo tratables mediante las funciones de bajo nivel dadas por Dr. Robot. Incluso la c amara CMOS, muy buena para el sistema por sus propiedades f sicas, tra a consigo una peque na placa controladora (que acondicionaba las se nales de entrada/salida de la c amara) cuyo esquem atico y modelo de funcionamiento tampoco eran accesibles. Esto implicaba que para conseguir hacer funcionar la c amara CMOS, deber a dise narse de cero una placa acondicionadora que copiase en la medida posible la funcionalidad del sistema de Dr. Robot; o bien aplicar ingenier a inversa hasta averiguar cu al era el funcionamiento de esa controladora. Del mismo modo no era posible acceder en ninguna medida al software o hardware a bajo nivel, dado que tambi en el c odigo de la plataforma software de control era propietario. La u nica manera de programar el robot era desde la plataforma de trabajo que ofrec a Dr. Robot (exclusivamente para sistemas operativos Windows y mediante el uso de Active X), utilizando las funciones dadas, siempre desde alto nivel, sin poder descender a un nivel hardware m as bajo. Antig uedad de los componentes: el robot X80 ven a dotado con un m odulo Wi-Fi 802.11b con una velocidad de 11Mbps. Actualmente todos los m odulos Wi-Fi tienen una velocidad de 54Mbps y utilizan el est andar 802.11g, siendo el 802.11b todav a soportado pero s olo utilizado por temas de compatibilidad con los dispositivos m as viejos. Adem as, el m odulo Wi-Fi tambi en era un m odulo no est andar, propietario de Dr. Robot. El modelo de comportamiento: el modelo de comportamiento elegido para la

22

CAP ITULO 3. ANALISIS implementaci on del robot X80, fue un modelo BDI. Este modelo, tal y como se ha visto anteriormente, presenta dicultades cuando el robot debe moverse en un entorno susceptible a un gran n umero de cambios, teniendo que reaccionar ante ellos. Esto supon a un problema en el caso de la inclusi on del robot en el ambiente inteligente, dado que este deber a no s olo ser plenamente capaz de detectar los cambios del entorno, sino de variar todos sus patrones en funci on de ellos. La utilizaci on de creencias predenidas en el modelo de comportamiento, supone trabas en este aspecto y complica el modelo.

Por el otro lado, el robot X80 presentaba toda una serie de ventajas que facilitar an la labor de este Proyecto Final de Carrera y que lo convert an en un buen punto de partida: La estructura f sica del robot: tal y como anunciaba Dr. Robot con respecto a este modelo, el robot X80 posee una estructura robusta que no le impide moverse de forma r apida. La estructura hace sencilla y eciente tanto la colocaci on de sensores como de las placas de acondicionamiento necesarias para el robot. Partir de una estructura f sica ya denitiva, facilita enormemente la labor de este PFC, dado que permite olvidarse del dise no mec anico del robot. Los componentes b asicos: motores, servos, bater as y c amara CMOS. Los motores de las ruedas del robot original eran los adecuados como para conseguir un movimiento r apido y eciente, copiando el sistema de alimentaci on original. Esto ahorra un estudio sobre cu ales son los motores adecuados para el robot. Los servomotores de la c amara eran funcionales, est andares y estaban completamente adaptados a la estructura del robot, permitiendo su utilizaci on de forma r apida. El hecho de que el robot original tuviera dos packs de bater as solucionaba el problema de la alimentaci on. La c amara CMOS de 8 bits que incorporaba el robot original ten a una resoluci on de 352x288 p xeles (CIF), lo que equivale a 0.1Megap xeles. Pese a ser una c amara en color, no ten a posibilidad de zoom, hecho que diculta el reconocimiento de personas y objetos. Sin embargo, dado que se trata de un robot m ovil, capaz de aproximarse a su objetivo antes de enfocarlo, la c amara por su estructura f sica (tama no e integraci on en el sistema) y sus propiedades era adecuada para el robot. Su u nica gran limitaci on, como se ha mencionado anteriormente, es el problema de ingenier a inversa que supon a la utilizaci on de su tarjeta controladora correspondiente. La red de sensores: el robot X80 original pose a una muy buena red de sensores, basada en encoders, piroel ectricos, detectores de proximidad infrarrojos y de ultrasonidos. Si bien su n umero era algo reducido en algunos casos y el rmware de los piroel ectricos y detectores de ultrasonidos era propietario y no pod a adaptarse a otros sistemas; s supon a una muy buena orientaci on y punto de partida. Con las mejoras aplicadas al robot original se ampli o el tipo de sensores, a nadi endole sensores de luminosidad y temperatura y creando, pues, una red bastante completa.

 3.2. COMPONENTES DEL ROBOT MOVIL

23

3.2.

Componentes del robot m ovil

Para realizar el an alisis exhaustivo de los componentes del robot m ovil, los dividiremos en dos categor as: aquellos componentes relacionados con el sensado del entorno y la interacci on con el mismo; y los componentes asociados a la inteligencia y modelado del comportamiento del robot.

3.2.1.

Sensado e interacci on con el entorno

La red de sensores Tal y como hemos visto anteriormente, la estrategia m as com un para el sensado del ambiente es la de crear una red con el mayor n umero posible de sensores. El robot X80 utilizaba un buen n umero de sensores, si bien no estaban situados de forma sim etrica, tal y como puede verse en la gura 3.3 dando mayor importancia al sensado en la parte delantera del robot. A priori parec a necesario aumentar el n umero de sensores con el n de dar simetr a a la red. Adem as, los sensores propietarios de Dr. Robot, dado que estaban preparados para utilizarse s olo con el software de la empresa, no incluyen informaci on detallada sobre su funcionamiento. En el apartado de dise no veremos con detalle las decisiones tomadas con respecto al n umero, tipo y disposici on de los sensores en el robot.

Figura 3.3: Sensores originales del robot X80 Fuente: [19] A continuaci on listamos las caracter sticas b asicas de los sensores de los que dispon a el robot mejorado, viendo sus ventajas e inconvenientes. Nos centraremos exclusivamente en aquellos sensores necesarios para el comportamiento del robot y

24 su interacci on directa con el entorno.

CAP ITULO 3. ANALISIS

Como vemos, la mayor a de sensores ten an una alimentaci on de 5Vcc, en vez de los 3.3Vcc que vienen siendo habituales en sistemas m as nuevos. El alcance de los sensores de ultrasonidos parec a, a priori, algo corto, y el datasheet de los sensores piroel ectricos no explicaba las condiciones de funcionamiento ni detallaba cu al era el resultado obtenido a la salida. Debemos recordar que adem as de estos sensores, el robot mejorado estaba dotado de: Sensores de temperatura: basados en el chip LM92 Semiconductors, ofrec a a salida una se nal digital de 13 bits. de National

Sensores de luminosidad: basado en chip TSL2561 de TAOS, que tambi en ofrec a una salida digital y se comunicaba por I2C.

Estrategias de sensado Adem as del n umero y tipo de sensores, otro punto importante es la estrategia de sensado y la comunicaci on con los sensores. Para ello puede optarse por dos soluciones diferentes: comunicar los sensores con el robot por medio de los GPIOs de que dispusiera la placa base del robot, o bien por medio de entradas con ADC en el caso de sensores que ofrezcan una salida anal ogica. Esta soluci on presenta como ventaja la capacidad de poder tomar muestras de los sensores en cualquier momento; pero tiene como inconveniente un gasto excesivo de puertos de entrada/salida, adem as de la necesidad de disponer de entradas anal ogicas que realicen una conversi on interna a digital, o bien fabricar un conversor. comunicar los sensores con el robot por medio de un bus serie, ya sea SPI o I2C. Esto exige que la placa de inteligencia del robot disponga de esa interfaz, o que deba ser implementada. Tiene como ventaja que se minimiza el n umero de GPIOs, pero presenta el inconveniente de que, al ser un bus serie, existe un tiempo m nimo para la encuesta de los sensores de la red. Si el n umero de sensores es muy elevado, esto puede implicar un retardo considerable. En concreto, suponiendo una red de unos 30 sensores (el robot original dispon a de 14, la mitad de los cuales eran de salida anal ogica), ser an necesarios 30 GPIOs si quisi eramos realizar una comunicaci on directa (algunos de los cuales deber an ser entradas anal ogicas). La mayor a de las placas vienen con un m aximo de 32 GPIOs, incluyendo las entradas o salidas anal ogicas, hecho que nos limitar a el tama no m aximo de la red. Si adem as se quisiera gestionar la c amara o los motores paso a paso mediante pines de entrada salida, la red de sensores deber a reducirse todav a m as. Para esta misma red de 30 sensores, ser an necesarios 5 pines de E/S que permitir an decodicar hasta 32 sensores de un bus SPI, y no habr a gasto de GPIOs en el caso de utilizar una placa con bus I2C integrado. Sin embargo, el

 3.2. COMPONENTES DEL ROBOT MOVIL

25

Sensores Ultrasonidos Alimentaci on: 5Vcc - Salida Digital - Rango 4cm a 340cm Funcionamiento: se pone a la entrada un pulso de enable y se recibe el eco de se nal Propietario Dr. Robot

Sensores Piroel ectricos Alimentaci on: 5Vcc - Salida Anal ogica Funcionamiento: Un canal de salida se naliza la presencia de personas y el otro el movimiento Propietario Dr. Robot

Sensores Infrarrojos Alimentaci on: 5Vcc - Salida Anal ogica - Rango de 12 a 80cm de alcance Funcionamiento: Se obtiene un valor a la salida proporcional (no lineal) a la proximidad de los objetos Modelo SHARP, informaci on de funcionamiento disponible. No necesitan acondicionamiento.

Quadrature Encoders Alimentaci on: 5Vcc - Salida de 2 canales digitales Funcionamiento: En funci on de la velocidad de las ruedas, las se nales de salida presentan una frecuencia u otra. En funci on de la direcci on del movimiento, una se nal se adelanta respecto a la otra Modelo E4-300 US Digital: informaci on de funcionamiento disponible. Precisan etapa de acondicionamiento.

Cuadro 3.1: Caracter sticas de los sensores del robot X80 original y mejorado

26

CAP ITULO 3. ANALISIS

tiempo total de sensado de un u nico bus I2C con 30 sensores podr a llegar a ser de 1 200ms . En el caso del robot X80, este comunicaba todos sus sensores a trav es de GPIOs. Esto limitaba el n umero de sensores que se pod an a nadir al robot. En las mejoras realizadas posteriormente se a nad a una placa controladora que a nad a un bus I2C y conversores anal ogico-digitales, con el n de poder aumentar todav a m as el n umero de sensores a conectar al robot. Se adoptaba, pues, una soluci on h brida de las dos anteriores, ante la imposibilidad de mantener la soluci on original. Interacci on con el entorno Tal y como se ha comentado anteriormente, para su interacci on con el entorno, el robot X80 dispon a de dos motores de 12Vcc capaces de mover las dos ruedas motrices y conseguir el desplazamiento del robot por el entorno. Tambi en, y pese a que este aspecto no se cubrir a en esta primera parte del PFC, posee una c amara controlada mediante dos servomotores que deber an permitirle, en un futuro, tomar im agenes del entorno cuando lo crea necesario o bien le sea ordenado por el ambiente inteligente. La interacci on con el entorno inteligente, tal y como se ha comentado, se llevar a a cabo mediante WiFi, de forma que el robot pueda comunicar su estado y recibir ordenes del ambiente.

3.2.2.

Inteligencia del robot

Debido a que todas las placas controladoras del robot eran propietarias de Doctor Robot Inc. era necesario cambiar todo el hardware que supondr a la parte de la inteligencia del robot, redise nando el sistema desde cero. Para ello se realiz o un an alisis de las posibles placas a utilizar, en funci on de los requisitos que esta deb a cumplir, y se seleccion o el modelo que mejor encajaba. Como requisito indispensable, y tambi en en la l nea de trabajo de lo que se lleva haciendo en el Laboratorio de Sistemas Integrados, la idea era trabajar con un dispositivo embedded, a poder ser un SoM capaz de soportar un Linux o un ucLinux. Adem as, la placa elegida deber a cumplir con las siguientes especicaciones de dise no: Disponer de un n umero m nimo de GPIOs para su interacci on con los motores, la c amara y algunos de los sensores. En caso de que el n umero de GPIOs no fuera muy elevado (menor de 16) disponer, por lo menos, de algunas entradas ADC.
C alculo realizado aproximadamente y en el peor caso, utilizando la m nima frecuencia de trabajo del bus I2C, que seg un el est andar es de 40KHz. Se ha tenido en cuenta que los sensores, en general, utilizar an tramas formadas por 1 byte de direcci on, 1 byte de comando y 2 bytes de informaci on, y que algunos sensores necesitan un tiempo de c alculo entre que reciben el comando y responden con el dato
1

 3.2. COMPONENTES DEL ROBOT MOVIL

27

Disponer de alg un tipo de bus serie, ya fuera SPI o I2C, para comunicar la placa con los sensores Contar con un m nimo de soporte para poder instalar un m odulo WiFi o, como m nimo, que esto fuera posible. No tener un consumo excesivamente elevado, ya que todo el sistema deber a funcionar con las dos bater as (de 7.2Vcc) del robot original. El SoM deber a disponer de procesador y memoria sucientes como para soportar las funciones de integraci on en el entorno inteligente. Esto es, la placa deber a ser capaz de realizar el procesado del entorno que se llevar a a cabo en la segunda parte de este Proyecto Final de Carrera (o parte del mismo), que incluye la localizaci on del robot y el mapeado del entorno. El SoM deber a disponer de procesador y memoria sucientes para realizar el tratamiento de imagen necesario (o parte del mismo) necesario para el reconocimiento de los usuarios del entorno inteligente. Dadas las especicaciones anteriores, una de las placas del mercado que mejor encajaba con ella era el modelo M-501 de Artila Electronics (ver gura 3.4)

Figura 3.4: Artila M-501 SoM Fuente: [6] Esta placa presentaba las siguientes caracter sticas que la convert an en una muy buena elecci on para la realizaci on de este proyecto: La M-501 es un SoM basado en ARM9 (procesador AT91RM9200) 200MIPS@180MHz, con MMU, 64MB SDRAM y 16MB NOR de memoria Flash. Dado que pose a una MMU era capaz, ya no de soportar un ucLinux, sino un kernel de Linux. Soporte para kernels de Linux 2.6.x; un kernel 2.6.14 ven a preinstalado en el SoM. 32 GPIOs, compatibles con el est andar CMOS/3.3V

28

CAP ITULO 3. ANALISIS Puerto SPI e I2C, adem as de 4 puertos UART a 921.6Kbps y un puerto Ethernet. El puerto I2C ven a con un driver nativo y permit a el uso del protocolo smbus desde espacio de usuario. Dos puertos USB 2.0, con driver nativo para adaptadores WiFi con chip Ralink (802.11b/g)

La placa requer a una alimentaci on de 3.3Vcc y disipaba una potencia m axima de 2.5W a pleno rendimiento. Adem as, su peque no tama no de 8cmx5cm y su buena relaci on calidad/precio, la hac an ideal para el sistema a implementar. Para su aprendizaje y uso Artila ofrec a, adem as de la placa M-501, un Starter Kit (g. 3.5), es decir, una placa de desarrollo, que inclu a: Circuitos de alimentaci on, consistentes en un regulador de 5V y otro de 3.3V para la alimentaci on de la placa Diversos puertos para la conexi on con el SoM: puerto Ethernet, 4 puertos RS232, 2 puertos USB, 1 socket SD, 2 expansores de GPIOs, puerto JTAG para debug y expansor del puerto SPI. Artila facilitaba adem as informaci on sobre el toolchain adecuado para el desarrollo de aplicaciones para el SoM, as como el c odigo fuente del kernel instalado y sus actualizaciones, drivers y conguraciones.

Figura 3.5: Artila M-501 Starter Kit Fuente: [6] Este SoM cumpl a con los requisitos b asicos especicados anteriormente. Pese a no tener ninguna entrada de ADC, lo que obligar a a acondicionar todos los sensores

 CON EL AMBIENTE INTELIGENTE 3.3. COMUNICACION

29

anal ogicos para convertir su salida bien a digital o a bus I2C, esta falta se supl a con el gran n umero de GPIOs disponibles. Adem as, la documentaci on de la placa, muy buena a nivel hardware (Artila publica los esquem aticos del Starter Kit en su web), si bien algo escasa en cuanto al software, facilitar a el dise no de algunas de las partes del robot, ofreciendo un buen punto de partida. Otras placas del mercado en el mismo rango de precios, como la TS-7400 (basada en el procesador Cirrus EP9302 ARM9) ofrec a caracter sticas semejantes, si bien no llevaba drivers nativos para I2C ni para una conexi on WiFi a trav es de USB. Adem as, carec a de MMU, y por tanto imped a trabajar con un kernel Linux. La placa SOM-A2709 con procesador Marvell XScale PXA270, es otro ejemplo, si bien esta placa no estaba preparada siquiera para un ucLinux, sino que funcionaba con Windows CE 5.0. La placa M-501 de Artila se perlaba, por tanto, como la mejor elecci on.

3.3.

Comunicaci on con el ambiente inteligente

A tenor del an alisis anterior del hardware para la inteligencia del sistema, el modelo m as sencillo de comunicaci on con el ambiente inteligente, se perlaba como un m odulo WiFi conectado por USB. Para ello s olo ser a necesario (tomando como elecci on el SoM M-501) una WiFi USB con un chip Ralink, para asegurarnos la compatibilidad con los drivers nativos. La WiFi deber a permitir la comunicaci on ambiente-robot, haciendo del robot un sensor m as que vendr a a a nadir informaci on al entorno. S olo que el robot ser a un sensor especial, en cuanto a que dispone de la autonom a suciente como para desplazarse por el ambiente antes incluso de que este lo requiera. El sistema deber a estar dise nado de tal forma que, en caso de que el ambiente no env e informaci on al robot, este sepa reaccionar de forma completamente aut onoma, tomando decisiones seg un su propio criterio. El ambiente, cuando sea posible o as se desee, se podr a comunicar con el robot, modicando las ordenes que debe llevar a cabo o reorient andole en el entorno. La forma m as simple para realizar este dise no parece el de poner en comunicaci on un s olo ordenador (servidor/AmiServer) con el robot (cliente/AmiBot), de forma que se comuniquen entre ellos en una conexi on uno a uno. Cuando cualquier usuario del ambiente inteligente desee interaccionar con el robot, o cuando el propio ambiente le env e una orden, lo har a a trav es del servidor (ver gura 3.6). De esta forma, todas las ordenes estar an centralizadas en el servidor, que decidir a, en funci on de unos criterios pre-establecidos, cu ales son las que deben enviarse al robot. De esta forma aumentamos la autonom a del robot, facilitamos el dise no de la red y nuestro robot nunca podr a verse sometido a ordenes que presenten un conicto entre ellas.

30

CAP ITULO 3. ANALISIS

Figura 3.6: Comunicaci on del robot con el ambiente inteligente Fuente propia

3.4.

Requisitos del sistema

En esta primera parte del PFC el sistema no llegar a a implementar el reconocimiento de usuarios ni la localizaci on en el entorno inteligente. Se empezar a por dotar al robot de una autonom a simple, mediante la uni on de agentes sencillos que le den, tal y como dec a Brooks, una inteligencia semejante a la de un insecto. As , nos centraremos u nicamente en su capacidad para moverse de forma aut onoma y m nimamente inteligente por su entorno, siguiendo diversos comportamientos predenidos. La comunicaci on con el entorno deber a ser sucientemente efectiva como para poder variar estos comportamientos. El sistema deber a cumplir una serie de requisitos, que dividiremos en los requisitos asociados al robot y los requisitos asociados al ambiente inteligente.

3.4.1.

Requisitos asociados al robot

Autonom a del robot: minimizando la utilizaci on de recursos del sistema y sin requerir acciones externas, el robot deber a ser capaz de guiarse de forma aut onoma por el entorno. Deber a reaccionar adecuadamente tanto a los objetos como a las personas, siendo capaz de distinguir entre ellos. Ser a especialmente importante la sensibilidad del robot respecto a cambios en el entorno. Sensado exhaustivo del entorno: el comportamiento del robot requerir a un sensado sucientemente exhaustivo del entorno, con redundancia en las medidas, tanto para esta primera parte, en la que el robot s olo deber a reaccionar a estas mediciones, como para la segunda parte de este proyecto, en la que adem as ser a necesario construir un mapa a partir de ellas.

3.4. REQUISITOS DEL SISTEMA

31

Ser a necesario construir una red sucientemente amplia de sensores, tanto en n umero como en tipo; sim etrica en la medida de lo posible, y que permita obtener un modelo real del entorno del robot. Las soluciones de dise no a implementar deber an ser, en la medida de lo posible, sencillas, a n de tener un sistema sucientemente ligero como para poder implementar la localizaci on y mapeado de la segunda parte con menos problemas. Del mismo modo, en la elecci on de sensores y su acondicionamiento, deber a tenerse en cuenta el precio del sistema, sin menoscabo en la calidad del resultado nal. Dado que una de las grandes limitaciones de funcionamiento del robot original era el hecho de ser en s mismo un sistema propietario, el nuevo sistema deber a dise narse, en la medida de lo posible, mediante herramientas de software libre.

3.4.2.

Requisitos asociados al ambiente inteligente

Los requisitos b asicos de la integraci on del robot en el ambiente ser an los de por s necesarios en un ambiente inteligente. El sistema no deber a ser intrusivo. Dotar de inteligencia al ambiente no debe suponer una carga adicional a los usuarios, sino todo lo contrario. La existencia del robot en ning un momento deber a perturbar a los usuarios sino, en cualquier caso, facilitarles algunas tareas. El hecho de que el robot forme parte del ambiente inteligente deber a colaborar en su enriquecimiento. El robot, en su funci on de sensor m ovil, aportar a informaci on adicional al entorno, cuando este se la solicite. El robot tambi en podr a pedir informaci on al entorno, si bien debe ser capaz de tomar decisiones en caso de que este no responda.

32

CAP ITULO 3. ANALISIS

Cap tulo 4 Dise no

El presente cap tulo est a dedicado al dise no del sistema completo, tanto del robot AmiBot (Ambient Intelligence Robot) como de su comunicaci on con el ambiente inteligente a trav es del servidor AmiServer. En primer lugar realizaremos una denici on y toma de decisiones con respecto al hardware y al software del sistema. As , se elegir an los elementos que formar an la red de sensores y la placa de procesamiento, se decidir a y dise nar a el modelo de comportamiento, as como el sistema de comunicaci on con el ambiente. Esto nos permitir a realizar el dise no detallado de la arquitectura del sistema, tanto a nivel hardware como software y, por u ltimo, realizar un dise no que, en la siguiente fase, ser a implementado de forma real.

4.1.
4.1.1.

Denici on de Hardware y Software

Elecci on de la red de sensores

La elecci on de la red de sensores supone uno de los puntos clave para el dise no de AmiBot, dado que los aciertos en esta decisi on facilitar an en gran medida el resto de partes del proyecto, mientras que los errores supondr an problemas en un futuro. Un buen dise no de la red de sensores nos permitir a un sensado exhaustivo y correcto del entorno. La utilizaci on de sensores incorrectos, mal distribuidos o mal acondicionados, implicar an un mayor n umero de puntos oscuros en el conocimiento del mundo que rodear a al robot. Hay que tener en cuenta que el robot original empezaba a contar con problemas por falta de GPIOs para todos los sensores, por lo que se dise n o una placa adicional para el control del resto de sensores. Dado que en nuestro caso el sistema se dise naba de cero, y se quer a ampliar la red de sensores, para no caer en errores anteriores se decidi o comunicar todos los sensores por I2C. Esta decisi on de dise no tendr a sus implicaciones tanto en la elecci on de los sensores como en la arquitectura, tal y como veremos m as adelante. 33

34

CAP ITULO 4. DISENO

Con el n de crear una red de sensado completa, se opt o por realizar las siguientes actuaciones con respecto al robot original y el mejorado: Mantener todos los tipos de sensores utilizados anteriormente, dando especial importancia a aquellos m as relevantes para la detecci on de obst aculos y elementos del terreno. Aumento del n umero de sensores del robot, creando una red en la que los sensores estuvieran dispuestos de la forma m as sim etrica posible. Se decidieron a nadir otro tipo de sensores no presentes en el robot original ni en el mejorado, como son: detectores de choques, detectores de desniveles elevados (inclin ometros), br ujula, detectores de n de terreno (para la detecci on de escaleras u otros desniveles que AmiBot no es capaz de salvar), sensores de corriente en motores y sensores de nivel de bater as. Cambio de los sensores propietarios por otros sensores comerciales o bien de dise no propio. Se decidi o mantener los sensores de proximidad infrarrojos, aumentando su n umero, dado que eran comerciales, f aciles de acondicionar y daban buenos resultados. Los sensores de ultrasonidos, sin embargo, por ser propietarios y no tener tan buenas propiedades, se desecharon y se adquiri o otro modelo comercial, comunicados por bus I2C, aumentando su n umero. Los sensores piroel ectricos, tambi en propietarios de Dr. Robot, fueron sustituidos por unos nuevos, con un sistema de acondicionamiento propio. En la tabla 4.1 podemos ver c omo queda la composici on de la red de sensores. El tipo de sensor, el modelo utilizado si es un sensor comercial, sus caracter sticas b asicas, y el n umero de sensores de ese tipo incluidos en la red de sensores. La distribuci on de los sensores m as importantes de dicha red puede verse en la gura 4.1 La red quedaba as constituida por un total de unos 37 sensores.

4.1.2.

Elecci on de la placa de procesado

Tal y como se ha visto en el cap tulo anterior, la opci on que parec a m as viable como plataforma para el desarrollo del robot, era el SoM M-501 de Artila. As , se opt o por escoger esta placa, adquiriendo tambi en el kit de desarrollo, lo que nos permitir a una r apida familiarizaci on con la plataforma de trabajo. En primera instancia, la conexi on con la placa se realiz o por Ethernet mediante el cliente SSH preinstalado en el kernel. La transferencia de archivos se pod a realizar de forma f acil mediante FTP. El toolkit proporcionado por Artila permiti o realizar unas primeras pruebas de compilaci on cruzada y prueba de programas en la placa, que funcionaron de la forma esperada. Posteriormente, para la comunicaci on con la placa mediante WiFi, se busc o un dispositivo WiFi por USB con un chip Ralink (para utilizar el driver nativo del SoM). Por su probada compatibilidad con los kernel Linux en general y con el driver utilizado por la M-501 (Ralink rt73) en concreto, se opt o por

 DE HARDWARE Y SOFTWARE 4.1. DEFINICION

35

Tipo Sensores choque

Modelo Modelo propio

Proximidad infrarrojo Proximidad ultrasonidos

SHARP GP2Y0A2

Devantech SRF10

Piroel ectricos

muRata IRA-E700 (dual)

Quadrature encoders Nivel bater as Corriente motores de en

E4-300 US Digital

Caracter sticas Alimentaci on: 3.3Vcc Salida digital Realizados mediante pulsadores Alimentaci on: 5Vcc Salida anal ogica Rango de 10 a 80cm. Alimentaci on: 5Vcc Salida digital I2C (16bits) Rango: hasta 11 metros con ganancia m axima. Alimentaci on: 3.3Vcc Salida digital(2bits) Acondicionamiento propio Gran rango de sensado Alimentaci on: 5Vcc Salida digital(2bits) Acondicionamiento propio y conversi on ADC Alimentaci on: 3.3Vcc Conversor I-V propio Se obtienen medidas de corriente relativas Alimentaci on: 3.3Vcc Salida digital I2C (16bit) Precisi on d ecimas de grado Requiere calibraci on Alimentaci on: 3.3Vcc Salida digital I2C Aceler ometro de 3 ejes Alimentaci on: 5Vcc Salida anal ogica Rango de 4 a 30cm Alimentaci on: 3.3Vcc Salida digital I2C Sensor PFC Luis Moreno Alimentaci on: 3.3Vcc Salida digital I2C Sensor PFC Luis Moreno

N umero 10

10

Sensor propio Sensor propio

1 1

Br ujula

HMC-6352

Inclin ometro (tilt sensor) Detecci on desnivel Luminosidad

LIS-302DL

SHARP GP2D120

LM92 National

Temperatura

TSL2561 TAOS

Cuadro 4.1: Dise no de la red de sensores de AmiBot

36

CAP ITULO 4. DISENO

Figura 4.1: Distribuci on de los sensores de AmiBot Fuente propia el dispositivo C54RU de Conceptronic. Esta WiFi USB trabajaba seg un el est andar 802.11g con un velocidad de 54Mbps y ten a un alcance m aximo de 120m seg un especicaciones, con un consumo menor que otras marcas (330mA en transmisi on continua). El driver de I2C nativo tambi en era funcional y permit a la comunicaci on sencilla desde espacio de usuario con dispositivos que cumplieran la especicaci on SMBUS [15]. Esta especicaci on est a derivada del est andar I2C y sirve para comunicar una gran parte de los dispositivos I2C del mercado de forma ecaz y sencilla. El inconveniente principal consist a en que, debido a las limitaciones del driver I2C de m as bajo nivel de la placa M-501, la comunicaci on con dispositivos I2C que no cumplieran el est andar SMBUS o bien que utilizaran un protocolo no contemplado por el driver o no est andar, requerir an para su utilizaci on, variar toda la estructura de la pila de drivers I2C y, por tanto, no se considera viable. En cualquier caso, el hecho de que la placa tambi en pudiera comunicarse mediante SPI proporcionaba una soluci on en el caso de que existieran dispositivos que, nalmente, no funcionaran de forma adecuada mediante I2C. El kernel 2.6.14 tambi en ten a soporte nativo para la comunicaci on con los GPIOs de forma intuitiva.

4.1.3.

Decisiones Software

La decisi on fundamental a tomar en cuanto al software del sistema, consist a en la elecci on del modelo de comportamiento del robot. Tal y como se vio en el apartado dedicado a estado del arte, es necesario decidir entre el dise no de un agente reactivo o un agente deliberativo. El robot mejorado realizado por Luis

 DE HARDWARE Y SOFTWARE 4.1. DEFINICION

37

Moreno en su PFC [30] ten a un comportamiento deliberativo, con todas las ventajas e inconvenientes que ello aporta. En este caso, se decidi o dotar al robot de un comportamiento reactivo con una arquitectura de subsunci on. En un robot que ha de ser integrado en un ambiente inteligente, y del que valoraremos por encima de todo su autonom a y no intrusi on, se hace especialmente necesaria la capacidad de AmiBot para moverse por el mundo de la forma m as reactiva posible, siendo su comportamiento robusto frente a los cambios. Adem as, la simplicidad computacional que aporta un comportamiento reactivo de subsunci on cumpl a con la premisa tambi en indispensable de tener un sistema ligero, que pueda m as adelante soportar las necesidades computacionales del mapeado del entorno, sin detrimento del comportamiento reactivo del robot. De este modo dise naremos una estructura jerarquizada de comportamientos, gobernados por un proceso arbitro que se encargar a de inhibir unos comportamientos u otros, en funci on del modo de funcionamiento del robot. Esta estructura no es en realidad una estructura reactiva de subsunci on pura dado que el arbitro es capaz de realizar transformaciones sobre la jerarqu a en funci on de su modo de trabajo. Esto nos permitir a, una vez implementada la parte de localizaci on y mapeado, generar una capa de m as alto nivel por encima de la capa de reacci on pura, aunando las ventajas de los agentes reactivos y deliberativos. Por coherencia con el modelo reactivo y el objetivo de consumir un m nimo de recursos, se opt o por programar todo el sistema en C, utilizando el compilador cruzado recomendado por Artila Electronics, y que era arm-linux-gcc-3.3.2.

4.1.4.

Denici on de la comunicaci on con el ambiente inteligente

A efectos de programaci on, conguraci on y pruebas de la placa, se opt o por utilizar la conexi on por SSH del SoM, y transmitir los archivos necesarios por FTP. De cara a la comunicaci on nal, bien con el entorno inteligente o bien con un usuario, se opt o por una conexi on WiFi implementada mediante sockets TCP entre la aplicaci on del robot (cliente AmiServer) y el servidor AmiServer. Es el servidor quien, a partir de los datos recibidos del entorno inteligente o de las peticiones de los usuarios, cambia el modo de funcionamiento de AmiBot. Se denieron una serie de modos de funcionamiento para AmiBot, de los cuales s olo algunos de ellos ser an plenamente funcionales en la nalizaci on de la primera parte de este PFC. Adem as, se contar a con una serie de estados predenidos de AmiBot, de los que el robot informar a al ambiente cuando fuera necesario. El arbitro de procesos del comportamiento reactivo, tal y como se ha comentado m as arriba, ser a el que dispone de la informaci on actualizada del modo de funcionamiento del robot y quien, adem as, controlar a la variable del estado actual del robot. Los modos de funcionamiento del robot ser an los siguientes: Random - aleatorio (funcional) : el robot siempre sigue un comportamiento de seguimiento de paredes (movi endose de frente y a la derecha), buscando siempre las paredes m as cercanas y esquivando los objetos que encuentre por el camino.

38

CAP ITULO 4. DISENO Follow human - seguir personas (semi-funcional) : el robot es capaz de seguir a las personas de su entorno, gracias a la informaci on de sus sensores piroel ectricos. En esta primera parte, si el robot no detecta nada a trav es de sus sensores, lo comunica al ambiente y permanece quieto. En la segunda parte de este PFC se dise nar an mejoras con respecto a este modo de funcionamiento. Go To - ir hacia (no funcional) : este comportamiento permite al robot dirigirse a un punto del mapa. No podr a ser funcional hasta la segunda parte de este proyecto. Do Nothing - no hacer nada (funcional) : el robot se detiene, a la espera de un cambio en su modo de funcionamiento. Explore - exploraci on del terreno (no funcional) : este modo es semejante al modo Random, con la diferencia de que, conforme vaya explorando el terreno el robot se ir a guardando un mapa detallado del entorno. Una vez recorrido su entorno cercano, decidir a qu e areas deben ser exploradas m as a fondo y se dirigir a a ellas. Este modo de funcionamiento ser a funcional en la segunda parte del proyecto. Exit - salida (funcional) : el robot se detiene y el programa de AmiBot termina.

Para comprobar el correcto funcionamiento de esta comunicaci on robotservidor, y a falta de un banco de pruebas real y una estructura completa de los nodos del ambiente inteligente que aportaran informaci on al robot, se opt o por crear una aplicaci on en Java a modo de demostrador en el ordenador servidor AmiServer mediante una GUI. De esta forma se podr a ver de forma gr aca el estado del robot en todo momento, as como enviarle ordenes con respecto a su comportamiento. Debe tenerse presente en todo momento que la recepci on de ordenes por parte de AmiBot no debe interferir en ning un momento con su autonom a o su comportamiento reactivo. AmiBot siempre sigue un comportamiento por defecto, aunque este sea tan simple como el seguimiento de paredes. Lo sigue de forma aut onoma, esquivando objetos y personas de forma reactiva. El ambiente, en cualquier momento, podr a decidir que AmiBot debe dejar de seguir paredes y empezar a seguir personas. En ese caso el robot seguir a esquivando objetos de forma reactiva, pero el arbitro de comportamientos se encargar a de suprimir las acciones de esquivar personas, y pasar a seguirlas. La comunicaci on con el ambiente inteligente y las ordenes que este d e a AmiBot deben entenderse y dise narse como la capa superior de la estructura jerarquizada del robot, siempre controlada por el arbitro de procesos.

4.2.
4.2.1.

Arquitectura del Sistema

Arquitectura Hardware

La arquitectura hardware comprende el dise no de bloques del sistema, dividido en cuatro partes b asicas comunicadas entre ellas: red de sensores - bus I2C - placa

4.2. ARQUITECTURA DEL SISTEMA de inteligencia de AmiBot - actuadores (ver gura 4.2)

39

Figura 4.2: Arquitectura Hardware: diagrama de bloques Fuente propia

Red de sensores - bus I2C Cuando se trata de comunicar un gran n umero de sensores a una placa a trav es del bus I2C, surgen los problemas inherentes a un bus serie, el principal de los cuales consistir a en que debemos trabajar a una velocidad que sea adecuada para todos los sensores, sin que estos intereran entre ellos, y sin que el tiempo total de encuesta de todos los sensores del bus sea excesivo. Si bien el robot es un sistema que funciona a tiempo real, sus restricciones temporales no son limitantes en cuanto a tiempo de muestreo de los sensores. En realidad, la verdadera restricci on se encuentra en la sincronizaci on entre el arbitro, los comportamientos y el muestreo del bus, tal y como veremos m as adelante. Dada la velocidad del robot (a nivel efectivo bastante por debajo de su velocidad m axima de 1m/s) y su tama no (aproximadamente 50cm de lado), no nos ser a necesario tomar m as de 4 muestras por segundo de cada sensor (de hecho, podr amos quedarnos incluso con un par de muestras por segundo), con lo que el sistema funcionar a perfectamente mientras podamos realizar una encuesta completa al bus I2C en menos de 250ms. El dispositivo I2C maestro de la placa Artila M-501 por defecto se sincronizaba con el resto de dispositivos esclavos del bus con una velocidad de 40KHz. Dado que todos los sensores I2C del mercado han de ser capaces de funcionar a esta velocidad, esta soluci on ahorrar a problemas en cuanto a sincronismos. Teniendo en cuenta el peor caso de nuestro sistema, en que todas las tramas tuvieran 4bytes de datos, y tuvi eramos que encuestar 40 sensores, a un teniendo en cuenta los timeouts de los dispositivos, tardar amos menos de 250ms. Por tanto se decidi o mantener la velocidad del bus a su nivel m nimo, contando con la posibilidad de aumentarla si en alg un momento llegara a ser necesario. En cualquier caso, debe tenerse en cuenta que pese a que el n umero de sensores

40

CAP ITULO 4. DISENO

en el bus sea de 37, no se realizan 37 encuestas del bus a 37 direcciones de esclavo diferentes, sino muchas menos. La etapa de acondicionamiento de la red de sensores se dise n o de forma que aquellos sensores digitales que s olo ofrecieran un bit o dos a la salida (bumpers, encoders y sensores piroel ectricos) se multiplexaran en un s olo dispositivo I2C (expansor I2C de 8 bits) de forma que para encuestar 8 bumpers s olo fuera necesario comunicarse una vez con un dispositivo con una direcci on de esclavo asignada. Del mismo modo, y con el n de minimizar el n umero de direcciones de esclavo a utilizar, todos los sensores anal ogicos se acondicionaron de forma que ofrecieran una salida CMOS/3.3V, que era llevada a un ADC de 8bits con 8 canales multiplexados y comunicaci on I2C.

Figura 4.3: Agrupaci on de los sensores por direcci on I2C Fuente propia Agrupando los sensores del bus por tipos y utilizando los expansores I2C para los sensores digitales se podr an encuestar los 10 Bumpers, 2 encoders y 4 sensores piroel ectricos mediante s olo 3 tramas de comunicaci on I2C. Gracias a los ADC de 8 canales, el sistema completo se encuestar a con un total de 13 direcciones de esclavo diferentes: 3 expansores, 2 ADCs, 6 sensores de ultrasonidos, br ujula e inclin ometro (ver gura 4.3). Bus I2C - Placa M-501 - Actuadores Para poder instalar el SoM M-501 en AmiBot, era necesario dise nar una placa base para el sistema. Esta deber a incluir algunas de las partes de que constaba el Starter Kit, y algunas partes nuevas, tal y como veremos a continuaci on. El diagrama de bloques de la placa base es el que responde a la gura 4.4 La placa base de AmiBot, que albergar a el SoM M-501, estar a dividida en diversas zonas, compuestas por: Sistema de regulaci on propio: a partir de las dos bater as de 7.2Vcc y 3700mAh, se dise nar a un regulador conmutado capaz de dar dos tensiones, una de

4.2. ARQUITECTURA DEL SISTEMA

41

Figura 4.4: Diagrama de bloques de la placa de inteligencia de AmiBot Fuente propia 5Vcc para motores, WiFi USB y para algunos de los sensores utilizados (ultrasonidos, encoders e infrarrojos), y otra de 3.3Vcc para el SoM M-501 y el resto de sensores. Pese a que el sistema no deber a consumir m as de 1A en continua, el regulador se dise nar a de forma que pueda proporcionar una corriente de 3A, para ser robusto respecto a los picos de corriente que introducir an los motores y el sistema completo durante el arranque. Comunicaci on mediante la WiFi USB: Se acondicionaran las se nales USB provenientes del SoM y se llevar an a un socket USB, para su conexi on con el dispositivo WiFi C54RU de Conceptronic. Acondicionamiento del bus I2C: se realizar a una expansi on de puertos para el bus I2C. La placa contar a con 12 conexiones para bus I2C, expandidas desde el SoM, con el acondicionamiento necesario. La mitad de estas conexiones ser an para un bus I2C alimentado a 3.3Vcc. La otra mitad pasar an por un conversor bidireccional de I2C de 5 a 3.3Vcc, y permitir an conectar el resto de dispositivos a un bus I2C de 5Vcc. Este acondicionamiento incluye la inclusi on de las resistencias de pull-up necesarias para que, con todos los dispositivos necesarios conectados, el bus funcione correctamente. Expansi on de puertos de E/S: La placa permitir a la conexi on, de forma sencilla, de los 32 GPIOs, divididos en dos arrays de 16 pines para una mejor interconexi on de los elementos del sistema. Sensado del nivel de bater as: se incorporar a en la placa la circuiter a necesaria para poder realizar el sensado de las bater as y conocer el tiempo de vida

42

CAP ITULO 4. DISENO restante de AmiBot antes de verse obligado a ir a su puesto de recarga.

La comunicaci on de la placa base con los actuadores (que en esta primera parte ser an u nicamente los dos motores de las ruedas de AmiBot), se llevar a a cabo a trav es de 4 GPIOs. Estos terminales se llevar an a otro PCB tambi en de dise no propio que ser a el encargado de dar la corriente adecuada a los motores en funci on de la direcci on que deba llevar el robot.

4.2.2.

Arquitectura Software

La arquitectura software comprende todo el dise no de bloques del modelo de comportamiento reactivo del robot. La malla de reacci on (ver gura 4.5) del robot se estructura de forma jer arquica y se divide en toda una serie de comportamientos. Cada uno de los comportamientos del robot estudia la informaci on aportada por el grupo de sensores que le afectan. Con esta informaci on, cada comportamiento decide la siguiente acci on que deber a llevar a cabo el robot, dadas las condiciones. Las acciones, en el caso de nuestro sistema, se traducen a direcciones de movimiento del robot. Si un determinado comportamiento no tiene informaci on que aportar, puede responder con la acci on ANY (cualquiera), y si no sabe reaccionar adecuadamente por falta de datos o por incoherencia entre los mismos, puede responder con la acci on STOP(parada). De este modo, por ejemplo, el comportamiento Survive toma datos de los sensores de nivel de bater as y de corriente en motores. En caso de que se detecte que los niveles son bajos, el robot indica la direcci on que debe tomar el robot para dirigirse al puesto de recarga. Si no supiera cu al es esa direcci on, responder a con la acci on STOP. En caso de que el nivel de bater a fuera correcto, el comportamiento decidir a la acci on ANY. La malla de reacci on de AmiBot est a constituida por los siguientes comportamientos: Survive - sobrevivir: comportamiento encargado de la lectura de los niveles de bater a y de corriente en motores. En caso de que este comportamiento detectara que los niveles de corriente en motores (cuando estos funcionan) o de voltaje de salida de las bater as son demasiado bajos, indicar a la direcci on que debe seguir el robot hacia su puesto de recarga. Si se desconoce el puesto de recarga, el robot se detiene. Escape - huir: este comportamiento lee el estado de los sensores de choque y de los sensores de proximidad cercana (infrarrojos). Se encarga de buscar la salida optima en caso de que el robot haya chocado contra alg un objeto. Conserva una memoria de las u ltimas direcciones de choque, recordando las huidas infruct feras para no volver a cometer los mismos errores. Avoid - esquivar: este comportamiento lee el estado de los sensores de proximidad (cercana y lejana) y establece qu e objetos se encuentran en su camino, buscando un camino por el que no vaya a chocar contra nada en las pr oximas iteraciones. Un buen dise no de este comportamiento facilita el dise no del resto y mejora mucho el comportamiento global del robot.

4.2. ARQUITECTURA DEL SISTEMA

43

Figura 4.5: Malla de reacci on de AmiBot Fuente propia

Find human - buscar humano: lee de los sensores de proximidad por ultrasonidos y de los sensores piroel ectricos, con el n de hallar la direcci on en la que se encuentra la persona m as cercana al robot. Terrain - terreno: detecta los obst aculos del terreno no detectados de forma directa por los sensores de proximidad y los bumpers. Para ello, comparar a las lecturas de los encoders de las ruedas y los niveles de corriente en motores para detectar si hay un obst aculo no detectado. Adem as, este comportamiento es el encargado de detectar los desniveles del terreno y actuar de forma acorde.

El arbitro de comportamientos es el encargado de decidir qu e comportamientos ser an suprimidos, reorganizando la jerarqu a en funci on del modo de funcionamiento actual del robot. Las decisiones del arbitro ser an enviadas a los actuadores, que se comunicar an con la placa controladora de los motores, para conseguir que AmiBot siga las direcciones decididas. Adem as el sistema contar a con un proceso m as, con una sincronizaci on propia con el arbitro de procesos e independiente de la de los comportamientos meramente reactivos. Ser a el proceso Ambient - ambiente, encargado de la comunicaci on con el servidor AmiServer y la actualizaci on del modo de funcionamiento del arbitro de procesos con las ordenes procedentes del ambiente.

44
Dispositivo ADC con I2C ADS7830 Texas Inst. Uso Conversi on A/D de sensores infrarrojos, encoders, sensores de bater a y corriente

CAP ITULO 4. DISENO

Caracter sticas Alimentaci on: 3.3Vcc Conversor 8bits 8 canales multiplexados M aximo 4 dispositivos en el mismo bus Direcci on de esclavo jada por hardware Alimentaci on 3.3Vcc Expansor de 8bit M aximo 8 dispositivos en el mismo bus Direcci on de esclavo jada por hardware Alimentaci on: 5Vcc/3Vcc Requiere se nal de enable y pullup propio N umero 2

Expansor I2C PCF8574 Philips SC

Conversi on de la se nal digital de bumpers y piroel ectricos a trama de 8bit

Conversor de niveles I2C PCA9306 Texas Inst.

Conversi on de se nales de bus I2C de 5Vcc a 3.3Vcc para sensores de ultrasonidos

Cuadro 4.2: Integraci on de sensores en el bus I2C

4.3.
4.3.1.

Dise no del Hardware

La red de sensores

El dise no detallado de la red de sensores comprende el acondicionamiento de los sensores y su integraci on en el bus I2C. Tal y como se ha mencionado anteriormente, se utilizar an tres dispositivos diferentes con el n de comunicar todos y cada uno de los sensores de la red con el bus I2C de 3.3Vcc de la placa base de AmiBot. En la tabla 4.2 podemos ver las caracter sticas de cada uno y el n umero de dispositivos utilizados en el dise no. Los sensores de ultrasonidos Devantech SRF10 podr an ser conectados directamente al conversor de niveles I2C, a nadiendo u nicamente las resistencias de pull-up adecuadas. Estos dispositivos viene programados de f abrica todos con la misma direcci on de esclavo. Ser a necesario programarles la direcci on adecuada antes de integrarlos en el bus. La programaci on de esta direcci on viene especicada por el fabricante y puede realizarse de forma sencilla mediante comandos SMBUS. La br ujula e inclin ometro podr an conectarse directamente al bus I2C de 3.3Vcc del SoM. El resto de sensores necesitar an de un acondicionamiento previo para poderlos conectar, bien al ADC con interfaz I2C o bien al expansor I2C, que detallamos a continuaci on. El acondicionamiento m as simple es el aplicado a los sensores infrarrojos y a los bumpers. Pese a estar alimentados con una tensi on de 5Vcc, por construcci on, los sensores infrarrojos s olo con capaces de ofrecer a su salida una se nal anal ogica que tiene, como valor m aximo, 3.5Vcc. Dado que este valor a la pr actica queda limitado a un valor inferior a los 3.3Vcc, y a que la tolerancia de la se nal de entrada de los canales multiplexados ADC es mayor que este valor, podemos conectar directamente

 DEL HARDWARE 4.3. DISENO

45

la salida de los sensores infrarrojos a la entrada de los ADC. Los bumpers, por su parte, son simples pulsadores que ser an polarizados con una tensi on de 3.3Vcc y s olo necesitar an una resistencia de pull-down para jar su tensi on negativa cuando est en abiertos. La salida del pulsador (o de la resistencia de pull-down ) puede conectarse directamente a uno de los canales de entrada de los expansores I2C. Obtendremos, por tanto, una se nal perfectamente CMOS/3.3V compatible. En la gura 4.6 podemos ver el esquem atico del acondicionamiento de estos dos tipos de sensores.

Figura 4.6: Esquem atico del circuito de los bumpers y sensores infrarrojos Fuente propia El acondicionamiento de los sensores piroel ectricos y encoders entra na una complejidad mayor, tal y como veremos a continuaci on. En el caso de los piroel ectricos, el acondicionamiento requiere la utilizaci on del multivibrador monoestable dual MM74HC123A, cuyo funcionamiento podemos ver en la gura 4.7 Los sensores piroel ectricos ofrecen a la su salida un pulso de una amplitud muy peque na (4.3mVpp) que necesitar a pasar por una doble etapa de amplicaci on (preamplicaci on y amplicaci on, con el n mejorar el CMRR del sistema y tener un sistema m as robusto respecto a ruido) para su acondicionamiento. Los piroel ectricos duales dar an a su salida un pulso positivo en la activaci on del primer sensor y un pulso negativo en la activaci on del segundo, tal y como podemos ver en la gura 4.8. El correcto acondicionamiento de estos pulsos nos permitir a conocer, no s olo la presencia de una persona, sino tambi en la direcci on de su movimiento. Ser a conveniente convertir los pulsos dados por el piroel ectrico en pulsos cuadrados por medio de un comparador de ventana. La utilizaci on de un multivibrador monoestable dual nos permitir a proporcionar a la salida informaci on de la direcci on de movimiento en forma de dos bits. El bit de mayor peso indicar a un movimiento izquierda-derecha y el bit de menor peso, el movimiento contrario, con respecto al sistema de referencia del sensor piroel ectrico. La salida del circuito acondicionador ser a una se nal digital de 3.3Vcc que podr a conectarse directamente al expansor I2C. En la gura 4.9 podemos ver el circuito de acondicionamiento completo para el sensor, as como las se nales obtenidas en cada paso.

46

CAP ITULO 4. DISENO

Figura 4.7: Teor a de operaci on del multivibrador monoestable Fuente: Datasheet Fairchild Semiconductor

Figura 4.8: Se nal de salida de los sensores piroel ectricos Fuente: Infrared Parts Manual - Glolab Corporation

 DEL HARDWARE 4.3. DISENO

47

Figura 4.9: Circuito de acondicionamiento de los sensores piroel ectricos Fuente propia

Los encoders opticos de US Digital est an formados por un par de LEDs emisor-receptor y una rueda con una codicaci on pensada para reejar la luz emitida por el LED. En funci on del n umero de marcas opticas de la rueda, el encoder tendr a una mayor precisi on en grados. Cada marca optica corresponde a un ciclo. En el caso de los encoders de US Digital del robot, estos daban a su salida una se nal con 300 CPR (ciclos por revoluci on) con una resoluci on X4. Esto implica que a cada revoluci on se obtienen 1200 pulsos, de la forma que puede verse en la gura 4.10. Adem as, cuentan con dos canales a la salida, de forma que, en funci on de la se nal adelantada en fase, se puede deducir si est a produciendo un movimiento de la rueda hacia delante o hacia atr as. En un primer momento, se opt o por realizar un acondicionamiento muy simple para los encoders, basado u nicamente en la detecci on de los ancos en cualquiera de los dos canales y el c alculo de su promedio, s olo con el n de detectar si hab a un movimiento efectivo o no. Sin embargo, se vio que esta opci on ser a insuciente de cara a la segunda parte de este proyecto, cuando fuera necesario calcular la posici on exacta del robot y, adem as, se estaban desperdiciando las capacidades del sensor. As que se opt o por realizar un acondicionamiento que permitiera obtener, con resoluci on suciente, el n umero de ciclos (pulsos) obtenidos a la salida del sensor, entre encuestas consecutivas del bus I2C. De esta forma, de cara a la segunda parte del proyecto, y tal y como se detallar a m as adelante, se obtendr an un conjunto de datos de los sensores coherentes entre s . Este acondicionamiento ofrec a dos posibilidades:

48

CAP ITULO 4. DISENO

Figura 4.10: Funcionamiento de los codicadores opticos Fuente: Datasheet del fabricante US Digital la utilizaci on de varios de los GPIOs de la placa para realizar una lectura de ambas se nales, ver cu al de ellas se avanza y a la vez contar el n umero de pulsos producidos entre encuestas sucesivas del bus o bien un acondicionamiento hardware, que implicar a la utilizaci on de un PIC para contar los pulsos. El PIC ser a un sensor m as integrado dentro del bus I2C, que resetear a su contador interno a cada encuesta. La primera soluci on, pese a ser relativamente m as sencilla de implementar a nivel hardware, no parec a trivial desde un punto de vista software. Supuestamente, el SoM dispon a de un Watchdog Timer que nos permitir a realizar este acondicionamiento, si bien nos implicar a a nadir un driver para los GPIOs indicados y posiblemente recompilar el kernel completo. En cualquier caso, y pese a que esta opci on tambi en era viable, parec a m as sencillo aislar por completo la red de sensores del SoM y, siguiendo la misma pol tica que con el resto de sensores, utilizar el bus I2C. De esta forma, nos pod amos olvidar de problemas de sincron a entre lecturas de sensores. Se opt o, pues, por la segunda opci on de dise no. As pues, tal y como se puede observar en la gura 4.11, se opt o por la utilizaci on de un PIC con interfaz I2C y un m odulo espec co para el acondicionamiento de encoders opticos. El PIC utilizado ser a el modelo PIC18F2331 [3]. Optamos por un PIC de la familia 18 dado que cumpl a con las especicaciones del dise no y no nos dar a problemas de falta de memoria para nuestra aplicaci on concreta. Adem as, su relaci on calidad precio era muy buena y se dispon a de experiencia en el laboratorio de utilizaci on de PICs de la misma familia

 DEL HARDWARE 4.3. DISENO

49

y caracter sticas similares. El u nico inconveniente de esta soluci on es el hecho de que, dado que el PIC s olo dispone de un m odulo para el acondicionamiento de los encoders, necesitaremos dos PIC, uno para cada rueda, para llevar a cabo el acondicionamiento, lo que implicar a la utilizaci on de dos direcciones de esclavo.

Figura 4.11: Circuito de acondicionamiento de los encoders Fuente propia El PIC tendr a como entradas digitales las se nales de los canales A y B de los encoders. A cada encuesta del bus I2C, se resetear a el contador de ciclos y se seguir an contando los pulsos recibidos en el canal adelantado, anotando si ese canal es el A o el B para conocer el sentido de giro de las ruedas. Dada que la velocidad m axima del robot es de 1m/s, el tama no de las ruedas es de 18cm de di ametro, y teniendo en cuenta que, como m nimo y en el peor de los casos, se realizar an 2 encuestas al bus I2C por segundo (aunque el sistema est e preparado para realizar 4), mediante un c alculo simple obtenemos que el robot, entre encuestas, podr a avanzar 2 revoluciones. Dado que una revoluci on completa son 1200 pulsos, ser a necesario poder codicar hasta 2048 pulsos, lo que implicar a una resoluci on m nima de 12 bits. Por el bus I2C los datos que viajen deber an ser m ultiplos de 1 byte, por lo que utilizaremos 2 bytes para transmitir el valor de la cuenta. Este dise no encaja perfectamente con la implementaci on que el PIC18F2331 ofrece para los lectores opticos de cuadratura. En la gura 4.12 podemos ver el bloque Quadrature Encoder Interface del PIC. Este m odulo utiliza tres entradas de datos: QEA y QEB, correspondientes a los canales A y B del lector optico, y el canal INDX, que utiliza como reset del sistema. El m odulo, en cuanto una de las ruedas del robot inicia el movimiento, guarda en un bit de registro si el movimiento producido es hacia delante o hacia atr as, y en funci on de ese movimiento cuenta o descuenta valores de un contador (MAXCNT) previamente cargado. En nuestro caso, y dado que la u nica comunicaci on que tendremos con el m odulo es v a I2C, utilizaremos uno de los propios pines de salida del PIC para resetear el contador una vez hayamos le do el dato a trav es del bus I2C. En la gura 4.13 podemos ver el funcionamiento temporal del m odulo. Finalmente, mediante todos los acondicionamientos anteriormente vistos, se

50

CAP ITULO 4. DISENO

Figura 4.12: Diagrama del bloque QEI del PIC18F2331 Fuente: Microchip - Datasheet del fabricante.

Figura 4.13: Diagrama temporal del bloque QEI del PIC18F2331 Fuente: Microchip - Datasheet del fabricante.

 DEL HARDWARE 4.3. DISENO

51

consigui o dise nar un bus de sensores capaz de ser plenamente compatible con el protocolo SMBUS y, por tanto, no era necesario dise nar un driver para cada uno de los dispositivos, sino que se pod a acceder directamente a la lectura del bus mediante las funciones de espacio de usuario ofrecidas por las librer as de I2C est andar de un kernel 2.6 (en concreto, la librer a i2c-dev.h del paquete de lmsensors ). En el ap endice de planos D.1, se puede ver el dise no detallado del acondicionamiento de la red de sensores.

4.3.2.

Los motores

En el dise no de esta primera parte trataremos u nicamente con unos de los actuadores del robot: los dos motores de 12Vcc de las dos ruedas motrices de AmiBot. La especicaci on de dise no a cumplir era que, por una parte, los motores recibieran la suciente corriente como para poder mover el robot a una velocidad coherente. El robot no ten a por qu e ser capaz de alcanzar la velocidad m axima de dise no inicial de los motores, pero s ser capaz de moverse sin problemas y de transportar algo de peso, aunque fuera a costa de reducir su velocidad. El robot est a estructuralmente preparado para poder transportar hasta 10Kg en su plataforma, si bien no es la intenci on del dise no de los motores el poder transportar objetos de ese peso. La segunda especicaci on consist a en que el robot deb a ser capaz de tener un margen de maniobra suciente como para poder moverse c omodamente por el entorno del laboratorio, pudiendo realizar giros completos sobre s mismo. El dise no del circuito de acondicionamiento de los actuadores deber a ser tal que los motores pudieran ser f acilmente controlados mediante un n umero de GPIOs (el m nimo posible) provenientes de la placa Artila M-501. Dadas las especicaciones de dise no y la nalidad del circuito, se pod a optar por dos estrategias diferenciadas: Alimentaci on de los motores mediante un puente en H y un sistema de control basado en un regulador PID, que permitiera en todo momento controlar y corregir la velocidad de giro de los motores, de modo que el robot siguiera siempre la trayectoria prevista. Alimentaci on de los motores mediante un puente en H y un sistema de control PWM, sin posibilidad de programaci on software de la velocidad y limitado a una determinada corriente. Estas estrategias son de por s excluyentes entre ellas, y cada una posee una serie de ventajas e inconvenientes que fueron considerados a la hora de llevar a cabo el dise no. Los reguladores PID tienen como gran ventaja que permiten establecer y variar la velocidad de giro de los motores. La regulaci on PID permitir a establecer una consigna de velocidad para cada movimiento del robot y, a un m as, paliar el error asociado a la diferencia de velocidad de giro de ambas ruedas, permitiendo que, en un tramo recto prolongado, el robot no se desviara hacia ninguna direcci on. El problema de la regulaci on PID es, sin embargo, m as complejo de lo que parece. En primer lugar, desarrollar un sistema con regulador PID, que regule de forma adecuada la velocidad de giro de los motores en un tiempo de respuesta muy corto (el robot

52

CAP ITULO 4. DISENO

estar a cambiando constantemente su direcci on), y que adem as deba tener en cuenta qu e movimiento est a efectuando el robot (giros pronunciados, curvas suaves o rectas) para corregirlo de forma adecuada; es computacionalmente costoso y complicado de regular. Existen circuitos integrados comerciales que incluyen reguladores PID sencillos para este tipo de aplicaciones. Estos sin embargo suelen ser muy caros, y por tanto no ser a rentable incluir uno en nuestro robot. De modo que s olo ser a viable la soluci on de realizar todo el procesado en la placa M-501, sacando por alguno de los GPIOS una se nal PWM que ser a la que nalmente alimentar a un circuito con un puente en H para dar corriente a los motores. Esto, sin embargo, chocar a con el principio de intentar hacer el software de la placa lo m as liviano posible, sin sobrecargarlo innecesariamente. La regulaci on PID podr a dar muy buenos resultados, si bien no solucionar a el problema inherentemente asociado a la localizaci on de un robot: el error en el c alculo del desplazamiento del mismo. Si bien mejorar a, las ruedas siempre acabar an introduciendo un error y es por tanto imposible conseguir que el robot se desplace de forma perfectamente controlada por el entorno. Podr amos utilizar una excelente regulaci on PID, pero en las rectas, el robot acabar a desvi andose. La alimentaci on mediante un puente en H y un sistema de control PWM, sin embargo, es sencilla, barata y r apida. Existen toda una serie de circuitos integrados comerciales que permiten, a partir de un sistema de control basado una se nal digital de 2 bits por motor, programar el movimiento a realizar: mover motor hacia adelante, hacia atr as, frenarlo o deshabilitarlo. El integrado consta de una peque na etapa l ogica para decodicar las se nales de entrada, un generador PWM y un puente en H. La velocidad del motor puede ajustarse de forma manual mediante componentes hardware (una resistencia) cuyo valor establecer a la velocidad de giro. Un regulador basado en PWM se encargar a de dar corriente a los motores (limitada al valor m aximo admitido por el integrado) hasta que estos alcancen la velocidad de giro programada. Los inconvenientes claros de este sistema son, en primer lugar, la velocidad se jar a manualmente. Esta deber a ajustarse la primera vez y luego se trabajar a con ese valor, pero no podr a cambiarse ad-hoc. En segundo lugar, no hay posibilidad alguna de controlar que la velocidad de ambos motores sea la misma, ni de corregirla o compararla. Finalmente, se decidi o que el dise no de los actuadores se har a siguiendo la segunda opci on, por las siguientes razones: Simplicidad: uno de los objetivos del dise no de AmiBot era que fuera todo lo m as sencillo posible, sin detrimento de su funcionalidad. Un regulador PID no era sencillo de implementar de forma correcta, si bien esta soluci on lo era. El integrado realiza la regulaci on de velocidad, por lo tanto podemos asumir que el robot en general se mover a de forma semejante. Adaptaci on al entorno - asumir el error de los actuadores: el objetivo de esta parte era dise nar un robot capaz de moverse de forma aut onoma e inteligente por su entorno. Para ello no era imprescindible que el robot se moviera de forma perfecta por el, sino que supiera reaccionar perfectamente al entorno. Hagamos un s mil con el comportamiento humano: cuando caminamos, las personas no nos preocupamos por si nuestros pasos son m as largos o m as

 DEL HARDWARE 4.3. DISENO

53

cortos, o por si avanzamos en l nea recta. Nosotros simplemente avanzamos y, si vemos un obst aculo, giramos. Si no giramos lo suciente, volvemos a girar. Pero en ning un momento dedicamos nuestra atenci on a si acercarnos a una mesa nos llevar a m as o menos pasos, o si estos ser an o no, realizados en una l nea perfectamente recta. Perder tiempo y esfuerzo en intentar que las ruedas del robot se movieran de forma perfecta era, en este punto, totalmente innecesario. De esta forma, para el sistema de acondicionamiento de los actuadores, se dise n o el circuito de la gura 4.14. Para ello se utiliz o el integrado A3968 de Allegro MicroSystems, capaz de controlar bidireccionalmente hasta dos motores DC, ofreciendo una corriente a la salida de hasta 600mA, con voltajes de operaci on de hasta 30V. La corriente m axima de salida puede jarse mediante una resistencia (en nuestro caso 0,5) y la duraci on del pulso PWM mediante la constante de tiempo de un circuito RC. Las se nales de control permiten cambiar el funcionamiento del motor, permiti endonos frenar, moverlo hacia adelante, hacia atr as o deshabilitarlo. La combinaci on de las se nales de los motores y el tiempo durante el cual se apliquen nos permitir an denir ocho direcciones de movimiento del robot (ver gura 4.15).

Figura 4.14: Dise no de los actuadores para las ruedas motrices de AmiBot Fuente propia En el ap endice de planos D.7, se puede ver el dise no detallado del circuito.

4.3.3.

La alimentaci on del robot

Para la alimentaci on completa del robot se dispon a de dos bater as de 7.2Vcc y 3700mAh. El robot original funcionaba con un s olo pack de bater as y utilizaba el segundo como bater a de reserva, para poder cambiarla manualmente cuando

54

CAP ITULO 4. DISENO

Figura 4.15: Control de los actuadores de AmiBot Fuente propia

la primera se hubiera agotado. En el caso de AmiBot, se pretend a que el robot pudiera disponer de un puesto de recarga de bater a (Dock ) al cual acudir a cuando sus bater as se estuvieran agotando y en el que permanecer a hasta que estas se hubieran cargado por completo. Por esta raz on, se decidi o utilizar los dos packs de bater as simult aneamente en el robot. De esta forma aumentar amos su autonom a y siempre estar amos utilizando ambos packs de bater a. Al disponer de dos bater as, se nos planteaba la primera decisi on de dise no de importancia: la conexi on en serie de las mismas, o la conexi on en paralelo. Lo que podr amos traducir a: un aumento de la corriente m axima capaz de absorber por el sistema, o bien a un aumento de la tensi on de entrada del sistema antes de la etapa de regulaci on. El segundo factor limitante del dise no era la necesidad de una doble regulaci on: regulaci on a 5Vcc y regulaci on a 3.3Vcc. Para realizar esta regulaci on nos jamos en el dise no del esquem atico que nos proporcionaba Artila para su SoM. La estrategia de dise no de Artila consist a en la utilizaci on de un regulador commutado ajustable (step-down) para bajar de la tensi on de entrada (entre 9 y 40 Vcc) a 5Vcc, y posteriormente la colocaci on en cascada de un regulador lineal para bajar de 5Vcc a 3.3Vcc. Esta estrategia parec a adecuada para nuestro sistema, de forma que se decidi o adaptarla a nuestros requisitos. El tercer factor limitante del dise no era la corriente que iba a consumir el sistema y, m as importante todav a, los picos de corriente que iban a producir algunos de los elementos del sistema, como son los motores. Para minimizar los efectos de estos picos de corriente, se puso especial atenci on en el dise no de los ltros de salida de los reguladores y en los de entrada de los diferentes componentes a los que se alimentaba. Para ello se separaron por bloques los circuitos en funci on de la alimentaci on requerida, teniendo en cuenta que cada bloque deb a tener un camino de retorno diferenciado para evitar que el ruido de cada uno (en especial los motores) se colara en el regulador y se repartiera por el resto del circuito. A cada uno de estos bloques se le dot o de un fusible reseteable PPTC, de forma que las zonas quedaran protegidas de corrientes excesivamente elevadas, tal y como puede verse en la gura 4.16

 DEL HARDWARE 4.3. DISENO

55

Figura 4.16: Estrategia de alimentaci on del sistema - Separaci on por bloques Fuente propia Finalmente, antes de realizar el dise no en detalle de los componentes, era necesario realizar una estimaci on del consumo del sistema, con el n de poder calcular la corriente m axima (y corriente m axima de rizado) que deber a ser capaz de soportar nuestro regulador. A continuaci on, en la tabla 4.3, podemos ver cu ales son los requisitos de corriente de nuestro sistema, calculado en el peor de los casos. Tal y como puede apreciarse, el sistema deber a ser capaz de dar una corriente m axima de 2.2A aproximadamente. En la pr actica nunca alcanzaremos este valor, dado que para ello todos los dispositivos deber an estar trabajando en el peor caso de consumo de corriente y todos ellos de forma simult anea, si bien si podemos esperarnos picos que alcancen ese valor. Si hacemos el dise no del regulador con ese dato de corriente, sin embargo, nos aseguramos el funcionamiento del sistema para la segunda parte de este PFC, cuando el SoM est e trabajando a pleno rendimiento y adem as estar a preparado para, m as adelante, utilizar los servomotores de la c amara. De este modo, mantendremos una previsi on de corriente m axima de 2.2A, que corresponder a a una corriente RMS de aproximadamente 3A. Siguiendo la estrategia de dise no de un regulador conmutado de 5Vcc y otro lineal para pasar de 5Vcc a 3Vcc, y partiendo de los esquem aticos de Artila, elegimos el regulador conmutado LM2596S-5.0 y el regulador lineal LM1085IS-3.3 y los dise namos para que sean capaces de soportar una corriente RMS de hasta 3A. Con estas consideraciones y en funci on de los datos aportados por el datasheet del fabricante, vemos que el dise no que nos aporta un rendimiento optimo del regulador es el basado en la conexi on de las dos bater as en serie (tensi on de entrada de 14,4Vcc y corriente de 3700mAh), dado que el rendimiento del regulador disminuye para tensiones de entrada inferiores. Con los datos del regulador se realiza el ajuste de los valores de los componentes,

56
Dispositivo SoM Artila M-501 M odulo WLAN Conceptronic RC54C Motores (con integrado Allegro A3968) Sensores infrarrojos SHARP Sensores ultrasonidos Devantech SRF10 Sensores choque Piroel ectricos y circuito de acondicionamiento Encoders y circuito de acondicionamiento Br ujula I2C HMC6352 Inclin ometro (tilt sensor) LIS302DL Conversores ADC 8 bit Expansores I2C Consumo (mA) 760 330 650 30 15 2 5 N umero uds. 1 1 1 10 6 10 4

CAP ITULO 4. DISENO

Consumo total (mA) 760 330 650 300 90 20 20

18mA 2 <1 <1 <1

2 1 1 2 3

36mA 2 <1 <1 <1

Cuadro 4.3: Consumo estimado del sistema llegando al dise no nal del circuito que puede verse en la gura 4.17

Figura 4.17: Circuito de regulaci on de la alimentaci on Fuente propia En el ap endice de planos D.5, se puede ver el dise no detallado de la alimentaci on del sistema.

4.4.

Dise no del software

El dise no del software comprende la creaci on, gesti on y sincronizaci on de los procesos o hebras1 que conforman el comportamiento del agente reactivo AmiBot.
1 en adelante, y u nicamente en el apartado de dise no, utilizaremos indistintamente ambos t erminos para hacer referencia a segmentos de c odigo que a efectos pr acticos ser an ejecutados de forma concurrente y se sincronizar an entre ellos

 DEL SOFTWARE 4.4. DISENO

57

Los principios del comportamiento reactivo obligan a la creaci on de una hebra por cada uno de los comportamientos del sistema, as como de una hebra para el arbitro. En nuestro caso, adem as, se a nadir an tres procesos m as: uno para la gesti on de la comunicaci on con ambiente inteligente (cliente de AmiServer), otro para la gesti on de los actuadores y un u ltimo para la encuesta del bus I2C. El sistema tendr a un funcionamiento c clico: a cada ciclo se realizar a una encuesta del bus, y en base al valor de los sensores, los comportamientos decidir an, de forma concurrente, cu al es su decisi on, que deber a ser comunicada al arbitro, que actuar a sobre los motores de AmiBot.

Figura 4.18: Principio de funcionamiento del comportamiento reactivo Fuente propia El funcionamiento detallado del sistema es el de la gura 4.18: El proceso I2C Read realiza una encuesta c clica de todo el bus I2C, obteniendo los valores de todos los sensores y guard andolos en el recurso compartido SensorValue. Cada uno de los comportamientos consulta el recurso compartido SensorValue, qued andose con los valores que necesite para realizar sus c alculos internos y propone una decisi on al arbitro. El arbitro de procesos toma una decisi on en funci on de las propuestas de los diversos comportamientos, jerarquiz andolos en funci on del modo de funcionamiento del robot. El arbitro env a su decisi on a los actuadores. Para la correcta sincronizaci on del sistema, podemos dividir el problema en dos partes diferenciadas (g. 4.19):

58

CAP ITULO 4. DISENO Un primer problema consistente en la sincronizaci on de un proceso escritor (I2C Read ) y N procesos lectores (Behaviour ) que comparten el recurso SensorValue (array de valores de los sensores). Un segundo problema consistente en la sincronizaci on de N procesos escritores (Behaviour ) y un proceso lector (Arbiter ) que comparten el recurso OrderArray (array ordenes propuestas por los comportamientos).

Figura 4.19: Sincronizaci on del sistema del agente reactivo Fuente propia La correcta sincronizaci on de ambas partes por separado, implicar a la correcta sincronizaci on del comportamiento reactivo concreto. Para ello ser a necesario utilizar las herramientas b asicas de sincronizaci on entre procesos (condiciones y exclusi on mutua de procesos). La hebra de comunicaci on con el ambiente inteligente ser a la encargada de gestionar las conexiones con el servidor AmiServer y el env o de informaci on entre ellos. Esta se sincronizar a con el arbitro de procesos para cambiar su modo de funcionamiento como un escritor m as, si bien no inuir a para nada en la lectura del recurso compartido que supone el bus I2C. Este proceso ser a el encargado de conectarse como cliente al servidor AmiServer a trav es de un socket a trav es del cual se comunicar an la informaci on pertinente. El dise no software del servidor AmiServer, tal y como se ha comentado anteriormente, comprende la gesti on de la informaci on procedente de AmiBot y la creaci on de un demostrador que permita al usuario congurar el robot de forma sencilla e intuitiva. En el apartado de implementaci on, estudiaremos en detalle la estructura y c omo se llev o a cabo dicho demostrador.

Cap tulo 5 Implementaci on

A partir del an alisis y el dise no realizado en los apartados anteriores, se procedi o a la implementaci on del prototipo completo para integrarlo en el robot m ovil y realizar las pruebas de funcionamiento pertinentes. Se procur o que la implementaci on cumpliera con todos los objetivos expuestos para esta primera parte del PFC. Tal y como se expuso en el apartado de dise no, sin embargo, algunas funcionalidades deber an aplazarse para la segunda parte del PFC. La implementaci on se dividi o en un primera parte hardware, para dotar al robot de su red de sensores, actuadores y placa base; y una segunda parte software, capaz de convertir el robot en un agente reactivo comunicado con su entorno.

5.1.

Implementaci on Hardware

La implementaci on hardware del sistema comprende, desde la colocaci on f sica de la red de sensores, tal y como se dispuso en el dise no, hasta la fabricaci on de los PCBs necesarios para el acondicionamiento, la placa base, regulaci on, etc. y la interconexi on de los diversos m odulos entre ellos. En el caso de la implementaci on de la red de sensores, adem as, ser a necesario realizar una m nima caracterizaci on de los sensores una vez dispuestos en el robot, con el n de establecer los umbrales de detecci on. En la segunda parte de este PFC se ampliar a este concepto, realizando una caracterizaci on m as exacta de algunos de los sensores, que ser au til para el mapeado del entorno. En el apartado de red de sensores, tambi en se prestar a atenci on a la implementaci on de los actuadores y sus acondicionadores de se nal.

5.1.1.

La red de sensores y actuadores

En primer lugar se desensambl o por completo el robot X80 original, dado que era necesario rehacer desde cero la interconexi on de todos los elementos. Se quitaron las placas de procesamiento y los sensores que no iban a utilizarse. Se distribuyeron los sensores de choque, ultrasonidos e infrarrojos seg un se especic o en el apartado de dise no (ver secci on 4.1.1). Se conserv o en gran parte la disposici on original de 59

60

CAP ITULO 5. IMPLEMENTACION

los sensores infrarrojos y los encoders, dado que coincid a en gran medida con el dise no. Todos los sensores fueron identicados y numerados de la forma m as clara posible, de forma que pudieran integrarse en el bus I2C de forma ordenada. En la gura 5.1 se puede apreciar la disposici on redundante de los sensores infrarrojos y ultrasonidos, as como de los bumpers.

Figura 5.1: Disposici on redundante de los sensores de AmiBot Fuente propia Se decidi o que todas las placas de acondicionamiento, exceptuando las de los sensores piroel ectricos, se instalar an bajo la plataforma del robot, de modo que quedaran protegidas de golpes por la cubierta, a la vez que aisladas de las interferencias electromagn eticas que podr an producir los motores. Los sensores piroel ectricos, dado el tipo de acondicionamiento y la se nal de salida del sensor, deber an estar instalados en el lugar de medida. Para todos los PCB interconectados con la placa base mediante I2C, se deni o una misma interfaz de 4 pines: Vcc-SDASCL-Gnd, con las se nales de alimentaci on y comunicaci on del bus. Los sensores infrarrojos, la salida del circuito de acondicionamiento de los encoders, el sensor de bater a y el sensor de corriente en motores fueron llevados a los ADC. Para ello fue necesaria la realizaci on del siguiente PCB (ver gura 5.2), que implementa el dise no del circuito que podemos ver en el ap endice D.1.3. B asicamente, el PCB incluye dos ADC con diferente direcci on de esclavo (jada por hardware ) y toda una serie de headers para conectar los sensores a los canales de los ADC. Los bumpers y las salida del circuito de acondicionamiento de los sensores piroel ectricos, son llevados a los expansores I2C. Para ello se realiz o el PCB de la gura 5.3, que implementa el dise no del circuito del ap endice D.1.4. B asicamente el circuito consta de 3 expansores I2C con la direcci on jada por hardware, las resistencias de pull-down necesarias para los bumpers y todos los pines necesarios para conectar los sensores a los canales de los expansores. A los sensores de ultrasonidos se les program o una direcci on de esclavo distinta a cada uno, y posteriormente, una vez dispuestos en el robot, se ajust o su Analog Gain (ajuste en ganancia) para mitigar el efecto de las falsas detecciones a causa

 HARDWARE 5.1. IMPLEMENTACION

61

Figura 5.2: PCB para los ADC con interfaz I2C Fuente propia

Figura 5.3: PCB para los expansores I2C Fuente propia

62
Sensor USR0 USR1 USR2 USR3 USR4 USR5

CAP ITULO 5. IMPLEMENTACION

Analog Gain 6 8 8 8 4 8

Cuadro 5.1: Analog Gain de los sensores de ultrasonidos

de los reejos producidos por el suelo. En la tabla 5.1 se puede ver la ganancia nal utilizada para cada sensor. Debe tenerse presente que una reducci on de la ganancia implica una disminuci on del rango de medida de cada sensor, por ello es benecioso que los sensores de ultrasonidos tuvieran un rango m aximo mucho mayor del necesario para que, una vez ajustada la ganancia, no se nos quedaran cortos en cuanto a detecci on se reere. Adem as, dado que los sensores de ultrasonidos se alimentaban a 5Vcc, fue necesario instalar un conversor de niveles I2C de 3.3Vcc a 5Vcc (PCA9306). Para la primera versi on de este prototipo no se lleg o a realizar un PCB del circuito, hecho que quedar a pendiente como mejora de este PFC. El circuito conversor de niveles se mont o reaprovechando un PCB con la misma huella, de forma que se pudieran alimentar los sensores de ultrasonidos. El acondicionamiento de los sensores piroel ectricos se realiz o tal y como se dise n o en el apartado 4.3.1. Dada la disposici on de los sensores piroel ectricos en el robot, se dise n o el PCB de forma que los componentes pudieran quedar lo m as protegidos posible por la propia carcasa del robot. Los circuitos quedaron tal y como se muestra en la gura 5.4. Pese al correcto funcionamiento del acondicionamiento de se nal, los sensores piroel ectricos en la aplicaci on de este sistema, presentaban un comportamiento algo conictivo. Los sensores eran muy sensibles a las fuentes de radiaci on infrarroja y poco directivos, lo que, pese a ser bueno para poder detectar personas, supon a un problema a la hora de saber en qu e direcci on se encontraba esa persona. El funcionamiento ser a correcto en lugares poco poblados pero en interiores, en una sala donde f acilmente pueda haber un conjunto considerable de personas en poco espacio, puede ser imposible saber de d onde procede la fuente de radiaci on m as cercana.

Figura 5.4: PCB para el acondicionamiento de los sensores piroel ectricos Fuente propia

 HARDWARE 5.1. IMPLEMENTACION

63

En cuanto a los encoders, se opt o por equipar al prototipo con el acondicionamiento b asico descrito en el apartado de dise no y consistente u nicamente en una detecci on de si exist a o no movimiento. En el momento de escritura de esta memoria, pese a que se realiz o el dise no del circuito capaz de codicar con exactitud el movimiento de las ruedas, todav a no se dispone de una implementaci on funcional de este. Por u ltimo, se incluyeron tambi en en el robot la br ujula y el aceler ometro de 3 ejes comentados anteriormente (ver gura 5.5). En el caso de la br ujula cabe destacar que, debido a los campos magn eticos presentes en el propio robot (motores, la propia estructura met alica, etc.), fue necesario realizar una recalibraci on del dispositivo para eliminar el oset magn etico inicial y obtener medidas correctas. El dispositivo ven a preparado para este tipo de calibraci on, de modo que no supuso ning un problema adicional.

Figura 5.5: La br ujula y el aceler ometro de 3 ejes de AmiBot Fuente: Datasheet HMC6352 y LIS302DL Las huellas de todos los PCB se pueden encontrar en el ap endice de planos (ap endice D). Finalmente, con todos los PCBs dispuestos e interconectados, se conform o el bus I2C completo. A continuaci on, incluimos una tabla (ver cuadro 5.2) en la que se puede ver el acceso a cada uno de los dispositivos mediante su direcci on de esclavo, y una breve descripci on del comando SMBUS (ver ap endice B) que deber a utilizarse en cada caso. En cuanto a los actuadores, se implement o un u nico PCB que tuviera como entradas las se nales de control provenientes de los GPIOs del SoM M-501, y que diera como salida las corrientes necesarias para alimentar directamente los motores. El integrado utilizado, el A3968 de Allegro MicroSystems, era capaz de ofrecer a su salida corrientes de hasta 600mA para alimentar los motores. Por ello, se dise n o el PCB de tal forma que la etapa de potencia correspondiente a los motores tuviera componentes SMD capaces de aguantar las corrientes que se iban a disipar. Del mismo modo, y con el n de minimizar las p erdidas, se procur o que las conexiones de la etapa de potencia de realizaran con pistas m as anchas de lo habitual, y la conexi on a los motores se realiz o a trav es de bloques terminales, que impidieran cortocircuitos entre los cables en bornes del motor. Se prest o una especial atenci on a la etapa de ltrado de alimentaci on de los motores, dado que eran susceptibles

64

CAP ITULO 5. IMPLEMENTACION

Sensor IR0 IR1 IR2 IR3 IR4 IR5 IR6 IR7 IR8 IR9 BAT CURR ENCR ENCL BUMPER 0-7 BUMPER 8-9 Piro 0-3 USR 0 USR 1 USR 2 USR 3 USR 4 USR 5 COMPASS TILT

Dispositivo I2C Canal Tipo 0 - 0x84 1 - 0xC4 1 - 0x94 1 - 0xD4 ADC 0 1 - 0xA4 1 - 0xE4 1 - 0xB4 1 - 0xF0 0 - 0x84 1 - 0xC4 ADC 1 1 - 0x94 1 - 0xD4 0 - 0x00 PIC 0 - 0x03 Expander 0 Expander 1 Expander 2

Trama SMBUS

Direcci on de esclavo

Read byte data

0x48

Read byte data

0x49

Read word data Read byte data Read byte data Read byte data

0x54 0x38 0x39 0x3A 0xE0 0xE2 0xE4 0xE6 0xE8 0xEA 0x21 0x1C

Interno

Write/Read byte data

Disp.Integrado Disp.Integrado

Read word data Read word data

Cuadro 5.2: Direcciones de esclavo I2C de la red de sensores de AmiBot

 HARDWARE 5.1. IMPLEMENTACION

65

de producir ruido de alta frecuencia que, sin el ltrado adecuado, se colar a en el resto de la alimentaci on. A efectos de evitar sobrecorrientes, adem as se incorpor o un fusible PPTC al sistema, tal y como se mostraba en la etapa de dise no. El PCB de acondicionamiento de los actuadores, que puede verse en la gura 5.6 tambi en incluye la circuiter a necesaria para el sensado de corriente en los motores. La salida del sensor deber a llevarse a la placa de ADCs con el n de convertirla a un valor inteligible y poder realizar un procesado sobre ella para conocer una estimaci on del nivel de corriente en motores.

Figura 5.6: PCB de acondicionamiento de los motores de las ruedas de AmiBot Fuente propia

5.1.2.

La placa base y el m odulo WiFi

La realizaci on de la placa base de AmiBot, tal y como se coment o en el apartado de dise no, comprend a la implementaci on de un PCB que hiciera las funciones de socket para el SoM M-501 y acondicionamiento de las se nales de entrada salida. Para ello, se incluyeron los siguientes m odulos en la placa base: Alimentaci on y regulaci on Acondicionamiento USB Socket SoM M-501 Circuiter a de Reset Expansi on de se nales de alimentaci on y tierra Expansi on de puertos E/S Expansi on de puertos I2C y acondicionamiento En la gura 5.7 pueden apreciarse los bloques de que consta el PCB, y en la gura 5.8 puede apreciarse el PCB montado y con el SoM insertado en su socket correspondiente. A continuaci on, exponemos algunas de las particularidades de cada uno de los bloques tenidas en cuenta a la hora de realizar el PCB correspondiente.

66

CAP ITULO 5. IMPLEMENTACION

Figura 5.7: Bloques del PCB de la placa base de AmiBot Fuente propia

Figura 5.8: PCB de la placa base de AmiBot montada con el SoM de Artila Fuente propia

 HARDWARE 5.1. IMPLEMENTACION Alimentaci on y regulaci on

67

Con el n de minimizar los efectos adversos debidos a las posibles p erdidas del regulador, se dedic o especial importancia a la parte del PCB del regulador. Se sectoriz o el PCB completo, asignando una parte al regulador, con un plano de masa dise nado para minimizar las p erdidas resistivas y pistas lo m as cortas posibles entre los componentes del regulador, situ andolos de forma que se minimizaran las interferencias, tal y como se indicaba en el datasheet. Las pistas, adem as, se realizaron lo m as anchas posibles. De la masa del regulador se sacaron el resto de masas que, mediante caminos diferenciados en rutado, se distribuyeron hacia el resto de m odulos.

Acondicionamiento USB Para permitir la conexi on con el m odulo Wi Conceptric RC54U, se dispuso en el PCB un conector USB hembra en el extremo de la placa que quedaba menos tapado por la cubierta de AmiBot, en la parte trasera del robot. De este modo, pese a que la placa base quedar a protegida por la cubierta, la interfaz Wi quedar a al aire y no se sufrir a una disminuci on de la cobertura. Para el acondicionamiento de la interfaz Wi se realiz o el ltrado de su alimentaci on y las se nales del par diferencial USB, llev andolas desde el SoM M-501 hasta el circuito acondicionador, tomando como modelo el de los esquem aticos del kit de desarrollo del SoM.

Socket del SoM y circuito de reset El acoplamiento de la placa M-501 al SoM requer a la creaci on de una huella de cero con un conjunto de sockets dispuestos de la forma adecuada y de las dimensiones adecuadas para poder alojar el SoM. Las l neas del SoM que iban a utilizarse en esta implementaci on se rutaron hacia el exterior, para poderlas utilizar en el resto de la placa y el sistema. Adem as, se implement o un circuito de reset hardware de la placa por si fuera necesario en un futuro, tambi en tomando como punto de partidas los esquem aticos del kit de desarrollo de Artila.

Expansi on de puertos Con el n de interconectar el resto de m odulos del sistema, se realiz o una expansi on del puerto I2C y los GPIOS, y se dise n o la alimentaci on de forma que esta quedara dispuesta para poder conectar no s olo el SoM sino el resto de m odulos de AmiBot, con posibilidad de ampliarlos en un futuro. La expansi on se realiz o de forma que ocupara el m nimo de espacio posible y estuviera dispuesta de la forma m as sencilla y menos enrevesada posible. En la gura 5.9, se puede apreciar la distribuci on del sistema completo sobre la cubierta de AmiBot.

68

CAP ITULO 5. IMPLEMENTACION

Figura 5.9: Distribuci on de los PCBs sobre la cubierta de AmiBot Fuente propia

5.2.

Implementaci on Software

La implentaci on software del sistema comprende, por una parte, la generaci on de todo el c odigo correspondiente al comportamiento reactivo de AmiBot y su puesta en funcionamiento. En segundo lugar, comprende la implementaci on de un demostrador de la comunicaci on con el ambiente inteligente mediante la estructura cliente/servidor AmiServer, con una GUI que permitiera comprobar las funcionalidades b asicas del sistema y poner en pr actica la comunicaci on con el robot.

5.2.1.

Agente reactivo AmiBot

En base al estudio realizado en los cap tulo de An alisis y Dise no, la programaci on de todo el comportamiento reactivo se llev o a cabo en el lenguaje de programaci on C, y con la ayuda de las herramientas POSIX de que se dispon a en el kernel 2.6 del SoM. En concreto, se utiliz o pthreads [28] para la gesti on de la concurrencia entre procesos. Se opt o por esta opci on en vez de por la de crear procesos completos concurrentes (mediante un fork ) porque, pese a que el sistema lo permit a (recordemos que el SoM M-501 tiene MMU), se consider o de importancia minimizar la utilizaci on de recursos del sistema. En este caso, la herramienta pthreads permit a una comunicaci on m as ecaz entre hebras y mejoraba el comportamiento de todo el sistema. Para la correcta sincronizaci on de todas las hebras se utilizaron las herramientas que proporcionaba el propio pthreads, creando tantas hebras como comportamientos tuviera el agente reactivo, adem as de las hebras del arbitro, los actuadores, la comunicaci on con el ambiente inteligente y la encuesta del bus I2C. En las guras 5.10 y 5.11 mostramos los diagrama de ujo simplicados del

 SOFTWARE 5.2. IMPLEMENTACION funcionamiento de cada uno de los comportamientos reactivos del robot: Survive Escape Avoid Find-Human Terrain

69

En cuanto a la hebra encargada de la comunicaci on con el ambiente inteligente, esta se conecta mediante dos sockets TCP al servidor AmiServer. A trav es del primero se env a y recibe la informaci on referente al estado del robot y las ordenes con respecto al modo de funcionamiento. El segundo se implement o como un canal unidireccional de env o de informaci on de debug desde el robot al servidor del ambiente inteligente. A trav es del socket de informaci on se enviaba un string de informaci on robot-servidor que conten a la informaci on de: modo, estado y posici on actual del robot (para hacer el sistema compatible con la segunda parte de este PFC); y se recib a una orden en forma de string servidor-robot que conten a el modo de funcionamiento que ordenaba el ambiente inteligente y, de forma optativa, una pista acerca de la siguiente posici on a la que ha de ir el robot para poder cumplir con la orden (esta parte quedar a plenamente funcional en la segunda parte de este PFC). La hebra se encarga de leer peri odicamente (como primera aproximaci on 2 segundos parec a un intervalo coherente de tiempo) el estado actual del robot y enviarlo al servidor, y recibir de este una nueva orden, consistente (en primera iteraci on) en un modo de funcionamiento. Este proceso se sincroniza con el arbitro a trav es de una variable compartida por ambos y protegida por exclusi on mutua. El arbitro de procesos, por su parte, espera a que todos los comportamientos hayan tomado una decisi on de cu al debe ser la siguiente direcci on a tomar. Una vez todos han decidido, el arbitro lee el estado actual de robot (modo de funcionamiento y estado), y en funci on de este, toma una decisi on predenida. El arbitro consulta las decisiones de todos los comportamientos y modica (o no) la decisi on predenida, en base a los siguientes criterios que se ejecutan de forma secuencial: Si la decisi on de todos los comportamientos es ANY, se sigue la decisi on predenida Si el comportamiento Terrain detecta un obst aculo (su orden es STOP), se ignora la decisi on predenida y se gira 90o a derecha o izquierda con probabilidad 0.5 En el resto de casos, alg un comportamiento ha detectado un obst aculo: Priorizamos la decisi on del comportamiento Escape sobre el resto (a menos que Survive indique STOP). Si Escape y Avoid no deciden nada (orden ANY) y Survive tiene una orden distinta de ANY o STOP, la seguimos

70

CAP ITULO 5. IMPLEMENTACION

(a) Survive Behaviour

(b) Escape Behaviour

(c) Avoid Behaviour

Figura 5.10: Diagramas de ujo de los comportamientos de AmiBot Fuente propia

 SOFTWARE 5.2. IMPLEMENTACION

71

(a) Find-Human Behaviour

(b) Terrain Behaviour

Figura 5.11: Diagramas de ujo de los comportamientos de AmiBot (II) Fuente propia

72
Archivo amibot.c [./amibot/] arbitration.c report.c /sensors/ i2c bus.c matrix.h /behaviour/ behav.c concurrent.c /actuators/ /ambient/ motor driver.c ambient.c

CAP ITULO 5. IMPLEMENTACION

Descripci on Archivo principal, contiene el main. Crea los threads y ejecuta la funci on de encuesta del bus I2C Thread del arbitro de procesos Archivo de apoyo para las funciones de report de AmiBot. Encuesta a bajo nivel de los sensores del bus I2C Funci on con los valores para acceder a los GPIO mediante comandos IOCTL Archivo con todos los comportamientos del agente reactivo Archivo de apoyo con las funciones de concurrencia de los comportamientos Gesti on a bajo nivel de los motores de AmiBot mediante comandos IOCTL Archivo para la comunicaci on con el ambiente inteligente (cliente AmiServer), conexi on mediante sockets TCP

Cuadro 5.3: Estructura de archivos del agente reactivo AmiBot Si Avoid detecta un obst aculo, y no estamos siguiendo humanos, seguimos su orden. En caso contrario, seguimos la orden indicada por Find-Human. Esta implementaci on da lugar a la estructura de archivos para el agente AmiBot que puede verse en el cuadro 5.3.

5.2.2.

Demostrador AmiServer

La implementaci on del demostrador de Amiserver se llev o a cabo en Java, dado que era necesario utilizar un lenguaje de programaci on que permitiera, de forma sencilla, realizar una Gui que permitiera programar de forma f acil el modo de funcionamiento del robot. La Gui se llev o a cabo utilizando las librer as SWT y un modelo MVC que permit a al usuario congurar el robot de forma intuitiva. En la gura 5.12 se puede apreciar la interfaz de la aplicaci on. Permite cambiar el modo de funcionamiento del robot y, a la vez, visualizar el estado del robot. Pese a que s olo se implementa esta parte, la aplicaci on est a preparada para poder visualizar en la misma ventana el mapa del entorno del robot e interactuar con la c amara de a bordo. El modelo implementa el servidor AmiServer, al que se conecta el cliente AmiBot para poder enviar y recibir informaci on. El controlador actualiza los cambios en la interfaz e informa de los cambios congurados por el usuario al modelo. En el cuadro 5.4 se puede ver la estructura de archivos de AmiServer. El diagrama completo de clases puede encontrarse en el ap endice E.

 SOFTWARE 5.2. IMPLEMENTACION

73

Figura 5.12: Interfaz gr aca del demostrador del servidor AmiServer Fuente propia

74

CAP ITULO 5. IMPLEMENTACION

Paquete amiserver

Clase AmibotModel

InfoServer amiserver.server

DebugServer

SocketString

amiserver.amigui

GuiView

DebugDialog

.amigui.controller

Controller

ModeController

amiserver.iface

Buer BuerString

Descripci on Clase principal, contiene el main. Crea el resto de clases, parsea la informaci on obtenida de los sockets e informa de los cambios a la Vista Thread encargado de la lectura del socket de Informaci on y el env o de la informaci on recibida, por una pipe, al Modelo Thread encargado de la lectura del socket de Debug y el env o de la informaci on recibida, por una pipe, al Modelo Clase con m etodos para la correcta comunicaci on del cliente (socket C) con el servidor (socket Java) Vista. Thread que crea los di alogos y muestra la ventana principal de AmiBot, con todas sus opciones Vista. Di alogo de debug que permite visualizar los mensajes enviados por AmiBot Controlador. Thread que actualiza la Vista a partir de los datos recibidos de AmiBot Controlador. Informa al modelo de los cambios que se han producido en la vista (a partir de acciones del usuario) Clase abstracta de un buer de datos Extiende de Buer y guarda un String de tama no variable en cada posici on del Buer

Cuadro 5.4: Estructura de archivos del servidor AmiServer

5.3. PRUEBAS

75

En cuanto a la implementaci on del demostrador, cabe destacar que las librer as de SWT s olo utilizan una clase con un thread de ejecuci on para actualizar la vista. Si se quiere actualizar la vista desde varios puntos (como en este caso, en que la clase Controller actualiza datos y tambi en lo hace GuiView) entonces debemos recurrir a la ejecuci on de un m etodo ejecutable (el de la clase Controller) mediante el m etodo syncExec() durante los ciclos en que la GUI no sufre actualizaciones de GuiView dentro de bucle de control de la Vista, tal y como puede verse a continuaci on:
public class GuiView extends Thread implements Observer{ ... public void run(){ ... while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.syncExec(ctrl); display.sleep(); } } display.dispose(); } ... }

Tambi en debe prestarse atenci on a la comunicaci on entre sockets C de AmiBot y sockets Java, dado que los tama nos de variables (char e int) denidos por la m aquina virtual de Java dieren de los de C, de forma que algunas conversiones acaban no siendo tan inmediatas como podr a parecer en un principio.

5.3.

Pruebas

Para probar el correcto funcionamiento del prototipo implementado, se llevaron a cabo toda una serie de pruebas. Primero se prob o todo el hardware implementado de forma aislada, en segundo lugar se prob o todo el software y, nalmente, se realizaron las pruebas de conjunto de todo el sistema. A continuaci on detallaremos todas las pruebas realizadas, incluyendo aquellas partes de las que se realiz o un an alisis m as exhaustivo y aquellas en las que las pruebas se realizaron de forma m as laxa, explicando el porqu e de cada decisi on.

5.3.1.

Pruebas de hardware

En primer lugar se probaron todos los sensores del bus I2C por separado, para comprobar que aisladamente funcionaran de forma correcta. Una vez probado que todos los sensores y acondicionadores funcionaban de la forma esperada, se montaron en el robot y se conectaron al bus I2C. Cabe destacar que, pese a que la conexi on de los sensores al bus es un tema trivial, el conexionado fue el problema de hardware m as habitual encontrado durante la realizaci on de las pruebas. Cuando se trabaja con una malla de sensores grande y todos ellos deben disponerse en un espacio

76

CAP ITULO 5. IMPLEMENTACION

reducido, acaban encontr andose problemas de malas conexiones, cables partidos, sensores intercambiados, etc. que acaban dicultando el funcionamiento de todo el sistema. Por ello, una de las pruebas m as importantes y cr ticas del sistema fue, pese a que no parezca importante, la del conexionado correcto de todos los sensores. Una vez conectados todos los sensores se procedi o a las pruebas de integraci on en el bus I2C. Se cre o un peque no programa de prueba que encuestara el bus completo para comprobar que, efectivamente, pudieran llevarse a cabo las medidas en el tiempo adecuado y que todos los sensores respondieran adecuadamente. Exceptuando algunos errores aleatorios en forma de respuestas err oneas de la br ujula, y los fallos en la comunicaci on con el aceler ometro de tres ejes, el resto de sensores no presentaron ning un problema en la integraci on en el bus. El tiempo de encuesta es sucientemente peque no e inferior al calculado (inferior a 250ms) por lo que es posible realizar 4 encuestas por segundo en el bus I2C. En cuanto a los valores dados por los sensores del bus, se detectaron problemas de falta de repetibilidad entre sensores de un mismo tipo. Es decir, la caracterizaci on de sensores del mismo tipo, variaba en funci on de su posici on en el robot. Para el correcto funcionamiento del sistema completo, se denieron rangos de cercan a y lejan a para los sensores de proximidad IR, de forma que al detectar por umbrales se minimizaran este tipo de errores. En cuanto a los USR fue necesario tocar en Analog Gain de todos los USR para conseguir que las detecciones de objetos fueran lo m as reales posibles y para que el comportamiento de todos los sensores fuera semejante. Las reexiones de los USR con el suelo, hecho que podr a haber sido problem atico, se solucion o tambi en de esta forma. En cuanto a los sensores piroel ectricos, estos fueron los que mostraron un peor comportamiento, dando muchos falsos positivos en el ambiente del Laboratorio de Sistemas Integrados (lugar de las pruebas) a ra z posiblemente de la multitud de fuentes de radiaci on af n a estos sensores. Este hecho dicultar a much simo la capacidad del robot de seguir personas, dado que no sabr a discernir de qu e direcci on proviene la radiaci on de calor. Finalmente, las pruebas hardware demostraron el funcionamiento de la red de sensores que veremos a continuaci on Sensores plenamente funcionales: infrarrojos, ultrasonidos, sensores de bater a y corriente. Sensores que presentan malas detecciones espor adicas: sensores piroel ectricos (falsos positivos), br ujula (errores espor adicos aleatorios) y bumpers (falsos negativos). Sensores no funcionales o cuyo acondicionamiento no lleg o a implementarse completamente: inclin ometro (aceler ometro de tres ejes) y encoders. En segundo lugar, se prob o el sistema de regulaci on y alimentaci on del sistema. El robot fue capaz de funcionar correctamente con las bater as originales conectadas en serie a la etapa de regulaci on dise nada. El regulador de 5Vcc y 3.3Vcc es capaz de alimentar el SoM, la Wi USB, la red de sensores y de dar suciente corriente a los motores como para mover el robot sin problemas. La etapa de alimentaci on de los motores, tambi en funcionaba correctamente. La falta de un sensor eciente

5.3. PRUEBAS

77

de medida de la corriente consumida, nos impidi o realizar pruebas de consumo exhaustivas en el robot, as como medir el consumo en cont nua del sistema completo. Si bien, las medidas aisladas, teniendo en cuenta un consumo bajo por parte del SoM y con el peso m nimo en el robot (motores consumiendo el m nimo), el consumo medio (sin tener en cuenta picos de corriente) no pasaba de los 500mA, lo que dar a una autonom a te orica a las bater as de 7 horas. Esta autonom a te orica ser a sensiblemente inferior a la real que, en condiciones de funcionamiento continuo (motores continuamente en movimienot), se prevee que no superar a las 3 horas.

5.3.2.

Pruebas de software

El primer punto cr tico del funcinamiento software del sistema era la interacci on del SoM con el mundo exterior. En primer lugar se trabaj o con el SoM conectado directamente a su kit de desarrollo, con el n de familiarizarse con la plataforma. De esta forma se realizaron las primeras pruebas y se comprob o el correcto funcionamiento del bus I2C (con el que se interactu o mediante comandos smbus), y de los GPIOs. Tambi en se compil o y a nadi o el m odulo WiFi para el kernel del SoM, permitiendo la comunicaci on inhal ambrica con el entorno por SSH. En segundo lugar, se realizaron pruebas para sincronizar todos los threads de procesos y el sistema completo con la lectura del bus I2C. Las lecturas al bus se simularon, con el n de aislar las pruebas entre ellas. Uno de los grandes inconvenientes en el trabajo con pthreads es la depuraci on de la sincronizaci on entre procesos, por eso se realizaron pruebas exhaustivas de cara a evitar posibles errores en esta parte que, una vez se complicara el funcionamiento del sistema, pudieran generarnos comportamientos inesperados dif ciles de debugar. Una vez probada la sincronizaci on, se programaron los diversos comportamientos del robot, analizando la respuesta de cada uno en funci on de un array de entradas simuladas de los sensores, con el n de estudiar si la respuesta parec a correcta.

5.3.3.

Pruebas de conjunto del sistema

Una vez probado el hardware y el software por separado, se prob o el sistema completo. Para ello, se dej o al robot en el entorno del Laboratorio de Sistemas Integrados en modo Random, lo que implicaba un comportamiento predenido de seguimiento de paredes (avanzar al frente y a la derecha), variando la ruta cuando encontrara obst aculos. Las primeras pruebas indicaron que la sincronizaci on entre procesos era correcta, que el robot reaccionaba al entorno y variaba la ruta en funci on de los cambios, sin sufrir retardos mayores de los esperados. El n umero de encuestas al bus por segundo era correcto y el robot respond a a tiempo real. Sin embargo, parec a que el robot apuraba demasiado las distancias, es decir, pese a detectar objetos correctamente, se acercaba demasiado a ellos antes de girar, lo que provocaba choques en ocasiones. Adem as se comprob o tambi en que, pese al elevado n umero de bumpers, el robot pod a chocar sin que ninguno de sus bumpers fuera pulsado, de forma que la u nica forma de saber que el robot hab a chocado era viendo que la corriente en motores aumentaba y los encoders no indicaban movimiento cuando deber a haberlo. Esto llev o a pensar que tal

78

CAP ITULO 5. IMPLEMENTACION

vez deber a haberse pensado con colocar toda una estructura de protecci on de pl astico alrededor del robot (como en algunos robots comerciales) para mejorar la detecci on de choques. Con el n de mejorar el comportamiento reactivo del robot, se retocaron ligeramente los diferentes comportamientos y se aument o el rango en el cual daba la detecci on de un objeto por positiva, con el n de que el robot chocara menos. Nos encontramos entonces con que exist an ciertos comportamientos cr ticos. En concreto, el comportamiento Avoid (esquivar) resultaba cr tico para el funcionamiento del robot. Este comportamiento permit a hacer el robot muy sensible a su entorno (muy reactivo) o bien m as proactivo, permiti endole seguir sus direcciones predenidas pese a que hubiera objetos demasiado cerca. Tambi en, durante la navegaci on del robot se pod a comprobar que existen ciertos objetos que, por la estructura f sica del mismo y la colocaci on de los sensores, resultaban invisibles o indetectables en una primera iteraci on. Es el caso de objetos met alicos (patas de mesas, etc.) que o bien no tienen un grosor apreciable y por tanto no caen en el rango de ning un sensor, o bien se encuentran a una altura que no es detectada. Este problema s olo podr a solucionarse mediante la colocaci on de un array todav a m as amplio de sensores. Por u ltimo, se prob o el demostrador para la comunicaci on con el ambiente inteligente. Las pruebas se centraron en la capacidad del robot de comunicar su estado y su modo de funcionamiento al ambiente, as como la posibilidad del usuario de cambiar estos par ametros. Estas funcionalidades fueron probadas con resultados satisfactorios.

Cap tulo 6 Resultados

En este cap tulo veremos los resultados obtenidos a ra z de la realizaci on de esta primera parte del proyecto. Tal y como vimos en la introducci on, nuestro punto de partida era el robot X80 de Dr. Robot Inc. con las mejoras realizadas al mismo en el Proyecto Fin de Carrera de Luis Moreno. Nuestro objetivo para esta primera parte era la de convertir el robot inicial en un agente reactivo con una red de sensores completa, que le permitiera tener una autonom a suciente como para desenvolverse en un entorno inteligente, comunic andose con el mismo. El resultado es el prototipo AmiBot, cuya implementaci on nal podemos ver en la gura 6.1. El funcionamiento del mismo es el siguiente: en cuanto el robot es encendido, su placa base se inicializa y el SoM se conecta, si es posible, al entorno inteligente. En ese momento el robot inicia un comportamiento predenido por el usuario (comportamiento aleatorio, seguir personas o esperar ordenes). El robot realizar a encuestas c clicas del bus I2C, leyendo los datos de todos sus sensores. En funci on de esos datos, los comportamientos indicar an qu e direcci on debe seguir el robot. El arbitro suprimir a las decisiones de esos comportamientos o bien modicar a la decisi on predenida en funci on de la jerarqu a de decisiones, tomar a una decisi on y la enviar a a los motores. Los motores mover an el robot en la direcci on decidada. Este ciclo se repetir a indenidamente mientras el robot est e en funcionamiento. El robot se mover a por el entorno, intentando seguir su ordenes predenidas pero esquivando los obst aculos que encuentre, hasta que reciba una orden distinta. El usuario podr a variar las ordenes que sigue el robot a trav es del interfaz gr aco del servidor AmiServer, que podr a instalarse en cualquier ordenador que disponga de una m aquina virtual de Java y una conexi on de red. Pese a los problemas y posibles mejoras que presenta el robot, el funcionamiento general es satisfactorio y cumple con los objetivos marcados para esta primera parte del proyecto. AmiBot es capaz de moverse de forma aut onoma por su entorno, transmitiendo su estado al ambiente inteligente, y el ambiente es capaz de interactuar con el robot, cambiando algunos de sus par ametros. Si el ambiente no respondiera o no enviara informaci on al robot, este no se ver a afectado, sino que continuar a navegando por el entorno en el u ltimo modo de funcionamiento que hubiera impuesto el ambiente. En u ltima instancia, si el robot no supiera c omo reaccionar o se quedara sin bater a, simplemente se detendr a y no har a nada. El 79

80

CAP ITULO 6. RESULTADOS

Figura 6.1: Prototipo nal del robot AmiBot Fuente propia sistema completo, en las condiciones probadas, tiene un consumo en continua inferior a los 500mA (sin contar con los picos de consumo que puedan provocar los motores y la placa), lo que le da una autonom a aproximada de unas 3 horas de funcionamiento con las bater as actuales. La velocidad del robot es inferior a la velocidad m axima del robot original (1m/s), si bien es adecuada para desplazarse por el entorno y adem as le permite reaccionar con mayor ecacia ante los cambios s ubitos del entorno. Por otra parte existen toda una serie de inconvenientes a nivel hardware que dicultan el correcto funcionamiento del robot. Entre ellos cabe destacar que no se dispuso del tiempo suciente para acabar de implementar el sistema de acondicionamiento de los encoders. Este tema se consider o menos prioritario, dado que en una primera iteraci on s olo con saber si el robot se mov a o no ser a suciente, de forma que se pospuso su implementaci on y, nalmente, no se dispuso de tiempo para obtener el prototipo del PCB funcional que calculara el movimiento producido en cada una de las ruedas. En cuanto a los piroel ectricos, pese a que el sistema de acondicionamiento funcionaba perfectamente, en ambientes muy poblados (como es el laboratorio) los sensores ten an tanta sensibilidad que eran incapaces de discenir en qu e direcci on se hallaba la persona m as cercana, dado que todos ellos ten an detecciones. Este problema podr a solventarse mediante el uso del reconocimiento de usuarios con la c amara. En cuanto los piroel ectricos detectaran un ambiente muy poblado, podr an utilizar la c amara para realizar el reconocimiento de usuarios del entorno. Esto, sin embargo, escapa a los objetivos de dise no para esta primera parte. Los bumpers no presentaban un buen comportamiento frente a algunos obst aculos. Pese al elevado n umero de los mismos y su correcto funcionamiento, no siempre detectaban los choques. Para mejorar su funcionamiento ser a necesario a nadir una protecci on envolvente al robot, de forma que si la protecci on de pl astico chocara, la exi on de la misma activara algunos de los bumpers. Esta mejora no pudo llevarse a cabo por falta de tiempo. En cuanto al software, el comportamiento del robot es puramente reactivo, y se demuestra que la arquitectura de subsubci on, unida a las acciones predenidas para cada modo de funcionamiento, presenta muy buenos resultados. Hay que decir, sin embargo, que el funcionamiento no es 100 % able. Existen puntos en que el comportamiento reactivo provoca que el robot realice bucles de acciones

81 o no sepa salir de algunas situaciones. Este es un problema habitual en los robots puramente reactivos: al carecer de memoria de acciones y simplemente reaccionar ante el ambiente, sin cadenas de acciones programadas, pueden realizar una serie de movimientos adelante-atr as que no los llevan a ning un lugar, o quedarse encerrados entre diversos obst aculos sin saber c omo huir de ellos. En otras ocasiones, parece que las decisiones tomadas por los comportamientos no son optimas y que, a simple vista, el robot podr a haber tomado acciones m as favorables en determinados momentos. El comportamiento Avoid se perl o como un comportamiento cr tico para el funcionamiento global del robot. Peque nos cambios en este comportamiento provocaban que el robot esquivara mejor o peor los obst aculos del terreno y lo hac an m as o menos reactivo. Acabar de depurar estos comportamientos implicar a la realizaci on de una bater a de pruebas m as exhaustivas que no se han podido llevar a cabo por una raz on de tiempo. Es de esperar, por tanto, que en ocasiones el robot no sepa huir de algunos obst aculos y haga falta una interacci on por parte del usuario para guiarle. En cualquier caso, el funcionamiento es el esperado para el prototipo, dado que cumple con todos los objetivos marcados para esta primera parte del proyecto.

82

CAP ITULO 6. RESULTADOS

Cap tulo 7 Conclusiones y l neas futuras

En este cap tulo se presentan las conclusiones de esta primera parte del proyecto, as como las limitaciones del prototipo implementado y las mejoras y posibles l neas futuras que podr an partir de este proyecto.

7.1.

Conclusiones

En primer lugar retomaremos los objetivos expuestos en la introducci on del proyecto, con el n de poder comprobar que se han alcanzado los objetivos jados. Soporte hardware y software : El an alisis del software y hardware realizado en los primeros apartados nos llev o a optar por una red de sensores sucientemente completa como para permitir al robot la redundancia suciente para localizar objetos en su entorno, con un margen de error asumible por el sistema. Del mismo modo, el an alisis del SoM a utilizar y sus capacidades, ha permitido poder montar todo un sistema software bastante ligero y que no limita en tiempo de reacci on al robot, permiti endole un funcionamiento adecuado a tiempo real. El an alisis del soporte y la elecci on de un soporte tanto hardware como software adecuado permiti o obtener un prototipo funcional del robot m ovil. Tomar como punto de partida el robot X80 simplic o en gran medida muchas de las elecciones, dado que se ten a la experiencia de utilizaci on de la anterior plataforma y se pod an solventar algunos de sus problemas. La red de sensores : La red de sensores del robot fue dise nada de forma que la redundancia le permitiera ser m as robusta a falsos negativos y falsos positivos en el entorno. Pese a que casi se dobl o el tama no de la red de sensores, siguen existiendo puntos oscuros en los que la detecci on del robot es algo pobre. Ser a positivo incrementar todav a m as el tama no de la red, no s olo para que cada sensor tenga que cubrir un ancho de haz m as estrecho, sino para cubrir diferentes alturas en la detecci on de objetos. Optar por una encuesta por bus I2C 83

84

CAP ITULO 7. CONCLUSIONES Y L INEAS FUTURAS simplic o en gran medida la creaci on de esta red, sobretodo mediante la inclusi on de los ADC y los expansores I2C, que permit an encuestar todos los bumpers con una sola lectura del bus. Tal y como se ha expuesto en los resultados, el funcionamiento de algunos sensores es mejorable, sobretodo el de los bumpers y encoders, pese a que la red completa es funcional.

El comportamiento reactivo : El comportamiento reactivo en combinaci on con la arquitectura de subsunci on y las decisiones predenidas ha dado un muy buen resultado en la interacci on del robot con el entorno, permiti endole reaccionar r apidamente. Hay que destacar que existe un compromiso complicado entre la capacidad del robot de alcanzar sus objetivos (es decir, seguir las ordenes dadas por el ambiente), y esquivar de forma eciente y con un m nimo de errores los objetos presentes en el entorno. En general, si el robot tiende a esquivar todos los objetos en cuanto los detecta, modicando de forma cont nua la ruta para no chocar contra nada, es complicado que pueda llegar de forma r apida a su destino. Por el contrario, si queremos que alcance su destino de forma r apida, existe el riesgo de que choque contra algunos objetos del entorno. El comportamiento que afecta de forma cr tica a este compromiso es el de Avoid (esquivar) encargado de sortear obst aculos antes de aproximarse excesivamente a ellos. La comunicaci on WiFi con el ambiente : AmiBot es capaz de comunicarse mediante una WiFi con chip Ralink conectada a uno de los dos puertos USB del SoM. La comunicaci on WiFi permite al robot conectarse por medio de un par de sockets TCP al demostrador del servidor AmiServer, de forma que los usuarios puedan, de forma intuitiva variar las ordenes enviadas al robot. De esta forma, el objetivo de comunicar al robot m ovil con el entorno inteligente queda cumplido. Funcionamiento del robot m ovil : La integraci on del software y el hardware permite al robot m ovil desplazarse de forma aut onoma por el entorno del Laboratorio de Sistemas Integrados. El robot es capaz de realizar la encuesta del bus I2C, sus comportamientos de tomar las deciciones correspondientes, el arbitro de procesarlas y los actuadores de desplazar el robot a tiempo real. Debe tenerse en cuenta que, pese a que se dispone de tiempo suciente para realizar todas estas acciones en tiempo real, hay que decir que la sincronizaci on del sistema es otro de los puntos cr ticos del proyecto. Pese a que haya tiempo de sobras para realizar las tareas, todas ellas deben estar perfectamente sincronizadas, para evitar errores del tipo de reaccionar a lecturas de los sensores antiguas o desfasadas. La terna lectura del bus - toma de decisi on - ejecuci on debe realizarse siempre sincronizada. Tal y como podemos comprobar, los objetivos planteados al inicio de este proyecto han sido cumplidos. Se han dise nado toda la arquitectura hardware, implementado con exito la placa base del prototipo, as como el acondicionamiento de la mayor a de los sensores del bus I2C (pirol ectricos, ADCs, expandores I2C, conversores de niveles del bus I2C). Tambi en se ha realizado la placa de comunicaci on con los motores, que permite controlarlos de forma adecuada. El comportamiento

7.2. LIMITACIONES DE AMIBOT

85

reactivo del robot funciona correctamente y AmiBot se comunica mediante su m odulo WiFi por USB con el ambiente inteligente. De esta forma, el robot es capaz de recibir ordenes de funcionamiento y enviar informaci on de su estado al ambiente inteligente. Existen una serie de puntos cr ticos, ya mencionados anteriormente, cuya mejora implicar a una gran mejora del funcionamiento del sistema en su conjunto. Como conclusi on global, podr amos decir que el funcionamiento del prototipo se debe en gran parte a haber tomado de forma correcta algunas de las decisiones de dise no cr ticas (comportamiento reactivo, arquitectura de subsunci on, encuesta por I2C, etc.) m as que a la implementaci on real del sistema. El fallo, o funcionamiento no del todo correcto, de algunos de los sensores de la red queda enmascarado por el dise no de una arquitectura robusta, que permite que el robot siga funcionando de forma adecuada.

7.2.

Limitaciones de AmiBot

El prototipo de AmiBot implementado tiene una serie de limitaciones que expondremos a continuaci on: Limitaciones estructurales de AmiBot y poca sosticaci on del sistema: el conexionado de la red de sensores ha sido realizada completamente a mano. Algunos sensores, como los bumpers, tambi en han sido fruto de un montaje realizado a mano, con el n de obtener una red de sensores sencilla y barata. Esto implica una limitaci on de funcionamiento basada en la poca sosticaci on de los componentes. En algunos de los elementos de la red, como es el caso de los bumpers, habr a funcionado mejor la utilizaci on de una mampara de pl astico que rodeara al robot y que, al chocar, por exi on disparara uno de los bumpers m as cercanos. Realizar este sistema a mano, sin embargo, tambi en tiene sus limitaciones. La estructura de AmiBot no estaba preparada para incorporar un array de sensores tan grande, de forma que algunos de ellos tuvieron que colocarse en lugares poco pr acticos. Si se hubiera tenido que colocar, adem as, una mampara de pl astico, se habr a reducido todav a m as el espacio para la colocaci on de sensores. Limitaciones de la red de sensores: pese a que este tema se estudiar a m as a fondo en la segunda parte de este proyecto, el bajo coste de algunos de los sensores (como son los infrarrojos) limita su respuesta. El comportamiento de los sensores de proximidad del robot es poco repetible, es decir, se obtienen medidas muy dispares del mismo objeto en funci on del sensor que lo detecte. Esto supondr a un problema de cara a la segunda parte del proyecto, donde ser a necesaria una caracterizaci on m as exacta de los sensores del bus. Limitaciones asociadas al comportamiento reactivo: el uso de un comportamiento reactivo implica de forma inherente toda una serie de desventajas que podemos apreciar en el funcionamiento de AmiBot. Entre ellas cabe destacar la toma de decisiones que desde un punto de vista externo pueden

86

CAP ITULO 7. CONCLUSIONES Y L INEAS FUTURAS resultar absurdas, como son la repeteci on en bucle de movimientos adelanteatr as, debido a que el robot no es capaz de esquivar de forma eciente un objeto, o bien es capaz de esquivarlo pero acaba volviendo siempre a el. No es posible eliminar este tipo de comportamientos de forma eciente en la capa reactiva del robot, pero s ser a posible eliminarlos de cara a la segunda parte de este PFC, cuando podamos elaborar un mapa del entorno y marcar ciertas zonas como obst aculos del terreno que no deber an ser rebasados. Limitaciones por la alimentaci on del robot: en la actualidad, AmiBot est a alimentado por las bater as originales del robot X80. Esto implica, por una parte, que la duraci on de las mismas no ser a excesiva, y por otra, que estamos limitados a alimentar tanto los motores como la placa con el mismo pack de bater a cuando, quiz a en un futuro, interesar a separar ambas alimentaciones por razones de ruido. En cualquier caso, el consumo del robot lleva a que la duraci on de las bater as sea bastante escasa, problema que se agravar a de cara a la segunda parte de este PFC.

7.3.

Mejoras y l neas futuras

Existen toda una serie de mejoras y l neas futuras que podr an llevarse a cabo con el n de mejorar el prototipo implementado de AmiBot, y que se exponen a continuaci on: La red de sensores : Las mejoras que podr an realizarse en la red de sensores son las siguientes: Deber a a nadirse la ya mencionada pantalla de protecci on para los bumpers de AmiBot, con el n de detectar cualquier choque producido en cualquier parte del robot. Esto implicar a el reposicionamiento de algunos de los sensores, y posiblemente implicar a retocar un poco la parte estructural del robot, para poder jar estos nuevos sensores. Podr a estudiarse la posibilidad de modicar de forma sustancial la estructura, para poder alojar un mayor n umero de sensores en mejores posiciones. Faltar a por implementar y montar el circuito de acondicionamiento de los encoders, realizando pruebas para comprobar la precisi on de los mismos y si el dise no de realizar lecturas entre encuestas del bus I2C funciona correctamente. No se lleg o a acondicionar adecuadamente el inclin ometro (acel ometro de tres ejes). Ser a conveniente acondicionarlo adecuadamente para integrarlo al bus I2C,y ver si su funcionamiento es correcto. Falta por a nadir al bus I2C los sensores de detecci on de ca das, tanto en la parte delantera como en la parte trasera del robot. Pese a que no es complicado a nadir estos sensores (bastar a con a nadir sensores de proximidad IR de rango menor de 20cm y conectarlos a los ADC, no se lleg o a implementar en este proyecto. Tambi en deber an a nadirse los

7.3. MEJORAS Y L INEAS FUTURAS

87

sensores de humedad y temperatura, que no han llegado a integrar en el bus. Deber a dise narse y fabricarse el PCB conversor de bus I2C de 3.3Vcc a 5Vcc. Por razones de tiempo, en el prototipo del robot se reaprovech o un PCB ya existente. Sin embargo, ser a interesante no s olo realizar el conversor, sino una expansi on de puertos I2C, con el n de liberar algunos puertos de la placa base y poder a nadir m as sensores al bus. El comportamiento reactivo : Ser a conveniente revisar de forma m as exhaustiva el comportamiento reactivo, con el n de detectar posibles fallos. Adem as, parece conveniente estudiar la criticidad del comportamiento Avoid, para ver si podr a dise narse de un modo m as transparente al resto de funcionamiento del sistema, de forma que dejara de ser tan cr tico. Una l nea futura muy interesante ser a poder generar de forma autom atica parte del c odigo del comportamiento reactivo. De esta forma, cada vez que quisi eramos a nadir un sensor m as al bus y, por tanto, modicar una de las funcionalidades de los comportamientos, bastar a con introducir una nueva regla en el generador de comportamientos reactivos. Este a nadir a el sensor y generar a el nuevo comportamiento con las reglas predenidas. De esta forma generar amos un sistema modular y escalable adaptado a las necesidades del robot. Medida de consumos y alimentaci on del robot : Una l nea de futuro importante en este proyecto ser a el dise no e implementaci on de un sistema de medici on de consumo del robot, que nos permitiera ver la corriente instant anea y media del robot, con detalles sobre los picos de consumo tanto del SoM como de los motores. En vista de los resultados de este an alisis de consumo, deber a redise narse de cero todo el sistema de alimentaci on del prototipo. Ser a interesante estudiar la necesidad de una alimentaci on separada para los motores y el SoM, con el n de aislar el SoM del ruido de alta frecuencia y en previsi on de las necesidades de consumo de la placa cuando funcione a pleno rendimiento y se utilicen los servomotores y la c amara CMOS. Tambi en se hace necesario el dise no de un puesto de recarga de bater a, que permita recargar las bater as sin dejar de alimentar el robot. Adem as, el robot deber a ser capaz de llegar de forma aut onoma al punto de recarga, as que ser a necesario un sistema de alineamiento con el puesto de recarga, para que el robot no necesitara intereacci on con el exterior para recargarse.

88

CAP ITULO 7. CONCLUSIONES Y L INEAS FUTURAS

Parte III

S ntesis de resultados

173

Cap tulo 15 S ntesis de resultados

Dado que este proyecto nal de carrera ha sido dividido en dos partes diferenciadas, a continuaci on incluimos un cap tulo dedicado a la s ntesis global de los resultados de ambas partes. De esta forma podremos ver que, pese a que se hayan realizado dos proyectos distintos con contenidos diferentes, en el fondo forman parte de un proyecto global m as amplio, que acaba abarcando diferentes areas de conocimiento, cada una con sus puntos fuertes y d ebiles, y sus areas m as y menos complicadas. A continuaci on veremos las conclusiones del funcionamiento del prototipo del robot en general, dedicaremos una secci on a la experiencia personal en la realizaci on de este proyecto y tambi en haremos una breve rese na de las limitaciones, mejoras y l neas futuras del proyecto global.

15.1.

Conclusiones de funcionamiento

Para poder obtener unas buenas conclusiones sobre el funcionamiento general del prototipo implementado, debemos en primer lugar tomar en consideraci on la diferenciaci on clara entre las dos partes de este PFC. La primera parte de este PFC corresponde a una tem atica muy centrada en la electr onica a nivel hardware, con un contenido muy pr actico. La propia estructura de la memoria ya nos deja ver que el trabajo se dividi o en una parte de an alisis bastante r apida sobre las opciones que se barajaban; y un dise no m as laborioso pero extremedamente orientado a implementaci on. Es por ello que es f acil ver que la primera parte del PFC estaba extremadamente ligada a la implementaci on. Pese a que no se trataba de uno de los objetivos del proyecto en s mismo, si se ambicionaba el conseguir una implementaci on funcional del prototipo (o al menos de sus partes m as cr ticas) con el n de contar con el en la segunda parte como plataforma de trabajo. La segunda parte de este PFC, en cambio, requiere de un an alisis y dise no mucho m as amplios y te oricos, y una parte de implementaci on que, pese a ser muy interesante (sobretodo en la localizaci on y mapeado simult aneo) queda en segundo plano con respecto al dise no. Este adem as era un proyecto muy amplio, que realizaba 175

176

CAP ITULO 15. S INTESIS DE RESULTADOS

el dise no casi completo de una arquitectura, lo que obligaba a invertir m as tiempo en abstracci on que en practicidad. Este proyecto cost o de una etapa mucho m as amplia de documentaci on y an alisis, dado que tambi en se part a de un menor conocimiento de base sobre el tema. El hecho de tener una etapa de dise no mucho m as abstracta implicaba una mayor inversi on en tiempo, lo que inevitablemente ha obligado a recortar el tiempo dedicado a la implementaci on. Por estas razones a lo largo de toda la memoria se ha podido ver la corriente claramente pr actica de la primera parte y la claramente abstracta de la segunda. En cualquier caso, estas dos aproximaciones tan distintas han llegado a un buen equilibrio en el prototipo. Parte de los esfuerzos de la segunda parte se dedicaron a convertir las abstracciones en elementos pr acticos. Eso he hecho que, en la nalizaci on de este proyecto nal de carrera, se disponga de un prototipo del robot que no s olo es capaz de desplazarse por el ambiente inteligente de forma absolutamente reactiva, sino que adem as disponga de una capa deliberativa por encima que le permita trazar mapas y lo vuelva m as inteligente de forma transparente al usuario. La idea es que el usuario no sepa capaz de distinguir, mientras el robot act ua, si realmente est a utilizando la capa deliberativa o no, y que s olo sea consciente de ello porque toma acciones m as inteligentes. En cualquier caso, como conclusi on global del sistema, podr amos decir que el funcionamiento del robot es el adecuado para lo que se pretend a en este PFC. Desde un primer momento se era consciente de que no se podr an llevar a cabo pruebas exhaustivas sobre el funcionamiento del sistema, pero se quer a dar una primera aproximaci on al tema y ver c omo funcionaba todo y si era realmente posible disponer de un robot de bajo coste y consumo razonable que pudiera ser de utilidad en el ambiente inteligente. En cuanto a estas cuestiones, parece que el prototipo s cumple con las especicaciones para las cuales fue dise nado.

15.2.

Experiencia Personal

En general, todo proyecto nal de carrera aporta una gran experiencia personal a su autor. La realizaci on de dos, por tanto, aporta una experiencia a un mayor. En primer lugar, y pese a que quiz a es algo obvio, hay que destacar que una de las mayores experiencias que uno se lleva de la realizaci on del proyecto es el aprendizaje. Haber pasado un a no en el Laboratorio de Sistemas Integrados, viendo la forma de trabajar de los compa neros del grupo y aprendiendo de ellos, es sin duda el factor que aporta una mayor y mejor experiencia. Sin duda, y aunque s olo fuera por este hecho, val a la pena realizar el proyecto en este grupo. La experiencia no s olo se centra en el aprendizaje sobre el area de trabajo en s (en este caso la electr onica), sino que tambi en ofrece la oportunidad de aprender c omo es la forma de trabajar de un grupo que realiza proyectos de investigaci on y proyectos de empresa. En segundo lugar, la gesti on del tiempo en un proyecto acotado (en este caso a poco m as de un a no) y cuyos objetivos de implementaci on (que no de dise no) acaban siendo jados sobre la marcha, al nal acaba siendo el mayor problema y por tanto

15.3. LIMITACIONES Y MEJORAS. L INEAS FUTURAS.

177

el hecho a partir del cual m as se aprende. Al nal se acaba aprendiendo, aunque sea a base de errores, la importancia de estimar el tiempo de dedicaci on a las diversas tareas de que se compone el proyecto. Tambi en, de la misma forma y si se quieren alcanzar el mayor n umero de objetivos posible, acaba siendo relevante la capacidad para no quedarse encallado en alg un error o alg un dise no que no acaba de funcionar. Sobretodo en la primera parte de este PFC, muy centrado en implementaci on, se corr a el riesgo de perder mucho tiempo en peque nos m odulos o peque nas placas de acondicionamiento que presentaran errores y en las que, a lo mejor, la opci on m as viable era redise nar el m odulo por completo, antes que intentar conseguir reducir sus funcionalidades. En denitiva, podemos decir que la experiencia personal en la realizaci on de este PFC ha sido extremadamente positiva.

15.3.

Limitaciones y mejoras. L neas futuras.

Pese a que en cada una de las partes por separado de este PFC se han expresado las mejoras y l neas futuras a implementar, se ha cre do conveniente a nadir este apartado, para poder desglosar brevemente las l neas futuras que pod an llevarse a cabo a partir del conjunto de ambos PFCs y de sus resultados. Estas l neas futuras, adem as, son ideas que necesitar an un grueso de trabajo mayor, la viabilidad de las cuales, habr a que estudiar: Cambio del demostrador por un servidor real del entorno inteligente : Pese a que el demostrador AmiServer es suciente como para poder realizar la interacci on con un usuario del entorno, lo adecuado ser a que AmiServer fuera un servidor dedicado al robot para su interacci on con el ambiente inteligente, encargado de recoger la informaci on del ambiente y de los usuarios por s mismo y generar a partir de ella y en funci on de una serie de par ametros, las ordenes que ha de recibir el robot. De esta forma, cada uno de los usuarios podr a disponer de un cliente de AmiServer en su ordenador (lo que ahora ser a el demostrador) con el cual podr a enviar ordenes al robot. El servidor recibir a esa orden y la llevar a a cabo (o no) en funci on de los par ametros establecidos. El usuario podr a ver en todo momento si es su orden o es otra orden la que se est a llevando a cabo en ese momento. Dise no de los niveles superiores de la capa deliberativa de AmiBot : En este proyecto nal de carrera s olo se ha llegado a implementar la planicaci on de rutas de la capa deliberativa de AmiBot. Sin embargo, existen dos capas de un mayor nivel de abstracci on por encima que no se han llegado siquiera a dise nar o analizar, que son el Planicador de Misiones y la parte de m as alto nivel del Navegador. Una l nea futura ser a la del dise no de estas capas de alto nivel, ya sea en el propio robot o bien como parte del entorno inteligente, pero de forma que las ordenes que el usuario da al sistema pueden tener un nivel de abstracci on elevado. Estandarizaci on del agente reactivo :

178

CAP ITULO 15. S INTESIS DE RESULTADOS Una l nea futura muy interesante ser a la de la estandarizaci on del agente reactivo para su utilizaci on en otras plataformas. Esto se podr a llevar a cabo creando un agente congurable propio que, mediante algunas reglas b asicas predenidas, nos genere el c odigo necesario y est andar como para poderlo ejecutar el diversos robots m oviles. Estos robots compartir an una serie de caracter sticas b asicas y divergir an en otras, de forma que el programa deber a ser sensible a estas divergencias, generando situaciones distintas en funci on del robot. Esto nos permitir a tener una red de robots aut onomos basados en un mismo sistema de bajo coste que les permita realizar acciones distintas dentro del mismo entorno inteligente, permitiendo incluso la cooperaci on entre ellos.

Reconocimiento e interacci on real entre usuario y robot : El campo del reconocimiento de los usuarios del entorno es muy amplio y puede llegar a complicarse tanto como se desee. En primer lugar, podemos extender el sistema para que no s olo se base en un reconocimiento de im agenes realizado en remoto, sino que el reconocimiento de los usuarios lo realice el propio robot. Tambi en podemos pensar en un sistema en que usuario y robot interactuan, y en el que el robot, una vez reconocido al usuario que tiene frente a s , es capaz de aceptar ordenes gestuales, reaccionando ante ellas de la forma predeterminada por el programador, o por el propio entorno de forma congurable.

Bibliograf a
[1] Mobile robot programming toolkit. Technical report, The MRPT Project. Available from: http://babel.isa.uma.es/mrpt/. [2] Smarter control in robotics & automation. Technical report, The Orocos Project. Available from: http://www.orocos.org/. [3] Pic18f2331 datasheet. Technical report, Microchip Technology Inc., 2007. Available from: http://www.microchip.com/stellent/idcplg?IdcService= SS_GET_PAGE&nodeId=1335&dDocName=en010268. [4] Anderson A.S. Sousa Andre M. Santana et al. Localization of a mobile robot based in odometry and natural landmarks using extended kalman lter. Technical report, Federal University of Rio Grande do Norte, Brazil, 2005. [5] Ronald C. Arkin. Behavior-Based Robotics (Intelligent Robotics and Autonomous Agents). The MIT Press, 1998. Available from: http://books. google.com/books?id=mRWT6alZt9oC. [6] Artila. Artila M-501 Evaluation Kit User Guide and specications, September 2007. [7] Fred Boekhorst. Ambient intelligence: the next paradigm for consumer electronic: How it will aect silicon? ISSCC 2002: IEEE International SolidState Circuits Conference., 2002. [8] Alan Schultz Brian Yamauchi and William Adams. Mobile robot exploration and map-building with continuous localization. Technical report, Navy Center for Applied Research in Articial Intelligence. Washinghton DC., 1998. [9] Jos e Neira Carlos Estrada and Juan D. Tard os. Hierarchical slam: Real-time accurate mapping of large enviroments. Technical report, IEEE Transactions on Robotics. Vol 21 num 4, 2005. [10] Dirk Schulz Dirk Hamel and Wolfram Burgard. Map building with mobile robots in populated enviroments. Technical report, University of Freidburg, Department of Computer Science. [11] Dirk Schulz Dirk H ahnel and Wolfram Burgard. Map building with mobile robots in populated enviroments. Technical report, University of Freiburg, Department of Computer Science, Germany, 2002. 179

180

BIBLIOGRAF IA

[12] An bal Ollero Federico Cuesta. Intelligent Mobile Robot Navigation. Springer, 2005. Available from: http://books.google.com/books?id=C-ekP4m2y7gC. [13] J.M. Moya Fern andez et al. A scalable security framework for reliable AmI applications based on untrusted sensors. Technical report, Laboratorio de Sistemas Integrados, DIE - Universidad Polit ecnica de Madrid, 2007. [14] Joseph L. Jones Bruce A. Seiger Anita M. Flyyn. Mobile Robots: Inspiration to Implementation. AK Peters, Ltd.; 2 Sub edition, 1998. Available from: http://books.google.com/books?id=KZOJnieBC6cC. [15] SBS Implementers Forum. System Management Bus (SMBUS) Specication, August 2000. [16] Luigi Freda and Giuseppe Oriolo. Frontier-based probabilistic strategies for sensor-based exploration. Technical report, Dipartimento di Informatica e Sistemistica Universit` a di Roma La Sapienza, 2005. [17] Reuven Granot. Course of architectures of autonomous systems. Technical report, Faculty of Mathematics and Computer Science, Haifa University. [18] Huosheng Hu and Dongbing Gu. Reactive behaviours and agent architecture for sony legged robots to play football. International Journal of Industrial Robot, 28(1):4553, January 2001. [19] Dr. Robot Inc. User Manual X-80 Robot. [20] J.M Mart nez J.A. Castellanos et al. Simultaneous map building and localization for mobile robots: A multisensor fusion approach. Technical report, Departamento de Inform atica e Ingenier a de Sistemas, Universidad de Zaragoza, 1998. [21] J.M. Montiel J.A. Castellanos et al. The spmap: A probabilistic framework for simultaneous localization and map building. Technical report, IEEE Transactions on Robotics and Automation, Vol 15 no 5, 1999. [22] Juan D. Tard os Jose A. Castellanos. Mobile Robot Localization and Map Building - A Multisensor Fusion Approach. Springer, 1999. Available from: http://books.google.com/books?id=VHGNU3qAbnoC. [23] Juan D. Tard os Jos e Neira. Data association in stochastic mapping using the joint compatibility test. Technical report, IEEE Transactions on Robotics and Automation, 2001. [24] Juan D. Tard os Jos e Neira and J.A. Castellanos. Linear time vehicle relocation in slam. Technical report, Dept. Inform atica e Ingenier a de Sistemas. Universidad de Zaragoza., 2003. [25] Hamid Aghajan Juan Carlos Augusto, Hideyuki Nakashima. Ambient intelligence and smart environments: A state of the art. Technical report, 2009. [26] MIT Articial Intelligence Laboratory. Humanoid Robotics Group. Available from: http://www.ai.mit.edu/projects/humanoid-robotics-group/.

BIBLIOGRAF IA [27] Jean-Claude Latombe. Robot motion planning. Springer, 1990. [28] Livermore National Laboratory Lawrence Blaise Barney. Programming.

181

POSIX Threads

[29] John Leonard Michael Bosse, Paul Newman et al. An atlas framework for scalable mapping. Technical report, Laboratory of Computer Science and Ocean Engineering. MIT, 2003. [30] Luis Moreno Moreno. Dise no e implementaci on de una plataforma para dom otica y seguridad basada en un robot asistente. Masters thesis, ETSI. Telecomunicaci on, Universidad Polit ecnica de Madrid, 2008. [31] Matthew Self Randall Smith and Peter Cheeseman. A stochastic map for uncertain spatial relationships. Technical report, SRI International, 1995. [32] Luis Moreno Santiago Garrido et al. Path planning for mobile robot navigation using voronoi diagram and fast marching. Technical report, Robotics Lab. Carlos III University. Madrid, Spain. [33] Milos Seda. Roadmap method vs. cell decomposition in motion planning. Technical report, Institute of Automation and Computer Science, 2007. [34] Mark Weiser. The Computer of the 21st Century. 1991. Available from: http://www.ubiq.com/hypertext/weiser/SciAmDraft3.html.

182

BIBLIOGRAF IA

Parte IV

Ap endices

183

ndice A Ape Pliego de condiciones

El proyecto ser a realizado bajo la direcci on t ecnica de un Ingeniero de Telecomunicaci on. La ejecuci on del Proyecto se llevar a a cabo por el procedimiento de contrataci on directa. El Contratista tiene derecho a obtener a su costa copias del Pliego de Condiciones y del Presupuesto. Si el Contratista lo solicita, el Ingeniero deber a autorizar estas copias con su rma, despu es de confrontarlas. Se abonar a al Contratista la obra que realmente se ejecuta, de acuerdo con el Proyecto que sirve de base para la contrata. Todas las modicaciones ordenadas por el Ingeniero-Director de las obras, con arreglo a sus facultades, o autorizadas por la superioridad, ser an realizadas siempre que se ajusten a los conceptos de los Pliegos de Condiciones y su importe no exceda la cifra de los presupuestos aprobados. El Contratista queda obligado a abonar al Ingeniero autor del Proyecto y Director de las obras, as como a sus ayudantes, el importe de sus respectivos honorarios facultativos por direcci on t ecnica y administraci on, con arreglo a las tarifas vigentes. Tanto en las certicaciones de obras como en la liquidaci on nal se abonar an las obras, realizadas por el Contratista en base a los precios de ejecuci on material que guran en el Presupuesto, por cada unidad de obra. En el caso excepcional de que se ejecute alg un trabajo no consignado en la contrata, siendo admisible a juicio del Ingeniero-Director de las obras, se pondr a en conocimiento del Organo correspondiente, proponiendo a la vez la variaci on de precios estimada por el Ingeniero. Cuando se considere necesario ejecutar obras que no guren en el Presupuesto de la contrata, se evaluar a su importe a los precios asignados a estas u otras obras an alogas. Si el contratista introduce en el Proyecto, con autorizaci on del Ingeniero-Director de la obra, alguna mejora en su elaboraci on, no tendr a derecho sino a lo que le corresponder a si hubiese efectuado la obra estrictamente contratada. El ingeniero redactor del Proyecto se reserva el derecho de percibir cuanto ingreso en concepto de derechos de autor pudiera derivarse de una posterior comercializaci on, reserv andose adem as el derecho de introducir cuantas modicaciones crea conveniente.

185

186

APENDICE A. PLIEGO DE CONDICIONES

ndice B Ape El est andar SMBUS

Toda la informaci on de este apartado ha sido obtenida de [15]. A continuaci on resumiremos las caracter sticas m as relevantes del est andar SMBUS. The System Management Bus (SMBus) is a two-wire interface through which various system component chips can communicate with each other and with the rest of the system. It is based on the principles of operation of I2C*. SMBus provides a control bus for system and power management related tasks. A system may use SMBus to pass messages to and from devices instead of tripping individual control lines. Removing the individual control lines reduces pin count. Accepting messages ensures future expandability. With System Management Bus, a device can provide manufacturer information, tell the system what its model/part number is, save its state for a suspend event, report dierent types of errors, accept control parameters, and return its status. El System Management Bus (SMBus) es una interfaz de dos hilos a trav es de la cual varios chips de un sistema se pueden comunicar entre ellos y con el sistema. SMBus es un derivado de I2C, y pueden utilizarse los protocolos indistintamente en la mayor a de los casos, sin embargo existen una serie de diferencias entre ellos: Las especicaciones I2C y SMBus denen diferentes niveles de las se nales de entrada y salida para considerarlas como 0 o 1 l ogicos. SMBus est a dise nado para que su nivel bajo tenga consumos muy bajos en su versi on low-power, mientras que I2C no. La corriente m axima de leakage para los dispositivos conectados al bus tambi en var a. SMBus no especica una capacidad m axima en el bus, mientras que I2C s lo hace. El est andar SMBUS dispone de toda una serie de protocolos est andar para la comunicaci on con los dispositivos. A continuaci on listaremos los diversos protocolos B.1 que se han utilizado en este proyecto nal de carrera. 187

188

APENDICE B. EL ESTANDAR SMBUS

Figura B.1: Diagrama del protocolo de paquetes SMBus Fuente: [15]

Send byte protocol

El m aster env a un byte de datos al esclavo I2C B.2.

Figura B.2: Diagrama del protocolo Send Byte Fuente: [15]

Receive byte protocol

El m aster recibe un byte de datos del esclavo I2C B.3.

Figura B.3: Diagrama del protocolo Receive Byte Fuente: [15]

189

Write byte/word protocol

El m aster env a un comando al esclavo y escribe un byte/word de datos B.4.

Figura B.4: Diagrama del protocolo Write Byte Fuente: [15]

Read byte/word protocol

El m aster env a un comando al esclavo y lee un byte de datos B.5.

Figura B.5: Diagrama del protocolo Read Byte Fuente: [15]

190

APENDICE B. EL ESTANDAR SMBUS

ndice C Ape Lista de materiales

191

192

Red de sensores Fabricante Sharp Devantech USDigital HoneyWell ST ADCs con interfaz I2C (1 PCB) Fabricante Texas Instruments Multicomp Kemet Tyco Tyco Expansores I2C (1 PCB) Fabricante NXP Modelo PCF8574 Package SOIC16 Distrib Farnell C odigo 1201333 Pvp/Ud 3,72A C 1-826926 1-826926 0805 0805 DIP DIP Farnell Farnell Farnell Farnell ADS7830IPWT TSSOP16 Farnell Modelo Package Distrib C odigo 1180129 9332383 9227806 1580055 1580055 Precio Ud. 2,91A C 0,035A C 0,085A C 0,75A C 0,50A C Modelo GP2Y0A21YK SRF10 E4P HMC6352 LIS302DL Package Distrib Farnell Acroname USDigital Digikey Farnell C odigo 1243869 R241-SRF10 342-1041-1 1435588 Pvp/Ud 9,02A C 46,52A C 18,65A C 18,17A C 10,17A C

Cant. 10 6 2 1 1

Ref -

Descripci on Sensores Infrarrojos Ultrasound Rangers Optical Encoders Br ujula 3 Axis Accelerometer

Cant

Descripci on

1 1 2 1

Ref. PCB ADC-00 ADC-01 R1 C1 P1 P2 I2C

ADC de 8 bit con interfaz I2C Resistor 1k Capacitor 1uF Headers 8x1 Headers 4x1

Cuadro C.1: Lista de materiales para la Red de Sensores, ADC y Expansores I2C Yageo Multicomp 0805 0805 Farnell Farnell 9234055 9332383 0,042A C 0,035A C

APENDICE C. LISTA DE MATERIALES

Cant. 3

Descripci on Expansores I2C 8 bits

10

Resistor 2k2

Ref PCF85740 PCF85741 PCF85742 Rpd1 a Rdp10 Rpu

Resistor 1k

Acondicionamiento sensores piroel ectricos (4 PCBs) Fabricante Murata Fairchild SC ST KEMET Multicomp AVX 0805 0805 Farnell Farnell TS934ID SOIC14 0805 Farnell Farnell 1094398 1650863 1759273 16508 Modelo IRA-E700ST0 MM74HC123AM Package SOIC16 Distrib Farnell Farnell C odigo 1006209 1013961 Pvp/Ud 3,07A C 0,55A C 2,19A C 0,05A C 0,019A C 0,63A C

Cant. 1 1

Ref PIR Mono

1 2

Descripci on Sensor piroel ectrico y lente Multivibrador monoestable dual Quad-Operational Ampliers Capacitor 0.1uF

1 4

Capacitor 47p Capacitor 10uF

2 2 1-826926 Vishay Vishay Vishay Multicomp Multicomp Vishay Tyco

Resistor 1k Resistor 2k2

Multicomp Yageo

0805 0805 0805 0805 0805 0805 0805 0805 DIP

Farnell Farnell Farnell Farnell Farnell Farnell Farnell Farnell Farnell

9332383 9234055 1469856 1469896 1469860 9334335 9332413 1570775 1580055

0,035A C 0,042A C 0,034A C 0,036A C 0,034A C 0,015A C 0,035A C 0,02A C 0,25A C 193

Resistor 10k

1 2

Resistor 22k Resistor 100k

2 2

Resistor 300k Resistor 1M

Cuadro C.2: Lista de materiales para el Acondicionamiento de los sensores Piroel ectricos

2 2

4-OA C1OA2 C2OA3 C2 Cext C1OA3 C1OA1 C1 R1 R6 Rpu1 Rpu2 R1OA1 R1OA3 Rext RA1 RA2 R3 R4 R2OA1 R2OA3 R2 R5 GPIO PW

Resistor 2M2 Headers 2x1

194

Placa base AmiBot (1 PCB) Fabricante National National VISHAY Tyco LUMBERG Tyco Tyco Tyco 1-826926 DIP Farnell 1-826926 DIP Farnell 1580055 1580055 1,5A C 1,75A C Modelo LM2596S-5.0 LM1085IS-3.3/NOPD 30WR04 1776275-2 2410 06 1-826926 Package SMD SMD D-PAK DIP DIP Distrib Farnell Farnell Farnell Farnell Farnell Farnell C odigo 1469195 1469039 1298464 1098611 1308874 1580055 Pvp/Ud 4,76A C 2,29A C 0,89A C 0,50A C 0,61A C 0,35A C

Cant. 1 1 1 1 1 12

Descripci on Regulador 5V 3A Regulador 3.3V 3A Diodo Recticador Schottky Bloque terminal 2 entradas Hembra USB tipo A Headers 4x1 2,54mm

Headers 8x2 2,54mm

Headers 16x1 2,54mm

2 SAMTEC BOURNS SQW-125-01-L-D MF-USMF075 DIP 1210

Sockets 50 way, 2mm

SAMTEC

SQW-125-01-L-D

DIP

Farnell Farnell Farnell

1668196 1668196 1294886

5,90A C 2,95A C 0,69A C

1 3

Sockets 25 way, 2mm Fusibles PPTC reseteables 0,75A LITTLEFUSE Tyco Multicomp AVX FSM6JH 1210L005

Ref REG5 REG3.3 Dshot BAT USB I2C0 a I2C11 GPIO0 GPIO1 VCC3 GND VCC5 CN2 CN3 CN1 Fplaca Fi2C Rusb Fbat1 1210 DIP 0805 0805 Farnell Farnell Farnell 1608237 1555983 1759273 1396165 0,15A C 0,019A C 0,016A C

Cuadro C.3: Lista de materiales para la Placa base de AmiBot(1)

APENDICE C. LISTA DE MATERIALES

1 2 1

RSTBtn C2 C3 Crst

Fusibles PPTC reseteables 0,05A Pulsador Capacitor 47pF Capacitor 100pF

Cant. 4

Descripci on Capacitor 100nF

Fabricante Yageo

Modelo -

Package 0805

Distrib Farnell

C odigo 1362552

Pvp/Ud 0,033A C

Capacitor 10uF

AVX

0805

Farnell

16508

0,63A C

2 EPCOS MURATA KOA Vishay Vishay Multicomp Yageo Vishay 0805 0805 0805 B82477P4 LQM21WN1R SMD 8085 0805 0805 0805 Farnell Farnell Farnell Farnell Farnell Farnell

DIP 1644652 9527850 1400284 1469923 1469856 9332413 9238069 1469846 1,82A C 0,26A C 0,21A C 0,034A C 0,034A C 0,035A C 0,049A C 0,0018A C

2 2 1 1 2

Electrolitic Capacitor 330uF/35V Inductance Power 33uH 3,3A Inductance 1uH Resistor 47 Resistor 4,7k Resistor 10k

Cuadro C.4: Lista de materiales para la Placa base de AmiBot (2)

1 1 3

Ref Ci2c Cplaca Cout3 C12 C11 Cin2 Cout2 Cin1 Cout1 L1 Lreg L2 L3 Rrst2 Rrst1 Rscl Rsda Rvbat2 Rvbat1 R01 R02 R03

Resistor 1M Resistor 3M9 Resistencias 0R

195

196

Acondicionamiento circuito motores Fabricante Allegro SC Microchip Tyco Electronics Tyco Tyco AVX AVX Yageo AVX AVX BOURNS MF-USMF075 1210L005 SRU5028 SMD 1206 0805 0805 0805 0805 0805 1210 LITTLEFUSE Bourns WELWYN Vishay Vishay Vishay Vishay Multicomp Farnell Farnell Farnell Farnell Farnell Farnell Farnell Farnell 1608237 7506582 1506154 1469856 1692535 1469860 1469846 9332413 0,381A C 0,52A C 0,034A C 0,031A C 0,034A C 0,0018A C 0,035A C 1-826926 1-826926 DIP DIP 0805 0805 0805 0805 0805 1210 Farnell Farnell Farnell Farnell Farnell Farnell Farnell Farnell 1580055 1580055 1301785 1395814 1362552 16508 1658064 1294886 0,35A C 0,35A C 0,31A C 0,022A C 0,033A C 0,63A C 2,64A C 0,69A C Modelo A3968SLBTR-T MCP6041T-I/OT 1776275-2 Package SOIC16 SOT-23 Distrib Digikey Farnell Farnell C odigo 620-1141-1-ND 1332129 1098611 Pvp/Ud 1,36A C 0,69A C 0,50A C

Cant. 1 1 2

Descripci on IC Motor Driver Operational Amplier Bloque terminal 2 entradas

1 1 1 1 1 1 1 1

Ref Driver OA1 MOT1 MOT2 GPIO Power Coa Cosc Cmot2 Cmot1 CVcc Fmot

Fbat2

1 2

Headers 4x1 2,54mm Headers 3x1 2,54mm Capacitor 47nF Capacitor 560pF Capacitor 100nF Capacitor 10uF Capacitor 47uF Fusibles PPTC reseteables 0,75A Fusibles PPTC reseteables 0,05A Inductor 15uH 1.1A Resistor 0.5

Cuadro C.5: Lista de materiales para el acondicionamiento de los motores

APENDICE C. LISTA DE MATERIALES

1 1 1 2 1

Lmot Rsens1 Rsens2 R2 Rosc RoaS2 R01 R02 RoaS1

Resistor 10k Resistor 56k Resistor 100k Resistencias 0R Resistor 1M

ndice D Ape Planos

D.1. Red de sensores

A continuaci on encontraremos los esquem aticos y huellas de PCB de los dispositivos relacionados con la red de sensores del bus.

D.1.1.

Sensores piroel ectricos

Figura D.1: Top Layer PCB Piroel ectrico (Zoom 2x)

Figura D.2: Bottom Layer PCB Piroel ectrico (Zoom 2x)

197

VCC_3 Pyro A D S G IRA-E700 GND GND GND R4 Res2 300K R5 Res2 2M GND OA4 Rpu1 Res2 2.2K B2 Q1* B Rpu2 Res2 2.2K B1 Q2* Rext Res2 22K Cext C 10u GND B 1 2 3 C2 C 100pF R6 Res2 1K OA3 R1 Res2 C1 1K C 10u GND R2 Res2 2M R3 Res2 300K VCC_3 Pw VCC_3 1 GND 2 OA1 GND GPIO OA2 VCC_3 VCC_3 VCC_3 RIGHT LEFT 1 2 Header 2 Rext1 Rext2 Header 2

RA2 Res2 100K RA1 Out2 OA4 OA3 GND C2oa3 C 0.1u R2oa3 Res2 1M Res2 100K

Mono A2 VCC_3 A1 A1 B1 Q1* RIGHT Rext2 GND GND 1 2 3 4 5 6 7 8 A1 B1 CLR1 Q1* Q2 CEXT2 REXT2 GND VDD REXT1 CEXT1 Q1 Q2* CLR2 B2 A2

4-OA VCC_3 OA1 Out2 OA2 R2oa1 Res2 1M C1oa2 C 0.1u Out2 1 2 3 4 5 6 7 OUT1 INV1 NINV1 VCC NINV2 INV2 OUT2 TS934ID OUT4 INV4 NINV4 GND NINV3 INV3 OUT3 14 13 12 11 10 9 8

VCC_3 16 15 Rext1 14 13 LEFT 12 Q2* VCC_3 11 10 B2 9 A2

GND

MM74HC123AM

C C1oa3 C 10u R1oa3 Res2 10K

C1oa1 C 10u

R1oa1 Res2 10k

GND

Title Amibot Pyroelectric Sensors Conditioning Size A4 Date: File: 1 2 3 09/12/2009 \\..\PyroSheet.SchDoc Sheet of Drawn By: 4 Number Revision

D.1. RED DE SENSORES

199

D.1.2.

Encoders

ENC_R 1 2 3 4 A Header 4

VCC_5 A1 B1 VCC_5 GND RIGHT A1 B1 1 2 3 4 5 6 7 8 Mono A1 B1 CLR1 Q1* Q2 CEXT2 REXT2 GND VDD REXT1 CEXT1 Q1 Q2* CLR2 B2 A2 VCC_5 16 15 Rext1 14 LEFT 13 VCC_5 12 11 10 B2 9 A2

VCC_5 ENCR ENCL

Conn 1 2 3 4 Header 4 A

GND GND

ENC_L 1 2 3 4 Header 4

VCC_5 Rext2 A2 B2 GND GND GND

MM74HC123AM

VCC_5 Rext Res2 470K Cext C 100n GND

RIGHT

R11 Res2 300K C1 C 100nF R21 Res2 470K

ENCR

Rext1 Rext2 GND LEFT R12 Res2 300K C2 C 100nF R22 Res2 470K GND GND ENCL

GND

Title Amibot Wheel Encoders Signal Conditioning Size A4 Date: File: 1 2 3 09/12/2009 \\..\EncoderSheet.SchDoc Sheet of Drawn By: 4 Number Revision

D.1. RED DE SENSORES

201

D.1.3.

ADC con interfaz I2C

Figura D.3: Top y Bottom Layer PCB ADC por I2C (Zoom 2x)

ERRATA NOTES PCB: ADC-00 P1 A 1 2 3 4 5 6 7 8 Header 8 6 7 8 1 2 3 4 5 CH0 CH1 CH2 CH3 CH4 CH5 CH6 CH7 ADS7830IPWTG4 VCC SDA SCL A1 A0 GND2 REF GND 16 15 14 13 12 11 10 GND 9 GND C1 C 1uF ADC-01 P2 1 2 3 4 5 6 7 8 Header 8 6 7 8 C 1 2 3 4 5 CH0 CH1 CH2 CH3 CH4 CH5 CH6 CH7 ADS7830IPWTG4 VCC SDA SCL A1 A0 GND2 REF GND 16 15 14 13 VCC_3 12 11 VCC_3 10 9 GND C Vcc GND R1 Res2 1K GND VCC_3 VCC_3 Vcc VCC_3 I2C VCC 1 SDA 2 SCL 3 GND 4 Header 4 GND 29/4/09: Faltan las 4 vas para el puerto I2C

Vcc

Title Amibot ADC Pcb Board Size A4 Date: File: 1 2 3 09/12/2009 \\..\ADCSheet.SchDoc Sheet of Drawn By: 4 Number Revision 2/4/09

D.1. RED DE SENSORES

203

D.1.4.

Expansores I2C

Figura D.4: Top y Bottom Layer PCB Expander I2C (Zoom 1x)

2 VCC_3

BUMP0 1 2 3 4 5 6 7 8 Header 8 Rpd8 Res2 2.2K GND BUMP1 1 2 3 4 5 6 7 8 Header 8 GND PYRO 1 2 3 4 5 6 7 8 C Header 8 PIR-1R PIR-1L PIR-2R PIR-2L PIR-3R PIR-3L PIR-4R PIR-4L GND GND BP9 BP10 P11 P12 P13 P14 P15 P16 GND Rpd10 Res2 2.2K Rpd9 Res2 2.2K PCF8574-2 VCC_3 A0-2 1 A1-2 2 A2-2 3 PIR-1R 4 PIR-1L 5 PIR-2R 6 PIR-2L 7 8 GND A0 A1 A2 P0 P1 P2 P3 GND PCF8574 VCC SDA SCL INT P7 P6 P5 P4 VCC_3 16 15 SDA 14 SCL 13 12 PIR-4L 11 PIR-4R 10 PIR-3L PIR-3R 9 GND Rpd7 Res2 2.2K GND Rpd6 Res2 2.2K Rpd5 Res2 2.2K Rpd4 Res2 2.2K Rpd3 Res2 2.2K Rpd2 Res2 2.2K Rpd1 Res2 2.2K GND VCC_3 A0-1 A1-1 A2-1 BP9 BP10 P11 P12 1 2 3 4 5 6 7 8 PCF8574-1 A0 A1 A2 P0 P1 P2 P3 GND PCF8574 VCC SDA SCL INT P7 P6 P5 P4 VCC_3 16 15 SDA 14 SCL 13 12 P16 11 P15 10 P14 P13 9 B BP1 BP2 BP3 BP4 BP5 BP6 BP7 BP8 GND A0-0 A1-0 A2-0 BP1 BP2 BP3 BP4 1 2 3 4 5 6 7 8 PCF8574-0 A0 A1 A2 P0 P1 P2 P3 GND PCF8574 GND VCC SDA SCL INT P7 P6 P5 P4 VCC_3 16 15 SDA 14 SCL 13 12 BP8 11 BP7 10 BP6 9 BP5 Rpu Res2 1K VCC_3 I2C VCC_3 1 SDA 2 SCL 3 GND 4 Header 4

GND

GND

GND

GND

GND

GND

INT

Title Amibot I/O Expansor Parallel to I2C Converter Size A4 Date: File: 1 2 3 09/12/2009 \\..\ExpanderSheet.SchDoc Sheet of Drawn By: 4 Number Revision

D.2. PLACA BASE DE AMIBOT

205

D.2.

Placa base de AmiBot

Figura D.5: Top Layer PCB Placa base de AmiBot (Zoom 1x)

Figura D.6: Bottom Layer PCB Placa base de AmiBot (Zoom 1x)

Regulator RegulatorSheet A

USB USBSheet A HDPA GND

VCC_5

M501-IO M501Sheet VCC_3 B VCC_3 VCC_5 GND BAT+ HDMA HDPA B

GND

HDMA

VCC_3

VCC_5

VCC_5

BAT+

GND

Title Amibot Motherboard PCB Size A4 Date: File: 1 2 3 09/12/2009 \\..\MBSheet.SchDoc Sheet of Drawn By: 4 Number Revision

1 VCC_3 VCC_3 VCC_5 VCC_5 GND Fi2c 1 2 GPIO0 PIO0 PIO2 PIO4 PIO6 PIO8 PIO10 PIO12 PIO14 1 3 5 7 9 11 13 15 2 4 6 8 10 12 14 16 PIO1 PIO3 PIO5 PIO7 PIO9 PIO11 PIO13 PIO15 0.75A Fplaca 1 2 0.75A

R04 Res2 Cplaca 0 C 0.1u GND R03

VCC_3 VCC_5 GND A

VCC_3f0 VCC_3f0 HDMA Rrst Res2 4.7K Rvbat1 BAT+ Rrst2 Res2 47 VCC_3f0 PIO17 PIO19 PIO21 PIO23 PIO25 PIO27 PIO29 PIO31 GND Crst C 100pF RSTBtn GND Res2 4M Fbat1 * 2 1 50mA Rvbat2 Res2 1M R02 Res2 0 SensBat

Reset VCC_3f1

Socket

Res2 Ci2c 0 C 0.1u GND

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49

GND

GND

Header 8X2 GPIO1 PIO16 PIO18 PIO20 PIO22 PIO24 PIO26 PIO28 PIO30 1 3 5 7 9 11 13 15 2 4 6 8 10 12 14 16 PIO17 PIO19 PIO21 PIO23 PIO25 PIO27 PIO29 PIO31

CTS2 RTS2 TXD3 RTS3 RXD4 CTS4 PD23 PIO17 PIO19 PIO21 PIO23 PIO25 PIO27 HDPB HDMA PIO29 PIO31 BTNRST PB6 TWS TSD RSCK GND GND VCC3

M-501 ARTILA M-501 VCC_3 VCC3 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Header 16 VCC_5 VCC5 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Header 16 GND GND 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Header 16

DSR2 RXD3 CTS3 TXD4 RTS4 PD22 PIO16 PIO18 PIO20 PIO22 PIO24 PIO26 PIO28 HDMB HDPA PIO30 PWROK NTRST PD6 TSCK RSD RWS GND GND VCC3

VCC_3f0 VCC_3f0 Rsda Res2 1K SDA Rscl Res2 1K SCL

Header 8X2

2 4 6 8 10 12 PIO16 14 PIO18 16 PIO20 18 20 PIO22 PIO24 22 PIO26 24 PIO28 26 28 30 32 PIO30 34 36 38 40 42 44 GND 46 GND 48 VCC_3f0 50

I2C0 VCC_3f1 1 SDA 2 SCL 3 GND 4 Header 4 C I2C3 VCC_3f1 1 SDA 2 SCL 3 GND 4 Header 4 I2C6 VCC_3f1 1 SDA 2 SCL 3 GND 4 Header 4 I2C9 VCC_3f1 1 SDA 2 SCL 3 GND 4 Header 4

I2C1 VCC_3f1 1 SDA 2 SCL 3 GND 4 Header 4 I2C4 VCC_3f1 1 SDA 2 SCL 3 GND 4 Header 4 I2C7 VCC_3f1 1 SDA 2 SCL 3 GND 4 Header 4 I2C10 VCC_3f1 1 SDA 2 SCL 3 GND 4 Header 4

I2C2 VCC_3f1 1 SDA 2 SCL 3 GND 4 Header 4 I2C5 VCC_3f1 1 SDA 2 SCL 3 GND 4 Header 4 I2C8 VCC_3f1 1 SDA 2 SCL 3 GND 4 Header 4 I2C11 VCC_3f1 1 SDA 2 SCL 3 GND 4 Header 4 VCC_3f0 GND GND

VCC_3f0 80 GND 82 GND 84 86 88 90 92 94 96 98 100 102 SCL 104 106 PIO3 108 PIO5 110 PIO7 112 PIO9 114 PIO11 116 PIO13 PIO15 118 120 PIO2 122 124 126 128

VCC3 GND GND ERX0+ ETX0+ MISO SPCK NPCS1 MCCDA MCDA1 MCDA3 PD20 TWCK PIO3 PIO5 PIO7 PIO9 PIO11 PIO13 PIO15 PIO2 RXD1 RTS1 TXD2 RCD2

VCC3 GND GND ERX0ETX0ACTLED MOSI NPCS0 MCCK MCDA0 MCDA2 PD19 TWD PIO1 PIO4 PIO6 PIO8 PIO10 PIO12 PIO14 PIO0 TXD1 CTS1 DTR2 RXD2

79 81 83 85 87 89 91 93 95 97 99 101 103 105 107 109 111 113 115 117 119 121 123 125 127

SDA PIO1 PIO4 PIO6 PIO8 PIO10 PIO12 PIO14 PIO0

GND

52 54 56 58 60 62 64 66 68 70 72 74 76 78

D0 D1 D2 D3 D4 D5 D6 D7 NOE NCS4 NCS6 PA24 PB18 GND

A0 A1 A2 A3 A4 A5 A6 A7 NWE NCS3 NCS5 PA21 PB7 VCC3

51 53 55 57 59 61 63 65 67 69 71 73 75 77

HDPA

VCC_3f0

Title Amibot M-501 I/O Pcb Size A4 Date: File: 09/12/2009 \\..\M501Sheet.SchDoc Sheet of Drawn By: 4 Number Revision

R00 BAT+ Res2 0 BAT 1 2 1 2 BAT+ GND Cin1 C Pol 2 330u/35V GND B GND GND GND GND GND GND 1 5 3 REG5 IN FB ON/OFF OUT GND LM2596S-5.0 4 2 Lreg Inductor B82477P4 Dshot 33u 30WQ04F Cout1 C Pol 2 330u/35V Cout3 C 0.1u REG3.3 3 Cin2 C 10u GND LM1085IS-3.3 IN GND OUT 2 Cout2 C 10u R01 VCC_3 Res2 0 VCC_5

Conector ED-1631 GND

GND

Title Amibot Power Regulator PCB Size A4 Date: File: 1 2 3 09/12/2009 \\..\RegulatorSheet.SchDoc Sheet of Drawn By: 4 Number Revision

VCC_5

Fusb 1 2 0.75A C11 C 10u GND

L1 Inductor B82477P4 33u C12 C 0.1u GND GND

Carcasa Carcasa

1 2 3 4

VBUS USB_DUSB_D+ GND

HDMA

1 L2 1u *

2 C2 C 47p GND USB

HDPA

1 L3 1u *

GND

2 C3 C 47p GND

GND GND B

5 6

Title USB Adaptor for Amibot MotherBoard Size A4 Date: File: 1 2 3 09/12/2009 \\..\USBSheet.SchDoc Sheet of Drawn By: 4 Number Revision

210

APENDICE D. PLANOS

D.3.

Actuadores

Figura D.7: Top y Bottom Layer PCB Motores (Zoom 1.5x)

3 NOTAS:

GPIO 1 2 3 4 A Header 4 Power 1 2 3 Header 3 VCC_5 GND VCC_3 Sens1 Rsens1 0.5 1A 1B 2A 2B Driver 1 MOT1A MOT2A 2 1A 2A 3 1B 2B GND 4 GND GND 5 Rs1 Rs2 M1B 6 MOT1B MOT2B VCC_5f0 7 VBB VCC 8 VREF RC Cvcc C A3968SLBTR 47u M1A 16 15 14 13 12 11 10 9 M2A 2A 2B GND M2B VCC_5f0 1 Rsens2 0.5 M1B M1A R01 Res2 0K M2B M2A R02 Res2 0K 1 2 1 2

Motor1 1 2 Conector ED-1631 Motor2 1 2 Conector ED-1631

30/4/09: Cambiado en implementacin el LPV321M5 por MCP6041

Fmot 1 2 0.75A

Lmot L Cmot1 10uH/1.1A C 10uF GND

VCC_5f0 Cmot2 C 0.1u GND

GND GND VCC_5f0 R1 Res2 39K

Rosc Res2 56K GND

Cosc GND C 680p 3 Sens1 Fbat2 2 *1 *

VCC_3 OA1 LPV321M5 CurrBat 4 1 Socket GND B 2 RoaS2 Res2 100K GND

R2 Res2 10K GND

RoaS1 Res2 1M

Coa C 47nF

Title Motor Driver for Amibot Size A4 Date: File: 1 2 3 09/12/2009 \\..\MotorSheet.SchDoc Sheet of Drawn By: 4 Number Revision

212

APENDICE D. PLANOS

ndice E Ape Diagramas de clases

E.1. Diagramas UML de AmiServer

213

214

APENDICE E. DIAGRAMAS DE CLASES

Figura E.1: Diagrama de clases del paquete amiserver

E.1. DIAGRAMAS UML DE AMISERVER

215

Figura E.2: Diagrama de relaciones del paquete amiserver.server

Figura E.3: Diagrama de clases del paquete amiserver.server

216

APENDICE E. DIAGRAMAS DE CLASES

Figura E.4: Diagrama de clases del paquete amiserver.amigui

E.1. DIAGRAMAS UML DE AMISERVER

217

Figura E.5: Diagrama de clases del paquete amiserver.amigui.controller

Figura E.6: Diagrama de clases del paquete amiserver.iface

218

APENDICE E. DIAGRAMAS DE CLASES

ndice F Ape Presupuesto

El presupuesto consta de los siguientes conceptos: Presupuesto de ejecuci on material Gastos generales y benecio industrial Honorarios por la redacci on y direcci on del proyecto Presupuesto total El presupuesto de ejecuci on material junto a los gastos generales y el benecio industrial constituyen lo que se denomina como presupuesto de ejecuci on por contrata. Este, junto con los honorarios por la redacci on y direcci on del proyecto, dan lugar al presupuesto total. Todos los presupuestos se presentar an en Euros.

F.1.

Presupuesto de ejecuci on material

El presupuesto de ejecuci on material recoge los costes de los recursos empleados (hardware, software y otros), as como la mano de obra.

F.1.1.

Presupuesto de recursos software

En primer lugar analizaremos el coste de los recursos de software, que podemos ver en la tabla F.1

F.1.2.

Presupuesto de recursos hardware

A continuaci on, en la tabla F.2, encontramos los recursos hardware utilizados a lo largo del proyecto. 219

220

APENDICE F. PRESUPUESTO

Concepto Sistema operativo Debian Sistema operativo Windows XP Licencia Altium Protel DXP Coste total:

Coste 0,00 120,00 2000,00

Amortizaci on 20 % 20 % 10 %

Coste real 0,00 24,00 200,00 224,00

Cuadro F.1: Presupuesto de los recursos software

Concepto Alquiler de l nea ADSL, 12 meses Ordenador de estaci on de trabajo Impresora l aser Router D-Link DI-254 WiFi USB Conceptronic C54RC Placa SoM Artila M-501 y StarterKit Fabricaci on PCBs Componentes para circuitos dise nados Oscilosc opio Tektronics TDS 210 Estaci on de soldadura JBC AM 6000 Coste total:

Coste 720,00 800,00 2000,00 50,00 25,00 250,00 150,00 510,00 5400,00 2500,00

Amortizaci on 100 % 20 % 10 % 20 % 20 % 25 % 25 % 25 % 10 % 10 %

Coste real 720,00 160,00 200,00 10,00 5,00 62,50 37,50 127,50 540,00 250,00 2.112,50

Cuadro F.2: Presupuesto de los recursos hardware

 MATERIAL F.1. PRESUPUESTO DE EJECUCION Relaci on de salarios Sueldo base mensual de ingeniero 3.150,00 Sueldo base diario de ingeniero 150,00 Relaci on de obligaciones sociales Vacaciones retribu das 8,33 % Seguro de accidentes 7,00 % Abono de d as festivos 12,00 % D as de enfermedad 1,65 % Plus de cargas familiares 4,25 % Graticaciones 25,00 % Otros conceptos 20,00 % Total de obligaciones sociales 78,23 % Importe total de los salarios Sueldo base diario 105,00 Cargas sociales 81,90 Coste salarial diario 186,90 Ingeniero contratado 1 a no 47.098,80 Cuadro F.3: Costes de mano de obra Concepto Recursos hardware Recursos software Mano de obra Consumibles, material fungible, de ocina y encuadernaci on del proyecto Total Cuadro F.4: Coste total de los recursos Coste 2.112,50 224,00 47.098,80 400,00 49.435,30

221

F.1.3.

Costes de mano de obra

Para la realizaci on del proyecto es necesaria la intervenci on de un Ingeniero de Telecomunicaci on. Este perl se enmarca dentro del grupo de cotizaci on 1 del R egimen General de Seguridad Social, con una jornada laboral de 8 horas al d a y 21 d as al mes. El desglose completo se puede consultar en la tabla F.3.

F.1.4.

Coste total de los recursos

El coste total de los recursos materiales est a formado por el coste de recursos hardware y software, la mano de obra, material de ocina e impresi on y encuadernaci on del proyecto. Su desglose lo podemos ver en la tabla F.4.

222

APENDICE F. PRESUPUESTO Concepto Presupuesto de ejecuci on material Gastos generales (16 % del P.E.M.) Benecio industrial (6 % del P.E.M.) Total presupuesto de ejecuci on por contrata Cuadro F.5: Gastos generales y benecio industrial Presupuesto total Concepto Presupuesto de ejecuci on por contrata Honorarios por direcci on Honorarios por redacci on Subtotal I.V.A. (16 %) Coste 60.311,06 3.377,42 3.377,42 67.065,90 10.730,54 Coste 49.435,30 7.909,64 2966,12 60.311,06

Presupuesto total
Cuadro F.6: Honorarios y presupuesto total

77.796,44A C

F.2.

Gastos generales y benecio industrial

Bajo el cap tulo de gastos generales se incluyen todos aquellos gastos derivados de la utilizaci on de instalaciones, cargas duciarias, amortizaciones, gastos scales, etc. Con esto, el presupuesto de ejecuci on por contrata queda como vemos en la tabla F.5.

F.3.

Honorarios y presupuesto total

Los honorarios que recomienda aplicar el Colegio Ocial de Ingenieros de Telecomunicaci on, tanto para la redacci on como para la direcci on del proyecto son los asociados a trabajos tarifados por tiempo empleado, con un valor de un 5,6 %. Finalmente, sumando todas las imputaciones anteriores, y aplicando el 16 % de IVA, se obtiene el presupuesto total (ver cuadro F.6). El presupuesto total del proyecto asciende a setenta y siete mil setecientos noventa y seis euros con cuarenta y cuatro c entimos de euro. Madrid, de Marzo de 2010

Fdo.: Marina Zapater Sancho Ingeniera de Telecomunicaci on

F.3. HONORARIOS Y PRESUPUESTO TOTAL

223

P agina en blanco intencionadamente