Robotics Studio 2010+ RRS feed

  • General discussion

  • Does anyone have any information on what if anything Microsoft is planning roadmap wise in terms of Microsoft Robotics Studio in the future?  Any plans for a MSRS 2010?

    I think there is plenty of room for Microsoft to make the tool:
    -Easier to use with more wizards, tutorial movies, a single application to start when launching MSRS, etc...
    -More powerful with more tools for machine vision, SLAM, etc...
    -Better support for already supported robots, easier ways to configure it for custom robots, etc...
    Sunday, January 31, 2010 11:42 PM

All replies

  • Thanks for your feedback.

    I can't comment officially on future releases. There will be another minor release this year, but a major release is still some time away.

    I'm not quite sure what you mean by "a single application to start". Mostly you run DssHost with a manifest and that's it. Alternatively you run VPL and launch the app from in there. They are different approaches, but still only a single executable in either case.

    You can do machine vision right now using RoboRealm which has an RDS service interface. You can also use OpenCV via one of the .NET wrappers that are available as open source.

    I understand about more documentation, wizards, easier config. We're working on it :-)

    Wednesday, February 3, 2010 2:38 AM
  • Hi Trevor,

    In terms of a "Single Application to Start" we currently have a number of executables in the Application Folder:

    DSS Command Prompt
    DSS Manifest Editor 2008
    Run DSS Node
    Visual Programming Language 2008

    The newbie asks him or herself, "Which of these do I start with?  Am I missing the Robotics Studio executable?"

    To add to this, these aren't the only executables one must launch to work in MSRS, one must also launch Visual Studio to develop services and such.  Anyone with time and patience can begin to sort this out as they go through the tutorials, but I think there is room for improvement in making this more intuitive.  When I think of making something intuitive my goal is to only have the user ask themselves questions when they need to make a creative decision, otherwise the process should be obvious and serial (i.e. clicking the "Next" button).

    For instance let's consider Visual Studio itself, an extremely powerful Suite for development.  One can use a whole host of languages to develop all kinds of libraries, applications, services, websites, classes, etc...  With all these variables and choices, one would expect Visual Studio to have many executables for one to manage depending on their objective.  But instead of overwhelming the user, Microsoft has managed to pull this all into one well designed executable (although yes, it probably does launch more than one exe, but what I'm trying to get at is how transparent this is to the user) complete with a start page and synergy between all the tools needed to create one's project (creating forms, writing code, debugging... it's all there).  One can do forms / GUI work in one tab and be taken right to their code in another by double clicking on controls.  In addition, all documentation and help can be accessed from within the visual studio application.  I find it makes it easier to understand how all the pieces fit together and keeps the UI familiar.

    With regard to wizards and easier configuration, I have a lot of ideas.  I envision the MSRS Application would make it easier for the user to define their hardware (even if they intend to use simulations) in the form of a profile.  So somewhere in the interface one would have a window that says the name of the profile  (aka target hardware) with the options for "New..." "Open..." & "Edit...", this may also be a convenient place to show a hardware tree.  Perhaps this could have some similarities to how one selects a target microcontroller in an environment like AVR Studio.  One could import a profile that has already been created for their robot and edit it or create a new one via a wizard like tool.  Inside the tool one could select their CPU / Microcontroller from a dropdown, then the wizard would list the I/O ports, next the user could define what sensors are connected to each from drop downs (of course anything that isn't available in the drop down could be created with a little more work), but hopefully you begin to get the idea.  In additional there should be tools for one to define the geometry and orientation of their sensors graphically in 3 space, even if the tool for modeling has to be crude.  I have a bit of experience in GUI design (designed the GUI for Rapster one of two Mac OS Napster clients, no longer in use), so perhaps it would help for me to lay out a mock application in VS to make this a little clearer if there is interest.

    In any case I believe in this way one could tailor the environment to their hardware up front and in VPL for instance, drag pre-configured hardware from the tree into their diagram rather than from a list of services, many of which will be inapplicable to or unconfigured for the users project.

    Another thought is adding a button next to "Start" for "Start in Simulation Environment", another opportunity to bring these pieces into tighter integration.

    Like what I've said before, what exists today is a great start, but there is a lot of room for improvement or in some cases some light reorganization of what's already there.  Perhaps I'm being a little premature in my critique of MSRS as I still have plenty of tutorials left and of course your book to read (on it's way), but wanted to start putting some ideas on the table sooner than later given the time it takes for development when resources are limited.

    Sunday, February 21, 2010 4:05 AM
  • Hi,

    Thanks for the feedback. I understand better what you are looking for now.


    Monday, February 22, 2010 5:55 AM
  • One more note, to elaborate on my recommendation to integrate all the necessary Robotics Studio development tools under one roof; one of the biggest questions is how would one integrate the Visual Studio IDE in Robotics Studio for instance.

    One area where Microsoft has done a decent job of taking the power of one application and integrated it into another already is with Word in Outlook.  If this worked the way Robotics Studio does today, one would have to launch Word separately ,  compose their e-mail in there - then close out of word and import it in Outlook.  No fun there.  Luckily the power of Word (most of it at least) is launched when one composes a new e-mail (assuming they have it configured to work as such).

    Just a thought, where we can leverage an existing solution with a track record, rather than reinventing the wheel.  As for the global template errors one frequently gets with this integration, let's leave that to another discussion.



    Sunday, March 28, 2010 6:25 PM
  • It would be nice to see MSRS baked into .NET.  Something like Windows 7 Sensors.  At the end of the day, learning MSRS, getting everything installed and running correctly, is not worth the effort.  Writing a program to access a com port directly to talk to a robot is much easier than trying to use MSRS.   Exposing devices as webservices is the right thing to do.  I applaud MSRS for doing so.  It just needs to be built into the operating system, make DSS like IIS.

    Tuesday, May 4, 2010 2:43 AM
  • Thank you for your feedback.

    Integration at that level is a long-term process. We are continuing to work towards CCR being incorporated into .NET.

    Windows Sensors are local APIs, i.e. they do not work in a distributed environment like DSS services can, and the supporting drivers have to be provided by the hardware vendor. The APIs are conceptually similar to generic contracts in DSS which define how to talk to sensors, but do not provide the actual sensor drivers.



    Wednesday, May 5, 2010 7:53 AM
  • Get the release for MRDS 2008 R3 now, it's available as a download, and the Standard Edition is free again!



    Thursday, May 20, 2010 11:35 AM

    It's nice to see there is some activity on this project, although I am a bit concerned about the speed and agenda for the roadmap.

    I saw CCR in particular having some real potential for parallel applications in robotics but also x-pollinating to other applications.  In robotics for instance, it would be useful to be able to continuously generate a signal while listening for an arbitrary event in such a case that you couldn't use a traditional interrupt that would impact your outgoing signal.

    Still had quite the wishlist for this:

    -Wizard based setup of hardware profiles (this way one doesn't see irrelevant services when developing)

    -Code that executes on the actual hardware, not a control PC

    -Unified GUI IDE (VPL, C# and simulation) with all components under one roof.


    Competition (i.e. from National Instruments) has proven there is a market for this kind of thing, if done right.  I just hope Microsoft is seeing this as such to put more oomph behind the project.

    Monday, May 24, 2010 3:06 AM
  • Thank you for your suggestions.

    RDS 2008 R3 is only a minor release and the main emphasis was not on new functionality but on eliminating the different Editions and making it free for everyone. We are continuing to develop RDS in a variety of different directions.

    CCR is still a core component of RDS and we will continue to develop it. We routinely hear of customers who have used CCR as a key element of their systems and just last week we had a request to use CCR from another Microsoft product group.

    At this stage there are no plans to run on platforms other than Windows, i.e. we do not intend to generate code that runs directly on embedded devices.



    Tuesday, May 25, 2010 6:52 AM
  • The consolidation was certainly welcome in my opinion.  Allows the team to focus on making one product better rather than making multiple products.  Also gets rid of the customer having to choose between versions.

    Personally, I'd love to see the many versions of Windows consolidated into maybe 2 or 3, but that's another story.  It's more a business decision of a science called "price discrimination" rather then a technical issue.

    I am disappointed about there being no plan to support embedded hardware, although it's becoming increasingly practical to make embedded systems out of x86 architecture capable of running full blown Windows.

    So it basically means one would need to limit themselves to building autonomous robots with say an Atom processor at a minimum.

    Tuesday, May 25, 2010 11:45 PM
  • Hi Trevor,

    Could you clarify what you mean by "there are no plans to run on platforms other than Windows"?

    By Windows do you mean only x86 or x64 based Desktop Windows versions?

    How about an ARM based robot running Windows 7 Embedded?  Since MSRS is dependent on the .NET runtime, I suppose whatever system is used must have the .NET runtime installed (although this is further complicated by the different configurations one might have of processors, Windows versions and .NET frameworks, not only compact vs. full but different revs as well).

    With that said, I didn't see any way in MSRS to execute the code on a system running .NET aside from the machine running MSRS in the first place.

    Any light you could shed on these variables would be greatly appreciated.


    Tuesday, June 1, 2010 5:35 PM
  • Second that interest in a minimalist Windows Platform.

    One project I worked on had a laptop clamped to the top of it and we had a hard drive failure within a few weeks.  Apparently Laptops are not designed for bouncing  around.  Who knew?

    I don’t know exactly what windows phone 7 has in it, but I have heard Silverlight will be there.

    How about a  ‘Microsoft ROBOT 7’  That would be a boon to the community. Strip out all the extras and leave just the stuff needed for the platform to work. 

    If a Bluetooth interface is the primary I/O portal, a MS Phone ‘COULD’ be the brain-box.  My phone already has more CPU power than the 12 bit processor board I am using now.


    Tuesday, June 15, 2010 9:45 PM
  • If you use a laptop on a mobile robot you should use SSD disk (no mechanical parts) or some big USB key. Regarding .NET and MSRS, would be nice to see the guys behind Novell's mono (.NET port to Linux/OS-X) work a bit with MSRS
    Microsoft MVP J# 2004-2009, Borland Spirit of Delphi 2001
    Wednesday, July 28, 2010 6:52 PM
  • BTW, I don't see it very hard to make MSRS runtime stuff run on other CPUs as long there's Windows and .NET for them
    Microsoft MVP J# 2004-2009, Borland Spirit of Delphi 2001
    Wednesday, July 28, 2010 6:54 PM
  • Just to summarize:

    RDS 2008 R3 uses .NET 3.5 SP1 at present. It does not support the Compact Framework which is not the full .NET.

    As for Mono, I would be very happy to see RDS running with Mono. The issue is that it needs to be compatible with .NET 3.5 SP1. The last time I investigated this (which was a while ago) it was not at this level.

    Of course we will be moving to .NET 4.0 some time in the future (yet to be decided) and this will also be an issue if Mono cannot keep up.


    P.S. The only version of Windows that does not run on Intel architecture is Windows CE (or whatever the current name for it is). This is based on a different kernel from standard Windows.


    Sunday, August 1, 2010 12:12 AM
  • Indeed, that's why I write "as long as there's Windows and .NET for them". However I guess the requirement is mostly .NET, not Windows or am I wrong and you use OS calls too (via P/Invoke or whatever)?

    Btw, Intel architecture includes both the EMT64 (compatible to AMD's x64) and IA64 (Itanium) - Windows comes in both flavours, think .NET does too. So if RDS uses only .NET that shouldn't be an issue I guess (would use multiplatform target at precompiled IL)

    Microsoft MVP J# 2004-2009, Borland Spirit of Delphi 2001
    Monday, August 2, 2010 1:12 PM
  • Just wanted to refer a bit more of what has been said about the ease of integrating with more powerful tools such as for machine vision.

    EmguCV http://www.emgu.com/wiki/index.php/Main_Page  is an OpenCV wrapper that I've tested without CCR in VS2010 and it's working perfectly fine. I've developed some simple projects for testing common things in machine vision such as face recognition and object recognition using robust algorithms such as sift/surf...

    I'm now going towards different tests with these algorithms, trying to get everything down into stats to identify benefits of CCRwhen compared to their same implementations without CCR.


    Generally speaking, I think these wrappers really enhance the MSRDS capabilities by bringing together powerful libraries such as OpenCV... So, service production from indepent providers ( us ! ) can also be enhanced in order to increase actual repositories such as in codeplex.

    Sunday, August 15, 2010 5:54 PM
  • Hello,

    I've been trying to integrate emguCV with Robotics Studio, but have not had much luck.  I can get the libraries to work in VS2010.  I'm probably missing something simple when it comes to MSRDS seeing them.


    Thanks for any suggestions,


    Thursday, November 4, 2010 5:35 PM
  • Please have a look at:


    This is still a Beta, but it might help you.



    Friday, November 5, 2010 5:09 AM
  • Hi !


    If you´re able to run any sample of the EmguCV by its own, meaning outside an MSRDS service, then you must be able to run it inside the service also. 


    Be sure to add the whole references needed i.e:







    Monday, November 8, 2010 6:23 PM