Thinking further about subdivisions of parts, I realise that I also
neglected the structural components. So with the above terminology change,
and the addition of ``chassis'', I think we have six labels which cover
all aspects of the design:
control, movement, sensors, effectors, power, chassis
I'm not advocating that any of these can be designed or operated in
isolation. But thinking about these as modules which offer services and
make demands between each other across well-defined boundaries makes
planning much simpler. For example, the design of the rangefinding
sensor (if we have one) doesn't have anything to do with the choice of
drive motor, and therefore the details of these things can be decided
independently. However, both parts make demands on the power supply,
and limits to those demands must be specified.
> The reactive, behaviour-based robots move in real time at real speeds
> and deal with obstacle navigation without being specifically programmed
> to avoid those obstacles. ...
> As to what I mean by 'much more', I mean the finished robot should be
> more than the sum of it's parts.
Watching complex behaviour emerge from simple rules and components
is fascinating, and I hope we will indeed see such behaviour.
What I would really love to see is a herd of Mowbots figuring out how
best to co-operate, but that might be a bit beyond my budget:-)
> The key is that these behaviours are all running concurrently with a
> high refresh rate, the reactive process makes sure the robot deals with
> the world as it occurs, rather than gathering data - fusing the data -
> building a model - outputting motor commands.
> ... They need to be integrated as a whole. If we think of them as
> 'subsystems' then we may decompose the robot control that way as in:
> Sensors -> Processing -> Motors. That is a traditional (say from the
> '60's and '70's) method of robot decomposition, it is driven by a
> computational model, and it has proven to be unsatisfactory for real
> world robotics.
I acknowledge that it is often best to have responses to stimuli being
automatic rather than ``conscious''. One very easy way to do this
is with microprocessor control, and that is why this model has been
used successfully for many years. Having direct interconnections
between, for example, bumpers and motors certainly has a part to
play in simple safety reflexes, but it is very awkward to develop
further because it is so inflexible. Sticking a micro in the path
allows soft reconfiguration---even dynamic reconfiguration---and for
that reason, using the processor as a switching hub is a good scheme.
This architecture doesn't prevent you designing in reflexes, but it does
gives you the freedom to do many other things besides.
Anyway, once again we are getting a bit ahead of ourselves. First
we need to establish what behaviours the robot will need, and only
then can we sensibly debate the implementation.
So what are the behaviours?
* cut grass when it is long enough
* don't cut things that aren't grass
* avoid hitting things
* avoid getting stuck
* avoid crossing defined boundaries
* visit all parts of the accessible area in a timely fashion
* return to recharching station when battery is flat
Any more? Most of these can be explained in a lot more detail, but for
our current purposes, I hope this is detailed enough.
Robin.
-- R.M.O'Leary <robin nospam at acm.org> +44 973 310035 P.O. Box 20, Swansea SA2 8YB, U.K.