PFC UPC Estacion Seguimiento UAV

TRABAJO DE FIN DE CARRERA
TTULO DEL TFC: Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo TITULACIN: Ingeniera Tcnica de Telecomunicacin, especialidad Sistemas de Telecomunicacin AUTOR: Borja Lpez Livana DIRECTOR: Marco A. Pea Basurto FECHA: 9 de julio de 2007
Ttulo: Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo Autor: Borja Lpez Livana Director: Marco A. Pea Basurto Fecha: 9 de julio de 2007
Resumen
El sector aeronutico se encuentra en una nueva era de crecimiento gracias a numerosos avances tecnolgicos. Uno de ellos son los UAV, aviones no tripulados que son capaces de volar por s solos y con capacidad de tomar decisiones. Este trabajo forma parte del proyecto SKY-EYE, el cual est desarrollando un nuevo sistema con tecnologa UAV para uso civil. Es cierto que ste tipo de tecnologa ya se usa en el mbito militar desde hace aos, pero es ahora en el uso civil dnde se puede expandir an ms. El proyecto tiene como meta poder desarrollar un sistema con UAVs a los que se puedan embarcar todo tipo de cmaras o sensores. Este nuevo sistema de captacin de informacin, rpido y fiable, abre un gran abanico de aplicaciones. La primera de ellas podra ser el control de incendios forestales, el sistema ser capaz de prevenir, detectar, vigilar, etc. un incendio. Una de las primeras tareas es la de disear una aplicacin para la estacin de seguimiento. Esta aplicacin deber controlar la flota UAV, los planes de vuelo, y recibir toda la informacin que genere la flota para posteriormente tratarla. Este trabajo forma parte de un grupo de trabajo el cual se encargar de desarrollar el primer prototipo de esta aplicacin. Esta aplicacin se dividir en tres flujos de trabajo, uno para cada uno de los proyectistas del grupo. La primera de las partes se encargar de la integracin visual de la informacin georeferenciada de seguimiento, la segunda de los mecanismos de gereferenciacin y ortorectificacin de imgenes areas, y la tercera de la modelizacin y tratamiento de planes de vuelo. Sobre la ltima es la que trata ste trabajo.
Title: Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo Autor: Borja Lpez Livana Director: Marco A. Pea Basurto Date: July, 9th 2007
Overview
The aeronautical sector is now in a growing period thanks to the newest technological advances. One of them are the UAVs, unmanned aerial vehicles that are able to fly by themselves and to take decisions. This work is part of the SKY-EYE project; SKY-EYE is developing a new system with UAV technology for civil use. Although the army has been using the UAVs for many years, it is interesting to keep the increasing this technology now at the civil society. The project has the objective to develop a system with UAVs, this UAVs will be able to carry any kind of cameras or sensors. This new capture information system, fast and reliable, has a lot of possible applications. The first one could be used to control forest fire, the system would be able to prevent, detect, guard a forest fire. The first task to do is designing the software application that will be in the controlling station. This application should control the UAVs, the flight plans, and will receive all the information generated by the planes. This work is part of a workgroup that has the objective to develop the first prototype of this application. The application is divided in three parts, one for every designer of the workgroup. The first part will develop the visual integration of the flight plan georeferenced information; the second one will develop the algorithms to georeference and orthorectifice aerial images; and the third will develop the modeling and treatment of flight plans. This work is the one that develops the last part.
NDICE
INTRODUCCIN ............................................................................................... 1 CAPTULO 1. CONTEXTO TECNOLGICO Y ANLISIS DE OBJETIVOS .... 3
1.1. Escenario, Visin y Tecnologa........................................................................................ 3 1.1.1. Escenario y Visin .................................................................................................. 3 1.1.2. Tecnologa .............................................................................................................. 5 Motivacin .......................................................................................................................... 8 Objetivos ............................................................................................................................ 8 1.3.1. Objetivos de SKY-EYE ........................................................................................... 8 1.3.2. Objetivos del grupo de trabajo................................................................................ 9 1.3.3. Objetivos del TFC................................................................................................. 10 Planificacin y estimacin de costes ............................................................................ 10 1.4.1. Divisin de Tareas ................................................................................................ 10 1.4.2. Planificacin.......................................................................................................... 11 1.4.3. Estimacin de Costes ........................................................................................... 12 Metodologa de trabajo ................................................................................................... 14
1.2. 1.3.
1.4.
1.5.
CAPTULO 2. ANLISIS DEL PROBLEMA.................................................... 15

2.1. Sistemas de Informacin Geogrfica (GIS) .................................................................. 15 2.2.1. Qu es un GIS?.................................................................................................. 15 2.2.2. Relacin GIS Aplicacin SKY-EYE ................................................................... 16 2.2.3. Criterios de seleccin de GIS ............................................................................... 16 2.2.4. Evaluacin y seleccin de GIS ............................................................................. 17 2.2.5. Eleccin Final ....................................................................................................... 18 Cartografas...................................................................................................................... 18 Plan de vuelo.................................................................................................................... 19 Estacin de seguimiento ................................................................................................ 20 2.3.1. Introduccin .......................................................................................................... 20 2.3.2. Informacin como un servicio............................................................................... 20 2.3.3. Paquetes de telemetra ........................................................................................ 21 2.3.4. Paquetes de misin .............................................................................................. 22
2.2. 2.3. 2.4.
CAPTULO 3. ESPECIFICACIN.................................................................... 23
3.1. 3.2. 3.3. Plan de vuelo.................................................................................................................... 23 Concrecin de objetivos................................................................................................. 26 Planificacin detallada.................................................................................................... 26
CAPTULO 4. DISEO .................................................................................... 28

4.1. 4.2. 4.3. 4.4. Plataforma .NET ............................................................................................................... 28 XML ................................................................................................................................... 30 ArcGis Development Kit ................................................................................................. 31 Diseo de estructura de clases...................................................................................... 32 4.4.1. Plan de Vuelo ....................................................................................................... 32 4.4.2. Gestor de Cartografas ......................................................................................... 33 4.4.3. Seguimiento de telemetra.................................................................................... 34 4.4.4. Seguimiento de misin ......................................................................................... 34
CAPTULO 5. IMPLEMENTACIN Y PRUEBAS............................................ 36

5.1. Implementacin ............................................................................................................... 36 5.1.1. Librera FlightPlan ................................................................................................ 36 5.1.2. Librera BBDD_Fotos ........................................................................................... 37 5.1.3. Librera ReceivedInfo ........................................................................................... 38 Pruebas individuales....................................................................................................... 39 Integracin del sistema y pruebas................................................................................. 39
5.2. 5.3.
CAPTULO 6. BALANCE................................................................................. 44
6.1. 6.2. Evolucin del proyecto ................................................................................................... 44 Costes finales .................................................................................................................. 45
CAPTULO 7. CONCLUSIONES ..................................................................... 47

7.1. Revisin de objetivos...................................................................................................... 47 7.1.1. Objetivos individuales ........................................................................................... 47 7.1.2. Objetivos del grupo de trabajo.............................................................................. 48 7.1.3. Objetivos SKY-EYE .............................................................................................. 48 Conclusiones ................................................................................................................... 48 7.2.1. Conclusiones individuales .................................................................................... 49 7.2.2. Conclusiones del grupo de trabajo ....................................................................... 49 Lneas futuras .................................................................................................................. 49 Estudio de la ambientalizacin ...................................................................................... 50
7.2.
7.3. 7.4.
BIBLIOGRAFA ............................................................................................... 51
Introduccin
INTRODUCCIN
El sector aeronutico se encuentra en una nueva era de crecimiento gracias a numerosos avances tecnolgicos. Uno de ellos son los UAV, aviones no tripulados que son capaces de volar por s solos y con capacidad de tomar decisiones. Este trabajo forma parte del proyecto SKY-EYE, el cual est desarrollando un nuevo sistema con tecnologa UAV para uso civil. Es cierto que ste tipo de tecnologa ya se usa en el mbito militar desde hace aos, pero es ahora en el uso civil dnde se puede expandir an ms. El proyecto tiene como meta poder desarrollar un sistema con UAVs a los que se puedan embarcar todo tipo de cmaras o sensores. Este nuevo sistema de captacin de informacin, rpido y fiable, abre un gran abanico de aplicaciones. La primera de ellas podra ser el control de incendios forestales, el sistema ser capaz de prevenir, detectar, vigilar, etc. un incendio. Una de las primeras tareas es la de disear una aplicacin para la estacin de seguimiento. Esta aplicacin deber controlar la flota UAV, los planes de vuelo, y recibir toda la informacin que genere la flota para posteriormente tratarla. Este trabajo forma parte de un grupo de trabajo el cual se encargar de desarrollar el primer prototipo de esta aplicacin. Esta aplicacin se dividir en tres flujos de trabajo, uno para cada uno de los proyectistas del grupo. La primera de las partes se encargar de la integracin visual de la informacin georeferenciada de seguimiento, la segunda de los mecanismos de gereferenciacin y ortorectificacin de imgenes areas, y la tercera de la modelizacin y tratamiento de planes de vuelo. Sobre la ltima es la que trata ste trabajo. Al tratarse de un proyecto de software, ste sigue la estructura general. Se inicia con un anlisis del contexto tecnolgico y del problema, a continuacin se pasa al desarrollo con una primera especificacin para despus pasar a disear, implementar e integrar. Todas estas fases seguirn unos objetivos y planificacin especficos, los cuales se definirn al inicio y se repasaran al acabar. La primera planificacin indicaba la finalizacin del proyecto a inicios de junio dejando un mes de guarda hasta la fecha lmite. Aunque finalmente se ha alargado la planificacin hasta llegar a esta fecha, inicios de julio. En el primer captulo se analiza el contexto general en el que se sita el proyecto y tambin se hace una primera planificacin juntamente con un primer listado de objetivos. El siguiente captulo realiza un anlisis ms especfico de los temas relacionados con el proyecto.
Estacin SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo
En el captulo de especificacin se puede encontrar la solucin tcnica al problema. Adems se revisan y concretan los objetivos del proyecto para, a continuacin, realizar una nueva planificacin ms detallada. En el siguiente captulo se disea la estructura de la aplicacin a desarrollar. Tambin se analizan las herramientas que se utilizarn durante el desarrollo. Cuando finaliza el diseo, se inicia la implementacin de la aplicacin. En ste captulo se comentan las partes de la aplicacin ms importantes y las pruebas de funcionamiento correspondientes. Tambin se expone la integracin de las tres partes de la aplicacin. En el captulo de balance se puede ver un anlisis de la planificacin y la revisin de los costes finales. stos se contrastan con los previstos en un inicio y se comentan y justifican dichas variaciones. El ltimo captulo es el de conclusiones. En ste se pueden encontrar la revisin de los objetivos tanto a nivel personal como de grupo adems de las conclusiones del proyecto. Junto a la memoria se adjunta un tomo de anexos. En el que se puede encontrar toda la documentacin relacionada con el proyecto. Se pueden encontrar documentos generados por el equipo que amplan los contenidos de los captulos de la memoria. Adems tambin se adjuntan documentos externos que estn muy relacionados con el proyecto.
Contexto tecnolgico y anlisis de objetivos
CAPTULO 1. CONTEXTO TECNOLGICO Y ANLISIS DE OBJETIVOS
1.1.
1.1.1.
Escenario, Visin y Tecnologa

