Atividade 3 - Tutorial Project 2 - A Life Agent

published by aluno2 on Tue, 06/25/2013 - 22:41

Esta segunda parte do tutorial sugere exercícios sobre um novo agente - "A Life Agent" - um pouco mais completo do que o anterior: neste caso, tem-se um jogo de tabuleiro (10 x 10 posições) onde um "agente" deve decidir sua movimentação, desviando de pedras e evitando sair de dentro do tabuleiro, monitorando o seu nível de saúde ("health"), alimentando-se quando necessário e desviando de 2 predadores que se movimentam aleatóriamente.

A seguir uma visão geral do tabuleiro:

Exercício 1

Tarefa 1: rápida análise da GUI

Questão 2.1. Compare a GUI de "alifeAgent" e "basicAgent"; quais são as diferenças e por que elas ocorrem?

A GUI dos 2 agentes difere na seção A, onde está justamente o "panel" específico de cada um deles: "ALifeGuiPanel.java" é mais detalhado do que o seu equivalente no "basicAgent", sendo divido em 3 partes, uma principal com o tabuleiro do jogo e outras duas que permitem a visualização das características dos objetos.

Tarefa 2: inspeção do grafo PAM

O grafo apresenta vários nós interligados, de uma maneira até de difícil visualização; os links são definidos dentro do "alifeAgent.xml" e criados no código de inicialização "CustomPamInitializer.initModule()" com a categoria PARENT.

Os nós criados parecem descrever as diversas situações que podem ser encontradas no ambiente, do ponto de vista do AGENTE; os conceitos também são relacionados entre si, para permitir uma categorização. Um exemplo são os nós que indicam o que está à frente do agente:

"treeFront", "rockFront", "predatorFront", "foodFront", todos relacionados com o nó "front"

Cada um deles, por sua vez, está também relacionados com os objetos específicos que representam:

"treeFront" com "tree"

"rockFront" com "rock"

"predatorFront" com "predator"

"foodFront" com "front"

Será a partir desses conceitos que o agente irá tomar suas decisões.

Tarefa 3: breve análise das tarefas em execução

Através da tab "Running Tasks" é possível verificar quais as todas as "tasks" existentes no agente. Seu escalonamento pode ser visualizar na tab "Task Queue", que representa um determinado instante do processo de execução:

Uma breve análise das tarefas existentes e seu escalonamento permite verificar a existência de detectores para todas as situações importantes que devem ser representadas na PAM, especialmente relacionadas aos objetos descritos acima. São no total 11 tarefas de detecção.

Também estão presentes as tarefas correspondentes aos "attention codelets" que analisam a informação que está na PAM, levando-a para a consciência. Neste caso, são em menor número - apenas 8.

Exercício 2

Tarefa 0: observação da movimentação do agente, de acordo com o nível de "health"

Enquanto o nível de "health" está acima de um determinado valor (algo ao redor de 0,65) o agente não se move; somente após esse limite o agente passa a se mover, em busca de alimento.

Depois de um determinado limite (ao redor de 0,325, como indicado no enunciado do exercício) o agente para de se mover.

Tarefa 1: criação da classe "BadHealthDetector"

Nesta tarefa fica explícito o motivo do agente não se mover depois que sua saúde cai abaixo de 0,33.

Criação da classe "BadHealthDetector", utilizando a classe "FairHealthDetector" como base, simplesmente acertando o limite de comparação para "abaixo de 0,33":

Tarefa 2: definição da tarefa correspondente ao "BadHealthDetector"

Modificação do arquivo "factoryData.xml" para criar a nova tarefa, usando a "FairHealthDetector" como base:

Tarefa 3: declaração da tarefa correspondente ao "BadHealthDetector"

Para completar a criação de uma nova tarefa, ela deve ser adicionada dentro do "taskspawner" definido em "alifeAgent_ex2.xml":

Tarefa 4: declaração de uma tarefa para detectar predadores à frente - "predatorFrontDetector"

