Friday, June 20, 2008

C# Windows Forms: Enabling users to resize components at run time

This has nothing to do with the topic of this blog. The only way it relates is the C# aspect. I have been surfing for 2 days and could not find the solution to this problem. I am creating a user control, but the user needs to be able to resize it. Go on, search the net, but you'll find rubbish.

The manner in which I solved the problem is very simplistic. I made the control the "background" to the "main" control (can be a panel) which is smaller and offset to the background. That forms a border, so when you click on the background, it allows you to drag resize. Then all you have to do is fit the contents. I'm pretty sure this is how Microsoft does it.

  1. Create the variables you'll need for maintaining:
    //MouseMove is used in conjunction
    private bool _mouseDown;
    //remember the mouse's original point.
    private Point _orig;
    //for storing the mouse difference
    private Point _diff;
    //the original size of the object
    private Point _size;
  2. Now create a MouseDown method. Insert this code:
        _mouseDown = true;
    _orig = Cursor.Position;
    _size = new Point(Width, Height);
  3. Create a MouseUp method and insert:
        _mouseDown = false;
  4. Next create a MouseMove method and insert
        if (_mouseDown)
    {
    //get the difference
    _diff.X = Cursor.Position.X - _orig.X;
    _diff.Y = Cursor.Position.Y - _orig.Y;

    //change the width and height,
    //relative to the old size
    Width = _size.X + _diff.X;
    Height = _size.Y + _diff.Y;

    //modify the inner object
    innerPan.Width = Width - 8;
    innerPan.Height = Height - 8;
    }
I recommend you give the background a darker colour so that you can see the difference. Also change the cursor using this.Cursor = Cursors.[whatever];

I really hope that you find this via a high-ranking google search. I hate it when websites give bad advice.

Wednesday, June 18, 2008

Creating a custom simulation is MRDS

Today I finally cracked the nut open! I think this may be my first blog of use to someone else. Today I am covering the means by which a programmer can load a custom environment using the simulator and connect it to a program designed in the VPL. I'm doing it really simply so there shouldn't be any tricks.

One thing I noticed is that you can't just define a scene and load it in the VPL. What you need to do is define a scene with all the components that you will be using in the Simulation Editor (right down to the differential drive 'entities') and then load the manifest for the Simulation Environment 'on top' of those components. So it will feel like you are loading the environment several times, when in reality you are just connecting a piece of your robot to that simulation. That's why you tell it to use existing if it has been loaded beforehand.

  1. Start up the "Basic Simulation environment" change the mode to edit and add / remove the entities you wish. They are quite straight forward. I decided to keep the basic entities like the skybox and the floor. I added a the Lego NXT bot, which looks like a box. You can probably load a ton of meshes and get it looking nice, but that is not the point of today. I also added a table, just to see that I could.
  2. Now select the NXTTribot in the editor and expand the "Misc" category. Under the "ServiceContract" field type (or select) "http://schemas.microsoft.com/robotics/simulation/services/2006/05/simulateddifferentialdrive.html"
  3. (Optional) To get the Tribot looking good, select the Tribot and click "Edit Entity".
    Then click the elipses "..." in the "EntityState" property. In the "EntityState" window, click the elipses under the mesh property and select the LegoNXTTribot.bos file. You can make your robot look like anything you like with this.
  4. Save your manifest file. Give it a unique name and preferrably include the date. I saved it under "Samples\Config" since many of them are there.
  5. Now design your VPL language. Obviously I just used one that has a GenericDifferentialDrive. Then you can load the manifest by changing the configuration of the drive to "Use a manifest" and then import your custom manifest.[1]
  6. Run the program. Mine worked well!

[1] This is not possible if you did not load the right ServiceContract The robots are just meshes until you plug that guy in. So the best way to do it is to load a pre-existing SE and then see what contracts are used.

I hope this helps!

UPDATE:
  1. If you struggle with the entity (like getting wheels), then check out THIS POST
  2. Please also be aware that I wouldn't actually recommend you create robotic entities from scratch unless they are really simple. When creating a Pioneer 3DX robot with a LRF, I found that the existence of the LRF made a collision point, making the robot fly off in a random direction. Rather, just edit existing scenes with the robot that you want to use
  3. Comments are welcome on this blog, but please keep in mind you get what you pay for here, I'm trying to help. If you have a question, I'm all ears and I'll do my best. I will not tolerate insults on this blog, that's what my other blog is for.