Escenario y Visin
Hasta ahora, toda captacin de informacin cartogrfica de precisin se hacia por medio de aviones tripulados o satlites con costosos sistemas abordo. El proyecto SKY-EYE se concibe a partir de la necesidad de un nuevo sistema ms sencillo y menos costoso. Para ello SKY-EYE trata de disear un sistema modular basado en aviones no tripulados (UAV) capaces de captar cualquier tipo de informacin geogrfica y transmitirla rpidamente a tierra para procesarla. La finalidad es conseguir un sistema que resuelva el problema sin grandes costos, substituyendo a los aviones tripulados o satlites. La evolucin de la tecnologa permite que una flota de UAVs sea capaz de proporcionar una calidad de informacin muy similar a los sistemas ya existentes a una mayor velocidad y movilidad. Las posibles aplicaciones del proyecto son muy diversas. La primera aplicacin sobre la que se centrar el proyecto ser la de prevencin, deteccin, control y seguimiento de incendios forestales en tiempo real (Figura 1.1). En un futuro las aplicaciones se podran ampliar a vigilancia de grandes infraestructuras como oleoductos, red viaria o ferroviaria, yacimientos petrolferos, etc., a vigilancia y salvamento martimo o forestal, a anlisis y actualizacin de catastro, etc.
Figura 1.1 Aplicacin SKY-EYE sobre incendios forestales
Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo
En su concepcin el proyecto SKY-EYE lo forman varios grupos de investigacin universitarios y empresas del sector tecnolgico en Espaa. Principalmente el proyecto lo lidera el grupo de investigacin ICARUS de la Escuela Politcnica Superior de Castelldefels (EPSC). El proyecto se desarrolla en gran parte en la EPSC, esto supone una gran fuente de recursos humanos sobretodo, ya que en ella se estudian Ingenieras Tcnicas de Telecomunicaciones y de Aeronutica. En la EPSC se dispone de laboratorios y personal, tanto docente como becario. Dando lugar a numerosas tesis, proyectos y trabajos de final de carrera. El completo desarrollo del proyecto SKY-EYE supondra una revolucin en el mercado aeronutico, situando a ICARUS y a la ESPC a la cabeza. El uso de UAV hasta ahora se ha limitado al mbito militar. En el mbito civil este tipo de tecnologa todava se usa muy poco. Se trata de una tecnologa sin desarrollar con muchas expectativas de futuro, con una mediana inversin de capital para desarrollo puede dar lugar a resultados muy econmicos pero efectivos. Existen muchos impedimentos hoy en da para el desarrollo de un proyecto relacionado con UAVs en Espaa. Existe un sector del mundo aeronutico contrario al uso de UAVs que circulen libremente sin una persona que lo controle directamente. El espacio areo se encuentra muy cerrado para ste tipo de tecnologa, los pilotos areos no quieren UAVs navegando junto a ellos. Debido a esto se necesita un buen desarrollo en UAVs para que cuando se les permita volar en el espacio areo sean totalmente fiables y seguros.
Figura 1.2 Esquema general del proyecto SKY-EYE
1.1.2.
Tecnologa
SKY-EYE estudia y desarrolla un sistema modular embarcado en un avin no tripulado (UAV). El sistema embarcado estar formado por mdulos intercambiables de control de vuelo, de misin y de captura de informacin. Los mdulos de captura de informacin podran ser cmaras fotogrficas de espectro visible, cmaras de vdeo, cmaras trmicas por infrarrojo, tipo de sensor medioambiental, etc. El proyecto SKY-EYE tiene tres secciones diferenciadas (Figura 1.2). La primera de ellas es la parte area, en sta estar el UAV que en un futuro se ampliara a una flota de UAVs. En tierra hay dos tipos de estaciones, una estacin de control para cada zona en la que acte una flota de UAVs y una estacin central de seguimiento conectada a cada una de las estaciones de control. En el proyecto SKY-EYE todas las aplicaciones desarrolladas sern de uso civil, desde control de incendios a vigilancia de grandes infraestructuras.
Seccin 1: Flota UAV Un Unmaned Aerial Vehicle (UAV), es un avin sin piloto abordo. Un UAV puede estar controlado remotamente o puede volar automticamente basndose en un plan de vuelo pre-programado (Figura 1.3).
Figura 1.3 UAV modelo Shadow 240
El UAV diseado embarcar una plataforma modular con sistema de control de vuelo, de misin y de captacin de informacin. La plataforma embarcada en el UAV constar de un mdulo que se encargar de controlar el plan de vuelo previsto, comunicndose en todo momento con el Sistema de Navegacin (Flight Control System, FCS), siendo capaz de ejecutar modificaciones en el plan de vuelo en casos de emergencia. El control de la misin y de la carga de pago lo implementar otro mdulo, ste ir dando rdenes de misin a la plataforma de observacin a medida que el mdulo de control de vuelo vaya completando el plan de vuelo. El mdulo de plataforma de observacin tendr capacidad de acoger todo tipo de cmaras fotogrficas o sensores.
Seccin 2: Estacin de control La estacin de control estar situada en el rea de operaciones de una flota de UAVs. sta se encargar de controlar la flota y establecer las comunicaciones con cada uno de los UAV (Figura 1.4).
Figura 1.4 Ejemplo de estacin de control
Entre la estacin de control y el UAV habr dos flujos de comunicaciones. El primero de ellos ser de bajo ancho de banda, ya que se utilizar para enviar toda la telemetra relacionada con el seguimiento del plan de vuelo del UAV y el estado del UAV y de los equipos abordo. Se utilizar un radioenlace para este tipo de comunicacin, un radioenlace nos asegura gran cobertura a bajo ancho de banda. Es muy importante que desde la estacin de control no se pierda la comunicacin con el UAV, ya que desde est se podr controlar el UAV en caso de emergencia. La segunda comunicacin requiere un mayor ancho de banda, se destinar a la obtencin de toda la informacin generada por el control de misin y la plataforma de observacin. El sistema de comunicacin que se emplee an est por definir, est en base de investigacin, se barajan opciones como WiFi, WiMax, etc. Este tipo de enlaces no garantizan la cobertura en todo momento, en caso de que se produzcan cortes en la conexin se debern tomar algunas decisiones. Para estas decisiones se establecer un protocolo de prioridades segn la misin que se est desarrollando. Una de las prioridades podra ser que en caso de que se corte la conexin, al retomarse, sea prioritaria la informacin en tiempo real, y que se enve la informacin que no se pudo transmitir en ventanas de tiempo en que no haya misin o al aterrizar el UAV. Otra prioridad podra ser que en el caso que estemos buscando un tipo de informacin en concreto, si se encuentra, su transmisin sea prioritaria al resto, ste sera el caso de focos de calor en un incendio forestal.
Para las dos tipos de comunicacin entre el UAV y la estacin de control se debern disear un conjunto de protocolos tanto de telemetra como de misin especficos para el proyecto SKY-EYE. Seccin 3: Estacin de seguimiento La estacin de seguimiento se podr situar en cualquier punto del territorio, ser nica y todas las estaciones de control debern conectarse a ella (Figura 1.5). Para la conexin hacia la estacin de seguimiento se utilizarn conexiones de red de comunicacin convencionales.
Figura 1.5 Ejemplo de estacin de seguimiento
En esta estacin se coordinarn todas las estaciones de control y sus flotas de UAVs, juntamente con los planes de vuelo, misin y recepcin de informacin. Para esta estacin se disear una aplicacin de software con diferentes funciones, ha de ser capaz de tratar toda la informacin recibida, poderla visualizar en mltiples pantallas simultneamente, etc. La aplicacin poseer todas las herramientas caractersticas de un Sistema de Informacin Geogrfica (GIS), ser capaz de visualizar sobre una cartografa la informacin de plan de vuelo, y podr georeferenciar y ortonormalizar la informacin de misin. En la estacin de seguimiento tambin se disearn todos los planes de vuelo y misin que despus se transmitirn a las estaciones de control y a las flotas de UAVs, as que la aplicacin tendr un editor de planes de vuelo y misin, para escoger todos los waypoitns, maniobras, acciones de la plataforma de observacin, etc.
1.2.
Motivacin
Despus de llegar casi al final de la Ingeniera Tcnica de Telecomunicaciones en la EPSC, hago balance de todas las asignaturas cursadas y me doy cuenta de que las que ms me interesaron fueron las relacionadas con la programacin. Las primeras fueron IC y LP en las que aprend conocimientos de C y de la programacin en general. Ms tarde ya en la especialidad de Sistemas de Comunicacin curs LPII, en la que me introdujeron a C#, dando resultado a proyectos mucho ms interesantes. Dada la gran motivacin que me proporcion la programacin en .NET, orientada a objetos y con herramientas grficas, me decant a escoger DSEM como asignatura optativa. En ella descubr la programacin para dispositivos mviles y la creacin de aplicaciones grficas. De todos los proyectos que he hecho durante la carrera, los que ms me han interesado y motivado han sido los de programacin. Se debe al hecho de que me gusta poder disear e implementar algo que despus produce un resultado operativo, con una finalidad, que tenga interaccin con un posible usuario. Esto da lugar a la obtencin de resultados durante todo el progreso del proyecto, pudiendo siempre mejorar. Lo prefiero a proyectos de investigacin y diseo sobre el papel, que en ningn momento llegan a convertirse en algo concreto y utilizable. La motivacin que me llev a aceptar este proyecto cuando se propuso fue la posibilidad de ampliar mis conocimientos sobre programacin. Tambin me sedujo que se trataba de un proyecto de gran envergadura, con mucha gente trabajando, no slo era un TFC con principio y final. La aplicacin a disear e implementar se hara en un grupo de trabajo, relacionndose con otras lneas de investigacin sobre SKY-EYE. El grupo de trabajo al que iba a formar parte tambin me otorgaba experiencia profesional como becario en una empresa de desarrollo de proyectos tecnolgicos.
1.3.
1.3.1.
Objetivos
Objetivos de SKY-EYE
SKY-EYE se trata de un proyecto a largo plazo, por tanto el proyecto tiene numerosos objetivos hasta llegar a desarrollar un sistema completo formado por una flota de UAVs, estaciones de seguimiento y una estacin central de seguimiento. El proyecto se encuentra actualmente en la primera fase, y cada uno de los grupos de investigacin involucrados se encarga de una fase diferente. Como objetivo conjunto est el de conseguir la implementacin de un prototipo para poderlo presentar en la FireParadox de Agosto de este ao en Portugal. Para ste prototipo, cada parte del conjunto tiene un objetivo.
Un grupo de investigacin se encargar de disear un sistema para embarcar en un UAV capaz de capturar todo tipo de informacin a travs de cmaras fotogrficas, de video, sensores de la superficie terrestre. Otro grupo disear los sistemas de transmisin de datos entre los UAVs y las estaciones de control. El ltimo grupo disear una estacin de seguimiento con la aplicacin de software apropiada para supervisar todo el sistema y informacin generada. Del desarrollo del sistema embarcado en el UAV y de las comunicaciones a tierra se encargarn el grupo de investigacin ICARUS en la EPSC, y del diseo de la estacin de seguimiento y de la aplicacin de software se encargar el grupo de trabajo formado por los tres proyectistas Myriam Gonzlez, Juan Manuel Lema y Borja Lpez. Este grupo estar trabajando en la empresa INFINIFISH y estar supervisado por Marco A. Pea, miembro de ICARUS.
1.3.2.
Objetivos del grupo de trabajo
El grupo de trabajo se encargar de disear e implementar una aplicacin de software que sea capaz de gestionar toda la informacin generada por un UAV, tanto sea de plan de vuelo como de misin (Figura 1.6). El desarrollo de la aplicacin de dividir en tres flujos de trabajo. - El primer flujo se encargar de la parte de la aplicacin que gestiona el plan de vuelo y lo llevar a cabo Borja Lpez. - El segundo flujo se encargar de la georeferenciacin y ortonormalizacin de imgenes y lo llevar a cabo Myriam Gonzalez. - El tercer flujo se encargar del diseo de la interfaz de usuario que integre las herramientas implementadas por las otras dos partes y lo llevar a cabo Juan Manuel Lema. Cada una de las partes dar lugar a un TFC distinto, pero en conjunto formarn la aplicacin de usuario que se encarga al grupo de trabajo.
Figura 1.6 Estructura de la Estacin de seguimiento SKY-EYE para UAVs
10
1.3.3.
Objetivos del TFC
Este TFC en concreto se dedica a la parte de plan de vuelo. Estar centrado en el acceso a datos externos a la aplicacin y su posterior tratamiento y almacenamiento. Los objetivos seguirn un orden de desarrollo, cada uno de los objetivos es requisito del siguiente. 1. El diseo de un modelo conceptual especfico para almacenaje de planes de vuelo. ste debe ser totalmente accesible desde la capa de presentacin para su posterior visualizacin tanto grficamente sobre una cartografa como en texto u otros formatos. 2. Un sistema lector de planes de vuelo XML para el modelo conceptual. 3. Un sistema gestor de cartografas almacenadas, este sistema debe relacionar los planes de vuelo con las cartografas y ortofotos disponibles asociadas. Para ello se utilizarn herramientas de GIS para consultar coordenadas cartogrficas. 4. Diseo del modelo conceptual para almacenamiento de informacin de seguimiento y misin. 5. Implementacin de un simulador de telemetra y misin.
1.4.
1.4.1.
Planificacin y estimacin de costes

