CAPÍTULO 4:

MICROSOFT ROBOTICS
STUDIO
4.1 - INTRODUCCIÓN AL MODELO DE APLICACIÓN

Microsoft Robotics Studio está basado en un entorno de Windows y su uso está dirigido a
la creación de aplicaciones de robótica de forma sencilla y para una gran variedad de
plataformas de hardware de ámbito académico, de aficionados y para su desarrollo
comercial. La ejecución de Microsoft Robotics Studio desarrolla un entorno que ha sido
diseñado para complacer las necesidades de un amplio rango de aplicaciones de
robótica:

1. Debe ser posible monitorear el estado e interactuar con componentes

individuales mientras la aplicación está siendo ejecutada.

2. Debe ser posible descubrir, crear, poner fin, y reiniciar componentes mientras la
aplicación está siendo ejecutada.

3. Debe ser posible trabajar con las entradas de múltiples sensores

simultáneamente y organizar tales entradas como tareas, sin riesgo de
interferencias no intencionadas entre tareas.

4. Debe ser posible manejar aplicaciones automatizadas autónomas así como

controladas, ambas a nivel local y lo largo de la red de trabajo.

5. La ejecución debe ser ejecutada de una forma suficientemente “ligera” en una

gran variedad de entornos.

6. El entorno de aplicación debe ser suficientemente extensible y flexible para

complacer la interacción con una gran variedad de hardware y software.

Para cubrir estos requisitos, la ejecución de Microsoft Robotics Studio provee una
arquitectura de servicio orientada que combina los aspectos clave de la arquitectura
tradicional basada en Web con servicios en red para proporcionar un modelo de
aplicación flexible, ligero y muy distribuido.

El enfoque principal de la arquitectura Web está en la sencillez, la interoperabilidad, y

la conexión ininterrumpida. Las aplicaciones basadas en Web demuestran a través del
HTTP (HyperText Transfer Protocol) que este modelo se ajusta bien, suministra la
interoperabilidad, y es suficientemente flexible para complacer una gran variedad de
situaciones.

A pesar del éxito del HTTP, sin embargo, hay aspectos bien conocidos que no capta de
forma eficaz. En particular, las dos limitaciones con las que las aplicaciones Web se
encuentran repetidamente son:
 1. Ausencia de soporte para la manipulación de los datos estructurados. Es decir las
únicas operaciones permitidas en un recurso están en el "nivel del recurso", no
en la subestructura de un recurso. Esto hace difícil actualizar el estado de un
servicio, lo que limita cómo pueden interactuar los servicios.

2. No hay ningún soporte para la notificación de eventos. El HTTP es un protocolo

de solicitud/respuesta y no permiten modelos de notificación de eventos basados
en transmisión de datos. Mientras mecanismos como el RSS son muy útiles,
todavía son básicamente orientados a la extracción de datos y suministran poco
soporte para filtros estructurados.

Un aspecto clave del HTTP es que permite que las aplicaciones saquen provecho de un
modelo de aplicación simple y orientada a estado, comúnmente conocido como REST.
La ejecución de Microsoft Robotics Studio está basada en el modelo de REST pero lo
aumenta con fragmentos de servicios Web para permitir la manipulación de datos
estructurada y la notificación de eventos.

Extendiendo el modelo de REST de esta manera, las aplicaciones pueden aprovechar un

modelo de notificación de eventos y la manipulación estructurada de los datos sin
perder la interoperabilidad con la infraestructura de REST existente. El resultado son
aplicaciones mucho más interactivas y dinámicas construidas como composiciones de
servicios que se organizaron a lo largo de la red.

4.1.1 - Web y REST

El término "REST" fue creado por Roy Fielding. Abstrae, y a la vez, formaliza la
arquitectura de Web. El REST se basa en la noción presentada por Tim Berners-Lee
según la cual un URI (Uniform Resource Identifier, identificador uniforme de recurso)
hace referencia a un recurso y todas las interacciones con ese recurso ocurren mediante
el intercambio de estados. Se puede establecer un símil en el que un recurso sería como
una persona y una fotografía de esa persona como una representación especial. Las
representaciones pueden cambiar con el tiempo y ser expresadas en gran variedad de
formatos de datos. Por ejemplo, una representación de una persona puede ser dada como
una fotografía, una descripción de texturas, un vídeo, etcétera. La única manera de
interactuar con recursos es a través del intercambio de las representaciones de estado.
La separación de estado y comportamiento de un recurso es un componente
fundamental para conseguir conexión ininterrumpida entre componentes que se
comunican entre sí.
Mientras muchas personas piensan en el REST como únicamente dirigido al HTTP, ésta
no es la verdad. Los principios del REST (y la arquitectura de Web en general) pueden
ser implementados en gran número de maneras pero hoy por hoy, el HTTP es el único
protocolo que permite que uno piense en términos de REST eficazmente: respalda a los
URIs y suministra un lenguaje compartido para interactuar con los recursos.

4.1.2 - SOAP y REST: manzanas y naranjas

El protocolo de SOAP (Simple Object Access Protocol) está en el núcleo del modelo de
servicios de Web. Mientras el SOAP se puso en marcha como una manera de publicar
por entregas objetos de C# y Java, por la época en que SOAP/1.0 fue publicado, tenía la
estructura de mensaje semi-estructurado y estaba concentrado en la extensibilidad.

Debido a que SOAP es un protocolo, es comparado con el HTTP y el REST a menudo,

pero ése es un error. El objetivo de SOAP es proporcionar un modelo de extensibilidad
distribuido y estructurado, mientras que el propósito del REST es proporcionar un
modelo de aplicación.

El modelo de extensibilidad de SOAP está basado en un conjunto de reglas para

procesar un mensaje de SOAP que permite que un remitente indique lo que un receptor
debe hacer para procesar ese mensaje apropiadamente. El modelo de extensibilidad
proporcionado por SOAP era un conjunto directo de aquello que proveía el HTTP y se
desarrolló a partir de la observación de las muchas maneras en que el HTTP estaba
siendo usado.

La diferencia principal entre el HTTP y SOAP es que SOAP no define un modelo de

aplicación como el HTTP y es ahí donde volvemos a REST. Porque SOAP no se
preocupa por cómo está siendo usado: puede soportar cualquier número de modelos de
aplicación que se extienden desde RPC a aplicaciones con holguras acopladas e incluso
aplicaciones de estilo REST.

El resultado de estas diferencias es que ambos protocolos desempeñan funciones útiles

y complementarias, y aunque SOAP es usado principalmente en el contexto de la
programación de estilo de RPC, actualmente no hay ninguna razón para que SOAP no
pueda ser también usado en un contexto de SOAP.
4.1.3 - Ejecución de Microsoft Robotics Studio
La ejecución del Microsoft Robotics Studio proporciona un entorno, también conocido
como nodo, para crear, ofrecer, dirigir, y conectar servicios dentro de ese nodo y a lo
largo de la red con el propósito de situarlos en las aplicaciones. El resultado es un
modelo de aplicación distribuido donde los nodos son semejantes en vez de clientes y
servidores, y los datos son intercambiados de forma bidireccional a petición, en lugar de
por sondeo.

El soporte de tiempo de ejecución o Runtime de Robotics Studio consta de dos

componentes principales que hacen posible la construcción, supervisión, despliegue y
funcionamiento de un gran rango de aplicaciones. Estos dos componentes son el CCR
(Concurrency and Coordination Runtime) y el DSS (Decentralized Software Services):

1. La concurrencia y coordinación de la ejecución (CCR), que permite la

