Codelets de Geração de Goals

Em nosso controlador motivacional, o SMAN tem como finalidade solucionar o desafio da busca e captura de joias no ambiente visando maximizar a pontuação obtida. Funções como controle energético não fazem parte do escopo deste subsistema. Para que o agente cognitivo consiga obter a máxima pontuação, a arquitetura deve gerar Goals que resolvam este problema, e em seguida gerar planos que contemplem esses goals. Os Codelets responsáveis por essa tarefa são os Codelets de Planejamento e de Seleção de Planos. Entretanto, o funcionamento desses codelets depende anteriormente da existência degoals para que os planos possam ser elaborados. Assim, o Codelet de Geração de Goals além de fornecer parâmetros para o sistema de planejamento, também tem o objetivo de gerarGoals que descrevam um estado futuro desejável. Para isso, esses Codelets utilizam informações das memórias sensoriais. No caso do nosso controlador, o Codelet utiliza

Figura 28 – Codelets Emocionais computando as distorções cognitivas e interferindo no comportamento motivacional.

informações da tabela de trocas para poder definir o objetivo de coletar as joias que ainda precisam ser capturadas.

Em nosso pacote de software, o Codelet de Geração de Goals utiliza a classe Goal para armazenar parâmetros de busca e descoberta de joias. Assim como as demais estrutura de dados citadas neste capitulo, a classeGoal faz parte do pacote motivacional do CST. Na estrutura da classe, existe um atributoGoal Abstract Objects, que é utilizado para descrever um estado futuro desejável. Este atributo armazena uma lista de objetos da classe Abstract Object, que descreve objetos existentes em uma cena de simulação observada pelo agente inteligente. Neste lista, é possível armazenar objetos de simulação e descrever propriedades desses objetos, tais como “Categoria”, “Cor”, “Posição” etc. Essa classe também permite a descrição de propriedades internas do próprio agente, como: “Energia”, “Tabela de Trocas”, “Joias e Maçãs Percebidas” etc. A Figura29demonstra a estrutura da classeAbstract Object. A estrutura de um Abstract Object pode ficar bastante complexa, incluindo Objetos Compositos (partes) e Agregados (para a descrição coletivos),

Propriedades e Affordances1_.

Figura 29 – A classe Abstract Object e suas relações com outros objetos do CST (GUDWIN et al., 2017).

A classe Abstract Object foi concebida para ser capaz de representar diferentes tipos de objetos do mundo real, desde objetos simples com uma única propriedade (como um objeto sensor, com uma única propriedade valor), como coletivos de objetos com diferentes tipos de partes (por exemplo, uma frota de carros, onde cada carro possui diversas partes como rodas, bancos, volante, vidros, etc., e roda por sua vez pode ser composta por pneu, parafusos, etc.). De uma maneira primitiva umAbstract Object pode ser definido por uma lista de Propriedades que definem o objeto. Por exemplo, se queremos representar um objetocarro, poderíamos ter propriedades como a cor do carro, o modelo, ou o ano de fabricação. Propriedades são definidas a partir de dimensões de qualidade. No exemplo do carro, a propriedade “Cor” pode possuir as dimensões de qualidade “R”, “G” e “B” para determinar uma determinada cor bem específica, sendo que para cada uma dessas dimensões de qualidade haveria um número associado como valor. Mas a representação de um objeto não se limita a um conjunto de propriedades. Pode também ser definida a partir de uma lista de partes (outrosAbstract Object), chamadas de objetos “Compositos” ou de uma lista de “Agregados” (também outros Abstract Object). A lista de objetos “Compositos” diz respeito a partes que necessariamente devem existir e que compõem o objeto. Os objetos “Agregados”, ao contrário, são utilizados para definirAbstract Objects que funcionam como coletivos de outro objetos, entendidos como sendo um objeto de per si. Por exemplo, quando descreve-se um carro, pode-se imaginar que o motor, as rodas, o chassi e carroceria são partes necessárias de um carro, pois sem eles um carro não poderia exercer sua função de carro. Portanto, esses sub-objetos são armazenados nas lista de objetos “Compositos” de um objeto carro. Já se queremos representar um objeto frota, podemos representá-lo agregando diversos objetos carro como “Agregados” do objeto frota. Vale a pena ressaltar, que tanto a lista de objetos “Compositos” quanto 1 _{Ações que podem ser executadas sobre o objeto}

a lista de objetos “Agregados” instancia também objetos do tipo Abstract Object. Desse modo, cada um destes pode, recursivamente, possuir objetos “Compositos” e “Agregados”, gerando potencialmente uma estrutura de dados bastante complexa.

No caso do atributo “Goal Abstract Objects” da classe Goal, na lista de objetos “Compositos” estão todas as combinações da tabela de trocas da criatura. Dentre as propriedades que descrevem as combinações da tabela de trocas estão: o “Score” da tabela de trocas (utilizado para a troca de joias por pontos no Ponto de Troca) e também as joias coletadas com suas respectivas cores e quantidades, organizadas de acordo com seu tipo (por exemplo, três da cor azul, zero da vermelha, e assim por diante). O valor do “Score” e da lista de joias são armazenados como dimensões de qualidade de cada propriedade.

O Codelet de Geração de Goals em nosso controlador motivacional utiliza o atri- butoGoal Abstract Objetcs para armazenar a quantidade e as cores das joias que já foram capturadas e também das joias que ainda faltam. O codelet insere oGoal gerado dentro de umMemory Object, e em seguida, armazena-o nas Memórias de Goals (ou Goal Memory). A Figura 30demonstra a geração de Goals a partir das informações sensoriais.

Figura 30 – Codelet de Geração deGoals utilizando informações sensoriais para gerar e definir um Goal.