Yeah, there is a certain amount of decoupling that can be applied to
the project.
>
> > 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:-)
Wow, now that _really_ would be something. Mowbots cooperating to
achieve
the task, some cutting the lawn, others sweeping up, another hiding the
body of the cat they ran over ;-)
>
> > ... 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.
I wasn't proposing the removal of micro buffering between sensors and
actuators. I was really alluding to the sensor fusion model, where data
is fused into a map representing the world, then choosing motor actions
based on the fusion. This is a slow and error prone method. What I mean
is
for example, the bump sensors don't need to be integrated with the
grass sensors, things like that, in other words certain parts of the
system
only require information from specific sensors (this is really about
inter-module communications).
> 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.
True enough, we don't even have a chassis to play with yet.
>
> 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.
Sounds like a good start. We'd better hurry, the grass in my yard is
getting
pretty long ;-D
Dave.