+Superfície de
ESTAÇÃO EMBARCADA Módulo de Kernel
7.6 Evolução dos Componentes do Ambiente de Desenvolvimento e Operação
Nas dissertações de MAETA (2001) e MIRISOLA (2001), que abordam e detalham temas originários e inseridos nos trabalhos desta tese, o protótipo do Ambiente de Desenvolvimento e Operação sofreu vários aprimoramentos. Maeta abordou a evolução da Estação Embarcada e em particular o MKE. Mirisola abordou a evolução da Estação de Terra enfocando o MKT, outros componentes a ela associados e a inclusão, na IHM de operação, de um sistema de programação de tarefas por pontos de passagem, constituindo um módulo básico de especificação de missões.
A principal deficiência apresentada pelo protótipo inicial do ambiente, principalmente do MKE e do MKT, residia na dificuldade de se acrescentar novas funcionalidades, fazendo com que o processo de manutenção e evolução fosse complexo e
ineficiente. A principal causa desta deficiência deveu-se ao desenvolvimento segundo uma metodologia de prototipagem, utilizando técnicas de programação procedurais. Tornou-se necessário o uso, no processo de desenvolvimento, de uma metodologia de projeto que formalmente englobasse e documentasse as várias fases, dando garantia à evolução do software.
7.6.1 Evolução dos Módulos de Kernel Embarcado e em Terra
Para alicerçar a geração de uma nova versão do Ambiente de Desenvolvimento e Operação, MAETA (2001) e MIRISOLA (2001) adotaram um paradigma de programação orientado a objetos. Além disso, a metodologia UML (Unified Modeling Language) foi utilizada como ferramenta de desenvolvimento de software, englobando as fases clássicas de Especificação de Requisitos, Análise de Requisitos, Projeto e Implementação; ao final do ciclo de desenvolvimento foram gerados os diagramas das classes e diagramas de colaboração (da metodologia UML) para o sistema.
Para estas versões orientadas a objeto do MKE e do MKT, os objetivos considerados foram:
• Encapsular as rotinas de baixo nível como: leitura/escrita de dados das portas seriais, formatação/conversão de dados de sensores e acesso a outros periféricos;
• Separar em módulos os diversos elementos que compõem os sistemas embarcado e de terra, organizando-os segundo critérios de funcionalidade e facilidades de compreensão e manutenção;
• Permitir que novos sensores fossem facilmente acoplados, tanto na estação embarcada como na estação de terra, sem geração de impactos significativos no restante do sistema;
• Simplificar a inserção de algoritmos de controle e navegação nas estações embarcada e de terra, com a sintonização de seus parâmetros “on line” a partir da estação de terra, sem impactos significativos no restante dos componentes do sistema;
• Facilitar o processo de conexão dos sistemas de controle de baixo nível embarcados com outros que possuam um nível de abstração mais elevado, como programação de tarefas ou controle de missão;
• Sistematizar e melhorar a qualidade da documentação, facilitando a compreensão do sistema, de seu funcionamento, e também a sua evolução. Tanto para o MKE como o para o MKT estabeleceu-se analogia com um agente robótico apresentado em MAETA (2001), resultando no diagrama simplificado da nova estrutura do software embarcado e de terra, ilustrado na Figura 7.9 (MAETA, 2001), que apresenta na sua parte superior os componentes de hardware e na parte inferior os componentes de software, que nos seus níveis mais próximos ao hardware refletem seus componentes, e nos níveis mais afastados refletem os componentes de nível de abstração maior.
Hardware -
Sensores
Computador
Atuadores ComunicaçãoSistema de
Software
Sensores Atuadores Comunicação
Sistema de Controle
Controladores - posição, direção, velocidade Objetivos da Missão
Sistema Inteligente - Tomada de Decisões
Ambiente
Interface do Sistema de Controle
Figura 7.9: Esquema simplificado da estrutura para o software do módulo do Kernel Embarcado e módulo do Kernel em Terra.
As novas versões do MKT e do MKE compõem-se de quatro elementos principais: sensores (sensors), atuadores (actuators), sistema de controle (control) e sistema de
comunicação (communication). No caso da instância implementada pelo MKT, os elementos atuadores não são utilizados.
A Figura 7.10 apresenta o diagrama de classes aplicável tanto para o sistema embarcado (embedded_system) quanto para o sistema em terra. Ele é composto pelos quatro módulos: sensors, communication, control e actuators e as suas interfaces públicas. Observa-se na figura que as interfaces públicas das classes correspondem a métodos para a inicialização e execução das tarefas destas e para a troca de mensagens com outros módulos. Observa-se, também, que as classes sensors, control e actuators herdam características da classe module, com compartilhamento de métodos para troca de mensagens com outros módulos, inclusive mensagens que podem ser trocadas entre o MKE e o MKT. Vê-se também a classe canManager, que é compartilhada pelos módulos sensors e actuators, pois ela pode ser utilizada para acionamento de atuadores ou para leitura de dados de sensores. sensors init( ) receiveSensorData( ) getSensorDataPtr( ) actuators init( ) executeActuators( ) getCommandsPtr( ) control init( ) executeControl( ) communication init( ) receiveMessage( ) sendMessage( ) module putMessage( ) getMessage( ) initModule( ) insertMsgOutQueue( ) canManager init( ) sendMsg( ) recvMsg( ) setRecvMsg( ) resetRecvMsg( ) handleInterrupt( ) embedded_system initEmbeddedSystem( ) doIteration( ) close( )
Figura 7.10: Diagrama de classes dos módulos que compõem o sistema embarcado A Figura 7.11 apresenta um dos diagramas de colaboração elaborados para o MKE, mostrando o relacionamento dos métodos das classes no caso de inicialização do sistema (MAETA, 2001). O Diagrama de Colaboração consiste em caixas representando as classes, linhas verticais partindo das classes e, em linhas horizontais, setas que podem interceptar as linhas verticais indicando ou não a existência de uma colaboração entre as classes.
Assim o diagrama de colaboração da Figura 7.11 mostra a colaboração existente entre as classes do sistema embarcado no seu processo de inicalização: a classe "embarc_main" do MKE chama o método de inicialização (initEmbeddedSystem) da instância da classe principal do MKE (embedded_System). A chamada da inicialização do sistema embarcado consiste:
i) na chamada da inicialização da rede CAN através do método "init" da classe canManager;
ii) na inicialização dos sensores através do seu método de inicialização que recebe a referência do gerenciador da rede CAN (canManager);
iii) na inicialização dos atuadores, no caso atual através da especificação da referência do módulo microcontrolador (MCC) descrito no Anexo 1;
iv) na inicialização dos algoritmos de controle através do seu método "init" e; v) na inicialização da comunicação entre os módulos através do método "init". Há outros diagramas de colaboração como o que descreve um passo de iteração do sistema de controle, etc.
EMBEDDED : embedded_system
SENSORS : sensors ACTUATORS : actuators CONTROL : control communication COMM : embarc_main CANMAN : can Manager init (int) init (canManager) init (mcc) init ( ) init (sensors, control, actuators) initEmbeddedSystem ( )
Figura 7.11: Diagrama de seqüência da inicialização do sistema embarcado.
Como já foi dito anteriormente, o MKT (MIRISOLA, 2001) utiliza o mesmo diagrama de classes que o MKE e possui praticamente a mesma estrutura que este. A sua implementação é mais simples, com a instanciação de objetos adequados à estação de terra. 7.6.2 Programação de Tarefas por Pontos de Passagem e Sintonização de Controladores
Em (MIRISOLA, 2001) é apresentado o desenvolvimento de um Módulo da IHM que permite ao operador da estação de terra, durante o vôo, de interagir com o sistema embarcado com dupla finalidade:
i) ajustar dos parâmetros de configuração e sintonia dos algoritmos embarcados de controle e navegação do dirigível, apresentados no Capítulo 8 e ;
ii) possibilitar a programação de tarefas, estabelecidas nessa versão através da definição de um conjunto de pontos de passagem que representam locais a serem sobrevoados pelo dirigível.
Figura 7.12: Interface gráfica do sistema de programação de tarefas.
A Figura 7.12 apresenta a tela principal do módulo, com seus vários botões de interface com o usuário. No campo à esquerda aparecem botões que são auto explicativos, na medida em que o mouse para sobre eles. Existem botões associados à alteração de parâmetros de configuração e de sintonia dos algoritmos de controle no caso os botões "set" e "Send Param", sendo os demais botões associados à definição de uma tarefa através de pontos de passagem como os botões "Send Mission", "Save", "Load", etc.
No caso de definição de uma tarefa por pontos de passagem, mostrado na Figura 7.12, aparece na tela o mapa digitalizado da região de vôo definido através de um arquivo de configuração. O usuário, movimentando o mouse sobre o mapa, pode definir novos pontos por onde o dirigível passará e clicando sobre o local correspondente, incluir este ponto na lista de pontos da tarefa do dirigível. Da mesma forma ele pode apagar pontos da lista, selecionando um ponto com um click do mouse e clicando no botão "X". O Botão "Save" permite ao usuário salvar uma lista de pontos, e o botão "Load" carregar uma lista de pontos. Esta lista de pontos é armazenada sob forma textual permitindo ao usuário editá- la com um editor de texto e alterá-la. Quando da execução de um vôo o usuário pode enviar uma lista de pontos ao sistema embarcado através do botão "Send Mission", sendo que na versão atual esta lista só será aceita pelo sistema embarcado caso o dirigível esteja em modo de pilotagem manual. Imediatamente após o chaveamento de modo manual para automático no rádio-controle do dirigível, este começará a fazer a varredura seqüencial da lista enviada.
Conforme já foi dito, os botões "Set" e "Send Param" estão associados à alteração parâmetros de configuração e de sintonia dos algoritmos de controle. O click no botão "Set" abre a janela de configuração mostrada na Figura 7.13, chamada de "Parameters".
O nome e número de parâmetros é definido num arquivo de configuração, aparecendo na janela o número de linhas correspondente ao número de parâmetros. O programa em si não realiza nenhuma crítica nos parâmetros digitados, sendo a estação embarcada a que tem entendimento sobre sua semântica. No caso mostrado na figura são definidas onze parâmetros, dos quais os oito primeiros correspondem a ganhos dos controladores de trajetória e altitude, as linhas chamadas de "RECT_EDGE_A" e RECT_EDGE_B" servem para definir duas arestas de um retângulo, caso se use geração automática de pontos de passagem na estação embarcada e a última linha "CNT_ENABLE" é para definir quais são os controladores que serão habilitados quando do chaveamento para o modo automático, atualmente "0" significa só trajetória, "1" trajetória e altitude, "2" trajetória, altitude e velocidade e "3" só altitude.
O botão "Send Param" da janela principal serve para se enviar via rádio-modem os parâmetros para a estação embarcada, que só os aceita, caso se encontre em modo de pilotagem manual. Observa-se que o piloto deve utilizar o rádio-controle para comandar os atuadores que não foram habilitados para o modo de controle automático, assim no modo "0" ele deve controlar a altitude pelo leme de profundidade e ou vetorização, e a velocidade de rotação dos motores.
Este módulo, por ser compilado, apresenta vantagens de desempenho em relação a aplicativos escritos em Java ou Tcl/Tk, que são interpretados. A base para o seu desenvolvimento em C++ é a biblioteca gráfica orientada a objetos, o "qt", que possui estrutura de dados para facilitar aplicações que usam interfaces gráficas e a classe “template” que implementa as estruturas de dados comuns (fila, listas, etc).
Por ter sido desenvolvido segundo uma metodologia orientada a objetos, o módulo pode ser facilmente modificado para atender aos novos tipos de tarefas e novos algoritmos de controle e navegação. Em MIRISOLA, (2001) são explicados detalhes do módulo, como a independência da representação gráfica do objeto e das suas características gerais, ou a forma como seriam introduzidas primitivas adicionais como vôo pairado, decolagem e aterrissagem.
7.6.3 Visualizador 3D de vôos
Outra evolução incorporada foi a de visualização 3D do movimento do dirigível, mostrada na Figura 7.14, realizada por um programa cliente escrito em “C”, visu3D, que se conecta ao servidor de dados da estação de terra. Este programa utiliza funções da biblioteca MESA (MESA, 2001), com funcionalidade análoga ao Open-GL, e com base nas informações dos estados, posição e orientação do dirigível, realiza a visualização 3D do veículo. Diferentes pontos de vista podem ser definidos pelo usuário; na Figura 7.14 vê-se o dirigível a partir do solo, enquanto que uma outra possibilidade é a visão do solo a partir de uma câmera virtual embarcada no dirigível.
Figura 7.14: Visualização 3D dos estados do dirigível.
Esta solução de visualizador em Mesa/OpenGL para o dirigível foi desenvolvida pela equipe do Dr. José Raul Azinheira do IST, Portugal. Ela foi adotada em substituição à visualização JAVA/VRML apresentada no Capítulo 5, pois esta última necessita de um
plug-in VRML para Linux, que até muito recentemente não estava disponível.
7.7 Conclusões
Este capítulo apresentou inicialmente a motivação para a concepção de um ambiente de suporte ao desenvolvimento e operação do dirigível, tendo como referência outro ambiente desenvolvido para uso com veículos subaquáticos. Abordou-se então a configuração conceitual do ambiente com todos os componentes integrados por uma rede TCP/IP. A seguir foi apresentada a estrutura efetivamente adotada em termos de
modularização e comunicação entre os módulos. Foi detalhado o protótipo inicial, desenvolvido congregando as estações de terra e embarcada, além do ambiente de CACSD do dirigível; o ambiente assim configurado pode ser utilizado no modo simulado (dando suporte ao desenvolvimento) ou no modo real (apoiando a operação do dirigível robótico em seus vôos). Na seção final apresentaram-se brevemente resultados de duas dissertações de mestrado, associadas a esta tese, desenvolvidas na perspectiva da evolução do ambiente, utilizando técnicas de projeto de software e programação orientada a objeto, e da inclusão de um módulo de IHM para a programação de tarefas para o dirigível, em termos de pontos de passagem, para a sintonização dos controladores embarcados e para a incorporação de um visualizador em 3D da situação do dirigível em vôo
O ambiente de desenvolvimento e operação constitui a base para os trabalhos do dirigível robótico, dando suporte à telemetria e armazenamento de dados, à alteração de parâmetros e configuração de algoritmos de controle, à programação de seqüências de vôo, permitindo uma série de testes em vôo real e simulado. Além do mais ele constitui a base para o desenvolvimento da arquitetura de software robótico do dirigível tratado no Capítulo 9.
Os programas que compõem este ambiente totalizam aproximadamente vinte mil linhas de código escrito em "C", "C++", Java, Tcl/Tk e assembler. Alguns de seus componentes possuem solução específica para uso no sistema operacional Linux, mais particularmente o RTLinux, sendo que a migração para outros sistemas de tempo real poderá requerer a realização de um trabalho de adaptação.
O próximo capítulo enfoca o sistema de controle e navegação, cuja implementação utilizou o Ambiente de Desenvolvimento e Operação.