locked
About choosing the right generic contracts when creating services RRS feed

  • Question

  • I'm a novice concerning MSRDS.

     

    I require functionality from the RoboticsCommon library in order to use an ANALOG CAMERA. I know that a reference to the Robotics Common Library should be made through its proxy DLL, RoboticsCommon.Proxy.dll.

     

    In C# Express 2008, when I right-click on References in the Solution Explorer and choose Add Reference, which generic contract should I use with my ANALOG CAMERA? 

     

    The Explorer will "listen" to the Analog Camera Service events and send instructions to a Solenoid Service (actuator).

     

    I suppose when I create the Solenoid Service I will again need to select the correct generic contract. What would the correct generic contract for a solenoid device be?

     

    Can one Solenoid Service run multiple solenoids? ; or if I have 5 solenoids do I need a seperate service for each solenoid?

     

    Thanks.

     

    SamQ

    Sunday, August 17, 2008 4:08 AM

Answers

  • Hi Sam,

     

    Sorry I did not reply sooner. I look for unanswered messages, and I did not notice your response.

     

    I guess you can liken a generic contract to a superclass, but there is no real "inheritance" in MRDS.

     

    All you need to do to create a service without a generic contract is use DssNewService. Check out Service Tutorial 1.

     

    The "action" messages will be notifications. They can occur asynchronously. Consumers of the notifications have to subscribe. (It is basically a Publish-Subscribe model).

     

    The point of orchestration in your case is that the camera should not know anything about the solenoids. Likewise the solenoids have no idea who is manipulating them, and certainly do not know that it is a camera. Therefore some higher-level service has to wrap it all together to achieve the desired outcome. The concurrency sort of comes along for the ride, but in robotics applications concurrency is essential because you never know what is going to happen or when. Of course, if you implement polling of your sensors then things are a little more ordered, but the orchestration service would have to do this so it is still in charge.

     

    Trevor

    Monday, August 25, 2008 5:42 AM

