This is my second post on the Microsoft Technology Summit which I attended on Microsoft's Redmond campus.  This post is a summary of the Day 2 sessions.  My post about Day 1 can be found here.  MTS is a conference of technologists and bloggers invited by Microsoft to hear updates about various Microsoft products and initiatives and to provide feedback. Most of the attendees are experts in technologies and communities that aren't closely, if at all, associated with Microsoft.  Full disclosure: Microsoft paid for my travel, lodging and food during the summit.

Microsoft Open Source Software Lab
Annandeep Pannu, Senior Program Manager for Platform Strategy, gave an introduction to the Microsoft OSS Lab.  The lab's mission is to foster mutual respect and understanding between MS and OS community such that both act responsibly toward each other.

Recent projects the lab has completed include:
- Windows Media Player 11 Firefox interop
- Silverlight/Moonlight firefox interop
- SQL Server drivers Java/PHP interop
- FastCGI Java/PHP/Python interop
- Firefox on Vista
- SAMBA interop with file and print services

Current projects include:
- Hyper-V Linux interop
- WS-Man compliance tool (system management)
- PHP Pear/ADOB Abstraction (PHP interop)
- ASF Technology Transfer (Apache interop)
- cardspace relying party (Java/PHP/Ruby/C interop)
- HPC Linux/Windows environment (identity integration, file server integration, resource manager interop)

In answer to an attendee's question, Pannu stated that Microsoft has no plans to port Office apps to Linux.  It is a fundamental belief of the lab that Windows is the best OS.  As such, their efforts will always be focused on letting other systems integrate with Windows, not porting Windows applications to other systems.

IIS7 Product Overview
Bill Staples, Principle Product Unit Manager of the IIS Product Division, went into a lot of detail on the new version of Microsoft's web server, IIS7.

He was one of the few presenters that didn't reuse their presentation from the MIX08 conference, instead opting to just demo the product.

Microsoft has been working on IIS7 for five years.  They decided that every IIS7 feature must be built on public APIs in order to have as little of the server built into the kernel.  I'm sure this was motivated by security concerns; the less server code running in the kernel, the fewer potential exploits that would provide kernel access.  To accomplish this, they added a slim request/response API with an extensibility model. All other features are modules that can be added/removed as needed, a la Apache."  Also borrowing from Apache, the "configuration repository"  for the server is an XML file.

IIS7 is clearly a huge improvement over IIS6, but Staple's audience grilled him on why they should be excited about this stuff considering Apache has done all of it for a long time.  Staples commented that Apache/Linux is a great solution and that now developers have a similarly modular option on Windows.  Apparently the company position is that Apache doesn't run on Windows!  IIS7 only runs on Vista and Windows Server 2008.

One differentiator is the GUI admin tool that is built on top of the XML configuration file.  It's pretty much what you'd expect from a Windows management interface.  All of the configuration can also be done from the command line apparently.  Site specific IIS config can be controlled via an XML web.config file located in the site's root directory.

As a demo, Staples created a Wordpress blog and served it with IIS and the FastCGI module.

Output caching allows dynamic content to be cached for period of time (eg 30 secs).  Staples showed how this dramatically improved IIS/FastCGI/Wordpress performance.

By default, sites run in separate processes.  IIS7 will eventually include a new URL rewriting feature which has not yet been publicly released.

IIS7 does include a cool feature called Bandwidth Throttling.  A site can be configured to respond to a request for certain media types with a temporary burst of very high bandwidth for a few seconds, then continue with bandwidth throttled at a percentage (better be >= 100) of the media file bitrate so that the downloading stays just ahead of the media player.  The point is to save bandwidth in the situations where a user only watches the first few seconds of a media clip by avoiding serving the entire clip during that time.  In the event of a network interruption, IIS increases bandwidth allocation.  Does Apache have this capability?

So IIS7 looks great compared to IIS6, and developers and sysadmins who have no choice but to use the Microsoft stack should be excited about it.  Those who use Apache probably don't have any new motivation to switch, with the possible exception of the bandwidth throttling feature.

The Microsoft Local Software Economy
John Fernandes, Director of International Business Development discussed Microsoft efforts to foster healthy local software economies in international communities.  Local governments have asked Microsoft what they can do to help with the local economies, and this program is the eventual answer.

Local Software Economy Initiative
-builds self-sustaining ecosystems though local partnerships in 70+ countries
-helps governments drive prosperity
-grows competencies of local IT community
-creates new businesses
-focuses on students academics, government, ISVs and startups
-drives long term growth opportunity for partners & MS

Local software Economy Programs
-skills & capacity building
-foster innovation & ICT growth
-enable ICT competitiveness

Microsoft Innovation Centers
- provide environment for innovation
- operated with government, university, industry organizations - not on a MS campus
- 110 MICs in 60+ countries

Fernandes was asked bluntly if Microsoft's goal in running the innovation centers was to train developers who are dependent on Microsoft technology, or to build a general local software economy that would payoff over the long term.  In other words, are they creating customers now or a market later?  Fernandes said it was the latter.

He took some flak for this from an attendee who said she has been in the training centers and there is nothing being taught except Microsoft products.  On one hand I think it's unrealistic to criticize Microsoft for donating and teaching their own technology.  What do you expect?  Linux classes?  On the other hand, maybe a conflict of interest is too inherent in the Microsoft-only program, and a better way to work towards the stated goal of long term health of the local software economies would be to donate resources to or co-found a non-profit.

IE8 Product overview
Chris Wilson, Internet Explorer Platform Architect talked about the major changes in IE8.  He first discussed the different consumers of the product, users and developers, and how these groups have different priorities.

Users want predictability, productivity, and power, while developers want productivity, power, and predictability, but those concepts mean different things to each group.

For users, predictability means security, compatibility, and reliability.  New IE8 features to address these needs include:
-the site domain name is highlighted in address bar separately from rest of the URL
-the Manage Add-Ons experience has been improved
-ActiveX components can be installed per-user and per-site without admin rights
-DEP/NX code execution prevention
-users' sites and apps work in new browser version

Two new big features increase user productivity.  Activities provide a framework for plugins that can do something with data on a web page.  An example would be obtaining a map for an address selected on a page.  Activities are available via right-click and have a category, such as "Map", that supports hierarchical navigation through the right-click menu.  Activities are defined with the OpenService format.

WebSlices allow a user to subscribe to a specific piece of content on a site.  the WebSlice format is based on hAtom, but extends it.  WebSlices support dynamic content while hAtom only supports static content.  WebSlice subscriptions get added to the Feeds platform.