coordinación de mensajes sin el uso de coordinación manual, bloqueos,
semáforos, etcétera. El CCR está basado en el paso de mensaje asíncrono y
proporciona el contexto a una ejecución para servicios incluyendo un conjunto
de prototipos de alto nivel para sincronizar los mensajes.

El 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 el aseguramiento de 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. Cabe
destacar que el CCR es un componente DLL que se ejecuta en el entorno .NET y
accesible desde cualquiera de los lenguajes de programación disponibles en
.NET.

2. Servicios de sistema descentralizados (DSS), que proporcionan un entorno y un

juego de servicios básicos que facilitan tareas tales como depurar, la
observación, la seguridad, el descubrimiento, y la recuperación de datos.
El DSS combina la arquitectura tradicional Web (HTTP) con elementos de las
nuevas arquitecturas orientadas a servicios Web (SOAP). La arquitectura
resultante está completamente 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 la simplicidad,
transparencia y la interoperabilidad. Las composiciones de servicios se pueden
usar sin importar si estos servicios están funcionando dentro del 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.
DSSP es un protocolo propio que ofrece DSS y se encarga de la mensajería entre
 servicios. Los servicios mantienen un estado durante el periodo 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.

La ejecución del Microsoft Robotics Studio ha sido diseñada ser ligera y flexible, y es
posible usarla en una gran variedad de situaciones aplicables a la robótica.

4.1.4 - La unificación de modelos: una base de aplicación más fuerte

La ejecución de Microsoft Robotics Studio aúna servicios de REST y de Web

asumiendo el modelo de REST y su fundamento pero extendiéndolo con la
representación de datos estructurada y las notificaciones de evento del mundo de
servicios de Web. Para hacer esto, DSS define un modelo de aplicación que incluye la
noción de la notificación de eventos y la manipulación de datos estructurada en un
entorno de REST y lo usa como parte de su modelo de servicio (ver Fig. 1).

Fig.1

Añadiendo la notificación de evento y la manipulación de datos estructurada, es posible

manipular y monitorear los datos de una manera más eficiente que la que permite el
HTTP hoy en día.

4.1.5 - Manipulación de datos estructurada en un entorno REST

El HTTP fue definido antes de la creación de XML y tenía ninguna manera obvia de
crear recursos como entidades estructuradas. Por consiguiente, el HTTP solamente
posee los métodos que funcionan a nivel de recurso como GET y PUT que cambian el
estado entero de un recurso. Mientras se puede argumentar que el URI consulta la
notación (por ejemplo: "http://www.example.com?keyword=value") y proporciona una
vista parcial de un recurso, ésta todavía es una visión poco estructurada y refleja
solamente la lectura del estado; no su cambio.
Por contraste, los servicios de Web son intrínsecamente representados como XML que
son descritos a menudo en una variedad de sistemas incluyendo XSD y C #. Pensar en
un recurso como una entidad estructurada hace posible definir las operaciones comunes
que afectan a partes de un servicio.

La ejecución de Microsoft Robotics Studio asume la noción de que un recurso puede ser
una entidad estructurada y define un conjunto de operaciones que permiten que un
estado de servicio sea añadido, eliminado, actualizado, y consultado sin requerir un
modelo de datos común para todos los servicios. Manipular un estado de esta manera no
es nuevo pero combinando la visión estructurada de servicios Web con REST el
resultado es una manera mucho más flexible para interactuar con los servicios.

4.1.6 - Notificación de eventos en un entorno REST

El segundo fragmento que la ejecución de Microsoft Robotics Studio asume del mundo de
servicios Web es relativo a las notificaciones de evento. Haciendo un modelo de un
evento como un cambio estado en un servicio, se vuelve más sencillo introducir los
eventos en el modelo de REST. Por ejemplo, en el caso de una operación de
actualización sobre un servicio, el estado de ese servicio cambia como un resultado
directo de esa operación de actualización. Además, la operación de actualización misma
representa el cambio de estado directamente y por tanto es natural pensar en la
notificación de evento como sólo la operación de actualización (ver Fig. 2).

Fig.2

4.1.7 - Modelo del servicio de Microsoft Robotics Studio

En la ejecución de Microsoft Robotics Studio, una aplicación es una composición de
servicios donde cada uno es un servicio del estilo de REST con un soporte añadido para
la notificación de eventos y la manipulación de datos estructurada como se ha descrito
anteriormente. Organizando servicios con holgura acoplados y ligeros sobre un anfitrión
solo o a lo largo de la red, pueden crearse aplicaciones de diferente complejidad y de
esta forma hacer aplicaciones aún más complicadas.

Debido a la relación con el HTTP, el estado de cada servicio puede ser monitoreado y
manipulado directamente a través del HTTP usando un explorador web, o a través de un
simple protocolo basado en SOAP llamado DSSP (protocolo de servicios de software
descentralizado):

1. El HTTP permite el soporte para operaciones tales como GET, PUT, POST, y
DELETE. Esto permite que un servicio sea usado dentro de un abundante
contexto UI como un explorador web que usa infraestructura y formato de datos
existentes.
2. DSSP permite el soporte para la manipulación estructurada de datos del estado
del servicio que soporta órdenes como UPDATE, INSERT, y QUERY. Además,
DSSP proporciona un modelo de notificación de evento que está relacionado con
los cambios en el estado de ese servicio.

4.1.8 - Aplicación robótica de ejemplo

Una aplicación en Robotics Studio es en esencia una coordinación de diversos servicios
distribuidos y asíncronos. Por ejemplo, un sensor se representa por un servicio que
ofrece una entrada de información, un actuador tendrá otro servicio asociado que
representa la respuesta física del robot, finalmente, un servicio controlador se encargaría
de interpretar la información obtenida del sensor y mandaría los comandos apropiados
al actuador.

Un ejemplo simple de una aplicación de Microsoft Robotics Studio es una composición

de tres servicios que pueden ser usados para controlar un robot simple (ver Fig. 3). Los
servicios son: un servicio de conducción (actuador) que puede mover el robot en
diferentes direcciones a diferentes velocidades; un servidor (sensor) de parachoques que
emite una señal cuando es golpeado por otro objeto, y un servicio de explorador (la
organización) que cambia la velocidad y la dirección del robot dependiendo de la
entrada del parachoques.

La coordinación se produce en la comunicación asíncrona entre todos estos servicios.

Por ejemplo, si el servicio de parachoques detecta un impacto, éste envía un mensaje al
servicio controlador, que a su vez decidirá qué mensaje enviar al servicio de control de
ruedas para realizar la maniobra oportuna. Este escenario se complica cuando el número
de sensores y de actuadores aumenta. El funcionamiento de los servicios asociados a los
sensores y actuadores sigue siendo similar al ejemplo puesto anteriormente, sin
embargo, el servicio coordinador (o servicios coordinadores) debe manejar mucha
información en tiempo real y aplicar complejas políticas de control.

Fig.3

En esta aplicación de muestra el servicio de explorador (EXPLORER) se suscribe al

servicio de parachoques (BUMPER) y envía instrucciones al servicio de conducción
(DRIVE). Tal composición se denomina emparejar. Una pareja es una referencia
direccional que representa la relación que un servicio tiene con otro servicio. Una pareja
es descrita por el tipo de la pareja y el ejemplo de pareja del servicio. La información
de la pareja también es expuesta como estado y puede ser inspeccionada usando la
operación de consulta que es parte del DSSP.

La figura 4 ilustra un ejemplo de cómo podría aparecer el servicio de un parachoques en

un explorador web. En este caso, la representación es una simple transformación de
XSLT del estado subyacente del servicio pero veremos que después, la representación
no está limitada a eso.
Fig.4

4.1.9 - Interactuar con la ejecución

