Arquitectura de Fault Tolerance System distribuido entre UAVs APÉNDICES INSTALACIONES A.- Cómo instalar y configurar Ant Ant es una herramienta que permite prescindir de los script de shell para automatizar las tareas repetitivas y secuenciales como puede ser, compilar y correr test, generar instalables... etc. Es independiente del entorno al funcionar bajo la JVM. Instalación Abrir el gestor de paquetes Synaptic, buscar el paquete ant y marcarlo para su instalación. Esto hará que se instalen todas sus dependencias (si no lo están ya). Para verificar que la instalación se ha hecho correctamente, abrir un terminal y hacer: ant -version Si todo está bien se debería ver el mensaje: Apache Ant version 1.7.1 compiled on <fechaDeCompilacion> Herramientas auxiliares Ant-Contrib Tasks Ant-Contrib tasks es una colección de tasks, tipos y herramientas para Apache Ant. Para su instalación, abrir el gestor de paquetes de Synaptic, buscar el paquete antcontrib y marcar para su instalación. Esto hará que se instalen todas sus dependencias (si no lo están ya). Una vez instalado se puede encontrar la librería instalada en /usr/share/java (buscar librería ant-contrib-1.0b3.jar). Para configurar Ant se dispone de un par de opciones: · Configurar en el plug-in de Eclipse: · Pulsar en el botón derecho sobre el fichero build.xml en el Explorador de proyectos. · Después Run As -> Ant Build... · A continuación seleccionar la pestaña Classpath. · Finalmente añadir la librería ant-contrib-1.0b3.jar haciendo clic en Add External JARs y seleccionar la localización de la librería. · Configurar Ant en el terminal · Abrir un terminal y compilar el proyecto ant añadiendo las librerías de ant147 Arquitectura de Fault Tolerance System distribuido entre UAVs contrib > ant <otrasOpciones> -lib /usr/share/java/ant-contrib-1.0b3.jar Una vez que se tenga 'Ant-Contrib' correctamente instalado y configurado, podemos empezar a utilizar los tasks de esta librería añadiendo en nuestro fichero 'build.xml' la siguiente definición: <taskdef resource="net/sf/antcontrib/antlib.xml" /> Cpptasks Cpptasks es un conjunto de tasks que permiten la compilación de diferentes lenguajes de programación (C/C++, FORTRAN, MIDL, etc). es capaz de producir ejecutables, librerías dinámicas y librerías estáticas. Para instalar la librería cpptasks: Descargar la última versión del Ubuntu Mirror: http://ubuntumirror/Ubuntu/Eclipse/cpptasksS2.jar Copiar la librería a /usr/share/java La configuración Ant para cpptasks se realiza del mismo modo que para Ant-Contrib. > ant <otrasOpciones> -lib /usr/share/java/cpptasksS2.jar Una vez que tengamos 'Cpptasks' correctamente instalado y configurado, se podrá empezar a utilizar los tasks de esta librería añadiendo en nuestro fichero 'build.xml' la siguiente definición: <taskdef resource="cpptasks.tasks" /> Esquema general En este apartado se describe el aspecto general de un fichero build.xml, que es el que contiene las acciones a realizar. <project name="<nombreDelProyecto>" default="<TargetPorDefecto>"> <property name="<nombreDeLaPropiedad1>" value="<valor de la propiedad>1"/> ... <property name="<nombreDeLaPropiedadN>" value="<valor de la propiedad>N"/> <target name="<target1>" description="<target's description>"> ... </target> <target name="<target2>" description="<target's description>"> ... </target> ........................................ <target name="<targetN>" description="<target's description>"> ... </target> <target name="<TargetPorDefecto>" description="<target's description>"> 148 Arquitectura de Fault Tolerance System distribuido entre UAVs ... </target> </project> Por otra parte cada vez que se quiera hacer uso de Ant-Contrib será necesario añadir al fichero build.xml: <project name="<nombreDelProyecto>" default="<TargetPorDefecto>"> <taskdef resource="net/sf/antcontrib/antlib.xml" /> ... </project> Y si se desea utilizar las herramientas de Cpptasks: <project name="<nombreDelProyecto>" default="<TargetPorDefecto>"> <taskdef resource="cpptasks.tasks" /> ... </project> Pasar parámetros desde línea de comandos a Ant Se puede pasar parámetros desde línea de comando que pueden ser utilizados luego en el archivo build.xml (o cualquier otro fichero ant que utilicemos) como si de una propiedad se tratara. Para ello se usa el argumento -D. > ant -Dpropiedad="valorDePropiedad" En build.xml: ............. <echo message="Genero el directorio pasado con el parámetro 'propiedad': ${propiedad}"/> <mkdir "${propiedad}"/> ............... Ejemplos prácticos Compilar código C++ con Ant - Cpptasks <taskdef resource="cpptasks.tasks" /> <target name="build" description="compiles the source code"> <mkdir dir="../bin/IS900" /> <mkdir dir="obj" /> <cc name="g++" outtype="executable" outfile="../bin/IS900/exec" objdir="obj"> <fileset dir="src" includes="*.cpp" /> <libset libs="stdc++" /> </cc> </target> Utilizar Ant-Contrib con Ant <taskdef resource="net/sf/antcontrib/antlib.xml" /> <target name="print"> <for list="a,b,c,d" param="letter"> <sequential> <echo>${entrada} @{letter}</echo> </sequential> 149 Arquitectura de Fault Tolerance System distribuido entre UAVs </for> </target> Ant e integración continua En este apartado, se explicará el caso particular para configurar un entorno de Integración Continua para C++. Los requisitos son los siguientes: Hudson como servidor de IC. Eclipse CDT como entorno de programación. C++ como lenguaje. Ant como herramienta de construcción. Se supone un entorno estándar de IC: Servidor con Hudson, servidor de referencia y servidor de compilación. A continuación se detallan los pasos a seguir para un proyecto en concreto. Se ha usado la configuración aplicada al proyecto HAL, por lo que se tendrán que cambiar todas las referencias a este nombre por la que corresponda. B.- Hudson como servidor de IC Un primer paso antes de configurar una nueva tarea en Hudson, es confirmar que el comando ant -f build.xml se ejecuta correctamente en la máquina del repositorio. Puede ser que ant nos de el siguiente error: Unable to locate tools.jar. Expected to find it in /usr/lib/jvm/java-6-openjdk/lib/tools.jar En este caso simplemente encontrar tools.jar y copiarlo a la carpeta en la que busca ant. En nuestro caso estaba en la carpeta /usr/lib/jvm/java-1.5.0-gcj-4.4/lib. Configuración en Hudson Hudson se conecta por https con su usuario, por lo que para que ejecute ant en nuestra máquina debemos configurarle la clave pública. Para ello, en la máquina que corre Hudson, se ejecutarán los siguientes comandos: sudo passwd hudson. Poner la contraseña que se prefiera. su hudson. Para registrarse en la shell como usuario Hudson, escribir la contraseña creada en el paso anterior. Ejecutar los comandos para crear una clave https teniendo en cuenta que <ip_servidor> debe ser del tipo user@ip ya que se nos pide la contraseña del servidor remoto. Una vez se haya creado el proyecto en Hudson, en la sección Configure: En Source Code Management: · Seleccionar Mercurial. · Se selecciona el repositorio adecuado En Build Triggers: 150 Arquitectura de Fault Tolerance System distribuido entre UAVs · Seleccionar Poll SCM · Schedule: */5 7-18 * * 1-5 En Build: · En Execute shell: · command for CL: ssh 192.168.5.183 'cd projects/CL; ant -lib /usr/share/java/jsch.jar -lib /usr/share/java/cpptasks1.0b5.jar -buildfile CI/build-compile.xml' · command for HAL: ssh 192.168.5.183 'cd projects/Hal; ant -lib /usr/share/java/jsch.jar -lib /usr/share/java/cpptasks1.0b5.jar -buildfile CI/build-compile.xml' Los .xml de ANT (build-compile.xml por ejemplo) se encuentran versionados en el repositorio de sus respectivos proyectos. Instalación de Ant Antes de poder ejecutar Ant hay alguna configuración adicional que se tendrá que hacer a menos que esté instalando la versión de RPM jpackage.org: - Se añada el directorio bin al path. Se establece la variable de entorno ANT_HOME al directorio donde se ha instalado Ant. o Ant es instalado en /usr/local/ant. Los siguientes pasos establece el entorno: § export ANT_HOME=/usr/local/ant § export JAVA_HOME=/usr/local/jdk-1.5.0.05 § export PATH=${PATH}:${ANT_HOME}/bin - Opcionalmente, se establece la variable de entorno JAVA_HOME. Esta debería estar en el directorio donde está instalado el JDK. No se debe instalar el archivo ant.jar de Ant en el directorio lib/ext del JDK/JRE. Ant es una aplicación, mientras que el directorio de la extensión es para extensiones JDK. Comprobación de la instalación Se puede comprobar la instalación básica con la apertura de un nuevo shell y escribiendo ant. Se debe recibir un mensaje como este BuildFile: build.xml no existe! Build failed 151 Arquitectura de Fault Tolerance System distribuido entre UAVs Eso significa que Ant funciona. Este mensaje se debe a que se tiene que tener un BuildFile individual para cada proyecto. Si se escribe ant -version se debe obtener algo como Apache Ant version 1.7.1 compiled on June 27 2008 Si esto no funciona hay que hay que asegurarse de que las variables de entorno están correctamente establecidas. Se debe resolver: requerido:%% ANT_HOME \ bin \ ant.bat opcional:% JAVA_HOME% \ bin \ java.exe requerido:% PATH% = ... otra entradas ...;% ANT_HOME%\bin; ... otra entradas ... ANT_HOME es utilizado por el script para encontrar las bibliotecas. JAVA_HOME es utilizado por el programa de ejecución para encontrar el JDK/JRE. Si no se establece, el lanzador intenta encontrarlo en la variable de entorno % PATH%. Configuración de Ant en el proyecto Para configurar el proyecto para ser compilado y ejecutado por Ant hay que seguir estos pasos: Se necesitará añadir los JAR ant-contrib y cpptasksS2. Para ello se tendrá que ejecutar el fichero build.xml del proyecto como compilación de Ant Run as -> Ant build... Luego se tendrá que seleccionar la pestaña Classpath y consecuetemente Ant Home -> Add external JARs... Y añadir los citados ant-contrib y cpptasksS2. Ahora, es necesario desactivar la opción de compilar antes de ejecutar por defecto de Eclipse, por lo que se tendrá que seleccionar la pestaña Build y aquí desactivar la opción Build before launch. C.- Generación de instaladores Este apartado explica la forma en la que se tienen que crear los instaladores de las distintas bibliotecas y de la aplicacion. Los instaladores consistirán en paquetes .deb ya que se desarrolla software para distribuciones Linux. 152 Arquitectura de Fault Tolerance System distribuido entre UAVs Estructura de directorios en los proyectos Eclipse para incorporar la generación de instaladores La generación de los instaladores se realiza mediante tres scripts: debgen.sh, debgenclean.sh y debgentest.sh. Estos scripts se deben alojar dentro de la carpeta scripts (bajo la carpeta principal del proyecto) según se muestra en la siguiente imagen: Descripción de los scripts utilizados en la generación de los instaladores Los scripts necesarios en la generación de los instaladores: § debgen.sh: Genera los paquetes necesarios del proyecto que lo contiene en la carpeta debs. § debgenclean.sh: Borra los paquetes y la carpeta debs. § debgentest.sh: Realiza tests a los instaladores como si se pueden instalar, borrar, etc. Instaladores necesarios en la aplicación Los paquetes .deb que se deben generar para la aplicación desarrollada son: § Instalador del ejecutable. § Instalador de la documentación de la aplicación. Instaladores necesarios en las bibliotecas Los paquetes .deb que se deben generar para una biblioteca desarrollada son: § Instalador de la biblioteca para su uso. § Instalador de la biblioteca para su desarrollo. § Instalador de la documentación de la biblioteca. 153 Arquitectura de Fault Tolerance System distribuido entre UAVs Consideraciones sobre el instalador de un ejecutable § El nombre del paquete sigue regla: NombreEjecutable_Versión_Arquitectura.deb. la siguiente § El fichero binario del ejecutable se guarda en /opt/NombreEjecutable/bin. Si necesita algún script también se podrá guardar en esta ruta. § Los ficheros de configuración se guardan en /etc/opt/NombreEjecutable. Si el ejecutable necesita los ficheros de configuración en el mismo directorio se crearán los enlaces simbólicos necesarios. § Las dependencias del paquetes son las bibliotecas que requiere. Consideraciones sobre el instalador de la documentación un ejecutable § El nombre del paquete sigue doc_Versión_Arquitectura.deb. la siguiente regla: NombreEjecutable- § Toda la estructura de directorios de la documentación se aloja bajo la ruta: /opt/NombreEjecutable/doc. § No tiene dependencias por lo que lo normal es que la arquitectura sea all. Consideraciones sobre el instalador de una biblioteca para su uso § El nombre del paquete de regla: NombreBiblioteca_Versión_Arquitectura.deb. sigue la § La biblioteca se aloja en: /usr/lib. § Los ficheros de configuración se guardan en: /etc/NombreBiblioteca. § Las dependencias del paquetes son las bibliotecas que requiere. siguiente Consideraciones sobre el instalador de una biblioteca para su desarrollo § El nombre del paquete sigue la siguiente regla: NombreBiblioteca- dev_Versión_Arquitectura.deb. § La dependencia del paquetes es paquete: NombreBiblioteca_Versión_Arquitectura.deb. § Las interfaces públicas se guardan en /usr/include/NombreBiblioteca con la estructura de directorios necesaria. 154 únicamente el Arquitectura de Fault Tolerance System distribuido entre UAVs Consideraciones sobre el instalador de la documentación de una biblioteca § El nombre del paquete sigue doc_Versión_Arquitectura.deb. la siguiente regla: NombreBiblioteca- § Toda la estructura de directorios de la documentación se aloja bajo la ruta: /usr/share/doc/NombreBiblioteca. § No tiene dependencias por lo que lo normal es que la arquitectura sea all. Automatización de la generación, instalación y prueba de los instaladores Los proyectos de Eclipse tienen en el script de Ant objetivos para la generación, instalación y prueba de los instaladores de ese proyecto. Estos objetivos consisten en llamadas a los scripts descritos anteriormente. Los scripts necesitan permisos de superusuario, igual que el comando dpkg en la instalación y prueba de los paquetes. Por ejemplo, si los proyectos que tienen la automatización de los instaladores son CL, CommonDataLibrary y TestbedHALLib, el fichero /etc/sudoers debe tener una entrada análoga a (la ruta específica de los scripts debe ser la adecuada en cada máquina): admin_user ALL= NOPASSWD: /home/admin_ user/Desktop/ANIMOWorkSpace/CL/scripts/debgen.sh, /home/admin_ user/Desktop/ANIMOWorkSpace/CL/scripts/debgenclean.sh, /home/admin_ user/Desktop/ANIMOWorkSpace/CL/scripts /debgentest.sh, /home/admin_user/Desktop/ANIMOWorkSpace/CommonDataLibrary/scripts/debg en.sh, /home/admin_user/Desktop/ANIMOWorkSpace/CommonDataLibrary/scripts/debg enclean.sh, /home/admin_user/Desktop/ANIMOWorkSpace/CommonDataLibrary/scripts/debg entest.sh, /home/admin_user/Desktop/ANIMOWorkSpace/TestbedHALLib/scripts/debgen.s h, /home/admin_user/Desktop/ANIMOWorkSpace/TestbedHALLib/scripts/debgencl ean.sh, /home/admin_user/Desktop/ANIMOWorkSpace/TestbedHALLib/scripts/debgente st.sh, /usr/bin/dpkg 155 Arquitectura de Fault Tolerance System distribuido entre UAVs D.- Instalación de librerías - Librerías necesarias para CL o RTI DDS. ¿Qué es DDS? DDS (Data Distribution Service) es la especificación para un middleware del tipo publicador/subscriptor en sistemas distribuidos específicos para sistemas en tiempo real. Es una arquitectura orientada a datos, donde el publicador envía los datos a la red dónde son consumidos por el subscriptor, siendo nodos independientes y sin un conocimiento específico de cada uno. Instalación de DDS Descargar el paquete desde ubuntu-mirror: http://ubuntu-mirror/Ubuntu/Varios/rtidds4_5d.tar.gz . Extraer el paquete. Se creará una carpeta de nombre rtidds4_5d. Desde una consola, acceder a dicha carpeta y ejecutar: sudo ./install.sh -i Para desinstalar el paquete, ejecutar desde la misma carpeta: sudo ./install.sh -u § RTI Data Distribution Service viene en dos o más archivos tar.gz: Un archivo anfitrión que contiene documentación, archivos de cabecera y otros archivos necesarios para el desarrollo; y uno o varios archivos de destino que contienen las bibliotecas y otros archivos que se necesitan para implementación. Se descomprimen como se describe a continuación (no es necesario estar registrado como usuario root durante la instalación). · Hay que asegurarse de que se tiene la versión de GNU de la utilidad tar (la que se ocupa de los nombres de archivos largos). Este es el ejecutable ejecutable por defecto. · Se crea un directorio para RTI Data Distribution Service. Se debe instalar en /opt/rti / (aunque se puede sustituir las referencias a /opt/rti/ a otro directorio). 156 Arquitectura de Fault Tolerance System distribuido entre UAVs · Se mueve el archivo descargado en el directorio recién creado. Este archivo se puede llmar , por ejemplo, rtidds45x-i86Linux2.6gcc3.4.3.tar.gz. · Se extrae la primera distribución de host de la siguiente forma: gunzip rtidds45x-i86Linux2.6gcc3.4.3.tar.gz gtar xvf rtidds45x-i86Linux2.6gcc3.4.3.tar - Librerías necesarias para HAL o Log4cplus. Requisitos: Una cadena de herramientas GCC válido y el código fuente se puede obtener de log4cplus en SourceForge. Descomprimir el código fuente y sólo se tiene que seguir las instrucciones del install.txt. Hay que asegurarse de que se dispone de los permisos necesarios (sudo). Se inicia el terminal y se va a la ubicación donde se ha desempaquetado el código fuente. Se configura el paquete del sistema. sudo. / configure Se compila el paquete. make Se instala con los privilegios necesarios el paquete. sudo make install Se actualiza la caché de biblioteca. sudo ldconfig 157 Arquitectura de Fault Tolerance System distribuido entre UAVs La biblioteca y la ubicación predeterminados de encabezado de la versión 1.0.4 son /usr/local/lib y /usr/local/include. Hay que asegurarse de que los liblog4cplus.a, bibliotecas y cabeceras liblog4cplus.so existe. QT Creator integración: Se crea una nueva aplicación de consola y se abre el archivo de proyecto creado. Se añade la biblioteca log4cplus y cabecera añadiendo las siguientes líneas al archivo del proyecto y se trata de compilar sin errores. Se crea un archivo de propiedades simple (por ejemplo log.properties con nombre) para la aplicación y se coloca este archivo en la carpeta de salida donde se compila la aplicación para que (por ejemplo, *-build-desktop). Hay que asegurarse de que se tiene los privilegios para crear un archivo en la ubicación definida por el archivo de propiedades. Hay que asegurarse de que se ha establecido el objetivo de generación para no DEBUG RELEASE. Cuando se utiliza el modo RELEASE el compilador debe quejarse de las referencias pthread que faltan. Se compila y se ejecuta la aplicación. Si no se actualiza la caché de biblioteca después de instalarse el paquete log4cplus el compilador debe quejarse de la biblioteca liblog4cplus.so.4. Si el archivo de propiedades no puede ser encontrado, el registrador se queja de no tener ningún appenders. o Rudeconfig. Esta instalación coloca los archivos de cabecera y las bibliotecas en lugares públicos para que estén fácilmente accesibles por todos los programas. Las zonas públicas son normalmente /usr/include y /usr/lib o /usr/local/include y /usr/local/lib. Puede ser necesario tener privilegios de superusuario (por ejemplo, iniciar sesión como root) para instalar Config. 158 Arquitectura de Fault Tolerance System distribuido entre UAVs · Si no existe, se crea lib rude pública y los directorios bajo /usr/include y /usr/lib. >mkdir /usr/include/rude >mkdir /usr/lib/rude >chmod 755 /usr/include/rude >chmod 755 /usr/lib/rude · Se descomprime el paquete >tar xzvf rudeconfig.2.1-nnnnn.tar.gz · Se entra en el directorio descomprimido >cd rudeconfig.2.1 · Se copia el archivo de cabecera (config.h) en el directorio /usr/include/rude. >cp config.h /usr/include/rude/config.h >chmod 644 /usr/include/rude/config.h · Se copia las bibliotecas en el directorio /usr/lib Para Biblioteca compartida: >cp rudeconfig.so.2.1 /usr/lib/rudeconfig.so.2.1 >chmod 644 /usr/lib/rudeconfig.so.2.1 >ln -sf /usr/lib/rudeconfig.so.2.1 /usr/lib/rudeconfig.so Para Biblioteca regular: >cp rudeconfig.lib /usr/lib/rudeconfig.lib >chmod 644 /usr/lib/rudeconfig.lib o Isense. 159 Arquitectura de Fault Tolerance System distribuido entre UAVs 1. Descargar de la ubuntu-mirror las librerias de isense (http://ubuntumirror/Ubuntu/Varios/). 2. Copiar la libreria libisense.so a los directorios /lib y /lib64. 3. Incluir isense.h en el proyecto. - Comunes Doxygen. Primero hay que ir a la página de descarga para obtener la última distribución, si no se tiene doxygen descargado ya. Se compila desde el código fuente de UNIX. Con el fin de generar un Makefile para la plataforma, se necesita perl. El script de configuración asume la disponibilidad de las herramientas estándar de UNIX como set, date, find, uname, mv, cp, cat, echo, tr, cd, y rm. Para sacar el máximo provecho de doxygen se cuenta con las siguientes herramientas adicionales que deben ser instaladas. Qt Software GUI toolkit Qt versión 4.3 o superior. Esto es necesario para construir el GUI front-end doxywizard. Una distribución: por ejemplo teTeX 1,0 Esto es necesario para generar LaTeX, PostScript y PDF de salida. El conjunto de herramientas de visualización gráfica versión 1.8.10 o superior incluye gráficos de dependencia, gráficos de herencia gráficas y gráficos de colaboración. Si se compila graphviz, hay que asegurarse de que se incluye soporte freetype (que requiere la biblioteca freetype y archivos de cabecera), de lo contrario los gráficos no representará las etiquetas de texto apropiadas. Si no se hace uso de pdflatex, las fórmulas que el intérprete ghostscript necesita, se pueden encontrar en www.ghostscript.com. Con el fin de generar la documentación propia de doxygen, Python es necesario, este puede ser encontrado en www.python.org. Se descomprime el archivo y se ejecuta el script de configuración 160 Arquitectura de Fault Tolerance System distribuido entre UAVs sh. / configure El script trata de determinar la plataforma que se utiliza, la herramienta make (que debe ser GNU make) y el intérprete perl. Se informará lo que encuentra. Para reemplazar la plataforma de auto detección y el compilador pueda ejecutar, se configura de la siguiente manera: configure - platfform platfforma-type Ver el archivo PLATFORMS para una lista de posibles opciones de plataforma. Se compila el programa con make: make El programa debe compilar sin problemas y los binarios (doxygen y doxywizard opcionalmente) deben estar disponible en el directorio bin de la distribución. Opcional: Generar el manual de usuario. make docs Para dejar que doxygen genere la documentación HTML, el directorio HTML de la distribución ahora contendrá la documentación html (sólo apuntar un navegador HTML con el archivo index.html en el directorio html). Se necesitará el intérprete de python para esto. Opcional: Generar una versión PDF del manual (se necesitará pdflatex, makeindex y egrep para esto). make pdf El doxygen_manual.pdf manual PDF se encuentra en el directorio de látex de la distribución. 161 Arquitectura de Fault Tolerance System distribuido entre UAVs Instalación de los binarios en UNIX Después de la compilación del código fuente se hace un make install para instalar doxygen. Después de haber descargado la distribución binaria para UNIX, escriba: . / configure make install Los binarios se instalan en el directorio <prefix> / bin. Se utiliza install_docs para instalar la documentación y los ejemplos en <docdir> / doxygen. <prefix> usa por defecto /usr/local pero se puede cambiar con la opción -prefix de la secuencia de comandos de configuración. El directorio por defecto es <docdir> <prefix> /share/doc/packages y se puede cambiar con la opción-docdir del script configure. Si se prefiere, también se puede copiar los archivos binarios en el directorio bin manualmente en un directorio bin en la ruta de búsqueda. Esto es suficiente para utilizar doxygen. Se necesita la herramienta de instalación de GNU para que esto funcione (que es parte del paquete de coreutils). Otras herramientas de instalación pueden poner los binarios en el directorio equivocado. § Google Test y Google Mock. La forma más fácil para instalar Google Test en Ubuntu es instalarlo desde los repositorios de paquetes utilizando sudo apt-get install libgtest-dev Esto descargará los archivos de código fuente en /usr/src/gtest y las cabeceras de /usr/include/gtest, y cada vez que se actualiza la fuente, se descargará automáticamente. 162 Arquitectura de Fault Tolerance System distribuido entre UAVs E.- Instalación del Mercurial Abrir el gestor de paquetes Synaptic, buscar el paquete mercurial y marcarlo para su instalación. Esto hará que se instalen (si no lo están ya) otros paquetes dependientes. También es recomendable marcar el paquete tortoisehg, para tener una interfaz gráfica para el Mercurial, y el paquete tortoisehg-nautilus, para tener el Mercurial integrado en el Nautilus. Si se instala el Mercurial desde una Ubuntu Server, el comando para la instalación es el siguiente: sudo apt-get install mercurial Y se instala TortoiseHG y TortoiseHG-Nautilus. sudo apt-get install tortoisehg tortoisehg-nautilus Para instalar el plug-in de Eclipse del Mercurial, que integra Eclipse con Mercurial, hay que descargar el fichero mercurial_eclipse_1.6.0.tar.gz de los repositorios de Ubuntu, en la carpeta /Varios. Una vez esté copiado, se abre un terminal y se escribe lo siguiente (el Eclipse debe estar cerrado): cd /opt/eclipse sudo tar xzf <ruta_donde_este_el_zip> Se comprueba la correcta instalación del plug-in abriendo el Eclipse y navegando a Window > Preferences. En el árbol a la izquierda, desplegar la opción Team, y aparecerá una opción llamada Mercurial, donde se puede configurar el plug-in. Para acceder a las opciones del Mercurial (update, commit, push, pull, etc.), se hace clic con el botón derecho sobre el proyecto, y se accede al submenú Team. Si el proyecto aún no está versionado, se puede crear un nuevo repositorio pulsando sobre Share Project, y escogiendo Mercurial como motor de versionado. Instalación de la herramienta de comparación de versiones En algún momento seguramente habrá que hacer un merge de distintas versiones del repositorio. Para que esto sea más fácil, lo mejor es instalar la herramienta kdiff3, con la siguiente orden: sudo apt-get install kdiff3 163 Arquitectura de Fault Tolerance System distribuido entre UAVs F.- Configuración CI en una máquina Windows En este apartado se describen los pasos realizados en la máquina de referencia para el subproyecto que utiliza la plataforma Windows. Es importante notar que tiene clonado el repositorio aunque esto no es necesario para la máquina de referencia. De esta manera, bibliotecas comunes como Gtest o Gmock son accesibles para la ejecución de los tests. Las bibliotecas desarrolladas en estos proyectos que son necesarias para compilar otros, se tienen que generar con los propios proyectos. Los pasos realizados son: § Instalación de Windows 7. § Instalación del servidor ssh. § Instalación de Visual Studio 2010. § Creación del usuario hudson. § Instalación y configuración del hg Tortoise (cliente). § Instalación de Qt 4.8.2 y plugin para que Visual Studio reconozca los proyectos Qt (qt-vs-addin-1.1.11-opensource). Este plugin no es instalado en la máquina de compilación pero sí en la de referencia. § Instalación de jdk (jdk-7u3-windows-x64) es necesario para la instalación de WinAnt. § Instalación de Ant (winAnt): § Para instalar Winant, se necesita el archivo ejecutable de instalación. § Se ejecuta el programa de instalación para instalar Winant en la estación de trabajo. § Se busque el archivo denominado winant_setup. § Se hace doble clic en winant_setup. Entonces se abre un cuadro de diálogo Abrir archivo. § Se hace clic en Ejecutar. El asistente de instalación Winant se abre. 164 Arquitectura de Fault Tolerance System distribuido entre UAVs § Se hace clic en Siguiente. Entonces aparecerá el directorio donde la aplicación se instalará. Este puede ser seleccionable ya sea escribiendo la ruta del directorio o usando el explorador. § § Se hace clic en Siguiente. Aparecerá la carpeta del programa, donde se situara la aplicación. Se puede escribir un nombre de carpeta o seleccionar una carpeta de la lista para cambiar esta situación. § Se hace clic en Siguiente. Ahora se mostrara un resumen de la instalación. § Se hace clic en Instalar. El programa se instala en el equipo. § Se hace clic en Finalizar. Winant se incluye ahora en la lista de programas en el menú Inicio de Windows. § La aplicación Winant instala varios archivos en el ordenador. § El archivo ejecutable de instalación Winant § El archivo ejecutable de desinstalación Winant § Archivo de texto que incluye información sobre Winant § Carpeta de recursos que contiene los archivos de referencia para Winant. Instalación de Gtest y Gmock. Consiste en clonar ExternalLibraries y establecer la variable de entorno NOMBREPROYECTO_HOME con la ruta donde está clonado. Ej:C:\Projects\NOMBREPROYECTO § Instalación de doxygen (doxygen-1.7.4-setup.exe). § Instalación de RTI DDS (RTI_Professional_Edition-4.5f-WIN32_lic.exe) en C:\Program Files (x86)\RTI32, esta ruta es la utilizada en los proyectos. La licencia requiere establecer la variable de entorno RTI_LICENSE_FILE con la ruta del fichero de licencia, por ejemplo, C:\Program Files (x86)\RTI32\rti_license.dat. En la página web se puede pedir una licencia de evaluación por un mes. G.- Generar un nuevo proyecto C++ con Ant o importar uno existente Dado que el proyecto está compuesto de pequeños subproyectos independientes, es posible configurar Eclipse para solo importar el subproyecto que necesitemos. 165 Arquitectura de Fault Tolerance System distribuido entre UAVs Configuración en Eclipse Generar un nuevo proyecto con Ant Para crear un nuevo proyecto usando Ant, se deben seguir los siguientes pasos: § File > New > Project. § Seleccionar C++ Project. § Indicar el nombre del proyecto que queramos para Eclipse y hacer clic en Next >. § En la siguiente ventana hacer clic en Advanced Settings... § En la barra lateral izquierda seleccionar C/C++ Build. § En la pestaña Builder Settings deseleccionar las opciones: § Use Default build command. 166 Arquitectura de Fault Tolerance System distribuido entre UAVs § § Generate Makefiles automatically. En la pestaña Behaviour deseleccionar las opciones: § Build (Incremental build). § Clean. Si además se quiere definir una referencia a un proyecto padre que ya está importado en Eclipse, hacer: 167 Arquitectura de Fault Tolerance System distribuido entre UAVs § Clic en Project References en la barra lateral izquierda. § Seleccionar los proyectos que queramos de referencia. § Finalmente hacer clic en OK y después en Finish. Importar proyecto Para importar un proyecto ya existente en el Workspace, se tendrían que seguir los siguientes pasos: 168 Arquitectura de Fault Tolerance System distribuido entre UAVs § Generar un proyecto nuevo como se indica en el apartado anterior. § Clonar el repositorio del proyecto que se quiere configurar. § Arrastrar el contenido de la carpeta del proyecto (la física) al proyecto de Eclipse creado y seleccionar la opción Link to files and folders para que edite los ficheros sobre el path original del proyecto (de este modo los ficheros no se copiaran a el workspace). § Finalmente hacer clic en Apply y después OK. La penúltima opción se puede descartar, y mover directamente el contenido de la carpeta clonada a la carpeta del proyecto. 169 Arquitectura de Fault Tolerance System distribuido entre UAVs H. Migrar un proyecto de Eclipse a Visual Studio Copiando el proyecto de Eclipse Lo primero que se debe hacer es copiar el contenido de la carpeta del proyecto que se quiere migrar en la carpeta que va a albergar el contenido del nuevo proyecto en Visual Studio. Es decir, se crea la carpeta para el workspace (Solution) y la carpeta del proyecto, por ejemplo CL. Normalmente, el contenido de los proyectos se encuentra en el repositorio, por lo que habrá que clonar el repositorio. Para ello, es necesario tener instalado Mercurial. Creando el nuevo proyecto en Visual Studio Ahora, ya en Visual Studio, se crea el nuevo proyecto mediante: File -> New -> Project from existing code... Seguidamente se rellenan los campos Project file location y Project name El uso de estos campos es el siguiente: Project file location: C:\...\workspaceName\ProjectName Project name: ProjectName En la siguiente ventana se selecciona la opción Use external build system, si se quiere utilizar una herramienta de compilación externa, como por ejemplo Ant. En la siguiente ventana se dejan los campos vacíos, y se finaliza. 170 Arquitectura de Fault Tolerance System distribuido entre UAVs Compilando el nuevo proyecto Ahora para compilar correctamente el proyecto se debe instalar y configurar ANT. Editando el script para la correcta compilación de ANT El script que compila ANT en Eclipse dispone de una sintaxis que debe ser levemente modificada para compilar ANT en Visual Studio. Estos cambios son los siguientes: - Invocación al compilador: En Eclipse debe estar contemplado entre los elementos <cc> name="g++"...</cc> En Visual Studio debe estar contemplado enntre los elementos <cc> name="msvc"...</cc> Además hay que modificar las rutas de los includepath con sus correspondientes rutas en Windows. 171 Arquitectura de Fault Tolerance System distribuido entre UAVs Como trabaja Mercurial 1. Que hay en el repositorio Los repositorios Mercurial contienen un directorio de trabajo, junto con un archivo: El archivo contiene la historia completa del proyecto, cada directorio de trabajo se combina con una copia privada de la historia. Esto permite el desarrollo en paralelo. El directorio de trabajo contiene una copia de los archivos del proyecto en un punto dado en el tiempo. Dado que las etiquetas y los archivos ignorados están bajo control de revisiones, también son incluidos. 2. Committing cambios Cuando se sube cambios a repositorio (commit) se registra como un nuevo conjunto de cambios (también llamado una nueva "revisión"): 172 Arquitectura de Fault Tolerance System distribuido entre UAVs 3. Revisions, changesets, heads, and tip Mercurial agrupa los cambios relacionados con varios archivos en changesets, los cuales son revisiones de todo el proyecto. Cada uno de estos recibe un número secuencial de revisión. Debido a que Mercurial permite el desarrollo distribuido en paralelo, estos números de revisión pueden diferir entre los usuarios. En este sentido Mercurial también asigna a cada revisión un ID de changeset global. Estos IDs son números hexadecimales de 40 dígitos, pero se pueden abreviar a cualquier prefijo inequívoco. Las ramas (branches) y combinaciones (merges) de revisiones pueden ocurrir en cualquier momento del desarrollo. Cada rama sin combinar crea un nuevo head en el historial de revisiones. 4. Un sistema centralizado Mercurial es un sistema completamente descentralizado, y por lo tanto no tiene una noción interna de un repositorio central. Así, los usuarios tienen la libertad de definir sus propias topologías para compartir los cambios: 173 Arquitectura de Fault Tolerance System distribuido entre UAVs A diferencia de SVN/CVS, donde se suele albergar todo los proyectos relacionados en un mismo repositorio, Mercurial no fue diseñado para esto, si no para albergar proyectos en diferentes repositorios. I.- Calidades de servicio en DDS (QoS) DDS permite modificar la calidad de servicio de la comunicación. Para ello se utilizan ficheros xml en los cuales se pueden modificar los parámetros referentes a los participantes, publicadores, subscriptores y tópicos. Decir que según la QoS que utilice cada aplicación, habrá comunicación entre las diferentes partes o no (ya que pueden ser, o no, compatibles entre ellas según se requiera). Obviamente la compatibilidad viene dada de la siguiente manera: la entidad que recibe datos no puede recibirlos a mayor calidad de la que se envía, pero sí puede exigir recibirla a menor calidad de la enviada. Por poner un ejemplo, se tiene un publicador de datos de telemetría, y dos subscriptores: uno de estos subcriptores únicamente representa los datos en tiempo real, mientras que el otro requiere que no haya pérdidas de ningún dato para poder almacenarlos para su posterior procesamiento. Si el publicador dispone de la máxima calidad en su fichero QoS, el primer subscriptor puede recibir a menor calidad (ya que es importante la rapidez aunque se pierda algún dato), y el segundo subscriptor puede recibir a la misma calidad que el publicador. 174 Arquitectura de Fault Tolerance System distribuido entre UAVs QoS predefinidas de DDS Por defecto, DDS nos ofrece tres perfiles básicos de QoS, los cuales se pueden utilizar tal cual, o modificar según las necesidades de cada aplicación. RELIABLE Es el perfil por defecto. Con esta QoS se garantiza el envío y la recepción de todos los datos. HIGH THROUGHPUT Pensado para redes de alto rendimiento en las que el ancho de banda no es problema. Es el perfil que más recursos consume, tanto de CPU de cada máquina como de memoria utilizada por DDS. LOSSY NETWORK Es un perfil destinado a utilizarse en redes que presenten muchas pérdidas. Modificar un perfil En un mismo fichero xml, podemos disponer de todos los perfiles necesarios. La estructura del fichero es como sigue: <dds> <qos_library name="NOMBREPROYECTO"> <qos_profile name="NombreDelPerfil" is_default_qos="true"> <datareader_qos> //Propiedades del subscriptor </datareader_qos> <datawriter_qos> //Propiedades del publicador </datawriter_qos> <participant_qos> //Propiedades del participante </participant_qos> </qos_profile> </qos_library> <qos_library name="SiguientePerfil" base_name="NombreDelPerfil"> ... </qos_library> </dds> Los siguientes perfiles se pueden basar en alguno que esté ya hecho, sin más que añadir la opción de base_name y pasándole el nombre del perfil del que va a heredar. Seguidamente sólo resta reescribir las propiedades que cambian respecto al perfil base, y añadir las que sean necesarias. 175 Arquitectura de Fault Tolerance System distribuido entre UAVs Propiedades de las entidades Las entidades disponibles en DDS son: data writer, data reader, participant, subscriber, publisher y topic. Todas las entidades tienen propiedades comunes tales como reliability (para definir el nivel de fiabilidad) o history (para definir la cantidad de datos almacenados en el historial). Por otro lado, disponen de propiedades únicas a cada uno, como por ejemplo <writer_resource_limits> en el caso del data writer. <reliability> <kind>BEST_EFFORT_RELIABILITY_QOS</kind> <max_blocking_time> <sec>DURATION_ZERO_SEC</sec> <nanosec>100000000</nanosec> </max_blocking_time> </reliability> En reliability se utilizan parámetros para definir el nivel de fiabilidad. <history> <kind>KEEP_LAST_HISTORY_QOS</kind> <depth>1</depth> <refilter>NONE_REFILTER_QOS</refilter> </history> En history se determina el tamaño del historial de datos. <resource_limits> <max_samples>5</max_samples> <max_instances>1</max_instances> <max_samples_per_instance>5</max_samples_per_instance> <initial_samples>2</initial_samples> <initial_instances>1</initial_instances> </resource_limits> Se especifican los recursos disponibles para la entidad. <reader_resource_limits> <max_remote_writers>1</max_remote_writers> <max_remote_writers_per_instance>1</max_remote_writers_per_instance> <max_samples_per_remote_writer>5</max_samples_per_remote_writer> <initial_remote_writers>1</initial_remote_writers> <initial_remote_writers_per_instance>1</initial_remote_writers_per_ins tance> <initial_infos>1</initial_infos> <initial_outstanding_reads>1</initial_outstanding_reads> <max_samples_per_read>5</max_samples_per_read> <disable_fragmentation_support>false</disable_fragmentation_support> <max_fragmented_samples>5</max_fragmented_samples> <initial_fragmented_samples>1</initial_fragmented_samples> <max_fragmented_samples_per_remote_writer>5</max_fragmented_samples_pe r_remote_writer> <max_fragments_per_sample>128</max_fragments_per_sample> <dynamically_allocate_fragmented_samples>false</dynamically_allocate_f ragmented_samples> <max_total_instances>1</max_total_instances> </reader_resource_limits> Propiedad específica para definir recursos disponibles del data reader. <protocol> 176 Arquitectura de Fault Tolerance System distribuido entre UAVs <rtps_reliable_reader> <min_heartbeat_response_delay> <sec>0</sec> <nanosec>0</nanosec> </min_heartbeat_response_delay> <max_heartbeat_response_delay> <sec>0</sec> <nanosec>0</nanosec> </max_heartbeat_response_delay> </rtps_reliable_reader> </protocol> Propiedad específica para definir recursos disponibles del data reader. QoS profiles El proyecto comprende la transmisión de datos en tiempo real para su representación visual y envío de comandos para controlar los diferentes sistemas conectados. Dada la gran cantidad de información a enviar por segundo, se configura la QoS para ahorrar recursos de los equipos lo que conlleva a no verificar si un dato ha sido enviado, a no guardar el historial de datos, etc. Por ello se utiliza el perfil llamado Last, que hace referencia al comportamiento del historial, ya que sólo guarda la última muestra a enviar/recibir. El perfil Reliable y HighThroughput se mantienen en caso de que aplicaciones futuras no requieran tal volumen de datos o no necesiten comunicaciones en tiempo real. J.- Entorno de desarrollo con CI Se ha configurado un entorno de integración continua bajo máquinas linux. El objetivo principal es, a cada cambio que se genera durante el desarrollo, lanzar el proceso por el cual se compila el proyecto con dichos cambios y se ejecutan, en una máquina de referencia idéntica a la de producción del cliente, todas las pruebas pertinentes para asegurarnos de que nada se haya roto durante la última subida al repositorio y evitar sorpresas en la entrega de distribuciones al cliente. El entorno de integración continua consta de varios elementos: · Servidor de Integración Continua Hudson. · Respositorio de versiones Mercurial Server. · Servidor de compilación. · Máquina de referencia. 177 Arquitectura de Fault Tolerance System distribuido entre UAVs El funcionamiento, en definitiva, es como se explica en la siguiente imágen: En los próximos párrafos se describe en detalle cada una de las máquinas implicadas. Servidor de Integración Continua Hudson 178 Arquitectura de Fault Tolerance System distribuido entre UAVs El Servidor de CI es quién orquesta todo el proceso. En la página principal podremos ver un resumen con todos los proyectos que tenemos configurados. Los señalados en la siguiente imagen son los configurados para la capa de comunicación y para la capa de abstracción hardware. Hudson consulta periódicamente al repositorio para ver si existen cambios. Si así fuera, ejecutaría lo que tuviera programado hacer. En este caso, conectarse a la máquina de compilación y ejecutar un script. 179 Arquitectura de Fault Tolerance System distribuido entre UAVs 180 Arquitectura de Fault Tolerance System distribuido entre UAVs A partir de entonces, la máquina de compilación envía hasta el final del proceso el resultado de la ejecución de dicho script, redirigiendo la salida estándar a Hudson. Así Hudson mantiene un histórico con todas las ejecuciones que se han realizado y su resultado. Para poder entrar por ssh desde el servidor hudson a la máquina de compilación, se debe tener configurada la clave pública para que no nos la pida cada vez que queramos conectar. Al ser una aplicación web desplegada en un Tomcat, se debe acceder por el puerto 8080. Repositorio de versiones Mercurial Server Se tendrá una máquina que contendrá siempre versiones actualizadas de los últimos cambios del proyecto, gestionado por un repositorio de versiones Mercurial. Se tendrá como repositorio remoto y se subirán los cambios a él. En el momento de que se produzca alguno, Hudson que está siempre consultándole, ejecutará los scripts que tiene asociados para iniciar todo el proceso de CI. El servidor Mercurial está publicado a través de un servidor Apache por https, como recomiendan para entornos de desarrollo serios los desarrolladores de Mercurial. Servidor de compilación Esta máquina es la que se encargará de lanzar el script que pondrá en marcha el grueso del proceso. Tras un script ant (Ant de Apache) se ejecutarán los pasos a seguir para la ejecución de las pruebas: · · · · Se descargarán los cambios del respositorio. Se compilarán las librerías, instalables y ejecutables (tanto de pruebas como de aplicación, si fuera necesario) del proyecto. Se copiarán los ejecutables, librerías e instalables imprescindibles a la máquina de referencia junto con el script específico con las acciones a realizar por la máquina de referencia. Se le indicará a la máquina de referencia que ejecute su script. 181 Arquitectura de Fault Tolerance System distribuido entre UAVs Máquina de referencia Esta máquina es la que se encargará de probar que todo funciona correctamente y que los ejecutables y paquetes de instalación que se generan son los que el cliente requiere. La máquina de compilación habrá copiado todo lo necesario para las comprobaciones que ha de realizar la máquina de referencia, incluido el script con todos los pasos que debe seguir: · · · Se ejecutan las pruebas unitarias Se ejecutan las pruebas de integración Se genera los .debs necesarios con los instalables, librerías, código fuente y documentación del proyecto. 182