Sistema de gestión y control de ficheros de configuración para robots NAO aplicado a competiciones SPL Robocup

UNIVERSITAT POLITÈCNICA DE VALÈNCIA INGENIERÍA INFORMÁTICA SISTEMA DE GESTIÓN Y CONTROL DE FICHEROS DE CONFIGURACIÓN PARA ROBOTS NAO APLICADO A COMPETICIONES SPL ROBOCUP Proyecto Final de Carrera Presentado por: Jorge Sanmartín Martínez Dirigido por: Juan Francisco Blanes Noguera Valencia, Septiembre 2011 AGRADECIMIENTOS Quisiera dar las gracias a todas las personas que han formado parte de mi vida durante este paso por la Universidad, especialmente a mi familia y a mis amigos que me han apoyado durante estos años, y han hecho que esto sea posible. Me gustaría agradecer también a todos los profesores que me han enseñado y formado durante sus clases, y a todos mis compañeros, muchos de ellos grandes amigos ahora, que me han acompañado durante este paso por la Universidad, y han hecho tan especial esta etapa de mi vida. Sin todos ellos esto no hubiera sido posible. RESUMEN Este proyecto final de carrera tiene por objetivo dotar de flexibilidad al sistema empotrado del robot Humanoide Nao a la hora de configurar parámetros de control y ejecución de los procesos en ejecución. Para ello se diseñará y desarrollará un sistema informático, con el fin de gestionar un conjunto de ficheros de parametrización del control del sistema empotrado, incrementando de esta forma la flexibilidad del sistema y evitando errores sintácticos que desencadenan comportamientos no deseados por parte del robot. Palabras Clave: Robótica humanoide, Sistema empotrado, Comunicaciones, Sintaxis XML Índice 1 – Introducción 1.1 Robots humanoides 1.2 Robot Nao 1.3 Entorno de desarrollo en Nao 1.4 Standard Platform League Robocup 2 – Objetivos 3 – Diseño de sistema 3.1 Secure Shell (SSH) 3.2 Secure Copy (SCP) 3.3 Archivo de configuración .INI 3.4 Archivo XML 3.5 Diccionario de datos 4 – Desarrollo de soporte de comunicaciones 4.1 Conexión SSH 4.2 Intercambio de ficheros 4.3 Traducción de .INI a XML 4.4 Edición y modificación de ficheros XML 4.5 Diccionario de datos 5 – Diseño y desarrollo de la interfaz gráfica de usuario 6 - Conclusiones 7– Anexo: 6.1 Manual de usuario 6.2 Manual de desarrollador 8 - Bibliografía Capitulo 1 INTRODUCCIÓN 1.1 Robots humanoides La robótica, según una de sus definiciones más sencillas, es la ciencia y la tecnología de los robots. Se ocupa del diseño, manufactura y aplicaciones de los robots. La robótica combina diversas disciplinas como son la mecánica, la electrónica, la informática, la inteligencia artificial y la ingeniería de control. Isaac Asimov fue el primero en introducir el término robótica tal y como lo entendemos en la actualidad, con una versión más humanizada y como una disciplina encargada de construir y programar robots. Este autor plantea una serie de reglas que debe cumplir todo robot, más conocidas como las Tres leyes de la robótica. • Un robot no puede hacer daño a un ser humano o, por inacción, permitir que un ser humano sufra daños. • Un robot debe obedecer las órdenes dadas por los seres humanos, excepto si estas órdenes entrasen en conflicto con la Primera Ley. • Un robot debe proteger su propia existencia en la medida en que esta protección no entre en conflicto con la Primera o Segunda Ley. Estas leyes surgen como medida de protección para los seres humanos. Según el propio Asimov, la concepción de las leyes de la robótica quería contrarrestar un supuesto temor que el ser humano desarrollaría frente a unas máquinas que hipotéticamente pudieran rebelarse y alzarse contra sus creadores. Asimov crear un universo en el que los robots son parte fundamental durante los próximos años de la historia humana, incrementando su nivel de complejidad cada vez más. Entender y aplicar lo anteriormente expuesto requiere verdadera inteligencia y consciencia del mundo real por parte del robot, algo que a pesar de los avances tecnológicos de la era moderna no se ha llegado. Figura 1.1 Podemos hacer una clasificación de los robots dependiendo de su arquitectura, definida por el tipo de configuración general del robot, y se puede subdividir en los siguientes grupos: poliarticulados, móviles, androides, zoomórficos e híbridos. Los robots humanoides o androides son robots que intentan reproducir total o parcialmente la forma y el comportamiento cinemática del ser humano. Uno de los aspectos más complejos de estos robots y sobre el que se centra la mayoría de los trabajos, es el de la locomoción bípeda. En este caso, el principal problema es el control dinámica y coordinadamente en tiempo real del proceso y mantener simultáneamente el equilibrio del robot. El androide siempre ha sido representado como una entidad que imita al ser humano tanto en apariencia como en habilidades mentales y de movimiento. Las principales ventajas que tienen los robots humanoides respecto a otro tipo de configuraciones son dos: • Facilitan la interacción con otros humanos. • Se adaptan rápidamente a entornos y herramientas diseñados para humanos. Sin embargo, la construcción de un robot que imite convincentemente la libertad de gestos y movimientos humanos, es una tarea de una enorme complejidad técnica. De hecho, es un problema que está todavía abierto a la investigación y la mejora, aunque existen ciertos ejemplos bastante meritorios en este sentido, que imitan ciertas conductas y capacidades humanas. Figura 1.2 1.2 Robot Nao Dentro de este grupo de robots humanoides se encuentra el modelo Nao de la empresa francesa Aldebaran Robotics usados en la SPL (Standard Platform League). Existen prototipos para utilizar en el área de la investigación en experimentos de locomoción, localización, reconocimiento de objetos y comunicación. En Agosto de 2007, Nao sustituye al perro robot Aibo de Sony como la plataforma estándar para la Robocup, un concurso internacional de robótica. El modelo Nao de Aldebaran cuenta con un gran número de sensores y grados de libertad, de tecnología puntera, programable y controlable, permitiendo realizar movimientos precisos y coordinados. Nao ofrece una representación de la figura humana a tamaño reducido, mide 58 cm de altura, y pesa 4,3 kg y la carcasa está fabricada en plástico. Dispone de un cargador que funciona a 90-230 voltios, y una batería con una autonomía de unos 90 minutos aproximadamente. El robot dispone de módulos software que permiten la reproducción de archivos de texto a voz, localización basada en sonido, reconocimiento de formas y creación de efectos visuales mediante sus LEDs. Figura 1.3 El robot Nao posee 21 grados de libertad, 2 en la cabeza, 4 en cada brazo, 1 en la pelvis y 5 en cada pierna. En la tabla 1.1 podemos ver la distribución de las articulaciones, sus movimientos, su rango de actuación y el tipo de actuador. Tabla 1.1 Capitulo 2 OBJETIVOS Este proyecto final de carrera tiene por objetivo dotar de flexibilidad al sistema empotrado del robot Humanoide Nao a la hora de configurar parámetros de control y ejecución de los procesos en ejecución. Para cumplir con este objetivo general se ha trabajado en el diseño e implementación un sistema de gestión de ficheros de configuración bajo sintaxis XML, capaz de gestionar, modificar y actualizar los archivos de configuración de un robot, de manera rápida y eficaz, y crear un diccionario de datos en el sistema empotrado de control que el robot pueda interpretar para ejecutar dichos parámetros durante las competiciones. Como etapas a cubrir en el desarrollo general del proyecto podemos enunciar: • El diseño y desarrollo de una interfaz gráfica fácil de usar y amigable con el usuario, que sea capaz de mostrar toda la información necesaria, y de ejecutar las acciones necesarias. • El desarrollo de las comunicaciones vía Internet, siguiendo unos protocolos seguros de forma que la información que enviemos llegue a su destino de forma fiable. • El desarrollo de unos módulos de interpretación XML para sistemas de control, capaces de obtener la información contenida en este tipo de ficheros y de modificar estos ficheros para diferentes usos. • La validación y verificación de la información contenida en estos ficheros de configuración, evitando de esta forma posibles errores que puedan llevar a comportamientos no deseados por parte del robot. Por todo ello, esta aplicación está desarrollada para que dentro de la competición de la SPL Robocup, sea posible la modificación de estos archivos de configuración de manera rápida y segura, evitando de esta forma errores de sintaxis en los archivos que puedan a llevar a fallos en el comportamiento del robot durante la competición. Capitulo 3 DISEÑO DE SISTEMA 3.1 Secure Shell (SSH) El primer objetivo del proyecto es mantener una conexión abierta con un robot específico con la intención de poder hacer un intercambio de ficheros. Para ello hacemos uso del protocolo SSH (Secure Shell) que nos sirve para acceder a maquinas remotas a través de la red. Nos permite manejar el equipo destino, mediante un intérprete de comandos, de manera remota desde nuestro propio equipo. Esto nos es de utilidad para el proyecto de forma que podremos analizar el sistema de archivos del robot y ejecutar órdenes en el robot desde nuestro equipo. Existen diversos protocolos para la conexión y transferencia de archivos remotos, como puede ser Telnet, pero la principal ventaja de SSH con respecto a la seguridad, es que usa técnicas de cifrado que hacen que la información que viaja por el medio de comunicación vaya de manera no legible y ninguna tercera persona pueda descubrir el usuario y contraseña de la conexión ni lo que se escribe durante toda la sesión. Para este tipo de conexiones, además de especificar la dirección del robot al que nos queremos conectar, deberemos introducir el usuario y contraseña, de formar que se asegura una conexión más segura. Figura 3.1 Una de las formas de autenticación del usuario en SSH es mediante el cifrado de llave pública. Para este tipo de autenticación se dispone de una llave pública, que es la que se aloja en los equipos a los que se quiere acceder, y una llave privada, que solamente dispone el propietario y se mantiene en secreto. De esta manera cuando un usuario cifra algo con su llave privada, solamente es aceptado en el destino si se puede descifrar con la llave pública alojada en el equipo. Aun teniendo este par de llaves para el cifrado de mensajes, para mayor seguridad de la llave privada se puede pedir la contraseña al usuario. En sistemas Unix, la lista de llaves autorizadas para el acceso remoto está almacenada en la carpeta authorized_keys de ssh. Como hemos dicho anteriormente el uso típico del protocolo SSH es el de conectarse a una maquina remota y poder ejecutar comandos, aunque también es posible la transferencia de archivos remotos mediante los protocolos SFTP y SCP, del que hablaremos más tarde. El puerto utilizado por defecto para este tipo de protocolos es el puerto 22 de TCP, aunque se puede modificar a un puerto no estándar como medida extra de seguridad. Respecto a la arquitectura interna del protocolo SSH (definido en el RFC 4251) podemos ver las diferentes capas que la compone: • Capa de transporte (RFC 4253). Esta capa se encarga de iniciar el intercambio de llaves, así como de la autenticación y de verificar la encriptación, comprensión e integración del mensaje. Provee a la capa superior de una interfaz capaz de mandar y recibir paquetes de 32.768 bytes cada uno (más de lo que está permitido en la implementación). • Capa de autenticación de usuario (RFC 4252). Esta capa maneja la autenticación del cliente y le provee de distintos métodos de autenticación para poder conectarse. La autenticación debe ser parte del cliente, por lo que cuando se hace la petición de contraseña, es la parte cliente la que debe facilitarla y no la parte servidor. El servidor simplemente contesta a la petición de autenticación por parte del cliente. Los posibles métodos incluidos en la autenticación son los siguientes: o contraseña: un método de autenticación mediante contraseña de texto plano por parte del cliente, con la facilidad de que la contraseña puede ser cambiada por parte del usuario. o clave pública: un método de autenticación basado en la clave pública, que normalmente soporta al menos los pares de llaves DSA o RSA. o interactiva por teclado: un modo versátil en el que el servidor es el que pide la contraseña y el cliente es el que debe de introducir la información por pantalla y enviársela de nuevo al servidor. Es usada sobre todo para la autenticación de contraseñas una sola vez como puede ser S/Key o SecurID. o GSSAPI: un método de autenticación el cual provee un esquema extensible que provee SSH en el que se usan mecanismos externos como Kerberos 5 o NTLM. Este tipo de métodos son normalmente usados para implementaciones comerciales de SSH para su uso en organizaciones. • Capa de conexión (RFC 4254). Esta capa define el concepto de canales, petición de canales y peticiones globales usando los servicios que provee SSH. Una conexión simple de SSH puede albergar diferentes canales simultáneamente, cada una de ellas transfiriendo datos en ambas direcciones. La petición de canales es usada para retransmitir datos específicos en canales fuera de la banda normal, como puede ser el cambio de tamaño de la ventana de un terminal. • El almacenamiento SSHFP DNS (RFC 4255), provee un almacenamiento de claves públicas de host para añadir una verificación de la autenticación en las diferentes sesiones del host. Figura 3.2 Este tipo de arquitectura abierta provee una considerable flexibilidad, permitiendo a SSH ser usado para una variedad de propósitos usando el Secure Shell. Las funcionalidades de la capa de transporte son comparables a la Capa de Seguridad de Transporte (TLS); la autenticación del usuario es extensible con múltiples métodos de autenticación; y la capa de conexión provee la habilidad de abrir múltiples sesiones secundarias en una sola conexión SSH, una característica comparable a BEEP y no disponible en TLS. 3.2 Secure Copy (SCP) Tras analizar cuáles son las principales del protocolo SSH, con el que principalmente nos vamos a conectar remotamente a un equipo destino y ejecutar comandos sobre este, nos vamos a centrar ahora en el intercambio de ficheros. Para el intercambio de ficheros entre equipos remotos hacemos uso de SCP o Secure Copy, el cual es un medio de transferencia seguro de archivos informáticos entre un host local y otro remoto o entre dos hosts remotos, usando el protocolo Secure Shell SSH. La característica principal de SCP es que los datos son cifrados durante su transferencia, para evitar que potenciales packet sniffers extraigan información útil de los paquetes de datos. Sin embargo, el protocolo mismo no provee autenticación y seguridad, sino que espera que el protocolo subyacente, SSH, lo asegure. La descripción de un formato de comunicación en las cabeceras enviadas por la red es la que podemos ver en la figura 3.3: Figura 3.3 El modo SCP es un protocolo simple que deja al cliente y al servidor tener múltiples conversaciones sobre una TCP normal. Este protocolo está diseñado para ser simple de implementar. El servicio principal es el control del dialogo entre el servidor y el cliente, administrando sus conversaciones y agilizadas a un alto porcentaje. SCP puede solicitar de manera iterativa cualquier contraseña para establecer una conexión con un host remoto El protocolo SCP implementa la transferencia de archivos únicamente. Para ello se conecta al host usando SSH y allí ejecuta un servidor SCP. Para realizar la subida, el cliente proporciona al servidor los archivos que desea subir y opcionalmente puede incluir otros atributos, como permisos, fechas, etc., lo que es una ventaja respecto a otros protocolos como FTP. Para descargar, el cliente enviar una solicitud por los archivos que desea descargar, el proceso de descarga está dirigido por el servidor y es el que se encarga de la seguridad del mismo. El cliente SCP más utilizado es el programa scp del intérprete de comandos, que está incorporado en la mayoría de las implementaciones de SSH. La sintaxis del programa scp es similar a la sintaxis de la orden de copia cp: scp usuario@host:directorio/ArchivoOrigen ArchivoDestino scp ArchivoOrigen usuario@host:directorio/ArchivoDestino Por tanto con los protocolos SSH y SCP, anteriormente explicados, tenemos las funcionalidades de conexión remota, ejecución de comandos remotamente y la transferencia de archivos entre equipos remotos. Todo esto nos es muy útil en el proyecto para la conexión remota a un robot, y la transferencia de archivos entre el equipo local y el robot remoto, pudiendo hacer modificaciones sobre archivos contenidos en el robot y pudiendo enviarlos de nuevo tras la modificación. 3.3 Archivos de configuración .INI Esta es la función principal de nuestro proyecto, y los archivos que queremos modificar son los archivos de inicialización del robot, los llamados archivos .INI. Un archivo .INI consiste en un simple archivo de texto ASCII que contiene dos tipos de entradas: • Secciones: permiten agrupar parámetros relacionados. • Valores: definen parámetros y su valor. Primero se define el nombre del parámetro y después su valor separado por el signo de igualdad (=). • Comentarios: permiten explicar el propósito de una sección o parámetro. Los comentarios comienzan con el carácter punto y coma (;) u otro caracteres como (# o //). El significado de secciones y valores no está bien definido y cada aplicación puede reaccionar de manera diferente ante secciones duplicadas, parámetros duplicados o valores, que pueden consistir en texto, números o listas separadas por comas. Esto depende de la aplicación. Un ejemplo de nuestro archivo INIT.INI tiene la forma que se muestra en la figura 3.4, donde se pueden observar los parámetros definidos con sus valores correspondientes, y los comentarios añadidos al fichero. Figura 3.4 Tras ejecutar una aplicación, sus parámetros de configuración por defecto son los que están almacenados en el archivo .INI, y son los que se ejecutan al inicio para definir el estado inicial de la aplicación. Adicionalmente, cualquier usuario puede abrir el fichero .INI con un editor de texto y modificarlo, en caso de un mal funcionamiento de aplicación o que se quieran modificar los parámetros iniciales. Pese a todo esto, queremos modificar estos archivos .INI por archivos XML. Con ellos conseguimos una organización de los ficheros en un formato más estructurado y una sintaxis más adecuada para que nuestro programa sea capaz de analizar y modificar estos archivos. 3.4 Archivo XML El archivo XML, siglas en inglés de eXtensible Markup Language, es un metalenguaje extensible de etiquetas desarrollado por el Worl Wide Web Consortium (W3C). Es una simplificación y adaptación del SGML y permite definir la gramática de lenguajes específicos; por tanto XML no es realmente un lenguaje en particular, sino una manera de definir lenguajes para diferentes necesidades. XML no ha nacido sólo para su aplicación en Internet, sino que se propone como un estándar para el intercambio de información estructurada entre diferentes plataformas. Se puede usar en bases de datos, editores de textos, hojas de cálculo, etc. XML es una tecnología sencilla que tiene a su alrededor otras que la complementan y la hacen mucho más 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 información de una manera segura, fiable y fácil. XML y sus extensiones han recibido multitud de críticas por su nivel de detalle y complejidad. El mapeo del modelo de árbol básico de XML hacia los sistemas de tipos de lenguajes de programación o bases de datos puede ser difícil, especialmente cuando se utiliza XML para el intercambio de datos altamente estructurados entre aplicaciones. Pero este no era su primer objetivo al diseñarlo y en cambio dispone de otras muchas ventajas: • Es extensible: después de diseñado y puesto en producción, es posible extender XML con la adición de nuevas etiquetas, de modo que se pueda continuar utilizando sin complicación alguna. • El analizador es un componente estándar, no es necesario crear un analizador específico para cada versión de lenguaje XML, por lo que posibilita el empleo de cualquiera de los analizadores disponibles. • Si un tercero decide usar un documento creado en XML, es sencillo de entender su estructura y procesarla. Mejora así la compatibilidad entre aplicaciones, y podemos comunicar aplicaciones de distintas plataformas sin que importe el origen de los datos. • Y una de las más importantes, es que transformamos fatos en información, pues se le añade un significado concreto y los asociamos a un contexto, con lo cual tenemos flexibilidad para estructurar documentos. En cuanto a la estructura de un documento XML, la tecnología XML busca dar solución al problema de expresar información estructurada de la manera más abstracta y reutilizable posible. Que la información sea estructurada quiere decir que se compone de partes bien definidas, y que esas partes se componen a su vez de otras partes. Una etiqueta consiste en una marca hecha en el documento, que señala una porción de éste como un elemento. Las etiquetas tiene la forma <nombre>, donde nombre es el nombre del elemento que se está señalando. En la figura 3.5 podemos observar el archivo de inicialización INIT.INI anterior en formato XML. Figura 3.5 En este archivo INIT.xml se puede observar la misma información que en el archivo anterior, pero de una manera estructurada, donde los parámetros pasan a ser las etiquetas y el valor correspondiente está definido entre las etiquetas. Esta sería una manera simple de representar nuestra información en forma de árbol, donde la etiqueta root es nuestro nodo raíz, y partir de él están representados el resto de parámetros con sus valores como nodos hojas. Ahora bien, para que un documento XML funcione correctamente y no contenga errores, debe de seguir algunas definiciones básicas. Los documentos denominados “bien formados” (del inglés well formed) son aquellos que cumplen con todas las definiciones básicas de formato y pueden, por lo tanto, analizarse correctamente con cualquier analizador sintáctico (parser) que cumpla con la norma. Figura 4.3 Tras conseguir esta traducción, ya disponemos del fichero XML con el que vamos a trabajar a partir de ahora. Este archivo va a contener la misma información que el antiguo fichero de configuración, pero con el formato XML. Ahora nuestro objetivo es extraer la información contenida en el archivo XML. Para ello hacemos un “parseo” del archivo, recorriendo todo el árbol; primero extraemos la raíz del árbol con la instrucción “getRootElement” y a partir de ahí conseguimos la lista de hijos, que a continuación recorremos para conseguir la información. Figura 4.4 Este tipo de parseo, en forma de árbol, lo vamos a utilizar continuamente durante la aplicación puesto que vamos necesitar extraer la información de los ficheros, para actualizarlos y modificar o añadir determinados parámetros. 4.4 Edición y modificación XML Y por último, nos vamos a centrar en la edición y modificación de los ficheros XML. Como hemos dicho, nuestro objetivo principal en este proyecto es el de poder modificar ficheros de configuración del robot y volver a enviarlos. La forma de proceder va a ser la de leer un fichero XML ya creado y con información, o la de crear un fichero desde el inicio, con la ayuda de una plantilla que nos va a ayudar en este trabajo. Si queremos construir un fichero de configuración desde cero, vamos a tener la ayuda de una plantilla, que vamos a cargar inicialmente, en el que se nos van a presentar todos los valores posibles de los parámetros que podemos dar valor en cada tipo de fichero. Para ello hemos definido unas plantillas con los siguientes campos: • Edit: Indicaremos si el campos es editable “true” (podemos escribir datos sobre él), o si no lo es “false” (deberemos elegir los datos de una lista). Este campo tiene un valor especial “extra” para ciertos campos que van a aparecer dependiendo del número de extras que indiquemos. • Tipo: Indicaremos el tipo de variable que vamos a utilizar en este campo, normalmente utilizaremos los tipos “int” para enteros o “string” para cadenas de texto. • Min_Range: En el caso de que el campo sea editable, indicaremos cual es el valor mínimo que se le puede al atributo. • Max_Range: Igual que en el caso anterior, si el campo es editable, indicaremos el valor máximo que puede tomar el atributo. • Default_Value: Por defecto, le asignaremos un valor al campo. • Enum_Value: En el caso de que el campo no sea editable, necesitaremos ofrecer al usuario una lista con los valores que puede elegir. En este campo añadiremos los valores que va a contener la lista, para que el usuario pueda elegir uno entre ellos. En nuestra aplicación esto se verá reflejado en una pantalla en la que iremos rellenando los valores de los parámetros, o dejando en blanco (valor “null”) los que no queramos configurar. El documento de la figura 4.5 es la forma que tendría un ejemplo de plantilla para un tipo de fichero determinado, en el que se pueden observar sus campos y los valores permitidos. Figura 4.5 La otra opción es la de cargar un fichero XML con valores ya configurados. En este caso nosotros nos vamos a limitar a mostrar estos campos por pantalla y permitir su modificación mediante los campos correspondientes. Ambas opciones se basan en la plantilla del fichero que vamos a editar, el cual nos proporcionará todos los datos acerca del tipo de los parámetros y los valores que estos pueden tomar. La implementación de esta parte, se basa como hemos dicho en cargar una plantilla definida en un archivo XML, el cual vamos a tener que parsear, para extraer la información de cada uno de los parámetros. El parseo de las plantillas es muy parecido al de los ficheros, recorriendo todos los hijos de la raíz, y en este caso, dentro de cada hijo dispondremos de toda la información. Toda esta información se va a almacenar en arrays, que son los que luego deberemos de consultar para ver que se cumplen todas las restricciones de los valores introducidos. Cada parámetro va a disponer de 5 arrays donde va a almacenarse toda la información. • Listatext: va a contener el nombre del parámetro. • Listacombo: va a contener la lista de valores permitidos, en el caso de que el parámetro no sea editable y debamos elegir entre unos valores dados. Este campo solo va a tener información si el parámetro no es editable. • Listaedittext: en el caso de que el parámetro sea editable, este es el campo donde vamos a almacenar el valor que se va a introducir por pantalla. • Listarangomin: en el caso de que el parámetro sea editable, este parámetro indicará el rango mínimo que puede tomar el valor introducido. Nos servirá para comprobar esta restricción. • Listarangomax: es el mismo caso que el anterior, pero indicará el rango máximo. Esto nos va a permitir, no poder introducir una cadena de texto en un parámetro que solo admite enteros, o de introducir enteros que sobrepasan el rango permitido por el parámetro. A la hora de modificar un determinado parámetro, deberemos introducir en su campo correspondiente el valor que le queramos asignar, o elegir de la lista de sus posibles valores. Con esto lo que haremos será modificar en el array, el valor correspondiente al parámetro que queramos modificar, siempre consultando que cumple todas las restricciones exigidas, y que más tarde escribiremos en el nuevo archivo XML. Hay algunos casos especiales en el que determinados ficheros tienen campos extras, con información adicional, no especificados desde un principio y que pueden cambiar. Esto lo hemos abordado mediante el campo editable de la plantilla, donde le hemos asignado el valor extra. Con esto lo que conseguimos es identificar este tipo de parámetros especiales, que luego tendremos que manejar de diferente manera, para poder introducirlos según la cantidad de extras que el usuario quiera añadir al fichero. A la hora de aplicar los cambios y guardar el fichero, lo que hacemos es primero de todo verificar que los parámetros cumplen las restricciones exigidas. Para ello consultamos los arrays que contienen la información de los rangos y los tipos permitidos por el valor. Si todo esto se cumple, pasamos a guardar el fichero en formato XML, creando una raíz “root”, y creando tantas hojas en el árbol como parámetros vayamos a añadir al fichero. La figura 4.6 sería un ejemplo del fichero final, con los parámetros y sus valores modificados: Figura 4.6 4.5 Diccionario de datos El caso del diccionario de datos lo abordamos de forma diferente. Como hemos dicho anteriormente, el robot Nao permite su programación en lenguaje C++ entre otros. Nosotros hemos utilizado este lenguaje de programación para definirnos una clase “dictionary”, donde vamos a gestionar el diccionario de datos. El procedimiento va a ser similar al anterior, ya que tenemos que leer un archivo XML e introducir sus valores en el diccionario de datos. Para ellos vamos a hacer uso de un parser para C++. El parser que hemos utilizado es TinyXML, ya que es un pequeño parser, muy simple programado en C++, además de ser libre y open source. Aunque es un parser simple, tiene todas las funcionalidades que vamos a necesitar en nuestro proyecto. Es capaz leer y escribir archivos XML y de parsear un archivo XML en un árbol DOM, de manera que la lectura va a ser simple Figura 4.7 Capitulo 5 DISEÑO Y DESARROLLO DE LA INTERFAZ GRÁFICA DE USUARIO En este capítulo vamos a tratar los distintos elementos que hemos utilizado para elaborar nuestra interfaz gráfica de la aplicación y como interactúa con el usuario. Primero de todo cabe destacar que la aplicación está implementada en lenguaje de programación JAVA, con la herramienta de desarrollo Netbeans IDE 7.0. JAVA es un lenguaje de programación orientado a objetos, desarrollado por Sun Microsytems a principios de los años 90. Sus principales características son que usa la metodología de la programación orientada a objetos, permite la ejecución de un mismo programa en múltiples sistemas operativos, incluye por defecto soporte para trabajo en red, está diseñado para ejecutar código en sistemas remotos de forma segura, y es fácil de usar y toma lo mejor de otros lenguajes orientados a objetos como puede ser C++. El entorno de desarrollo que hemos elegido para trabajar con JAVA es Netbeans IDE 7.0, ya que está hecho principalmente para JAVA. Existe un número importante de módulos para extender Netbeans y además es un producto libre y gratuito sin restricciones de uso. La interfaz gráfica de usuario es la forma mediante la cual se le presenta la información al usuario. Nuestra aplicación se va a basar en una interfaz gráfica de ventanas, que van a contener toda la información y van a permitir la entrada de datos para los procesos que queramos ejecutar. Vamos a disponer de una ventana principal, donde vamos a poder encontrar los diferentes procesos que podemos ejecutar, y a partir de la ventana principal vamos a poder ejecutar procesos en diferentes subventanas. Dentro de una ventana podemos disponer de distintos objetos que nos van a proporcionar información o la capacidad de ejecutar determinadas acciones. Figura 5.1 Podemos disponer de objetos informadores, como pueden ser cuadros de texto o mensajes de información, que informan al usuario de cuál es el estado de la aplicación en un momento determinado o de si la información está siendo tratada adecuadamente. También disponemos de mensajes de errores, que nos informan de que debido a algún error no se puede continuar con la acción que queríamos realizar y que deberemos volver a intentarlo. También disponemos de objetos accionadores, como pueden ser los botones, que se encargan de iniciar ciertas acciones que el usuario quiere realizar. Este es el caso de determinadas acciones que queremos llevar a cabo, como puede ser el de conectar por SSH a una maquina remota, en el que deberemos presionar un accionador determinador y esperar una respuesta. Figura 5.2 Como hemos dicho vamos a disponer de una ventana principal que se va a ejecutar al iniciar nuestra aplicación. En ella vamos a disponer de tres regiones, que se van a encargar de distintas acciones. Figura 6.1.3 Si pulsamos sobre el botón “XML Editor” nos aparecerá la siguiente ventana de la Figura 6.1.3. En esta ventana tenemos dos funcionalidades, la primera es la de traducir un archivo .INI en archivo XML. Para ello elegiremos en nuestro PC local, el archivo .INI que queremos traducir, para ello tendremos la ayuda de una ventana que nos guiará por nuestro gestor de archivos para elegir el adecuado. Una vez elegido el origen, debemos elegir donde queremos ubicar nuestro archivo XML final. Para ello volvemos a disponer de una ventana que nos ayudará a elegir la carpeta donde queremos guardar nuestro archivo XML. Es importante guardar nuestro archivo con extensión .xml, para no dejar el archivo sin formato. Una vez elegido el origen y destino de nuestros ficheros, simplemente deberemos pulsar el botón “Convertir .INI a XML”. Si alguno de los ficheros no tiene el formato correspondiente, nos saldrá una advertencia avisándonos sobre ello, y si todo sale correctamente no saldrá una ventana confirmando la acción y la carpeta donde se aloja el fichero destino. Figura 6.1.4 En la Figura 6.1.4 podemos ver como cargamos un el fichero “CTRL.INI” de la carpeta “C:\tmp\” y alojamos el fichero XML en la misma carpeta con el nombre “control.xml”. Como todo ha ido correctamente nos sale el mensaje de confirmación. Pasamos a la segunda funcionalidad que disponemos en la Figura 6.1.2, que es la de editar un fichero XML para poder darle los valores que nosotros deseemos a las variables del fichero. En este caso, como podemos ver en la Figura 6.1.2 disponemos de un desplegable donde podremos elegir el tipo de fichero que queremos editar. En este caso vamos a editar un fichero “CTRL.xml”. Elegimos “CTRL” en el despegable y pulsamos el botón “Cargar plantilla XML”. Nos aparecerá un mensaje de confirmación diciendo que hemos encontrado la plantilla y se ha podido cargar correctamente. Con esto conseguimos que se nos muestre una nueva pantalla en la que ya le podremos dar valores a las variables que contiene el fichero “CTRL.xml”, como la que podemos en la Figura 6.1.5. Figura 6.1.5 En ella podemos observar las variables editables en el fichero “CTRL.xml”, y en estos momentos ya podremos modificar todas las variables que nosotros necesitemos. Como podemos ver existen desplegables en algunas variables, ya que sus posibles valores están limitados y por tanto debemos elegir de la lista que se nos ofrece. Para los valores que están más abiertos, disponemos de unos cuadros de texto donde deberemos introducir el valor deseado, este valor luego se comprobará que esté dentro de los rangos permitidos para según cada variable. Cabe destacar que si una variable queremos no darle un valor determinado, deberemos elegir el valor “null”, para que luego al leer el robot el fichero final, sepa que esta variable no va a contener ningún valor, y por tanto evitar comportamientos no deseados. Disponemos del botón “Cargar fichero XML” situado en la parte inferior izquierda, que nos va a servir para cargar los valores de las variables desde un fichero XML que ya tengamos en nuestro PC local. Si pulsamos este botón dispondremos de una ventana donde podremos elegir un fichero XML dentro de nuestro gestor de archivos y que al cargar dicho fichero, todas las variables se van a cargar con los valores que contenga el fichero XML. Esto nos puede ser útil si queremos modificar un fichero que ya tenemos creado, y que simplemente queremos cambiar un valor determinado, sin tener que modificar el resto. Como podemos ver existe un botón de “Actualizar EXTRAS”, esto ocurre porque en determinados ficheros como puede ser el “CTRL” existe una variable que puede contener variables EXTRAS, según el valor que tome la variable “HFSM_EXTRA_NUMBER”. Es por ello que hemos añadido esta funcionalidad. Si queremos añadir EXTRAS a nuestro fichero deberemos indicar el número en el cuadro de texto de la variable anterior, y pulsar en “Actualizar EXTRAS”, de esta forma nos aparecerán tantos EXTRAS como hayamos indicado, y podremos de esta forma darle valor a estas nuevas variables. Por último disponemos del botón “Aplicar cambios”, este botón nos sirve para guardar los cambios que hemos hecho en las variables mediante el editor, y guardarlo en un fichero XML nuevo. Para ello, si pulsamos en el botón de aplicar cambios nos aparecerá una ventana para examinar nuestro gestor de archivos y guardar en nuestro PC local el nuevo fichero XML en la carpeta que nosotros elijamos. Cabe destacar que deberemos darle extensión .xml al archivo para poder guardarlo correctamente, sino hacemos esto nos aparecerá un mensaje avisándonos que el fichero que queremos guardar no es XML. En la Figura 6.1.6 podemos ver un ejemplo de un fichero que hemos modificado, le hemos añadido 7 variables EXTRAS y hemos modificado los valores de algunas variables, y que nos disponemos a guardar los resultados en la carpeta ficheros con el nombre “ejemplo.xml”. Figura 6.1.6 Como hemos dicho en la parte central de nuestra aplicación existen 2 botones, “SCP From” y “SCP To”. Estos son los encargados de transferir archivos entre el PC local y el PC remoto al que queremos conectarnos, en nuestro caso un robot. Si pulsamos sobre el botón “SCP From” se nos abrirá una ventana como la de la Figura 6.1.7. Figura 6.1.7 En ella podemos observar los campos que deberemos rellenar para en este caso, traer un fichero del equipo remoto a nuestro PC local. Para ellos deberemos indicar el host al que queremos conectarnos y el usuario con el que nos queremos autenticar. Luego deberemos indicar el fichero origen de la maquina remota que queremos traer a nuestro PC, para ello deberemos indicar la ruta completa de donde se encuentra el fichero origen. Para guardar el archivo en nuestro PC local le deberemos indicar un directorio donde guardarlo, para ello nos vamos a ayudar de la ventana elegir destino, donde vamos a examinar y elegir el directorio mediante una ventana de gestor de directorios. Nos será mucho más fácil de esta forma elegir el lugar donde queremos guardar el fichero origen. Cuando tengamos todo ello, simplemente debemos pulsar el botón “SCP From”, que nos pedirá la contraseña correspondiente al usuario para autenticarnos y de esta manera poder realizar la transferencia del archivo. Si existiera cualquier error con la contraseña o con la transmisión del fichero, nos indicará un mensaje de error, mientras que recibiremos un mensaje si todo ha ido correctamente. La otra opción “SCP To” es análoga a la que acabamos de explicar, simplemente deberemos de elegir en nuestro PC local el archivo origen que queremos enviar, e indicar la ruta del equipo remoto donde queremos guardar el archivo. Por último vamos a disponer de la última región de nuestra aplicación en la que solo se muestra un botón, “Editar Fichero XML Remoto”. Este botón se encarga de editar un fichero que está alojado en el equipo remoto, y volver a enviar el que hemos modificado de nuevo. Es una función que aglutina todas las funcionalidades anteriores, pudiendo hacerlo todo de un solo paso. La ventana que nos aparece es la que vemos en la Figura 6.1.8. Figura 6.1.8 Podemos ver que existen los campos host y user, donde deberemos introducir el host al que queremos conectarnos y el usuario con el que queremos autenticarnos. Ahora debemos elegir la carpeta donde se aloja el fichero que queremos modificar, para ello disponemos de un desplegable con las rutas donde suelen estar alojados los ficheros de configuración, si bien también es editable por si queremos elegir una ruta diferente. En fichero origen debemos elegir, de la lista dada, que son los archivos de configuración que se suelen modificar, cuál es el fichero que queremos modificar. Una vez hecho todo esto, pulsaremos el botón “Editar XML”, y tras autenticarnos con nuestra contraseña de usuario, pasaremos a la ventana de edición y modificación de los ficheros XML, como la de la Figura 6.1.5. Hacemos las modificaciones pertinentes, y guardamos nuestro archivo modificado. En este caso se nos guardará en la carpeta donde están todos los archivos de la aplicación. En este punto es donde volveremos a la pantalla de la Figura 6.1.8, y tendremos la opción de enviar archivo. Ahora podremos enviar el archivo modificado de nuevo al robot, o una de las funcionalidades de la aplicación es que podremos modificar el host, de forma que este archivo que hemos modificado, lo podremos mandar no solo al robot origen, sino también a otros robots que queremos que tengan el mismo comportamiento. 6.2 Manual de desarrollador En este apartado vamos a describir cual es la estructura que siguen los ficheros dentro del proyecto, y las funciones que hemos utilizado para programar la aplicación. El objetivo de este apartado es ayudar a que cualquier usuario programador sea capaz de modificar la aplicación. En la Figura 6.2.1 podemos observar la estructura de nuestro proyecto con los diferentes ficheros JAVA que lo componen. Podemos ver diferenciados los archivos JAVA que forman parte del proyecto, y en la parte inferior las librerías que hemos incluido para poder desarrollar ciertas funciones. Figura 6.2.1 Como podemos ver se incluye una clase “Main” que va a ser el código que se va a ejecutar al iniciar la aplicación. A partir de este podemos ver el resto de clases que van a depender unas de otras dependiendo de las llamadas que se vayan ejecutando. Vamos a ir describiendo una por una todas las clases de las que forma parte el proyecto y explicando cual es el funcionamiento y objetivo de cada una. La clase “Control Panel” es la que da forma a la ventana principal de nuestro proyecto. En esta clase principalmente mostramos por pantalla los botones y cuadros de texto necesarios para ejecutar el resto de funcionalidades. En la Figura 6.2.2 podemos observar las funciones que forman parte de la clase “Control Panel”. Todas ellas como hemos comentado son funciones que llevan asociadas una acción tras pulsar el botón correspondiente. Además de eso contiene la función “initComponents” que es donde por defecto se van a inicializar todas las variables. Figura 6.2.2 La siguiente clase que vamos a describir es “ConexionSSH”, esta clase se encarga de realizar la conexión con el equipo remoto y de ejecutar los comandos. Como podemos ver en la Figura 6.2.3 solamente tiene tres funciones muy simples. En este caso no disponemos de botones ni ventana que mostrar por lo que las funciones aquí detalladas serán llamadas desde el la ventana principal, pulsando los botones correspondientes. Figura 6.2.3 La clase “XMLconvert”, que podemos ver en la Figura 6.2.4, es la encargada de traducir los ficheros .INI en ficheros XML, y de cargar una plantilla XML para poder editar y modificar sus campos. Tenemos dos funciones donde vamos a seleccionar tanto el fichero origen .INI que queremos traducir como el destino donde queremos ubicar el fichero XML. Luego tenemos la función “convert” que es la que va a ejecutar la función para traducir el fichero .INI. Ya por otra parte tenemos la función de “cargar plantilla” y la de “editar XML” donde pasaremos a la nueva ventana donde vamos a poder modificar los valores de los atributos. Por último disponemos de la función “initComponents” donde por defecto se van a inicializar todas las variables.