Sunday, October 31, 2010

First successes in robotics

Two months in this school year have passed, and a lot has happened. Most of our project work up to now was just research; we evaluated the JADE framework for distributed agent systems, the rule based language JESS, and the Protégé Ontology API, which all are Java based and can therefore run on the CBC controller.

On friday, Dr. David Miller arrived at Vienna, and our teacher wanted to have a robot prototype to show. On wednesday, we met at university to build something out of lego... which proved to be difficult, because the collection of Lego parts was very limited, and we hardly managed to connect a single motor to the lego gears. So we met at my place the next day and built a robot out of Fischertechnik which is, in my opinion, clearly superior to Lego. The result was this robot:

Each of the tracks is powered by two motors, although that didn't seem to bring much of a performance gain. The thing on top, in case you didn't recognize it, is a camera, and the robot's objective was to follow a blue ball.

We actually programmed the robot twice; once with C, which is natively available on the controller, and once with Java, which was installed on our controller at the university during summer. My part was the Java program, and I tried to add a few abstractions to later reuse the code.
  • As each of the tracks is powered by multiple motors, I added an abstraction for the motors, to combine multiple physical motors into one logical motor
  • Next was the drive and navigation. Our robot is tracked, so its steering uses the speed difference of the tracks. I tried to keep the theoretical possibility to use another type of steering, although some adaption is probably necessary.
  • Last but not least, the robot's construction may make it more convenient to wire it in a specific way. What actuators and sensors are on which pins can be configured, so that a new construction does not necessarily mean to change the program. Especially imagine how many times a motor may be accessed in the program, and what it would mean to change all the occurrences.
Now this is just foundation code, and the real logic, checking the camera and following the ball, was simply implemented in the main method in a loop. And that's the glorious result:

For those of you that don't understand the quiet, german comments: We have adjusted the camera for our lighting, and it already got pretty dark. For the video, we turned on the lights, and suddenly, the robot stopped recognizing the ball. So, the first thing you see in the video is me turning off the lights again, and then you can hear my teacher commenting on it^^

Saturday, October 2, 2010


One part of our project will be to build an ontology for our robot. An ontology is a model of the world, condensed into the relevant parts for a given problem. For example, our robot will have motors, digital and analog sensors, and so on. These would be represented in the ontology, but possibly more, like a simple model of the robot's surrounding: Hills, obstacles and so on.

At school, we're using a really easy-to use Ontology editor called Protégé; it also has some nice visualization features. The result might be an "owl" file; a standard xml file for ontologies that can easily be accessed from a program.

I'm just starting to learn this topic and not quite sure what the advantage of an ontology as opposed to e.g. an object graph is. Both model reality in some way, both are hierarchical and have properties, reference objects and so on.

One of the differences is that an ontology also models the objects, the individual instances. For example, you might model a city's subway network. In a class hierarchy, you could only model things like Subway, Station and whatever is needed for the model. Creating the objects will either mean hardcoding them or writing some code that reads the objects from a file; the former is inflexible and the second is error-prone and redundant. An ontology can (and will) contain the explicit lines and stations of the city along with the definitions, and neither of the above is needed.

The second diference is its position in context with reasoning. Reasoning is the main reason for the existence of ontologies, and therefore there are a few (hopefully good) APIs out there that make it easy to write statements like "how many stations are there on subway line 1?" or "should I go left or right around the obstacle to reach my target faster?"

And this is where we get to rule-based programming. Pulling conclusions out of the ontology is half of the work of writing a rule. See you next time!