Aula 7 - SOAR: Controlando o WorldServer3D.

Atividade 1

Nesta aula, irá estudar e experênciar a utilização da arquitetura cognitiva artificial SOAR como um sistema de controle em um ambiente virtual. Para execução desta aula, será utilizado os seguintes códigos fontes de softwares juntamente com sua respectiva função como:

• DemoSOAR: Software controlador (Mente Artificial) que controla Animats no ambiente virtual WorldServer3D utilizando SOAR.
• WorldServer3D: Ambiente Virtual.
• WS3DProxy: Uma ferramenta (Framework) de comunicação entre a mente aritifial(DemoSOAR) e o ambiente virtual(WorldServer3D).

1.1 - DemoSOAR, WorldServer3D e WS3DProxy.

O DemoSOAR é um software que implementa o conceito de mente artificial que controla Animats presente no ambiente virtual proposto pelo software WorldServer3D. Ele utiliza-se da arquitetura cognitiva artificial denominada de SOAR, que basicamente ela executa regras de produção que são previamente projetadas e que manipula (grava e exclui) dados presente em um grafo (Memória de Trabalho), que pode realizar comportamentos diversos no Animat que o mesmo controla. Neste caso, o SOAR serve como controlador do Animat no mundo virtual.
Como visto nos tutoriais, o SOAR apresenta características fundamentais para ser considerada um sistema cognitivo artificial e algumas delas a capacidade de controle, a capacidade de aprendizado e a capacidade de armazenamento. Tendo em vista uma comparação com um sistema nervoso humano, o SOAR é a mente do Animat que é capaz de sensoriar e executar ações sobre o mundo em sua volta, as regras de produção é a consciência de um indivíduo que executa e controla as atividades no mundo e o grafo é a memória de trabalho do indivíduo.
O DemoSOAR e o ambiente WorldServer3D são aplicações independentes e distintas, portanto há a necessidade de existir uma ferramenta que servirá como um meio de comunicação entre ambos que neste caso estabelece um conexão via protocolo TCP/IP, consequentemente definindo alguns protocolos de comunição para ações do Animat no ambiente virtual. Por sua vez, a ferramenta utilizada para determinada responsabilidade é o WS3DProxy, nela está implementada protocolos de comunicação pré-determinados conforme os comandos do WorldServer3D.

1.2 - Gerenciamento de JNIs.

Inicialmente, deve-se entender como o DemoSOAR importa as libraries do SOAR para poder utiliza-la. O SOAR foi desenvolvido em JAVA e apesar de ser desenvolvido em uma linguagem Multiplaforma, o SOAR apresenta suas libraries compiladas para diversos SOs como Mac OS, Distribuições Linux e Windows, então as libraries do SOAR são carregadas conforme o sistema operacional que o usuário esta utilizando naquele momento. Portanto, o DemoSOAR utiliza-se de um gerenciamento de JNIs (Java Native Interface) para selecionar quais libraries o mesmo deve carregar para execução conforme o sistema operacional que o usuário está executando. No código fonte do projeto do DemoSOAR apresenta um trecho de código que responsável por verificar na Figura 1 abaixo.

Figura 1 - Código Fonte Gerenciador de JNIs.

Podemos perceber na Figura 1 demonstrada anteriormente que o software DemoSOAR utiliza-se da library System(nativa do JAVA) para verificar em qual SO o mesmo se encontra e em qual versão é sua arquitetura (32 ou 64bits) com os seguintes códigos abaixo.

• System.getProperty("os.name")
• System.getProperty("os.arch")

A partir desse momento, obtem-se um série de condições "if" verificando o SO/Arquitetura e consequentemente carregando as libraries correspondente. Para isso, o DemoSOAR utiliza-se da Classe NativeUtils. Vale ressaltar que este trecho de código está presente no método "main()" da classe SimulationSOAR.
A função da classe NativeUtils é localizar e carregar as libraries do SOAR conforme a seleção anterior. Para cada SO o SOAR apresenta suas libraries que são:

• Windows:
  • Soar.lib
  • Soar.dll
  • Java_sml_ClientInterface.dll
• Mac OS:
  • libSoar.dylib
  • Java_sml_ClientInterface.jnilib
• Linux:
  • libSoar.so
  • Java_sml_ClientInterface.so

