Control in Soar and Related Digressions

1
Control in Soar (and Related Digressions)
Presented at Integrated Models of Cognitive
Systems Workshop, 4 March 2005.

• Frank E. Ritter1,2,3
• Shuang Sun1, Ian Schenck2,3, Mark Cohen1,4
• Joshua B. Gross1 and William E. Stevenson1
• 1 IST, 2 Y, 3 CSE _at_ Penn State 4 Lock Haven
  University
• ritter_at_ist.psu.edu

• -- acs.ist.psu.edu/papers (passwd doc / user)
• This project was supported by the US Office of
  Navy Research, award number N000140110547. Isaac
  Councill created the first version of dTank.
  Geoff Morgan has helped maintain dTank and its
  manual.

2
Overview of Soar Architecture(Soar on a slide)

• Rules fire when matched, and in cycles
• Match is automatic
• They propose changes
• Operators chosen synchronously
• Input every 100 msnot active, no explicit
  Type2
• Output every 100 ms, no explicit Type2 (but
  see Chong)

acs.ist.psu.edu/soar-faq
3
Those Questions - Answers

• Soar Input -- no control
• Fixed interval
• Last for that interval
• Cognition copies it to keep it
• Central processor -- Well specified
• Soar Rules have no control
• Soar Rules (Decl and Proc mem.) -- fire when
  they match
• Soar PSCM - sequences operators and learnsThere
  are some interesting model control mechanisms
  (e.g., data-chunking)
• Soar Output parallel allowed, typically serial
  (but trouble with learning if you learn to do x
  y at the same conditions)

4
Those Questions - Comments

• Cognition can change sensors
• Tcl/Tk stub to do more (which we will do)
• Will want to compare a lot of tasks and
• Across architectures for a particular task
• So, I thought, what would someone smarter than me
  do?

5
dTank Microworld acs.ist.psu.edu/dTank ?
Morgan et al., submitted .

• For testing explanation ofdynamic, adversarial
  models
• Multiple players and teams onmultiple machines
• Improved 2004 task complexity, vision theory,
  speed, interface. Architecture use 6 (Soar,
  Herbal/Soar, Soar/Slip, CAST, Jess, Java)
  3(JACK, CoJACK , ACT-R)
• 2005 Replay, log analysis with CaDaDis,
  tournament server
• in Java, usable by UGs
• Used by Army MURI (?Sun et al., 2004), Lock
  Haven U. (www .lhup.edu/mcohen/
  dTank/dTankJess.htm), Fed. U. of Uberlandia
  (Brazil)

6
What dTank Provides

• Models and humans play together
• Near human performance possible
• Default knowledge set
• Models get displayed information
• Inputs (model/human)
• Agents in turret view / Agents in turret view
• Stones in turret view / Stones in turret view
• Self stats / ditto
• Health of opponent upon query / ditto
• Tank hit / Bullet path (ok, burr)
• Radio / none
• Outputs (model/human)
• Commands (5) onto link / Command onto key,mouse
• Command executed flag / Command executed flag?
• Commands all in (but for architecture) / all in

7
CAST (an agent arch. for teams)(Yen et al., 2001)
8
What CAST Does in dTank ? Sun et al., 2004

• Cognitive from decision-making, collaboration,
  teamwork, R-CAST looking at RPD
• CAST perception not well defined
• CAST output parallel, pass through
• Cognition sequential -- fixed cycle of percept,
  pick up operator, operator, output. Specified in
  a process. But lots of other mechanisms not
  found in ACT-R/Soar
• Checking for errors looks for anomalyfix
  construct for R-CAST at decision level and at
  process level B/c of adversaries and teammates
• Learning about checking for errors none

9
CAST vs. Soar in dTank? Sun et al., 2004 (IST
402 project)

• Fixed knowledge, fixed modeler
• N vs. N dTank games
• Soar better in small N
• CAST better in large N

10
What Java Does in dTank

