Objetivo

Utilizar o Soar para controlar uma aplicação externa por meio da interface SML. O sistema desenvolvido será a mente artificial de um agente capaz de controlar o robô no ambiente WorldServer3D utilizado na primeira aula.

Relatório das Atividades

Atividade 1

Para essa atividade, o código do WorldServer3D, que foi utilizado na primeira aula foi modificado. Veja o programa funcionando, acessando os seguintes links:

• WorldServer3D
• DemoSOAR

Os arquivos com o código fonte desses mesmos programas podem ser obtidos nos seguintes links:

• WorldServer3D
• DemoSOAR
• WS3DProxy

O WS3DProxy é uma library de apoio, que faz toda a conexão com o WorldServer3D, e envia e recebe comandos em objetos de alto nível. Seu código fonte está sendo adicionado, para auxiliar o estudo.

Abra o código fonte do DemoSOAR no Netbeans, e faça uma análise de seu funcionamento. Para tanto, siga o roteiro a seguir, registrando as eventuais respostas a perguntas em seu relatório.

1. Abra o código da classe SimulationSOAR.java, que contém o método main. Observe o uso da classe NativeUtils para resolver o problema do gerenciamento do código JNI para diferentes versões de sistema operacional. Entenda como esse gerenciamento é feito e registre em seu relatório.
   
   A classe NativeUtils provê o método loadFileFromJar que lê um arquivo especificado, cria uma cópia temporária no diretório local e o carrega para acesso pelo programa.
    
2. Observe que essa solução é estendida ao carregamento de arquivos com código SOAR, para uso do controlador. Como isso é implementado no Demo ?
   
   Da mesma forma que para as bibliotecas nativas, o arquivo de regras é carregado e passado para a classe SimulationTask que por sua vez passa para a classe SoarBridge que cria um kernel Soar e instancia um agente com as regras contidas nesse arquivo.
    
3. O loop principal de simulação do DemoSOAR também se encontra no método main. Explique seu funcionamento.
   
   O método main instancia um objeto SimulationTask cujo método runSimulation é chamado a cada passada do loop principal. O ambiente de simulação é iniciado através das chamadas aos métodos initializeEnviroment e initializeCreatureAndSOAR.
    
4. Acesse o código da classe SimulationTask.java, para compreender em mais detalhes o que está acontecendo. Observe que essa classe já se utiliza das classes de apoio em WS3DProxy. Entenda e explique como é feito o acesso ao WorldServer3D, por meio do WS3DProxy.
   
   O objeto WS3DProxy estabelece uma conexão via socket com o WorldServer3D e provê métodos para a execução de comandos no ambiente e captura das respectivas respostas.
    
5. Observe que a classe SimulationTask utiliza-se da classe SoarBridge, para ter acesso ao SOAR. Explique como é feita a leitura do estado do ambiente no WorldServer3D, e como esses dados sensoriais são enviados para o SOAR. Da mesma forma, explique como os dados enviados pelo SOAR são aproveitados para controlar a criatura no WorldServer3D. Registre suas conclusões no relatório de atividades.
   
   SimulationSOAR.main
      SimulationTask.runSimulation
         c.updateState(); { Creature c; WS3DProxy proxy; c =proxy.createCreature(100,100,0); }
         List<Thing> v = c.getThingsInVision();
         prepareAndSetupCreatureToSimulation(c, v);
         soarBridge.runSimulation(); { sml.Agent agent; agent.RunSelfTilOutput(); checkForKernelOrAgentError(); }
         processResponseCommands();
   
   A leitura do ambiente no WorldServer3D é realizada através do método sendGetCreatureState da classe CommandUtility e esses dados sensoriais são passados ao SOAR soarBridge.setupStackHolder
    
6. Acesse o conteúdo do arquivo de regras SOAR: soar-rules.soar e tente entender seu funcionamento. Explique o princípio lógico de seu funcionamento.
   
   A criatura vagueia (wander) pelo ambiente e guarda na sua memória as entidades captadas pelo sensor visual (comida ou jóia). A criatura se move na direção das entidades na sua memória (comida ou jóia). A criatura come a comida ou pega a jóia que estejam próximas dela. A criatura evita obstáculos (brick). Uma série de preferências orientam a escolha da ação a ser tomada dentre diversas propostas.
   x tem preferência sobre y
   seeEntityWithMemoryCount seeEntityWithoutMemoryCount > moveJewel moveFood
   avoidBrick > seeEntityWithMemoryCount seeEntityWithoutMemoryCount
   seeEntityWithMemoryCount  = seeEntityWithoutMemoryCount
   getJewel > moveJewel moveFood
   getJewel > avoidBrick
   moveJewel (d) > moveJewel (d1 > d)
   getJewel (d) > getJewel (d1 > d)
   eatFood > moveFood moveJewel
   eatFood > avoidBrick
   moveFood (d) > moveFood (d1 > d)
   eatFood (d) > eatFood (d1 >d)
   moveFood > moveJewel (if fuel < threshold)
   moveJewel > moveFood (if fuel > threshold)
   avoidBrick (d) > avoidBrick (d1 > d)
   avoidBrick > moveJewel moveFood (if entity is in memory)
   wander <

Atividade 2

