Anthony M Harrison

I am. I am.

Surprise, surprise, my previous rant was completely unjustified. Turns out it was my own stupid fault. I was programmatically launching player, unfortunately I forgot to harvest the program’s stdout and stderr. The process’s buffers were flooded. Stooopid Ediot!

But, at least the monkey sims can run for much longer now. And not a moment too soon as the robot lab is rapidly filling with interns. (It’s such a nice change of pace to no longer be on the bottom of the totem pole)

I love division of labor, it saves us all from having to reinvent the wheel.. but sometimes it just drives me insane.

I’ve hooked up player/stage through a java client, enabling jACT-R (and the monkey models) to interact in the simulated robotic environment. For sometime now I’ve had a bug where stage would freeze after around four minutes of simulated time. I initially thought it was due to my unorthodox use of the client (the threading model in the client is a tad weak), so I reverted it back to the normal usage and the simulations were now running past four minutes with no problem. Yay, problem fixed!

Nope. Now it dead locks around 6 minutes. So maybe it’s a problem with stage? Lo and behold, someone else was encountering a similar problem. The recommended fix? Upgrade to playerstage 2.1, which is, of course, not support by the client yet and no one has posted any word on an ETA.

I am able to detect when it occurs, which lead me to believe that I’d be able to disconnect the clients and reconnect. Unfortunately, the only way to resurrect stage at this point is to completely kill the socket owning process. My only option is to not only disconnect the clients, but then force quit stage and restart it.. Ick!

I think it’s time to work on something else for a little while.

* This is not meant as a disparagement of anyone’s work, rather just me venting. I fully acknowledge that the same statements could be- (and probably have been-) applied to my own work.

After finally getting the movement tolerances working the jACT-R so that the robo-monkeys could finally see each other as they move around, I came upon a motor bug. Actually, I’m still trying to hunt down the exact circumstances under which it occurs. It’s particularly challenging because it involves the interaction of the robot/simulation sending a movement status and colliding with the model’s desire for things to complete in a predictable amount of time.

Since this bug is so hard to track down given the current tools, I decided it was about time to implement a long desired feature. In my experience, and the reports of others supports that, most of us just run the models and when something goes wrong we dig through the trace. Only as a last resort do we ever really step into the models. (Basically, all that work I did to integrate break-points and a debugger were for naught )

However, once we’ve found where something went wrong we immediately want to know what fired (easy enough from the trace) and what the state and contents of the buffers were (not so easy). The log view jACT-R has provided is good, but not great. The tabular format and filters makes it easier to ignore irrelevant info, but you still don’t get a clear picture of the buffer contents. To rectify this I’ve added the ability to dynamically modify the tooltip for the log viewer. Combined with the buffer event listener and the runtime tracer, the log view can now display the full contents of any buffer as well as its flag values both before and after conflict resolution.

The buttons on the tooltip allow you to toggle between seeing the buffer contents before and after conflict resolution. It’s not completely correct right now in two regards: some state information may be lost at the start and end of a run (i.e. your model starts with buffers pre-stuffed or the runtime terminates before sending the last bits of info), and the changes to the chunks while in the buffer are not being tracked. The first issue I don’t care about, but the second will be addressed soon.

This added information does carry with it a moderate performance penalty so I’ll be including it as a runtime configuration option. A little later I will also add tooltip information for the declarative (i.e. visualization of encoded chunks) and procedural (i.e. fired production and resolved instantiation, encoded productions) module traces.

But for now, I’m quite happy and this is making tracking down that spurious motor.state=error soooo much easier.

First off, I’m not talking distributed representations, no, this is entirely about implementation.

While the community is still some ways off from needing something like this, in the future many of us will be running models across much longer time-spans, both simulated and real. These models are going to seriously tax the underlying implementations. Currently jACT-R has no problems with chunk counts in the hundreds of thousands, but millions? And what about productions? Most hand-coded models don’t exceed a few dozen productions, but with production compilation enabled for a long period in dynamic environments, it’s easy to envision scenarios where the production counts will be on par with the chunks.

