A SIMULAÇÃO PARA SISTEMA DE MISSÃO DE AUVS · PDF filetrabalho apresenta...
Transcript of A SIMULAÇÃO PARA SISTEMA DE MISSÃO DE AUVS · PDF filetrabalho apresenta...
ARQUITETURA E AMBIENTE DE SIMULAÇÃO PARA SISTEMA DE MISSÃO DE AUVS BASEADO EM CONTROLE
SUPERVISÓRIO
SANDRO BATTISTELLA, MAX H. DE QUEIROZ
Depto. de Automação e Sistemas (DAS), Universidade Federal de Santa Catarina (UFSC)
88040-900 Florianópolis, SC, Brasil
Depto. de Engenharia Elétrica, Universidade Estadual do Oeste do Paraná (UNIOESTE)
85856-070, Foz do Iguaçu, PR, Brasil
E-mails: [email protected], [email protected]
Abstract Performing missions for autonomous underwater vehicles (AUVs) requires the coordination of multiple software
and hardware components distributed through its embedded control architecture. Through the Supervisory Control Theory (SCT)
it is possible to derive formal models based on modular automata for these components in way to ensure, by design, compliance
with several vehicle operation and safety requirements. This paper presents an architecture for the Mission Control System
(MCS) of AUVs based on SCT, and a simulation environment for validating this architecture. The proposed architecture allows
the direct implementation of the formal models used during the system analysis stage, through automatic code generation, main-
taining desired properties of the system, such as absence of deadlocks and compliance with specifications. The architecture and
the simulation environment are implemented in C/C++ and Java languages, running on ROS (robot operating system) middle-
ware and integrated with Matlab/Simulink software. At the end of the study, two mission scenarios are presented, showing the
flexible and safe operation of the proposed architecture.
Keywords Mission control, underwater robotics, supervisory control theory, robotic architectures, discrete event systems.
Resumo A realização de missões por veículos subaquáticos autônomos (autonomous underwater vehicles ou AUVs) exige a
coordenação de vários componentes de software e hardware distribuídos pela sua arquitetura de controle embarcado. Através da
Teoria de Controle Supervisório (TCS) é possível derivar modelos formais baseados em autômatos modulares para tais
componentes, de modo a garantir, por projeto, o atendimento a diversos requisitos de operação e segurança do veículo. Este
trabalho apresenta uma arquitetura para o Sistema de Controle de Missão (SCM) de AUVs baseado na TCS, e um ambiente de
simulação para validação da respectiva arquitetura. A arquitetura proposta permite a implementação direta dos modelos formais
empregados durante a etapa de análise do sistema, através da geração automática de código, mantendo propriedades desejadas
para o sistema, como ausência de deadlocks e garantia de cumprimento de especificações. A arquitetura e o ambiente de
simulação são implementados em linguagem C/C++ e Java, executados no middleware ROS (robot operating system) e
integrados com o software Matlab/Simulink. Ao final do trabalho, dois cenários de missões são apresentados, mostrando o
funcionamento flexível e seguro da arquitetura proposta.
Palavras-chave Controle de missão, robótica subaquática, teoria de controle supervisório, arquiteturas robóticas, sistemas a
eventos discretos.
1 Introdução
Veículos subaquáticos autônomos (autonomous
underwater vehicles – AUVs) são dispositivos
robóticos inteligentes que atuam na água, com
capacidades de percepção sensorial, tomada de
decisão, planejamento de tarefas, controle de
movimento e execução de ações (Bian et al., 2009).
AUVs são empregados na pesquisa oceanográfica,
exploração de recursos marinhos, acompanhamento
de ecossistemas, inspeção e manutenção de estruturas
submersas, entre outros.
A organização das funcionalidades e equipamentos
de um veículo autônomo se traduz no projeto e
construção de um sistema embarcado, organizado em
uma arquitetura robótica, que determina as estrutura
de dados, o conjunto de componentes de software e
hardware e a interação entre os mesmos (Valavanis et
al., 1997). Como características desejáveis para uma
arquitetura robótica citam-se: abstração com respeito
ao hardware; facilidade de inclusão de novas
funcionalidades e equipamentos; perfomance
razoável frente as imposições de natureza tempo-real;
robustez e tolerância a falhas; disponibilidade de
ferramentas de desenvolvimento, entre outros. A
escolha adequada de uma arquitetura favorece o
desenvolvimento e validação do sistema embarcado
do veículo robótico.
O AUV possui um comportamento de natureza
híbrida, envolvendo dinâmicas dirigidas pelo tempo,
ou contínuas (navegação, localização, sensoriamento,
controle de movimento, etc.) e dirigidas a eventos, ou
discretas (tomada de decisão, controle de missão,
descrição de comportamento de componentes, etc.).
Nesse sentido, teorias da área de Sistemas a Eventos
Discretos (SEDs) vêm sendo aplicadas à robótica
móvel como formalismo matemático para a
modelagem e a análise do comportamento dinâmico
de veículos autônomos, como por exemplo em:
planejamento de missões (Xu, Zhang e Feng, 2004);
descrição da evolução de componentes da
arquitetura (Barrouil e Lemaire, 1996); topologia de
ambientes e descrição de comportamentos
(Christensen e Pirjanian, 1997); representação de
dinâmica híbrida, como manobras (Bhattacharyya et
al., 2005); ou sistemas multi-robôs (Xiang et al.,
2007). Outros trabalhos, além de empregar teorias de
Anais do XX Congresso Brasileiro de Automática Belo Horizonte, MG, 20 a 24 de Setembro de 2014
4044
SEDs para a modelagem e análise, propõem e/ou
implementam arquiteturas embarcadas baseadas em
tais teorias. Tal abordagem permite que os modelos
derivados durante a etapa de análise sirvam também
de modelos para componentes do sistema embarcado
do veículo, preservando certas propriedades, como
ausência de bloqueios, cumprimento às
especificações de segurança e intertravamento, dentre
outras. Exemplos dessa abordagem podem ser
encontrados nos trabalhos de Dias et al. (2006) e
Palomeras et al. (2009).
Particularmente em Battistella, Queiroz e Santos
(2012) propõe-se o uso da Teoria de Controle
Supervisório (TCS) para a modelagem e análise de
AUVs empregando autômatos modulares como
modelos de subsistemas e de especificações de
operação e segurança. Além disso, tal trabalho utiliza
o Controle Supervisório Modular Local (CSML)
(Queiroz e Cury, 2002) para derivar estruturas de
controle, denominadas de supervisores, responsáveis
por garantir que tais especificações sejam atendidas,
independente do tipo de missão a ser realizada pelo
veículo. A abordagem de CSML empregada pelos
autores permite a modelagem do comportamento
dinâmico do AUV baseada na natureza modular da
planta, ou seja, levando em consideração seus
subsistemas, além de prever a ocorrência de eventos
não-deterministas, como falhas e erros, porém sem
fixar a missão a uma sequência única de eventos,
permitindo, portanto, o veículo completar missões
através da realização de caminhos alternativos
àqueles especificados no arquivo de missão. Tais
características diferem das abordagens usuais de
teorias de SEDs em problemas de missão de AUVs.
Por exemplo, em Xu, Zhang e Feng (2004), aplica-se
a TCS. Porém, erros e falhas implicam no
cancelamento da missão, não explorando, assim, os
diversos caminhos habilitados pelo controle
supervisório. Por sua vez, em Palomeras et al.
(2009), empregam-se redes de Petri para o problema
de missão. Contudo, a abordagem é centralizada, não
explorando a modularidade dos diversos subsistemas
do veículo.
O presente trabalho extende e implementa a
arquitetura para o Sistema de Controle de Missão
(SCM) para AUVs atuando em lagos de barragens de
hidrelétricas, cuja modelagem é originalmente
apresentada em Battistella, Queiroz e Santos (2012),
incluindo o Gerenciador de Missão (GM), estrutura
baseada em regras, responsável pela tradução do
arquivo de missão e pela subsequente seleção de uma
entre várias sequências de eventos habilitada pelos
modelos formais do CSML. Tais eventos são
mapeados pela arquitetura do CSML em comandos
que irão guiar o AUV em direção aos objetivos da
missão. A estrutura de CSML é obtida pela geração
automática de código, diretamente a partir dos
modelos empregados durante a fase da análise do
sistema, minimizando, portanto, erros devidos à
codificação manual. O trabalho também apresenta um
ambiente distribuído de simulação para validação da
arquitetura. O emprego de ferramentas de simulação
permite a análise, validação e correção do sistema
antes do mesmo ser construído, diminuindo os custos
e aumentando o sucesso no desenvolvimento desse
tipo de sistemas. A arquitetura proposta e o ambiente
de simulação são desenvolvidos a partir da integração
do middleware ROS robot operating system (ROS)
com o software Matlab/Simulink e uma interface
homem-máquina (IHM) desenvolvida em Java.
O trabalho é organizado da seguinte forma. A seção 2
descreve o processo de modelagem e síntese de
supervisores empregado pelo CSML aplicado ao
problema de missões de AUV. A seção 3 apresenta a
arquitetura para o SCM baseado no CSML. O
ambiente de simulação para a validação do SCM é
descrito na seção 4. Simulações para dois cenários de
missão são mostradas na seção 5. Ao final, são
apresentadas as conclusões do trabalho.
2 Modelagem de AUV usando a TCS
Ambientes de lagos de barragens costumam ser
mais complexos que os ambientes marinhos, devido à
presença de objetos desconhecidos, existência de
regiões proibidas à navegação e correntezas de maior
intensidade. Portanto, a operação de um AUV nesse
tipo de ambiente exige a capacidade de tomada de
decisões que o permita completar uma missão de
maneira segura. Assim, a TCS é empregada nesse
trabalho na modelagem de especificações de
operação do veículo de modo a garantir sua
integridade e segurança, independente do tipo de
missão a ser realizada.
2.1 Teoria de Controle Supervisório (TCS)
A TCS apresenta um framework formal para a
síntese de supervisores ótimos não-bloqueantes
baseados em autômatos modelando o comportamento
em malha aberta, denominado de planta, e
especificações desejadas de comportamento para um
sistema a eventos discretos (SEDs) (Ramagde e
Wonham, 1989). Eventos são gerados
espontaneamente pela planta, e podem ser divididos
em eventos controláveis, cuja ocorrência pode ser
impedida por um agente externo ou supervisor, e
eventos não-controláveis. O supervisor é a estrutura
responsável por observar a evolução da planta e
habilitar e desabilitar eventos controláveis,
informando à planta os caminhos possíveis de serem
realizados e impedindo sequências consideradas
indesejadas. A controlabilidade é a condição
necessária e suficiente para a existência do supervisor
não-bloqueante que atenda uma determinada
especificação desejada para a planta. Quando essa
condição não é satisfeita, é possível sintetizar um
supervisor ótimo minimanente restritivo que atenda a
especificação, dado pela máxima sublinguagem
controlável (Ramadge e Wonham, 1989).
Anais do XX Congresso Brasileiro de Automática Belo Horizonte, MG, 20 a 24 de Setembro de 2014
4045
O Controle Supervisório Modular Local (CSML)
(Queiroz e Cury, 2002) explora características
modulares do sistema físico e das especificações para
o cálculo de um conjunto de supervisores que agem
localmente sobre a planta, mas levam à uma solução
global ótima. A complexidade computacional da
síntese e tamanho dos supervisores locais é reduzida,
evitando o problema de explosão de estados
encontrado na abordagem monolítica, onde somente
um supervisor global é obtido. Assim, a planta é
modelada como um conjunto de autômatos
assíncronos, e as especificações, como autômatos
modulares que restringem o comportamento da
planta. Através do processo de síntese é obtido então
um supervisor ótimo local para cada especificação. A
condição de não-conflito entre os supervisores locais
garante o comportamento global não-bloqueante e
minimamente restritivo.
2.2 Modelagem do AUV segundo o CSML
Como cenário de missão foi adotada a realização
de tarefas de aquisição de dados em lagos de
barragens de hidrelétrica. Nesse sentido, o SCM deve
ser capaz de coordenar o funcionamento de vários
componentes de software e hardware do AUV,
selecionando ações que levem o veículo a cumprir
seus objetivos e impedindo ações que violem
especificações de segurança. Para esse trabalho
foram considerados os seguintes subsistemas: nível
de bateria disponível; carga útil (sonar de batimetria,
câmera e GPS); sensores e algoritmos envolvidos na
determinação da posição e orientação; geração de
trajetórias de referência e controle de movimento do
veículo; previsão e detecção de falhas. A partir do
estudo desses subsistemas foram derivados 12
modelos baseados em autômatos e que descrevem o
comportamento em malha aberta das funcionalidades
do AUV: estado da bateria; colisão; falhas; sensores
CTD; GPS; câmera; sonar de batimetria; submersão
do veículo; e 4 tipos de manobras (navegação,
descida, subida e retorno).
Figura 1. Autômato para a manobra de navegação.
Na figura 1 é possível visualizar o autômato que
representa a evolução de uma manobra de navegação
do AUV. Eventos controláveis são representados por
um arco com traço. O início da manobra é
representada pelo evento st_m e a finalização pelo
evento end_m. Manobras podem ser suspensas
(sus_m) ou retomadas (rsm_m), e manobras
suspensas podem ser finalizadas (fin_m). Erros de
execução de manobras são representados pelo evento
er_m, sendo possível reinicializálas (rst_m). De
modo similar, empregam-se autômatos para
representar cada um dos demais 11 subsistemas ou
plantas modulares.
A composição das plantas modulares representa o
conjunto de todas as sequências de eventos discretos
que o AUV é capaz de realizar. Entretanto, existem
sequências de eventos não desejadas e que devem ser
evitadas pela ação dos supervisores locais sobre a
planta. Tais sequências independem do tipo de
missão a realizar pelo AUV e são obtidas através de
especificações de segurança, como por exemplo,
evitar a realização simultânea de manobras,
suspender a missão enquanto houver erros de
posicionamento, cancelar a missão caso ocorram
falhas ou quando o nível de bateria for muito baixo,
entre outras. Para esse trabalho foram consideradas
57 especificações. A figura 2 apresenta o autômato
da especificação que evita a realização da manobra
de navegação quando ocorrer falhas (f), impedindo
início da manobra (st_m) ou sua retomada (rsm_m).
Mais detalhes sobre os autômatos que descrevem as
plantas, as especificações e o processo de síntese dos
supervisores podem ser obtidos em Battistella,
Queiroz e Santos (2012).
Figura 2. Autômato da especificação que impede o início ou
retomada da manobra de navegação ante a ocorrência de falhas.
Os modelos da planta e das especificações e a
obtenção dos supervisores modulares locais ótimos
não-bloqueantes foram feitas através da ferramenta
Supremica (Akesson, 2002). Para esse trabalho, as
plantas modulares modeladas possuem cerca de 3 a 4
estados, as especificações locais, 2 estados, com
exceção da especificação que impede a ativação
simultânea de manobras, com 5 estados (figura 2).
Como todas as especificações são controláveis e não-
bloqueantes, é possível empregá-las diretamente
como supervisores modulares. Através da ferramenta
é possível ainda emular o funcionamento da planta
sob controle dos supervisores modulares, permitindo
a comprovação das especificações e correções de
possíveis erros cometidos ainda durante a fase de
modelagem.
3 Arquitetura para o SCM
Um dos componentes essenciais para a
realização de missões complexas consiste no Sistema
de Controle de Missão (SCM), responsável por
traduzir cada uma das sentenças contidas em um
arquivo de missão em ações correspondentes que irão
gerar o funcionamento desejado para o AUV
Anais do XX Congresso Brasileiro de Automática Belo Horizonte, MG, 20 a 24 de Setembro de 2014
4046
(Christensen e Pirjanian, 1997; Palomeras et al.,
2009). Eventos não-controláveis são utilizados para
representar a ocorrência não-determinista de
situações no plano de missão, possibilitando o
planejamento condicional da missão, ou seja, a
escolha de caminhos alternativos ao contido no
arquivo de missão. Por sua vez, os eventos
controláveis representam opções de ativação /
desativação de componentes ou operações do AUV.
O método de síntese de supervisores modulares do
CSML garante que a ação dos mesmos sobre o
sistema seja ótima, ou minimante restritiva
(Ramadage e Wonham, 1989), conferindo
flexibilidade no sentido que vários caminhos, ou
sequência de eventos controláveis, possam ser
escolhidos com o objetivo de completar a missão.
Uma segunda estrutura do SCM, denominada de
Gerenciador de Missão (GM) é responsável por
traduzir o arquivo de missão em eventos controláveis
e parâmetros para os vários componentes do sistema.
Por exemplo, sempre que o arquivo de missão
especificar uma trajetória entre dois pontos
quaisquer, o GM escolhe o evento controlável que
indica o início de uma manobra para realizar tal
trajetória, contendo os parâmetros relacionados a
esse deslocamento, como os pontos inicial e final, e
timeouts para realização da manobra, sempre que a
estrutura de CSML permitir que tal evento seja
possível de ser ativado. Além disso, o GM explora os
vários caminhos habilitados pelo CSML, permitindo
então ao veículo completar uma missão sem,
necessariamente, seguir o caminho sequencial de
fases especificados no arquivo de missão.
3.1 Arquitetura para Implementação do CSML
Através de uma arquitetura hierárquica de 3
camadas (figura 3) é possível implementar o CSML,
possibilitando a implementação direta dos modelos
formais da planta e os supervisores em uma
linguagem de programação (Queiroz e Cury, 2002).
Figura 3. Arquitetura do Controle Supervisório Modular Local.
Os Supervisores Modulares (SM) estão situados no
nível superior da arquitetura do CSML. O nível
seguinte contém o Sistema-Produto (SP) que
representa os modelos abstratos das plantas
modulares. E no nível inferior da arquitetura, as
Sequências Operacionais (SO) atuam com a planta
real. De acordo com a ocorrência de eventos nas
plantas modulares, os supervisores habilitam ou
desabilitam eventos controláveis. O SP envia
comandos ao nível SO correspondentes aos eventos
controláveis que estão habilitados. Finalmente, as
sequências operacionais traduzem os comandos do
nível SP em sinais de entrada para o sistema real e lê
os sinais de saída do mesmo, gerando as respostas
enviadas ao SP.
3.2 SCM com Gerenciador de Missão
A arquitetura do CSML é adaptada ao problema
de controle de missões em AUV, ao incluir o
Gerenciador de Missão (GM), e pode ser vista na
figura 4.
Figura 4. Sistema de Controle de Missão baseado no CSML.
O nível sequência operacionais é responsável pela
troca de sinais entre os vários subsistemas do AUV
(planta real) e o nível SP do CSML. No nível SP os
modelos abstratos são atualizados, e os eventos
controláveis são habilitados ou desabilitados pelos
supervisores modulares. Cabe ao CSML desabilitar
os eventos que levam o sistema a estados
considerados indesejados. Além disso, pelo método
de síntese formal, a ação conjunta dos supervisores
modulares do CSML é ótima ou minimamente
restritiva. Portanto, várias são as sequência de
eventos consideradas seguras que são permitidas pelo
CSML, ficando a cargo do GM escolher uma entre
tais sequências. A escolha desses eventos pelo GM
pode ser feita com base em métodos de otimização,
buscando minimizar critérios de consumo de energia,
tempos e distâncias dos deslocamentos, prioridades
de fases, entre outros, possibilitando explorar os
vários caminhos habilitados pelo CSML. O GM
também é responsável pela leitura e tradução do
arquivo de missão, que contém os parâmetros para
Anais do XX Congresso Brasileiro de Automática Belo Horizonte, MG, 20 a 24 de Setembro de 2014
4047
cada uma das fases da missão do AUV, em uma
sequência de eventos controláveis que irá comandar o
veículo.
Sempre que um evento controlável é selecionado
pelo GM, o mesmo é enviado para o nível SP que
atualiza o estado das plantas, atualizando também o
estado dos supervisores no nível SM. Por sua vez, o
nível SP envia para o nível SO o evento ativado, que
é traduzido em comandos para os demais
componentes distribuídos pela arquitetura de
simulação. Os parâmetros de missão também são
enviados para o nível de SO. Do mesmo modo,
respostas enviadas pelos componentes ao nível de SO
são traduzidos em eventos não-controláveis para o
nível SP, que os repassa para o GM.
3.3 Implementação do SCM
O SCM composto pelo gerenciador e pelos 3
níveis do CSML é implementado em um processo em
execução na plataforma Linux, desenvolvido na
linguagem C/C++ e sob supervisão do middleware
ROS. Esse processo é então validado através de um
ambiente que simula os demais componentes do
AUV, e que será apresentado na seção 4.
Os modelos abstratos teórico-formais que descrevem
o comportamento do AUV em malha aberta são
representados por 12 autômatos, e correspondem aos
subsistemas ou plantas modulares comentadas na
seção 2.2, compondo o nível SP. Os supervisores
modulares do nível SM correspondem às 57
especificações, pois as mesmas são controláveis, o
que permite usar diretamente a especificação como
um supervisor. De modo a minimizar ou evitar erros
na codificação destes modelos, foi desenvolvido um
parser em C#.Net para tradução automática dos
autômatos, codificados pela ferramenta Supremica
em formato XML, para código C++. Os eventos
controláveis e não-controláveis, definidos no nível de
representação dos autômatos contidos no SP e SM,
são traduzidos para comandos e respostas no nível
SO.
Em uma primeira implementação do GM, visando a
validação da arquitetura proposta, foi utilizada uma
solução mais simples para a heurística de seleção dos
eventos controláveis, baseado em um conjunto de
regras considerando o estado atual da missão e do
veículo e os eventos controláveis habilitados pelo
CSML. Essa base de regras também emprega a
natureza modular dos modelos formais do CSML.
Por exemplo, sempre que a bateria entrar no estado
de nível baixo de energia, ocasião em que um evento
não-controlável é gerado pela planta e enviado ao
SCM, a manobra em curso deve ser finalizada e a
missão cancelada. Contudo, como o CSML somente
impede que uma manobra possa ser iniciada ou
retomada, é necessário que o GM selecione o evento
controlável de finalização de manobra. Da mesma
forma, à medida em que a missão é realizada, o GM
lê a próxima fase com o respectivo ponto destino, e
gera o evento controlável de início de manobra,
desde que esteja habilitado pelo CSML.
Finalmente, o arquivo de missão, no formato texto,
contém as várias fases da missão. Cada fase é
definida pelas coordenadas (x, y, z, , , ) dos
pontos inicial e final da fase; pelo estado de cada um
dos sensores de carga útil (varíavel tipo booleana
contendo true/false para indicar a ação de
ligar/desligar o sensor); pelo tipo de manobra
(navegação, subida, descida e retorno); pela margem
de erro empregada para considerar se o veículo
alcançou ou não uma determinada posição; e pelo
timeout ou tempo máximo para alcançar o ponto final
da fase atual.
4 Ambiente de Simulação
Para validação do SCM baseado no CSML foi
desenvolvido um ambiente distribuído para a
simulação dos demais componentes do AUV, através
do uso do middleware ROS, do software
Matlab/Simulink e de uma interface homem-máquina
(IHM) desenvolvida em Java. A figura 5 apresenta o
ambiente de simulação, em execução na plataforma
Linux, onde é possível observar os principais
componentes do ambiente: dinâmica contínua,
simulada através do software Matlab/Simulink;
dinâmica dirigida a eventos, simulada através da
IHM desenvolvida em linguagem Java; o SCM e os
demais processos ou threads em execução no sistema
operacional Linux e gerenciados pelo ambiente ROS.
4.1 Processos em Execução no Ambiente ROS
O ambiente ROS (robot operating system) é um
middleware e conjunto de ferramentas, bibliotecas e
componentes que permite o desenvolvimento e
execução de aplicações robóticas. Os processos ou
threads desenvolvidos em C/C++ em execução na
plataforma Linux e gerenciados pelo ROS, empregam
mecanismos de comunicação do tipo
publisher/subscriber e cliente/servidor,
disponibilizados pelo próprio ambiente ROS. A
comunicação destes processos com os demais
componentes do ambiente de simulação foi realizada
via sockets TCP/IP. Os processos desenvolvidos para
o ambiente ROS, representados na figura 5, são
apresentados na sequência.
Sistema de Controle de Missão (SCM):
implementação baseada no CSML, já apresentado na
subseção 3.3.
Dados sensoriais (sensor_imu_broadcaster): recebe
os dados de posição e orientação atual do AUV e os
disponibiliza aos demais componentes através da
publicação da mensagem pose.
Navegador (navigator): com base na posição e
orientação atuais e dos objetivos da missão, envia ao
Matlab/Simulink, através da porta TCP/IP 4050, os
valores de referência de posição e orientação (x, y, z,
Anais do XX Congresso Brasileiro de Automática Belo Horizonte, MG, 20 a 24 de Setembro de 2014
4048
Figura 5. Sistema de controle de missão e ambiente de simulação baseado em ROS, Matlab/Simulink e IHM desenvolvida em Java.
, , ) para o ponto final da fase atual da missão. A
comunicação com o SCM é feita via mecanismo
cliente/servidor. Um timeout, configurado no arquivo
de missão, indica o tempo máximo permitido para o
veículo alcançar a posição e orientação desejados,
gerando um erro de execução de manobra no caso do
valor deste timeout ser alcançado. Nesse trabalho,
desconsiderou-se a geração de trajetórias de
referência, assumindo que o veículo deve se deslocar
a velocidade constante até atingir uma determinada
região em torno ao ponto (posição e orientação) final
desejado.
Estado do Sistema e da Missão
(scm_status_broadcaster): envia para a IHM, pela
porta TCP/IP 8000, informações a respeito do estado
do veículo (estado de um sensor ou equipamento,
estado de uma manobra), estado da missão (posição e
orientações atuais), e o estado lógico das várias
plantas locais que representam os diversos
subsistemas e componentes do AUV.
Estado do AUV (auv_status_broacaster): informa
aos demais componentes do ambiente ROS, o estado
dos sensores de carga útil, GPS, câmera, nível de
bateria. Os dados da IHM são recebidos via porta
TCP/IP 7000 e publicados através da mensagem
auv_status.
Eventos gerados manualmente
(controlled_events_simulator): representa os
comandos associados a eventos controláveis,
disponíveis somente no modo manual, recebidos pela
porta TCP/IP 7050.
Além disso, através da posição e orientações
simuladas pelo Matlab/Simulink e publicadas no
tópico pose, é possível visualizar o movimento do
AUV por meio da ferramenta gráfica RVIZ
disponível no ambiente ROS.
4.2 Dinâmica Contínua
O comportamento cinemático e dinâmico do
AUV e o sistema de controle de movimento é
simulado através do software Matlab/Simulink. O
modelo de AUV empregado neste trabalho consiste
no NEROV, cujos parâmetros podem ser encontrados
em (Fjellstad, 1994). Os dados referentes à posição
(x, y, z) e orientação (rotações em torno a esses eixos,
ou , , ) (Fossen, 1994) são enviados ao demais
componentes do ambiente através da porta TCP/IP
5000. Desse modo é possível simular, para o SCM, a
geração de dados típicos dos subsistemas de
localização. O veículo possui 6 graus de liberdade,
sendo empregado um PID para cada posição e
orientação, uma vez que a faixa de velocidade, a
geometria e a disponibilidade e disposição de seus 6
propulsores permite o desacoplamento entre os graus
de liberdade. De modo a simplificar o modelo
contínuo, não foi empregado o controle de
velocidade. As referências (coordenadas x, y, z, , ,
do ponto final desejado) para os controladores PID
são enviados pelo SCM e recebidos pelo
Matlab/Simulink através da porta TCP/IP 5050.
Também foram desenvolvidos 2 parsers com o
objetivo de adequar o formato dos dados e
mensagens trocadas entre os processos em execução
no ROS e o Matlab/Simulink.
Anais do XX Congresso Brasileiro de Automática Belo Horizonte, MG, 20 a 24 de Setembro de 2014
4049
4.3 Dinâmica Dirigida a Eventos
Mediante uma interface homem-máquina (IHM)
desenvolvida em linguagem Java é possível enviar e
receber comandos relacionados com a dinâmica
discreta ou dirigida a eventos do AUV.
Basicamente, através de vários botões, a IHM
permite gerar sinais que representam a ocorrência de
falhas de instrumentação, o nível de bateria
disponível, ações de ligar ou desligar equipamentos e
sensores, e diversas outras ações relacionadas à
execução de manobras.
O modo de operação, manual ou automático, define
quais são os comandos possíveis de serem gerados
pelo ser humano. No modo manual, todos os
comandos estão disponíveis. Porém, no modo
automático, somente os comandos associados à
eventos não-controláveis estão disponíveis, ficando,
neste caso, a cargo do SCM gerar a melhor sequência
de comandos de modo a guiar o veículo conforme o
arquivo de missão. Os comandos relacionados aos
eventos não-controláveis implementados foram: falha
em sensor de carga útil, câmera ou GPS; o nível de
bateria disponível; e a condição do veículo estar na
superfície ou submerso. Por sua vez, os comandos
relacionados à eventos controláveis foram: início,
suspensão, retomada, finalização e reinício de todas
as manobras disponíveis; ações de ligar, desligar e
reinício dos vários equipamentos e sensores do
veículo.
Além disso, a IHM também permite visualizar o
estado lógico dos modelos formais, ou autômatos,
que representam a planta, os estados lógicos dos
eventos não-controláveis e controláveis, bem como o
estado atual da missão e os objetivos ainda não
alcançados pelo veículo. A IHM emprega a porta
TCP/IP 7000 para enviar comandos relacionados aos
eventos não-controláveis para os processos em
execução no ROS; a porta 7050 para enviar
comandos associados aos eventos controláveis; e a
8000 para receber o estado lógico do sistema e da
missão. A figura 6 mostra a IHM com os eventos
não-controláveis situados à esquerda, e os
controláveis à direita. Através dessa interface é
possível gerar eventos não-controláveis que
representam o funcionamento do veículo, bem como
os eventos controláveis quando no modo manual. Na
parte inferior da figura 6, é possível visualizar, à
esquerda, a realização da simulação de uma missão
através da ferramenta gráfica RVIZ, pertencente ao
middleware ROS, e à direita, a mesma missão, em
um gráfico do programa Matlab/Simulink.
5 Simulações
Com o objetivo de mostrar o funcionamento da
arquitetura de CSML, dois cenários de missões em
um lago de reservatório de hidrelétricas são
considerados. No cenário inicial, a missão do AUV
consiste em submergir a uma profundidade específica
Figura 6. Interface homem-máquina (IHM) e ferramentas de
visualização RVIZ e Matlab/Simulink.
e, a partir dessa profundidade, aproximar-se de uma
área para realização de perfil de trajetória para a
aquisição de imagens, ocasião em que a câmera
deverá estar ligada. Ao finalizar a aquisição, o
veículo se aproxima do ponto próximo à segunda
área, para levantamento de dados de temperatura,
condutividade e profundidade, além do levantamento
da topografia do fundo do lago do reservatório. Os
deslocamentos entre as áreas é realizado com a carga
útil desligada, a fim de economizar energia. Ao
finalizar a missão, o veículo retorna ao ponto inicial.
No segundo cenário, a mesma missão do cenário
anterior deve ser realizada pelo AUV, porém
considera-se a ocorrência de falhas de
posicionamento, ocasião em que o SCM deve ser
capaz de suspender a missão, dirigir o veículo à
superfície para correção via GPS, e retornar ao ponto
anterior à suspensão da missão.
No primeiro cenário, a missão é realizada através da
escolha pelo GM daqueles eventos controláveis que
correspondam às fases contidas no arquivo de
missão, e que não violem as especificações de
segurança, definidas pelo CSML. No segundo
cenário, apesar da ocorrência não-determinista de
erros de posicionamento, a missão não é cancelada,
pois a heurística de escolha de caminhos,
implementada pelo GM, permite a seleção de
caminhos alternativos que possibilitem continuar a
missão. Assim, mesmo que tal caminho contenha
passos ou fases não incluídos no arquivo de missão,
como por exemplo, a necessidade de subir à
superfície e correção de erros via GPS, o AUV é
capaz de realizar a missão. Além disso, tais caminhos
também não violam especificações de segurança
devido a ação do CSML. A figura 7 apresenta a
simulação da missão para o segundo cenário.
6 Conclusão
O presente trabalho apresentou uma proposta de
arquitetura para o Sistema de Controle de Missão
(SCM) de um AUV basedo no Controle Supervisório
Anais do XX Congresso Brasileiro de Automática Belo Horizonte, MG, 20 a 24 de Setembro de 2014
4050
Figura 7. Missão com falhas de posicionamento e ajuste via GPS.
Modular Local (CSML), validada por ambiente de
simulação. A modelagem formal dos subsistemas e
componentes do AUV e a obtenção de supervisores
conforme o CSML, permite garantir o atendimento à
requisitos e especificações de operação e segurança
na realização de diversos tipos de missões. O SCM
permite a escolha alternativa de caminhos contidos
no arquivo de missão, possibilitando a realização da
mesma ante a ocorrência não-determinista de
situações como erros e falhas, ao mesmo tempo que
garante que as especificações de segurança sejam
atendidas para qualquer tipo de missão. Além disso, a
geração automática de código permite a tradução
direta dos modelos teórico-formais do CSML para o
sistema embarcado do AUV, reduzindo erros devido
a programação do sistema. Como perspectivas para
continuidade do trabalho citam-se o emprego de
algoritmos de busca em árvore para escolha de
caminhos ótimos pelo gerenciador de missão, e a
própria implementação do SCM em um AUV.
Agradecimentos
Os autores são gratos pelo suporte financeiro
fornecido pela Fundação Parque Tecnológico
ITAIPU (PTI), localizado em Foz do Iguaçu, PR.
Referências Bibliográficas
Akesson, K. (2002), Methods and Tools in
Supervisory Control Theory. Tese de doutorado.
Suécia.
Barrouil, C.; Lemaire, J. (1999), Advanced Real-
Time Mission Management for an AUV.
Symposium on Advanced Mission Management
and System Integration Technologies for
Improved Tactical Operations. Florença, Itália.
Battistella, S.; Queiroz, M. H., Santos, C. H. F.
(2012), Modelagem e Síntese de Supervisores
para Controle de Missão de AUVs atuando em
Lagos de Barragens de Hidrelétricas baseado na
Teoria de Controle Supervisório. XIX Congresso
Brasileiro de Automática. Campina Grande, PB,
Brasil. p. 1870-1877.
Bian, X.; Chen, T.; Yan, Z.; Qin, Z. (2009b),
Autonomous Management and Intelligent
Decision for AUV. Proceeding of the IEEE
International Conference on Mechatronics and
Automation. Changhun, China. p. 2101-2106.
Bhattacharyya, S.; Kumar, R.; Tangirala, S.;
O’Connor, M.; Holloway, L. E. (2005), Hybrid-
Model Based Hierarchical Mission Control
Architecture for Autonomous Underwater
Vehicles. American Control Conference.
Portland, EUA. p. 668-673.
Christensen, H. I.; Pirjanian, P. (1997), Theorical
Methods for Planning and Control in Mobile
Robotics. First International Conference on
Knowledge-Based Intelligent Eletronics
Systems. Adelaide, Austrália. p. 81-86. 1997.
Dias, P. S.; Gomes, R. M. F.; Pinto, J.; Gonçalves, G.
M.; Sousa, J. B.; Pereira, F. L. (2006), Mission
Planning and Specification in the Neptus
Framework. Proceedings of the IEEE
International Conference on Robotics and
Automation. Orlando, Flórida, EUA. p. 3220-
3225.
Fjellstad, O. E. (1994), Control of Unmanned
Underwater Vehicles in Six Degrees of Freedom:
A Quaternion Feedback Aproach. Tese de
doutorado. Noruega.
Fossen, T. I. (1994), Guidance and Control of Ocean
Vehicles. Ed. John Wiley & Sons.
Palomeras, N.; Ridao, P.; Carreras, M.; Silvestre, C.
(2009), Using Petri Nets to Specify and Execute
Missions for Autonomous Underwater Vehicles.
The IEEE/RSJ International Conference on
Intelligent Robots and Systems. St. Louis, EUA.
p. 4439-4444.
Queiroz, M. H.; Cury, J. E. R. (2002), Synthesis and
Implementation of Local Modular Supervisory
Control for a Manufacturing Cell. 6th
International Workshop on Discrete Event
Systems. Espanha.
Ramadge, P. J. G.; Wonham, W. M. (1989), The
Control of Discrete Event Systems. Proceedings
of the IEEE, Vol. 77. N. 1. p. 81-98.
ROS. Robot Operation System. Disponível em:
<http://wiki.ros.org>. Acessado em janeiro 2014.
Valavanis, K. P.; Matijasevic, M.; Kolluru, R.
Demetriou, G. A. (1997), Control Architecture
for Autonomous Underwater Vehicles. IEEE
Control System. p. 48-64.
Xiang, X.; Xu, G.; Zhang, Q.; Xiao, Z.; Huang, X.
(2007), Coordinated Control for Multi-AUV
Systems based on Hybrid Automata. Proceedings
of the 2007 IEEE International Conference on
Robotics and Biomimetics. Sanya, China. p.
2121-2126.
Xu, H.; Zhang, Y.; Feng, X. (2004), Discrete
Hierarquical Supervisory Control for Automous
Underwater Vehicle. International Symposium
on Underwater Techonology. p. 417-421.
Anais do XX Congresso Brasileiro de Automática Belo Horizonte, MG, 20 a 24 de Setembro de 2014
4051