Behavior Programming Issues

[Rud]

Been working on the Create. I have the web camera mounted so it peeks over the IR sensor on the front. The camera feeds to RoboRealm which does some image processing to determine the center of gravity of a 3" diameter red dot. The dot can be near or far and the processing almost always finds it.

Previoiusly I implemented the behavior stack: Flee, Bump, Trapped, Cruise (from highest to lowest priority). This makes the Create wander. When it Bumps into something a data structure is set that tells Flee to execute a back and turn motion. Trapped does something similar if the Create has moved any real distance in 10 seconds, the assumption being it is in a canyon so it turns 180 and flees.

I added the behavior RedDot which gets the X position of the red dot from RR. It aligns the Create with the dot and advances or backs to keep the dot a certain size in the image. I put RedDot between Bump and Trapped. The problem is that Trapped kicks in because the RedDot is holding the Create in position.

In all behaviors, except Trapped, a higher priority behavior preempts the lower priority behaviors from performing triggering. The still execute, the just don't get to control the Create. Trapped isn't preempted because it needs to take control even when higher priority behaviors are firing since they are being unsuccessful. Putting Trapped higher would normally work but not with RedDot holding the Create's postion.

Okay, I could put an internal sensor (a flag variable) that RedDot sets saying that holding position is intentional and Trapped shouldn't fire. But that strikes me as a kludge that could easily lead to more flags as I add more behaviors.

Note that this is how Rodney Brooks' Subsumption works. In subsumption, RedDot would be a higher level behavior and would inhbit the input or output of Trapped. Or maybe it would inhibit Flee? Hmmm, there is a thought. Flee already has an internal senors structure which has an 'active' flag. If RedDot were at the top of the behavior stack it could turn off the active flag before Flee gets to see it.

I'll think about trying that and think more about the overall problem. But I though it might be interesting to discuss issues as they arise. Then others can see what goes into developing a robot and maybe others will have suggestions on solving the problem.

[Dave]

Been working on the Create. I have the web camera mounted so it peeks over the IR sensor on the front. The camera feeds to RoboRealm which does some image processing to determine the center of gravity of a 3" diameter red dot. The dot can be near or far and the processing almost always finds it.

Cool.

Previoiusly I implemented the behavior stack: Flee, Bump, Trapped, Cruise (from highest to lowest priority). This makes the Create wander. When it Bumps into something a data structure is set that tells Flee to execute a back and turn motion.

Sorry, I'm a bit confused here. Is Bump a behaviour or a sensor input? Ideally, you wouldn't have any communication between layers (except the reset to inhibit) so Bump couldn't trigger Flee?

Trapped isn't preempted because it needs to take control even when higher priority behaviors are firing since they are being unsuccessful.

In that case isn't Trapped the de facto highest priority, rather than the others?

Okay, I could put an internal sensor (a flag variable) that RedDot sets saying that holding position is intentional and Trapped shouldn't fire. But that strikes me as a kludge that could easily lead to more flags as I add more behaviors.

Yeah, flags are a bad idea in subsumption because they introduce explicit internal states which subsumption was designed to remove.

Note that this is how Rodney Brooks' Subsumption works. In subsumption, RedDot would be a higher level behavior and would inhbit the input or output of Trapped. Or maybe it would inhibit Flee? Hmmm, there is a thought. Flee already has an internal senors structure which has an 'active' flag. If RedDot were at the top of the behavior stack it could turn off the active flag before Flee gets to see it.

Yeah, I agree with that. Something like:

                 --- RedDot -->
                |                   |
                |--- Flee ----> |
                |                    |
                |--- Trapped ->|
                |                    |
Sensors ------- Cruise -------- Motors

?

[Rud]

Subsumption does not approve of modeling the state of the environment. I don't recall it saying explicitly not to have any internal state. In fact there has to be some internal state to accomplish ballistic behaviors. To back, rotate, and go forward in a ballistic move requires triggers based on time or distance. The triggers and the flag recording which step is underway are internal state. The Trapped behavior requires state to determine the robot has not moved (distance state) for a period of time (interval state).

Bump is a behavior triggered by the bump sensors. I implemeted RedDot by putting an inhibt on the Flee structure and it worked fine. I think you are correct that Trapped should move above Bump but not sure if it should be higher. Have to think and experiment on that.
Here is the stack as implemented right now:


                |--- RedDot --> |
                |--- Flee ----> |
                |--- Bump ----> |
                |--- Trapped -> |
     Sensors ---|--- Cruise ----|--- Motors