[ACT-R-users] visual-location buffer query; tracking

[db30 at andrew.cmu.edu]

--On Friday, October 08, 2010 2:22 PM +0000 David.Kaethner at dlr.de wrote:

> Hello everyone,
>
> I have two questions I could not answer by reading the manual.
>
> 1. I want to harvest the first chunk that is stuffed into the
> visual-location buffer after a scene change (SET-BUFFER-CHUNK
> VISUAL-LOCATION VISUAL-LOCATION0-0 REQUESTED NIL). To do that, I want to
> query the state of the buffer (if there are any chunks in it or not). Is
> there any way to do that? The visual-location buffer does not have a
> query like the visual buffer (state empty).
>

Every buffer can be queried for "buffer full" or "buffer empty".  If you
want to know if a chunk has been stuffed into the buffer you can query
for "buffer unrequested" which is also available for every buffer.  Thus,
this query in a production would only match when there was a chunk stuffed
into the visual-location buffer:

?visual-location>
   buffer full
   buffer unrequested

However, if you want to harvest the chunk, then you don't really need
the "buffer full" query since the buffer test itself is only going to
match if there's a chunk in the buffer.  So, this combination would
be sufficient to match that state and then use the chunk:

(p harvest-stuffed-visual-location
   =visual-location>
      isa visual-location
   ?visual-location>
      buffer unrequested
==>
...
)


> 2. I'm trying to do some tests with the tracking feature. In order to do
> that, I obviously need a moving object first. I want to use the
> act-r-window with a simple loop that works like "add-text-to-exp-window
> -- clear-exp-window -- add-text-to-exp-window (at a new position)".

Before getting to the actual questions, it should be noted that using
tracking with the vision module can be a little finicky to work with.
The mechanism you describe, clearing the screen and adding a new item,
requires the vision module to determine whether or not the items are the
"same" for tracking purposes, and that may not do what you want or expect
all the time.  It is more consistent if you "tell" the module that it's
the same thing either by using the same object in the device or by 
returning
the same feature chunk on subsequent screen updates.  The examples 
indicated
below show those two mechanisms in use.


> The
> problem is that the model needs to run the entire time (instead of having
> it restarted like in Unit 3 of the tutorial). - When do I call the model
> with the "run"-command? If I do it before the start of the loop, the
> model runs through and obviously can't detect anything since the window
> has not been executed yet. If I do it within the loop, the model is
> restarted.

There is no one right answer for how to write the code that presents an
experiment and runs the model.  So, I can't really offer much in the
way of specific advice in that regard.  However, I can make some general
comments about it.

First, calling one of the ACT-R run commands does not restart the model.
All the run commands do is cause time to advance executing the events
which occur as it does.  Thus, a second call to run would just cause the
model to pick up where it left off.

As for writing the experiment code itself there are two very broad
strategies for how to approach that.  The iterative style works as you
describe with a loop executing some code and then running the model
for a while and repeating.  There is another approach however which uses
more of an event-based style.  The event-based style relies on the fact
that the event system that runs the model is also available for scheduling
actions which can execute arbitrary code as well as the ability of the
model's actions (key presses, mouse clicks, etc) to also cause arbitrary 
code
execution.  With the event-based approach there is typically only one call
to run the model needed and any necessary set up happens along the way when
appropriate.  There are examples of both used in the tutorial models, and
the experiment description in unit 4 of the ACT-R tutorial (the unit4_exp
file) discusses some of the differences between them.

When designing the code to present a task, my approach is to try to separate
that from thinking about the model and how it should operate.  Often the 
task
itself suggests a style which may be easier to use to set things up, and
from there the user interaction (be it person or model) just fits in 
naturally.
For a moving object task, an important question would be when does the item 
move?
If it's on a fixed time scheduled then that could be done iteratively by 
using
fixed length calls to run to space out the execution of the movement code, 
or
event-based by scheduling the actions to move the item when appropriate. 
If
however, the item is to move based on the user's interaction then the 
event-
based approach would seem to be the much easier way to go.


> - How often do I have to use the "install-device" command?
> Apparently everytime the model updates the scene (proc-display). But that
> feels odd, since I take it that install-device only tells the model which
> device it has to use. Why should I do that several times?

Install-device should only need to be called once because it does do
just what you note -- it tells the model which device to use.  Without
seeing your code I can't say why you'd need multiple calls, but the
only two reasons that I can think of would be because of the model
being reset or because you're opening a new window for the interface
each time.

> If anyone has
> some example source-code for a tracking task that uses the act-r-window
> I'd be very interested.
>
>

There is an example provided with the ACT-R sources in the examples 
directory
called "visual-tracking-example.lisp".  It contains two example situations
using the mechanisms I described above to ensure that the object is tracked
reliably i.e. repeated use of the same object using the included virtual 
windows
and a custom interface device which returns the same visual-location 
feature
chunks modified appropriately on successive updates.


Hope that helps, and if you have any other questions let me know,
Dan