Cuando se inicia un entorno, todos los servicios de infraestructura básicos están
disponibles para el uso por parte de otros servicios. Muchos de los servicios de
infraestructura pueden ser accedidos directamente desde la página de inicio del nodo
como se ilustra en la Fig. 5.
Fig.5

Dos servicios importantes accesibles desde la página de inicio son el panel de control y
el directorio de ejemplo. El panel de control proporciona una lista de todos los tipos de
servicio que están presentes sobre un nodo en particular y permite que un usuario
empiece un servicio desde cero (ver Fig. 6).
Fig.6

El directorio de ejemplo del servicio suministra una lista de servicios activos que se han
registrado con el directorio (ver Fig.7). La lista contiene un enlace al ejemplo del
servicio así como una lista de las parejas que son miembro de un servicio. Dado que las
parejas son también servicios, sólo se puede negar e inspeccionar cualquier aspecto de
una aplicación siguiendo los enlaces en un explorador web.
Fig.7

4.2 - INTRODUCCIÓN AL LENGUAJE DE PROGRAMACIÓN

VISUAL
El Lenguaje de programación Visual de Microsoft (VPL) es un entorno de desarrollo de
aplicación diseñado sobre un modelo de programación de flujo de datos basado en
gráficos en vez del control de flujo que es típico encontrar en la programación
convencional. En vez de la serie de comandos imperativos ejecutados secuencialmente,
un programa de flujo de datos es más como una serie de trabajadores sobre una cadena
de montaje, que hacen su tarea asignada cuando los materiales llegan. Por consiguiente
VPL es muy adecuado para programar una gran variedad de escenarios de
procesamiento simultáneo o distribuido.
VPL es adecuado para programadores principiantes con una comprensión básica de
conceptos como variables y lógica. Sin embargo, VPL no está limitado a principiantes.
La naturaleza del lenguaje de programación puede servir a programadores más
avanzados para la creación rápida de prototipos o el desarrollo de código. Además
mientras que su toolbox está confeccionado desarrollando aplicaciones de robot, la
arquitectura subyacente está limitada a los robots de programación y podría ser aplicada
también a otros usos. Por tanto, VPL podría resultar atractivo para una amplia gama de
usuarios incluyendo estudiantes, aficionados, así como posiblemente desarrolladores de
Web y programadores profesionales.

El VPL está basado en la programación de flujo de datos, esto lo hace particularmente

adecuado para las aplicaciones de programación de robots donde la distribución y la
concurrencia son inherentes.

Como hemos visto anteriormente, un programa de VPL consiste en bloques, que

generalmente llamamos actividades. El flujo de datos consiste en una secuencia de
actividades conectadas. Las actividades o bloques en VPL pueden representar un gran
número de cosas diferentes. Anteriormente hemos usado un cuadro de diálogo de
dirección, que no es más que un servicio pre-compilado que VPL tiene disponible. Un
bloque o actividad puede también ser un elemento de control de flujo de datos, una
función, un fragmento de código, etcétera. Los programas en VPL se escribirán
mediante la conexión de actividades. La aplicación resultante se denomina pues,
orquestación, refiriéndose a la secuenciación de procesos separados.

En VPL las actividades conectadas transmiten los datos a través de las conexiones.
Obsérvese a la siguiente figura:

En esta figura la actividad data transmite el valor 10 a lo largo de la conexión hasta la

actividad calculate. El valor transmitido se denomina en este caso value. La actividad
calculate recibe el valor 10, le añade cincuenta, y transmite el resultado a la actividad
variable bajo la denominación value. La variable actividad toma el valor entrante y lo
utiliza para ajustar la variable con el nombre indicado.

Las actividades se conectan mediante puntos o cuadrados. Nos referimos a ellos como
pines de conexión. Los pines de la izquierda son de entrada, y los pines de la derecha
son de salida. Estos pines representan las conexiones con las actividades de acciones
internas. Cuando se conecta un pin de entrada de una actividad se está seleccionando
una acción a la que llamar. Por ejemplo, cuando conectamos la actividad
GenericDifferentialDrive, podemos seleccionar la acción SetDrivePower. Cuando una
actividad recibe un mensaje de entrada válido se activa, procesa los datos del mensaje y
ejecuta su código. En el caso de la acción SetDrivePower, un mensaje de entrada válido
es un double.

En VPL hay muchas actividades que reciben entradas. Este no es el comportamiento por
defecto de las actividades.

Una actividad puede tener múltiples puertos de conexión a la entrada y cada uno de
ellos con su propio conjunto de puertos de conexión a la salida.

Las actividades tienen dos tipos de pines de salida. Los pines cuadrados son para salidas
de resultado o respuesta. Una salida de respuesta es proporcionada como resultado de
una entrada en particular. Los pines circulares son para las salidas de notificación. Una
notificación es típicamente enviada en respuesta a algún cambio o evento en un estado
interno. De todas formas, una actividad puede también enviar una notificación en
respuesta a un mensaje que entre. En resumen, las salidas de los resultados son
mostradas como puertos de conexión rectangular, mientras que las publicaciones (o
eventos) poseen puertos de conexión circular.

Un puerto de salida de respuesta se usa en situaciones donde el mensaje saliente (dato)

es enviado como resultado de un mensaje de acción específica entrante. Los puertos de
notificación pueden enviar información resultante como un mensaje, pero de forma más
frecuente lanzan un mensaje en forma de cambio en su estado interno.

Es importante hacer notar que al contrario que en una salida de resultado, en la cual sólo
se envía una señal cada vez, una salida de notificación puede ser disparada
repetidamente. Así, los puertos de salida de notificación son usados para enviar
mensajes de datos sin tener que solicitar el estado de la actividad.

Las actividades pueden, a su vez, incluir composiciones de otras actividades. En este

sentido, una aplicación construida en VPL es en sí misma una actividad. Los bloques de
actividades incluyen típicamente el nombre de la actividad y representaciones de sus
puntos de conexión. Un bloque de actividades también puede incluir gráficos que
ilustren el propósito de la actividad, así como elementos de interfaz con el usuario que
le permitan introducir valores, asignaciones o transformaciones de datos para su uso en
una actividad.

4.2.1 - Controlar un robot en simulación

Como primera tarea, crearemos un simple programa con el lenguaje visual de
programación de Microsoft para controlar un robot mediante un joystick.

Este ejemplo pretende ser una primera experiencia con el MSRS. Nos mostrará cómo
usar el lenguaje de programación visual de Microsoft o VPL para conectar sistemas
genéricos de definidos, asociarlos a un robot en particular y usar el robot en un entorno
simulado. Se puede substituir el robot simulado por un robot real sin tener que cambiar
el programa.

Paso uno: Añadir un servicio de joystick.

Desde la caja de herramientas de servicios a la izquierda de la ventana del VPL,

arrastrar el servicio de desktop joystick al entorno de trabajo. Este servicio muestra la
ventana que expone las capacidades básicas de un joystick que puede ser dirigido
mediante un ratón o el teclado.

Probarlo.

Desde el menú seleccionar run y start, o presionar la tecla F5. La primera vez que se
ejecuta un nuevo diagrama se deberá salvar. VPL iniciará un nuevo nodo DSS y
ejecutará el diagrama. Cuando el diagrama empiece a ejecutarse verá una ventana
llamada desktop joystick.
Pasó dos: añadir un sistema de conducción diferencial genérico.

De la misma forma que añadimos el servicio de joystick de escritorio en el paso uno,

ahora añadimos un servicio de sistema de conducción diferencial genérico; se denomina
genérico porque sirve de apoyo a las operaciones comunes disponibles en la mayoría de
sistemas de conducción diferenciales, pero no está asociado por defecto a ningún
sistema de conducción específico. Uno de los beneficios de Robotics Studio es que
puedes escribir programas genéricos que funcionarán en una gran variedad de robots.

