Jon Simpson

On Robotics Abstractions (or: How robots can't take over the world, yet)

9 May 2006 — robotics, occam-pi, transterpreter

In trying to program for real-time control, good platform-assisted concurrency is vastly useful. It seems sensible to keep the limitations of a sequential execution process out of the actual software and instead, in the underlying runtime. (see TVM). Highly concurrent runtimes for small devices aren’t prevalent, and a lot of work with small robotics devices in an educational scenario is an almost LOGO style approach of entirely sequential actions.

The idea of being able to do entirely unrelated, or just things that aren’t mutually exclusive comes naturally to us as humans, and it seems logical that we should take this kind of approach when programming robotics systems. The problem being that robotics platforms, as mostly mobile, bare hardware interfaces lack commonality in their programming models (and a common runtime, for that matter). There are people thinking about how to deal with this already and creating runtimes that provide concurrency primitives across many small platforms (including a number of common robotics ones).

However, the runtime is just part of the battle. Being able to express a way of interacting with the environment that is not specific to any given robotics platform, and is instead an expression of what stimuli and controls are needed to achieve a given result could also be of benefit. Due to the nature of most general purpose (generally available?) robotics hardware, its hard to define these abstractions without artificially limiting some devices (say, a fairly expensive Pioneer robot running Player/Stage) or running into limitations on small devices (say, the Lego RCX).

A cleanly architected model might allow us to add additional/optional blocks that interact with process networks to bias and influence their behaviour, given a particular piece of hardware functionality is available, and paring down to a core functionality that can occur on the lowest possible subset of hardware. (This, however, reeks of singularity for its own sake…)

Is there an inherent value to this? I don’t know… But the idea of scaling programs along with hardware capabilities is something potentially interesting.

Disclaimer: Its revision season and I’m just emptying my head of a few things I’d been meaning to post here for a while. I have no doubt this piece contains wild generalisations, factual inaccuracies and grammar errors galore. But at least its here and to me, that’s something.