Descargar

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