Fritz Heckel

Since I want the ActionModel to take care of action resolution, and there to be only one per agent, it can’t be used directly by the agents. Really, though, this is a good thing. The ActionModel also needs to store some basic state information for behaviors—if following a path, it needs to keep the path around. It should at least track the effectors so it can figure out when they actuallly run.

So I’ve added an ActionModelInterface class. It has storage for some basic state, hold onto the SubsumptionPolicy of the layer, and has simplified move/speak/act request functions. This should actually simplify behaviors, and to some extent, the ActionModel, quite a bit.

This functionality could just be folded into the Behavior base class, but I think this approach is better. If nothing else, it makes for easier testing, which is important right now.

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

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.

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.

To deal with the previously mentioned problems, and clear up the mess that is percept handling at present, I’m putting together a new object for the agent core. The PerceptManager will be a single object for each agent which ties up behavior parameters and percepts. It will also help reduce some overhead, in that the agentcontroller will generally never need to touch the percepts. The object itself will also handle locks for each type of data. To keep data flowing, the agentthread will still copy the percepts out of the object, though behaviors will probably get to directly act on the behaviorparameters, since those will be entirely entirely to the agentcontroller.

Percepts are currently handled as pure percepts, which are always available, and so treated as a dictionary. The only item in this dictionary so far is egoLocation. Transient percepts will temporarily be treated as one pipe (but expect that this will change). Geometry percepts will be treated separately once SSPS is available.

With one type of percept– egolocation– it’s easy to figure out how to deal with it. We keep overwriting the egolocation every time we get an update. With multiple types, it’s less clear.

So far, I’ve just been overwriting the percepts that are passed into each individual agent controller. This works well because we’ve only got one type. But with multiple types, need to be a bit more principled. I don’t really want to handle each type of data differently at the main thread; the main thread should just focus on routing percepts to the appropriate agents, rather than routing the individual types of percepts.

This implies that the percept management should be handled within the agentcontroller. In an ideal world, we’d do no processing– as current. Really, we need to be more careful. Some types can just be overwritten: egolocation, for example. But some may need to be handled differently. With the investigate example again, if the agent hears multiple noises, it should be able to keep track of (at least roughly) where they are, so it can investigate all of them in turn, and them drop them. If we have a “defend location” behavior triggered by the appearance of enemies, we should hold onto all enemy percepts which may affect how the behavior actually runs.

Three categories then: percepts that are always present (call them pure percepts), percepts which are events (transient), and percepts which directly observe other entities in the environment (referential). Furthermore, some transient percepts may actually be related to referential percepts: if the noise is in fact just a really loud bullfrog, then we should know to ignore it in the future, because we know there’s a bullfrog there.

From a cognitive standpoint, transient events should have some memory associated. It’s generally acknowledged that people have a sort of “iconic” memory for transient visual events, and an “auditory loop” for auditory events.

Arguably, this is overthinking, because we can cheat our way around it. But the architecture will be a stronger contribution if we do just a little better. I’m not claiming that we should do everything like the roboticists do– this is clearly a step above that. Also, we shouldn’t necessarily do everything the way cognitive scientists do (at least not yet). But I want to find the right shortcut for this.

For now, I think I’ll continue to treat the pure percepts with overwrites, and add in queues of limited size to deal with transient percepts. Referential percepts will be ultimately go into some sort of collection. Filters can be attached to the transient percepts, so that they can be ignored once the agent has decided it’s dealt with them– at the agentcontroller level, we’ll keep tags on all the percepts to track origins. These tags will either not be passed onto the behaviors, or only passed on once the behaviors have discovered the origin.

There is one issue with basing triggers on the current percept stream, and not allowing them to run until a behavior is complete/goal achieved: short-span percepts. Example: a “Hear Noise” percept– the noise may be a short-span percept, only received once instead of ongoing. Without additional state, a “Go To Point” behavior will not achieve the goal of investigating the noise.

The trigger could instead generate some sort of state that can be interpreted as a percept– a goal of investigating the noise. This would generate some additional complexity in mapping the agent description to the agent implementation.

