Fritz Heckel

Scientific:

Accomplishments:

• A working plan for dealing with the behaviors needed for the guard scenario was sorted out

Challenges:

• During the rewrite, need to go over the engine pretty carefully and make sure we’re dealing with memory, agent relationships, and other such things in a principled way. We’ll need to start using the other tabs in BehaviorShop

Engineering:

Accomplishments:

• The difficult behaviors are pretty much in place and ready for testing

Problems:

• Haven’t really touched the C++ rewrite this week
• At this point, need the animations and a good way to actually invoke them; since that part of FI3RST has been a bit of a mess, getting them working has been painful. I’d really rather not be writing the timing logic to make sure they don’t get interrupted into the behaviors.
• Currently have written some things into behaviors which belong in other sections of the agent description

General problem: Guard scenario requires agent interaction

Specific problem: Guard must have memory of agents that have attempted to enter, to provide escalating response. However, unless we add a specific “attempt to enter building” behavior which is then detectable by the guard, we have a continuous action (moving towards guard/building) which needs to be treated as something episodic so that the guard doesn’t overreact.

Possible Solution: Keith provided this idea, and I think it’s a good one. We should actually adjust the guard’s internal state / memory on transitions. So when an unauthorized agent attempts to enter, the guard moves into a response behavior, and on that transition to the response (the trigger), a “hostile event” counter on that agent gets incremented.

Challenges: The guard’s memory must be adjusted when the trigger fires, so we need to attach a rider to the trigger which actually makes the change. Not a huge deal in the code, but a bit trickier to do intuitively in BehaviorShop. In the PerceptManager, a dictionary for each agent encountered will be kept around, keyed on particular memory types (hostile, friendly, etc.), with a value.

My concern is that this solution, and additional pieces which will be needed to implement it, will start making BehaviorShop a bit complex.  I guess we’ll just have to try it and see.

BEHAVEngine

• Created the initial Python implementation of BEHAVEngine
• Multithreaded agent engine
• XML specs
• Uses region decompositions
• Interfaces with FI3RSt
• Includes agent, object, transient, affordance and location percepts
• Paper submitted to FLAIRS 09

SSPS

• Rewrote SSPS in Python as an object oriented system
• Calculates additional information not in original implementation (centroids)

Influence Points

• Wrote up basic implementation of influence points and influence maps
• Compared points and maps and submitted as a paper to FDG 09

Misc

• Research at NRL on interest/boredom detection submitted and accepted as late breaking abstract and poster to HRI 09