1. Cada criatura no WorldServer3D possui um "leaflet", ou seja, uma meta na obtenção de jóias. O programa DemoSOAR e também o soar-rules.soar, foram modificado de tal forma que os leaflets de cada criatura sejam levados em consideração pelos seus controladores.
   
   Inicialmente foi necessário adicionar os leaflets à criatura. Isso foi realizado através da alteração da classe DemoSOAR.SoarBridge, incluindo no método setupStackHolder uma estrutura representando os leaflets pertecentes à criatura. Essa estrutura foi adicionada no inputLink da criatura, abaixo de ^CREATURE, e sua descrição é:
   ^LEAFLETS
      ^NUMBER-OF-LEAFLETS <número de leaflets>
      ^SCORE <soma dos valores payment de cada leaflet>
      ^DONE <0|1>
      ^LEAFLET
         ^ID <ID do leaflet>
         ^PAYMENT <valor do payment para o leaflet>
         ^COLOR <cor da jóia>
            ^TO-COLLECT <número de jóias a coletar>
            ^COLLECTED <número de jóias coletadas>
         ^COMPLETED <0|1>
   Há três instâncias de ^LEAFLET e em cada uma, há de uma a três instâncias de ^COLOR. O elemento ^COMPLETED indica se o leaflet correspondente já foi completado, ou seja, se os valores em ^TO-COLLECT e em ^COLLECTED são iguais para todas as instâncias de ^COLOR. O elemento ^DONE indica se todos os leaflets foram completados, ou seja, se para todos os leaflets o elemento ^COMPLETED correspondente possui valor 1.
   Para garantir a atualização da estrutura a cada ciclo de entrada do SOAR, o método clearEntitiesToNextSimulation da classe SoarBridge foi alterada para remover os elementos da estrutura ^LEAFLET da memória de trabalho.
   
   Ainda em DemoSOAR, foi criada a classe SoarCommandDeliver para representar o comando DELIVER e alteradas as seguintes classes:
   SimulationRobot - para adicionar métodos set e get para a lista de leaflets;
   SimulationTask - para incluir a inicialização da lista de leaflets da criatura no método prepareAndSetupCreatureToSimulation;
   SimulationTask - para incluir método processDeliverCommand para o tratamento do comando DELIVER e que é invocado pelo método processResponseCommands;
   SoarCommand - para inclui o comando DELIVER;
   SoarBridge - para incluir o tratamento do comando DELIVER no método getReceivedCommands;
   
   O WS3DProxy também sofreu alterações, para a inclusão do parâmetro leafletID nos métodos deliverLeaflet, da classe
   Creature, e sendDeliverLeaflet, da classe CommandUtility.
   
   Outras alterações foram realizadas para facilitar a simulação e permitir a execução simultânea de duas instâncias de DemoSOAR:
   Em WS3DProxy, nas classes:
   World - para incluir o método getNumberOfCreatures que retorna o número de criaturas presentes no ambiente;
   Em DemoSOAR:
   SimulationTask - para incluir o teste do número criaturas presentes no ambiente, para evitar que mais de uma criatura execute o método de geração de objetos no ambiente; e
   Em WorldServer3D, as classes Main, Creature e Leaflet para contabilizar as jóias de um leaflet já obtidas e impedir o deliver de um leaflet incompleto.
   A versão modificada pode ser executada pelo link: WorldServer3D e os códigos fonte podem ser obtidos no link: WorldServer3D.zip.
   Os códigos fonte da versão modificada do WS3DProxy podem ser obtidos no link: WS3DProxy.zip.
   
   As alterações estão identificadas com comentários iniciados pelas iniciais: EFJC.
   
   As regras SOAR também foram modificadas para incluir o deliver dos leaflets completos, acrescentando e adequando preferências, além de uma regra para deteção da condição de conclusão, fazendo com que o agente passe a executar o operador wander (atribuindo-lhe maior preferência) quando todos os leaflets forem completados.
   As figuras Fig. 2.1 e Fig. 2.2 mostram as regras adicionadas ao soar-rules.soar, relacionadas aos leaflets da criatura.
   
   

   Fig. 2.1 - Operadores Deliver

   
   

   Fig. 2.2 - Preferências para o operador Deliver e condição de parada.

   
    
2. O programa DemoSOAR modificado pode ser executado pelo link: DemoSOAR e os códigos fonte podem ser obtidos no link: DemoSOAR.zip.
   
   As figuras a seguir mostram a captura das telas do SOAR Debugger e do ambiente do WorldServer3D para uma execução do DemoSOAR modificado, mostrando que a criatura se comporta como o esperado.
   
   

   Fig. 2.3 - A estrutura de Leaflets da Criatura na memória de trabalho.

   
   
   

   Fig. 2.4 - Momentos da execução em que os Leaflets foram entregues e o score final obtido.

   
   
   

   Fig. 2.5 - O ambiente do WorldServer3D ao final da execução.

   
   
   Observações:
   1. Como o WorldServer3D não está exigindo que os leaflets sejam entregues somento no Delivery Spot, e para simplficar a implementação, as entregas foram realizadas na posição em que a criatura se encontrava no momento em que cada leaflet foi completado;
   2. A tela Knapsack and Score não é atualizada corretamente e, portanto, o valor do campo Score e as quantidades das jóias mostradas no campo Leaflet estão incorretas;
   3. De fato, o operador wander faz com que a criatura gire sobre o seu eixo em vez de vaguear pelo ambiente.
    
3. Duas criaturas competindo em um mesmo ambiente, para ver qual delas consegue completar seu "leaflet" com mais rapidez.
   
   Em função de problemas no WS3DProxy, essa atividade ainda não pode ser concluída.
    
4. Efetuar uma competição entre o controlador desenvolvido e outro desenvolvido por um colega de turma que já tenha concluído essa atividade.
   
   Pelo mesmo motivo do item anterior e pela maioria ainda não ter disponilizado suas versões, essa atividade também ainda não foi concluída.