Para asociar el sistema de conducción genérico a un sistema de conducción de un robot

específico, de forma que se pueda interactuar con el hardware del robot, se clicará en el
icono GenericDifferentialDrive para abrirlo. Luego, en la barra de herramientas de la
derecha denominada propiedades, para la configuración, seleccionaremos la entrada
"usar un manifiesto". Ahora, bajo manifiesto, hacer clic en el botón importar.
Seleccionar la entrada para IRobot.Create.Simulation.Manifest.xml. La barra de
herramientas de propiedades debería ser como ésta:
El manifiesto especifica, además de otras cosas, qué servicio implementará el sistema de
conducción genérico; mediante la selección de un manifiesto, la conducción genérica en
el diagrama ha sido asociada a un servicio de conducción de un robot particular (en este
caso, un IRobot Create10 simulado).

Paso tres: los componentes.

Conectar una notificación a un pedido

Conectamos el puerto de notificación (el pequeño círculo rojo de la derecha) del

desktop joystick al puerto de entrada (el pequeño cuadrado rojo de la izquierda) del
GenericDifferentialDrive.

Microsoft Robotics Studio sirve de apoyo a un sistema de publicación-subscripción. Un

servicio, o en este caso un diagrama, puede suscribir las notificaciones que otro servicio
publica. En este caso, cuando la posición del joystick cambia el servicio de joystick de
escritorio publicará una notificación. El diagrama puede recibir esa notificación
mediante la conexión con el puerto de notificaciones. El pequeño cuadrado rojo de la
derecha es la salida del resultado.

Aparecerá un cuadro de diálogo de conexiones. Éste mostrará las notificaciones

disponibles que el servicio de desktop joystick ofrece a la izquierda y los tipos de
pedidos disponibles que el servicio del sistema de conducción diferencial genérico
posee, en la columna derecha. El propósito de este diagrama es conducir un robot
usando un joystick, así pues se deberá seleccionar UpdateAxes de la columna izquierda
y SetDrivePower de la columna derecha.
Ahora aparecerá el cuadro de diálogo de conexiones de datos. Este cuadro de diálogo
permite especificar cómo la notificación producida por el desktop joystick es asimilada
por el servicio de conducción diferencial genérica.
Configurar las conexiones de datos.

El servicio de desktop joystick envía notificaciones cuando los ejes del joystick
cambian (en este caso los valores de X e Y), y estos valores oscilan entre -1000 y 1000.

El servicio GenericDifferentialDrive espera valores para las ruedas izquierda y derecha

(LeftWheelPower y RightWheelPower) entre -1 y 1, donde estos valores son
representativos de la cantidad de energía con que se alimentará a las ruedas izquierda y
derecha respectivamente. Si ambos son positivos el robot se moverá hacia delante, si
ambos son negativos entonces el robot se moverá hacia atrás. Si los valores de la
izquierda y derecha son diferentes entre sí, entonces el lado del robot con mayor valor
se moverá más que el lado con menor valor, haciendo que el robot gire.

Necesitaremos una transformación de los datos desde el desktop joystick a las ruedas
izquierda y derecha. Para ello, seleccionamos la casilla Edit values directly en la tabla
de conexiones de datos. Luego, introducimos las siguientes expresiones en las celdas de
valores para LeftWheelPower y RightWheelPower:
 (-Y + X) / 1000.0
 (-Y - X) / 1000.0

Paso cuatro: simulación.

Pulsar start desde el menú RUN o presionar F5. Se puede usar el ratón y las teclas w, a,
s, d, q, r para cambiar la localización de la cámara dentro del entorno simulado.

Usar un joystick.

Para usar un joystick con este diagrama, debemos arrastrar el servicio GameController
desde la caja de herramientas (toolbox) de servicios. Entonces unir el pin de notificación
(el círculo rojo pequeño de la derecha) con el medio del cable que conecta el desktop
joystick con el servicio GenericDifferentialDrive, como se muestra la figura:

En el diálogo de conexiones de datos, igual que antes, elegir UpdateAxes en el lado de

la izquierda y en el de la derecha elegir MergeConnection. Ahora nuestro diagrama
trabajará tanto con el joystick de escritorio como con el joystick físico a la vez. Esto es
posible puesto que ambos servicios funcionan con la misma interfaz (o contrato en la
terminología de MSRS).

4.3 - EL EDITOR DE SIMULACIONES

Las simulaciones se ejecutan desde el Microsoft Visual Simulation Environment. Una

vez ejecutándose el simulador, podemos cambiar el punto de vista mediante el ratón.
Esto no cambia la posición de la cámara sino el punto hacia el que mira. Para mover la
cámara hay que utilizar el teclado (de forma similar a la de muchos videojuegos),
presionando W y S para avanzar y retroceder. Del mismo modo, A y D desplazan a
izquierda y derecha, y Q y E arriba y abajo.

El menú File incluye comandos que permiten abrir y salvar escenas. Cuando se salva
una escena, el simulador salva el estado de cada entidad de la escena. También salva el
manifiesto que puede ser usado para reiniciar la escena y cualquier servicio asociado a
las entidades.

El menú Open incluye comandos que permiten cargar un nuevo escenario. Primero
elimina todas las entidades que estén actualmente en la escena, y luego carga el archivo
de estados y simula las entidades que contiene.

El comando Open Manifest del menú File permite ejecutar un manifiesto. Los
manifiestos de simulación contienen de forma habitual una referencia al estado del
simulador, así como servicios que están asociados con entidades en la escena.

También está disponible la opción Capture Image As del menú File durante la ejecución
de la simulación para salvar la imagen actual en un archivo al uso.

El menú View nos permite habilitar una barra de estado que aparece bajo la imagen.
Esta barra nos muestra tasa de “frames” por segundo así como la posición actual de la
cámara y hacia dónde apunta.

Desde este menú se puede también cambiar la dirección adonde apunta la cámara.
Seleccionando cualquiera de las opciones bajo “Look along” podemos cambiar la
dirección adonde apunta la cámara (recuérdese que la cámara permanecerá en la misma
localización).

El menú Render nos permite seleccionar una de las siguientes opciones de

representación:

 Visual: la malla asociada a cada entidad de la escena es representada con luces y

bordes realistas.

 Wireframe: las mallas son representadas con las mismas luces y bordes, pero en
forma de bastidor. Esto permite hacerse una idea de cuántos polígonos
constituyen cada malla y dónde están los bordes de los mismos.
 Physics: de esta manera se representan las formas físicas asociadas a cada
entidad. Esto nos permite ver cómo ha sido modelada cada entidad en el motor
de física. Sólo se podrá realizar esto si la física ha sido activada desde el menú
Physics.

 Combined: se representan simultáneamente las formas visuales y las físicas. Esta

vista permite determinar cómo de bien encaja cada forma física con el mallado
 visual de cada entidad. Igualmente, sólo disponemos de esta opción si la física
ha sido activada.

Se puede pasar de un modo a otro mediante la tecla F2.

Los comandos Settings del menú Render permiten especificar los ajustes de la
representación gráfica, y permanecerán así la siguiente vez que se ejecute el simulador.
Muchas tarjetas gráficas soportan sistemas anti-aliasing. Usando el comando
Antialiasing, la tarjeta gráfica se ralentizará. De todas formas, este sistema permite que
los bordes de los objetos queden mucho mejor definidos. Como ejemplo, compárense
los bordes de las siguientes imágenes:

Sin antialiasing. Con antialiasing.

