Câmpus Itajaí - Departamento de Engenharia Elétrica - Bacharelado em Engenharia Elétrica

Desenvolvimento de simulador 3D de máquina portuária do tipo Reach Stacker

Alunos: Fabricio Simoes Fonseca Hermes, Isabelli Sasdelli Tavares e Nefi Augusto de Nobrega Estork.

Orientador: Prof. Sergio A. B. Petrovcic, Dr. Eng.

Desenvolvimento

Partes Mecânicas

Partes Eletrônicas

Comunicação Arduíno com Unity

Simulação 3D

Download de arquivos do projeto

Desenvolvimento

As atividades a desenvolvidas foram divididas de acordo com sua respectiva categoria: documentação e entregas, mecânicas, eletrônicas, programação e simulação 3D, de acordo com o cronograma.

Inicialmente, foram realizados alguns estudos para o projeto, como a plataforma escolhida, a Unity, os materiais da cabine da RSK, os pedais e a comunicação serial do Arduíno.

Partes Mecânicas

Para os pedais, optou-se por desenvolver o pedal de freio e utilizar o pedal de RSK modelo DRS por sua robustez, sendo este por empréstimo, pois possui alto custo para aquisição e a intenção é desenvolver um produto com melhor custo benefício. A seguir, nas Figuras 1 e 2, são mostrados um pedal de RSK modelo DRS (utilizado), composto por um potênciometro acoplado pela parte mecânica que faz o movimento e interpreta a intensidade da aceleração, assim como um contato lógico no qual detecta que o acelerador está sendo acionado. Para a base de suporte do acelerador e do freio foi selecionado um tapete de borracha para carro anexado a um compensado de 7 mm.

O volante foi desenvolvido projetando um caixa de madeira com buracos de 22 mm ao centro nas partes da frente, do meio e internamente na parte de trás, o mesmo diâmetro do rolamento encaixados, nestes buracos, com uma barra roscada conectada no encoder ao fundo. Na figura 3 e 4 mostra o volante de um Renault Clio 2019 que foi definido por se adequar ao tamanho de um volante de RSK.

A base do joystick foi a mesma utilizada pelo "Testador de Joystick", projeto anterior realizado na unidade curricular de Projeto Integrador 2.

Figura 1: Pintura do pedal.

Fonte: Autores

Figura 2: Construção do pedal.

Fonte: Autores

Figura 3: Pedais para simulação.

Fonte: Autores

Figura 4: Pedal de RSK modelo DRS visão lateral.

Fonte: Autores

Figura 5: Construção da caixa para volante.

Fonte: Autores

Figura 6: Montagem da caixa.

Fonte: Autores

Figura 7: Volante pronto

Fonte: Autores

Explicação do funcionamento mecânico do cockpit.

VID_20220305_205610491.mp4

Fonte: Autores.

Partes Eletrônicas

Os componentes utilizados foram:

1 Arduíno Leonardo cujo o esquemático está disponível nos arquivos de projeto (Anexo C);
1 encoder de 600 pulsos;
1 joystick da máquina, cujo diagrama elétrico está disponível nos arquivos de projeto (Anexo A), que consta com 3 botões digitais e 3 potenciômetros;
1 potenciômetro para o pedal de freio;
1 potenciômetro para pedal de acelerador;
1 botoeira funcionando como chave para escolha das direções (frente e ré).

Tabela 1: Pinagem utilizada no Arduíno Leonardo.

PINAGEM ARDUINO LEONARDO

Fonte: Autores.

Comunicação Arduíno com Unity

A programação dos scritps para o funcionamento e comunicação entre Arduino e Unity 3D foi feita no programa Visual Studios na linguagem C#. Já a definição dos pinos analógicos e digitais foi feito no próprio programa do Arduino (Figura 8), para um tesde inicial de comunicação. O esquemático da conexão pode ser visto na Figura 9 e a Figura 10 representa o teste de movimentação integrando Arduino e Unity 3D.

Figura 8: Código no Arduíno para comunicação serial.

Fonte: Autores.

