|
[DPRG] From Bugs to Emergence?
Subject: [DPRG] From Bugs to Emergence?
From: David M Wilson
davidmw at tx.rr.com
Date: Wed Jun 13 19:13:32 CDT 2007
>>We've had a discussion before on the list of, is it *really*
intelligent, or does it just *look* intelligent? I've been
of the opinion that *looking* intelligent is sufficient, for
bot humans and robots ;)
It seems to work for politicians. Fool me once...
>>What part of the behavior do you consider a bug?
I'm using the word 'bug' as conversational shorthand but don't think it has
a place in BBR. There are certainly compile and link time errors. Once the
code is flashed to the robot controller everything becomes a behavior that
can be demonstrated to be some combination of 'good or bad,' 'intentional or
not,' 'productive or unproductive' and the developers job isn't to eliminate
bugs but to build on and encourage some behaviors and to discourage others.
When I last worked on ball following the bot would avoid touching the ball
and would stay back about 10 inches. This gives it enough room to turn in
pursuit. If the ball is not in motion the bot would sit calmly at the
standoff distance or oscillate safely around the standoff distance (a
behavior that I decided to preserve since it suggests enthusiasm for ball
play) without contact.
The unintended behavior, or bug if you must, is ignoring the standoff
distance, contacting the ball, and then pushing it smoothly. Also
unintended is the repeated bumping of the ball that is stuck and not
rolling. It is a complete surprise that the bot seems to back up and run at
the stuck ball and for it to continually try new impact angles. This
tenacious behavior has an organic look to it and gives the bot a good chance
of solving the problem which is apparently an effort to put the ball back in
play. Drifter changed the game.
Changes to locomotion, steering, braking, camera position, blob processing,
camera calibration, floor friction, or interrupt processing could influence
the ability to hold the standoff distance. For example if some change
makes threshold braking less efficient the bot will skid right through the
standoff distance. It could then be more prone to the oscillation behavior
since it needs a bigger correction or it could result in contact with the
ball. Take a ball catching dog to a slick floor and the game will be
completely different.
There should be at least two ways of encouraging the ball handling behavior.
One is to figure out which parameters can be toggled to move between ball
following and ball handling. The risk here is that the parameter could be a
pretty obscure control for the task. It could be something like 'decrease
braking power' or 'increase minimum camera angle.'
The other option is to create a new ball handling task that tries to
recreate and build on the behavior.
David Wilson
More information about the DPRG mailing list
|