• Perception inputs well designed, no control
• Cognition probably sequential
• Outputs sequential, constrained by task env.
• Checking for errors up to you

What CoJACK will do in dTank ? (Norling
Ritter, 2004, Ritter Norling, in press)

• Perception inputs well designed, no control
• Cognition basically sequential, but driven by
  percepts and goals
• Outputs sequential, constrained by task env.
• Checking for errors up to you

11
What Soar/Slip Does in dTank(IST 402 class
project!)

• Without checking for errors0-100 output
  (move-forward) slips
• Next stepChecking for errors
• Learning about checking for errors none
• Would make smart compilers very attractive,
  e.g., ? G2A or ? Herbal or ACT-R tutorial ch. 9

12
Comparing Architectures within a Single
Simulation Lessons

• A shared simulation supports comparison (AMBR!)
• Enforces some constraint on the architectures
  examined
• Multiple architectures inform each other
• Considering mechanisms useful
• Soar and CAST and JAVA and COJACK have simple
  control in Type 2 mechanisms
• Can see multiple levels in some mechanisms
• Encouraged us in this case to consider errors
• Errors would affect workload, checking
  particularly
• How would you correct errors in a model with
  knowledge?
• How does error correction affect control ? --
  Ties the architecture tighter together and spews
  implications all over the architectures
• Errors and control clearly affected by stress and
  emotion
• Could put slips into the world/simulation

13
Questions?References

• Gluck, K. A., Pew, R. W. (2001). Lessons
  learned and future directions for the AMBR model
  comparison project. In Proceedings of the 10th
  Computer Generated Forces and Behavioral
  Representation Conference. 10TH-CGF-067.
  113-121. Orlando, FL Division of Continuing
  Education, University of Central Florida.
  www.sisostds.org/cgf-br/10th/.
• Newell, A. (1992). Unified theories of cognition
  and the role of Soar. In J. A. Michon A.
  Akyurek (Eds.), Soar A cognitive architecture in
  perspective Dordrecht, NL Kluwer Academic
  Publishers.
• Norling, E., Ritter, F. E. (2004). A parameter
  set to support psychologically plausible
  variability in agent-based human modelling. In
  The Third International Joint Conference on
  Autonomous Agents and Multi Agent Systems
  (AAMAS04). 758-765. New York, NY ACM.
• Pew, R. W., Gluck, K. A. (Eds.). (in
  preparation). Modeling human behavior with
  integrated cognitive architectures Comparison,
  evaluation, and validation. Mahwah, NJ
  Lawrence Erlbaum.
• Ritter, F. E. (2003). Soar. In L. Nadel (Ed.),
  Encyclopedia of cognitive science (60-65).
  London Nature Publishing Group.
• Ritter, F. E., Norling, E. (in press).
  Extending a BDI architecture to make a better and
  more interesting team member The case of JACK to
  COJACK. In Cognition and multi-agent
  interaction From cognitive modeling to social
  simulation Cambridge, UK Cambridge University
  Press.
• Sun, S., Councill, I., Fan, X., Ritter, F. E.,
  Yen, J. (2004). Comparing teamwork modeling in an
  empirical approach. In Proceedings of the Sixth
  International Conference on Cognitive Modeling.
  388-389. Mahwah, NJ Lawrence Erlbaum.
• Tor, K., Haynes, S. R., Ritter, F. E., Cohen,
  M. A. (2004). Categorical data displays generated
  from three cognitive architectures illustrate
  their behavior. In Proceedings of the
  International Conference on Cognitive Modeling.
  302-307. Mahwah, NJ Lawrence Erlbaum.
• Yen, J., Yin, J., Ioerger, T. R., Miller, M. S.,
  Xu, D., Volz, R. A. (2001). CAST Collaborative
  agents for simulating teamwork. In Proceedings of
  the Seventeenth International Joint Conference on
  Artificial Intelligence (IJCAI-01). 1135-1142.
  Los Altos, CA Morgan Kaufmann.