Figura 9: Esquemático dos componentes utilizados no teste.

Fonte: Autores.

Figura 10: Software Unity 3D e Arduíno para teste de movimentação.

Fonte: Autores.

A comunicação do Arduíno Leonardo com o Unity se deu por meio do programa de configuração de joystick EMC FFB Utility (Figura 11). Para a utilização deste programa foi necessário modificar a memória EEPROM (Electrally Eresable Programable Read-only Memory) do Arduíno Leonardo (Anexo D) que deixou de se comportar com as funções padrões de fábrica e passou a se dedicar como um hardware do EMC. Para o Carregamento da nova programação foi utilizado o Software Xloader (Figura 12) no modo bootloader do Arduíno.

Após essa configuração, foi necessário calibrar o joystick como periférico e depois associar cada componente dentro do Unity, através do sistema de Input Manager (Figura 13).

Figura 11: Programa para configuração do cockpit

Fonte: Autores.

Figura 12: Programa para carregar EEPROM

Fonte: Autores.

Calibração joystick parte 2.mp4

Fonte: Autores.

Calibração joystick.mp4

Fonte: Autores.

Figura 13: Configuração do joystick Arduino no Unity.

Fonte: Autores.

Foram feitos scripts para a movimentação da lança no sentido de recolher e estender, movimentação do spreader no sentido de abrir, fechar, deslocar para direita e deslocar para a esquerda, e movimentação das rodas para direcionamento e rotação.

Os scripts estão disponíveis nos arquivos para download, no Anexo D.

Simulação 3D

Na parte de simulação 3D, foi feita primeiramente a criação de um cenário simples, a fim de se familiarizar com esse tipo de objeto. Depois, alguns objetos foram adicionados, como um contêiner, com modelo adquirido na loja oficial da Unity. Também foi incluído um veículo genérico de exemplo, do tipo carro, e feito sua movimentação através de potenciômetros (componente eletrônico dos pedais), simulando um volante e troca de marchas para alteração de velocidade. Nesse momento, foi testada a comunicação serial com o Arduino e os conceitos de rigid body, de colisão.

A decisão pela compra de um modelo 3D comercial da máquina foi em virtude da discrepância de aparência e, principalmente, funcionalidade quando comparada aos modelos gratuitos, e modelar a máquina do zero estava fora do escopo deste projeto. Abaixo, seguem imagens (Figuras 14 e 15) de comparação entre um modelo 3D gratuito encontrado semlhante à maquina e o modelo 3D adquirido.

Figura 14: Modelo RSK gratuito.

Fonte: 3D Warehouse.

Figura 15: Modelo RSK adquirido.

Fonte: Autores.

A criação do cenário do software foi inspirado em uma imagem real do porto de Itajaí. A faixa amarela hachurada indica a área da parte de trás dos guindastes, denominada de back reach e de proibido colocar materiais. O espaço entre o rio e a back reach representa o cais, local dos guindastes. As setas representam indicação de fluxo de veículos, como a máquina reach stacker, os caminhões terminal tractors, os veículos de apoio/veículos utilitários e a van para transporte de passageiros. Esses elementos foram criados através de planos e texturas no Unity.

As pilhas dos contêineres são de largura e altura variáveis, de acordo com o cenário operacional, portanto, não houve um padrão de altura para as pilhas, simulando diversos cenários possíveis e respeitando o limite de no máximo 5 contêineres empilhados. Os contêineres podem ser de tamanhos diferentes, sendo os suportados pelo spreader da RSK os de 20 e 40 pés de largura. Para as diferentes empresas (armadores portuários) foram inseridos texturas personalizadas para os contêineres.

Os contêineres no cenário do Unity foram inseridos com base na criação de um modelo prefab, recurso do software para facilitar a alteração de propriedades dos objetos após sua criação. Assim, todos os contêineres possuem rigid body, para aplicar conceitos físicos como massa e centro de gravidade, colisores, para definir o limite espacial do objeto e assim não é possível apenas atravessá-lo. No total, foram inseridos cerca de 400 contêineres em diferentes posições e de diferentes empresas.