Predictability for developers has conflicting definitions.  Should IE8 behave like the standard or like IE7?  Of course, this is a quandary of Microsoft's own making by not supporting the standards as they emerged.  Microsoft considered having sites opt into IE8's standards support, but they thankfully went the other way.  Instead, IE8 will default rendering according to the standards.  Sites that don't render correctly in the standards mode can add a <meta> tag directing IE8 to render in IE7 mode.  This will allow them to make a small change to support IE8 if their site doesn't look right by default, and then convert their site to standard HTML and CSS on their own schedule.  Users will also have an option to switch to IE7 mode for sites that don't add the meta tag or convert to standards.  When in standards mode, IE8 now passes the ACID2 test.

IE8 also has a new layout engine with the goal of providing developers with predictable layout.  This layout engine has an improved typographic foundation and benefits from having CSS2.1 in hand while being designed - one of the problems with the prior engine.  This clean start is the end of hasLayout.

A few changes are intended to improve performance.  The parallel connection limit is increased from two to six unless the user is on a modem.  Also, there are javascript improvements and the pre-parser doesn't block at script tags.

Finally, there are some improvements to increase developer productivity including better support for web history in Ajax applications, a debugger, a CSS selector API, and HTML 5 storage.

Dynamic Languages @ Microsoft
John Lam, Senior Program Manager for Visual Studio Managed Languages discussed the Dynamic Language Runtime.  In response to his own rhetorical question asking why Microsoft would support dynamic and open source languages on the .NET runtime, he listed the following reasons:
- increased opportunity to get Microsoft technology used
- clear trend to build stuff on OSS
- developers want freedom to create stuff
- developers want freedom to see the source code

The Microsoft Permissive License got changed to Microsoft Public License(MSPL), and got OSI approval.

The Dynamic Language Runtime(DLR) was refactored from the IronPython implementation. Common code and services that were needed for dynamic languages was extracted into a reusable framework.

Because the DLR is distributed as MSPL, anyone can port to other platforms.  So assemblies can run on Mono without changes.

Microsoft is hoping to have Rails running on the DLR by RailsConf 08.  John demoed Django today, but acknowledged having to make a few changes to the Django source to do so.  He also admitted that both IronRuby and IronPython have performance issues right now.

Microsoft Robotics Studio
Tandy Trower and George Chrysanthakopoulos of R&D Advanced Strategies presented on Microsoft's robotics development tools, which include a general concurrency and distributed services solution.  Robotics Studio is a development platform for the robotics community supporting a wide variety of users, hardware, and application scenarios.  The tool is free for non-commercial use and $399 for commercial use.

The tool and technology looked cool, but it was the end of a second long day and I'm not a robotics guy so I don't have much to say about it.  In summary, robots are big, big, big, and Microsoft has an IDE and simulation environment to develop and test robotic control.  If you are into such stuff, it definitely looked like it's worth checking out.

Analysis: When I spoke recently at an IARPA conference in Orlando, and was asked to give a glimpse into Microsoft's vision of R&D trends, one of the possibly surprising areas I highlighted was robotics.  We're making a major push in that area, for reasons that might not be intuitive based on an old-fashioned impression of what Microsoft offers in the government realm.  More on the intelligence community's potential use below.

If you missed Automatica this year, as I did, tough luck - it's only held every two years, so we'll have to wait until June 2010.  The trade-show combines old-school automation and new-wave robotics: "assembly and handling technology, robotics, machine vision and associated technologies, [in] the very first international event that brings together all branches of the robotics and automation industry under the same roof in a single event," according to the agenda.  And the EU took the occasion to announce a new policy to boost European robotics, doubling official EU investments between 2007 and 2010 with almost €400 million to support European robotics research.  The EU plans to foster stronger links between academia and industry, and will fund "widespread experimentation by academic researchers and industry."

The reality is, though, robotics advance is driven less by government top-down investment, and more by the ROI recognized by industry. An Economist article last week ("Nothing to Lose but Their Chains") noted the bottom-line drivers in a report on Automatica:

"Robotic blobs, arms and devices that resemble spiders will pave the way.  A lot more of these are coming to work in offices and homes, and some will do more than one thing... Four trends were on show: robots are rapidly becoming more responsive, cheaper, simpler to program, and safer."

I'm doubly upset I missed Automatica because the event was in Munich this year, one of my favorite cities, which is apparently a central hub of Europe's robotics industry.  Microsoft has an R&D center in Germany and if I had known earlier about Automatica I probably could have contrived a trip to cover it.

Microsoft was not an exhibitor at Automatica this year, but that may change in the next go-round. The change is best described by none other than Bill Gates himself, who wrote the cover story in Scientific American's December 2006 issue ("A Robot in Every Home: The leader of the PC revolution predicts that the next hot field will be robotics").  He described the state of play then: "The challenges facing the robotics industry are similar to those we tackled in computing three decades ago. Robotics companies have no standard operating software that could allow popular application programs to run in a variety of devices. The standardization of robotic processors and other hardware is limited, and very little of the programming code used in one machine can be applied to another. Whenever somebody wants to build a new robot, they usually have to start from square one."

We've begun to address those challenges: check here for the latest release of free downloads of Microsoft Robotics Studio (MSRS), and a more robust Microsoft Robotics Developer Studio 2008, software development kits which simplify the creation of robotic applications using a wide range of programming languages (amateur to complex).  The SDK includes the Visual Simulation Environment, a cool simulation tool that lets robot builders test their applications in a 3D virtual environment before trying them out in the real world.  There are great tutorials and lots of information to spark robotics innovation.

Adoption of Robotics Platforms

Gates described the goal with these SDK's as a parallel to what Microsoft did in its earliest years with BASIC and MS-DOS: "to create an affordable, open platform that allows robot developers to readily integrate hardware and software into their designs."  You can check out Bill's enthusiasm for MSRS in a Q&A session, podcast and video interview with Scientific American Online earlier this year.

There's been some controversy. Gregory Dudek is a prominent blogger on robotics, and professor at the McGill Research Center for Intelligent Machines; he and some others greeted the introduction of the MSRS skeptically at first in 2007, worrying (wrongly) that it would drive out independent platforms and efforts.  See here for a very interesting early post, and note in the comments that Microsoft's Tandy Trower (daddy of MSRS) responds with some thoughtful input.  Well, Dudek seems to have come around and is now actively using MSRS for his own projects on underwater and walking robot systems, winning a Microsoft Human Robot Interaction Award in the process for his Aqua robotic vehicle.

There's a lot of commercial activity using this new platform, with uses as diverse as MySpace (network modeling simulation) and Tyco (facility access modeling). But my Institute is interested in government use (see Information Week story here). 