Divisin de Tareas
Como proyecto de software, las principales tareas que deben llevarse a cabo y tener en cuenta durante la planificacin son las siguientes: - Requerimientos: Antes de empezar a estructurar y analizar el problema del proyecto, hace falta una base previa de investigacin. En ella se recopilar toda la informacin que nos har falta en adelante. Para este proyecto se recopilar informacin sobre planes de vuelo y estaciones de seguimiento, y sobre los GIS que existen en el mercado. Para el proyecto interesan tanto aplicaciones GIS como libreras GIS. - Anlisis del problema: Tarea de anlisis en la que se modela la estructura generalizada de la aplicacin. Aqu se analizarn en detalle los GIS y se escoger cul de ellos se utilizar, y como consecuencia en qu plataforma de programacin se trabajar. - Especificacin: Una vez escogido el GIS y la plataforma de programacin, se concretarn los objetivos del proyecto y se realizar una planificacin ms detallada para el resto de tareas. Se disearn los diagramas UML de estructura de clases y de casos de uso para la aplicacin, etc. - Diseo: En esta tarea se disearn las libreras y clases necesarias que ms tarde se implementarn. En ste caso libreras y mtodos para la para acceder a informacin externa a la aplicacin como archivos XML y cartografas. Tambin se disearn libreras y mtodos para tratar y gestionar toda la informacin externa anterior.
11
Implementacin y pruebas: Tarea propiamente de programacin e implementacin de todo lo diseado. A medida que se va implementando se irn realizando pruebas unitarias y posteriormente pruebas de integracin. Integracin del sistema: Finalizada la tarea anterior se pasar a integrar las diferentes partes de la aplicacin, se integrarn las tres partes de la aplicacin y se realizarn pruebas de compatibilidad.
1.4.2.
Planificacin
Para poder empezar a trabajar sobre el proyecto, antes se debe establecer una planificacin previa (Figura 1.7 y Anexo A). sta planificacin est basada en los objetivos iniciales del proyecto, una vez se analice con detalle el problema, se deber realizar una planificacin ms detallada. En el captulo de Balances, se detalla la variacin de la planificacin a lo largo del proyecto debido a cambios de objetivos y otros problemas surgidos.
Figura 1.7 Diagrama de Gant de la planificacin previa
La planificacin previa es para el grupo de trabajo en conjunto y se hace siguiendo las tareas generales de un proyecto de software. Cada una de las fases tiene un periodo de trabajo dedicado a fondo, aunque sta no finalizar hasta que acaben sus revisiones y correcciones. o Estudio y comprensin del problema. sta fase corresponde a la tarea de requerimientos. Se analizarn y documentarn temas como el proyecto SKY-EYE, planes de vuelo y de misin, GIS, estaciones de seguimiento, etc. Esta fase durar 1 semana. o Anlisis detallado del estado del arte. Anlisis general del problema y definicin de objetivos generales. Esta fase durar 2 semanas. o Evaluacin de sistemas GIS. Documentacin y pruebas de software GIS para la eleccin del GIS que se usar. Esta fase durar 1 semana. o Especificacin y planificacin para las fases posteriores. Concrecin ms detallada de los objetivos y de la planificacin a seguir. Esta fase durar 1 semana.
12
o Diseo, implementacin y pruebas. En estas fases se trabajar por separado para cada una de las partes de la aplicacin: - Gestin de Plan de Vuelo. - Georeferenciacin y Ortonormalizacin de informacin. - Diseo del GUI de la estacin de seguimiento integrado con GIS. Estas fases durarn 4 semanas. o Desarrollo de componentes. Una vez acabados los prototipos de las tres partes se acabarn de desarrollar conjuntamente. Esta fase durar 5 semanas. o Integracin del sistema. Finalmente, se integrar por completo el sistema acabando de perfeccionar las partes. Tambin se realizarn pruebas de integracin. Esta fase durar 2 semanas. o Documentacin TFC. sta fase se dedicar a recopilar toda la documentacin generada durante las fases anteriores para componer las memorias de los 3 TFC y elaborar la presentacin del proyecto. Esta fase durar 3 semanas.
1.4.3.
Estimacin de Costes
Antes de iniciar el proyecto, tambin es necesario realizar una estimacin de costes del mismo. La estimacin de costes se har en base al grupo de trabajo como conjunto, teniendo en cuenta que hay tres miembros. Estos costes se distinguirn en dos tipos: recursos humanos e infraestructura.
Recursos humanos Segn la planificacin previa del apartado anterior, el proyecto tendr 8 partes. Cada una de las fases requiere un tipo de profesional diferente: o Analista informtico. Se encargar de las tareas: - Estudio y comprensin del problema - Anlisis detallado del estado del arte - Evaluacin de sistemas GIS - Especificacin y planificacin para las fases posteriores La suma de estas cuatro tareas, desde el da 7 de febrero al da 14 de marzo, son 26 das laborables. o Programador informtico. Se encargar de las tareas: - Diseo, implementacin y pruebas - Desarrollo de componentes - Integracin del sistema La suma de las estas tres tareas, desde el da 15 de marzo al da 18 de mayo, son 47 das laborables. o Documentador. Se encargar de la tarea: - Documentacin TFC Esta tarea se inicia el da 15 de mayo y acaba el 6 de junio, sumando 16 das laborables.
13
Infraestructura Para cada uno de los miembros del grupo de trabajo se necesitar un puesto de trabajo completo con un ordenador y pantalla plana, el valor estimado para cada equipo sera de 1000. Tambin es necesaria conexin a Internet de mnimo 2Mbps. Cada una de las estaciones de trabajo tendr el software Windows XP y Microsoft Office XP. Se debern adquirir las licencias correspondientes. Adems se necesitar un software de desarrollo de sistemas y unas libreras GIS, pero al ser una previsin de costes an no se sabe que licencias se requerirn y que costes tienen. Como se indica en el apartado de Metodologa, se crear un portal para intercambio de informacin generada durante el proyecto. Para ello se necesitar el alquiler de un dominio para el portal de intercambio y una licencia sharepoint. Adems se toma en cuenta unos gastos en material de oficina de 500 para el grupo de trabajo. Material de oficina puede ser cds, dvds, cartografas, etc. Coste total El coste total estimado se realiza para el grupo de trabajo como conjunto, por tanto disponemos de 3 recursos humanos (Tabla 1.1). El salario de los tres tipos de profesionales es una estimacin de las remuneraciones que se indicaron en proyectos de final de carrera similares realizados en la EPSC y la FIB. Las jornadas de trabajo se establecen de lunes a viernes a 25 horas semanales.
RECURSOS Das de Horas Horas Coste Horas Coste Recursos /hora HUMANOS trabajo por da Recurso Recurso Totales Total Analista Informtico 3 26 5 32 130 4.160 390 12.480 Programador 3 47 5 25 235 5.875 705 17.625 Documentador 3 16 5 20 80 1.600 240 4.800 TOTAL 445 11.635 1335 34.905 INFRAESTRUCTURA Estacin de Trabajo Licencia Windows XP Licencia Sharepoint Licencia Microsoft Office 2007 Licencia Entorno de Desarrollo Licencia Libreras GIS Materiales de oficina varios Cantidad 3 3 1 3 coste unidad 1.000 159 2.000 450 por determinar por determinar TOTAL COSTE TOTAL coste total 3.000 477 2.000 1.350
500 7.327 40.405,00
Tabla 1.1 Costes estimados de recursos humanos e infraestructura
14
1.5.
Metodologa de trabajo
Para un correcto funcionamiento del grupo de trabajo es necesario determinar una metodologa de trabajo. El grupo estar formado por tres proyectistas, cada uno encargado de una parte diferente de la aplicacin. Los tres flujos de trabajo debern avanzar a en paralelo y en algunos momentos del desarrollo coincidirn en tareas. La forma de controlar y hacer un seguimiento ser a travs de reuniones semanales, marcando tareas y objetivos para la siguiente reunin. Para cada una de las reuniones se elaborar un documento de orden del da y despus otro de acta de la reunin, para dejar constancia de todos los temas tratados y decisiones acordadas. A cada fase que se vaya completando se deber generar la documentacin correspondiente. La forma de compartir informacin entre el grupo ser a travs de un repositorio de documentacin, en el que se guardar toda la informacin generada, rdenes del da y actas de las reuniones de seguimiento e informacin externa relacionada. ste repositorio se situar en un portal web con acceso restringido.
Anlisis del estado del arte
15
CAPTULO 2. ANLISIS DEL PROBLEMA

En este captulo se analizan todos aquellos sectores que estn relacionados con el proyecto. Este anlisis es importante para despus poder pasar a desarrollar el proyecto con una buena base de conocimientos. Los temas a analizar sern los sistemas de informacin geogrfica, cartografas, planes de vuelo y estaciones de seguimiento.
2.1.
2.2.1.
Sistemas de Informacin Geogrfica (GIS)

Qu es un GIS?
Un GIS (del ingls Geographic Information System) se encarga de administrar la informacin geogrfica de forma eficaz y completa. De esta manera, a travs de una base de datos de un sistema GIS podemos capturar, almacenar, manipular, analizar y desplegar en todas sus formas la informacin geogrficamente referenciada con el fin de resolver problemas complejos de planificacin, gestin, visualizacin, etc. Un GIS se caracteriza por dividir su informacin en capas. Estn las capas con vertiente espacial y las de vertiente temtica. De esta manera, para un lago en un GIS, no slo tendremos capa de profundidad y dimensiones (capas espaciales), sino que podremos tener grados de contaminacin, niveles de flora y fauna, etc. (capas temticas) (Figura 2.1).
Figura 2.1 Representacin del modelo de capas para GIS De esta manera, a travs de un GIS conseguiremos disponer de una base de datos de informacin geogrfica muy completa con la que podremos trabajar de forma rpida y efectiva. Existen diferentes maneras de almacenar la informacin geogrfica en las bases de datos. Entre ellos tenemos dos principales modelos: Raster y Vectorial. El modelo Raster divide la zona de inters en pequeas celdas regulares llamadas pxeles. Estas celdas estn en todo momento georeferenciadas ya que sabemos sus coordenadas y se les atribuye un valor numrico en funcin
16
de la temtica. Existe un compromiso con el nmero de pxeles, ya que a mayor nmero mejor resolucin pero a la vez mayor costo computacional. El modelo Vectorial es aqul que utiliza herramientas grficas para el almacenamiento e interpretacin de la informacin. Un punto puede ser un pozo de agua, una lnea una carretera, un circulo un ro, etc. El inters de las representaciones vectoriales se centra en la precisin de localizacin de los elementos sobre el espacio.
2.2.2.
Relacin GIS Aplicacin SKY-EYE
La aplicacin a desarrollar se dedicar a visualizar informacin geogrfica sobre un mapa, tanto podr ser un plan de vuelo, el seguimiento de ste o una fotografa. El proyecto SKY-EYE no intentar crear un GIS, de hecho un GIS tiene muchas ms herramientas de las que se necesitan. El objetivo es intentar sacar el mximo provecho a la informacin geogrfica de que dispondremos. Las herramientas que ms interesan para este TFC son las relacionadas con el seguimiento del avin y la misin. Si se quiere crear un gestor de misiones y planes de vuelo, adems del gestor de cartografas, se trabajar sobre un mapa, agregando puntos de paso, trayectorias, datos de telemetra, fotografas, etc. Organizando toda esta informacin en diferentes capas para su posterior visualizacin. Se sabe de la existencia de numerosos GIS y que son capaces de satisfacer estas necesidades. Por ello se intentar aprovechar, en la medida de lo posible, alguna herramienta que ya exista en el mercado.
2.2.3.
Criterios de seleccin de GIS
Como se ha comentado anteriormente se precisa de un sistema o librera GIS para poder cubrir una serie de necesidades presentes a la hora de afrontar el proyecto SKY-EYE. Se realizar un estudio de investigacin analizando software GIS, en primer lugar en base a la documentacin referida a ellos, y en segundo lugar con pruebas de software. En los Anexos C y D se pueden consultar los documentos completos para la seleccin de GIS. Para el estudio de documentacin se determinar cules son las caractersticas ms importantes a tener en cuenta en los GIS, a la hora de cumplir los requerimientos del proyecto. Cada una de las caractersticas tiene un peso diferente sobre el conjunto y se puntuar con una nota entre 0 y 10. Las caractersticas tenidas en cuenta son las siguientes: programabilidad / cdigo abierto, formatos, Gestin de Base de Datos, Licencia, Georeferenciacin / Ortonormalizacin y Sistema Operativo. Una vez realizada la primera seleccin de GIS, se realiza un anlisis ms profundo mediante pruebas de software prcticas, en concreto: - Cargar cartografas y ortofotos que tengamos en el ordenador o a travs de Internet (WMS, WFS, WCS, ArcIMS)
17
Crear distintas capas y comprobar su funcionamiento intentando georeferenciar informacin Guardar y conectar con Base de datos Observar estructura de cdigo base
Se intentar encontrar el programa que mejor realice estas tareas, para poderse ahorrar trabajo a la hora de programar la aplicacin. Coincidiendo en el transcurso de esta fase, en la Fira de Barcelona se celebrar los das 20, 21 y 22 de febrero la feria GlobalGeo. sta esta dedicada al mundo de la geomtica y geotelemtica. Es de gran inters su asistencia ya que se podr recaudar informacin, experiencias, contactos, intereses de primera mano. El informe de la visita a GlobalGeo se encuentra en el Anexo F.
2.2.4.
Evaluacin y seleccin de GIS
La tabla siguiente muestra los resultados obtenidos tras la evaluacin de los GIS seleccionados en base a las caractersticas que se eligieron (Tabla 2.1).
Mark ARCGIS GvSIG QUANTUM TerraLib GRASS ERDAS PostGIS Program. 40%
VB C++ C# Java C++ C++ Cdigo Abierto C++ C C++ Java PLRuby
Formatos 20%
BBDD 15%
SI SI PostGre SQL SI SI SI SI SI NO SI SI SI SI SI
Licencia 15%
Georef. & Orto. 5%