Para o piso, foram aplicados desníveis, como buracos e elevações, simulando as irregularidades que podem ser encontradas no chão e desnivelar a máquina, além da aplicação de uma textura imitando um asfalto.

Figura 16: Porto de Itajaí.

Fonte: Flickr APM Terminals.

Figura 17: Cenário na Unity 3D, visão lateral.

Fonte: Autores.

Figura 18: Cenário na Unity 3D, visão aérea.

Fonte: Autores.

Figura 19: Contêineres de diferentes tamanhos e estilizados.

Fonte: Autores.

Antes de iniciar a programação dos scripts da máquina, primeiro foi necessário utilizar o software 3DS Max, da AutoDesk, para fazer alguns ajustes dos objetos da máquina. Inicialmente, todas as partes vieram como objetos separados e com nomes genéricos codificados. Na roda, por exemplo, não havia o conjunto definido com aro, pneu, roda e eixo diferencial, e nem os componentes estavam prontos para realizar a movimentação e translação no eixo correto, a exemplo da rotação do pneu. Essa estapa adicional no projeto não estava prevista e demandou uma considerável carga horária, iniciando com a familiarização com o 3DS Max, aprender a utilizar o software, e constantemente exportar os modelos.

Para controle de versão durante o desenvolvimento, foi utilizado uma planilha no Google Drive compartilhado do projeto, adotando um padrão para o nome do arquivo, e anotando informações como usuário que atualizou por último, data e hora e as informações relevantes da alteração (Anexo B).

A princípio, todo o projeto seria compartilhado através de um repositório no GitHub, porém os arquivos ultrapassavam o limite permitido de 50MB. Considerou-se o recurso de utilizar o recurso do Git Ignore e fazer o upload apenas do modelo da máquina, mas apenas o arquivo da RSK possui cerca de 200MB. Esse fator também influenciou o andamento do projeto, pois era necessário se certificar que o arquivo alterado estava funcionando antes de disponibilizar, dificultando o trabalho em equipe.

Figura 20: Hierarquia no Unity, com os objetos todos separados e não nomeados de acordo com sua função.

Fonte: Autores.

Figura 21: Objetos não agrupados e para o conjunto exemplo de pneus.

Fonte: Autores.

No vídeo ao lado é possível verificar que os objetos referentes à movimentação dos pneus não estão agrupados, e também demonstra a rotação nos eixos.

Esse fator faz com que os objetos não trabalhem juntos, bem como suas caracterísitcas físicas da Unity 3D, como texturas e materiais aplicados.

RSK - Unity3D - SampleScene - PC, Mac & Linux Standalone - Unity 2020.3.9f1 Personal_ _DX11_ 2022-01-26 15-54-17.mp4

Fonte: Autores.

Para resolver tal problema, as partes interessadas foram reagrupadas, modificando a hierarquia, no 3DS Max. Assim, os pneus dianteiros esquerdo e direito internos e externos e os pneus traseiros podem trabalhar juntos, facilitando a programação de deslocamento e rotação, conforme demonstra vídeo ao lado.

O mesmo conceito foi aplicado aos twistlocks, que são os pinos de travamento do spreader no contêineres.

AGRUPAMENTO NO 3DS MAX.mkv

Fonte: Autores.

Ao lado, segue melhor explicação do procedimento realizado.

Fonte: Autores.

Ao lado, segue conjuntos definidos após agrupamento para melhor programação.

Os conjuntos definidos são, basicamente: eixos dianteiros e traseiros, cabine do operador, spreader e lança, carcaça/estrutura da máquina e demais cabos e conexões (mangueiras hidráulicas).

Para complementar a máquina, foi adicionado, dentro do Unity, a iluminação de acoplamento do spreader, conhecida popularmente como "3 marias". Essa iluminação fica localizada na máquina real na parte final da lança, conforme Figura 22. A iluminação foi desenvolvida com a criação de textura e adicionando LightPoints de acordo com a cor de cada luz.

Figura 22: Localização da iluminação na máquina.