Las órdenes Rotation Movement Scale y Translation Movement Scale afectan a la
forma en que las entradas de teclado, ratón y joystick son interpretados por el
simulador. Cifras altas hacen que la rotación y la traslación cambien más rápidamente
ante una misma entrada. De esta forma, el usuario puede personalizar la interacción con
el simulador de acuerdo a sus preferencias.

El indicador Quality Level afecta a la luminosidad de los objetos que se dibujan en la

pantalla. Ajustar un nivel de calidad más alto de lo recomendado puede provocar fallos
en la simulación.

El menú Camera permite la posibilidad de cambiar de cámara si se tiene más de una en

el escenario. Se puede usar la tecla F8 para cambiar entre cámaras rápidamente.

El menú Physics ofrece activar o desactivar el motor de física. También puede usarse F3
para cambiar rápidamente entre la activación y desactivación del motor físico. Cuando
está desactivado, el menú aparecerá con letras rojas y las entidades no se moverán o
actualizarán mediante el motor. Por ejemplo, los servicios de conducción serán
incapaces de mover los robots. Si se está tratando de dirigir a un robot y éste no se
mueve, lo primero que se debe comprobar es si el motor físico está habilitado.

Se pueden modificar los ajustes físicos mediante el comando Settings del menú Physics.
Estas operaciones no permanecerán de una sesión a otra.

La primera de las casillas nos permite especificar cómo será tratada la cámara principal
por el motor físico. Si se activa, una esfera invisible será colocada alrededor de la
cámara de forma que empujará o golpeará a los objetos circundantes. Dicha esfera se
volverá visible si se cambian las opciones a vista Physics.

La otra entrada que se puede ajustar en el cuadro de diálogo nos permite ajustar el valor
de la gravedad. Para simular situaciones de ingravidez, sólo debemos ajustar el valor 0.

El menú Mode permite alternar entre el modo normal (Run) y el modo Edit. También se
puede cambiar de uno a otro mediante F5. En el modo Edit, la ventana tiene el siguiente
aspecto:
El panel de la esquina superior izquierda es la ventana de entidades y el de abajo a la
izquierda, la de propiedades. El tamaño de dichos paneles puede ser ajustado a voluntad
del usuario.

La ventana de entidades muestra una visión jerárquica de todas las entidades de la

escena. Cuando una de estas entidades es seleccionada, las propiedades de dicha entidad
se mostrarán en el panel de abajo a la izquierda.

Cuando se cambia al modo Edit, el motor de física se desactiva automáticamente y el

comando correspondiente aparece en rojo en la barra de menú llamada Physics. Se
puede activar la opción del motor físico en el modo Edit si así se desea, pero eso hará
que sea más difícil mover objetos por el escenario.

En el modo Edit, la cabecera Entity aparecerá en el menú. Allí podemos salvar y cargar
entidades, así como cortar, copiar y pegar operaciones en entidades.

Si seleccionamos una entidad como el cielo (sky), se nos mostrarán una serie de
propiedades. Para cambiar el mapa de texturas usadas en el cielo, seleccionaríamos la
etiqueta VisualTexture.

Directions.dds, sky.dds y sky_diff.dds son tipos especiales de imágenes denominados

mapas cúbicos o cubos de texturas. Están constituidos por seis imágenes diferentes que
semejan las caras de un cubo. La entidad del cielo sólo puede cargar este tipo de
imágenes.

Sobre la casilla de propiedades se muestran el nombre y tipo de la entidad

seleccionados.
Para cerrar la simulación se selecciona la opción Exit Simulator desde el menú File.
Este comando corta la acción del simulador y del nodo DssHost de forma ordenada.

Una forma sencilla de visualizar las entidades seleccionadas es hacer clic en ellas con el
botón derecho del ratón desde la venta de simulación. Desde ahí, podemos rotar el
objeto (Rotation) o cambiar su posición en cualquiera de los ejes.

También se puede realizar una copia de una entidad seleccionando su casilla

correspondiente desde la ventana de entidades y luego seleccionando Copy desde el
menú Entity (o presionando Ctrl+C). Después, elegir Paste desde el menú Entity (o
presionar Ctrl+V) y se creará otra entidad similar en la lista. Esta nueva entidad estará
en la misma posición que la anterior, por lo que se deberá modificar su emplazamiento.

Es posible editar las formas y texturas que usan las entidades. Si deseamos modificar el
tamaño de un objeto (shape), no tenemos más que cambiar los valores de sus
dimensiones en cualquiera de los ejes y presionar OK. En el caso de una esfera,
podemos modificar su radio y, en general, la masa de la entidad también será un valor a
editar bajo el nombre Mass.

Si deseamos cambiar la apariencia que tendrá una entidad, no tenemos más que
seleccionar dentro de la propiedad EntityState y pulsar un pequeño botón que abrirá otro
menú. Allí, podremos elegir un valor para la textura (Mesh) que nos dará la apariencia
de la entidad.

Si seleccionamos Combined View desde el menú Render, comprobaremos que la forma

física del objeto que hemos modificado sigue siendo la misma, a pesar de su apariencia
en la simulación.

El alumbrado general puede ser ajustado cambiando los parámetros del sol. El sol es
una LightSourceEntity, una entidad especial diseñada iluminar el lugar de maneras
diferentes. Las propiedades propias de una luz están bajo la sección LightProperites de
la celda de propiedades.

Algunas propiedades importantes de la luz son el tipo (Type) y el color (Color). Hay
tres tipos de luz disponibles: Omni, Directional, y Spot. Cada una de ellas alumbra los
objetos de maneras diferentes. Una luz “omni” emite la luz desde punto a todas las
direcciones - por lo tanto, solamente su posición afecta al entorno. Seleccionando el sol
en la cuadrícula de propiedades y poniendo su tipo a Omni podremos cambiarlo de
lugar y notar cómo cambia la iluminación del lugar. También se puede comprobar cómo
girarlo no tiene ningún efecto en el escenario. Las luces direccionales iluminan todos
puntos en la escena desde la misma dirección -en este caso, solamente su rotación afecta
el lugar. Una luz de Spot solamente ilumina puntos dentro de su Umbral, o puntos
dentro del cono. Un valor de umbral más grande quiere decir que el cono de luz es más
amplio. Las luces de Spot usan tanto la posición como la rotación. Poniendo el tipo de
sol a Spot, moviéndolo y girándolo podremos iluminar los puntos que más nos
interesen.
Otra propiedad útil de las luces es la llamada CastsShadows. Poniendo este valor como
verdadero hará que las sombras sean dibujadas para todos objetos con respecto a la luz
correspondiente. Esto puede tener un impacto negativo sobre el rendimiento. Cuando
esta propiedad está activada debe ser llevado a cabo un gran cálculo previo que podría
tomar mucho tiempo dependiendo de las mallas que estén representadas en el entorno.
El modelo de LegoNXT puede tardar hasta varios minutos en prepararse para la versión
de representación de sombras. Sin embargo, esto solamente se hace una vez para cada
malla.

Sombras lanzadas desde un foco (Spot).

El color de una entidad está determinado por las luces en el entorno y el material de la
malla de la entidad. Las propiedades del material pueden ser cambiadas para mejorar el
contraste o diferenciar entidades entre sí.

Una manera más fácil de editar materiales es usando el editor material. Haciendo clic en
el botón junto a la propiedad RenderingMaterial se abre el editor material que brinda
una interfaz fácil de usar para cambiar las propiedades del material.
Editor material.

Entre dos entidades se puede establecer una relación “padre-hijo”. De esta forma, la
adición de una entidad hijo de otras entidades permite “pegarlas” para tratarlas como
una unidad. Las entidades padre se actualizan siempre antes que sus hijos, y éstas
seguirán siempre los cambios que se provoquen en las entidades padre.

