However, I have made a bit of a start on the PhD work. I’ve got a couple of books out the library which seem like they could be useful (I was further encouraged to see the same book on someone else’s desk, I must have made a good choice). I’ve also spent a fair bit of time finding papers relating to robotic navigation (generally from Space Robotics) and I read an interesting PhD thesis on autonomous scientific target identification for rovers on Mars (always a good idea to see what you’re ultimately aiming for). Otherwise, for the moment, I’ve spent a lot of time playing (by which I mean designing, ordering components and building circuit boards for the Argo; so I can actually do some research – honest).

I seem to have been in quite a number of meetings with people from the Geography department (who, despite having a reputation for colouring in maps seem [as you would hope] very knowledgeable, friendly and helpful) in an attempt to get a more concrete idea of the environment in Greenland that the Argo is likely to encounter. For the most part it sounds like there is little to worry about in March/April time; the melt season hasn’t  (usually) started and any holes are usually snow covered to a point that they can support vehicles. However, we still don’t want to risk having an Argo drive down a Moulin and so in some respect, although the snow may seem like an advantage, it actually causes more problems; how do you identify a hole that isn’t there? Another reason for these meetings has been to identify exactly what it is that the Geography department are interested in, in terms of scientific data. Whilst it is possible to do lots of ‘surface analysis’ (snow coverage, storm and weather analysis, etc) and to develop high detailed Digital Elevation Models or DEMs (we’ve talked about tethered balloons with sensor equipment mounted, laser scanners, IR, camera systems, etc) they are much more interested in what is underneath the ice. So, at the moment, there is still a considerable amount of work to be done to identify which sensors we will and will not be installing on the Argo for deployment.

More recently I’ve been having some interesting ideas about other fun things to do with the Argo. In particular (and highly related to other research being undertaken at Aberystwyth within the Intelligent Robotics Group) I would like to try and have a go at getting some kind of  developmental learning algorithm on the Argo so that it can learn its own capabilities and learn to drive.

For the next month I’m going to be pretty busy sorting out the Argo, though I would very much like to start writing some of my thesis. Whilst most people I have spoken to seem to suggest it is very hard to complete a PhD in the 3 years and they usually use the 4th year for writing up, I would like to complete my PhD on time! So, looks like I’ve got a lot of work to do. I’ll try and keep this blog updated, even if it is only once a month, it’s still better than last year – so far so good!

Until my next (hopefully more interesting) post!

Although my phone camera is pretty useless (or I am) I did take some photographs and a short video of ‘Robothespian‘ who was on display for the final day of the conference.

During the final day of the conference there was a particularly interesting talk by Mike Smith from Oxford University on ‘Generating Implicit Surfaces from Lidar Data’. Most interesting was a technique he detailed from an earlier paper written by him and his colleges on ‘A generative framework for fast urban labelling using spatial and temporal context’. In essence this was a means of identifying surfaces and giving them labels such as ‘Tarmac’ in real-time. I hope to investigate this more and see if it can be used with the ARGO to help with dynamic surface type identification and control system tuning.

I thoroughly enjoyed the conference this year and look forward to participating again next year (hopefully) – but for now, those interested can find the slides from my talk here. As always, I welcome any comments and suggestions from those present; or anyone else for that matter.

The other day I wrote a small tutorial on getting dynamic class loading working for Java. In that post I mentioned that it could also be done in C# – but that it was more difficult, and from my personal experience, there is less information available about it – so here is how to do it!

First, as with the Java, we need to create our API. However, unlike the Java there is an additional requirement – a ‘module manager’ class needs to be within the API. As such you will need to create these two files…

using System;
using System.Reflection;

namespace com.michaelclarkeblog.dynamic.api {

    public static class ModuleManager {

        public static Module getInstance(String fileName) {

            /* Load in the assembly. */
            Assembly moduleAssembly = Assembly.LoadFile(fileName);

            /* Get the types of classes that are in this assembly. */
            Type[] types = moduleAssembly.GetTypes();

            /* Loop through the types in the assembly until we find
             * a class that implements a Module.
             */
            foreach (Type type in types) {
                if (type.GetInterface("Module") != null) {
                    /* Create a new instance of the 'Module'. */
                    return (Module)Activator.CreateInstance(type);
                }
            }

            return null;

        }

    }

}

using System;

namespace com.michaelclarkeblog.dynamic.api {

    public interface Module {
        String getText();
    }

}

Once you’ve got the two files you can compile them into a library….

api $ mcs -t:library Module.cs ModuleManager.cs
api $ ls -a | grep .dll
Module.dll
api $

Now that we’ve made the API the next thing to write is the application that is going to use it for loading modules. This is a very simple application…

using System;
using com.michaelclarkeblog.dynamic.api;

namespace com.michaelclarkeblog.dynamic.application {

    public class Application {

        public static void Main(String[] args) {

            if (args.Length > 0 ) {
                Module module = ModuleManager.getInstance(args[0]);
                Console.WriteLine(module.getText());
            } else {
                Console.WriteLine("Usage: mono Application module_name");
            }
        }

    }

}