Right off the bat, as far as the government & public sector goes, there's obvious utility in the education space.  Microsoft Research is a sponsor of the Institute for Personal Robots in Education (IPRE), which applies and evaluates robots as a context for computer science education, a joint effort between the Georgia Tech and Bryn Mawr College's Computer Science Department.  (Their blog had a great compilation of reaction to the Gates article.)  Microsoft also works with education efforts like the Arizona State Robotics Camp for high school students.

Microsoft is also sponsoring work on disaster response with the University of Massachusetts Robotics Lab.  And there's tremendous public-sector use for robotics in health-care: check out the enGadget video of French robotics company Robosoft's newest service robot designed to help the elderly and disabled, a "24-hour monitoring bot, including daily reminders, remote teleconferencing abilities, scaring off of house pets, and alerts if the patient falls or is in trouble."  It was designed virtually in MSRS and uses the software for control.

Intelligence Analysts and Robotics

When I spoke to IARPA's "Incisive Analysis" conference in May, the focus was on better technologies for analyst use.  For example, MSRS allows the use of simulated hardware, physical entities, and included 3D terrain, so the robotics problem space is actually quite relevant to many problems in "an intelligent Intelligence Enterprise." Both at their core are about services and orchestrations. Both share the need to be able to scale both up and down. Robotics simulation allows easy scenarios that would otherwise be difficult or impossible to provide to a broad audience, e.g.:

• a geosynchronous orbit-plane populated by multiple vehicles;
• a city destroyed by a nuclear device or earthquake;
• any indoor facility populated by robotic avatars.

I also pointed out to the IARPA conference that, as a commercial and user-friendly parallel to the famous DARPA Grand Challenge Race for real robot vehicles, Microsoft has launched RoboChamps, a cool simulated robotics league open to academics, hobbyists, and developers from around the world. RoboChamps is built on top of Microsoft Robotics Developer Studio 2008 using the  immersive 3D simulation environments, and the best simulated robot teams can actually win real robots as prizes. It's wild!  An IARPA analogue focusing on analytic uses might be interesting...

If you're interested in wider reading on robotics, for a fairly comprehensive list of resources that will keep you busy for a while check out the Future of Engineering blog's "Future of Robotics - Robots Uses, Trends, Applications" from March 2008, highly recommended.   And the IPRE site is a great central resource for links on robotics news and developments.

Oh - and if you're in the DC Beltway area and want to get elbow-deep in this stuff, check out the Meetup group that's formed for robotics enthusiasts. 

This moment in robotics really does have the spark of the very early days in personal computing software; watch this video of those days, with Jobs and Wozniak and Gates and the like, and you'll get the comparison.

 
Email this post to a friend

le damos clic en el botón “…”

que se encuentra en este bloque de Variables en la parte inferior y nos mostrara un cuadro Defines Variables en donde ingresaremos en nombre de una variable en mi caso le puse Prueba y nos aseguramos de que el tipo de dato sea un int. 

Ahora arrastraremos un bloque de datos (Data) y le ingresamos un valor 1

y también nos aseguramos de elegir su tipo de dato en int ahora vincularemos desde el pin de salida de este bloque de datos hasta el de Variable mostrara un cuadro de Connections en donde le daremos en SetValue ahora aceptamos

Añadiremos un bloque Merge a la derecha del bloque de variables y lo conectamos del bloque de variables al Merge, usaremos este bloque para crear el bucle de conteo, un Merge puede tener múltiples entradas y cada entrada es recepcionada.

Ahora añadiremos a nuestro diagrama un bloque de IF Activity a la derecha del bloque Merge y conectaremos el pin saliente del Merge al entrante del bloque IF Activity, en esta actividad introduciremos Prueba == 10 esto se encargara de comprobar que la variable entrante sea igual a 10

Añadiremos un bloque de Calculate y lo conectaremos al pin Else saliente del bloque IF , esto sesto significa que si la condición no se cumple ira al bloque calcular en donde tomaremos la variable Prueba y le sumamos un 1 a esta misma variable, para así actualizar esta variable

Añadiremos otro bloque de Variable para establecer el nuevo valor que tendrá esta variable así que vinculamos el pin saliente del Bloque Calculate al pin entrante del Bloque Variable se mostrara el cuadro y le daremos en SetValue y aceptar,

ahora conectamos el pin saliente de este Bloque de Variable a el Merge ya que puede recibir múltiples entradas
Bien ahora para probar que la variable Prueba va aumentando su valor en 1 ya que la condición aun no se cumple, añadiremos un Bloque de Servicios en Basic Service buscamos SpeechText y el Bloque de Merge un pin de salida lo conectamos al pin de entrada del Speechtext

nos mostrara una ventana de Connections de damos en SayText y luego seleccionamos la variable que sería Prueba una vez hecho esto añadiremos un Bloque de Data para insertar un texto en el y nos aseguramos de que su tipo de dato sea String y conectamos el pin saliente del Bloque IF al pin entrante del Bloque Data.

Bien ahora añadiremos otro Bloque de SpeechText para que nos diga el texto que escribimos en el Bloque Data enlazamos el Bloque data al SpeechText .

y ahora podremos ejecutar nuestra aplicación con Run en el menú de Edit o F5.

Las conexiones de datos se abre el cuadro de diálogo. En la lista desplegable, seleccione el valor.

Este VPL dice que desea aplicar el valor de los datos de actividad para el texto del mensaje de alerta para la forma de este cuadro de diálogo.
Su diagrama debe ahora ver como la siguiente.

Ahora selecciona Ejecutar el comando Ejecutar en el menú (o presione F5). Si no ha guardado su proyecto, sin embargo, VPL abre el cuadro de diálogo Guardar. Introduzca un nombre para su proyecto y haga clic en Guardar.

VPL ahora procede a ejecutar su aplicación. Si aparece un mensaje preguntando si para desbloquear la aplicación, seleccione Desbloquear.

Lo que debe ver es un simple aviso aparecerá el cuadro de diálogo con el texto, Hello World, en el mismo.

Requisitos de Hardware
Se necesita un robot con microcontrolador y un sensor de contacto. Sensores de contacto suelen ser simples mecanismos que envían una señal cuando entre en contacto físico. El sensor también puede ser la distancia de detención de dispositivos (como los sonares o sensores infrarrojos) que proporcionan una señal binaria simple. Conecte el sensor a su robot en el microcontrolador

Software
Microsoft Visual Programming Language y también se necesitara un navegador como Internet Explorer u otro navegador web convencional.

Añadir una actividad de Data arrastrando una de la caja de herramientas Basic Activities, a la derecha del sensor de actividad de servicios. Seleccionar en la lista que es un String e introduzca el texto que guste.