This scenario is rapidly approaching for us working with robots operating over anything but the most trivial time scales.

The big information companies out there manage this volume of information easily with existing database systems. Why should the ACT-R implementations have to manage their own information searches, linkages and retrievals when there are specially tailored systems that can do it so much better?

Imagine if all chunks, types and productions were backed by something like MySQL. ACT-R could be freed to maintain only the most active subset of procedural and declarative memory, while less active information would be managed by the database. This scenario carries with it a slew of useful benefits.

Scalability

The most obvious benefit of database backing would be in scalability. Database systems are designed to handle data quantities well beyond what we have attempted to this point, but quantities that are certainly within the realm of those required by long running models. By limiting ACT-R to only the immediately relevant information set, the architecture would require significantly fewer resources that could be better leveraged elsewhere.

This information subset could be intelligently managed using information we already have available. As the chunks in a buffer are changed, relevant chunks could be prefetched by following the associative links. The declarative subset would effectively be managed through the activation levels. Similarly, productions could be prefetched based on the chunktypes of the chunks currently in declarative memory. As the chunks and productions are deemed to be no longer relevant, they can be committed back to the database system (if changed) or discarded outright.

Persistence

Obviously, anything stored in a database is persisted. This gives us the ability to created bootstrapped models. I can’t count the number of times I’ve heard researchers wish they could have preexisting models of some user group. This scheme would allow us to have specific databases of different population types and knowledge. With access restrictions, we could even set up domain specific databases (i.e. mathematics knowledge) and constrain what any connected model could access (i.e. up to and including algebra education). This applies to declarative and procedural knowledge equally.

With some neat use of caching database systems, you could set up a centralized immutable system with a common knowledge base, accessed by each lab’s local database system which is accessed by all the researchers, who themselves have a local system running with write privileges for their respective models. Similarly, there is no reason that any one model would be tied to only one database system. Need a model of a high-school senior who plays video games? Point the model to an aggregating database that provides access to separate high-school level knowledge bases and then point it to a video game specific database.

Performance

Much of the scalability benefits are directly relevant to performance. What’s really nice about having multiple database systems is that the architecture could make multiple simultaneous search requests to all the databases and harvest the first result. With network latencies decreasing every year, it’s not unreasonable to expect that infrequently used information would still be accessible faster than realtime.

But how?

I can’t speak towards how one would implement such a scheme in Lisp. The lack of real threading across most implementations makes this a challenge. In jACT-R this would be relatively simple (it’s still one heck of an undertaking).

For maximum performance you’d want the system to engage in asynchronous management of the relevant information subset. Fortunately, both the procedural and declarative modules already support asynchronous modes of operation. Each would attach listeners to the buffers (for chunk additions and removals) as well as to the chunks in the buffers (to catch any changes). All the chunks associated with these active chunks could then be prefetched. Similarly, their chunk-types would be used to prefetch the productions that depend upon those chunk-types.

Since all major entities (types, chunks, productions) are represented as handles, the system can create and return these handles before the contents have been fully received and recreated from the databases. This allows the architecture to work with the chunks and productions before they are actually available, further exploiting the asynchronies. (Obviously, if the chunk or production’s contents need to be accessed, the system will block until that data is available).

While this prefetch mechanism would work well for information directly connected (through some depth), it doesn’t address the retrieval of information specified at runtime by productions. Fortunately, the retrieval module relies upon the synchrony of the declarative module. It would merely make a request from the database and immediately return a handle to a chunk. If no result is received within a specified window of time (or an empty response returned), the declarative module would just redirect the handle to point to the standard error chunk.

As chunks and productions become irrelevant, they can be checked for any parameter changes. Any changes can then be sent back to the database for persistence. Newly created chunks would be handled in the same way, only committing when the chunk is deemed to be contextually irrelevant. Fortunately, Java already supports a mechanism to keep track of object references, so other modules would still be able to prefetch information and retain it indefinitely without fear of it being reclaimed.