Tuesday, June 17, 2008

Simulation

This is one of the key areas of Microsoft Robotics, for people like me. The simulator achieves one of the design goals of MRDS: to allow programmers to work on a robot synchronously, while not running the risk of damaging hardware or having to take turns in making use of the hardware.

This is what makes .Net languages so useful in robotics. Microsoft has kept it's eyes on team-based development software throughout their architecture. Most notably (for me) was the invention of partial classes.

Anyway, Sara Morgan defines a simulation for us: "A simulation is a mathematical model that is used to represent one or more physical objects. Data is fed into the model, and the result may or may not be rendered to create a visual three-dimensional image."

The biggest disadvantage from the simulation is the problem of abstraction from reality. What this is saying is that the robot lacks the 'fuzziness' that it would get in the real world. For example, floors are never perfectly flat, however, a plane in a simulator is. Sensor input may also be too clean and the robot may demonstrate strange behaviour in the real world.

What I am really interested in is running a custom simulation through the VPL. I assume this would include loading a manifest file that had my pre-defined simulation engine set as a partner service in the manifest file. I took a look at the Lego tribot in the VPL that provides a SE (under "\Microsoft Robotics Dev Studio 2008\samples\Config\LEGO.NXT.Tribot.Simulation.manifest.xml") and there is a partner service there to "LEGO.NXT.Tribot.SimulationEngineState.xml." Looking at that file it is easy to see how you get your simulation environment included in the VPL. But it's going to take some time for me to figure out the details.

First, I assume you are going to have to define the simulation environment and your robot's components in .Net MRDS code, then in the component code add the simulation as a partner service. Then take your robots components and add them (or their equivalent components) in a VPL and then load using a manifest. I'm still uncertain about autonomy, but this is a big step for me. When I do an example, I'll show you how.

Saturday, June 14, 2008

The VPL tutorials

Just starting on the VPL (Visual Programming Language). I thought this thing was for kids. When I was checking out Lego Mindstorms RCX at the beginning of my studies, one of the main reasons I did not go for it was the provided VPL and lack of support with other languages. Obviously since then, the support has grown and VPLs still exist. What is nice is that I can use Microsoft's VPL and not be confined to the Lego's VPL.

The VPL, as far as I can tell, acts as a 'pleasant' gateway into building a project without having to define every service using code. As far as I am aware, a VPL programmed bot can be ported to a C# (or any other .Net language). That would make my autonomous robots very nice indeed.

If you want to see about code generation: in the VPL, click help --> contents and then click on code generation under the user guide for VPL. There are a few scary things there, but I'm hoping for the best.

I think it's rather unnecessary that Sara did the example with a physical Boe-Bot. I would rather say use the simulation envioronment - that's what it's there for. Not everyone has a Boe-Bot lying around at home while reading the book.

It was at this point that I put Sara's book down and looked at the VPL Introductory tutorials. They do not require any hardware and therefore better suite my purposes.

It's probably better not to ue the XInput controller, since you'll learn a little more about the inputs and controls. Joins are there just to compound data, sort of a struct. The reason forwards, backwards and stop are the same values is that the differential drive will apply the same values to each wheel when performing these operations.

The real power comes in where you don't actually add a simulation environment component, it all depends on what manifest you load. Very cool.

MRDS Architechture

I watched the Architecture video about MRDS and wow it cleared up a few things. I learned what the choice arbiter is for and learned about the join arbiter. I am starting to see why these guys are so wound up about the CCR. This thing is going to break huge boundaries for the future!

The arbiter is a way of waiting for a response from another service. What make it so cool is that it can execute code once this has been done. Further coolness is added by the fact that the sender can have code that needs to be executed. I really wanted to know what all that arbiter stuff in the tutorials was about! I guess just hearing someone explain it makes it so much easier!

The choice arbiter is waiting for one event to happen, while the join arbiter waits for a combination of messages, in any order, to be received. There are other arbiters, but George explains them much better than I do.