Paso 2
Conecte el ContacSensor, arrastrando de la ronda de notificación respecto a la actividad ContacSensor, a los datos de actividad.
Si arrastrado desde el punto de conexión correcto, debería ver el cuadro de dialogo de conexión. Elija Update y Create en el cuadro de dialogo de conexiones y haga clic en aceptar.

Esto envía el mensaje de actualización del ContactSensor a la acción Crear los datos de actividad. Si bien los datos de actividad no utilizan los datos procedentes de ContactSensor, usa el mensaje para activar la creación de los datos (“TEXTO”) que ha introducido.

Paso 3
Ahora arrasa un Simple Dialog de la ventana de Service y el dataflow en el lugar derecho del bloque de datos. Conecte las dos actividades. En el cuadro de dialogo las Conexiones se Abren, seleccione Value y AlertDialog a continuación, haga clic en aceptar.
En Data Connections cuadro de dialog, seleccione el Value como valor que se enviara a los destinatarios del mensaje. Esto significa que el texto “TEXTO” se envía el mensaje como texto de la descripción de la forma simple de dialogo

Paso 4
El ContactSensor actividad representa un servicio genérico que se puede aplicar a un contacto de sensores para diferentes robots. Antes de poder ejecutar su solicitud, tiene que decirle VPL sensor que desea utilizar.
Haga clic derecho en el bloque ContactSensor actividad para abrir su contexto emergente. Seleccione el conjunto de comandos de configuración. En el cuadro de dialogo que aparece, en virtud del conjunto de configuración, seleccione utilizar manifiesto. En caso de que no se manifiestan aparece en la lista, seleccione Manifiesto de importación y elija el manifiesto para el sensor que está utilizando, y de clic en aceptar también puede seleccionar un manifiesto de simulación, el manifiesto debe ser seleccionado en la lista desplegable.

Paso 5
Ejecute su aplicación seleccionando e comando Start del menú Run o pulsando F5

Lenguaje de Programación Visual ( VPL - Visual Programming Language) es un entorno de desarrollo de aplicaciones diseñada sobre una grafica de flujo de datos basado en modelo de programación en lugar de controlar el flujo normalmente se encuentran en la programación convencional, en lugar de imperativas series de comandos ejecutados secuencialmente.
Un flujo de datos se parece a una serie de trabajadores, que están esperando a que lleguen sus materiales para que empiecen a realizar sus tareas asignadas), Como resultado tenemos a VPL el cual se adecua perfectamente a una gran variedad de programación concurrente o de procesamiento distribuidos

VPL Está destinada a los principiantes en la programación los que tienen una compresión básica de conceptos como variables y la lógica.

Los programadores más avanzados pueden hacer uso de sus prototipos y desarrollar código de manera más rápida, además mientras en la caja de herramientas se ajusta al desarrollo de aplicaciones de robot, la arquitectura no se limita a la programación de robots y podría aplicarse a otras aplicaciones también. Como resultado de ello VPL puede apelar a una amplia audiencia de usuarios entre ellos estudiantes, entusiastas y aficionados, así como posiblemente los desarrolladores web y programadores profesionales

Un flujo de datos consiste en una secuencia conectada de las actividades representadas como bloques con entradas y salidas que se pueden conectar a otros bloques de actividad.

Las actividades pueden incluir también las composiciones de otras actividades esto hace posible la reutilización de componentes de actividades y la composición de un edificio en bloque. En este sentido, una aplicación construida en VPL es en sí misma una actividad

Bloques de actividades suelen incluir el nombre de la actividad y las fronteras que representan sus puntos de conexión. Una actividad en Bloque también puede incluir gráficos para ilustrar el propósito de la actividad, así como elementos de interfaz de usuario que pueden permitir que el usuario introduzca los valores, las cesiones, o transformaciones de datos utilizados en una actividad

Las actividades están conectadas a través de su conexión pins, una conexión pin en el lado izquierdo de una actividad que representa el punto de conexión para los mensajes de entrada y el pin del otro lado representa el punto de conexión para la salida de mensajes.

Una actividad recibe mensajes que contengan los datos a través de su conexión de los pines de entrada. Una actividad de los pines de entrada son puntos de conexión a sus funciones predefinidas inferior conocido como acciones o manipuladores (que puede ser o bien como funciones que ofrece un servicio o anidadas de datos corrientes)

Una actividad bloque se activa y procesa los mensajes de datos tan pronto reciba una valida mensaje entrante. Todos Los datos enviados a la actividad es consumida por la actividad. Por los datos que se transmitirá a través de la actividad de producción, recepción de la actividad debe replicar los datos y ponerla en su producción respecto.

Una actividad puede tener múltiples clavijas de conexión de entrada y cada una de ellas con su propio conjunto de patillas de conexión de salida. Patillas de conexión de salida puede ser uno de los tipos: un resultado de salida o una notificación de salida (a veces también a que se refiere como un evento o publicación de salida). Resultados productos se muestran como patillas de conexión rectangular, mientras que los productos de publicación rondan clavijas de conexión

Una respuesta de pines de Salida se utiliza en situaciones en que un mensaje saliente (Datos) es enviada como resultado de una acción específica de mensajes entrantes, Los pines de notificación pueden enviar información resultante de un mensaje entrante, pero más típicamente un mensaje como el de un cambio de su estado interno. También pueden generar mensajes varias veces, mientras que un pin de resultado solo envía un solo mensaje en la recepción de un mensaje entrante. Por lo tanto, los pines de salida de notificación se utilizan para el envió de mensajes de datos sin tener que solicitar en varias ocasiones o encuestas para el estado de una actividad.

Ya puedes empezar a usar el VPL desde Menú Inicio en “Microsoft Robotics Studio”.

Microsoft Robotics Visual 1.5

Day 1

I got my Phidgets components in the mail, and went right to work assembling my pan-tilt camera mount, controlled with two servos from a controller board, and connected to my laptop from there by a USB cable.  A tiny allen wrench was included, but not a phillips screwdriver, which you will also need.  You can see the components assembled and connected in the picture below.

The black thing in the back right corner is just a USB hub.  This is connected to (on the right) an 8/8/8 controller (with lots of room for more components to plug in), and then to the mini joystick.  The other USB connector plugs into a 4-servo controller, and then to the dual servos in the pan-tilt assembly in the back left of the picture.

