Instalación

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