Fritz Heckel

E-M:

This has a pretty good example of k-means, which at least helps with the basic idea: http://www.ise.ufl.edu/pardalos/dm/k-means.pdf

Cross-validation basics:

http://www.cs.cmu.edu/~schneide/tut5/node42.html

ANOVA:

http://www.physics.csbsju.edu/stats/anova.html

http://www.uwsp.edu/psych/stat/12/anova-1w.htm

Bayes:

Still working on some links for this.

y

Red Army

Combining Influence Regions

Also, a really lucky screen– this was the first load of the tank and dead body into the world, and the coordinate choices were purely accidental.

Run over by a tank

Some of these I can fix now, others will be trickier

• When using a path planner, need to make sure that the current path gets invalidated if a behavior other than the one that created that path takes over and moves the agent around. Really, each agent should probably have a single action model– at present, for ease, each behavior has a separate action model instance.
• Action model also needs to take into account the behavior parameters. At the moment, the USAR victim wanders the world looking for a hiding place, and will move away from it if another agent comes near. However, during the wander, the agent does not attempt to move away from other agents which may be wandering nearby. It may be that there should just be a “move away from agents” behavior which picks a new goal, but the behavior parameters/moods are going to be important to integrate here.
• Action model needs sensible defaults for certain things, like the ranges at which actions can be perceived. In some cases, these are provided as options to the behavior, but not all.
• Rotation issue has to be dealt with. Perhaps once within particular range, send a goto command on the rotate?
• Wishlist for FI3RST: Minimap, text labels over agents, semi-transparent circles representing visibility ranges on objects, affordances, etc.

This post is to advise about the status of the scenarios and give my reference behaviors

1. Urban Search and Rescue
   1. Role 1: Rescuer (incomplete)
   2. Role 2: Lost person (incomplete)
2. Area Protection
   1. Role 1: Protector
      Priority 1, trigger Always: Go to point, (-297.7, -470.3). Agent goes to a point in front of the restricted doorway and holds position.
      Priority 2, triggers See Agent (Successful Authorizations = 0) and Location Type (Restricted Area): Request Authorization. Agent requests authorization from any agents which approach and have not yet successfully authorized. If they do not authorize within a certain time period (5s), they are marked as having failed authorization.
      Priority 3, triggers Hear Speech: Confirm Authorization. If agent hears speech, checks that the speech matches the password for authorization. If password is correct, source agent is marked as authorized. If incorrect, source agent is marked as unauthorized.
      Priority 4, trigger See Agent (Successful Authorizations >= 1): Carry On animation. When authorized agent approaches, turns to agent and gives "carry on" signal
      Priority 5, trigger See Agent (Failed Authorizations >= 1): Halt Animation. When an agent that has failed authorization approaches, turns to agent and gives halt gesture. Alertness is incremented.
      Priority 6, trigger See Agent (Failed Authorizations >= 1) and Mood (Alertness >= 10): Wave Away Animation. When an agent that has failed authorization approaches & alertness is elevated, turns to agent and gives wave away gesture. Alertness is incremented.
      Priority 7, trigger See Agent (Failed Authorizations >= 1) and Mood (Alertness >= 100): Ready Stance Animation. When an agent that has failed authorization approaches & alertness is elevated, turns to agent and gets into ready stance. Alertness is incremented.
      Priority 8, trigger See Agent (Failed Authorizations >= 1) and Mood (Alertness >= 100): Point Gun Animation. When an agent that has failed authorization approaches & alertness is elevated, turns to agent and points gun. Alertness is incremented.
   2. Role 2: Unauthorized individual
      Priority 1, trigger Always: Go To Point (-208.13,-435.4). Agent attempts to enter the restricted Federal Building and hold position.
      Priority 2, trigger Hear Speech: Provide Authorization. If the agent hears a challenge, it offers a fake password, attempting to bluff the authorization process.
      Priority 3, trigger See Action: Respond To Action. If the agent observes an action, it responds to the action. If the action is hostile, the agent becomes scared and decreases the perceived friendliness of the source agent.
      Priority 4, trigger Mood (Scared >= 1): Avoid Hostiles. If the agent is scared, it leaves the area and avoids regions where there are hostile agent (Friendly Actions < 0).
   3. Role 3: Authorized individual (incomplete) Will be similar to unauthorized agent (could be identical, but with correct password)
3. IED Sweep and Defuse
   1. Role 1: Bomb squad member
      Priority 1, trigger always: Explore Map. Methodically visits each region of map
      Priority 2, trigger See Agent with Mood Nervous: Go To Point. Goes to the location of the suspect
      Priority 3, trigger Find Object with objectName 'bomb' and range 90: Go To Point. Goes to location of bomb if found
      Priority 4, trigger Find Object with objectName 'bomb' and range 5: Remove Object. Removes found bomb. Also increments Mood 'Alertness' and Performed Actions 'Defused Bomb'.

      Note that it is possible that this particular behavior will not defuse the bomb if the bomb squad finds the suspect first. I expect to modify the reference agent so it uses an And trigger dependent on the agent having heightened alertness or performed a Defused Bomb action. A better reference agent would also approach to a certain distance from the bomber, and then use the point gun animation.

   2. Role 2: Bomber
      Priority 0, trigger always: Wander. Wanders around the map
      Priority 1, trigger Location Type (vulnerable area) and (not) see Agent and Performed Action (Placed Bomb, value 0): Place Object. Places a bomb, also increments Mood 'Nervous' and Performed Actions 'Placed Bomb'
      Priority 2, trigger Performed Action (Placed Bomb, min value 1, max value 600): Explore Map. Methodically visits each region of map
      Priority 3, trigger Performed Action (Placed Bomb, min value 1, max value 600) and Location Type (Hiding Place): Go To Point. Goes to an area marked as 'Hiding Place'.

      Note that this behavior does not require that the agent get close to the Vulnerable Area before placing the bomb. This would be a better policy, and the best reference agent would include this.

