Control de Tiempo Real estricto en un robot móvil basado en MaRTE OS. Francisco Javier Feijoo Cano. Proyecto Fin de Carrera Ingeniería Informática

Transcripción

1 Proyecto Fin de Carrera Ingeniería Informática Control de Tiempo Real estricto en un robot móvil basado en MaRTE OS Francisco Javier Feijoo Cano Director: José Luis Villarroel Salcedo Departamento de Informática e Ingeniería de Sistemas Centro Politécnico Superior Universidad de Zaragoza Diciembre 2007

2

3 Mi agradecimiento a la gente del laboratorio de robótica que han hecho posible la realización del presente trabajo en especial a Danilo Tardioli, porque con sus conocimientos y su colaboración, me ayudó a seguir hacia delante en los momentos más difíciles. Agradecer también la desinteresada colaboración de Daniel Sangorrin, que desde la Universidad de Cantabria me prestó su ayuda y su tiempo en diferentes partes del proyecto.

4

5 Índice general Índice de guras 9 Índice de cuadros Introducción Objetivo y alcance Contexto Diferentes objetivos de los sistemas operativos Sistema operativo de propósito general Sistema operativo de tiempo real Elección del sistema Necesidad de control temporal en un robot móvil Estructura de la memoria El sistema operativo MaRTE OS Características Trabajando con MaRTE OS El robot móvil Pioneer Arquitectura del sistema Sensores Actuadores Mecanismo de comunicación Método de trabajo actual con el robot Integración de los sensores en MaRTE Análisis general Diseño arquitectural Microcontrolador y P2OS Análisis Diseño Láser SICK LMS Análisis Diseño Comunicación inalámbrica

6 Análisis Diseño GPS Novatel Análisis Diseño Implementación y pruebas Caracterización temporal completa del sistema Medir el tiempo de cómputo en MaRTE Dependencia de la línea serie Pruebas realizadas y resultados Navegación autónoma y tiempo real estricto Esquema de tareas y cumplimiento de plazos Comunicaciones en tiempo real Resultados Conclusiones y trabajos futuros Conclusiones Dicultades encontradas Trabajos futuros Bibliografía 46 A. Fases del proyecto y diagrama de Gantt 48 A.1. Hitos temporales A.2. Diagrama de Gantt B. Estudio sobre sistemas operativos de tiempo real 50 B.1. Arquitectura de un SO de tiempo real B.1.1. Arquitectura de un SO de propósito general B.1.2. Clases de tiempo real B.1.3. Características de rendimiento B.1.4. Arquitectura de un SO de tiempo real B.1.5. Rendimiento del sistema B.2. Algunos de los SO de tiempo real más usados B.2.1. Introducción B.2.2. ADEOS (Adaptative Domain Environment Operating Systems ) B.2.3. RTLinux B.2.4. MaRTE B.2.5. VxWorks C. P2OS: El Sistema Operativo del microcontrolador. 64 C.1. Introducción C.1.1. Especicaciones técnicas C.2. El Sistema Operativo del robot. P2OS

7 ÍNDICE GENERAL 7 C.2.1. Conexión Cliente-Servidor C.2.2. Comandos de movimiento C.2.3. Sonar C.2.4. Emergencias y paradas D. El láser SICK LMS 68 D.1. Información básica sobre el láser D.2. Software. Mecanismo de comunicación D.2.1. Esquema de funcionamiento para la comunicación con LMS D.2.2. Establecer la comunicación con LMS D.2.3. Valores por defecto del LMS D.2.4. Cambiar la velocidad de transmisión D.2.5. Cambiar la resolución del LMS D.2.6. Cambiar la unidad de medida en LMS D.2.7. Empezar con la salida continua de datos desde el LMS D.2.8. Interpretación de los datos recibidos D.2.9. Detención de la salida continua de datos D.2.10.Formato de la cadena de datos de salida D.2.11.Información del byte de estado (status byte) E. Trabajando con MaRTE OS 76 E.1. Instalación E.2. Creación de nuevos drivers E.3. Arrancar en red con MaRTE OS y el robot E.3.1. Elementos hardware E.3.2. Elementos software E.3.3. Conguración del servidor E.3.4. Conguración del host E.3.5. Método de trabajo F. Manual de usuario y API 80 F.1. Manual de usuario F.2. Funciones en lenguaje C F.2.1. P2OS F.2.2. Láser F.2.3. GPS F.2.4. Comunicación inalámbrica F.3. Funciones en lenguaje Ada F.3.1. P2OS F.3.2. Láser F.3.3. GPS F.3.4. Comunicación inalámbrica F.4. Consideración nal

8 G. Interfaz de programación entre Ada y C 89 G.1. Visibilidad global de los datos G.2. Visibilidad global de funciones G.3. Ejecución del programa G.3.1. Inicialización G.3.2. Captura de excepciones G.4. Interfaz de funciones

9 Índice de guras 2.1. Arquitectura de MaRTE OS para aplicaciones ADA y C Entorno de desarrollo del proyecto Robot Pioneer 3-AT Los dispositivos más importantes del robot y sus conexiones Diseño del driver P2OS Esquema de funcionamiento del puerto serie Doble búfer del láser para minimizar bloqueos Medición del tiempo de cómputo de una función en MaRTE para C y Ada respectivamente Ejemplo de tareas con tiempos en MaRTE Algoritmo de navegación adaptado a MaRTE Esquema de las tareas Navegación del robot a través de comunicación inalámbrica y control A.1. Diagrama de Gantt D.1. Principio de medida y rango angular de LMS D.2. Resumen del funcionamiento de las comunicaciones con LMS D.3. Esquema de la inicialización del LMS D.4. Barrido láser en el modo 0 o..180 o y o D.5. Operaciones en la ejecución de un programa con LMS F.1. Funciones para manejar el P20S en C F.2. Funciones para manejar el Láser en C F.3. Funciones para manejar el GPS en C F.4. Funciones para manejar el P20S en Ada F.5. Funciones para manejar el Láser en Ada F.6. Funciones para manejar el GPS en Ada

10 Índice de cuadros 4.1. Opciones de conguración del láser Interrupciones generadas por la línea serie Información sobre las tareas Resultados obtenidos

11 Capítulo 1 Introducción 1.1. Objetivo y alcance El objetivo principal de este proyecto es la implantación del sistema operativo (SO) de tiempo real estricto MaRTE OS en un robot móvil Pioneer 3-AT. Se crearán los controladores (drivers) de algunos dispositivos del robot. Entre ellos el microcontrolador, el láser, el sistema de comunicación inalámbrico y el GPS. Además se proporcionarán las herramientas necesarias para continuar investigando y poder realizar aplicaciones en este nuevo sistema. MaRTE OS (Minimal Real Time Operating System for Embedded Applications ) [1] es un SO para aplicaciones empotradas basado en un subconjunto del estándar POSIX.13 para tiempo real. Está escrito principalmente en Ada y actualmente está siendo desarrollado en la Universidad de Cantabria. Es totalmente necesario añadir al control de los robots restricciones de tiempo real. Una mala gestión del procesador por parte del SO puede provocar diversos problemas de control en el robot. Con el SO MaRTE pueden realizarse aplicaciones ables bajo un entorno determinista que asegura una planicación correcta de las tareas que componen la aplicación. Para poder realizar comunicaciones en tiempo real se estudiará y portará a MaR- TE el protocolo RT-WMP que actualmente se desarrolla en la Universidad de Zaragoza. RT-WMP (Real Time Wireless Multi-hop Protocol ) [7] es un protocolo de comunicación basado en paso de testigo, con la característica principal de soportar transmisiones en tiempo real. Se demostrará el correcto funcionamiento de las herramientas desarrolladas con diferentes aplicaciones y se evaluarán los resultados obtenidos. Además se deberá realizar una caracterización temporal completa del conjunto de funciones disponibles para cada dispositivo. Como valor añadido del proyecto, se han establecido las bases para trabajar con un SO de tiempo real de libre distribución que es capaz de funcionar en diferentes arquitecturas. Esto permite el estudio de diferentes técnicas y protocolos basados en tiempo real que hasta ahora eran difíciles o imposibles de realizar. 11

12 1.2. Contexto El proyecto se ha llevado a cabo en el grupo de Robótica, Percepción y Tiempo Real del Departamento de Informática e Ingeniería de Sistemas (DIIS). El departamento posee 4 robots móviles Pioneer de la casa constructora ActiveMedia. Hasta ahora los robots sólo tenían instalado un SO Linux de propósito general. Para poder interaccionar con los dispositivos del robot (odometría, láser, GPS, comunicaciones, etc) se trabaja a través de una plataforma cliente/servidor llamada Player/Stage de libre distribución que se ejecuta sobre este SO. Una aplicación que se ejecuta en un SO de estas características no puede controlar qué tarea entra a ocupar el procesador en cada instante haciendo imposible garantizar el cumplimiento de restricciones temporales. La forma de ejecución de las tareas que componen la aplicación no las determina el usuario, sino el SO que tiene otros objetivos diferentes a los de tiempo real. No se garantiza una correcta planicación de las tareas que se ejecutan en el robot, pudiendo provocar comportamientos no especicados en el sistema Diferentes objetivos de los sistemas operativos Los SO proporcionan una plataforma de software encima de la cual otros programas, llamados aplicaciones, puedan funcionar. Las aplicaciones se programan para que funcionen encima de un SO particular, por tanto, la elección del SO determina en gran medida las aplicaciones que se pueden utilizar. En el anexo B se ilustran las características más importantes que diferencian a un SO de propósito general de uno de tiempo real desde un punto de vista técnico Sistema operativo de propósito general El objetivo de este tipo de SO es gestionar y administrar ecientemente los recursos hardware del ordenador, permitiendo ejecutar concurrentemente varios programas sin que haya conictos en el acceso de cada uno de ellos a cada uno de los recursos que necesita y sin que ningún programa monopolice un recurso determinado. El SO intentará que la CPU del ordenador realice el mayor rendimiento medio posible. Esto se consigue gracias a un planicador que aprovecha al máximo la capacidad del procesador haciendo evolucionar todos los procesos o tareas alterando su ejecución y modicando dinámicamente la prioridades. El usuario no tiene acceso al control directo del hardware y tampoco puede prever con seguridad el momento en el que una tarea terminará su ejecución, ni el momento en el

13 1. Introducción 13 que un proceso obtendrá un resultado. Otra de las características de este tipo de SO es que son multitarea, multiaplicación y multiusuario. En una misma máquina pueden estar en ejecución varias tareas, estar en marcha varias aplicaciones y estar registrados varios usuarios al mismo tiempo Sistema operativo de tiempo real Un sistema de tiempo real es un sistema de procesamiento de información que debe responder a estímulos de entrada generados externamente en un período nito y especí- co. Las respuestas correctas dependen no sólo de los resultados obtenidos sino también del tiempo en que son entregadas. Las fallos por no responder a tiempo son tan malos como un mal resultado. Este tipo de sistemas está formado por dispositivos de E/S, hardware y software de propósito especíco en donde existe una fuerte interacción con el entorno. El entorno cambia con el tiempo y el sistema debe controlar y/o reaccionar ante cada uno de los cambios. Para conseguir un funcionamiento correcto se imponen varias restricciones. Restricciones de tiempos: Cómputo, periodo, plazos. Restricciones de predecibilidad: Implica que debe ser posible demostrar o comprobar a priori que los requerimientos de tiempos se cumplen en cualquier circunstancia. Como consecuencia, la predecibilidad implica: Una cuidadosa planicación de tareas y recursos. Cumplimiento predecible de requisitos temporales: determinismo. Anticipación a fallos, y sus requerimientos temporales. Consideraciones de sobrecargas: degradación controlada. Consideraciones de elementos de impredecibilidad. Dotar al sistema con capacidades de monitorización y control de tiempos (hardware, software, SO, lenguaje, líneas y protocolos de comunicaciones). Restricciones de recursos: una tarea puede requerir acceso a ciertos recursos, además del procesador, como dispositivos de E/S, redes de comunicación, estructuras de datos, archivos y bases de datos. Restricciones de precedencia: una tarea puede requerir resultados de una u otra tarea antes de comenzar su ejecución. A diferencia de los SO de propósito general, los SO de tiempo real son monousuario y monoaplicación. Sólo puede haber un usuario que es el que ejecuta la única aplicación que hay en el sistema. Esta aplicación se encargará de crear las diferentes tareas que controlen el sistema.

14 Elección del sistema Es evidente que estos dos tipos de SO cubren aplicaciones totalmente diferentes. Un SO de propósito general no está diseñado para controlar un sistema móvil que realiza operaciones con unos requisitos temporales y ha de ser able en todo momento. Por otro lado, tampoco es lógico usar un SO de tiempo real en aplicaciones sin restricciones temporales, que en un SO de propósito general se ejecutan sin problemas. Será necesario usar un SO de tiempo real cuando la aplicación requiera un control estricto, de forma que cuando reciba un dato de entrada sea necesario realizar el procesamiento de dicho dato antes de la recepción de la siguiente entrada. Es posible encontrar sistemas empotrados que basan su funcionamiento en algún tipo de SO de tiempo real realizando multitud de aplicaciones en aviones, trenes, coches, teléfonos móviles, etc Necesidad de control temporal en un robot móvil El robot que se ha usado en el proyecto esta formado por una serie de sensores que recogen información del entorno y actuadores que le permiten realizar movimientos. Cada uno de estos dispositivos envían/reciben datos a una frecuencia diferente. Para poder recoger los datos correctamente será necesario crear una tarea para cada dispositivo que se ejecute a la frecuencia correspondiente. Para que el robot se mueva o realice un trabajo, será necesaria una tarea que se encargue por ejemplo de ejecutar un algoritmo de navegación evitando obstáculos. Además es posible que se desee visualizar en una pantalla lo que el robot está haciendo y para ello se creará otra tarea que muestre los datos deseados. Al tratarse de un sistema móvil, los requisitos temporales se deben respetar siempre. Los algoritmos de control tienen que cumplir unos periodos jos y responder dentro de unos plazos previamente establecidos. En un robot que se mueve a una velocidad de 2 m/s (7.2 km/h) y ejecuta su control cada 100 milisegundos, reaccionar 50 milisegundos más tarde supone reaccionar 10 cm más lejos de lo que se desea. Esto puede provocar un golpe del robot, a una persona o realizar un mal movimiento. Como es lógico, cada tarea del sistema tendrá una prioridad determinada, que será asignada después de realizar un estudio de planicabilidad. La tarea que atiende un sensor tiene más prioridad que la tarea que realiza la navegación. De la misma forma, la tarea de navegación no puede ser interrumpida por la tarea que muestra información en la pantalla. En denitiva no se puede permitir que en un momento determinado el SO decida dar mayor o menor prioridad a una de las tareas, ni expulsar a una tarea del procesador para que entre otra.