jACT-R already has a simple format that is easily persisted and searched in databases, and is already used to transmit information in an agnostic manner across the network: the ASTs used to bi-directionally translate between source and model.

In theory, all of this could be accomplished by extending the default implementations of the declarative and procedural modules, with custom implementations of the chunk, type and production handles (to notify the modules when they are no longer relevant).

Will this idea ever see the light of day? I sure as hell hope so. Is it anywhere on my horizon? Nope. Little old me still needs to bump up the pub count.

For the past few days I’ve been working on implementing the movement tolerance handling in the visual system (and aural, configural, manipulative), and I’m really tired of it right now. It was supposed to have been easier than this (hell, it should have been done last week) - but it ultimately required some significant refactoring of the asynchronous caching of afferent chunk encodings. Total headache.

Now as I’m getting to the final tidbits, I’m incredibly bored with it. Add to that the fact that I prefer my code to be readable, twice now I’ve refactored what I’ve already done. It will be done this week..

..but for a distraction, I’ve added a new category to document some of the crazy cool ideas I’ve been playing with in the back of my head. There are some that I converse with who believe these ideas should be held close to the chest until I can get prototypes assembled, but I’d rather throw them out there, see if they have any resonance with folks and to get some additional feedback.

Without further ado…

It took longer than expected (what doesn’t?), but the update to MINA 2 has been completed. MINA provides the underlying communications infrastructure between jACT-R and CommonReality (which provides the simulation brokering). The previous version had an out-of-order bug that took me forever to track down. I figured it was my code and my liberal use of threads, but it turned out to be a MINA issue. Fortunately, the 2.0 release (M2) has a more consistent threading model that functions much better.

While initial runs showed that it actually ran slower, subsequent runs have revealed that was due to the short duration of those early tests. Long term executions, such as my handedness model, are hovering around the original performance numbers (~ 50-70x realtime). No complaints from me.

The update required significant rejiggering of the state and connection management which should now allow participants to come in and out at anytime during the simulation (assuming none is the exclusive owner of a clock). I can now return to examining some model fits, further monkey refinements, perhaps get my dissertation into a publishable form? Craziness.

The next stage in the monkey modeling will incorporate some new features we’ve been playing with at the lab: gaze following. Aside from being relevant to developmentalists, gaze following presents a useful and cheap perspective-taking surrogate in the absence of more advanced processing. From my current meta-cogitating perspective, this also provides a useful starting point for goal inferencing.

But before I do that.. I really need to fix the movement tolerances in the visual system..

Last week marked the first major deadline that I’ve had here at NRL. The boss man was presenting our work at a social cognition workshop that was populated by cognitive and developmental psychologists plus some roboticists. From his report, it was an interesting interchange.

Our push leading up to it were some model fits of the monkey models plus demos of the robot running the models. The fits didn’t happen (bug in common reality that I’m working on currently), but the movies did (and should be posted soon). The final push towards the deadline has highlighted a few architectural divergences between jACT-R and ACT-R proper that I need to address. Those differences that are clearly mistakes will be patched, but those that are architectural decisions will likely be parameterized.

The post-workshop debriefing has produced some interesting discussions around here regarding the nature of theory of mind and meta-cognition more generally. Some of my early brain-storming regarding concurrent protocols seems like it really will set the stage for a general meta-cognitive capacity. Production compilation, threaded cognition, and a carefully designed declarative task description can get us really close to this goal. However, I suspect there are two pieces that need to be developed: variablized slot names and the ability to incrementally assemble a chunk specification (i.e. module request). I throw out this tantalizing bit with the promise that I will post a very lengthy consideration of this issue in the immediate future (I need to put together the pieces that currently exist and see how it plays out).

My insomnia development of the production static analyzer and visualizer is coming along nicely. Below are two screenshots from the analysis of the handedness model (which uses perspective taking to figure out which hand another person is holding up). The first shows all the positively related productions and their directions (i.e. which production can possibly follow which), with the selected production in yellow and its possible predecessors in blue and successors in green. The icons in the top-right corner show the filters for showing all, sequence, previous and next productions, plus positive, negative and ambiguous relationships. There are also configurations for layouts and zoom levels. Double clicking the production will switch the view to sequence which filters out all the other productions that are not directly related to the focus, across a configurable depth (1 currently).