Entidades padre e hijo conectadas por una unión física.

Hay un caso especial en que ambas entidades, padre e hijo, tienen formas físicas. En
este caso, se crea una articulación física que conecta las dos entidades. Dicha
articulación se eliminará si el hijo se separa del padre. Inicialmente, la unión es rígida.
Las propiedades de la unión pueden ser modificadas en el cuadro de propiedades de la
entidad hijo bajo la denominación ParentJoint. Cambiar de lugar una entidad padre
causará que las entidades hijo se muevan con ella. Sin embargo, desplazar a una entidad
hijo por el escenario hará que su posición relativa y orientación cambien
permanentemente para acomodarse a su nueva posición.

Si hemos terminado de modelar el escenario, podemos abandonar el modo de edición

mediante F5. Salvaremos el entorno bajo una denominación (por ejemplo,
MyRobot.xml) y comprobaremos que se escribirán dos archivos: MyRobot.xml que
contiene el simulador y la entidad estado, y MyRobot.manifest.xml que contiene todos
los servicios que necesitan ser ejecutados.

Si ahora seleccionamos Open Manifest, desde el menú File y abrimos

MyRobot.manifest.xml, la escena se volverá a cargar y todos los servicios especificados
para las entidades se iniciarán de forma simultánea.

Cuando se abre un nuevo manifiesto, el simulador no se esfuerza en clausurar ningún

servicio que pueda estar ejecutándose. Esto puede provocar que múltiples servicios
intenten tomar como referencia a la misma entidad. Mediante el Panel de Control se
pueden cerrar todos los servicios que haga falta antes de cargar un nuevo manifiesto.

Si es elige la opción Open Manifest para ejecutar un nuevo manifiesto, un mensaje rojo
de error aparecerá en la ventana de la consola DssHost. No es un error importante si el
tipo de servicio que falló al cargar en el motor de simulación. Esto se debe al hecho de
que el motor de simulación está activo cuando el manifiesto trata de empezar una nueva
instancia.

Cuando se salva una escena con el propósito de iniciar los servicios automáticamente al
cargar el manifiesto resultante, se debe especificar siempre un ServiceContract para las
entidades, con objeto de arrancar los servicios adecuados. Esto es particularmente
importante si la entidad está definida en un conjunto que no ha sido cargado por defecto.
En este caso, la entidad debe mencionar el servicio que contiene su definición para ser
creada en el entorno. Las entidades que están definidas en el ensamblaje actual deben
ser definidas en un servicio válido de DLL.

4.3.1 - Robots disponibles en MSRS

El programa de simulación viene equipado con los manifiestos de los siguientes robots:
1. iRobot

2. Kuka LB320
3. Lego NXT

4. Pioneer 3DX21
4.3.2 - Trabajos de Trevor Taylor en MSRS

Si se profundiza un poco en cualquier foro oficial de Microsoft Robotics Studio, es sólo

cuestión de tiempo encontrarse referencias o artículos escritos por Trevor Taylor22.

Profesor de la Universidad Tecnológica de Queensland (Brisbane, Australia), y coautor

del libro Professional Microsoft Robotics Studio, Taylor ha realizado numerosas
aplicaciones en MSRS que tienen su código disponible en internet. Para realizar este
trabajo se contó con su ayuda a través de correo electrónico para resolver dudas
referentes a uso de programas que él mismo diseñó:

GENERADOR DE MAPAS (MAZE SIMULATOR)23

Basado en un código original de Ben Axelrod, crea un mundo de apariencia laberíntica

a partir de una imagen de mapa de bits bidimensional. Este modelo plano especifica
mediante un código de colores la altura y el color o textura de los muros y demás
objetos rectangulares presentes en el laberinto. Además, en la última versión, se puden
crear incluso objetos esféricos.

El mapa que se usa como modelo del entorno tridimensional debe ser creado con los 16
colores básicos que se usa en Windows Paint por defecto en formato BMP, aunque la
imagen puede estar en formatos BMP, GIF y JPG. Cuando el Maze Simulator lee el
mapa de bits, asume que el píxel de la esquina superior izquierda es parte del suelo y
usa su color para identificar el resto de suelo.

A través de la modificación del código se pueden realizar multitud de ajustes en la

simulación. La más inmediata es cambiar el mapa que viene por defecto, por uno de
nuestra creación. Para ello, no tenemos más que cambiar el nombre correspondiente en
la línea correspondiente del archivo MazeSimulator.Config.xml

De la misma manera, se pueden variar opciones tales como la textura y masa de los
objetos y la altura de los muros mediante cambios similares en el código.
Análogamente, podemos seleccionar qué tipo de robot queremos controlar en la
simulación. Los robots disponibles con el Pioneer 3DX y el Lego NXT. Obsérvese que
el robot de Pioneer posee una cámara montada en la parte superior, pero el Lego no.

Los requerimientos e instrucciones para la instalación de este simulador están

disponibles en la web.

Cuando se inicia la ejecución del Maze Simulator se crean dos ventanas: el simulador y
un teclado direccional.
El motor de simulación nos permite usar simultáneamente varias cámaras. Podemos
cambiar de una a otra presionando la tecla F8 en la ventana de simulación, o
seleccionando desde el menú Camera.

Si tenemos seleccionado el robot de Pioneer y optamos por la robocam del menú

Camera, podremos tener una visión subjetiva desde el robot. De esta forma, puede ser
más fácil dirigirlo. Un ejemplo de lo que estaría viendo el robot en el escenario
mostrado en las imágenes anteriores es el siguiente:

En el teclado direccional debemos introducir localhost como nombre del nodo remoto y
número de puerto 50001. Luego, podremos darle al botón Connect. Aparecerán dos
servicios en la lista. Elegiremos el simulateddifferentialdrive y luego pulsaremos el
botón Drive. A partir de ahí, podremos controlar el robot. También podemos hacer uso
de un joystick o controlador de juego. Debe ser compatible con DirectX, pero casi todos
los modelos modernos lo son.

Un ejemplo de mapa tridimensional creado a partir de uno bidimensional lo podemos

ver en un laberinto generado para este proyecto:
SIMULADOR DE EXPLORADOR (EXPLORERSIM PROGRAM)24

Este programa es una versión modificada del anteriormente comentado tribot explorador
con ultrasonidos. En este caso, el robot Pioneer explora el entorno usando un medidor
de distancia por láser y construye un mapa sobre la marcha.

A continuación, se muestra una captura de pantalla del programa en ejecución. Nótese

que podemos ver la cámara del robot en una ventana separada y en el teclado
direccional tenemos un mapa basado en los datos del rayo láser:
Básicamente, el programa ExplorerSim controla un robot Pioneer 3DX simulado, que
lleva acoplado un sensor de distancia por rayo láser y una cámara. El láser se usa para
determinar la dirección en la que hay mayor espacio libre y que el robot se encamine
hacia ella. Por ello, el robot avanza, se para, gira en torno suyo y prosigue la marcha
cada cierto tiempo.

Por supuesto, el algoritmo de exploración no es perfecto y se producen algunos fallos. A

veces, el robot regresa a áreas previamente exploradas (puesto que el programa no hace
uso del mapa que se va construyendo) y a veces oscila de un lado a otro para decidir a
dónde dirigirse.