On the software side, using the Phidgets .NET API was very easy.  Just instantiate a Servo object, provide an event handler to run when a device is attached, and from there I was able to set each servo position or read the position back.  The only confusing part was realizing that the servo controller board is represented by the Servo class, and the individual servos plugged into that controller are represented by the ServoServo class.  (Was this API written in Bora Bora, perhaps?)  I would have named them ServoController and Servo, respectively, but I got over it and moved on.

What you see visualized in the test application (see screenshot below) is a coordinate graph custom control that displays the position of both servos.  When I hooked up the mini joystick, I made the mistake of mapping the joystick position to the graph, but then realized that my graph would be useless unless I was controlling everything with the joystick.  I wanted to script out servo movements and replay the sequences and still have their position represented in the coordinate graph control, so I made that update (and ever since have been unable to calibrate the system to center itself).

Hooking up the hardware took only 15 minutes, and most of the application involving the Phidgets API took an hour or two at the most, but I spent the rest of the day creating the custom graph control and getting it to translate coordinate systems correctly.  The joystick maps values from 0 to 1000 along each axis, the servos have a servo position range of -22 to 232 on one axis and something close to that on the other, and the graph control was 150 pixels wide.  I made it general enough to work with any coordinate ranges on both axes.

First Impressions

I have to say that it's really cool to see physical objects interacting with software that you write yourself.  (It reminds me of fun I had with a hydraulic robotic arm I programmed in high school using an Apple 2c and low-level calls to the parallel port, but this is way more powerful).  The bridgeware components are easy to connect, and the APIs are a breeze to use.  Building the intelligence between inputs and outputs, however, is the really fun and challenging part.  Even though this initial experiement was simple, I can already tell that coordinating a much more complicated set of inputs and outputs will require careful planning and the use of tools such as Microsoft Robotics Studio, which include the Concurrency & Coordination Runtime and Decentralized Software Services Protocol.

Now that I've gotten my feet wet and have some confidence that I can build, connect, and interface with these components (and have a box full of other goodies like 3-axis accelerometers, light and temperature sensors, sliders, buttons, and switches), I have a bunch of ideas for at least one cool summer project that I hope to announce in the next month or two.

Port-Based Messaging

Port-based messaging has been in practice for a long time.  In the realm of low-level electronics, components have always been operating in parallel, hardware interface ports are designed around standards, and messages are posted to those ports, queuing up somewhere until the receiver is ready to process them.  This pattern has worked extremely well in multiple domains for a long time, and its key characteristic is the decoupling of data flow from control flow.

In sequential programs, one statement runs after another each time it’s run, and the behavior is predictable and repeatable. Concurrency is difficult because you have to consider all possible interleavings of multiple simultaneous tasks, so the overall behavior is nondeterministic. Depending on the relative timings of concurrent tasks, you could get different results each time if you’re not careful to set the appropriate locks on shared resources.  Port-based messaging architectures isolate islands of state across different execution contexts, and connect them with safe, atomic messages delivered through pre-defined ports.

The posting of a message to a port, as shown in Figure 1, is followed by some handler method that is receiving and processing messages.  What's not evident in the diagram, however, is that while data flows into the port, that posting is a non-blocking call.  The sender continues on doing other work, taking the time only to queue up a message somewhere.

Queuing is important because, even with large thread pools, we can't guaranty that a receiver will be listening at the very moment a message arrives.  Letting them queue up means the receiver doesn't have to block on a thread to wait.  Instead, the data waits and the thread checks messages on the port when it can.

What is a Port?

So what exactly is a port?  A port is a communication end point, but not in the sense of "a web service on a physical server".  Think much more fine grained than that, even more fine-grained than methods.  With sequential programming, we commonly use try-catch blocks and handle both the exceptional and non-exceptional results of operations within a single method.  In port-based programming, you post a message to a port, which results in some handler method running on the receiving end, and different results can be sent back on different callback ports depending on the type of message.  Instead of calling a method that returns back to you when it ends, port-based programming is about always moving forward, and unwinding a call stack has very little meaning here.

We can see in the sequence diagram above (Figure 3) a collection of services that communicate with and depend on each other.  Starting from the top, the left-most service posts a message to port 1, and then goes on to do other work or surrenders its thread back to the dispatcher for other tasks that are waiting to run.  A registered method on port 1 runs, and the logic there needs another service to complete it's task, so it posts a message on port 2, and also continues processing without waiting.  The path of solid blue arrow lines traces the message path for normal execution.  If anything goes wrong, an exception can be posted to a different callback port, shown with a red outline in the diagram.

This diagram shows one possible composition of services and data flow.  Port sets, which are simply a collection of related ports, are shown as callback receivers in pairs, but they can consist of any number of ports with any mixture of messages types, depending on the needs of the system being coordinated.  In this example, if anything goes wrong in the handler methods at ports 2, 5, or 6, an exception message will be routed to port 6, where another handler method can compensate for or report on the error.  Also note that while during startup this system may have to process data at port 4 before the logic at ports 5, 7, and 8 can run... once it gets going, there could be activity operating at many ports concurrently (not just one port per service).

Arbiters, Dispatchers, and DispatcherQueues

Now it's time to peel away some of the layers of simplification presented so far.  (It may help to have a beer or glass of wine at this point.)

An arbiter is a rule (or set of rules) about when and how to process messages for a specific port (or set of ports).  (It is helpful to think of arbiter as a data flow or message flow coordinator.)  Should messages be pulled off the queue as soon as they arrive?  Should the software wait until 5 messages have arrived before processing them all as a group?  Should messages be checked according to a timer firing every 20 seconds?  Should logic be run only when two ports have messages waiting (a join)?  What logic should be run when one of these conditions occurs?  Can method handlers on three specific ports run concurrently until a message arrives on a fourth port, whose handler must run exclusively, and when done the other three can run again (interleave)?  These are just a few of the many coordination patterns that can be expressed with different types of arbiters (and hierarchically nested arbiters, which are ingenious).

Figure 4 illustrates that an arbiter is associated with a port to monitor and a method to execute under the right conditions.  The logic of the arbiter, depending on its type and configuration, determines whether to handle the message.  It gets its thread from a thread dispatcher, which contains a thread pool.  (Not the same as System.Threading.ThreadPool, though, as there can only be one of those per process.)

The next diagram (figure 5) could represent a join coordination.  An arbiter waits for messages on two ports, and depending on how it's defined, it may process messages from one port repeatedly, but as soon as it receives a message on the second port (it may be an exception port, for example), the whole arbiter might tear itself down so that no more handling on those port will occur.  As you are probably starting to see, composition and attachment of arbiters are key to controlling specific patterns of coordination in arbitrarily powerful and flexible ways.

