search

lsa-pucrs / mas-pc-pucrs-2016

Repository for the 2016 MAS programming contest: https://multiagentcontest.org/
2 stars 1 forks source link

simStart Cartago signals bug? #10

Closed rafaelcaue closed 9 years ago

rafaelcaue commented 9 years ago

Pessoal,

Quando a simulação começa é enviada uma percepção simStart, e um conjunto de outras percepções que pelo que eu entendi só deviam ser enviadas no início da simulação (com esse simStart). Vide documento protocol.pdf página 6.

Percepcões como produtos e o número total de passos (steps(N)) deveriam ser enviadas para os agentes apenas no início da simulação, entretanto os nosso artefatos cartago continuam enviando signals com elas durante todos os passos, isso está gerando eventos desnecessários e podem estar atrapalhando a seleção do evento +step que é o que ativaria a escolha da ação para um determinado step.

Primeiro temos que garantir que todas percepções relacionadas ao simStart sejam enviadas apenas 1 vez (por enviadas eu quero dizer gerem apenas 1 evento), é de responsabilidade dos agentes salvar ou não a informação.

Penso eu que o ideal é que só chegue aos agentes (de novo por chegar eu quero dizer gere eventos) informações especificas sobre eles. O número total de passos, produtos, e facilities, podem todas serem enviadas do cartago diretamente para o lider, algo semelhante a o que a arquitetura dos agentes no código do Jomi faz.

O que acham?

anibalsolon commented 9 years ago

De fato, deve estar entulhando os agentes de percepções. Em todos os steps o environment tá mandando todas as percepções, como posição das facilities e tal. Então teria que haver um filtro no artefato ainda, para não encher o líder de coisa.

Acredito ser a ideal essa estrutura de líder fazendo o reasoning pesado. Mais simples e objetiva.

rafaelcaue commented 9 years ago

Exato, precisamos de um filtro. Uma quick fix seria limpar as percepções do artefato depois de dar o signal.

Para ver o problema testem aí, adicionando o código em qualquer agente: +simStart <- .print(simStart).

Vai ver que eles vão printar isso em todos os steps, apesar do cartago receber isso apenas no primeiro step.

meneguzzi commented 9 years ago

@rwesz tu não tiveste este problema na implementação dos artefatos do ROS? Podes dar uma olhada rápida neste problema para ver se a tua maneira de resolver não se aplica aqui?

rafaelcaue commented 9 years ago

Na verdade descobrimos nessa quarta que não é um bug do Cartago, mas sim uma opção do servidor que vinha marcado como default.

A opção em questão está no config file eismassimconfig.xml na raiz, queued=no. Se trocar para yes aí as percepções relevantes ao primeiro step são enviadas apenas no primeiro step, como descrito no protocol.pdf na documentação.

O @rwesz pode ajudar se tiver um tempo na mudança de signals para observable properties, se tiver interesse me chama no gtalk que explico melhor.