I’m still not handling chunktype relationships, and I also need to provide buffer+chunktype transformations (i.e. +visual> isa move-attention doesn’t place a move-attention into the visual buffer, but a visual-object instead). Once those are in place, I’ll add a chunktype filter to the visualizer so that you can focus on all productions that depend upon a specific chunktype, which will help really complex models (the monkey model, with all of its contingency and error handling is around 90 productions, all nicely layered by hierarchical goals, but that’s still a boat load of productions to have to visualize at once)

I’m hoping to get a bunch of this menial development and fixes done on the flight to/fro Amsterdam for HRI. If all goes well, there should be a groovy new release in two weeks.

I’ve previously mentioned that I’m working on a static analysis tool for productions. Basically it gives you a score that reflects the match between two productions based on their conditions and actions. This allows you to visualize their relationships without ever having to run the model. A huge chunk of the basic logic is done and thanks to the joys of open source tools and my new favorite project, Zest, after a day of tinkering I’ve got a basic (but far from ideal) visualization tool:

Here we’ve got the unit one semantic model showing one of the three different view types: following. This shows which productions can follow the chain-category production. You can also view proceeding productions (those leading into chain-category, which only shows initial-retrieve in green), or All (showing all the productions and all their relationships).

It’s still not perfect. It’s not handling chunk type tests (simple addition), nor variables (bloody impossible without a hypothesis testing tool too), nor more comparison slot tests (less-than, etc). But all in all, pretty damned cool and useful.

In the weeks that have passed since I last posted on my work and ideas much has happened in the world of interfacing ACT-R with robots. As of Friday, jACT-R was piloting our in house robot, George. Yeah, there were a few glitches, but damn was it cool. The integration of jACT-R with actual robots and simulated has illustrated many interesting issues with respect to modeling in realtime domains (and I’ll use the softer definition of being able run within a 50ms cycle time on average, not deterministically). I’m thinking about putting together a talk for the ACT-R workshop this year on the topic. Could be interesting.

The test bed has been a social learning model (two actually, otherwise it wouldn’t be very social) of a chimp learning what food is safe to pursue in the presence of an alpha male. It’s quite entertaining. Two robo-chimps enter a space. The dominant will always pursue whatever food it can see and if a subordinate gets too close, the dominant will smack it. The subordinate needs to learn what food is safe to pursue based on distance and its visibility to the dominant. I’ve got the models up and running and interacting with each other in parallel (trivial for jACT-R, but not the Lisp) and the models are actually running faster than playerstage (i.e. they spend most of their time waiting for the simulation to advance the clock and send sensor data). The subordinate engages in perspective taking and can make the critical go/no-go decisions. The only problem is that the dominant has suddenly decided to pacifist on me. It refuses to smack the subordinate.

Much fun. The challenges that this work have presented have resulted in some serious improvements to jACT-R, to the point that I will state outright that I believe jACT-R is the better option if you need to work with real systems. Granted, it’s still not feature complete (compared to the Lisp) and there are still significant gaps in the theoretical validations - but all in all, she’s a fast and easily (and safely) extended system.

One element that I’ve been working on after hours has been a static production analysis tool. It hooks into the model compiler (unlike the Lisp which builds a live model, jACT-R models are entirely declarative and need to be parsed, compiled and built), and examines the possible end states of productions. From this it can generate probable execution paths. If you’ve ever had to read someone else’s model (hell, even your own after a month away from it) you’ll see the obvious appeal of such a tool. This would be particularly useful for inspecting a model after an extended run with production compilation enabled. Those productions can get down-right strange after enough time. I’m hoping to have a function GUI for this beast to show this summer. Hopefully I’ll be doing a tutorial at the ACT-R workshop to introduce folks to the whole system. A coming out party, if you will.