Now we can compile our ‘Application’ against the API…

application $ mcs -reference:../api/Module.dll Application.cs
application $ ls -la | grep exe
-rwxr-xr-x 1 michaelfclarke michaelfclarke 3072 Apr  5 19:32 Application.exe
application $

And now finally we can write a couple of modules!

using System;
using com.michaelclarkeblog.dynamic.api;

namespace com.michaelclarkeblog.dynamic.modules {
  public class Mike : Module {
    public String getText() {
      return "Hello from Mike's Module!";
    }
  }
}

using System;
using com.michaelclarkeblog.dynamic.api;

namespace com.michaelclarkeblog.dynamic.modules {
  public class Another : Module {
    public String getText() {
      return "Hello from Another Module!";
    }
  }
}

Compile the modules…

modules $ mcs -t:library -reference:../api/Module.dll Another.cs
modules $ mcs -t:library -reference:../api/Module.dll Mike.cs
modules $ ls -la | grep dll
-rwxr-xr-x 1 michaelfclarke michaelfclarke 3072 Apr  5 19:36 Another.dll
-rwxr-xr-x 1 michaelfclarke michaelfclarke 3072 Apr  5 19:36 Mike.dll
modules $

There is just one last thing we need to do before we can run our application. We need to copy the Module.dll API from the api directory into the application directory…

modules $ cd ../application
application $ cp ../api/Module.dll .

And now lets try running our dynamic application…

application $ mono Application.exe ../modules/Mike.dll
Hello from Mike's Module!

application $ mono Application.exe ../modules/Another.dll
Hello from Another Module!

application $ mono Application.exe
Usage: mono Application module_name

Questions may (or more likely not) be popping into your heads now regarding this need for more time. Surely now I’ve graduated from my degree I should have all the time in the world – I should be working in the day and have my evenings for my own, or perhaps I should be travelling the world, taking a gap year – a whole host of possibilities! Nope, wrong, being the numpty that I am, I have taken up the opportunity of a PhD with Aberystwyth University. Yes, yes, I know – three (ehem, more like four) more glorious years of researching (read as playing), writing papers (also read as playing), rushing towards the day that my viva will come (read as not another exam) and I will have to show the worth of it all. But, until that day, I figured what a better place to record my strife (playtime) than to blog. Now, I know I’ve said this before. Indeed, in the past I have promised great things - particularly during my final year project! All those hours of footage, photos, code updates you were expecting from my MEng dissertation never did materialise. However, this time, as a ‘mature and professional postgraduate student’ I hope that such things will be more… apparent.

It is my wish to keep everyone up to date and informed as I progress through my three years as a PhD student, and indeed hopefully at the end of these three years I will have a valuable resource full with details of experiments, papers, and notes to help me with finishing my thesis. Well that is the cunning plan anyway.

So, to start it might be prudent to give a general idea as to the topic of my PhD and a few more details. Those who know me will be aware that during my final year of my masters degree I became particularly interested in robotics. Until this point robotics had (to me) been a ‘interesting topic’, but one that I didn’t really have much time for. When I say “I didn’t really have much time for”, I don’t mean to suggest I disliked robotics or thought it “wishy-washy”, more that I was far more interested in operating system design and theory. As a result of my masters dissertation I have “found time” for robotics and in the course have managed to get a paper written (due to be published at the Towards Autonomous Robotics Systems (TAROS) conference at the end of August 2010 in Plymouth). So, how does this lead to a PhD? Well, apart from anything else I applied (a good start), and was accepted pretty quickly. But, as anyone who has ever applied for a PhD will know, this is only the start of the story. Funding is the show-stopper!

I made various attempts to get funding – through the Aberystwyth Postgraduate Research Scholarship (APRS), a PhD scholarship with EADS, and even a Research Associate job within the Department of Computer Science at Aberystwyth University. However, all of these attempts were either unsuccessful or are still pending and stuck due to contract issues (most likely intellectual property but I’m not 100% sure myself). So, very kindly, the Computer Science department and Geography Department have agreed to jointly sponsor me for my first year until I can sort out more permanent funding. There is a catch – I am expected to (still within my interests and within the scope of a PhD) work on a project that they want. That project revolves around automated surveying of glaciers, ice caps and the water flows under these massive ice blocks in and around Greenland. As such, my next three years will be spent building robots to collaborate and automate complex and often life-threatening scanning and surveying of such glaciers, etc.

I must admit that my knowledge of ice (as you may have noticed) is somewhat lacking, and so this part is going to be a considerable learning curve. However, I always enjoy a good challenge and am really starting to look forward to my starting date of the 27th September 2010; but before then I intend to take it easy, relax a bit, perhaps start writing my lecture slides (did I mention I’m teaching some of the CS101 Computer Science module this year?) and at some point write my talk for the TAROS conference (I will blog nearer the time and let you all know how it goes).

However, for now, I think I have rambled on long enough and I’m sure you’re all quite board now. So, until the next episode.