UNIVERSIDAD DE LAS PALMAS DE GRAN CANARIA Facultad de Informtica

Proyecto Fin de Carrera

DISEO HARDWARE/SOFTWARE PARA EL CONTROL Y MONITORIZACIN DE UN VEHCULO ELCTRICO INTELIGENTE A ESCALA

Aday Esteban Talavera Hierro

Tutores Dr. D. Javier J. Snchez Medina Dr. D. Enrique Rubio Royo

Noviembre 2010

Dedicatoria

A mi familia y amigos de verdad por estar ah siempre que se les necesita, prestando su ayuda y consuelo en los momentos difciles.

ndice

I Introduccin
1. Introduccin 1.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Organizacin de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Estado del arte 2.1. Robocar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7
9 11 12 13 13 14 15 17 19 21 21 23

2.2. Dreambot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Nightmare 3. Metodologa 4. Recursos necesarios 5. Plan de trabajo y temporizacin 5.1. Plan de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2. Temporizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

II Diseo hardware y software del sistema informtico del vehculo

1. Anlisis de requisitos del hardware del sistema informtico 1.1. Puertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Placa base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Procesador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4. Dispositivos de disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5. Dispositivo de conexin a red inalmbrica (Wi-Fi) . . . . . . . . . . . . . . . . . 1.6. Alimentacin elctrica del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 3

25
27 27 28 31 33 34 35

NDICE 1.7. Conclusiones del anlisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 39 39 40 40 47 47 48 50 55 55 57 58

2. Diseo del hardware del sistema informtico 2.1. Conguracin escogida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2. Estimacin del consumo de energa del sistema

2.3. Uso de un ratn mecnico como codicador ptico . . . . . . . . . . . . . . . . 3. Anlisis y eleccin del sistema operativo 3.1. Anlisis de requisitos del sistema operativo . . . . . . . . . . . . . . . . . . . . 3.2. Anlisis de distribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3. Eleccin de distribucin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Instalacin del sistema informtico en el vehculo 4.1. Instalacin y conguracin de la distribucin . . . . . . . . . . . . . . . . . . .

4.2. Establecimiento de un sistema de copias de seguridad . . . . . . . . . . . . . . 4.3. Prueba de hardware y software sensorial . . . . . . . . . . . . . . . . . . . . .

III Desarrollo de aplicacin JASEIMOV (control y monitorizacin)

1. Anlisis de requisitos de usuario 1.1. Descripcin del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61
63 63 64 65 66 71 71 86 91

1.2. Descripcin de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Glosario de trminos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4. Descripcin tcnica de dispositivos . . . . . . . . . . . . . . . . . . . . . . . . 2. Anlisis de requisitos de software 2.1. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Prototipo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Diseo del software 3.1. Herramientas de desarrollo 3.2. Diseo arquitectnico . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91 91 96

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3. Diseo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.4. Diseo de interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 3.5. Diseo detallado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 4

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.6. Diseo funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 3.7. Metodologa de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 4. Implementacin 157

4.1. Archivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 4.2. Documentacin del cdigo fuente . . . . . . . . . . . . . . . . . . . . . . . . . 158 4.3. Manual de la aplicacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

4.4. Publicacin y licencia del cdigo fuente . . . . . . . . . . . . . . . . . . . . . . 159

IV Conclusiones
1. Pruebas de validacin

161
163

1.1. Calibracin de dos sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 1.2. Duracin de la batera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 1.3. Detener automticamente el vehculo ante un obstculo . . . . . . . . . . . . . 164 2. Conclusiones y trabajo futuro 167

2.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 2.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

V Apndices
A. Protocolo del ratn PS/2

169
171

A.1. Caractersticas generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 A.2. Paquete de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 A.3. Modos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 A.4. Comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 A.5. Microsoft Intellimouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 B. Diseo de conguraciones del sistema 177

B.1. Conguraciones de plataforma Intel Atom . . . . . . . . . . . . . . . . . . . . . 178 B.2. Conguraciones de plataforma VIA . . . . . . . . . . . . . . . . . . . . . . . . 179 B.3. Dispositivo de disco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

B.4. Batera del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 5

NDICE C. Prueba de sockets frente a RMI 183

C.1. Diseo de la prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 C.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 D. Patrones de diseo 187

D.1. Patrn Comando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 D.2. Patrn Mtodo Fbrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 D.3. Patrn Modelo-Vista-Controlador . . . . . . . . . . . . . . . . . . . . . . . . . 188

D.4. Patrn Observador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 D.5. Patrn ThreadPool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 E. Manual de usuario de JASEIMOV E.1. Introduccin 193

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

E.2. Manejo de la interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 193 E.3. Limitaciones conocidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 E.4. Convertir un conjunto de imgenes en un vdeo . . . . . . . . . . . . . . . . . . 205 E.5. Iniciar el servidor en modo de prueba . . . . . . . . . . . . . . . . . . . . . . . 205 E.6. Congurar el servidor con un archivo de conguracin . . . . . . . . . . . . . . 205 E.7. Solucin de problemas conocidos . . . . . . . . . . . . . . . . . . . . . . . . . 207 F. Manual del sistema de copias de seguridad F.1. Sistema escogido 209

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

F.2. Utilizacin del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 F.3. Script creado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 ndice de guras Bibliografa 213 219

Parte I Introduccin

Captulo 1

Introduccin
Actualmente nos encontramos en un contexto global caracterizado por una crisis medioambiental, energtica y econmica. El desarrollo del ltimo siglo ha precipitado la escasez de combustibles fsiles y un cambio climtico sin precedentes, que requieren de acciones inmediatas para evitar continuar deteriorando el medio ambiente del planeta. Adems, la siniestralidad vial es motivo de preocupacin, especialmente en Europa, y en ese sentido se estn desarrollando multitud de esfuerzos para reducirla. El objetivo principal de la Comisin Europea de la Seguridad Vial es reducir, para el ao 2010, a la mitad el nmero de accidentes mortales, en comparacin con los registrados en 2001. Para ello, la comisin ha desarrollado iniciativas intentando mejorar el comportamiento responsable de los conductores, aumentando la seguridad en los vehculos con el apoyo a los avances tcnicos y mejorando las infraestructuras viales utilizando las tecnologas de la informacin y la comunicacin. Por todo lo anterior, es necesario un cambio de modelo de movilidad en general. En particular, todo parece indicar que los vehculos comerciales deberan evolucionar a vehculos elctricos debido a su menor impacto medioambiental. Tambin es presumible que estos vehculos incorporen progresivamente sistemas inteligentes de conduccin, lo cual afectara principalmente a la seguridad vial. Los sistemas inteligentes de transporte constituyen uno de los retos de la sociedad actual. En muchas universidades y centros de investigacin se emplea tiempo y esfuerzo en este tema. En algunos casos, se han conseguido productos comerciales que resuelven parte del problema, ofreciendo ayuda a las acciones de los conductores. En la actualidad, el estado de los proyectos est bastante avanzado, aunque muchas de las soluciones propuestas requieren de un cambio de la infraestructura, por ejemplo, en trenes urbanos, metros, etc, necesitando una fuerte inversin econmica. En estos momentos, la investigacin est dirigida hacia vehculos inteligentes como autobuses y coches, tanto elctricos como de gasolina, que sean capaces de ofrecer una conduccin automtica, por ejemplo: yendo de un punto a otro circulando por la carretera, manteniendo una distancia mnima de seguridad entre vehculos, regulando la velocidad en funcin de las condiciones del trco, adelantando a otros vehculos, etc. Tambin, en los ltimos aos han surgido modelos de vehculos privados dotados de sistemas de ayuda a la conduccin. Estos sistemas guan al conductor para aparcar el vehculo, encuentran la ruta ms corta hacia un destino, vigilan los ngulos muertos ante cambios de carril para evitar colisiones, alertan al conductor si se est quedando dormido, indican una colisin inminente con un obstculo analizando los datos provenientes de radares y cmaras, etc. El objetivo de estos sistemas es prevenir posibles accidentes ayudando al conductor en la conduccin.

Captulo 1. Introduccin El desarrollo de este proyecto gira en torno a la creacin de una plataforma de experimentacin que se ha denominado ASEIMOV, en ingls Autonomous Scaled Electric Intelligent MOnitorized Vehicle. La plataforma se basa en la transformacin de un coche ele ctrico radiocontrol de escala 1:10, aadindole sensores para captar su entorno y dispositivos para controlar el movimiento del vehculo utilizando su motor y su servomotor. Gestionando todos estos dispositivos, se ha instalado en el propio vehculo un sistema informtico de pequeo tamao, que utiliza una conexin inalmbrica Wi-Fi para comunicarse con otros sistemas, permitiendo as su control y monitorizacin de forma remota.

Figura 1.1: Dispositivos implicados en la plataforma ASEIMOV

En este contexto investigador, el objetivo de ASEIMOV es servir como plataforma exible de investigacin en materia de conduccin inteligente, de forma que se puedan extrapolar los resultados a vehculos elctricos reales, y adems de bajo coste, permitiendo trabajar a grupos de investigacin con pocos recursos. Usualmente en este tipo de investigaciones se requiere de una fuerte nanciacin, ya que se necesita obtener un vehculo real y modicarlo, con todo el gasto y problemtica que implica. Con ASEIMOV sera posible realizar investigaciones a escala, llevando la teora a la prctica de forma sencilla y a bajo coste. Dentro del trabajo implicado en la creacin de ASEIMOV, se ha realizado este proyecto de n de carrera, consistiendo en el diseo hardware y software del sistema informtico del vehculo, adems del desarrollo de una aplicacin para controlar y monitorizar el vehculo de forma remota. Paralelamente al desarrollo de este proyecto, un alumno de Ingeniera Industrial y de Ingeniera en Electrnica y Automtica Industrial realizar a su vez su proyecto de n de carrera escogiendo los sensores para el vehculo y modicando su estructura para incorporarlos. 10

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 1.2: Vehculo ASEIMOV

1.1. Objetivos
Los objetivos de este proyecto son: Disear un sistema informtico para el vehculo escogiendo su hardware y su software. El diseo del sistema se realizar teniendo en cuenta las restricciones a su tamao, consumo energtico y prestaciones. Se deber encontrar un formato de placa base compatible con el espacio disponible en el vehculo, con un consumo energtico moderado que permita alimentarlo mediante bateras. Adems se buscar un sistema exible compatible con los estndares hardware de los ordenadores actuales como PS/2, USB, procesador compatible x86, etc. Deber utilizarse un dispositivos de disco basado en memoria ash, puesto que un disco mecnico podra verse afectado por el movimiento del vehculo. Adems, el sistema deber disponer de conexin a red inalmbrica Wi-Fi. El diseo software comprender escoger y adaptar el sistema operativo del sistema, En este caso, se escoger una distribucin GNU/Linux como sistema operativo, adaptndola y congurndola a las necesidades de la plataforma. Habr que tener en cuenta aspectos de la distribucin tales como el espacio ocupado en disco y en memoria, estabilidad o soporte de actualizaciones. Desarrollar una aplicacin para controlar y monitorizar el vehculo de forma remota. Esta aplicacin deber permitir visualizar en tiempo real desde otro equipo, la lectura de los sensores del vehculo y adems de controlarlo para moverlo. El propsito de esta aplicacin es demostrar el funcionamiento de la plataforma y servir como herramienta para futuros proyectos. Analizar la posibilidad de utilizar un ratn mecnico (ratn de bola) como codicador ptico (encoder) para el motor del vehculo. Para esto se analizar el protocolo PS/2 utilizado por 11

Captulo 1. Introduccin los ratones.

1.2. Organizacin de la memoria

Esta memoria se ha organizado en cinco partes: 1. Introduccin: presenta el proyecto y sus objetivos, la metodologa empleada y los recursos necesarios, adems del plan de trabajo. 2. Diseo hardware y software del sistema informtico del vehculo: comprende escoger el hardware y el software del sistema informtico que se colocar en el vehculo. 3. Desarrollo de aplicacin JASEIMOV para el control y monitorizacin remota del vehculo: describe el proceso de desarrollo de la aplicacin para el control y monitorizacin remota del vehculo. 4. Conclusiones: presenta las pruebas realizadas en la plataforma nal y las conclusiones del proyecto realizado. 5. Apndices: incluye los apndices descritos en las partes anteriores y la bibliografa utilizada.

12

Captulo 2

Estado del arte

2.1. Robocar

Figura 2.1: Robocar Robocar es un proyecto lanzado por la empresa japonesa ZMP en el 2009. Se trata de un vehculo diseado para la enseanza y la investigacin en materia de conduccin inteligente, sobre todo para la prueba de algoritmos de navegacin autnoma. Las caractersticas principales de la plataforma son: Aspecto similar al de un turismo real. Reconocimiento de imagen estreo mediante dos cmaras en el frontal. Ocho Sensores de distancia infrarrojos dispuestos alrededor del permetro del vehculo. Medidor de distancia lser. Giroscopio. Sistema informtico: AMD Geode LX800 500MHz, red inalmbrica Wi-Fi, con un sistema operativo basado en kernel Linux en tiempo real. El precio del conjunto es bastante elevado, de unos 5000e, sobre todo si se tiene en cuenta que este precio no incluye ni la carrocera ni las dos cmaras. Fuente: http://www.zmp.co.jp/e_html/products_rc-z_en.html 13

Captulo 2. Estado del arte

Figura 2.2: Carrocera de Robocar

2.2. Dreambot

Figura 2.3: DreamBot DreamBot es un vehculo autnomo desarrollado por Carlos Agell como parte de su tesis en la la Universidad de California-Irvine. DreamBot utiliza un modelo todoterreno de coche radiocontrol como base de la plataforma. Las caractersticas principales de DreamBot son: Basado en un coche radiocontrol de escala 1:10, Traxxas Emaxx. Empleo de una cmara web para capturar imgenes. 14

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala Control del motor y el servomotor originales del coche radiocontrol mediante una placa de instrumentacin (Arduino Diecimila). Sensores de distancia infrarrojos dispuestos en forma radial. Dispositivo GPS. Control de velocidad empleando un ratn mecnico (de bola) como encoder. Sistema informtico: placa mini-ITX, red inalmbrica Wi-Fi y sistema operativo Fedora.

Figura 2.4: Detalle del ratn utilizado como encoder de DreamBot Sobre la plataforma se han realizado experimentos como posicionamiento en tiempo real utilizando la seal del GPS junto con GoogleEarth y GoogleMaps, as como algoritmos de conduccin autnoma. Fuente: https://webfiles.uci.edu/cagell/Dreambot/default.htm

2.3. Nightmare
Nightmare es un robot de experimentacin fabricado en la Universidad de Aveiro por Antnio J. R. Neves, Gustavo A. Corrente and Joo Figueiredo. Se diseo como un robot verstil que fuera capaz de participar en varias competiciones de robtica. Las caractersticas principales de Nightmare son: Utiliza un microcontrolador PIC18F258 conectado a un ratn mecnico PS/2, dos leds, un sensor de terreno y un mdulo con un doble puente H para controlar los dos motores que mueven el robot. El microcontrolador se conecta con el ordenador mediante un puerto RS232. El ratn se utiliza como encoder para los dos motores, adems se utilizan los dos botones para iniciar y detener el robot. 15

Captulo 2. Estado del arte

Figura 2.5: Nightmare Los leds sirven para indicar el estado del robot. Por ejemplo, cuando alcanza un objetivo como parte de un algoritmo, se encienden. Dispone de dos cmaras web para captar el entorno. Sistema informtico: placa mini-ITX VIA EPIA Nehemiah M10000, dispositivo de disco basado en una tarjeta compact ash de 512mb y sistema operativo Debian GNU/Linux Sarge 3.1. El robot gan el premio especial a la innovacin de la edicin en 2005 de la competicin MicroRato, organizada en la Universidad de Aviero. Fuente: [1].

16

Captulo 3

Metodologa
Durante el desarrollo de la plataforma se colaborar con Moiss Daz Cabrera, alumno de Ingeniera Industrial y de Ingeniera en Electrnica y Automtica Industrial, quin tambin se encuentra realizando su proyecto de n de carrera en torno al vehculo. Moiss se encargar fundamentalmente de adaptar el chasis original del vehculo radiocontrol para incorporar los dispositivos adicionales en el mismo, apantallamiento elctrico de los dispositivos y escalado de masas del vehculo con masas adicionales, tomando como referencia un turismo elctrico real. En el diseo hardware del sistema informtico, se analizar el mercado actual en formatos de placa base de pequeo tamao: fabricantes, procesadores, dispositivos de almacenamiento, consumo energtico, etc. Posteriormente se disear y comprar el sistema en base a los datos de dicho anlisis. Dado el carcter moderno de esta tecnologa, la mayora de la informacin se consultar en Internet. Por ello se habr de tener especial atencin en guardar los enlaces a las informaciones ms relevantes y, si se cree preciso, una copia de las pginas. En el diseo software del sistema informtico, se escoger el sistema operativo del sistema informtico. En este caso se escoger una distribucin GNU/Linux. Primero se analizarn los requisitos del sistema operativo para este sistema para escoger que distribuciones se probarn en el hardware escogido en el apartado anterior. Finalmente, en base a estas pruebas se escoger que distribucin se utilizar en el sistema. Para estudiar la posibilidad de usar un ratn mecnico como codicador ptico, se estudiar el protocolo que utilizan estos dispositivos. Para trabajar con el ratn a bajo nivel, se intentar primero encontrar y adaptar cdigo fuente que pueda encontrarse en la red. En el desarrollo de la aplicacin para el control y monitorizacin remota del vehculo, se trabajar inicialmente con un prototipo con el objetivo de capturar correctamente los requisitos del software. Adems, servir como un primer diseo de la interfaz de usuario. Se seguir un diseo modular en el que se diferencie la visualizacin de sensores y el telecontrol, con el objetivo de su posterior reutilizacin en otros proyectos. En el diseo arquitectnico habr que disear un sistema de comunicacin entre la aplicacin y los dispositivos conectados al vehculo. La memoria del proyecto se realizar con LaTeX y con la documentacin se incluir un disco grabado con el cdigo fuente del proyecto, libreras usadas y documentacin pertinente.

17

Captulo 4

Recursos necesarios
La nanciacin para la obtencin del hardware necesario para el proyecto (vehculo, instrumentacin, hardware informtico y herramientas) ir a cargo del CICEI. Desde que se obtengan, estos recursos se encontrarn en todo momento en un rea de trabajo destinada al efecto en las instalaciones del CICEI, en el Edicio Central del Parque Cientco y Tecnolgico del Campus Universitario de Tara. Adems se necesitar un ordenador con una distribucin Linux con acceso de administrador, conexin a Internet y las herramientas usuales como procesador de texto, navegador web, etc. Deber disponer de al menos un puerto PS/2 para poder conectar un ratn mecnico de este tipo. Tambin tendr que ser posible instalar en el equipo nuevas distribuciones de Linux por si se necesita realizar pruebas. El equipo se hallar en el rea de trabajo mencionada anteriormente. Con el objeto de minimizar costes, se emplear ante todo software libre o, como mnimo, con una licencia de distribucin y modicacin abierta.

19

Captulo 5

Plan de trabajo y temporizacin

A continuacin se incluye la organizacin del plan de trabajo y temporizacin del proyecto.

5.1. Plan de trabajo

En esta seccin se detalla el plan de trabajo del proyecto. ste se divide en tres fases de trabajo que tienen asociadas una serie de actividades. A su vez las actividades tienen una serie de tareas a realizar. 5.1.0.1. Fase 1: Diseo hardware/software del sistema informtico del vehculo Actividad 1.1 Anlisis de hardware del sistema.

Anlisis de placas base. Anlisis de dispositivos de disco. Generacin de documentacin anlisis de componentes.
Actividad 1.2 : Diseo y presupuesto del sistema.

Diseo del sistema informtico. Contacto con distribuidor. Elaboracin y aprobacin del presupuesto. Generacin documentacin diseo y presupuesto del sistema informtico.
Actividad 1.3 Bsqueda de distribuciones Linux.

Bsqueda de distribuciones Anlisis de distribuciones Generacin documentacin de bsqueda de distribuciones

Actividad 1.4 : Eleccin de distribucin Linux.

Instalacin y prueba de distribuciones. Eleccin de distribucin. Generacin documentacin eleccin de distribucin Linux.
Actividad 1.5 : Instalacin del sistema informtico. 21

Captulo 5. Plan de trabajo y temporizacin

Instalacin de la distribucin Linux escogida. Adaptacin y conguracin de la distribucin. Probar hardware y software sensorial. Generacin documentacin instalacin del sistema informtico.
Actividad 1.6 Analizar el posible uso un ratn mecnico como encoder.

Bsqueda de documentacin y cdigo fuente. Experimentar con cdigo fuente. Generacin documentacin anlisis de uso de ratn mecnico como encoder.
5.1.0.2. Fase 2: Desarrollo de aplicacin para el control y monitorizacin remota del vehculo

Actividad 2.1 Anlisis de requisitos de la aplicacin.

Consultar tutor sobre requisitos. Elaboracin de un prototipo. Requisitos de usuario. Requisitos de software. Generacin documentacin anlisis de requisitos de la aplicacin.
Actividad 2.2 : Diseo de la aplicacin.

Diseo arquitectnico. Diseo de interfaz de usuario. Generacin documentacin de la aplicacin.

Actividad 2.3 : Implementacin de la aplicacin.

Implementacin del telecontrol del vehculo. Implementacin de visualizacin remota de sensores. Generacin documentacin implementacin.
5.1.0.3. Fase 3: Validacin y publicidad del PFC

Actividad 3.1 : Pruebas de validacin.

Denicin de los test de validacin. Aplicacin de los test de validacin. Anlisis de resultados de los test de validacin. Generacin documentacin test de validacin.
Actividad 3.2 : Publicidad.

Confeccin de manuales de usuario.

22

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

5.2. Temporizacin
En esta seccin se detalla la temporizacin de las actividades del proyecto, incluyendo una estimacin de horas de trabajo por cada actividad. TEMPORIZACIN DEL PFC Fases / Actividades Fase 1: Diseo hardware/software del sistema informtico del vehculo Anlisis de hardware del sistema Diseo y presupuesto del sistema Bsqueda de distribuciones Linux Eleccin de distribucin Linux Instalacin del sistema informtico Analizar el posible uso un ratn mecnico como encoder Fase 2: Desarrollo de aplicacin para el control y monitorizacin remota del vehculo Anlisis de requisitos de la aplicacin Diseo de la aplicacin Implementacin de la aplicacin Fase 3: Validacin y publicidad del PFC Pruebas de validacin Publicidad TOTAL HORAS 1 X 2 X Meses 3 4 5 6 X X 80 60 50 50 60 60 X X X X X 120 120 240 X 50 20 910 7 8 Horas

23

Parte II Diseo hardware y software del sistema informtico del vehculo

25

Captulo 1

Anlisis de requisitos del hardware del sistema informtico

Las opciones de hardware que pueden usarse para disear un sistema informtico son innumerables. El objetivo de este anlisis es concretar que componentes y que caractersticas de ellos hay que tener en cuenta para diseo el sistema. Adems, se pretende que el anlisis sirva como base de conocimiento para poder escoger componentes alternativos para posibles repuestos o mejoras en el futuro. Se van a estudiar los siguientes aspectos hardware del sistema: Conexin de sensores (puertos). Placa Base. Procesador. Memoria RAM. Dispositivo de disco. Dispositivo de conexin a red inalmbrica Wi-Fi. Batera del sistema. La arquitectura hardware del sistema que se pretende construir, se reeja en la gura 1.1.

1.1. Puertos
Inicialmente se pretende incorporar al vehculo los siguientes dispositivos: 4 x puertos USB: cmaras web (webcams). 5 x puertos USB: sensores y actuadores varios. 1 x puerto PS/2: ratn mecnico (ratn de bola). Esta lista puede usarse a modo orientativo sobre las conexiones necesarias en la placa base. Por tanto, en el diseo se supondr el uso de nueve puertos USB y un puerto PS/2. Si se 27

Captulo 1. Anlisis de requisitos del hardware del sistema informtico

Figura 1.1: Arquitectura hardware del sistema informtico necesitan ms puertos USB la mejor opcin sera utilizar un concentrador USB pequeo que funcione sin alimentacin externa, para conseguir ms puertos en el sistema. Adems, hay que tener presente que cada dispositivo USB toma energa del puerto, lo que puede impedir que otros dispositivos funcionen por no disponer de energa suciente. En este caso, podran usarse concentradores que usen alimentacin externa para garantizar que a ningn dispositivo le falta energa. Sin embargo, su uso no es recomendable por requerir energa adicional que provendra de la batera del sistema.

1.2. Placa base

Cuando se disea un sistema informtico, lo primero que hay que tener en cuenta es que placa base se va a usar. A la placa base se conectan todo el resto de componentes (procesador, perifricos, disco, etc.) y por ello afecta directamente al rendimiento del sistema. La placa debe disponer de sucientes puertos USB para conectar todos los sensores y, si es necesario, hardware adicional. Adems, debe ser pequea para que quepa en el interior del chasis del vehculo. Las dimensiones del espacio interior del vehculo son 200 mm x 170 mm x 95 mm. Esto son dimensiones mximas, ya que tambin los sensores y cables necesarios utilizarn parte de este espacio. Las dimensiones de una placa base dependen directamente del formato en el cual se ha fabricado. El formato estndar en ordenadores de escritorio es ATX (305 mm x 244 mm). Cualquier placa de este tamao supera con creces el espacio disponible, sin contar que precisan de una fuente de alimentacin estndar ATX. Hay que estudiar formatos con menor tamao y consumo energtico, pero que sigan siendo compatibles con los estndares usuales de escritorio como: USB, PS/2, PCI y procesador compatible x86. En el mercado actual existen varios estndares en cuanto a formatos de placa bases pequeas compatibles con ATX. Los ms destacados son: microATX, mini-ITX, nano-ITX y pico-ITX. Una comparacin de los tamaos de estos formatos puede verse en la gura1.2

1.2.1. microATX
Es un formato diseado para ser totalmente compatible con ATX pero con menores dimensiones: 244 mm x 244 mm. La principal diferencia con respecto a una placa ATX, es que en28

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 1.2: Detalle de los distintos formatos de placa base contramos menos puertos de expansin PCI que en una placa ATX, siendo el mximo permitido cuatro. Gracias a esto se reduce el tamao de la placa. Estas placas estn destinadas a sistemas de escritorio, usando los mismos procesadores y chipsets, con el objetivo de que ocupen menos espacio, ya que se pueden usar carcasas ms pequeas que para una placa ATX. En nuestro caso, las dimensiones del formato hacen imposible su colocacin en el vehculo. Adems al usar los mismos procesadores y chipsets, las demandas energticas son altas, dicultando el uso de una batera. La especicacin de este formato puede verse en [6].

1.2.2. mini-ITX
Mini-ITX es un formato de placas base de especicaciones abiertas desarrollado por VIA, con el objetivo de construir ordenadores pequeos de bajo consumo y modestas prestaciones para uso industrial. Actualmente se ha popularizado su uso como sistemas HTPC (Home Teather Personal Computer), car PC (ordenadores para vehculos de transporte), pequeos servidores, enrutadores, etc. Las dimensiones de estas placas son de 170 mm x 170 mm, lo que hace posible su colocacin en el vehculo. Puesto que es un formato abierto ms fabricantes aparte de VIA lo trabajan, pudindose encontrar placas con procesadores de VIA, Intel y AMD. Un ejemplo de este formato puede verse en la gura1.3 Lo mejor de este formato es que mantiene buenas prestaciones (potencia, nmero de puertos...) en un tamao muy ajustado. El consumo energtico tiende a ser bajo, dependiendo de la combinacin de procesador y chipset que se use. Por ello la mayora disipan el calor mediante disipadores pasivos, aunque algunos modelos incluyen un ventilador de uso opcional. La fuente de alimentacin de ests placas suele usar el conector estndar ATX, aunque algunas incorporan la propia fuente de alimentacin en la placa. La especicacin puede consultarse en [25].

1.2.3. nano-ITX y pico-ITX

VIA desarroll estos dos formatos como una evolucin del formato mini-ITX. El formato nanoITX dene el tamao de la placa en 120 mm x 120 mm, mientras que el pico-ITX lo dene en 100 mm x 72 mm. Sus dimensiones hacen de estas placas perfectas para el espacio del vehculo. Sin embargo existen inconvenientes. Por una parte al ser tan pequeas tienen muy limitado el nmero de puertos fsicos del que disponen. Por ejemplo, en las placas nano-ITX suelen incluir un conector VGA, uno o dos puer29

Captulo 1. Anlisis de requisitos del hardware del sistema informtico

Figura 1.3: Detalle de placa mini-ITX de VIA tos USB, un RJ45 para conexiones LAN, quizs un puerto PS/2 y las conexiones de la tarjeta de sonido. De forma similar, en una placa pico-ITX normalmente incluye un conector VGA y un RJ45. En ambos casos, se disponen de conexiones adicionales en pines en la placa. As se dispone de ms puertos PS/2, USB, conexiones de la tarjeta de sonido, etc. Incluso muchas veces lo que ocurre es que junto a la placa se incluyen las piezas o conexiones necesarias para utilizar los pines. Un ejemplo de placa nano-ITX se encuentra en la gura 1.4, as como un ejemplo de placa pico-ITX en la gura 1.5

Figura 1.4: Detalle de placa nano-ITX de VIA Durante el desarrollo de este anlisis slo se han encontrado placas de estos formatos fabricadas por VIA, que utilizan procesadores VIA C7. En estas placas, la disipacin del calor se suele realizar mediante disipadores pasivos, puesto que sus demandas energticas son menores. La descripcin del formato nano-ITX puede consultarse en [26] y la de pico-ITX en [28]. En conclusin, si las placas pico/nano-ITX tienen sucientes prestaciones en capacidad de proceso y nmero de puertos, seran la eleccin perfecta en cuanto a su tamao y su consumo energtico. Si no, existe la alternativa de las placas mini-ITX con mayor consumo y tamao pero con mejores prestaciones que los otros dos formatos. Por ltimo, microATX no es un formato vlido, tanto por su consumo como por su tamao. 30

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 1.5: Detalle de placa pico-ITX de VIA Tabla 1.1: Comparativa de placas base Micro-ATX grande mayores mayor bajo Mini-ITX medio medias medio medio pico/nano-ITX pequeo menores mnimo alto

tamao prestaciones consumo precio

1.3. Procesador
Las placas base de los formatos mini/nano/pico-ITX utilizan generalmente procesadores de Intel y VIA. Para estudiar el impacto en el rendimiento y consumo energtico del sistema se analizarn los procesadores que actualmente se utilizan en estos formatos. Un detalle a tener en cuenta es que normalmente, en contrapartida a las placas ATX y microATX, los procesadores estn soldados a la propia placa y no se pueden cambiar por otro. Por tanto, si se necesitara un procesador mejor en un futuro, se debera cambiar la placa entera. Adems, se analizar el consumo del chipset que acompaa al procesador. En estas placas se concentran muchas funciones en el chipset incluyendo hardware grco, de sonido y de red, entre otros. Por ello, el chipset juega un papel muy importante en el rendimiento y en el consumo de energa nal del sistema. Para denir el consumo energtico de un componente se suele utilizar como medida el TDP (Thermal Design Power), que representa la mxima cantidad de calor que necesita disipar el sistema de refrigeracin de un ordenador mientras ejecuta aplicaciones reales. Bsicamente viene a representar el consumo del componente cuando se usan aplicaciones normales, que no demandan excesivos recursos como pudiera ser un juego o un test sinttico. A continuacin se analizan los modelos de procesadores de cada fabricante en el contexto de las plataformas mini/nano/pico-ITX:

1.3.1. Procesadores Intel

Los procesadores del fabricante Intel que encontramos en placas mini-ITX son de la familia Atom. Tambin se encuentran placas con procesadores de la familia Celeron, no obstante, estos procesadores tienen mayores prestaciones y su consumo energtico es mayor. Dentro de la familia Atom, nos encontramos actualmente en el mercado con dos procesadores de un ncleo 31

Captulo 1. Anlisis de requisitos del hardware del sistema informtico y uno de doble ncleo. En los procesadores de un ncleo encontramos dos modelos muy similares, el Atom 230 y el Atom n270, con una frecuencia de 1,6GHz, 533MHz en bus de sistema y 521KB de cache de nivel 2. Se diferencian en que el 230 es un procesador de 64 bits mientras que el n270 es de 32 bits. Adems el 230 tiene un TDP de 4W mientras que el n270 lo tiene de 2,5W. El procesador de doble ncleo corresponde al Atom 330, con dos ncleos de 64 bits a una frecuencia de 1,6GHz, 533MHz en bus de sistema y 1MB de cache de nivel 2 (512KB por ncleo). Su TDP es de 8W. La arquitectura Atom se basa en la ejecucin de las instrucciones en orden y la utilizacin de la tecnologa Intel Hyper-Threading. Esta tecnologa permite que un segundo hilo utilice las unidades ociosas del procesador, lo que mejora el rendimiento en entornos multihilo. La principal desventaja de estos procesadores es, que a pesar de que tienen un consumo reducido, el chipset que suele acompaarlos es el Intel 945GC que tiene un TDP de 22,5W!. Este consumo tan elevado se debe a que es un chipset diseado para sistemas de escritorio. Existe otro chipset, el Intel 945GSE, con un TDP de 6W, que se usa en conjunto con el n270, ofreciendo un sistema con un consumo bajo.

1.3.2. Procesadores VIA

En este caso nos encontramos con dos familias de procesadores: C7, y Nano. La primera surgi en el ao 2005 como una evolucin de la antigua familia C3. La segunda es la familia ms moderna y con ms prestaciones, lanzada en el 2008. Los procesadores C7 se basan en el ncleo con nombre clave Esther, son de 32 bits y sus velocidades van desde 1GHz a 2 GHz, con un FSB de 400MHz a 800MHz y 128KB de nivel 2. La ejecucin de las instrucciones se hace en orden. Es una familia extremadamente amplia con procesadores destinados a equipos de escritorio, sistemas mviles, sistemas embebidos y lneas de bajo voltaje. El TDP mximo es de 20W pero en la lnea de bajo voltaje no supera los 8W. Los procesadores de menor frecuencia no precisan de ventilacin y funcionan con refrigeracin pasiva. Estos ltimos son los que ms se usan en las placas nano/pico-ITX y los que tienen menor TDP. Los procesadores Nano se basan en el ncleo con nombre clave Isaiah, son de 64 bits y sus velocidades van desde 1GHz a 2 GHz, con un FSB de 533MHz a 800MHz y 1MB de nivel 2. El TDP mximo es de 25W, pero existe una lnea de bajo voltaje que no supera los 8W. Ofrecen un mejor rendimiento con respecto a la familia C7 para una misma frecuencia, gracias a una arquitectura ms compleja superescalar, con ejecucin fuera de orden, prediccin de saltos, ms cache, etc. En el momento de realizar este anlisis VIA anunciaba la serie Nano 3000 a principios del 2010, con mejor rendimiento y menor consumo. VIA lleva mucho tiempo enfocando la fabricacin de los procesadores hacia el bajo consumo y un buen rendimiento. Por ello el consumo de sus procesadores es bastante bajo y precisan nicamente de refrigeracin pasiva. Adems, los chipset de VIA no consumen mucha energa. La principal desventaja de estos procesadores es de no disponer de procesadores de mltiples ncleos o con tecnologas como el Hyper Threading de Intel. Esto permite no elevar el consumo energtico demasiado, pero en la actualidad el uso de tecnologa de multiproceso est en auge y el software est aprovechndola, mejorando el rendimiento del sistema. Se incluye a continuacin una tabla comparativa donde se resalta aproximadamente el rendimien32

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala to, consumo y precio de un sistema completo segn el procesador que use: Tabla 1.2: Comparativa de procesadores Atom Atom n270 Atom 230 bajo bajo 14W 20W menor 80e VIA C7 C7 ULV VIA Nano bajo bajo alto 12-20W 8-12W 15-25W mayor 100e

