Request for input for Future RDS Releases RRS feed

  • Question

  • We are currently at the planning stage for the next release of RDS and I am looking for input from the user community.

    Please respond with a posting to this thread so that all the input will be in one place and everyone else can see the suggestions to avoid duplication. This thread is for general input. There are similar threads in the Simulation and VPL forums, so please use those for the respective RDS components.

    Friday, September 11, 2009 8:52 PM


All replies

  • Hi Trevor,

    I would like to be able to set the "Save new projects when created" property in Visual Studio back to false.  I like to create simple proof of concept projects to test without saving.  Please see this thread:



    Saturday, September 12, 2009 10:06 PM
  • Hi Trevor,

    Can there be an overload of the subscribe helper method that will allow the use of the NotificationPortConfiguration property of the subscribe object?



    Saturday, September 12, 2009 10:07 PM
  • I hope this isn't off topic, but I was thinking that with the form factor of motherboards getting smaller, less expensive, and less power consuming almost daily, in the future the optimal scenario will be to have RDS running onboard the robot.  I was looking at versions of Microsoft's embedded operating systems on this page:


    I noticed that there are some very specific versions for specialized environments like Point of Sale.  Would it make sense for Microsoft to create a version of Windows Embeded that was specifically tuned to run RDS on an onboard computer?

    The DSSHost could be modified to be started as a windows service so that the board would start it as part of the boot process.  A simpler solution would be to write a simple windows service that monitored the DSSHost and started it when it found that it was not running.  It could then start it with a list of manifests that was maintained in an XML file or even a flat text file, so the user can easily change the configuration.

    Is this even possible?


    Saturday, September 12, 2009 10:33 PM
  • Hi Trevor (and the rest of the RDS team)

    I think the single most important feature would be a "designer for (serial) communications".

    The problem with connecting hardware from different vendors, and writing and maintaing our own drivers for them is a lot of work.
    So what I would like is some designer (like the modelling language "M" and Oslo) in which I can describe the serial communications, and the possible responses and timeouts and wait periods, so we can optimize the line speed. Also locking on the serial buses could be minimized this way.

    For example generic I2C drivers, and only a description of the device/communication protocol should be supplied by the user.

    Other requests:
    Drop the Express, Standard, Academic versions, I think it really hurts the hobby community.
    Graphic designer for simulated area's, like dropping in furniture.
    More simulated "real" environments like a factory with Kuka's, or a conveyor belt.
    Support for "arduino/freeduino" like systems, which show up a lot lately.
    Extend VPL to visualize concurrency (problems), more like a state diagram or like that.



    Sunday, September 13, 2009 10:42 AM
  • You probably have already taken care of this, but I wanted to get it on the checklist.

    Please change the font color from white in the DSS Log Analyzer.  I'd love to change my window background color back to white.



    Sunday, September 13, 2009 4:58 PM
  • I never did figure out what the difference was between DssHost.exe and DssHost32.exe, nor why the "Run DSS Node" shortcut runs DssHost32.exe, while the default value for the "Debug: Start external program: property runs DssHost.exe.


    If one of these is incorrect, could that be fixed for the next release?


    Sunday, September 13, 2009 4:58 PM

  • I was under the impression that 'DssHost32.exe' was included to allow development on 64-bit systems...

    Monday, September 14, 2009 12:44 PM

  • Interesting that you mention this.

    I happen to have been developing a Robot (Robbie the Robot) as part of a university engineering project (Curtin Uni - Western Australia).

    The primary control of Robbie was developed using MS Robotics Studio and is being run on a little Intel D945GCLF (inc. Atom processor)
    which was picked up fairly cheap. We are currently running XP Prof. onboard and have DSSHost run on startup. Connect to the
    board using Remote Desktop (Wi-Fi) and control through the onboard GUI. However we have run XP Embedded on the onboard comp.
    and will hopefully be able to get the control prog running on this within a month or so...    if good luck prevails.

    If XP embedded works as we're hoping then I don't think they'll need to develop a dedicated version, perhaps just a quick manual on 'How
    to get your MS Robotics Application Running Under Embedded XP'.

    Monday, September 14, 2009 12:57 PM
  • Edward AE,

    Cool!  That will be great as long as the manual is complete enough.  I had though that it would be handy to just have an installation for a pre-made version, but it sounds like the steps are pretty simple.  Can you give me an idea as to the size of the effort?

    What about licensing?  I thought the CE and Imbedded versions had a peculuar licensing scheme.  I haven't explored that deeply enough.

    When you get this up and working, would you mind spinning a new thread with your approach, your steps, and/or your lessons learned?

    Good Luck,
    Monday, September 14, 2009 1:53 PM
  • I would like to see a few new generic interfaces setup for generic output devices specifically analog and digital output values.  My thinking of the existing AnalogSensor and ContactSensor makes me think of input values only.  The idea of using Replace is not what I'd call ideal since it replaces the 'whole' state rather than just the specific output value.

    Ed Harfmann
    Monday, September 14, 2009 2:09 PM
  • Edward AE,

    Since this is off topic, I sent it to a new thread:


    Monday, September 14, 2009 4:49 PM
  • Monday, September 14, 2009 5:40 PM
  • RDS is pretty broad, and needs work on a number of fronts:


    For hobbyists:

    ·        More syntactic sugar.  Maybe so much so that there is a meta-language for specifying operations ports, messages, interfaces, service connectivity, timer loops, etc…

    ·        The ability to run on a broader range of hardware.  For example, the roboard (http://www.roboard.com/ ) or Qwerk (http://www.charmedlabs.com/index.php?option=com_content&task=view&id=29 ).   These robot specific processors fit somewhere between a gumstix (http://www.gumstix.com ) and an eBox (http://www.compactpc.com.tw/ebox-2300.htm ).

    ·        Python support

    ·        Less security, more usability


    For enterprise:

    ·        Better support for inter-node operations.  Like finding nodes, services, etc.  Stuff like this: http://social.msdn.microsoft.com/Forums/en-US/roboticsdss/thread/8042fb43-2962-48b6-aab9-eafcbe2c6809

    ·        An easier way to manage a system of dozens of services over many nodes.  For example, to be able to know quickly and easily who is polling who and at what rates,  who is subscribed to who and at what rates are the notifications, how long is each handler running for, etc.   I know RDS is not a RTOS, but it basically has all the components of one, and therefore needs the debugging and diagnostics tools of one too.

    ·        version-to-version stability!


    For academia:

    ·        Mono support

    ·        Higher level libraries for computer vision, navigation, AI, machine learning, etc., (or the ability to work with other robot platforms that already have these libraries)


    As you can see, many of these improvements are at odds with each other.   It is up to the RDS team to strike a balance here…

    Friday, September 18, 2009 3:52 AM
  • We are still using the Ageia PhysX, right? If so, are we going to use new verion of PhysX from nVidia, which will take the advantage of nVidia graphics cards?

    Friday, September 18, 2009 5:44 AM
  • Trevor,

    I'd like to see a "MAJOR" overhaul of RDS so it would provide "Super-Simple" integration of planner, controller, and sensor algorithms in the form of plug-ins.
    Please see http://openrave.programmingvision.com/index.php?title=Main_Page#Robot_Systems_using_OpenRAVE for an example of what I'm getting at.

    Currently, doing real work in RDS is a slow and cumbersome exercise, but it need not be! ---This overlaps into the "library" request you've posted as well.
    A "library" of plug-ins would be a great way to start; path planning plug-in, vision plug-in, various sensor plugins....etc.

    Wednesday, September 23, 2009 11:22 PM
  • Hi Trevor and the rest of the MRDS team.

    Would it be possible to give guidelines on how to adopt a test-driven development framework with robotics studio services. I think in the forums this was mentioned that the MRDS team have unit tests, although I understand this is part of your internal development process. However, there may be some merit to adopting TDD when writing robotics studio applications to ensure maintainability and quality. This need  becomes apparent when the applications would involve many services distributed across many machines and need to have reliable continuous running times - almost like enterprise applications.

    Thursday, September 24, 2009 6:19 AM
  • Hi everybody.
    Mono support is indeed insteresting since many robots on the market have a linux version embeded.
    Friday, September 25, 2009 1:01 PM
  • Less dependence on the MRDS installation directory during development (along the lines of http://social.msdn.microsoft.com/Forums/en-US/roboticscommunity/thread/0d4bc3b6-18b9-477f-af2a-7ef400b22f32).  Ideally the MRDS installation wouldn't need to be write-able by standard users and could be installed into "C:\Program Files" (after all, you wouldn't expect your C# project outputs to go into Visual Studio's installation directory...).
    Monday, October 12, 2009 8:27 AM
  • I agree.  One of the strengths of the typical Microsoft world over the Java world is that the code is agnostic to it's location.  This allows the developer freedom of organization.  I understand that the "sandbox" was designed in from the beginning, but it sure throws a monkey wrench into typical business processes.

    Friday, October 16, 2009 3:04 PM
  • I completely agree.  RDS should be trying to attract companies to use it's product if they want actual sales.  By sticking with this sandbox approach, they are discouraging businesses and encouraging hobbyists. 

    Friday, October 16, 2009 3:09 PM
  • RDS has a lot of nice built-in functionality to take the burden off the developer.  This is nice for beginners, and when writing simple services.  However, when beginners need to expand their skills and take on more complicated services, all this hidden code can be a hindrance.  I would like to see a new tutorial or two that shows a service in its simplest form, and again in its most verbose form.  Off the top of my head some things that contain a lot of hidden code:
    • Service handler interval
    • base.start()
    • subscription manager
    • default message handlers (get / httpGet)
    I know these things are spread throughout the tutorials in both their forms, but it would be nice to see a bunch in one place.
    Wednesday, February 3, 2010 5:08 AM
  • Thanks everyone!  We are closing this thread now.
    Friday, April 30, 2010 11:50 PM