Friday, 24 July 2009

The Stone Age.

I was having dinner with lots of computer sciencists last night, these things happen in academia (I love my job). The older scientists told us all stories about what it was like to do computer science in the olden days, particularly one of my supervisors, Professor Alan Winfield. He's a real engineer! I don't want to spoil his anecdotes, but this is amazing. When he was doing his PhD back in the 70s one of the academics very excitedly brought in their new (first generation) Intel processor. There was absolutely no software running on it (like y'know an operating system) it was just some hardware attached to a board. Without any support. So what him and a few others did is develop a compiler for it and a system for downloading code and a bootloader and all the stuff that's needed to just make the thing work (same story as told by Alan). These days just one of those things would be a phd worthy endeavor, they did it just because it was there! I wouldn't even know where to begin, I don't know what a bootloader even is. It's amazing, I have a Master's degree in electronic engineering and I know NOTHING about real engineering like that. How was it possible for me to get that degree? When I went to Aberystwyth there were guys there (specifically Mark Neal and Colin Sauze) and they could just knock together some stuff and it becomes a fully working robot!
Anyway, back to the point. Alan's mentioned that they transferred code between their giant processors and computers using punch cards. Punch cards! Really that's only one level up from bashing rocks together. To debug their code it was easier to edit it on the card than in the code on the processor, he would de-bug stuff using a hole punch and some white tape. He had another story about how he de-bugged a problem in his code using an oven! Computer science, it would seem, was difficult in the past. You wrote a program and the next day it would be compiled, the day after that you might be able to get time on the university computer to run your code. What discipline it must take to make your code perfect first time. How much dedication must you have needed to de-bug something on punch card or wait 2 days to find the results of your code?

The point I'm making here is that technology has come a LONG way since the late 70s / early 80s (hereafter refered to as "the stone age"). Even during my lifetime there's been a hell of an improvement. During the same time there's been a dumbing down of us as computer scientists. I don't think I know anyone (apart from Alan obviously) who is so very capable and dedicated that they could work with this old technology and remain motivated and sane. The sheer range of knowledge required is astounding! So much of this tedious, difficult work is done for us these days. It's easy to write something that doesn't quite work, there's no rigour. I don't need to read and re-read my code to check for syntax errors or memory leaks: it takes 2 seconds not 2 days to compile and run code. The level of dedication and perservance that was required to complete a computer science PhD in the stone age has been lost, what will things be like in the future when I'm Alan's age? Will I be telling the young students about how when I started university computers only had ONE core? Will the role of programmer be usurped altogether? Will robots assemble themselves out of a heap of compoent parts? Given the current rate of technology development the gulf will be even bigger than the current stuff and punch cards. A prospect both scary and exciting. Exciting in that we'll have new toys, but scary to consider how much lazier we'll have become.

Tuesday, 14 July 2009

Interactions Between Learning and Evolution

David Ackley and Michael Littman (1991). "Interactions Between Learning and Evolution", In: Proceedings of the Second Conference on Artificial Life.

New paper added to my reading list.

This is a very interesting paper about some agents that can learn and also evolve. The learning happens over a short time span, the lifetime of an agent, the evolution happens as agents reproduce and populate the simulation. The agents use two neural networks as controllers, one of them is an 'action network' which controls how the agent reacts to a situation. The other is an 'evaluation network' which is how the agent decides what is a good situation and what is bad. The evaluation network and the initialisaiton for the action network are inherited from parent agents. So natural selection controls what the agents think is good or bad, and how they will initially react to stimuli in the environment, and over time the agent will adapt its action network to learn behaviours that result in situations it believes are good. The agents' aim is to live for as long as possible and to reproduce as often as possible.
The simulation they used was apparently very difficult to survive in, which skewed their results a bit (it made evolution a bit crappy for instance because agents, and most of the population, died before they could pass along genes). The results they presented of the one population that lasted over 9 million time steps were interestin though. They showed how having the population start out knowing that food is good eventually led to the agents instinctively getting food, it also showed that when the agents start off instinctively avoiding predators their evaluation of whether predators are good or bad had little effect. These results are somewhat contradictory but the experiment was successful in that the agents lasted a long time before going extinct.
Overall what they present is a very interesting control structure, and I think how they implement instinctive actions is quite clever (but smart people might think it was obvious) the paper leaves me wondering what would happen if it was easier to survive in the simulation, (probably there would be less adaption and the experiment would be much less interesting).

Monday, 13 July 2009

Finally, a Player/Stage Manual

Well, the Player/Stage manual I've been talking about for so long has finally been released!
I've knocked together a basic web page about it on my work website:
  • Player/Stage manual

  • It's also been published on the official Player/Stage Website by Richard Vaughan. This makes me very happy! So far the only feedback I've had about it from people (these were the folks working from the first draft) was that it's great. Personally I just hope I haven't got things horribly wrong. The manual's been released a bit too late for this academic year (as far as students doing their final year projects are concerned) but I'm hoping it could be more widely read now.

    Tuesday, 7 July 2009

    Player/Stage Manual redux

    The Player/Stage manual is finished!
    The rest of this week will be sent sending it people so they can check it for typos / errors and then I'll release it here, my website and (hopefully) to the Player/Stage website!
    I'm very excited that I've actually seen this (very long) project through and I can really add something of value to the robotics community.
    At the start of the AIR 2009 summer cam we had to make presentations about who we were and what we do, I mentioned that I'd written a Player/Stage manual and there was a collective sigh of relief and cries of "Publish! Publish now!". It really surprises me that no-one's done this earlier. There seems to be such a massive demand for it?
    Anyway dear readers and people who search for "Player/Stage" in Google, wait until next Monday (the 13th July) and you'll be able to download my manual for yourselves!

    ETA: see my next post about the manual.

    Friday, 3 July 2009

    AIR 2009 in retrospect

    After the first two days of lectures we then went on to work on a project in teams. My team were working on an autonomous sailing boat which uses an artificial endocrine system for fault tolerance. Our goal was to make the boat maintain a heading, so for instance it should always try and point towards north, if we can do this then the boat will move in a straight line. The difficulty was that the boat doesn't have a rudder, it steers with two sails, one at the front and one at the back. We only had 3 days to do this work in so although it doesn't sound ambitious it kept us very busy! The main problem came with communicating with the PIC on the boat since you can only receive information every so often without causing latency issues. We spent a long time solving this problem and cursing the PIC. I think it was a problem with the API or something. Anyway we managed to get it working and it can move in the direction we tell it to. It doesn't point the right way whilst doing it... it tends to oscillate around the goal heading and slows down a lot when it faces into the wind but it does move in the right direction.
    Now the research camp is over my team (including me) are writing a paper for submission to UK Computational Intelligence in Nottingham. It'll be my first publication!

    Overall the research camp has been a really good experience and I've learnt a lot about robotics and teamwork. The location, Aberystwyth, was also lovely and I miss the epic scenery and the beaches and lakes. I hope to go back soon! I would thoroughly recommend the summer camp to anyone who's interested in robotics as part of their PhD, there were even a couple of people there who knew nothing about robots and it was useful for them too. Very highly recommended, kudos to Martin Huelse for organising it.