Rendimiento Consumo precio

Atom 330 medio/alto 25W

En conclusin, los procesadores con mejor rendimiento son el Atom 330 y el VIA Nano. El primero por ser de doble ncleo y tener un bajo consumo (aunque aumenta con el chipset), el segundo por ser un procesador con una arquitectura ms compleja y de buen rendimiento, aunque con un consumo mayor en comparacin con los Atom. Los procesadores con menor consumo son el Atom n270 y los VIA C7, aunque estos ltimos tienen menor rendimiento que el Atom n270. Un aspecto a tener en cuenta es el precio de las plataformas, en el que los modelos de Atom tiene ventaja frente a los modelos VIA. Por tanto, en la fase de diseo se deber escoger entre un sistema con uno de los dos procesadores.

1.4. Dispositivos de disco

Al analizar que dispositivo de disco escoger hay que tener en cuenta que los discos duros convencionales pueden comprometer la estabilidad del sistema al verse su mecnica afectada por los golpes y vibraciones producidos por el movimiento del vehculo. La alternativa es usar un disco basado en memoria de estado slido, ms comnmente conocida como memoria ash. Las principales ventajas de estas memorias frente a un disco duro convencional son: El tiempo de acceso a los datos es menor. En un disco duro, para leer un dato es necesario esperar a que se posicione la cabeza lectora sobre el rea que debe leer, as como esperar a que la rotacin site los datos bajo esta cabeza lectora. En cambio, un disco basado en memoria no dispone de partes mecnicas y el tiempo de acceso a un dato es mnimo. Debido a esto, la fragmentacin externa1 tiene poco impacto sobre el rendimiento de un disco de este tipo. Inmunidad frente a golpes, vibraciones, etc. gracias a la ausencia de partes mecnicas. Menor peso. Las principales desventajas son: Tienen un coste mucho mayor por espacio en disco (Coste por Gigabyte), que provoca que sean de menor capacidad. Esto no es directamente un problema, puesto que se
Cuando se guarda un chero, se almacena en un conjunto de bloques del disco. Si estos bloques no estn localizados de forma contigua en el disco no se puede realizar una lectura secuencial del chero y hay que volver a colocar la cabeza lectora para leer los bloque aislados. Esto aumenta el tiempo de lectura para del chero.
1

33

Captulo 1. Anlisis de requisitos del hardware del sistema informtico estima que con unos 4GB hay suciente espacio para instalar una distribucin Linux con los paquetes y controladores necesarios y an sobrara mucho espacio para los usuarios del sistema. Las celdas de estas memorias tienen un lmite de ciclos de borrados y escrituras que si se alcanza las puede estropear. Aunque este lmite es alto, en torno a los 100.000 ciclos, y los fabricantes utilizan tcnicas como Wear Leveling [22] para evitar alcanzarlo, es recomendable tomar precauciones para evitar realizar muchas escrituras en el disco. La velocidad de lectura y escritura es, de momento, menor que la que ofrece un disco duro SATA. La diferencia es an ms importante si usamos puertos ms lentos que SATA, como por ejemplo USB. No obstante debido al reducido tiempo de acceso, son mejores para leer muchos archivos pequeos. Observando los dispositivos de almacenamiento disponibles en mercado actual se han analizado los siguientes en funcin del puerto de conexin que utilizan:

1.4.1. Memorias ash con conexin USB

Comnmente conocidos como pendrives, estos dispositivos de almacenamiento porttil presentan capacidades que normalmente rondan los 8GB a un bajo coste. El rendimiento que ofrecen stas memorias es variable. Por ejemplo, si echamos un vistazo a la gama de pendrives de Kingston [11], la mayora ronda hasta los 10MB/s en lectura y 5MB/s en escritura, aunque existen modelos ms rpidos que alcanzan hasta los 24MB/s en lectura y los 20MB/s en escritura.

1.4.2. Memorias ash con conexin eSATA

El caso de estas memorias es bastante parecido al anterior, pero en lugar de usar una interfaz USB, usan un puerto SATA externo, eSATA, siendo ambos puertos compatibles. Un puerto SATA presenta una velocidad mucho mayor que un puerto USB 2.0. Como ejemplo, el dispositivo OCZ Throttle eSATA 8GB [13], ofrece un rendimiento de hasta 90MB/s de lectura y de hasta 30MB/s de escritura segn el fabricante.

1.4.3. Discos de estado slido o SSD (Solid State Drive)

Estos dispositivos estn diseado con el objetivo de sustituir a los discos duros convencionales. Tambin presentan capacidades mayores al ser ms grandes, aunque el tamao pudiera ser un inconveniente en comparacin con los dos anteriores. Tambin al ser ms grandes disponen de mejor hardware, sobre todo en los dispositivos ms caros, lo que se nota en el rendimiento. Por ejemplo, si se analiza la gama de SSD de Kingston [12], observamos en la gama ms barata un rendimiento de hasta 100MB/s en lectura y hasta 80MB/s en escritura. Mientras la gamas ms rpida, y cara, ofrece 250MB/s en lectura y 170MB/s en escritura.

1.5. Dispositivo de conexin a red inalmbrica (Wi-Fi)

El sistema debe contar con un dispositivo de conexin a red inalmbrica (Wi-Fi) para permitir el intercambio de datos en red entre el ordenador del vehculo y un ordenador externo. A la hora de escoger uno hay que tener en cuenta lo siguiente: 34

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala Compatibilidad con Linux: el dispositivo debe ser compatible con Linux y disponer de controladores, o bien por parte del fabricante o por parte de la comunidad de usuarios. Lo ms sencillo, si el fabricante no incluye controladores Linux, es identicar el chip que usa el dispositivo y buscar si existe un driver para l. Conexin con el sistema: segn los puertos que tenga la placa base, deberemos elegir un dispositivo con conexin PCI, Mini PCIe o USB. Lo ideal sera una conexin Mini PCIe, ya que as no ocuparamos un puerto USB y adems son muy pequeas. La alternativa podra ser una tarjeta PCI muy pequea, pero es complicado que quepa dentro del vehculo sin problemas. Otra opcin, sera utilizar un dispositivo con conexin USB del tamao de un pendrive. Estndares: deber soportar como mnimo el estndar IEEE 802.11 G y a ser posible el nuevo estndar IEEE 802.11 N. As se garantiza que se alcanzar la mejor velocidad de transmisin posible durante varios aos, puesto que aunque el estndar actual es el G, se encuentra en transicin hacia el N.

1.6. Alimentacin elctrica del sistema

