Arquiteturas Híbridas Utilizando Três Camadas

Esta sessão resume vários aspectos ligados a arquiteturas de software robótico híbridas utilizando três camadas. Tratam-se brevemente aspectos ligados aos estados, à forma de implementação, à operação dos diferentes mecanismos e à extensão dessa arquitetura para o caso de multi-agentes.

5.4.1 Estados

Nas ASR híbridas, é de fundamental importância a existência de estados que caracterizem a situação do robô (GAT, 1997). Nessas arquiteturas a memória do estado interno tem diferentes papéis em cada um dos seus diferentes mecanismos: nos Comportamentos há pouca ou nenhuma lembrança sobre os estados internos; no Executivo há memória sobre o estados passados; já no Planejador os algoritmos realizam predições sobre estados futuros.

5.4.2 Implementação

A implementação dos três componentes de uma arquitetura híbrida pode ser realizada em diferentes processos numa aplicação multi-tarefa, ou encadeados adequadamente numa aplicação mono-tarefa. No caso multi-tarefa os processos devem poder interagir quando necessário.

5.4.3 Comportamentos

Os Comportamentos são normalmente escritos em linguagem de alto nível como “C”, sendo sua ativação ou desativação coordenada pelo Executivo. Este tem como papel selecionar quais comportamentos são ativados. Em alguns casos isso envolve a determinação da função de transferência que o(s) controlador(es) deve(m) usar num determinado instante, suprindo os seus parâmetros para sua operação.

5.4.4 Executivo

O Executivo deve ter informação sobre a história passada do sistema. Em função de contingências que ocorrem no ambiente de operação do robô, dessa história, deve ser capaz de comandar o seqüenciamento dos comportamentos. Isto pode ser implementado pelo chamado “seqüenciamento condicional” (GAT, 1997).

O seqüenciamento condicional é análogo ao modelo de “instruções” que pode ser utilizado pelas pessoas para execução de tarefas. Ele contém a base computacional para codificar as instruções em relação às contingências. Assim, o Executivo deve possuir construções para responder a contingências, gerenciar múltiplas tarefas paralelas de interação, através de um seqüenciamento condicional. Essas características podem ser obtidas em programas escritos em “C” (GAT, 1997). Entretanto, as construções tornam-se complexas nessa linguagem, sendo benéfico o uso de linguagens especiais, como os RAP (do Inglês reactive action packages —pacote de ações reativas) (GAT, 1997), os PRS (do Inglês procedural reasoning system — procedimento de raciocínio procedural). Essas linguagem especiais podem ser uma extensão de alguma outra linguagem, como a ESL (Executive Support Language —linguagem para apoiar o executivo) (GAT,1997), que é uma extensão do Lisp ou; a TDL (SIMMONS, 1998), que é uma extensão do C++.

A linguagem TDL

Simmons e seu grupo vem desenvolvendo infra-estruturas para o desenvolvimento de ASR para robôs autônomos há mais de 10 anos, inicialmente através da TCA – Task

Control Architecture (SIMMONS,1994) e, posteriormente, com a TDL, uma evolução da

TCA. Via de regra, ambas utilizam o IPC - Inter Process Communication (SIMMONS, 1994) como base para a comunicação entre os diferentes aplicativos; o IPC é citado brevemente na Seção 7.3.

No contexto de uma cooperação firmada com o Dr. Simmons, e de uma missão de doutorado sanduíche realizada na CMU com financiamento de CNPq, a TDL tornou-se a base da arquitetura do software róbotico do dirigível autônomo. Por outro lado, conforme explicitado na Seção 7.3, o modelo do IPC não foi adotado, sendo a comunicação assegurada pelos sockets do protocolo TCP / IP, tanto no Ambiente de Desenvolvimento e Operação, tratado no Capítulo 7, quanto na ASR do dirigível.

A linguagem TDL, baseada na linguagem ESL (SIMMONS, 1998),, é uma extensão do C++ concebida para compor o nível executivo de uma arquitetura de software robótico, com recursos para a decomposição de tarefas, a sincronização, o monitoramento e o tratamento de exceções (i.e. contingências).

A execução de árvores de tarefas ou task trees constitui um dos recursos para a decomposição tarefas, como está ilustrado na Figura 5.1.

As task trees são estruturas que refletem a hierarquia das tarefas a serem executadas. Os dois tipos básicos de nós das árvores são goals (nós intermediários) e

commands (folhas). Os goals representam tarefas relativamente complexas que devem ser

divididas em sub-tarefas, que são por sua vez divididas em outros goals ou commands. Os

commands são tarefas simples que podem ser executadas diretamente pelo robô.

Cada nó é um pedaço de código que executa uma determinada ação, a qual pode ser auto-suficiente ou pode ser subdividida, gerando filhos na árvore. A criação de filhos é feita dentro do código do nó através de uma cláusula spawn que pode ser seguida de uma clausula with onde são colocadas as restrições sobre a sub-tarefa.

command G goal A goal B goal C goal E command D command F command H command I

Figura 5.1: Árvore de tarefas.

As ações podem conter código condicional, iterativo e até mesmo recursivo, mas a árvore resultante é sempre uma árvore simples, pois os filhos, mesmo quando são nós do mesmo tipo, são nós inteiramente novos na árvore. Note-se que, como a criação dos filhos se dá dentro do código do nó, o mesmo código pode gerar árvores bem distintas em diferentes execuções.

Outro tipo de recurso é denominado de monitor. Enquanto goals e commands são tarefas que são executadas apenas uma vez a cada vez que são chamados (através de uma cláusula spawn), monitors são tarefas repetitivas. O monitor pode, para uma mesma chamada, ser instanciado várias vezes, periodicamente ou não. Quando o monitor é periódico, ele é disparado a cada intervalo de tempo fixo definido na chamada. O monitor não periódico é disparado conforme a restrição de ativação que é também definida na sua chamada.

A TDL possui recursos para tratamento de exceções que operam de forma bem parecida com os recursos similares do C++. Quando é constatada uma situação de exceção, seu tratamento consiste na passagem do evento de nó para nó até que seja encontrado um

que contenha um exception handler capaz de tratá-la. Exception handlers podem ser adicionados incrementalmente nas tarefas durante a programação. Isso facilita o desenvolvimento de um sistema, onde não foram previstas antecipadamente todas as situações possíveis, que podem ser muitas, de anormalidades, correspondendo em muitos casos à ocorrência de contingências.

5.4.5 Planejador

No Planejador, escrito em linguagem convencional de alto nível, são executados os processos de planejamento que requerem o uso intensivo de recursos computacionais. A interface entre o executivo e o planejador pode ser realizada de duas diferentes formas (GAT, 1997), na primeira ele produz planos para a executivo e na segunda ele responde a questionamentos do executivo. No caso da arquitetura 3T (BONASSO, 1995) a primeira forma é utilizada enquanto que na arquitetura ATLANTIS a segunda.

5.4.6 Arquitetura de Três Camadas para o Caso Multi-agentes

Em SIMMONS (2000) o conceito de arquitetura de três camadas é estendido explorando o paradigma de multi-agentes (WOOLDRIDGE, 1995). Nesta visão, cada agente é composto das três camadas como numa arquitetura híbrida, sendo que a interação entre os agentes, visando a execução de um trabalho cooperativo, só pode ocorrer entre os mesmos níveis de uma arquitetura de três camadas; isto é, componentes dos níveis de planejamento, executivo e comportamentos só podem interagir com os correspondentes níveis dos outros agentes