A Couple of questions about MRS

I was waiting for somebody else to reply

I think Rob has given a good explanation, but I'm going to put in my two cents worth anyway.

MSRS is not designed to directly generate code to run on particular hardware, such as a PIC microcontroller. The services require a Windows platform, such as Windows XP or Windows CE. So if your robot is based on a PC or a PDA then you are in luck. If not, then you have to write some code yourself.

It is important to understand this because it is a fundamental misconception about MSRS that many people have. Lots of hardware/software packages out there allow you to write code and then download it to your robot for execution, but MSRS does not work this way. Basically with MSRS you tele-operate the robot via a service running on a PC.

What you need to do is design a control program to go inside your robot that communicates with a MSRS service. This can use Bluetooth for instance, which is really just a serial port as far as the code is concerned.

This control program must accept commands to control the robot and also send back regular updates with the current sensor values. Alternatively, your MSRS service can poll the robot periodically. Yes, it is event driven, but you create the events!

In an MSRS service you can handle subscriptions. (Microsoft provide a Subscription Manager for this.) Changes to the sensor values are reflected in the state of the service, and can be automatically propagated to the subscribers.

There are quite a few examples for different robots that are included in the package. Also there is the code for the Scribbler written by Ben Axelrod and available from the IPRE web site, but the Scribbler uses a Basic Stamp. The main reason I mention it is that the Georgia Tech people are currently using a Bluetooth-to-Serial dongle. That takes all of the wireless networking out of the equation because you just need to talk to a serial port on the robot side, and a virtual serial port on the PC side.

I hope this helps.

Trevor

I just joined this forum, after downloading but not installing the Robotics Lab v1.5.

I also have a general question about how Microsoft would like their MSRS to fit into real-world control systems.

Most of what I see so far is at the academic or hobby level, but it seems to me that Microsoft would like to use MSRS to penetrate the industrial controls market and integrate with PLCs, industrial robots, conveyor and process controls, and higher-level factory floor controllers.

I have been designing such systems for almost 30 years, from the mechanical and electronics, to the embedded systems, robotic control systems, and on up. The only time I have used Windows was in 1997, for a telerobotic remote operator console to unload very hazardous materials, and later in 1999 for a distributed control using C++ for the control and the operator interface in Visual Basic, communicating by event subscription through DCOM.

MSRS has already been used for several real-world applications such as a car entered in the DARPA Urban Challenge, and underwater robot and of course Kuka have a bunch of software and tutorials for their industrial-strength robotic arms.

If you have used C++, VB and DCOM, then you will be happy to know that the environment is similar. Of course, you really should learn C# but that is not difficult if you know C++. And rather than events, you subscribe to messages.

As for PLCs, conveyors, etc., this is really up to somebody to develop the appropriate hardware interfaces and drivers. MSRS is a framework -- it does not directly target any particular robot. However, there are a lot of samples and tutorials available that just happen to run on a variety of robots :-)

I think MSRS should be "industrial strength".

Trevor

That's fine, and I see all that, but it is marketing-level.

I would like to see some more engineering-level documentation, high-level architecture and the how-to plain-English explanation of each functional aspect.

For example, you say I would really learn C#. Why

This is the same unanswered question I have for WCF. MSDN says it can be be coded in VB.NET, C#, C++, JScript, etc, but only shows examples in C#. Fine, that's easy, just tell me the underlying reason why. If VB.NET has limitations, Microsoft needs to put that up in bright lights, because no experienced engineering manager is going to let a project be started in unknown territory, and the more naive ones who end up down a blind alley will be forever sworn off of MSRS or WCF or whatever burned them.

Or, to get back to marketing level...I can design, build, and code a complete vision system, process control, machine control, CNC machine, etc from scratch in ANSI C++, Modula-2, or Ada with its own embedded operating system and deliver the product from concept to handover in 180 days. I can build some in Windows XP with a remote HMI in VB right now. Sell me on switching to MSRS.

Point me to the documentation on how to develop drivers for MSRS for PLCs, stepper controllers, A/D boards, etc.

I have done them before for other projects. That would tell me a lot about how MSRS really works.

I am not flaming at all.

I am just talking from the viewpoint of an engineering manager, who is considering using WCF and MSRS to implement a new $21 million industrial control project. Or, I could just do it in .NET, as a migration up from older architectures using VB 6.0 with some DLLs in VC++ and a little COM Interop for newer .NET objects, which is ugly and works poorly.

At some level, C# is not going to everything, and you are going to have to use ANSI C++ to develop some abstract base classes which will compile to something predictable. Those are all the things we software engineers need to know, in order to control risk, allocate resourses, and deliver the applications on time, beginning with choosing the correct tools and architecture for the job.

I use C++ all the time because, for instance, I am using the OpenCV (Open Computer Vision) library from Intel. I don't have a problem with it except that in the .NET environment the code is usually unmanaged.

C# has some features that make writing code for MSRS a lot easier. Try it. I think you will like it! I'm a convert and I've used a wide variety of languages over the years.

On the other hand, if portability is an issue, e.g. to Linux, then you probably don't want to code in C#. But in that case, you won't be running MSRS on a Linux system anyway. (Unless somebody migrates it to Mono.)

Trevor

I was not posing a question about my personal preferences for coding in Visual C++, ANSI C++, C# or VB.NET

I am asking how the creators of MSRS intended for it to be used, to be programmed, and the shortcomings of using various languages, so I don't waste any of my precious time finding the dead ends. If VB.NET or C# will do everything that you can do in MSRS, then that's great.

Subcribing to messages is not a new concept. OPC (OLE for Process Control) was using an event subscription service back in 1999, before there was a .NET.

If I were going to develop in embedded Linux, I wouldn't be in this forum. There is no code portability between Windows and anything else, beyond the most basic procedures which will run in any operating environment.