SI Geo Geo Geo SI ? Geo NO ? Geo SI ? ?
SO 5%
Cualquier Conocido Win Linux Mac OSX Windows Linux Windows Linux Linux Win2000 WinXP ? Windows Windows ? Linux Windows Windows ? Windows Linux
8,50 8,20 8,20 7,50 7,30 7,25 6,35
10 8 8 8 8 7 6 5
10 8 8 5 7 10 7 8 8 6 5 7 8 6
10 9 9 9 7 10 6 8 0 5 7 7 10 8
GNU Version Pro 300 Soft Libre GNU GPL Licencia 228 ? Freeware GNU GPL Soft Libre Soft Libre Soft Libre
0 9 9 9 7 0 7 4 6 7 6 5 1 0
10 6 6 5 6 10 5 7 0 2 5 7 6 5
10 8 8 7 6 9 7 7 9 5 6 8 6 5
Map Marker 6,10 GDAL / OGR HidroGIS Kosmos MiraMon OracleSpatial Spring
5,75 5,75 5,50 3,95 3,85 2,90
C++ Java Java
7 6 5 0 0
Cdigo Cerrado
Tabla 2.1 Resultado de la evaluacin de GIS por documentacin Como resultado podemos diferenciar tres grupos de GIS: - Grupo Amarillo: GIS prcticamente descartados. El motivo es la falta de informacin o que no tienen un mnimo de aspectos de inters. - Grupo Naranja: GIS de inters, pero por diferentes motivos no acaban de ser adecuados. - Grupo Rojo: GIS que cumplen prcticamente con todos los factores de inters del anlisis. Cualquiera de ellos, con lo que se ha visto hasta ahora, podran servir para el proyecto.
18
2.2.5.
Eleccin Final
Una vez analizados los sistemas GIS en profundidad se debe llegar a una conclusin sobre qu camino se debe seguir, y para ello se debe elegir uno de los softwares aqu mencionados. Como aspecto positivo de esta etapa, se valora la variedad de posibilidades. Esto permite tener ms alternativas a la hora de empezar a trabajar. En consecuencia, el aspecto negativo, es el que brinda cualquier decisin: el saber si ste es el camino correcto. Tras muchas investigaciones se llega a las siguientes conclusiones. La herramienta que se necesita debe ser capaz de solventar de antemano los problemas bsicos que genera el trabajo con mapas. Tambin es Lo importante es tener una herramienta capaz de solventar de antemano los problemas bsicos que genera el trabajo con mapas. De esta manera se deber centrar casi toda la atencin en desarrollar la nueva aplicacin. Tambin es importante tener las herramientas necesarias para poder solventar futuros atascos lo ms rpido posible. Dicho esto, se ha considerado que el pack de desarrollo de ArcGIS podr adecuarse muy bien a los intereses de SKY-EYE, si bien es verdad que se debe asumir un gasto adicional. ArcGis requiere de licencia de desarrollo, pero ante la posibilidad de poder llegar a la meta de SKY-EYE supone una inversin muy necesaria y que garantiza un trabajo de calidad. Esta herramienta de desarrollo ArcGis es uno de los productos ms conocidos de la empresa ESRI. ESRI es una de las compaas lderes en el sector GIS a nivel mundial. Si bien es cierto que antes de iniciar el proceso de seleccin ArcGis ya era la herramienta ms completa que cumpla los requisitos para el proyecto, era necesario realizar una seleccin y anlisis de los sistemas GIS ms importantes en el mercado.
2.2.
Cartografas
La cartografa es una disciplina que integra ciencia, tcnica y arte, que trata de la representacin de la Tierra sobre un mapa o representacin cartogrfica. Al ser la Tierra esfrica ha de valerse de un sistema de proyecciones y coordenadas para pasar de la esfera al plano. Adems de representar los contornos de las cosas, las superficies y los ngulos, se ocupa tambin de representar la informacin que aparece sobre el mapa, segn se considere qu es relevante y qu no. En la cartografa, la tecnologa ha evolucionado para dar servicio a nuevas demandas y nuevos usuarios. Actualmente estas representaciones se realizan con aplicaciones GIS, en las que se puede georeferenciar cualquier tipo de informacin sobre un mapa de manera rpida y sencilla con resultados mucho ms visuales e interactivos.
19
Son muchos los tipos y estilos de cartografas usados, pero el ms interesante para el proyecto es el llamado ortofotografa. La ortofotografa es una presentacin fotogrfica de una zona de la superficie terrestre, en el que todos los elementos presentan la misma escala, libre de errores y deformaciones, con la misma validez de un plano cartogrfico. Una ortofoto se consigue mediante un conjunto de imgenes areas que han sido corregidas digitalmente para representar una proyeccin ortogonal sin efectos de perspectiva, y en la que por lo tanto es posible realizar mediciones exactas. Al contrario que sobre una fotografa area simple, que siempre presentar deformaciones causadas por la perspectiva desde la cmara, la altura o la velocidad a la que se mueve la cmara. A este proceso de correccin digital se le llama ortorectificacin.
2.3.
Plan de vuelo
Un plan de vuelo es un informe dnde se indican los datos referentes a un vuelo. En ste, adems debe constar informacin relacionada con el lugar de salida, destino, altitudes, velocidades de crucero, puntos de paso de la ruta, planes de emergencia alternativos, etc. La correcta definicin de un plan de vuelo es muy importante, en especial para UAVs ya que no tienen un piloto humano a bordo para poder pasar a control manual. Antes de empezar a disear el plan de vuelo hay que realizar una buena recopilacin de informacin. Interesa conocer informacin como la orografa de la zona que se sobrevolar, las construcciones civiles tanto viviendas, carreteras, industria, etc., las condiciones meteorolgicas, la misin del vuelo, trfico areo, entre otras. Una vez recopilada se pasar a disear el plan de vuelo relacionado con la misin a cumplir. El proyecto SKY-EYE necesita establecer una especificacin para planes de vuelo, de tal forma que incluyan todas las necesidades del proyecto y del UAV. En el contexto del proyecto, un plan de vuelo se refiere a la ruta que el UAV debe seguir. No se refiere al documento ms completo que define la autoridad area OACI (Organizacin de Aviacin Civil Internacional). Para su especificacin es necesario identificar todos los elementos que forman parte de un plan de vuelo y la relacin entre ellos.
20
Figura 2.2 Ejemplo sencillo de plan de vuelo El esquema muestra un ejemplo simple de un plan de vuelo (Figura 2.2). La especificacin de plan de vuelo podr definir planes de vuelo cmo el mostrado en la figura. Los objetivos de este proyecto se centran en este punto, en trabajar con la especificacin de plan de vuelo. En los captulos posteriores de Especificacin y Diseo se analiza este tema en profundidad.
2.4.
2.3.1.
Estacin de seguimiento
Introduccin
El UAV establecer dos flujos de comunicacin con tierra durante el vuelo. La estacin de seguimiento se encargar de recopilar y tratar toda la informacin que provenga de las dos comunicaciones. En esta primera fase del proyecto, la aplicacin se centrar en el tratamiento de paquetes propiamente de seguimiento con informacin de telemetra que proviene de la primera comunicacin. Tambin se tratarn paquetes de la segunda comunicacin que contienen informacin acerca del seguimiento de la misin y de captura de datos de la plataforma de observacin del UAV. Las dos comunicaciones se encuentran en fase de desarrollo y definicin, no se puede disponer de un streaming de datos definitivo. La estructura y organizacin de los datos no est acabada pero si se sabe cul ser la informacin que contengan.
2.3.2.
Informacin como un servicio
Toda la informacin relacionada con los datos que se recibirn una vez el avin haya despegado puede encontrarse en el documento Service Abstraction Layer for UAV Flexible Application Development en el Anexo I.
21
En este documento se explica el funcionamiento de envio de datos. Si se requiere de algn dato del UAV, se debe realizar una suscripcin al servicio de envo. Existirn muchos usuarios de este servicio, que est conectado al UAV a travs de una red de comunicaciones. El diagrama a continuacin explica grficamente el sistema (Figura 2.3).
Figura 2.3 Arquitectura del sistema de comunicacin
2.3.3.
Paquetes de telemetra
Como se ha explicado anteriormente, an no se dispone de la versin definitiva de ste tipo de paquete, pero s sabemos qu informacin contendrn y como estarn estructurados. El paquete de telemetra que se enviar ser un conjunto de paquetes de informacin especfica. Cuando el cliente se subscriba al servicio de telemetra podr seleccionar que paquetes de informacin especfica quiere recibir. Los diferentes paquetes de informacin se muestran en la tabla (Tabla 2.2).
Nombre uavAngles Componentes Roll Pitch Yaw X Y Z X Y Z Latitude Longitude Altitude(MLS) True Altitude North East Down Indicated airspeed True airspeed Time Time Time Time Tipo de Datos Float Rango 0 to 2 rad. Unidades radians Descripcin Roll, pitch y Yaw angulos del UAV. Aceleracin del UAV en las coordenadas X, Y y Z. Tasa de giro del UAV para las coordenadas X, Y y Z.
uavAccelerate
Float
Device range
m/s2
uavRateTurn
Float Double Double Float Float Float Float Float Float Float Integer Integer Integer Integer
UAV range 0 to 2 0 to 2 UAV range UAV range UAV range UAV range UAV range UAV range UAv range
rad/s radians radians meters meters m/s m/s ms ms ms ms
uavPosition
Posicin 3D del UAV.
uavSpeed airSpeed flightTime totalTime missionTime maxTime
Velocidad 3D del UAV. Informacin de Velocidad del Viento en el UAV Tiempo del UAV volando. -----------Duracin de la misin tiempo BINGO
Tabla 2.2 Informacin de telemetra del vuelo
22
2.3.4.
Paquetes de misin
Los paquetes que genere el UAV con informacin an no estn definidos, tan slo hay algunas ideas y esbozos. La idea es que haya un paquete con tres tipos de informacin posible. El primero de ellos tan slo tendr informacin general de la misin pero no el resultado de ella (por ejemplo podr indicar que se ha tomado una fotografa pero no contendr dicha fotografa), el segundo contendr la misma informacin y adems el resultado de la misin pero en baja resolucin, una compresin, y el ltimo contendr la informacin de la misin y la fotografa ya en resolucin sin modificar. Cmo se dijo en el apartado de Tecnologa del Captulo 1, ste flujo de comunicacin requiere un gran ancho de banda. Al no poder asegurar la calidad de la conexin en todo momento se disean tres tipos de paquetes de tamaos diferentes. Los datos de misin que contendr el paquete an no estn definidos. A medida que se desarrolle la aplicacin, se ver qu datos son importantes para una misin, a partir de esto se disear e implementar un primer prototipo del conjunto de paquetes de misin.
Especificacin
23
CAPTULO 3. ESPECIFICACIN
Una vez analizado el estado del proyecto y todos sus temas relacionados, es necesario realizar un anlisis ms profundo de los puntos ms importantes del proyecto. A continuacin, con el anlisis completado, se pasar a concretar los objetivos personales del proyecto y a organizar una planificacin ms detallada acorde con los objetivos finales.
3.1.
Plan de vuelo
Una vez analizado el tema de planes de vuelo, se pasa a realizar un anlisis ms especfico. Antes de pasar al diseo de un diagrama de clases acorde, se debe estudiar cmo es el modelo conceptual del plan de vuelo del proyecto. La definicin de este modelo conceptual no corre a cargo de este proyecto sino de otro grupo de trabajo del grupo ICARUS. Cabe indicar que se trata de una de las primeras versiones del modelo desarrolladas, se puede consultar en el Anexo H, es posible que durante el proceso de diseo e implementacin surjan problemas de estructura que den lugar a un refinamiento del modelo conceptual final. Los elementos principales para el modelo conceptual son FlightPlan (Plan de vuelo), Stage (Etapa), Leg (Trayectoria) y Waypoint (Punto de paso). Un plan de vuelo contiene diferentes Stages, cada una de ellas contiene un conjunto de Legs. Un Waypoint es una posicin en el espacio que se usa como punto de paso, un Leg es la trayectoria que une dos Waypoints. En la figura siguiente (Figura 3.1) se puede ver grficamente cuales son las relaciones entre los diferentes elementos.
Figura 3.1 Modelo conceptual de plan de vuelo FlightPlan Un plan de vuelo define el camino seguido por el avin. Cada plan de vuelo est compuesto por una secuencia de Stages en orden correcto. La secuencia debe ser: Take-Off Departure Procedure Route Mission Approach Route Arrival Land. No slo se dispondr de un plan de vuelo principal, sino tambin se debern definir planes de vuelo alternativos para situaciones de emergencia.
24
El elemento FlightPlan contendr un nombre, descripcin, si es o no el plan de vuelo principal, la secuencia de Stages y un indicador de cul es el primer leg. Stage Un Stage es cada una de las etapas que componen un plan de vuelo, y est formado por todo un conjunto de legs. Un Stage tiene las caractersticas siguientes: - Cada stage debe corresponder correctamente a una fase del vuelo. - Salvo el primer y ltimo stage, todo stage tiene un nico predecesor y un nico sucesor. - Un stage puede tener ms de una salida igual que ms de una entrada. - Para unir las diferentes salidas de un stage con las entradas del siguiente se definir una estructura de intersecciones. - En un stage habr el mismo nmero de entradas que de salidas, correspondiendo cada una de las entradas a una nica salida. El elemento Stage contendr un nombre, una descripcin, el tipo de fase, el conjunto de legs que lo forman, y un listado de entradas y otro de salidas. Leg Un Leg define la trayectoria entre dos Waypoints. El parmetro dest especifica cual es el waypoint destino. Los parmetros next y prev indican cual es el siguiente y el anterior leg. El waypoint origen del leg corresponde al waypoint destino del leg anterior. Segn las necesidades del proyecto, se definen diferentes tipos de legs: - Parametric legs: la trayectoria viene definida por una funcin paramtrica. - Iterative legs: indican secuencias de repeticin de una misma trayectoria. - Intersection legs: son aquellas trayectorias que pueden contener una interseccin. - Basic legs: son las trayectorias bsicas, cmo lneas rectas, etc. As un Leg contendr un waypoint de destino dest, una referencia al leg anterior y posterior prev y next, un posible plan de vuelo de emergencia emergency, y una referencia al stage el cual pertenece. En esta primera fase no se trabajar con todos los tipos de legs, sino que slo se implementarn los Basic legs. Estos son los diferentes tipos que existirn: - Initial Fix: determina el punto de inicio de un plan de vuelo. - Track to Fix: es una trayectoria recta de un waypoint a otro. - Direct to Fix: es una trayectoria recta desde el punto actual, sea cual sea, directamente a un punto destino. - Radius to Fix: es una trayectoria en arco hacia un waypoint destino. - Holding Pattern: indica una trayectoria eliptica alrededor de un punto hasta nueva orden.
Especificacin
25
Eight Turn: es una trayectoria en arco que empieza y acaba en el mismo waypoint.
Waypoint Un Waypoint es una posicin geogrfica en el espacio definida en coordenadas geogrficas de latitud y longitud. Se definirn dos tipos de waypoints, Named Waypoints y Unnamed Waypoints. Los primeros son aquellos que indican una posicin conocida, se les llamar Fix y tendrn un nombre y descripcin. Los segundos son simplementes puntos en el espacio sin un nombre concreto. El waypoint posee una caracterstica que define como se debe sobrevolar, flyover especifica que se debe pasar por encima de l y fly-by indica que tan slo es necesario volar cerca de l (Figura 3.2).
Figura 3.2 Diferencia de trayectorias entre fly-by y fly-over.
El elemento Waypoint contiene como informacin propia una altura, velocidad y si es fly-by o fly-over (Figura 3.3). Las caractersticas de coordenadas y los posibles nombres y descripciones las contendrn los subelementos Fix o UnnamedWP.
Figura 3.3 Modelo conceptual para el elemento Waypoint.
26
3.2.
Concrecin de objetivos
Despus de analizar cada uno de los temas relacionados con el proyecto como son GIS, plan de vuelo, cartografas y seguimiento de telemetra y misin, se deben revisar los objetivos. Los objetivos finales sern ms concretos y ordenados y servirn para realizar la nueva planificacin. Los objetivos son: 1. Diseo de una estructura de clases para plan de vuelo acorde con el modelo conceptual definido en el proyecto. 2. Implementacin de un sistema lector de planes de vuelo en formato XML para la estructura de clases anterior. 3. Diseo de un gestor de cartografas para la aplicacin con su estructura de clases correspondiente. 4. Disear un sistema para guardar la informacin del gestor fuera de la aplicacin, en un archivo XML. 5. Implementar una metodologa que relacione los parmetros del plan de vuelo cargado con las cartografas disponibles en el gestor. 6. Disear una estructura de clases para la informacin de telemetra. 7. Disear un paquete de telemetra en XML acorde con el modelo conceptual. 8. Implementar una simulacin de conexin con UAV con envo de informacin de telemetra. 9. Disear una estructura de clases para la informacin de misin. 10. Disear un paquete de misin en XML acorde con el modelo conceptual. 11. Implementar una simulacin de conexin con UAV con envo de informacin de misin.
3.3.
Planificacin detallada
Una vez analizados a fondo los temas que rodean el proyecto y concretado los objetivos, se pasa a planificar las tareas que se llevarn a cabo a partir de este momento. En este punto, el proyecto ya se encuentra demorado alrededor de 1 mes con respecto a la planificacin inicial. En el diagrama de Gant siguiente se muestra la planificacin a seguir durante la etapa de diseo e implementacin para este proyecto (Figura 3.4). Los tres flujos de trabajo debern finalizar el da 10 de abril para pasar al desarrollo de componentes e integracin del sistema. Est planificado el final del proyecto para el da 6 de junio. El diagrama completo se puede consultar en el Anexo A.
Especificacin
27
Figura 3.4 Planificacin detallada para la fase de Diseo.
28
CAPTULO 4. DISEO
En este captulo se analizan las herramientas que se utilizarn para el desarrollo de la aplicacin. Despus se pasar a disear las estructuras de clases que se necesitan. Es importante tener una buena base de conocimientos acerca de las herramientas de desarrollo que se utilizarn antes de empezar a disear.
4.1.
Plataforma .NET
.NET es una nueva plataforma de Microsoft para el desarrollo y ejecucin de aplicaciones que se basa sobre una mquina virtual que aglutina mltiples tecnologas preexistentes. La plataforma es capaz de soportar mltiples lenguajes y nuevos dispositivos como PDAs, Smartphones, Microsoft pretende reemplazar la Interfcie de Programacin de Aplicaciones (API) Win32 o WindowsAPI. .NET solventa la falta de documentacin detallada, uniformidad y cohesin entre componentes de stas dando lugar a un conjunto nico y expansible con facilidad. Estas cualidades han dado lugar a que muchas otras empresas e instituciones se hayan unido en el desarrollo de la plataforma. La plataforma software .NET se basa en un nuevo nivel .NET Framework y en una nueva herramienta de desarrollo Visual Studio (Figura 4.1). Los objetivos de Framework son los siguientes: - Aportar un entorno de ejecucin robusto y seguro: el Common Language Runtime. - Simplificar la gestin y administracin de aplicaciones, simplificar el de desarrollo de aplicaciones gracias a las Base Class Libraries - Dar soporte a mltiples dispositivos y a mltiples leguajes de programacin Common Language Specification.
Diseo
29
Figura 4.1 Estructura general de .NET
El .NET Framework constituye la base de la plataforma .NET y denota la infraestructura sobre la cual se renen un conjunto de lenguajes, herramientas y servicios. Actualmente .NET Framework soporta ms de 30 lenguajes de programacin, tambin da soporte tanto a aplicaciones Windows, aplicaciones Web con ASP.NET y a aplicaciones en dispositivos con .NET como smartphones, Pocket PCs, etc. Microsoft necesitaba un nuevo lenguaje para .NET. ste nuevo lenguaje debera ser orientado a objetos y componentes y que soportara las construcciones de .NET. Este nuevo lenguaje es C# y se trata de un lenguaje muy similar a Java y C++, en parte para atraer a programadores de estos lenguajes. C# posee gran cantidad de libreras y documentacin y est orientado a la red, da soporte a un gran nmero de protocolos: HTTP, FTP, etc. y tambin a aplicaciones y servicios Web.
30
4.2.
XML
XML (del ingls eXtensible Markup Language) es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). XML no es realmente un lenguaje en particular, sino una manera de definir lenguajes para diferentes necesidades. Este lenguaje no se cre solo para su aplicacin en internet, sino que se propone como un estndar para el intercambio de informacin estructurada entre diferentes plataformas. Se puede usar en bases de datos, editores de texto, hojas de clculo, etc. XML es una tecnologa sencilla que tiene a su alrededor otras que la complementan y la hacen mucho ms grande y con unas posibilidades mucho mayores. Tiene un papel muy importante en la actualidad ya que permite la compatibilidad entre sistemas para compartir la informacin de una manera segura, fiable y fcil. Las ventajas del uso de XML son muchas: - Es extensible, lo que quiere decir que una vez diseado un lenguaje y puesto en produccin, igual es posible extenderlo con la adicin de nuevas etiquetas de manera de que los antiguos consumidores de la vieja versin todava puedan entender el nuevo formato. - El analizador es un componente estndar, no es necesario crear un analizador especfico para cada lenguaje. Esto posibilita el empleo de uno de los tantos disponibles. De esta manera se evitan bugs y se acelera el desarrollo de la aplicacin. - Si un tercero decide usar un documento creado en XML, es sencillo entender su estructura y procesarlo. Mejora la compatibilidad entre aplicaciones. La tecnologa XML busca dar solucin al problema de expresar informacin estructurada de la manera ms abstracta y reutilizable posible. Que la informacin sea estructurada quiere decir que se compone de partes bien definidas, y que esas partes se componen a su vez de otras partes. Entonces se tiene un rbol de pedazos de informacin, estas partes se llaman elementos, y se las seala mediante etiquetas. Una etiqueta consiste en una marca hecha en el documento, que seala una porcin de este como un elemento, un pedazo de informacin con un sentido claro y definido. Las etiquetas tienen la forma <nombre>, donde nombre es el nombre del elemento que se est sealando. Los documentos XML se pueden estructurar y restringir de una forma muy precisa mediante un lenguaje de esquema XML Schema Definition (XSD). XSD es un lenguaje de esquema escrito en XML basado en la gramtica y pensado para proporcionar una mayor potencia expresiva que la DTD (Definicin de Tipo de Documento). Estos documentos esquema se concibieron como una alternativa a las DTD intentando superar sus debilidades. Su principal aportacin es el gran nmero de tipos de datos que incorpora.
Diseo
31
4.3.
ArcGis Development Kit
ArcGIS ofrece a travs del kit de desarrolladores una serie de herramientas para poder programar nuevos programas relacionados con el mundo de la geomtica. De esta manera, el programador consigue tener a su disposicin mucho cdigo de funciones bien resueltas de manera rpida y estructurarlas a su conveniencia. De esta manera se puede acceder a todos las funciones de escritorio que se aprecian en los programas de ArcGIS, ya sea de dibujar una lnea, como cargar un mapa a travs de WMS. Este development kit provee acceso a una larga coleccin de componentes ArcObjects (los componentes con los que se construye ArcGIS) y tambin incluye varios controles de desarrollo con el fin de crear software de gran calidad. Los componentes visuales estn disponibles como controles .NET, controles JavaBeans, y ActiveX. El development kit puede ser utilizado tanto en Windows, Linux, o el sistema operativos Solaris. Como ayudas adicionales a los programadores, el kit viene acompaado de un Development kit help, en el que se describen las interficies, funciones, mtodos y todo lo que se pueda encontrar en el development kit y genere algn tipo de duda, as como ejemplos de programas. Tambin se puede consultar el foro de programadores que ofrece ArcGIS. Para poder empezar a instalar el kit de desarrollo se debe tener ya instalado algn entorno de programacin. Cmo los integrantes del grupo de trabajo estn familiarizados con Visual Studio .NET, se ha escogido este entorno para programar la nueva interficie visual. Son muchas las libreras que se facilitan con el development kit. Como es de esperar no todas ellas son necesarias. Se valora la gran variedad de posibilidades que permite el Developer kit, pero para empezar se utilizarn muy pocas. Entre ellas estn System, SystemUI, Geometry, Display, Carto, GeoProcessing y Controls. Developer Kit tambin proporciona a la plataforma .NET todo un conjunto de controles visuales: ArcGis Windows Forms. Estos controles son los siguientes: MapControl, PageLayoutcontrol, ToolbarControl SceneControl, GlobeControl, TOCControl, LicenseControl y Symbologycontrol. De esta forma se trabajar con herramientas GIS de la misma manera que se puede trabajar con botones, labels, paneles, etc.
32
4.4.
4.4.1.
Diseo de estructura de clases

