Proyecto Fin de Carrera Implementación del FKE para SLAM 4. Microsoft Robotics Studio 4.1. Introducción Microsoft Robotics Studio (MSRS) es un entorno de programación de simulación e implementación para robots de Microsoft. Adaptado para el nivel académico, aficionados y nivel profesional. Es compatible con una gran variedad de hardware desde robots conectados directamente al ordenador a través del puerto serie, bluetooth, USB, etc., hasta los robots que tienen un PC abordo. Es posible también, trabajar con robots simulados ya que proporciona las herramientas necesarias para crear el entorno de simulación. Además el programa ha sido diseñado para apoyar cualquier tipo de aplicación relacionada con la robótica, desde el tratamiento básico de las entradas de los sensores a drive-by-wire, y la presencia remota, hasta operaciones autónomas, cooperación entre múltiples robots y demás. Los lenguajes utilizados son C#, Phyton Visual Basic, VPL (Visual Programming Lenguaje) todos ellos utilizando .NET Framework. MSRS Runtime es un entorno que ha sido diseñado para proporcionar un espacio para desarrollar las aplicaciones con un amplio conjunto de requisitos entre ellos. • Debe ser posible controlar el estado e interactuar con cada uno de los componentes mientras se ejecuta la aplicación. • Debe ser posible encontrar, crear, terminar, y reiniciar componentes mientras la aplicación se está ejecutando. • Debe ser posible tratar las entradas de diferentes sensores simultáneamente y orquestarlas sin que existan interferencias entre diferentes tareas. • Debe ser posible trabajar con un manejador autónomo, así como el control de las aplicaciones robóticas tanto localmente como a través de la red • El tiempo de ejecución debe ser lo suficientemente ligero para que pueda ser ejecutado en una gran variedad de entornos. • El entorno de aplicación debe ser extensible y lo suficientemente flexible como para dar cabida a la interacción con una amplia variedad de hardware y entorno software. 59 Proyecto Fin de Carrera Implementación del FKE para SLAM 4.2. Microsoft Robotics Studio Runtime MSRS Runtime consta de dos componentes principales que facilitan la construcción, vigilancia, despliegue, y el funcionamiento de un amplio conjunto de aplicaciones con estos requisitos. 4.2.1. Concurrency and coordination runtime CCR Permite la coordinación concurrente y asíncrona del flujo de ejecución abstrayendo al programador del uso de hilos, semáforos, y otras técnicas de más bajo nivel para asegurar la exclusión mutua o la prevención del interbloqueo. Además plantea un modelo de programación asíncrona que facilita y optimiza la explotación de un entorno de ejecución paralelo o multihilo. El CCR es un componente DLL que se ejecuta en un entorno .NET y accesible desde cualquiera de los lenguajes de programación disponibles en .NET. 4.2.2. Decentralized and software services DSS El DSS combina la arquitectura tradicional web (HTTP) con elementos de las nuevas arquitecturas orientadas a servicios web (SOAP). El resultado es una arquitectura basada en servicios que se coordinan entre sí para crear aplicaciones distribuidas. Por lo tanto, desde este punto de vista una aplicación desarrollada en Robotics Studio es un conjunto de servicios que se coordinan entre sí. El principal objetivo es promover simplicidad, transparencia y la interoperabilidad. Las composiciones de servicios se pueden usar sin importar si estos servicios están funcionando dentro de un mismo nodo o a través de la red. El resultado es una plataforma flexible capaz de soportar un amplio rango de aplicaciones. El DSS utiliza los protocolos HTTP y DSSP. Este último, es un protocolo que ofrece DSS y se encarga de la mensajería entre servicios. Los servicios mantienen un estado durante el período de vida de la aplicación y se ejecutan en nodos DSS, que son los encargados de posibilitar la comunicación entre todos los servicios. 60 Proyecto Fin de Carrera Implementación del FKE para SLAM 4.3. Modelo de aplicación REST 4.3.1. Introducción La tarea principal de una aplicación robótica es tratar todas las señales recogidas a través de los diferentes sensores y apartir de esta información dar las señales necesarias a los actuadores de forma que se consiga el objetivo de la aplicación. A continuación se muestra un ejemplo sencillo del flujo de la información en un caso con un solo sensor y un único actuador. Figura 11 Un caso más complicado puede ser Figura 12 En este último caso cada sensor y actuador son similares al del ejemplo anterior, sin embargo en este caso el sistema que orquesta el flujo de la información tiene que manejar más componentes. Además de la complejidad añadida de orquestar un número mayor de los componentes hay más factores que distinguen estas aplicaciones • Tratar las entradas de los sensores y el control de los actuadores desde realizarse concurrentemente ya que sino podría producirse que a los actuadores no les llegase información y que los sensores fuesen ignorados. • La orquestación y la composición son una parte crucial de la aplicación sobretodo en el número de sensores y actuadores crece y la orquestación se vuelve más compleja. • La orquestación autónoma y colaborativa requiere que los componentes puedan ser distribuidos y accesibles en toda la red. Con el fin de satisfacer estas necesidades MSRS Runtime proporciona una alta concurrencia, el modelo de la aplicación orientada a servicio combina aspectos de la arquitectura tradicional basada en web con parte de la arquitectura basada en servicios web que proporcionan una flexibilidad a un ligero modelo de aplicación distribuida naturalmente. Esta manera de ver una 61 Proyecto Fin de Carrera Implementación del FKE para SLAM aplicación no es única para la robótica y los sensores y los actuadores no están limitados a los componentes tradicionales de la robótica como motores y sensores de contacto. 4.3.2. Arquitectura web y arquitectura orientada a servicios web 4.3.2.1 Introducción El objetivo principal de la arquitectura web es la simplicidad, la interoperabilidad, y la perdida de acoplamiento, HTTP promueve este modelo permitiendo aprovechar la ventaja de un simple modelo de aplicación orientado a estado, conocido comúnmente como REST. Las aplicaciones basadas en web a través de HTTP han demostrado que este modelo proporciona interoperabilidad, y es lo suficientemente flexible para albergar una gran variedad de escenarios. A pesar del éxito de HTTP son bien conocidos los aspectos que no trata. En particular: • No proporciona herramientas para la manipulación de información estructurada. Es decir, las únicas operaciones permitidas son a nivel del recurso no en la subestructura del mismo. Esto dificulta la actualización de un servicio limitando la forma en la que los servicios pueden interactuar. • No permite la notificación de eventos. HTTP es un protocolo de petición/respuesta que no proporciona medios para que las notificaciones de un modelo lleguen a sus subscriptores. Mientras que los mecanismos con RSS son muy útiles, proporcionan poco apoyo al filtrado para estructuras. • No tienen medio para expresar el tipo de relación entre componentes. Es decir, no hay forma de expresar que un orquestador particular está asociado con un sensor y actuador específico. MSRS Runtime proporciona un modelo de aplicación basado en REST, pero mejorado con parte de los servicios web para poder manejar la información estructurada, la notificación de eventos y la asociación entre servicios. Ampliando el modelo REST de esta forma, las aplicaciones tienen la ventaja de contar con un modelo de notificación de eventos y manipulación de datos sin perder la interoperabilidad con la infraestructura existente REST. El resultado es mucho más interactivo y permita construir aplicaciones dinámicas como composición de servicios organizados dentro de los nodos y a través de la red. 62 Proyecto Fin de Carrera Implementación del FKE para SLAM 4.3.2.2 Manipulación de información estructurada en el modelo REST HTTP se definió antes de que XML fuera conocido y no tiene forma evidente de tratar los recursos como entidades estructuradas. Como resultado HTTP sólo prevé los métodos que operan en nivel de recursos como las órdenes GET y PUT que intercambian el estado completo de un recurso. Aunque se puede pensar que la notación URI proporciona una visión parcial del recurso, esta es una vista desestructurada y sólo refleja una lectura del estado, no permite cambiarlo. Sin embargo, los servicios web están inherentemente representados como XML que a menudo se describen en una variedad de tipos de sistemas incluyendo XSD, C#, y Java. Pensando en el recurso como una entidad estructurada puede ser posible definir operaciones comunes para trabajar sobre parte de los servicios. MSRS Runtime adapta la noción de que un recurso puede ser una identidad estructurada y define un conjunto de operaciones que permiten al estado del servicio ser incrementado, eliminado, actualizado y requerido sin necesidad de un modelo de datos común para todos los servicios. Manipular el estado de esta forma no es nuevo, pero combinar la estructura de los servicios web con REST proporciona una forma más flexible de interactuar con los servicios. 4.3.2.3 Notificación de eventos en el modelo REST La notificación de eventos es la segunda parte que adopta MSRS de la arquitectura de servicios web. Modelando un evento con un cambio en el estado del servicio, es fácil introducir los eventos en el modelo REST. Por ejemplo, en el caso de una operación de actualización UPDATE en un servicio, el estado del servicio cambia como resultado directo de la operación UPDATE. Por otra parte, la operación UPDATE en sí misma representa directamente el cambio de estado así que es lógico pensar que la notificación se produce con la operación UPDATE. Expresando las notificaciones de eventos como cambios en el estado de un servicio, los subscriptores tienen una forma común de vigilancia de los editores independientes de la semántica de un determinado servicio y los editores tienen una forma común de representar las notificaciones de los eventos transmitiendo todos los cambios del estado a los subscriptores. 63 Proyecto Fin de Carrera Implementación del FKE para SLAM 4.4. Modelo del Servicio 4.4.1. Introducción En MSRS Runtime una aplicación es una composición de servicios donde cada uno de ellos es un servicio de estilo REST con capacidad para tratar notificación de eventos e información estructurada. Debido a la relación con HTTP, el estado de cada servicio puede ser seguido y manipulado directamente a través de un navegador web usando HTTP, o mediante un protocolo basado en SOAP llamado DSSP (Decentralized Software Services Protocol): • HTTP permite respaldar operaciones como GET, PUT y POST, y DELETE. Esto permite que el servicio pueda ser utilizado dentro de un amplio contexto UI, como un navegador web utilizando la infraestructura existente y los formatos de información existente. • DSSP permite respaldar la manipulación de la información estructurada de los estados de los servicios con órdenes como UPDATE, INSERT y QUERY. Además DSSP proporciona un modelo de notificación de eventos que está ligado a los cambios en los estados del servicio. Los servicios son los bloques básicos de construcción para escribir aplicaciones utilizando Microsoft Robotics Studio y son un componente principal del modelo de aplicación DSS. Los servicios son ejecutados en el contexto de un nodo DSS. Un nodo DSS es un ambiente de ejecución que proporciona soporte para que los servicios sean creados y manejados hasta que se borren o el nodo DSS se detenga. Los servicios están de forma inherente permitidos en la red y pueden comunicarse entre ellos de manera uniforme, independientemente de si se ejecutan dentro de un mismo nodo DSS o a través de la red. El modelo DSS de servicio ha sido diseñado para facilitar la reutilización de los servicios convirtiéndolos en fácilmente utilizables y trabajar con otros mientras se produce un acoplamiento libre entre ellos. Todos los servicios DSS consisten en una serie de partes comunes que se describen a continuación. 4.4.2. Service Identifier – Identificador de servicio Cuando se crea un servicio en un nodo DSS, el Servicio Constructor le asigna una dirección URI. Este identificador del servicio se refiere sólo a un caso particular del identificador del servicio funcionando en un nodo particular de DSS. El identificador del servicio es el que permite a otros servicios comunicarse con ese servicio, así como para acceder a él a través de un navegador Web. El identificador del servicio sólo proporciona identificación de un caso 64 Proyecto Fin de Carrera Implementación del FKE para SLAM concreto del servicio; no transmite la información sobre el estado del servicio, el comportamiento, o el contexto. Es decir, nunca es fiable hacer conjeturas sobre un servicio basándose en el identificador del servicio. 4.4.3. Contract Identifier – Identificador de contrato Un contrato es una descripción condensada de la implementación de un servicio que describe su comportamiento, así otros servicios pueden integrar y reutilizar servicios a través únicamente de sus contratos correspondientes. El contrato de un servicio se puede inspeccionar usando la herramienta de DSS Contract Information (DssInfo.exe). Los contratos son usados para generar DSS Proxy DLLs que es lo que los servicios unen cuando se comunican con otros servicios en vez de vincularlos directamente unos a otros. Un identificador de contrato es una dirección URI que identifica inequívocamente el contrato de un servicio. Un identificador de contrato se crea automáticamente cuando se crea el proyecto del servicio, por ejemplo usando la herramienta de DSS New Service Generation Tool (DssNewService.exe). 4.4.4. Service State – Estado del servicio El estado del servicio es una representación de un servicio en cualquier instante de tiempo. Una forma de pensar en el estado del servicio es como en un documento que describe en contenido actual de un servicio. Ejemplos: • El estado de un servicio representando un motor puede consistir en las rotaciones por minuto, la temperatura, la presión del aceite, el consumo de combustible. • Un servicio representando una cola de trabajo puede contener una lista de todos los tipos de trabajos almacenados en la cola y sus estados actuales. Los tipos de trabajo pueden ser servicios que permiten a la cola de trabajo referirse a ellos utilizando simplemente su identidad. • Un servicio representando un teclado puede contener información sobre las teclas que han sido pulsadas. Cualquier información que pueda ser recuperada, modificada o monitorizada como parte de un servicio DSS puede ser expresada como parte del estado de un servicio. Además para guardar una parte del un servicio, el estado también se puede utilizar para dirigir la interfaz de usuario de un servicio. 65 Proyecto Fin de Carrera Implementación del FKE para SLAM 4.4.5. Service Partners – Servicios asociados Una parte crítica del modelo de aplicación de DSS es permitir una composición de los servicios para proporcionar mayores niveles de funcionalidad. Esto significa que para que los servicios puedan utilizar eficientemente otros servicios, deben permitir y establecer un medio de comunicación con los demás de forma eficaz y predecible. Sin embargo, como los servicios están vagamente unidos, un servicio no sabe a priori si los otros servicios de los que depende están disponibles o incluso donde se encuentran. Para abordar esta cuestión, el modelo de aplicación DSS proporciona la noción de servicios asociados. Los servicios asociados son otros servicios que interactúan con un servicio y que posiblemente influyen en este último para que funcione correctamente. Al declarar un conjunto de servicios como asociados, un servicio puede indicar al tiempo de ejecución que quiere estar conectado a estos servicios como parte del proceso de creación del servicio en sí. Un servicio asociado es declarado usando el atributo Partner que posee una gran variedad de opciones para controlar exactamente que tipo de asociación tiene con el resto de socios declarados. Por ejemplo, un servicio puede declarar que se necesita un servicio asociado para funcionar y si ese socio no puede encontrarse entonces no hay necesidad para el servicio de iniciar a los demás. Los servicios asociados también se pueden declarar como opcionales en cuyo caso el tiempo de ejecución está pendiente de unir el servicio con los socios pero si no hay éxito entonces el proceso de creación continúa independientemente. 4.4.6. Main Port – Puerto principal El puerto principal es un puerto CCR donde llegan los mensajes de otros servicios. Debido a que las implementaciones de los servicios no están vinculadas directamente a otras, un servicio puede sólo comunicarse con otro enviando mensajes a su puerto principal. El puerto principal es un miembro privado de la clase del servicio que esta identificado por el atributo ServicePort. Un ejemplo de la declaración del puerto principal es: [ServicePort("/mysample")] private MySampleOperations _mainPort = new MySampleOperations(); Los mensajes aceptados en el puerto principal se definen por el tipo de puerto, en el caso anterior por el tipo MySampleOperations. Todas las operaciones definidas en el puerto principal deben seguir el mensaje de operaciones definidas por DSSP o HTTP. A continuación se muestra un ejemplo de la definición de un puerto principal que soporta las operaciones de DSS como LOOKUP, DROP, GET, y REPLACE, así como las operaciones de HTTP como GET y POST. 66 Proyecto Fin de Carrera Implementación del FKE para SLAM public class MySampleOperations : PortSet<DsspDefaultLookup, DsspDefaultDrop, Get, Replace, HttpGet, HttpPost> {} 4.4.7. Service Handlers – Manejadores de servicio Para cada una de las operaciones DSSP definidas en el puerto principal, se necesita registrar un manejador para controlar los mensajes entrantes que están llegando al puerto. La única excepción es el manejo de las operaciones DsspDefaultLookup y DsspDefaultDrop para las que la rutina DSS registra manejadores por defecto. Por ejemplo, en el caso de la definición anterior de MySampleOperations, el servicio MySample deberá registrar manejadores para Get, Replace, HttpGet, y HttpPost. Los manejadores pueden ser registrados usando el atributo ServiceHandler. El siguiente ejemplo muestra la declaración se un manejador de servicio para la operación GET de DSSP: [ServiceHandler] public IEnumerator GetHandler(Get get) { get.ResponsePort.Post(_state); yield break; } En el contexto del manejador de un servicio, un servicio puede enviar mensajes a otros servicios de dos formas diferentes: • No solicitadas en el formulario del mensaje de petición enviado a otro servicio. • Solicitadas en el formulario de notificación de un evento enviado a un subscriptor como consecuencia de un cambio del estado del servicio dentro de la generación de notificación de eventos del servicio. En cualquier caso, los mensajes son enviados a través de un servicio de transporte que es una representación local del puerto principal CCR del servicio remoto. Cuando un mensaje es enviado a través del servicio de transporte, éste se transmitirá a través de los tiempos de ejecución hasta alcanzar un transporte que direccione el mensaje, posiblemente a través de la red, para el transporte de los demás servicios. Aquí el mensaje transmitido será transportado a través del tiempo de ejecución hasta que alcance el puerto principal del servicio receptor. 4.4.8. Event Notifications – Notificación de eventos Un patrón común utilizado en los servicios DSS es la suscripción a otros servicios. Un servicio genera notificación de eventos como resultado de un cambio en su propio estado. Para cada suscripción que un servicio tenga establecida con otros servicios, el servicio recibirá notificaciones de eventos en diferentes puertos CCR. Mediante el uso de diferentes puertos para cada suscripción, es posible diferenciar notificaciones y determinar que suscripción está asociada a cada notificación. Por otra parte, debido a que la notificación de eventos llega a los 67 Proyecto Fin de Carrera Implementación del FKE para SLAM puertos, es posible organizar los mensajes de notificación de eventos utilizando el espectro completo de primitivas de CCR. Dado que las notificaciones de eventos se generan como resultado de cambios en el estado de un servicio, y el cambio en el estado ocurre como resultado de las operaciones de DSSP como DELETE, INSERT, UPDATE, etc., los mensajes de notificación de eventos actuales son exactamente un conjunto de operaciones en el puerto principal que afectan al cambio de estado. Como resultado, un puerto de notificación local donde llegan las notificaciones de eventos es del mismo tipo que el puerto principal del servicio asociado con esa suscripción particular. Por ejemplo, si introducimos un servicio llamado MySample2 y MySample se suscribe a ese servicio. El tipo del puerto de notificación local en el servicio MySample donde llegan las notificaciones como resultado del cambio de estado del servicio MySample2 es el mismo que el del puerto principal de MySample2. 68