Toda la documentación necesaria, así como un breve tutorial para el manejo del
programa se encuentra disponible en la web de Trevor Taylor. Adicionalmente, el
profesor Taylor prestó su ayuda al autor de este proyecto durante varias semanas para
un mejor entendimiento de sus trabajos y solucionar los problemas debidos al uso de
diferentes versiones de MSRS y Windows Vista.
4.3.3 - Resumen
La ejecución de Microsoft Robotics Studio ha sido diseñada para facilitar la creación y
ejecución de aplicaciones de robótica a lo largo de una gran variedad de plataformas de
hardware. Para complacer los escenarios de robótica comunes, la ejecución suministra
una infraestructura basada en mensajes que organiza simultáneamente prototipos de alto
nivel así como un modelo de aplicación con un soporte adicional para la manipulación
de datos estructurada y la notificación de eventos. El resultado es un ambiente flexible
para desarrollar aplicaciones de robótica que se extienden desde las autónomas hasta las
aplicaciones controladas operadas en una gran variedad de escenarios.

Microsoft Robotics Studio se centra en una amplia gama de objetivos en un intento de

acelerar el desarrollo y la adopción de la robótica. Una parte importante de este esfuerzo
es el tiempo de ejecución de la simulación. Es obvio que los juegos de PC y
videoconsola han pavimentado el camino de forma que han hecho la simulación
robótica asequible y extensamente utilizable. Los juegos dependen de visualizaciones
foto-realistas con simulación de física avanzada y funcionan dentro de las restricciones
de tiempo real. Este fue un punto de partida perfecto para el desarrollo de este
programa.

El tiempo de ejecución de la simulación se diseñó para ser usados en una gran variedad
de escenarios avanzados con demandas altas de fidelidad, visualización, y
adaptabilidad. Al mismo tiempo, un usuario principiante con poca o ninguna
experiencia de programación puede hacer uso de la simulación, desarrollando
aplicaciones interesantes en un entorno similar al de los videojuegos. La integración del
motor PhysX de Ageia Technologies permite el uso de un producto de simulación de
física muy versátil y que se puede desarrollar constantemente hacia las características
que serán imprescindibles para la robótica. El motor de representación gráfica está
basado en el marco XNA de Microsoft.

En el siguiente apartado, discutiremos:

 Los desafíos planteados por el desarrollo de la robótica

 Beneficios de la simulación

 Desventajas de la simulación y sus limitaciones

 Visión general del tiempo de simulación

LOS DESAFÍOS PLANTEADOS POR EL DESARROLLO DE LA ROBÓTICA

El equipo físico de robótica puede ser costoso y difícil de encontrar

Las plataformas de robótica modulares, como las de LEGO MINDSTORMS ™ y

fischertechnik®, han hecho la robótica asequible a una amplia gama de consumidores.
Estas plataformas son un punto de partida excelente para el mercado educativo y los
aficionados, pero si se desea subir un nivel en relación con la complejidad del robot o el
número de robots individuales, el coste prohíbe a la mayoría de las personas ir más
lejos.

Dificultad de para resolver problemas en el hardware

Localizar fallos de hardware, incluso en el caso de elementos ampliamente extendidos

como un reproductor de DVD o una TV es difícil. Los elementos de consumo habitual
en electrónica suelen ser sumamente seguros, así que la mayoría de las personas no
tienen que preocuparse por cosas que se estropeen. Cuando se está montando un robot
(especialmente un robot por encargo basado en una plataforma modular por partes con
elementos externos) la destreza con que se haga será determinante así como el tiempo y
el esfuerzo invertidos en “depurar” su instalación.

Dificultad del uso simultáneo

Desarrollar un robot avanzado (como los vehículos que participaron en las

competiciones de DARPA25) con un equipo de personas se está volviendo un
acontecimiento común. Uno de los desafíos es que a menudo, el robot que se está
desarrollando es costoso y hay solamente uno. Estas dos propiedades hacen difícil
realizar pruebas simultáneamente con otros y sin peligro de destruir el robot. Esto dirige
el esfuerzo a tratar de desarrollar componentes aisladamente, hace la integración más
difícil e introduce defectos difíciles de localizar.

BENEFICIOS DE LA SIMULACIÓN

Bajos requerimientos

La simulación permite que el desarrollo de robots muy interesantes o enjambres de ellos

sea realizado con los únicos factores restrictivos principales de tiempo e imaginación
por parte de un usuario con un ordenador. Al mismo tiempo, los restringe en las
maneras similares a los robots físicos, así de forma que el esfuerzo se enfoca en algo
que puede ser realizado.
Enfoque por etapas

Microsoft Robotics Studio se acerca a la simulación por etapas, permitiendo que los
usuarios se las arreglen con la complejidad de forma gradual. De esta forma se puede
"depurar" un robot simulado empezando con elementos primitivos y requiriendo
solamente conocimientos básicos. Es sumamente conciso para añadir tal robot virtual en
un entorno, además de algunas formas simples con las que interactuar. Esto quiere decir
que depurar, incluso en la simulación, es muy simple.

Creación de prototipos

Los modelos físicos de un robot y los servicios de simulación que los usan pueden ser
desarrollados simultáneamente por muchas personas, exactamente de la misma manera
que muchas comunidades de desarrollo de software crean una "plataforma" que muchos
pueden usar y modificar sin preocuparse por estropear robots costosos y únicos.

Educación

La simulación puede ser una ayuda instructiva sumamente útil. Permite al usuario
escoger en qué se punto va a concentrar, fortalecer la complejidad, y controlar el
entorno. También se pueden introducir componentes que son prácticamente virtuales,
conceptos que no pueden ser fácilmente realizados pero que resultan útiles para el
aprendizaje.

Sistema de aprendizaje.

Otro aspecto muy interesante de la simulación es que puede ser usado mientras el robot
está en movimiento, como una herramienta predictiva o u módulo de aprendizaje
supervisado. Durante bastante tiempo, la simulación se ha usado simultáneamente con
un robot activo para realizar pruebas en el mundo de simulación que es actualizado en
tiempo real con los datos sensoriales. Luego, la simulación puede determinar
(probabilísticamente) si algo es una buena idea, "mirando hacia el futuro" entre varias
posibilidades.
DESVENTAJAS DE LA SIMULACIÓN Y SUS LIMITACIONES

Estamos tratando esencialmente de convertir un problema de hardware en uno de

software. Sin embargo, desarrollar el software y un modelo físico tiene sus propios
desafíos, así que terminamos con un conjunto diferente de desafíos y limitaciones.
Generalmente esto quiere decir que hay un punto óptimo; un rango de aplicaciones
donde la simulación es muy apropiada, y luego un rango de aplicaciones o etapas en el
desarrollo, donde usar el robot verdadero es esencial o más fácil. Cuando mejoramos el
tiempo de ejecución de la simulación, el alcance donde la solicitud es apropiada se
dilata. El aumento en el poder de procesamiento más la naturaleza concurrente y
distribuida de Microsoft Robotics Studio debe ayudar abordar algunos de estos asuntos.

Ausencia de ruidos en los datos.

En general, el consejo que se obtiene de personas acostumbradas a trabajar en proyectos

de gran envergadura con robots es que se debe pasar mucho tiempo con el robot real, sin
importar cuán buena pueda llegar a ser la simulación. Esto es así parcialmente porque
debemos realizar mucho trabajo para obtener una simulación más útil y más objetiva.
Pero también es porque el mundo real es imprevisible y complicado con mucho ruido
siendo capturado por sensores.

Modelos incompletos e inexactos.

Existe un gran número de efectos en el mundo real que todavía son muy difíciles de
modelar. Esto quiere decir que no siempre se podrá ser capaz de modelar todo con
exactitud, especialmente en tiempo real. Para ciertos casos, como los vehículos con
ruedas, el movimiento a velocidades bajas todavía es un desafío grande para los
mecanismos de simulación. El modelado de sónar es otro de los que presenta
dificultades.