En el diseo del sistema habr que escoger una batera para alimentarlo elctricamente. Habr que tener en cuenta el tipo de fuente que usar la placa escogida y encontrar una batera adecuada. Adems sera interesante que sirviera tambin para alimentar a los motores del vehculo en sustitucin de su batera original para ahorrar espacio. Si esto no fuera posible, en cualquier caso, se podr usar exclusivamente la batera original del vehculo para alimentar a los motores y la nueva batera solamente para el sistema informtico. En el mercado de placas mini/nano/pico-ITX se destacan dos posibilidades en cuanto a fuentes de alimentacin: Alimentacin estndar ATX: la placa se alimenta mediante un conector estndar ATX, algunas tambin con un conector P4. Para reducir el espacio de los sistemas basados en mini-ITX se han desarrollado mini fuentes de alimentacin (ver gura1.6. stas fuentes tienen una entrada en forma de minijack donde conectar un pequeo transformador elctrico como el que usa un ordenador porttil. En el caso de las placas pico-ITX (y muchas de las nano tambin), tienen su propio conector de alimentacin, similar al estndar ATX pero de menor tamao y menos conexiones, aunque se siguen manteniendo los mismos voltajes [28]. Por esto, es posible usar un adaptador para usar una fuente ATX en estas placas. En conclusin, con una batera del voltaje y capacidad adecuadas conectados a la entrada minijack de una mini fuente, se podra alimentar el sistema. Fuente integrada en placa: la fuente de alimentacin esta incluida en la estructura placa, incluyendo en sus conexiones un minijack con el objetivo de alimentar a la placa usando un transformador AD-DC. Igual que en el caso anterior, con la batera adecuada deberamos ser capaces de alimentar al sistema. Por tanto, en cualquier caso, hay que tener en cuenta las caractersticas de la entrada a la fuente para conseguir una batera del voltaje adecuado. En cuanto a la batera, deber disponer de sucientes Wh (Vatios por hora) para alimentar a todos los dispositivos que conectemos junto al consumo de la propia placa base. Sin embargo 35

Captulo 1. Anlisis de requisitos del hardware del sistema informtico

Figura 1.6: Detalle de mini fuente picoPSU-150-XT con conexiones ATX, P4, SATA y PATA no se disponen de datos ables sobre cuanto podrn consumir todos los dispositivos hasta que los tengamos a nuestra disposicin. Por eso, lo nico que puede hacerse es una estimacin del consumo de los dispositivos que vamos a conectar al sistema. Un puerto USB puede suministrar hasta 500 mA a 5 V. Los dispositivos que ms energa demandan podran ser las webcams (posiblemente los 500 mA), mientras que otros no superarn la barrera de los 100mA. Ante la imposibilidad de saber el consumo de estos dispositivos hasta disponer de ellos, se estimar un consumo medio de 250 mA por cada puerto USB. Tambin estimaremos el consumo del dispositivo del disco en torno a los 2,5 W. Este dato se deduce de las observaciones del consumo de los discos SSD analizados en [24]. No obstante es una estimacin del consumo mximo, mientras no se use el disco, posiblemente su consumo ser menor de 1W. En el caso de emplear una memoria ash USB o eSATA el consumo ser muy parecido. Tabla 1.3: Consumo estimado del sistema Componente ratn PS/2 puertos USB dispositivo de disco Cantidad 1 9 1 Total Consumo (W) 0,5 1,25 2,5 Total (W) 0,5 11,25 2,5 14,25

A esta estimacin habra que aadir el propio consumo de la placa y el de los motores del vehculo. Una solucin prctica para alimentar el sistema, sera usar una batera universal de porttil. stas bateras usan conectores minijack, disponen de suciente carga para que funcione un ordenador porttil unas horas con un consumo moderado y se recargan de forma sencilla (incorporan un transformador para esto). 36

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

1.7. Conclusiones del anlisis

En resumen, las conclusiones de este anlisis son las siguientes: 1. El formato ms interesante para el sistema es mini-ITX puesto que mantiene un consumo moderado junto con unas buenas prestaciones. La placa deber tener al menos un puerto PS/2 y al menos entre 8 y 10 puertos USB para intentar no tener que utilizar hubs USB. Si se determina que una placa mini-ITX es demasiado grande para el vehculo, como alternativas encontramos a las nano/pico-ITX, pero con menos prestaciones (CPUs ms lentas y menor nmero de puertos). 2. Los procesadores con mejor rendimiento en la plataforma mini-ITX son el Intel Atom 330 y el VIA Nano. No obstante hay que tener en cuenta tambin el consumo energtico y el precio de los sistemas completos que incluyen estos procesadores. El consumo energtico puede verse fuertemente afectado por el chipset usado. En cambio el precio favorece claramente a Intel, ya que las placas que integran procesadores VIA son ms caras. En el caso de que se necesitara una placa nano/pico-ITX, la variedad de procesadores se limita al VIA C7, generalmente con frecuencias de 1GHz, consiguiendo con ello un consumo muy bajo con respecto a los anteriores sistemas. 3. El disco ptimo para el sistema sera un disco SSD, pero son caros, por lo que una memoria ash con interfaz eSATA podra ser una buena alternativa de menor rendimiento y tamao. Como ltima opcin, se puede usar una memoria ash USB de alta velocidad. 4. Si es posible se escoger una placa con un puerto Mini PCIe, con el objetivo de conectar una tarjeta de conexin a red inalmbrica Wi-Fi en dicha interfaz, por sus reducidas dimensiones. Como alternativa se podra usar un pequeo dispositivo USB que cumpla esta funcin. 5. Se usar una batera universal para porttil con unas dimensiones adecuadas, as como caractersticas elctricas que la hagan compatible con la fuente de alimentacin de la placa base y el consumo energtico de todos los dispositivos. El consumo de los dispositivos que se han propuesto conectar al sistema se ha estimado en 14W, a lo que hay que aadir el consumo de la placa que se escoja en el diseo y el de los motores del vehculo. El objetivo principal de esta batera ser alimentar al sistema informtico, y, si es posible, a los motores del vehculo.

37

Captulo 2

Diseo del hardware del sistema informtico

Una vez realizado el anlisis del hardware que era adecuado a las restricciones del proyecto, el siguiente paso era disear el hardware del sistema informtico. Es decir, escoger nalmente qu hardware formar parte del sistema nal. Adems, es necesario justicar este gasto ante la Universidad presentando factura pro forma de lo que se necesita. Por tanto, se deber encontrar un distribuidor local con el que obtener la factura y, nalmente, el hardware. Para ello, en un primer momento se observ el hardware disponible en algunas tiendas online para elaborar varias conguraciones distintas del sistema. El objetivo por una parte, es determinar el precio aproximado de la conguracin a partir del precio de la tienda online. Por otra parte, comparar diferentes conguraciones para determinar cual es ms adecuada como sistema nal. Es un objetivo que el hardware empleado por el vehculo sea lo ms barato posible, cumpliendo las restricciones de prestaciones, tamao y consumo energtico del sistema. Las distintas conguraciones generadas pueden consultarse en el apndice B Diseo de conguraciones del sistema para un mayor detalle de las opciones contempladas. La ltima seccin de este captulo corresponde al estudio acerca del uso de un ratn mecnico como encoder.

2.1. Conguracin escogida

La conguracin escogida a mutuo acuerdo entre el tutor y el alumno fue la siguiente: Tabla 2.1: Placa ZOTAC ION ITX-A-E Atom 330 con disco y batera universal Componente Placa RAM Wi-Fi Fuente Transformador Memoria ash eSATA Batera universal Referencia ZOTAC ION ITX-A-E Atom 330 2 x DDR-2 1Gb 800 Mhz Incluido en placa Incluido en placa Incluido en placa OCZ 8 Gb - eSATA - Throttle XPAL Power 8000 Total Precio 156e 35e 36e 109e 336e

39

Captulo 2. Diseo del hardware del sistema informtico Frente a la conguracin presentada en el apndice, se incluye un pendrive con interfaz eSATA y una batera universal. Los motivos por los que se escogi esta conguracin son: Prestaciones de la placa: potencia del procesador, doble canal de memoria RAM y nmero de puertos USB. La placa incluye fuente de alimentacin y tarjeta Wi-Fi mini PCIe integrada, lo que provoca un ahorro en costes a comprar esos componentes por separado adems de asegurar la compatibilidad de estos componentes entre s. Tras determinar el hardware que queramos obtener, se contact con el distribuidor Odisea Informtica, ubicado en Vecindario, para obtener factura pro forma y, una vez aprobado el gasto con la comisin pertinente, el hardware.

2.2. Estimacin del consumo de energa del sistema

Tal y como se estudi en la fase de anlisis, en el apartado 1.6 Alimentacin elctrica del sistema, el consumo del sistema aproximado ser el consumo de la placa base junto con el de los dispositivos conectados a ella: Tabla 2.2: Consumo estimado del sistema actualizado Componente placa base ratn PS/2 puerto USB dispositivo de disco Cantidad 1 1 9 1 Total Consumo (W) 25 0,5 1,25 2,5 Total (W) 25 0,5 11,25 2,5 39,25

Por tanto el consumo del sistema se sita en torno a los 40W. Hay que tener en cuenta que, en muchos casos, no se emplearn tantos dispositivos USB y por ello la mayora del tiempo se tenga un consumo menor. La placa escogida tiene una fuente integrada con una entrada en forma de minijack de 19V. La batera escogida, XPAL POWER XP8000 tiene precisamente una capacidad de 40Wh y soporta en la salida de 19V un mximo de 2A. Por ltimo hay que tener en cuenta dos variables ms. Por un lado, se ha realizado una estimacin al alza del consumo, posiblemente los dispositivos consuman menos de lo que ha predicho. Por otro lado, se quiere utilizar esta batera para alimentar tambin al motor del vehculo. Estas variables no pueden determinarse en el momento de realizar este diseo y pueden hacer que el consumo vare.

2.3. Uso de un ratn mecnico como codicador ptico

Puesto que uno de los objetivos del proyecto es el bajo coste, se propone emplear como codicador ptico (encoder) para los motores del vehculo un ratn mecnico, ms conocido como 40

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala ratn de bola. Estos ratones cuentan con dos codicadores pticos, uno para cada eje de coordenadas, que indican su movimiento en incrementos al controlador del ratn. De esta forma, se puede interpretar mediante software dicho incremento, como por ejemplo, para mover el cursor en la pantalla. La idea es aprovechar el hardware de un ratn, para obtener la lectura de los incrementos mediante software, y calcular la velocidad de las ruedas del vehculo. No obstante, se debe estudiar la forma en la que el ratn comunica los datos al ordenador, para determinar si es posible emplearlo para el uso descrito. Por ejemplo, las ruedas del vehculo podran ir demasiado rpido, impidiendo una correcta lectura por este medio. El objetivo de este anlisis es determinar si es viable utilizar uno ratn mecnico para dicha funcin, estudiando el protocolo estndar de los ratones PS/2 y analizando como calcular la velocidad a partir de los datos obtenidos del ratn, adems de desarrollar una librera con el objetivo de poder trabajar a bajo nivel con dicho protocolo. Por ltimo, se disearn y ejecutaran experimentos que demuestren la viabilidad de usar el ratn como codicador ptico utilizando la librera desarrollada.

2.3.1. Interfaces y protocolos

Los ratones mecnicos pueden utilizar tres tipos de interfaces: Puerto de serie RS232: los ratones que utilizan este puerto disponen de una amplia variedad de protocolos: protocolo Microsoft, protocolo Microsoft de 3 botones, protocolo Logitech, protocolo Mousesystems, protocolo Sun y protocolo MM. Puerto PS/2: los ratones de este puerto utilizan un protocolo bsico estndar de tres botones. Este es el protocolo con el que se trabajar.Tambin existen extensiones del protocolo que permiten emplear una rueda de desplazamiento en el ratn y un cuarto y quinto botn. Puerto USB: aunque son difciles de encontrar, existen ratones mecnicos que emplean este puerto. En este caso se emplea el estndar USB HID (Dispositivo de Interfaz Humana), que se dise con el objetivo de emplearlo con todo tipo de dispositivos que precisarn de la interaccin con una persona. Es empleada por ratones, teclados, joysticks, etc.

2.3.2. Descripcin del protocolo de ratn PS/2

Consultar el apndice A Protocolo del ratn PS/2.

2.3.3. Consideraciones tcnicas

Atendiendo a la especicacin del protocolo, puede denirse un lmite terico a la capacidad del ratn para detectar el movimiento. Los lmites dependen de los parmetros siguientes: Modo de funcionamiento: se puede trabajar en dos modos. En el modo Stream, el ratn enva paquetes al controlador del ratn cada vez que se produce un cambio en su estado, es decir, cada vez que se mueve o se pulsa un botn. En el modo Remote, se solicita el envo de un paquete al ratn mediante un comando del protocolo. 41

Captulo 2. Diseo del hardware del sistema informtico Frecuencia de muestreo: indica la frecuencia con la que el ratn podr enviar paquetes al controlador. Por defecto, 100 muestras/seg. Mximo 200 muestras/seg. Resolucin: afecta a como se incrementan o decrementan los contadores de movimiento del ratn en funcin de los pulsos generados por el movimiento de las ruedas. Por defecto tiene un valor de 4 unidades/mm, pero se puede congurar con los valores 1, 2, 4 y 8 unidades/mm. Escalado: el escalado 2:1 modica la cantidad de movimiento que enva el ratn en los paquetes, por tanto se congurar el ratn con un escalado 1:1. Teniendo en cuenta el paquete de datos que enva el ratn, la mxima cantidad de movimiento que puede detectar el ratn entre paquetes antes de desbordar los registros es de 8 bits, ms 1 bit para el signo en complemento a dos. Esto implica 255 pulsos por cada paquete. Si tericamente, el protocolo posibilita el envo de 200 paquetes por segundo, entonces el ratn podra detectar 51000 pulsos por segundo. Sin embargo, muchos ratones directamente reportan el movimiento en los 8 bits del registro del paquete para el movimiento de X e Y en complemento a dos. Aunque esta prctica es compatible con el protocolo estndar, siempre que en el byte de status se active el bit de signo correspondiente, provoca que en cada paquete slo puedan utilizarse 7 bits (en lugar de 8) para detectar movimiento ms el bit de signo. Esto signica 127 pulsos por paquete y un mximo supuesto de 25400 pulsos por segundo. Para el desarrollo bajo Linux, se disponen de una interfaz directa con el ratn por medio de un chero localizado en /dev/input/mouseN, donde N es un nmero entero que diferencia a cada ratn conectado al sistema. Esta interfaz emplea el protocolo PS/2 independientemente del tipo real del ratn por razones de compatibilidad con las aplicaciones. En este caso, y bajo el ncleo 2.6, el ratn siempre se encuentra en la siguiente conguracin: modo Stream, reporte de datos activo, resolucin 8 unidades/mm y frecuencia de muestreo 200. Aunque pueden enviarse comandos al ratn por medio de dicha interfaz, el nico comando que funciona es el de leer el estado del ratn. Por eso, no puede cambiarse directamente con el protocolo PS/2 la conguracin establecida en el ratn por el driver. Si estamos trabajando con un ratn de puerto PS/2, puede obtenerse pleno control del ratn cambiando el driver para acceder al puerto en modo raw. Para ello se utiliza el driver del mdulo serio_raw. La interfaz en este caso ser el chero /dev/serio_rawN, lo que inhabilita el chero correspondiente /dev/input/mouseN. Con este driver, el ratn responde correctamente a los comandos de conguracin. No obstante si se trabaja en modo Stream, hay que tener en cuenta que el ratn sigue enviando paquetes al nuevo driver y este los almacena en un buffer de lectura. Si hay datos no ledos en este buffer y enviamos un comando al ratn, en lugar de leer el byte de respuesta al comando, posiblemente, leamos un byte de un paquete de movimiento. Esto puede producir situaciones no deseadas y se debe tener en cuenta. Para cambiar el driver empleado en el puerto puede utilizarse el script siguiente:

#Activa el protocolo estandar en el raton modprobe -r psmouse modprobe -v psmouse proto=bare modprobe -r psmouse

42

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

#Activa el modulo serio_raw modprobe -r serio_raw modprobe -v serio_raw #Activa serio_raw como controlador del puerto serio1 echo -n serio_raw > /sys/bus/serio/devices/serio1/drvctl dmesg | grep "serio_raw" chmod uga+wr /dev/serio_raw0
Si trabajamos con un ratn de puerto USB, funciona con otro protocolo, USB HID http://www. usb.org/developers/hidpage/. No obstante, como se ha descrito es posible obtener una lectura equivalente a la del protocolo PS/2 con la interfaz correspondiente en /dev/input/mouseN, aunque seguiremos sin poder enviar comandos del protocolo PS/2 al ratn. La interfaz seguir en modo Stream, con una resolucin de 8 unidades/mm, aunque, en este caso, se puede congurar la frecuencia con la que el controlador se comunica con el ratn. Esto se realiza con el parmetro mousepoll del mdulo usbhid de la forma siguiente: Si usbhid est integrado en el kernel:

echo -n "N" > /sys/module/usbhid/parameters/mousepoll

Si usbhid est compilado como mdulo:

modprobe -r usbhid && modprobe usbhid mousepoll=N

Donde N son milisegundos y puede tomar los siguientes valores: 1 / 2 / 4 / 8 / 10 ms, que equivale a una comunicacin de 1000 / 500 / 250 / 125 / 100 paquetes/segundo, respectivamente. No obstante estos valores no son compatibles con todos los ratones por lo que es necesario probar a que frecuencia mxima pueden funcionar. As mismo, hay que tener en cuenta que cuanta ms frecuencia, ms ocupado estar el procesador en atender estos paquetes, restando capacidad de proceso para otras tareas.

2.3.4. Desarrollo de librera: mouselib

Se desarroll una pequea librera en C++ denominada mouselib, que emplea el protocolo estndar de ratn PS/2. El desarrollo se hizo sobre una clase denominada Mouse, implementada en dos cheros: un .h para la descripcin de la clase y un .cpp para la implementacin. El diagrama de clases UML de la librera puede verse en la gura 2.1. La librera funciona sobre las interfaces de dispositivo que generan salidas en el formato del protocolo de ratn PS/2 estndar: /dev/input/mouseN, /dev/serio_rawN, /dev/psaux y /dev/input/mice. La librera se ha usado para realizar los experimentos con el ratn.

2.3.5. Experimentacin
Para poder calcular la velocidad del movimiento, se debe tener en cuenta como lo mide un ratn mecnico. En un ratn de este tipo, se dispone de un emisor y un receptor ptico colocados uno frente al otro. En el espacio entre los dos se encuentra una rueda con ranuras, de forma 43

Captulo 2. Diseo del hardware del sistema informtico

Figura 2.1: Diagrama de clases UML de mouselib que al producirse movimiento en dicha rueda, sus ranuras interrumpen o permiten la emisin y recepcin del haz ptico, produciendo una serie de pulsos elctricos (tics) que provocan un cambio en los registros internos del ratn. Cuando el ratn reporta el movimiento, lo hace con los contenidos del registro del eje X y del eje Y, entre otros datos. Dependiendo de la resolucin, los tics producen cambios mayores o menores en dichos registros. En la gura 2.2 puede verse una imagen donde se observa claramente el emisor, el receptor ptico y la rueda ranurada de un ratn mecnico.

Figura 2.2: Detalle de emisor y receptor ptico en un ratn mecnico Para calcular la velocidad, es necesario conocer el nmero exacto (o lo ms exacto posible) de tics que se produce por segundo, ya que un tic signicar un incremento de grados, que ser igual a 360 divido por el nmero de ranuras de la rueda. As, se puede calcular la velocidad con la expresin:

v = r = r

tics grados 2 seg tic 360

Donde r es el radio de la rueda y los grados/tic se calculan dividiendo 360 entre el nmero de ranuras de la rueda. 44

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala Para ver como como afectaba el modo y la resolucin del ratn al movimiento reportado, se realizaron los siguientes experimentos utilizando un ratn PS/2 Genius con ruedas de 40 ranuras: Experimento con el ratn en modo stream: Reset del ratn, cambio a frecuencia 200, activar envo de paquetes.. Para cada resolucin, leer y acumular el movimiento reportado por el ratn para una vuelta completa de la rueda del encoder. Repetir la operacin cinco veces para reducir los errores de mover la rueda con la mano. Experimento con el ratn en modo remote: Reset del ratn, cambio a frecuencia 200, cambio a modo Remote. Para cada resolucin, solicitar paquetes continuamente al ratn con el comando Read Data y acumular el movimiento reportado para una vuelta completa de la rueda del encoder. Repetir la operacin cinco veces para reducir los errores de mover la rueda con la mano. Los resultados de los experimentos son los siguientes: Tabla 2.3: Ratn congurado en modo stream Resolucin 1 unidad/mm 2 unidades/mm 4 unidades/mm 8 unidades/mm Medida 1 20 40 81 168 Medida 2 20 40 84 163 Medida 3 21 41 82 161 Medida 4 19 40 80 165 Medida 5 19 41 81 158

Tabla 2.4: Ratn congurado en modo remote Resolucin 1 unidad/mm 2 unidades/mm 4 unidades/mm 8 unidades/mm Medida 1 20 40 80 155 Medida 2 20 40 81 158 Medida 3 19 41 79 162 Medida 4 20 40 80 166 Medida 5 19 41 82 160

Se comprueba que las medidas no se ven afectadas por el modo de funcionamiento, aunque si por la resolucin escogida. Para una resolucin de 2 unidades/mm, encontramos que el movimiento reportado por el ratn equivale al nmero de ranuras de la rueda, es decir, 40. Por tanto, sera la resolucin ms adecuada para hacer el clculo de la velocidad. Por otra parte puede verse como las distintas resoluciones obtienen medidas equivalentes pero de mayor o menor magnitud. As con una resolucin de 1 unidad/mm obtenemos la mitad de movimiento que con 2 unidades/mm, con 4 unidades/mm obtenemos el doble y con 8 45

Captulo 2. Diseo del hardware del sistema informtico unidades/mm el cudruple. Por tanto, es posible convertir la medida entre una resolucin y otra, por lo que, aunque seamos incapaces de enviar comandos al ratn para cambiar la resolucin se podra calcular la equivalencia con la resolucin de 2 unidades/mm para realizar el clculo de la velocidad. Esta conversin puede establecerse en la expresin para el clculo de la velocidad, cambiando consecuentemente el trmino grados/tic. Esta prueba, se repiti con un ratn mecnico USB del fabricante Dell con una rueda de 60 ranuras. Los resultados obtenidos rondan los 240 tics. Es decir, el ratn funciona a una resolucin de 8 unidades/mm. Por ello, con un ratn de este tipo se deber realizar una conversin de los tics para hacer los clculos, ya que en un ratn USB no puede cambiarse la resolucin.

2.3.6. Conclusiones
Para calcular la velocidad del movimiento con un ratn mecnico se puede trabajar tanto en modo Remote como en modo Stream bajo una resolucin de 2 unidades/mm, ya que esta resolucin ofrece equivalencia directa entre el desplazamiento de las ranuras y el movimiento reportado por el ratn. Sin embargo, se puede trabajar tambin a otras resoluciones y convertir el movimiento reportado multiplicando o dividiendo en funcin de la resolucin. A la hora de programar existen diferencias importantes en funcin del modo. Si se trabaja en modo Stream hay que tener en cuenta que el ratn seguir enviando paquetes al buffer independientemente de si un programa lo est leyendo o no, esto puede provocar lecturas errneas o problemas a la hora de recibir el byte de conrmacin del ratn (ACK) ante un comando. Adems, por la misma naturaleza del modo Stream las lecturas son bloqueantes si no se produce movimiento. Por el contrario, en modo Remote, al solicitar un paquete siempre se obtiene un paquete de movimiento inmediatamente y, mientras no se solicite un paquete al ratn no se acumularn datos en el buffer. A cambio, si se produce demasiado movimiento sin haber solicitado un paquete al ratn, es ms probable que se produzca un desbordamiento del registro interno del ratn. Es necesario establecer en que formato enva los datos el ratn, si usan el formato del estndar, es decir un bit de signo y 8 bits indicando el movimiento, o bien, directamente los 8 bits que indican el movimiento en complemento a dos. En el segundo caso, el de todos los ratones probados, slo se disponen de 7 bits para indicar el movimiento lo que supone que el registro se desborda en 127. Si la rueda se mueve lo sucientemente rpido, en la resolucin mayor podra ser complicado evitar el overow del registro. Para evitar esto, si se utiliza un ratn con puerto PS/2 puede disminuirse la resolucin, si se utiliza un ratn USB puede aumentarse la frecuencia de muestreo del mdulo usbhid con el parmetro mousepoll. Otra alternativa, consiste en tapar ranuras de la rueda del encoder para que se produzcan menos tics por vuelta y, por ello, menos posibilidades de que se desborden los registros internos del ratn.

46

Captulo 3

Anlisis y eleccin del sistema operativo

Una parte del diseo software del sistema informtico del vehculo se centra en escoger su sistema operativo. Como se va a emplear software libre, el sistema operativo escogido es GNU/Linux. Sin embargo, al referirnos a GNU/Linux, nos referimos bsicamente al ncleo del sistema operativo. A diferencia de otros sistemas operativos, Linux se distribuye en forma de distribuciones que parten del ncleo de Linux y aaden software adicional para satisfacer las necesidades de un grupo concreto de usuarios. Al ser software libre, existe una amplia variedad de distribuciones, orientadas a todo tipo de sistemas y usuarios. Por todo esto, preciso determinar que distribucin instalaremos en el sistema.

3.1. Anlisis de requisitos del sistema operativo

En este anlisis se determinar que requisitos debera cumplir una distribucin Linux para ser adecuada para el sistema, basndose en el hardware que se va a utilizar y en las necesidades de la plataforma. Con estos requisitos, se buscarn distribuciones que cumplan al menos una parte de ellos. Los requisitos necesarios en la distribucin se pueden dividir en dos vertientes: aquellos provenientes del propio hardware del sistema y los que se derivan del uso al que se va a destinar el sistema nal. 3.1.0.1. Requisitos derivados de las caractersticas del hardware empleado Recursos hardware ajustados: el sistema no dispone de excesivos recursos debido a la necesidad de un sistema pequeo y de bajo consumo. Por ello, la distribucin no debe consumir muchos recursos y se deben ahorrar, de forma que queden disponibles a las aplicaciones. Espacio en disco limitado: el sistema utilizar un disco basado en memoria ash. Estos discos disponen de menos espacio comparados con un disco duro de tecnologa magntica, por lo que es preferible una distribucin que ocupe poco espacio en disco o que, al menos, pueda realizarse una instalacin mnima de paquetes de la misma. Compatibilidad hardware: para intentar asegurar el soporte hardware, desde el punto de vista del sistema operativo, las distribuciones debern utilizar una versin mayor del ncleo de Linux actualizada, actualmente la 2.6. No obstante, este aspecto no es tan relevante como los anteriores, puesto que no se descarta tener que instalar drivers o compilar un nuevo ncleo para soportar todo el hardware necesario. 47

Captulo 3. Anlisis y eleccin del sistema operativo Debido a estos requisitos es interesante buscar distribuciones orientadas a equipos limitados en recursos, normalmente orientadas a usarse en ordenadores antiguos, y que ocupan poco espacio en disco. 3.1.0.2. Requisitos derivados del uso nal del sistema

Estabilidad: el sistema operativo debe ser estable y no provocar problemas a los posibles experimentos que se hagan sobre la plataforma. Hay que tener en cuenta que el sistema no va a disponer permanentemente de una pantalla en la que visualizar cualquier problema relacionado con el sistema operativo. Por tanto, se necesita de un sistema estable que necesite un mantenimiento mnimo. En este sentido, lo ideal es que el sistema operativo fuera como un rmware, de forma que solo necesite actualizarse para solucionar problemas puntuales o mejorar sus caractersticas. Repositorios de paquetes: los repositorios deben ser amplios y disponer de un mnimo de actualizaciones. Siempre es ms sencillo descargar software de los repositorios que compilarlo, as el manejador de paquetes resuelve las dependencias del software automticamente sin intervencin del usuario. Soporte: en caso de tener problemas con la distribucin que no se logren resolver, a dnde y quin se acude?. En la mayora de distribuciones se ofrece soporte mediante foros de discusin, listas de correo, correo electrnico u otros medios en lnea. Es importante determinar el grado de participacin en estas herramientas, ya que normalmente es la propia comunidad de usuarios la que ayuda a resolver los problemas. Tambin es importante si este soporte puede hacerse en espaol. As mismo, es necesario conocer cuanto tiempo ofrecen soporte, incluyendo actualizaciones, para una versin de la distribucin. Por ltimo, hay que estudiar la documentacin que se ofrece. Experiencia: es interesante tener en cuenta la experiencia y opinin de los usuarios que trabajarn sobre la plataforma nal en materia de distribuciones Linux. En estos requisitos, las distribuciones ms veteranas y extendidas como por ejemplo, Debian o Red Hat, tienen ventaja sobre el resto. Ya que llevan ms aos en el mercado y disponen de una amplia comunidad tras ellas, que ayudan en su soporte, manteniendo el repositorio de paquetes, etc.

3.2. Anlisis de distribuciones

En base a los requisitos del apartado anterior, se ha determinado analizar varias distribuciones de equipos limitados en recursos y de propsito general.

3.2.1. Distribuciones orientadas a equipos limitados en recursos

Las distribuciones de este tipo siempre han tenido demanda por los usuarios. Es interesante ver como ests distribuciones estn optimizadas para ejecutarse en equipos con cierta antigedad, sin ralentizarse, ofreciendo un entorno de escritorio completo donde navegar por Internet, editar documentos, etc. Con este tipo de distribuciones es posible reciclar ordenadores antiguos, por ejemplo, para usos educativos. En el caso del sistema informtico del vehculo, una distribucin con estas caractersticas puede ofrecer un mejor rendimiento en el sistema al tener un hardware ms limitado del normal. 48

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.2.1.1. Slitaz Slitaz es una pequea distribucin pensada para ejecutarse rpidamente en sistemas con 256MB de RAM. Al iniciarse se carga todo el sistema operativo en la memoria, aumentando as la velocidad. La instalacin de Slitaz ocupa apenas 100MB. Los repositorios de paquetes de esta distribucin son pequeos en comparacin con otras distribuciones. El tiempo de soporte de cada versin no est denido, disponiendo de un foro y lista de correo, en ingls. La documentacin de la distribucin no es amplia y se centra mayormente en aspectos de instalacin y conguracin general del sistema. 3.2.1.2. Puppy Linux Puppy Linux es una distribucin que se carga y ejecuta completamente en slo 64MB de RAM, consiguiendo as aumentar notablemente la velocidad. Est pensada para ejecutarse como sistema operativo sobre un pendrive. Tanto la documentacin como los repositorios no son tan amplios como en otras distribuciones. El soporte de cada versin no est denido, existiendo un foro de soporte en ingls.

3.2.2. Distribuciones de propsito general

Las distribuciones de propsito general tienden a ofrece un sistema operativo preparado para usarse en ordenadores de escritorio, incluyendo interfaces grcas y paquetes de software especcos. Normalmente estas distribuciones requieren de ms recursos que las anteriores. 3.2.2.1. CentOS CentOS es una distribucin basada en los fuentes libres de Red Hat, que es una distribucin empresarial de pago orientada a servidores. La idea es que CentOS sirva como sistema operativo empresarial sin los costes aadidos que se pagan en soporte. La instalacin es voluminosa, aunque es posible realizar una instalacin mnima. Al basarse en una distribucin empresarial, se trata de una distribucin muy estable, si bien, los paquetes de sus repositorios no se actualizan tanto ni son tan numerosos como en otras distribuciones. Dispone de una gran comunidad activa y el soporte de cada versin es de 7 aos. Tambin tiene listas de correo en espaol. La documentacin de que dispone se basa mayoritariamente en la propia de Red Hat y est en ingls. 3.2.2.2. Debian Debian es una distribucin Linux ampliamente utilizada en todo el mundo y en la que estn basadas otras distribuciones. Se trata de una distribucin estable con unos amplios repositorios de paquetes. Al ser una distribucin veterana, la comunidad que hay detrs de ella es enorme y dispone de una amplia documentacin. La distribucin est estructurada en tres versiones distintas: stable que corresponde a la versin actual de la distribucin, testing que corresponde a la distribucin en pruebas de la siguiente versin estable y unstable que es la versin donde se prueban todos los paquetes antes de pasar a testing. Se lanza una nueva versin estable aproximadamente cada dos aos, mantenindose el soporte a la anterior versin stable durante un ao. Dispone de listas de correo y documentacin en espaol. 3.2.2.3. Ubuntu Ubuntu es una distribucin basada en Debian y orientada para usuarios con pocos conocimientos de Linux, como alternativa a Windows. Dispone de un amplio soporte hardware, grandes 49

Captulo 3. Anlisis y eleccin del sistema operativo repositorios actualizados regularmente y una amplia comunidad tras de s. Es posible realizar una instalacin mnima en la edicin de servidor. Normalmente, el soporte es de 18 meses (ao y medio) en cada versin, pero cada 2 aos lanzan una versin LTS (Long Term Support) cuyo soporte es de 2 aos en la edicin de escritorio y de 5 en la de servidor. Est versin est ms probada que las otras y es ms estable. Dispone de foros, listas de correo y una documentacin amplia, todo ello en espaol.

3.2.3. Conclusiones del anlisis

Las distribuciones orientadas a equipos limitados en recursos, pueden ser una buena opcin para el sistema, no obstante, el soporte y documentacin del que disponen no puede compararse con el de otras distribuciones. Lo malo de estas ltimas es que al ser de propsito general, no estn optimizadas para consumir pocos recursos. An as, si se realiza una instalacin mnima de paquetes de una de estas distribuciones y se adapta al sistema, es muy posible que el resultado nal sea suciente para el hardware del equipo. De esta forma se ganaran las ventajas de los dos tipos de distribuciones: el consumo limitado de recursos y el soporte, documentacin y actualizaciones de las distribuciones ms veteranas. Las distribuciones que se ha decidido probar son Puppy Linux, CentOS y Debian. Se descarta inicialmente Slitaz ya que se espera que se pueda usar una distribucin con mejor soporte, aunque consuma algunos recursos ms. Ubuntu se descarta en favor de Debian, ya que Ubuntu es una distribucin basada en Debian, pero es menos congurable en favor de una mejor experiencia de usuario y consume ms recursos. En cambio con Debian, se puede realizar una instalacin mnima fcilmente.

3.3. Eleccin de distribucin

Una vez analizadas que distribuciones Linux se deban probar, se procedi a instalarlas en el sistema. Es necesario denir ms ampliamente que parmetros se van a probar de cada distribucin con el objetivo de poder compararlas.

3.3.1. Denicin de parmetros de prueba

El objetivo de estos parmetros es determinar que distribucin es ms adecuada balanceando el consumo de recursos, el soporte de hardware/software y el mantenimiento de cada distribucin en cuanto a repositorios de paquetes, nuevas versiones de la distribucin, soporte tcnico y documentacin. A continuacin se incluyen los parmetros que se analizarn en cada una de las tres distribuciones: Instalacin mnima: si es posible realizar una instalacin de la distribucin con un mnimo de paquetes. Versin del ncleo de Linux empleada: actualmente la ltima versin estable del ncleo en kernel.org es la 2.6.32.9 a febrero de 2010. Como referencia, la versin 2.6.30 fue lanzada en junio de 2009. Es importante que el ncleo est compilado con la opcin SMP (Symmetric Multi-Processing) activada, para poder aprovechar los dos ncleos del procesador Atom 330. 50

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala Soporte hardware inherente: el soporte de hardware est directamente relacionado con la versin del ncleo y los controladores incluidos en la distribucin. Muchas veces los controladores no se incluyen en las distribuciones por ser privativos y no utilizar licencias libres. Sin embargo, en muchas ocasiones no existe alternativa libre al controlador que permita utilizar el hardware. En concreto el soporte para la tarjeta Wi-Fi viene dado por el driver ath9k, incorporado al ncleo desde la versin 2.6.271 . Consumo de disco: cunto espacio en disco consume la instalacin mnima de la distribucin. Consumo de memoria: cunta memoria consume la instalacin mnima de la distribucin con el sistema recin iniciado. Actualizaciones de la distribucin: cada cuanto aproximadamente se lanza una nueva versin de la distribucin. Repositorio de paquetes: formato de los paquetes, amplitud de los repositorios de la distribucin y actualizacin de los mismos. Soporte: se volver a hacer hincapi en el tipo de soporte ofrecido por cada distribucin, calidad de la documentacin, comunidad de usuarios, etc. Tiempo de arranque: si el tiempo de arranque es demasiado alto sera un factor negativo a tener en cuenta. Se medir desde que se inicia la entrada correspondiente en el gestor de arranque GRUB, hasta que el sistema solicita el login al usuario.

3.3.2. Pruebas de distribuciones

En este apartado, se proceder a probar las distribuciones instalndolas en el sistema, para determinar cual es la ms adecuada segn los parmetros denidos anteriormente. 3.3.2.1. Puppy Linux 4.3.1 Esta distribucin est orientada a usarse en sistema con hardware antiguo. Para ello se carga completamente en la memoria consiguiendo ser muy rpida. Tanto al instalarse sobre un disco como al utilizarse como Live CD, la distribucin utiliza una imagen completa del sistema de archivos contenida en un chero para cargarla en memoria. Para poder guardar nuevos archivos, se utiliza un chero representando otro sistema de cheros para los archivos de conguracin, nuevos programas, etc. Los dos sistemas de cheros se unican mediante UnionFS2 . Instalacin: sencilla y preparada para hacerse sobre todo tipo de discos. Aunque la instalacin en s ocupa muy poco espacio, no es posible realizar una instalacin mnima prescindiendo de muchos paquetes innecesarios. Kernel: 2.6.30.5 SMP i686.
1 2

http://linuxwireless.org/en/users/Drivers/ath9k

UnionFS permite fusionar dos sistemas de cheros para que en la prctica parezca que son un nico sistema. De esta forma se combinan los archivos que se encuentran en la misma carpeta en ambos sistemas de cheros. Las coincidencias se corrigen dando preferencia a uno de los dos sistemas-

51

Captulo 3. Anlisis y eleccin del sistema operativo Hardware: el hardware funciona incluida la tarjeta Wi-Fi, conexin de dispositivos USB, etc. Disco: en conjunto la distribucin slo utiliza cinco cheros con toda la informacin necesaria, ocupando 104,5 MB en total. El chero imagen donde se guardan los archivos nuevos ocupa un espacio jo indicado cuando se crea. El tamao recomendado es de 512 MB, por lo que dicho espacio en disco tambin ser ocupado. Memoria: el sistema arrancado y corriendo el escritorio consume 394 MB de RAM. Hay que tener en cuenta que hay varios sistemas de cheros montados en RAM que consumen espacio adicional, pero que mejoran el rendimiento del sistema. Actualizaciones de la distribucin: no tienen periodicidad ja. Paquetes: el repositorio de paquetes es pequeo y la distribucin utiliza un sistema propio de paquetes (pet), por tanto, ser necesario instalar bastante software de forma manual. Soporte: dispone de una wiki, varios foros de discusin y documentacin sobre el manejo de la distribucin. Tiempo de encendido: 36 segundos. 3.3.2.2. CentOS 5.4

CentOS es un sistema empresarial completamente libre basado en los fuentes de libres de Red Hat. Instalacin: sencilla pero puede ser muy grande con 6 CD o un DVD. Para conseguir instalar el sistema nicamente con el primer disco de la distribucin, hay que desactivar la instalacin de todos los paquetes, dejando nicamente un sistema bsico mnimo. Kernel: 2.6.18-164 SMP i686. Hardware: funciona todo excepto la Wi-Fi. Para obtener un kernel que soporte la tarjeta habra que compilarlo, ya que la distribucin no ofrece imgenes del kernel precompiladas de versiones ms actuales. Disco: ocupa aproximadamente 800 MB. Memoria: consume poca memoria, 86 MB de RAM. Actualizaciones de la distribucin: depende directamente de las actualizaciones de Red Hat, con una nueva versin cada 2 aos y actualizaciones menores cada 6 meses. Paquetes: el repositorio de paquetes es amplio, no obstante se utilizan versiones antiguas por motivos de estabilidad, aunque es posible aadir repositorios de terceros para conseguir versiones ms actualizadas. CentOS proporciona paquetes adicionales a los suministrados originalmente por Red Hat. El formato de los paquetes es rpm. Soporte: cada versin de la distribucin tiene soporte para 7 aos, con actualizaciones menores cada 6 meses. Dispone de documentacin propia y procedente de Red Hat, wiki, lista de correo y foros. Tiempo de encendido: 41 segundos. 52

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.3.2.3. Debian 5.0.4 stable Debian es una distribucin libre organizada en un sistema de tres versiones: La versin stable es la versin actual de la distribucin y es la ms estable de todas. Aproximadamente cada dos aos se lanza una nueva versin estable y se mantiene el soporte para la anterior versin estable aproximadamente por un ao. La versin testing corresponde a la versin en desarrollo de la siguiente versin estable. Es menos estable que la versin anterior pero a cambio ofrece actualizaciones ms recientes del software. La versin unstable es donde se prueban los paquetes antes de entrar en la versin testing y por ello es la ms inestable de todas. Ya que en el sistema se precisa de estabilidad, se ha probado la versin stable de Debian. Instalacin: utilizando la versin netinstall, descarga e instala una instalacin mnima a travs de Internet. Si se quiere, se pueden seleccionar ms paquetes durante la instalacin, como por ejemplo el entorno grco. Kernel: inicialmente 2.6.26-2 SMP i686. Posteriormente se instal la 2.6.32 SMP i686 para comprobar el soporte del hardware Wi-Fi. Hardware: funciona todo, incluyendo la Wi-Fi, previa instalacin de una imagen del ncleo actualizada. Disco: ocupa aproximadamente 800 MB. Memoria: consume muy poca memoria, 33 MB. Actualizaciones de la distribucin: cada 2 aos aproximadamente se lanza una nueva versin estable. Paquetes: repositorios muy amplios basados en paquetes Debian (deb). Posibilidad de emplear numerosos repositorios adicionales tanto de la distribucin como de terceros. Soporte: aproximadamente 3 aos para cada versin estable. Disponible documentacin propia, wiki, listas de correo y foros. En la actualidad una derivacin de Debian, Ubuntu, est teniendo mucho xito en el mercado. Al ser distribuciones parecidas, es posible aprovechar tambin su documentacin y su comunidad de usuarios para resolver posibles problemas. Tiempo de encendido: 13 segundos.

3.3.3. Eleccin de distribucin

Puppy Linux est ajustada al mximo para conseguir un rendimiento muy bueno al cargar todo el sistema en memoria, si bien por ello consume mucha ms memoria que las otras dos distribuciones. Esto tambin es un inconveniente, puesto que se requiere la posibilidad de congurar y adaptar la distribucin. Al no usar un sistema convencional de sistema de archivos diculta 53

Captulo 3. Anlisis y eleccin del sistema operativo cualquier modicacin en la misma. Su sistema de paquetes es muy limitado y se incluye bastante software innecesario preinstalado. Aunque tiene una pequea comunidad que mantiene esta distribucin, no presenta tanta documentacin y soporte como las otras dos alternativas. Por todo esto, se descarta Puppy Linux para usarse como distribucin del sistema. Por tanto, la eleccin queda entre las otras dos distribuciones. Tanto la instalacin como el consumo de disco y memoria en ambas es similar. El soporte hardware, tal y como se indic, est muy ligado a la versin del ncleo que se emplee. En los repositorios de CentOS se encuentra una versin slo un poco ms actualizada que la incluida en la instalacin. En cambio, con Debian es posible obtener mediante el gestor de paquetes imgenes del ncleo precompiladas ms actualizadas, lo que posibilit el correcto funcionamiento de la tarjeta Wi-Fi. En cuanto al tiempo de arranque del sistema, CentOS tarda mucho ms en arrancar el sistema, ya que su ncleo es ms pesado. Debian consigue un tiempo de arranque muy corto y similar en las dos versiones del ncleo que se utilizaron. Cuando se analiza el soporte, los paquetes y las actualizaciones de la distribucin, todos ellos son conceptos muy relacionados que pueden resumirse en uno: la comunidad y el proyecto detrs de cada distribucin. Por un lado est la comunidad de CentOS, que al ser una distribucin empresarial est centrada en la estabilidad. Por otro lado, Debian es un proyecto ms abierto y exible con una rama muy estable sin las restricciones de CentOS, por ello es posible obtener de sus repositorios software ms actualizado, incluyendo imgenes del ncleo actualizadas. Adems, dispone de mejor documentacin y recursos para resolver problemas, a la vez que es posible emplear tambin los recursos de la comunidad de Ubuntu. En conclusin, se escoge Debian como sistema operativo del prototipo por su exibilidad frente a CentOS y su mejor soporte.

54

Captulo 4

Instalacin del sistema informtico en el vehculo

Una vez decidida que distribucin Linux emplear en el sistema y llegado el hardware necesario, se procedi a instalar el sistema informtico en el vehculo. Esto incluye adaptar y congurar la distribucin escogida, establecer un sistema de copias de seguridad y probar los dispositivos incorporados al vehculo (hardware y software).

4.1. Instalacin y conguracin de la distribucin

A continuacin se describen las tareas realizadas para instalar y congurar la distribucin escogida para el sistema: Primero se preparo el hardware del sistema para la instalacin. Se desembal la placa base, se instal la memoria RAM en la misma y se comprob que el sistema encenda sin problemas con un monitor y un teclado. En estos momentos el sistema se us mediante el adaptador de corriente incluido con la placa, dejando el uso de la batera para realizar pruebas cuando el montaje del sistema estuviera ms avanzado.

Figura 4.1: Foto de la placa durante la instalacin del sistema operativo

Seguidamente se procedi a realizar una instalacin mnima de la distribucin GNU/Linux Debian 5.04 stable, utilizando como medio soporte de instalacin un pendrive USB 2.0 55

Captulo 4. Instalacin del sistema informtico en el vehculo de 2 GB. Para ello se utiliz la aplicacin UNetbootin1 . En la aplicacin se seleccion de la lista de distribuciones Debian Stable Netinstall y luego el dispositivo /dev correspondiente a la particin del pendrive (ver gura 4.2). La aplicacin se encarga de descargar los archivos necesarios a travs de Internet y preparar adecuadamente el pendrive para poder arrancar la instalacin en l.

Figura 4.2: Captura de UNetbootin La instalacin de Debian denominada Netinstall precisa de conexin a Internet. Para ello, se utiliz una conexin por cable de red RJ45 disponible en el rea de trabajo en el CICEI. Una vez iniciada la instalacin, se formate el pendrive eSATA de la siguiente forma:

Primera particin de 144 MB, formateada como ext3 y punto de montaje /boot. Usada
como particin del sistema de arranque.

Segunda particin de 3890 MB, formateada como ext3 y punto de montaje raz /.
Usada como particin del sistema principal.

Tercera particin con el espacio restante, 3480 MB, formateada como ext3 sin punto
de montaje. Usada como futura particin del sistema de copias de seguridad. En las particiones montadas se seleccion como opcin de montaje noatime. Esta opcin hace que al acceder a un chero no se actualice la fecha de ltimo acceso, de forma que nicamente se actualiza esta fecha slo cuando se modica el chero (fuente: ayuda man del comando mount ). De esta forma se evitan algunas escrituras innecesarias sobre la memoria ash. Entonces se instal el sistema base y se congur la cuenta de administrador. Por ltimo, no se seleccion la instalacin de ningn paquete de software adicional para conseguir una instalacin de menor tamao. Una vez iniciado el sistema, se comprob que la tarjeta de red inalmbrica no funcionaba correctamente. Se determin que era necesaria una actualizacin a un kernel de Linux ms reciente que soportara el driver ath9k incluido en el ncleo desde la versin 2.6.27.
1

http://unetbootin.sourceforge.net

56

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala Para instalar un ncleo ms reciente en esta distribucin, la opcin ms sencilla es activar el repositorio de paquetes denominado backports2 . Una vez activado el repositorio backports, se actualiz el ncleo a la versin 2.6.32 con aptitude -t lenny-backports install linux-image-2.6.32-bpo.5-686 y se instal la nueva versin de las utilidades de Linux para la Wi-Fi con aptitude -t lenny-backports install wireless-tools. Tras comprobar que funcionaba la tarjeta de red inalmbrica con el nuevo ncleo se procedi a realizar un pequeo script que se ejecutara al inicio del sistema para conectarse automticamente a un punto de acceso disponible en el centro de trabajo y solicitar la conguracin de red mediante DHCP. El sistema escogido fue modicar el archivo /etc/rc.local aadiendo las siguientes lneas:

# Configurar WIFI ifup wlan0 # Cancin de inicio sh /root/songs/aseimov.sh exit 0

La instruccin ifup wlan0 congura la interfaz de red inalmbrica segn los datos del archivo /etc/network/interfaces. Al contenido de este archivo se han aadido las siguientes lneas para congurar esta interfaz:

iface wlan0 inet dhcp wireless-essid ASEIMOV wireless-key CLAVE_WEP_HEXADECIMAL

El script aseimov.sh utiliza el comando beep para reproducir una meloda por el altavoz interno del sistema. Puesto que este sistema no tendr pantalla, la meloda servir para anunciar al usuario de que el sistema est listo para ser utilizado de forma remota. El comando puede instalarse de los repositorios con aptitude install beep. Para que funcionara el sistema ACPI de la placa para poder apagar el sistema normalmente utilizando el botn de encendido/apagado, se procedi a instalar el demonio acpid con la instruccin aptitude -t lenny-backports install acpid. Se ha instalado un servidor de SSH con la orden aptitude install opensshserver. As, es posible conectarse de forma remota al ordenador del vehculo para trabajar con l y transmitir cheros.

4.2. Establecimiento de un sistema de copias de seguridad

Para establecer un sistema de copia de seguridad lo ms able posible, se ha instalado en la particin habilitada para ello un sistema mnimo con la misma versin de Debian, pero con las siguientes caractersticas:
2

Este proceso se detalla en http://wiki.debian.org/ath9k.

57

Captulo 4. Instalacin del sistema informtico en el vehculo Se ha incorporado al GRUB una entrada para arrancar este nuevo sistema. El sistema no aloja el ncleo en la particin de arranque para ser lo ms independiente posible del sistema principal. Se ha instalado la aplicacin partimage http://www.partimage.org que permite volcar el contenido de una particin en un slo archivo comprimido con un buen factor de compresin. Se ha creado una carpeta /backup en el que almacenar estos archivos de imagen. Se ha creado un manual que describe el proceso para realizar una copia de seguridad y restaurarla, apoyndose en la utilizacin de un pequeo script. Para ms detalles consultar el manual en F Manual del sistema de copias de seguridad.

4.3. Prueba de hardware y software sensorial

Como parte de la instalacin del sistema informtico era necesario comprobar el funcionamiento de los dispositivos incorporados al vehculo. Las pruebas de los dispositivos se han dividido en los dispositivos del fabricante Phidget, las cmaras web y el ratn mecnico.

4.3.1. Prueba de dispositivos Phidgets

Antes de probar cualquier dispositivo se debe descargar el driver para Linux disponible en http://www.phidgets.com/drivers.php. Entonces se debe descomprimir y compilarse con make jni para tener soporte Java en el driver (este paso requiere instalar el JDK: Java Development Kit en el sistema), e instalarse con make install. Hecho esto se pueden probar los dispositivos con varias aplicaciones de ejemplo escritas en diversos lenguajes. Los ms comunes son C y Java. Los ejemplos y manuales para programar en los lenguajes disponibles pueden descargarse en http://www.phidgets.com/ programming_resources.php. Entre los ejemplos de Java pueden encontrarse varias aplicaciones con interfaz grca que hacen mas amigable la prueba de los distintos dispositivos. Por ello se han escogido para realizar estas pruebas. 4.3.1.1. Acelermetro

El funcionamiento del acelermetro se prob con la aplicacin de ejemplo Accelerometer-full.jar. Se comprob el funcionamiento en los tres ejes moviendo el sensor y observando la respuesta del sensor en la interfaz. 4.3.1.2. Controlador de motor

El controlador de motor se prob con la aplicacin de ejemplo MotorControl-full.jar. En este caso el controlador no funcionaba inicialmente con el motor que inclua de serie el coche radiocontrol. El controlador slo puede controlar motores de hasta 1,5A de intensidad y este motor, por su potencia, era de aproximadamente 1,75A. Al probarse sobre un motor de menor potencia no hubo ningn problema con el controlador. Para estas pruebas se utiliz la batera universal como fuente de alimentacin del controlador. 58

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 4.3.1.3. Controlador de servomotor El controlador de servomotor se prob con la aplicacin de ejemplo Servo-full.jar. El servomotor funcion correctamente a las rdenes emitidas por el controlador, sin embargo hay que congurar el controlador en funcin del servomotor al que est conectado. De serie se incluyen una serie de deniciones de distintos servomotores, aunque tambin es posible denir una conguracin propia. Puesto que no conocemos exactamente que servomotor viene de serie con el coche radiocontrol, se probaron varias de estas deniciones. Se determin que la conguracin denominada como HITEC_HS5245MG era la que mejor funcionaba con el servomotor. 4.3.1.4. Infrarrojos y sonares Los sensores infrarrojos y sonares se deban probar en las entradas analgicas de la placa denominada InterfaceKit 8/8/8. La aplicacin de ejemplo en este caso es InterfaceKit-full.jar. Se fueron conectando uno a uno los sensores infrarrojos a la placa y luego los sonares. Para probar el funcionamiento de los sensores se realiz una medicin simple de una caja situada a 50cm del sensor tomando como referencia una regla. Se comprob que las medidas no distaban demasiado de dicha distancia, teniendo en cuenta que no se han calibrado los dispositivos an.

4.3.2. Prueba de cmaras USB

Las cuatro cmaras USB corresponden al modelo de Logitech Webcam C160. Disponen de una resolucin de hasta 640 x 480 pxeles y funcionan con la interfaz USB 2.0, lo que produce una buena tasa de imgenes por segundo.

4.3.3. Prueba de ratn mecnico

Se comprob que el puerto PS/2 de la placa era slo vlido para teclados. Esto impide utilizar un ratn con este tipo de conexin. Por tanto, se consiguieron ratones USB del fabricante Dell y se comprob que eran compatibles con el sistema. Tras eso, Moiss Daz procedi a instalar uno de los dos codicadores pticos del ratn en el vehculo, de forma que el movimiento del eje de una de las ruedas traseras del vehculo moviera una rueda ranurada entre el emisor y el receptor ptico del ratn. Este montaje puede verse en la gura4.3.

Figura 4.3: Acoplamiento del hardware original del ratn al vehculo Por ltimo, se realiz una prueba para comprobar el nmero de tics que provocaba una vuelta completa del ratn. Una vuelta debera hacer supuesto unos 240 tics (60x4), sin embargo no 59

Captulo 4. Instalacin del sistema informtico en el vehculo se consegua esa cifra siempre. Esto se deba a que el haz ptico del encoder no atravesaba correctamente una parte de las ranuras de la rueda debido a las imperfecciones del montaje. Por eso, se opt por reducir el nmero de ranuras de la rueda para que el haz tuviera que atravesar huecos ms grandes. En concreto se opt por reducir a 12 ranuras. De esta forma, se consigui una lectura correcta de 48 (12x4) tics.

60

Parte III Desarrollo de aplicacin JASEIMOV para el control y monitorizacin remota del vehculo

61

Captulo 1

Anlisis de requisitos de usuario

En este captulo se presentan los resultados del anlisis de requisitos desde el punto de vista del usuario, presentando el problema a solucionar, las funcionalidades necesarias y el dominio del problema desde el punto de vista del hardware.

1.1. Descripcin del problema

Se dispone de un vehculo elctrico radiocontrol de escala 1:10 modelo Kyosho TF-5. El vehculo inicialmente incluye una batera, un sistema de control por radio (mando de control y receptor en el vehculo), un motor que permite mover el vehculo hacia adelante y hacia atrs y un servomotor que permite variar la direccin del movimiento moviendo las ruedas como si fuera el volante de un vehculo real. Una foto del vehculo sin la carrocera pude verse en la gura 1.1.

Figura 1.1: Vehculo original Kyosho TF-5 Para captar informacin de su entorno y dotarlo de inteligencia, se han dispuesto una serie de sensores en su carrocera. Para controlar el movimiento del vehculo a travs del motor y el servomotor se han instalado dos controladores. Sensores:

Acelermetro: phidgets PhidgetAccelerometer 3-Axis. Cmaras (webcams): Logitech Webcam C160.

63

Captulo 1. Anlisis de requisitos de usuario

Encoder: basado en el hardware de un ratn mecnico Dell USB Ball Mouse. Utilizado para medir las revoluciones en los ejes de las ruedas del vehculo.

Infrarrojos: phidget IR Distance Sensor. Sonar: phidget Sonar Sensor.

Controladores:

Controlador de motores DC: phidget PhidgetMotorControl LV. Controlador de servomotores: phidget PhidgetServo 1-Motor.
Todos los dispositivos emplean un puerto USB para conectarse a un ordenador. En este caso, se dispone de un sistema informtico de reducidas dimensiones incorporado a la estructura del vehculo. Se necesita una aplicacin para, desde un equipo remoto, visualizar en tiempo real el estado de todos los sensores y controlar el vehculo. Por ello ser necesaria una arquitectura cliente/servidor, en la que el servidor se ejecutar en el sistema informtico del vehculo y permitir a varios clientes acceder a los dispositivos de forma remota.

1.2. Descripcin de requisitos

1.2.1. Requisitos funcionales
Los requisitos de capacidad o funcionales identican funciones y operaciones requeridas por los usuarios para resolver un problema o alcanzar un objetivo. Fundamentalmente describen una operacin o secuencia de ellas, que el software debe ser capaz de realizar. RF.1 Requisitos de control del vehculo. RF.1.1 Controlar el motor: poder controlar la velocidad y aceleracin del motor del vehculo y poder detenerlo. RF.1.2 Controlar el servomotor: poder cambiar la posicin del servomotor del vehculo, que cambia la orientacin de las ruedas delanteras del vehculo. RF.2 Requisitos de visualizacin de sensores. RF.2.1 Visualizar la medida de un sensor en pantalla. RF.2.2 Indicar grcamente la localizacin de cada sensor en el vehculo. RF.2.3 Permitir almacenar en un chero de texto los datos de uno o varios de los sensores. RF.2.4 Permitir realizar grcas en tiempo real con los datos recogidos por uno o varios de los sensores. Las grcas podrn guardarse en un chero de imagen. RF.2.5 Visualizar la imagen de las cmaras en streaming, es decir, visualizar la imagen de forma contina como un vdeo. Permitir el inicio y parada del proceso de streaming. RF.2.6 Posibilidad de capturar una imagen o una secuencia de imgenes (vdeo) de una cmara para poder guardarlas en disco. RF.2.7 Poder congurar la velocidad con la que se actualizan los datos de los sensores en pantalla. 64

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

1.2.2. Requisitos no funcionales

Los requisitos de restriccin o no funcionales describen restricciones impuestas por los usuarios sobre la manera en que el software es construido, sin alterar o describir las capacidades del mismo. RNF.1 Diseo modular: diferenciar el control del vehculo y la visualizacin de los sensores. RNF.2 Visualizacin en tiempo real, o lo ms cercano posible al tiempo real, del estado de los sensores. RNF.3 Adaptacin del software a cambios en la disposicin de los dispositivos en el vehculo. RNF.4 Tener en cuenta el soporte de nuevos dispositivos. RNF.5 Requisitos del cliente. RNF.5.1 Aplicacin independiente del sistema operativo empleado. RNF.5.2 Soportar dos lenguajes: espaol e ingls. RNF.6 Requisitos del servidor. RNF.6.1 Consumo de recursos limitado, dadas las limitaciones del hardware donde se ejecutar. RNF.6.2 Conguracin de dispositivos: poder cambiar los dispositivos que usa el servidor. RNF.6.3 Control de los dispositivos descritos en el apartado 1.4 Descripcin tcnica de dispositivos.

1.3. Glosario de trminos

A continuacin, se denen un conjunto de trminos en el contexto del dominio tratado. acelermetro: dispositivo que mide aceleraciones. aceleracin: magnitud vectorial que indica el cambio de la velocidad de un mvil por unidad de tiempo. cmara: dispositivo que captura imgenes de forma continua. controlador: dispositivo que sirve para controlar algo. controlador motor: controlador que sirve para controlar la velocidad y aceleracin de un motor de corriente continua. controlador servo: controlador que sirve para controlar la posicin de un servomotor. distancia: magnitud escalar medida por un sonar o un infrarrojo que indica la separacin entre dos objetos. dispositivo: hardware empleado por el sistema informtico que puede ser un controlador o un sensor. 65

Captulo 1. Anlisis de requisitos de usuario encoder: sensor que sirve para medir el movimiento mediante tics. imagen: conjunto de datos que forman una fotografa. infrarrojo: sensor que emite una onda infrarroja para medir la distancia que le separa de otro objeto mediante el rebote de la misma. motor: el motor se encarga de transmitir movimiento a las ruedas delanteras y traseras del vehculo de forma que el vehculo se mueva hacia adelante o hacia atrs. tics: un tic es un pulso elctrico producido mediante el empleo de un emisor y un receptor de luz. Al interrumpir y permitir el paso de un haz de luz entre emisor y receptor se produce un pulso elctrico. En el caso de un encoder se suele conseguir mediante el empleo de una rueda con ranuras que dejan pasar o no este haz de luz. sensor: dispositivo que proporciona datos del entorno. servo: se encarga de cambiar la orientacin de las ruedas delanteras del vehculo y con ello la direccin del movimiento del vehculo. sistema informtico: el sistema informtico gestiona una serie de sensores y controladores para controlar y monitorizar el vehculo. sonar: sensor que emite una onda de sonido inaudible para los humanos para medir la distancia que le separa de otro objeto mediante el rebote de dicha onda. streaming: capacidad de visualizar de forma continua las imgenes capturadas por las cmaras formando un vdeo. vehculo: coche elctrico radiocontrol a escala 1:10.

1.4. Descripcin tcnica de dispositivos

A continuacin se incluye una descripcin ms amplia y tcnica sobre los distintos dispositivos que pueden ser utilizados en el vehculo.

1.4.1. Dispositivos Phidget

La mayora de los dispositivos empleados para controlar y monitorizar el vehculo son fabricados por la empresa Phidgets. Esta empresa ha desarrollado un gran nmero de dispositivos "plug and play"de bajo coste que emplean el USB como sistema de conexin con un ordenador. La losofa de su diseo es que no es necesario ser un Ingeniero Electrnico para emplear sensores, controlar motores, etc empleando un ordenador. La gran ventaja de estos dispositivos es que son muy sencillos de emplear e integrar en cualquier ordenador que disponga de puertos USB, existiendo controladores para Windows, Mac y GNU/Linux. A travs de una API se controlan dichos dispositivos desde varios lenguajes de programacin como C, C++, Java, Phyton, Visual Basic... Existen numerosos ejemplos de como emplear la API para cada lenguaje de programacin. Cada dispositivo Phidget tiene un nmero de serie nico que puede ser ledo mediante la API para identicarlo de forma unvoca. 66

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala Acelermetro: phidgets PhidgetAccelerometer 3-Axis Mide hasta 3G (29,4 m/s2 ) en los tres ejes del espacio: X, Y, Z. Frecuencia de muestreo: 60 muestras/segundo. Calibrado de fbrica. Se conecta y alimenta directamente de un puerto USB. Manual: [17].

Controlador de motores DC: phidget PhidgetMotorControl LV Controla dos motores de corriente continua de forma independiente en direccin, velocidad y aceleracin. Rango de velocidad: de -100 a +100. Rango de aceleracin: de 0.1 a 100. Tiempo de respuesta 30 ms. Se conecta directamente a un puerto USB, pero se necesita una fuente de alimentacin externa para los motores de entre 5-12V DC y de hasta 1,5A. Tiene proteccin contra sobrecorrientes. Manual: [18].

Controlador de servomotores: phidget PhidgetServo 1-Motor Controla la posicin de un servomotor desde -23 grados hasta 223 grados, con una resolucin de hasta 0,1 grado. Tiempo de ciones/segundo. actualizacin: 50 actualiza-

Se conecta y alimenta directamente de un puerto USB. Manual: [15].

67

Captulo 1. Anlisis de requisitos de usuario Infrarrojo: phidget IR Distance Sensor IR Distance Adapter: Se encarga de hacer de interfaz entre una entrada analgica de una placa PhidgetInterfaceKit 8/8/8 y un sensor de distancia Sharp. Se alimenta de la placa PhidgetInterfaceKit 8/8/8, y proporciona energa al sensor de distancia Sharp. Frmula para calcular la distancia a partir del valor proporcional del sensor en cm: Distancia(cm) = 4800 Valor20 . Vlida para valores comprendidos entre 80 y 500. Manual: [20]. Sharp GP2D12 (10 - 80cm): Sensor de distancia Sharp por infrarrojos, rango de 10 a 80 cm. Se conecta a una interfaz IR Distance Adapter y toma la energa necesaria de l.

Sonar: phidget Sonar Sensor Detecta objetos entre 0 y 254 pulgadas (hasta 6,45m) con una resolucin de 1 pulgada. Tiempo de emisin de onda: 50 ms. Se calibra automticamente al encenderse. Debe conectarse a una entrada analgica del PhidgetInterfaceKit 8/8/8. Frmula para calcular la distancia a partir del valor proporcional del sensor en cm: Distancia(cm) = Valor 1,296. Manual: [19].

68

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala Tarjeta de adquisicin de datos: PhidgetInterfaceKit 8/8/8 Tarjeta de adquisicin de datos de sensores. Dispone de 8 entradas analgicas, 8 entradas digitales y 8 salidas digitales. Rango de entradas analgicas: de 0 a 5 V. Posibilidad de lectura de sensor proporcional (ratiometric), esto signica que la salida del sensor es proporcional al voltaje aplicado al mismo. Frecuencia de muestreo: entrada analgica 65 muestras/segundo, entrada digital 125 muestras/segundo, salida digital 125 muestras/segundo. Se dispone de la versin 0 de dicha tarjeta. La versin 1 permite congurar la frecuencia de muestreo de las entradas. Se conecta y alimenta directamente de un puerto USB. Manual: [16].

1.4.2. Otros dispositivos

En esta seccin se describe los otros dispositivos: la cmara web y el ratn empleado como encoder. En la fase de diseo habr que tener en cuenta como acceder a los datos generados por estos dispositivos para su posterior procesamiento por parte del software.

Logitech Webcam C160 Resolucin mxima: 640 x 480 pxeles. Buena cantidad de FPS (frames por segundo). Interfaz USB 2.0. Soporte en Linux: compatible con v4l y v4l2.

69

Captulo 1. Anlisis de requisitos de usuario Encoder: ratn mecnico Dell USB Ball Mouse Se utilizar como encoder para el motor del vehculo. Resolucin: 8 unidades/mm. Tics/vuelta completa: 48 tics/vuelta. Frecuencia de tras/segundo. muestreo: hasta 500 mues-

Se emplearn los datos del captulo 2.3 Uso de un ratn mecnico como codicador ptico y la experiencia adquirida en el mismo para emplear el ratn como encoder del vehculo.

70

Captulo 2

Anlisis de requisitos de software

En este captulo se presentan los requisitos desde el punto de vista del sofware, con el estudio de casos de uso del software y la muestra del prototipo desarrollado durante la fase de anlisis.

2.1. Casos de uso

Un caso de uso representa un escenario que describe cmo el software va a ser usado para una determinada situacin [21]. Para crear un caso de uso, primero se identican las personas y/o dispositivos (actores) que utilizan el sistema actuando con un rol determinado sobre el mismo. Entonces, un caso de uso dene la interaccin de un actor con el sistema para lograr un n determinado. Cada caso de uso se describe con un diagrama UML que identica al actor y las operaciones que puede llevar a cabo en el sistema con un n determinado. Adems para cada operacin se describe la informacin siguiente:

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

El nombre de la operacin Descripcin de lo que hace la operacin Condiciones que se deben cumplir para poder realizar la operacin Datos que necesita la operacin para hacer su funcin Pequea descripcin de que hace la operacin en el sistema Posibles fallos en la ejecucin de la operacin Cambios de estado en el sistema

A continuacin se incluyen los casos de uso del sistema cliente y del sistema servidor.

2.1.1. Sistema cliente

En los casos de uso del cliente nos encontramos con el actor operador, que cumple los roles de controlador del vehculo y monitor del estado de los sensores del mismo. El diagrama de la gura 2.1 describe los escenarios del operador del sistema cliente. Cada uno de los escenarios y sus operaciones se describen a continuacin en su propia seccin. 71

Captulo 2. Anlisis de requisitos de software

Figura 2.1: Casos de uso del sistema cliente

2.1.1.1.

Establecer Conexin

Intencin del actor: controlar la conexin entre el cliente y el servidor en el vehculo. Diagrama: gura 2.2

Figura 2.2: Casos de uso de establecer conexin 72

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Conectar a Servidor Establecer una conexin con el servidor Cliente no conectado Direccin IP, puerto Se intenta conectar al conjunto IP:puerto suministrado por el usuario. Si se establece la conexin se podrn controlar/monitorizar los dispositivos del servidor. Si no se establece la conexin se muestra un mensaje de error. Fallo en la conexin Cliente conectado

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Desconectar de Servidor Desconectar del servidor Cliente conectado Se corta la conexin con el servidor y se reinicia la interfaz al estado inicial Alertar al usuario de posibles prdidas de datos Cliente desconectado

2.1.1.2. Controlar Vehculo Intencin del actor: mover el vehculo de forma manual. Diagrama:

Figura 2.3: Casos de uso de controlar vehculo

Para que se puedan ejecutar las operaciones de control del vehculo se deben cumplir estas precondiciones: cliente conectado, ventana de control del vehculo abierta. 73

Captulo 2. Anlisis de requisitos de software Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Establecer Velocidad Establecer la velocidad del motor del vehculo Existe un controlador de motor en el servidor Controlador de motor, velocidad Se enva la orden al controlador de motor y se informa de cualquier error Fallo en la conexin, Error en dispositivo La velocidad del motor se establece al valor pasado

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Establecer Aceleracin Establecer la aceleracin del motor del vehculo Existe un controlador de motor en el servidor Controlador de motor, aceleracin Se enva la orden al controlador de motor y se informa de cualquier error Fallo en la conexin, Error en dispositivo La aceleracin del motor se establece al valor pasado

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Establecer Posicin Establecer la posicin del servomotor del vehculo Existe un controlador de servomotor en el servidor Controlador de servomotor, posicin Se enva la orden al controlador de servomotor y se informa de cualquier error Fallo en la conexin, Error en dispositivo La posicin del servomotor se establece al valor pasado

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Detener Vehculo Detener el movimiento actual del vehculo lo antes posible Existe un controlador de motor en el servidor Controlador de motor Se establece en el controlador de motor la aceleracin al mximo y la velocidad a cero (el motor no se mueve) Fallo en la conexin, Error en dispositivo Aceleracin del motor al mximo, velocidad del motor a cero (motor parado)

2.1.1.3.

Consultar Sensor

Intencin del actor: visualizar el estado de un sensor del vehculo. Diagrama: 74

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 2.4: Casos de uso de consultar sensor

Para que se puedan ejecutar estas operaciones se deben cumplir estas precondiciones: cliente conectado, existe como mnimo un dispositivo sensor en el servidor.

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Abrir Sensor Abrir la ventana de un sensor para ver su estado Sensor Se establece comunicacin con el sensor y se abre una ventana para representar su estado. Si la ventana ya est abierta no tiene efecto. Ventana de sensor abierta

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Actualizar Manualmente Actualizar el estado actual del sensor en su ventana asociada Ventana de sensor abierta Sensor Se obtiene el estado del sensor y se actualiza la ventana con los datos Error en sensor

75

Captulo 2. Anlisis de requisitos de software Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Iniciar Actualizacin Automtica Actualizar de forma automtica cada cierto tiempo el estado del sensor en su ventana asociada Ventana de sensor abierta, actualizacin automtica detenida Sensor, tiempo de actualizacin Se ejecuta en intervalos de tiempo denidos por el tiempo de actualizacin el proceso para obtener el estado del sensor y actualizar la ventana con los datos Error en sensor Actualizacin automtica iniciada

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Detener Actualizacin Automtica Parar la actualizacin automtica Ventana de sensor abierta, actualizacin automtica iniciada Sensor Se detiene el proceso de actualizacin automtica Error en sensor Actualizacin automtica detenida

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Establecer Tiempo Actualizacin Cambiar el tiempo de actualizacin del sensor Ventana de sensor abierta Sensor El usuario introduce el tiempo de actualizacin y se cambia el tiempo en el sensor Tiempo no vlido Tiempo de actualizacin de sensor cambiado

2.1.1.4.

Observar Cmara

Intencin del actor: observar las imgenes capturadas por una o varias cmaras del vehculo. Diagrama: 76

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 2.5: Casos de uso de observar cmara Para que se puedan ejecutar las operaciones siguientes se deben cumplir estas precondiciones: cliente conectado, ventana de visin de cmaras abierta, existe como mnimo una cmara en el servidor. Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Iniciar Streaming Iniciar el proceso de streaming de vdeo Streaming detenido Cmara Se inicia el proceso de streaming, mostrndose las imgenes de la cmara en la interfaz Fallo en la conexin, Error en dispositivo Streaming iniciado Detener Streaming Detener el proceso de streaming de vdeo Streaming iniciado Cmara Se detiene el proceso de streaming Streaming detenido Iniciar Captura Iniciar la captura de imgenes de la cmara para almacenar un vdeo Captura detenida Cmara Se inicia el proceso de streaming si no est iniciado y se activa la captura de imgenes Streaming iniciado, Captura iniciada 77

Captulo 2. Anlisis de requisitos de software Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Detener Captura Detener la captura de imgenes de la cmara Captura iniciada Cmara Se detiene la captura de imgenes y el proceso de streaming. Se guarda la captura. Streaming detenido, Captura detenida, Captura guardada

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Ver Captura Reproducir el vdeo de la captura guardada Captura guardada Captura Se reproducen las imgenes capturadas en la interfaz simulando un vdeo

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Borrar Captura Borrar la captura guardada Captura guardada Cmara Se borran las imgenes guardadas de la captura Captura no guardada

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Guardar Imagen Guardar en un archivo la imagen actual de la cmara Streaming iniciado al menos una vez Cmara, nombre de archivo Se guarda la imagen mostrada actualmente en la cmara Error del sistema de archivos Fichero de imagen guardado en disco

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Guardar Vdeo Guardar una serie continua de imgenes en archivos en disco Captura guardada Frames, carpeta Se guardan todos los frames capturados como archivos de imagen en la carpeta indicada Error del sistema de archivos Ficheros de imagen guardados 78

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Establecer Tiempo Actualizacin Cambiar el tiempo de actualizacin de la cmara Ventana de cmara abierta Cmara El usuario introduce el tiempo de actualizacin y se cambia el tiempo en la cmara Tiempo no vlido Tiempo de actualizacin de cmara cambiado

2.1.1.5. Hacer Grca Intencin del actor: dibujar una grca que represente la medida de uno o varios sensores a lo largo del tiempo. Diagrama:

Figura 2.6: Casos de uso de hacer grca

Para que se puedan ejecutar las operaciones siguientes se deben cumplir las siguientes precondiciones: cliente conectado, ventana de grcas abierta, existe como mnimo un dispositivo sensor en el servidor. 79

Captulo 2. Anlisis de requisitos de software Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Iniciar Grca Iniciar el dibujado de la grca con las medidas de los sensores seleccionados Mnimo de un sensor seleccionado, Grca detenida Grca, tiempo de actualizacin Se obtiene la medida de cada sensor seleccionado en perodos de tiempo denidos por el tiempo de actualizacin y se dibuja la medida en pantalla Fallo en la conexin, Error en dispositivo Grca iniciada

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Detener Grca Detener el dibujado de la grca Grca iniciada Grca Se detiene el dibujado de la grca Grca detenida

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Limpiar Grca Borra el dibujo de la grca y la reinicializa Grca Se limpia el dibujo actual de la grca Grca borrada

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Guardar Grca Guardar en un archivo en disco el dibujo actual de la grca Grca, nombre de archivo Se guarda una imagen en disco con el nombre de archivo proporcionado Error del sistema de archivos Archivo guardado

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Seleccionar Sensor Seleccionar uno o ms sensores para hacer grcas con sus datos Grca detenida Sensores El usuario selecciona uno o ms sensores y conrma la seleccin Sensor/es seleccionado/s 80

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Establecer Tiempo Actualizacin Cambiar el tiempo de actualizacin de los sensor seleccionados Sensores seleccionados Sensores El usuario introduce el tiempo de actualizacin y se cambia el tiempo en los sensores Tiempo no vlido Tiempo de actualizacin de los sensores cambiado

2.1.1.6. Capturar Datos Intencin del actor: capturar las medidas de los sensores para almacenarlas en disco. Diagrama:

Figura 2.7: Casos de uso de capturar datos Para que se puedan ejecutar las operaciones siguientes se deben cumplir las siguientes precondiciones: cliente conectado, ventana de captura de datos abierta, existe como mnimo un dispositivo sensor en el servidor. Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Iniciar Captura Iniciar la captura de los datos de los sensores seleccionados Mnimo de un sensor seleccionado, Captura detenida Capturador, tiempo de actualizacin Se obtiene la medida de cada sensor seleccionado en perodos de tiempo denidos por el tiempo de actualizacin y se muestra la medida en una tabla Fallo en la conexin, Error en dispositivo Captura iniciada 81

Captulo 2. Anlisis de requisitos de software Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Detener Captura Detener la captura de datos Captura iniciada Capturador Se detiene la captura de datos Captura detenida

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Limpiar Captura Borra la tabla de datos y la reinicializa Capturador Se borran los datos capturados hasta ahora y se reinicializa la tabla que muestra los datos Tabla borrada

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Guardar Captura Guardar en un archivo en disco los datos capturados Capturador, nombre de archivo Se guarda un archivo con los datos de la captura en disco con el nombre de archivo proporcionado Error del sistema de archivos Archivo guardado

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Seleccionar Sensor Seleccionar uno o ms sensores para capturar sus datos Captura detenida Sensores El usuario selecciona uno o ms sensores y conrma la seleccin Sensor/es seleccionado/s

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Establecer Tiempo Actualizacin Cambiar el tiempo de actualizacin de los sensores seleccionados Sensores seleccionados Sensores El usuario introduce el tiempo de actualizacin y se cambia el tiempo en los sensores Tiempo no vlido Tiempo de actualizacin de los sensores cambiado 82

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 2.1.1.7. Establecer Idioma Intencin del actor: cambiar el idioma de la aplicacin. Diagrama:

Figura 2.8: Casos de uso de establecer idioma Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Seleccionar Idioma Seleccionar el idioma de la aplicacin de una lista de idiomas soportados Idioma Se cambia el idioma de la aplicacin y se actualiza la interfaz con el nuevo idioma Idioma cambiado

2.1.1.8. Seleccionar Sensor Intencin del actor: congurar una seleccin de sensores para realizar operaciones sobre ellos. Diagrama:

Figura 2.9: Casos de uso de seleccionar sensor Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Aadir Sensor Aade un sensor a la seleccin Sensor no seleccionado Sensor El sensor se aade a la lista de seleccionados Sensor seleccionado 83

Captulo 2. Anlisis de requisitos de software Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Quitar Sensor Quita un sensor de la seleccin Sensor seleccionado Sensor El sensor se quita de la lista de seleccionados Sensor no seleccionado

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Conrmar Seleccin Terminar la seleccin de sensores y conrmarla Lista de seleccionados Se almacena la lista de seleccin para que pueda ser consultada

2.1.1.9.

Establecer Tiempo Actualizacin

Intencin del actor: congurar el tiempo de actualizacin de uno o ms sensores Diagrama:

Figura 2.10: Casos de uso de establecer tiempo actualizacin

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Introducir Tiempo Introducir el nuevo tiempo de actualizacin Tiempo El usuario introduce el nuevo tiempo de actualizacin en la interfaz Tiempo introducido 84

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Establecer Tiempo por Defecto Cambiar el tiempo de actualizacin a un valor por defecto Tiempo por defecto Se cambia el tiempo de actualizacin al valor por defecto Tiempo introducido

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Conrmar Tiempo Cambiar el tiempo de actualizacin Tiempo introducido Sensor/es, tiempo Se cambia el tiempo de actualizacin de el/los sensor/es al nuevo tiempo introducido Tiempo no valido Tiempo de actualizacin cambiado

2.1.2. Sistema servidor

En los casos de uso del sistema servidor nos encontramos con el actor administrador, que se encarga de iniciar/detener el sistema servidor y de congurarlo adecuadamente. El siguiente diagrama describe estas operaciones.

Figura 2.11: Casos de uso del sistema servidor

Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin

Iniciar Servidor Iniciar el servidor para que los clientes puedan utilizar a los dispositivos Servidor no iniciado, servidor congurado Conguracin del servidor Congurar el servidor segn las datos de conguracin e iniciar los servicios necesarios Fallo en la conexin, Error en dispositivo Servidor iniciado 85

Captulo 2. Anlisis de requisitos de software Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Operacin Funcin Precondicin Parmetros Flujo de ejecucin Excepciones Postcondicin Detener Servidor Detener el servidor en el vehculo para dejar de ofrecer servicios a los clientes Servidor iniciado Detener todos los servicios prestados Servidor no iniciado, aplicacin servidor cerrada Congurar Servidor Congurar los dispositivos que utilizar el servidor mediante un archivo de conguracin Servidor no iniciado Archivo de conguracin Leer el chero, congurar los dispositivos con los datos encontrados y guardarlos en una lista Error del sistema de archivos Servidor congurado

2.2. Prototipo
Durante la fase de anlisis se ha desarrollado un prototipo con el objetivo de capturar mejor los requisitos del software y disear de forma preliminar la interfaz de usuario. De esta forma se mejora la calidad del proceso de anlisis. Como se menciona en [21], aunque el prototipo puede servir como primer sistema, es recomendable desecharlo y que sirva nicamente como mecanismo para identicar requisitos del software. Al desarrollar un prototipo se realiza un diseo rpido, representando la interfaz de usuario y los procesos de entrada/salida de forma muy rpida para que el prototipo funcione lo antes posible, sin tener en cuenta aspectos de calidad, mantenimiento, etc. Por eso, una vez identicados los requisitos, es recomendable desechar el prototipo y realizar un diseo empezando de nuevo de forma ms detenida. A continuacin se incluyen un conjunto de capturas que muestran las funcionalidades de la interfaz del prototipo: Ventana principal, gura 2.12: permite establecer la conexin con el servidor, visualizar los sensores en el vehculo y mostrar el resto de ventanas. Ventana de control del vehculo, gura 2.13: permite controlar el motor y el servomotor del vehculo. Visor de cmaras, gura 2.14: permite trabajar las cmaras del vehculo. Ventana de captura de datos, gura 2.15: permite capturar los datos de uno o ms sensores. Ventana de elaboracin de grcas, gura 2.16: permite elaborar grcas con los datos de uno o ms sensores. 86

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 2.12: Ventana principal de la aplicacin

Figura 2.13: Ventana de control del vehculo

87

Captulo 2. Anlisis de requisitos de software

Figura 2.14: Visor de cmaras

Figura 2.15: Ventana de captura de datos

88

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 2.16: Ventana de elaboracin de grcas

89

Captulo 3

Diseo del software

En este captulo se va a denir la arquitectura del software que se pretende construir, deniendo los sistemas y subsistemas, la forma en la que se comunicarn, las bibliotecas que utilizarn y sus interfaces de usuario. Entonces se proceder a la especicacin del diseo detallado de estos sistemas y al diseo funcional de los casos de uso.

3.1. Herramientas de desarrollo

El lenguaje de programacin escogido para el desarrollo es Java por ser un lenguaje independiente del sistema operativo porque funciona sobre una mquina virtual, orientado a objetos, con gran cantidad de libreras, facilidad para desarrollar interfaces grcas de usuario y herramientas para el desarrollo de aplicaciones distribuidas, gestin de hilos de ejecucin, listas, etc. incluidas en el propio lenguaje. Para el desarrollo del software se emplearn las siguientes herramientas: Ordenador con sistema operativo GNU/Linux, distribucin Ubuntu 9.10. Entorno de desarrollo Java: OpenJDK 1.6.1. IDE: Netbeans IDE 6.8. Herramientas UML: dia 0.97 para los diagramas de casos de uso de la fase de anlisis y ArgoUML 0.30.1 para el resto de diagramas UML en la fase de diseo. Otros diagramas: OpenOfce Impress 3.1.1.

3.2. Diseo arquitectnico

El diseo arquitectnico dene la relacin entre las estructuras principales del software, deniendo los sistemas/aplicaciones a desarrollar y la comunicacin entre ellos. Este desarrollo va a contemplar dos aplicaciones, un servidor localizado en el vehculo que proporcionar servicios de acceso a los dispositivos del mismo a uno o ms clientes establecidos en una red inalmbrica Wi-Fi. A continuacin se dene la arquitectura del cliente y del servidor, seguida de la denicin de la arquitectura del sistema completo. 91

Captulo 3. Diseo del software

3.2.1. Arquitectura del cliente

El diagrama de esta arquitectura se encuentra en la gura 3.1.

Figura 3.1: Arquitectura del cliente Al estar desarrollada en Java, la aplicacin cliente se ejecutar en su mquina virtual Java (MVJ) y ser independiente del sistema operativo del cliente, siempre y cuando, este sistema operativo disponga de una implementacin de la MVJ. La aplicacin se apoyar en dos libreras: JChart2D http://jchart2d.sourceforge.net Licencia: LGPL versin 2.1 Esta librera permite representar grcas en dos dimensiones con una conguracin mnima. Otras libreras tienen muchas opciones de visualizacin que permiten realizar grcas ms elaboradas a costa de rendimiento y conguraciones ms complejas. Por esto se ha escogido esta librera para realizar los histogramas con los datos de los sensores, al ser ms sencilla y eciente. JGraph 5 http://www.jgraph.com/jgraph5.html Licencia: Simplied (modern) 3 clause BSD versin 1.1 Esta librera est orientada para representar grafos en pantalla. Se va a utilizar como apoyo para poder representar una vista en planta del vehculo en la que se colocarn los dispositivos en funcin de su localizacin real en el mismo. La idea de usar esta librera se ha tomado de una aplicacin que maneja una placa de instrumentacin que controla un robot http://www.terk.ri.cmu.edu/software/ robot-universal-remote. En este caso, la librera se usa para representar la placa de instrumentacin y sus diferentes entradas y salidas. Al hacer clic en una de ellas se abre una pequea ventana para poder controlarla.

3.2.2. Arquitectura del servidor

El diagrama de esta arquitectura se encuentra en la gura 3.2. Al igual que el cliente, el servidor al estar desarrollado en Java depender nicamente de que exista una implementacin de la mquina virtual de Java. El servidor se apoyar en las siguientes libreras para poder acceder los distintos dispositivos del vehculo: mouselib Esta librera sirve para leer los paquetes de movimiento del protocolo PS/2 emitidos por los cheros de dispositivos localizados en /dev/input/mouseX , donde X es un nmero de 92

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 3.2: Arquitectura del servidor dispositivo. Los detalles del protocolo de ratn PS/2 pueden consultarse en el apndice A Protocolo del ratn PS/2. phidgets Java lib versin 2.1 http://www.phidgets.com Licencia: LGPL versin 3 Esta librera es proporcionada por el fabricante Phidgets para poder acceder a sus dispositivos desde el lenguaje de programacin Java. Esta librera depende de la librera nativa phidgets del sistema operativo para acceder a dichos dispositivos. Actualmente la librera nativa se encuentra disponible para Windows, GNU/Linux y MAC OS X, Windows Mobile/CE e iPhone. v4l4j http://code.google.com/p/v4l4j Licencia: GPL versin 3 Esta librera permite acceder a interfaces de captura de vdeo compatibles con Video4Linux, una API para dispositivos de vdeo incorporada en el kernel de Linux. Por tanto la librera depende directamente del sistema operativo GNU/Linux y de un dispositivo compatible con Video4Linux para poder capturar imgenes de los mismos. Puesto que el servidor se encuentra en el vehculo y funcionar bajo Linux, no existe inconveniente en crear esta dependencia con este sistema operativo. Se ha comprobado que las webcams del vehculo son compatibles con esta librera. Como alternativa se contempl Palantir http://www.fastpath.it/products/palantir, un servidor escrito en C que permite obtener una imagen capturada por un dispositivo compatible con Video4Linux. Esta aplicacin est pensada para hacer streaming de dichas imgenes por Internet. La idea hubiera sido conectar el cliente a este servidor para obtener las imgenes.

3.2.3. Arquitectura de comunicacin entre cliente/servidor

El diagrama de esta arquitectura se encuentra en la gura 3.3.

Figura 3.3: Arquitectura de comunicacin entre cliente/servidor El cliente se comunicar con el servidor empleando la tecnologa Java RMI (Remote Method Invocation) que permite invocar en una mquina remota un mtodo de una clase determinada. 93

Captulo 3. Diseo del software RMI se apoya directamente en los protocolos TCP/IP como sistema de comunicacin. La red empleada en este caso es de tipo Wireless LAN, denida por el estndar IEE 802.11 y ms comnmente conocida como Wi-Fi. RMI permite realizar aplicaciones distribuidas de forma sencilla al evitar la necesidad de establecer un protocolo de mensajes en la aplicacin a nivel de sockets, puesto que directamente se invoca un mtodo en un objeto de la mquina remota y se obtiene una respuesta. Para conseguirlo, se dene una clase con mtodos remotos, y se registra un objeto de esta clase en un registro RMI. Al registro, acceden los clientes para obtener una referencia al objeto remoto y poder invocar sus mtodos remotos como si de un objeto local se tratara, pero en en realidad se ejecutan en la mquina remota. La forma de acceso se basa en un nombre nico que se le da al objeto al registrarlo en el registro RMI. El registro de un objeto remoto en el registro RMI se hace de la siguiente forma: Primero, se dene una interfaz remota:

// La interfaz remota a definir debe heredar de java.rmi.Remote public interface Hello extends java.rmi.Remote{ // Aqu se definen los mtodos remotos String sayHello() throws java.rmi.RemoteException; }
Luego, se registra un objeto de una clase que implemente la interfaz en el registro RMI:

// Server es una clase que implementa la interfaz Hello Server obj = new Server(); // Exportacin del objeto en un stub Hello stub = (Hello) UnicastRemoteObject.exportObject(obj, 0); // Obtencin del registro RMI de esta mquina Registry registry = LocateRegistry.getRegistry(); // Registro (bind) del objeto en el registro RMI con un nombre registry.bind("nombre del servicio", stub);
Por ltimo, se obtiene la referencia de un objeto remoto en el registro RMI:

// Obtencin del registro RMI de la mquina remota Registry registry = LocateRegistry.getRegistry(IP); // Obtencin de la referencia al objeto remoto Hello stub = (Hello) registry.lookup("nombre del servicio"); // Invocacin del mtodo, se hace en la mquina remota String response = stub.sayHello();
La arquitectura de comunicacin se basar en que cada dispositivo en el vehculo estar representado por una clase con mtodos remotos para que sean invocados desde el cliente. El servidor se encargar de desplegar el registro RMI y de registrar en l los objetos (servicios RMI) que permitirn a los clientes manejar los dispositivos. El nombre de registro de cada servicio deber ser diferente, puesto que deben ser nicos. 94

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala Para poder determinar los dispositivos disponibles en el registro RMI, el servidor crear una lista de servicios que podr ser accedida tambin con mtodos remotos utilizando RMI. La lista se registrar con un nombre nico bien conocido, lo que permitir a los clientes conectarse a ella fcilmente. El diagrama de la gura 3.4 describe como se relacionan los elementos que intervienen en este proceso.

Figura 3.4: Despliegue de servicios RMI en el servidor y acceso por parte del cliente

3.2.4. Arquitectura alternativa basada en sockets

Como alternativa a esta arquitectura de comunicacin se contempl la posibilidad de emplear sockets para la comunicacin, puesto que al ser una herramienta de ms bajo nivel podra ofrecer mejor rendimiento que RMI. Con objeto de poder comparar las dos tecnologas, se realiz una prueba incluida en el apndice C Prueba de sockets frente a RMI. Los resultados de esta prueba concluyen que, la diferencia entre RMI y sockets no es tan importante como para no optar por las ventajas de diseo e implementacin que ofrece RMI. No obstante, los sockets son una herramienta ms rpida.

3.2.5. Separacin en subsistemas

En las secciones anteriores se han denido dos sistemas principales: el cliente y el servidor. Adems, de las caractersticas del sistema de comunicacin se extrae un tercer sistema, que denir las interfaces de comunicacin entre el cliente y el servidor. Es necesario separar estos sistemas principales en varios subsistemas, que puedan tratarse de forma independiente entre s. En este contexto un subsistema dene un conjunto de clases que colaboran entre s con una responsabilidad en comn. El sistema de comunicacin cliente/servidor incluye los subsistemas que denen las interfaces remotas de los servicios que se alojarn en el registro RMI: Interfaces de dispositivos: dene las interfaces remotas para interactuar con los distintos dispositivos a travs de RMI. Listado de servicios: dene las interfaces remotas para poder listar los servicios disponibles en un servidor a travs de RMI. El sistema servidor est denido por los subsistemas: Conguracin: congura los dispositivos en el servidor en funcin de un archivo de conguracin. 95

Captulo 3. Diseo del software Implementacin de dispositivos: implementa las interfaces de dispositivos para poder utilizar un dispositivo a travs de RMI. Libreras de dispositivos: utilizadas en las implementaciones de dispositivos para utilizar los dispositivos. Servicio: se la asigna un dispositivo implementado y se encarga de registrarlo/borrarlo del registro RMI. Lista de servicios: es una lista con todos los servicios del servidor que permite iniciarlos y detenerlos, adems de permitir al cliente obtener informacin de los servicios que contiene a travs de RMI. Registro RMI: el servidor ser responsable de desplegar el registro RMI. El sistema cliente incluye: Cliente de dispositivo: responsable de conectar con un dispositivo a travs de RMI. Lista de dispositivos: acceder al listado de servicios del servidor para obtener los datos necesarios para crear y listas los clientes de dispositivos. Interfaz principal: denir la ventana principal de la interfaz de usuario. Interfaces secundarias: dene las ventanas secundarias de la interfaz que dependern de la interfaz principal.

Control: dene la interfaz de control remoto del vehculo. Grcas: dene la interfaz de elaboracin de grcas. Captura de datos: dene la interfaz de captura de datos. Cmaras: dene la interfaz de visin de cmaras. Visor de sensores: dene la interfaz de visualizacin de cada sensor. Dilogos: dene los dilogos de la aplicacin como el de conexin y el de desconexin de un servidor entre otros. En la gura 3.5 se representan todos los sistemas y subsistemas y las interacciones principales entre ellos. En la seccin de diseo detallado se proceder a una denicin ms amplia de cada subsistema.

3.3. Diseo de datos

El diseo de datos crea un modelo de los datos y la informacin, deniendo las estructuras de datos a nivel de componentes y, si se utilizan, las bases o almacenes de datos. 96

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 3.5: Representacin de sistemas y subsistemas

3.3.1. Informacin comn a los dispositivos

Todos los dispositivos dispondrn de la siguiente informacin accesible de forma remota: Nombre de dispositivo: una ristra que se obtendr del archivo de conguracin del servidor y que servir para identicar al dispositivo en la interfaz de usuario. Identicador: un nmero entero positivo que identicar de forma unvoca a cada dispositivo, y que se utilizar como nombre del servicio RMI y para diferenciar un dispositivo de otro. Tipo de dispositivo: corresponder a un valor de una enumeracin donde se denirn todos los dispositivos. Localizacin: ser un valor de una enumeracin donde se denen las posibles posiciones reales de los sensores en el vehculo. Para obtener esta informacin se ha diseado la interfaz Device: 97

Captulo 3. Diseo del software

public interface Device extends java.rmi.Remote{ String getName() throws java.rmi.RemoteException; int getID() throws java.rmi.RemoteException; DeviceType getDeviceType() throws java.rmi.RemoteException; DevicePosition getDevicePosition() throws RemoteException; }

3.3.2. Listado de servicios

Para que el cliente pueda conocer que dispositivos estn disponibles en el servidor, ste desplegar en el registro RMI un servicio denido por la interfaz ServiceListing. La denicin de la interfaz ServiceListing es la siguiente:

public interface ServiceListing extends java.rmi.Remote{ String serviceName = "service-list"; public String[] getServiceList() throws java.rmi.RemoteException; }
La String serviceName ser el nombre que debe usar el servidor para desplegar el servicio y, por tanto, el que debe usar el cliente para acceder a l. El mtodo remoto getServiceList() devolver un vector de String con una entrada por cada servicio de dispositivo disponible en el servidor con la siguiente informacin separada por comas: Ristra: Identicador del dispositivo. Entero positivo: Puerto utilizado por el servicio. Valor enumerado: Tipo de servicio utilizado de una enumeracin con los tipos de servicios utilizados. El identicador se utilizar como nombre del servicio del dispositivo en el registro RMI. El puerto corresponder al puerto del registro RMI y el tipo de servicio a un valor enumerado que lo identique como servicio RMI. Alternativamente, si se utilizar un sistema de comunicacin basado en sockets, el sistema estara preparado para indicar el puerto del socket y que el servicio es de otro tipo.

3.3.3. Conguracin del servidor

Para establecer la conguracin del servidor se denir un archivo de conguracin con una lnea de caracteres por cada dispositivo. El formato de cada lnea depender del dispositivo. En el archivo se podrn introducir lneas de comentarios comenzando por el carcter #. Ejemplo:

# Esto es un comentario
En algunas de las indicaciones y ejemplos del formato de los dispositivos se han tenido que utilizar saltos de lnea, ya que toda la informacin a describir no caba bien en una. No obstante, las conguraciones deben escribirse en el archivo de conguracin siempre en una sola lnea por dispositivo. 98

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.3.3.1. Identicador de dispositivos Para identicar a cada dispositivo se utilizara el valor de la enumeracin con los tipos de dispositivos. Los valores denidos en dicha enumeracin son:

MOTOR_CONTROL SERVO_CONTROL ACCELEROMETER_SENSOR ENCODER_SENSOR INTERFACE_KIT SONAR_SENSOR IR_SENSOR CAMERA_SENSOR

3.3.3.2. Localizacin de dispositivos Con varios de los dispositivos es necesario especicar la posicin donde estn colocados en el vehculo. As la aplicacin cliente puede emplear esa informacin para indicar el usuario donde se encuentran los dispositivos. Puesto que las posiciones para colocar sensores en el vehculo son limitadas, se ha escogido un sistema basado en constantes enumeradas, que indicarn una posicin en el vehculo. Se han creado constantes para localizar las posiciones de sensores delanteras/traseras/laterales, el centro del vehculo y las cmaras delanteras/traseras. Por ltimo se ha aadido posiciones en cada ruedas para las posibles localizaciones de un encoder. El nombre de las constantes se ha escogido de forma que ayuda a tener una idea clara de a que posicin se reere cada una. Los nombres y su posicin pueden verse en la gura 3.6.

Figura 3.6: Constantes de localizaciones de sensores en el vehculo 99

Captulo 3. Diseo del software 3.3.3.3. Formato: Acelermetro phidgets

ACCELEROMETER_SENSOR=[nombre],[numero de serie],[localizacin]
nombre: nombre para identicar al dispositivo. numero de serie: nmero de serie nico identicativo del dispositivo Phidget. localizacin: constante con la posicin del dispositivo. Ejemplo:

ACCELEROMETER_SENSOR=mi acelermetro,456789,CENTER
3.3.3.4. Formato: Cmara

CAMERA_SENSOR=[nombre],[fichero de dispositivo],[ancho],[alto],[calidad], [localizacin]

nombre: nombre para identicar al dispositivo. chero de dispositivo: cadena con la ruta a un dispositivo compatible con v4l4j. ancho: ancho de la resolucin en pxeles. alto: alto de la resolucin en pxeles. calidad: nmero entre 0 y 100 indicando la calidad/compresin de las imgenes JPEG capturadas. 100 es la mnima compresin/mxima calidad y 0 es la mxima compresin/mnima calidad. localizacin: constante con la posicin del dispositivo. Ejemplo:

CAMERA_SENSOR=camara izquierda,/dev/video0,317,268,85,FRONT_LEFT_CAMERA
3.3.3.5. Formato: Controlador de motor phidgets

MOTOR_CONTROL=[nombre],[numero_serie],[ndice motor]
nombre: nombre para identicar al dispositivo. numero de serie: nmero de serie nico identicativo del dispositivo Phidget. ndice motor: 0 o 1, ndica el puerto del controlador al que est conectado el motor. Ejemplo:

MOTOR_CONTROL=mi motor,123567,0
100

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.3.3.6. Controlador de servomotor phidgets Formato:

SERVO_CONTROL=[nombre],[numero_serie],[ndice servo],[posicin mnima], [posicin mxima],[posicin inicio]

nombre: nombre para identicar al dispositivo. numero de serie: nmero de serie nico identicativo del dispositivo Phidget. ndice servo: 0 o 1, ndica el puerto del controlador al que est conectado el servomotor. El controlador usado slo tiene un puerto y por tanto el ndice correcto es 0, pero en el futuro podran utilizarse otros controladores con otros ndices. posicin mnima: nmero positivo indicando la posicin mnima del servomotor. El mnimo del controlador es 0. posicin mxima: entero indicando la posicin mxima del servo. El mximo del controlador depende del tipo de servomotor usado. posicin inicio: entero indicando la posicin de reposo del servomotor, aquella en la que el vehculo se mueve recto. Ejemplo:

SERVO_CONTROL=mi servo,123567,0,30,110,75
3.3.3.7. Placa de captura: InterfaceKit 8/8/8 phidgets Formato:

INTERFACE_KIT=[nombre],[numero_serie]
nombre: nombre para identicar al dispositivo. numero de serie: nmero de serie nico identicativo del dispositivo Phidget. Ejemplo:

INTERFACE_KIT=mi placa,123567
3.3.3.8. Infrarrojo phidgets Formato:

IR_SENSOR=[nombre],[serie interface kit],[entrada analgica],[localizacin]

nombre: nombre para identicar al dispositivo. serie interface kit: nmero de serie nico identicativo de la placa de captura a la que est conectado el sensor. La placa debe haber sido denida anteriormente en el chero de conguracin como una entrada de INTERFACE_KIT. entrada analgica: nmero de 0 a 7 correspondiente al puerto de entrada analgica de la placa de captura a la que est conectado el sensor. localizacin: constante con la posicin del dispositivo. Ejemplo:

IR_SENSOR=ir frontal izquierdo,123567,2,FRONT_LEFT

101

Captulo 3. Diseo del software 3.3.3.9. Formato: Sonar phidgets

SONAR_SENSOR=[nombre],[serie interface kit],[entrada analgica], [salida digital],[localizacin]

nombre: nombre para identicar al dispositivo. serie interface kit: nmero de serie nico identicativo de la placa de captura a la que est conectado el sensor. La placa debe haber sido denida anteriormente en el chero de conguracin como una entrada de INTERFACE_KIT. entrada analgica: nmero de 0 a 7 correspondiente al puerto de entrada analgica de la placa de captura a la que est conectado el sensor. salida digital: nmero de 0 a 7 correspondiente al puerto de la salida digital que activa el sonar. localizacin: constante con la posicin del dispositivo. Ejemplo:

SONAR_SENSOR=sonar frontal,123567,3,3,FRONT_LEFT_CORNER
3.3.3.10. Formato: Ratn como encoder

ENCODER_SENSOR=[nombre],[fichero dispositivo],[radio de rueda], [tics de una vuelta],[eje de medida],[localizacin]

nombre: nombre para identicar al dispositivo. chero de dispositivo: cadena con la ruta al dispositivo correspondiente a una interfaz de ratn PS/2. radio de rueda: el radio de la rueda del vehculo en centmetros. tics de una vuelta: tics del encoder para una vuelta completa de la rueda. eje de medida: indica que eje del ratn se utiliza para contar los tics y que sentido/signo de este eje corresponde a cuando el coche se mueve hacia adelante. El eje viene indicado por una de las constantes siguientes:

POSITIVE_X_AXIS NEGATIVE_X_AXIS POSITIVE_Y_AXIS NEGATIVE_Y_AXIS

: : : :

eje eje eje eje

X X Y Y

con con con con

sentido sentido sentido sentido

positivo. negativo. positivo. negativo.

localizacin: constante con la posicin del dispositivo. Ejemplo:

ENCODER_SENSOR=encoder,/dev/input/mouse0,0.4553,48,POSITIVE_X_AXIS, BACK_LEFT_WHEEL
102

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

3.4. Diseo de interfaz de usuario

En el diseo de interfaz se denen las distintas ventanas con las interactuar el usuario, deniendo que operaciones pueden ejecutarse. El diseo de la interfaz de usuario del cliente trata la interfaz diseada a partir del prototipo de la aplicacin cliente. El servidor no dispondr de interfaz de usuario, ya que su sistema no dispone de pantalla.

3.4.1. Interfaz de usuario del cliente

A continuacin se incluye la descripcin de la interfaz de usuario del cliente deniendo las operaciones que pueden realizarse sobre ella, relacionadas directamente con los casos de uso del anlisis (ver 2.1 Casos de uso). El diseo de algunas ventanas ha mejorado con respecto al prototipo con el objetivo de hacer la aplicacin ms sencilla e intuitiva para el usuario. Sobre todo se han incorporado iconos que ayudan a identicar las operaciones ms comunes de la interfaz, mejorando el aspecto visual de la aplicacin y estimulando la memoria visual del usuario al utilizarla. 3.4.1.1. Ventana principal La interfaz principal corresponde a la ventana principal de la aplicacin, es decir, lo que ve el usuario inicialmente tras abrir la aplicacin.

Figura 3.7: Ventana principal de la aplicacin La interfaz principal est dividida en dos reas: Men principal: situado en la parte superior de la ventana principal, muestra una serie de botones con imgenes descriptivas que permiten establecer la conexin con un servidor 103

Captulo 3. Diseo del software y abrir las distintas ventanas que conforman la aplicacin. Los botones slo se activan o desactivan cuando la aplicacin se conecta o desconecta del servidor en funcin de las precondiciones de las operaciones que ejecutan.

Botn Conectar: permite conectar a un servidor, siempre que no se est ya conectado a uno, mostrando el dilogo de conexin.

Botn Desconectar: permite desconectar del servidor actual, siempre que ya se est
conectado a uno, mostrando el dilogo de desconexin.

Botn Cerrar todo: permite cerrar la aplicacin. Si la aplicacin est conectada al

servidor, se mostrar un dilogo avisando de la posible prdida de datos.

Botn Controlar el vehculo: permite abrir la ventana de control del vehculo, ejecutando la operacin Controlar Vehculo.

Botn Ver cmaras: permite abrir el visor de cmaras, ejecutando la operacin Observar Cmaras.

Botn Capturar datos: permite abrir el visor de captura de datos, ejecutando la operacin Capturar datos.

Botn Crear grcas: permite abrir el visor de grcas, ejecutando la operacin Hacer grca.

Botn Seleccionar lenguaje: permite establecer el lenguaje utilizado por la aplicacin

mostrando el dilogo de cambio de lenguaje.

Botn Establecer tiempo act.: permite cambiar el tiempo de actualizacin, ejecutando la operacin Establecer Tiempo Actualizacin rea principal de trabajo: que muestra una vista en planta de una representacin del interior del vehculo.

Imagen en planta del vehculo: esta imagen representa el interior del vehculo. Se
puede mover por el rea de trabajo e incluir a los recuadros de los sensores.

Sensores: al conectarse a un servidor, se representarn los sensores conectados

al vehculo mediante cuadros con imgenes y colores representativos dependiendo del sensor. Al hacer clic en uno de los recuadros se abrir un visor de dicho sensor (operacin Abrir Sensor ).

Visor de sensor: un visor de sensor permite visualizar la medida del sensor que tiene
asociado en pantalla.

A continuacin puede verse una imagen que representa la visualizacin de los sensores y los visores de sensores sobre la imagen en planta del vehculo una vez se ha establecido conexin con un servidor: 104

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 3.8: Ventana principal: detalle de disposicin de sensores en el vehculo

3.4.1.2. Dilogo de conexin Este dilogo se abre cuando el usuario quiere conectarse a un servidor para solicitar los datos de conexin.

Figura 3.9: Dilogo de conexin

El botn Conectar ejecuta la operacin Conectar a Servidor con los datos introducidos en la ventana. El botn Cancelar cierra la ventana sin hacer nada ms. 3.4.1.3. Dilogo de desconexin Este dialogo se abre para conrmar la desconexin manual del servidor a peticin del usuario y evitar posibles prdidas de datos por ello. 105

Captulo 3. Diseo del software

Figura 3.10: Dilogo de desconexin El botn Desconectar ejecuta la operacin Desconectar de Servidor. El botn Cancelar cierra el dilogo sin hacer nada ms. 3.4.1.4. Dilogo de cierre

Este dilogo se abre para conrmar el cierre de la aplicacin cuando se est conectado a un servidor para evitar posibles prdidas de datos.

Figura 3.11: Dilogo de cierre El botn Cerrar todo, cierra la aplicacin. El botn Cancelar cierra el dilogo sin hacer nada ms. 3.4.1.5. Dilogo de cambio de lenguaje

Este dilogo se muestra cuando el usuario quiere cambiar el lenguaje de la aplicacin.

Figura 3.12: Dilogo de cambio de lenguaje El dilogo dispone de un botn para el lenguaje ingls y un botn para el lenguaje espaol. Ambos botones ejecutan la operacin Selecciona idioma con distintos parmetros. Una vez seleccionado el lenguaje, se cierra la aplicacin y se vuelve a abrir con el nuevo lenguaje. 3.4.1.6. Visores de sensor

El visor es una pequea ventana anclada al rea principal de trabajo que puede moverse por la misma y cerrarse a voluntad. Todos los visores comparten las siguientes operaciones que se ejecutan con los botones de la parte superior de cada visor. De izquierda a derecha: 106

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala Botn Actualizar ahora: ejecuta la operacin Actualizar Manualmente, actualizando inmediatamente el visor con las medidas del sensor. Botn Actualizar automticamente: es un botn de seleccin. Cuando se selecciona ejecuta la operacin Iniciar Actualizacin Automtica) que inicia un proceso de actualizacin del visor con las medidas del sensor a intervalos de tiempo discretos. Cuando se deselecciona se ejecuta la operacion Detener Actualizacin Automtica, deteniendo el proceso. Botn Establecer tiempo de actualizacin: ejecuta la operacin Establecer Tiempo Actualizacin mostrando el dilogo de tiempo de actualizacin. Para cada sensor se despliega un rea de visualizacin diferente en funcin del tipo de sensor que representa: visor acelermetro, visor cmara, visor encoder, visor infrarrojo y visor sonar.

