> > I'm not sure I entirely agree with this decomposition. The one you've
> > suggested would be useful for designing a motorised computer,
> > but this project will be much more than that.
>
> Now it's my turn to sound pedantic:-) I don't really understand your
> point about a motorised computer. Surely this is exactly what we are
> designing, albeit a fairly stupid but well-equipped one? Of what are
> we going to have ``much more''?
Well that would not really constitute a robot, nor would it constitute
an autonomous vehicle. My early robots were basically 'motorised
computers'
. When you stop and look at them they are just glorified remote control
vehicles lacking autonomy or the capability to deal with situations I
hadn't hard coded for. Research in the last decade has identified new
methods for robot control that work better (the old ideas really didn't
work at all). As an example take the Stanford Cart, it would move
forward
one metre, then compute the scene for 15 minutes before the next
metre!!!
Compare that to the reactive behaviour based robots of today, using
bugger all
processing power (as opposed to the UNIX mainframe used by the Stanford
Cart),
proving that the problem was not a computational one but a behavioural
one.
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. Robot control and navigation is closer to psychology
than it
is to computing, I believe the key is to avoid thinking computationally
if
you want to really achieve anything with mobile robots.
As to what I mean by 'much more', I mean the finished robot should be
more
than the sum of it's parts. Chucking motors, electronics, sensors and
computers
together does not constitute an autonomous robot, it is the underlying
behaviours
that are competing for control that make it what it is. 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.
> > Any or all of the subsystems listed may become part of the finished
> > project, but they will not be subsystems as I will explain.
> I suspect my use of the term ``subsystem'' might be the problem. It would
> have been better to call them ``aspects of the design'' at this stage.
> But please do explain why, later on, they won't be subsystems.
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.
A better way to decompose is:
\ Sensors
--------- > Processing
/ motors
All the processes are occurring concurrently, as they do in all living
creatures,
and since they seem well suited to surviving in the real world I believe
they make
a better model than computers do.
All this may seem far removed from the project at hand, but avoiding the
compuational methedology will, I believe, help us progress successfully.
>
> > The danger I see with this mailing list is that it
> > could become anarchic, with everyone talking about any element of the
> > project without and formal agenda.
> Good point. But I hope that the group will not get bogged down in
> formality either. Perhaps the best thing is to get the most important
> administrative sorted out so we can move on quickly.
Yeah, agreed. I don't want this to become _too_ formal either.
>So I formally
> propose that the following items be put on the agenda for discussion:
> * Organisation
> - Appointment of ``chairman'' of the meeting. He gets to tell
> people to move on when a point has already been made, does any
> formal calls for comments, sets the timetable for moving on
> the discussion, has the final say in deadlocked disputes etc.
> It seems to me that this person should be Ray as he is to
> blame for it all in the first place:-)
I second the motion :-)
> - Appointment of the secretary.
> At some point we'll need a potted history of discussion to date.
> As time goes by, this will expand to a portfolio of design
> notes. This will be useful for newcomers and for reference
> during discussion, and could be posted periodically to Usenet.
> The automatic archiving by the list server and the proposed
> Web/ftp site will help with this. I'll stand for this post.
Excellent. You have quite an ability for writing clearly (something I
lack).