In the Concurrency & Coordination Runtime, we can attach and detach these arbiters during runtime; we don't have to define them statically at compile time.  There has been some criticism towards this approach because dynamic arbitration rules are much more difficult to verify formally with analysis, and are therefore difficult to optimize compilation and thread management for, but the advantages of this flexibility are enormous and the performance (see this paper by Chrystanthakopoulos and Singh) has been very impressive compared to conventional multithreading approaches.  Ultimately, it's not about whether we can guaranty 100% that nothing will go wrong using only the mathematical models currently in our repertoire, but whether we can be productive with these techniques to release software that meets acceptable quality standards across a broad range of application domains.

I don't think we're going to find a better set of strategies to work with anytime soon, and when we've pushed this technology hard enough, the tactics will be fine tuned and we can start absorbing some of these coordination concepts into languages themselves (without sacrificing the dynamism that a library of composable parts provides).  People are going to attempt concurrent programming whether it's safe or not, and using a library such as the CCR significantly reduces the risk of ad hoc multi-threading code.

Cooperative Multitasking

When mainstream operating systems like Windows took their first steps to support multi-tasking, cooperative versus preemptive multi-tasking was a common topic.  The idea of an operating system depending on applications to surrender control in a well-behaved way was generally and rightfully considered a bad idea.  Any kind of error or instability in software could easily bring down the entire operating system, and enforcing a quickly growing community of software vendors to share nicely wasn't a realistic option.  Being preemptive meant that the OS could forcefully stop an application from running after giving it a small, measured slice of time, and then switch the thread to a new context where another application could run for another time slice.  Regardless of how poorly applications ran, as benevolent dictator, the OS could ensure a fair scheduling of processor time.

The solution encapsulated in the Concurrency & Coordination Runtime is, on the other hand, a cooperative multi-tasking strategy.  However, because it operates within the local scope of an individual process, and is isolated from other processes in the same OS, its risk of destabilizing the system is nonexistent.  This deep level of cooperation, in fact, is what gives the CCR its great performance.  When used correctly, which George Chrysanthakopoulos (in this video) and his colleagues have brilliantly put within our reach in the CCR library, threads don't sit around waiting on some resource or for long-running operations to complete; instead, control is freely surrendered back to the thread pool, where it is quickly assigned to a new task.

Finally, by surrendering threads freely instead of holding onto them, a continuous flow of threads through the different activities of the system is maintained, and there is therefore always an abundance of them to handle new messages waiting on ports.  Existing threads are not wasted.  As the Tao Te Ching says:

If you want to accord with the Tao,
just do your job, then let go.

Control & Data Flow: Sequential vs. Concurrent

In sequential programs, stacks are used to unwind method calls and provide return values (return messages), and threads follow the data flow; whereas in port-based programming, threads are managed by one or more thread dispatchers that are capable of maximizing the use of that thread by making it available in a pool and sharing it with with many other (potentially unrelated) tasks.  Data flows orthogonally and according to a different coordination strategy than control flow.  This task-thread agnosticism (the opposite of thread-affinity) is similar to the statelessness of a web server such as IIS; one or more threads from a large pool are injected into the tasks of processing, rendering, and serving up huge numbers of web pages, after which those threads are recycled back into the thread pool for execution of other tasks for a highly concurrent and scalable service platform.

So herein lies the trick: in order to split this coupling between data flow and control flow, a different means is needed to compose the two coordination strategies.  In C# and other popular imperative programming languages, methods implicitly pass thread control along with data arguments (the message), and the use of the stack for method calls asserts constraints on control flow, so making the CCR work involves some interesting patterns.

That's why port-based programming is hard to get your head around.  It's such a large shift from common sequential logic and it requires some additional planning (and good visualizations).  It's obviously important to have a good set of tools for expressing that coordination, a simple set of conceptual primitives that allows us to compose arbitrarily-complex coordination patterns.  These primitives, including Message, Port, PortSet, Dispatcher (thread pool), and others provide the building blocks that we can use to define these relationships.  Once we define what we want to happen with these building blocks, the CCR can make it all happen.

This level of coordination is a level beyond the strategies used by most concurrent applications and frameworks in software today, primarily because there hasn't been a pressing need for it until recently--processors had been growing phenomenally in speed for many years.  Now, however, we're told that processor speed has plateaued, that we now have to scale out to scale up, spreading the processing load across multiple cores.  We are very fortunate that the work being done by researchers in fields like robotics can be applied in other service oriented architectures, and is a testament to the widespread use of the .NET Framework and the fantastic efforts of some very bright individuals.

Where to Find Microsoft Robotics Studio

Robotics Studio is a free download and can be found here, and while it is full of other good stuff, it's worth checking out for the Concurrency and Coordination Runtime alone.

I've been watching videos like this, reading about the Micro Framework for the past few months, have pre-ordered this book from Amazon, and have been itching to get my hands on a hardware development kit to start experimenting.  The only problem is that the interfaces for these embedded devices are so foreign to me (I2C, GPIO, etc.), and I'm not exactly sure what my options are for assembling components.  What kinds of sensors are available?  Do I have to solder these pieces together or is there a nice modular plug system similar to the SATA, IDE, and PCI connectors on modern computers (but on a smaller scale)?  Do I have to write my own device drivers for anything I plug in, or is there some abstraction layer for certain classes of inputs and outputs?

The other issue that makes me hesitate is the thought of programming without language conveniences like generics on a more resource-constrained device than the Windows Mobile devices I'm already frustrated with (and have been for the past four years).

I'm not saying that I'm not excited about managed code on tiny embedded devices, and I'm not saying I won't start playing with (and blogging about) this important technology sometime in the next few months, but I've discovered another platform for embedded device development with the ability to interact directly with the physical world that offers a much lower technical barrier for entry, so that's where I'm starting.

What I'm referring to is Microsoft Robotics Studio, which is by all accounts a phenomenal platform for more than just robotics, and seems to overlap somewhat with the Micro Framework's reach (at the intersection of the computer-digital and physical-analog worlds).  The two critical components of this architecture are the Decentralized Software Services Protocol (DSSP, originally named WSAP) and the Concurrency & Coordination Runtime (CCR).  Make sure you watch this video on the CCR, and note how George emphasizes that "it's not about concurrency, it's about coordination", which I found especially enlightening.  These are highly robust and general purpose libraries, and both of them will run on Compact Framework!  (I was very impressed when I read this.)

Without having studied them both in depth yet, the CCR seems to cannibalize on the Task Parallel Library (TPL), at least conceptually, offering a much more complete system of thread manipulation and synchronization than the original System.Threading types, all for a vertical industry that has much greater demands of a concurrency framework that must, for example, deliver massive concurrency and complex coordination rules in a highly-distributed system, all the while handling full and partial failures gracefully.  Some of the patterns and idioms for making concurrency and synchronization operations easy to write and understand are masterfully designed by Henrik Nielsen and George Chrysanthakopoulos (and I thought Vanderboom was a long name!).