Figura 3.13: Visor acelermetro

Figura 3.14: Visor cmara

Figura 3.15: Visor encoder

Figura 3.16: Visor infrarrojo 107

Captulo 3. Diseo del software

Figura 3.17: Visor sonar 3.4.1.7. Dilogo de tiempo de actualizacin

Este dilogo permite cambiar el tiempo de actualizacin denido para uno o ms sensores introduciendo el tiempo en un recuadro.

Figura 3.18: Dilogo de cambio de tiempo de actualizacin El botn Por Defecto ejecuta la operacin Establecer Tiempo por Defecto, que establece el tiempo en el recuadro al valor por defecto de tiempo de actualizacin. El botn Conrmar ejecuta la operacin Conrmar Tiempo, que cambia el tiempo de actualizacin de el/los sensor/es. El botn Cancelar cierra el dilogo sin hacer nada ms. 3.4.1.8. Ventana de control del vehculo

Esta ventana permite controlar el vehculo mediante el controlador de motor y el controlador de servomotor.

Figura 3.19: Ventana de control del vehculo Los controles deslizantes de aceleracin, velocidad y posicin, permiten controlar los valores 108

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala correspondientes del motor y el servomotor, pudiendo introducirlos directamente en los recuadros con echas que se encuentran a su lado. Los cambios de velocidad ejecutan la operacin Establecer Velocidad. Los cambios de aceleracin ejecutan la operacin Establecer Aceleracin. Los cambios de posicin ejecutan la operacin Establecer Posicin. Tambin puede controlarse la velocidad y la posicin en el rea de la derecha, moviendo el punto rojo con el ratn manteniendo el botn izquierdo pulsado. El centro del circulo representa un estado de reposo, donde la velocidad del motor es cero y la posicin del servomotor es la de reposo (posicin inicial). Al mover el punto en el eje vertical, se producen cambios en la velocidad del motor. Hacia arriba, cambia la velocidad hacia el mximo valor de velocidad. Hacia abajo cambia la velocidad hacia el mnimo valor de velocidad. Al mover el punto en el eje horizontal, se producen cambios en lo posicin del servomotor. Hacia la izquierda, cambia la posicin hacia el mximo valor del servomotor. Hacia la derecha, cambia la posicin hacia el mnimo valor del servomotor. Si se presiona el botn derecho del ratn en el rea, la velocidad y la posicin vuelven al centro del crculo. Por ltimo, puede detenerse el vehculo con el botn que muestra la seal de STOP, que ejecuta la operacin Detener Vehculo. 3.4.1.9. Visor de cmaras Este visor es una ventana independiente que sirve para poder visualizar una o ms cmaras del vehculo.