A classe NativeUtils apresenta outra função de grande importância que é carregar os arquivos relacionados a lógica operacional do SOAR (extensão *.soar). Internamente deste arquivo estão as regras de produção que irá realizar todo o sistema de controle do Animat. Abaixo a Figura 2 o trecho de código presente na classe SimulationSOAR.

Figura 2 - Código Fonte Carregando Regras de Produção SOAR.

1.3 - Inicialização e Execução do DemoSOAR.

A partir do momento que o DemoSOAR carrega todas as libraries do SOAR, o método "main()" instância a classe SimulationTask. A função principal desta classe é inicializar objetos no ambiente virtual do Animat juntamente com os objetos do SOAR e também inicializa a comunicação com WorldServer3D utilizando da classe WS3DProxy. Pode-se verificar no trecho de código a seguir na Figura 3.

Figura 3 - Código Fonte Inicializando Comunicação e Mundo Virtual.

Com o código acima demonstrado, pode-se observar que com a utilização da classe SimulationTask inicializa parâmetros do ambiente virtual "initializeEnviroment()" e "initializeCreatureAndSOAR()". O primeiro método é responsável por criar muros em volta do ambiente virtual, entretanto efetifivamente isso não acontece porque é passado o parâmetro booleano "false". Em seguida é executado o "initializeCreatureAndSOAR()" com os parâmetros: "soarRulesPath, soarDebuggerPath, soarDebuggerPort". O intuito principal deste método é: estabelecer comunicação com o WorldServer3D, inicializar o ambiente virtual, inicializar uma criatura(Animat) e inicializar a mente virtual SOAR com base no arquivo "soar-rules.soar".Após a execução dos métodos, o software entre em um laço onde executa os seguintes passos:

• Atualiza o estado da criatura.
• Captura objetos (perceptos) que estão em seu campo de visão.
• Converte os objetos em Working Memory Element e envia-os ao SOAR.
• Executa as regras no SOAR.
• Em seguida, é capturada a decisão tomada pelo SOAR (MOVE, GET ou EAT).
• A decisão é convertida em comando e enviada para o WorldServer3D.

1.4 - Interface de Comunicação e SimulationTask.

Com dito anteriormente, os softwares WorldServer3D e DemoSOAR são aplicações distintas que se comunicam utilizando o protocolo TCP/IP. Toda tomada de decisão gerada por parte do SOAR (encasulado no DemoSOAR) é convertida em comando (padrão WorldServer3D) e enviado ao ambiente virtual, em seguida, recebe a resposta para determinado comando. Com os comandos padronizados, obtem-se o conceito fundamental que entre as aplicações que existe um protocolo de comunicação, em outras palavras, uma lista de comandos de ações no WorldServer3D. Portanto, houve a necessidade de desenvolver uma ferramenta (Framework) de comunicação entre aplicações e o WorldServer3D, que neste caso é o WS3DProxy.
O WS3DProxy dispõe de métodos para diversas ações no mundo virtual, porem ele é instânciado pela classe SimulationTask que utiliza-o para envia alguns comandos que são:

• GET - Pegar Jóia.
• MOVE - Mover Criatura.
• EAT - Pegar Alimento.

Além de utilizar-se do WS3DProxy, a classe SimulationTask usa outra classe chamada SoarBridge, que é justamente a proposta de servir como "ponte" entre o SOAR e a criatura no mundo virtual. As responsabilidades são de converter os sinais sensoriais que foram enviados pelo WorldServer3D em WMEs na mente artificial(SOAR) via o método "setupStackHolder()" e por converter as tomadas de decisão realizadas pelo SOAR em comandos para criatura no mundo virtual utilizando o método "getReceivedCommands()".

1.5 - Interface de Comunicação e SimulationTask.

O arquivo "soar-rules.soar" compor a mente artificial da criatura com regras referente ao comportamentos que ocorrerão. Os comportamentos ocorrem com o "chuncking" e aplicação dos operadores. No arquivo temos os seguintes operadores com as suas respectivas funcionalidades:

• Wander:Faz a criatura rotacionar em seu eixo em busca de objetos dentro de seu campo de visão.
• See Entity With Memory Count: Armazena na memória da criatura os objetos presentes em seu campo de visão(FOOD ou JEWEL) verificando a quantidade de informações presente na memoria da criatura (memory ^COUNT quantity < 7).
• See Entity Without Memory Count: Idem ao anterior, porem sem verificar a quantidade de informações presentes na memória da criatura.
• Move Food:Movimenta a criatura até o alimento avistado.
• Eat Food:Criatura alimenta-se da comida que está a distância menor do que 30.
• Move Jewel:Movimenta a criatura até a jóia avistada.
• Get Jewel:Criatura captura a jóia que está a distância menor do que 30.
• Avoid Brick:Controle de colisão(rotação) executada pela criatura com parades.

Quando há operadores selecionados ao mesmo tempo ou até mesmo ausência de "chuncking" de operador, o SOAR permite criar regras de resolução de impasses e preferência de operadores, porem deve-se informar a mente artificial qual operador tem preferencia sobre outro e neste caso o arquivo apresenta as seguites regras:

• Move Jewel or Move Food vs See Entity:Preferência do Operador "See Entity With Memory Count ou See Entity Without Memory Count" sobre os operadores "Move Jewel ou Move Food".
• See Entity With Memory vs Avoid Brick:Preferência do Operador "Avoid Brick" sobre os operadores "See Entity With Memory Count ou See Entity Without Memory Count".
• Move Jewel vs Get Jewel: Preferência do Operador "Get Jewel" sobre os operadores "Move Jewel ou Move Food".
• Move Jewel vs Move Jewel: Resolução de impasse entre dois operadores "Move Jewel" decidindo mover-se para a jóia que está em menor distância da criatura.
• Get Jewel vs Get Jewel: Resolução de impasse entre dois operadores "Get Jewel" decidindo pegar a jóia que está em menor distância da criatura.
• Move Food vs Eat Food: Preferência do Operador "Eat Food" sobre os operadores "Move Jewel ou Move Food".
• Eat Food vs Avoid Brick: Preferência do Operador "Eat Food" sobre os operadores "Avoid Brick".
• Move Food vs Move Food: Resolução de impasse entre dois operadores "Move Food" decidindo pegar a jóia que está em menor distância da criatura.
• Eat Food vs Eat Food: Resolução de impasse entre dois operadores "Eat Food" decidindo pegar a jóia que está em menor distância da criatura.
• Avoid Brick vs Avoid Brick: Resolução de impasse entre dois operadores "Avoid Brick" decidindo pegar a jóia que está em menor distância da criatura.
• Wander: Operador "Wander" com menor preferencia em um impasse.
• Avoid Brick vs Move Jewel vs Move Food: Preferência do Operador "Avoid Brick" sobre os operadores "Move Food ou Move Jewel".
• Move Food vs Move Jewel: Preferência do Operador "Move Food" sobre os operadores "Move Jewel", se e somente se o combustível estiver em nível baixo.

Atividade 2

Na atividade 2, deve-se análise e otimizar o código do DemoSOAR e principalmente o arquivo "soar-rules.soar". De maneira resumida, o software DemoSOAR tem a meta de capturar jóia e alimentos que estão dentro de seu campo de visão. Pode-se perceber com a execução do DemoSOAR a maior meta da criatura é capturar jóias do que alimento, com anteriormente demonstrado temos mecanismo de regras de impasses que propõe a resolução deste problema.
A principal ação a se tomar é realizar alterações na mente da criatura, ou seja, alterar o arquivo SOAR. Primeiramente, deve-se verificiar os operadores responsaveis pela movimentação e orientação, que neste caso são: See Entity With Memory Count, See Entity Without Memory Count, MoveFood, MoveJewel e Wander. Portanto alterou-se a velocidade de rotação da criatura(de 1 para 10) no operador Wander, para que ela consigua perceber mais rapidamente os objetos presentes dentro de seu campo de visão. Em seguida, alterou-se a velocidade da criatura para busca-las de forma mais eficiente. Após isso, criou-se um ramo do WME "Creature" chamado "Target", nele estão links com os nomes das cores presentes no leaflet que consequentemente aponta para a quantidade necessária a ser pega. Conforme a criatura captura as jóias, é decrementado do valor do nó do link de cor corresponde. Assim, aplicou-se uma condição nos operadores "See Entity With Memory Count e See Entity Without Memory Count" para que a criatura apenas enchergue as jóias que devem ser capturadas e as que ainda não completaram a quantidade suficiente propósta pelo leaflet. Para maiores detalhes da aplicação, segue o código fonte juntamente com WebStart.

WebStart.

EduardoFroesSOAR.