Plan de Vuelo
La estructura de clases diseada para el plan de vuelo sigue el modelo conceptual que se analiz en captulos anteriores. La estructura intenta seguir el diagrama XSD para planes de vuelo definido acorde con el modelo conceptual por ICARUS. A continuacin se muestra una vista general de cmo ser el diagrama de clases (Figura 4.2).
Figura 4.2 Diagrama de clases para el Plan de Vuelo
El elemento principal de la estructura ser FlightPlan y ser nico. ste se compondr de tres elementos llamados FlightPlanType, EmergencyPlans y Fixes. EmergencyPlans contiene un listado de planes de emergencia para el plan de vuelo y Fixes contiene un listado de FixType, que corresponden a los Fixes del modelo conceptual.
Diseo
33
FlightPlanType tendr atributos con informacin propia de plan de vuelo cmo Id, name, description, etc. adems de un elemento Stages. ste elemento tiene a su vez una relacin 1 a n de StageType. StageType corresponde al elemento de stage del modelo conceptual, as tiene los elementos initialLegs, finalLegs y Legs. Legs es un listado de elementos LegType. LegType s la clase padre para los legs, cmo tenemos diferentes tipos de legs, LegType tiene tres herencias, una para cada tipo de leg: TFLeg, IFLeg y RFLeg. Adems para cada LegType tenemos un elemento WaypointType. sta es la estructura generalizada de clases, todos los atributos de los elementos son los que se definen en el modelo conceptual. En cuanto a los mtodos, tan slo se necesitan los de consulta de informacin. Toda la informacin de plan de vuelo se cargar en la estructura a travs de los constructores que leern de un archivo XML.
4.4.2.
Gestor de Cartografas
Tal y como se ha definido en captulos anteriores, el gestor de cartografas debe almacenar un registro de las cartografas cargadas en la aplicacin. La estructura que se seguir ser la que se puede ver en el diagrama (Figura 4.3). El elemento principal PhotoGroups contiene un listado groups de elementos Group. Cada uno de estos elementos representa a un grupo de cartografas que comparten un mismo tipo, formato, resolucin y localizacin, de esta manera cada grupo tendr un listado (FotoList) de fotografas (FotoType). De cada fotografa interesa almacenar el rea que cubre para posteriormente hacer bsquedas por zonas.
Figura 4.3 Diagrama de clases para el Gestor de Cartografas
34
4.4.3.
Seguimiento de telemetra
La estructura de clases (Figura 4.4) para el seguimiento de telemetra seguir el modelo conceptual definido en el documento Service Abstraction Layer for UAV Flexible Application Development en el Anexo I. Un paquete completo de telemetra (TelemetryPackage) podr contener hasta 10 tipos de paquetes de informacin diferentes. Cada uno de ellos est organizado en su clase correspondiente como son: ratetrun, acceleration, airspeed, position, speed, angles y time. ste ltimo se comparte para 4 informaciones distintas, pero que todas son informacin temporal. Tambin se definir una clase Package en la que se almacenarn cada uno de los TelemetryPackage que se vayan generando.
Figura 4.4 Diagrama de clases para el Seguimiento de Telemetra
4.4.4.
Seguimiento de misin
La estructura de clases para el seguimiento de misin no sigue ningn esquema conceptual definido, tan slo se tiene conocimiento de cul ser la informacin que contiene el paquete. Las clases para esta estructura (Figura 4.5) estarn definidas en la misma librera de clases que la estructura para seguimiento de telemetra. Esto se debe a que comparten algunas clases. Un paquete de misin (MissionPackage) contiene informacin de telemetra del UAV como son los tiempos, la posicin y los ngulos, para stas se utilizarn las clases ya definidas anteriormente. missioninfo contiene informacin propia
Diseo
35
de la misin y adems un elemento missiondata y otro missioncamera. En el primero est la fotografa en s del paquete de misin, y en el segundo los parmetros de la cmara que ha tomado la fotografa. Esta informacin es necesaria para ms tarde poder hacer el tratamiento de la fotografa (georeferenciacin y ortonormalizacin).
Figura 4.5 Diagrama de clases para el Seguimiento de Misin
36
CAPTULO 5. IMPLEMENTACIN Y PRUEBAS
5.1.
Implementacin
Segn los diseos de diagramas de clases del captulo de Diseo se pasa a implementar las libreras. Se implementarn tres libreras: FlightPlan, BBDD_Fotos y RecievedInfo. La primera se encarga de la gestin de planes de vuelo, parsea el archivo XML correspondiente y vuelca la informacin en la base de datos. La segunda librera corresponde al gestor de cartografas, parsea el archivo XML dnde se guarda el registro y lo vuelca en la base de datos, tambin consulta la base de datos de plan de vuelo para seleccionar las fotos relacionadas. La tercera y ltima se encarga del seguimiento de telemetra y misin, hace la simulacin de la comunicacin y almacena la informacin recibida en las bases de datos dedicadas. En la figura siguiente (Figura 5.1) se puede ver un esquema general de la arquitectura de libreras. A continuacin se pasa a detallar cada una de ellas.
Figura 5.1 Esquema de arquitectura para las libreras a implementar
5.1.1.
Librera FlightPlan
Tal y como se dise en el captulo anterior, la estructura de clases para FlightPlan sigue el modelo conceptual definido. Al tratarse de un modelo en fase de desarrollo durante la implementacin han surgido algunos problemas que no estaban resueltos. Las clases se han organizado en tres grupos: ComplexType, Elements y SimpleType. Los dos primeros forman el peso de la librera y dando lugar a la
Implementacin y pruebas
37
estructura general del modelo. En el tercer grupo se encuentran clases an por acabar de definir cmo toda la organizacin de id para todos los elementos de un plan de vuelo. Un id bien definido ha de ser nico e irrepetible, que slo sea el id de un solo elemento, para ello se ha de definir todo un sistema de nomenclatura que hasta el momento no est hecho. Es por esto que todos los campos de id se han substituido por string, as aunque no acten como verdaderos identificadores s que se podrn leer. Otro de los problemas observados durante la implementacin fue acerca de la clase Coord. Este elemento, en el modelo conceptual, sirve para indicar una posicin en el espacio en coordenadas hexadecimales (grados, minutos y segundos). El problema no surge al definir la clase, sino al hacer uso de ella. En la aplicacin visual, como zona de visualizacin, se utilizan herramientas de ArcGis. Estas herramientas, el sistema de coordenadas predefinido es el mtrico. Existen numerosos sistemas de coordenadas mundiales, y en especial el hexadecimal requiere un conjunto de clculos y transformaciones complejas hasta llegar al mtrico. Al no conseguir resultados correctos para dichas transformaciones, se opt por eliminar la clase Coord y substituirla por float para utilizar coordenadas mtricas. FlightPlan es una estructura de clases con un uso principal de almacenamiento. La informacin se carga a travs de los constructores mientras se lee un archivo XML, y se extrae con mtodos en todas las clases. Tan slo hay un mtodo llamado damearea en la clase FlightPlan. Este mtodo se encarga de recorrer todo el plan de vuelo y devolver el rea que cubre ste. damearea se utiliza en la visualizacin para centrar el mapa en el plan de vuelo y por el gestor de cartografas para buscar cartografas asociadas a esa rea.
5.1.2.
Librera BBDD_Fotos
La librera de clases BBDD_Fotos se ha implementado siguiendo el diseo de diagrama de clases. sta librera da servicio a un gestor visual de cartografas desde el que se pueden consultar, aadir o borrar cartografas. Adems la informacin relacionada debe almacenarse externamente a la aplicacin para que en posteriores usos de la aplicacin se conserve la informacin del gestor. Las clases proporcionan mtodos al gestor para consulta de todos los datos contenidos en ellas. Al arrancar la aplicacin, la carga de informacin en la estructura de clases se hace con los constructores al leer el archivo Fotos.xml que contiene el ltimo estado del gestor. Mientras la aplicacin se est ejecutando, se puede aadir informacin a la estructura con el mtodo Insert_group de la clase PhotoGroups. Cada vez que se modifica el contenido de la estructura de clases, la clase PhotoGroups se encarga de sobrescribir el archivo Fotos.xml con el nuevo estado de informacin del gestor.
38
La informacin que contienen los FotoType, rea de trabajo, se obtienen al cargar el archivo cartogrfico en una capa raster. sta capa es una herramienta de ArcGis, es una capa con informacin geogrfica en la que se puede georeferenciar informacin, principalmente fotogrfica. A travs del raster se puede consultar cuales son las coordenadas que cubre la fotografa. Un mtodo muy importante en PhotoGroups es Buscar_Grupos. ste se encarga de retornar un elemento PhotoGroups con tan slo los grupos de cartografas que cumplen los requisitos del plan de vuelo. Aqu es donde se utiliza el mtodo dameaera de FlightPlan. El visualizador muestra al usuario el resultado de la bsqueda para que antes y durante la visualizacin, de un plan de vuelo, pueda elegir que cartografas cargar. Otro mtodo interesante en esta librera es el de area_completa. ste mtodo se encarga de, una vez se ha realizado la bsqueda de cartografas para un rea determinada de plan de vuelo, mirar si el grupo de cartografas cubre por completo el rea o slo parcialmente. Para ello calcula intersecciones de reas entre plan de vuelo y cartografas hasta completar el rea.
5.1.3.
Librera ReceivedInfo
La librera de clases ReceivedInfo tiene un uso completamente de almacenamiento. Los elementos principales son MissionPackage y TelemetryPackage. Como se ha diseado una simulacin de streaming de datos, stos vienen en archivos de formato XML, as que las dos clases anteriores son las encargadas de, con los constructores, leer los archivos. Los atributos referentes a informacin de telemetra del UAV se han implementado de forma que no son obligatorios. La especificacin detalla que el envo de paquetes de telemetra se hace a travs de suscripcin pudindose elegir qu paquetes se quieren recibir. La clase MissionPackage no da servicio directamente al visualizador, sino que da servicio a otra clase. Esta clase almacena toda la informacin de misin y adems genera de nueva relacionada con las proyecciones de la cmara utilizando algoritmos de fotogrametra. Todo el contenido de esta nueva clase se lleva a cabo por otro miembro del grupo de trabajo, Miryam Gonzalez, y se puede consultar en el TFC Estacin de seguimiento SKY-EYE para UAVs: mecanismos de georeferenciacin y ortorectificacin de imgenes areas.
39
5.2.
Pruebas individuales
El correcto funcionamiento de los diferentes elementos de las estructuras de clases se ha puesto a prueba durante la implementacin de los mismos. Se ha sometido a cada elemento a pruebas de validacin que slo afectaban a s mismo. De esta forma se ha comprobado que cada elemento cumpla, con el diseo propuesto y la implementacin del mismo, los requerimientos establecidos. La librera FlightPlan es la ms compleja e importante de las que se implementan. Al tratarse de una librera de clases que se cargaban desde archivo XML con un XSD determinado, era muy subceptible a errores. La lectura del archivo se realiza con un XmlReader que se pasa a travs de los constructores de un elemento a otro. Es en este punto donde se realizaron la mayor parte de las pruebas de interaccin adems de las individuales para cada uno de los elementos. En caso de la librera BBDD_Fotos, se utilizaban herramientas del Development Kit, se realizaron pruebas de extraccin de informacin de los raster. Para cada una de las fotografas que se aade a la clase se necesitan las coordenadas del rea que cubre. El mtodo que caus ms problemas fu el de area_completa porque se utilizaban mtodos geomtricos complejos con muchas variables. La librera ReceivedInfo con las clases principales TelemetryPackage y MissionPackage no ha necesitado pruebas complejas, tan slo de comprobacin de carga del archivo XML.
5.3.
Integracin del sistema y pruebas
El paso final en el desarrollo de la aplicacin es integrar las tres partes de los flujos de trabajo. La documentacin de las otras dos partes se puede consultar en las memorias Estacin de seguimiento SKY-EYE para UAVs: integracin visual de componentes de seguimiento y georeferenciacin sobre GIS de Juan Manuel Lema y Estacin de seguimiento SKY-EYE para UAVs: mecanismos de georeferenciacin y ortorectificacin de imgenes areas. Una vez acabadas las partes se pasa a integrarlas y a realizar las pruebas necesarias. Al integrar cada una de las partes, hay que tener muy en cuenta la estructuracin de la aplicacin. La arquitectura que se sigue para el diseo de la aplicacin es la llamada Arquitectura de 3 capas. Las capas son las de datos, de negocio y de presentacin. La capa de presentacin es la que presenta el sistema al usuario, le comunica la informacin y captura la informacin del usuario dando un mnimo de proceso. La capa de negocio es donde residen los programas que se ejecutan, recibiendo las peticiones del usuario y enviando las respuestas tras el proceso. La capa de datos es donde residen los datos. Est formada por uno o ms gestor de bases de datos que
40
realiza todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperacin de informacin desde la capa de negocio. Para la aplicacin de Estacin de seguimiento SKY-EYE, las libreras desarrolladas en este proyecto se ubican en las capas de datos y de negocio. El proyecto mecanismos de georeferenciacin y ortorectificacin de imgenes areas se ubica en la capa de negocio por completo, y el proyecto integracin visual de componentes de seguimiento y georeferenciacin sobre GIS se ubica en la capa de presentacin. En la figura se puede ver cmo queda estructurada la aplicacin (Figura 5.2). La librera ProcessedMission se encarga de procesar la informacin de misin para georeferenciar y ortonormalizar informacin. La librera Sky-Eye es la principal y contiene los formularios utilizados, a ella le da soporte GraphicElementProp que gestiona el aspecto visual de los elementos utilizados en el visualizador de plan de vuelo.
Figura 5.2 Estructuracin del proyecto en Visual Studio
Figura 5.3 Pantalla principal de la aplicacin
41
La figura muestra cmo es el aspecto visual inicial de la aplicacin ya con las tres partes integradas (Figura 5.3). Al iniciar hay que introducir la ruta dnde se encuentra el proyecto a cargar (con archivo de plan de vuelo, telemetra y misin). Es en este momento donde se carga el plan de vuelo en la librera FlightPlan. Desde esta pantalla se puede acceder tanto a la pantalla de seguimiento de plan de vuelo como a la de tratado de informacin de misin. Este es el aspecto, (Figura 5.4), de la aplicacin de seguimiento de un plan de vuelo y telemetra correspondiente. En ella se utilizan las libreras diseadas en este proyecto.
Figura 5.4 Aspecto visual de la aplicacin de seguimiento de plan de vuelo
42
Tras la integracin de las partes, en la figura se puede ver como es el aspecto visual del gestor de cartografas (Figura 5.5). Desde el formulario se accede a la estructura de clases del gestor, dando la posibilidad de ver la informacin de los grupos de fotos, de eliminarlos, de modificar los ya creados o de aadir de nuevos.
Figura Aspecto visual del gestor de cartografas
Otra de las partes importantes de la aplicacin es el siguiente formulario (Figura 5.6). ste muestra el resultado de la bsqueda de cartografas que cubren el rea del plan de vuelo cargado. El formulario est accesible en todo momento, dando la posibilidad de cambiar las cartografas a visualizar durante la ejecucin de un plan de vuelo.
Figura 5.6 Aspecto visual del resultado de bsqueda de cartografas
43
El formulario de seguimiento de plan de vuelo dispone de informacin (Figura 5.7). ste tiene diferentes vistas, cada personalizadas para cada tipo de informacin: Waypoints y Seguimiento de telemetra y Misin. Todas las vistas acceden datos correspondiente para consultar la informacin a mostrar.
un panel de una de ellas Fixes, Legs, a la base de
Figura 5.7 Detalle de los paneles de informacin
44
CAPTULO 6. BALANCE
Al iniciar el proyecto se estableci una planificacin preliminar, y ms tarde en el captulo de Especificaciones se detallaron las tareas para cada una de las lneas de trabajo. En este captulo se analizarn las variaciones de la planificacin sufridas a lo largo del proyecto. No slo la planificacin ha sufrido variaciones sino tambin los costes, se realizar un clculo de los costes finales para el proyecto.
6.1.
Evolucin del proyecto
El desarrollo final del proyecto se ha producido segn el diagrama siguiente (Figura 6.1), el diagrama completo se puede consultar en el Anexo A.
Figura 6.1 Diagrama de Gant del desarrollo final del proyecto.
Para hacer un anlisis de la evolucin del proyecto se compara el estado final con las planificaciones hechas en el captulo Contexto tecnolgico y anlisis de objetivos Figura 1.7 y en el captulo Especificaciones Figura 3.4. El punto ms importante a destacar en este balance es la demora de 1 mes en la fecha final del proyecto. Si bien es cierto que en la planificacin inicial ya se tuvo en cuenta una posible demora del proyecto, dejando 1 mes de guarda entre la fecha final prevista y la fecha final lmite. Las causas de demora han surgido de las primeras fases del proyecto, principalmente de evaluacin de sistemas GIS (Anlisis del problema). El anlisis no result sencillo y se destinaron muchos ms recursos de los previstos. Adems durante este perodo el grupo de trabajo no le pudo dedicar al proyecto las horas necesarias a causa de traslado del puesto de trabajo, vacaciones y perodo de exmenes. Con el retraso de las fases de anlisis el desarrollo de la aplicacin como tal no se pudo empezar hasta mediados de mayo.
Balance
45
El margen de guarda de 1 mes que se guard al inicio se dej con la intencin de alargar las tareas de desarrollo de la aplicacin y no las de anlisis. Desde la segunda planificacin hasta el final, el proyecto no ha sufrido grandes cambios, ya que se tena una fecha lmite inamovible y se dedicaron todos los recursos necesarios para llegar a sta. Es por esto que aunque al desarrollo se le hayan dedicado muchos ms recursos que los previstos, no se refleja en la planificacin final. A causa de esto tareas de desarrollo de componentes e integracin se han solapado con la documentacin del TFC, cuando se deberan haber finalizado con anterioridad.
6.2.
Costes finales
Los costes finales para un proyecto, no suelen ser iguales a la estimacin inicial. Esto es debido a gastos extras producidos por el retardo del proyecto y por gastos de infraestructuras en software que no se tuvieron en cuenta. En este caso, el gasto en recursos humanos ha aumentado porque el proyecto se ha retardado alrededor de 1 mes. No slo se ha demorado el proyecto sino que tampoco se ha dedicado la jornada de trabajo de 20 horas semanales que se indic inicialmente. Tambin cabe indicar que la dedicacin de horas al proyecto no ha sido regular, el perodo central fue de bajo rendimiento a causa de cambios del puesto de trabajo, vacaciones y perodos de exmenes. Durante todo el proyecto se ha hecho un seguimiento del plan de trabajo y de las horas dedicadas para cada tarea, estos documentos se pueden consultar en el Anexo B. De estas tablas se extraen las horas finales dedicadas a cada rol del grupo (Analista, Programador, Documentador). En la prctica no ha habido 9 personas trabajando, sino slo tres que han ido asumiendo los diferentes roles de trabajo para cada tarea. Los gastos en infraestructura tambin son mayores por el uso de licencias de software que no se tuvieron en cuenta. En la previsin de costes se saba que se utilizara un entorno de desarrollo y unas libreras GIS, pero no se saba cuales seran.
46
El coste final del proyecto es el siguiente (Tabla 6.1).
RECURSOS HUMANOS INDIVIDUAL Analista Informtico Programador Documentador
/hora 32 25 20 TOTAL /hora 32 25 20 TOTAL
Horas Individual inicial final 130 198 235 302 80 111 445 611 Horas Equipo inicial final 390 636 705 822 240 382 1335 1840 Cantidad 3 3 1 3 3 1 coste unidad 1.000 159 2.000 450 679 1.750 TOTAL COSTE TOTAL DEL GRUPO
Coste Individual 6.336 7.550 2.220 16.106 Coste Total 20.352 20.550 7.640 48.542 coste total 3.000 477 2.000 1.350 2.037 1.750 500 11.114 59.656
RECURSOS HUMANOS GRUPO DE TRABAJO Analista Informtico Programador Documentador
INFRAESTRUCTURA Estacin de Trabajo Licencia Windows XP Licencia Sharepoint Licencia Microsoft Office 2007 Licencia Microsoft Visual Studio 2005 Licencia Development Kit ESRI Materiales de oficina varios
Tabla 6.1 Costes finales de recursos humanos e infraestructura.
Como se puede ver en la tabla, comparando el coste final del proyecto con el inicial, Contexto tecnolgico y anlisis de objetivos Tabla 1.1, se puede ver que ha habido un aumento en los costes de 19.251 . Los gastos en recursos humanos han aumentado considerablemente. Los tres recursos destinados para cada proyecto han aumentado considerablemente el nmero de horas, en el caso de este proyecto en concreto de 166 horas, y para el grupo de trabajo de 505 horas. Los gastos en infraestructura son mayores porque se han usado software de desarrollo que no se presupuestaron como son el Microsoft Visual Studio 2005 y el Development Kit de ESRI. Todos estos costes son en realidad estimados, ya que nos encontramos en un contexto universitario. Los gastos en recursos humanos no son reales porque no se tiene a nadie contratado, y para los gastos de infraestructura se disponen de ordenadores personales y licencias prestadas por la universidad. En todo caso se cree que este coste final se aproxima bastante al real en caso de que se realizara el proyecto en una empresa.
Conclusiones
47
CAPTULO 7. CONCLUSIONES
En este punto es necesario hacer una revisin de los objetivos marcados al inicio del proyecto, realizar un estudio de las posibles lneas de trabajo futuro y conclusiones finales del proyecto.
7.1.
Revisin de objetivos
Durante el transcurso del proyecto, igual que con la planificacin, se han producido cambios en los objetivos tanto individuales, del grupo o de SKY-EYE en su conjunto. A continuacin se analizan y justifican todas estas variaciones.
7.1.1.
Objetivos individuales
Como objetivos iniciales se marcaron el diseo e implementacin de un sistema lector de planes de vuelo y de un gestor de cartografas. Ms tarde, en la concrecin de objetivos, se aadi el diseo e implementacin de un sistema lector de informacin de telemetra y misin, adems de un simulador provisional. El sistema lector de planes de vuelo en formato XML se tena que basar en un XSD (XML Schema Definition) determinado. De este XSD se encarga otro grupo del proyecto SKY-EYE, por tanto se dependa de la entrega de versiones de ste documento. La primera versin que se entreg era algo incompleta, pero se implement igualmente para realizar pruebas. La segunda y ltima se entreg hacia el final del desarrollo de la aplicacin, y aunque no era la versin definitiva del XSD se tom como tal. De esta forma, el sistema implementado de lectura de planes de vuelo no est acabado aunque s proporciona un buen porcentaje de la funcionalidad total. El XSD actual slo dispone de 3 tipos de legs y no se contemplan las mltiples conexiones entre stages. Para futuras actualizaciones del documento XSD hara falta modificar el sistema lector y la estructura de clases. El gestor de cartografas se ha implementado completamente. Es capaz de gestionar grupos de cartografas en formatos .sid y .tiff. En la aplicacin el gestor calcula sobre un plan de vuelo qu cartografas estn disponibles y durante la visualizacin permite cambiar las cartografas cargadas para visualizar. Los sistemas de captacin y almacenamiento de telemetra y misin se han desarrollado completamente con la informacin relacionada que se dispona. La telemetra y la misin an no estn completamente definidas por ICARUS, as que se ha diseado con versiones provisionales de ellas.
48
7.1.2.
Objetivos del grupo de trabajo
El grupo de trabajo tena como objetivo principal el diseo e implementacin de una aplicacin de software que operara como estacin de seguimiento. La aplicacin se dividira en tres flujos de trabajo: - El flujo de trabajo encargado de la gestin de plan de vuelo, cartografas, telemetra y misin se ha implementado por completo cumpliendo todos sus objetivos. - El flujo de trabajo encargado de la georeferenciacin y ortonormalizacin de imgenes ha sido el ms laborioso de los tres. La georeferenciacin se ha realizado correctamente, y la ortonormalizacin parcialmente. La ortonormalizacin se trata de una tarea muy complicada para la que, con el tiempo disponible, tan slo se han obtenido resultados parciales. - El ltimo flujo de trabajo estaba encargado del diseo de la interfaz de usuario para integrar los dos flujos anteriores. El diseo final de la aplicacin ha resultado satisfactorio. La aplicacin muestra cartografas, planes de vuelo y su seguimiento, as como toda la informacin textual relacionada. La simbologa aadida encima de las cartografas, como el plan de vuelo o seguimiento, no se ha realizado utilizando capas sino otras herramientas aunque se obtienen los mismo resultado visuales.
7.1.3.
Objetivos SKY-EYE
El objetivo de SKY-EYE a corto plazo era conseguir la implementacin de un prototipo para poderlo presentar en la FireParadox de Agosto en Portugal. Desde el conocimiento de este grupo de trabajo, dicho prototipo no estar disponible para Agosto, y la visita a FireParadox se limitar a recaudar informacin del sector y establecer contactos. Durante el transcurso del proyecto, el grupo de trabajo ha tenido un vaco de informacin proveniente de los otros equipos de ICARUS. stos no han podido coincidir en el flujo de trabajo debido a cambios de objetivos, y a tener otras prioridades y ritmos de trabajo.
7.2.
Conclusiones
Aunque ya se han analizado en captulos anteriores todos los objetivos del proyecto, es en este punto dnde se hace un anlisis ms personal de lo que ha sido el proyecto. Estas conclusiones se dividirn en las referentes al trabajo individual y las de trabajo en grupo.
Conclusiones
49
7.2.1.
Conclusiones individuales
Ha sido una satisfaccin para m el haber podido formar parte de un proyecto de gran envergadura. No slo se trata de un TFC sino del trabajo en equipo en un entorno que se puede semejar al profesional. El TFC es de la ltima tarea de la carrera, en ella que se puede aplicar todo lo aprendido y adems adquirir nuevos conocimientos. Me llevo conmigo lecciones muy valiosas en el mbito de la organizacin y la planificacin de equipos y proyectos. Como comentaba en la motivacin para involucrarme en este proyecto, me motivaba el hecho de tratarse de un proyecto en equipo y adems de desarrollo de software. Y as ha sido, he conseguido cumplir todas las expectativas personales que tena y adems los objetivos concretos del TFC.
7.2.2.
Conclusiones del grupo de trabajo
La unin de tres flujos de trabajo ha dado lugar a este proyecto. Estos flujos han de estar bien organizados y planificados para que del conjunto se obtenga un buen resultado. El trabajo en equipo implica la dependencia de los dems miembros del grupo para avanzar a la par. Es necesario marcar una buena planificacin e ir definiendo objetivos a corto plazo para controlar el buen funcionamiento. Si no se hace as puede dar lugar a la desintegracin del proyecto, al retraso del mismo y a un mal resultado final. El caso de este proyecto, el equipo se ha mantenido hasta el final, dando como resultado un buen proyecto. Se defini una planificacin al inicio y se fue adaptando a medida que los objetivos se cumplan o variaban. El formar parte de un grupo de trabajo implica que en cualquier momento se pueden cambiar las tareas hacia otros objetivos, por tanto cada uno de los miembros tiene que estar preparado para estos cambios.
7.3.
Lneas futuras
Los objetivos para ste TFC se han cumplido satisfactoriamente, aunque cmo se ha indicado anteriormente, en un futuro se debera actualizar el gestor de planes de vuelo con los nuevos XSD. Esta actualizacin tambin implicara la modificacin de algunas partes de la capa de presentacin de la aplicacin. La telemetra que hemos simulado para la aplicacin es completamente local, leyendo de carpetas ficheros XML. Una vez se pueda disponer de un streaming en formato real bien simulado, se podra conectar a la aplicacin para poder realizar un seguimiento de un plan de vuelo ms real. Esto implica que otros grupos del proyecto SKY-EYE definan todo lo relacionado con las comunicaciones y los paquetes de informacin.
50
En cuanto a las herramientas de la aplicacin, en un futuro se podra seguir desarrollando la georeferenciacin y en especial la ortonormalizacin de fotografas. La aplicacin que se ha desarrollado en el grupo de trabajo se trata de un primer prototipo para la estacin de seguimiento. El proyecto SKY-EYE define que habr diversas estaciones de control conectadas a una estacin central de seguimiento. El prototipo se puede desarrollar por numerosas lneas de investigacin, la opcin de mltiples pantallas con planes de vuelo simultneos, la conexin ha estaciones de control con protocolos de comunicacin, el desarrollo de las estaciones de control a partir del prototipo desarrollado, acceso a una base de datos para almacenar planes de vuelo, misiones, telemetras, cartografas, informacin capturada por los UAVs, etc.
7.4.
Estudio de la ambientalizacin
La aplicacin que se desarrolla en este proyecto forma parte del proyecto SKYEYE. La aplicacin por s sola no tiene ningn efecto sobre el medio ambiente, pero en cambio el proyecto en conjunto s que lo tiene. SKY-EYE trata de desarrollar un nuevo sistema areo de captacin de datos terrestres usando tecnologa UAV. El uso de UAVs favorece al medio ambiente al no usar mucha cantidad de combustible, es mucho ms silencioso, no necesita personal abordo, etc. El proyecto no slo tiene en cuenta el medio ambiente en la parte de materiales usados sino tambin en las futuras aplicaciones. La primera aplicacin hacia la que se est desarrollando el proyecto es el control, seguimiento y vigilancia de incendios forestales. En el futuro se podra ampliar a vigilancia y salvamento martimo, control meteorolgico, vigilancia forestal, etc.
Bibliografa
51
BIBLIOGRAFA
[1] GIS SIG Sistemas de informacin geogrfica < http://www.gabrielortiz.com/ > NASA Unmanned Aerial Vehicles < http://uav.wff.nasa.gov/ > Coleccin de software GIS gratuito < http://www.gabrielortiz.com/index.asp?info=063 > Recopilacin de teora de GIS: Core Currculum in GIS de la N.C.GIA < http://www.gabrielortiz.com/index.asp?info=071 > Geographic Information System (GIS): libro digital < http://www.gabrielortiz.com/index.asp?info=078 > The source for GIS and mapping software < http://software.geocomm.com/raster > Espinosa Oscanoa, Domingo Procesamiento Digital de Ortofotos.
[2]
[3]
[4]
[5]
[6]
[7]
[8] Garca Len, Josefa y Cuarteto Sez, Aurora Compraracin de procesos de rectificacin y ortoproyeccin mediante fotogrametra terrestre digital. [9] E. Freeville INTEGRA Metrics & Methodologies Efficiency Algorithm Assessment 2002 [10] UAV Ground Control Stations < http://www.uavm.com/uavsubsystems/groundcontrolstations.html > [11] Institut Cartogrfic de Catalunya < http://www.icc.es/portal/ > [12] Fire Paradox < http://www.fireparadox.org/ > [13] Comets Project Fire Monitoring < http://www.comets-uavs.org/applications/fire.shtml > [14] Fira GlobalGeo < http://www.globalgeobcn.com/ > [15] ESRI The GIS Software Leader < http://www.esri.com/ >
52
[16] ESRI Developer Network < http://edn.esri.com/ > [17] gvSIG < http://www.gvsig.gva.es/ > [18] GRASS GIS < http://grass.itc.it/ > [19] Miramon: Geographic Information System and Remote Sensing Software < http://www.creaf.uab.es/MiraMon/ > [20] QUANTUM GIS < http://community.qgis.org/ > [21] .Net Compact Framework, 2005 < http://msdn2.microsoft.com/en-us/library/f44bbwa1.aspx > [22] MSDN Home Page Espaa < http://msdn2.microsoft.com/es-es/default.aspx >