15 1. Introducción 15 Para que todas las tareas empiecen en los momentos determinados y acaben dentro de su plazo correspondiente es necesario disponer de un SO de tiempo real que asegure una ejecución de las tareas de la misma forma que han sido planicadas Estructura de la memoria En el capítulo 2 y 3 se puede ver una introducción al SO MaRTE y al robot utilizado durante el proyecto. En el capítulo 4 se muestra el proceso de desarrollo de cada uno de los drivers, pasando por las fases de análisis, diseño, implementación y pruebas. En el capítulo 5 se explican algunas consideraciones sobre la medición del tiempo en MaRTE y en el capítulo 6 se muestran las aplicaciones realizadas para demostrar el buen funcionamiento del sistema y los resultados que se han obtenido en el proyecto. Para nalizar en el capítulo 7 se pueden ver las conclusiones obtenidas y los trabajos futuros que se plantean como resultado de este proyecto. Además tras la memoria se puede profundizar en los aspectos más importantes que se han planteado consultando los diferentes anexos realizados. Características de SO de tiempo real, manuales de los drivers, arranque en red, API de la aplicación o los hitos más importantes del proyecto son algunos de los temas que se pueden consultar.

16 Capítulo 2 El sistema operativo MaRTE OS MaRTE OS es un SO de tiempo real destinado al desarrollo de aplicaciones empotradas que se ajusta al perl de Sistema de Tiempo Real Mínimo denido en el estándar POSIX MaRTE está escrito en lenguaje Ada, con partes en C y en ensamblador, y soporta aplicaciones Ada, C y C++. [2] 2.1. Características Permite ejecutar aplicaciones en máquinas desnudas. Da y controla el acceso a los recursos hardware. Es bastante diferente de un sistema de propósito general como Linux ya que no soporta sistemas de cheros ni tiene una consola de comandos. Sigue el subconjunto mínimo de tiempo real POSIX.13. Dentro de POSIX.13 MaR- TE OS gura dentro de la categoría Mínimo, destinada a sistemas empotrados pequeños, en la cual no es necesario ofrecer sistema de cheros ni multiproceso. MaRTE OS no hace uso pues de la MMU de algunas arquitecturas, no usa disco duro sino que se aloja en memoria volátil y tampoco necesita de un terminal. Es lo que se denomina en jerga POSIX como controlador de un Tostador. Funcionalidad del perl mínimo del subconjunto POSIX.13 incluida en MaRTE OS: Threads: también llamados hilos o hebras. Un thread es una secuencia de instrucciones ejecutada en paralelo con otras secuencias. Los threads son una forma de dividir un programa en varias tareas que se ejecutan de forma concurrente. Mutexes, variables condicionales, semáforos: estructuras utilizadas para la sincronización de varios threads. Señales: servicio del núcleo que permite indicar la existencia de un evento. Relojes y contadores: ofrecen funcionalidad para controlar el tiempo de ejecución de cada thread. Suspensión de threads, retrasos absolutos y relativos. 16

17 2. El sistema operativo MaRTE OS 17 Ficheros de dispositivo y entrada/salida: Permiten tratar los dispositivos desde un punto de vista abstracto como si fueran un chero al que realizar llamadas del tipo open, read, write,... Funcionalidad extra: Manejadores de interrupciones hardware, planicación denida por la aplicación. Ofrece concurrencia a nivel de thread (tareas en Ada) pero no a nivel de procesos. En MaRTE OS sólo hay un proceso (que será el encargado de crear los threads-tareas necesarios), y por tanto un único espacio de direcciones de memoria. Utiliza una política de planicación expulsiva con prioridades jas. Estos algoritmos permiten un alto aprovechamiento de la CPU y su implementación es sencilla tal y como dene el estándar POSIX.13.1 permite utilizar políticas de planicación expulsivas como FIFO con prioridades, round-robin o servidor esporádico. Para la sincronización de tareas implementa el protocolo de herencia básica de prioridad y el techo de prioridad inmediato. Todos los servicios tienen una respuesta y latencia temporal acotada, por lo que se puede utilizar para aplicaciones de tiempo real (tanto estricto como no). El espacio de direcciones es compartido por el núcleo y la aplicación con lo cual no se provee la protección de otros sistemas operativos y se debe probar a fondo el sistema nal. La ventaja es que permite una mayor velocidad de ejecución. Es un núcleo monolítico. Un núcleo monolítico se caracteriza porque cuando se está ejecutando una parte de su código no hay otras partes ejecutándose concurrentemente. Permite simplicar su desarrollo y ser muy ecientes en sistemas monoprocesador, aunque es complicado portarlo a sistemas multiprocesador. Está escrito en Ada 95 (salvo algo de código en C y ensamblador) pero ofrece interfaces tanto para aplicaciones Ada como C, o incluso aplicaciones que mezclen threads con tareas Ada. Es portable a diferentes plataformas gracias a una capa de abstracción hardware. Incluyendo microcontroladores, de gran importancia en el mundo de los sistemas empotrados. Actualmente se encuentran implementadas para: Arquitectura x86 PC (bien en máquinas desnudas o bien en emuladores). El núcleo es compatible con cargadores que usen el protocolo Multiboot. Arquitectura Linux y LinuxLib, donde MaRTE OS corre dentro de Linux. Principalmente destinada a investigación y enseñanza (no se puede alcanzar requerimientos de tiempo real estricto dentro de un sistema que no lo es, como Linux). Arquitectura M683XX. No se distribuye actualmente con MaRTE OS debido a que corresponde a una versión antigua que no ha sido actualizada. Es código libre con licencia GNU/GPL.

