Visualisation!
August 23rd, 2010I was toying with the idea of setting up a whole new blog to cover some research-centric posts I’ve been wanting to write, but since I really don’t want to work out a new template design, I’m just going to shove them here instead
In this post I want to talk briefly about some work I’ve been doing writing a visualisation system for the research I’m undertaking. In a mad moment of satisfaction I posted a screenshot of it to Twitter, and it generated enough interest that it seemed worth a wee explanation.
Background
In Automated Planning we typically describe the environment we want to work with in a language called PDDL – the Planning Domain Description Language. This has three principal components :
- A list of the possible actions that you can undertake in the world, the facts that have to be true before the action can be undertaken and the way the action changes the world.
- A complete listing of all the facts that are true in the world initial.
- A list of the important facts that must hold true for the task to have been satisfied.
Typically this is split into two parts, a “Domain” description, and a “Problem” description. This might give you a domain that says there are trucks, planes, packages and locations and you can move the planes and the trucks between locations and load and unload the packages onto trucks or planes. That might look something a little like this. Then you have a problem file and that tells you how many of each different thing you have and how everything is linked together.
So far so good.
A Reformulation
The problem is that all of these facts that can be true or false is pretty miserable, and for reasons that I’ll get into in another post sometime, what is really needed is a different kind of representation, one that has replaces high number of variables with a low number of possible values (in this case two) for a low number of variables with a higher number of possible values. It turns out that you can do the translation between the two automatically, and what you get is a long-ass file that really is next to unintelligible if an actual person reads it. Which sort of sucks, since a lot of this stuff needs to be debugged in the model to verify that the information being fed into the AI system makes sense.
Not only that, but the way I’m working with these graphs means that I want to track which variable has what value currently, what value it needs to take in the goal state and how the values can change within a single variable. Previously that has meant reading a _lot_ of command line output and getting pretty good at parsing a lot of data on the fly – as well as spending a lot of time going through the output looking to see where the system went haywire.
Visualisation’s what you need (if you want to be a record breaker)
So the obvious solution has been to develop a visualisation system. It turns out that this isn’t _so_ straightforward, as it means writing a GUI algorithm that can take any kind of graph description and turn into a representation that can be displayed in an application and updated on the fly. Arranging a graph of unknown size and connectivity on the fly is a difficult problem it turns out, and inevitably, the old stalwart dot (or more accurately his cousin Circo) has been employed to enhance it. The upshot of this system is that I can take a PDDL representation of a problem, translate it into SAS+ using a slightly modified version of Helmert’s script, parse that into the formalism used by my Integrated Influence Architecture, load it into the architecture and get a nice pictorial representation of what exactly is happening in the guts of the thing, and how the world my agent is operating in is actually put together. This makes debugging your models a lot easier since you can actually see the operators and transitions in front of you
Colourisation
One final note is on the colouring of the nodes within the graph – this is part of the architecture that I mentioned above and represents the result of applying a “clustering” algorithm to the graph. Essentially it is a load of fancy maths which boils down to grouping nodes that are close together, the idea being that then the AI system can focus on traversing between the clusters, which will save quite a bit of computation micro-managing how it moves within specific clusters of a graph, thus breaking a problem into essentially “bite-sized chunks”. You can read more about this in the paper detailing the process which will be presented next week at the International Conference on Intelligent Data Engineering and Automated Learning.
Comments, questions and criticisms are more than welcome in the comments – obviously this isn’t groundbreaking stuff but I’m pretty chuffed with it and with a bit of luck it will be of real use to me. If anyone wants the source, they’re welcome to it, but as it relies extensively on having the right python libs in exactly the right place and other hackery, I’m not at this moment going to put it out there for absolutely everyone to grab and them mail me that it doesn’t work – it’s awful hacky, so if you do want a copy, be warned!
Finally finally finally, I’d be remiss if I didn’t explicitly thank the following folk for their contributions : Malte Helmert for writing the original PDDL -> SAS+ translator, Christian Muise for the KRToolkit and extensive Python support and AT&T Labs for the GraphViz toolkit and the Grappa Java library