Another thing that I haven't mentioned before: Although the CCR is event-based, it is not polling based. This is awesome why? Because you don't have to sit and wait for a result, rather results are pushed back to you. This means you don't waste computation cycles polling - you receive it when you receive it. This makes robotics cool how? Now I just get these messages informing me of different events occurring on the robot, not dealing with the ones I don't have to!

Service Tutorials

Today(with my lifestyle it took 4 days) I'm blasting through the service tutorials one more time. I'm going through them step by step just to make sure I have it down. I want to be really sure before I dive into the next part, either today or tomorrow (sigh).

Once again, they are located in "...\Microsoft Robotics Dev Studio 2008\documentation\MsrsUserGuide.chm" under "Decentralized Software Services" --> "DDS Service Tutorials" --> "C#." I'm surprised to see that it's still C# 2005 based. I'm using 2008 now.

Caution: Don't use underscores in your project name. If you did, just pretend that you didn't...

Wow - let me say the service tutorials have been improved by far. So far I remember having such problems and not understanding - they even give links and tips (for things like attributes). The only thing they missed is when you use the dsshost, you first need to do a "cd.." in the command prompt.

Tutorial 1 and 2 can be completed fairly quickly with no bumps. Just read before you code. I made a few mistakes by getting ahead of myself.

Tutorial 3 reveals a tastey piece of information:

"Returning a task with yield return causes the handler to enter a wait state until the task completes. This allows you to create sequences of asynchronous operations."

That's what I need!

Just a note for service tutorial 5: it gets a little odd. I just recompiled the service tutorial 4 given and then added that reference instead - it is a little different though. The advantage of that is if there is a mistake, you can recompile the service tutorial and make changes.

Also, tutorial 5, last section - I had a bit of trouble because I was progressively using the same file for all the tutorials. I had huge compilation errors with the IncrementTick class being defined in the fifth tutorial. So I just commented out the class and any relating methods, then it worked fine. So I ended up commenting out:
  1. class IncrementTick
  2. class IncrementTickRequest
  3. void TimerHandler
  4. public IEnumerator IncrementTickHandler


I'm stopping at tutorial 5 - I would still recommend tutorial 6 but for now I want to move on with other videos and with the textbooks.

Thursday, June 12, 2008

Snakes in the desert?

Check out this agile robot from the robotics institute:
[Biorobotics Laboratory]

It really is quite amazing.

It got me looking elsewhere:

Tuesday, June 10, 2008

Lego: Education or Base?

I have compiled a list (free for download, compiled by me) of differences between the Lego Mindstorms NXT and Lego Mindstorms NXT Education set. The main idea is to see which one I would rather buy, since they are both within the same price range. I would like to sell my biases from the start: I like the look of the base kit, it looks more serious. The education kit comes with far more 'standard' Lego pieces and, for reasons beyond me, a surfer dude. A surfer dude? Yes a surfer dude. It puzzles me so much.

That said, the education kit comes with something really nifty: a rechargeable battery. Now I remember being a kid and trying to suck batteries out of my parents, which leads me to believe that they might become expensive. So a rechargeable battery is somewhat of a major plus. But the vote may not sway one one component alone, rather get the cheaper one and make up the difference. I'm going to give you my requirement: I want to build cool Lego robots, make them autonomous and get my monies worth. I have many spare bits of Technic Lego from back in my day, and plenty normal Lego blocks from way back in my day.

So here is the approach: I'm going to pretend to unpack this kit and tell you what I get that Billy doesn't (Billy is my exact opposite who gets the Education kit) and tell you how it makes me feel.

The first thing I notice is the Compact Disk for the NXT, which Billy does not have. Billy will have to pay R500.00za (+-$60.00us) to get this. But what does it contain? Just the software for the NXT. I am going to be using C# and MRDS, so really this does not concern me or Billy at the moment.

Now looking at what Billy doesn't have - there are these Bionicle pincer thingies, which I noticed as the 'most important' missing objects. To be quite fair there is useful stuff Billy is missing, but nothing that cannot be duplicated with my pre-existing Lego. If I want pincers I can make them! All in all there are 30 categories missing from Billy's set, with the total number of pieces being 143. But lets be frank: Billy has 86 pieces that I don't (in 33 categories), but I beat him in total number of pieces: 587 to 434. He wins in total categories by three, I have 90.