The fact that the CCR and DSSP were developed together is significant.  Tasks running in parallel need to be manipulated, coordinated, and tracked regardless of whether they're running on four processors in one computer or on 256 processors spread across a hundred devices, and distributed services need a dependable way of parallelizing their efforts on individual machines.  This is a synergistic relationship, each subsystem enhancing the elegance and usefulness of the other.  So why not use the CCR in every application instead of developing the TPL?  Are these two teams actively collaborating, or have they been building the two frameworks in isolation?

I also have to make special mention of the decentralized software services, which as a protocol sits on top of HTTP in a RESTful implementation.  It supports composition of services by creating partnerships with other services, defining securely which partnerships are allowed, offering identification and discovery of services, and much more.  In this assembly then, we have a robust library for building distributed, composable, decentralized services-oriented systems with event publication and subscription, with services that can be hosted on desktop and mobile computers alike.  Wow, call me a geek, but that's really frickin' cool!  Some of the ideas I have for future projects require this kind of architectural platform, and I've been casually designing bits and pieces of such a system (and got so far as getting the communication subsystem working in CF).  Now, however, I might be turning my attention to seeing if I can't use the Robotics Studio APIs instead.

One thing to be clear about is that Robotics Studio doesn't support Micro Framework, at least not yet.  I wonder exactly how much value there would be to adding this support.  With hardware options such as this 2.6" x 2.3" motherboard with a 1.6 GHz Intel Atom processor, video support, and up to 1 GB of RAM, capable of running Windows XP or XP Embedded, and priced at $95 (or a 1.1 GHz version for $45), we're already at a small enough form factor and scale for virtually any autonomous or semi-autonomous robotics (or general embedded) applications.  There's also the possibility for one or more Micro Framework devices to exchange messages with a hardware module that is supported in Robotics Studio, such as the tiny board just mentioned.

Where do we go next?  For me, I just couldn't resist jumping in with both feet, so I ordered about $500 in robotics gear from Phidgets: USB interface boards, light and tempature sensors, a 3-axis accelerometer (think Wii controller), motors and servos, an RFID reader with tags, LEDs, buttons, knobs, sliders, switches, and more.  I plan to use some of this for projects at CarSpot, and the rest simply to be creative with and have fun.  I also pre-ordered this book, but the publication date is set for June 10th, so by the time I get it, I may have already figured most of it out.

Pratiquement chaque mois, et ce depuis juin 2006, Microsoft a sorti une nouvelle version de leur "Robotics Studio" (MRS). Avec la dernière version en date (l’article est d’octobre), par sa base de code stable cette quatrième version donne l’impression d’un futur prometteur.

Une application MRS est un ensemble de services executés dans un ou plusieurs noeuds afin de s’échanger des messages entre eux, permettant ainsi d’avoir le comportement que l’on souhaite donner au robot. Ces services se transmettent l’information via divers webservices que l’on appelle Web Services Application Protocol (WSAP).

Une machine peut contenir plusieurs noeuds et ainsi plusieurs services d’un même noeud peuvent communiquer à la fois entre eux, avec les services d’autres noeuds de la même machine ou bien encore avec les services de noeuds appartenant à une autre machine.

Chaque service se voit attribué son propre état. Un soin particulier à été apporté ainf de différencier les actions qui iront modifier cet état des autres.

Avec .NET on peut arriver à échanger ce type de message, bien que cela n’ait été fait dans aucun langage du framework. Pourtant cette possibilité est testée pour être incluse dans MRS au niveau du CLI(Common Language Runtime).

Sous le nom de CCR (Coordination and Concurrency Runtime), un tel envirronement peut paraître confus pour ceux qui ne connaissent pas les architectures web orientées services. L’architecture du CCR et les extensions de langages qui y sont liées, sont basés sur certaines fonctionnalitées du framework .net2, comme par exemple les types génériques et les itérateurs. Le CCR va même plus loin en vous permettant des itérations au travers de blocks utilisant le constructeur ’yield return’.

D’autre part la notion de port est fondamentale pour la compréhension du CCR. Les ports représentent des files d’attente (des queues) gérant un certain type de données qui doivent leur être transmis, ils conservent également une liste de handlers qui seront appellés lorsque ce type de donnée sera reçu.

e.g.

// Create a port : Port<DateTime> _timerPort = new Port<DateTime>() ;

// Define the handler : void TimerHandler(DateTime signal) // do something

// Activate the handler : Activate(Arbiter.Receive(true, _timePort, TimerHandler)) ;

A partir de cette définition, lorsque vous souhaitez faire apparaitre un évenement, postez un message avec un type DateTime.

_timerPort.Post(DateTime.Now) ;

L’exemple ci-dessus n’est pas à proprement utile, mais la technique utilisée peut servir avec des ports supportant plusieurs types et plusieurs handlers.

Vous avez la possibilité d’associer des recepteur qui attendront un ou plusieurs messages, facilement mettre en oeuvre des modèles fournis, créer des conditions depuis les sorties des ports, etc. Ensuite, vous pouvez affecter certains services à un port afin qu’ils puissent recevoir un message de ce dernier. Cela peut être utile dans l’utilisation de données provenant d’un sonar(des capteurs à ultrason par exemple) et faire une carte des environs, mais aussi l’utiliser comme un "butoir" (capteur de butée). Toutefois, attention : avec une carte topologique lourde et inflexible, sachez que votre service butoir traitera quand-même les messages de ce service.

Si vous avez déjà tenté d’écrire une application par procédures ou par threads vous savez alors qu’il est difficile de coordonner toutes les activitées inhérentes au robot quand il tente d’avancer pendant qu’il teste des encodeurs tout en scrutant des capteurs à ultrasons, capteurs de butée, créer la carte, etc....

Par exemple :

Le capteur à ultrasons SRF235 de Devantech a une interface I2C et retourne des données de l’ordre du centimètre.Vous pouvez donc interfacer votre PC vers un bus I2C en utilisant le module USBI2C de chez Devantech pour un prix trés abordable, ou alors la version combinée sans fil RF03/CM02.

Par conséquent, une application à base de microcontrolleur utilisera une boucle pour lire les 2 octets de données de distance envirron toutes les 100mS.