Figura 3.20: Ventana de visualizacin de cmaras El visor incluye un Panel de cmara por cada cmara disponible en el vehculo y las sita agrupadas dependiendo de si la cmara son frontales o traseras. En la parte superior del visor puede 109

Captulo 3. Diseo del software seleccionarse mediante tres botones si se quieren ver todas las cmaras, slo las frontales o slo las traseras. 3.4.1.10. Panel de cmara

Este panel permite controlar una cmara individual en un visor de cmaras.

Figura 3.21: Panel de control de cmara En la parte superior del panel se muestra informacin correspondiente a la cmara: el nombre del dispositivo, su ID, la resolucin de la cmara en pxeles y los frames por segundo (FPS). En medio se visualiza la imagen de la cmara. En la parte inferior se incluyen botones para controlar la cmara: Botones disponibles en cualquier momento:

Botn Ver: es un botn de seleccin. Cuando se selecciona ejecuta la operacin

Iniciar Streaming, mostrando las imgenes de la cmara en el panel. Cuando se deselecciona se ejecuta la operacin Detener Streaming, dejando de mostrar dichas imgenes.

Botn Capturar vdeo: es un botn de seleccin. Cuando se selecciona ejecuta la

operacin Iniciar Captura, iniciando la captura de las imgenes provenientes de la cmara. Cuando se deselecciona ejecuta la operacin Detener Captura, deteniendo la captura.

Botn Guardar imagen actual: ejecuta la operacin Guardar Imagen para almacenar
la imagen actual de la interfaz en un chero en el disco.

Botn Establecer tiempo de actualizacin: ejecuta la operacin Establecer Tiempo

Actualizacin para cambiar el tiempo de actualizacin de la cmara. Botones disponibles slo si se ha realizado una captura de vdeo:

Botn Reproducir vdeo capturado: es un botn de seleccin. Cuando se selecciona

se ejecuta la operacin Ver Captura, iniciando la reproduccin del vdeo capturado hasta su nalizacin. Mientras se est reproduciendo puede deseleccionarse el botn para pausar la reproduccin del vdeo. 110

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Botn Borrar vdeo capturado: ejecuta la operacin Borrar Captura, borrando las
imgenes capturadas.

Botn Guardar vdeo capturado: ejecuta la operacin Guardar Vdeo para guardar el
vdeo capturado en una carpeta en el disco. Se guarda una imagen por cada frame guardado cuyo nombre es el nmero de frame.

Control deslizante: permite seleccionar el frame a mostrar de la captura moviendo el

deslizador. La posicin ms a la izquierda representa el primer frame y la ms a la derecha el ltimo frame.

Botn Ir al primer frame: establece como frame actual el primer frame capturado. Botn Ir al ltimo frame: establece como frame actual el ltimo frame capturado.
3.4.1.11. Ventana de captura de datos Esta ventana independiente que sirve para poder recolectar datos de uno o ms sensores y almacenarlos en un chero.

Figura 3.22: Ventana de captura de datos La ventana presenta una tabla de datos donde se muestran las con el nombre del sensor, su ID, el tiempo en milisegundos transcurridos desde que se inicio la captura y el dato capturado del sensor para ese tiempo. En la parte superior se incluyen una serie de botones. De izquierda a derecha: Botn Seleccionar sensores: muestra el dilogo de seleccin de sensores para poder realizar las operaciones de Seleccionar Sensor. Botn Establecer tiempo de actualizacin: ejecuta la operacin Establecer Tiempo Actualizacin para cambiar el tiempo de actualizacin de los sensores seleccionados. Botn Iniciar/Detener captura: es un botn de seleccin. Cuando se selecciona se ejecuta la operacin Iniciar Captura comenzando la captura de datos de los sensores seleccionados y su muestra en la tabla. Cuando se deselecciona se ejecuta la operacin Detener Captura deteniendo la captura de datos. 111

Captulo 3. Diseo del software Botn Limpiar captura: ejecuta la operacin Limpiar Captura eliminando los datos capturados en la tabla. Botn Guardar captura: ejecuta la operacin Guardar Captura almacenando en un chero separado por comas (csv) todos los datos de la tabla. 3.4.1.12. Ventana de elaboracin de grcas

Esta ventana independiente sirve para elaborar grcas con los datos de los sensores.

Figura 3.23: Ventana de elaboracin de grcas La ventana presenta un rea donde se dibujan las grcas con lneas de colores a medida que se van capturando los datos de los sensores. En la parte superior se incluyen una serie de botones. De izquierda a derecha: Botn Seleccionar sensores: muestra el dilogo de seleccin de sensores para poder realizar las operaciones de Seleccionar Sensor. Botn Establecer tiempo de actualizacin: ejecuta la operacin Establecer Tiempo Actualizacin para cambiar el tiempo de actualizacin de los sensores seleccionados. Botn Iniciar/Detener captura: es un botn de seleccin. Cuando se selecciona se ejecuta la operacin Iniciar Grca comenzando el dibujado de las grcas de los sensores seleccionados. Cuando se deselecciona se ejecuta la operacin Detener Grca deteniendo el dibujado de las grcas. Botn Limpiar: ejecuta la operacin Limpiar Grca eliminando cualquier grca dibujada. Botn Guardar captura: ejecuta la operacin Guardar Grca almacenando en un chero de imagen PNG la grca mostrada en la interfaz. 3.4.1.13. Dilogo de guardado de archivos

Este dilogo sirve para poder guardar un chero y est implementado de serie en Java con la clase javax.swing.JFileChooser. La extensin por defecto se escoge en funcin del tipo de archivo a guardar. 112

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 3.24: Dilogo de guardado de archivos

3.4.1.14. Dilogo de seleccin de sensores Este dilogo sirve para poder seleccionar uno o ms sensores de la lista de sensores del servidor al que se est conectado, con el objetivo de poder capturar o elaborar grcas con sus datos. El dilogo muestra dos listas. La lista de sensores disponibles est a la izquierda y muestra los sensores que no se han seleccionado.

Figura 3.25: Dilogo de seleccin de sensores

La lista de sensores seleccionados est a la derecha y muestra los sensores que se han seleccionado. El botn Aadir ejecuta la operacin Aadir Sensor, que permite mover el sensor sobre cuyo nombre se ha hecho clic (en la imagen se muestra un fondo azul sobre el texto) de la lista de disponibles a la lista de seleccionados. De forma similar, el botn Quitar ejecuta la operacin Quitar Sensor, que quita un sensor de la lista de seleccionados y volverlo a colocar en la lista de disponibles. El botn Limpiar, quita todo los sensores de la lista de seleccionados. Para terminar la seleccin y cerrar el dilogo se debe hacer clic en el botn Terminar, ejecutando la operacin Conrmar Tiempo. 113

Captulo 3. Diseo del software

3.5. Diseo detallado

En el diseo detallado se disean las clases y los mtodos que conforman los subsistemas. Los diagramas de clase muestran la estructura de un sistema mostrando las clases, sus atributos y las relaciones entre ellas, incluyendo asociacin, pertenencia, herencia, etc.

3.5.1. Patrones de diseo

Los patrones de diseo empleados se explican en el apndice D Patrones de diseo.

3.5.2. Sistema de comunicacin cliente/servidor

3.5.2.1. Interfaces de dispositivos remotos Para establecer comunicacin con los dispositivos, es necesario denir las operaciones disponibles en cada uno en una interfaz remota. El servidor, implementar en una clase la interfaz del dispositivo, que trabajar con el dispositivo real a travs de la biblioteca correspondiente. El cliente utilizar la interfaz remota para controlar el dispositivo a travs de una referencia remota. El diagrama de la gura 3.26 representa una organizacin de los dispositivos en forma de rbol. En la raz del rbol est la interfaz Device, deniendo las operaciones comunes a todos los dispositivos y heredando de la interfaz java.rmi.Remote. En Device se denen las operaciones para obtener un nombre del dispositivo, el tipo del dispositivo segn la enumeracin DeviceType y un identicador nico, que se utilizar para registrar el dispositivo en el registro RMI. Tambin se incluye una operacin para obtener la localizacin del dispositivo en el vehculo segn la enumeracin DevicePosition. Finalmente, de Device se extraen dos subinterfaces que representan dos tipos de dispositivos: ControlDevice, representando a dispositivos de control y SensorDevice, representando a dispositivos sensores. Se han denido interfaces para el controlador de motor y servomotor, cmaras web, acelermetro, sonares, infrarrojos y encoder. Dada la variedad de dispositivos con sus propias libreras, existen varias excepciones a tratar. Para transmitir cualquier excepcin relacionada con el funcionamiento del dispositivo al cliente durante la comunicacin remota, se utilizar la excepcin DeviceException. La excepcin ser declarada en todos los mtodos remotos susceptibles de fallar a causa de una excepcin del dispositivo. Por ltimo, se dene la clase abstracta AbstractDevice, que implementa las operaciones comunes a todos los dispositivos de la interfaz Device. Cuando se implemente la clase de un dispositivo, se heredar de AbstractDevice para proveer la implementacin de los mtodos de Device. Para proveer de los mtodos concretos de cada dispositivo implementar la interfaz correspondiente. Tambin se dene el mtodo abstracto closeDevice() a implementar por las clases que hereden de AbstractDevice, con el objetivo de poder cerrar correctamente cada dispositivo cuando se detenga el servidor.

114

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

115

Figura 3.26: Clases de interfaces de dispositivos remotos

Captulo 3. Diseo del software 3.5.2.2. Interfaz de listado de servicios

Para que el cliente pueda saber que servicios tiene el servidor, se utilizar un servicio RMI del que se obtendr una lista con la informacin de los servicios disponibles en el servidor. El servicio viene denido por la interfaz ServiceListing. Por motivos de posibles ampliaciones del software, se dene la enumeracin ServiceType deniendo los tipos de servicios disponibles en el servidor. Esto permitira diferenciar un servicio RMI de un servicio implementado de otra forma, por ejemplo, con un socket.

Figura 3.27: Clases de interfaz de listado de servicios

3.5.3. Sistema servidor

El sistema servidor se basa en la clase ServerApp, que representa al servidor en s misma. Permitir congurar, iniciar y detener el servidor. Para la conguracin se apoyar en la clase Congurer, y para iniciar/detener todos los servicios en la clase ServiceList.

Figura 3.28: Clases del sistema servidor

3.5.3.1.

Conguracin del servidor

Para congurar el servidor se utilizar la clase Congurer mediante un mtodo esttico al que se le pasar el archivo de conguracin. El mtodo devolver un vector de AbstractDevice con los dispositivos inicializados segn la conguracin descrita en el chero. 3.5.3.2. Lista de servicios

Para manejar los servicios se utilizar una lista de servicios representada en la clase ServiceList, que implementa la interfaz ServiceListing. ServiceList se registrar en el registro RMI para permitir al cliente listar los servicios disponibles en el servidor. Adems permitir iniciar y detener todos los servicios incluidos en la lista. 116

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 3.29: Clases de lista de servicios 3.5.3.3. Implementacin de dispositivos Las implementaciones de los dispositivos heredan de la clase AbstractDevice e implementa la interfaz de dispositivo correspondiente. En la implementacin de las operaciones de la interfaz se interacta con el dispositivo real utilizando su librera correspondiente: phidgets, v4l4j o mouselib. El diagrama de clases de las implementaciones puede verse en la gura 3.30 Los parmetros de los constructores de las implementaciones de los dispositivos se basan en los datos que deben escribirse para cada dispositivo en el chero de conguracin del servidor, tal y como se ha descrito en el apartado 3.3.3 Conguracin del servidor. Los constructores son: AccelerometerDevice(String name, int serial). CameraDevice(String name, String device, int width, int height, int compression). InterfaceKitDevice(String name, int serial). IRDevice(String name, InterfaceKit ikit, int sensorPort). MotorControlDevice(String name, int serial,int motorIndex). MouseEncoderDevice(String name, String le, double wheelRadius, int ticsPerTurn, MouseAxis mouseAxis). ServoControlDevice(String name, int serial, int index, int min, int max, int start). SonarDevice(String name, InterfaceKit ikit, int sensorPort, int outputPort).

117

Captulo 3. Diseo del software

118 Figura 3.30: Clases de implementacin de dispositivos

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.5.3.4. Despliegue de servicios Para que el servidor despliegue de forma efectiva los servicios, se ha diseado la interfaz ServiceDevice que dene los mtodos que debera implementar una clase para iniciar y detener un servicio. La clase ServiceRMIDevice implementa esta interfaz para poder iniciar y detener un servicio RMI asociado a un objeto de la clase AbstractDevice, registrando y borrando el dispositivo del registro RMI. Este diseo deja abierta la posibilidad de utilizar la interfaz ServiceDevice para implementar un servicio basado en sockets, por ejemplo.

Figura 3.31: Clases de despliegue de servicios

3.5.4. Sistema cliente

El sistema cliente se basa en la clase ClientApp, que representa al cliente en s misma. La clase manejar a la interfaz principal de la aplicacin (clase MainFrame), que desplegar al iniciarse. Adems ser responsable de la conexin/desconexin con un servidor, por lo que almacenar la IP y puerto del servidor actual para que puedan ser utilizadas por el resto de sistemas. Por ltimo, tendr una lista de servicios del servidor al que se est conectado representada en la clase DeviceList.

Figura 3.32: Clases del sistema cliente 3.5.4.1. Listado de dispositivos del servidor La clase DeviceList es una lista que contiene los servicios de un servidor. Los servicios se obtienen a travs del servicio RMI ServiceListing desplegado por el servidor. Una vez obtenidos los servicios, la clase crear un objeto DeviceInfo por cada servicio. El objeto DeviceInfo incluir un objeto que implemente la interfaz ClientDevice para establecer la comunicacin con el dispositivo remoto. Si DeviceInfo se reere a un dispositivo del tipo SensorDevice, incluir adems un 119

Captulo 3. Diseo del software objeto de la clase Updater con objeto de poder actualizar automticamente datos del dispositivo en la interfaz.

Figura 3.33: Clases de listado de dispositivos del servidor 3.5.4.2. Conexin con dispositivos remotos

Se dene en la interfaz ClientDevice los mtodos necesarios para establecer una conexin con un servicio y obtener una referencia a un objeto Device. La clase ClientRMIDevice, implementa esta interfaz con objeto de conectar con un servicio RMI y obtener una referencia al objeto remoto de tipo Device. Ante cualquier error de conexin se utilizar la excepcin ConnectException. As, es posible enmascarar las excepciones producidas por los mtodos de conexin. Este diseo permitira en el futuro implementar una clase para comunicarse mediante sockets con los dispositivos remotos.

Figura 3.34: Clases de conexin con dispositivos remotos 3.5.4.3. Actualizacin automtica de datos

Este subsistema se ha diseado para poder actualizar automticamente los datos provenientes de sensores en el resto de la aplicacin. Por ello se ha utilizado el D.4 Patrn Observador. 120

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 3.35: Clases de actualizacin automtica de datos La clase Updater se crea en el nodo DeviceInfo junto con un SensorDevice, que implementa el mtodo update() devolviendo un objeto con los datos del sensor. Updater utiliza este mtodo en su propio mtodo update, noticando a los observadores del nuevo dato. De esta forma, cada vez que se invoca update, los observadores obtienen una copia del dato del sensor. El proceso de actualizacin automtica se implementa en el mtodo autoUpdate(), que utiliza el D.5 Patrn ThreadPool. Para ello se emplea el mtodo scheduleAtFixedRate() de un ThreadPool nico para todos los objetos Updater. As se ejecuta una tarea peridicamente que invoca al mtodo update() del Updater. El tiempo viene determinado por el atributo updateTime, que indica el tiempo en milisegundos. Este tiempo puede cambiarse con el mtodo setUpdateTime(). Este proceso puede verse en el diagrama de la gura 3.36, que comienza en el hilo del ThreadPool y termina en el observador.

Figura 3.36: Diagrama de secuencia del proceso de actualizacin automtica

Por otro lado, la clase SensorCapturer se ha diseado con el objetivo de poder capturar los datos de un sensor. La clase implementa la interfaz Observer para observar un objeto Updater y extiende la clase Observable para que otras clases puedan observar los datos que captura. Cuando se notica un nuevo dato proveniente del Updater, se almacena junto con una marca 121

Captulo 3. Diseo del software de tiempo y se notica a los observadores el cambio. La clase dispone de mtodos para iniciar/detener la captura y borrar los datos capturados. Esta clase es usada por la interfaz de captura de datos y la interfaz de elaboracin de grcas para almacenar los datos de los sensores. Este proceso puede verse en el diagrama de la gura 3.37, que comienza con la noticacin a los observadores de Updater y termina en el observador.

Figura 3.37: Diagrama de secuencia del proceso de noticacin a los observadores de SensorCapturer

3.5.4.4.

Interfaz principal

Este subsistema est representado por la clase MainFrame, que hereda del componente javax.swing.JFrame que representa una ventana independiente en pantalla. La clase contiene un objeto JDesktopPane que permite la representacin grca de los sensores del vehculo en la interfaz y la apertura de los visores de sensores. La interfaz principal puede mostrar un dialogo de conexin (clase ConnectDialog), un dilogo de desconexin (clase DisconnectDialog), los visores de sensores (clase SensorVisor), la ventana de control del vehculo (clase ControlFrame), la ventana de grcas (clase ChartFrame), la ventana de captura de datos (clase CaptureFrame) y el visor de cmaras (clase CameraFrame). Para mostrar los componentes anteriores se emplean comandos asociados a los botones de la interfaz mediante el patrn de diseo D.1 Patrn Comando,

122

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

123

Figura 3.38: Clases de interfaz principal

Captulo 3. Diseo del software 3.5.4.5. Comando Conectar a Servidor

Cuando en la interfaz principal se presiona el botn Conectar, se ejecuta el comando ShowConnectDialog, mostrando el dilogo de conexin (ConnectDialog). Si en el dilogo se presiona el botn Conectar, se ejecuta el comando ConnectCommand. Este cambia la IP y el puerto en la clase esttica ClientApp, y ejecuta el mtodo connectServer().

Figura 3.39: Clases del comando conectar a servidor

3.5.4.6.

Comando Desconectar de Servidor

Cuando en la interfaz principal se presiona el botn Desconectar, se ejecuta el comando ShowDisconnectDialog, mostrando el dilogo de desconexin (DisconnectDialog). Si en el dilogo se presiona el botn Desconectar, se ejecuta el comando DisconnectCommand. Este ejecuta el mtodo disconnectServer() de la clase esttica ClientApp. 124

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 3.40: Clases del comando desconectar de servidor

3.5.4.7. Comando Controlar Vehculo Cuando en la interfaz principal se presiona el botn Controlar el Vehculo, se ejecuta el comando ControlVehicleCommand, que utiliza la clase DeviceList para obtener una referencia a un dispositivo de tipo motor y otro de tipo servomotor. Los dos se utilizan para crear la ventana de control del vehculo (clase ControlFrame).

Figura 3.41: Clases del comando controlar vehculo

3.5.4.8. Comando Observar Cmaras Cuando en la interfaz principal se presiona el botn Ver Cmaras, se ejecuta el comando ViewCamerasCommand, que utiliza la clase DeviceList para obtener una referencia a las cmaras disponibles en el servidor. Estas cmaras se utilizan para crear el visor de cmaras (clase CameraFrame). 125

Captulo 3. Diseo del software

Figura 3.42: Clases del comando observar cmaras

3.5.4.9.

Comando Capturar Datos

Cuando en la interfaz principal se presiona el botn Capturar Datos, se ejecuta el comando CaptureDataCommand, que utiliza la clase DeviceList para obtener una referencia a los sensores disponibles en el servidor, excluyendo a las cmaras. Estos sensores se se utilizan para crear el visor de captura de datos (clase CaptureFrame).

Figura 3.43: Clases del comando capturar datos

3.5.4.10.

Comando Hacer Grcas

Cuando en la interfaz principal se presiona el botn Crear Grcas, se ejecuta el comando MakeChartcommand, que utiliza la clase DeviceList para obtener una referencia a los sensores disponibles en el servidor, excluyendo a las cmaras. Estos sensores se utilizan para crear el visor de grcas (clase ChartFrame). 126

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 3.44: Clases del comando hacer grcas 3.5.4.11. Comando Seleccionar Idioma Cuando en la interfaz principal se presiona el botn Seleccionar Lenguaje, se ejecuta el comando ShowLanguageDialog, mostrando el dilogo de seleccin de lenguaje (LanguageDialog). Si en el dilogo se presiona el botn del lenguaje ingls o el del lenguaje espaol, se ejecuta el comando SelectLanguageCommand. Este cambia el lenguaje de la aplicacin con el mtodo setLanguage() de la clase ClientApp.

Figura 3.45: Clases del comando seleccionar idioma 3.5.4.12. Interfaz de control Este subsistema se encarga de desplegar una interfaz y los componentes necesarios para poder controlar el vehculo a travs de un controlador de motor y un controlador de servomotor. Puesto que esta interfaz tiene diferentes vistas sobre los mismos datos (aceleracin, velocidad y posicin), se ha utilizado el patrn Modelo-Vista-Controlador (ver D.3 Patrn Modelo-Vista-Controlador). Tambin se ha utilizado el patrn Comando para implementar los comandos de cambio de aceleracin, velocidad y posicin, as como el comando de detener el vehculo. En el caso del motor, se encapsulan los datos de aceleracin y velocidad en un modelo representado por la clase MotorModel. Si se cambia la velocidad o la aceleracin en el modelo, 127

Captulo 3. Diseo del software este actualizar las vistas y ejecutar el comando correspondiente, SetAcelerationCommand o SetVelocityCommand. El modelo adems gestiona el controlador de motor representado por la interfaz remota MotorControl. Las vistas en este caso son controles de tipo JSlider, JSpinner y el control grco implementado en la clase VisualControlPanel. Por motivos de claridad en el diagrama se han representado las vistas como la clase View. Ante una manipulacin de los controles se producen un evento dirigido a una clase ChangeListener que ejecuta el comando setAceleration() o SetVelocity() del modelo. Este proceso corresponde al controlador del patrn.

Figura 3.46: Clases del control del motor

En el caso del servo, se encapsula la posicin en un modelo representado por la clase ServoModel. Si se cambia la posicin en el modelo, este actualizar las vistas y ejecutar el comando SetPositionCommand. El modelo adems gestiona el controlador de servomotor representado por la interfaz remota ServoControl. Las vistas son controles de tipo JSlider, JSpinner y el control grco implementado en la clase VisualControlPanel. Nuevamente, por claridad se han representado las vistas como una nica clase View. Ante una manipulacin de los controles se producen un evento dirigido a una clase ChangeListener que ejecuta el comando setPosition() del modelo. Este proceso corresponde al controlador del patrn. 128

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 3.47: Clases del control del servomotor

