He's baaaaack...

Now all of a sudden my supervisor doesn't mind me continuing in the field of simulated robotics... It only took a whole year of misdirected study. I had two supervisors leave me (they went to work in industry - recession and all) before I went back to the old one. The problem is I picked up a lot of their idea's on the way. So I need to shake off the excess and now plunge forward.

As I am going to continue in this field, I just hope that I have not fallen too far behind, of course I will be blogging in order to keep me fresh. Needless to say I have to go back and read my own blog again.

Update

It's been a while since I have updated here... Sorry - I am currently working on unofficial PhD work: I have handed in my masters but have not (officially) received a mark. So I can't register for anything - which is good - because that means I can whack out publications.

I have not been permitted to continue studying in robotics (apparently the engineering department doesn't like computer science guys doing robotics). However, I will continue developing in MRDS because I do enjoy it. But it will be purely as a hobby. But that won't stop me from trying to publish ;)

I am waiting for an official response to my masters and the end of March, then I will start developing again. Also I have to wait to get a better computer. I will try to create a robot to solve a real problem. I'll start off with toy problems and move on from there.

CCR and DSS are now distinct from MRDS

Microsoft have finally separated the CCR and DSS libraries into individual toolkits for applications other than robotics. Check it out [here].

These two libraries are really useful, and I believe they will change the manner in which programmers code. They are extremely powerful.

Just to be current

I just thought that I would show you what I have been working on. What's more important is what is going on in the background. I coded the robot in C^# and designed the environment in the VSE. Then I connected it via the manifest editor. But like I said, it's more about what's going on in the background.

Microsoft© CCR getting you down?

In my research, which is almost complete, I have come across the first paper that was written regarding the CCR. No doubt changes have been made to it, but it would be a useful read for those who wish to understand it in more depth.

Here it is, and another one:
An Asynchronous Messaging Library for C^#
Developing a concurrent service orchestration engine in ccr

Custom messages using the PortSet

I am not sure whether this is in the tutorials, but I thought I would highlight it anyway. Making custom messages in MRDS is really easy. Also you can pass state information through them. This post should also give you insight into how the request operations on hardware works.

To create a custom message, the first step is to create the request class. This request class can contain data that you want to send through. It is declared in the <dss_name>Types.cs file. Remember that all properties need to be Serializable. That means (a) the class needs to be a [DataContract] and (b) the properties need to be ints, bools, strings, etc ([DataMember]). I do not recommend customizable objects, since these services are actually designed to pass between computers, what good is a local definition? So create the message of the structure you want:

[DataContract]
public class NewMessageRequest
{
    private bool _input;

    [DataMember]
    public bool Input
    {
        get { return _input; }
        set { _input = value; }
    }
}

Then create a class in the <dss_name>Types.cs that inherits from the Update portset:

public class NewMessage : 
    Update<NewMessageRequest, 
      PortSet<ReturnType, Fault>>
{
    public NewMessage() : 
         base(new NewMessageRequest()) { }
}

What is awesome is you can specify the return type. I kinda guessed this behaviour from navel gazing at the code. That means you can post state changes directly back or whatever information you wish. I went for the state, so that the DSS is still 'responsible' for the output it gives. Then you need to write the handler for the request. This occurs in the <dss_name>.cs file:

[ServiceHandler
  (ServiceHandlerBehavior.Exclusive)]
public IEnumerator<ITask> 
    NewMessageHandler(NewMessage msg)
{
    if (beh.Body.Input)
    {
        //perform certain changes
    }
    else
    {
        //perform other changes
    }
    msg.ResponsePort.Post
      (/*ReturnType instance*/);
    yield break;
}

In this manner, you can create customized messages and defer computation to other services, rather than focusing all computation in one service. This is really distributable computing, making use of DSS and CCR.

The pursuit camera

Paul Roberts (blog), the author of the pursuit camera, pointed out that the pursuit camera in fact does follow the bot (I feel ashamed! I was mistaken, I did cross it out...)¹. It just needs to be set in the constructor (See his post - done in code: [Pursuit Camera Service]). But since I prefer the VSE (I have my reasons), I wanted to find out how to set it up from there. I realised what I was doing wrong.

When you create the PursuitCamera, a form pops up with the constructor, just like the TriangleMeshEnvironment entity. You can either set the 'target' property (before creation) or set the TargetName property (after creation).

Just type in the name of the bot you wish to pursue, and it does the rest. It is quite nifty! Just don't set it's parent!

¹ Firstly, I am so sorry for being over-critical before doing my research! It will not happen again. Secondly, thank you for reading a blog as humble as mine. Thirdly: Please keep up the excellent work! I love this framework. If I had children, regardless of their age and gender, they would be programming robots.