You are here

The challenge of a general motor module

ACT-R proper is only aware of its hands, it's not a motor system, rather a manual motor system. I've never been too terribly pleased with this. Inevitably other motor systems will need to be modeled, and the current implementation leads us down the path of building a new module for every motor system. Personally, I'd rather see manual subsumed under a more general motor module, but this presents some interesting questions.

Do we continue to permit only a single motor preparation and execution at a time? Does this mean that when I'm walking down the corridor I can't turn my head? Wouldn't it make more sense if the motor system bottleneck were at the muscle level? But to do that, the module tests on the left hand side need to be more fine grained. For example:

(p walk-and-chew-bubble-gum

=goal> ...


muscle torso ;for walking

state free


muscle mouth ;for chewing

state free



isa walk


isa chew)

Here you see the motor lhs query is using an additional slot muscle that constrains the state/prep/proc/exec tests. Most motor commands are tied to specific muscles (such as walk, or chew). In the absence of the muscle slot, the queries just check the aggregate of all the commands (if muscle is preparing or executing). This would permit back-compatibility.

Note, I've also used motor not manual. I think I'm going to keep the module that I'm implementing as motor and just provide parse time translation of manual to motor so that modelers need not deal with them as a unified module until they want to start using it.

Of course, all of this is hypothetical right now. I am currently building the motor module, but it is particularly challenging. The goal is to make it maximally flexible and extensible without requiring much custom coding by individuals who want to provide support for other movements (beyond manual). Right now this is accomplished by a set of delegates. These control the mapping of action requests (+motor> isa walk) into specific motor commands, as well as customizable equations for the time durations of preparation, processing and execution.

Hopefully all of this work will be done in a day or two so that I can utilize it for the Player/Stage interface I'm working on for NRL.