3.5.4.13. Visores de sensores Los visores de sensores se basan en una clase base abstracta SensorVisor que hereda de javax.swing.JInternalFrame. Un JInternalFrame es una pequea ventana interna a la aplicacin parecida a un JFrame que se encuentra dentro de los lmites de un panel JDesktopPane. Los visores se colocan en una capa superior a la capa donde se representan grcamente los sensores del vehculo. En la clase SensorVisor se implementan las operaciones de Actualizar Manualmente, Iniciar/Detener Actualizacin Automtica y Establecer Tiempo de Actualizacin. SensorVisor utiliza el D.4 Patrn Observador, implementando la interfaz Observer como parte de la implementacin de esas operaciones para observar un objeto Updater. No obstante, la responsabilidad de implementar el mtodo update() recae en las clases hijas. De SensorVisor hereda una clase por cada dispositivo que se muestra en la interfaz: acelermetro, cmara, encoder, IR y sonar. Estas clases conguran el SensorVisor aadiendo paneles SensorPanel con el mtodo addPanel(). Un SensorPanel representa en la interfaz la medida de un sensor con un nombre para esa medida y una unidad. En la implementacin del mtodo update() se recogen los datos y se colocan en uno o ms SensorPanel. Un caso aparte constituye el visor de cmara, que no utiliza un SensorPanel si no otro contenedor para mostrar la imagen de la cmara. Para crear los visores de sensores fcilmente, se utiliza el D.2 Patrn Mtodo Fbrica en el mtodo getSensorVisor() de la clase VisorFactory, que toma un objeto DeviceInfo y devuelve el visor adecuado. 129

Captulo 3. Diseo del software

Figura 3.48: Clases de los visores de sensores

3.5.4.14.

Representacin grca de los sensores del vehculo

Para representar grcamente la disposicin de los sensores del vehculo se ha utilizado la librera JGraph, pensada para representar grafos y permitir al usuario manipularlos. Para ello se dispone un panel en el que pueden introducirse celdas (nodos de un grafo) y establecer relaciones entre ellos como, por ejemplo, unirlos con echas o establecer una herencia de padre e hijo. Este panel es la clase JGraph y se sita en la capa ms al fondo del panel JDesktopPane de la interfaz. Para representar la vista del vehculo, se introduce una celda padre que muestra la imagen en planta del vehculo. Como celdas hijas de esta, estarn representados todos los dispositivos de tipo SensorDevice. Estas celdas se han implementado en una clase DeviceCell, de forma que contienen un objeto DeviceInfo. As se puede obtener la localizacin del dispositivo en pantalla segn las constantes de DevicePosition y escoger la imagen que muestra la celda dependiendo del DeviceType. Cuando se hace clic en pantalla sobre una celda DeviceCell se abre un visor de sensor (operacin Abrir Sensor), utilizando la clase VisorFactory y el objeto DeviceInfo contenido en la celda. 130

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 3.49: Clases de la representacin grca de los sensores del vehculo

3.5.4.15. Interfaz de visualizacin de cmaras La interfaz de visualizacin de cmaras est representada en la clase CameraFrame. A la clase se le pasa una lista de cmaras con las que se crea un objeto CameraPanel en el mtodo addCamera(). Los CameraPanel se organizan en dos zonas distintas de la interfaz dentro del CameraFrame: uno para las cmaras que estn en la parte frontal del coche y otro para las que estn en la parte trasera. As se distingue claramente donde est cada cmara. La clase CameraPanel implementa las operaciones de manejo de las cmaras: Iniciar/Detener Streaming, Iniciar/Detener Captura, Ver Captura, Borrar Captura, Guardar Imagen, Guardar Vdeo y Establecer Tiempo Actualizacin. La clase PlayVideo es una clase de apoyo a las tareas de gestin de una captura para reproducirla en la interfaz. Para reproducir el vdeo utiliza un Timer que se congura con el tiempo de actualizacin del sensor, que ser el tiempo entre imgenes capturadas.

Figura 3.50: Clases de la interfaz de visualizacin de cmaras 131

Captulo 3. Diseo del software 3.5.4.16. Interfaz de captura de datos

La clase CaptureFrame implementa la interfaz de captura de datos. A la clase se le pasa una lista con los sensores disponibles, que en este caso la habr generado el comando CaptureDataCommand. Los datos capturados se representan en pantalla en una tabla de datos con un objeto JTable. Al ser la clase JTable parte de la interfaz Swing de Java, se requiere de la denicin de un modelo como parte de la implementacin Swing del D.3 Patrn Modelo-Vista-Controlador. El modelo est representado en la clase SensorTableModel que hereda de la clase AbstractTableModel, que ya implementa gran parte de los mtodos necesarios en el modelo, dejando nicamente la implementacin de tres mtodos abstractos al programador. El modelo contendr un nmero indeterminado de columnas representadas por objetos de la clase SensorDataRow, que incluirn el nombre del sensor, su identicador, la marca de tiempo guardada por SensorCapturer y los datos del sensor en cuestin. SensorTableModel utilizar el D.4 Patrn Observador para observar a los objetos SensorCapturer para generar los datos que precisa en objetos SensorDataRow. Los objetos SensorCapturer que observar, vendrn denidos por la seleccin de sensores hecha en SensorSelectDialog. En CaptureFrame se han implementado las operaciones de captura de datos: Iniciar/Detener Captura, Limpiar Captura, Guardar Captura, Seleccionar Sensor y Establecer Tiempo Actualizacin.

Figura 3.51: Clases de la interfaz de captura de datos 3.5.4.17. Interfaz de elaboracin de grcas

La clase ChartFrame implementa la interfaz de elaboracin de grcas. A la clase se le pasa una lista con los sensores disponibles, que la habr generado el comando MakeChartCommand. Las grcas se dibujan en pantalla mediante la librera JChart2D, para ello se utiliza un panel que representa un eje de coordenadas (clase Chart2D) y se dibujan sobre l las grcas con 132

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala objetos Trace2DSimple que implementan de forman sencilla la interfaz ITrace2D. Un objeto SensorChartInfo contiene un objeto SensorTracer y un objeto SensorCapturer. El objeto SensorTracer utiliza el D.4 Patrn Observador para observar al SensorCapturer y contiene un objeto ITrace2D. A medida que se notican nuevos datos al SensorTracer, se van aadiendo puntos al ITrace2D con la medida de tiempo guardada en SensorCapturer y el dato del sensor. Para seleccionar los sensores a capturar se despliega un SensorSelectDialog, en este caso con una lista de objetos SensorChartInfo. A la grca Chart2D, se le aaden los ITrace2D de los SensorTracer seleccionados. De esta forma cuando se aade un punto a un ITrace2D, se dibuja inmediatamente en la grca. En ChartFrame se han implementado las operaciones de hacer grca: Iniciar/Detener Grca, Limpiar Grca, Guardar Grca, Seleccionar Sensor y Establecer Tiempo Actualizacin.

Figura 3.52: Clases de la interfaz de elaboracin de grcas

3.5.4.18. Dilogo de seleccin de sensores A este dilogo se le pasa una lista de sensores que se utiliza como conjunto de seleccin, es decir, sensores que pueden ser seleccionados. La idea es utilizar el dilogo para interactuar con las dos listas, seleccionando uno o ms sensores. Cuando el usuario conrma la seleccin (botn Conrmar), se utilizan el mtodo de getSelectedObjects() para obtener la lista de los sensores seleccionados.

Figura 3.53: Clases del dilogo de seleccin de sensores 133

Captulo 3. Diseo del software 3.5.4.19. Comando Establecer Tiempo de Actualizacin / Dilogo de tiempo de actualizacin

Este comando se utiliza en diferentes partes de la interfaz para cambiar el tiempo de actualizacin de uno o ms sensores. Cuando se ejecuta el comando ShowTimeDialog, se muestra el dilogo de tiempo de actualizacin (TimeDialog). Si en el dilogo se cambia el tiempo en el cuadro de texto y se presiona el botn Conrmar, se ejecuta el comando SetTimeCommand. Este cambia el tiempo de actualizacin de la lista de objetos de la clase Updater que se le ha pasado.

Figura 3.54: Clases del comando/dilogo establecer tiempo de actualizacin

3.6. Diseo funcional

El diseo funcional consiste en describir utilizando diagramas de secuencia el intercambio de mensajes entre objetos para implementar un caso de uso. Los diagramas de secuencia muestran la interaccin entre un conjunto de objetos a travs del tiempo para un caso de uso. De esta forma se obtiene un diagramas con informacin sobre los objetos que implementan un caso de uso y los mensajes que intercambian.

3.6.1. Diseo funcional del servidor

El diseo funcional del servidor comprende las operaciones Congurar Servidor, Iniciar Servidor y Detener Servidor. Generalmente estas operaciones se ejecutan en ese mismo orden. 134

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.6.1.0.1. Congurar Servidor

Figura 3.55: Diagrama de secuencia de la operacin congurar servidor

3.6.1.0.2. Iniciar Servidor

Figura 3.56: Diagrama de secuencia de la operacin iniciar servidor

135

Captulo 3. Diseo del software 3.6.1.0.3. Detener Servidor

Figura 3.57: Diagrama de secuencia de la operacin detener servidor

3.6.2. Diseo funcional del cliente

El diseo funcional del servidor comprende un gran nmero de operaciones. En algunos de los diagramas que se presentan a continuacin, aparecen objetos que representan a un conjunto de objetos para que el diagrama sea ms genrico. Estos objetos son:

Invoker: representa a una clase que invoca un comando utilizando el D.1 Patrn Comando. De esta forma se indica que el origen de la ejecucin del comando puede estar en distintas partes del sistema, explicando simplemente que ocurre cuando se ejecuta el comando independientemente de qu lo haya ejecutado.

View: representa una vista, es decir, un componente que el usuario puede manipular en la interfaz para lograr algo. Si existen varios componentes diferentes que manipulan un mismo dato se representar de esta forma para indicar que varias vistas producen la misma secuencia de operaciones. 136

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.6.2.1. Operaciones de Establecer Conexin 3.6.2.1.1. Conectar a Servidor

Figura 3.58: Diagrama de secuencia de la operacin conectar a servidor

3.6.2.1.2. Desconectar de Servidor

Figura 3.59: Diagrama de secuencia de la operacin desconectar de servidor

137

Captulo 3. Diseo del software 3.6.2.2. 3.6.2.2.1. Operaciones de Establecer Idioma Seleccionar Lenguaje

Figura 3.60: Diagrama de secuencia de la operacin seleccionar lenguaje

3.6.2.3. 3.6.2.3.1.

Operaciones de Seleccionar Sensor Mostrar dilogo de seleccin de sensores

Figura 3.61: Diagrama de secuencia de la operacin mostrar dilogo de seleccin de sensores

138

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.6.2.3.2. Aadir Sensor

Figura 3.62: Diagrama de secuencia de la operacin aadir sensor

3.6.2.3.3. Quitar Sensor

Figura 3.63: Diagrama de secuencia de la operacin quitar sensor

139

Captulo 3. Diseo del software 3.6.2.3.4. Conrmar Seleccin

Figura 3.64: Diagrama de secuencia de la operacin conrmar seleccin

3.6.2.4. 3.6.2.4.1.

Operaciones de Establecer Tiempo Actualizacin Mostrar dilogo de establecer tiempo de actualizacin

Figura 3.65: Diagrama de secuencia de la operacin mostrar dilogo de establecer tiempo de actualizacin

3.6.2.4.2.

Introducir Tiempo

Esta operacin est implcita en la interfaz, al permitir introducir el tiempo en un cuadro de texto. 140

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.6.2.4.3. Establecer Tiempo por Defecto

Figura 3.66: Diagrama de secuencia de la operacin establecer tiempo por defecto

3.6.2.4.4. Conrmar Tiempo

Figura 3.67: Diagrama de secuencia de la operacin conrmar tiempo

3.6.2.5. Operaciones de Controlar Vehculo 3.6.2.5.1. Controlar Vehculo Esta operacin muestra la ventana de control de vehculo. 141

Captulo 3. Diseo del software

Figura 3.68: Diagrama de secuencia de la operacin controlar vehculo

3.6.2.5.2.

Establecer Velocidad

Figura 3.69: Diagrama de secuencia de la operacin establecer velocidad

142

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.6.2.5.3. Establecer Aceleracin

Figura 3.70: Diagrama de secuencia de la operacin establecer aceleracin

3.6.2.5.4. Establecer Posicin

Figura 3.71: Diagrama de secuencia de la operacin establecer posicin

143

Captulo 3. Diseo del software 3.6.2.5.5. Detener Vehculo

Figura 3.72: Diagrama de secuencia de la operacin detener vehculo

3.6.2.6. 3.6.2.6.1.

Operaciones de Consultar Sensor Abrir Sensor

Figura 3.73: Diagrama de secuencia de la operacin abrir sensor

144

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.6.2.6.2. Actualizar Manualmente

Figura 3.74: Diagrama de secuencia de la operacin actualizar manualmente

3.6.2.6.3. Iniciar Actualizacin Automtica

Figura 3.75: Diagrama de secuencia de la operacin iniciar actualizacin automtica

3.6.2.6.4. Detener Actualizacin Automtica

Figura 3.76: Diagrama de secuencia de la operacin detener actualizacin automtica

3.6.2.6.5. Establecer Tiempo Actualizacin El diagrama tiene su propio apartado. 145

Captulo 3. Diseo del software 3.6.2.7. 3.6.2.7.1. Operaciones de Observar Cmara Observar Cmara

Esta operacin muestra la ventana de visualizacin de cmaras (visor de cmaras).

Figura 3.77: Diagrama de secuencia de la operacin observar cmara

3.6.2.7.2.

Iniciar Streaming

Figura 3.78: Diagrama de secuencia de la operacin iniciar streaming

146

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.6.2.7.3. Detener Streaming

Figura 3.79: Diagrama de secuencia de la operacin detener streaming

3.6.2.7.4. Iniciar Captura

Figura 3.80: Diagrama de secuencia de la operacin iniciar captura

3.6.2.7.5. Detener Captura

Figura 3.81: Diagrama de secuencia de la operacin detener captura

147

Captulo 3. Diseo del software 3.6.2.7.6. Ver Captura

Figura 3.82: Diagrama de secuencia de la operacin ver captura

3.6.2.7.7.

Borrar Captura

Figura 3.83: Diagrama de secuencia de la operacin borrar captura

148

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.6.2.7.8. Guardar Imagen

Figura 3.84: Diagrama de secuencia de la operacin guardar imagen

3.6.2.7.9. Guardar Vdeo

Figura 3.85: Diagrama de secuencia de la operacin guardar vdeo

3.6.2.7.10. Establecer Tiempo Actualizacin Al dilogo se le pasa el Updater correspondiente a la cmara del panel donde se encuentra el botn que abre el dilogo. 149

Captulo 3. Diseo del software 3.6.2.8. 3.6.2.8.1. Operaciones de Capturar Datos Capturar Datos

Esta operacin muestra la ventana de captura de datos.

Figura 3.86: Diagrama de secuencia de la operacin capturar datos

3.6.2.8.2.

Iniciar Captura

Figura 3.87: Diagrama de secuencia de la operacin iniciar captura

150

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.6.2.8.3. Detener Captura

Figura 3.88: Diagrama de secuencia de la operacin detener captura

3.6.2.8.4. Limpiar Captura

Figura 3.89: Diagrama de secuencia de la operacin limpiar captura

151

Captulo 3. Diseo del software 3.6.2.8.5. Guardar Captura

Figura 3.90: Diagrama de secuencia de la operacin guardar captura

3.6.2.8.6.

Seleccionar Sensor

Al dilogo se le pasa un array de SensorCapturer con todos los sensores disponibles. Para ms detalles ver el diagrama general de Seleccionar Sensor.

3.6.2.8.7.

Establecer Tiempo Actualizacin

Al dilogo se le pasa un array de Updater correspondientes a los SensorCapturer seleccionados en el dilogo de seleccin de sensores. Para ms detalles ver el diagrama general de Establecer Tiempo Actualizacin. 3.6.2.9. 3.6.2.9.1. Operaciones de Hacer Grca Hacer Grca

Esta operacin muestra la ventana de elaboracin de grcas. 152

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 3.91: Diagrama de secuencia de la operacin hacer grca

3.6.2.9.2. Iniciar Grca

Figura 3.92: Diagrama de secuencia de la operacin iniciar grca

153

Captulo 3. Diseo del software 3.6.2.9.3. Detener Grca

Figura 3.93: Diagrama de secuencia de la operacin detener grca

3.6.2.9.4.

Limpiar Grca

Figura 3.94: Diagrama de secuencia de la operacin limpiar grca

154

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.6.2.9.5. Guardar Grca

Figura 3.95: Diagrama de secuencia de la operacin guardar grca

3.6.2.9.6. Seleccionar Sensor Al dilogo se le pasa un array de SensorCapturer con todos los sensores disponibles de Seleccionar Sensor.

3.6.2.9.7. Establecer Tiempo Actualizacin Al dilogo se le pasa un array de Updater correspondientes a los SensorCapturer seleccionados en el dilogo de seleccin de sensores. Para ms detalles ver el diagrama general de Establecer Tiempo Actualizacin.

3.7. Metodologa de desarrollo

Durante el proceso de desarrollo del software se ha optado por seguir una metodologa de desarrollo basada en un modelo incremental. Un incremento comprende a un conjunto de funcionalidades que debe tener el software y que se implementan de una vez. La metodologa se ha seguido de la siguiente forma: 1. Se ha realizado un anlisis de requisitos que a derivado en los requisitos de usuario y los requisitos del software. Como parte del anlisis se ha realizado un prototipo para renar el proceso. 2. Se ha realizado el diseo arquitectnico del software, deniendo los sistemas y subsistemas que se deben implementar. 3. Se ha procedido a disear e implementar los subsistemas en incrementos denidos. 155

Captulo 3. Diseo del software 4. Al terminar cada incremento se ha mostrado la funcionalidad implementada al usuario nal, recogiendo sus impresiones y realizando los cambios oportunos.

3.7.1. Denicin de incrementos

Se han denido los siguientes incrementos para desarrollar el software. Cada incremento se reere tanto a la parte correspondiente al servidor como a la del cliente: 1. Sistema bsico de comunicacin entre cliente y servidor. 2. Control remoto del vehculo. 3. Visualizacin remota de los sensores de Phidgets: acelermetro, sonares e infrarrojos. 4. Visualizacin remota del encoder basado en un ratn. 5. Visualizacin remota de las cmaras. 6. Captura de datos. 7. Elaboracin de grcas.

156

Captulo 4

Implementacin
En este captulo se detallan aspectos propios del proceso de implementacin del software.

4.1. Archivos del proyecto

Los archivos que se incluyen en esta seccin estn localizados en la carpeta JASEIMOV del disco que acompaa a esta memoria.

4.1.1. Proyectos software

Se indica en la siguiente lista los proyectos que se han generado en Netbeans junto con sus dependencias: Proyecto comm-lib: correspondiente a la librera del sistema de comunicacin cliente/servidor. Proyecto mouselib: correspondiente a una adaptacin reducida en Java de la librera que se desarroll para el captulo 2.3 Uso de un ratn mecnico como codicador ptico. Proyecto client: correspondiente a la aplicacin cliente. Depende de las libreras:

comm-lib.jar jchart2d-3.1.0.jar jgraph.jar

Proyecto server: correspondiente a la aplicacin servidor. Depende de las libreras:

comm-lib.jar mouselib.jar phidget21.jar v4l4j-0.8.7.jar

phidget21.jar corresponde a la librera phidgets Java lib versin 2.1. jchart2d-3.1.0.jar corresponde a la librera de JChart2D. jgraph.jar corresponde a la librera JGraph 5. v4l4j-0.8.7.jar corresponde a la librera v4l4j. Adems casi todos los iconos utilizados en la aplicacin se han tomado de una biblioteca denominada Silk icon set 1.3, realizada por Mark James1 .
1

http://www.famfamfam.com/lab/icons/silk/

157

Captulo 4. Implementacin

4.1.2. Otros archivos incluidos

En la carpeta en la que se distribuye la aplicacin se incluye adems: client.sh: un script bash para iniciar la aplicacin cliente. cong: el archivo de conguracin utilizado para congurar el servidor con todos los dispositivos incorporados al vehculo. javadoc.sh: un script bash para generar la documentacin Javadoc conjunta de los tres proyectos que forman JASEIMOV. La documentacin se genera y guarda en la carpeta JAVADOC. LICENSE.txt: con la licencia del cdigo fuente. server.sh: un script bash para iniciar la aplicacin servidor congurndola con el archivo cong. server-test.sh: un script bash para iniciar la aplicacin servidor congurndola en modo test.

4.2. Documentacin del cdigo fuente

El cdigo fuente se ha documentado utilizando Javadoc. Javadoc es una herramienta que permite generar documentacin de cdigo fuente de Java a partir de los comentarios del mismo. Los comentario deben seguir unas reglas de formato para que la herramienta pueda recoger la informacin necesaria y generar un conjunto de archivos html con la documentacin. Un ejemplo de la documentacin generada con Javadoc puede verse en la gura 4.1.

Figura 4.1: Ejemplo de documento Javadoc La herramienta extrae informacin de las clases y las agrupa por paquetes, de tal forma que es fcil localizar la informacin que se necesita en cada momento. Incluso en entornos de desarrollo como Netbeans, es posible enlazar los Javadoc con las libreras incluidas en un proyecto 158

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala de forma que se puede consultar rpidamente la documentacin asociada a una clase cuando se est usando en el editor. Los comentarios del cdigo fuente se han escrito en ingls, por tanto, la documentacin Javadoc generada se encuentra en dicho idioma tambin. Para generar la documentacin puede utilizarse el script bash javadoc.sh, que genera la documentacin de los tres proyectos en un nico Javadoc. Alternativamente puede generarse la documentacin individual de cada proyecto con la opcin Generar Javadoc abriendo el proyecto en Netbeans.

4.3. Manual de la aplicacin

Se ha realizado un pequeo manual de usuario de la aplicacin que incluye: Descripcin de las operaciones que se pueden realizar en la interfaz de usuario. Descripcin del modo de prueba del servidor. Descripcin del archivo de conguracin del servidor. Solucin de problemas conocidos. El manual se incluye en este documento como el apndice E Manual de usuario de JASEIMOV.

4.4. Publicacin y licencia del cdigo fuente

La aplicacin se publicar en la web del proyecto ASEIMOV2 , acompaando a las fotos y vdeos del vehculo. Se dispondr una versin compilada y otra del cdigo fuente y su documentacin Javadoc. El cdigo fuente se distribuye bajo licencia GPL versin 3 [4].

http://cicei.ulpgc.es/aseimov

159

Parte IV Conclusiones

161

Captulo 1

Pruebas de validacin
Se han realizado unas pruebas sencillas con objeto de probar la reusabilidad de la plataforma. Se ha optado por realizar una calibracin de dos sensores, medir la duracin de la batera y implementar un algoritmo sencillo para detener el vehculo cuando se topa con un obstculo de frente. Estas pruebas se han realizado en estrecha colaboracin con Moiss Daz Cabrera, con objeto de poder demostrar lo mejor posible las posibilidades de la plataforma.

1.1. Calibracin de dos sensores

En este apartado se procedi a realizar la calibracin de un sensor infrarrojo de corta distancia y un sonar, localizados en la parte delantera del vehculo. Para ello se capturaron con el software JASEIMOV, las medidas de separacin con respecto a una pared en un rango de 10 a 90 cm, en intervalos de 10 cm. En cada intervalo se toman aproximadamente unas 100 medidas con una frecuencia de muestreo de 50 ms. Para medir la separacin real con la pared se utiliz una cuadrcula impresa en papel de recuadros de 1 cm, con indicacin de las franjas de 10 cm. El escenario de la captura junto con la cuadrcula pueden observarse en la gura 1.1. Adems, se realiz la captura del acelermetro del vehculo ya que da un pulso cada vez que el coche se mueve y se detiene. Con los pulsos se pueden acotar las medidas de la captura en cada intervalo, es decir, cada vez que se mueve y se detiene el coche en una posicin de medida. En la gura 1.2 puede observarse la curva de calibracin del sensor infrarrojo, mientras que en la gura 1.3 puede verse la del sonar. Tras la captura se aplica un ltro y se ajustan las distancias medidas con respecto a las medidas reales en una curva denominada curva de calibracin. Con esta, dentro del rango medido, podemos obtener una medida del sensor y relacionarla con la medida real, con una bondad de ajuste determinada. Estos clculos fueron realizados por Moiss Daz Cabrera utilizando la aplicacin Mathlab.

1.2. Duracin de la batera

En esta prueba se ha comprobado cuanto aguanta la plataforma encendida a pleno rendimiento utilizando la batera como fuente de energa. En este contexto, a pleno rendimiento se entiende como el estado en el que se utilizan todos los sensores disponibles a la vez que se mueve el 163

Captulo 1. Pruebas de validacin

Figura 1.1: Escenario de la calibracin vehculo. Para hacer la prueba se ha cargado la batera del sistema completamente y se ha controlado el tiempo con un cronmetro desde que se ha encendido el sistema informtico hasta que se ha agotado la energa de la batera. El pleno rendimiento se ha conseguido desplegado en el software desarrollado la visualizacin simultnea de todos los sensores y cmaras del vehculo mientras se mova el coche por una habitacin. En las pruebas realizadas se ha obtenido una duracin aproximada de unos 50 minutos, que puede extenderse hasta 10 minutos ms si no se hace un uso constante del motor. Si recordamos la estimacin realizada en el apartado 2.2 Estimacin del consumo de energa del sistema podemos determinar que se acert, puesta que si el consumo est en torno a los 40W y la batera dispone de 40W/h, lgicamente durar aproximadamente una hora.

1.3. Detener automticamente el vehculo ante un obstculo

En esta prueba se ha implementado un algoritmo para detener el vehculo cuando se le presenta un obstculo de frente. Para ello se ha utilizado un sensor de la parte frontal del vehculo, donde disponemos de dos infrarrojos de corta distancia, un infrarrojo de larga distancia y un sonar. La disposicin de estos sensores puede verse en la gura 1.4. Se ha desarrollado una pequea aplicacin Java que controla el motor y obtiene los datos de estos sensores. El algoritmo utilizado es el siguiente:

avanzarMotor() mientras( distanciaSensor > umbral ) { avanzarMotor();

164

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura 1.2: Curva de calibracin del infrarrojo

} detenerMotor();
Para implementarlo se ha utilizado aprovechado el servidor de JASEIMOV y algunas clases del cliente de JASEIMOV que nos permiten de forma sencilla acceder a los dispositivos remotos en el servidor. El cdigo puede encontrarse en la clase AvoidCollision del proyecto testAseimov, incluido dentro de la carpeta JASEIMOV del disco que acompaa a esta memoria. Al algoritmo se le pasan los siguientes parmetros: IP del servidor. ID del sensor con el que se mide. Velocidad con la que avanza el motor. Umbral de distancia a la que debe detenerse el vehculo.

165

Captulo 1. Pruebas de validacin

Figura 1.3: Curva de calibracin del sonar

Figura 1.4: Sensores delanteros de ASEIMOV

166

Captulo 2

Conclusiones y trabajo futuro

2.1. Conclusiones
Impacto social. Utilidad del proyecto en el mbito social En este proyecto se ha tomado parte en el desarrollo de una plataforma de trabajo que proporciona una herramienta exible y de bajo coste, que permite realizar investigaciones que luego pueden trasladarse a coches elctricos reales. En esta plataforma se pueden probar tanto sistemas de ayuda a la conduccin humana como sistemas de conduccin automtica. Incluso, si se construyen ms vehculos se podran implementar algoritmos de control distribuido entre vehculos, en los que varios vehculos colaboraran entre s.

Calidad, dicultad y amplitud del trabajo desarrollado que justique el tiempo de dedicacin al proyecto En cuanto a mi trabajo en el proyecto creo que ha concluido satisfactoriamente. El sistema informtico diseado para el vehculo tiene prestaciones sucientes para las tareas necesarias, a la vez que se cumplen las restricciones de tamao y consumo energtico. Se ha comprobado que un ratn de bola puede utilizarse como un encoder de bajo coste y fcil acceso. La distribucin GNU/Linux escogida soporta adecuadamente todo el hardware, es estable y consume pocos recursos de memoria y espacio en disco. La aplicacin desarrollada para controlar y monitorizar de forma remota el vehculo cumple las expectativas de los usuarios. Adems, gracias al diseo que se ha hecho, se pueden incorporar fcilmente nuevos dispositivos al sistema y adaptarse frente a cambios en la disposicin de los sensores.

Aspectos integradores de las disciplinas de la titulacin de Ingeniero en Informtica Durante la realizacin de este proyecto he necesitado una gran cantidad de conocimientos adquiridos durante la carrera. En el diseo del sistema informtico he utilizado conocimientos de arquitectura de computadores, perifricos e interfaces, sistemas operativos y redes. En el desarrollo de la aplicacin he requerido de conocimientos de ingeniera del software, programacin concurrente, sistemas robticos mviles, instrumentacin y sistemas distribuidos. En cierta forma, puede decirse que he tomado los roles de administrador de sistemas, analista y arquitecto de software y programador. 167

Captulo 2. Conclusiones y trabajo futuro Conocimientos adquiridos Tambin hay que tener en cuenta los nuevos conocimientos y experiencias adquiridos. He diseado un sistema informtico de dimensiones reducidas, cumpliendo unos requisitos y elaborando un presupuesto. He aplicado tcnicas de ingeniera del software a un desarrollo software del mundo real. He tratado con tecnologas nuevas para m, como el hardware mini-ITX, Java RMI o el protocolo PS/2 de los ratones. Por ltimo, he adquirido una experiencia de trabajo en un proyecto real de ingeniera, teniendo reuniones, resolviendo problemas, presentando resultados, etc. En este sentido, hay que destacar el trabajo colaborativo con Moiss Daz Cabrera para llevar a buen puerto la construccin de toda la plataforma.

Facilidad de utilizacin de los resultados del proyecto por terceras personas. Publicidad de los resultados del proyecto a travs de pginas web Los siguientes proyectos analizarn mejor las posibilidades de la plataforma y realizarn los primeros experimentos serios sobre la misma. Adems, ya se ha solicitado nanciacin para montar un segundo vehculo. En el futuro se publicarn los progresos y trabajos realizados en la plataforma en la web de ASEIMOV en http://cicei.ulpgc.es/aseimov, donde adems se publicar el cdigo fuente desarrollado bajo licencia GPL.

2.2. Trabajo futuro

En este apartado se tratan los futuros proyectos o trabajos que podra realizarse para mejorar el presente proyecto. Mejorar el sistema informtico con nuevo hardware. Durante la realizacin del proyecto ya han salido nuevas placas y procesadores con mejor rendimiento y menor consumo energtico. Implementar el sistema de comunicacin de JASEIMOV utilizando sockets. La arquitectura de comunicacin de JASEIMOV se ha basado en Java RMI, pero el diseo realizado permitira implementar la comunicacin mediante sockets, mejorando el rendimiento. Implementar una interfaz para la prueba y ejecucin de algoritmos aprovechando la arquitectura de JASEIMOV. Implementar algoritmos que ya realizan vehculos reales, como por ejemplo la bsqueda y realizacin de aparcamiento, reconocimiento visual de seales, control de velocidad con respecto al vehculo de delante y de detrs, alerta de colisiones, etc. Implementar algoritmos de control distribuido entre vehculos. Cuando se tengan varios vehculos se podran organizar entre s para hacer tareas en comn. Por ejemplo, para que actuarn automticamente cedindose el paso en un cruce.

168

Parte V Apndices

169

Apndice A

Protocolo del ratn PS/2

Fuentes: basado fundamentalmente en [2] y [7]. El puerto PS/2 surgi con la serie de ordenadores IBM Personal System/2 en 1987, que se disearon para conectar un teclado y un ratn, en lugar de emplear un puerto AT DIN 5 para el teclado y un puerto de serie RS-232 para el ratn. Posteriormente los conectores fueron adaptados rpidamente en el mercado del PC. El conector es elctricamente equivalente al AT DIN 5, lo que supuso una fcil adaptacin de los teclados existentes a dicho formato con un simple adaptador. En la actualidad, poco a poco los fabricantes estn dejando de incluir estos conectores en las placas base en favor de los puertos USB, cuya principal ventaja frente a este puerto es permitir la conexin en caliente (hotplug) de los dispositivos y un conector mucho ms fcil de conectar y ms resistente.

A.1. Caractersticas generales

La interfaz PS/2 utiliza un protocolo en serie bidireccional. El ratn transmite los movimientos y el estado de los botones al controlador en el ordenador. El controlador puede enviar una serie de comandos al ratn para congurarlo. La interfaz proporciona al ratn 5V a 100mA como fuente de energa. El protocolo estndar soporta las entradas siguientes: movimiento en el eje X (izquierda y derecha), movimiento en el eje Y (arriba y abajo), botn izquierda, botn medio y botn derecho. El movimiento del ratn se almacena en dos contadores, uno para X y otro para Y. Al moverse el ratn, se incrementa o decrementa el contenido de estos contadores. Los contenidos de estos registros as como del estado de los botones se envan al controlador del ratn en un paquete de 3 bytes. Cada vez que se enva un paquete, se reinician los contadores a cero. Si los contadores se salen de rango (overow), se activa el bit correspondiente y no se permite seguir modicando el contador hasta que se provoque un reinicio del mismo. Es posible establecer en que cantidades se incrementan o decrementan los contadores de movimiento mediante un parmetro denominado resolucin. La resolucin por defecto es de 4 unidades/mm. Este valor puede cambiarse con el comando Set Resolution. Otro parmetro es el escalado, que no afecta a los contadores de movimiento, pero que si afecta al valor enviado al en el paquete al controlador. Por defecto se usa un escalado de 1:1 con no afecta a los valores. Pero si se utiliza un comando Set Scaling y se establece un escalado de 2:1, e ratn aplica el siguiente algoritmo sobre el valor de los contadores antes de enviarlos al controlador: 171

Captulo A. Protocolo del ratn PS/2

Tabla A.1: Escalado 2:1 Contador de movimiento 0 1 2 3 4 5 Movimiento reportado 0 1 1 3 6 9

N>5

2N

El escalado solo se aplica a los datos reportados en el modo Stream.

A.2. Paquete de datos

Tabla A.2: Paquete de datos de movimiento Bit 7 Y overow Bit 6 X overow Bit 5 Y sign bit Bit 4 Bit 3 X sign bit 1 Movimiento X Movimiento Y Bit 2 Medio Bit 1 Derecho Bit 0 Izquierdo

Byte 1 Byte 2 Byte 3

Los valores de movimientos son enteros en complemento a 2 de 9 bits, donde el bit ms signicativo o bit de signo corresponde a los bit 5 y 6 del byte 1: el X sign bit y el Y sign bit. Su valor representa el incremento de cada contador con respecto al ltimo paquete enviado, en unidades correspondientes a la resolucin actual. El rango de valores va desde -255 a +255. Si se sobrepasa este rango, el bit correspondiente de overow es activado: X overow o Y overow. Los bits Medio, Derecho e Izquierdo corresponde al estado del botn con ese nombre: pulsado (valor 1) o no pulsado (valor 0).

A.3. Modos
Segn el modo en el que funcione el ratn, ste reporta los datos al controlador de formas diferentes:

A.3.1. Reset
Es un modo de inicio en el que el ratn se prepara para funcionar y realiza un autodiagnstico. El ratn entra en este modo cuando se enciende o si se ejecuta el comando Reset. Tras entrar en este modo, el ratn efecta un autodiagnstico y se congura con los siguientes valores: Frecuencia de muestreo: 100 muestras/seg. 172

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala Resolucin: 4 unidades/mm. Escalado: 1:1. Reporte de datos: desactivado. Despus del autodiagnstico, el ratn enva 0xAA si el no hubo error, o si lo hubo, 0xFC. Entonces, enva su identicador de dispositivo 0x00, para distinguirlo de un teclado o un ratn no estndar. Tras esto, el ratn entra el el modo Stream.

