Microsoft Robotics Developer Studio (MRDS) is a powerful tool, capable of realistically simulating the behavior of a well defined robot. Unfortunately, the MRDS toolkit is not all-inclusive, nor does it include adequate instruction on how to build pieces which simulate behavior. Our team purchased an instructional book entitled Proefssional Microsoft Robotics Developer Studio which includes useful explanations, samples, and tutorials about how to create services, entities, and use the simulation environment as well as the Visual Programming Language (VPL) tool. Getting MRDS up and running was a rough experience, one where we stumbled across several surprises which rapidly expanded the scope of what we thought we’d have to do.
The first surprise with MRDS is its installation location. Most applications install themselves by default to the “C:\Program Files” directory, allowing the user an option to specify another location. MRDS by default installs to the user’s profile, and the user must choose do the “custom” option for installation to redirect that location. The installing user must also have Administrative rights on the computer they’re installing to (this is especially relevant for installing to machines on campus).
The second surprise with MRDS (although not as surprising) is that there is no environment for creating the physical representation of a robot. One might assume that a “development studio” might include tools to create the physical representation of a robot from scratch, perhaps using predefined parts whose characteristics could be specified. In reality, the physical characteristics of a robot are described using a .NET language, most commonly C#. Microsoft Visual Studio is not supplied with MRDS. The physical “Entity” of the robot is outlined in ‘code’ which is then run as a service on the computer, which the Simulation service interacts with. This multi-service architecture is observed, not explained, through the use of the book we purchased.
The thirdsurprise with MRDS is that Microsoft Visual Studio 2008 must be installed before MRDS, in order for MRDS to include the “New Service” type of class. Conveniently, MRDS provides a partial class with a few of the required code portions used for a service. If you do install MRDS before Visual Studio, you’ll have to uninstall and reinstall MRDS in order to use those service partial classes. This was only indicated in the book we purchased, not in any setup documentation we found for MRDS.
The fourth surprise with MRDS is that there is no environment for creating the visual representation of a robot. To make a robot look realistic (rather than as boxes and cylinders) a 3d image of the robot must be loaded as a separate file into the robot entity service. This 3d image must be in .obj format. Our solution was to create the robot visually using SolidWorks, and convert the assembly of parts into the .obj format using an external tool called Blender. There may be other ways to do this, but as we were given SolidWorks parts and assemblies to start with, it’s the route we chose.
Overcoming these surprises resulted in frustration, lost time, and a sturdy grasp on just how unpredictable the twists and turns of the software would be. Having an understanding of the software capabilities (in theory), the rest of our adventures will be regarded as challenges. Some of these challenges were due to a lack of user instruction for MRDS, while others were due to a lack of debugging or output tools. These are the challenges which we were not able to overcome. For many of them, completely “starting over” would be a better approach than “start from where we left off,” as their complexity would depend on an understanding of developing for MRDS to solve.
The first challenge of developing services to run with the Decentralized Software Services (DSS) architecture is that to generate proxy files for the robot’s service, certain classes and methods must be included and assigned specific attributes. Because this architecture is not checked by Visual Studio upon compilation, there is no feedback about where the architecture hasn’t been properly implemented. We believe that our current implementation adheres to the needed architecture for producing a proxy (using examples from the book), but this may not be the case. The robot’s variable module design (defined at run time, and thus not static for a proxy) may be preventing the proxy from being properly created and used.
The second challenge was coordinating multiple services. At a code level, each service must be its own project, and if it communicates with another service must include a reference to that other services’s project and proxy file (The proxy file must be created via compiling before another project can reference it). There are certain occasions where objects communicate as objects via traditional object communication, and certain occasions where services communicate via their proxy classes. These relationships are logical once understood, but the MRDS resources don’t provide adequate explanation on their relationships. That having been said, our lack of understanding has surely caused delays in development.
The third challenge has been determining what exactly the service classes required for VPL need to be formatted like. For VPL to access functionality of a service, that service must have objects (which are written as classes, act as delegates) within that service and listed on the main service port. It seems that even though those classes compile and run, there are rules being violated which prevent them from having any functionality in VPL/ whatever services VPL is acting on. This issue is only evident once attempting to access the functionality via VPL. Although we don’t have a solution (obviously), it is likely a simple problem to solve.
The fourth challenge of developing in MRDS is coordinating entity images with their entities when using subentities. For example, the Robot entity contains four Module sub-entities. The .obj image for either of them is in position relative to the entity’s location in the simulation when run as independent entities; but when a Module is a subentity (child) of a Robot, the .obj image sets at point 0,0,0 in the simulation, even though the Module entity is located relative to the Robot entity. This disconnect between ‘normal’ object oriented design and the MRDS simulation environment is not evident in the tutorials or book examples. Though there must be some way to accomplish parent/child relationships in order to have joints between entities without each entity running as a separate service, we were unable to discover it.
When beginning to develop the entities and services for the simulation and VPL, we thought the best approach would be to work within the design offered by examples and tutorials, mimicking their structure. Because code will ‘compile’ and even appear to ‘run’ services without providing any feedback on where MRDS rules are violated, subsequent teams would be advised to research and understand the MRDS framework in depth before creating their first service. The book we used would be useful for information, but the examples should only be looked at after completely grasping how to program for the services.
Although not written in a ‘learn about MRDS’ way, the User Guide on MSDN (or ‘help’) does hold relevant information about using the service functionality. However boring the reading might be, we suggest reading through as much as bearable, and understanding the DSS architecture from a DSS standpoint, not just a Simulation standpoint. One should not depend on support from forums online, but rather proactively search documentation and examples for a comparable situation, as the forums for a Microsoft Robotics tool aren’t exactly high traffic web sites.
A final note for future development teams working on the RP series of robots, is the suggestion to start from scratch with the simulation software. Only by starting from scratch will a team understand ‘why’ certain attributes and classes are framed the way they are. There’s no use for copy/pasting chunks of code which don’t work on their own, though understanding the structure of how we implemented the robot simulation would be useful for finding where our code failed to meet the MRDS rules.
The biggest test with developing a simulation is that there’s no real concept of ‘baby steps.’ A lot of overhead has to go into building a service which can run at all, and adding any functionality is a dedicated task which can’t really be broken down to see progress. We invested a lot in the approach we took, and then the result failed. We were left with no clue as to what is out of line, and reluctance to start over, and therefore moved on to the next step, hoping to come back to the initial problem. We strongly recommend fervently ensuring every step is perfect before moving on, no matter how much effort must be put into discovering and fixing that step.
The rationale behind using MRDS, we find, is legitimate. It’s free for students and RIT to put on machines, MRDS itself is relatively documented (compared to other offerings), and the VPL environment should be friendly for Engineering students. We wish any team the best of luck in their endeavors to simulate any of the RP offerings.