En prennant cet example, mais cette fois avec MRS, on utilisera plutôt (pas le chien) un service qui scrute le sonar afin de mettre tout seul à jour les données de distance. L’état peut alors être lu par un autre service en utilisant la commande GET, ou si le service est configuré par le biais de souscriptions (comprendre : l’abonnement à ce service) tous les services abonnés recevront un message de mise à jour des nouvelles données reçues (principe du message passing).

L’état peut être sérialisé au traver d’un butineur internet en tant que donnée XML :

Raw XML of the SRF235

Raw XML of the SRF235

en utilisant les feuilles de style XSLT, on peut transformer des données XML en une page HTML.

Vous pouvez alors créer des instances depuis des modèles génériques comme Sonar ou SonarAsBumper pour vous inscrire à un sonar spécifique dont les données seront utilisées par le service d’un autre hardware.

Pour un tronche pensant microcontrolleur (texto, NTDR) tout ceci pourrait passer pour une perte de temps. Pourquoi XML ? pourquoi un OS ? pas de temps réèl ? fichtre, diantre !

Pourtant, les PC deviennent de plus en plus rapides et en même temps bon marchée, les CCR sont capable de traiter à peu près 90000 messages soap en une seconde sur une machine multiprocesseurs.

Prendre les modèles génériques de services permet de réutiliser la logique d’une appli pour une autre, peut importe si c’est un Pioneer avec télémètre laser ou un LEGO NXT.

La communication inter-noeuds utilise le PC comme le cerveau avec une webcam pour reconnaitre les objets envirronants pendant qu’il continuera de traiter une boucle PID. Vous pouvez même télécharger un flux météo pendant ce temps et ordonner à votre robot de rentrer à la maison si la pluie est annoncée.

MS à ajouté des extension pour des moteurs à deux roues, des webcams, conversion texte vers voix, sonars, capteurs à contacts, etc .... . Ces services génériques donne lieu à l’une des plus puissante possibilités de MRS pour ensuite le relier avec le moteur de physique AGEA, vous pouvez ainsi envoyer votre robot virtuel dans un labyrinthe avec de vraies contraintes physiques et ainsi tester vos capteurs de contact et surtout la cohérence de votre code avec la webcam simulée.

Pour un rapide aperçu d’un programme crée à partir d’un service, regarder l’exemple Say Fire

C’est tout pour l’instant.Il y a plus de documentation sur le site de Microsoft, avec de bonnes vidéos montrant comment utiliser un CCR, au-delà de la robotique type wiki canal 9.

video du CCR : http://channel9.msdn.com/ShowPost.a...

CCR : http://channel9.msdn.com/wiki/defau...

video MRS : http://channel9.msdn.com/Showpost.a...

MRS d’octobre : http://msdn.microsoft.com/robotics/...

Chips Devantech : http://www.robot-electronics.co.uk/...

Amusez-vous bien !

RobotTurk is a prototype Unmanned Aerial Vehicles (UAV) equipped with a camera that is capable of streaming live video of disaster struck areas to ground command stations. The helicopter carries onboard an eBox compute-unit that runs Microsoft Robotics Studio, allowing the robot to execute specific command issued by ground statation or to auto-fly or safely land. The ground stations utilizes Windows Server 2008 Media Services that capture, process and streams video. The disaster coordination users utilizes Microsoft Virtual Earth as a mapping tool and Silverlight streaming to show the overlaid video on the maps.

With Microsoft Virtual Earth as the mapping tool, users can select a new destination, add a new mission, and track the helicopter’s current position on the map. Images of the site are streamed using Silverlight.

The Microsoft Virtual Earth map on the right shows the actual position of the robot as well as additional flight data. Hosted on Windows Server 2008, the Web site uses Silverlight to stream the incoming images.

We currently have a prototype and most of the ground station and automous flight tasks have been implemented. The high-level architecture of the system is as follows:

http://RobotTurk.eu

To learn more about the kit, free downloads, documentation and tutorials, check out the Boe-Bot Kit for Microsoft Robotics Studio product page.

To learn more about Microsoft Robotics Studio, go to the Microsoft Robotics Studio page.

The Boe-Bot Kit Microsoft Robotics Studio

This kit’s hardware includes our popular Boe-Bot robot full kit and the eb500 Bluetooth module, making it possible for the Boe-Bot robot to communicate with a PC’s Bluetooth radio. All the software you’ll use with the kit is available for free download, including the following:

• The Parallax BASIC Stamp Editor
• PBASIC example programs for the Boe-Bot robot
• The latest Microsoft Robotics Studio Community Technical Preview (CTP) release
• Microsoft programming languages such as Microsoft Visual C# and VB.Net.

The kit’s documentation and example code provide tutorials and demonstrations that use a Microsoft Robotics Studio “service” to control the Boe-Bot robot. They also demonstrate how to manipulate the Boe-Bot robot’s PBASIC and the PC’s C# code for PC programmed wireless Boe-Bot robot monitoring and control. After that, you’ll be ready to tackle Microsoft’s tutorials, which show how to leverage the Robotic Studio’s BASIC Stamp 2 services for PC navigation based on sensor inputs as well as GUI development.

Check out the Boe-Bot Kit for Microsoft Robotics Studio.
For additional assistance with the Robotics Studio hardware contact us.

About Microsoft Robotics Studio

Microsoft Robotics Studio provides an end-to-end robotics development environment for hobbyist, academic, and commercial robotic developers. Microsoft Robotics Studio is a Windows-based environment that offers the following key features and benefits:

End-to-End Robotics Development Platform: Microsoft Robotics Studio enables developers to generate modular services for hardware and software, allowing users to interact with robots through Windows-based or Web interfaces. Developers can also simulate robotic applications using realistic 3D models with AGEIA™ PhysX™ Technology. AGEIA™ is a pioneer in hardware-accelerated physics, enabling real-world physics simulations with robot models. Simulations can be accelerated through hardware acceleration using the AGEIA™ PhysX™ processor (Available in PhysX™ Accelerator add-in cards for PCs).Lightweight services-oriented runtime: Microsoft Robotics Studio provides a lightweight service-oriented runtime. Using a .NET-based concurrency library, it makes asynchronous and distributed application development simple. The service-oriented message-based architecture makes it possible to realization of highly complex applications through the composition and orchestration of simpler services.

Scalable and extensible platform: Microsoft Robotics Studio programming model can be applied for a variety of robot hardware platforms, enabling users to transfer their learning skills across platforms. Third-parties can also extend the functionality of the platform by providing additional libraries and services. Both remote (PC-based) and robot-based (autonomous) execution scenarios can be realized using a selection of programming languages, including those included in Microsoft Visual Studio and Microsoft Visual Studio Express languages (C# and VB.NET), as well as Jscript and Micro