A.3.2. Stream
Es este modo, el que el ratn enva por s mismo paquetes al controlador cuando se produce movimiento o cambia el estado de un botn. La frecuencia mxima con la que estos datos son reportados se congura con el parmetro frecuencia de muestreo, con un valor por defecto de 100. La frecuencia puede cambiarse con el comando Set Sample Rate a un rango entre 10 y 200 muestras/seg. Por defecto, el reporte de datos est desactivado. Si no se activa con un comando de Enable Data Reporting, el ratn no enviara ningn paquete de datos al controlador. Este modo es el que el ratn usa por defecto, pero tambin puede entrarse en l con el comando Set Stream Mode.

A.3.3. Remote
En este modo el ratn actualiza sus registros internos a la frecuencia de muestreo actual, pero no enva automticamente paquetes al controlador. En lugar de eso, se enva el comando Read Data y el ratn enva un paquete con los datos como respuesta y reinicia los registros. El ratn entra en este modo con el comando Set Remote Mode, aunque este modo es raramente usado.

A.3.4. Wrap
Este es un modo de diagnstico, raramente usado, en el cual el ratn reenva cada byte recibido de vuelta al controlador, incluso si el byte representa un comando vlido. Las nicas excepciones son el comando Reset y el comando Reset Wrap Mode.

A.4. Comandos
Los comandos que pueden enviarse al ratn tienen un formato de un byte en hexadecimal. Si el ratn se encuentra en el modo Stream, se debe desactivar el reporte de datos antes de enviar cualquier otro comando. A continuacin se describen los comandos: Reset (0xFF): el ratn responde a este comando con recibido (0xFA) y entra en modo Reset. Resend (0xFE): el controlador usa este comando cada vez que recibe datos no vlidos del ratn. El ratn acta reenviando el ltimo paquete. 173

Captulo A. Protocolo del ratn PS/2 Set Defaults (0xF6): al ratn responde a este comando con recibido (0xFA) y se congura con los siguientes valores: frecuencia de muestreo 100, resolucin 4 unidades/mm, escalado 1:1, reporte de datos desactivado, reinicio de los contadores de movimiento y entrada en modo Stream. Disable Data Reporting (0xF5): el ratn responde a este comando con recibido (0xFA), reiniciando los contadores de movimiento y desactivando el reporte de datos. Esto slo afecta al ratn en modo Stream. Enable Data Reporting (0xF4): el ratn responde a este comando con recibido (0xFA), reiniciando los contadores de movimiento y activando el reporte de datos. Esto slo afecta al ratn en modo Stream. Set Sample Rate (0xF3): el ratn responde a este comando con recibido (0xFA), entonces el controlador enva un byte de informacin con la nueva frecuencia de muestreo. Los valores vlidos son: 10, 20, 40, 60, 80, 100 y 200 muestras/seg. Tras recibir la nueva frecuencia,el ratn responde con recibido (0xFA) y reinicia los contadores de movimiento. Get Devide ID (0xF2): el ratn responde a este comando con recibido (0xFA) seguido de su identicador de dispositivo, 0x00 si es un ratn PS/2 estndar. Adems el ratn reinicia los contadores de movimiento. Set Remote Mode (0xF0): el ratn responde a este comando con recibido (0xFA), reinicia sus contadores de movimiento y entra en modo Remote. Set Wrap Mode (0xEE): el ratn responde a este comando con recibido (0xFA), reinicia sus contadores de movimiento y entra en modo Wrap. Reset Wrap Mode (0xEC): el ratn responde a este comando con recibido (0xFA), reinicia sus contadores de movimiento y entra de nuevo en el modo que estuviera antes de entrar en modo Wrap. Read Data (OxEB): el ratn responde a este comando con recibido (0xFA) y enva un paquete de datos de movimiento. A continuacin reinicia los contadores de movimiento. Esta es la nica forma de leer paquetes de movimiento en modo Remote. Set Stream Mode (0xEA): el ratn responde a este comando con recibido (0xFA), reinicia sus contadores de movimiento y entra en modo Stream. Status Request (0xE9): el ratn responde a este comando con recibido (0xFA) y enva un paquete de 3 bytes que indica el estado del mismo. A continuacin reinicia los contadores de movimiento. Tabla A.3: Paquete de estado Bit 7 0 Bit 6 Mode Bit 5 Enable Bit 4 Bit 3 Bit 2 Scaling 0 Izquierdo Resolution Sample Rate Bit 1 Medio Bit 0 Derecho

Byte 1 Byte 2 Byte 3

174

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Izquierdo, Medio y Derecho: tienen valor 1 si el botn correspondiente est presionado o 0 si no lo est.

Scaling: escalado del ratn. 1 escalado 2:1, 0 escalado 1:1. Enable: reporte de datos. 1 activado, 0 desactivado. Mode: modo de funcionamiento. 1 modo Remote, 0 modo Stream.
Set Resolution (0xE8): el ratn responde a este comando con recibido (0xFA), entonces el controlador enva un byte con la nueva resolucin del ratn. Los valores vlidos son 0 = 1 unidad/mm, 1 = 2 unidades/mm, 2 = 4 unidades/mm y 3 = 8 unidades/mm. El ratn responde con recibido (0xFA) y reinicia sus contadores de movimiento. Set Scaling 2:1 (0xE7): el ratn responde a este comando con recibido (0xFA) y activa un escalado 2:1. Set Scaling 1:1 (0xE6): el ratn responde a este comando con recibido (0xFA) y activa un escalado 1:1. Los nicos comandos que el ratn puede enviar al controlador son Resend 0xFE y Error 0xFC.

A.5. Microsoft Intellimouse

La extensin ms popular al protocolo estndar es la Microsoft Intellimouse. Esta extensin aade soporte para un total de 5 botones y tres ejes de movimiento, donde el eje adicional corresponde a la, ya habitual, rueda del ratn. Esto requiere que el paquete de movimiento se ample en un byte pasando a ser un paquete de 4 bytes. Para no provocar la incompatibilidad con los controladores estndar, un ratn que pueda usar esta extensin no la usa si el controlador no lo permite. Por defecto un ratn con esta extensin funciona como un ratn estndar. Para activar la rueda del ratn hay que ejecutar la secuencia de comandos siguiente: 1. Set sample rate 200. 2. Set sample rate 100. 3. Set sample rate 80. 4. Get device ID. Si el ratn no soporta la extensin, es decir, es un ratn estndar, responder con un identicador de dispositivo de 0x00, como se esperaba. Si el ratn soporta la extensin, responder con un identicador de dispositivo 0x03 y el controlador deber actuar a partir de ahora con el siguiente formato de paquete de movimiento de 4 bytes: 175

Captulo A. Protocolo del ratn PS/2

Tabla A.4: Paquete de movimiento de 4 bytes incluyendo la rueda Bit 7 Y overow Bit 6 X overow Bit 5 Y sign bit Bit 4 Bit 3 X sign bit 1 Movimiento X Movimiento Y Movimiento Z Bit 2 Medio Bit 1 Derecho Bit 0 Izquierdo

Byte 1 Byte 2 Byte 3 Byte 4

Una vez activada la rueda, para activar el cuarto y quinto botn, el controlador debe enviar la secuencia de comandos siguiente: 1. Set sample rate 200. 2. Set sample rate 200. 3. Set sample rate 80. 4. Get device ID. Al igual que antes si el ratn soporta la extensin, responder con un identicador de dispositivo de 0x04 y el controlador deber actuar a partir de ahora con el siguiente formato de paquete de movimiento de 4 bytes: Tabla A.5: Paquete de movimiento de 4 bytes incluyendo la rueda y el cuarto y quinto botn Bit 7 Y overow Bit 6 X overow Bit 5 Y sign bit Bit 4 Bit 3 X sign bit 1 Movimiento X Movimiento Y o 5 botn 6o botn Bit 2 Medio Bit 1 Derecho Bit 0 Izquierdo

Byte 1 Byte 2 Byte 3 Byte 4

Movimiento Z

Existen ratones con una rueda horizontal, adems de la vertical. La forma de implementarla es que cuando la ruda se mueve verticalmente, se incrementa o decrementa el contador Z en 1, mientras que, si se mueve horizontalmente, se incrementa o decrementa el contador Z en 2.

176

Apndice B

Diseo de conguraciones del sistema

A continuacin se incluyen las distintas conguraciones del sistema elaboradas con datos de varias tiendas online http://linitx.com, http://www.mini-box.com, http://www.ibertronica. es y http://www.mini-itx.com, incluyendo tambin al distribuidor local Odisea Informtica http://www.odiseainformatica.com. Se hicieron conguraciones de las plataformas Intel Atom, VIA C7 y VIA Nano. stas dos ltimas con nes comparativos, puesto que ya en la fase de anlisis se determin que la plataforma Intel Atom era la ms adecuada por su relacin potencia - precio - consumo energtico. Cada conguracin consta de los dispositivos siguientes:

Placa base: la base del sistema y que determina la eleccin de todo lo dems. RAM: siempre se escogen 2 GB de memoria a la mayor frecuencia permitida por la placa. Dispositivo Wi-Fi: si la placa dispone de puerto mini-PCI/miniPCIe se incluye una tarjeta de este tipo. Si no se opta por un modelo USB. Fuente de alimentacin: si la placa no tiene fuente de alimentacin propia, se incluye en su presupuesto una fuente especial para placas mini-ITX PicoPSU 90W 12V DC-DC. Transformador AC-DC: para poder conectar la placa a la corriente elctrica y no depender de la batera para trabajar con ella.

Como sern parte del sistema nal, independientemente del resto de elecciones, tanto los dispositivos de disco, como la batera del sistema tienen su propia seccin. Tambin se indica el consumo de las placas en idle en vatios W. Hay que indicar que los fabricantes no indican este parmetro y por ello el valor se ha extrado de la informacin proporcionada por el distribuidor Ibertrnica en su web (placas de VIA) y de webs serias que realizan tests o reviews de hardware (placas Intel) como Toms Hardware http://www.tomshardware. com. Los precios de las conguraciones son aproximados a partir de los datos de varias tiendas, ya que el objetivo de indicar el precio es estimar el coste de cada conguracin, no ser un reejo exacto del precio real. 177

Captulo B. Diseo de conguraciones del sistema

B.1. Conguraciones de plataforma Intel Atom

B.1.1. Placa Intel con procesador Atom n270
Componente Placa RAM Wi-Fi Fuente Transformador Referencia Intel BLKD945GSEJT Atom n270 SO-DIMM DDRII 2GB 667MHz Tarjeta Wi-Fi miniPCIe Incluida en placa Transformador AC-DC 12V Total Precio 85e 32e 55e 25e 197e

Ventajas: Bajo consumo energtico debido a la combinacin de procesador y chipset: unos 12W en idle. La placa incluye una fuente integrada. Tecnologa Hyper-Threading sobre un ncleo. Puerto miniPCIe para tarjeta Wi-Fi. Inconvenientes: Procesador poco potente. Pocos puertos USB: 7 Puerto PS/2 slo para teclado.

B.1.2. Placa Intel con procesador Atom 330

Componente Placa RAM Wi-Fi Fuente Transformador Referencia Intel D945GCLF2 Atom 330 DDR-2 2GB 667MHz Dispositivo Wi-Fi USB PicoPSU 90W 12V DC-DC Transformador AC-DC 12V Total Precio 82e 32e 20e 37e 25e 196e

Ventajas: Procesador potente con tecnologa Hyper-Threading en dos ncleos. Puerto PS/2 para ratn. 178

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 8 puertos USB. Inconvenientes: Consumo de energa elevado por el chipset: unos 33W en idle. Dispositivo Wi-Fi USB.

B.1.3. Placa ZOTAC con procesador Atom 330 y chipset ION ITX
Componente Placa RAM Wi-Fi Fuente Transformador Referencia ZOTAC ION ITX-A-E Atom 330 2 x DDR-2 1GB 800 MHz Incluida con la placa Incluida en placa Incluido con la placa Total Precio 156e 35e 191e

Ventajas: Procesador potente con tecnologa Hyper-Threading en dos ncleos. La placa incluye fuente de alimentacin, adaptador de corriente y tarjeta Wi-Fi mini-PCIe. Puertos USB: 10. Chipset ION ITX con menor consumo que el de la placa de Intel Atom 330. Interfaz de memoria de doble canal a mayor frecuencia que las placas de Intel Atom, 800 MHz. Inconvenientes: Consumo de energa elevado, aunque menor que la placa Intel: unos 25W en idle. Puerto PS/2 slo para teclado.

B.2. Conguraciones de plataforma VIA

B.2.1. Placa VIA con procesador VIA C7
Componente Placa RAM Wi-Fi Fuente Transformador Referencia VIA EPIA VB7002 C7-D 1,5GHz 2 x DDR-2 1Gb 667 MHz Tarjeta Wi-Fi miniPCI PicoPSU 90W 12V DC-DC Transformador AC-DC 12V Total Precio 156e 36e 55e 37e 25e 309e

179

Captulo B. Diseo de conguraciones del sistema Ventajas: Puerto miniPCI para tarjeta Wi-Fi. Interfaz de memoria de doble canal a 667 MHz. El consumo de energa, 15W en idle. Puerto PS/2 para ratn. Inconvenientes: Procesador menos potente, ausencia de tecnologas que benecien a entornos multihilo. Puertos USB: 8. Precio de la placa, comparado con las placas basadas en procesador Intel Atom.

B.2.2. Placa VIA con procesador VIA Nano

Componente Placa RAM Wi-Fi Fuente Transformador Referencia VIA EPIA VB8001 Nano 1,6GHz 2 x DDR-2 1Gb 667 MHz Tarjeta Wi-Fi miniPCI PicoPSU 90W 12V DC-DC Transformador AC-DC 12V Total Precio 130e 36e 55e 37e 25e 283e

Ventajas: Procesador ms potente y complejo que el Atom 330: superescalar, ejecucin fuera de orden, prediccin de saltos, ms cache, etc. Puerto miniPCI para tarjeta Wi-Fi. Interfaz de memoria de doble canal a 667 MHz. Puerto PS/2 para ratn. Inconvenientes: Ausencia de tecnologas que benecien a entornos multihilo. El consumo de energa, 18W en idle. Puertos USB: 8. Precio de la placa, comparado con las placas basadas en procesador Intel Atom. 180

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

B.3. Dispositivo de disco

En cuanto a dispositivos de disco, debido a la gran variedad, se solicit al distribuidor local presupuesto para un disco SSD de 2,5 con un precio aproximado de 100e. As mismo, se escogi un pendrive eSATA/USB de 8GB, OCZ Throttle. El presupuesto para estos componentes es el siguiente: Componente Disco SSD Pendrive eSATA/USB Referencia HD TAKEMS SSD 32GB OCZ 8 GB - eSATA - Throttle Precio 95e 36e

Como se puede observar, la diferencia en precios es importante al igual que la de rendimiento (ver 1.4 Dispositivos de disco). Adems el tamao del pendrive es mucho menor que el del disco SSD. Finalmente, se escoge el pendrive como mejor alternativa para el de sistema por la relacin entre precio, tamao y prestaciones.

B.4. Batera del sistema

En cuanto a emplear una batera universal para porttiles, una restriccin muy importante viene afectada por el espacio disponible en el coche. Por tanto buscamos una batera con unas dimensiones mximas de 150 mm x 85 mm x 11 mm con el objetivo de sustituir el hueco ocupado por la batera original del coche. Se encontr una nica batera que caba en el hueco, XPAL POWER XP8000. Dispone de una capacidad de 40Wh y tres salidas diferentes: 5V a 1A/ 12V a 3A/ 19V a 2A. Adems incluye una gran variedad de conectores tipo minijack para todo tipo de ordenadores porttiles, telfonos mviles, etc. El precio en el distribuidor local es de 109e. Si existen problemas de autonoma y/o necesidad de ms energa, la solucin pasa por reducir el consumo del sistema disminuyendo el nmero de dispositivos conectados a la vez, con una placa de menor consumo y/o no empleando esta batera para alimentar el motor del vehculo, sino utilizar la batera original del coche para esta tarea. Lgicamente, tambin podran usarse otras bateras ms grandes y con mejores caractersticas. Sin embargo, estas bateras no cabran en el espacio de la batera original del coche y presentaran un importante problema de espacio por sus dimensiones. A continuacin se incluye una lista de todas las bateras consultadas y sus caractersticas: Referencia i-Joy i-Power Portable External Laptop Battery - SP75 External Battery Pack - BP150 Batera universal MOBILIS XPAL POWER XP8000 XPAL POWER XP18000 Salidas (V) 5 16 19 5 16 19 5 16 19 5 16 19 5 16 19 5 16 19 I mx. (A) 3,2 3,4 4,75 3,1 2 3,5 Capacidad (Wh) 73 73 153 60 40 90 Tamao (mm) 193 x 88,5 x 27,5 187,5 x 87,5 x 25 270 x 145 x 32.5 175 x 85 x 25 109 x 73.66 x 23 180 x 73.66 x 23

181

Apndice C

Prueba de sockets frente a RMI

Para probar las dos tecnologas, se probar la diferencia de tiempo de respuesta de un servidor que implemente sockets a uno que implemente RMI como sistema de comunicacin. Se busca poder realizar desde el cliente una monitorizacin en tiempo real, o lo ms cercana posible, teniendo en cuenta que puede haber muchas peticiones debido a la gran variedad de dispositivos manejados por el servidor.

C.1. Diseo de la prueba

Para comparar el tiempo de respuesta de los sockets frente a RMI se realizaran unas pruebas que simularan la peticin continua de datos cada 100 ms de un par de cliente y servidor por cada dispositivo del vehculo. Cada servidor responder ante cada peticin del cliente una cadena de bytes determinada que representar los datos del mismo: 1 x Acelermetro: tres double (64 bits), 3 x 8 = 24 bytes. 17 x Infrarrojo, sonar y ratn encoder: un entero (32 bits) cada uno, 4 bytes. 4 x Cmaras: depende de la compresin JPEG y de la resolucin utilizada. Con la librera v4l4j, con una resolucin de 352 x 288 pxeles y una compresin JPEG del 90 %, las imgenes se transforman en cadenas de aproximadamente 15000 bytes cada una. Para probar un entorno concurrente de peticiones, se desarrollaron dos clases, una cliente y una servidor, tanto para la comunicacin bajo sockets como bajo RMI. En ambas nos abstraemos totalmente del proceso de establecimiento de la conexin, centrndonos nicamente en el de comunicacin, y midiendo el tiempo entre la peticin de un dato y la obtencin de respuesta. En el caso de sockets, el cliente enva un mensaje de peticin al servidor cada 100 ms consistente en la cadena siguiente:

GET\r\n
El servidor responde con un mensaje consistente en la cadena:

RESP BYTES\r\n
183

Captulo C. Prueba de sockets frente a RMI Donde BYTES es una cadena bytes, cuya longitud es el nmero de bytes que debe responder el servidor. Esto dene un pequeo protocolo de comunicacin, similar al que sera necesario en el caso de que se implementar el servidor con este sistema. Se mide el tiempo que pasa desde que se enva la cadena con la peticin al servidor hasta que se lee completamente la cadena de respuesta. En el caso de RMI, el cliente invoca al mtodo remoto byte[] enviarPeticion() cada 100 ms que devuelve una cadena de bytes con los datos. Se mide el tiempo que se tarda en ejecutar ese mtodo remoto. Para realizar la prueba, se ejecutaron los servidores en un ordenador porttil con conexin Wi-Fi, jndonos que tuviera una seal alta y estable con la red inalmbrica. Los clientes se ejecutaron en otro ordenador conectado a la misma red mediante un cable. Se lanzaron los hilos clientes y servidores siguientes: 1 hilo de 24 bytes, 16 hilos de 4 bytes y 4 hilos de 15000 bytes. Se ejecutaron 3 pruebas por cada tecnologa durante 30 segundos cada una, almacenando los tiempos de respuesta de cada peticin. Con los tiempos, se realiz una pequea estadstica donde se calcul la media de los mismos.

C.2. Resultados
En la tabla C.1 y en la gura C.1 pueden verse la media de los tiempo de respuesta de los distintos tipos de peticiones de la prueba. De estos datos puede extraerse que una implementacin en sockets resultara ms rpida que una bajo RMI, aunque las diferencias se recortan de forma notable en el caso del envo de grandes cantidades de datos (15000 bytes), habiendo slo 2 milisegundos de diferencia entre ambas. Las diferencias podran ser an ms pequeas si tenemos en cuenta que una implementacin que utilizara sockets requerira del diseo de un protocolo de comunicacin que requerir un tratamiento de la informacin, tanto por parte del servidor como por parte del cliente. Tabla C.1: Tiempo de respuesta medio en ms 4 bytes 24 bytes 15000 bytes RMI 10,23 10,11 11,34 SOCKETS 3,79 3,83 9,03

Este resultado es de esperar, puesto que los sockets trabajan a ms bajo nivel que RMI. No obstante, el desarrollo bajo RMI permite al programador abstraerse de protocolos de comunicacin, permitiendo un desarrollo ms controlado de aplicaciones distribuidas. En el caso que nos ocupa, hablamos de una diferencia media de aproximadamente 6 milisegundos para obtener una respuesta del servidor entre una u otra tecnologa. Y en el caso de la transmisin de 15000 bytes, la diferencia sera de 2 milisegundos. El tiempo de respuesta de los sensores, expresado como el tiempo que tarda en producirse un cambio en la magnitud que estn midiendo, en algunos casos ni siquiera es tan alto. Por otra parte, con el peor tiempo de respuesta bajo RMI, en torno a los 10 milisegundos, seramos capaces de enviar una peticin para cambiar el rumbo del vehculo o detenerlo bastante rpido. 184

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura C.1: Tiempo de respuesta medio en ms En conclusin, la implementacin en sockets es ms rpida, pero RMI no es tan lento como para no desestimar su uso gracias a sus ventajas.

185

Apndice D

Patrones de diseo
En este apndice se incluyen los patrones de diseo utilizados en el diseo de la aplicacin. En algunos casos, el lenguaje Java provee de clases e interfaces que implementan estos patrones.

D.1. Patrn Comando

Es un patrn que sirve para ejecutar una operacin sin conocer lo que hace dicha operacin. La idea es denir el mtodo abstracto execute() en una clase o una interfaz a la que se le denomina Command. Cada operacin se representa en una clase que hereda de Command, implementando el mtodo execute(). Con este patrn se consigue independizar la parte de la aplicacin que invoca las rdenes de la implementacin de esas rdenes, mejorando el diseo del software. Normalmente se asocia un comando a componentes de la interfaz de usuario como botones o opciones de men. En Java la librera Swing stos dos componentes disponen de las operaciones getActionCommand() y setActionCommand(), para obtener o asignar una ristra que identica al comando.

Figura D.1: Patrn comando

La implementacin del patrn se basa en una clase abstracta Command, a la que se le asigna un nombre de comando en su constructor que puede obtenerse con el mtodo getName(). Adems dene el mtodo abstracto execute(). Cuando se implementa una operacin se crea una clase que hereda de la clase Command, haciendo necesario implementar lo siguiente: 187

Captulo D. Patrones de diseo En el constructor de la nueva clase se debe llamar al constructor de Command para especicar el nombre del comando. Hay que implementar la operacin execute().

D.2. Patrn Mtodo Fbrica

Es un patrn que sirve para poder crear diferentes objetos de una misma familia, utilizando un nico mtodo denominado mtodo fbrica, en ingls factory. Para explicar este patrn es mejor utilizar un ejemplo concreto. Por ejemplo, el caso de la creacin de un botn en una operacin multiplataforma. Se dispone de una aplicacin multiplataforma, Windows y Linux, en la que se utilizan como elementos de la interfaz botones. Cuando se quiere crear un botn esto depende directamente de la plataforma en la que nos encontramos. Por tanto se crea una clase base Botn y dos subclases, BotnWindows y BotnLinux. Para evitar mltiples comprobaciones en el cdigo del tipo si la plataforma es Windows crear BotnWindows o si la plataforma es Linux crear BotnLinux, se utiliza un mtodo fbrica. En este caso el mtodo podra llamarse getBotn() y comprobara que plataforma se esta usando, creando un objeto de la subclase correcta y devolviendo un objeto Botn. As la aplicacin puede abstraerse utilizando el botn a partir de la clase padre y crendolo con el mtodo fbrica.

Figura D.2: Patrn mtodo fbrica

D.3. Patrn Modelo-Vista-Controlador

Es un patrn que sirve para separar el manejo de los datos (modelo), de la lgica de control (controlador) y de la interfaz de usuario (vista). 188

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala El modelo representa a los datos con los que opera el sistema. El modelo se ocupa de obtener los datos y, en muchos casos, noticar si hay cambios en ellos utilizando el D.4 Patrn Observador. La vista representa al modelo en la interfaz de usuario utilizando los datos que le provee. El controlador responde ante eventos, normalmente acciones del usuario, que pueden modicar el modelo y/o la vista.

Figura D.3: Patrn modelo-vista-controlador El funcionamiento del patrn es el siguiente: 1. El usuario interacta con la interfaz de usuario (Vista). 2. El Controlador recibe por parte de la Vista una noticacin con la accin del usuario. Entonces el Controlador accede al Modelo, manipulando los datos del alguna forma. 3. Se actualiza la Vista. Esto puede deberse a una accin directa del Controlador o porque la Vista est observando al Modelo mediante el patrn observador.

D.4. Patrn Observador

Es un patrn que sirve para que un objeto pueda noticar cambios en su estado a uno o ms objetos. En Java este patrn se implementa directamente a travs de la interfaz java.util.Observer, que dene el mtodo abstracto update() y la clase java.util.Observable, que provee los mtodos para que clases que implementen la interfaz Observer puedan observarla. As, una clase que necesita ser observada heredar de la clase Observable. El funcionamiento es el siguiente: 1. Un Observer notica la intencin de observar a una clase Observable utilizando el mtodo addObserver(). El Observer se aade a una lista. 189

Captulo D. Patrones de diseo 2. Cuando la clase Observable quiere noticar de un cambio en su estado, utiliza el mtodo notifyObservers(). Este mtodo recorre la lista de Observer y llama a sus mtodos update() pasndoles el objeto Observable y un dato opcional. 3. Si un Observer quiere dejar de observar a un Observable utiliza el mtodo deleteObserver().

Figura D.4: Patrn observador

D.5. Patrn ThreadPool

Es un patrn de diseo de aplicaciones concurrentes y comunicaciones. La idea es tener un conjunto o pool de hilos que pueden realizar tareas. Las tareas se organizan en una cola a la que el programador aade las tareas que quiere ejecutar. Cuando un hilo del pool est libre ejecuta una tarea de la cola extrayndola. Cuando termina la tarea si hay otra hace lo mismo, y as sucesivamente. Generalmente hay ms tareas que hilos en el pool, congurndose el nmero de hilos al crear el ThreadPool. En Java existen varias formas de implementar este tipo de patrn. La ms general y completa consiste en utilizar la clase ScheduledThreadPoolExecutor del paquete java.util.concurrent. Al constructor se le pasa el nmero de hilos que se quiere que tenga el pool. Luego se utilizan los mtodos siguientes para ejecutar tareas en el pool:

schedule(): ejecuta la tarea una sola vez. Se le pasa la tarea ejecutar y un tiempo opcional de espera antes de ejecutar la tarea. scheduleAtFixedRate(): ejecuta la tarea peridicamente hasta que se detiene. Se le pasa la tarea ejecutar, un tiempo opcional de espera antes de ejecutar la tarea y el perodo de ejecucin.

La tarea a ejecutar viene denida por la interfaz Runnable, que obliga a implementar el mtodo run(). 190

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura D.5: Patrn ThreadPool

191

Apndice E

Manual de usuario de JASEIMOV

E.1. Introduccin

Figura E.1: Logo de ASEIMOV

ASEIMOV (Autonomous Scaled Electric Intelligent MOnitorized Vehicle) es un coche radiocontrol de escala 1:10 al que se ha incorporado un ordenador para dotarlo de inteligencia gestionando dispositivos como infrarrojos, sonares, cmaras, acelermetros, motores... JASEIMOV (Java ASEIMOV) es un software que permite acceder a esos dispositivos de forma remota para visualizar su estado, capturar sus datos, elaborar grcas o, por ejemplo, controlar el vehculo. El software se basa en una arquitectura cliente - servidor, en la que el servidor se localiza en el ordenador del vehculo, permitiendo a varios clientes conectarse a l para realizar las tareas que se han mencionado en una interfaz amigable.

E.2. Manejo de la interfaz de usuario

Se aconseja que para manejar la interfaz de usuario se utilice una pantalla con una resolucin de 1200 pxeles de ancho y 900 pxeles de alto, para poder visualizar siempre, sin desplazarse, todas las interfaces.

E.2.1. Ventana principal

Cuando se abre la aplicacin se muestra la ventana principal de la misma: 193

Captulo E. Manual de usuario de JASEIMOV

Figura E.2: Ventana principal del cliente

En la parte superior de la ventana se dispone de una serie de botones que permiten realizar las operaciones principales de la aplicacin: conectar o desconectar de un servidor, cerrar la aplicacin, controlar el vehculo, observar las cmaras, capturar datos, elaborar grcas, cambiar el lenguaje de la aplicacin y cambiar el tiempo de actualizacin global. El resto del rea la ocupa una representacin grca de una vista del vehculo en planta. Si se mantiene pulsado el botn izquierdo del ratn sobre el recuadro de la vista, se puede mover libremente por el rea. Cuando se establece una conexin con un servidor, se muestra en la vista del vehculo los sensores segn donde estn colocados. 194

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

Figura E.3: Ventana principal del cliente: detalle de disposicin de sensores en el vehculo Si se hace clic en uno de los sensores se abre una pequea ventana que permite visualizar las medidas del sensor, que se llama visor de sensor. E.2.1.1. Visor de sensor

Para cada tipo de sensor existe un visor de sensor asociado al mismo que muestra los datos que recoge. Cada uno de estos visores tiene en la parte superior tres botones que hacen lo siguiente (de izquierda a derecha): Botn Actualizar ahora: actualiza inmediatamente el visor con las medidas actuales del sensor. Botn Actualizar automticamente: actualiza peridicamente el visor con un periodo igual al tiempo de actualizacin del mismo. Si se pulsa otra vez detiene este proceso. Botn Establecer tiempo de actualizacin: permite cambiar el tiempo de actualizacin del sensor asociado al visor. A continuacin se muestran los distintos visores de sensores que existen en la aplicacin:

Figura E.4: Visor acelermetro 195

Captulo E. Manual de usuario de JASEIMOV

Figura E.5: Visor cmara

Figura E.6: Visor encoder

Figura E.7: Visor infarrrojo

Figura E.8: Visor sonar E.2.1.2. Conexin al servidor

Para conectar con un servidor se hace clic en el botn Conectar de la ventana principal, que muestra la siguiente ventana:

Figura E.9: Dilogo de conexin 196

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala En el dilogo se debe introducir la IP donde se encuentra el servidor y, si es necesario, un puerto diferente al puerto por defecto (1099). Entonces se hace clic en el botn Conectar para conectar con el servidor. Si hay algn error se mostrar el usuario una pequea ventana con informacin del error. E.2.1.3. Desconexin del servidor

Cuando la aplicacin se ha conectado a un servidor, se puede terminar la conexin haciendo clic en el botn Desconectar de la ventana principal, que muestra el siguiente mensaje de aviso para evitar posibles prdidas de datos:

Figura E.10: Dilogo de desconexin Si se hace clic en desconectar, se cierran todas las ventanas secundarias de la aplicacin y se reinicia la ventana principal al estado inicial. E.2.1.4. Cierre de la aplicacin

Cuando se cierra la aplicacin, si no se est conectado a un servidor se muestra el siguiente aviso para conrmar el cierre:

Figura E.11: Dilogo de cierre As si el usuario tiene abiertas otras ventanas con datos importantes y accidentalmente intenta cerrar la aplicacin, la aplicacin avisa de la posible prdida de datos. E.2.1.5. Cambiar el lenguaje

Para cambiar el lenguaje de la aplicacin, se debe hacer clic en el botn Seleccionar Lenguaje de la ventana principal, que muestra la ventana siguiente:

Figura E.12: Dilogo de cambio de lenguaje 197

Captulo E. Manual de usuario de JASEIMOV Si el usuario hace clic en cualquiera de los dos lenguajes, la aplicacin se reinicia cambiando el lenguaje. De esta forma los textos de toda la aplicacin cambian al lenguaje escogido. Este proceso produce que se cierren todas las ventanas abiertas de la aplicacin. E.2.1.6. Cambiar el tiempo de actualizacin global

Se puede cambiar el tiempo de actualizacin de todos los sensores disponibles haciendo clic en el botn Establecer tiempo act. de la ventana principal. Para ms detalles consultar E.2.7 Cambiar el tiempo de actualizacin de uno o ms sensores

E.2.2. Ventana de control del vehculo

Si se hace clic en el botn Controlar vehculo de la ventana principal, se abre la ventana siguientes, que nos permite controlar el motor y el servomotor del vehculo:

Figura E.13: Ventana de control del vehculo En el rea de la izquierda de la ventana, pueden verse barras deslizantes y cuadros de texto que indican la aceleracin y velocidad actual del motor del vehculo, as como la posicin del servomotor del mismo. Al controlar el motor podemos mover el vehculo hacia adelante (velocidad entre 1 y 100), hacia atrs (velocidad entre -1 y -100) o detenerlo (velocidad 0). Controlando el servomotor podemos girar las ruedas delanteras del vehculo para cambiar la direccin en la que se mueve. En el rea de la derecha se visualiza un eje de coordenadas con un botn rojo. El eje horizontal representa la posicin del servomotor, mientras que el vertical representa la velocidad del motor. Cuando el botn rojo se haya en el centro del eje corresponde a una situacin de reposo donde la velocidad es 0 y la posicin del servomotor es aquella en la que el coche va en lnea recta. El botn rojo puede moverse manteniendo pulsado el botn izquierdo del ratn en el rea blanca del eje y movindolo. Esto produce los cambios esperados en la velocidad y direccin de movimiento del vehculo. Si se presiona el botn derecho, se devuelve el botn rojo al centro de los dos ejes, deteniendo el vehculo. 198

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala Cuando se pulsa el botn con el icono STOP, detiene el motor del vehculo.

E.2.3. Ventana de visualizacin de cmaras

Si se hace clic en el botn Ver cmaras de la ventana principal, se abre esta ventana, que permite ver las cmaras que se encuentre en el servidor al que estemos conectados:

Figura E.14: Ventana de visualizacin de cmaras

Se disponen de dos las de cmaras. La superior muestra las cmaras que se encuentran en la parte frontal del vehculo. La inferior muestra las cmaras que se encuentran en la parte trasera del vehculo. A su vez la que est ms a la izquierda corresponder a la que est en la izquierda de esa parte (frontal o trasera), y la que est ms a la derecha a la que est a la derecha de esa parte. En la parte superior se puede ltrar que cmaras se ven con tres botones, para mostrar slo las cmaras del frontal, slo las traseras o todas. Cada cmara dispone de un panel de control con la forma siguiente: 199

Captulo E. Manual de usuario de JASEIMOV

Figura E.15: Panel de control de cmara En la parte superior del panel se muestra informacin relevante a la cmara como la resolucin utilizada en pxeles (pix) y los frames por segundo actuales. En la parte inferior del panel nos encontramos con los botones siguientes (de izquierda a derecha): Botn Ver: permite que se muestre en pantalla lo que ve la cmara. El proceso de obtencin de la imagen se hace peridicamente, donde el perido es el del tiempo de actualizacin de la cmara. Si se pulsa otra vez se detiene el proceso. Botn Capturar vdeo: si no se est viendo la cmara, se inicia el proceso y adems cada imagen que llega se guarda para formar un vdeo. Cuando se pulsa de nuevo el botn, se termina la grabacin y se muestra el primer frame de la misma. Botn Reproducir vdeo capturado: reproduce el vdeo capturado. Si se pulsa otra vez antes de que termine la reproduccin, se pausa la misma. Botn Borrar vdeo capturado: elimina el vdeo capturado. Botn Guardar imagen actual: abre un dilogo para guardar en un archivo de disco la imagen que se muestra en ese momento en el panel. Para ms detalles consultar E.2.6 Guardar un archivo. Botn Guardar vdeo capturado: abre un dilogo que permite seleccionar una carpeta para guardar todas las imgenes que forman un vdeo. Para transformar las imgenes en un vdeo, ver el apartado E.4 Convertir un conjunto de imgenes en un vdeo. Para ms detalles consultar E.2.6 Guardar un archivo. Inmediatamente encima de los botones anteriores nos encontramos con unos controles que nos permiten recorrer el vdeo capturado, si hay uno. El botn Ir al primer frame, mueve la posicin del vdeo al primer frame. El botn ir al ltimo frame, mueve la posicin del vdeo al ltimo frame. En medio se muestra una barra deslizante que permite seleccionar un frame del vdeo movindola de izquierda a derecha. Al lado de todos estos, se indica el frame actual y el nmero total de frames del vdeo. 200

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