Anyway. Now back to the barrel and inject some aggression into those monkeys.

There’s been an idea percolating in the back of my mind for the past few weeks. It all started with the boss’s boss, Alan Schultz’s desire for a cognitively plausible mechanism for robots to explain what (and presumably why) they are doing what they are doing. While for Alan this was a practical desire, it struck me that from a cognitive psychology perspective what he was asking for was actually much deeper and more interesting.

What he really wanted was to have robots engage in concurrent verbal protocols (Ericsson & Simon, 1993). This is a general task that asks people to describe what they are doing while they are doing it with as little filtering or elaboration as possible. The idea is that these utterances represent the most basic description of the contents of working memory in service of the current goal. A great introspective tool (more so that retrospective protocols at least).

From a cognitive modeling perspective the challenge is to implement it in a general manner so that one can use the same productions across multiple models, regardless of goal structures. This means that any model of concurrent protocols should not be dependent upon interruptions of the current goal, but should operate in parallel (hence concurrent).

I do believe that I have a solution. Not surprisingly it relies upon one of my favorite contributed ACT-R modules, threaded cognitiion. Combined with the learning from instruction work that John and Niels have done, an interesting new system emerges.

Extending threaded cognition

Threaded cognition allows a model to engage in multiple goals at once, interleaving them at the production level. However, there is a level of isolation that prevents individual goals from being aware of each other (a good thing). For concurrent verbal protocols to work, there needs to be a mechanism to get at the other goal(s). A modest proposal is to add a query such as this:

(p what-else-am-i-doing
  =goal>
    isa verbal-protocol
    ....
  ?goal>
    other-goal =otherGoal
  ==>
   +retrieval>
    =otherGoal
   !output! (Im also doing =otherGoal))

The example is idiotic, but the idea is that when querying the goal buffer, you can request a reference to the other goal, which will bind to any goal in the buffer that is not the one that fired this production. With the other goal in hand, one can then begin to inspect it.

Learning from instruction

If the goal was learned via the learning from instruction work, you’d have a goal with a state slot. This state slot can then be used to retrieve from declarative memory the instructions that preceded and succeeds this one. In other words, you can launch a retrieval which will describe what it is doing. If one extended the learning from instruction work to include meta information for the justification for that instruction, you now have the ability to query the model for what and why it is doing what it is doing.

Levels of description

Of course, this will likely result in protocols that are very fine in their granularity. The states from learning from instruction are at the unit task level (i.e. reading a letter, pressing a button). This is not really that useful. If one extended the learning from instruction work to include progressively deepening goals (ala standard task analyses), the concurrent verbal protocols could then prefer to report at the level just above unit tasks:

(p avoid-unit-tasks
  =goal>
   isa verbal-protocol
   ...
  =retrieval>
   isa unit-task
   parent =parent
 ==>
  +retrieval>
   =parent)

One could then also query the model for more or less detail where it would then chain up or down the goal.

Beyond just a tool

In discussing this brainstorming, Greg Trafton realized that it may be more than just a damned useful tool. There may be genuine predictions and fits that can be evaluated with respect to the verbal protocol methodologies. Not only does this solution present a potential multi-tasking cost to performance of the primary goal, but the simple act of engaging in the protocols would change the state of the model.

With production compilation engaged, repeated protocols would become much faster as the instruction retrievals are compiled out (just as they were when learning how to do the core task). But more interestingly, the act of accessing the other goal via the retrieval buffer would lay down a memory trace for the partially completed goals. Without the concurrent protocol, the intermediate steps of the goal would be lost (or rather, never encoded). These partial goals may make further explanations easier, strengthen the instructions, provide further compilation opportunities, and (potentially) result in the improved learning that is seen when subjects are asked to explain their actions while learning a new task.

One could also look at the different predictions regarding concurrent and retrospective protocols.

What started as a potential solution to a practical problem, when situated within ACT-R, is now looking like a genuine theoretical construct that may get some serious mileage. Gotta love it when an idea germinates into something so much greater than expected.