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