E.2.4. Ventana de captura de datos

Cuando se pulsa el botn Capturar datos de la ventana principal, se muestra esta nueva ventana que permite capturar los datos de varios sensores y guardarlos en un chero csv.

Figura E.16: Ventana de captura de datos

En la parte inferior de la ventana hay una tabla donde se mostrarn los datos capturados por los sensores. Las columnas de dicha tabla son: Nombre, ID, Tiempo y Dato. Correspondiendo respectivamente a: el nombre del sensor, el identicador nico del sensor, los milisegundos transcurridos desde que se inicio la captura y la medida obtenida del sensor. En la parte superior de la ventana nos encontramos con los siguientes botones (de izquierda a derecha): Botn Seleccione los sensores a capturar: permite seleccionar que sensores se van a capturar. Para ms detalles consultar E.2.8 Seleccin de sensores. Botn Establecer tiempo act.: permite seleccionar el tiempo de actualizacin de los sensores seleccionados con la anterior funcin. Para ms detalles consultar E.2.7 Cambiar el tiempo de actualizacin de uno o ms sensores. Botn Iniciar/Detener Captura: cuando se pulsa inicia la captura de los datos de los sensores. Los datos se capturan por sensor peridicamente, con un periodo igual al tiempo de actualizacin de cada sensor. Cuando se pulsa de nuevo el botn se detiene el proceso de captura. Botn Limpiar captura: al hacer clic se borra la captura de datos actual. Si el proceso de captura se ha iniciado, se seguirn aadiendo datos a la tabla. Guardar captura: abre un dilogo que permite guardar los datos capturados en un archivo de valores separados por comas, csv. El archivo puede ser fcilmente tratado en programas de hoja de clculo como Microsoft Excel o OpenOfce, o por ejemplo, en Mathlab. Para ms detalles consultar E.2.6 Guardar un archivo. 201

Captulo E. Manual de usuario de JASEIMOV

E.2.5. Ventana de elaboracin de grcas

Cuando se pulsa el botn Crear grcas de la ventana principal, se muestra la interfaz que permite elaborar grcas temporales con los datos de varios sensores.

Figura E.17: Ventana de elaboracin de grcas En el rea blanca de la ventana se presenta un eje de coordenadas donde el eje horizontal corresponde al tiempo en milisegundos, y el vertical a la medida de los sensores. A medida que se van capturando datos de los sensores, se van dibujando puntos donde la X corresponde al tiempo de la captura y la Y a la medida obtenida. Cada punto se uno con el anterior formando una lnea temporal que indica las medidas del sensor. En la parte superior de la ventana nos encontramos con los siguientes botones (de izquierda a derecha): Botn Seleccione los sensores a capturar: permite seleccionar que sensores se van a capturar. Para ms detalles consultar E.2.8 Seleccin de sensores. Botn Establecer tiempo act.: permite seleccionar el tiempo de actualizacin de los sensores seleccionados con la anterior funcin. Para ms detalles consultar E.2.7 Cambiar el tiempo de actualizacin de uno o ms sensores. Botn Iniciar/Detener Captura: cuando se pulsa inicia la captura de los datos de los sensores. Los datos se capturan por sensor peridicamente, con un periodo igual al tiempo de actualizacin de cada sensor. Cuando se pulsa de nuevo el botn se detiene el proceso de captura. Botn Limpiar: al hacer clic se borran las grcas actuales. Si el proceso de captura se ha iniciado, se seguirn dibujando dichas grcas. Guardar imagen actual: abre un dilogo que permite guardar la grca actual como un archivo de imagen en formato png. Para ms detalles consultar E.2.6 Guardar un archivo. En la parte inferior de la ventana aparece el nombre de las trazas con el color con el que se dibujan sus medidas en la grca. Si se hace clic derecho sobre el nombre se pueden cambiar 202

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala varios aspectos de la traza como el color, hacerla o no visible o cambiar el tipo de lnea que dibuja.

E.2.6. Guardar un archivo

Este dilogo permite guardar un archivo en el disco con algunos datos. Se utiliza en varias partes de la aplicacin para guardar imgenes y archivos csv.

Figura E.18: Dilogo para guardar archivos La ventana permite navegar por el rbol de directorios del ordenador. Para guardar un archivo se introduce el nombre de archivo en el cuadro Filename y se presiona el botn Save. Existe un dilogo un poco diferente que permite seleccionar un directorio para guardar un conjunto de imgenes. En ese caso el nombre del directorio se introduce en Filename o se selecciona la carpeta en el rbol de directorios. Entonces se presiona el botn Save para guardar las imgenes en ese directorio.

E.2.7. Cambiar el tiempo de actualizacin de uno o ms sensores

Este dilogo permite cambiar el tiempo de actualizacin de uno o ms sensores, y se muestra en diferentes contextos dentro de la aplicacin. Dependiendo de esto, puede cambiar el tiempo a uno o a varios sensores.

Figura E.19: Dilogo de cambio de tiempo de actualizacin El tiempo de actualizacin actual se muestra en el recuadro de texto. Cuando se quieren cambiar el tiempo de actualizacin a ms de un sensor se muestra la media de los tiempos de actualizacin de esos sensores. Se puede volver al tiempo de actualizacin por defecto haciendo clic en el botn Por defecto. 203

Captulo E. Manual de usuario de JASEIMOV Si se presiona el botn Conrmar, se realiza el cambio en el tiempo de actualizacin y se cierra el dilogo. El cambio del tiempo de actualizacin afecta a toda la interfaz. Esto supone que, por ejemplo, si se est capturando un sonar con un tiempo de actualizacin de 1000 ms en la ventana de captura de datos, si abrimos el mismo sonar en la ventana principal y cambiamos ah el tiempo de actualizacin cambiaremos tambin el de la captura.

E.2.8. Seleccin de sensores

Este dilogo permite seleccionar sensores para capturar o realizar grcas con ellos.

Figura E.20: Dilogo de seleccin de sensores

En la lista de la zona izquierda se muestran los sensores disponibles. En la lista de la derecha los sensores seleccionados. Para seleccionar un sensor, se hace clic en su nombre en la lista de sensores disponibles y luego se pulsa el botn Aadir. El sensor desaparece de la lista de la sensores disponibles y se aade a la lista de sensores seleccionados. Para deseleccionar un sensor, se hace clic en su nombre en la lista de sensores seleccionados y luego se pulsa el botn Quitar. El sensor desaparece de la lista de seleccionados y aparece de nuevo en la de sensores disponibles. Para deseleccionar todos los sensores, se hace clic en el botn Limpiar. Esto quita todos los sensores de la lista de seleccionados. La seleccin se termina pulsando el botn Conrmar, que cierra el dilogo.

E.3. Limitaciones conocidas

E.3.1. Ventana de control del vehculo
La ventana de control del vehculo no permite seleccionar el motor y el servomotor a controlar. Por ello, si existe ms de un motor y servomotor en un servidor, se utilizar el primer motor y el primer servomotor por orden de aparicin en la lista de servicios del servidor. 204

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

E.3.2. Resolucin de las cmaras

Aunque las cmaras soportan resoluciones mayores, no es posible establecer desde el cliente la resolucin que se quiere. Para cambiar la resolucin de una cmara, se debe cambiar el ancho y alto en pxeles de la misma en el archivo de conguracin del servidor y reiniciarlo.

E.4. Convertir un conjunto de imgenes en un vdeo

En la ventana de visualizacin de cmaras se pueden grabar vdeos con las imgenes que capturan las cmaras. Estas imgenes se guardan en una carpeta a eleccin del usuario, donde cada imagen tiene como nombre el nmero de frame del vdeo. Todas las imgenes numeradas de una carpeta pueden convertirse en un vdeo de forma sencilla utilizando la aplicacin ffmpeg1 con el comando siguiente:

ffmpeg -r framerate -b 1800 -i %d nombrevideo.avi

Donde framerate corresponde a los frames por segundo del vdeo y nombrevideo al nombre que se le quiere dar al archivo de video. Para saber el framerate que escoger lo mejor es jarse cuando se est grabando el vdeo de los fps que se indican en el panel de cada cmara. Los fps pueden variar dependiendo del nmero de cmaras simultneas que se estn viendo o grabando y del tiempo de actualizacin de cada cmara.

E.5. Iniciar el servidor en modo de prueba

Se ha desarrollado un modo de prueba en el servidor, en el que se despliegan un conjunto de dispositivos virtuales en lugar de los reales. Los dispositivos virtuales generalmente devuelven valores aleatorios dentro del rango de valores de su equivalente real. Tambin se puede operar sobre un motor y un servomotor virtual y ver cmaras virtuales que devuelven una imagen ja durante todo el tiempo. De esta forma se pueden hacer pruebas en la aplicacin cliente sin siquiera disponer del hardware real en el servidor. Para iniciar en modo prueba el servidor se ejecuta de la forma siguiente:

java -jar server.jar -test

E.6. Congurar el servidor con un archivo de conguracin

En el modo normal, el servidor se congura a partir de un archivo de conguracin donde se determinan los dispositivos que se van a utilizar. El archivo de conguracin del servidor se especica ejecutando el servidor de la siguiente forma:

java -jar server.jar -configure archivo

Donde archivo corresponde al archivo de conguracin.
1

http://ffmpeg.org/

205

Captulo E. Manual de usuario de JASEIMOV

E.6.1. Formato del archivo de conguracin

El formato del archivo de conguracin puede consultarse en el apartado 3.3.3 Conguracin del servidor de esta memoria.

E.6.2. Ejemplo de archivo de conguracin

# Configuration file for JASEIMOV Server # Motor MOTOR_CONTROL=motor,41908,0 # Servo SERVO_CONTROL=servo,45451,0,30,110,70 # Accelerometer ACCELEROMETER_SENSOR=accel,94332,CENTER # Encoder ENCODER_SENSOR=encoder,/dev/input/mouse0,0.7275,48,NEGATIVE_X_AXIS,BACK_RIGHT_WHEEL # Cameras CAMERA_SENSOR=front left cam,/dev/video0,352,288,90,FRONT_LEFT_CAMERA CAMERA_SENSOR=front right cam,/dev/video1,352,288,90,FRONT_RIGHT_CAMERA CAMERA_SENSOR=back left cam,/dev/video2,352,288,90,BACK_LEFT_CAMERA CAMERA_SENSOR=back right cam,/dev/video3,352,288,90,BACK_RIGHT_CAMERA # Interface Kit 1 & Sonar/IR INTERFACE_KIT=ikit1,156745 IR_SENSOR=left front ir,156745,0,IR_20_150,LEFT_FRONT IR_SENSOR=left back ir,156745,1,IR_10_80,LEFT_BACK IR_SENSOR=front right ir,156745,2,IR_10_80,FRONT_RIGHT IR_SENSOR=front ir,156745,3,IR_10_80,FRONT_CENTER_BOTTOM IR_SENSOR=front left ir,156745,4,IR_10_80,FRONT_LEFT SONAR_SENSOR=front right sonar,156745,5,2,FRONT_RIGHT_CORNER SONAR_SENSOR=front center sonar,156745,6,1,FRONT_CENTER_TOP SONAR_SENSOR=front left sonar,156745,7,0,FRONT_LEFT_CORNER # Interface Kit 2 & Sonar/IR INTERFACE_KIT=ikit2,156744 IR_SENSOR=back right ir,156744,1,IR_10_80,BACK_RIGHT IR_SENSOR=right front ir,156744,3,IR_10_80,RIGHT_FRONT IR_SENSOR=right back ir,156744,4,IR_10_80,RIGHT_BACK IR_SENSOR=back left ir,156744,6,IR_10_80,BACK_LEFT SONAR_SENSOR=back right sonar,156744,0,0,BACK_RIGHT_CORNER
206

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

SONAR_SENSOR=right sonar,156744,2,2,RIGHT_CENTER SONAR_SENSOR=left sonar,156744,5,5,LEFT_CENTER SONAR_SENSOR=back left sonar,156744,7,7,BACK_LEFT_CORNER

E.7. Solucin de problemas conocidos

E.7.1. Problema de conguracin de RMI
En algunas distribuciones de Linux ocurre un fallo en el manejo del registro Java RMI que impide la conexin entre el cliente y el servidor. Lo que ocurre es que en el chero /etc/hosts de algunas distribuciones no se actualiza correctamente la IP actual de la interfaz de red del ordenador. Esto produce que en los entresijos de Java RMI se acabe devolviendo como IP de los objetos RMI del servidor 127.0.0.1, cuando debera ser otra. Para solucionarlo se debe modicar el chero /etc/hosts que tendr al inicio un contenido similar a:

127.0.0.1 192.168.0.19

localhost nombre-maquina

Donde nombre-maquina vara, rerindose al nombre de la mquina actual. Lo que hay que hacer es cambiar la IP a la izquierda de nombre-maquina con la IP real que tiene ahora la interfaz de red del ordenador, que puede verse con el comando ifcong.

207

Apndice F

Manual del sistema de copias de seguridad

Este manual se ha creado con el n de describir el proceso a seguir para realizar copias de seguridad del sistema y restaurarlas.

F.1. Sistema escogido

Para realizar las copias de seguridad se utilizar la aplicacin partimage, que permite copiar el contenido de una particin en un archivo comprimido. Para poder utilizar esta aplicacin independientemente del sistema operativo principal, se ha realizado una instalacin mnima de Debian en otra particin y se ha habilitado su arranque en el GRUB. Las copias de seguridad se almacenarn en el directorio /backup de esta particin. Normalmente partimage se utiliza a travs de una interfaz que puede resultar compleja para alguien que no conozca el sistema. Por ello se ha creado un script bash que permite escoger entre las siguientes opciones con un men:

Script para realizar backups Autor : Aday Talavera Hierro Opciones : 1 - Hacer copia de particion Linux 2 - Restaurar copia de particion Linux 3 - Hacer copia de particion /boot 4 - Restaurar copia de particion /boot 5 - Salir Introduzca un numero de las opciones disponibles y presione la tecla Enter
Donde particin Linux se reere a la particin principal del sistema, en este caso /dev/sda2, y la particin /boot a la particin de arranque /dev/sda1. En /dev/sda3 se encuentra instalado el sistema de copias de seguridad. El archivo de imagen de la particin Linux se guarda como system.partimg.gz y al de la particin /boot como boot.partimg.gz. El script dispone de varias variables que permiten modicar su comportamiento para adaptarlo a otros sistemas. 209

Captulo F. Manual del sistema de copias de seguridad

F.2. Utilizacin del sistema

Para poder realizar una copia de seguridad o restaurar una previamente hecha, se deben seguir los pasos siguientes: 1. Arrancar el sistema y en el GRUB escoger la opcin correspondiente al sistema de recuperacin. Se arranca la particin del sistema de recuperacin. 2. Iniciar sesin en el sistema. 3. Ejecutar el script con sh backup.sh y utilizar el men para hacer una copia de seguridad o restaurar una. 4. Las copias se almacenarn en el directorio /backup de esa particin.

F.3. Script creado

#!/bin/bash # Basado en el script de Carlos TORRICO DELGADILLO publicado en: # http://grupos.emagister.com/debate/automatizar_partimage_usando_un_script/7266-649774 # Configuracion del script # bootpart -> particion /boot del sistema bootpart=/dev/sda1 # linuxpart -> particion del sistema a respaldar linuxpart=/dev/sda2 # backupsdir -> directorio donde almacenar los backups backupsdir=/backup # opciones de partimage para guardar (save) saveopt="-d -o -b -z1" # opciones de partimage para restaurar (restore) restoreopt="-b" menu { echo echo echo echo echo echo echo echo echo read } () "Script para realizar backups" "Autor : Aday Talavera Hierro" "Opciones :" " 1 - Hacer copia de particion Linux" " 2 - Restaurar copia de particion Linux" " 3 - Hacer copia de particion /boot" " 4 - Restaurar copia de particion /boot" " 5 - Salir" "Introduzca un numero de las opciones disponibles y presione la tecla Enter" eleccion

hacerbackup ()
210

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala

{ echo "\n" if [ $eleccion = 1 ]; then # Hacer copia de la particion /dev/sda2 con el sistema Linux partimage $saveopt save $linuxpart ${backupsdir}/system.partimg.gz echo "La copia de seguridad fue guardada" elif [ $eleccion = 2 ]; then # Restaurar copia de la particion /dev/sda2 con el sistema Linux partimage $restoreopt restore $linuxpart ${backupsdir}/system.partimg.gz.000 echo "La copia de seguridad fue restaurada" elif [ $eleccion = 3 ]; then # Hacer copia de la particion de arranque /boot en /dev/sda1 partimage $saveopt save $bootpart ${backupsdir}/boot.partimg.gz echo "La copia de seguridad fue guardada" elif [ $eleccion = 4 ]; then # Restaurar copia de la particion de arranque /boot en /dev/sda1 partimage $restoreopt restore $bootpart ${backupsdir}/boot.partimg.gz.000 echo "La copia de seguridad fue restaurada" fi echo "\n" } # Inicio de script clear while [ "$eleccion" != "5" ]; do menu hacerbackup done echo "Si quieres reiniciar el sistema, escribe reboot y presiona Enter" exit 0;

211

ndice de guras
1.1. Dispositivos implicados en la plataforma ASEIMOV . . . . . . . . . . . . . . . . 1.2. Vehculo ASEIMOV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1. Robocar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11 13 14 14 15 16 28 29 30 30 31 36 44 44 55 56 59 63 72 72 73 75

2.2. Carrocera de Robocar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. DreamBot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Detalle del ratn utilizado como encoder de DreamBot . . . . . . . . . . . . . . 2.5. Nightmare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.1. Arquitectura hardware del sistema informtico . . . . . . . . . . . . . . . . . . . 1.2. Detalle de los distintos formatos de placa base . . . . . . . . . . . . . . . . . . 1.3. Detalle de placa mini-ITX de VIA . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4. Detalle de placa nano-ITX de VIA . . . . . . . . . . . . . . . . . . . . . . . . . 1.5. Detalle de placa pico-ITX de VIA . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6. Detalle de mini fuente picoPSU-150-XT con conexiones ATX, P4, SATA y PATA . 2.1. Diagrama de clases UML de mouselib . . . . . . . . . . . . . . . . . . . . . . . 2.2. Detalle de emisor y receptor ptico en un ratn mecnico . . . . . . . . . . . . . 4.1. Foto de la placa durante la instalacin del sistema operativo . . . . . . . . . . . 4.2. Captura de UNetbootin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Acoplamiento del hardware original del ratn al vehculo . . . . . . . . . . . . . 1.1. Vehculo original Kyosho TF-5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1. Casos de uso del sistema cliente . . . . . . . . . . . . . . . . . . . . . . . . .

2.2. Casos de uso de establecer conexin . . . . . . . . . . . . . . . . . . . . . . . 2.3. Casos de uso de controlar vehculo . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Casos de uso de consultar sensor . . . . . . . . . . . . . . . . . . . . . . . . . 213

NDICE DE FIGURAS 2.5. Casos de uso de observar cmara . . . . . . . . . . . . . . . . . . . . . . . . . 2.6. Casos de uso de hacer grca . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7. Casos de uso de capturar datos . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8. Casos de uso de establecer idioma . . . . . . . . . . . . . . . . . . . . . . . . 2.9. Casos de uso de seleccionar sensor . . . . . . . . . . . . . . . . . . . . . . . . 2.10.Casos de uso de establecer tiempo actualizacin . . . . . . . . . . . . . . . . . 2.11.Casos de uso del sistema servidor . . . . . . . . . . . . . . . . . . . . . . . . . 2.12.Ventana principal de la aplicacin . . . . . . . . . . . . . . . . . . . . . . . . . 2.13.Ventana de control del vehculo . . . . . . . . . . . . . . . . . . . . . . . . . . 2.14.Visor de cmaras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.15.Ventana de captura de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.16.Ventana de elaboracin de grcas . . . . . . . . . . . . . . . . . . . . . . . . 3.1. Arquitectura del cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Arquitectura del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3. Arquitectura de comunicacin entre cliente/servidor . . . . . . . . . . . . . . . . 3.4. Despliegue de servicios RMI en el servidor y acceso por parte del cliente . . . . 3.5. Representacin de sistemas y subsistemas . . . . . . . . . . . . . . . . . . . . 3.6. Constantes de localizaciones de sensores en el vehculo . . . . . . . . . . . . . 77 79 81 83 83 84 85 87 87 88 88 89 92 93 93 95 97 99

3.7. Ventana principal de la aplicacin . . . . . . . . . . . . . . . . . . . . . . . . . 103 3.8. Ventana principal: detalle de disposicin de sensores en el vehculo . . . . . . . 105 3.9. Dilogo de conexin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 3.10.Dilogo de desconexin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 3.11.Dilogo de cierre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 3.12.Dilogo de cambio de lenguaje . . . . . . . . . . . . . . . . . . . . . . . . . . 106

3.13.Visor acelermetro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 3.14.Visor cmara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 3.15.Visor encoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 3.16.Visor infrarrojo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 3.17.Visor sonar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 3.18.Dilogo de cambio de tiempo de actualizacin . . . . . . . . . . . . . . . . . . 108

3.19.Ventana de control del vehculo . . . . . . . . . . . . . . . . . . . . . . . . . . 108 3.20.Ventana de visualizacin de cmaras . . . . . . . . . . . . . . . . . . . . . . . 109 214

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.21.Panel de control de cmara . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 3.22.Ventana de captura de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 3.23.Ventana de elaboracin de grcas . . . . . . . . . . . . . . . . . . . . . . . . 112 3.24.Dilogo de guardado de archivos . . . . . . . . . . . . . . . . . . . . . . . . . 113 3.25.Dilogo de seleccin de sensores . . . . . . . . . . . . . . . . . . . . . . . . . 113 3.26.Clases de interfaces de dispositivos remotos . . . . . . . . . . . . . . . . . . . 115 3.27.Clases de interfaz de listado de servicios . . . . . . . . . . . . . . . . . . . . . 116 3.28.Clases del sistema servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 3.29.Clases de lista de servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

3.30.Clases de implementacin de dispositivos . . . . . . . . . . . . . . . . . . . . . 118 3.31.Clases de despliegue de servicios . . . . . . . . . . . . . . . . . . . . . . . . . 119 3.32.Clases del sistema cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 3.33.Clases de listado de dispositivos del servidor . . . . . . . . . . . . . . . . . . . 120 3.34.Clases de conexin con dispositivos remotos . . . . . . . . . . . . . . . . . . . 120 3.35.Clases de actualizacin automtica de datos . . . . . . . . . . . . . . . . . . . 121 3.36.Diagrama de secuencia del proceso de actualizacin automtica . . . . . . . . . 121 3.37.Diagrama de secuencia del proceso de noticacin a los observadores de SensorCapturer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 3.38.Clases de interfaz principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 3.39.Clases del comando conectar a servidor . . . . . . . . . . . . . . . . . . . . . . 124 3.40.Clases del comando desconectar de servidor . . . . . . . . . . . . . . . . . . . 125 3.41.Clases del comando controlar vehculo . . . . . . . . . . . . . . . . . . . . . . 125 3.42.Clases del comando observar cmaras . . . . . . . . . . . . . . . . . . . . . . 126 3.43.Clases del comando capturar datos . . . . . . . . . . . . . . . . . . . . . . . . 126 3.44.Clases del comando hacer grcas . . . . . . . . . . . . . . . . . . . . . . . . 127 3.45.Clases del comando seleccionar idioma . . . . . . . . . . . . . . . . . . . . . . 127 3.46.Clases del control del motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 3.47.Clases del control del servomotor . . . . . . . . . . . . . . . . . . . . . . . . . 129 3.48.Clases de los visores de sensores . . . . . . . . . . . . . . . . . . . . . . . . . 130 3.49.Clases de la representacin grca de los sensores del vehculo . . . . . . . . . 131 3.50.Clases de la interfaz de visualizacin de cmaras . . . . . . . . . . . . . . . . . 131 3.51.Clases de la interfaz de captura de datos . . . . . . . . . . . . . . . . . . . . . 132 3.52.Clases de la interfaz de elaboracin de grcas . . . . . . . . . . . . . . . . . . 133 215

NDICE DE FIGURAS 3.53.Clases del dilogo de seleccin de sensores . . . . . . . . . . . . . . . . . . . 133 3.54.Clases del comando/dilogo establecer tiempo de actualizacin . . . . . . . . . 134 3.55.Diagrama de secuencia de la operacin congurar servidor . . . . . . . . . . . . 135 3.56.Diagrama de secuencia de la operacin iniciar servidor . . . . . . . . . . . . . . 135 3.57.Diagrama de secuencia de la operacin detener servidor . . . . . . . . . . . . . 136 3.58.Diagrama de secuencia de la operacin conectar a servidor . . . . . . . . . . . 137 3.59.Diagrama de secuencia de la operacin desconectar de servidor . . . . . . . . . 137 3.60.Diagrama de secuencia de la operacin seleccionar lenguaje . . . . . . . . . . . 138 3.61.Diagrama de secuencia de la operacin mostrar dilogo de seleccin de sensores 138 3.62.Diagrama de secuencia de la operacin aadir sensor . . . . . . . . . . . . . . 139 3.63.Diagrama de secuencia de la operacin quitar sensor . . . . . . . . . . . . . . . 139 3.64.Diagrama de secuencia de la operacin conrmar seleccin . . . . . . . . . . . 140 3.65.Diagrama de secuencia de la operacin mostrar dilogo de establecer tiempo de actualizacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 3.66.Diagrama de secuencia de la operacin establecer tiempo por defecto . . . . . . 141 3.67.Diagrama de secuencia de la operacin conrmar tiempo . . . . . . . . . . . . . 141 3.68.Diagrama de secuencia de la operacin controlar vehculo . . . . . . . . . . . . 142 3.69.Diagrama de secuencia de la operacin establecer velocidad . . . . . . . . . . . 142 3.70.Diagrama de secuencia de la operacin establecer aceleracin . . . . . . . . . . 143 3.71.Diagrama de secuencia de la operacin establecer posicin . . . . . . . . . . . 143 3.72.Diagrama de secuencia de la operacin detener vehculo . . . . . . . . . . . . . 144 3.73.Diagrama de secuencia de la operacin abrir sensor . . . . . . . . . . . . . . . 144 3.74.Diagrama de secuencia de la operacin actualizar manualmente . . . . . . . . . 145 3.75.Diagrama de secuencia de la operacin iniciar actualizacin automtica . . . . . 145 3.76.Diagrama de secuencia de la operacin detener actualizacin automtica . . . . 145 3.77.Diagrama de secuencia de la operacin observar cmara . . . . . . . . . . . . . 146 3.78.Diagrama de secuencia de la operacin iniciar streaming . . . . . . . . . . . . . 146 3.79.Diagrama de secuencia de la operacin detener streaming . . . . . . . . . . . . 147 3.80.Diagrama de secuencia de la operacin iniciar captura . . . . . . . . . . . . . . 147 3.81.Diagrama de secuencia de la operacin detener captura . . . . . . . . . . . . . 147 3.82.Diagrama de secuencia de la operacin ver captura . . . . . . . . . . . . . . . . 148 3.83.Diagrama de secuencia de la operacin borrar captura . . . . . . . . . . . . . . 148 3.84.Diagrama de secuencia de la operacin guardar imagen . . . . . . . . . . . . . 149 216

Diseo Hardware/Software para un Vehculo Elctrico Inteligente a Escala 3.85.Diagrama de secuencia de la operacin guardar vdeo . . . . . . . . . . . . . . 149 3.86.Diagrama de secuencia de la operacin capturar datos . . . . . . . . . . . . . . 150 3.87.Diagrama de secuencia de la operacin iniciar captura . . . . . . . . . . . . . . 150 3.88.Diagrama de secuencia de la operacin detener captura . . . . . . . . . . . . . 151 3.89.Diagrama de secuencia de la operacin limpiar captura . . . . . . . . . . . . . . 151 3.90.Diagrama de secuencia de la operacin guardar captura . . . . . . . . . . . . . 152 3.91.Diagrama de secuencia de la operacin hacer grca . . . . . . . . . . . . . . . 153 3.92.Diagrama de secuencia de la operacin iniciar grca . . . . . . . . . . . . . . 153

3.93.Diagrama de secuencia de la operacin detener grca . . . . . . . . . . . . . . 154 3.94.Diagrama de secuencia de la operacin limpiar grca . . . . . . . . . . . . . . 154 3.95.Diagrama de secuencia de la operacin guardar grca . . . . . . . . . . . . . 155

4.1. Ejemplo de documento Javadoc . . . . . . . . . . . . . . . . . . . . . . . . . . 158 1.1. Escenario de la calibracin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 1.2. Curva de calibracin del infrarrojo . . . . . . . . . . . . . . . . . . . . . . . . . 165 1.3. Curva de calibracin del sonar . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 1.4. Sensores delanteros de ASEIMOV . . . . . . . . . . . . . . . . . . . . . . . . . 166 C.1. Tiempo de respuesta medio en ms . . . . . . . . . . . . . . . . . . . . . . . . 185

D.1. Patrn comando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 D.2. Patrn mtodo fbrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 D.3. Patrn modelo-vista-controlador . . . . . . . . . . . . . . . . . . . . . . . . . . 189 D.4. Patrn observador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 D.5. Patrn ThreadPool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 E.1. Logo de ASEIMOV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 E.2. Ventana principal del cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 E.3. Ventana principal del cliente: detalle de disposicin de sensores en el vehculo . 195 E.4. Visor acelermetro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 E.5. Visor cmara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 E.6. Visor encoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 E.7. Visor infarrrojo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 E.8. Visor sonar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 217

NDICE DE FIGURAS E.9. Dilogo de conexin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 E.10.Dilogo de desconexin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 E.11.Dilogo de cierre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 E.12.Dilogo de cambio de lenguaje . . . . . . . . . . . . . . . . . . . . . . . . . . 197

E.13.Ventana de control del vehculo . . . . . . . . . . . . . . . . . . . . . . . . . . 198 E.14.Ventana de visualizacin de cmaras . . . . . . . . . . . . . . . . . . . . . . . 199 E.15.Panel de control de cmara . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 E.16.Ventana de captura de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 E.17.Ventana de elaboracin de grcas . . . . . . . . . . . . . . . . . . . . . . . . 202 E.18.Dilogo para guardar archivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 E.19.Dilogo de cambio de tiempo de actualizacin . . . . . . . . . . . . . . . . . . 203

E.20.Dilogo de seleccin de sensores . . . . . . . . . . . . . . . . . . . . . . . . . 204

218

Bibliografa
[1] Antnio J. R. Neves, Gustavo A. Corrente and Joo Figueiredo: NightMare: a simple and efcient vision-based robot, 2005, http://www.ieeta.pt/~an/publications/2005d. pdf. 16 [2] Adam Mouse computer-engineering.org/ps2mouse/. 171 Chapweske: The PS/2 Interface, 2003,

http://www.

[3] Debian: Pgina principal, http://www.debian.org/. [4] Free Software Foundation: GNU GENERAL PUBLIC LICENSE Version 3, 2007, http:// www.gnu.org/licenses/gpl-3.0.html. 159 [5] Hardware Secrets, Gabriel Torres: Inside Atom Architecture, 2008, http://www. hardwaresecrets.com/printpage/615. [6] Intel Corporation: microATX Motherboard Interface Specication Version 1.2, 2004, http://www.formfactors.org/developer/specs/matxspe1.2.pdf. 29 [7] James O. Hamblen, Michael D. Furman: Rapid Prototyping of Digital Systems A Tutorial Approach, 2002,Second Edition Kluwer Academic Publishers. 171 [8] JChart2D: Pgina principal, http://jchart2d.sourceforge.net. [9] JGraph 5: Pgina de principal, http://www.jgraph.com/jgraph5.html. [10] Kenneth L. Calvert, Michael J. Donahoo: TCP/IP Sockets in Java Practical Guide for Programmers Second Edition, 2008. [11] Kingston Technology Corporation: Flash Memory - Meet The DataTraveler Family, 2009, http://www.kingston.com/flash/dt_chart.asp. 34 [12] Kingston guide, Technology 2009, Corporation: SSDNOW End User ref

http://www.kingston.com/ukroot/ssd/pdf_files/ SSDNOW_End_User_ref_guide_A5_EN_1209.pdf. 34

[13] OCZ Technology: OCZ Throttle eSATA Flash Drive, 2010, http://www.ocztechnology. com/products/flash_drives/ocz_throttle_esata_flash_drive. 34 [14] Oracle: Java SE 6 Documentation, http://download.oracle.com/javase/6/docs/. [15] Phidgets: Phidgets Product Manual 1000 - PhidgetServo 1-Motor, 2009, http://www. phidgets.com/documentation/Phidgets/1000.pdf. 67 219

BIBLIOGRAFA [16] Phidgets: Phidgets Product Manual 1018 - PhidgetInterfaceKit 8/8/8 for Board Revision 0, 2008, http://www.phidgets.com/documentation/Archive/ 1018_0_Product_Manual.pdf. 69 [17] Phidgets: Phidgets Product Manual 1059 - PhidgetAccelerometer 3-Axis, 2009, http:// www.phidgets.com/documentation/Phidgets/1059.pdf. 67 [18] Phidgets: Phidgets Product Manual 1060 - PhidgetMotorControl LV, 2009, http://www. phidgets.com/documentation/Phidgets/1060.pdf. 67 [19] Phidgets: Phidgets Product Manual 1128 - Sonar Sensor, 2009, http://www.phidgets. com/documentation/Phidgets/1128.pdf. 68 [20] Phidgets: Phidgets Product Manual 2008 - IR Distance Sensor, 2008 http://www. phidgets.com/documentation/Phidgets/2008.pdf. 68 [21] Roger S. Pressman: Ingeniera del software un enfoque prctico, 2002, Quinta edicin en espaol por McGRAW-HILL. 71, 86 [22] SPANSION: Ken Perdue Wear Leveling, 2008, http://www.eettaiwan.com/STATIC/ PDF/200808/EETOL_2008IIC_Spansion_AN_13.pdf. 34 [23] Toms Hardware, Chris Angelini: Zotacs Ion Board On Windows 7: Nvidia Re-Arms Intels Atom, 2009, http://www.tomshardware.com/reviews/zotac-ion-atom,2300. html. [24] Toms Hardware, Patrick Schmid and Achim Roos: Flash SSD Update: More Results, Answers, 2008, http://www.tomshardware.com/reviews/ssd-hard-drive, 1968.html. 36 [25] VIA Technologies: New Mini-ITX Mainboard Specication White Paper, http://www.via.

com.tw/en/downloads/whitepapers/initiatives/spearhead/ini_mini-itx. pdf. 29
[26] VIA Technologies: VIA Nano-ITX Form Factor, http://www.via.com.tw/en/products/ embedded/ProductSeries.jsp?serialNo=1. 30 [27] VIA Technologies: VIA Nano Processor Introductory White Paper, http://www.via.com. tw/en/downloads/whitepapers/processors/WP080529VIA_Nano.pdf. [28] VIA Technologies: VIA Pico-ITX Form Factor White Paper, http://www.via.com.tw/en/ downloads/whitepapers/initiatives/spearhead/pico-itx_form_factor.pdf. 30, 35

220