PFC UPC Estacion Seguimiento UAV

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

PFC UPC Estacion Seguimiento UAV

Încărcat de

Drepturi de autor:

Formate disponibile

TRABAJO DE FIN DE CARRERA

CAPTULO 2. ANLISIS DEL PROBLEMA.................................................... 15

2.2. 2.3. 2.4.

CAPTULO 4. DISEO .................................................................................... 28

CAPTULO 5. IMPLEMENTACIN Y PRUEBAS............................................ 36

CAPTULO 7. CONCLUSIONES ..................................................................... 47

Estacin SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo

Contexto tecnolgico y anlisis de objetivos

CAPTULO 1. CONTEXTO TECNOLGICO Y ANLISIS DE OBJETIVOS

Escenario, Visin y Tecnologa

Figura 1.1 Aplicacin SKY-EYE sobre incendios forestales

Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo

Figura 1.2 Esquema general del proyecto SKY-EYE

Contexto tecnolgico y anlisis de objetivos

Figura 1.3 UAV modelo Shadow 240

Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo

Figura 1.4 Ejemplo de estacin de control

Contexto tecnolgico y anlisis de objetivos

Figura 1.5 Ejemplo de estacin de seguimiento

Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo

Contexto tecnolgico y anlisis de objetivos

Objetivos del grupo de trabajo

