From Aaron Sloman Wed Jan 11 18:43:54 GMT 2006
To: CoSy Mailinglist
Subject: [CoSy] Playmate/Kitty scientific objectives
Very sorry to be constantly behind with things. Although I had started
preparing answers to messages about playmate sent by Bernt and Ales in
November and December somehow the unfinished messages never got sent
partly because I allowed myself to be distracted by other things.
Also Jeremy is so extraordinarily busy now that we don't have enough
time to get together to thrash out important things. We have done so
now, and this message and my next one (or more) express what I believe
is agreed policy here, though there are still details to be decided, and
we try to be flexible enough to learn that we have made mistakes that
need to be corrected.
Anyhow Bernt asked about the scientific aims, both in his helpful
(but too short!) November message and in the more recent one.
The aims of PlayMate remain as in the original CoSy proposal, but
specifically, as far as PlayMate is concerned, to explain what makes it
possible for an animal or robot to perceive, manipulate, talk about
think about, and learn about 3-D objects various sorts that might be
encountered and acted on in a domestic situation. The Fido domestic
robot scenario in the proposal was invented by Henrik but the Birmingham
people are very happy to accept it as defining the long term goals to
which all our work, at least on PlayMate, must be directed.
[For non-English speakers, the dog's name 'Fido' is usually pronounced
so as to rhyme with 'fly dough' 'sigh flow', as opposed to feedo or
feedoo]
We see the core capabilities of the Fido robot as being analogous to a
child who is old enough (4 or 5 years??) to help disabled or blind
people with domestic tasks. We are ignoring other things like Fido
having wireless connections to databases, etc!)
There's a partial specification of Fido in the still incomplete
requirements matrix:
http://www.cs.bham.ac.uk/research/projects/cosy/matrix/
Deriving concrete short term project goals from that long term objective
is very difficult -- the old AI trap: whatever anyone proposes will seem
impossibly difficult or too trivial, e.g. just a minor extension of
current competence. Different people will judge each proposal in
different ways.
One answer is to find a good (deep and comprehensive) characterisation
of the impossibly difficult long term stuff then select a simplified
subset, making it clear why it is a subset that (a) could be a milestone
on the route to the long term goals (b) why doing it would lead to a
significant advance in our current knowledge (c) why it is achievable in
the time available.
That's only possible if you have an agreed characterisation of the
superset. In Freiburg I tried to propose using very detailed scenarios
for that, but very few people wanted to do that. I know it is difficult
to do.
In CoSy as a whole I don't believe we have achieved that specification
-- partly because some people have not been interested, because they
already know which subsets they want to work on. We did not have
that advantage in connection with PlayMate.
Anyhow, I now think we have a useful *partial* generative specification
of the superset in terms of a collection of orthogonal recombinable
competences (extracted from the work on vision as simulation and
generalised, but still incomplete):
http://www.cs.bham.ac.uk/research/cogaff/misc/orthogonal-competences.html
[That presents some of the same information as the matrix, but in a
different way.]
Also we have now in birmingham at last been able to choose a tiny subset
for playmate that we think (hope??) (a) could be a step on the long term
road, (b) would provide a non-trivial extension of current know-how and
(c) is achievable quickly enough to provide a demonstration by month 24.
(Alas that is VERY soon!!)
One view of that subset is here
http://www.cs.bham.ac.uk/research/projects/cosy/deliverables/matrix/general-general/axs-kitty.html
However it is still such a small step that some people may be
dissatisfied.
So we have a proposal as to how to proceed that will allow parallel
activities that can be merged if the opportunity arises.
My next message will enlarge on that, including the proposed
architecture, which will support a 'minimal' core scenario mostly
implemented here, while allowing for it to be extended in various ways
as and when partners provide contributions. (Which it may be hard to do
in time for the 24 month deadline, but may be doable by the 30 month end
to the second planning people.)
Once again, sorry for taking so long to get to this point.
Aaron
From Aaron Sloman Thu Jan 12 02:55:12 GMT 2006
To: CoSy Mailinglist
Subject: [CoSy] Playmate/Kitty month 24 target
This is the promised second message saying in more detail
what we want to try to achieve by month 24 for PlayMate (August!!!)
Perhaps a revised, shortened, better structured, version of this
document can meet Henrik's request for a revised workplan, at least for
PlayMate.
The general idea is to propose a core, minimal, demonstration system for
month 24, but use an architecture that supports a lot of extensions. So
if more ambitious components are ready in time they can be combined and
added.
[Risk management.]
There's much catching up to do in a very short time:
As mentioned in an earlier message we are very much hampered because we
(a) have not made enough progress with arm control software
(documentation is being provided by Marek) and (b) we have not made much
progress on shape perception.
Moreover, it turns out that the general state of the art in shape
perception is too backward for us to be able to simply import work from
elsewhere to do the sorts of things we originally wanted to do in
PlayMate. (Does anyone remember our earlier proposals for a tea-party
scenario?)
After I formulated my 5 page 'challenge' for vision theorists a year ago
and sent it round the world, I was informed that in general the problem
of shape understanding had been ignored. (Also confirmed by David
Forsyth at the Edinburgh tutorial.) There has been work on deriving
shape representations, e.g. using vision or laser range finders
(including good work at UOL), but that produces a simulated
'replica' of a 3-D object which is useful for projecting images from
different viewpoints but still leaves unsolved the problem of
*understanding* the shape of the model in terms of possibilities for
action (affordances) -- e.g. which bits of the object can
be grasped; which approach angle of the wrist, and which finger
orientation will be required to grasp at a specific point, and what
will be the consequence of pushing here, in this direction, etc.?
Simplified initial scenario (month 24):
So we have decided for the initial demo to stick with graspable objects
with *very* simple shapes and to go for very simple shape
representations that will be sufficient to drive a model-based vision
system to perceive where the arm and hand are and where other things are
and how things are moving.
This will be sufficient for the simple explorations of consequences of
actions, described in Jeremy's message of 30th Nov, saved here:
http://www.cs.bham.ac.uk/research/projects/cosy/matrix/general-general/jlw-kitty.html
Besides the questions posed in that document, the work will also
(eventually) address questions about whether a certain architecture and
collection of modules provides a good stepping stone towards the sort of
domestic robot referred to in the long term goals. (See previous
message, and Nick's document mentioned below.)
The draft specification for an initial 'minimal' visual system (a
model-based vision system) is here (based on discussion with Somboon):
http://www.cs.bham.ac.uk/research/projects/cosy/matrix/general-input/axs-kitty.html
Providing this as fast as possible for immediate use will allow other
partners to work on alternative visual systems that can be switched in
when ready -- because the design of the architecture will be highly
modular, and we know how to provide tools to support easy insertion and
removal of components.
Architecture:
We have provisionally decided on an architecture that allows the
*minimal* scenario to be implemented, but includes many opportunities
for *extension* when additional competences are implemented, e.g. in
vision, language, planning, learning, self-understanding (philosopher
scenario).
The architecture will allow new things to be added provisionally to see
how they interact with the core things, and then to be either removed or
left in.
One way to handle visual systems produced by different partners will
then be to treat them as if they used different sensory modalities.
I.e. techniques for multi-modal integration will be applicable to
multi-mechanism intra-modal integration.
E.g. there could be components providing distance information using two
cameras and stereo, components providing distance information using
optical flow and components providing distance information using
model-based vision. Sometimes the different visual modules will provide
the same information by different means, and sometimes they will provide
different information required for different tasks.
[I actually think human vision works like that. E.g. your posture
control system uses differnt visual modules from your face recognition
or reading functions.]
We shall need to have well defined programming interfaces for all of
this, of course.
Software Engineering:
All development will have to be based on a strong discipline of agreed,
precisely documented, interfaces *before* implementation starts.
That will allow appropriate stubs to be available and may even allow
incremental simulation of components that do not yet exist.
We don't want to have the problem of someone providing a component that
doesn't fit what others have provided.
(I hope all the agreements can be reached amicably. If that proves
difficult the management group will have to set up a management
decision-making strategy for resolving conflicts about how to proceed.)
Barge-in support:
The requirement for 'barge-in' which we have discussed several times in
the past can be met by ensuring that the core method of interaction uses
forward chaining rule interpreters within most of the central modules,
so that when dynamic changes are produced in one module by events in
another (e.g. new items of information are added to the workspaces or
old ones removed, or modified), the effects will be almost immediate
(different rules triggered).
(A different approach to this could be based on a neural-network
architecture using multiple networks with rich connectivity, some
monitoring others -- but I don't think we have the right expertise to do
that, or the computing resources, in this project.)
Rapid Prototyping:
At this stage we don't care about efficiency, only functionality,
robustness, and ease of design, implementation, debugging and testing.
We shall explicitly use the rapid-prototyping methodology (get testable
prototypes going, with simplified functionality, as quickly as possible,
and be prepared to throw them away and use what we have learnt to do
things much better next time. Work in cycles of increasing depth and
breadth.)
https://www.spider.hpc.navy.mil/index.cfm?RID=TTE_OT_1000054
http://dsnra.jpl.nasa.gov/devel/eac/prototyp.html
http://en.wikipedia.org/wiki/Extreme_Programming
(Extreme Programming:)
Tolerance:
Some people may be reluctant to recode their algorithms and forms of
representation to support constant interaction and 'barge-in' mentioned
above. In that case we can still cope with a subset of modules that work
only in batch mode, but their inflence and responsiveness will simply be
reduced. (I.e. integration is not all-or-nothing.)
Incidentally support for barge-in can provided enhanced development and
testing/debugging capabilities also.
Concurrency:
The proposed architecture has a collection of components ALL of which
are concurrently active, though some are more active than others.
I.e. there is no global pipeline through the components, and there
is no global sense/decide/act cycle, as used by many (misguided??) AI
systems.
There's a draft picture of the components of the architecture here
(without the many connecting arrows that are really required!)
http://www.cs.bham.ac.uk/research/projects/cosy/matrix/architectures/kitty/kitty-arch.png
and a draft description of the architecture here
http://www.cs.bham.ac.uk/research/projects/cosy/matrix/architectures/kitty/
We believe that past experience in Birmingham will enable us to produce
all the general architecture code apart from the spreading activation
substrate (inspired by ACT-R) fairly easily in a 'throw-away'
implementation. (E.g. Nick's PhD work and other things here had many
similar features).
The initial kitty scenario (for month 24) has no assembly, only touching
and pushing with grasping added *if* it works easily. So the planning
component will initially be very simple, but we would like to discuss
with Freiburg people ways of doing planning for a manipulater, to be
plugged in later. This is obviously going to depend on the complexity of
the shapes and the tasks, and also things like the kinds of obstacles to
movement that may occur as tasks get more complex with more clutter on
the table.
Natural Language
For reasons explained previously, we regard it as essential that the
whole thing should be able to work without the natural language
component (as many animals and young children do) so that there is a
rich semantics defined independently of the linguistic component for
language to engage with, and so that we can explore forms of language
learning such as might happen in a child.
This will require the early robot to have a motivational system (mostly
curiosity) that generates goals and questions autonomously, instead of
everything having to be driven by questions and commands. (Goal
generators and question generators could used the representational
transformations discussed in DR 2.1.)
There are endless possibilities for a linguistic component to be added
later, with many different functions including asking and answering
questions, providing explanations, collaborative planning, extending the
robot's ontology, other forms of teaching, pointing out ontological or
other mistakes, discussion of 'what if' scenarios ('Could you have
picked the object up if it had been here?')
So a good task for people interested in language would be to start
(collaboratively) to specify a collection of desirable types of
linguistic communication for the more advanced PlayMate scenario.
We already have a few examples in this old file
http://www.cs.bham.ac.uk/research/projects/cosy/PlayMate-start.html
(originally around May 2004, when we were still optimistic about what
could be achieved in the first year....)
After the desirable types of communication have been specified, we can
then move towards designing the interfaces that will support them.
The architecture will allow preliminary versions of linguistic
components to be switched in temporarily for testing when they are
available.
Learning:
We have spent much of the past year discussing various kinds of
learning, especially learning in human-like altricial robots and
animals. We hope to be able to demonstrate learning in PlayMate but
probably not within the few months remaining for the next demonstration
deadline (month 24).
We are interested in several different kinds of learning, of which more
needs to be written later.
Scientific questions:
Nick has a draft document on some of the scientific questions that can
be posed in relation to the architecture.
http://www.cs.bham.ac.uk/research/projects/cosy/matrix/architectures/kitty/architecture.scientific.questions.txt
[Written by Nick, but slightly modified since.]
Enough for now. I hope this makes sense as a basis for discussing how to
proceed with PlayMate.
Must later return to the offerings from Ales and Bernt on vision, which
we think can be accommodated within this framework.
I'll try to produce a better formatted version of this document.
Comments criticisms suggestions for improvement/clarification welcome.
This is based on discussions with Bham CoSy members, including Jeremy,
but he has not had time to check what I have written! He may request
some changes.
Aaron
http://www.cs.bham.ac.uk/~axs/
From GJ Thu Jan 12 09:43:44 2006
Cc: CoSy Mailinglist
Subject: [Cosy-all] [CoSy] Re: Playmate/Kitty month 24 target
To: Aaron Sloman
hi aaron, all,
just a brief message (promise!). overall, i think the proposed
discussion looks very interesting indeed. there are a few comments
below. i think the focus on getting perceptive and proprioceptive
modalities to work before language is fine -- this actually lines up
with the slides i've been preparing, where i'm trying to figure out
what all we'd need in those modalities before we could think of
particular types of linguistic interaction that are more complex than
what we've now. (having said that, i'll be focusing on particular
functional ASPECTS, across many modalities, rather than specifying
one or two modalities in full -- functional vertical decomposition if
you want).
> As mentioned in an earlier message we are very much hampered
> because we (a) have not made enough progress with arm control
> software (documentation is being provided by Marek) and (b) we have
> not made much progress on shape perception.
when it comes to arm control -- what concrete development timeline
are we thinking of? the one that is given in marek's thesis proposal?
> Software Engineering:
> All development will have to be based on a strong discipline of
> agreed, precisely documented, interfaces *before* implementation
> starts.
agreed. nick: i'll go through the manifesto you worked on earlier,
before the meeting.
> Barge-in support:
> The requirement for 'barge-in' which we have discussed several
> times in the past can be met by ensuring that the core method of
> interaction uses forward chaining rule interpreters within most of
> the central modules, so that when dynamic changes are produced in
> one module by events in another (e.g. new items of information are
> added to the workspaces or old ones removed, or modified), the
> effects will be almost immediate (different rules triggered).
>
> (A different approach to this could be based on a neural-network
> architecture using multiple networks with rich connectivity, some
> monitoring others -- but I don't think we have the right expertise
> to do that, or the computing resources, in this project.)
i strongly agree with the need for content-associativity to handle
active situational awareness. whether this ought to be rule-based, or
activation-based, or argmax-based, or ... may still be an open
question perhaps.
> Rapid Prototyping:
> At this stage we don't care about efficiency, only functionality,
> robustness, and ease of design, implementation, debugging and testing.
>
> We shall explicitly use the rapid-prototyping methodology (get
> testable prototypes going, with simplified functionality, as
> quickly as possible, and be prepared to throw them away and use
> what we have learnt to do things much better next time. Work in
> cycles of increasing depth and breadth.)
> https://www.spider.hpc.navy.mil/index.cfm?RID=TTE_OT_1000054
> http://dsnra.jpl.nasa.gov/devel/eac/prototyp.html
> http://en.wikipedia.org/wiki/Extreme_Programming
> (Extreme Programming:)
i'd agree on trying to shorten the development cycles. i am not
terribly convinced by extreme programming: this would work in our
case if we'd have sizeable libraries at hand which would enable us to
explore many possibilities in vision, motor control, etc. to find out
how to put together the functionality we want. however, at least in
some cases we lack those libraries, which imho means we'll have to
spend some time on actually building up those libraries/apis. we need
to think the construction of such apis through so that they evolve in
a way that they indeed enable us to explore different architectures,
different functionality.
> We believe that past experience in Birmingham will enable us to
> produce all the general architecture code apart from the spreading
> activation substrate (inspired by ACT-R) fairly easily in a 'throw-
> away' implementation. (E.g. Nick's PhD work and other things here
> had many similar features).
what functionality does the general architecture code aim to provide?
what framework(s) will it use?
> Natural Language
> For reasons explained previously, we regard it as essential that
> the whole thing should be able to work without the natural language
> component (as many animals and young children do) so that there is
> a rich semantics defined independently of the linguistic component
> for language to engage with, and so that we can explore forms of
> language learning such as might happen in a child.
> This will require the early robot to have a motivational system
> (mostly curiosity) that generates goals and questions autonomously,
> instead of everything having to be driven by questions and
> commands. (Goal generators and question generators could used the
> representational transformations discussed in DR 2.1.)
sure, the motivational component is crucial here if we want to model
exploration and play -- language isn't exactly the driving force
there ;-)
note that the rich semantics you refer to provides the basis FOR
linguistic meaning. the interpretation of communicated meaning is
based in that rich semantics, reflects it.
and, eventually, we'd have to consider how language, particularly
learning through language, can help reconfigure and extend this rich
semantics: e.g. assimilation and integration based on verbalization.
> There are endless possibilities for a linguistic component to be
> added later, with many different functions including asking and
> answering questions, providing explanations, collaborative
> planning, extending the robot's ontology, other forms of teaching,
> pointing out ontological or other mistakes, discussion of 'what if'
> scenarios ('Could you have picked the object up if it had been here?')
>
> So a good task for people interested in language would be to start
> (collaboratively) to specify a collection of desirable types of
> linguistic communication for the more advanced PlayMate scenario.
we've been thinking here about several aspects of communicated
meaning that we'd like to address. i'll present some of these aspects
at the birmingham meaning, e.g. spatial perspectivization,
establishing common ground in understanding the environment,
establishing plans for (joint/collaborative) action, and the issue of
active situational awareness.
> We already have a few examples in this old file http://
> www.cs.bham.ac.uk/research/projects/cosy/PlayMate-start.html
> (originally around May 2004, when we were still optimistic about
> what could be achieved in the first year....)
various examples of the above issues can indeed be aligned with what
was proposed at that time.
> After the desirable types of communication have been specified, we
> can then move towards designing the interfaces that will support them.
> The architecture will allow preliminary versions of linguistic
> components to be switched in temporarily for testing when they are
> available
... what i hope to convince people of during the birmingham meeting
is that there are various issues in the design of the pre-linguistic
architecture that will have a profound effect on the (in)ability for
expressing, or dealing with, particular aspects of meaning in
communication. seen the other way round, thinking about what we'd
eventually like to communicate in terms of our understanding of the
environment will pose several questions for, or requirements on, the
functionality of the pre-linguistic architecture.
in other words, even when we (rightly) want to focus on getting
vision and motor control in place, before we start thinking of how we
could make the cognitive system capable of communication, i hope to
convince you that this is not a matter of simply tacking a next
version of the COMSYS module onto the architecture. aside from the
question whether there will be such an individuatable module, the
issue is (imho): if you look at the architecture in a "vertical" way,
thinking of how a particular function could be supported across low-
level and high-level cognitive processes (see also rodney brooks on
methodological considerations in system design), then we may well
need to think more or less from the start what the mentioned
interfaces should actually provide to higher level cognitive
processes like communication or action planning.
however, because linguistically communicated meaning is for an
important part based in the rich semantics we are interested in for
the pre-linguistic architecture, thinking about what these interfaces
should provide is thus not so much an issue of what communication
should be capable of, but what kind of model(s) of rich semantics
we'd like to have.
> Scientific questions:
> Nick has a draft document on some of the scientific questions that
> can be posed in relation to the architecture.
>
> http://www.cs.bham.ac.uk/research/projects/cosy/matrix/
> architectures/kitty/architecture.scientific.questions.txt
> [Written by Nick, but slightly modified since.]
many of the questions i try to raise in my presentation provide more
specific instantiations (or aspects of) various questions nick asks
in that document. i'll try to make this clear in my talk (though i'm
wondering whether everything is going to fit in those 20 minutes...).
cheers, gj
From Aaron Sloman Thu Jan 12 12:50:44 GMT 2006
To: CoSy Mailinglist
Subject: [Cosy-all] Admin for PlayMate planning meeting.
Thanks GJ.
Our computer officers are very security conscious and unfortunately all
wireless hardware has to be pre-registered, so please will anyone who
wants wireless access whilst here send MAC address for your wireless
card to Nick:
N.A.Hawes
See the draft schedule here
http://www.cs.bham.ac.uk/research/projects/cosy/requirements.meeting.php
[Ales, Daniel, your departure & arrival times are not indicated. If you
have not already told Nick, please do so.]
[gj]
> many of the questions i try to raise in my presentation provide more
> specific instantiations (or aspects of) various questions nick asks
> in that document. i'll try to make this clear in my talk (though i'm
> wondering whether everything is going to fit in those 20 minutes...).
The overview sessions on day 1 will be chaired viciously! There will be
time in the following days to go into more detail. With luck, all
pre-planned detail will have been sent in advance for people to read
before the meeting starts, as previously requested.
We hope to reserve time at the end of each session for a summary of
decisions taken (or still to be taken).
So most people should come having read a lot.
I assume people who are coming will have internet access over the
weekend (if not, please let me know -- e.g. if you want things
emailed to you). So I'll make all documents available.
Unfortunately our web server sometimes gets overloaded and freezes -- a
new web server is being configured and tested but it's taking a long
time because the whole site is being redesigned, alas.
I'll start preparing a downloadable package containing all contributions
(including a location-independent version of the requirements matrix)
late on Friday.
As new contributions arrive I'll make them accessible over the weekend.
Please either send your contributions to the whole cosy list if you'd
like general feedback or else to
A.Sloman
N.A.Hawes
my blueyonder address
Format:
For your contributions, use any of
plain text
html
latex
pdf
If anyone wants to provide a powerpoint file, I'll convert it to pdf
using openoffice. Embedded movies will not work, but can be provided
as separate files. Don't use 'arial narrow' font as OO cannot format
that properly.
The day 1 short presentations should not go into technical details of
how things will work, but merely indicate something like:
(a) indicate the kinds of scientific questions people would like to
address in the near-term PlayMate (i.e. kitty, with 30month
delivery, or the review demo with 24month delivery, i.e. August
2006)
(b) indicate how you wish to address them.
Overview only: As high level as possible (kinds of competences
and how they will be provided.)
(c) how soon you think you can do which portions
(d) any pre-requisites needed from other sites for that to work
[Or choose your own headings if you prefer. The aim is partly to inspire
everyone else to want to work with you!]
For more technical requirements and high level design suggestions
prepare separate contributions (preferably circulated in advance). They
can then be shown/discussed in the more detailed sessions, e.g.
architectural implications of NLP aims can be discussed in the 17:00
session on Tuesday and again later. If there are cross module
requirements (e.g. what prerequisites for vision modules come from the
motivational module's requirements then they can be discussed on
Wednesday, and Thursday).
If you wish to link a contribution to a box in the requirements matrix
use ether the "column X row" format or the directory name in the box.
E.g. for a note on communication about spaces, times, locations, use
communicative competences X Space, time & purely spatial/temporal entities
or the directory name in the box:
space-communicate-about
I can add any such offerings to the matrix. I am not sure how well
Nick's PHP code will cope with new file names. We will make something
work. Preferred format is plain text or html (allowing cross-references)
with images in jpg or png or gif format (or anything that works in all
browsers).
If you want participants to read something that's already in one of the
CoSy deliverables or one of the publications please circulate details
and a link to the deliverable.
[Remember: all publications are supposed to be freely available to all
partners. So either put them on the wiki or on a local web site and
send round URLs for each of them.]
Deeper issues:
GJ makes some important points about how linguistic competences can
impact on the whole architecture. E.g. if PlayMate says
"I asked Joe to pass me the block but did not say why"
there are enormous implications regarding the architecture and
competences of the speaker, of Joe, and of the hearer. There are many
other types of examples (e.g. the differences between "I picked up the
ball" and "I was picking up the ball" in various contexts).
GJ's point is very important and that's one reason for using
rapid-prototyping tools that make it very easy to add or change
components of the architecture and to test small or large changes
without restarting a run of the whole system.
But for now I suspect detailed planning of such things (though extremely
interesting) is not as urgent as other things required for bootstrapping
kitty as fast as possible.
One thing we can easily do is clone the architecture and have a copy
running with *very* simplified simulated actions and perception, in
order to explore some of the other issues about NLP, motivation,
intentions, beliefs, planning, etc.
Tools:
The only way we in Birmingham can envisage doing this in the timescale
for the 24 month demo is to use techniques in SimAgent that we know
well. This will run on linux machines which everyone has. There's a
partial port to OSX where everything works (I believe) apart from the
graphics, but I am reluctant to inflict that on anyone.
It is described here.
http://www.cs.bham.ac.uk/research/poplog/packages/simagent.html
with videos of some samples (including Marek's hybrid
reactive/deliberative sheepdog) here
http://www.cs.bham.ac.uk/research/poplog/figs/simagent/
http://www.cs.bham.ac.uk/research/poplog/figs/simagent/#hybriddemo
If anyone wants to play with SimAgent I'll tell you what to fetch, and
how to run some toy demos that you can easily edit. (Download is
about 20MB. Installed system is under 100MB, of which parts can
be removed if space is a problem.) Code tends to be very compact,
partly because user code creates no object files: everything is
incrementally compiled (as in Prolog, Lisp, Scheme). Syntax is much
simpler than C++ or Java. Application specific syntax is easy to add.
One thing that might be worth considering later as an alternative is
Mozart (developed mainly at DFKI?), which is more portable, has higher
level inter-computer support, and I think aims to give similar
facilities to those in SimAgent. But I have never used it. Has anyone in
CoSy ever used it:
http://www.mozart-oz.org/
I think the main difference is that mozart aims to support the
complexities arising from constraint propagation and distributed agents
(which may be numerous but simple), whereas SimAgent aims primarily to
support the within-agent complexity, where diverse sub-mechanisms
interact asynchronously in a rich way (e.g. combining reactive and
deliberative components, supporting internal self-observation at a
meta-management level).
However, switching to mozart at this stage would probably add a delay of
at least two months to the bham implementation work which is not
tolerable in present circumstances.
Aaron
From Aaron Sloman Thu Jan 12 13:09:19 GMT 2006
To: CoSy Mailinglist
Subject: [Cosy-all] Admin for PlayMate planning meeting. [PS]
I forgot to say in my last message that putting all the architectural
support in SimAgent does not require other people to code their
components that way.
Instead communication via pipes or sockets can be used (e.g. that's how
Nick's PhD system communicated with the 'unreal tournament' game running
on another computer).
So vision/speech/arm-control stuff can run in other processes, and the
communication will probably be no harder than using Corba, Carmen, or
whatever.
(In fact, for PlayMate it may be easier to use CoSy-specific wrappers
round sockets than to use any of those generic tools. But that's an
issue for discussion under 'tools' when we have taken decisions about
what to do.)
However, people who write code in their preferred language will have to
think hard about how they are going to support the requirements for rich
interaction. E.g. it should be easy at any time to modify or abort the
current task or to interrogate what has already been found.
'Batch-processing' techniques are obviously not suitable for a live
robot. (Playmate or Explorer or the Philosopher, which needs to be able
to answer unexpected questions about what it is doing and why?)
An interesting question (among many) is how that will impact on
learning.
Aaron