Building Bridges
Robotics is not a very young science, and yet there are considerable
gaps between the ways in which robotics is used, and the cutting edge
of robotics research.
In my own area I am particularly concerned with the gap between the
state-of-the-art in the planning of moves for robot manipulators, and
current requirements for robots in industry.
Put crudely, those on one side of the divide think in terms of
configuration spaces and AI search techniques, whilst those on the
other side are thinking about loop gains and touch sensors.
That there is such a divide was tacitly recognised a decade ago, with
the start of a move from mathematically perfect concepts
such as configuration space, to more holistic approaches like the
subsumption architecture.
Essentially, one part of the robotics community gave up on the idea of
building an internal model of the world, and decided to use the world
as its own model instead.
This is not to denigrate the subsumption architecture and those that
have followed;
they have supplied a whole set of practical solutions to practical
problems.
However if we want to be able to devise devices that are adaptable and
that can ``think ahead'' then some model other than the world itself
must be used.
One of the biggest bugbears of the perfect modelling approaches of ten
years ago was speed, especially for motion planning.
However by using smarter algorithms, by replacing concepts such as
`completeness' by `probabilistic completeness', and by using today's
computers, speed is no longer the major obstacle.
There are several problems remaining though:
- Object Complexity.
Robotics researchers have tended to build models of the world that are
simple in both form and complexity.
However real-world problems in, say, manufacturing, involve objects
designed on CAD systems that have large numbers of geometric elements
and specific form features (e.g., mating surfaces).
The presence of such complexity often overwhelm current planners.
- Imperfect Models.
Real-world objects do not agree with their models at every level of
detail.
Although this does not matter for some problems (e.g., gross motion
planning), it is critical for others (e.g., peg-in-hole insertion).
- Run-Time Errors.
Even if the plan and models were perfect, our robots are not.
Planning researchers cannot continue to ignore the run-time environment.
In Oxford we have been looking at ways of closing this gap between theory
and practise for many years.
We started with relatively simple systems (mobile vehicles),
and have been extending our ideas in a controlled manner to more complex
systems (manipulators).
I now believe that we have come up with an idea that is so simple that
it might just work,
and we are starting to build the tools to test the concept on a large scale.
The idea has two parts, one of which is long-established principle of AI,
and the other is one that attempts to deal with the problem of geometry:
- Problem Decomposition.
This is a standard problem-solving strategy, whereby one has a hierarchy
of scale, and you solve the problem at different levels and combine the
results.
As an example that we have studied previously:
a task planner for mobile vehicles will first decide which vehicles
will be assigned which tasks and in which order,
based on positions only;
this is followed by a coarse path planner,
which generates rough paths based on a choice of approach directions;
and finally a fine path planner generates trajectories based on
detailed knowledge of the vehicle and load characteristics.
- Using Proximity.
We wished to avoid overloading the planners with too much geometric
detail,
and have discovered a simple, but effective, method of doing so.
We allow the planners to ask about the proximity of objects,
with the answers being returned as a small vector of real numbers.
Thus, for example, our vehicle planner asks about Euclidean distance
(i.e., `what are the things close to me?'),
and about distance to an obstacle in a particular direction
(i.e., `how far can I move in a given direction?').
Using proximity in this way means that planning competence and geometric
competence can be separated in an overall planning program.
This makes the planners short, and easy to understand and to maintain;
for example, our vehicle task planners use a rule-base of 10-100 rules.
Furthermore, if the geometry gets more complex, then the code
that computes the proximity measures may take longer, or need upgrading,
but the planner can often stay the same.
Our earlier results showed the feasibility of this approach for robot vehicles,
which of course have no more than three degrees-of-freedom.
More recent results also show that the technique extends nicely to
complex robot manipulators as well.
Of course, there are always problems which really depend for their
solution on an intimate knowledge of the robot and its environment:
mating problems spring immediately to mind,
and in our vehicle task planner we assume the existence of a low-level
competence for docking that would be implemented using a run-time
feedback loop.
Even so, we claim that many planning problems in practical robotics could
benefit from this separation of planning and geometry,
even if only at the prototyping stage.
To demonstrate this further we are constructing a shell for building
planners called OxSim,
which contains a domain dependent low-level planner,
an efficient routine for computing distances,
and connects to a high-level planner (or planners)
and to a geometric modelling system.
We expect to eventually demonstrate this system constructing plans
for the aerospace industry,
in which a robot manipulator has to work within tight spaces
in an environment that is geometrically complex
(i.e., large numbers of curved facets).
Initially these experiments will deal with off-line planning only,
but we believe that the same ideas also provide a convenient bridge to
run-time systems.
Sensors are, for the most part, devices that return range data to a greater or
lesser degrees of accuracy.
Thus by modifying our proximity measures slightly we should be able
to take a reactive planning architecture, and use it for off-line planning;
and by simulating uncertainty in the proximity measure, to produce plans
off-line with some measure of certainty that they will execute off-line.
|
|