Just updating this thread in the mailing list: The problem turned out to
be an incorrect bounding box on the robots. The bounding box is what
actually checks to see if a robot crashes into something. The bounding
box is just four lines to check for intersection in the simulated world.
The robot might actually be drawn with a complicated shape, but the
bounding box is what is checked to see if a robot has bumped into
something. This makes the Python-based simulator much faster than it
would if it checked each line of the robot's shape.
You can see the bounding box in the Pyrobot simulator's window by
selecting View -> boundingBox. There are other things that you can turn
on/off there that can help with debugging.
-Doug
belinda thom wrote:
Symptom: Robots "stall" for no reason when there's multiple robots in a
single world.
Potential hypothesis: w/multiple threads, various stall flags are
becoming corrupted.
Setup: An empty room (10 m x 10 m), 3 robots (radii .4 m), all
w/Avoid.py behavior (taken from the brain file downloaded from CVS about
3 days ago). Running G5 Mac w/OS X 10.4.
Details:
I've used some Mac screen-grabs to document what I mean.
The behavior I report below seems to be easy to replicate for each of
the 3 robots (its not dependent on order robots are added). Shown on the
left is a typical example. On the right is that robot's controller pane,
with results shown for several steps. (The only way I changed Avoid.py
was to intersperse print statements in its step and auxillary functions
to determine if a STALL condition was visible to the robot during its
step.)
At the point I'm showing the robot, it would have been sitting there for
a long time (appearing not to move at all, but actually making micro
adjustments to left/right motors, as you can see in the command pane).
At no point does the stall value change from "0". Yet every time I hit
the step button, for a brief second, the "X: 0.40 .. Th: 13" text
flickers to "X:40 .. Th: 13 [STALL!]. And the robot really seems like it
will sit there indefinitely.
------------------------------------------------------------------------
------------------------------------------------------------------------
I've tried to mimic this behavior in a world that is identical except
that it only contains 1 robot and have had no luck. In that case, the
robot can always recover from long walls (and only rarely gets stuck in
a corner, although then it still doesn't flicker "STALL!").
In the multiple-robot case I've also seen stall behavior when a robot is
near a light or another robot (in the single-robot case, the robot walks
on top of the light no problem, which is the desired behavior, i think)
I am unclear where the "show a STALL on the text bar" order comes from.
Avoid.py merely calls move w/translate and rotate values. Since the
robot isn't going anywhere (and doesn't seem to see its own flag as
stalled) it seems that move's call to motor must somehow be being thrown
away.
I look forward to hearing any opinions regarding this unfortunate
behavior, as until its cleared up, I'm not going to be able to create
interesting multi-robot Braitenberg demos.
Thanks,
--b
------------------------------------------------------------------------
_______________________________________________
Pyro-users mailing list
[email protected]
http://emergent.brynmawr.edu/mailman/listinfo/pyro-users
_______________________________________________
Pyro-users mailing list
[email protected]
http://emergent.brynmawr.edu/mailman/listinfo/pyro-users