Ok so I am a bit upset that there is nothing that cannot be made out of my existing Lego to beat Billy's set. It seems like it's just useful pieces that are missing from his set. These things can be collected from raiding a good Technic set (to be honest the same goes for Billy's unique pieces). This is reflected even more so when going down into the overlap. Billy seems to have less pieces overall, but still has quite a few. The standard set seems to be a lot more serious in nature and number of parts, the significant ones are those that have twenty or more pieces, which I do like to have. The one thing I notice is that Billy has one more touch sensor. That annoys me.

Then, looking at what I didn't get: the first fifteen pieces cause me to laugh at Billy, he got some extra bricks. Nothing special. But then I see that (queue heavenly choir) rechargeable battery. I have to have that, no question. The next piece confuses me, the 'electric light and sound brick' which doesn't seem to be too significant.

The conversion cable is for a RCX brick, the sort of 'beta' to the NXT. I laugh at Billy for wasting his money, he in turn laughs at my CD and test pad. The rest of the stuff is pretty standard, but again, I did not get it. Plates are always nice to have, but I have previous Lego. All in all it is the battery alone I want out of that lot.

After consideration I am happy that Billy got what he got, but I'll stick with mine. I have a serious set that may lack a bit here and a bit there, but the girliest thing I got was manly stickers for the Lego. Billy got a surfer dude (and a girl head - why such big hair?) and some unnecessary plates and bricks. The rubber bands hardly qualify for envy. On the other hand, Billy got that glorious battery (takes a 9v charger - easy to find), an extra touch sensor and the electric light and sound brick.

The extra touch sensor really means nothing when you consider the intelligent brick still takes the same number of inputs - only consider this if you (a) really need two touch sensors and (b) are willing to give up one sensor in order to make room.

The CD may become significant when considering that I might need drivers, or just want to make sure the thing works.

In addition Billy's kit comes in a very nice case, but that hardly sways my mind. All Lego is subject to entropy, chaos always reigns the Lego bin eventually.

Additional goodies to think about is the Vernier NXT Sensor adapter, infra-red link sensor, angle sensor, temperature sensor and the USB BlueTooth dongle. I would say I would prefer the base kit to the education kit, but would not argue with Santa either way if it were Christmas. It is really difficult to tell because they do not say at whom the kits are guided. I know the education is based at ages 8+, and I have a sneaky suspicion that the base kit is for 10+.

I would conclude that the education kit is for school students, whereas the base kit is more for general purpose. After saying all of that I know one thing is sure: no matter what kit I buy, I'm going to be raiding the Technics stuff, and visiting a store that sells Technics soon! I still lean towards the base kit though.

Links:

Monday, June 9, 2008

Competitors

As someone who is simply dying to get into this field of robotics, I am keeping an eye open for robotics simulators. One I found (that can be compared to Microsoft's Robotics Development Studio) is the Cogmation Robotics suite. It works with Ageia PhsyX and has a 3-Dimensional simulation environment. The only problem is that it is R600.00za ($70.00us) more than MRDS, which is free.

Other problems are supported robots, the thing about MRDS is that you can actually support your own robots. I have to say I am sticking to MRDS. I have done research previously and found a nice list of simulators for robotics, but none even come close to MRDS.

Links:
[Cogmation Robotics Suite "robotSuite"]
[Simulators]

Sunday, June 8, 2008

A neat toy

You have to check out the i-Sobot by Tomy! This tiny little guy has 17 servo's and is apparently remarkable! As far as I can tell he can be programmed by MRDS, but I all I have as evidence at the moment is a VSE discussion on MSDN forums. Thinkgeek has stock of these little dudes and is very impressed by them.

I would say that programming would be easy if you played the role of the remote control rather than the robot itself. However that becomes wildly absurd when you consider that you would need the sensor information to program autonomy into it. I'll have to do some more digging!

I'm still pro-LEGO, since the robotics can be re-assembled. But the i-Sobot is definitely something I'd love to play with! Also the non-assembly feature of the i-Sobot may be better suited to beginners like me!

Links:

Services cont'd to end.

Still in chapter 2, I have discovered a semi-useful definition:
"yield return allows [the programmer] to iterate through objects returned by a method call." (Sara Morgan)

Then moving on in services, I am reminded (and feel it important to report) that in MRDS, the events that occur around the sensors are pushed through the system, rather than servers having to poll sensors for state changes. This is an awesome feature in MRDS, since polling takes up considerable computation. I learned that from the first channel 9 video on MRDS.

Subscriptions are the means by which services are made aware of events. There are two parties involved in a subscription: the publisher and the subscriber. We need to remember that only certain operations create events (Delete, drop, insert, replace, update and insert), whereas Get and Query do not.

To configure a publisher:
  1. Add the SubscriptionManager service (Using Microsoft.DSS.Services.SubscriptionManager;//some use an alias like submgr). This service maintains the list of subscribers and forwards the notifications to that list.
  2. Create a port that acts as a partner service between the two services.
  3. Create a subscribe message that supports the SubscribeRequestType and SubscribeResponseType.*
  4. Add the message to the list of supported PortSet operations
  5. A service needs to be created for the subscribe operation
  6. Make sure that when the state is changed that the notifications are sent to the subscribers.


Then the subscriber needs to be configured:
  1. Reference the proxy assembly file for the publisher service (this requires building the subscriber). Click add reference and add the ___.proxy.dll file. Proxy files are the means by which services communicate.
  2. Make sure that your code will always reference the correct assembly by changing the 'Copy Local' and 'Specific Version' properties to false.
  3. Add a namespace {alias} declaration to the subscribers implementation class.
  4. Now add the a partner declaration, similar to the one in the publisher.
  5. Add code that invokes the Subscribe operation.


I cannot stress the significance of the service tutorials enough. They really will help when you get to understanding this stuff.

*I have significant evidence now to confirm that messages are in fact classes declared in the {service_name}Types.cs file, then added to the list of avalable operations in the PortSet operations. I know I'm slow... that's why the blog exists.

The next chapter is the VPL. This excites me because the VPL can be used to create an environment and then edited in code. It is probably in this chapter that I will get some autonomy in some kind of robot. That's what I'm hoping for. I'm also hoping to get the Lego Mindstorms NXT at the end of the month, because I have to play around with this stuff more.

Saturday, June 7, 2008

State Management

This is a separate blog because I feel that internal state posting (and other state handling operations) may have significant relavance to AI programmers such as myself. Again, this is a summary for academic purposes and is taken from Sara Morgan's great book "Programming Microsoft Robotics Studio." Buy it.

To post the state internally, the steps are as follows:
1. Declare the necessary state variables for internal storage.
2. Create an additional Port. It is a generic called Port, Sara uses a {string} example.
3. Create a message which is derived from the Update generic class. (b)This will require a new operation type and service handler (for the operation)
4. Add the operation to the operations list in the PortSet declaration
5. Create an exclusive message handler for the new message. (Would have to add code to poll the HTTP port for requests)
6. In order to actually post the data, the CCR Arbiter class needs to be utilized

Unfortunately Sara does not go into too much detail in describing the actual process of doing it yourself, yet. Code fragments are given, but only 3 (out of the 6 stages) and the placement is not clearly defined. As an assumption, I would say that since this is a state declaration, step one and two goes into {service_name}.cs. Since messages need to be managed, step 3 goes into {service_name}Types.cs, the same going for steps four and five since it deals with the portset operations. Finally step 6 I would guess goes in {service_name}.cs since it is associated with step 2, by means of posting data to the port. I did not attempt it as I have no idea how to poll the HTTP port just yet.

I would recommend revising the service tutorials. In fact, I will be going there now. It appears in the 2008 version the tutorials are quite separate. There are two files in the "Microsoft Robotics Dev Studio 2008\documentation" folder: MsrsUserGuide.chm and VseHelp.chm. The VSE is for simulation and the user guide contains the service tutorials under Decentralized Software Services --> DSS Service Tutorials. Just a note: I think it's wrong to call it DSS Service, since 'Service' is included in the acronym. Just a thought.

The service tutorials are way better than when I did them. Go Microsoft! But I cannot find what I am looking for (because it isn't there), so I will continue in slight ignorance and hope that a useful example will come my way when we get into it properly. I assume the most important thing here is to make note of what needs to happen. I think I should carefully indicate my concerns at this point:
1. State variables? What state variables? An example would be much needed for the whole thing if step one is vague.
2. Here code is given, and I can work out where that goes. But in terms of flow I am quite lost by this point.
3. Message? Is this an HTTP or DSSP message? That would mean it goes in {service_name}Types.cs. I hope I'm right, because I assume that this message is the operation that is being spoken of in step four. The message must be a class (due to the fact that it derives), but how am I supposed to know what gets added, considering I even doubt it's position? I am right, it must be similar to the Get class in {service_name}Types.cs, but after declaring :Update I have no idea what values to assume for TBody and TResponse. I compared to Get, but all I learned is that TBody and TRequest are "new() Update operation(s)." I assume that is where step three (b) comes in, but how am I supposed to do that?
4. Easy, that has been covered everywhere and is very clear in the service tutorials.
5. Polling, as I said, the HTTP port is something I still require to learn. Message handlers are covered in the service tutorials, if I am not mistaken.
6. Covered in the book, but placement will be difficult.

That said, I have thought it through and await an answer in the Next we consider state persistence using files.

Notes:
CCR is required in order to avoid threading conflicts when handling inbound requests.

Services

Today's blog content is found in Sara Morgan's book. You ought to buy it since I can't (and won't) re-publish it here for free. Today is a summary of services. Everything here is out of that book. I really recommend you do the service tutorials - it would provide deeper understanding and insight into what is mentioned. This is a summary for academic purposes.

Some terms:
Manifest - is an XML document which stores the services that are to be started.

Contract - Information that other DSSs need so that they may use the service. [MORE INFORMATION]

DSS Proxy - Provides stubs for communicating with the services, rather than allowing other services to directly communicate with one another

Transform - The DSS proxy exposes the service contract, the transform acts between the service and the proxy, making communication possible

Partner - "...represents a service that is tied to another service"

And then some useful C#
When you make a method that has the DATAMEMBER attribute, an intrinsic attribute in Microsoft.DSS.Core.Attributes.DataMember, it is indicating that that the public property must be serialized as XML.

The ServicePort attribute defines the URL of the service! This is where you will be accessing the state information, so make a mental note! It is found where the _mainPort (the type of which is your operations class) is declared.

I also need to learn about the yield keyword in c#. [MSDN]

Useful tidbits
  1. Make sure, in the service tutorials, that you add the name of the operation in the {service_name}Operations PortSet list. It's something I missed the first time
  2. Change the prefix of the namespace. It is found in the {service_name}Types.cs and in the manifest file. It ensures successful DSS in more distributed environments.
  3. The auto generated assemblies: There are three created per service: the service, proxy and transform. The naming standard is as follows: {service_name}.Y{year "yyyy"}.M{month "MM"}.{blank, "Proxy" or "Transform"}.dll
  4. The ServicePort attribute defines the URL of the service (found in the {service_name}.cs file)
  5. Page 29-30 Table 2-3 has the list of DSSP operations (you may write your own, but these are the povided ones)


Messages in services consist of three parts:
1. Action - "Typically ... informs the runtime of an action to be performed." (eg. HTTP GET)
2. Body - "...represents the XML found in the Microsoft.ServiceModel.Dssp.GetRequestType instance."
3. Response port - Informs the user of where to send response messages.

I am looking for the place where the ServiceHandlers are, if anyone has found them in the C# 2008 MRDS version. I would imagine it would have to be defined in the {service_name}.cs file (in the {service_name}Service class), since that is where the _state variable is declared. I inserted the code that Miss Morgan said was created by the VS Template (since I could not find it), and it worked fine. Well, fine in that no errors were thrown, I cannot say that just because no errors were thrown it actually worked...

But regardless, Service Handlers' behaviour can be set to one of five settings: Concurrent (does not modify state), Default (A kind of auto-detect), Exclusive (for state modification service handlers), Independant (will execute concurrently to all behaviours) or TearDown (marks the handler as a one-time operation, after which the service will be shut down).

The partnerships are pretty well covered in service tutorials four and five. I was really scared to run mine, but it worked like a charm!

Extra reading:
[More information on SOAP and HTTP interacting with services]

Friday, June 6, 2008

For beginners like me

Just in case you are wondering...

All you need to install is the Microsoft Express Studio (or professional edition) of your choice (C#, VB .NET, Iron Python, etc.) and the Robotics Studio. Don't get bogged down downloading DirectX, XNA or Ageia Physx until you need it. You should get all you need from two (rather large) downloads.

[Tutorial]

Also I would seriously recommend getting up to date with C#. There are many important little things that really need to be considered. The smallest thing is attributes. These bad boys are used throughout the code, but are thankfully not too necessary to understand when working through the tutorials. I still haven't figured them out, but I think it's more a time issue than a lack of resource issue.

Here are some sites I am reading on attributes:
[CODEPROJECT: Attributes in C#]
[C# HELP: Usage of Attributes in C#]
[C# CORNER: Attributes in C#]
[PROGRAMMING C#: Chapter 18]
[MSDN C# DEVELOPER CENTER: Attributes(C#)]

The next issue is services. I would recommend writing a service and testing it out. Especially if you use VISTA (which adds complications). Here is a tutorial that works perfectly (I wrote an SMS service in VISTA - and the tutorial is meant for XP, so it is good) [ARCANE CODE: Windows Services in C#: Getting started].

The tutorials. Yes. Go through them. They are useful, the service and simulation are the ones I went through. They are installed on your computer when you install the robotics studio but can be found equally easily online. One tip - be careful of names and locations. When I did the first tutorial it generated my files in a different location to what the tutorial said. So don't give up, a butterfly mist force it's way out of the cocoon, otherwise it dies.

I completed all the tutorials successfully, so there is no problem there. The problem with MRDS at the moment is that there is very little documentation, but that is being rectified. Also the tutorials do not cover the much needed "Start from square one" case. That is one thing I will cover on this blog. But so far I have not come across such a tutorial.

Then do some reading. That is where I am. I need to figure out attributes in C# while I do that. Currently I am reading Sara Morgan's book "Programming Microsoft® Robotics Studio". I am on chapter 1 and it is choc-full of good and useful information. But get caught up with DSS and CCR, as well as DDSP. She covers them but also recommends extra study.

I have had a good discussion with Trevor Talor (Author of the brand-spanking-new "Professional Microsoft® Robotics Developer Studio") over at [MSDN Forums]. I would recommend reading the discussion, it has a few useful links and information (for example C# Express and "Start External Program").

Thursday, June 5, 2008

More about me

I am currently at the end of my masters in Artificial Intelligence. When I began in Jan 2006, I really wanted to build a robot. I had a look at LEGO's Mindstorms but back then it was incredibly basic and fairly unheard of.

So my supervisor convinced me to do simulated robotics. I had no idea what was ahead of me for the next two years. I developed a graphics engine in DirectX, but that got as far as a sky box with a floating tiger mesh.

Well, it was a relief to see that Microsoft has now done all the work that I need not do. I have looked all over the show and trust me - there is one way to go, at least for now. This is free for academics, ready for rapid development (.NET framework) and is cutting edge.

Anyway, my topic is, in a nutshell: Developing specialized software to enable generic intelligence objects to be embedded inside simulated robotic agents, within a multi-agent context. It gets me no where with the ladies ;P

So the robots are not the most important part. However the very architecture of the MRDS is suited to my topic. The DSS and CCR runtimes both deal with distributed asynchronous objects, which I am going to apply to objects that enable intelligence. My masters is pretty large.

But I am close to finishing. I have all the theory on paper and I am now beginning the practical leg. I am hoping that by learning the MRDS framework that I am opening new doors for myself academically. My hope is to open a door in my lecturing career (and possibly PhD).

Welcome to robotexodus!

This blog is my journey into robotics. I am currently a Lecturer at the University of Johannesburg. I have always been involved in software development (I am finishing off a 6 month industry 'spat'), but prefer the Academic side to things.

I am trying to finish off my masters in computer science. I started off with no knowledge in robotics, but thanks to Microsoft's Robotics Development Studio (MRDS), I will hopefully be able to finish off in style and 3D.

This blog is a reference blog for those wishing to learn MRDS. I will detail my experiences (when I can), so that my mistakes need not be repeated. I also need a repository for the information I collect.