All replies

  • I'm not sure what you mean by an analog camera. MRDS supports webcams, but they are digital.

     

    There is no solenoid service as such in MRDS. This is a very simple service since a solenoid only has two states. In fact, it is a special case of a general digital output. Right now there is no generic contract for digital outputs, so you can just write your own service.

     

    As for multiple solenoids, the approach in MRDS would be to create 5 services. This keeps the services simple and it is extensible to more solenoids. However, if you are not using a generic contract, and you are absolutely, positively sure that there will never be more than 5 solenoids, then you could write your own service with an array of 5 solenoids. This can be generalized a little by allowing the number of solenoids to be a property that can be set, and then you could allocate more than 5 if necessary. But ultimately they have to be connected to hardware and that will be the limitation.

     

    Trevor

     

     

     

    Sunday, August 17, 2008 5:01 AM
  • Trevor,

     

    Thank you for your lucid reply.

    An analog camera will need a TV Tuner to accept RGB input, a digital camera doesn't need one. An analog camera may be a better robotic eye than a digital camera concerning zoom and accuracy; very good for taking apart small images off an LCD computer screen. Digital cameras "artificially" (via software) zoom in causing blur.

     

    I'm unsure whether a webcam service will suffice or not myself.

    I'll be using Roborealm software integrated with MSRDS to control my camera (if that adds any more info with which you can better guide me). I've just received my camera today and am about to download Roborealm, but it seemed prudent to see how to use MSRDS w C# and learn the application model.

     

    Now, I run into the "non-existent generic contract" problem.

     

    So which generic contract do I select for a digital webcam?

    Is there a tutorial on how to write my own generic contract?

    Is there a tutorial on writing a digital output service?

     

    There will be a maximum of 39 solenoids. The number will slowly increase as he project approaches conclusion.

     

    If I read you right, your implying that a generic contract allows me to write multiple services based on the contract, as opposed to writing only one non-generic/specific service that contains an array to handle the eventual 39 solenoids?!

     

    I will also have a piece of hardware that will drive the solenoids. All the solenoids will be connected to the hardware driver and the driver comes with software to drive it. I'm not sure how that will integrate into MSRDS.

     

    You may be wondering.....if I have Vision software (Roborealm) to drive the camera and software to actuate the solenoids, why do I need MSRDS? .....The answer is: I eventually want to run multiple image evaluations and maybe even multiple cameras in a concurrent fashion; exactly what robotic sensor processing needs. I want to avoid all the threading headaches, etc.

     

    SamQ

     

     

    Sunday, August 17, 2008 6:08 AM
  • Hi Sam,

     

    The analog camera will still need to be connected to a video capture device, or digitizer, in order to input the images into a computer. There are many of these devices available. The cheaper once plug in to a USB port and behave just like a webcam. Provided that there are drivers that conform to the normal Windows webcam standards then you can use the webcam service that comes with MRDS. So I can't really answer your question, but I suspect the MRDS webcam service will work.

     

    RoboRealm works by running as a server. The MRDS services that are provided for RoboRealm actually talk to the server, which might be running on the same PC or a different PC. You need support from RoboRealm for your camera, not MRDS.

     

    You don't have to write a generic contract. The idea behind generic contracts is that if there are going to be a whole family of hardware devices then it is best to abstract the basic features and functions and put them into a generic contract. Then it is possible to write higher-level applications (referred to as "orchestration services") that use the generic contract. To switch from one device to another you simply change the manifest at runtime to use a different service, but the higher-level code does not know about this.

     

    If you have a one-off device, then you just write a service. However, if you later design or buy a device that happens to be similar you will have to write another service. (Obviously, you would do a lot of copy/paste but they would still be two completely separate services).

     

    I might have confused you about the array of solenoids. It is certainly possible to write a generic service that has an array of devices.

     

    If you have software drivers for the solenoid(s), then you are half-way to writing a service. Your service will have to call the APIs for the solenoids. Basically, the service is a wrapper that hides the actual interface from the rest of MRDS. The tricky part is making sure that this service does not block execution, which is bad in a multi-threaded environment. However, you can set up your own dispatcher and have your own thread pool, so behind the scenes you might actually want to block. It really depends on the nature of the device driver that is supplied by the manufacturer.

     

    I'm glad that you are using MRDS with RoboRealm and your solenoids. Hopefully you will be able so share some of your experiences and maybe even the code.

     

    Trevor

     

     

     

     

    Sunday, August 17, 2008 7:35 PM
  • Trevor,

     

    Thanks again. You're really a great mentor.

     

    So a generic contract is like a superclass in Object Oriented Programming(?!).

     

    Which tutorial shows how to write a service without using a "generic contract"?

     

    My application design has a camera service (a.k.a. - sensor service) discern pieces of data, analyze the data, and then generate an "action" message. The action message is sent to the Explorer (Orchestrator). The Explorer sends an activation message to (at most) two Solenoid Services (a.k.a. - actuator services) that must execute concurrently. Does this design look ok to you? (verifies my overall understanding of how to use MSRDS properly)

     

    So far, my understanding is that the Orchestrator's sole purpose is to accomplish concurrent execution of actuators as well as receive concurrent input from sensor services, right?

     

    Thanks for the verification of my understanding of the MSRDS app model.

     

    SamQ

    Sunday, August 17, 2008 9:10 PM
  • Hi Sam,

     

    Sorry I did not reply sooner. I look for unanswered messages, and I did not notice your response.

     

    I guess you can liken a generic contract to a superclass, but there is no real "inheritance" in MRDS.

     

    All you need to do to create a service without a generic contract is use DssNewService. Check out Service Tutorial 1.

     

    The "action" messages will be notifications. They can occur asynchronously. Consumers of the notifications have to subscribe. (It is basically a Publish-Subscribe model).

     

    The point of orchestration in your case is that the camera should not know anything about the solenoids. Likewise the solenoids have no idea who is manipulating them, and certainly do not know that it is a camera. Therefore some higher-level service has to wrap it all together to achieve the desired outcome. The concurrency sort of comes along for the ride, but in robotics applications concurrency is essential because you never know what is going to happen or when. Of course, if you implement polling of your sensors then things are a little more ordered, but the orchestration service would have to do this so it is still in charge.

     

    Trevor

    Monday, August 25, 2008 5:42 AM