Para habilitar o agente a fugir se houver um predador na sua frente, é preciso criar uma tarefa para fazer essa detecção; a criação dessa tarefa resume-se a sua declaração no "taskspawner", uma vez que o tipo da tarefa - "ObjectDetector" - já existe.

Execução do agente:

O agente agora também se move quando a seu nível de "health" está abaixo de 0,33 e ele também foge quando aparece um predador na sua frente.

Questão 2.2: Por que o comportamento do agente é modificado depois que novos detectores de características são adicionados?

Apenas a adição de novos detectores de características provocou uma mudança de comportamento do agente porque na "Procedural Memory" já estavam criados schemes que eram ativados por conta dessas novas características reconhecidas; como pode ser verificado em "alifeAgent_ex2.xml":

"scheme.6", "scheme.6a" e "scheme.6b" definem ações para quando o agente está com "bad health", justamente uma das novas características identificadas.
"scheme.8" define uma ação quando existe um predador à frente, a outra característica identificada.

Todos esses esquemas mapeam para ações que já existiam dentro do "Sensory-motor memory".

Caso não houvesse schemes definidos para as características reconhecidas, ou esses schemes apontassem para ações não existentes no "Sensory-motor memory", novos schemes ou novas ações também deveriam ser criadas para se alterar o comportamento do agente.

Exercício 3

Tarefa 0: executar o agente e verificar que ele não foge dos predadores

Utilizando um novo arquivo de configuração do agente - "alifeAgent_ex3.xml", o agente para de fugir dos predadores.

Questão 2.3: Quais são as possíveis razões para que o agente não fuja?

Existe alguma falha no processo de detecção, verificação e aplicação da ação de fugir do predador: detectores para os nós "predatorFront" e "predatorOrigin" podem estar faltando ou com alguma configuração errada; ou o "attention codelet" responsável por verificar a existência dessas características e levá-las até a consciência podem também estar faltando ou com alguma configuração errada; por fim, podem não existir ou estarem inválidos os schemes que reajam à presença de predadores, a partir da difusão dessa informação na consciência ou haver ainda haver algum problema na própria aplicação da ação.

Numa comparação entre os arquivos de declaração do agente "alifeAgent_ex3.xml" e "alifeAgent.xml" é possível verificar que está faltando o "attention codelet" que verifica a existência das características na PAM.

Tarefa 1: criação de um "attention codelet" para verificação de predadores

Nesta tarefa é criado o "attention codelet" que estava faltando:

Questão 2.4: Como isso (criação do "attention codelet") afeta a cognição e comportamento do agente?

Conforme discutido na questão anterior, a existência dos "attention codelets" é o que permite o reconhecimento de uma entrada sensorial específica e, a partir disso, a sua transmissão até à consciência; dessa forma, a inclusão dos "attention codelets" permite que o agente interprete o que sentiu/percebeu do ambiente.

Tarefa 2: alteração da ativação inicial do "FoodAttentionCodelet"

Com a redução do parâmetro de "initialActivation" do "FoodAttentionCodelet" o agente na maioria da vezes que passa por uma posição com alimento não o come.

Questão 2.5: Como que essa alteração de parâmetro afeta a cognição do agente?

O qu deve ocorrer é que com o baixo nível de ativação inicial que o "FoodAttentionCodelet" cria a sua coalisão ao encontrar o nó "food" no "Workspace" na maioria das vezes essa coalisão não é ativada o suficiente para ser levada até à consciência.

De fato a coalisão com o nó de "food" nem aparece no painel do "Global Workspace".

Tarefa 3: variação do parâmetro "refractoryPeriod" de um "attention codelet"

Diminuindo o "refractoryPeriod" de "GoodHealthAttentionCodelet", "goodHealth" passa a fazer parte mais frequentemente das coalisões criadas, enquanto a "health" é maior ou igual à 0,66.

Exercício 4:

Tarefa 0: Analisar o movimento do agente enquanto "health" >= 0,66

O agente não se move enquanto estiver na condição de "goodHealth", ou seja, "health >= 0,66". Embora neste exercício seja utilizado um novo arquivo de configuração do agente ("alifeAgent_ex4.xml"), já nos exercícios anteriores o comportamento do agente era este mesmo.

