William Wong
|
ED Online ID #16631 |
September 5, 2007
VPL appeals to non-programmers because it is easier to visualize. In fact, VPL is as complex as any text-based system and it will take that level of programming expertise to master VPL as well. Still, the initial startup and the ability to easily access other components will make it very desirable in robotic programming where developers have a wide range of programming backgrounds. VPL is not required to use MSRS but it will likely remain as one of its key aspects.
Microsoft Visual Simulation Environment (VSE)
The Visual Simulation Environment (VSE) is designed to provide a simulated 3D environment based on objects that interact with their simulated environment using DSS services. The environment can be visually appealing or it can be rendered as line drawings. By default it uses the typical physics environment so you can’t put two objects in the same space at the same time. The theory is a robot can be easily simulated with a simple redirection of the DSS services being employed. In practice, it works rather nicely. In fact, developers can take advantage of MSRS exclusively using VSE.
It is possible to create a simulated robot from scratch but most developers are likely to employ models developed for them. For example, robots like the iRobot Create (See Real Robots: iRobot Create) have simulated versions available on the Internet.
The other advantage of VSE replication is trivial: Want six bots? No problem. Of course, there's also a downside. Simulations are approximations. It is easy to simulate a robot that goes straight on a flat surface, but in the real world that doesn’t happen. Likewise, there is a certain "fuzziness" in the operation of sensors and actuators that is actually hard to simulate. Still, the advantages typically offset any of the disadvantages. Developers simply need to be aware of the extent and limitations of a particular simulation environment.
From an application standpoint, a VSE robot and a real robot normally differ only by the DSS connections.
Running the VSE demos is a trivial exercise and Microsoft provides a number of examples. Making the sample platforms work with another application is a much more difficult process on par with working on a real robot like the Whitebox Robotics 9-Series PC-Bot.
MSRS On Whitebox Robotics 9-Series PC-Bot
Whitebox Robotics's 9-Series PC-Bot has a Mini-ITX motherboard that is capable of running operating systems like Windows and Linux. This allows the PC-Bot to run MSRS applications or even be used as a development platform. It is possible to attach a monitor to the robot but it is much easier to use remote desktop software instead. The advantages of this approach is having a single environment for development, testing and deployment. The disadvantage is the power of the system is less that the latest desktop or laptop PC.
The big problem installing and using MSRS on almost any platform including the PC-Bot is the complexity of MSRS and all the related components. Likewise, some items come from other sources like the .NET drivers for the PC-Bot.
For simplicity, I installed MSRS completely on the PC-Bot and a separate instantiation on a PC that would use the VSE almost exclusively. I won’t go through all the gory details but it starts with the .NET Framework and a copy of Visual Studio plus any of the desired languages. Next comes the MSRS software and then Whitebox Robotics' DSS services for the PC-Bot. Reserve at least an afternoon because there is a lot of software. The actual installation process isn't lengthy, but getting used to where everything is and what it does in general will take some time.
The DSS services available from Whitebox Robotics support the robot as a service in addition to a service that implements a GUI interface. The latter is similar to the B.R.I.A.N. interface that comes with the PC-Bot but it is completely implemented using MSRS. One thing I did run into was the differences between MSRS 1.0 and 1.5. There is evidently enough difference between the two that an update will be required to handle the latest version of MSRS. MSRS is still a project in flux so these kinds of quirks are to be expected.
The GUI provides access to all of the stock features including the motors, sensors and webcam. The webcam support can take snapshots or video clips. It is possible to toggle IO ports and drive the system using the mouse or a joystick. The big advantage over B.R.I.A.N. is that the host services are a completely separate DSS service. The GUI worked equally well on the PC-Bot or a remote PC.
One interesting aspect of the client/server architecture that MSRS highlights is the ability to have an application utilizing the PC-Bot services and also using the GUI. This is handy for performing maintenance such backing up the robot when it gets stuck.
I actually worked with the PC-based simulation environment to get the hang of MSRS. Unfortunately there is no support for a simulated PC-Bot at this point but there are enough other platforms to choose from to experiment with MSRS. I still don’t have a good feel for the entire MSRS environment but I can address the basics at this point. For programmers like me with C/C++ background it is probably faster to do some of the initial experimentation using C# instead of VPL or Iron Python.
Then again, others may prefer those depending upon their background. If you run through the online tutorials and such you can spend at least a week getting comfortable the system. Replicating the basic functionality of the Brian user interface (See Robots: White Box Robotics PC-BOT) that comes with the PC-Bot using Whitebox Robotic’s components was the first chore. It took a day or so, more due to the lack of familiarity with MSRS than complexity of the job.
MSRS In General
MSRS is definitely more complex than the other robotic platforms I have looked at, and it is potentially more powerful as well. It provides a standardized platform, although it's tightly coupled to Microsoft's tools and operating system platforms. Granted, DSS communication can work across standardized networks but building a similar framework on a different platform is no small task. For those familiar with .NET, C# and the like, Microsoft's robotic framework makes sense. It builds on .NET assemblies.
On the plus side, MSRS is now the target for most vendors of robotic platforms. DSS services to control these platforms are now becoming available. Prior to MSRS, there was not common platform for developers to target. MSRS is becoming popular because it is a rallying point around which developers can provide their product specific aspects as well as algorithms that others can then utilize. Its web-based roots allow control and cooperation across standard network links.
On the other hand, MSRS is possibly too complex. It's harder to use than any of the other robotic development environments I've looked at in this series. Even a quick run-through of the numerous Microsoft provided tutorials is enough to deter even the determined developer. Unfortunately, the tutorials often tell how to do something but there are so many details that it is difficult to understand the context. Part of the problem is the amount of code needed just to get started. Granted, much of this is generated by things like the command line tools for creating a new DSS service but this makes it very easy to accidentally creating a problem. For example, a minor deviation from a tutorial can result in something that will not build properly. This tends to be less of an issue for those familiar with Visual Studio but it may make MSRS less preferable as a starting point.
MSRS still utilizes a good deal of text-based commands and interfaces. This can be an advantage for some and the diagnostics are very useful. GUI interfaces tend to have a problem by isolating users from these details but it is exactly what is required when doing low level development.
MSRS is improving steadily from 1.0 to 1.5 and I expect even more when it finally hits version 2.0. Its dependency on command line programs highlights its rough edges at this point. The big problem at this point is that MSRS is still growing. The basic support being delivered by most vendors provides access to the sensors and movement controls, not more sophisticated navigation and algorithmic support. The plus side is that MSRS appears to be a good platform to deliver these kinds of services. Some video tracking support is provided by Microsoft which is a good start.
MSRS is an impressive platform whose components are not restricted to only robotic applications. Much of the MSRS protocols are covered the Microsoft Open Specification Promise license. It is, in theory, an open license but I have not had a chance to examine it in detail and neither can I render a legal opinion on it. It is clearly nothing along the lines of other open source licenses like GPL or LGPL but it may provide the openness that standards committees will find acceptable. Microsoft is talking with Open Source Initiative (OSI) about its licenses so this is likely to be fodder for another story.
Microsoft’s commitment to MSRS is probably the most impressive part of the environment. It is clear that Microsoft intends to stick with this platform although it remains to be seen whether the path changes of the past (like COM, DCOM, WIN32 etc.) are replicated with MSRS.
Reprints