Mucho tiempo para ajustar.

Durante la ejecución de la simulación, es en realidad muy fácil obtener un robot en el

mundo virtual andando de un lado para otro interactuando con otros objetos. Sin
embargo, todavía requiere un esfuerzo importante ajustar el equipo físico ficticio (los
llamamos entidades) para actuar de la misma manera que sus equivalentes del mundo
real. Usando tecnología de PhysX de AGEIA, tenemos un muy buen punto de partida
pero se requiere un esfuerzo mayor en los elementos automatizados para afinar los
parámetros de simulación.
VISIÓN GENERAL DEL TIEMPO DE EJECUCIÓN DE SIMULACIÓN

El entorno de simulación de MSRS está compuesto de varios módulos:

Simulation Engine Service: responsable del progreso del tiempo en el motor físico de
la simulación.

Managed Physics Engine Wrapper: abstrae al programador del nivel bajo del motor
físico.

Native Physics Engine Library: permite la aceleración del hardware a través de AGEIA
PhysX Technology.

Entities: representa el hardware y los objetos físicos en el mundo simulado. Un gran

número de entidades están definidas en MSRS y permiten al usuario crear rápidamente
un entorno de simulación.

El tiempo de ejecución de simulación está compuesto de los siguientes componentes:

El servicio del motor de simulación es responsable de dar entidades y avanzar la

simulación para el motor de física. Sigue la trayectoria del estado de entorno de
simulación entero y suministra el servicio a la simulación.

La envoltura de motor de física dirigido abstrae al usuario del motor de física de baja
intensidad (API), y provee una interfaz más concisa y adecuada para la simulación de
física.

La biblioteca del motor de física permite la aceleración de hardware a través del PhysX
SDK de AGEIA y el tiempo de ejecución, que soportan la aceleración del hardware a
través del procesador de PhysX de AGEIA.

Las entidades representan el hardware y los objetos físicos en el entorno de la

simulación. Varias entidades vienen predeterminadas con el Microsoft Robotics Studio
y permiten que los usuarios las monten rápidamente y desarrollen plataformas de robot
simulados diferentes entornos virtuales.

Se puede decidir interactuar solamente con la API del motor de física dirigida si no se
desea visualización. Sin embargo, es altamente recomendado el uso del servicio del
motor de simulación y definir entidades personalizadas que desactiven la representación
gráfica. Esto simplifica la inspección y depuración del código de simulación
enormemente.

El motor de representación gráfica la línea programable de tarjetas aceleradoras

gráficas, ajustada a los patrones de Directx9 Pixel/Vertex Shader.
4.4 - VENTAJAS DE MSRS

Entre las principales características y beneficios del entorno de Microsoft Robotics

Studio se incluyen:

-- La plataforma de desarrollo de robótica integrada. Microsoft Robotics Studio

incluye una herramienta de programación visual, que facilita la creación y utilización de
las aplicaciones de robots. Robotics Studio permite a los desarrolladores generar los
servicios modulares para hardware y software, permitiendo a los usuarios interactuar
con los robots a través de las interfaces basadas en la web o en Windows.

Los desarrolladores también podrán simular las aplicaciones robóticas por medio de
la utilización de modelos realistas en 3-D; Microsoft ha licenciado el buscador PhysX
de AGEIA, un pionero en la física de aceleración de hardware, que permite la
simulación de la física del mundo real a través de los modelos con robots. Las
simulaciones de PhysX también se pueden acelerar utilizando el hardware AGEIA.

-- Servicios de bajo peso orientados a la puesta en marcha. Microsoft Robotics Studio

proporciona servicios de bajo peso orientados a la puesta en marcha. Gracias a la
utilización de una biblioteca de concurrencias basada en .NET, consigue que el
desarrollo de aplicaciones asincrónicas sea algo sencillo. La arquitectura orientada a los
servicios y basada en los mensajes hace que sea simple acceder a los sensores más
novedosos de los robots, y actúa a través de un buscador web, y su modelo compuesto
permite la construcción de las funciones de elevado nivel gracias a la utilización de
componentes sencillos y proporcionando un código de reutilización de los módulos,
además de conseguir una mejor fiabilidad y capacidad de sustitución.

-- Plataforma escalar y extensible. El modelo de programación Microsoft Robotics

Studio se puede aplicar a través de una amplia variedad de plataformas de hardware
para robots, permitiendo a los usuarios transferir sus capacidades de aprendizaje en las
plataformas. Las terceras partes también pueden ampliar su funcionalidad de la
plataforma al proporcionar bibliotecas adicionales y servicios.

Tanto los escenarios de ejecución remotos (basados en los PC) y autónomos

(basados en los robots) se pueden desarrollar utilizando una selección de lenguajes de
programación, incluyendo los de los lenguajes Microsoft Visual Studio y Microsoft
Visual Studio Express (Visual C# y Visual Basic .NET), JScript y Microsoft IronPython
1.0 Beta 1, y los lenguajes de terceras partes que son conformes a estas arquitecturas
basadas en los servicios.
El amplio apoyo de la industria respalda la presentación técnica primaria.

En el certamen RoboBusiness26, Microsoft y otros socios industriales han ofrecido

modelos de trabajo y demostraciones acerca de la tecnología de Robotics Studio:

-- CoroWare Inc., una compañía de Innova Holdings, ha realizado demostraciones

sobre su Surveyor 3000, un robot de servicios móviles que se puede manejar de forma
remota o programar para que funcione de forma semiautónoma.

-- KUKA Robot Group ha mostrado un prototipo de robot de bajo peso controlado a

través de un servicio remoto de joystick y que utiliza los servicios basados en Microsoft
Robotics Studio.

-- Robosoft ha mostrado su robot de seis ruedas robuROC6, que es capaz de disfrutar

de navegación autónoma en terrenos complicados, lo que es una clara evidencia de la
correcta arquitectura de distribución integrada, que se ha construido a través del núcleo
robótico robuBOX, y que podría controlarse de forma fácil a través del tiempo de
funcionamiento de Microsoft Robotics Studio.

-- RoboticsConnection, que cuenta con un robot de seguimiento basado en Windows

XP y que utiliza una de sus placas Serializer.NET Robot Controller a través de
Microsoft Robotics Studio y de los servicios Serializer.

-- White Box Robotics Inc. ha mostrado un escenario de telepresencia que cuenta con
914 PC-BOT. El 914 se controló a través de una interfaz web basada en Robotics
Studio, que es accesible de forma remota a través de una red.

4.5 - SOFTWARE LIBRE SIMILAR (URBI)

URBI27 (Universal Robotic Body Interface) es un lenguaje de programación usado para

el control de robots.

Desarrollado por Gostai, una joven empresa francesa, pretende ser una alternativa a
Microsoft Robotics Studio (MRS). La aplicación funciona en Windows, y
próximamente en Mac y GNU/Linux. El SDK es de código abierto, está publicado bajo
licencia GNU GPL, y es independiente del sistema robótico empleado. Actualmente
puede probarse en simulaciones y de forma real en ciertos robots como por ejemplo, en
los nuevos NXT de Lego Mindstorms o en los robots aspiradora Roomba.
URBI es un lenguaje cuyo núcleo es de bajo nivel, diseñado para trabajar con motores y
sensores, aunque permite el desarrollo de comandos complejos de alto nivel. En su
diseño se ha cuidado la simplicidad, por lo que no existen arquitecturas complejas,
logrando que en pocos minutos se puedan realizar fácilmente programas de control
complejos. También permite la interconexión con otros lenguajes de programación,
como C++, Java, Python, Matlab y muchos otros.