18 Figura 2.1: Arquitectura de MaRTE OS para aplicaciones ADA y C En la gura 2.1 podemos ver la arquitectura en forma de capas de MaRTE OS para una aplicación escrita en Ada y en C. La principal diferencia entre ambas radica en la capa utilizada para comunicar la aplicación con el resto del sistema. Como puede apreciarse en ambas guras, el núcleo incluye una interfaz abstracta de bajo nivel para acceder al hardware. En ella se dene la visión que del hardware tienen las partes del núcleo que son independientes de la plataforma de ejecución (Ej: x86, PowerPC, ARM, MIPS,...). Esta interfaz constituye la única parte del núcleo que es dependiente del hardware, lo que facilita el portado de MaRTE OS a distintas plataformas. Por otro lado, los gestores de dispositivos (drivers) también presentarán dependencias respecto al hardware sobre el que se ejecutan Trabajando con MaRTE OS En el anexo E se puede consultar la forma de instalación del sistema, el proceso de creación de nuevos drivers y la conguración necesaria de nuestro entorno de desarrollo para poder arrancar el SO a través de la red. MaRTE es un SO destinado a controlar aplicaciones empotradas en diferentes máquinas y arquitecturas. Por este motivo al desarrollar una aplicación será necesario un ordenador donde el usuario programa y compila (servidor), y otra máquina donde se ejecute el archivo generado en el proceso anterior (host). Para comenzar con MaRTE OS es muy recomendable el uso de alguna máquina virtual, como por ejemplo Qemu (disponible en De esta forma no hay que traspasar el archivo entre diferentes ordenadores. Para un mayor detalle sobre como utilizar la máquina virtual con MaRTE OS se recomienda leer [3]. En este caso, la máquina host es el robot, y por lo tanto todas las pruebas deberán realizarse sobre esta arquitectura. El entorno en el que se ha desarrollado el proyecto se muestra en la gura 2.2

19 2. El sistema operativo MaRTE OS 19 with MaRTE_OS; with Text_IO; use Text_IO; procedure robot is begin setspeed(1.0,0.1);... end procedure; Ordenador de desarrollo Robot en ejecución Arranque en red o mprogram en disco Compilación Código objeto Enlazado MaRTE OS Red Programa ejecutable Inicializa el sistema Programa ejecutable Red Ejecuta programa del usuario Servidor DHCP + TFTP Figura 2.2: Entorno de desarrollo del proyecto. En el servidor tendremos que tener Linux con los archivos y el compilador de MaRTE instalado. Aquí será donde se programe la aplicación incluyendo las librerías del SO. Al compilar con el compilador de MaRTE se obtiene un chero llamado mprogram que se deberá copiar al robot para ser ejecutado. Para agilizar el proceso, se permitió al robot arrancar en red, descargándose el archivo generado después de compilar. El ordenador host obtiene la dirección de red por medio de un servidor DHCP, y este es el que le indica que archivo debe descargarse para arrancar. La máquina host lo descarga mediante un servidor TFTP instalado en el servidor y comienza la ejecución del SO y la aplicación programada. Esta conguración esta completamente especicada en el apartado 2.3 de [4].

20 Capítulo 3 El robot móvil Pioneer 3.1. Arquitectura del sistema En la gura 3.1 se puden observar los robots disponibles en el laboratio. Cada uno de estos robots está formado por un ordenador Pentium III a 800MHz, con 250MB de memoria RAM, 40GB de disco duro y una variedad de dispositivos sensores y actuadores. Los sensores permiten obtener información del entorno. Los actuadores sirven para interaccionar con el entorno y dar cierta movilidad al sistema. En la gura 3.2 se muestra una esquema gráco de la arquitectura del sistema donde se detallan los diferentes dispositivos estudiados y sus conexiones. Figura 3.1: Robot Pioneer 3-AT. El láser, el microcontrolador y el GPS se comunican con el robot a través de la línea serie RS232. El microcontrolador tiene conectados varios sensores. Él mismo se comunica con estos sensores gracias a un SO llamado P2OS que lleva incorporado. El ordenador (el robot) se comunica con el micro y sus sensores mediante comandos que el P2OS comprende. La tarjeta inalámbrica es de tipo PCMCIA. El robot no dispone de un conector de este tipo pero si de uno de tipo PCI 104. Para poder usar la tarjeta se ha utilizado un adaptador entre PCMCIA y PCI 104 de 32 bits. 20

21 3. El robot móvil Pioneer 21 LÁSER GPS MICRO- CONTROLADOR Odometría Sonar ttys0 ttys1 ttys2 Motores Brújula LINEA SERIE RS232 P2OS ROBOT PCI 104 ADAPTADOR PCI-PCMCIA PCMCIA TARJETA INALÁMBRICA Figura 3.2: Los dispositivos más importantes del robot y sus conexiones Sensores Posición relativa: El sensor de odometría es el que informa al robot de la posición en la que se encuentra situado respecto a los movimientos realizados. Básicamente lo que hace es medir el movimiento de las ruedas del robot, calculando la posición en X, en Y y el ángulo que se ha movido. Un sensor tacométrico esta conectado al microcontrolador. Con cada movimiento de las ruedas el sensor envía pulsos al microcontrolador y este los traduce a valores correspondientes al movimiento. Esta medida es aproximada y poco able ya que si una rueda derrapa el sistema de odometría creerá que el robot se ha movido más de lo que realmente se ha movido. Esto provoca que el robot tenga una información acerca de su posición incorrecta. Además, debido a que la odometría es un valor respecto al desplazamiento realizado, el error se va acumulando y cuantos más movimientos se hacen la calidad de la medida empeora. Con el sistema de odometría también se puede saber a que velocidad se realizan los movimientos, tanto translacional como angularmente. Estos valores de velocidad se obtienen derivando el valor de la posición. Posición global: Gracias al dispositivo GPS de la marca Novatel modelo ProPack G2 que lleva incorporado el robot se puede obtener la posición global en la que se encuentra el robot. El error del GPS es de pocos metros y se puede reducir a centímetros si se usa una estación base diferencial. El problema del sistema GPS es que sólo puede usarse en exteriores porque en interiores no recibe la señal de los satélites. Esto obliga a usar la odometría en interiores. Entorno 2D con láser: El robot dispone de un sensor láser de distancias de la marca SICK modelo LMS que es capaz de aportar información sobre lo que el robot tiene delante suyo. Su funcionamiento se basa en un mecanismo de espejo rotatorio, que va dirigiendo un pulso láser en un recorrido horizontal de hasta 180 o. Las medidas se calculan por tiempo de vuelo. Para obtener más información acerca del dispositivo SICK LMS se recomienda consultar el anexo D.

22 Entorno 2D con sonar: También existe la posibilidad de usar los 16 sensores sonar que proporcionan información similar al láser pero más limitada. En vez de utilizar un láser, lanza una onda que luego recoge y se obtiene la distancia al obstáculo. El problema es que las ondas no se transmiten en línea recta como el láser. Esto provoca que en diferentes situaciones el valor que se recoge es erróneo e incluso puede que la onda que recoge un sensor es la que envió otro de los sensores debido a algún rebote. Además en vez de obtener las 360 distancias que puede proporcionar el láser, ofrece tan solo 16. Orientación: Es posible usar una brújula electrónica para conocer de forma precisa la orientación del robot. La brújula es uno más de los sensores que está conectado al microcontrolador. Bumpers: En la parte frontal y trasera del robot están colocados 10 sensores que indican al robot que ha tocado o se ha chocado con algo. Cuando uno de estos sensores se activa, el robot por defecto se para. Este comportamiento es congurable. También está conectado al microcontrolador Actuadores Motores: Para realizar movimientos el robot dispone de 2 motores para mover las ruedas de cada lado. Se puede mover en la dirección X, Y con desplazamientos de translación y 360 o angularmente, pero para girar ha de rotar sobre sí mismo derrapando ya que las ruedas están jas sin poder modicar la dirección. La velocidad de translación máxima es de 2 metros/segundo y la angular de 360 o por segundo Mecanismo de comunicación El robot dispone de un conector PCI 104. Gracias a un adaptador que convierte una entrada PCI 104 a una de tipo PCMCIA es posible usar una tarjeta inalámbrica de tipo PCMCIA de la marca Conceptronics. A través de esta tarjeta se puede enviar información del robot a cualquier otra tarjeta inalámbrica utilizando el protocolo Además es posible utilizar el protocolo RT-WMP para comunicaciones en tiempo real que se esta desarrollando actualmente en la Universidad de Zaragoza Método de trabajo actual con el robot Actualmente el robot tiene instalado un SO Linux de propósito general. Para controlarlo se utiliza un programa de software libre con licencia GNU llamado Player/Stage. Player se ejecuta sobre el robot proporcionando un interfaz simple y claro para el manejo de sus sensores y actuadores sobre una red IP. Por lo tanto, para poder controlar el robot, se necesita de un programa cliente que acceda por medio de un socket TCP/IP a Player.

23 3. El robot móvil Pioneer 23 Este cliente puede leer la información que devuelven los sensores, dar órdenes a los actuadores y congurar los dispositivos que monta el robot al vuelo. Entre las principales características de Player cabe mencionar su capacidad para soportar distintos robots y su facilidad para añadir nuevo hardware. Todo esto es posible gracias a su arquitectura modular. Otra de las cosas que se puede destacar de Player es que si un programa de control funciona en su simulador (Stage), generalmente, este funcionará en el robot real sin ningún cambio. El programa es muy cómodo para desarrollar sistemas de navegación y todo tipo de aplicaciones robóticas. Permite realizar un desarrollo rápido usando un entorno integrado como Eclipse. Además no es necesario tener un robot para hacer pruebas ya que se pueden hacer en el simulador. El único problema del simulador es que no tiene en cuenta algunos factores del entorno. Las ruedas del robot no derrapan nunca, la odometría es perfecta y todos los valores de láser están disponibles instantáneamente sin error alguno.

24 Capítulo 4 Integración de los sensores en MaRTE 4.1. Análisis general Actualmente los algoritmos de control desarrollados para el robot (o el simulador del robot) se ejecutan sobre un SO Linux de propósito general. Un algoritmo de navegación bien diseñado no conseguirá mover el robot con la precisión que se desea. Mientras se ejecuta el algoritmo de navegación, el SO realiza diferentes tareas y su planicador dejará ejecutar la navegación si lo cree conveniente. Esto quiere decir que el movimiento del robot está condicionado por la carga y la política de planicación del sistema. En el capítulo 6 se ha demostrado que si se ejecuta una aplicación en Linux para mover el robot y se carga el sistema con otros procesos el robot se mueve de forma descontrolada. Si se ha desarrollado un buen algoritmo de navegación y se necesita un sistema able y robusto se deberá realizar una aplicación en MaRTE similar a la que podemos ver en el apartado 6.1. El ordenador del robot está dedicado únicamente a leer los sensores, procesar los datos (navegación) y mandar comandos a los motores. La planicación se realiza antes de lanzar la aplicación. Un SO como MaRTE y un estudio de planicabilidad garantizan que todas las tareas que forman la aplicación siempre se van a ejecutar dentro de sus plazos Diseño arquitectural En la gura 3.2 se pueden observar los dispositivos que componen el sistema y sus conexiones. Se han desarrollado los diferentes drivers que permiten la interacción del ordenador con: El microcontrolador. Driver de comunicación a través de la línea serie entre microcontrolador y ordenador. El láser. Driver de comunicación a través de la línea serie entre láser y ordenador. El GPS. Driver de comunicación a través de la línea serie entre GPS y ordenador. La tarjeta inalámbrica. Driver de comunicación a través de la conexión PCI 104 con el adaptador PCI/PCMCIA. Y a través de ésta se realiza la comunicación con la tarjeta inalámbrica PCMCIA. 24

25 4. Integración de los sensores en MaRTE 25 A continuación se explican las fases de análisis, diseño, implementación y pruebas por las que ha evolucionado el proyecto Microcontrolador y P2OS Análisis Como punto de partida es necesario conocer qué características tiene el microcontrolador y qué tarea de control hay que realizar para que el robot y el micro se comuniquen perfectamente. Para ello se estudió en profundidad el manual disponible en [11] donde se especican las características del micro y se dene desde el sistema de conexión para cada elemento hasta los diferentes comandos que se pueden enviar. En el anexo C hay disponible una versión resumida del manual en castellano. Varios de los sensores están conectados al microcontrolador que a su vez está conectado con el ordenador principal del robot a través de la línea serie RS232. Este micro se comunica mediante el P2OS con los motores, el sistema de odometría, los sensores sonar, la brújula, etc. El P2OS tiene una estructura cliente/servidor. El servidor está en el micro esperando los comandos que el cliente (el ordenador) le va mandando. Se pueden diferenciar dos tipos de paquetes de comunicación entre el micro y el ordenador: Paquetes SIP: Son Paquetes de Información del Servidor que cada 100 ms envía el microcontrolador al ordenador. Este paquete contiene información actualizada sobre todos los dispositivos conectados al micro. Esto signica que cada 100 ms el ordenador tiene actualizada correctamente la información de odometría, sonar, orientación, etc. Paquetes de Comando: Son paquetes diferentes a los anteriores. En este caso van en la dirección contraria, el ordenador envía una orden al micro para que realice un nuevo comando. Por ejemplo modicar el valor de la velocidad, la conguración de un sensor, etc. El driver desarrollado para el micro debe ser capaz de enviarle comandos correctamente, y de recibir la información que el micro envía periódicamente. Es decir, el driver implementa la parte cliente del P2OS Diseño El primer paso fue estudiar como estaba implementado el controlador del micro en la plataforma Player que se usa en el robot. En términos generales Player dispone de un nivel de usuario y un nivel hardware que se comunican pasándose mensajes en las dos direcciones. En el nivel hardware se crea un thread por cada dispositivo que se instancia en el robot. Si usamos tres dispositivos (microcontrolador, láser y GPS) se creará un thread

26 para cada uno. Cada thread atiende los datos que se envían/reciben para cada dispositivo y actualiza una serie de variables compartidas entre ambos niveles (datos de posición, velocidad, orientación, etc). Además intercambia mensajes con el nivel superior. El nivel de usuario tiene una visión abstracta del hardware. Es un nuevo proceso que mediante una serie de funciones que componen el API de Player, obtiene los datos compartidos y va generando los diferentes tipos de mensajes que comunican con el nivel hardware. Esta forma de comunicación con los dispositivos es incompatible con las características del tiempo real. El usuario no puede tomar decisiones sobre las prioridades de los diferentes threads que se crean. Todos los threads entran en conicto entre ellos y con los demás procesos del sistema. La alternativa al sistema de Player fue reutilizar una parte del driver que implementaba el cliente del P2OS y rediseñar la forma de creación y comunicación de las diferentes tareas. Las funciones que construyen, envían y reciben comandos para el microcontrolador se mantuvieron modicando algunas llamadas al sistema. Para todas estas funciones que estaban escritas en C, se elaboró una interfaz para poder utilizar toda la exibilidad de las tareas Ada. En el anexo G se puede ver como se realiza la interfaz entre C y Ada, y en el anexo F el conjunto de funciones que el usuario tiene a su disposición. Se proporcionan funciones que interaccionan directamente con el hardware y funciones que obtienen datos compartidos por las tareas. Los dos niveles de Player ahora se convierten en un sólo nivel. El usuario deberá crear las tareas que interaccionan con el hardware y las que se comunican mediante los datos compartidos. Ahora el control total de las tareas la tiene el usuario. Las funciones que realmente interaccionan con el hardware están escritas en C. Como la comunicación entre tareas no se puede implementar con objetos protegidos Ada se implementaron con mutexes de C. En este caso tienen la característica de poder ser inicializados con un protocolo de planicación de techo de prioridad inmediato modicando los atributos del mutex con el valor PTHREAD_PRIO_INHERIT y con la prioridad deseada. En cualquier caso el usuario puede modicarlo para usar cualquiera de los protocolos disponibles. Cuando una tarea quiere acceder a información compartida, debe realizar un bloqueo (función de usuario lockp2os), ejecutar las funciones correspondientes sobre los datos compartidos y volver a liberar el mutex (unlockp2os). El tiempo de cómputo que transcurre desde que se captura el mutex hasta que se libera supone un tiempo de bloqueo para otras tareas que también quieran acceder a los datos. Esta forma de trabajar se ha utilizado también en el láser y en el GPS. En la gura 4.3 se puede ver una explicación gráca para el caso del láser. En la gura 4.1 se muestran las fases y tareas que están involucradas en la comunicación entre el robot y el micro. Cuando encendemos el robot, el micro se queda a

27 4. Integración de los sensores en MaRTE 27 Microcontrolador Ordenador del robot + MaRTE Comunicación + Servidor P2OS 1 Escucha peticiones del cliente 1 Cliente P2OS Conecta al servidor SYNC0 SYNC1 SYNC2 2 Envía SIP cada 100 ms 2' Recibe comandos y actúa T1 Recibe SIP cada 100 ms y actualiza variable compartida Conexión Dos tareas concurrentes 2 2' T2 Envía comandos Figura 4.1: Diseño del driver P2OS la espera para recibir (1) una serie de comandos de conexión (comandos SYNC) que el cliente deberá mandar. Cuando el micro tiene un cliente conectado, realiza dos tareas automáticamente. Por un lado (2) envía un paquete SIP al cliente cada 100ms y por otro (2') espera la recepción de comandos del cliente para actuar sobre los motores. En el otro lado, el cliente lo forma el ordenador del robot controlado por MaRTE. Cuando la aplicación comienza manda los comandos de conexión (1) y el siguiente paso es lanzar dos tareas diferentes. La primera tarea (2) realiza la lectura de los paquetes SIP que envía el servidor (esto se hace cada 100ms). La segunda tarea (2') es la encargada de enviar los comandos al robot. En esta segunda tarea será donde se ejecute por ejemplo un algoritmo de navegación Láser SICK LMS Análisis El láser es el dispositivo que permite al robot obtener información sobre el entorno. Cada cierto tiempo este dispositivo envía al ordenador un conjunto de valores que representan la distancia que separa el sensor de los objetos que hay delante suyo. De forma similar al microcontrolador, el ordenador se comunica con el láser a través de la línea serie intercambiando datos. En el anexo D se detalla en profundidad el funcionamiento del dispositivo y los diferentes comandos que se envían para congurarlo y comenzar la lectura de datos. Hay varias conguraciones posibles para usar el láser. Para realizar la conguración se han de enviar diferentes comandos de una forma determinada. En primer lugar se puede congurar la velocidad de conexión con el dispositivo (9600, y bytes por se-

28 Rango angular Resolución angular Número de puntos 0º.. 100º 1º 101 0º.. 100º 0.5º 201 0º.. 100º 0.25º 401 0º.. 180º 1º 181 0º.. 180º 0.5º 361 Cuadro 4.1: Opciones de conguración del láser gundo). Es posible obtener las distancias en un rango de 100 o ó 180 o y con una precisión de 1 o, 0.5 o ó 0.25 o obteniéndose un número de valores de distancias diferente en cada caso. Por último se puede congurar la precisión de las distancias que se recogen en cm o en mm. Las fases de comunicación con el dispositivo son muy simples: 1. Enviar comandos de conguración. 2. Enviar comando Start para empezar a recibir datos de forma continua. 3. Enviar comando Stop y Reset para terminar y dejar el dispositivo con los valores por defecto. Cuantos más puntos se obtengan del láser, se podrá conocer mejor el entorno pero la frecuencia de muestreo será menor. Los diferentes modos de conguración del láser se pueden consultar en la tabla 4.1. Todos los datos se envían a través de la línea serie a una velocidad determinada limitando la capacidad de transmisión. El driver del láser debía ser capaz de implementar la comunicación entre el dispositivo y el robot a la perfección. Además se debían de aportar soluciones para poder usarlo dentro del marco del tiempo real Diseño La cantidad de información (bytes) que el sensor manda al robot es muy grande y lo hace a una frecuencia elevada. Esto provoca que se generen un gran número de interrupciones a través de la línea serie. Se estudió la gestión de interrupciones en el puerto serie en MaRTE ya que a tasas de envío altas se perdían interrupciones. Esto es un error grave que había que arreglar y con este objetivo se estudió como estaba implementada la línea serie. Los problemas de la línea serie En la gura 4.2 se pueden observar los elementos más importantes que componen el driver de la línea serie en MaRTE. El problema que planteaba este diseño es que la rutina de interrupción se ejecuta correctamente dependiendo de la velocidad del procesador. El procesador del robot es más lento (800 MHz) que el procesador que había usado la persona que desarrolló este driver y no lo tuvo en consideración. El primer problema

29 4. Integración de los sensores en MaRTE 29 INT RS232 Rutina de interrupción Serial_port_driver REGISTRO ENTRADA REGISTRO SALIDA BUFER DE ENTRADA BUFER DE SALIDA PROGRAMA DE USUARIO Read write (bloqueante / nobloqueante) Figura 4.2: Esquema de funcionamiento del puerto serie. importante fue que el búfer circular (entrada y salida) tan solo tenía espacio para 1 Byte. Este problema se solucionó modicando la denición del búfer ampliando la capacidad. El segundo problema que hubo que solucionar fue que mientras se estaba atendiendo a una interrupción, llegaban nuevas interrupciones que más tarde no eran atendidas. Para ello se modicó el manejador de la interrupción para que antes de salir comprobara si habían nuevos datos en el registro del RS232. De esta forma se consiguió que la línea serie funcionara con el láser SICK LMS para las velocidades de 9600bps y 19200bps. El problema es que este manejador presenta una condición de carrera y un aumento en la frecuencia de recepción de interrupciones provoca que de nuevo no dé tiempo al driver a atender a todas las interrupciones correctamente. Con la siguiente velocidad posible (38400bps) el driver volvía a fallar. La solución más sencilla es ampliar la velocidad del procesador. Sin embargo en Linux, con la misma velocidad y el mismo procesador todo funciona correctamente. La explicación es que, o bien el código del driver de la línea serie no está tan optimizado como para Linux, o directamente el driver está mal implementado y con velocidades altas no funciona. El desarrollo del driver se realizó siguiendo el manual del dispositivo. Una vez corregida la transmisión de datos a través de la línea serie en MaRTE, se implementaron los diferentes comandos que hay que enviar al láser, así como todas las funciones necesarias para una comunicación correcta entre el ordenador y el dispositivo. El láser tiene unas fases de ejecución determinadas y deja poco margen a la imaginación. La única forma para conseguir que funcione correctamente es traducir a código el manual. Sin embargo, sí que se realizó una modicación adicional para poder usar el láser correctamente en tiempo real. Lectura y reducción de bloqueos Cuando realizamos una lectura del dispositivo láser rellenamos un búfer de distancias de diferente dimensión dependiendo del modo con el que lo hayamos inicializado, y por lo tanto tardaremos más o menos tiempo en leerlo. Por otro lado cuando tenemos una aplica-

30 Tarea que atualiza el búfer del láser wait (mutex) Escritura completa variable protegida signal (mutex) valores1 valores2 Tarea utiliza el láser wait (mutex) Lectura completa variable protegida Estructura con las signal (mutex) medidas del láser duplicada para minimizar bloqueos. Figura 4.3: Doble búfer del láser para minimizar bloqueos. ción y queremos consultar el láser entero iremos leyendo el búfer de elemento en elemento. Puede suceder que cuando usemos el láser desde una tarea leamos el búfer mientras que la tarea que actualiza el mismo búfer también este escribiendo, dejando un dato incoherente. La gura 4.3 muestra la solución que se ha dado a este problema. Para evitar leer un dato incoherente se tiene que proteger el búfer en el que se esta escribiendo/ leyendo en cada momento. Se implementó un objeto protegido mediante un mutex de la misma forma que en el driver del microcontrolador. Además para evitar tener que esperar a que una de las dos operaciones acaben completamente se duplicó el búfer. De esta forma cuando una tarea actualiza el búfer, la tarea que lo lee puede continuar sin bloquearse. Cuando el búfer esté actualizado y la otra tarea ya no esté leyendo (ha liberado el bloqueo) se intercambiarán los vectores y se podrá continuar. En el apartado 6.1 se pueden ver los valores de los bloqueos entre tareas y objetos protegidos para una aplicación típica Comunicación inalámbrica Análisis Este driver se implementó para poder comunicar el robot con otras máquinas. Para ello MaRTE OS dispone de un controlador para una tarjeta Conceptronics de tipo PCI. Por problemas de tamaño, es imposible instalar una tarjeta de este tipo en el robot. Lo que si se podía hacer es poner un adaptador PCMCIA/PCI que permite instalar una tarjeta Conceptronics de tipo PCMCIA. Debido a que las tarjetas son del mismo fabricante y de modelos muy similares el driver es exactamente el mismo para ambas tarjetas. El problema surgió debido a que no existía en MaRTE el driver para comunicarse con la tarjeta mediante PCMCIA. Desarrolladores de MaRTE OS en la Universidad de Cantabria estudiaron el problema y proporcionaron el driver que solucionaba los problemas anteriores.

31 4. Integración de los sensores en MaRTE 31 El ojetivo a partir de aquí fue realizar comunicaciones en tiempo real usando las funciones que proporcionaba este driver. El problema es que en un sistema distribuido (con varios robots o máquinas comunicándose), la tarea que monitorea y controla diferentes aspectos del entorno está dividida entre los nodos. Debido a los retardos impredecibles de la comunicación, los diferentes nodos pueden obtener nueva información en distintos instantes, causando que algunos nodos tengan una visión incorrecta del entorno. Estos actuarán inconsistentemente y fuera de control. Por lo tanto en un sistema distribuido de tiempo real se necesita garantizar el tiempo que tarda en enviarse un mensaje para permitir una planicación en tiempo real. En consecuencia cada evento o fase en un protocolo de comunicación debe tener una duración acotada. Sin embargo, los protocolos de comunicación inalámbrica existentes como no aportan garantías temporales en transmisiones de red debido a interferencia entre paquetes, retransmisiones y problemas de bloqueos Diseño Con el driver de la tarjeta funcionando se disponía de la tecnología suciente para enviar una trama de bytes desde una máquina a otra. Es decir, mediante las funciones send y receive que proporciona el driver era posible enviar datos desde una dirección MAC a otra. La mejor alternativa para poder conseguir una comunicación dentro del marco de tiempo real fue adaptar el protocolo RT-WMP para comunicaciones en tiempo real, que esta siendo desarrollando en la Universidad de Zaragoza a MaRTE OS. El protocolo RT-WMP funciona en tres fases. Fase de arbitrio de la prioridad, fase de autorización de transmisión y fase de transmisión del mensaje. Durante la fase de arbitrio de la prioridad, los nodos se ponen de acuerdo sobre cual de ellos tiene el mensaje de más prioridad en la red en ese momento. Después, en la fase de autorización de transmisión, se envía una autorización para transmitir al nodo que tiene el mensaje de mayor prioridad. Finalmente, en la fase de transmisión del mensaje, éste nodo envía el mensaje al nodo de destino. RT-WMP funciona mediante paso de testigo sobre un conjunto de nodos acotado. Cada nodo tiene su propia cola de mensajes y cada cola de mensajes tiene una prioridad (de 1 a 255 niveles). Cada mensaje tiene una dirección de destino, que es uno de los nodos de la red. Cuando un nodo recibe un token, éste busca en su cola el mensaje con mayor prioridad y, sí el valor de la prioridad del mensaje es mayor que el valor en el correspondiente campo del token, el nodo cambia el valor de la estación con mayor prioridad y el valor de la prioridad del mensaje en el campo del token y lo envía a otro nodo. El último nodo que recibe el toquen comprueba cual es el nodo que tiene el mensaje de mayor prioridad y, por lo tanto, cual es el nodo autorizado a enviar el mensaje. Entonces, manda un mensaje de autorización al nodo que tiene el mensaje de mayor prioridad. Finalmente este mensaje es enviado a través de un camino multi-salto. Cuando el mensaje llega al destino, el bucle se

32 reinicia. Los nodos saben sólo el número de nodos de la red. Cada nodo esta identicado con un número natural entre 0 y N que es su dirección en la red WMP. Las conrmaciones (ACK) son implícitas. Sí el nodo A envía un token al nodo B, y el nodo B lo envía al nodo C, el nodo A interpreta que éste pasa como un reconocimiento implícito de que el token fue recibido correctamente por el nodo B. Todas las capas de bajo nivel del protocolo envían sus tramas mediante broadcast. No hay ltrado y todos los nodos reciben la misma trama, lo cual es obligatorio para que el protocolo funcione correctamente. En [7] se puede obtener más información sobre el funcionamiento de RT-WMP. El protocolo hasta ahora sólo funcionaba en Linux, y está escrito en C y C++. Gracias a la exibilidad y modularidad con la que está implementado, adaptarlo a MaRTE no fue una tarea difícil. En primer lugar se denió la mejor forma de hacer el protocolo multiplataforma. Mediante cheros de denición se puede compilar el código directamente para la plataforma deseada. Para conseguir que funcionara en MaRTE fue necesario adaptar las llamadas al sistema del protocolo (para Linux) a sus equivalentes llamadas para MaRTE. En el capítulo 6 se puede ver una de las aplicaciones realizadas usando comunicaciones inalámbricas. Para este protocolo no se ha realizado un interfaz Ada debido a la escasez de tiempo. El protocolo genera diferentes threads que controla el SO pero no el usuario. En un futuro este interfaz permitirá lanzar el protocolo utilizando tareas de Ada GPS Novatel Análisis Este dispositivo tiene la misión de leer la posición, que es devuelta en coordenadas geográcas (longitud/latitud). Por lo tanto, también se encarga de pasarlas a coordenadas cartesianas en el sistema UTM (X,Y,h) donde X es positiva hacia el Este de la cuadrícula e Y hacia el Norte y h es el uso o zona UTM (UTM zone). El origen de este sistema de coordenadas es para la X el meridiano central del huso UTM en el que está el robot, y para la Y el ecuador. El problema inherente que trae consigo el uso de UTM es que el robot cambie de huso. Lo que ocurre en este caso es que el origen del sistema de coordenadas para la coordenada X también cambia y por lo tanto también cambiará la idea de posición que tiene el robot. Para evitar esto, se guarda el primer huso UTM de la primera lectura que se ha tomado del GPS y a partir de él se calculan las posiciones en coordenadas UTM. Para más información del sistema GPS y de la proyección UTM ver el anexo H en [10].

33 4. Integración de los sensores en MaRTE Diseño La comunicación con el dispositivo GPS se llevó a cabo siguiendo la misma idea que para el microcontrolador. En primer lugar se estudió el manual del dispositivo [12] y cómo estaba implementado el driver para Player. Las funcionalidades básicas que interaccionan a nivel hardware pudieron ser reutilizadas con algunas modicaciones. Para poder permitir un uso de tiempo real correcto también se creó otro objeto protegido mediante mutex exactamente igual que el del microcontrolador. El sistema GPS es de gran utilidad para poder corregir la posición (la odometría) del robot y disponer de una buena localización. El dispositivo envía cada segundo un nuevo dato con las coordenadas de la posición global Implementación y pruebas Esta ha sido la parte más laboriosa del proyecto ya que la implementación de los drivers debía ser a bajo nivel en lenguaje C. Básicamente se tuvo que realizar una traducción de los manuales a dicho lenguaje cumpliendo estrictamente con cada byte enviado y recibido. Además para poder probar cada nuevo avance o mejora era necesario ejecutar el código en el robot, haciendo mucho más pesado el trabajo. Pero es así como debe de realizarse la programación de un sistema empotrado. Cuando se completó la implementación y testeo de las funciones de cada driver en C, se realizó un interfaz entre C y Ada para poder usar dichas funciones desde un programa Ada. Esto posibilita realizar una mejor planicación de las tareas ya que para este tipo de aplicaciones, el lenguaje Ada es sin duda la mejor herramienta de desarrollo. Se puede consultar la conversión entre ambos lenguajes y tipos en el anexo G. Se ha creado por tanto un nuevo conjunto de funciones o API para el desarrollo de aplicaciones robóticas bajo el control de MaRTE OS tanto en Ada como en C disponible en el anexo F. Es importante resaltar que todas las funciones desarrolladas fueron fuertemente testeadas tanto individualmente como en conjunto con diferentes aplicaciones como se puede ver en el capítulo 6. Como resultado nal se dispone de un entorno de control para el robot amplio y robusto.

34 Capítulo 5 Caracterización temporal completa del sistema En un sistema de tiempo real, es completamente necesario denir de forma precisa los tiempos de cómputo de las operaciones que se pueden realizar, así como los periodos de ejecución de las tareas (o sus operaciones) y de los plazos de respuesta si es que existen. Por este motivo, en el momento que se probaron completamente las funciones de los drivers implementados, se midieron los tiempos de cómputo con la máxima precisión posible Medir el tiempo de cómputo en MaRTE Para medir el tiempo de cómputo de una función en MaRTE se han de tomar algunas precauciones. Se puede medir el tiempo inicial y nal de la ejecución de la función y luego restarlos. Pero de esta forma se obtiene el tiempo que está la función en ejecución y no su tiempo de cómputo. Si dicha función no se ejecuta a la máxima prioridad o se suspende en algún momento el planicador de MaRTE es libre de expulsarla mientras se está ejecutando para realizar otras operaciones y más tarde nalizar la primera. Para realizar una medida correcta del cómputo es necesario usar los relojes de ejecución disponibles en MaRTE. En la gura 5.1 se muestra la forma correcta de medir el tiempo de cómputo de una función para los lenguajes C y Ada. De esta forma el tiempo struct timespec ts; //para medir la duracion de la interrupcion clock_gettime(clock_thread_cputime_id, &ts); double t1=ts.tv_nsec; funcion_a_medir(); clock_gettime(clock_thread_cputime_id, &ts); double t2=ts.tv_nsec; printf("%.6lf nseconds elapsed\n", t2-t1); esc: terminar with POSIX; with POSIX_Timers; pragma Elaborate_All (POSIX_Timers); procedure medir is CPU_Time_First : POSIX.Timespec := POSIX.To_Timespec (0.0); CPU_Time_Last : POSIX.Timespec := POSIX.To_Timespec (0.0); begin CPU_Time_First := POSIX_Timers.Get_Time(POSIX_Timers.Clock_Task_Cputime_Id); funcion_a_medir; CPU_Time_Last := POSIX_Timers.Get_Time(POSIX_Timers.Clock_Task_Cputime_Id); put("tiempo = "); put ((POSIX.To_Duration (CPU_Time_Last) - POSIX.To_Duration (CPU_Time_First)) 1000); put_line("ms."); Figura 5.1: Medición del tiempo de cómputo de una función en MaRTE para C y Ada respectivamente. 34

35 5. Caracterización temporal completa del sistema 35 Baud rate interrupciones / Periodo mínimo Utilización segundo (inversa) µs µs µs Cuadro 5.1: Interrupciones generadas por la línea serie. medido corresponde únicamente al tiempo en el que la función que se desea medir ha estado ocupando el procesador. En el anexo F se puede ver el tiempo de cómputo de las funciones desarrolladas para el microcontrolador, el láser y el GPS. Todos han sido medidos usando los relojes de tiempo de ejecución. Debido a que el driver de la tarjeta inalámbrica estuvo disponible varios meses después de comenzar el proyecto, el tiempo de cómputo de las funciones del protocolo RT-WMP no ha podido ser medido completamente. Aunque las pruebas realizadas para la comunicación inalámbrica funcionan correctamente no se ha podido realizar un estudio de planicabilidad completo. Este trabajo será necesario hacerlo si en el futuro se pretende hacer un uso intensivo de la comunicación inalámbrica en el robot Dependencia de la línea serie Otro de los aspectos importantes de este sistema es que los drivers del P2OS, del láser y del GPS funcionan a través de la línea serie. Cada byte que envían estos dispositivos es capturado por MaRTE a través de una interrupción asociada a la línea serie como se muestra en la gura 4.2. En el momento en el que se instancia un dispositivo, por ejemplo el láser, dicha interrupción se ejecutará cada vez que reciba un byte. Se midió el tiempo de cómputo de la interrupción, resultando ser de 29 microsegundos. La frecuencia a la que se ejecutará dicha interrupción dependerá de la conguración de la línea serie. Para cada dispositivo habrá que tener en cuenta estas interrupciones. Una posibilidad es estimar que en el peor caso existe una tarea periódica de tiempo de ejecución 29 microsegundos y con un periodo igual a la separación mínima entre eventos. Esta separación se obtiene a partir de la velocidad a la que se instancia el dispositivo como se puede ver en la tabla 5.1. Si se instancia el P2OS a 9600 y el láser a 19200, sin hacer ninguna operación más habrá una utilización del procesador del 9.72 % y si además se instancia el GPS (9600) dicha utilización será del %. Estos datos son indispensables para poder realizar una planicación correcta de tiempo real. En la gura 5.2 se puede ver la distribución de tareas necesarias para realizar una

36 INT línea serie C=29µs T=833.33µs C=620µs T=100ms Rutina de interrupción linea serie Tarea actualiza P2OS Ejemplo de uso del driver P2OS con tareas a 9600bps C = Cómputo T = Periodo Datos P2OS p2osgetvalues Tarea que usa P2OS C=20ms T=300ms lockp2os unlockp2os Valores de ejemplo Figura 5.2: Ejemplo de tareas con tiempos en MaRTE. aplicación en tiempo real cuando se instancia el driver del microcontrolador. Por un lado se puede ver la rutina de interrupción que se ejecuta por haber instanciado el driver del P2OS. Tendremos que crear una tarea para cada dispositivo que funciona a través de la línea serie para tener en cuenta dicha rutina de interrupción. Por otro lado existirá una tarea de actualización de los datos del P2OS que se ejecutará continuamente a la frecuencia a la que se reciben los paquetes de información del micro. Y por último se crearán las tareas necesarias que usen las funciones del driver para realizar una navegación, visualizar datos del micro, etc. Los valores que se muestran para las tareas de manejo de la interrupción y actualización del P2OS corresponden a sus valores reales. Para la otra tarea será necesario medir el tiempo de cómputo (los de la gura son valores de ejemplo). Como se explicó en el apartado 4.4.2, para acceder a las funciones de los objetos protegidos implementados con mutexes es necesario realizar un bloqueo, leer los datos deseados y quitar el bloqueo. Será el usuario el que deba realizar el bloqueo y el desbloqueo correctamente bajo su responsabilidad. Si no se produce el bloqueo el sistema funcionará pero no tendrá un soporte de tiempo real y los datos pueden ser incoherentes.

37 Capítulo 6 Pruebas realizadas y resultados Después de testear a fondo las funciones que se crearon para poder interaccionar con los drivers, se pasó a realizar diferentes aplicaciones para comprobar que todo funcionaba correctamente Navegación autónoma y tiempo real estricto En primer lugar se adaptó un buen algoritmo de navegación para poder usarlo en MaRTE con las funciones que se han implementado en el proyecto. El algoritmo seleccionado usa el láser para obtener información del entorno y el microcontrolador para leer la odometría y actuar sobre los motores. Cuando empieza la ejecución intenta encontrar algún objeto que se encuentre en movimiento usando el láser. En el momento en el que algún objeto se mueve en su rango de visión, comienza a generar nuevos objetivos hacia los que mueve el robot. Para poder estimar estos nuevos objetivos realiza diferentes cálculos matriciales, entre ellos la estimación de la posición del objeto móvil mediante ltros de Kalman [13]. A todo es este proceso se le denomina traking. Además lleva incorporado un sistema de evitación de obstáculos conocido como ND que computa la mejor dirección de movimiento para un vehículo omnidireccional y circular [14]. Este algoritmo realiza gran cantidad de cálculos y por tanto su ejecución ocupa el procesador durante bastante tiempo. El esquema general del algoritmo se puede ver en 6.1 traking Nuevo objetivo Evitación de obstáculos ND Obstáculos (sensores) Robot Nuevo movimiento Figura 6.1: Algoritmo de navegación adaptado a MaRTE. La aplicación está compuesta por varias tareas que interaccionan entre sí modicando y consultando los objetos protegidos (a partir de ahora servidores), generando nuevos 37

38 movimientos y visualizando algunos datos de interés en una pantalla instalada en el robot. Todo ello bajo el control del tiempo real ofrecido por MaRTE y respaldado por un estudio de tiempos con la política de planicación basada en prioridades estáticas RMS. RMS (Rate Monotonic Scheduling) establece que la asignación de prioridades más altas a las tareas más frecuentes (periodo más corto) es óptima [5]. Este método de planicación requiere que el plazo de respuesta (tiempo que tiene la tarea para llevar a cabo su trabajo) sea igual al periodo, tal y como sucede en nuestro caso Esquema de tareas y cumplimiento de plazos En la gura 6.2 se puede ver el esquema con las tareas, servidores y las diferentes llamadas a los servicios. INT Microcontrolador (9600) INT Láser (19200) C=0.029ms T=0.833ms P=0.833ms Prio HW Rutina de interrupción linea serie C=0.029ms T=0.4196ms P=0.4196ms Prio HW Rutina de interrupción linea serie Tarea actualiza P2OS C=0.062ms T=100ms P=100ms Tarea de navegación C=50ms T=100ms P=100ms Prio 22 Prio 21 Servidor P2OS p2osgetvalues (B=0.062ms) lockp2os p2osgetxpos p2osgetypos p2osgetangle p2osgetxspeed p2osgetyawspeed unlockp2os Prio 22 B= ms Tarea Visualización Prio 20 C=12ms T=100ms P=100ms Tarea actualiza Láser Servidor Láser locklaser laserazo 361veces GetCounLaser unlocklaser Prio 21 B=1.1226ms C=1.867ms T=397.15ms P=397.15ms Prio 19 readlmsvalues (B=0.001ms) C = Cómputo T = Periodo P = Plazo B = Bloqueo Figura 6.2: Esquema de las tareas En la tabla 6.1 se se muestra la información sobre las tareas que se usará para realizar

39 6. Pruebas realizadas y resultados 39 la planicación. Se va a realizar el test de tiempo de nalización y después se calculará la utilización del procesador en esta aplicación.[6] Tarea Periodo = Plazo Cómputo Bloqueo Techo de prioridad Prioridad INT Láser HW INT Micro HW Actualiza P2OS Navegación Visualización Actualiza Láser Servidor P2OS 22 Servidor Láser 21 Test de tiempo de nalización Cuadro 6.1: Información sobre las tareas. En esta aplicación las tareas se comunican entre sí a través de los servidores que guardan los valores correctos del micro y del láser. Para poder realizar una planicación correcta, se debe estudiar cómo se verán afectadas las prioridades de las tareas al usar los servicios (funciones) que ofrecen dichos servidores. Se decidió usar un protocolo de techo de prioridad inmediato, que establece que una tarea que acceda a un recuso hereda inmediatamente el techo de prioridad del servidor. Este protocolo lo proporciona MaRTE y es sencillo de comprender. Para realizar el análisis de cumplimiento de plazos hay que obtener en primer lugar los tiempos de ejecución de peor caso tanto de las tareas como de los diferentes servicios que ofrece cada servidor. Estos son los bloqueos entre tareas ejecutándose con un protocolo de techo de prioridad inmediato: Bloqueo de las rutinas de interrupción: Ambas tareas se ejecutan a prioridad hardware (prioridad establecida por MaRTE). Como se ejecutan a la misma prioridad habrá que tener en cuenta que cualquiera de las dos tareas puede retrasar a la otra. Para tener esto en cuenta cada tarea tendrá como termino de expulsión a la otra. Bloqueo de la tarea que actualiza P2OS: Seleccionamos los servidores de prioridad mayor o igual que la tarea que actualiza p2os. Seleccionamos las tareas de menor prioridad y buscamos el servicio más largo que es llamado por una tarea de menor prioridad en alguno de los servidores anteriores. En este caso la tarea navegación llama a las funciones entre lockp2os y unlockp2os creando un bloqueo de ms. Bloqueo de la tarea navegación: De la misma forma calculamos el bloqueo para esta tarea. En este caso el servicio más largo es utilizar las funciones entre locklaser, unlocklaser, llamado por la tarea visualización. Produce un bloqueo de 1.226ms.

40 Bloqueo de la tarea visualización: Esta tarea es bloqueada durante tan solo 0.001ms por la tarea actualiza láser con el servicio readlmsvalues que tan sólo bloquea y desbloquea el mutex para cambiar el valor de la variable que determina el búfer de lectura escritura dentro del driver del láser. Bloqueo de la tarea actualiza láser: No existen tareas de menor prioridad así que la tarea no será bloqueada. A continuación comprobaremos el cumplimiento de plazos de las tareas calculando el trabajo requerido al procesador en los plazos de respuesta de cada tarea. Tarea INT láser: W (D i ) = j<i D i P j C j + C i + B i D i (6.1) W (D 0 ) = j<0 D 0 P j C j + C 0 + B 0 = 0, , = 0,058 < 0,4196 Tarea INT P2os: W (D 1 ) = j<1 D 1 C j + C 1 + B 1 = 0,833 0, , = 0,058 < 0,833 P j 0,4196 Tarea actualiza P2OS: W (D 2 ) = j<2 D 2 C j +C 2 +B 2 = ,029+ P j 0,4196 0,833 0,029+0,062+0,0218 = 10,518 < 100 Tarea navegación: W (D 3 ) = j<3 D 3 C j + C 3 + B 3 = , , P j 0,4196 0, , ,122 = 61,654 < 200 Tarea visualización: W (D 4 ) = j<4 D 4 C j + C 4 + B 4 = , , P j 0,4196 0, , ,867 = 134,191 < Tarea actualiza láser: W (D 5 ) = j<5 D 5 C j + C 5 + B 5 = 397,15 0, ,15 0, ,15 P j 0,4196 0,

41 6. Pruebas realizadas y resultados 41 0, , , , = 267,873 < 397, Se puede observar que todas las tareas nalizan antes de su plazo de respuesta y por lo tanto el test de nalización se supera sin problemas. Utilización del procesador La utilización del procesador (U) para n tareas con prioridades asignadas en orden de frecuencia, se calcula con la siguiente expresión: U(n) = n i=1 C i P i (6.2) Tras realizar los cálculos correspondientes la utilización total es del % para las 6 tareas de la aplicación. El resto del procesador puede ser usado por tareas con menor prioridad sin problemas Comunicaciones en tiempo real Para demostrar que la comunicación inalámbrica del robot funcionaba correctamente se desarrolló la siguiente aplicación. En la gura 6.3 se puede observar un esquema de los elementos que componen la aplicación. Por un lado se dispone del robot iniciado con MaRTE constituyendo un nodo de la red RT-WMP (nodo 0). Cualquier otro ordenador de la sala se puede iniciar con MaRTE (nodo 1) para que haga de estación de control del robot. Se ha realizado una aplicación que permite: Manejar el robot desde la estación de control mediante el teclado. Visualizar en la estación de control los datos más importantes que están disponibles en el robot. Con esta aplicación se pretende poner de maniesto que es posible realizar el control del robot desde un ordenador y mandar los comandos pertinentes al robot. El protocolo sobre el que se ejecuta la aplicación (RT-WMP) es un protocolo determinista que tiene todos los tiempos de envío y recepción acotados. La comunicación es determinista y las aplicaciones que se ejecutan sobre el ordenador y el robot también lo son. Este es sólo un ejemplo sencillo de lo que se puede conseguir utilizando los elementos que se han desarrollado en este proyecto. Se establecen las bases para investigar en aplicaciones multi-agente. Por ejemplo con estos recursos se podrían desarrollar aplicaciones en las que un conjunto de robots comparten información para ampliar o mejorar su conocimiento del entorno. Si uno de los robots dispone de una cámara y obtiene información importante puede compartirla con los robots que estén a su alrededor. Si un equipo de robots están realizando una misión en la cual deben moverse unos cerca de otros y uno de ellos dispone de GPS puede informar

42 Estación de control Robot + + Visualiza datos Da órdenes Ejecuta órdenes Envía datos & & RT-WMP rot = x = y = ang = 0.2 trans = 0.1 Posición Velocidad Movimiento q: + vtrans a: - vtrans w: + vrot s: - vrot esc: terminar Láser Odometría Teclado + Figura 6.3: Navegación del robot a través de comunicación inalámbrica y control. al resto de la posición en la que están. Estos son sólo algunos ejemplos de las posibilidades que ofrece un buen sistema de comunicación, y la importancia de hacerlo con restricciones de tiempo real para aplicaciones de control Resultados Hasta ahora todo el trabajo que se había realizado sobre los robots se había hecho sobre Linux utilizando Player. Los robots ejecutan los nuevos algoritmos que se van desarrollando sin problemas aparentes. Es complicado convencer y demostrar a alguien que este trabajando con los robots como se ha hecho hasta ahora de que trabajar con MaRTE es una opción mucho mejor. El problema es que los robots se usan con la nalidad de comprobar si un tipo de aplicación se ha implementado correctamente y poco más. Los robots hasta ahora no se han usado teniendo en mente conceptos como robustez, determinismo, tolerancia a fallos o rendimiento. Tras este proyecto todos los dispositivos que se han desarrollado funcionan perfectamente en el robot. La persona que desee realizar una aplicación en MaRTE tiene a su disposición un conjunto de funciones prácticamente idénticas a las que proporciona Player para controlar el robot. Existen además otras funciones que se deben conocer y usar para que las tareas funcionen correctamente en tiempo real. Para poder ver en que situaciones MaRTE OS permite controlar mejor al robot que Linux, se realizaron una serie de experimentos. El robot debía moverse en línea recta a una distancia de 4 metros con diferentes niveles de carga en el sistema y a diferentes velocidades. Se desarrolló una aplicación para Linux y otra para MaRTE que realizaban el mismo movimiento. Con esta prueba se pretendía observar si el robot se comportaría igual en SO diferentes. Los resultados se muestran en la tabla 6.2.

43 6. Pruebas realizadas y resultados 43 Prueba realizada Velocidad Distancia recorrida (cm) Error (%) Linux 0.2 m/s MaRTE 0.2 m/s Linux 0.4 m/s MaRTE 0.4 m/s Linux con carga 0.2 m/s MaRTE con carga 0.2 m/s Cuadro 6.2: Resultados obtenidos. Pruebas sin carga en el sistema En la primera prueba MaRTE únicamente estaba ejecutando las tareas de la aplicación que movía el robot cuatro metros hacia delante. Sin embargo en Linux, al existir otros threads en ejecución, la aplicación que movía al robot no disponía del procesador en los instantes precisos. Cuando el robot llegaba a los cuatro metros, no se paraba y seguía andando un poco más. La aplicación tiene que obtener el procesador para leer el valor de la distancia recorrida, comprobar que es 4 metros y volver a pedir el procesador para decirle al microcontrolador que tiene que parar las ruedas. Todo ese tiempo que transcurre desde que el robot llega al objetivo y el microcontrolador recibe la orden, el robot sigue moviéndose a una velocidad determinada. Cuanto mayor sea la velocidad, mayor será el error que comete. Pruebas con carga en el sistema La siguiente prueba se realizó para demostrar que realmente la carga del sistema estaba provocando los errores que se producían en Linux. Se escribió un pequeño programa llamado computos con un bucle que realizaba muchos cálculos y por tanto requería mucho procesador. Mediante el comando nice -n -10 computos se lanzó en Linux el programa con una prioridad del sistema de -10 (la máxima en este SO es -20). El sistema siguió funcionando y se ejecutó la aplicación que debía mandar al robot a 4 metros. Con el ordenador sobrecargado la aplicación disponía del procesador con mucha menos frecuencia. Esto provocó que desde que llegó a su objetivo hasta que se pararon los motores, pasó mucho más tiempo y por lo tanto se desplazo más distancia. En MaRTE se lanzó la aplicación de la misma forma con otra tarea más que realizaba los mismos calculos que el programa computos. Se le asignó una prioridad menor que a las demás tareas del sistema. El resultado fue el mismo que ejecutar la aplicación sin carga. Esto es debido a que la tarea de menos prioridad no afecta a las demás. En la tabla anterior se pueden observar los errores cometidos en las diferentes pruebas. El robot funciona más o menos bien en Linux cuando no hay sobrecarga, pero si en un momento dado el SO decide realizar otras tareas el robot se ve perjudicado. Esto es un problema muy grave en una aplicación de control.

44 Capítulo 7 Conclusiones y trabajos futuros 7.1. Conclusiones Durante el desarrollo del proyecto se ha estudiado un nuevo SO destinado al control de tiempo real en aplicaciones empotradas. Los robots disponibles en el laboratorio suponen una plataforma de trabajo perfecta para poder comprobar la potencia de un SO de estas características. Se han estudiado diferentes dispositivos y se han programado los drivers que permiten a MaRTE OS comunicarse con ellos. Tras varios meses de trabajo están disponibles diferentes herramientas para trabajar con el robot desde un nuevo punto de vista. Aunque hasta ahora los robots funcionaban más o menos bien, era indispensable disponer de un SO able para poder afrontar nuevas aplicaciones con mayores exigencias. Ahora se dispone de los elementos adecuados para controlar de forma able y determinista los robots. En el capítulo 6 se han visto diferentes aplicaciones que funcionan perfectamente y demuestran que este nuevo sistema cumple los objetivos planteados. Además se ha explicado y demostrado porqué un robot ha de trabajar utilizando un SO de tiempo real como MaRTE. Los resultados ponen de maniesto las limitaciones que tiene un SO de propósito general como Linux. En denitiva un sistema de control para el robot funciona mucho mejor en MaRTE que en Linux. Las herramientas que proporciona este proyecto permiten estudiar mejor diferentes protocolos y sistemas de tiempo real. La posibilidad de estudiar el protocolo de comunicación RT-WMP en un SO de tiempo real permite denir de forma precisa tiempos de funciones, retardos, bloqueos, etc. Este es sólo un ejemplo, pero seguro que en el futuro aparecerán nuevas aplicaciones que utilicen MaRTE. Al haber trabajado con los diferentes dispositivos a tan bajo nivel, se ha podido comprender mejor el funcionamiento del hardware del robot. Conguraciones nuevas no usadas anteriormente o comandos que mejoraban el movimiento han sido sólo algunas de las aportaciones. 44

45 7. Conclusiones y trabajos futuros Dicultades encontradas En primer lugar MaRTE es un SO que actualmente está en desarrollo. Pese a que en la página de distribución de la aplicación se aporta mucha documentación, a veces la documentación existente no es suciente para encontrar la solución a los problemas que van surgiendo. Además al tratarse de un SO relativamente nuevo, aparecieron problemas con algunos drivers. La línea serie es el elemento fundamental mediante el cual se conectan varios de los dispositivos del robot. Cuando se afrontó la programación del láser aparecieron errores debido al uso intensivo que éste hace de la línea serie. Encontrar el fallo y solucionarlo retrasó el proyecto más de un mes. Finalmente la solución que se encontró pasó a formar parte de MaRTE OS. El driver PCMCIA para MaRTE tampoco estaba implementado cuando empezó el proyecto, aunque fue posible usarlo unos meses más tarde. Por último, el desarrollo de aplicaciones empotradas es un campo en el que no estaba experimentado. El hecho de programar en un sitio y probarlo en otro (en este caso un robot) supone invertir muchas horas de trabajo para cargar la aplicación, reiniciar el robot, etc Trabajos futuros En el apartado se explica como se trató de solucionar el problema que presentaba el controlador de la línea serie en MaRTE. Tras varias semanas se pudo solucionar parcialmente consiguiendo usar el láser a una velocidad de 19200bps pero no a la siguiente velocidad de 38400bps. Solucionando este problema, el láser podrá ser usado con todo su potencial. El protocolo de comunicación RT-WMP no dispone de interfaz para poder usarlo desde un programa Ada. La gestión de tareas en Ada es mucho más exible que en C. Sería interesante poder juntar las ventajas de Ada y las posibilidades del protocolo. Hay muchos otros sensores que pueden ser integrados también para MaRTE aumentando así las capacidades del robot. Sería interesante poder usar cámaras desde el punto de vista del tiempo real. Pero lo más importante es que se abre un nuevo campo de investigación para aplicaciones robóticas que hasta ahora no estaba disponible. A partir de ahora ya no sólo se van a poder probar aplicaciones que muevan al robot. Se puede ir más allá y exigir al robot que realice diferentes tareas tal y cómo se ha planicado previamente. El usuario ahora controla totalmente lo que hacen los dispositivos, las tareas y el procesador.

46 Bibliografía [1] Mario Aldea Rivas y Michael González Harbour. MaRTE OS: An Ada Kernel for Real-Time Embedded Applications, [2] Mario Aldea. Planicación de Tareas en Sistemas Operativos de Tiempo Real Estricto para Aplicaciones Empotradas, [3] Daniel Sangorrin. Hello MaRTE using an emulator, tutorial para MaRTE, Mayo 2005 [4] Daniel Sangorrin. Gestión de dispositivos de entrada/salida analógica, digital y por el bus serie I2C, proyecto n de carrera, Febrero 2006 [5] Liu, C.L., Layland, J.W.. Scheduling Algorithms for Multiprogramming in a Hard Real- Time Environment, [6] José Luis Villarroel Salcedo. Sistemas de Tiempo Real, apuntes de la asignatura. [7] Danilo Tardioli y J. L. Villarroel. Real-Time Communications over : RT-WMP, The Fourth IEEE International Conference on Mobile Ad-hoc and Sensor Systems, [8] Francisco Guerreira. Entorno para la instalación y utilización de manejadores de dispositivos en MaRTE OS, proyecto n de carrera, Marzo [9] José Luis Mantecón. Desarrollo de una librería gráca para MaRTE OS, proyecto n de carrera, Diciembre [10] Óscar García Grasa. Robotización de una aplicación de supervisión agrícola, proyecto n de carrera, Junio 2007 [11] Pioneer3 & Pioneer2 H8-Series Operation Manual. Disponible en 46

47 BIBLIOGRAFÍA 47 [12] GPS Novatel Manual, disponible en [13] L. Montesano, J. Minguez y L. Montano. Modeling the Static and the Dynamic Parts of the Environment to Improve Sensor-based Navigation. In Proceedings of the International Conference on Robotics and Automation (ICRA), 2005, Barcelona, España. [14] Minguez J,., Montano L. Nearness Diagram Navigation (ND): Collision Avoidance in Troublesome Scenarios. IEEE Transactions on Robotics and Automation. Vol. 20, No. 1, 2004.

48 Apéndice A Fases del proyecto y diagrama de Gantt A.1. Hitos temporales En Diciembre de 2006 comencé a realizar una beca de colaboración en el laboratorio de Robótica, Percepción y Tiempo Real del Departamento de Informática e Ingeniería de Sistemas (DIIS). Durante la beca estudié y realicé diferentes pruebas de la calidad de la señal en comunicaciones inalámbricas. Además comencé a trabajar con los robots y conocer su funcionamiento. En Abril de 2007 decidí realizar este proyecto. El proyecto une los sistemas de tiempo real, los sistemas empotrados, los sistemas operativos y la robótica. Estas fueron algunas de las razones por las que decidí realizar este proyecto. El primer paso fue estudiar a fondo el sistema operativo MaRTE OS (instalación, método de trabajo, cheros, instalación de drivers). El siguiente paso fue conseguir tener un sistema de desarrollo adecuado para trabajar con el robot y arrancar el sistema operativo a través de la red. En Junio comencé a analizar, diseñar, implementar y probar cada uno de los drivers uno por uno. Comencé por el del micro, cuando funcionó completamente pasé al driver del láser y por último el GPS. Durante toda esta fase fueron apareciendo problemas debido a que un elemento importantísimo de MaRTE OS no funcionaba correctamente; la línea serie. Después de muchos quebraderos de cabeza se encontró el problema y se solucionó. En Septiembre la Universidad de Cantabria envió el driver de PCMCIA. Este elemento era indispensable para poder integrar la tarjeta inalámbrica en el robot. Se consiguió hacer funcionar la tarjeta y además se adaptó el protocolo RT-WMP al sistema operativo MaRTE. Finalmente en Octubre se realizaron diversas aplicaciones usando todos los recursos generados en el proyecto. Navegación autónoma, navegación remota o visualización en Tiempo Real son algunas de las aplicaciones realizadas. Hay que destacar que desde la elección del proyecto comencé a recopilar documentos y redactar los apartados que componen este proyecto. En la gura A.1 se pueden ver con más detalle todas estas tareas avanzando en el tiempo. 48

49 A. Fases del proyecto y diagrama de Gantt 49 A.2. Diagrama de Gantt A continuación se muestra la distribución temporal de las tareas más importantes del proyecto. También se puede observar que algunas de ellas fueron realizadas en paralelo. Comienzo lectura documentos calidad señal Documentación Robot+ Player/Stage Realización pruebas robot Conclusiones calidad señal Comienzo del Proyecto Estudio sistema operativo MaRTE Arranque en red MaRTE Estudio P2OS + implementación + test Estudio Láser + implementación + test Estudio GPS + implementación + test Revisión linea serie + corrección driver MaRTE Actividad Dic Ene Feb Mar Abr May Jun Jul Ago Sep Oct Nov Estudio comunicación inalámbrica + implementación RT- WMP en MaRTE + test Aplicaciones de prueba Documentación Figura A.1: Diagrama de Gantt

50 Apéndice B Estudio sobre sistemas operativos de tiempo real B.1. Arquitectura de un SO de tiempo real En este capítulo se van a exponer las características más importantes de un sistema operativo de tiempo real, comparando diferentes aspectos con los sistemas operativos convencionales. Se tratan temas como las clases de tiempo real dependiendo de la precisión que necesitemos, el rendimiento, ventajas y desventajas. Al nal se presenta un resumen de algunos SO de tiempo real existentes. B.1.1. Arquitectura de un SO de propósito general La memoria física de un computador está dividida entre el espacio reservado para los usuarios (user-space) y el espacio reservado para el kernel (kernel-space). El kernel multitarea es capaz de manejar múltiples aplicaciones de usuarios que ejecutan en el espacio de usuario haciendo creer a cada uno que dispone de todo el espacio de memoria y de todos los recursos hardware. La comunicación entre los programas en el espacio de usuario y el espacio del kernel se realiza a través de las llamadas al sistema. Estas llamadas típicamente lo que hacen es acceder a recursos físicos compartidos. Todos los accesos a los recursos hardware son controlados por el kernel de modo que los programas de usuario no conozcan los detalles físicos de los dispositivos. Las funcionalidades principales de un SO de propósito general son: Gestión de procesos. Planicación de procesos. Gestión de memoria. Interactuar con el Hardware. Servidor de Ficheros. Servidor de Comunicaciones. La funcionalidad principal y requerida para un sistema operativo de tiempo real es proveer de un nivel de servicio adecuado a las aplicaciones que requieran una respuesta 50

51 B. Estudio sobre sistemas operativos de tiempo real 51 en un intervalo de tiempo determinado. La característica principal de un sistema operativo de tiempo real es la respuesta ante eventos internos ó externos, tales como interrupciones hardware externas, interrupciones software internas ó interrupciones de reloj internas, es decir los requerimientos temporales. Una de las medidas de rendimiento de un SO de tiempo real es la latencia, ó tiempo desde que ocurre el evento y éste es tratado. La otra medida es el jitter, ó variaciones en el periodo normal de ocurrencia de eventos periódicos. Todos los sistemas operativos tienden a tener una baja latencia y un bajo jitter, pero los sistemas operativos de tiempo real requieren que esos valores estén determinados y que no dependan de la carga del sistema. B.1.2. Clases de tiempo real Un programa ó un sistema operativo es considerado como de tiempo real, si a pesar de las restricciones de tiempo le permiten trabajar y funcionar correctamente. Se distinguen las siguientes clases: B.1.3. Tiempo real estricto (Hard Real Time): Todas las acciones deben ocurrir dentro del plazo especicado. Tiempo real exible (Soft Real Time): Se pueden perder plazos de vez en cuando. El valor de la respuesta decrece con el tiempo. Tiempo real rme (Firm Real Time): Se pueden perder plazos ocasionalmente. Una respuesta tardía no tiene valor. Características de rendimiento El criterio fundamental de evaluación del rendimiento de un sistema operativo de tiempo real es la latencia y el periodo del jitter ante un evento. Un evento es cualquier tipo de interrupción, tanto interna, como externa. Latencia en un evento. Un evento puede ser tanto una interrupción hardware como una interrupción software. La latencia ante una interrupción hardware es el tiempo desde que se produce la interrupción hasta que se ejecuta la primera instrucción de la rutina de tratamiento. Puede haber retrasos debido al acceso al bus.

52 La latencia ante una interrupción software es el tiempo desde que la señal es generada hasta que la primera instrucción de la tarea es ejecutada. Aquí el valor depende únicamente del acceso a los registros del procesador. B.1.4. Periodo del jitter. El periodo del jitter se reere a las variaciones en el tiempo que experimenta una tarea cuando se ejecuta de manera repetitiva. Arquitectura de un SO de tiempo real El objetivo de un sistema operativo de tiempo real es reducir la latencia y el jitter en las interrupciones, tanto internas como externas, al orden de microsegundos. Es decir, la parte fundamental para convertir un sistema operativo de propósito general en un sistema operativo de tiempo real es el manejo de las interrupciones. El procesamiento de interrupciones en el kernel estándar está divido en 2 tareas. Una tarea que se encarga de leer los datos del dispositivo físico y escribirlos en un búfer, es lo que se conoce como manejador de interrupciones, y una tarea que se encarga de pasar los datos del búfer a otro para que sean accesible por el kernel. Con este esquema, cuando el manejador está ejecutando, todas las interrupciones están inhibidas con el siguiente retardo impredecible en el servicio de otras interrupciones que se puedan haber producido y por tanto en los valores de latencia y jitter. Para conseguir reducir la latencia y el jitter se han desarrollado distintas alternativas que modican el kernel de Linux en este aspecto fundamentalmente. Actualmente hay dos corrientes de diseño: Atención prioritaria en el kernel estándar (Preemptable kernel ) Esta metodología modica el kernel en profundidad de forma que los procesos de kernel ejecuten con máxima prioridad de forma que puedan interrumpir a procesos de menor prioridad en el acceso a los recursos que necesiten. Esta metodología implica cambios en los manejadores de interrupciones para que las interrupciones de alta prioridad no sean bloqueadas por el manejador de interrupciones mientras está manejando otra de menor prioridad. El resultado de esta metodología es una latencia y un jitter del orden de 1 milisegundo en un Pentium a 100 Mhz. A partir de la versión del kernel de Linux se incorpora esta metodología.

53 B. Estudio sobre sistemas operativos de tiempo real 53 Como se puede observar en la gura la tarea de tiempo real está controlada por el planicador del kernel y es una más de las tareas que controla el kernel. Esta tarea hace referencia a los procesos de tiempo real en el espacio de usuario. El planicador sabe que las tareas de tiempo real tiene mayor prioridad que las tareas que no son de tiempo real. Como se puede comprobar esta metodología es adecuada para aplicaciones de audio y vídeo donde el periodo de interrupciones es del orden de 1 milisegundo, pero inadecuado cuando ya hablamos de menos de 1 milisegundo. Benecios y limitaciones de la estrategia de kernel preemptable: Ventajas Desventajas Desarrollo de aplicaciones de tiempo real más fácil El rendimiento no es lo suficientemente bueno para los requerimientos de baja latencia en el rango de microsegundos Protección de memoria disponible Los programas de tiempo real no pueden quebrar el kernel El peor caso de latencia de una interrupción es desconocido ya que no es posible testearlo Cambio fuerte en el código fuente del kernel Acceso completo a los servicios del sistema (TCP/IP, Cada vez que sale una nueva versión del kernel I/O) es necesario un test profundo Threads de POSIX disponibles para las funciones de Para realizar el análisis de funcionamiento son tiempo real necesarios todos los drivers de dispositivos y módulos Soporte de herramientas para facilitar la depuración Rendimiento global del sistema reducido Modicaciones sobre el kernel estándar (Patch) Existen 4 estrategias de modicación del kernel de Linux para proveer capacidades de tiempo real. Tres de ellas implican añadir un segundo kernel (dual) para manejar las tareas de tiempo real y el cuarto implica modicar directamente el código del kernel para añadir características de tiempo real. Benecios y limitaciones de la estrategia de kernel dual:

54 Ventajas Cambios de contexto y latencia de interrupciones muy bajo (5-10 microsegundos) Desventajas Todas las características de tiempo real deben ser implementadas como módulos El kernel estándar de Linux ejecuta como una tarea El desarrollo de aplicaciones de tiempo real es de baja prioridad del microkernel mucho más complicado Capa de abstracción hardware e interrupciones Garantizada una planificación determinística Se debe ser conocedor de Linux en profundidad Interacción entre el kernel y los drivers de los dispositivos Código incorrecto puede provocar el fallo del kernel Más difícil depurar el código Las llamadas al sistemas de Linux no pueden tomar el control y el rendimiento no puede ser garantizado Micro-kernel Esta estrategia añade un segundo kernel que en realidad es una capa interfaz entre el hardware y el kernel estándar, lo que se llama tradicionalmente HALHardware Abstraction Layer. Esta capa, micro-kernel, controla la ejecución de las tareas de tiempo real y ejecuta el kernel estándar como una tarea en background, es decir, el kernel estándar sólo ejecuta cuando no hay tareas de tiempo real pendientes. Una implementación de esta estrategia es ADEOS. Los desarrolladores de este proyecto fueron precisamente los que pusieron el nombre de nano-kernel para diferenciarlo claramente de la estrategia de micro-kernel patentado por Yodaiken. Extensión con un nuevo kernel de acceso a los recursos (Recurso-kernel) Esta estrategia añade un kernel de forma que éste proporciona una puerta de acceso a los recursos, tales como al sistema de cheros, al puerto paralelo, etc, tanto para el kernel estándar como para los procesos de usuario. El recurso kernel no sólo captura las interrupciones sino que proporciona un mecanismo donde los programas de usuario pueden requerir, reservar y garantizarse un porcentaje nito de los recursos como pueden ser de CPU, memoria, etc. Extensiones POSIX de tiempo real añadidas al kernel Esta estrategia consiste en modicar directamente el kernel estándar de Linux para añadir librerías que implementan las extensiones de tiempo real de PO- SIX. El resultado es un kernel conforme al estándar IEEE d. No añade un segundo kernel.

55 B. Estudio sobre sistemas operativos de tiempo real 55 B.1.5. Las modicaciones realizadas al kernel consisten en la implementación de relojes, señales, semáforos, memoria compartida, planicador por prioridades, etc según lo especicado en IEEE d. Existen 2 aproximaciones diferentes para esta estrategia: KURT (The Kansas University Real Time Linux) que únicamente implementa los relojes conforme al estándar IEEE d. TimeSys Linux. Añade al preemptable kernel un planicador de kernel que proporciona una latencia y un jitter menor de 100microsegundos. El parche con el planicador no proporciona una alta resolución en los relojes, que es necesaria para tareas de tiempo real repetitivas. Rendimiento del sistema Si comparamos por ejemplo el kernel estándar con RTLinux podremos observar claramente como existe gran diferencia tanto en la latencia en las interrupciones como en el jitter, siendo mucho menos para el caso de RTLinux y siempre en el orden de 1 a 10 microsegundos para un Pentium a 100Mhz. Si comparamos entre si las distintas estrategias de diseño de un sistema operativo de tiempo real podremos observar que las diferencias no son tan amplias si las comparamos con el kernel estándar. Aplicación Latencia/Jitter SO estándar No Tiempo-Real 100µs a 100ms Linux(>2.5.X) Soft Real-Time 1ms estándar IEEE d Hard Real-Time 10 a 100µs Micro-Kernel Hard Real-Time 1 a 10µs RTOS Kernel Hard Real-Time 1 a 10µs B.2. Algunos de los SO de tiempo real más usados B.2.1. Introducción Vamos a realizar una breve descripción de la arquitectura, licencia y entorno para el cual están diseñados los S.O.T.R. que hemos escogido. Algunas de éstos están en continuo desarrollo y otros por el contrario están un poco estancadas ó denitivamente olvidadas, pero que son nombrados porque nacieron con el objetivo de proporcionar una nueva

56 característica ó una nueva losofía de diseño que otros S.O.T.R. no proporcionaban y que otras han seguido posteriormente. Distribución Licencia Arquitectura ADEOS GNU/GPL Nano-kernel RT-Linux Comercial Micro-kernel MaRTE GNU/GPL Extensiones POSIX VxWorks Comercial Micro-kernel B.2.2. ADEOS (Adaptative Domain Environment Operating Systems) El objetivo de ADEOS es proporcionar un entorno exible para compartir los recursos hardware para múltiples sistemas operativos ó múltiples instancias de un mismo sistema operativo. ADEOS activa múltiples kernels, llamados dominios, que existen simultáneamente sobre el mismo hardware. Ninguno de éstos dominios necesariamente conoce la existencia del resto, pero todos ellos si conocen de la existencia de ADEOS. Un dominio puede ser un SO completo, pero no necesariamente. La licencia de ADEOS es GNU/GPL. La arquitectura de ADEOS es la de kernel dual y más especícamente la llamada Nano-kernel. Dominios y Pipeline. Para permitir que las interrupciones y los eventos del sistema sean repartidos para compartir por los múltiples kernels (normalmente SO completos), ADEOS dene lo que ha llamado abstractamente "dominio". Un dominio es un componente software del kernel base al cuál ADEOS puede noticar: Las interrupciones hardware. Llamadas al sistema de las aplicaciones Linux. Eventos del sistema lanzados por el kernel de Linux. Otros eventos que personalicemos nosotros. Un dominio puede ser accesible como un módulo dinámico del kernel, ó como uno estático formando parte de una imagen del kernel, no produciendo ningún tipo de incidencia en el comportamiento de ADEOS. ADEOS también puede asegurar que los eventos sean disparados en el orden correcto para los distintos dominios denidos, gracias a ello, es posible proporcionar determinismo. Esto nos permite asignar a cada dominio una prioridad estática. El valor de esta prioridad

57 B. Estudio sobre sistemas operativos de tiempo real 57 determina el orden en que los eventos son tratados por los dominios. Todos los dominios son encolados de acuerdo a sus respectivas prioridades, formando un pipeline de forma abstracta, que es el que usa ADEOS para manejar el ujo de eventos desde el más prioritario hacia el menos prioritario. Los eventos de entrada son encauzados a la cabecera del pipeline (dominio más prioritario) y progresan hacia la cola (dominio menos prioritario). El código del kernel de Linux es enteramente el sólo un dominio especial predenido, que es creado por ADEOS en las primeras etapas de carga de Linux. Este dominio inicial normalmente hace referencia al dominio "root"hasta que la infraestructura proporciona lo suciente para cargar el resto de dominios dinámicamente (ej. el módulo cargador del kernel). Modo de Trabajo. ADEOS controla todas las interrupciones, los traps de la CPU y las excepciones del nivel hardware, ya que reprograma el software del manejador. De hecho, ADEOS actualmente reemplaza los manejadores instalados anteriormente por Linux durante el arranque por los suyos propios para las correspondientes interrupciones y eventos. En la plataforma x86, se hace simplemente cambiando el descriptor de interrupción de la tabla. En cualquier momento dada una CPU con ADEOS activado, un dominio puede estar: Ejecutándose. Interrumpido por un dominio más prioritario durante el procesamiento de una interrupción/ evento de entrada mientras el estaba procesando un evento pendiente. Voluntariamente autosuspendido, después de que todas las interrupciones/eventos hayan sido procesados. Cuando un dominio ha nalizado de procesar una interrupción/evento que ha recibido, llama a un servicio especial de ADEOS (adeos_suspend_domain()) el cual provoca que se pase la interrupción/ evento al siguiente dominio del pipeline y así sucesivamente, realizándose un ciclo del más prioritario al menos prioritario. Hay que destacar que ADEOS reanuda un dominio sólo si tiene que procesar una interrupción/evento ó si ocurre que ha sido interrumpido por un dominio más prioritario que ha recibido alguna interrupción/ evento para procesar, en otras palabras, no se produce intercambio entre dos dominios a menos que haya trabajo pendiente para alguno de ellos. Cuando una interrupción ocurre en un sistema ocioso, ADEOS despierta al dominio más prioritario interesado en ella y el ciclo de proceso del pipeline comienza de nuevo. ¾Por qué puedes necesitar ADEOS? Porque necesitas controlar determinísticamente el ujo de interrupciones hardware usando una capa software antes de que el kernel de Linux las procese. Este control incluye la interceptación, el enmascarado y/o la priorización de las interrupciones.

58 Porque necesitas monitorizar las llamadas al sistema de Linux, añadiendo más información y sin tener que modicar el código de las llamadas al sistema. Porque quieres un mecanismo para monitorizar los eventos internos que ocurren en el kernel de Linux como pueden ser la planicación de tareas, la creación de procesos ó las señales que capturan las tareas. Implementación de un dominio. El interfaz entre un dominio y ADEOS esta compuesto de: Un descriptor, que es una estructura de datos que describe las propiedades del dominio en el tiempo. Una rutina de entrada al dominio, a la cual ADEOS llama para iniciar un dominio. Esta rutina se encarga de registrar el conjunto de interrupciones/ eventos que va a manejar y a continuación el dominio pasa a ejecutar el bucle ocioso. Enlaces: B.2.3. ADEOS (web ocial distribución) ADEOS (web ocial desarrollo) Documentos: Diseño Adeos: dlopez/cache/doc/adeos.design.pdf Adeos: dlopez/cache/doc/porting.txt RTOS sobre ADEOS: dlopez/cache/doc/rtos.over.adeos.pdf RTLinux RTLinux es un SO de tiempo real que ejecuta Linux como un thread de menos prioridad que las tareas de tiempo real. Con este diseño, las tareas de tiempo real y los manejadores de interrupciones nunca se ven retrasados por operaciones que no son de tiempo real. La primera versión de RTLinux estaba diseñada para ejecutarse en la plataforma x86 y proporcionaba una pequeña API y un pequeño entorno de programación. La versión 2, que fue totalmente reescrita, fue diseñada para el soporte de multiprocesamiento simétrico (SMP) y para ser ejecutada en una amplia variedad de arquitecturas. RTLinux proporciona la capacidad de ejecutar tareas de tiempo real y manejadores de interrupciones en la misma máquina que el Linux estándar. Estas tareas y los manejadores ejecutan cuando se necesitan en detrimento de lo que estuviera ejecutando Linux. El peor caso de tiempo es entre que se detecta la interrupción hardware y el procesador ejecuta la primera instrucción del manejador de la interrupción. Este tiempo es del orden de los 10 microsegundos en la plataforma x86. Actualmente hay 2 versiones de RTLinux:

59 B. Estudio sobre sistemas operativos de tiempo real 59 RTLinux/Open: Disponible bajo la licencia GPL, pero que ya no se trabaja en ella desde RTLinux/Pro: Distribución comercial. Ambas versiones son distribuidas por la empresa FSMLabs. La arquitectura de diseño de RTLinux se encuentra patentada por FSMLabs. Una versión de la patente se encuentra accesible en el enlace: Y en aquí se puede ver que la FSF (Free Software Foundation) esta de acuerdo en los términos de la patente. A través de este otro enlace podemos leer una pequeña reexión sobre los efectos de la patente en el desarrollo de aplicaciones en RTLinux: A partir de aquí la descripción que se hace es sobre RTLinux/Open o RTLinux/GPL. Arquitectura. RTLinux es un pequeño y rápido sistema operativo que sigue el estándar POSIX : sistema operativo de tiempo real mínimo. RTLinux añade una capa de abstracción hardware entre el kernel estándar de Linux y el hardware de la máquina. Hay 3 modicaciones principales en el kernel de Linux con el objetivo de que RTLinux tenga el control del hardware de la máquina: Control directo de las interrupciones hardware. Control del reloj hardware e implementación de un reloj virtual para Linux. El control de las interrupciones por parte de Linux es reemplazado por 2 funciones que permiten activar ó desactivar las interrupciones, pero las virtuales. Estas modicaciones del kernel de Linux son complejas aunque no requieren excesivo código, pero si más que RTAI. RTLinux proporciona un entorno de ejecución bajo el kernel de Linux, como consecuencia de esto, las tareas de tiempo real no pueden usar los servicios de Linux. Para disminuir este problema, el sistema de tiempo real se ha divido en dos partes: la capa de tiempo real estricto que ejecuta encima de RTLinux, y la capa de tiempo real exible, que ejecuta como un proceso normal de Linux. Para la comunicación de ambas capas se pueden usar varios mecanismos (FIFO, memoria compartida). La propuesta de 2 capas es un método útil para proporcionar tiempo real estricto mientras se mantienen las características de escritorio de un sistema operativo. La separación del mecanismo del kernel de tiempo real del mecanismo del kernel de Linux de propósito general permite optimizar ambos sistemas de forma independiente. Características.

60 Soporte de múltiples arquitecturas y válida para arquitecturas multiprocesador. Gestión de procesos: Planicación, soporte de threads periódicos, amplio rango de prioridades, creación y borrado de threads, etc. Gestión de memoria: No protección de memoria en el kernel y no asignación de memoria de forma dinámica. Comunicación entre procesos: Semáforos, Mutex, control de inversión de prioridades, memoria compartida y FIFO's. Tiempo y relojes: Resolución de nanosegundos. No relojes de usuario. Facilidades para añadir nuevos relojes hardware. Programación de drivers: Se proporcionan funciones de acceso a dispositivos. No proporciona herramientas de calidad de servicio. Enlaces: B.2.4. Página Ocial ( Repositorio RTLinux GPL: Análisis RTLinux/GPL: MaRTE Aunque es el sistema operativo tratado en el proyecto y ya se ha hecho una descripción de él, pondremos los aspectos tratados en las secciones anteriores en forma de comparativa. Es un SO mínimo de tiempor real para aplicaciones empotradas, que puede ser usado en diferentes plataformas, incluyendo microcontroladores. Cumple un subconjunto POSIX.13. Ofrece los interfaces POSIX para los lenguajes C y ADA. Permite el desarrollo cruzado de aplicaciones de tiempo real C y ADA. Permite el desarrollo de aplicaciones C-ADA. Arquitectura. La parte central del sistema operativo MaRTE está en su kernel, el cual implementa las funcionalidades básicas del sistema. El kernel tiene una interfaz abstracta de bajo nivel para el acceso al hardware. Esta interfaz encapsula operaciones tales como: manejo de interrupciones, manejo del reloj y del tiempo y cambios de contexto en los threads. El

61 B. Estudio sobre sistemas operativos de tiempo real 61 objetivo de esto es facilitar la migración desde una plataforma a otra, ya que lo único que sería necesario cambiar es la capa de abstracción del hardware. En la parte de arriba del kernel hay una interfaz para aplicaciones POSIX.1 (actualmente funciones Ada con la forma de funciones POSIX.1). Esto proporciona dos importantes ventajas: Aplicaciones C pueden usar el kernel directamente, solo son necesarias un conjunto de cabeceras C. La capa de bajo nivel GNARL está por encima de la interfaz POSIX. Esta capa es para adaptarlo al kernel La distribución GNAT que se ha adaptado para que funcione en el sistema operativo MaRTE es la versión estándar desarrollada para Linux. Características. Apropiado para aplicaciones estáticas con el números de tareas y recursos del sistema conocido en tiempo de compilación. Los servicios tendrán tiempo de respuesta limitados. No está protegido. Multiplataforma. Multilenguaje. Entorno de Desarrollo. El entorno de desarrollo es en un PC con Linux. Y el destino para el que se desarrolla en una máquina x86 desnuda. Ambos sistemas están conectados por medio de una red de área local Ethernet (para aplicaciones de arranque) y un cable seria (para depuración remota). El compilador y el linker están basados en GCC y GNAT. El ciclo de desarrollo de una aplicación es bastante rápido e incluye los siguientes pasos: 1. El destino es arrancado con un disco netboot el cual es generado automáticamente durante la instalación del sistema operativo MaRTE. 2. La aplicación es compilada y enlazada en el ordenador de desarrollo usando los comandos mgnatmake o mgcc. 3. En la máquina destino el programa netboot descarga la aplicación que está en el ordenador de desarrollo a través de la Ethernet y lo ejecuta. 4. La aplicación se ejecuta libremente o es depurada remotamente desde el ordenador de desarrollo.

62 5. Tan pronto como la aplicación naliza el programa netboot de nuevo toma el control de la máquina destino y un nuevo ciclo puede empezar desde el paso 2. Enlaces. Sitio Ocial. B.2.5. VxWorks Es un componente run-time de la plataforma de desarrollo de sistemas empotrados Tornado II (Windows y UNIX). Hay dos versiones de VxWorks: VxWorks a secas, que es de la que hablaremos aquí. Y VxWorks AE, que está diseñado especialmente para alta disponibilidad con la ayuda distribuida de la mensajería y de la alta tolerancia. Características. Herramientas de desarrollo cruzado host-target: Compilador, Linkador y Cargador para el sistema target. Depurador remoto. Determinación de tiempos de ejecución. Simulador del sistema sobre el host. Soporte de un gran número de placas comerciales mediante Board Support Packages (más de 200), así como de placas a medida: Inicialización del HW. Conguración de interrupciones y temporizadores Memory mapping, etc. Consta de una interfaz con varias APIs (más de 1800 funciones). Es utilizado en diferentes tipos de aplicaciones: desde automoción (Antilock Braking Systems) a aplicaciones espaciales (Mars PathFinder), equipamiento de ocina (impresoras, faxes, etc.) y electrodomésticos (microondas, lavavajillas, etc.). Está adaptado a diferentes arquitecturas de CPU tales como: PowerPC, Intel 80x86, Motorola 68K, Intel 80960, ARM, SPARC, etc... Arquitectura. La arquitectura está basada en microkernel, dicho microkernel lo han llamado wind de unos pocos KB que incluye: Planicador multitarea basado en prioridades y con desplazamiento, el cual consta de 256 prioridades y tiene limitado el número de tareas. Primitivas de sincronización y comunicación entre tareas.

63 B. Estudio sobre sistemas operativos de tiempo real 63 Soporte a interrupciones. Gestión de watchdog timers. Gestión de memoria. Al tener una arquitectura modular, el sistema nal puede ser ampliado con diferentes módulos tales como: sistema de E/S, sistemas de cheros soporte para redes, etc.. Por lo tanto el sistema nal es adaptable a cientos de conguraciones diferentes ya que incluso los diferentes módulos son escalables. Los módulos individuales pueden ser utilizados durante el desarrollo y ser omitidos en el sistema nal. Es compatible con la norma POSIX (llamadas básicas al sistema) y b (real-time extensions). Enlaces. Sitio Ocial de VxWorks: aortiz

64 Apéndice C P2OS: El Sistema Operativo del microcontrolador. C.1. Introducción Para la realización del proyecto se ha usado un robot Pioneer 3-AT, distribuido por la empresa ActivMedia Robotics. Este robot contiene todo tipo de sensores y componentes de navegación que le permiten moverse en un entorno real. Es una plataforma perfecta para una gran variedad de proyectos de investigación. A continuación se resume el contenido de [11], dejando claros los puntos más importantes del manual. Para una especicación más detallada consultar [11]. C.1.1. Especicaciones técnicas Cada robot esta hecho con un cuerpo de aluminio, un sistema de movimiento (dos o cuatro ruedas), motores DC reversibles, electrónica de control del motor y conducción, encoders de movimiento de alta resolución, y baterías de larga duración. Todo ello soportado por un microcontrolador embebido sobre el cual está instalado el sistema operativo P2OS C.2, que distribuye ActivMedia. El robot actualmente presenta las siguientes características hardware: CPU Intel Pentium III 850-MHz con 256 MB memoria RAM. 1 Láser Sick LMS 1 Microcontrolador H8-Series. Controla odometría (posición), giróscopo, sonar y bumpers. 1 GPS Novatel. 1 Tarjeta Wi-Fi Conceptronics PCMCIA para comunicación inalámbrica a través de un adaptador PCI

65 C. P2OS: El Sistema Operativo del microcontrolador. 65 C.2. El Sistema Operativo del robot. P2OS La arquitectura de control del robot es de tipo cliente-servidor. Por un lado está el microcontrolador H8-Series dirigido por el P2OS (servidor) y por otro el PC del robot (cliente) conectados mediante el puerto serie. El servidor se encarga de controlar las operaciones de bajo nivel, como manejar los motores, lanzar el sonar, almacenar los valores del sonar y de la información de las ruedas, y otras muchas cosas. El cliente manda comandos para que el servidor los ejecute. Para comunicarse entre ambos se usan dos tipos de paquetes: Comand packet: Cliente ->Servidor. El cliente manda al servidor paquetes con los comandos que quiere que el microcontrolador ejecute en los dispositivos a los que accede. Por ejemplo, el cliente manda un comando de tipo VEL 2 al servidor. Cuando el P2OS recibe ese comando ordena a los motores correspondientes que se muevan a la velocidad correspondiente. Para ver una descripción completa de los comandos ver [11]. Server Information Packet (SIP): Servidor ->Cliente. El servidor envía cada 100 ms un paquete llamado SIP con información relativa a los dispositivos que controla. Se obtiene información de la odometría (posición), sonar, batería, bumpers, velocidad, etc. Ambos paquetes son cadenas de bits formadas por cinco elementos principales: una cabecera de dos bytes, un byte con el número de bytes que siguen, el comando o paquete SIP, los parámetros del comando o los datos del paquete SIP, y nalmente, dos bytes de checksum. Cada paquete está limitado a 206 bytes. Los diferentes tipos de paquetes se pueden ver en el manual extenso del microcontrolador ([11]). Por su extensión no se expondrán aquí. C.2.1. Conexión Cliente-Servidor Antes de poder ejecutar ningún control sobre el robot, debe de ejecutarse una aplicación cliente que establezca una conexión con el servidor del robot a través del puerto serie. Después de establecer la conexión el cliente podrá enviar comandos y recibir información del servidor. Cadena de sincronización: Para establecer la conexión el cliente debe enviar tres comandos de sincronización SYNC0, SYNC1 y SYNC2. La secuencia de bytes en hexadecimal que el cliente debe enviar es la siguiente:

66 SYNC0: 0xFA, OxFB, 0x03, 0x00, 0x00, 0x00 SYNC1: 0xFA, OxFB, 0x03, 0x01, 0x00, 0x01 SYNC2: 0xFA, OxFB, 0x03, 0x02, 0x00, 0x02 Autoconguración: Tras el comando SYNC2 el servidor manda al cliente los valores que tiene grabados en su memoria ash sobre el nombre (Nombre del robot en cuestión), clase (Pioneer) y subclase (P2AT8, P2DX,..) del robot. Con esta información el cliente podrá ajustar los parámetros concretos del robot en su aplicación. Abrir el servidor: OPEN Este es el siguiente comando que tiene que mandar el cliente para que el servidor comience diferentes servicios, como el sonar, los controladores del motor, escuche los comandos del cliente, y comience a transmitir paquetes de información (SIP). Comando en hexadecimal: 0xFA, OxFB, 0x03, 0x01, 0x00, 0x01 Mantener vivo al servidor: PULSE El microcontrolador tiene un watchdog de 2 segundos (parámetro congurable en la ash) que controla de forma segura el robot. Si en un periodo de 2 segundos no llega ningún comando del cliente, esto indicará que el cliente ha perdido el control del robot y este dejará de moverse. En el momento que se reciba un comando el robot volverá a moverse. Si nuestra aplicación tiene periodos en los que el cliente no manda ningún comando al servidor, se deberá mandar frecuentemente (menos de 2 segundos) el comando PULSE para evitar que el watchdog salte. Comando en hexadecimal: 0xFA, OxFB, 0x03, 0x00, 0x00, 0x00 Cerrar el servidor: CLOSE Para cerrar la conexión con el servidor, parando los motores, sonar y demás funciones del servidor. Comando en hexadecimal: 0xFA, OxFB, 0x03, 0x02, 0x00, 0x02 C.2.2. Comandos de movimiento El servidor P2OS que controla el motor acepta comandos de dos tipos. Control directo de las ruedas En este modo, el cliente debe de mandar un comando de translación (VEL) y después otro de rotación (ROTATE). Este modo es mucho más preciso. Control directo del movimiento De esta otra forma, el cliente manda un comando de tipo VEL2 con dos argumentos que indican la velocidad para las ruedas de cada lado del robot. Esto requiere, que

67 C. P2OS: El Sistema Operativo del microcontrolador. 67 el cliente calcule, a partir de la translación y rotación deseadas, los dos valores de los parámetros para componer el comando. El robot establece su posición a partir de las lecturas de los encoders que controlan cada rueda del robot. Mantiene la posición de sus coordenadas internas y las envía en el paquete de información SIP. Los valores devueltos son la posición en x (xpos), en y (ypos) y la dirección (Thpos). Estos valores representan la odometría del robot y sólo son válidos para tratar las variaciones de estos en pequeños movimientos. Se debe a que el movimiento del robot depende del entorno y si una rueda derrapa creerá estar en una posición, pero realmente está en otra. En supercies deslizantes el robot trabaja peor que en supercies rugosas. C.2.3. Sonar Cuando el cliente se conecta al servidor, el P2OS inicia directamente el sonar, mandando la información de este a través de los paquetes de información (SIP). Se puede usar el comando SONAR para habilitar o deshabilitar todos o algunos de los dispositivos sonar. Existen además otros dos comandos POLLING y SONAR_CYCLE. El primero establece la secuencia para lanzar cada uno de los sonar y el segundo para cambiar la frecuencia con la que se lanzan. C.2.4. Emergencias y paradas El robot Pioneer va equipado con sensores de contacto en la parte delantera y trasera. Cuando alguno de los sensores se activa (toca un obstáculo) se produce una parada de emergencia. P2OS permite activar o desactivar dichos sensores con el comando BUMPS- TALL. Además se puede congurar en la ash la acción que realizará el sensor al detectar un contacto (por defecto parada de emergencia).

68 Apéndice D El láser SICK LMS D.1. Información básica sobre el láser Nota: Esta es una versión resumida en castellano de las hojas de especicación del fabricante del láser SICK LMS. Si desea información completa y más especica consulte el Manual rápido de LMS en El Sistema de Medida Láser LMS 200, LMS 220, LMS 211, LMS 221, LMS 291 está basado en el principio de la medida del tiempo-de-vuelo (Radar Láser). Un único pulso láser es enviado fuera y reejado por la supercie de un objeto dentro del rango del sensor. El tiempo transcurrido entre la emisión y la recepción del pulso del láser sirve para calcular la distancia entre el objeto y el LMS. Mediante un espejo rotatorio integrado los pulsos del láser barren un rango en forma de radio en frente de la unidad LMS. Se dene de esta forma un campo o área de detección de dos dimensiones. Los principales benecios de estos principios de medida son: Detección de objetos independientemente del color o la textura que tengan. Detección able de la presencia de objetos. Figura D.1: Principio de medida y rango angular de LMS LMS ofrece solución a una gran cantidad de aplicaciones: Determina el volumen de los objetos (medición de paquetes, palets, contenedores ) Determina la posición de los objetos (palets, contenedores, cintas transportadoras ) Previene la colisión de vehículos 68

69 D. El láser SICK LMS 69 Controla procesos de atraque (posicionamiento) Clasicación de objetos (detección de vehículos) Automatización de procesos.. y muchas más D.2. D.2.1. Software. Mecanismo de comunicación Esquema de funcionamiento para la comunicación con LMS D.2.2. Figura D.2: Resumen del funcionamiento de las comunicaciones con LMS Establecer la comunicación con LMS Después de encender el láser, el led amarillo y el rojo se encenderán hasta que el proceso de inicialización haya sido completado. Solo cuando el led verde o el rojo esté activo, la unidad estará lista para la comunicación. Además, un mensaje de inicialización es enviado a la velocidad de 9600 bps a través del puerto serie al PC conectado. Mensaje de inicialización en hexadecimal LMS -> PC C 4D B B E D0 Para probar la conexión con el LMS conectado, se recomienda enviar el comando de estado al LMS. El comando de petición de estado para el LMS es:

70 Mensaje en hexadecimal PC -> LMS Mensaje en hexadecimal LMS -> PC C REFERENCIA A D.5 Nota: El red rojo activado permanente o temporalmente indica una infracción en alguno de los campos de la memoria interna del LMS. En caso de de que todo funcione correctamente sin infracciones el led verde se mantendrá activo de forma permanente. Figura D.3: Esquema de la inicialización del LMS D.2.3. Valores por defecto del LMS Por defecto, el láser después de inicializarse tiene los siguientes valores: Parámetro Valor Puerto serie C REFERENCIA A D.5 8 bits de datos sin paridad 1 bit de stop sin control de flujo Rango angular º Resolución angular 0.5º Unidades de medida mm Los valores por defecto de la tabla deben ser cambiados con los comandos que se describen más adelante. D.2.4. Cambiar la velocidad de transmisión Tras apagar el LMS, la velocidad de transmisión se resetea a 9600 baud. Para acceder a las mediciones del LMS a mayor velocidad, es necesario cambiar la velocidad a una mayor después de cada inicialización con alguno de los siguientes comandos:

71 D. El láser SICK LMS 71 Velocidad de LMS Comando PC -> LMS Respuesta LMS -> PC 9600 baud A A baud A A baud A A Nota: Al cambiar la velocidad de transmisión mediante estos comandos la comunicación con LMS y PC se interrumpe. Para reanudar de nuevo la comunicación con el LMS, es necesario cambiar a la nueva velocidad en el programa del PC también. D.2.5. Cambiar la resolución del LMS El LMS puede suministrar datos de distancia en los siguientes formatos: Rango angular: 0 o o ó 0 o o Resolución angular: 1 o, 0.5 o, 0.25 o (solo para 100 o ) Dependiendo de formato seleccionado, serán suministrados los diferentes valores de distancia: Rango angular Resolución angular Numero de valores 0º.. 100º 1º 101 0º.. 100º 0.5º 201 0º.. 100º 0.25º 401 0º.. 180º 1º 181 0º.. 180º 0.5º 361 Los diferentes modos pueden ser seleccionados enviando el correspondiente comando del PC al LMS: Nota: Después de enviar un comando, un paquete de reconocimiento (ACK) y la respuesta del LMS necesita ser recibida en el PC. Cuando se haya recibido la respuesta completa al ACK, la conguración del LMS habrá sido realizada y el siguiente comando podrá ser enviado. Los comandos intermedios serán ignorados. Modo LMS Comando PC -> LMS Respuesta LMS -> PC 0º.. 100º -- 1º B D 0F BB A 3F 0º.. 100º º B B BB º.. 100º º B E BB BE C4 0º.. 180º -- 1º B B BB 01 B E B2 0º.. 180º º B B B 1F BB 01 B F Figura D.4: Barrido láser en el modo 0 o..180 o y o