Trying to figure out how to make these different weird things a bit more normal for the interface.

First off, behavior parameters, the ones that aren’t hacked-on workarounds for a lack of inventory, are really “moods”. So the Behavior Parameter -> Mood in the interface. The trouble is that we still have the Placed Bomb behavior parameter to deal with, which is sort of the odd one out. So in the interface we probably need to put this down as “Performed Action”. Hunter is going to hate me, because this makes his life more complicated.

Behavior Parameters are used for triggers. As the “Mood” trigger, we will allow monitoring of internal state, such as Nervous, Scared, Alert. As the “Performed Action” trigger, we will allow monitoring of internal state such as “Placed Bomb”, “Defused Bomb”. Underneath, these will be the same trigger.

They are also used to observe other agents. In the See Agent trigger, they will be allowed to monitor the moods, such as Nervous, Scared, Alert.

I think this makes sense and is the best way to handle it. I’m sorry about the special-cased code.

update: Instead, I will split the behavior parameters out into Behavior Parameters and Performed Actions in the query file, since this is how they split with which are available to different triggers, and eliminates the need for special case code. In addition, to deal with the Agent Parameter weirdness, I’m going to change them from Authorized and Hostile Events to Successful Authorizations and Failed Authorizations. Still need a name for that one, but it just affects a single string in Hunter’s code.

Other updates: the place object behavior will need a note that placing a bomb makes the agent more Nervous and increments the Placed Bomb counter. The remove object behavior will need a note that placing a bomb makes the agent more Alert and increments the Defused Bomb counter.

Animation Changes: Each animation behavior now also emits an “action” comm percept. We could probably emit an action comm for checkauthorization and provide authorization instead of a text comm.

Ugly Hack: Agents now have knowledge of all other agent locations in percept manager– but only one behavior uses this, the AvoidHostileAgents behavior, since it needs to know where unfriendly agents are to get away. The need for this will be eliminated when we have a memory model

Scientific:

Accomplishments:

• …

Challenges:

• …

Engineering:

Accomplishments:

• Integrated other people’s models
• Integrated other people’s code
• Cleaned up other people’s models
• Cleaned up other people’s code

Problems:

• Decomp still sucks, but at least we don’t walk off the world
• Animations are there, they might be working. looped animations weren’t working yesterday, but Keith thinks he has them fixed now.
• Finally started testing the astar pathing, but the gateway path code from Hunter is busted. Looks like the A* is correct. This is needed since the walkable building is a u-shaped obstacle
• Colors in the marker system don’t work. Not even sure which version of the marker code to use
• I’m sure there are other problems in BEHAVE that I haven’t gotten to test yet.

This post is primarily to organize my thoughts about issues which I only realized this evening, now that I (almost) have animations ready:

• How do we communicate the animations to the observers? The imposter needs to know that the level of alertness of the guard is increasing, and to get away. This could be done with the alertness parameter, but i don’t have a good solution for monitoring it. Perhaps the imposter can set the guard’s alertness level as an agent parameter, and we can monitor for an increase? I think this is the best solution.
• Should guard check for authorization each time the imposter returns? If not, how do we increment the guard’s alertness? If so, how do we get the guard to check authorization and then go to the alert animations?

Scientific:

Accomplishments:

• A lot of the basic ideas such as behavior parameters work

Challenges:

• It’s hard to sense things like “suspicious” or “scared”. The temporary hack is to make these behavior parameters, and provide agents with limited ability to sense a few behavior paramaters, but this needs some thought
• Sometimes you just need inventory and other basic game-ish things. We’re going to have to add in some basic features to the agents
• Desperately need to start using additional tabs in BehaviorShop. We’re putting stuff into the main tab which belongs under dialog, and other such things. I also suspect that we need to add some study infrastructure for behavior shop.

Engineering:

Accomplishments:

• Multiple triggers definitely work
• The behavior parameters definitely work.
• Agent parameters, reflecting “opinions” and relationships with other agents, appear to be working
• We have some decent reference agents, though they’re not all complete

Problems:

• Need animation integration
• Need fixed up decomps
• C++ rewrite still on hold

Papers

• FDG and FLAIRS camera ready copies coming up soon
• Sandbox paper has been outlined

Comms, affordances, and objects were all rushed into BEHAVE, and it’s now causing major problems. This is partially my fault; I didn’t think through the roles as carefully as I might have and realize that the first batch would in fact include agent interactions.

But ultimately, we’re going to have to plan things better, because rushing stuff in just makes a mess. A lot of this cruft will get cleared out with the migration to C++, and C++ will make it harder to rush in new stuff like this anyway, but we really need to be careful, else we end up with odd problems popping up later.

In light of the fact that it looks like we’re not getting into user studies till Monday, I am going to try to get the C++ version going. If it’s not in good shape by Sunday, I’ll go back to the python code.