Alternatively, this trigger could remain active until the behavior it activates turns it off, giving the go to point the opportunity to properly investigate.

Or perhaps something like “investigate” is a higher-level behavior that makes use of go to point.

Or maybe I’m over thinking this right now, because in the end, “investigate” is a fairly high level behavior– to really generate this behavior, there has to be some persistent plan to check out a point or series of points as disturbances occur. There has to be some sort of internal state to do this effectively.

To get the event simulator tested thoroughly, I will just temporarily keep the triggers active until they are turned off. I’ll add in some behavior parameters once I know this is working.

The agent core is now loading in DASSIEs files to build agents, and behavior subsumption is working correctly. In addition, it will now dump an xml file with a listing of available behaviors and triggers, which DASSIEs can consume.

The Task: Evaluate the agent engine, to see how well it does at translating specification for the agent into a fully functional agent.

The Problem: Because the agents are generated using the UI, any rating of the agent will necessarily be a rating of the agent + the UI. Each piece needs to be evaluated separately.

Subproblem: Also entangled in this evaluation will be evaluation of individual behaviors in the engine, as well as the how the engine manages the behaviors.

Solution:

The main problem can be solved through a carefully built study.

Resources: An AI expert needs to be trained to translate the output of the user interface into actual behaviors. This expert must be able to read the XML output of the UI, translate it to a set of instructions, and then carefully follow these instructions while controlling an agent manually.

Another AI expert must also be trained to manually write the code to implement the behaviors specified in the XML. This expert will build individual, non-configurable agents hardcoded to behave as specified. This expert will be allowed to use the pre-defined behaviors available to the agent engine.

This also requires that a FI3RST interface which displays information about the current state of the agent and the world be constructed: this will include information such as the current location of the agent, and the current heading of the agent.

Procedure:

Subjects will be recruited who have no experience with AI (the subjects are AI naive). They will be given a short training period of how to use the UI, constructing agents for a small number of simple scenarios (2-5), but they will not actually instantiate the agents with the agent engine. Once the subjects are comfortable with the interface, they will be given two test scenarios. They will use the UI to generate agent specifications for each test scenario. These specifications will then be instantiated in three ways: the agent engine, the AI expert controlling an agent directly in the world, and the ai expert programming an agent. Movies of each of the agents will be recorded, and then played back for the subject in random order. The subject will rate each agent on how well it performed the specified set of behaviors, how well this conformed to their expectation, and the naturalness of the behavior.

Analysis:

After judging, the performance evaluations will be analyzed relative to one another. The hypothesis is that the human controlled agent will be rated as significantly more natural, but that both AI controlled agents will match the human controlled agent in performance.

I’ve started filling out the major components of the agent core; I have a base class for AgentBehaviors, am filling in functionality for the AgentThread, and have rough versions of the AgentController, GameController and main application threads. Most of the work I’ve done so far is on the AgentThread.

The AgentThread class has six major methods at present:

• run() : The meat of the agentthread. It first sorts the behaviors by priority and builds the generator functions for each behavior. It then goes into its main loop; each iteration includes a subloop which iterates over each behavior as many times as it is able given available resources. At present, it depends on the AgentController to tell it when to stop, collect its answers, and  reset for the next run. At present, it is not guaranteed to run all behaviors in the list.
• addBehavior(behavior,priority): Adds a behavior at a given priority — default is priority 0. Lower priorities run first.
• stop(): Tells the thread to stop running completely
• reset(): Tells the thread to collect its effector answers and reset for the next run. Also increments the step counter.
• setPercepts(): Sets up percepts for next timestep. Should be called before reset()
• getEffectors(): Gets the collected effector requests. Should be called after reset(). Returns false if effectors are not yet ready for harvest

These will change as the agentthread becomes more properly resource aware and is given a specific quantity of system time to work with. Also note that at present, the run thread starts working immediately after returning effector results; ultimately it will wait until the AgentController thread tells it to continue.