Fritz Heckel

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.

Scientific:

Accomplishments:

• Outline of the agent engine evaluation is here

Challenges:

• What is the most effective way to deal with percepts? Clearly some– like egolocation– are constantly available percepts, and should just overwrite with new information. But transient percepts are trickier. We need to make sure they stick around long enough to get used, but individual events shouldn’t last forever. See the previous couple posts for more on this. There’s also the problem of tying the perceptual events to the objects that generate them. I have some idea of how ACT-R does this, at least.
• Behavior parameters and influence points had the back burner this week, but with a plan to deal with percepts– at least temporarily– I can dig into this a little more now.

Engineering:

Accomplishments:

• Finished hooking up the toolchain: the UI generates XML files courtesy of Hunter, and the agent engine now reads them in properly and builds up an agent.
• EventSimulation module built. This allows us to schedule events at various times. The events at present are just “hearnoise” percepts coupled with a location, but we can drop arbitrary transient percepts in it.
• New trigger: Hear Noise. This trigger activates on a hearnoise percept, and saves the location as data. It remains active until the behavior it triggers turns it off. Go to point has been modified to make use of this trigger.
• Added some new options to the agentcore config file: max-threads and target-utilization. Neither is used yet, but max-threads will be soon. Max-threads will define the maximum number of agentthreads spawned by agentcontrollers
• Resolved a bug in the FlexiVehicle opensteer class which was causing gotobehavior to flip out

Problems:

• SSPS still needs to be connected, but it hasn’t been completed yet
• Behavior parameters need to be implemented
• Influence points also need to be implemented

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.

Last week’s status update was actually written Thursday, so much of what would be in this update was actually in the previous.

Scientific:

Same as last week.

Engineering:

1. Discovered the work that needs to be done to get SSPS running
2. Discovered additional work that needs to be done to use the pipe client with SSPS
3. Now have D* implementation in Python which can be used with the agentcore

Challenges

1. Get SSPS running properly
2. Adapt the pipe client to work with SSPS
3. Other question about pipe client: seems like opening and closing the pipe every time we use it is probably adding a lot of overhead– the gamecontroller thread actually does seem to be running pretty slowly, and I suspect this is why.

Paper Status

1. FLAIRS paper w/Hunter on interface evaluation: No change
2. FLAIRS paper on influence points: No change
3. FGDA paper: nothing yet.
4. HRI Pioneers Workshop abstract: Done.

Scientific

1. I have had some ideas on how to present behavior parameters and some of the things we can do with them
2. Worked out idea for influence points with Dr. Y

Problems

1. Need to design an experiment for evaluating the agent core that can be combined with the general DASSIEs evaluation
2. Need to think further about the behavior parameters and how to present them, as well as exactly how they will combine best with influence points
3. Details on influence points and how best to evaluate; running time should work, but is there a performance metric?

Engineering

1. Have come to uneasy truce with gamecontroller thread weirdness. The problem appears to be with this thread, and not the agentcontroller or agentthread.
2. Figured out how to convert the steering forces to reasonable effector commands for now, though this may want to change once we have strafing.
3. Have two working behaviors: patrolbehavior and gotobehavior. Currently these use two separate opensteer classes.
4. Name possibility: Agent Alfa: Agent Architecture for Lightweight Flexible Agents. I really will have a name soon.

Problems

1. Still need to keep an eye out for the thread hangs/crashes, since there are some odd interactions between changes in the behaviors and performance of the gamecontroller thread
2. The steering still looks pretty ugly. We need strafing, and it wouldn’t hurt to be able to combine rotation and motion commands. Actually, it would be really nice.
3. Need to combine the opensteer classes. gotobehavior is based on the “FlexiVehicle” class; I intend to use this to also implement wander, but I made need to ultimately subclass this. Either way, each agent should have a single opensteer vehicle, so we’re not copying geometry into half a dozen different vehicles. Ideally, multiple agents will ultimately share geometry, but I’ll worry about that later.
4. Need to lay out some groundwork for the influence point service
5. Need to hook up SSPS to the agentcore

Paper Status

1. FLAIRS paper w/Hunter on interface evaluation: Need to talk with Hunter about this, but we should have sufficient behaviors to run this, at least.
2. FLAIRS paper on influence points: Not yet started, except for catching up on background work
3. FGDA paper: nothing yet.
4. HRI Pioneers Workshop abstract: Need to take care of this by Oct 15, but it’s short. Will probably combine summer work at NRL and current work at UNCC for this. Also need to pass on request to Dr. Y for letter(email) of support.

The patrolbehavior is working, but a few issues remain:

• It appears that the agent threads are sometimes not generating answers quickly enough, or locking up and not returning answers at all. Because the default is currently to return a stop when there is no answer returned, we get jerky movement. I need to pass a None up and check for it properly so we just skip issuing a command.
• Turning is currently slow– the turning speed of 300 was much to fast, and basically uncontrollable. I didn’t get percepts in or effectors out fast enough, so Ralph would end up spinning in place because it kept missing the target. We need to either include a speed factor for rotation, or a rotate-to command to let the game control the rotation level.
• There are some steering artifacts; occasionally Ralph will make odd loop-de-loop maneuvers. I may have done something stupid in normalizing the angles so that he’s turning in the wrong direction.