|
[DPRG] Allen Robots (Will's emotions)
Subject: [DPRG] Allen Robots (Will's emotions)
From: Chris Jang
cjang at ix.netcom.com
Date: Mon Mar 5 19:21:43 CST 2007
>> Anybody else wrting robot code that is basically the
>> behavior-based or "subsumption" architecture, while
>> adding a supervisor or monitor layer above that to
>> control weights and ordering of the lower level behaviors?
>
>Maybe it gets across the idea of a mechanism that compresses a lot of
>information about the environment and the [robot|organism], over time,
>into a single, representational value that can drive a behavior.
In David's talk about UMBmark a few months ago, he spoke of jBot's
waypoint following strategy. Just like comparing floating point values,
some kind of approximate equality criterion is required. For jBot, if
the distance from the waypoint transitions from decreasing to increasing,
then the robot presumes it has approached as close as it may. It gives
up and proceeds to the next waypoint. My recollection of this may be
inaccurate.
Anyway, a lot of thought went into designing jBot so it would not become
stuck. But even then, there still need to be some behaviors built in to
prevent the robot from becoming trapped in a state space bowl of some
kind.
So that's what I'm thinking of as a supervisory behavior - recognizing
when there is something wrong, when self is stuck or there is a system
fault. I know that this kind of supervision is built into NASA flight
vehicles like the space probes. I think this is a very challenging
problem.
My robots are four wheeled Ackerman steered cars with monocular cameras
for environment sensing - this makes them prone to becoming stuck. That
might be evidenced in two obvious ways.
One is just trying to drive. Turning requires moving. So if a robot
drives into a corner or up an alley, turning around is not trivial. An
escape strategy is required. So the robot first needs to realize that it
must escape.
The other issue is the frailty of computer vision. Any given algorithm
is easily defeated with a change in conditions. The robot must know
when the algorithm in use has stopped working. Then it can try something
else or stop and flash its lights (help!).
This is all very hazy for me as I have not written any control code yet.
It makes me think of machine learning, approaching it as an optimization
problem. The hope is that for a given problem formulation, there exists
a good set of engineering fudge factors we can guess or compute via brute
force that give the behavior we want. I don't know how hard this is in
general. But I do know that for some computer vision problems, computing
these fudge factors (designing the digital filter) is very expensive and
difficult.
More information about the DPRG mailing list
|
