Embed Size (px)
Citation preview
PROGRAMAÇÃO DE INTERFACES GRÁFICAS E
COMUNICAÇÃO EM REDE APLICADA A
SIMULADORES DE EMBARCAÇÕES
Luiz Felipe de Sousa Léo
Projeto de Graduação apresentado ao Curso de
Engenharia Eletrônica e de Computação da Escola
Politécnica, Universidade Federal do Rio de
Janeiro, como parte dos requisitos necessários à
obtenção do título de Engenheiro.
Orientadores: Flávio Luis de Mello
Heraldo Luis Silveira de Almeida
Rio de Janeiro
Fevereiro de 2019
ii
iii
Declaração de Autoria e de Direitos
Eu, Luiz Felipe de Sousa Léo CPF 159.089.277-16 autor da monografia Programação
de interfaces gráficas e comunicação em rede aplicada a simuladores de embarcações,
subscrevo para os devidos fins, as seguintes informações:
1. O autor declara que o trabalho apresentado na disciplina de Projeto de
Graduação da Escola Politécnica da UFRJ é de sua autoria, sendo original em
forma e conteúdo.
2. Excetuam-se do item 1. Eventuais transcrições de texto, figuras, tabelas,
conceitos e ideias, que identifiquem claramente a fonte original, explicitando as
autorizações obtidas dos respectivos proprietários, quando necessárias.
3. O autor permite que a UFRJ, por um prazo indeterminado, efetue em qualquer
mídia de divulgação, a publicação do trabalho acadêmico em sua totalidade, ou
em parte. Essa autorização não envolve ônus de qualquer natureza à UFRJ, ou
aos seus representantes.
4. O autor pode, excepcionalmente, encaminhar à Comissão de Projeto de
Graduação, a não divulgação do material, por um prazo máximo de 01 (um) ano,
improrrogável, a contar da data de defesa, desde que o pedido seja justificado, e
solicitado antecipadamente, por escrito, à Congregação da Escola Politécnica.
5. O autor declara, ainda, ter a capacidade jurídica para a prática do presente ato,
assim como ter conhecimento do teor da presente Declaração, estando ciente das
sanções e punições legais, no que tange a cópia parcial, ou total, de obra
intelectual, o que se configura como violação do direito autoral previsto no
Código Penal Brasileiro no art.184 e art.299, bem como na Lei 9.610.
6. O autor é o único responsável pelo conteúdo apresentado nos trabalhos
acadêmicos publicados, não cabendo à UFRJ, aos seus representantes, ou ao (s)
orientador (es), qualquer responsabilização/ indenização nesse sentido.
7. Por ser verdade, firmo a presente declaração.
_________________________________________
Luiz Felipe de Sousa Léo
iv
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
Escola Politécnica – Departamento de Eletrônica e de Computação
Centro de Tecnologia, bloco H, sala H-217, Cidade Universitária
Rio de Janeiro – RJ CEP 21949-900
Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que
poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar
qualquer forma de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre
bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja
ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem
finalidade comercial e que seja feita a referência bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es).
v
AGRADECIMENTO
Gostaria de agradecer primeiramente à minha família por todo apoio e por tornar
possível a realização deste trabalho, e um agradecimento geral a todos os professores da
eletrônica da UFRJ por em grande maioria serem excepcionais e se dedicarem e se
preocuparem com a aprendizagem dos alunos.
Também gostaria de agradecer ao LabOceano pela oportunidade de estagiar e
desenvolver esse grande projeto que é o simulador e deu origem a este trabalho, em
especial ao Paulo Martins e Vinícius Vileti por todo apoio e ensinamentos, além do
desenvolvimento da parte gráfica e visual do simulador e da simulação matemática,
respectivamente.
Por fim agradecer meus amigos que me acompanharam ao longo de toda essa
jornada e passaram junto comigo por muitos altos e baixos, porém sempre seguindo em
frente e alvejando este momento.
vi
RESUMO
O presente projeto apresenta a viabilidade e as dificuldades teóricas e práticas
para a construção de um software simulador de embarcações. Os modelos escolhidos
para serem implementados foram as embarcações AHTS (Anchor Handling Tug
Supply), Porta Contentor e Rebocador (Tug Boat), muito utilizadas em diversos portos
do mundo, visando assim um maior espectro de emprego do software. A plataforma
Unity foi escolhida para ser utilizada no desenvolvimento do software devido a sua
facilidade de implementação e quantidade de conteúdo disponível, além de ser uma
plataforma gratuita. Ao final do projeto é mostrado como obter um software para
diversas aplicações, além de uma base para aplicações futuras e atualizações, gerando
assim como resultado um modelo mais dinâmico e maleável, servindo também como
base para outros estudos.
Palavras-Chave: Simulador, embarcações, Unity, AHTS, TUG, Contentor,Servidor.
vi
i
ABSTRACT
This project presents the feasibility and the theoretical and practical difficulties for the
construction of a ship simulator software. The chosen models to be implemented were
the AHTS (Anchor Handling TugSupply), Container Port and Tugboat vessels,
commonly used in several ports around the world, aiming at a wider range of software
use. The Unity platform was chosen to be used in software development because of its
ease of implementation and the amount of available content, as well as being a free
platform. At the end of the project it is shown how to obtain software for various
applications, as well as a basis for future applications and updates, thus resulting in a
more dynamic and malleable model, also serving as a basis for other studies.
Keywords: Simulator, vessels, Unity, AHTS, TUG, Container, Server.
vi
ii
SIGLAS
AHTS - Anchor handling tug supply
AIS – Sistema de Identificação automática
CCTV – Circuito fechado de televisão
COPPE – Instituto Alberto Luiz Coimbra de Pós-Graduação e Pesquisa em Engenharia
DC – Corrente Direta
FPS – Frames por segundo
ID – Identificador
IFSP – Instituto Federal de São Paulo
IP- Protocolo de Internet
I/O – Entrada/Saída
LabOceano – Laboratório de Tecnologia Oceânica da COPPE
LabOSIM – Simulador de embarcações do LabOceano
LED – Diodo emissor de luz
PWM – Modulação de largura de pulso
ROV – Veiculo Submarino Operado Remotamente
TCP/IP- Conjunto de protocolos de computadores em rede
TRANSAS – Empresa desenvolvedoras de simuladores
TUG - Rebocador
UFRJ – Universidade Federal do Rio de Janeiro
USB – Universal Serial Bus
V - Volts
XML- Extensão de arquivo
ix
Sumário
1 Introdução 1
1.1 - Tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 - Delimitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 - Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 - Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 - Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.6 - Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Fundamentação Teórica 4
2.1 - Simuladores de Embarcações . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 - LabOSIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 - Motores Gráficos e Ferramentas de desenvolvimento . . . . . 7
2.3.1 - Unreal Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2 - Quest3D Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3 - Unity Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.4 - Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 – Middleware entre Hardware e Software . . . . . . . . . . . . . . . .
7
9
9
11
12
2.4.1 – Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2 – Wago . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5 – Computação Científica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
13
16
x
3 Desenvolvimento do Simulador 18
3.1 – Hardware e conexões eletrônicas . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 – Sistema Wago . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 – Conexões com Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.3 – Hardware do Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 – Software do Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 – Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1.1 – Scripts de Inicialização . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1.2 – Plug-ins do Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1.4 – Scripts de comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 – Visualizadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2.1 – Programação dos visualizadores . . . . . . . . . . . . . . . . . . . . . .
3.2.2.2 – Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2.3 – Sincronizações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2.4 – Efeitos Visuais e Sonoros . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3 – Menu do Operador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3.1 – Painel de Controle de Clima e Oceano . . . . . . . . . . . . . . . . .
3.2.3.2 – Visualização da Cena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3.3 – Informações das Embarcações . . . . . . . . . . . . . . . . . . . . . . .
3.2.3.4 – Controle e geração de erros . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3.5 – Sistema CCTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4 – Sistemas de Navegação e Localização . . . . . . . . . . . . . . . . . . .
3.2.4.1 – Radar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.4.2 – Painel AIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.5 – Sistemas de Controle e Monitoramento . . . . . . . . . . . . . . . . . .
3.2.5.1 – Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.5.2 – Painéis Touch-Screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.6 – CCTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
19
20
21
24
25
26
29
38
43
44
45
47
49
52
53
57
61
63
64
64
65
71
73
74
77
81
xi
4 Conclusões 85
5 Bibliografia 88
xi
i
Lista de Figuras
2.1 –Simulador Transas Rebocador para recolhimento de óleo. . . . . . . . . . . . . . . . 4
2.2 –Simulador Transas de Aproamento de um Porta Contentor . . . . . . . . . . . . . . 5
2.3 –Uma das primeiras versões do LabOSim na simulação de derramamento de
óleo utilizando a engine Quest3D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.4 – Última versão usada como base antes das modificações realizadas no
contexto deste trabalho. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.5 – Uso do Kismet para programar uma luz acionada por um colisor sem a
necessidade de códigos de programação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.6 –Interface Unreal Engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.7 – Interface Quest3D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.8 – Interface inicial do Unity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.9 – Unity Asset Store . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.10 – Interface Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.11 – Arduino Uno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.12 – Arduino Mega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.13 – Arduino Nano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.14 – Interface de programação Arduino. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.15 – Esquema ilustrado do Wago Supply Module retirado de seu manual de
instruções. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.16 – Esquema ilustrado do Wago Internal Data Bus Extension Coupler Module
retirado de seu manual de instruções. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.17 – Esquema ilustrado do Wago 4-Channel Analog Input Module retirado de
seu manual de instruções. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.18 – Esquema ilustrado do Wago End Module retirado de seu manual de
instruções. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.19 – LabOSim no Simulink. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.20 – Interface externa de um bloco. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
xi
ii
3.1 – Esquemático da arquitetura do simulador. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 – Sistema Wago da sala de simulação 1 – Fonte 24V, sensores analógicos e saídas
de tensão WAGO de 5V e 10V. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 – Sala de Simulação 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 – Sala de Simuação 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 – Monitores Touch-Screen de Controle da embarcação. . . . . . . . . . . . . . . . . .
3.6 – Manetes de controle da Sala 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7 – Manetes de controle da Sala 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.8 – Mostrador Superior da Sala 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.9 – Painel de Controle CCTV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.10 – Conexões entre programas e usuários. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.11 – Esquema de comunicação entre servidor e demais programas do
simulador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.12 – Definições de rede do simulador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.13 – Qualidades disponíveis para resolução do oceano. . . . . . . . . . . . . . . . . . . .
3.14 – Exemplo de oceano pré-definido. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.15 – Escala de Beaufort de intensidade dos ventos. . . . . . . . . . . . . . . . . . . . . . . .
3.16 – Área aproximada de interpolação do Oceano. . . . . . . . . . . . . . . . . . . . . . . .
3.17 – UniStorm configuração do Player e Câmera. . . . . . . . . . . . . . . . . . . . . . . . .
3.18 – UniStorm configuração de tempo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.19 – UniStorm configuração de Clima. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.20 – UniStorm configurações de atmosfera. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.21 – Mapbox – Script de Configuração. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.22 – Variáveis de rede do Script de Passagem de parâmetros. . . . . . . . . . . . . . .
3.23 – Script de passagem de variáveis para os painéis touch. . . . . . . . . . . . . . . . .
3.24 – Parâmetros do Script Gerenciador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.25 – Player referente ao painel de controle do operador. . . . . . . . . . . . . . . . . . . .
3.26 - Imagem retirada do manual do Unity Cluster Package que descreve seu
funcionamento básico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.27 - Imagem retirada do manual do Unity Cluster Package que descreve a
configuração do seu arquivo em XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.28 – Imagem retirada do manual do Unity Cluster Package que exemplifica o
efeito paralaxe em que a imagem se estica conforme de aproxima dos cantos da
tela conforme a configuração da Figura 3.29. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.29 – Imagem retirada do manual do Unity Cluster Package que exemplifica as
19
21
21
22
22
23
23
23
24
25
28
29
30
31
32
33
34
35
36
37
39
40
41
43
45
45
46
xi
v
configurações das telas em relação ao seu controle. . . . . . . . . . . . . . . . . . . . . . . . .
3.30 – Visibilidade às 7 horas da manhã. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.31 – Visibilidade às 13 horas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.32 – Efeitos de chuva no vidro da tela. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.33 – Colisor do efeito sonoro para variação do som 3D. . . . . . . . . . . . . . . . . . . .
3.34 – Sistema do Menu do Operador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.35 – Painel de controle de clima e oceano do Menu do Operador. . . . . . . . . . . .
3.36 – Controle de oceano do Menu do Operador. . . . . . . . . . . . . . . . . . . . . . . . . .
3.37 – Cena da Carta Náutica do Menu do Operador. . . . . . . . . . . . . . . . . . . . . . .
3.38 – Painel de exibição dos navios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.39 – Exibição de conexões. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.40 – Tela de visualização no modo “Câmera Livre” . . . . . . . . . . . . . . . . . . . . . .
3.41 – Visão traseira (Popa) da embarcação TUG. . . . . . . . . . . . . . . . . . . . . . . . . .
3.42 – Visão dianteira (Proa) da embarcação TUG. . . . . . . . . . . . . . . . . . . . . . . . .
3.43 - Visão dianteira do Porta-Container. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.44 – Tela de visualização no modo “Tela dividida” . . . . . . . . . . . . . . . . . . . . . .
3.45 – Variáveis “Viewport Rect” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.46 – Exemplo de posicionamento de câmera na tela. . . . . . . . . . . . . . . . . . . . . .
3.47 – Painel de informações das embarcações. . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.48 – Exibição de velocidades relativas do navio. . . . . . . . . . . . . . . . . . . . . . . . .
3.49 – Painel de geração de erro do menu do operador. . . . . . . . . . . . . . . . . . . . . .
3.50 – Sistema de CCTV do operador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.51 – Ferramenta de geração de terreno do Unity. . . . . . . . . . . . . . . . . . . . . . . . .
3.52 – Normalmap utilizado no terreno do Radar. . . . . . . . . . . . . . . . . . . . . . . . . .
3.53 – Navios em textura verde. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.54 – Projeção de câmera secundária sobre primaria. . . . . . . . . . . . . . . . . . . . . . .
3.55 – Imagem do radar sem os efeitos de câmera. . . . . . . . . . . . . . . . . . . . . . . . .
3.56 – Imagem do radar com os efeitos de câmera. . . . . . . . . . . . . . . . . . . . . . . . .
3.57 – Resultado final com efeito de iluminação. . . . . . . . . . . . . . . . . . . . . . . . . .
3.58 – Botões, informações e trajetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.59 – Painel AIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.60 – Exemplo de movimentação irregular do navio. . . . . . . . . . . . . . . . . . . . . . .
3.61 – Console da embarcação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
49
50
50
51
52
53
54
55
56
56
58
59
59
59
60
60
61
62
63
63
64
65
66
66
67
68
68
69
70
71
72
74
x
v
3.62 – Rotina de calibragem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.63 – Seção de erros nos motores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.64 – Seção de controle dos motores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.65 – Seção de sinais sonoros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.66 – Seção de informações da embarcação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.67 – Seção de informações gerais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.68 - Seção de Piloto Automático. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.69 – Painéis touchs exibido nos monitores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.70 – Sistema CCTV Sala 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.71 – Sistemas CCTV Sala 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.72 – Disposição de câmeras no Porta-Container. . . . . . . . . . . . . . . . . . . . . . . . .
3.73 – Disposição de câmeras no TUG (Rebocador) . . . . . . . . . . . . . . . . . . . . . . .
3.74 – Painel Físico de controle do CCTV Sala 2. . . . . . . . . . . . . . . . . . . . . . . . . .
3.75 – Painel físico de controle CCTV Sala 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
77
78
78
79
79
80
80
81
81
82
82
83
84
x
vi
Lista de Tabelas
3.1 – Parâmetros de rede e suas definições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 – Variáveis de controle do objeto Player. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 – Frequências de cortes dos sons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 – Scripts de controle do Menu do Operador. . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 – Botões do Radar e suas funções. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6 – Informações do painel AIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
44
53
59
73
75
1
Capítulo 1
Introdução
1.1 – Tema
O tema do trabalho é a aplicação de técnicas de computação gráfica para
exibição de simulações de embarcações, e as forças externas que agem sobre ela. Neste
sentido, o problema a ser resolvido é analisar a viabilidade em se criar uma simulação
gráfica de embarcações levando em consideração as forças de chuva, vento e correnteza
que agem sobre o barco, e controlá-lo através de consoles físicos reais.
1.2 – Delimitação
O objeto de estudo está limitado à programação de visualização do simulador e
construção de painéis e sua comunicação, de embarcações pré-modeladas, que poderão
ser estendidas futuramente a outros modelos, analisadas em algumas condições
climáticas pré-definidas, além da realização e leitura da parte eletrônica de seus
controles e comandos. O modelo matemático usado para cálculos das forças
hidrodinâmicas será externo ao projeto, cedido pelo laboratório LabOceano
(Laboratório de Tecnologia Oceânica da COPPE) na forma de um programa no
Simulink (Matlab). No LabOceano, o autor deste trabalho é responsável pela
programação do simulador que há no laboratório, tomando decisões sobre que tipo de
plataforma é utilizada, como são feitos seus controles e sua interface, chegando à
escolha do melhor método a ser utilizado, os modelos tridimensionais e imagens
utilizadas para construções dos painéis são desenvolvidas pelo Designer Gráfico do
laboratório.
2
1.3 – Justificativa
O treinamento de novos controladores em diversas áreas está cada dia mais
complexo, e cada vez mais há a necessidade de métodos tecnológicos para a facilitação
do mesmo. A criação de simuladores é um dos métodos mais eficazes para a realização
de treinamentos e testes sem que haja riscos reais aos equipamentos, minimizando assim
o risco de acidentes. Tais simuladores precisam trazer ambientes cada vez mais
próximos à realidade para que sejam executados treinamentos cada vez mais reais.
Neste sentido, o presente projeto é uma complementação de estudos de controle
de embarcações, trazendo sua exibição tridimensional através da computação gráfica e
da realidade virtual, aumentando assim o realismo de simulações e tornando seu
treinamento mais eficaz.
Os simuladores existentes atuais são bastante limitados e precisam de
atualizações gráficas constantes, além da necessidade de uma nova versão a cada novo
componente de simulação adicionado. Por esta razão, torna-se interessante preparar um
simulador com gráficos de última geração e pronto para receber melhorias e novos
modelos de simulações sem a necessidade de que a cada atualização seja refeito todo o
processo.
1.4 – Objetivo
O objetivo geral é, então, a criação de um modelo visual capaz de receber
parâmetros de embarcações e através de uma seleção própria, gerar uma visualização
tridimensional e em realidade virtual da construção física do modelo, exibindo assim
suas reações a comandos e manobras, em ambiente seguro, para realização de
treinamentos e testes de manobrabilidade e qualidade. Desta forma, temos como
objetivo específico: (1) modelar o ambiente de simulação; (2) aplicar nesse modelo
controles das simulações de chuva, vento e correnteza, e; (3) criar diversos painéis de
controle e exibição de forma a tornar a sala de simulação o mais próximo possível de
um passadiço real de embarcação.
3
1.5 – Metodologia
Este trabalho utilizará técnicas de computação gráfica para a criação de modelos
tridimensionais de embarcações e modelos ambientais externos que irão gerar forças
externas ao controle do modelo, trazendo assim mais realidade para a simulação, e uma
forma de visualização interna para que o controlador se sinta dentro do próprio modelo.
A utilização de realidade virtual aumenta a imersão do usuário na simulação,
melhorando assim a qualidade de treinamentos e testes, permitindo ao usuário uma
melhor visualização com ângulos de observação totalmente livres. Assim, espera-se
adicionar um grau extra de liberdade de movimentação de câmera, possibilitando novas
perspectivas de análise em testes de equipamentos e manobras.
Desta forma, através de ambientes interativos baseados nos aspectos reais de
embarcações, as tomadas de decisões do usuário, assistidas por radares e computadores
de bordo semelhantes ao da realidade, serão observadas por profissionais externos a
simulação. Isto permite avaliar o desempenho do condutor ou do modelo a ser testado,
de forma dinâmica e em ângulos pré-selecionados, enquanto o usuário principal ficará
imerso na realidade virtual e observará apenas o que poderia ser visto de dentro da
cabine, não tendo noção, assim, de possíveis falhas ou erros externos causados por seus
atos.
Após uma pesquisa, foi decidido pela utilização da plataforma Unity como
motor gráfico do projeto, devido a recentes atualizações que garantem suporte à
realidade virtual, além de sua ampla compatibilidade com diversos programas de
modelagem e sua liberdade de alterações na base do projeto, além de ser uma
plataforma gratuita.
O êxito deste trabalho está centrado em gerar um ambiente imersivo de
simulações onde o usuário possa se sentir totalmente dentro da simulação, para que todo
seu treinamento seja posto à prova em uma situação mais realista possível, trazendo
assim todo cálculo hidrodinâmico e pesquisas na área para a “realidade” do usuário.
4
1.6 – Descrição
No capítulo 2 será apresentada a fundamentação teórica utilizada para o
desenvolvimento do simulador e outras opções de plataformas que foram testadas ou
utilizadas em algum momento antes da decisão final sobre qual utilizar.
O capítulo 3 apresenta como o simulador e todos os painéis desenvolvidos, e detalha
cada passo e os problemas envolvidos em sua implementação, além das soluções
obtidas.
Por fim, a conclusão é apresentada no capítulo 4, comentando sobre os
resultados obtidos e as possíveis ações futuras, assim como as dificuldades encontradas
em cada etapa.
5
Capítulo 2
Fundamentação Teórica
2.1 – Simuladores de embarcações
Atualmente existem diversos tipos de simuladores de embarcações no mercado,
que variam desde pequenos terminais com controle simples até grandes estações de
simulação que reproduzem até mesmo o balanço da embarcação. Os simuladores, em
sua maioria, são criados para fins específicos, e toda sua estrutura e comandos são
voltados para aquele fim, por exemplo, em uma simulação de derramamento de óleo são
utilizados duas ou mais embarcações, radares, comandos de guindaste, boia, Skimmer
(Figura 2.1).
Em uma simulação de aproamento em porto, são utilizados objetos de interesse
como sistema de câmeras, carta náutica com detalhamento de profundidade das áreas,
controle de posicionamento dinâmico, entre outras funções (Figura 2.2).
Há também simuladores que reproduzem possíveis defeitos nas embarcações,
comprometendo assim sua manobrabilidade, para que sejam realizados procedimentos
de segurança ou testes de aptidão diante de algum tipo de desastre.
Alguns bons exemplos desses tipos de simuladores são os simuladores da
TRANSAS, uma das maiores empresas do mundo no ramo, que oferece serviços desde
simuladores prontos, até novas simulações para determinada demanda específica,
fazendo com que sua construção seja sob medida para determinada aplicação.
Figura 2.1: Simulador Transas Rebocador para recolhimento de óleo
6
Figura 2.2: Simulador Transas de Aproamento de um Porta Contentor
Existem ainda os simuladores utilizados em diversas aplicações, que exigem
alterações de acordo com a necessidade e esteja sempre cumprindo os requisitos da
simulação desejada. Um desses simuladores é utilizado pela Marinha do Brasil, porém
por ser projeto interno não é de acesso aberto ao público geral.
2.2 –LabOSim
LabOSim é o simulador de embarcações desenvolvido totalmente no
LabOceano, e vem evoluindo ao longo do tempo para se manter utilizável e
acompanhando tudo que há de tecnologia de ponta na área de simulação. Inicialmente o
LabOSim era desenvolvido no Quest3D, e tinha sua parte de cálculos matemáticos
executadas através de um programa escrito em C++. Com o avanço tecnológico e de
computação gráfica, o Quest3D acabou ficando obsoleto, tendo sido realizada sua troca
para a nova engine gráfica, o Unity, onde haveria muito mais suporte e qualidade na
simulação para alcançar diversos objetivos.
7
Figura 2.3: Uma das primeiras versões do LabOSim na simulação de derramamento de óleo
utilizando a engine Quest3D
Inicialmente o programa do simulador utilizava arquivos de biblioteca .dll para
realizar sua comunicação com o servidor, um programa escrito em C e exibido em uma
janela de prompt de comando simples do Windows, onde eram realizados todos os
cálculos físicos e hidrodinâmicos. Estes cálculos eram enviados para o simulador,
juntamente com as informações de posições e ângulos de cada navio simulado, porém
dessa forma as alterações eram muito limitadas, requerendo acesso a arquivos de texto
que controlavam as condições iniciais do navio, suas características físicas entre outras,
fazendo assim com que as alterações no simulador fossem extremamente complicadas e
também limitando seu uso, uma vez que para cada tela era necessário um programa de
visualização que se comunicasse com o servidor e um arquivo de texto que indicaria
qual era a tela e a posição de sua câmera, para que, em conjunto com as outras,
formassem a visualização do simulador. Entretanto, posicionar as câmeras era um
trabalho extremamente complicado e que demandava muito tempo a cada pequena
alteração que era realizada no simulador.
O avanço das pesquisas no LabOceano resultou em uma melhora significativa na
qualidade do simulador. Contudo, a dependência do programa do servidor e de arquivos
para sua comunicação acabaram atrasando um pouco a sua evolução, até que foi
decidido pela mudança de plataforma, passando por diversas etapas de evolução.
8
Figura 2.4: Última versão usada como base antes das modificações realizadas no contexto deste
trabalho.
Com todo esse histórico de evolução no repertório, além de exemplos de
modelos de outros simuladores, foram utilizadas técnicas de programação e computação
gráfica para melhorar a qualidade do simulador, sendo esse o tema do trabalho.
2.3 – Motores Gráficos e Ferramentas de Desenvolvimento
Atualmente existem no mercado diversos motores gráficos para facilitar a
criação de plataformas dos mais diversos usos, dentre elas, os simuladores. A maioria
destas plataformas oferece uma versão limitada gratuita para desenvolvedores que
gerem receita até um valor fixo estipulado pelas empresas responsáveis pelo motor
gráfico e após este valor uma taxa é cobrada sobre o lucro obtido.
Nas subseções a seguir, são enumerados alguns motores gráficos gratuitos, entre
outros componentes utilizados como ferramenta para o desenvolvimento de
simuladores.
2.3.1 – Unreal Engine
A plataforma Unreal Engine, atualmente na sua 4ª versão, oferece diversas
ferramentas para o desenvolvimento de aplicações e jogos, além de suporte para
desenvolvimento em realidade virtual, ou para diversas plataformas como celulares,
tablets e outros sistemas operacionais. A plataforma é gratuita para desenvolvimento e
9
pesquisa, porém ao gerar receita, deverá ser pago a sua desenvolvedora, Epic Games,
5% do total de lucro.
Uma das principais ferramentas e também considerada um dos grandes
diferenciais da Unreal Engine é a interface “Kismet Visual Scripting”. Ela possibilita ao
desenvolvedor utilizar blocos de comandos pré-programados para criar toda a
programação do jogo de forma visual e simplificada, ou dividir sua equipe em uma
parte que construirá blocos genéricos enquanto outra parte apenas faz a ligação entre os
blocos “programando” assim todo o aplicativo de forma simples sem grandes
conhecimentos prévios requeridos (Figura 2.5).
Figura 2.5: Uso do Kismet para programar uma luz acionada por um colisor sem a necessidade
de códigos de programação
A linguagem utilizada tanto nos blocos do Kismet quanto nos demais scripts da
Unreal Engine é a C++ e a interface de programação conta com visualizações
personalizadas de cena, importação de materiais e objetos das mais diversas plataformas
e sua própria ferramenta de criação de terrenos.
10
Figura 2.6: Interface Unreal Engine
2.3.2 – Quest3D Engine
O Quest3D Engine atualmente encontra-se na versão 4.0, porém foi o primeiro
motor utilizado para representar graficamente o simulador LabOSim. Na época em que
foi utilizado, ele e os demais motores citados no trabalho eram todos pagos, tendo sido
escolhido como melhor custo x benefício na época.
Embora apresentasse a possibilidade de uma interface parecida com o Kismet do
Unreal (Figura 2.7), sua utilização era um pouco mais complicada, também programada
em C++, porém com qualidade gráfica muito inferior aos demais motores.
Um bom exemplo de sua qualidade limitada é a Figura 2.3 da primeira versão do
simulador já em 2014, com formato sem muitos detalhes e mar plano.
Figura 2.7: Interface Quest3D
Atualmente não há mais informações disponíveis sobre esta engine, pois
continua sendo uma engine paga, obtida sob a solicitação de orçamento.
2.3.3 – Unity Engine
Sendo a atual interface utilizada pelo simulador LabOSim, o Unity Engine se
encontra na sua versão 2018.2, e conta com 3 formas de utilização: (1)Versão Pessoal,
gratuita até um lucro de $100.000,00 , (2) Versão Plus atualmente R$80,00 por mês por
máquina para um lucro de até $200.000,00 e (3) Versão Pro custando R$ 400,00 por
11
mês por máquina para lucro ilimitado e dando total propriedade do Software criado
nessa versão para o desenvolvedor.
Ao contrário das plataformas citadas anteriormente, o Unity não possui uma
forma de Visual Scripting simplificado, deixando toda sua programação realizada
através de scripts na linguagem C# (C-Sharp). Contudo, conta com uma interatividade
muito boa entre sua interface e seus scripts, facilitando assim bastante a vida do
programador (Figura 2.8).
A interface também conta com suporte a diversas plataformas e fácil importação
de arquivos de outros programas, sendo assim uma das favoritas entre desenvolvedores
independentes.
Outro grande diferencial do Unity é a possibilidade de se obter diversos itens e
assets de suporte de forma gratuita na Unity Asset Store (Figura 2.9), ou realizar a
compra de plug-ins para diversos fins de forma fácil e rápida.
Figura 2.8: Interface inicial do Unity
12
Figura 2.9: Unity Asset Store
2.3.4 – Processing
Processing é uma plataforma gratuita de programação baseada em Java. Sua
interface simplificada e de fácil aprendizagem faz com que a ferramenta se torne uma
das melhores opções gratuitas para visualização de dados e programação de interfaces
simples.
A linguagem também conta com diversas bibliotecas desenvolvidas por usuários
ao longo do mundo de forma “open source” e compartilhadas para que facilmente sejam
encontradas soluções de diversos problemas em comum em diversas áreas.
Alguns exemplos dessas bibliotecas estão ligados ao uso de Hardwares como
Webcams, Sensores, Kinect, controles, entre outros, para desenvolvimento de interfaces
gráficas para automação e, principalmente, projetos artísticos iterativos utilizando a
plataforma Arduino.
13
Figura 2.10: Interface Processing
2.4 –Middleware de hardware e software
2.4.1 - Arduino
A plataforma Arduino é hoje uma das mais utilizadas para pesquisa e projetos
independentes, devido à sua facilidade de aprendizagem em relação a maioria dos
outros micros controladores.
Com a enorme quantidade de desenvolvedores, é muito fácil achar bibliotecas
prontas para as mais diversas áreas de atuação, criando assim uma rede de comunicação
entre o Arduino e a grande maioria de hardwares utilizados em pesquisa atualmente.
Existem diversos modelos e versões de Arduíno, que variam seu tamanho,
memória interna e capacidade de processamento. Os mais comuns dentre eles são:
Arduino Uno (Figura 2.11), considerado o Arduino padrão, Arduino Mega (Figura
2.12), uma versão com mais memória, processamento e portas I/O do Arduino Uno, e
Arduino Nano (Figura 2.13), uma versão simplificada e menor utilizada para ser
14
acoplada em pequenos espaços, quando se pode abrir mão de capacidade de
processamento para ganhar espaço físico.
Figura 2.11: Arduino Uno
Figura 2.12: Arduino Mega
Figura 2.13: Arduino Nano
Além do hardware do micro controlador, a plataforma também conta com um
software de desenvolvimento para programar o mesmo (Figura 2.14), tornando assim
muito rápida e prática a programação de uma unidade.
15
Figura 2.14: Interface de programação Arduino
2.4.2 – Wago
A plataforma Wago é muito utilizada, principalmente em automação industrial,
com sua principal característica sendo sua robustez. Embora tenha um custo muito
elevado quando comparado ao Arduino, a plataforma apresenta algumas diferenças
significativas, como uma maior resistência a mudanças de temperatura, um intervalo
maior de tensões de operação, e sua arquitetura modular, onde a quantidade de entradas
e saídas é definida de acordo com a necessidade do usuário.
Em seu escopo de atendimento, a plataforma atende às mais diversas áreas de
automação. Porém, no caso citado, o interesse está apenas na parte de leitura de dados e
alimentação. Com isso, utilizaremos apenas 4 tipos de módulos: Wago 750-623 –
Supply Module, Wago 750-628 – Internal Data Bus Extension Coupler Module, Wago
750-468 – 4-Channel Analog Input Module e Wago 750-600 - End Module.
O módulo Wago 750-623 – Supply Module (Figura 2.15) é responsável por
fornecer as tensões necessárias para alimentar o sistema, tendo como opções as saídas
de 5, 8, 10, 12 e 15 Volts, configuradas através de chaves em sua lateral, e conta com 2
opções de saída de tensão (iguais), saída 0V, aterramento e uma entrada de alimentação
de 24V.
16
Figura 2.15: Esquema ilustrado do Wago Supply Module retirado de seu manual de instruções.
O módulo anterior se conecta ao Wago 750-628 – Internal Data Bus Extension
Coupler Module (Figura 2.16), responsável por realizar a comunicação entre a
plataforma e a rede ou entre duas ou mais plataformas ligadas em série, utilizado para
reunir as informações de leitura dos módulos ligados a ele e disponibilizá-las através de
uma porta RJ-45 para ser acessado pelo seu IP pré-definido, deixando assim os dados
disponíveis para qualquer outro dispositivo ligado à rede.
O módulo apresenta uma entrada de alimentação de 24V, chaves de controle
para definição de IP fixo ou IP definido via rede, duas entradas RJ-45, duas saídas de
24V para alimentação de blocos seguintes, duas saídas 0V para o mesmo e duas saídas
ligadas ao aterramento do circuito.
Figura 2.16: Esquema ilustrado do Wago Internal Data Bus Extension Coupler Module retirado
de seu manual de instruções.
17
Outro módulo conectado é o Wago 750-468 – 4Channel Analog Input Module
(Figura 2.17), este módulo é responsável pela leitura analógica de dados, e envia por
comunicação interna para o módulo responsável pela disponibilização de dados na rede.
Ele conta com quatro entradas de tensão analógica, duas saídas para o 0V de
referência e duas saídas para o aterramento.
Após realizada a leitura de 0 a 10V é disponibilizado o valor em Hexadecimal
que varia entre 0000 e FFFF indicando o valor lido através do módulo de rede.
Figura 2.17: Esquema ilustrado do Wago 4-Channel Analog Input Module retirado de seu
manual de instruções.
Por fim ainda há o módulo Wago 750-600 – End Module (Figura 2.18), que indica o
fim da linha e fecha o circuito interno de comunicação, além de isolar a linha de transmissão
entre os módulos (que ficam em sua lateral).
Figura 2.18: Esquema ilustrado do Wago End Module retirado de seu manual de instruções.
2.5 – Computação Científica
18
O Matlab é um software de alto desempenho voltado para computação científica,
realizando análise numérica, cálculo com matrizes, processamento de sinais e
construção de gráficos em um ambiente de uso facilitado onde problemas e soluções são
expressos matematicamente, ao contrário da programação tradicional.
Além do programa principal, o Matlab conta com diversas extensões para áreas
específicas, como a utilizada no simulador LabOSim, o Simulink, que é uma ferramenta
para modelagem, simulação e análise de sistemas dinâmicos através de uma interface de
diagramação gráfica por blocos e bibliotecas customizáveis.
Para utilizá-lo, basta agrupar blocos que podem ser padrões de aplicações que já
vêm no programa, como por exemplo, gerador de sinais, leitores, blocos integradores
entre outros, ou programar sua própria biblioteca com blocos de NxM entradas e saídas
personalizadas para sua aplicação específica.
Figura 2.19: LabOSim no Simulink
Uma vez gerado os blocos sua programação é realizada através de ligações entre
eles (Figura 2.19), podendo assim dividir equipes e limitar a programação a blocos
genéricos enquanto equipes de outras áreas as utilizam de forma conveniente.
Também é possível criar uma interface gráfica para cada bloco, podendo assim
alterar seus parâmetros de forma externa sem a necessidade de conhecimentos de
programação (Figura 2.20).
19
Figura 2.20: Interface externa de um bloco
20
Capítulo 3
Desenvolvimento do Simulador
3.1 – Hardware e conexões eletrônicas
Toda eletrônica e hardware do simulador se comunica com o software através de
duas plataformas: Arduino e Wago. A Figura 3.1 apresenta um esquemático desta
arquitetura.
Figura 3.1 – Esquemático da arquitetura.
As conexões são divididas em cinco partes, um sistema Wago para cada sala,
responsável pela leitura dos potenciômetros dos manetes de controle, um Arduino para
cada sala responsável pela leitura do painel de controle do sistema “CCTV Camera” e
um Arduino extra na Sala 1 responsável pelo leme, que utiliza um encoder de saída
21
digital e pelo mostrador analógico que se localiza no teto da sala e necessita de uma
saída analógica, que é emulada por PWM (Pulse Width Modulation) através do
Arduino.
3.1.1 – Sistemas Wago
Os sistemas Wagos (Figura 3.2) funcionam de formas similares e independente
de computadores ou outros hardwares. Cada um é alimentado através de uma fonte de
24V e distribui a alimentação entre seus módulos. O módulo de rede (750-628 descrito
anteriormente) é conectado à rede interna do simulador e disponibiliza suas informações
de leitura para qualquer software conectado à rede. Em cada sistema há um módulo de
Power Supply, que alimenta os potenciômetros dos manetes com 10 Volts para que
sirva de referência para o módulo de leitura analógica. Também há, em ambos os
sistemas, um módulo de leitura analógica com quatro entradas que são utilizadas para
realizar as leituras dos quatro manetes de controle (Figura 3.3) na sala 1 (motor
principal 1, motor principal 2, propulsor de proa e propulsor de popa) e dos três manetes
de controle (motor principal, propulsor de popa e propulsor de proa) e do leme da sala 2.
Na parte lateral de cada módulo existem conexões externas para que possam ser
encaixados os próximos módulos, porém, quando não há mais a necessidade de outros
módulos, coloca-se o “End Module”, um módulo vazio que serve apenas para fechar
esses contatos de circuitos que ficariam expostos na lateral do sistema, isolando assim
todo o circuito.
Figura 3.2: Sistema Wago da sala de simulação 1 – Fonte 24V, sensores analógicos e saídas de
tensão WAGO de 5V e 10V
22
A disposição de sensores na sala 1 é realizada da seguinte maneira: o primeiro
módulo após o módulo de dados é um Power Supply extra de 5V, não utilizado ainda;
em seguida há um segundo módulo de Power Supply de 10V, que alimenta a todos os
potenciômetros das alavancas depois vem um módulo de 4 sensores analógicos que tem
na entrada 1 a alavanca do Bow Thruster, na entrada 2 a alavanca do Stern Thruster, na
entrada 3 a alavanca do motor principal 1 e na entrada 4 a alavanca do motor principal 2
e, após esse módulo, ainda há um segundo módulo de 4 sensores analógicos extras que
não está sendo utilizado e o End-Module.
3.1.2 – Conexões com Arduinos
Os Arduinos são responsáveis pelas conexões digitais de entrada e por todas as
conexões de saída para hardware, além de comandar o controle do sistema CCTV
(Figura 3.3), que se resume em uma alavanca do tipo X e Y e um botão de seleção de
câmera. A leitura da alavanca é dada através das entradas analógicas do Arduino,
variando assim de 0 a 5V para cada variável os valores da posição X e Y da alavanca
em relação ao centro, de -1 até 1, onde o centro se estabelece no ponto (0,0).
Além da alavanca, ainda no sistema CCTV, há um encoder seletor que seleciona
a câmera atual exibida na parte principal do sistema (que será explicitado mais a frente)
e tem seu valor obtido através de pulsos nas entradas digitais do Arduino.
Também há um Arduino responsável por coletar as informações de ângulo do
leme, através de um encoder, pelas entradas digitais, e após calcular o ângulo atual
escreve via PWM em uma saída digital o valor atual do leme no mostrador superior da
sala 1 (Figura 3.8) e envia a informação do ângulo para o Console (descrito
posteriormente) através de comunicação serial.
As ligações no Arduino utilizam os pinos digitais 8 e 12 para o controle do leme
e 9 e 13 para a escrita do mostrador superior.
Todos os Arduinos utilizados no simulador são do tipo Arduino Mega, que
utilizam a comunicação USB como fonte de alimentação e se comunicam com os
programas que os gerem através da porta serial.
23
3.1.3 – Hardwares do Simulador
O simulador conta com 12 televisões de 55 polegadas para visualização da cena,
ligadas a 12 computadores com hardware mais robusto para execução do programa de
visualização, sendo 7 televisões na horizontal na sala 1 dando 180º de visualização
(Figura 3.3) e mais 5 televisões na vertical na sala 2 dando 110º de visualização (Figura
3.4).
Figura 3.3: Sala de simulação 1 – Foto Panorâmica – 180º
Figura 3.4: Sala de simulação 2
Adicionalmente, há também 12 monitores de 21 polegadas, ligados a 12
computadores um pouco mais modestos, para exibição de toda a interface de iteração e
painéis de controle, sendo 7 na sala 1 e 5 na sala 2.
24
Por fim, também existem 2 monitores de 23 polegadas touch-screen ligados a
um computador em cada sala, para exibição dos painéis de controle touch-screen
(Figura 3.5).
Figura 3.5: Monitores Touch-Screen de controle da embarcação.
Além das telas, o hardware também conta com manetes de controle para os
motores de cada navio, sendo 4 para sala 1(2 motores principais e 2 motores laterais)
(Figura 3.6) e 3 para sala 2 (1 motor principal e 2 laterais) (Figura 3.7), e o controle do
leme é realizado por um timão na Sala 1 e exibido em um mostrador superior (Figura
3.8), já na sala 2 o leme é controlado por uma alavanca de leme.
Figura 3.6: Manetes de controle da Sala de simulação 1
25
Figura 3.7: Manetes e controle e alavanca de leme da sala 2.
Figura 3.8: Mostrador superior da Sala 1
Também é utilizado um painel de controle para comandar o sistema “CCTV” (Circuito
interno de câmeras) (Figura 3.9) que é ligado ao computador responsável pela tela em que o
programa do CCTV é exibido, através de um Arduino.
Figura 3.9: Painel de controle CCTV
26
3.2 – Softwares do Simulador
A seção a seguir descreverá os dispositivos de interface para o controle do
simulador e obtenção de dados, construídos através dos programas já descritos, com o
propósito de realizar a interação homem-máquina.
O usuário do simulador se comunica com o sistema através dos controles físicos
e dos monitores touch-screens, e recebe informações tanto dos próprios monitores,
quanto visualizadores (mostram a cena), painéis (dados da embarcação) e console.
Já o operador responsável pelo controle da simulação utiliza-se do menu do
operador para controlá-la, e recebe todas as informações necessárias através do mesmo
(Figura 3.10).
Figura 3.10 Conexões entre programas e usuário.
27
3.2.1 - Servidor
O servidor foi desenvolvido totalmente na plataforma Unity que reúne as
informações de todas as partes do simulador e as distribui via rede, processa as
condições iniciais da simulação, como a posição inicial dos navios, condições
climáticas, de vento e maré, e em seguida inicia o ciclo de simulação, que é repetido a
cada quadro. A comunicação entre os softwares e o servidor é ilustrada na Figura 3.11.
Figura 3.11: Esquema de comunicação entre o servidor e os demais programas do
simulador.
O programa recebe do console os comandos diretos dos navios e dos painéis
touch-screen os comandos secundários e passa todas essas informações para o
simulador matemático no Matlab. Logo após, recebe as informações de posições e
ângulos de cada navio, além das rotações atuais de cada motor.
Com isto, o navio é reposicionado através de interpolação, dado o tempo de
realização do ciclo, e suas interações físicas com o mar e objetos da cena são calculadas.
Ao fim do ciclo, temos uma nova posição e angulação de cada embarcação, que é
repassada para os visualizadores, radares, painéis AIS e painéis touch-screen através de
dados numéricos.
28
Terminado um ciclo, cada programa do simulador tem suas informações visuais
atualizadas e é iniciado o próximo ciclo, utilizando as posições e condições atuais como
iniciais, e todos os cálculos refeitos para o instante de tempo seguinte.
Para que tudo isso funcione corretamente são necessários diversos scripts
espalhados em algumas etapas.
3.2.1.1 – Scripts de inicialização
Primeiramente ao abrir o programa, é executado um script de início, que tem
como objetivo saber se o programa atual é o servidor, ou um dos clientes, e no caso de
ser cliente, a qual tela ele se refere. Para isso é aberto um arquivo de texto chamado
“server.txt” que indica se a máquina atual é servidor ou cliente e qual o IP atual do
servidor, por exemplo:
Server: True
IP: 192.168.20.186
O exemplo descreve que o programa em execução é o servidor, e seu endereço
de IP é o descrito no texto, caso seja um cliente este será o endereço no qual se conectar.
Logo após identificado o servidor, são habilitados o script de rede e o script de
inicialização da simulação. O script de rede inicializa o servidor local de rede,
habilitando assim o programa para as conexões vinda de qualquer cliente de acordo com
os parâmetros definidos pela rede, e logo em seguida habilita o servidor de tempo do
oceano. Dentre as configurações de rede existem diversos parâmetros, a tabela 3.1
mostra alguns dos principais parâmetros utilizados e suas definições.
Tabela 3.1: Parâmetros de rede e suas definições
Parâmetro de rede Definição
“customConfig” Habilita configurações personalizadas para a rede.
Tipo: Booleano
Valores: False/True
“AddChannel” Adiciona um novo canal ao servidor.
Tipo: QosType
Valores:Reliable, Ureliable, StateUpdate, AllcostDelivery.
“NetworkDropThreshold” Define a porcentagem de pacote que deve ser perdido antes que o tempo limite de envio
seja aumentado automaticamente.
Tipo: Porcentagem
Valor: 0 a 100%
“OverflowDropThreshold” Define a porcentagem dos pacotes a serem descartados por falta de espaço no buffer antes
que o limite de envio seja aumentado.
Tipo: Porcentagem
29
Valor: 0 À 100%
“MinUpdateTimeout” Define o tempo mínimo em milissegundos entre os envios dos pacotes de dados.
Tipo: Milissegundos
Valor: 1 à Qualquer valor inteiro.
“ConnectTimeout” Tempo de espera em milissegundos entre tentativas de conexão.
Tipo: Milissegundos
Valor: 1 a Qualquer valor inteiro.
“PingTimeout” Define o tempo entre o lançamento de “pings” para verificar a qualidade da conexão.
Tipo: Milissegundos
Valor: 1 a Qualquer valor inteiro.
“DisconnectTimeout” Tempo sem resposta para considerar que o cliente foi desconectado.
Tipo: Milissegundos
Valor: 1 a Qualquer valor inteiro.
“PacketSize” Tamanho máximo do pacote a ser enviado.
Tipo: Bytes
Valor: Qualquer valor maior que 1100
“SendDelay” Tempo de espera em milissegundos antes de enviar cada pacote.
Tipo: Milissegundos
Valor: 1 a Qualquer valor inteiro.
“FragmentSize” Define o valor de mensagens fragmentadas.
Tipo: Bytes
Valor: Maior que 64 Bytes.
“maxConnections” Número máximo de conexões simultâneas aceitas pelo servidor.
Tipo: Inteiro
Valor: 1 até 64 conexões.
“AcksType” Determina o tamanho do buffer para guardar mensagens confiáveis.
Tipo: Acks
Valor: Acks32, Acks64, Acks96, Acks128.
“MaxSentMessageQueueSize” Define o número máximo de mensagens por envio.
Tipo: Inteiro
Valor: 1 à 300 mensagens
“AckDelay” Define a duração em milissegundos que o receptor aguarda antes de enviar uma
confirmação de retorno sem esperar por qualquer outra carga de dados.
Tipo: Milissegundos
Valor: Maior que 1 milisegundo.
“networkAddress” Define o IP do servidor.
Tipo: Texto.
Valor: Qualquer IP válido.
Tabela 3.1: Parâmetros de rede e suas definições
Dado estes parâmetros de rede, e após a realização de alguns testes, foram definidos
parâmetros otimizados de rede para o simulador (Figura 3.12).
30
Figura 3.12: Definições de rede do simulador.
Após configurada a rede, iniciado o servidor e realizado os cálculos relacionados
a modelagem do oceano, entra em ação o script de início do simulador. Esse script
inicializa uma conexão TCP/IP que aguarda a entrada de dados do Matlab, e se
comunica através dela para que sejam lidas as posições do navio em cada instante de
simulação.
No servidor, a posição de cada navio é diretamente a posição recebida pelo
Matlab, uma vez que não há exibição visual dele para o usuário e o programa do
servidor fica rodando apenas em segundo plano, não é necessário realizar a interpolação
para que a cena fique fluida (a cena é executada em steps com tempo variável de acordo
com a velocidade do Matlab).
Além disso, o script de início do simulador também define as configurações de
câmera e qualidade da janela do servidor para as mínimas possíveis, ocupando assim o
menor espaço possível de vídeo e garantindo uma melhor taxa de FPS (quadros por
segundo).
No servidor, a cena não é exibida, fica em segundo plano, então não seria
necessário exibir nada na tela, porém para facilitar a depuração, o “farClipPlane” da
câmera (distância máxima que ela considera para renderizar a cena) foi diminuído de
182.000 metros (valor dos visualizadores) para apenas 600 metros, deixando assim o
programa muito mais leve, porém com uma pequena visualização do entorno do navio
para que, caso necessário, seja realizada uma comparação entre o que se passa no
31
servidor e o que se passa nos visualizadores quanto a posição do navio relativa às
câmeras.
3.2.1.2 – Plug-ins do simulador
Para a realização dos efeitos de clima e oceano, são utilizados plug-ins
adquiridos pelo laboratório para uma melhor qualidade gráfica, estes plug-ins são o
PlayWay Water System, para o oceano, UniStorm Weather System para o clima e
MapBox para geração do terreno.
Todos os plug-ins trazem consigo diversas opções de configurações, e após
definidas estas configurações em forma de “pré-definidos” são controlados por um
script externo de controle, que define qual dos pré-definidos será utilizado em cada
ocasião.
O plug-in PlayWay Water System tem como suas principais configurações a
resolução do oceano, que é uma das principais definições de sua qualidade. Quanto
maior a resolução, mais fidedigno à realidade ele fica, porém tem um custo enorme de
processamento. A Figura 3.13 descreve as opções de qualidade e a opção escolhida para
o simulador.
Figura 3.13: Qualidades disponíveis para a resolução do oceano.
Além da configuração de qualidade, também é possível criar oceanos pré-
definidos, para que com um comando simples possamos alterar diversas configurações e
também realizar de forma automática a interpolação entre vários modelos (Figura 3.14).
Temos as seguintes configurações de oceano pré-definidas: Calmo, Aragem, Brisa
Leve, Brisa Fraca, Brisa Moderada, Brisa Forte, Vento Fresco, Vento Forte, Ventania,
Ventania Forte, Tempestade, Tempestade Violenta e Furacão. A principal diferença
entre essas predefinições é a velocidade do vento, que impacta diretamente no tamanho
32
das ondas, essa escala segue a “Escala de Beaufort” que classifica a intensidade dos
ventos (Figura 3.15).
Figura 3.14: Exemplo de oceano pré-definido.
33
Figura 3.15: Escala de Beaufort de intensidade dos ventos.
O controle do oceano é realizado através do script “Controle_Oceano”, que tem
uma variável pública editada pelo painel de controle do operador aonde é definido o
valor-base do vento.
Contudo, como a simulação acontece dentro da Baía de Guanabara, o vento
definido é para o estado do mar do lado de fora da Baia, portanto, há uma interpolação
que faz com que as ondas diminuam conforme o navio adentre pela Baia, essa
interpolação começa um pouco após o morro do Pão de Açúcar, aonde a condição do
mar é exibida no valor selecionado, e vai até um pouco depois do centro da Baia (Figura
3.16), onde o valor pré-definido corresponde a duas unidades abaixo do selecionado.
Por exemplo, caso seja definido o mar como “Vento Fresco”, ele apenas será
exibido nessa forma na parte exterior da Baia de Guanabara. Conforme o navio se
aproxima da Ponte Rio-Niterói por exemplo, o mar começa uma interpolação entre
“Vento Fresco” e “Brisa Moderada”. No morro do Pão de Açúcar o vento atinge o mar
34
com valor de 35 nós (Ventania), e conforme avança por baixo da ponte o valor vai
caindo para aproximadamente 25 nós. Ao chegar próximo do centro da Baia o valor se
estabiliza em 14 nós (brisa moderada).
Essa interpolação é realizada através do script de controle do oceano, que pega a
posição atual do navio do usuário em relação a um ponto mínimo e máximo no eixo Z
do “world space” (exibido na Figura 3.16) e calcula um fator de 0 a 1 sendo “1” fora da
Baia de Guanabara (antes do início) e “0” Após o centro da Baia (depois do final) e este
fator é utilizado para interpolar a velocidade do vento (que defini a agitação do mar)
entre a máxima (definida pelo usuário) e a mínima (2 posições abaixo da máxima
segundo a escala de Beaufort) .
Figura 3.16: Área aproximada de interpolação do Oceano.
O plug-in do UniStorm Weather System é responsável pela exibição do clima da
simulação, através dele são geradas as nuvens, atmosfera, iluminação da cena, estrelas,
sol, lua e é marcado o horário do dia.
35
Assim como o oceano, o clima também é definido pelo painel de controle do
operador, sua conexão será explicada com mais detalhes na seção do painel do
operador, os dados são obtidos através da rede e são definidos o clima atual, horário e
direção do vento.
O plug-in também permite que a hora da simulação seja representada na
quantidade de minutos prevista pelo programador, sendo assim é possível ter uma hora
durando apenas um minuto, fazendo com que um dia inteiro dure apenas 24 minutos, ou
também é possível definir a hora com 60 minutos, fazendo com que a simulação
aconteça em tempo real.
As principais configurações do UniStorm Weather System são divididas em 4
partes: Player & Camera, Time, Weather e Celestial.
A seção “Player & Camera“ (Figura 3.17) configura onde ficará o centro do
globo de nuvens usados para gerar o clima, e qual câmera receberá os efeitos de clima
(chuva, relâmpagos, neblina) no caso do simulador, como a própria câmera principal
também se move com os navios, ela será o “Player” e a “Camera”.
Nesta seção também é possível configurar se o centro do clima andará com o
Player, ou será estático na cena, para que caso aconteçam grandes movimentações o
usuário não acabe saindo da zona de clima desejada.
Figura 3.17: UniStorm configuração de Player e Câmera.
36
A seção “Time” (Figura 3.18) é responsável pelas configurações de tempo. Nela
é possível controlar data e hora, duração do dia e noite (em minutos) e a possibilidade
de usar o horário real do computador em que se está executando o programa.
No caso do simulador, o script foi modificado para que a hora pudesse ser
controlada de forma automática diretamente do painel de controle do operador, que será
detalhado mais adiante, a duração do dia e noite foram definidos em 720 minutos (12
horas x 60 minutos por hora) para que após definida a hora atual, a simulação seguir em
tempo real.
Figura 3.18: Unistorm configuração de tempo.
Já a seção “Weather” (Figura 3.19) é onde acontece o controle do clima, a
transição entre os climas, temperatura, chances de precipitação e velocidade das nuvens.
Os climas são pré definidos e o script também foi modificado de forma a ser controlado
de forma automática pelo painel de controle do operador, portanto basta selecionar um
novo clima e todas as alterações nessas condições são feitas de forma automática. Os
climas pré-definidos são de chuva forte, nublado, parcialmente nublado, parcialmente
limpo, limpo, chuvoso, tempestades de raio, presença de neve e aleatório.
37
Figura 3.19: UniStorm configuração de clima.
Por último a seção “Celestial” (Figura 3.20), responsável pela configuração da
atmosfera, iluminação e dos astros, nela é possível configurar atributos como a cor do
sol, intensidade durante o dia, posição, fase da lua, entre outras configurações da
atmosfera em si. As configurações dessa seção são fixas, e não podem ser controladas
de forma externa (não podem ser alteradas pelo operador do sistema, apenas pelo
programador antes de ser compilado) portanto a seção é configurada para o cenário
38
simulado (considerando o hemisfério, posição do sol na cena, época do ano) e após
compilado o programa, não é mais alterada.
Figura 3.20: UniStorm configurações de atmosfera.
Após a definição do clima e oceano, o próximo passo é a geração do terreno, que
é dada através do plug-in “MapBox” (Figura 3.21), o plug-in pega informações de
longitude e latitude para gerar um mapa de relevo com textura do local indicado.
39
Apesar de bem completo, o plug-in tinha uma área de atuação e escalas bem
limitadas, e também necessitava de conexão com a internet para baixar o mapa a ser
gerado em tempo real, porém os computadores das salas de simulação ficam em redes
isoladas e sem conexão.
Devido a isso, foram necessárias algumas configurações e alterações no script
para tornar o terreno de tamanho real e fazer com o que o script funcione sem a
necessidade de acesso à Internet.
Para isso foi gerado o terreno uma única vez com conexão à Internet através da
execução do script e, após sua geração, utilizamos seus arquivos temporários que ficam
disponíveis em tempo de execução para que na, próxima vez que o programa fosse
aberto, fosse utilizado sempre o mesmo terreno, fazendo assim com que não existisse a
necessidade de conexão com a Internet e forçando o terreno ser exatamente igual em
todas as telas.
As principais configurações do plug-in são a localização, o zoom em torno do
centro, que define a resolução da textura do mapa (texturas com maiores resoluções
pesam muito mais e acabam deixando o simulador lento) e configuração de altura do
terreno e raio da terra para deixar tudo em escala 1:1.
Figura 3.21: MapBox – Script de configuração.
40
3.2.1.3 – Scripts de Comunicação
Nesse ponto, já foi inserido e configurado no simulador todo o cenário, restando
apenas inicializar a comunicação entre o servidor e as outras aplicações, essa
comunicação é realizada através dos scripts de comunicação em rede, eles são
responsáveis por realizarem a passagem de variáveis para os clientes para que possam
ser interpretadas.
O primeiro desses é o script “Passagem de Parâmetros via Rede” (Figura 3.22),
responsável por passar do servidor para os clientes as configurações recebidas através
do painel de controle do operador.
Através dele são passadas as informações de clima e oceano atual, direção do
vento, hora do dia e se a simulação está sendo executada ou pausada, para não
congestionar a rede. O script foi configurado para só enviar informação aos clientes
caso alguma alteração seja executada, do contrário ele permanece em estado de espera.
Também é disponibilizada uma “String” que descreve as posições e rotações de
cada navio na cena. Essa string é utilizada por outros programas, seja para exibir a
posição do navio em uma carta náutica, ou para obter a rotação e consequentemente, o
aproamento de determinado navio. A taxa de envio de informações pela rede foi
limitada em no máximo 0.2 segundos de intervalo por envio, fazendo assim com que,
mesmo existindo várias modificações simultâneas, o tráfego de rede se mantenha o mais
leve possível. Para este script é utilizado o canal 1, “ReliableFragmented” (canal que
garante a entrega do pacote de mensagem, porém envia apenas uma vez cada pacote),
para garantir a chegada da mensagem aos clientes, porém sem pesar muito na rede como
o “All Cost Delivery” (já este canal fica enviando repetidamente os pacotes de
mensagens até receber um retorno de que a entrega foi efetuada, dessa maneira, sendo a
forma de envio mais rápida e segura, porém a mais pesada). Esse script se comunica
principalmente com os visualizadores, porém também manda informação de
posicionamento para o painel AIS e para o painel de controle do operador.
41
Figura 3.22: Variáveis de rede do Script de Passagem de parâmetros.
O segundo script de rede é chamado “Passagem de parâmetros – Painéis de
Controle” (Figura 3.23), e é responsável pela comunicação entre o servidor e os painéis
de controle touch screens do navio. Ele envia para os painéis todas as informações a
serem exibidas, são elas: velocidade de proa, velocidade de popa, velocidade relativa,
distância total para o próximo marcador de trajeto, distância total do trajeto, ângulo de
aproamento, velocidade de giro, todos os erros possíveis nos motores, velocidade e
passo de cada motor e hora do dia.
Essas informações são enviadas para os painéis touch screen das salas 1 e 2 por
meio da execução de tarefas alternadas a cada meio segundo. Na primeira metade do
segundo são calculadas informações do navio da sala 1, sua velocidade (em
metros/segundo), seus motores, ângulos e a hora atual. Essas informações recebem uma
“hash” (código antes da mensagem com um significado a ser tratado), para que possa
ser ignorado pelo painel da sala 2, então a informação é enviada para todos os painéis.
Em seguida, meio segundo depois, começam os cálculos para o navio da sala 2, e os
mesmos recebem uma segunda “hash” para que possam ser ignorados pelos painéis da
sala 1.
Dessa maneira, a cada 1 segundo são atualizados ambos os painéis, com uma
alternância entre eles, ocupando a rede a uma taxa de apenas 2 Hz, fazendo assim com
que a comunicação seja leve, mesmo com o número elevado de informações passadas
para cada painel.
Essa forma de abordagem foi necessária pois o Unity apresenta um limite de até
32 variáveis que podem ser compartilhadas pela rede. Portanto se cada painel fosse
receber individualmente as informações do seu navio, seriam necessárias o dobro de
42
variáveis, ultrapassando assim o limite quando somado aos outros scripts. Dessa
maneira havia duas soluções viáveis para contornar o problema. Uma delas era reunir
diversas mensagens em uma só “string” e enviar para o painel, porém em testes foi
constatado que em mensagens grandes o risco de perda é muito alto ou, caso haja
garantia de entrega, ocupa muito espaço na rede.
Como os painéis são discretos e a informação que varia mais rapidamente é a
contagem dos segundos do relógio, uma segunda solução foi adotada, onde são
utilizadas as mesmas variáveis para ambos os painéis com uma “hash” inicial que indica
a qual painel ela pertence. Desta forma, realiza-se a atualização apenas uma vez por
segundo cada, isto é, são enviadas informações 2 vezes por segundo, uma para cada
painel.
.
Figura 3.23: Script de passagem de variáveis para os painéis touch screens do
simulador.
Um dos scripts de rede mais importantes de todo o simulador é o script
“Gerenciador” (Figura 3.24). Ele, assim como o script de rede, se encontra em todos os
programas do simulador, e é responsável por identificar as estações de trabalho na rede.
O Unity utiliza a lista de “Game Objects” do projeto para sincronizar todos os
objetos presentes em cada cena, porém, como temos programas complexos como os
visualizadores, que exibem cada navio e trocam muito mais informações, e programas
43
mais simples, como os painéis de informações, que pegam do servidor apenas alguns
valores, a quantidade de objetos em cada cena é muito diferente.
Mesmo que cada programa seja definido com um IP diferente, todos os objetos
da cena recebem internamente do Unity, de forma automática, um número de ID, que o
identifica dentro da cena.
Com essa condição o algoritmo do Unity acaba se confundindo e relacionando
objetos que não existem em determinadas cenas, com objetos que existem em outras,
devido ao mesmo ID recebido de forma automática, gerando uma confusão de posições
e scripts.
Para contornar este problema o script conta com uma lista que contém todos os
objetos compartilhados entre os programas via rede. Assim que iniciado, ele define um
ID fixo para cada um deles, para que não aconteça de um objeto ser confundido com
outro na inicialização de cada cliente.
Com o ID fixo entre cliente e servidor, é garantido que todos os outros scripts da
rede funcionem corretamente, eliminando assim possíveis problemas que costumavam
aparecer, principalmente quando objetos diferentes se sincronizavam de forma errada.
O script também é responsável por reunir as posições dos navios e criar a
“string” que os representam. Também cabe a ele organizar os objetos da cena de acordo
com a cena atual, e comandar o script de passagem de parâmetro do cliente para o
servidor, que será descrito a seguir.
44
Figura 3.24: Parâmetros do Script Gerenciador.
Os scripts de rede citados anteriormente levam dados do servidor para os
clientes, porém foi necessária a criação de um script que fizesse caminho contrário, e
trouxesse ao servidor as informações e comandos dos painéis. Esse script se chama
“Passagem de Parâmetros Cliente Servidor” e está presente em todos os clientes que se
comunicam com o servidor através do objeto pré-definido “Player”.
Quando um cliente inicia uma conexão com o servidor, é criado um novo objeto
na cena chamado “Player”. Este objeto é pré-definido e está atrelado a ele o Script de
passagem de parâmetros do cliente para o servidor. Assim que criado, o “Player”
original (objeto existente na aplicação que se conectou ao servidor) faz a leitura do
nome da cena na qual se encontra, e escreve em sua versão clone (a cópia presente no
servidor) a qual painel ele se refere através de uma variável booleana, tornando “True” a
booleana que indica a sua origem seguindo a tabela abaixo (exemplificado na Figura
3.25). Ou seja, existirão diversos “Players” no servidor, todos com as mesmas variáveis,
porém para que o servidor possa verificar qual player pertence a qual painel, basta
verificar qual variável booleana indicativa é a verdadeira, e assim só considerar as
variáveis referentes ao painel indicado.
Tabela 3.2: Variáveis de controle do objeto Player
Cliente Booleana indicativa
Painel touch-screen Paineltouch_publico
Painel de controle do Operador Painel_controle_publico
Uma vez definido a qual cliente o Player pertence, as variáveis do script
relacionadas ao Player em si começarão a ser consideradas pelo servidor. Estas
variáveis serão descritas na seção correspondente a cada um desses painéis. As demais
variáveis pertencentes aos outros players serão ignoradas neste objeto. Por exemplo, o
Player referente ao menu de controle do operador tem variáveis que controlam o clima,
horário e oceano, entre outras, a serem consideradas, mas também há neles as variáveis
dos demais clientes que ficarão zeradas e serão ignoradas pelo simulador (Figura 3.24).
O script também conta com uma limitação de taxa de envio de 200
milissegundos e envia informações através do canal de rede ReliableSequenced (que
garante a entrega das informações).
45
Figura 3.25: Player referente ao painel de controle do operador.
3.2.2 - Visualizadores
Os visualizadores são responsáveis por exibir em cada tela o que se passa dentro
da simulação a cada instante. Devido aos atrasos da comunicação por rede, os dados
provenientes do servidor passam por uma nova interpolação, para que não haja nenhum
tipo de travamento ou descontinuidade dos modelos de um ciclo para o outro, que
podem ser causados por algum erro ou travamento na rede. Desta forma, mantém-se
assim a visualização realista durante toda a simulação.
Além das posições e angulações dos navios, os visualizadores também recebem
informações de clima, horário e condições de oceano para exibir as causas de cada
movimentação do navio e garantir que tudo que acontece na cena esteja condizente com
os valores calculados na simulação matemática.
Toda a parte de som e imagem é gerada aqui, desde condições climáticas
visuais, sons de chuva, trovões, sinais sonoros dos navios e vibração do motor.
46
3.2.2.1 – Programação dos visualizadores
A principal diferença entre os visualizadores e as demais telas está no Script
Client. Este script é responsável por organizar o que se diz respeito à visualização.
Inicialmente o script abre o arquivo de seleção de telas, onde se encontram as
informações de qual sala, tela e qual a configuração de navios está sendo simulada.
Esta configuração indica que a tela na qual se está rodando o programa de
visualização se encontra na sala 1, a simulação que está sendo rodada nos navios é a
configuração 1, e esta é a 4ª tela da esquerda para a direita, ou seja, a tela central.
As possíveis configurações para o simulador atualmente são:
Sala 1 ou 2: Indica se está na maior sala (1) com telas de 1 a 7, ou na
menor (2), com telas de 8 a 12.
Navio 1 a 3: O valor 1 indica que a simulação está simulando o modelo
mais atual do navio AHTS na sala 1 e o TUG na sala 2. O valor 2 indica que
está simulando o modelo antigo do AHTS na sala 1 e o TUG na sala 2. O
valor 3 indica que está simulando o Porta Contentor na sala 1 com o TUG
na sala 2. Devido a estrutura pequena da sala 2, apenas o TUG está
disponível para ela, enquanto os outros dois navios dividem a sala 1.
Tela 1 a 12: Indica qual tela se está exibindo da simulação, sendo de 1 a
7 na sala 1, da esquerda para a direita, e de 8 a 12 na sala 2, da esquerda
para a direita.
Após ler a qual sala e tela o programa atual pertence, o script Client posiciona a
câmera no navio correspondente. Há também a possibilidade de escolher entre a
visualização frontal ou traseira do navio, através de um atalho no teclado. Em seguida, é
escrito o arquivo de controle do cluster e habilitado o seu script, que é responsável por
fazer o recorte da tela na visualização.
3.2.2.2 – Cluster
O plug-in Unity Cluster Package foi o cluster escolhido para realizar o recorte
das telas, o plug-in foi desenvolvido no Instituto Federal de São Paulo (IFSP) e
47
disponibilizado de forma gratuita através do site SourceForge em forma de código
aberto.
O funcionamento do cluster é simples: um servidor comanda a cena principal, e
os visualizadores fazem recortes desta cena de acordo com sua configuração exibindo
em telas separadas, para juntas formarem a cena completa (Figura 3.26).
Figura 3.26: Imagem retirada do manual do Unity Cluster Package que descreve seu
funcionamento básico.
A configuração de tela é descrita através do arquivo de controle descrito
anteriormente, que é escrita pelo script Client de acordo com sua sala e tela. O arquivo
de configuração trata-se de um arquivo com extensão XML, que tem a configuração
representada pela Figura 3.27.
Figura 3.27: Imagem retirada do manual do Unity Cluster Package que descreve a configuração
do seu arquivo em XML.
Os campos version e encoding representam a versão e codificação do arquivo
em XML, o campo type define se a tela em questão é a principal (Master) ou alguma
das secundárias (Client), as telas name, id e nodes tratam-se de configurações para
localizar-se dentro do programa a qual tela estamos nos referindo, porém esta parte não
48
é relevante, uma vez que o script Client já indica estas informações e escreve o XML
com elas já setadas.
Os campos ip e port indicam a localização do server e porta de comunicação. O
campo stereo e eye indicam se a projeção é do tipo estereoscópica e caso seja, de qual
“olho” se trata, utilizado para projetores polarizados, que não é o caso pois no simulador
não são utilizados projetores.
A partir daí são exibidas as configurações da tela em si, a tela é dividida em 4
pontos, A, B, C e E, que indicam respectivamente o canto inferior esquerdo da tela (A),
o cando inferior direito (B), o canto superior esquerdo (C) e a distância da cabeça do
observador em relação a tela (E). Para que possa ser realizado o efeito de paralaxe e
visão panorâmica (Figura 3.28).
Os pontos são definidos por vetores posição de 3 dimensões e suas unidades
indicam em “aspect rate” a posição da tela em relação ao centro da visualização, ou
seja, se for descrita a tela central, e seu aspect ratio for 16:9, o ponto inferior esquerdo
(A) se encontrará na posição -8, -4.5, 0 (no formato x,y,z em relação ao centro), seu
ponto superior esquerdo (C) estará na posição -8, 4.5, 0 (Figura 3.28).
Figura 3.28: Imagem retirada do manual do Unity Cluster Package que exemplifica o
efeito paralaxe em que a imagem se estica conforme de aproxima dos cantos da tela conforme a
configuração da Figura 3.29.
49
Figura 3.29: Imagem retirada do manual do Unity Cluster Package que exemplifica as
configurações das telas em relação ao seu controle.
O Unity Cluster Package funcionou bem, porém a sua forma de ajuste de câmera
faz o recorte da imagem diretamente na matriz da câmera, mantendo assim a posição e
direção de visualização do objeto câmera no Unity em local diferente do que de fato é
visualizado, ocasionando alguns problemas que serão descritos posteriormente neste
texto.
3.2.2.3 – Sincronizações
Como a visualização do simulador é exibida por programas separados em um
computador para cada tela, foi necessário fazer diversos ajustes de sincronização para
que o limite entre as telas estivesse recortado corretamente e a cena fosse exatamente
igual em todas elas.
As modificações mais importantes estão relacionadas ao clima, oceano e ao
posicionamento dos navios entre as telas. A modificação do clima deve-se
principalmente a dois fatores: 1: Nuvens geradas de forma aleatória e 2: Raios que
acontecem em momentos, posições e durações aleatórias.
Para resolver este problema, o plug-in de clima foi alterado de forma a forçar a
mesma semente de geração de nuvens em todas as telas, de forma fixa, para que não
haja nenhuma divergência. Já no caso dos raios, apenas o servidor é capaz de gerar um
raio, e este é repassado para cada cliente com localização e duração para que o
relâmpago aconteça ao mesmo tempo em todas as telas.
50
A sincronização do oceano tem como objetivo garantir que a onda que saia na
borda de uma tela esteja entrando na borda da tela seguinte, as ondas do oceano são
geradas através de uma série de Fourier pré-determinada que varia através do tempo e
espaço. Portanto, para garantir que as ondas fossem exatamente iguais em todas as telas
bastou forçar o tempo e a semente da série do oceano de cada um dos clientes serem
iguais à do servidor.
Esta sincronização é realizada através da rede, por um script cedido pelo próprio
plug-in do oceano, que força a todas as instâncias do oceano que estão em um
computador cliente a ignorar seu próprio tempo e copiar o tempo do servidor para
realizar o cálculo da série.
O posicionamento dos navios é realizado através de um script de
posicionamento em rede chamado Network Sync Transform. Esse script é responsável
por copiar a posição e rotação de um objeto no servidor para um cliente seguindo
algumas regras.
As duas primeiras regras são de configuração de envio. A primeira é o intervalo
de tempo mínimo em que essa alteração na posição vai ser enviada, fixada em 0.2
segundos (ou seja, envia a informação 5 vezes por segundo) e a segunda indica qual
canal será usado para enviar esta informação, no caso, o canal “All Cost Delivery”,
escolhido para garantir a chegada de informação aos clientes e assim evitar travamentos.
Logo em seguida, vêm as regras de alterações mínimas para que seja decidido
que houve um movimento. Esta regra é dividida em posição e rotação, e só envia uma
nova posição aos clientes. Caso a posição atual tenha se alterado em mais de 0.01
unidades, ou seja, caso o navio percorra mais que 1 centímetro.
A rotação, por ser mais facilmente percebida pela câmera, está definida para ser
enviada caso qualquer um dos ângulos do objeto se altere em mais que 0.001 radianos.
Por último, é definida a velocidade de interpolação, ou seja, dada uma nova
posição, nos quadros entre a posição atual e a próxima que só chegará no mínimo em
mais 0.2 segundos, com qual velocidade será feita a interpolação de movimento entre a
posição do cliente e a nova posição cedida pelo servidor. Esta velocidade está definida
como 1 unidade de tempo para a rotação e 10 unidades de tempo para a posição, onde a
unidade de tempo é dada pelo tempo de processamento entre um quadro e outro.
Deste modo, caso esteja executando o programa a 60 quadros por segundo, e
haja uma interpolação, a taxa de interpolação de movimento será dada por 1/6 de
51
centímetro por quadro, e a taxa de interpolação de rotação será dada por 1/60 radianos
por quadro.
Também foi definido que, caso o objeto percorra mais de 50 metros em um só
quadro, o objeto é instantaneamente colocado para a nova posição, sem passar pela
interpolação. Isso ocorre por que quando o servidor é reposicionado para alguma
simulação, é desejado que o navio apareça instantaneamente na nova posição, e caso
haja uma interpolação, além da velocidade absurda de movimento também há o risco de
colidir com outras unidades no trajeto. Logo, foi considerado que a tal distância, seria
impossível tratar-se de uma movimentação normal, e sim, de uma nova definição de
posições iniciais.
As regras para reposicionar os objetos na cena são necessárias, pois, caso o
objeto fosse reposicionado a cada quadro, seria gasto muito processamento de forma
desnecessária, causando assim um atraso ainda maior e possíveis travamentos na
visualização.
3.2.2.4 – Efeitos visuais e sonoros
As cenas de visualização também contam com efeitos visuais e sonoros para
trazer mais realidade a simulação, todos relacionados ao clima atual exibido.
Primeiramente, há uma variação na névoa do ambiente de acordo com o horário
do dia, para que ao amanhecer a visibilidade seja bem mais baixa do que meio dia
(Figuras 3.30 e 3.31), por exemplo, e para que haja mais névoa em climas chuvosos e
menos em climas secos.
52
Figura 3.30: Visibilidade às 7 horas da manhã.
Figura 3.31: Visibilidade às 13 horas.
Também em climas chuvosos há um efeito de “chuva no vidro”, simulando o
impacto e escoamento das gotículas de água em contato com os vidros da janela do
navio, causando deformação e embaçando a cena de fundo (Figura 3.32).
Figura 3.32: Efeitos de chuva no vidro da tela.
53
Outra modificação importante foi a inclusão de filtros passa-baixa nos efeitos
sonoros de chuva, trovão, e barulhos de motores e cornetas de navios, para que as altas
frequências e sons mais agudos sejam atenuados, dando assim a impressão de se estar
de fato dentro de uma cabine fechada, como em um navio (Tabela 3.3).
O motor principal do navio é onde acontece uma das maiores atenuações,
fazendo com que seu som seja extremamente grave, para que a sua vibração possa ser
sentida em toda a sala, como se de fato houvesse um motor em rotação bem abaixo do
usuário.
Tabela 3.3: Frequências de cortes dos sons.
Som Frequência de corte (Hz)
Motor 140
Chuva 3000
Relâmpagos 3000
Corneta 2000
Tabela 3.3: Frequências de cortes dos sons.
Existe também o efeito de som 3D nas cornetas dos navios, fazendo com que seu
volume se altere linearmente de acordo com a distância entre o navio emissor e a sala
receptora do som em uma área circular, ou seja, um navio distante que utilizar a corneta
será ouvido bem baixo, enquanto um mais próximo ou o próprio navio da sala serão
ouvidos bem mais alto (Figura 3.33).
54
Figura 3.33: Colisor do efeito sonoro para variação de som 3D.
3.2.3 - Menu do operador
O menu do operador é o software responsável pelo controle das condições da
simulação. Por meio dele, o operador pode alterar as condições climáticas, condições de
vento e oceano, horário e inserir navios na simulação, além de ter o retorno de todas as
informações que se passam na simulação e uma visualização de toda a cena (Figura
3.34).
Figura 3.34: Sistema do Menu do Operador.
Devido à capacidade de hardware do computador em que se utiliza o Menu do
Operador (atualmente com um processador I9 e 2 placas gráficas GTX 1080 Ti), foi
habilitado a ele também a opção de ser o servidor da simulação, ou seja, deixando de ser
apenas mais uma visualização da cena, e passando a se comunicar com todos os outros
painéis e o Matlab para realizar os cálculos das posições e iterações da embarcação.
O menu do operador é dividido em quatro partes: Controle de clima e oceano,
informações do navio, sistema de geração de erro ou CCTV e visualização.
A tela de geração de erro pode ser substituída pelo sistema CCTV de acordo
com a simulação, e vice-versa, e ocupam o mesmo espaço no menu.
55
3.2.3.1 – Painel de controle de clima e oceano
Por meio do painel de controle de clima e oceano o controlador pode alterar tais
condições, mudando assim a resposta do navio e a visibilidade da cena, para dar mais
realidade à simulação e obrigar determinadas reações do comandante da embarcação.
Também são exibidas as informações atuais de clima, data e hora, condições
marítimas e de vento e o tempo de simulação (Figura 3.35).
Figura 3.35: Painel de controle de clima e oceano do Menu do Operador, cena de controle de
Clima.
O painel possui com o servidor variáveis compartilhadas que indicam o clima,
oceano, hora, direção do vento e a atual situação da simulação, se está em play, pause,
ou stop.
Todas essas variáveis são controladas única e exclusivamente pelo Menu, não
podendo ser alteradas de forma independente pelo servidor.
A lógica de exibição do programa é composta por 4 cenas, 2 com câmeras
independentes e 2 que dividem a mesma câmera, e, conforme o usuário seleciona cada
uma delas no menu superior do aplicativo, acontece uma alternância entre elas, a cena
padrão inicial é a de controle de clima, já exibida na Figura 3.35.
A cena de controle de clima, assim como a cena de controle do oceano (Figura
3.36) compartilham da mesma câmera, que exibem uma prévia do clima e oceano
selecionados, além de ambas contarem também com um menu na parte inferior da tela,
para alterar entre as opções.
56
Ambas as cenas são controladas pelo Script Gerenciador (descrito anteriormente
na seção do Servidor) para alterarem suas variáveis através dele.
Figura 3.36: Controle de oceano do menu do operador.
Além dessas duas cenas, à esquerda da cena de controle do oceano no menu
superior, se encontra a cena da carta náutica (Figura 3.37), que exibe informações da
posição de todos os navios do simulador projetadas em uma carta náutica da Baia de
Guanabara. Nesta cena é possível dar zoom e mover o mapa com o arrasto do mouse, e
os navios são representados de acordo com a simbologia utilizada no site “Marine
Traffic”, que define suas cores e símbolos de acordo com o tipo de navio e sua função.
Toda cena da carta náutica e seu controle de zoom e arrasto é controlada por um
único Script chamado “Navegaçao_Carta_Nautica” que controla sua movimentação,
zoom, posições, cores e sprites de cada navio, e possui uma taxa de atualização de
posição de 1 segundo.
57
Figura 3.37: Cena da Carta Náutica do Menu do Operador.
Por fim há também um painel para aplicações futuras, onde será possível
adicionar novos navios a simulação em tempo real e posicioná-los na cena, que está
previsto para o projeto do simulador LabOSim 2019, mas por enquanto é utilizada para
exibição dos modelos dos navios presentes nas simulações.
A cena de exibição dos navios é controlada por um Script chamado
“Camera_Obital”, que tem esse nome devido à órbita que a câmera realiza em torno do
navio enquanto este é exibido. Devido à falta de referências externas, a impressão que
se passa é que o navio que está girando.
Além desse, também há na cena um script de controle do Oceano que faz o
recorte dele em volta de uma forma geométrica pré-definida, no caso uma esfera, dando
assim a impressão de que os navios estão em cima de uma semiesfera de água, como se
estivessem dentro de uma garrafa (Figura 3.38). Tal script faz parte do plug-in do
Oceano e seu desenvolvimento foge ao escopo do trabalho.
58
Figura 3.38: Painel de exibição dos navios.
O painel também conta com uma tela que exibe e controla suas conexões (Figura
3.39) para que o operador saiba que todos os programas daquela simulação estão
conectados.
Figura 3.39: Exibição de conexões
Para cada programa disponível há uma chave que indica se ele está ou não
habilitado para a simulação atual, e um LED indicativo de conexão. Caso o programa
esteja habilitado e conectado, o LED exibe a cor verde clara, como se estivesse aceso.
Para programas que estão habilitados e desconectados, o LED exibirá a cor vermelha e,
caso essa tela seja fechada, soará um alarme indicativo de que algum programa
59
habilitado está desconectado. Já no caso de o programa estar desabilitado, o LED
indicará a cor verde escura, como se estivesse apagado, e a conexão desse programa não
será considerada para o alarme.
A tela é dividida em LabOSIM 01 e 02 para indicar os programas das salas 1 e 2
de simulação.
O conjunto dessas quatro cenas, além do Canvas principal que também
disponibilizam funções de Arquivo (salvar e carregar configurações de clima e oceano) ,
Opções de simulação (play, pause e stop), Minimizar e Fechar o painel, são comandadas
por um conjunto de Scripts de controle descritos na Tabela 3.4.
Tabela 3.3: Scripts de controle do Menu do Operador
Script Função
Controle_Botões Realiza a função de todos os botões de cada cena,
alterando clima, oceano, hora, ocultando/exibindo as
barras de menu entre outros.
Controle_Menu Altera entre as cenas exibidas (Controle de Clima,
Controle de Oceano, Exibição de Modelos e Carta
Náutica)
Inicializar Inicializa os demais scripts definindo os padrões iniciais
como clima e ocenao inicial, hora inicial, local onde o
menu vai começar, entre outras condições iniciais.
Save_Load Responsável por gravar ou carregar um conjunto pré-
definido de configurações do Menu, para que caso várias
pessoas desejem fazer a mesma simulação não seja
necessária alterar todas as configurações novamente,
apenas carregar o arquivo da anterior.
Controle_Records Todas as simulações tem seu tempo gravado desde o play
até o stop, e ao final anotado o nome ou indicador da
simulação realizada, para gerar um arquivo de registro de
simulações e tempos.
3.2.3.2 – Visualização da cena
A cena de visualização consiste em uma cena externa da simulação. Seu objetivo
é dar ao instrutor a capacidade de ver como cada navio reage aos comandos dados em
simulação de forma mais ampla e externa, detectando assim erros cometidos pelos
usuários durante a navegação.
60
Sua programação consiste apenas no controle de câmera, e conta com posições
pré-definidas e a opção de câmera livre, para que o operador possa controlá-la e “voar”
livremente pela cena (Figura 3.40). Na opção de câmera livre a câmera é controlada
através de um script de controle que a movimenta através do controle no estilo
“WASD” onde W e S a movimentam para trás e para frente, e A e D para a esquerda e
direita, respectivamente. Com o mouse é possível apontar para onde a câmera está
olhando, e com os botões Q e E aumentar e diminuir a altura da câmera,
respectivamente. Esse tipo de controle é muito utilizado em jogos e simulações em
primeira pessoa, onde o usuário tem a câmera como se fossem seus próprios olhos na
cena.
Figura 3.40: Tela de visualização no modo “Câmera livre”
As posições pré-definidas consistem nas visualizações frontais e traseiras de
cada navio da simulação (Figura 3.41 e 3.42) (exceto no navio porta-contêiner, que tem
apenas a visualização frontal (Figura 3.43)) e a câmera se mantém de forma fixa
seguindo a movimentação e balanço do navio.
61
Figura 3.41: Visão traseira (Popa) da embarcação TUG
Figura 3.42: Visão dianteira (Proa) da embarcação TUG
Figura 3.43: Visão dianteira do Porta-Container
62
Além disso, também é possível ter uma visualização simultânea da visão dos
dois navios no modo tela dividida (Figura 3.44). Para realizar esta cena, foi necessária a
criação de uma segunda câmera na cena, com as mesmas características da primeira, e
realizar a configuração para que a primeira câmera fosse renderizada na metade superior
da tela, e a segunda na metade inferior.
Figura 3.44: Tela de visualização no modo “Tela dividida”
Essa configuração é dada através das variáveis “Viewport Rect” da câmera
(Figura 3.45) que possui quatro variáveis normalizadas, X e Y, que definem o ponto
inicial aonde a câmera será renderizada e as variáveis normalizadas Width e Height que
definem a largura e altura da imagem.
Figura 3.45: Variáveis “Viewport Rect”
Para definir o ponto inicial “X,Y” de renderização, é definido o ponto “0,0”
como sendo o limite superior esquerdo da tela, e o ponto “1,1” o limite inferior direito, e
a renderização é sempre dada a partir da ponta superior esquerda da imagem (Figura
3.46).
63
Figura 3.46: Exemplo de posicionamento de câmera na tela.
Já as variáveis Width e Height definem o tamanho da imagem a ser renderizada,
normalizadas em relação ao tamanho total da tela, ou seja, com altura igual a 1, a altura
da imagem é do tamanho da altura da tela, com largura igual a meio por exemplo, a
largura da imagem ocuparia meia tela.
Portanto, para fazer a cena com as duas visões, além de posicionar uma câmera
na cabine de cada navio, a câmera principal foi configurada com os valores X,Y em
(0,0) e os valores Width e Height em (1,0.5), ou seja, começando a renderizar da parte
superior esquerda da tela, com a largura igual à da tela (1), e a altura sendo a metade da
altura da tela (0.5) e a câmera auxiliar com as configurações de X,Y em (0,0.5) e Width
e Height em (1,0.5), ou seja, começando a renderizar a partir da metade da tela, à
esquerda, com largura igual à da tela, e metade da altura da tela, preenchendo assim o
espaço restante.
3.2.3.3 – Informações da embarcação
Na seção de informações da embarcação, são exibidas as condições atuais do
navio, tais como velocidades, acelerações, ângulos, além de exibir as posições atuais
dos controles de cada sala e do leme de cada embarcação (Figura 3.47).
64
Figura 3.47: Painel de informações das embarcações
O painel inicialmente utiliza a leitura via rede da plataforma Wago, para obter os
valores lidos diretamente no potenciômetro de cada alavanca em hexadecimal, e os
converte para valores decimais.
Para cada sala há um arquivo de calibragem que indica os valores máximos e
mínimos possíveis para cada potenciômetro. A partir desses valores e utilizando o valor
decimal atual, é possível fazer uma interpolação da posição atual e reescala-los para
uma escala entre 0 e 100, obtendo o valor final da alavanca.
Após se obter o valor físico de cada alavanca, o marcador é posicionado
indicando o valor da alavanca e a aceleração do motor começa a carregar, exibindo
visualmente o valor da aceleração real do motor naquele instante.
Além de exibir informação das alavancas e aceleração dos motores, também é
exibida a posição do leme do navio e as velocidades relativas.
A velocidade relativa de cada navio é exibida na forma de velocidade de popa,
proa e central (em nós) e ao se movimentarem, setas animadas aparecem exibindo sua
direção de movimentação, e se movimentam de acordo com sua velocidade (Figura
3.48).
65
Figura 3.48 Exibição de velocidades relativas do Navio.
Também é possível utilizar este painel para controlar os navios, através da tecla
de atalho F1 o operador passa a ter controle sobre a embarcação, com um clique e
arrasto nos valores das alavancas é possível reposicioná-las e o servidor irá considerar
como comando válido o último comando gerado, seja pelo painel do operador, ou pelas
salas de simulações.
3.2.3.4 – Controle e geração de erros
O Operador também é responsável por, caso faça parte da simulação, gerar erros
ou defeitos nos motores ou controle do navio, como por exemplo superaquecimentos,
defeito em motor, travamento do leme, entre outros, gerando assim situações em que o
usuário tivesse que tomar atitudes diferentes dos padrões para manobrar a embarcação.
O controle desses erros e a visualização de quais erros e defeitos estão ocorrendo
no momento é dado através desse painel (Figura 3.49). Após a inserção de um erro na
embarcação, o usuário é imediatamente avisado através dos painéis touch-screens.
Atualmente esta parte do Menu do operador serve apenas como forma de
exibição. Os erros são gerados de acordo com as demandas das simulações e serão
implementados conforme requisitados.
66
Figura 3.49: Painel de geração de erro do Menu do Operador.
3.2.3.4 – Sistema CCTV
Também é possível, dependendo da simulação, substituir a tela de controle e
geração de erros (caso não venha a ser utilizada) pelo sistema de câmera dos navios de
ambas as salas (Figura 3.50).
Figura 3.50: Sistema de CCTV do operador.
Através dos botões LabOSIM1 e 2 é possível alternar entre o CCTV de cada
sala, e com um Joystick virtual é possível controlar o ângulo de cada uma das câmeras.
A forma como o sistema foi implementado está descrita mais detalhadamente na
seção 3.2.6 – CCTV.
3.2.4 - Sistemas de navegação e localização
O sistema de navegação conta com um ou dois radares (dependendo da
embarcação) para auxiliar a navegação. O software foi desenvolvido de forma a simular
67
um radar real de embarcação, contendo assim os seus “defeitos” de visualização e sua
precisão limitada, além de simular sua taxa de atualização.
São disponibilizados também um ou dois painéis (dependendo da embarcação)
AIS (Automatic Identification System) que exibem informações de posicionamento
global do navio segundo sua carta náutica, velocidade, rotas e trajetórias, além de
informações de sensores de correnteza e direção do vento.
As informações são simuladas de forma a condizerem com o que é calculado
matematicamente e apresentado pelos visualizadores.
Nesse painel é possível traçar rotas e ter estimativas de tempo de trajetórias
relacionadas à velocidade atual da embarcação, além da visualização de alarmes e
direção de movimentação em relação ao aproamento do navio.
3.2.4.1– Radar
O software do Radar tem como principal objetivo parecer o mais realista
possível. Para isso, foi necessário simular alguns defeitos de visualização que
acontecem na vida real, como por exemplo, o Radar exibir apenas o primeiro objeto no
qual ele colide em cada direção, a imprecisão, o tipo de imagem um pouco mais
granulada e a taxa de atualização respeitando a velocidade de giro do radar.
Para implementar um radar que ao mesmo tempo fosse realista, e ainda sim
estivesse por dentro da simulação virtual do LabOSim, foram necessárias duas grandes
etapas. A primeira etapa foi a construção de um radar perfeito. Para programar toda sua
lógica de movimentação, funções, iteração com o cenário, canvas de interface do
usuário, entre outros, foram necessárias algumas adaptações. Primeiramente foi criado
um terreno todo esverdeado através da plataforma de criação de terreno do Unity, com a
forma muito próxima ao terreno real da simulação, gerado através do plug-in Mapbox já
descrito, pois além de ser muito pesado, o terreno do Mapbox vem com uma textura
pré-definida.
Ao utilizar a ferramenta de criação de terrenos do Unity (Figura 3.51) pode-se
contornar o problema do peso (uma vez que terrenos gerados no próprio Unity são bem
mais leves do que os importados) e consegue-se deixá-lo pronto para ser exibido
diretamente no radar. Essa ferramenta permite carregar um mapa de relevo em
“normalmap” (Mapas de alturas indicadas através de tons na escala de cinza, quanto
mais próximo ao branco, mais alto, figura 3.52) para dar a forma e o relevo do terreno, e
68
em seguida utilizar ferramentas de pintura e modelagem para dar os toques finais e
texturas.
Figura 3.51: Ferramenta de geração de terreno do Unity.
Figura 3.52: Normalmap utilizado no terreno do Radar.
69
Após a criação do terreno, cada navio presente na simulação recebe uma cópia
com textura verde (Figura 3.53), para que pudessem também aparecer no radar como se
fosse uma informação gerada por ele.
Figura 3.53: Navios em textura verde
O modelo 3D da ponte Rio-Niterói também recebeu a mesma textura, para ficar
condizente com o cenário. Assim, toda a cena já está pronta para o radar, porém temos
que estabelecer a lógica de visualização e os botões, para isso, foram criadas três
câmeras. A primeira câmera está definida para enxergar apenas os modelos 3D
(terrenos, navios, monumentos) e é posicionada na vertical, para ter uma vista de cima
de toda a cena, na posição aonde se encontra o navio responsável por aquele radar em
questão. A segunda câmera é programada para enxergar apenas a interface de usuário
(Canvas) onde ficam os botões e as informações para o usuário. Essa câmera está por
cima de tudo na cena, fazendo com que os botões estejam sempre nítidos e acima do
que se passa no radar.
A projeção dessas duas câmeras uma em cima da outra (Figura 3.54) (com a
segunda sobre a primeira) traz a imagem de um radar perfeito, que identifica
perfeitamente todo terreno e navios e os mostra na câmera, e pode ser controlado
através da interface gráfica da segunda câmera com botões como “Zoom” “Target”
entre outros.
70
Figura 3.54: Projeção de câmera secundária sobre primaria.
Porém, para trazer mais realismo ao radar, foi necessária a criação de uma
terceira câmera, que traz consigo os efeitos especiais da cena, entrando assim na
segunda etapa da programação do Radar, a inclusão dos efeitos. Essa terceira câmera
tem sua renderização localizada entre a primeira e a segunda, e serve como um tipo de
máscara para a cena, trazendo alguns detalhes como a taxa de atualização do radar e
algumas ranhuras na tela geradas por interferência, além de um efeito de “blur” para
fazer com que as bordas da cena estejam menos firmes, e causando assim uma
impressão mais real de um instrumento analógicos (Figura 3.56).
Figura 3.55: Imagem do radar sem os efeitos de câmera
71
Figura 3.56: Imagem do Radar com os efeitos de câmera
Para gerar a taxa de atualização do radar, foi utilizada uma imagem com
transparência circular em gradiente, fazendo com que a cena fique escura conforme ela
gira, é possível notar seu corte na parte superior da figura 3.55 e como vai clareando
conforme andamos no sentido anti-horário da imagem.
Por fim, ainda existia o problema de que todo terreno era exibido na cena,
mesmo as partes que estariam fora do alcance do radar, ou atrás de outros obstáculos.
Para resolver este problema foi utilizado uma iluminação na cena no estilo “point light”
(ponto de luz), onde toda a luz responsável por iluminar a cena parte de um ponto que se
encontra logo acima do navio que representa o radar. Dessa forma, toda parte do terreno
e objetos que ficariam atrás de algum obstáculo, ficam escondidos na sombra do
obstáculo à sua frente, e assim, não são exibidos na cena, tornando visível apenas as
partes mais altas posteriores a objetos mais próximos (Figura 3.57). Com isso também
foi possível limitar até onde a cena seria visível, alterando a intensidade dessa
iluminação, então, conforme se aumenta o ganho do radar, aumenta-se a intensidade da
luz para que uma parte mais distante do terreno se torne visível.
72
Figura 3.57: Resultado final com efeito de iluminação
Com isso o Radar se tornou bem próximo à realidade, restando apenas a
programação de suas informações a serem exibidas (Figura 3.58), que são latitude,
longitude, aproamento, velocidade, distância dos anéis e ângulo relativo do radar, além
das informações do trajeto, que são, ângulo para o trajeto, distância, curso, velocidade
relativa, e tempo estimado de chegada, e de seus botões, descritos na Tabela 3.4.
Figura 3.58: Botões, informações e trajetos
Tabela 3.4: Botões do Radar e suas funções
73
Botões Funções
ACQUIRE TARGET Cria um novo trajeto no ponto clicado no
radar.
SELECT TARGET Seleciona um trajeto para exibir suas
informações.
CANCEL TARGET Cancela trajeto selecionado.
CANCEL ALL TARGETS Cancela todos os trajetos.
+ Aproxima o zoom do radar
- Afasta o zoom do radar
HEAD UP Posiciona a marcação do radar na orientação
do aproamento do navio.
NORTH UP Posiciona o norte do radar para cima (0º)
RINGS Exibe/Oculta anéis de marcação de distância.
RADIAL Exibe/Oculta linhas radiais a cada 10 graus.
HEAD Exibe/Oculta marcação de ângulos.
BRILIANCE Ajusta o brilho da tela do radar.
GAIN Aumenta/Reduz o ganho de intensidade do
radar.
Todas as funções do radar são controladas pelo script “botoes.cs” que realiza
todos os cálculos de informações e o controle das câmeras e alguns efeitos, escreve os
valores nas variáveis e controla a interface do usuário.
3.2.4.2– Painel AIS
O painel AIS (Automatic Identification System) se utiliza da mesma carta
náutica que a parte de exibição das posições dos navios do Menu do operador, porém
disponibiliza outras informações para o usuário, e exibe apenas seu navio no mapa.
Dentre as funções do AIS estão a possibilidade de criar um trajeto a ser seguido pelo
navio, informações de aproamento, direção e velocidade de vento e correnteza, exibição
das coordenadas globais do navio, exibição de alarmes e erros, data e hora e
informações do trajeto (Figura 3.59).
74
Figura 3.59: Painel AIS.
Além de traçar o trajeto do navio, o painel também traça a rota que o navio está
percorrendo conforme se movimenta, sua curva de contorno seguro (relação entre a
direção do navio e a direção real de movimentação para que o navio não ande de lado
ou na diagonal, indicada por retângulo vermelho) e sua direção real de movimentação
(linha reta vermelha pontilhada no mapa) (Figura 3.60).
Figura 3.60: Exemplo de movimentação irregular do navio.
Na figura 3.60 pode-se notar que há um alarme ativado na lista, “Crossing safety
contour”, isso acontece pois a direção real do navio (linha preta) está fora do cone da
75
direção de movimentação do navio (linhas vermelhas sólidas). Na manobra exibida o
navio está andando para popa, na diagonal.
Também é exibida a rota gerada pelo navio, em verde, e o trajeto programado,
ponto a ponto, em laranja, além das demais informações fornecidas pelo painel,
explicitadas na Tabela 3.5.
Informação exibida Descrição
HDG (Heading) Aproamento do navio
Unidade: Graus
STW (Speed Through the Water) Velocidade do navio em relação a água
Unidade: Nós
COG (Couse Over Ground) Direção em que o navio está se movimentando (Curso do
navio)
Unidade: Graus
SOG (Speed Over Ground) Velocidade do navio em relação ao solo
Unidade: Nós
DEST (Destination) Distância para o próximo trajeto ou trajeto selecionado
Unidade: Milhas náuticas
SPD (Speed) Velocidade relativa ao próximo trajeto ou trajeto
selecionado
Unidade: Nós
TTG (Time To Target) Tempo até o próximo trajeto ou trajeto selecionado
Unidade: Hora/Minuto/Segundos
ETA (Estimate Time Arrival) Horário estimado de chegada no último trajeto
Unidade: Dia/Mês Hora/Minuto
POS (Position) Posicionamento em coordenadas globais
Unidade: Graus/Minutos/Segundos/Direção
Calendar Data e hora atual.
Alert List/Log Lista de alertas e suas descrições
Wind BRG Direção do vento
Unidade: Graus
Wind Speed Velocidade do vento
Unidade: Nós
Current Set Direção da corrente
Unidade: Gruas
Current Drift Velocidade da Corrente
Unidade: Nós
Reset Path Apaga todas as marcações no mapa (trajetos, destinos e
rotas realizadas)
76
Todas as informações exibidas são recebidas através do servidor e calculadas
quando necessárias através do script “Navegacao_Carta_Nautica”, que também
posiciona o navio no mapa e suas marcações, além de ser responsável pelo controle de
câmera (Arrasto do mouse e zoom) e do botão “Reset Path” e seleção dos trajetos.
Para adicionar um novo trajeto basta clicar com o botão central do mouse, e a
cada novo clique é ligado o trajeto anterior ao atual, na posição do mouse. Para
selecionar um trajeto ou arrastar/reposicionar, basta clicar com o botão esquerdo do
mouse sobre ele e arrastar para a posição desejada. Para apagar um trajeto basta clicar
sobre ele com o botão direito do mouse.
A data e hora do calendário é obtida através da data e hora do computador no
qual o painel AIS está sendo executado, assim como a data de ETA é calculada a partir
dela.
3.2.5- Sistemas de controle e monitoramento
O sistema é disposto ao usuário em uma série de painéis reunindo informações
sobre a embarcação e permitindo a realização de certos comandos.
O painel de console é responsável por realizar as leituras dos hardwares de
controle da embarcação, calcular suas posições e passar ao Servidor os comandos
realizados, além de exibir para o usuário informações de seu estado atual de comando
(posicionamento das alavancas de propulsores e leme) e de resposta (estado real de
aceleração dos motores e rotação do leme dentro da simulação).
Os painéis touch-screen são responsáveis pelo controle da parte mais
automatizada da embarcação, além da exibição de alguns dados ao usuário. Dentre eles
estão alarmes de erros, velocidades relativas de proa e popa, data e hora, distâncias e
tempos de viagem, entre outras informações. Também é possível realizar comandos
para a embarcação como por exemplo tocar sinal sonoro, habilitar e controlar o piloto
automático, entre outras.
3.2.5.1– Console
O painel “Console” é muito próximo visualmente ao painel de informações das
embarcações do Menu do Operador, porém um pouco mais completo, e é o painel que
controla de fato no servidor as acelerações de cada motor no navio e a posição do seu
leme.
77
Além do já descrito, o Console também exibe informações sobre as velocidades
relativas do navio, aproamento, informações de vento e correnteza e velocidade de giro
(Figura 3.61).
Figura 3.61: Console da embarcação.
Em sua versão anterior, o painel era programado utilizando a plataforma
Processing. Porém, para unificação dos sistemas e comunicação através da rede de
forma otimizada ele foi atualizado e sua versão atual, assim como os demais softwares
do simulador, é feita no Unity.
O painel recebe todas as informações de corrente, vento, velocidades,
aproamento e giro diretamente do servidor, assim como outros painéis, porém como é
de sua responsabilidade ler as informações de aceleração dos motores e leme (entradas
de comandos do usuário no simulador) ele realiza essa leitura diretamente dos
Hardwares.
Cada uma das alavancas da embarcação são potenciômetros que variam sua
tensão de 0 a 10V, e são alimentados e lidos através do sistema Wago, que disponibiliza
esse valor através da rede em uma escala hexadecimal.
O script “Console”, responsável por coordenar todas as ações do console
(escrever textos, posicionar efeitos e animações) também é responsável por realizar essa
leitura, através do arquivo XML do Wago na rede, e buscar o valor em hexadecimal de
cada sensor.
Em seguida os valores que, inicialmente variam de 0000 até FFFF que
representam de 0 a 10V são convertidos em valores de 0 até 65535, porém, devido a
78
distância entre os sensores e a fonte, a oxidação dos cabos entre outros fatores, os
valores acabam não sendo exatos.
Para isso, foi necessário a configuração de uma rotina de calibragem, que
acontece da seguinte forma, inicialmente todas as alavancas são colocadas na posição
máxima (10V) é lido separadamente o valor de cada uma delas e armazenado. Logo em
seguida, todas são colocadas no valor mínimo (0V) e o mesmo procedimento é
realizado.
Com o valor máximo e mínimo de cada alavanca salvo, é fácil mapear os valores
de 0 a 100 entre os valores mínimos e máximos lidos individualmente, garantindo assim
uma precisão muito boa para a leitura da posição das alavancas.
Após realizada a calibragem, é gerado um arquivo em .txt com os valores
calibrados para cada potenciômetro. Assim, na próxima vez que o painel for iniciado,
ele já realizará uma consulta a última calibragem disponível, mantendo-se assim sempre
calibrado.
O arquivo de calibragem também é acessado pelo painel de informações do
Menu do Operador, porém não é possível altera-lo através dele, como todos os painéis
fazem a leitura dos mesmos potenciômetros através da rede, utilizar o mesmo arquivo
de calibragem garante que a posição exibida de cada alavanca seja a mesma nos
consoles da sala e no painel de informações do Menu do Operador. Caso seja necessário
uma nova calibragem, basta apertar a tecla F1 do teclado para que seja aberta
novamente a rotina de calibragem, e instruções aparecerão na tela (Figura 3.62).
Figura 3.62: Rotina de Calibragem.
79
Ainda há também uma pequena diferença na versão do console entre as salas 1 e
2, na leitura do leme. O leme da sala 2, assim como todas as demais alavancas, são
potenciômetros, porém o leme da sala 1 é controlado por um timão, ligado a um
encoder, que tem uma frequência de saída de 2 kHz.
Devido à alta frequência do encoder, fica impossível processar sua posição
através de um programa que roda a no máximo 80 fps. Com essa limitação, o
processamento do encoder é realizado através de um Arduino, que calcula o ângulo de
giro do leme e se comunica com o painel do Console através de comunicação Serial
pela porta USB.
Como apenas o computador que está ligado à porta USB tem acesso ao Arduino,
o painel do Console também disponibiliza em rede os ângulos de leme, para que possam
ser acessadas por outros painéis e pelo servidor.
Após serem calculadas todas as posições das alavancas e do leme, o Console
reúne todas as informações de aceleração dos motores e escreve um arquivo .txt que
será lido diretamente pelo Simulador no Matlab, para que possam ser simuladas as
acelerações, obtendo-se assim as novas posições a serem enviadas para o servidor.
3.2.5.2– Painéis Touch-Screen
Os painéis Touch-Screen tratam-se de dois painéis feitos para serem exibidos em
dois monitores touch-screens de 24” por sala. Eles se comunicam com o servidor em via
de mão dupla, enviam e recebem informações, como já descrito anteriormente, e podem
ser divididos em diversas seções, que foram unidas para formarem cada um dos painéis.
O primeiro painel (display 1) pode ser dividido em 3 seções: Erros nos motores,
Controle dos motores e Sinais sonoros. A seção de erro nos motores recebe do Menu do
operador os possíveis erros simulados a afetarem a simulação, dependendo do tipo, e
podem gerar diversas consequências, que serão implementados conforme a demanda.
Ao disparar o alarme, um buzzer acoplado ao painel touch através de um Arduino é
acionado gerando um som de alarme. A seção é separada por motor, e tem um botão
80
para silenciar o alarme de cada um deles. Inicialmente alguns erros são exibidos de
exemplo, como botões que acendem conforme os erros acontecem (Figura 3.63).
Figura 3.63: Seção de erros nos motores.
A seção de controle dos motores tem alguns botões simples como ligar/desligar
motores, colocar em espera, botões de emergência e exibe o estado atual do motor, além
do seu “Pitch” (Inclinação dos motores) para os navios que tem essa função (Figura
3.64).
Figura 3.64: Seção de controle dos motores.
Cada botão acionado nessa seção, assim como os demais botões dos painéis, gera
um “beep” realizado pelo buzzer ao ser acionado.
A seção de sinais sonoros é responsável pelo controle da corneta de cada navio,
possuindo opções de toques automáticos pré-definidos e o botão de toque manual
(Figura 3.65).
81
Figura 3.65: Seção de sinais sonoros.
O segundo painel (display 2) pode ser dividido em mais 3 seções: Informações
da embarcação, Informações gerais e Piloto automático. A seção de informações do
navio exibe informações de aproamento, velocidades relativas e distâncias até um
próximo trajeto (Figura 3.66), essas informações também aparecem em outros painéis,
porém é muito comum em navios de grandes pontes de comando a redundância de
informações espalhadas em diversos painéis.
Figura 3.66: Seção de informações da embarcação.
Nela também se encontram disponíveis botões para alterar as velocidades de nós
para metros por segundo, e se estão sendo calculadas em relação a terra ou a velocidade
da água, e um botão para desativar possíveis alarmes que estejam tocando.
Na seção de informações gerais são exibidas a hora, ângulo de giro da
embarcação, a profundidade da superfície do mar abaixo do navio e o campo magnético
lido (que pode afetar possíveis bússolas ou outros instrumentos da embarcação). No
caso da simulação em questão essas duas últimas informações não são disponibilizadas.
Também há um botão de envio de sinal de emergência (Figura 3.67).
82
Figura 3.67: Seção de informações Gerais.
Por fim a última seção, piloto automático, ainda não tem uso prático
implementado, embora todos os seus botões sejam funcionais, são apenas recebidos
pelo simulador, mas não realizam resultados na simulação, está apenas em espera para
aplicações futuras. A seção conta também com um botão giratório touch que rastreia o
movimento do dedo para definir se está sendo girado no sentido horário ou anti-horário,
controlado via script (Figura 3.68).
Figura 3.68: Seção de Piloto Automático.
O programa dos painéis touchs são controlados basicamente por três scripts,
“Comunicação_Arduino” que é responsável por gerar o feedback sonoro ao aperto dos
botões e disparo dos alarmes através do buzzer, “Escrever_Displays_Touch” , que é
responsável por escrever os valores de todos os displays e botões e gerar as animações
de clique, além de rastrear os toques para posicionar o botão giratório, e
“Passagem_Parametros_Paineis_Controle” que é responsável pela comunicação com o
servidor, e recebe todas as informações a serem exibidas nos painéis, e passa para o
script de escrita nos displays.
83
Ao juntar cada uma dessas seções tem-se os painéis completos divididos em dois
monitores (Figura 3.69) que assim como em embarcações mais modernas, representam
diversas funções dos navios.
Figura 3.69: Painéis touchs exibidos nos monitores.
3.2.6 - CCTV
O simulador conta com um circuito fechado de televisão, CCTV, um programa
que se conecta ao Servidor para acessar a posição global do navio e gerar uma cena que
exibe cada “câmera” do navio, de forma similar ao funcionamento dos circuitos internos
de TV, com múltiplas câmeras sendo exibidas na tela e um controle de seleção e rotação
da câmera principal (Figuras 3.70 e 3.71).
Figura 3.70: Sistema CCTV Sala 1
84
Figura 3.71: Sistemas CCTV Sala 2
O sistema CCTV funciona na mesma forma que os visualizadores, utilizando-se
da mesma cena e mesmos scripts de controle, porém com diversas câmeras em posições
pré-definidas acopladas aos navios (Figura 3.72, 3.73).
Figura 3.72: Disposição das Câmeras no Porta-Contentor.
85
Figura 3.73: Disposição das Câmeras no TUG (Rebocador).
Os efeitos de divisão de tela para cada câmera são feitos de forma parecida ao do
utilizado no “Câmera dividida” da parte de visualização do Menu do Operador,
modificando as opções de X, Y, Width e Height de cada câmera para posicioná-la na
tela de forma correta (Figura 3.45).
Porém, devido ao baixo desempenho do computador em que se utiliza o sistema
CCTV e à grande quantidade de câmeras sendo renderizadas ao mesmo tempo, foi
observada uma grande queda na quantidade de frames por segundo (FPS) em que o
programa estava sendo executado, tornando sua utilização inviável.
Para contornar o problema, foi adicionado ao script de controle de câmera uma
rotina de otimização, que faz com que apenas a câmera principal exibida seja
renderizada em tempo real, e as demais câmeras, que são exibidas em janelas menores
estejam com taxa de atualização de 1 frame por segundo.
Ou seja, apenas a visualização principal é fluida, e as outras câmeras mantém
uma imagem fixa que se atualiza com a imagem real de 1 em 1 segundo.
Para que isso fosse possível o script “CCTV Manager”, responsável por
controlar as câmeras e definir qual está sendo exibida, foi atualizado com esta rotina que
a cada 1/6 segundos liga apenas uma câmera e desliga todas as demais, alternando entre
elas.
Com isto a taxa de atualização de quadros das câmeras por segundo total do
programa passa de 7 vezes a quantidade de frames por segundo (as 6 câmeras
secundárias mais a principal) para 1 vez a quantidade de frames por segundo mais 6 (1
quadro de cada câmera secundária por segundo) e com isso chega a uma taxa de frames
por segundo bem maior, tornando assim seu uso viável.
86
Todo o controle de seleção e rotação de câmera é realizado através de um painel
físico CCTV (Figura 3.74), conectado a um micro controlador Arduino, que se
comunica com o programa CCTV para passar as informações de controle.
Este painel conta com um manche que tem sua posição X,Y lida através de 2
potenciômetros (um representa a posição X e o outro a Y, de 0 a 5V) para o controle
fluido da câmera e sua movimentação, além de botões para alternar entre as câmeras.
Figura 3.74: Painel físico de controle do CCTV Sala 2.
No caso da sala 1, por terem mais câmeras, os botões do painel foram
substituídos por um encoder giratório que alterna entre as câmeras (Figura 3.75), este
encoder é lido através do Arduino, assim como o Leme do simulador.
Figura 3.75: Painel físico de controle CCTV Sala 1.
Em ambas as salas, os Arduinos que comandam cada painel se comunicam com
o software do CCTV através da porta USB via serial, e repassam as leituras de posição
de manche, botões e encoder cada vez que elas são alteradas.
87
Capítulo 4
Conclusões
Após todo o desenvolvimento de cada etapa do projeto e cada um dos seus
complementos, observa-se que a programação da interface gráfica e das iterações e
funções do simulador acabam se estendendo um pouco além do esperado devido à
quantidade de pequenos detalhes e problemas observados após a primeira versão testada
na prática de cada projeto.
Com isso fica clara a importância de uma reserva de contingência nos tempos de
entrega de cada projeto e da realização de diversas revisões e testes a cada pequena
etapa, além da realização de diversos métodos de realizar cada um deles, se adequando à
forma mais eficiente para o tipo de projeto.
Uma das etapas mais trabalhosas de todo o projeto foi a integração entre todos
os painéis e o servidor. Como toda a comunicação do simulador é realizada através da
rede, foram necessárias diversas adaptações para que tudo funcionasse de forma fluida e
independente, usando o mínimo de recursos e espaço possível, e uma das melhores
soluções para isso foi a alternância entre os dados de ambas as salas do simulador, que
reduziu pela metade a quantidade de variáveis a serem utilizadas, e a utilização de uma
taxa de envio mais baixa para informações discretas no tempo.
A montagem dos painéis digitais ocorreu de maneira mais rápida, pois já tinham
seu layout pré-estabelecido pelo Design Gráfico do laboratório, restando apenas
programar seu layout e suas funcionalidades.
Por parte da visualização de cena, os grandes problemas estavam relacionados à
sincronização entre as telas e à suavização das informações que vinham de forma
discreta do simulador, tendo sido esta parte resolvida através da interpolação da posição
ao longo do tempo entre cada informação recebida, já as sincronizações foram
resolvidas através da aplicação do cluster, fazendo assim com que as bordas de cada tela
estivessem perfeitamente encaixadas e com a edição das variáveis randômicas do clima
e do oceano, que passaram a ser randômicas apenas no servidor, e após definidas,
88
enviadas como valor fixo para todas as telas (como por exemplo duração de um
relâmpago ou tempo da série de Fourier que calcula o mar)..
A parte da interação entre o controle físico do usuário e o simulador foi realizada
de forma simples e eficaz, tendo sido trabalhosa apenas em sua montagem e no
tratamento das informações recebidas, disponibilizando-as de forma simples para que,
caso se faça necessária uma atualização em qualquer software do simulador, não seja
necessária refazer este segmento.
A criação do Menu do Operador passou por diversas mudanças durante seu
desenvolvimento, inicialmente projetado apenas para controle de clima e oceano,
acabou recebendo diversas modificações e atualizações durante o projeto, se tornando
até mesmo o servidor (devido ao computador mais robusto). Nele foram incluídas
diversas cenas derivadas de painéis já existentes para fazer com que quem estivesse no
controle da simulação obtivesse um panorama completo do que se passa nas salas,
ganhando assim a visualização do sistema CCTV, posição das alavancas nas salas e a
visão geral da cena.
Seu desenvolvimento foi sem dúvida um dos mais trabalhosos de todo o projeto,
pois, além de unir diversas cenas distintas e utilizar quatro monitores para exibi-las,
também foi necessária a comunicação com todos os demais painéis, leitura do sistema
Wago e a resolução de diversos problemas gerados pela utilização de múltiplas telas,
como por exemplo a posição de um componente em pixel na lógica do programa
considerando a tela atual dele.
Também foi desenvolvido para o simulador, embora não citada no projeto, uma
versão em Realidade Virtual, utilizando os óculos HTC-VIVE Porém devido a fatores
externos, não chegou a ser finalizada, deixando assim brechas para projetos futuros em
Realidade Virtual e Realidade Aumentada para o simulador.
Além de simulações em realidade virtual o projeto também abriu portas para
diversos trabalhos e pesquisas futuras em diferentes cenários, e para a inclusão de
diversos outros navios, modos de simulações e objetivos.
Como já citado no trabalho, também há uma seção em espera para o
desenvolvimento do sistema de erros, para gerar defeitos e condições adversas na
simulação, estendendo assim sua utilidade à diversas áreas, como treinamentos de
emergência, navegação em locais específicos, manobras diversas entre outras.
Por fim, o projeto teve uma realização muito satisfatória pela liberdade e apoio
cedidos pelo LabOceano para o desenvolvimento do simulador, trabalhando assim não
89
só a parte do conhecimento e pesquisa, mas também a criatividade e a capacidade de
soluções práticas e de baixo custo para a resolução dos diversos problemas que
apareceram no caminho, além de ideias para aprimoramento tanto da parte visual,
quanto da qualidade e realismo do simulador, explorando dessa forma todas as
qualidades necessárias para um bom profissional em uma área do mercado que cada vez
mais valoriza o profissional pelo seu conhecimento prático. O Link para visualização
em 360º do resultado final da sala de simulação 1 é https://goo.gl/maps/L3sPmJfESGN2
Os próximos passos de seu desenvolvimento a curto e médio prazo são a
implementação das funcionalidades restantes dos painéis, como auto piloto, painel de
erros, e a implementação de novos painéis, como painel de posicionamento dinâmico,
que já tem sua estrutura pronta para ser acrescentada, além da finalização da versão em
Realidade Virtual e pesquisas sobre Realidade Aumentada e, para longo prazo, a
implementação de novas embarcações, ou até mesmo de novos simuladores para outros
tipos de aplicações, como veículos ROV (Veiculo Submarino Operado Remotamente)
ou Submarinos.
90
Bibliografia
Unity Technologies, Unity Manual, disponível em
https://docs.unity3d.com/Manual/index.html?_ga=2.218783065.1591103071.15441
06340-2122073562.1486992334, acessado em 06/12/2018.
Ben Fry e Casey Reas. Processing Reference, disponível em
https://processing.org/reference/, acessado em 06/12/2018.
Arduino, Documentação de referência da linguagem Arduino, disponível em
https://www.arduino.cc/reference/pt/, acessado em 06/12/2018.
WAGO Kontakttechnik GmbH & Co. KG, WAGO documentação, disponível em
https://www.wago.com/global/search?q=*%3Arelevance%3AresultType%3Adownload
%3AdocCategory1%3ADL_13, acessado em 06/12/2018.
Wikipedia, Escala de Beaufort, disponível em
https://pt.wikipedia.org/wiki/Escala_de_Beaufort, acessado em 06/12/2018.
FANDOM Lifestyle Community, UniStorm Weather System Wiki, disponível em
http://unistorm-weather-system.wikia.com/wiki/Code_References, acessado em
06/12/2018
Zuzzu, PlayWay Water – High Quality Water System, disponível em
https://forum.unity.com/threads/playway-water-high-quality-water-
system.360079/, acessado em 06/12/2018
Mário Popolin Neto, Unity Cluster Package Documentation, disponível em
https://sourceforge.net/p/unityclusterpackage/wiki/Home/, acessado em 06/12/2018.
MarineTraffic, Live Map, disponível em
https://www.marinetraffic.com/en/ais/home/centerx:-12.0/centery:25.0/zoom:4,
acessado em 06/12/2018
MapBox, Maps SDK for Unity, disponível em https://www.mapbox.com/unity-
sdk/maps/overview/, acessado em 06/12/2018.