Figura 1.6 Estructura de la Estacin de seguimiento SKY-EYE para UAVs

Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo

Objetivos del TFC

Planificacin y estimacin de costes

Contexto tecnolgico y anlisis de objetivos

Figura 1.7 Diagrama de Gant de la planificacin previa

Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo

Contexto tecnolgico y anlisis de objetivos

500 7.327 40.405,00

Tabla 1.1 Costes estimados de recursos humanos e infraestructura

Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo

Anlisis del estado del arte

CAPTULO 2. ANLISIS DEL PROBLEMA

Sistemas de Informacin Geogrfica (GIS)

Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo

Relacin GIS Aplicacin SKY-EYE

Criterios de seleccin de GIS

Anlisis del estado del arte

Evaluacin y seleccin de GIS

Georef. & Orto. 5%

8,50 8,20 8,20 7,50 7,30 7,25 6,35

5,75 5,75 5,50 3,95 3,85 2,90

C++ Java Java

Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo

Anlisis del estado del arte

Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo

Informacin como un servicio

Anlisis del estado del arte

Figura 2.3 Arquitectura del sistema de comunicacin

rad/s radians radians meters meters m/s m/s ms ms ms ms

Posicin 3D del UAV.

uavSpeed airSpeed flightTime totalTime missionTime maxTime

Tabla 2.2 Informacin de telemetra del vuelo

Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo

Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo

Figura 3.2 Diferencia de trayectorias entre fly-by y fly-over.

Figura 3.3 Modelo conceptual para el elemento Waypoint.

Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo

Figura 3.4 Planificacin detallada para la fase de Diseo.

Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo

Figura 4.1 Estructura general de .NET

Estacin de seguimiento SKY-EYE para UAVs: modelizacin y tratamiento de planes de vuelo