Tarefa 1: Modificar ação relacionada a um scheme

Modificação, em "alifeAgent_ex4.xml", do "scheme.10b" para ligar-se à ação "action.moveAgent".

Com a modificação do scheme indicado, quando a condição "emptyFront" ocorre o agente também passará a executar a ação "action.moveAgent", além das ações de "action.turnLeft" e "action.turnRight"; anteriormente, executava a ação "action.turnAround".

Tarefa 2: Customização da inicialização de elementos da PAM - criação de nós e links

Com a modificação da classe de inicialização da "PerceptualAssociativeMemory" é possível customizar como os nós da PAM são criados.

Com as indicações de codificação na classe "alifeagent.initializers.CustomPamInitializer", são criados links da categoria "PARENT" entre os nós "food" e "rock" e um novo nó "object":

Detalhe do "PAM Graph" indicando as novas relações criadas entre "food" e "object" e "rock" e "object"

Indicação de que as novas relações criadas são levadas até o "Perceptual Buffer"

Tarefa 3: Customização da inicialização de elemntos da PAM - mudança da "DecayStrategy".

Nesta tarefa é sugerida a modificação da "DecayStrategy" específica para o nó "object"; para todos os demais é utilizada a estratégia default, definida no arquivo de configuração do agente:

A modificação específica para o nó "object" é feita programaticamente, dentro do mesmo método de inicialização da nova classe customizada:

Com essa mudança para a estratégia de "slowDecay" a ativação do nó "objeto" permance "1.0" por milhares de ciclos - de fato não foi notada o seu decréscimo.

Exercício avançado 1:

Neste exercício é pedido para adicionar o seguinte comportamento ao agente:

Quando houver uma árvore à frente, mova-se até ela.

Para tanto deve ser criado um "attention codelet" para detectar o nó "treeFront":

Além disso, é preciso criar um scheme que responda a essa detecção, fazendo com que o agente se mova à frente:

Com essa modificação o agente passa a ir até a árvore, caso ela esteja na célula à sua frente:

Exercício avançado 2:

Neste exercício é pedido para criar um módulo de "Action Selection" com um algorítmo próprio.

O primeiro passo é indentificar a classe que atualmente é utilizada para a implementação do "Action Selection"; pelo arquivo "alifeAgent_ex4.xml"; através dele é possível identificar a classe "edu.memphis.ccrg.lida.actionselection.BasicActionSelection", cujo código fonte pode ser encontrado dentro do conjunto de fontes do LIDA.

Essa classe será a base para a criação da nova classe "alifeagent.modules.BasicActionSelection":

Analisando essa classe é possível ver que ela implementa a interface "BroadcastListener"; entretanto, o "Action Selection" não consta como configurado para ser um listener do broadcast, dentro do arquivo "alifeAgent_ex4.xml"; essa modificação pode ser feita para ficar da seguinte forma:

Um detalhe importante foi que a versão do código do exercício está baseada no LIDA framework 1.1b, sendo que para a versão 1.2 existem diferenças nesta parte.

Para fazer a verificação sugerida no exercício - validar se todo o CONTEXTO declarado para o "Behavior" foi recebido no "Broadcast" da consciência, são necessárias as seguintes mudanças:

1. Armazenar o conteúdo do broadcast:

2. Validar cada "Behavior" candidato, para verificar se o seu CONTEXTO está todo presente no "broadcast":

Com essas modificações o agente continuou a funcionar a contento, uma vez que todos os CONTEXTOS listados eram exatamente os que já estava sendo ativados e difundidos. Na verdade, não ficou muito claro o tipo de mudança que estava sendo pedido, uma vez que o entendimento atual é o de que o CONTEXTO listado para um "Behavior" necessariamente terá que ter sido ATIVADO via broadcast para que o scheme tenha sido selecionado como "Behavior" candidato.

Ricardo Gudwin's Home Page

Aluno 2

Cursos

Main menu

You are here