Cognitive Computing Research Group (CCRG): the CCRG’s research revolves around the design and implementation of cognitive, sometimes "conscious," software agents, their computational applications, and their use in cognitive modeling.
As atividades desta aula complementam o conteúdo da Aula 12: Introdução ao LIDA. São duas as atividades: uam relacionada ao Tutorial Project I e outra ao Tutorial Project II (ambos fazem parte do Tutorial Exercises). Para o desenvolvimento das atividades utilizamos os projetos basicAgentExercises (para os exercícios básicos) e ALifeAgentExercises (para os exercícios avançados); seguimos as dicas dadas no apêndice do Tutorial Exercises. Também é necessário ter instalado o NetBeans.
Iniciamos as atividades do Tutorial Project I estudando um agente num ambiente, chamado "Button", em que são exibidos randomicamente um quadrado vermelho, um círculo azul ou nenhum dos dois objetos (um quadro branco). O agente reage pressionando um botão conforme o objeto percebido: pressiona o botão 1 se perceber o quadrado vermelho e pressiona o botão 2 se perceber o círculo azul. Obs.: os botões que aparecem na interface gráfica são meramente ilustrativos (não têm nenhuma função ativa). Os processos associados à percepção do agente, nesta atividade, são simples e não retratam todos os recursos do modelo cognitivo LIDA.
Para carregar o agente LIDA siga os seguintes passos (é necessário ter o Java JDK e o NetBeans instalados):
O objetivo desta atividade é explorar a implementação do agente, nesta etapa estudamos a estrutura do projeto basicAgentExercises, vide Figura 1: exibe a pasta "Pacotes de Códigos-Fonte" ("Source Packages").
Figura 1. Estrutura do projeto basicAgentExercises no NetBeans |
Cada um dos pacotes, Figura 1, contém as seguinte classes (Figura 2):
Figura 2. Classes dos pacotes de Códigos-Fonte |
myagent.Run
: executa a aplicaçãomyagent.modules.ButtonEnvironment
: implementação do ambiente "Button" myagent.modules.ButtonSensoryMemory
: implementação do SensoryMemory do agentemyagent.featuredetectors.ShapeDetector
: detector de formaNa estrutura de arquivos do projeto basicAgentExercises, Figura 3, encontramos na pasta "configs" os arquivos necessários para realizar algumas de nossas atividades.
Figura 3. Arquivos na pasta "configs". |
A seguir listamos brevemente alguns arquivos básicos, veja comentários sobre estes arquivos nas notas da Aula 12.
lidaConfig.properties
: arquivo que contém a configuração principal. É a base para as outras configuraçãoes necessárias na construção de aplicações envolvendo o agente.basicAgent.xml
: arquivo que declara o agente. Contém a definição da arquitetura do agente: módulos e processos que caracterizam o agente. factoryData.xml
: contém a definição dos elementos que podem ser obtidos em ElementFactory
: Node
, Link
, Strategy
e tipos de Task
. guiPanels.properties
: arquivo que configura o GuiPanels
usado pelo GUI do framework. Este arquivo permite adicionar, remover e/ou customizar os painéis. O conteúdo do lidaConfig.properties
está listado abaixo:
#########################################################################################
# Copyright (c) 2009, 2011 The University of Memphis. -- All rights reserved.
# This program and the accompanying materials are made available under the terms of the
# LIDA Software Framework Non-Commercial License v1.0 which accompanies this distribution,
# and is available at:
# http://ccrg.cs.memphis.edu/assets/papers/2010/LIDA-framework-non-commercial-v1.0.pdf
########################################################################################
#Agent properties
lida.agentdata=configs/basicAgent.xml
lida.elementfactory.data=configs/factoryData.xml
#Gui properties
lida.gui.panels=configs/guiPanels.properties
lida.gui.commands=configs/guiCommands.properties
lida.gui.enable=true
#Logging properties
lida.logging.configuration=configs/logging.properties
Como podemos ver, pela listagem acima, os nomes dos arquivos podem ser definidos no lidaConfig.properties
. O próprio lidaConfig.properties
, apesar de ser padrão, não necessariamente precisa ser mantido - desde que se indique o respectivo arquivo para a classe AgentStarter.java.
Esta atividade é baseada na execução do projeto basicAgentExercises, vide Figura 4, ativação da interface do ambiente Button..
Figura 4. Ambiente Button |
Utilizamos o ambiente Button para:
start/pause
, ticks
, step mode
e tick duration
.
A Figura 5 mostra o ambiente Button em execução. Para ampliar a figura, use o botão direito do mouse e escolhar "Ver Imagem".
Figura 5. Ambiente Button |
Com o botão "Start/Pause", podemos ativar e pausar a simulação. O quadro ButtonEnvironment exibe os objetos (quadrado vermelho, círculo azul ou branco). Conforme os objetos são mostrados, o agente pressiona um dos botões.
O botão "Step Mode" permite fixar a quantidade fixa de ticks por simulação. Por exemplo, se colocarmos 100 no campo ao lado do botão "Step Mode". Ao ativar a simulação usando o botão "Run ticks" o sistema executa 100 e pára. Esse processo se repete a cada execução via "Run ticks", com o "Step Mode" ativado.
Também é possível alterar a duração de um tick, basta utilizar o campo à direita de "Tick duration (ms):". Por exemplo, destive o "Step Mode", USE AS SETAS para alterar o valor do campo: aumente para 20, acione o "Start/Pause" e veja a velocidade de execução da simulação. Novamente, USE AS SETAS para alterar o valor para zero e acione o "Start/Pause".
O "Logging", parte inferior do painel, exibe diferentes tipos de informação (um tipo em cada coluna): a primeira exibe o número do log, a segunda o tick no momento em que o log foi gerado, a terceira o nível de severidade do log, a quarta o nome do log e, por último, a mensagem.
É possível escolher quais logs devem ser exibidos. Por exemplo, até esse momento os logs exibidos eram globais ("GLOBAL") - opção exibida ao lado do identificador "Logger". Use o mouse para selecionar a opção (seta à esquerda de "GLOBAL"): myagent.modules.ButtonEnvironment
- útima opção exibida na janela de escolhas. Em seguida, altere o nível do log, use o campo à direita do identificador “Level”: escolha a opção "FINEST". Ao executar a simulaçõa percebemso a mudança dos logs. Opções que aumentam o volume de logs diminuem a velocidade de execução da simulação.
A aba identificada por "Configuration Files", na mesma seção do "Logging" mostra quais arquivos de configuração estão sendo usados pela aplicação em execução. Neste caso é o arquivo lidaConfig.properties
(localizada na pasta configs).
Nesta atividade tratamos:
Para essas atividade retornamos ao Netbeans. Abra o arquivo, lidaConfig.properties
na pasta "config".
######################################################################################### # Copyright (c) 2009, 2011 The University of Memphis. -- All rights reserved. # This program and the accompanying materials are made available under the terms of the # LIDA Software Framework Non-Commercial License v1.0 which accompanies this distribution, # and is available at: # http://ccrg.cs.memphis.edu/assets/papers/2010/LIDA-framework-non-commercial-v1.0.pdf ######################################################################################## #Agent properties #lida.agentdata=configs/basicAgent.xml lida.agentdata=configs/basicAgent_ex2.xml . . .
Como mostra o trecho de código acima, configure o lida.agentdata
com o basicAgent_ex2.xml
. Após a alteração, salve o lidaConfig.properties
. Como feito anteriomente, compile e execute o projeto. Acione o botão "Start/Pause". Note que durante a execução da simulação o botão "Button 2" não é pressionado.
Podemos executar a simulação alterando a duração de um tick (utilizando as setas) A alteração de valores (um inteiro 1, 10, 20, etc) provoca uma variação no tempo de resposta do Button 1
. Ao executarmos a simulação, a PAM table
o que a percepção do agente captura. As alterações de valores de ativação mostrados na PAM table
ocorrem somente nos campos square
e red
, quando o quadrado vermelho aparece no ButtonEnvironment
. De fato, a percepção da ocorrência do quadrado vermelho eleva o valor de ativação para 1.0, decaindo para 0.0 nos outros casos. Note-se que não há alteração de nenhum outro valor de ativação (p.ex., referente ao blue
e circle
) em nenhum outro cenário. Ou seja, este agente não possui detector de características para blue
e circle
.
Durante a simulação, o painel PerceptualBuffer
exibe nós para as características square
e red
. Como vimos na Aula 12, os nós no buffer perceptual do workspace. Colocando o cursor do mouse sobre um nó no painel PerceptualBuffer
é possível ver o valor de ativação do nó. Para isso, altere a duração de um tick para 80 (ou mais). O valor de activação exibido pode não ser o mesmo mostrado na PAM table
. O motivo é que esses nós adicionados no buffer perceptual são instâncias de nós da PAM, não são os mesmos nós. Como vimos na Aula 12, esses novos nós têm sua própria relevância (activation) e mecanismos distintos para controle de sua excitação (via ExcitationTask
e ExciteStrategy
) e decaimento (via DecayStrategy
). Se houver muitos nós no PerceptualBuffer
é possível redimensionar o quadro-geral usando os controles do mouse.
Questão: 1.1: What module of the LIDA Model is the Perceptual Buffer in? Where do the nodes in this buffer come from? How do they differ from the nodes in other modules?
O buffer perceptual está no Workspace
(no framework, é implementado como um submódulo do Workspace - vide Aula 12). Como já mencionamos (vide comentário acima), os nós do buffer perceptual têm origem na PAM (carregadas de forma assíncrona) - veja também o comentário no apêndice.
A Figura 6 mostra o painel GlobalWorkspace
(para aumentar o tamanho da figura utilize o botão direito do mouse, escolha a opção "Ver Imagem"). Na metade superior, temos os campos das coalizões correntes (Coalitions
) e seus respectivos atributos. Na metade inferior, temos uma tabela que mostra a história recente das coalizões vencedoras e as informações relevantes (o evento mais recente está no topo).
Figura 6. O painel GlobalWorkspace |
Questão 1.2: Where do the coalitions int the Global Workspace come from? Where do they go? Think about how the answer to these questions depends on whether we are discussing the LIDA Model or a specific agent implemented using the Framework.
No modelo LIDA, apenas uma coalizão vence a disputa para o broadcast, propagando as informações para todos os módulos. Em relação ao framework LIDA, isto é, no caso de um agente baseado no framework LIDA, o broadcast irá atingir somente os módulos que tiverem implementados o BroadcastListener
e sendo devidamente registrados como listeners no módulo GlobalWorkspace
(veja o apêndice). Como vimos na Aula 12, a relação entre o módulo GlobalWorkspace e a interface BroadcastListener é um exemplo de uso do Observer Pattern. O modelo exige que a maioria dos módulos receba a transmissão consciente (conscious broadcast) do GlobalWorkspace. Desse modo, esses módulos devem implementar a interface BroadcastListener. Cada módulo receptor (consumer) deve registrar-se como o GlobalWorkspace usando o método addBroadcastListener. Quando o GlobalWorkspace precisar enviar um broadcast, ele chama o método receiveBroadcast (em BroadcastListener) para cada listener registrado.
Nesta tarefa adicionamos um painel que mosta o conteúdo do CurrentSituationalModel
(um submodulo do módulo Workspace). Encerre a aplicação e volte ao NetBeans. Procure na pasta config
o arquivo guiPanels.properties
. Abaixo destacamos parte do conteúdo do arquivo:
######################################################################################### # Copyright (c) 2009, 2011 The University of Memphis. All rights reserved. # This program and the accompanying materials are made available # under the terms of the LIDA Software Framework Non-Commercial License v1.0 # which accompanies this distribution, and is available at # http://ccrg.cs.memphis.edu/assets/papers/2010/LIDA-framework-non-commercial-v1.0.pdf ######################################################################################### # ____Tool Bar____ ToolBar=ToolBar,edu.memphis.ccrg.lida.framework.gui.panels.ControlToolBarPanel,TOOL,1,Y,0,20 # ____A Section____ environ =ButtonEnvironment,myagent.guipanels.ButtonEnvironmentPanel,A,1,Y # ____B Section____ . . . perceptualBufferGraph = Perceptual Buffer, edu.memphis.ccrg.lida.framework.gui.panels.NodeStructurePanel,B,3,Y,Workspace.PerceptualBuffer . . . # TASK 4 INSERT YOUR CODE HERE #name = panel title, class name, Position [A,B,C,FLOAT, TOOL], tab order, Refresh after load, parameters # ____C Section____ . . .
Os texto destacados em azul dizem como é a estrutura das declarações das variáveis. O texto que começa com "perceptualBufferGraph
" define como é o painel perceptualBufferGraph
. Para criar o painel CurrentSituationalModel
fazemos uma cópia da definição do perceptualBufferGraph
, alteramos o nome para csm (lado esquerdo do sinal de igualdade), o título é "CSM", a classe de criação do painel é a mesma, a posição também permanece inalterada, alteramos o tabOrder para 7 e o parâmetro que utilizamos para chamar o rmodelo situacional corrente é Workspace.CurrentSituationalModel:
# TASK 4 INSERT YOUR CODE HERE csm = CSM,edu.memphis.ccrg.lida.framework.gui.panels.NodeStructurePanel,B,3,7, Workspace.CurrentSituationalModel
Salve o arquivo e execute a aplicação. A Figura 7 mostra a nova aba CSM na sétima posição.
Figura 7. Painel com nova aba CSM |
O comportamento do novo painel é similar ao do buffer perceptual.
Questão 1.3: How are the contents of the Current Situational Model related to the contents of the Perceptual Buffer? To the contents of PAM? Think about how the answer to these questions depends on whether we are discussing the LIDA Model, or a specific agent implemented in the Framework.
Tratamos da primeira questão na Aula 12. A estrutura interna do workspace é composta por vários buffers (associados à PAM) de entrada e três módulos: o Current Situational Model, o Scratchpad e o Conscious Contents Queue (Ref.: [ aqui ]). O Current Situational Model é o local de armazenamento das estruturas que representam os eventos correntes interno e externo. Os structure-building codelets são responsávei pela criação dessas estruturas usando elementos de vários sub-módulos do workspace
. O Scratchpad é uma área auxiliar (localizada no workspace) onde os structure-building codelets podem construir previamente possíveis estruturas para depois movê-los para o Current Situational Model. O Conscious Contents Queue mantém o conteúdo dos últimos broadcasts e permite o "entendimento" e manipulação de conceitos. (Ref.: [ aqui ]).
Nessas condições, o conteúdo do CSM depende das características do ambiente e do agente (de como ele percebe o mundo). Isto é, depende das especificações declaradas nos arquivos de configuração. No caso da espeficicação do basicAgent não há nenhum módulo na memória declarativa e todo conteúdo da CSM vem do buffer perceptual via PAM (veja resposta no apêndice).
Neste exercício modificamos o arquivo de declaração do agente para melhorar suas funcionalidades. Sempre que for feita uma alteração no arquivo de declaração do agente a aplicação deve ser reinicializada para que as alterações tenham efeito. As atividades são:
Para essas atividades alteramos o arquivo lidaConfig.properties
na pasta "config" para (veja o destaque em laranja):
######################################################################################### # Copyright (c) 2009, 2011 The University of Memphis. -- All rights reserved. # This program and the accompanying materials are made available under the terms of the # LIDA Software Framework Non-Commercial License v1.0 which accompanies this distribution, # and is available at: # http://ccrg.cs.memphis.edu/assets/papers/2010/LIDA-framework-non-commercial-v1.0.pdf ######################################################################################## #Agent properties #lida.agentdata=configs/basicAgent.xml lida.agentdata=configs/basicAgent_ex3.xml . . .
Como mostra o trecho de código acima, configure o lida.agentdata
com o basicAgent_ex3.xml
. Após a alteração, salvamos o lidaConfig.properties
. Neste momento o projeto NÃO deve ser executado. A Figura 8 mostra o diagrama parcial da arquitetura ButtonAgent
. As demarcações em linhas tracejadas serão preenchidas neste exercício.
Figura 8. Diagrama parcial da arquitetura ButtonAgent . |
Novamente, no Netbeans (no modo de visualização de arquivos), acessamos a pasta configs
do projeto e encontramos o arquivo basicAgent_ex3.xml
.Este arquivo contém a especificação de um agente similar à atividade anterior (sem um módulo e um listener). O objetivos dessa e das atividades seguintes é ampliar as funcionalidades deste agente (adicionar as parte faltantes e novos elementos, como, um detector de características e um codelet de atenção).
Dica: para facilitar a navegação através dos arquivos XML utilizamos o Netbeans (veja a Figura 9).
Figura 9. Visualização de arquivos XML no Netbeans |
Na Figura 9, parte inferior da janela do Netbeans, é possível ver a estrutura do arquivo XML. Utizamos a estrutura de tags para navegar pelo arquivo basicAgent_ex3.xml
, vide esquema na Figura 10.
Figura 10. Estrutura de tags do arquivo basicAgent.xml no Netbeans |
Nesta tarefa adicionamos o módulo declaration1
na parte dos submódulos, veja esquema na Figura 11.
Figura 11. Estrutura dos submódulos na especificação do basicAgent.xml . |
A inclusão do módulo declaration1
no arquivo basicAgent_ex3.xml
é indicado por um comentário (vide esquema na Figura 12), logoa abaixo da tag <submodules>
(TASK 2
):
Figura 12. Estrutura dos módulos na especificação do basicAgent_ex3.xml . |
Para a escrita do módulo seguimos a sintaxe do módulo ActionSelection
(vide código abaixo):
<module name="ActionSelection">
<class>edu.memphis.ccrg.lida.actionselection.BasicActionSelection</class>
<param name="actionSelection.ticksPerStep" type="int"> 10</param>
<taskspawner>defaultTS</taskspawner>
</module>
A declaração fica entre o par de tags <module>
e </module>
, com os seguinte rótulos:
name: Environment
class: myagent.modules.ButtonEnvironment
E com parâmetros para: nome, tipo (int
, boolean
, string
, double
) e valor dentro da tag. Caso não haja nenhuma especificação, o formato default do parâmetro é:
Param1: name=”height” type=”int”, valor da tag 10
Param2: name=”width” type=”int”, valor da tag 10
Para a tag taskspawner
o padrão é defaultTS
. Desse modo, temos o seguinte código:
<module name="Environment
"> <class>edu.memphis.ccrg.lida.myagent.modules.ButtonEnvironment
</class> <param name="height" type="int"> 10</param> <param name="width" type="int"> 10</param> <taskspawner>defaultTS</taskspawner> </module>
Salvamos o arquivo e validamos a alteração, para validar basta colocar o cursor do mouse sobre o código e usar o botão direito para obter as opções. A validação trata somente da parte sintática, logo não verifica a validade dos nomes ou dos valores dos parâmetros.
Após a execução, verificamos que somente os nós red
e square
estão ativos. De fato, os detectores para blue
e circle
ainda não foram adicionados à PAM. A conexão entre a PAM e o Workspace
(veja a seta "Move Percept" no Modelo LIDA - Figura 3 da Aula 12) não está definida, logo não há comunicação com o PerceptualBuffer
. Isto é, o agente percebe red
e square
, porém estes nós não entram no Workspace
. Para estabelece a conexão é necessário adicionar um PamListener
na declaração do agente (próxima tarefa).
OBS.: a implementação em Java dos detectores estão no pacote myagent.featuredetectors
.
Como na tarefa anterior, faremos uma alteração no arquivo XML, dessa vez na tag <listeners>
: listenertype (edu.memphis.ccrg.lida.pam.PamListener
), modulename (PerceptualAssociativeMemory)
, listenername (Workspace
). Veja o código:
<listener> <listenertype>edu.memphis.ccrg.lida.pam.PamListener</listenertype> <modulename>GlobalWorkspace</modulename> <listenername>ProceduralMemory</listenername> </listener>
Novamente, salvamos e executamos a aplicação. Dessa vez, o PerceptualBuffer
exibe os nós red
e square
quando o agente percebe um quadrado vermelho (red square) no ambiente. Como ainda não adicionamos detectore para blue
e circle
na PAM, nada ocorre no PerceptualBuffer
quando um círculo azul aparece no ambiente (próxima tarefa).
Faremos uma alteração no módulo PerceptualAssociativeMemory
(veja trecho de código abaixo):
<module name="PerceptualAssociativeMemory">
<class>edu.memphis.ccrg.lida.pam.PerceptualAssociativeMemoryImpl</class>
<param name="pam.Upscale" type="double">.7 </param>
<param name="pam.Downscale" type="double">.6 </param>
<param name="pam.Selectivity" type="double">.5 </param>
<param name="nodes">red,blue,square,circle</param>
<taskspawner>defaultTS</taskspawner>
<initialTasks>
<task name="RedDetector">
<tasktype>ColorDetector</tasktype>
<ticksperrun>3</ticksperrun>
<param name="color" type="int">-65536</param>
<param name="node" type="string">red</param>
</task>
<!-- INSERT YOUR CODE HERE ************************* -->
<task name="blueDetector">
<tasktype>ColorDetector</tasktype>
<ticksperrun>3</ticksperrun>
<param name="color" type="int">-16776961</param>
<param name="node" type="string">blue</param>
</task>
<!-- *********************************************** -->
<task name="SquareDetector">
<tasktype>ShapeDetector</tasktype>
<ticksperrun>3</ticksperrun>
<param name="area" type="int">40</param>
<param name="backgroundColor" type="int">-1</param>
<param name="node" type="string">square</param>
</task>
<!-- INSERT YOUR CODE HERE ************************* -->
<task name="circleDetector">
<tasktype>ShapeDetector</tasktype>
<ticksperrun>3</ticksperrun>
<param name="area" type="int">31</param>
<param name="backgroundColor" type="int">-1</param>
<param name="node" type="string">circle</param>
</task>
<!-- *********************************************** -->
</initialTasks>
<initializerclass>edu.memphis.ccrg.lida.pam.BasicPamInitializer</initializerclass>
</module>
Seguindo o roteiro, a execução da aplicação mostra a ocorrência dos nós blue
e circle
no painel PerceptualBuffer
. Porém, o agente ainda não responde (pressiona Button 2
) às ocorrências dos círbilos azuis. Para que isso ocorra é necessário adicionar um codelet de atenção (para estabelecer uma coalizão) no GlobalWorkspace
(próxima tarefa).
Para a adição de um codelet de atenção alteramos o AttentionModule
: adicionamos entre as tags <initialtasks>
uma declaração similar ao RedSquareCodelet
(veja esquema abaixo):
<module name="AttentionModule"> <class>edu.memphis.ccrg.lida.attentioncodelets.AttentionCodeletModule</class> <associatedmodule>Workspace</associatedmodule> <associatedmodule>GlobalWorkspace</associatedmodule> <taskspawner>defaultTS</taskspawner> <initialTasks> <task name="RedSquareCodelet"> <tasktype>BasicAttentionCodelet</tasktype> <ticksperrun>5</ticksperrun> <param name="nodes" type="string">red,square</param> <param name="refractoryPeriod" type="int">30</param> <param name="initialActivation" type="double">1.0</param> </task> <!-- TASK 6: INSERT YOUR CODE HERE ************************* --> <task name="blueCircleCodelet"> <tasktype>BasicAttentionCodelet</tasktype> <ticksperrun>5</ticksperrun> <param name="nodes" type="string">blue,circle</param> <param name="refractoryPeriod" type="int">30</param> <param name="initialActivation" type="double">1.0</param> </task> <!-- ******************************************************* --> </initialTasks> </module>
Dessa vez o agente responde aos estímulos, pressiona Button 2
. em resposta a círculos azuis.
O framework LIDA independe da estrutura da GUI, para utilizar o framework sem a GUI é preciso alterar a propriedade lida.gui.enable
(para false
), no arquivo lidaConfig.properties
. Para tratar os logs o framework LIDA utiliza o mecanismo padrão do Java (java.util.logging). O framework usa o arquivo logging.properties
definido no arquivo lidaConfig.properties
. O exemplo abaixo está na pasta configs
(arquivo logging.properties
):
############################################################################### # Copyright (c) 2009, 2011 The University of Memphis. All rights reserved. # ... ############################################################################### #------------------------------------------------------------------------------ # Global properties #------------------------------------------------------------------------------ # #------------------------------------------------------------------------------ # "handlers" specifies a comma separated list of log Handler # classes. These handlers will be installed during VM startup. # Note that these classes must be on the system classpath. # By default we only configure a ConsoleHandler, which will only # show messages at the INFO and above levels. handlers= java.util.logging.ConsoleHandler #------------------------------------------------------------------------------ # To also add the FileHandler, use the following line instead. #handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler #------------------------------------------------------------------------------ # Default global logging level. # This specifies which kinds of events are logged across # all loggers. For any given facility this global level # can be overriden by a facility specific level # Note that the ConsoleHandler also has a separate level # setting to limit messages printed to the console. .level= INFO #------------------------------------------------------------------------------ # Handler specific properties. # Describes specific configuration info for Handlers. #------------------------------------------------------------------------------ #------------------------------------------------------------------------------ # default file output is in user's home directory. java.util.logging.FileHandler.pattern = %h/lida%u.log java.util.logging.FileHandler.limit = 50000 java.util.logging.FileHandler.count = 1 java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter #------------------------------------------------------------------------------ # Limit the message that are printed on the console to INFO and above. java.util.logging.ConsoleHandler.level = ALL java.util.logging.FileHandler.level = INFO java.util.logging.ConsoleHandler.formatter = edu.memphis.ccrg.lida.framework.initialization.FrameworkFormatter #------------------------------------------------------------------------------ # Facility specific properties. # Provides extra control for each logger. #------------------------------------------------------------------------------ # # For example, set the com.xyz.foo logger to only log SEVERE # messages: edu.memphis.ccrg.lida.level = INFO
Neste exercício examinamos os efeitos resultantes do ajuste fino do parâmetro ticksPerRun
(esse parâmetro já aparece na codificação das tarefas 4, 5, e 6). Para perceber esses efeitos, iniciamos a execução de uma aplicação com tickDuration
ajustado em dez (ajuste feito antes de iniciar a simulação). As coalizões (parte superior do painel) no Global Workspace
aparecem quando o quadrado vermelho ocorre no ambiente. Testamos diversas configurações sugeridas:
lidaConfig.properties
para executar com o basicAgent.xml
.alteração do RedSquareCodelet
no módulo de Attention (em <initialtasks>
)
Alterar ticksPerRun
para 50 e refractoryPeriod
para 300
tickDuration
para 10. Ocorrem poucas coalizões no Global workspace quando o quadrado vermelho aparece no ambiente.
Neste exercício fazemos com que o agente reconheça o ambiente vazio. A reação do agente para o ambiente vazio é deixar os dois botões liberados. Para efetivar tal comportamento, criamos um detector de feature (para o ambiente vazio), um codelet de atenção e um esquema (ação de liberar os botões):
o detector de feature está associado à tela em branco, a idéia para o detector segue do ShapeFeatureDetector
. O detector é adicionado como <tasks>
no factoryData.xml
.
<task name="EmptyEnvironmentDetector"> <class>myagent.featuredetectors.ShapeFeatureDetector</class> <ticksperrun>5</ticksperrun> <associatedmodule>SensoryMemory</associatedmodule> <associatedmodule>PerceptualAssociativeMemory</associatedmodule> <param name="area" type="int">40</param> <param name="backgroundColor" type="int">-1</param> <param name="node" type="string">empty</param> </task>
Em seguida, incluímos um nó associado ao ambiente vazio na PerceptualAssociativeMemory
.
<module name="PerceptualAssociativeMemory"> <class>edu.memphis.ccrg.lida.pam.PerceptualAssociativeMemoryImpl</class> <param name="pam.Upscale" type="double">.7 </param> <param name="pam.Downscale" type="double">.6 </param> <param name="pam.Selectivity" type="double">.5 </param> <!-- Advanced Exercise 3: inclusão de um no para o ambiente vazio --> <param name="nodes">red,blue,square,circle,empty</param> <taskspawner>defaultTS</taskspawner> . . .
O codelet de atenção deve ser associado à task com um parâmetro para o nó vazio.
<module name="AttentionModule"> . . . <task name="EmptyCodelet"> <tasktype>BasicAttentionCodelet</tasktype> <ticksperrun>5</ticksperrun> <param name="nodes" type="string">empty,empty</param> <param name="refractoryPeriod" type="int">30</param> <param name="initialActivation" type="double">1.0</param> </task> </initialTasks> </module>
A ação do agente é montada na ProceduralMemory
e segue o formato dos outros já existentes. A ação é o action.releasePress
. Ativamos o parâmetro smm.3
no módulo SensoryMotorMemory
.
<module name="ProceduralMemory">
<class>edu.memphis.ccrg.lida.proceduralmemory.ProceduralMemoryImpl</class>
<param name="proceduralMemory.ticksPerStep" type="int"> 14 </param>
<param name="scheme.1">if red square, press 1|(red,square)()|action.pressOne|()()|0.01</param>
<param name="scheme.2">if blue circle, press 2|(blue,circle)()|action.pressTwo|()()|0.01</param>
<param name="scheme.3">if empty, |(empty,empty)()|action.releasePress|()()|0.01</param>
. . .
</module>
. . .
<module name="SensoryMotorMemory">
<class>edu.memphis.ccrg.lida.sensorymotormemory.BasicSensoryMotorMemory</class>
<associatedmodule>Environment</associatedmodule>
<param name="smm.1">action.pressOne,algorithm.press1</param>
<param name="smm.2">action.pressTwo,algorithm.press2</param>
<param name="smm.3">action.releasePress,algorithm.releasePress</param>
. . .
</module>
Com essas modificações, o agente também reage (via releasePress
) ao ambiente vazio. A Figura 13 mostra o experimento, os destaquesw em vermelho apontam para os objetivos pretendidos nesta atividade.
Figura 13. Reconhecendo "ambiente vazio" |
Nas atividades desta seção vimos algumas funcionalidades da GUI do framework LIDA (alterando parte do código do projeto basicAgentExercises
). Modificamos a barra de tarefas, incluímos algumas funcionalidades e painéis que exibem o estado interno do agente. Exploramos o arquivo XML e vimos como adicionar um módulo, um listener, detectores de feature e codelets de atenção.
Para este bloco de atividades seguimos o Tutorial Project II. Assim como no TankSoar, a ação ocorre numa arena discreta, o ambiente é representado por uma grade dez por dez. Cada célula pode conter zero ou mais objetos . Na implementação do ALifeAgentExercises
temos os seguinte elementos: um agente, macacos maus, árvores, rochas e hambúgueres. Os macamos movem-se randomicamente na tentativa de capturar o agente, a captura ocorre quando macaco e agente ocupam uma mesma célula. Uma rocha ocupa uma célula interia, logo nenhum outro elemento pode ocupar uma célula que contenha uma rocha. O sensor do agente capta objetos da célula em que está situado e objetos da célula imediatamente a sua frente (visão frontal limitada). Além disso, o agente pode sentir o seu estado de saúde: o nível de saúde do agente decai a cada tick
, também há um decréscimo na saúde quando o agente é atacado por um macaco, quando tenta ocupar células que contenham rocha ou quando tenta mover-se para fora da arena). As açõe do agente se restringem a movimentos (para frente, esquera ou direita) restritos à célula adjacente (à célula do agente), de rotação, de fuga (rotacionar e mover para frente) e de alimentação. Comer um hambúrguer aumenta o nível de saúde do agente. A Tabela 1, mostra um resumo do cénario da Terra do Hambúguer, a Figura 14 exibe os personagens que atuam nesse cenário.
Environment Attributes
| Agente, macacos maus, árvores, rochas e hambúrgueres. Há uma grade 10x10 tal que cada célula da grade contém zero ou mais objetos. Macacos movem-se randomicamente e não podem ocupar células que contenham rochas ou árvores. O agente não pode ocupar células contendo rochas |
Sensing | Objetos correntes e os que estão na célula ao alcance da visão, saúde |
Actions | Movimento para frente, esquerda, direita, rotação, alimentar-se e fugir |
Agent Health | + come hambúrguer - atacado por um macaco, movimento para uma céclula contendo rochas, movimento para fora dos limites, tempo |
Tabela 1. Projeto II - Agente e ambiente |
| |
Figura 14. Elementos do ambiente |
Neste exercício exploramos o ALifeAgent. O carregamento do AlifeAgentExercises
é análogo ao do basicAgentExercises
. A manipulação do AlifeAgentExercises
no Netbeans segue o mesmo roteiro do basicAgentExercises
. A Figura 15 mostra o projeto em execução (para ampliar a figura: coloque o cursosr do mouse sobre a figura e com o botão direito escolha a opção "Ver Imagem"):
Figura 15. GUI do Alife Agent. |
A Figura 15 mostra a GUI contendo vários painéis: uma exibindo a arena com os personagens (lado esquerdo da figura), outra com os esquemas de ação que podem ocorrer nesse cenário (lado direito da figura: ProceduralMemory
) e, na parte inferior da figura, o Logging
.
Tarefa 1
Na Figura 15, no painel que contém a arena, usamos a seta vermelha para indicar que o cursor do mouse foi acionado sobre a célula que contém o macaco, em reposta o conteúdo da célula é exibido num painel à diretia do painel da arena (veja os destaques em vemelho). O painel abaixo exibe os atributos (id
, size
, name
, health
e container
) e os respectivos valores (no caso: 5
, predator
, 30
cell[3,0]
).
Cada aba (PAM Table
, PAM Graph
, etc) exibe um painle contendo informações pertinentes ao título da aba. No caso da Figura 15, o painel à direita exibe o Procedural Memory
que contém os esquemas de atuação dos personagens.
Questão: 2.1: Compare the GUI of the alifeAgent to that of the basicAgent. What are the differences, and why are they different?
Para verificar as diferenças técnicas basta olhar o arquivo guiPanels.properties
. Além do ambiente (A Section
das duas simulações) a dinâmica (B Section
: activationChart
) dos dois experimentos são distintos.
GUI do basicAgent # ____Tool Bar____ ToolBar = ToolBar,edu.memphis.ccrg.lida.framework.gui.panels.ControlToolBarPanel,TOOL,1,Y,0,20 # ____A Section____ environ = ButtonEnvironment,myagent.guipanels.ButtonEnvironmentPanel,A,1,Y # ____B Section____ pamTable = PAM Table,edu.memphis.ccrg.lida.framework.gui.panels.NodeStructureTable,B,0,Y,PerceptualAssociativeMemory pamGraph = PAM Graph,edu.memphis.ccrg.lida.framework.gui.panels.NodeStructurePanel,B,1,Y,PerceptualAssociativeMemory activationChart = Activation Chart,edu.memphis.ccrg.lida.framework.gui.panels.ActivationChartPanel,B,2,Y,100,red perceptualBufferGraph = Perceptual Buffer,edu.memphis.ccrg.lida.framework.gui.panels.NodeStructurePanel,B,3,Y,Workspace.PerceptualBuffer globalWorkspace = Global Workspace,edu.memphis.ccrg.lida.framework.gui.panels.GlobalWorkspaceTablePanel,B,4,Y,10 proceduralMemory = Procedural Memory,edu.memphis.ccrg.lida.framework.gui.panels.ProceduralMemoryPanel,B,5,Y actionSelection = Action Selection,edu.memphis.ccrg.lida.framework.gui.panels.ActionSelectionPanel,B,6,Y,5 # ____C Section____ LogPanel = Logging,edu.memphis.ccrg.lida.framework.gui.panels.LoggingPanel,C,1,N, myagent runningTasks = Running Tasks,edu.memphis.ccrg.lida.framework.gui.panels.FrameworkTaskPanel,C,2,Y, PerceptualAssociativeMemory taskQueue = Task Queue,edu.memphis.ccrg.lida.framework.gui.panels.TaskQueuePanel,C,3,N configFiles = Configuration Files,edu.memphis.ccrg.lida.framework.gui.panels.ConfigurationFilesPanel,C,4,N
GUI do AlifeAgent # ____Tool Bar____ ToolBar = ToolBar,edu.memphis.ccrg.lida.framework.gui.panels.ControlToolBarPanel,TOOL,1,Y,1,20 # ____A Section____ environ = AlifeEnvironment,alifeagent.guipanels.ALifeGuiPanel,A,1,Y,configs/icons.properties,40 # ____B Section____ pamTable = PAM Table,edu.memphis.ccrg.lida.framework.gui.panels.NodeStructureTable,B,0,Y,PerceptualAssociativeMemory pamGraph = PAM Graph,edu.memphis.ccrg.lida.framework.gui.panels.NodeStructurePanel,B,1,Y,PerceptualAssociativeMemory activationChart = Activation Chart,edu.memphis.ccrg.lida.framework.gui.panels.ActivationChartPanel,B,2,Y,100,goodHealth perceptualBufferGraph = Perceptual Buffer,edu.memphis.ccrg.lida.framework.gui.panels.NodeStructurePanel,B,3,Y,Workspace.PerceptualBuffer globalWorkspace = Global Workspace,edu.memphis.ccrg.lida.framework.gui.panels.GlobalWorkspaceTablePanel,B,4,Y,10 proceduralMemory=Procedural Memory,edu.memphis.ccrg.lida.framework.gui.panels.ProceduralMemoryPanel,B,5,Y actionSelection = Action Selection,edu.memphis.ccrg.lida.framework.gui.panels.ActionSelectionPanel,B,6,Y,5 # ____C Section____ LogPanel = Logging,edu.memphis.ccrg.lida.framework.gui.panels.LoggingPanel,C,1,N, alifeagent, edu.memphis.ccrg.alife runningTasks = Running Tasks,edu.memphis.ccrg.lida.framework.gui.panels.FrameworkTaskPanel,C,2,Y, PerceptualAssociativeMemory taskQueue = Task Queue,edu.memphis.ccrg.lida.framework.gui.panels.TaskQueuePanel,C,3,N configFiles = Configuration Files,edu.memphis.ccrg.lida.framework.gui.panels.ConfigurationFilesPanel,C,4,N
Tarefa 2
A Figura 16 mostra o ambiente após alguns ticks de execução, o painel à direita mostra o PAM Graph
.
Figura 16. GUI do Alife Agent com o PAM Graph. Destaques para o nó food no PAM Graph. |
Após alguns ticks de execução percebe-se que a saúde do agente tem baixo decaimento e que um ataque do macaco afeta muito a saúde do agente, porém um único hambúrguer é capaz de recuperar o nível de saúde a níveis elevados. A Figura 16 mostra o agente em ação, o agente tem um decaimento da saúde em função dos movimentos e de um ataque sofrido, porém o nível de saúde do agente volta a carga máxima após comer um único hambúrguer.
Tarefa 3
A Figura 17 a fila de tarefas (TaskQueue
), as tarefas em execução (Running Tasks
) e o estado do Global Workspace
.
Figura 17. Fila de tarefas, tarefas em execução e o estado do Global Workspace . |
Os paineis mostrados na Figura 17 nos dão uma perspectiva do comportamento futuro do agente. Podemos avaliar esse comportamento olhando a estrutura das coalizões e os broadcasts juntamente com a lista das tarefas e as tarefas em execução.
Neste exercício criamos um detector de feature e o adicionamos ao factoryData.xml
, adicionamos uma task ao arquivo de declaração do agente e modificamos outra. Iniciamos alterando o perfil do agente para alifeAgent_ex2.xml
, modificamos o arquivo lidaConfig.properties
ma pasta configs
.
LidaConfig.properties #Agent properties #lida.agentdata=configs/alifeAgent.xml lida.agentdata=configs/alifeAgent_ex2.xml lida.elementfactory.data=configs/factoryData.xml #Gui properties lida.gui.panels=configs/guiPanels.properties lida.gui.commands=configs/guiCommands.properties lida.gui.enable=true #Logging properties lida.logging.configuration=configs/logging.properties
Também alteramos o arquivo objects.properties
.
objects.properties #name=QTY,x,y,iconId,size,health,className,[attributes]* #food=10,-1,-1,8,10,1.0,edu.memphis.ccrg.alife.elements.ALifeObjectImpl food=0,-1,-1,8,10,1.0,edu.memphis.ccrg.alife.elements.ALifeObjectImpl # Não há hambúrgueres no ambiente rock=5,-1,-1,1,100,0.9,edu.memphis.ccrg.alife.elements.ALifeObjectImpl,color(string:brown),density(double:2.5) tree=5,-1,-1,2,75,0.9,edu.memphis.ccrg.alife.elements.ALifeObjectImpl agent=1,-1,-1,3,5,1.0,alifeagent.environment.elements.AgentObject,direction(char:S) predator=2,-1,-1,7,30,1.0,alifeagent.environment.elements.PredatorObject
Tarefa 0
Durante a execução da simulação o agente perde a mobilidade conforme o decaimento da saúde. Como não há hambúrgueres para repor o nível de saúde do agente, ele ficam sem ter energia para se locomover.
Tarefa 1
Nesta tarefa criamos uma nova classe Java chamada BadHealthDetector
. A classe é criada dentro do pacote alifeagent.featuredetectors
. A classe BadHealthDetector
estende o BasicDetectionAlgorithm.java
. para detectar baixo nível de saúde (abaixo de 0.33). De fato, o código é similar ao do GoodHealthDetector.java
(veja código abaixo):
/*******************************************************************************/ package alifeagent.featuredetectors; import java.util.HashMap; import java.util.Map; import edu.memphis.ccrg.lida.pam.tasks.BasicDetectionAlgorithm; public class GoodHealthDetector extends BasicDetectionAlgorithm { private final String modality = ""; private Map<String, Object> detectorParams = new HashMap<String, Object>(); @Override public void init() { super.init(); detectorParams.put("mode", "health"); } @Override public double detect() { double healthValue = (Double) sensoryMemory.getSensoryContent(modality, detectorParams); double activation = 0.0; if (healthValue >= 0.66) { /* Valor padrão para GoodHealth*/ activation = 1.0; } return activation; } }
Seguindo o esquema acima implementamos o BadHealthDetector
.
/*******************************************************************************/ package alifeagent.featuredetectors; import java.util.HashMap; import java.util.Map; import edu.memphis.ccrg.lida.pam.tasks.BasicDetectionAlgorithm; public class BadHealthDetector extends BasicDetectionAlgorithm { private final String modality = ""; private Map<String, Object> detectorParams = new HashMap<String, Object>(); @Override public void init() { super.init(); detectorParams.put("mode", "health"); } @Override public double detect() { double healthValue = (Double) sensoryMemory.getSensoryContent(modality, detectorParams); double activation = 0.0; if (healthValue <= 0.66) { /* Valor padrão para BadHealth*/ activation = 1.0; } return activation; } }
Tarefa 2
Incluímos o BadHealthDetector
na forma de task no arquivo factoryData.xml
.
. . . <task name="FairHealthDetector"> <class>alifeagent.featuredetectors.FairHealthDetector</class> <ticksperrun>3</ticksperrun> <associatedmodule>SensoryMemory</associatedmodule> <associatedmodule>PerceptualAssociativeMemory</associatedmodule> </task> <task name="BadHealthDetector"> <class>alifeagent.featuredetectors.BaddHealthDetector</class> <ticksperrun>3</ticksperrun> <associatedmodule>SensoryMemory</associatedmodule> <associatedmodule>PerceptualAssociativeMemory</associatedmodule> </task> . . .
Após a modificação validamos o arquivo XML (use o botão direito do mouse pra fazer a escolha de validação).
Tarefa 3
Adicionamos uma task no módulo PerceptualAssociativeMemory
(veja o arquivo alifeAgent_ex2.xml
).
. . . <module name="PerceptualAssociativeMemory"> <class>edu.memphis.ccrg.lida.pam.PerceptualAssociativeMemoryImpl</class> <param name="pam.Upscale" type="double">.7 </param> <param name="pam.Downscale" type="double">.6 </param> <param name="pam.Selectivity" type="double">.5 </param> <param name="nodes"> goodHealth,fairHealth,badHealth,health,front,origin,outOfBounds,predator,rock,tree,food, predatorOrigin,rockOrigin,treeOrigin,foodOrigin,predatorFront,rockFront,treeFront, foodFront,emptyFront </param> <param name="links"> goodHealth:health,fairHealth:health,badHealth:health,rockFront:rock,rockOrigin:rock, predatorFront:predator,predatorOrigin:predator,foodFront:food,foodOrigin:food, treeFront:tree,treeOrigin:tree,rockFront:front,predatorFront:front, foodFront:front,treeFront:front,rockOrigin:origin,predatorOrigin:origin, foodOrigin:origin,treeOrigin:origin </param> <taskspawner>defaultTS</taskspawner> <initialTasks> <task name="GoodHealthDetector"> <tasktype>GoodHealthDetector</tasktype> <ticksperrun>3</ticksperrun> <param name="node" type="string">goodHealth</param> </task> <task name="FairHealthDetector"> <tasktype>FairHealthDetector</tasktype> <ticksperrun>3</ticksperrun> <param name="node" type="string">fairHealth</param> </task> <!-- TASK 3 INSERT YOUR CODE HERE ************************* --> <task name="BadHealthDetector"> <tasktype>BadHealthDetector</tasktype> <ticksperrun>3</ticksperrun> <param name="node" type="string">badHealth</param> </task> <!-- ****************************************************** --> . . .
Tarefa 4
Adicionamos no alifeAgent_ex2.xml
um predatorFrontDetector
, também no módulo PerceptualAssociativeMemory
.
. . . <task name="predatorOriginDetector"> <tasktype>ObjectDetector</tasktype> <ticksperrun>3</ticksperrun> <param name="node" type="string">predatorOrigin</param> <param name="object" type="string">predator</param> <param name="position" type="int">0</param> </task> <!-- TASK 4 INSERT YOUR CODE HERE ************************* --> <task name="predatorFrontDetector"> <tasktype>ObjectDetector</tasktype> <ticksperrun>3</ticksperrun> <param name="node" type="string">predatorFont</param> <param name="object" type="string">predator</param> <param name="position" type="int">1</param> <!-- 1 = frente--> </task> <!-- ****************************************************** --> . . .
Note que o tipo da task é o mesmo do predatorOriginDetector
, logo e respectiva classe Java já existe. Evidentemente, a inclusão desses dois detctores (BadHealthDetector
e predatorFrontDetector
) deve modificar o comportamento do agente (agora o agente foge quando percebe o macamo na célula frontal, o que não acontecia antes).
Questão 2.2: Why does the agent's behavior change in this way after the new featuredetectors were added?
Os esquemas já existentes na Procedural Memory
(em resposta às condições de saúde e a presença de predadores), não eram ativados porque o agente não estava equipado com mecanismos para disparar tais esquemas. Com a inclusão dos detectores o agente torna-se capaz de agir de acordo.
Neste exercício exploramos os codelets de atenção (criação, modificação, estudo dos comportamento através da alteração dos parâmetrosmos dos codelets).
Novamente, alteramos o arquivo lidaConfig.properties
: configuramos o lida.agentdata
como segue:
lida.agentdata=configs/alifeAgent_ex3.xml
A quantidade de hambúrgueres disponibilizada na arena também é alterada.
food=10,-1,-1,8,10,1.0,edu.memphis.ccrg.alife.elements.ALifeObjectImpl
Tarefa 0
Nessa simulação o agente não reage a presença dos macacos.
Questão 2.3: What are the possible reasons the agent doesn’t flee?
Grosso modo, podemos supor a ausência de esquemas de ação e/ou ausência de mecanismos de percepção ou a falta de ligação entre os mecanismos de percepção e ação. No caso do agente alifeAgent_ex3.xml
o que ocorre é a ausência de codelets de atenção associado a predadores.
Tarefa 1
Criamos um codelet de atenção associado a predadores. A task predatorAttentionCodelet
está colocada no módulo de ateçao (AttentionModule
) no arquivo alifeAgent_ex3.xml
.
. . . <module name="AttentionModule"> . . . <!-- TASK 1 INSERT YOUR CODE HERE ************************* --> <task name="PredatorAttentionCodelet"> <tasktype>NeighborhoodAttentionCodelet</tasktype> <ticksperrun>5</ticksperrun> <param name="nodes" type="string">predator</param> <param name="refractoryPeriod" type="int">50</param> <param name="initialActivation" type="double">1.0</param> </task> <!-- ****************************************************** --> . . .
Questão 2.4: How might this affect the agent’s cognition and behavior?
No caso do modelo LIDA, o papel do codelt permite ao agente levar o "conceito" de predador à "consciência". Uma vez que o agente tem "consciência" desse "tipo de objeto" e ele pode agir de acordo.
Tarefa 2
Alteramos o FoodAttentionCodelet
para 0.01.
. . . <task name="FoodAttentionCodelet"> <tasktype>NeighborhoodAttentionCodelet</tasktype> <ticksperrun>5</ticksperrun> <param name="nodes" type="string">food</param> <param name="refractoryPeriod" type="int">50</param> <param name="initialActivation" type="double">0.01</param> </task> . . .
Quanto menor o valor inicial de ativação, menor é a percepção do agente em relação ao objeto em questão (Food).
Questão 2.5: How does this parameter change affect the agent’s cognition?
Já respondido. O parâmetro diminiu o interesse do agente em relação à comida.
Tarefa 3
Para esta tarefa o valor de FoodAttentionCodelet
volta a ser 1.0. Executamos a simulação. O painel do Global Workspace mostra a freqüência das coalizões contendo goodHealth
. A alteração do parâmetro refractoryPeriod
para 10 (no GoodHealthAttentionCodelet
, no módulo de atenção - AttentionModule
) aumenta o número de coalizões contendo goodHealth
.
. . . <task name="GoodHealthAttentionCodelet"> <tasktype>NeighborhoodAttentionCodelet</tasktype> <ticksperrun>5</ticksperrun> <param name="nodes" type="string">goodHealth</param> <param name="refractoryPeriod" type="int">10</param> <param name="initialActivation" type="double">0.10</param> </task> . . .
Neste exercício modificamos alguns esquemas do Procedural Memory
. Configuramos o módutlo Perceptual Associative Memory. Alteramos a estratégia de decaimento para nonNdefault
do ElementFactory
. Inciamos com a seguinte alteração:
lida.agentdata=configs/alifeAgent_ex4.xml
Tarefa 0
Ao executarmos a simulação vemos que o agente não se move até que um macaco se aproxime, ou então até que seu nível de saúde fique abaixo de 0.66.
Tarefa 1
Alteramos o esquema scheme.10b
.
. . . <module name="ProceduralMemory"> <class>edu.memphis.ccrg.lida.proceduralmemory.ProceduralMemoryImpl</class> <param name="proceduralMemory.ticksPerStep" type="int"> 14 </param> <param name="scheme.10">if emptyFront turn left|(emptyFront)()|action.turnLeft|()()|0.1</param> <param name="scheme.10a">if emptyFront turn right|(emptyFront)()|action.turnRight|()()|0.1</param> . . . <!-- MODIFY THE FOLLOWING scheme --> <!-- ____scheme_name__ _____ scheme_label_______|_context______|__action_name____|result|baseLabelActiv. --> <!-- <param name="scheme.10b">if emptyFront turn around ahead|(emptyFront)()|action.turnAround|()() |0.1</param> --> <param name="scheme.10b">if emptyFront move ahead|(emptyFront)()|action.moveAgent|()() |0.1</param> <taskspawner>defaultTS</taskspawner> <initializerclass>edu.memphis.ccrg.lida.proceduralmemory.BasicProceduralMemoryInitializer</initializerclass> </module> . . .
Com essa modificação o agente passa a movimentar-se pela arena.
Tarefas 2 e 3
A inicialização default da PAM é feita pelo BasicPamInitializer
, que lê dois parâmetros (“nodes” e “links”) e cria Nodes
e Links
na PAM (baseado nas especificações dos parâmetros lidos). Os Nodes e Links criados dessa forma usam estratégias default de excitação e decaimento. Para obter estratégias nonNdefault
é necessário fazer as seguinte alterações:
Arquivo: alifeAgent_ex4.xml . . . <module name="PerceptualAssociativeMemory"> . . . <initializerclass>alifeagent.initializers.CustomPamInitializer</initializerclass> </module> . . .
No Netbeans, abra a classe CustomPamInitializer
(veja o pacote alifeagent.initializers
). Este modo de inicialização permite configurar nós e links na PAM:
Node
com rótulo de "object".Link
a partir do Node
rock para o nó "objeto".Essa ligação faz com que o agente receba uma parte da ativação do nó rock toda vez que o agente percebe uma rocha. Se criarmos um link ar um link na PAM de "food" para "object", então o nó "object" também irá receber ativação quando "food" for pecebido. As instruções para as devidas modificações estão no próprio arquivo:
package alifeagent.initializers; . . . public class CustomPamInitializer extends BasicPamInitializer { @Override public void initModule(FullyInitializable module, Agent agent, Map<String, ?> params) { super.initModule(module, agent, params); PerceptualAssociativeMemory pam = (PerceptualAssociativeMemory) module; // Obtains the ElementFactory ElementFactory factory = ElementFactory.getInstance(); // Creates a new Node in PAM labeled 'object' Node objectNode = pam.addDefaultNode(factory.getNode("PamNodeImpl", "object")); // Obtains the 'rock' node from PAM Node child = pam.getNode("rock"); // Adds a Link in PAM from 'rock' to 'object' with link category PARENT pam.addDefaultLink(factory.getLink(child, objectNode, PerceptualAssociativeMemoryImpl.PARENT)); // Task 2: INSERT YOUR CODE HERE ************************** // Obtain the 'food' node from PAM Node childFood = pam.getNode("food"); // Add a Link in PAM from 'food' to 'object' with link category PARENT pam.addDefaultLink(factory.getLink(childFood, objectNode, PerceptualAssociativeMemoryImpl.PARENT)); // Task 3: INSERT YOUR CODE HERE ************************** } }
Durante a execução da simulação, após a inclusão do nó childFood
e o respectivo link com ObjectNode
, vemos na PAM table
as entradas para o nó "object” (veja Figura 18). No PAM graph
vemos o nó "object" com os respectivos links. O nó recebe ativação sempre que o agente detecta uma rocha ou comida. O nó "object" pode ser considerado como entrada para o PerceptualBuffer
, como parte da percepto (se tiver ativação suficiente), como qualquer outro nó da PAM.
A estratégia de decaimento trata do como a ativação de um Node
decai ao longo do tempo. Os tipos de DecayStrategy
( disponíveis estão definidos no factoryData.xml
.
. . . <LidaFactories xmlns="http://ccrg.cs.memphis.edu/LidaFactories" . . . <strategies> <strategy flyweight="true" name="defaultExcite" type="excite"> <class>edu.memphis.ccrg.lida.framework.strategies.LinearExciteStrategy </class> <param name="m" type="double">1.0</param> </strategy> <strategy flyweight="true" name="defaultDecay" type="decay"> <class>edu.memphis.ccrg.lida.framework.strategies.LinearDecayStrategy </class> <param name="m" type="double">0.02</param> </strategy> <strategy flyweight="true" name="slowExcite" type="excite"> <class>edu.memphis.ccrg.lida.framework.strategies.LinearExciteStrategy </class> <param name="m" type="double">0.000000001</param> </strategy> <strategy flyweight="true" name="slowDecay" type="decay"> <class>edu.memphis.ccrg.lida.framework.strategies.LinearDecayStrategy </class> <param name="m" type="double">0.000000001</param> </strategy> . . .
Como vemos no trecho de codificação acima, os parâmetros de decaimento são muito pequenos. Essas estratégias podem ser aplicadas ao nó "object", para isso basta inserir o código abaixo no CustomPamInitialazer
:
/ Task 3: INSERT YOUR CODE HERE ************************** DecayStrategy decayStrategy = factory.getDecayStrategy("slowDecay"); objectNode.setDecayStrategy(decayStrategy);
A estratégia "slowDecay" é obtida de ElementFactory
. Uma nova execução da simulação mostra que quando o objeto é detectado a ativação corrente permanece alta (1.0) por um período longo (visualizar a PAM table
).
Figura 18. Novos relação entre nós no PAM Graph. |
A Figura 18 mostra a nova estrutura (com a adição do nó "object" e o novo link de ativação associado ao food), compare com a estrutura exibida na Figura 16.
Nas implementações feita o agente não faz nada se estiver de frente para uma árvore. Células que contém uma árvore são células seguras contra macacos. Neste exercicio adicionamos um novo codelet de atenção (no arquivo de declaração do agente) em relação a presença de árvore (como local se segurança contra macacos). Para a ação ocorrer adicionamos um novo esquema na Procedural Memory
: action.moveAgent
.
Modificamos o módulo ActionSelection
usado neste projeto. A nova classe ActionSelection
estende o FrameworkModuleImpl
e implementa o ActionSelection
e a interface BroadcastListener
. Novamente, modificamos o arquivo de declaração do agente incluindo um novo listener. Nesse caso o ActionSelection
é um BroadcastListener
do GlobalWorkspace
. Alteramos o módulo ActionSelection contido no arquivo XML de declaração do agente. O algoritmo de seleção de ação implementado considera o broadcast antes de efetuar a escolha.
De fato, experimentamos criar um novo projeto no Netbeans, baseado no framework LIDA, seguindo a receita fornecida no tutorial:
Escolha File, selecione New Project. Em seguida, selecione Java para categorias e Java Application para projetos. Escolha um nome para o projeto. Desmarque a opção "Create main class".
Inclusão de bibliotecas. Na opção projeto, use o botão direito para abrir a janela "Properties": selecione "Libraries" e adicione os arquivos jar (todos os aquivos da pasta lib e o framework jar: lida-framework-v1.1b.jar
). Em seguida, configurar as referências para o arquivo-fonte e javadoc para o LIDA Framework Library.
Criação da pasta "config" e adição dos arquivos de configuração necessários: Use a aba "Files" para criar a pasta "config" em "Project". Em seguida adicione os arquivos de configuração (basta copiar dos projetos estudados anterioremete): os arquivos agent.xml
e factoryData.xml
; as propriedades guiPanels
, guiCommands
, lidaConfig
e esquemas LidaXMLSchema.xsd
e o LidaFactories.xsd
.
O trabalho que realizamos com o AlifeAgetExercises
é similar à prática realizada com o basicAgentExercises
, porém com grau de dificuldade maior: criamos um detector de feature, adicionamos uma nova task
em factoryData.xml
,e no arquivo de declaração do agente, criamos codelets de atenção, manuseamos esquemas da ProceduralMemory
e configuramos elementos da ElementFactory
. De fato, o framework LIDA oferece recursos interessantes para a implementação de agentes cognitivos, recursos que não são contemplados no Soar nem no CLARION, como, o efeito broadcast em alusão a processos conscientes. O formato de configuração do agente (todo ele embutido nos arquivos XML) poderia ser "incorporado" à estrutura (sintático-semântico) do Java. No entanto, o formato XML pode ser uma saída interessante, desde que se evite a identificação XML-Orientação a Objetos, para integrar outros paradigmas: funcional - para tratamento de processos concorrentes (interessante para o design do broadcast), declarativa - para o tratamento de regras (interessante para mecanismos de dedução e abdução), propagação de restrições - para o tratamento de "otimizações" (interessante para mecanismos de abdução e indução), etc. Essa integração de paradigmas no design dos agentes cognitivos tornaria o framework LIDA um framework computacional multi-paradigma "independente" de plataforma.
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer