Universidade Tecnológica Federal do Paraná – UTFPR

Departamento Acadêmico de Eletrônica – DAELN

Departamento Acadêmico de Informática – DAINF

Engenharia de ComputaçãoOficina de Integração 3 (IF66J) – S71 – 2017/1

Relatório TécnicoLand Tracker

Veículo semi-autônomo de rastreamento terrestre

Alan de Farias da Silva – alansilva@alunos.utfpr.edu.br

Fernando Carvalho de Souza – dosmoothpath@hotmail.com

Lucas Cardoso Polak – lucaspolak@alunos.utfpr.edu.br

Vinícius Sandri Diaz – diaz@alunos.utfpr.edu.br

Junho de 2017

Resumo

Este trabalho apresenta o desenvolvimento do projeto de um veículo deexploração de locais de difícil acesso. Seu objetivo é permitir a exploraçãoremota de terrenos e localizar objetos ou pessoas evitando riscos a explo-radores humanos. O sistema possui um pequeno veículo em campo (cha-mado de rover) com diversos sensores para a coleta de informações acercado ambiente, que serão enviadas a uma estação base por meio de comu-nicação sem fio. A estação base é um computador que, além de exibir asinformações vindas do rover, possui um software para controle remoto doveículo. Essa estação tem controle sobre quase todas as ações do rover,tais como ativação da captura de áudio e vídeo e controle de movimen-tação. Entretanto, o veículo é semi-autônomo, ou seja, recebe comandosde movimentação da estação base, contudo, caso seus sensores detectemalguma barreira intrasponível pelo caminho, de forma que seja impossívelexecutar o comando atual vindo da estação base, o veículo descarta essecomando e traça uma rota de desvio do obstáculo.

1 Introdução

Desastres naturais, bem como, aqueles causados por seres-humanos pro-duzem um grande número de vítimas, além de danos extensos à propriedade einfraestrutura. Esses eventos demonstram a necessidade do desenvolvimentode tecnologias de busca e resgate, com a finalidade de reduzir as perdas mate-riais e humanas. Robôs semi-autônomos podem ser uma solução eficiente narealização deste tipo de tarefa [1].

Robôs com a finalidade descrita acima já foram utilizados para busca de pes-soas em diversos desastres, tais como o das torres gêmeas nos Estados Unidos(2001) e o tsunami no Japão (2011) [1].

1

Relatório Técnico: Land Tracker 2

A utilização de tais robôs com autonomia ou semi-autonomia englobamtambém atividades industriais, exploração espacial e trabalhos perigosos ou re-petitivos para seres humanos [2].

Uma característica comum a esta classe de dispositivos é a necessidade denavegar pelo ambiente, reagir a estímulos e executar um determinado compor-tamento, através do controle de um software.

Este trabalho detalha o desenvolvimento do Land Tracker, um sistema de ex-ploração de locais de difícil acesso à seres humanos, controlado remotamente,inspirado na sonda Mars Rover da NASA [3].

Para tanto, o sistema possui um pequeno veículo (Rover) com câmera devídeo, microfone para captação de áudio, sensor de temperatura e giroscópiopara a coleta de informações do ambiente que são enviadas a uma estação basepor meio de comunicação sem fio.

A estação base é um computador com o software para controle remoto dorover. Essa estação permite o controle de quase todas as ações do veículo, taiscomo ativação da captura de áudio/vídeo e movimentação, entretanto o veículopossui certa autonomia para tomar pequenas decisões de deslocamento.

O diagrama que representa a relação entre o rover e a estação base encontra-se na Figura 1.

Figura 1: Visão geral do sistema

Relatório Técnico: Land Tracker 3

O Rover possui também sensoriamento de distância (através de 3 ultrassonspara detecção de barreiras, conforme apresenta a Figura 2) e um par de encodersóptoeletrônicos para medição da velocidade nas rodas traseiras do veículo.

Figura 2: Posicionamento dos sensores de ultrassom, controladores, motores edemais sensores no Rover

A estação base recebe os dados oriundos do sistema embarcado no veículo,tais dados são exibidos na interface gráfica, também utilizada para envio de co-mandos ao Rover.

Para especificar o que o projeto(Rover) deve fazer, são apresentados a seguiros requisitos Funcionais e Não-Funcionais. Os requisitos abordam as 4 prin-cipais características do projeto: Sistema Embarcado, Estação Base, Veículo eComunicação.

1.1 Requisitos Funcionais e Não Funcionais

Os requisitos funcionais descrevem explicitamente as funcionalidades e ser-viços do sistema. Como o sistema deve reagir a entradas específicas, como secomportar em determinadas situações e o que o sistema não deve fazer. Já osnão-funcionais definem propriedades e restrições do sistema, como requisitosdo produto, que especificam o comportamento do software, requisitos organi-zacionais, como consequência de políticas e procedimentos, e requisitos exter-nos derivados do ambiente ou fatores externos ao sistema [4]. Os requisitos re-ferentes a esse projeto estão listados na tabela 1.

Tabela 1: Requisitos Funcionais e Não Funcionais

Relatório Técnico: Land Tracker 4

Requisitos Funcionais Requisitos Não FuncionaisSistema deve ser capaz de obedecer aos co-mandos recebidos

O Sistema deve fazer a leitura de obstáculospresentes no ambiente por meio de ultrassom

O Sistema deve fazer a captura e envio dos da-dos de áudio e vídeo para a estação base

A aquisição de vídeo deve ser feita por meioda câmera digital específica para Raspberry Pi

O Sistema deve fazer o envio de dados de tem-peratura e umidade

O Sistema deve enviar dados de áudio e vídeopor meio do protocolo adequado

O Sistema deve ser capaz de controlar sua ve-locidade para mantê-la independente da in-clinação do terreno

O Sistema deve possuir sensores de tempera-tura com conversor AD (Analógico-digital)

O Sistema deve notificar a estação base casonão possa contornar um obstáculo

O Sistema deve possuir sensor de umidade doar

O Sistema deve possuir uma inteligência arti-ficial simples para desvio semi-autônomo deobstáculos

O Sistema deve fazer uso de giroscópio paraverificar inclinações no terreno

O operador da estação base pode ligar e desli-gar envio de áudio e vídeo

Deve haver controle da velocidade de acordocom a inclinação do terreno por meio de en-coders ópticos

O software na estação base deve possibilitar aexibição dos dados recebidos do rover em tela

O software da estação base deve ser desenvol-vido com programação orientada a objetos

A comunicação deve garantir a integridadedos comandos enviados pela estação base

A comunicação da estação base com o dispo-sitivo deve ser por protocolo TCP/IP para exe-cutar comandos de controle

A comunicação para áudio e vídeo toleraperda de dados

Um servo motor deve ser usado para controleda direção do veículo

O veículo deve ter tração somente no eixo tra-seiro

A estação deve enviar comandos via protocoloTCP devido a sua segurança

O veículo deve ter controle de direção so-mente no eixo dianteiro

Áudio e vídeo devem ser enviados via proto-colo que garanta velocidade e baixo consumode processamento no sistema embarcadoUm roteador deve ser utilizado para criar umarede interna para a comunicação da estaçãobase com o roverA tração do veículo deve ser feita por um mo-tor DC com torque suficiente para mover oveículo e manter uma velocidade estipulada

Na sequência estão descritas na Seção 2 os componentes e tecnologias utilizados neste pro-jeto. Na Seção 3 encontra-se a descrição da sequência de desenvolvimento do sistema. Na seção 4são apresentados os resultados obtidos após a implementação do projeto e por fim, na Seção 5são apresentadas as conclusões retiradas desse projeto

2 Componentes e Tecnologias

Para o desenvolvimento deste trabalho, foi necessária a utilização dos componentes e equa-ções descritas a seguir os microcontroladores utilizados, bem como os sensores de ultrassom eservo-motores, os circuitos de Ponte H utilizados para acionar o motor DC que fornece traçãoao rover, o sistema "anti-bloqueio"de tração, e os sistemas de controle (software). A tabela 3apresenta os componentes físicos utilizados nesse projeto.

Relatório Técnico: Land Tracker 5

2.1 Microcontroladores

Os microcontroladores utilizados foram um Raspberry Pi 3 [5] e o Arduíno Nano [6].O primeiro é o controlador principal do sistema embarcado, onde se encontram o servidor

que recebe os comandos da estação base, o sistema de streaming de áudio e vídeo e o controle doArduino.

Este último é responsável pelo controle dos servo-motores e leitura dos encoders das rodas.

2.2 Equipamentos Eletromecânicos

Nesta seção serão descritos os componentes eletromecânicos utilizados no projeto.

2.2.1 Sensor Ultrassônico

O dispositivo do sensor é composto por um emissor e um receptor de ultrassom. A onda ge-rada pelo emissor percorre o meio, reflete nos objetos e retorna ao receptor através da reflexão [7].

O trajeto feito pela onda ocupa um determinado tempo. Este tempo é medido e combinadocom o valor da velocidade do som. Desta forma, pode-se utilizar o valor da velocidade do som noar e o tempo decorrido entre a emissão do sinal e a recepção de seu eco para calcular o compri-mento da trajetória percorrida pela onda segundo a Equação 1 [8]:

x(t ) = v · t (1)

Na Equação 1, x é a distância percorrida pelo pulso de onda em metros, v é a velocidadeconstante da onda sonora no ar em m/s e t é o tempo em segundos necessário para o pulsoemitido pelo sensor refletir em um obstáculo e retornar. Considerando que, a onda percorre xmetros até encontrar o obstáculo e mais x para retornar ao receptor, é necessário dividir o valorda distância encontrada através da Equação 1 para obter a distância real do emissor até o objeto:

y(t ) = v · t

2(2)

De posse das Equações 1 e 2, é possível calcular a distância do sensor ultrassônico até abarreira que refletiu o sinal, dentro dos limites de alcance do sensor.

2.2.2 Servo Motor

Servo motor é um dispositivo eletromecânico, de movimento proporcional e de malha fe-chada, que possui diversos formatos semelhantes ao da Figura 3.

Figura 3: Servo MotorFonte: http://dan-scientia.blogspot.com.br/2011/10/o-que-e-amostra-em-audio-

digital.html

Esse dispositivo recebe um sinal de controle, verifica a posição atual e se movimenta paraa posição desejada [9]. Assim, através de um sinal PWM (Modulação por Largura de Pulso) emsua entrada, é possível rotacionar o atuador à um ângulo específico. Os servo motores utilizadosneste projeto apresentam movimentos de 0° à 180° e são utilizados para o controle da direção doRover, bem como, para rotacionar o sensor de ultrassom e a câmera para algum ângulo desejado.

Relatório Técnico: Land Tracker 6

O servo utilizado para os sensores de ultrassom e para a câmera, são do modelo Micro Servo 9gSG-90 [10], igual ao da Figura 3.

2.3 Ponte H

Para controlar o motor DC, é necessário o uso de um modulo de controle da velocidade. Aponte H, é uma solução comum para controle de motores DC. Este dispositivo, utiliza chavea-mento de transistores para controlar a direção da corrente nos polos de saída, através de umaentrada digital. A figura 4 abaixo ilustra este funcionamento.

Figura 4: Funcionamento da Ponte HFonte: Autoria Própria

Considerando que o motor DC (Representado pela letra M na figura 4) apresenta seus polosconectados aos pontos A e B, com dos dois pinos de controle em nível baixo, não há circulação decorrente e o motor encontra-se desligado (representado em vermelho).

Quando um dos pinos de controle apresenta nível alto a corrente circula em um sentido (emazul). Analogamente, invertendo o sinal dos pinos de controle, o sentido de circulação da cor-rente é invertido (em verde).

Com estas três configurações, é possível controlar o sentido da rotação do motor, através docontrole do sentido da corrente, bem como sua velocidade de rotação, utilizando o conceito dePWM. Tal conceito refere-se ao controle do tempo de ativação do motor. Alternando o estadodo motor, entre ativado e desativado, além de controlar a porção de tempo em que o motor per-manece em cada estado. Dessa forma, a velocidade do motor será proporcional ao tempo deativação, sendo que a velocidade máxima corresponde ao motor sempre ativado.

Por ser um componente comum, existem diversos modelos no mercado. Procuramos esco-lher o modelo que mais se adequava ao projeto, considerando as especificações do motor e ocusto-benefício. Desta forma, o modelo escolhido pela equipe é uma Ponte H com fornecimentomáximo de 2A. Assim, foi escolhido o modulo 2x2A DC Motor Shield, ilustrado na figura 5, daDFRobot, baseado no CI LM298, frequentemente utilizado em outros módulos de Ponte H. Estemodulo se encarrega do controle de direção e velocidade de até dois motores, fornecendo até 2Apara cada motor.

Relatório Técnico: Land Tracker 7

Figura 5: Modulo 2x2A DC Motor Shield da DFRobotFonte: https://www.dfrobot.com/product-69.html

O controle é feito com a utilização de 2 pinos para cada motor. A tabela de controle paraum dos motores está ilustrada na tabela 2, onde E1 e M1 representam os pinos de controle, Lrepresenta estado logico baixo, H alto e X representa qualquer valor. O pino E1, além dos estadosbaixo e alto, também pode receber um valor analógico dentro da faixa de 0 a 255, que atua comovalor intermediário. Este valor é transformado pelo modulo da Ponte H no tempo de ativação,e consequente velocidade de rotação do motor. Essa possibilidade é representada pelo estado"PWM"na tabela.

Tabela 2: Tabela de Controle para um Motor DCE1 M1 EstadoL X Motor 1 DesativadoH H Motor 1 Reverso

PMW X Controle de Velocidade por PWMFonte: Adaptado de https:

//www.dfrobot.com/wiki/index.php/Arduino_Motor_Shield_(L298N)_(SKU:DRI0009)

Além disso, esse modulo permite que a alimentação dos motores seja feita através de umafonte externa, isolando o sinal de controle. Desta forma, é desacoplado o sinal enviado pelo Rasp-berry Pi para a ponte H, do sinal de ativação dos motores. Com isso, permite evitar danos ao con-trolador Raspberry Pi e possibilitando que os sinais de controle de 3.3V, vindos do controlador,consigam efetivamente acionar um Motor DC de 12V.

2.3.1 Motor DC

Devido a proposta do veículo ser capaz de explorar ambientes de difícil acesso, foi necessárioum motor com torque suficiente para suportar o peso total do dispositivo, bem como, superarterrenos inclinados e acidentados. Desta forma, para um torque estimado com uma margem desegurança, que considera situação de estresse para dispositivo, como sobrepeso e inclinação doterreno, foi calculado o valor mínimo de 7kg f .cm, através da Equação 3, na qual R representa oraio da roda do veículo e F a força incidente em um caso de esforço extremo.

T = F ·R (3)

No entanto, além da estimativa de torque, foi necessário considerar as dimensões geométri-cas do motor, devido a baixa possibilidade de adaptações no chassis. Considerando as restriçõese após testes com diferentes motores, o motor escolhido para este projeto foi um Micro Motor DC,com caixa de redução, de 12V , 83RP M e torque de 11.10K g f .cm[11], semelhante ao da Figura 6.

Relatório Técnico: Land Tracker 8

Figura 6: Motor DC

Devido à escolha desse motor de baixa rotação, somado à caixa de redução presente no chas-sis e as engrenagens acopladas, a velocidade máxima do veículo foi adotada como a velocidadenominal de operação.

2.3.2 Sistema anti-blocante

O chassis utilizado no Rover [12] possui um sistema antiblocante no eixo diferencial traseiro.Esse sistema impede que o motor de tração trave mesmo que as rodas estejam completamentetravadas. Entretanto, esse sistema apresentava desgaste, impedindo a tração máxima do motor.Esse problema foi corrigido aumentando-se o atrito entre o disco da engrenagem que entra emcontato com o disco do eixo de tração.

Esse sistema apresenta um funcionamento muito semelhante à um sistema de embreagemautomotiva, como o apresentado na Figura 7

Figura 7: Esquema de embreagem similar ao anti-blocante.Imagem adaptada do site: http://www.autozone.com/repairguides/GM-Blazer-Jimmy-

Typhoon-Bravada-1983-1993-Repair-Guide/CLUTCH/Clutch-Disc-and-Pressure-Plate/_/P-0900c1528003dbbb

Na Figura 7, nota-se que a transferência da rotação do motor para a engrenagem ligada aoeixo de tração ocorre através do atrito entre a peça acoplada ao eixo do motor e o disco do sistemaanti-blocante. Quando as rodas travam a ponto de romper o atrito estático entre o disco anti-blocante, a engrenagem de tração e a peça acoplada ao eixo do motor, o sistema gira em falsosem transferir a potência para as rodas, evitando o travamento do motor e o consequente picoelétrico de corrente no sistema.

2.4 Sotware e Algoritmos

2.4.1 Servidor e cliente no sistema embarcado

Para permitir a transmissão e recepção de dados do dispositivo, por comunicação sem fio,foi escolhida a comunicação sem fio (Wi-Fi) [13]. Esse modelo de comunicação foi utilizado de-vido à sua velocidade e largura de banda, próprias para streaming multimídia e por permitir acomunicação entre Rover e a estação-base sem a necessidade de cabeamento [13]. O que com-prometeria a mobilidade do veículo. O protocolo utilizado pelo sistema foi o TCP/IP. Para isso, foinecessário que o sistema embarcado possua um servidor, com uma porta de recepção dos dadostransmitidos pela estação base. Por outro lado, o sistema também possuí um cliente para enviar

Relatório Técnico: Land Tracker 9

os dados coletados em campo para a estação base. Para deixar o sistema ágil e integrado com asdemais partes do sistema embarcado, o cliente e o servidor foram implementados em linguagemC++.

Do lado do servidor, foi necessário abrir um socket em uma porta e defini-lo como "listen-ning", ou seja, um socket para receber dados que chegam na porta definida. O software que im-plementa o servidor fica esperando uma requisição de conexão. Posteriormente, após recebê-la,aguardará o envio de dados. Desta forma, é necessário que o servidor seja executado em uma th-read do sistema e, sempre que receber pacote de dados, tome as devidas medidas para processá-lo, sem interromper, por longos períodos de tempo, as demais linhas de execução do sistema, taiscomo o sensoriamento do ambiente.

2.4.2 Sistema Operacional Raspbian

O Raspbian é um sistema operacional derivado do Debian para o Raspberry Pi. O Raspbianfoi criado em 2015 e o seu nome, é oriundo da composição de Raspberry Pi e Debian [14]. Atu-almente, é o principal sistema operacional suportado pela Fundação Raspberry Pi. O sistema éaltamente otimizado para a arquitetura ARM utilizada nos projetos da Fundação [14].

2.4.3 Prioridade do software embarcado no Raspbian

Como foi utilizado o sistema Raspbian, um sistema operacional Linux derivado do Debian,as prioridades dos softwares executados nesse S.O. variam de 20 (menos prioritário) à -20 (maisprioritário). É importante manter o sistema embarcado desenvolvido em prioridade máxima,para que tenha preferência de execução no momento do escalonamento do sistema operacional.Para isso, utiliza-se uma chamada de sistema para requisitar prioridade máxima para o programaque gerencia o dispositivo.

2.5 Softwares de Streaming de áudio e vídeo

Para a realização da streaming de vídeo, foi escolhida a ferramenta de linha de comandoraspivid [15] para a captura do vídeo. A saída desse comando foi utilizada como entrada para osoftware Netcat, uma ferramenta gratuita que pode ler e escrever em conexões de rede utilizandoo protocolo TCP/IP [16]. Um script em linguagem Bash foi gerado contendo a concatenação doscomandos raspivid e netcat, direcionando a streaming de vídeo para o Ip e porta específicos daestação base, que exibe o vídeo recebido por meio do software MPlayer [17].

A transmissão de áudio utilizou a mesma lógica da transmissão de vídeo. Um software delinha de comando, nesse caso o Arecord [18] foi utilizado para a captura do áudio e, os dados queesse arquivo gera como saída (o áudio) são passados como parâmetro de entrada do Netcat, querealiza a streaming do áudio para o mesmo Ip da Estação Base, porém para uma porta diferente.

A estação base recebe os dados de áudio via Netcat e utiliza outra funcionalidade em linhade comando do linux, o Aplay, para reproduzir o áudio recebido.

Inicialmente pensou-se em utilizar ferramentas que implementassem o protocolo UDP ouRTP, protocolos mais comuns quando se trata de streaming. Entretanto, toda ferramenta testadaque utiliza algum dos dois protocolos consumia demasiado processamento no sistema embar-cado, tornando essa opção inviável, conforme está descrito na seção de Resultados.

2.6 Algoritmos de Controle

Dentro dessa seção, são discutidos os três principais algoritmos de controle utilizados, res-ponsáveis pela semiautonomia do veículo. São estes: controle de movimentação, detecção deobstáculo e desvio de obstáculo.

Relatório Técnico: Land Tracker 10

2.6.1 Controle de Movimentação

Os comandos de movimentação da estação base somente ativam os motores. O controleda distância percorrida e subsequente desativação dos motores é realizada por uma rotina detratamento de interrupção. As interrupções geradas pelos encoders são utilizadas para o cálculoda distância percorrida, e esta é comparada a distância objetivo. Quando a distância percorridacalculada atinge a distância objetivo, os motores são desativados e a rotina encerrada.

2.6.2 Detecção de Obstáculo

Para evitar batidas com objetos, caso algum comando recebido da estação base coloque oRover em rota de colisão, foi utilizada uma rotina de detecção de obstáculo e desativação dos mo-tores. Desta forma, com base na resposta dos sensores ultrassônicos é possível detectar colisões.Tal rotina consiste em: analisar os dados dos sensores, identificar algum obstáculo, comparandoas medidas de distância com um threshold de detecção e, por fim, interromper a ativação dosmotores, mesmo que a distancia objetivo, enviada pela estação base, não tenha sido atingida. Porfim, é acionado a rotina de desvio que está descrita em detalhes na Seção 2.6.3.

Devido ao posicionamento dos sensores ultrassônicos, bem como à precisão desses com-ponentes, a rotina é capaz de detectar obstáculos em um arco de 45° em frente ao rover. Umterceiro sensor ultrassônico, acoplado ao ponto mais alto do veículo, evita que o mesmo entre emaberturas sem altura mínima.

2.6.3 Desvio de Obstáculo

Ao detectar um obstáculo, a rotina de desvio é acionada. Essa rotina inicia uma busca porbrechas pelas quais o Rover consiga passar para continuar sua trajetória, fazendo uma varredurado ambiente em 180° (90° para a esquerda e 90° para a direita a partir da frente do Rover) com osultrassons e utilizando a resposta desses ultrassons para verificar a existência de brechas. Casoalguma brecha seja detectada, a sua amplitude é calculado.

Com os tamanhos calculados, é escolhida a brecha de maior tamanho para o desvio. Deacordo com a posição da brecha, é gerada uma lista de comandos para desvio a direita ou a es-querda. Essa lista de comandos é adicionada a lista de execução, encerrando a rotina de desvio.

3 Sequência de desenvolvimento

De posse dos componentes, softwares e conhecimentos, realizou-se a integração das partesdescritas nessa seção.

A primeira etapa realizada foi a confecção das partes mecânicas e estruturais necessáriaspara os acoplamentos dos componentes eletromecânicos no chassis.

Posteriormente, realizou-se a implementação dos servidores e clientes TCP para o envio/recepçãode comandos. Entre estes comandos, foram implementados os de movimentação do veículo, ati-vação/desativação de streaming e controle de servo-motores.

Em sequência foram implementados os streamings de áudio e vídeo, e a última parte à serintegrada no projeto foi a inteligência artificial.

4 Resultados

Nesta seção estão descritos os resultados obtidos nos testes realizados com o sistema.

Relatório Técnico: Land Tracker 11

4.1 Tabela de Custos

No início do projeto foi realizado um orçamento prévio de todos os componentes previstospara uso durante todo o projeto, uma superestimativa do custo total, devido a falta de conheci-mento, a priori, de todos os valores e componentes.

Após a pesquisa, escolha e compra dos componentes, foi gerada uma nova tabela de custos,apresentada na Tabela 3, que contém todos os valores de componentes utilizados.

Tabela 3: Tabela de custos.

4.2 Testes de campo

No decorrer do desenvolvimento do projeto, cada etapa implementada foi seguida de testespara verificar a efetividade das soluções. A Figura 8 apresenta um dos primeiros testes de mo-vimentação do dispositivo. Este teste foi realizado após a instalação do motor de tração. Nesteteste, o veículo recebia comandos da estação base e deveria transpor o pequeno obstáculo emsua frente.

Relatório Técnico: Land Tracker 12

Figura 8: Primeiro teste de transposição de pequeno obstáculo.Fonte: Autoria própria

Pela imagem pode-se verificar que o veículo foi bem sucedido em completar sua tarefa. En-tretanto, nos demais testes realizados com obstáculos leves (com menos de 200g ) e soltos no chãonotou-se que o Rover apresentava dificuldades em transpor estes obstáculos. O dispositivo porvezes arrasta os objetos, sem transpor os mesmos. Esse fato, por vezes provocava um desvio in-desejável de rota, visto que o objeto preso às rodas dianteiras forçava o eixo frontal do veículo.A solução encontrada foi aumentar o peso do Rover para forçar um maior atrito entre as rodase o obstáculo, permitindo desta forma, transpor a barreira, além do ajuste do mecanismo anti-blocante que aumentou a tração das rodas, como já citado previamente.

Outros testes em um terreno mais acidentado foram realizados, com objetivo de testar a tra-ção do motor e a capacidade do Rover de transpor obstáculos maiores que o apresentado ante-riormente. A imagem 9 apresenta um dos testes realizados em campo com o Rover, no qual oveículo subiu uma rampa e transpôs um pequeno degrau.

Figura 9: Teste de stress do Rover.Fonte: Autoria própria

Relatório Técnico: Land Tracker 13

4.3 Testes de comunicação Multimídia

Foram realizados testes com as bibliotecas de streaming VLC e ffmpeg. Também foram rea-lizados testes de streaming via netcat. A primeira biblioteca consumiu aproximadamente 80% deprocessamento do microcontrolador e a segunda aproximadamente 25%. O streaming por net-cat consumiu no geral menos de 1%. Desta forma, a melhor solução foi utilizar o serviço netcat,direcionando para uma porta IP específica para o streaming.

4.4 Testes de Alcance e Autonomia

Nesta Seção, estão os resultados do alcance da rede do Rover, bem como, da autonomia dabateria.

4.4.1 Alcance da Rede

Para análise do alcance da rede wifi, foi utilizado o software Wifi Analyser, que é um aplicativopara Android, capaz de apresentar a qualidade do sinal de acordo com a atenuação em dB.

Os nossos resultados demonstram que em um raio de 25m, com interferência de outras redese obstáculos físicos a atenuação máxima foi de -80dBm. Com esse sinal, a velocidade de trans-missão máxima foi de 36 mbps.

Em área aberta, com distâncias de até 25m a atenuação máxima foi de -64dB. Com esse sinal,a velocidade de transmissão máxima é de 54 mbps.

4.4.2 Autonomia das Baterias

A alimentação dos componentes foi dividida em dois módulos. Um deles engloba somente oMotor DC de 12V. O outro representa o controlador Raspberry PI e todos os periféricos conectadosa ele, ou seja, todos os sensores e servo motores de 5V e 3.3V .

A alimentação dos dois módulos foi realizada através de Baterias Li-Po idênticas. Ambasapresentam tensão nominal de 14.8V e capacidade máxima de 2650mAH. Tomando a utilizaçãoda bateria pelo Motor DC como pior caso, extrapolando para a pior situação onde o motor estáativo sempre em velocidade máxima, com consumo constante de 2A, a autonomia para uma ba-teria que fornece 2650mAH é dada pela equação 4.

Autonomi a = 2650m AH

2000m A= 1.325H ≈ 1Hor a (4)

Porém, considerando o pior caso a utilização da bateria pelo outro módulo que contém ocontrolador, sensores e servos, extrapolando para a situação onde todos os componentes são uti-lizados todo o tempo em situação de stress (com carga nos servos, alto processamento no contro-lador), o resultado é um consumo constante de 6A como mostra a equação 5. Para este consumo,a autonomia é dada pela equação 6

C ar g a = 2A(Contr ol ador )+2.5A(Ser vos)+1.5A(Sensor es) = 6A = 6000m AH (5)

Autonomi a = 2650m AH

6000m AH= 0.44H ≈ 25Mi nutos (6)

5 Conclusão

Entre as dificuldades encontradas no desenvolvimento do projeto, podemos destacar o aco-plamento mecânico. Esta parte mostrou-se um desafio, devido a sua exigência por habilidadesdistintas das vistas neste curso de engenharia. Desta forma, o acoplamento do motor no chassis,bem como, os ajustes no sistema anti-blocante foram um desafio considerável a equipe.

Relatório Técnico: Land Tracker 14

Na implementação de streaming um desafio a ser destacado, foi a implementação da trans-missão de áudio com a mesma eficiência que a transmissão de vídeo. A transmissão de vídeo, ape-sar de exigir maior banda na transmissão de dados, possui codecs mais otimizados no RaspberryPi. Com isso, inicialmente a transmissão de vídeo apresentava desempenho superior a transmis-são de áudio. A solução adotada pela equipe foi utilizar o serviço netcat.

Outro desafio superado foi a limitação de pinos com PWM por hardware no Raspberry Pi.Inicialmente a equipe buscou implementar PWM por software no Raspberry, no entanto, o de-sempenho não foi satisfatório. A solução encontrada foi passar a geração do PWM dos servomotores para um segundo controlador (o Arduíno) via comunicação I2C entre o Raspberry Pi e oArduino Nano. Desta forma, foi possível controlar os quatro servo-motores previstos inicialmenteno projeto.

O veículo Rover apresentou facilidade em transpor obstáculos firmes e estáveis em seu tra-jeto. Isso é devido ao torque do motor do dispositivo, que foi dimensionado para cargas superi-ores as utilizadas no projeto. No entanto, em objetos muito leves e soltos, foi observado que oRover apresentava dificuldades em transpor. Esse problema foi solucionado com o aumento nopeso do Rover, resultante da evolução do protótipo, além do ajuste do mecanismo anti-blocanteque aumentou a tração das rodas, forçando um maior atrito com os obstáculos, permitindo destaforma, transpor as barreiras.

No decorrer do projeto, a equipe sofreu a desistência de um de seus integrantes. Desta forma,as atividades que estavam previstas para o mesmo executar, precisaram ser redistribuídas entreos demais membros da equipe.

Ao integrar os componentes do projeto, nos testes realizados pela equipe, o protótipo cons-truído apresentou desempenho satisfatório no que tange a movimentação em terrenos com re-levo pouco acidentado. A comunicação da estação-base com o sistema embarcado foi fluída, nãoapresentando problemas na interpretação dos comandos e no envio de dados.

Desta forma, podemos concluir que o projeto atendeu as etapas esperadas de acordo com ocronograma proposto de forma satisfatória.

Referências

[1] Julio Vilela Yugang Liu, Goldie Nejat. Learning based semi-autonomous control for robotsin urban search and rescue. IEEE, 2012.

[2] George A. Bekey. Autonomous Robots. MIT Press, 2005.

[3] Mars Exploration Rover Mission: Home. https://mars.nasa.gov/mer/home/.

[4] Eduardo Figueiredo. Requisitos funcionais e requisitos não funcionais. Disponível em:<http://homepages.dcc.ufmg.br/ figueiredo/disciplinas/aulas/req-funcional-rnf_v01.pdf>.Acesso em 14 de junho de 2017.

[5] Raspberry Pi. Raspberry pi 3 model b. https://www.raspberrypi.org/products/raspberry-pi-3-model-b/>. Acesso em 06 de junho de 2017.

[6] Arduino nano. Disponível em: <https://www.arduino.cc/en/Guide/ArduinoNano>. Acessoem 07 de maio de 2017.

[7] Daniel Thomazini and Pedro U. B Albuquerque. Sensores Industriais Fundamentos e Aplica-ções. Érica, 4 edition, 2012.

[8] Paul A Tipler and Gene P Mosca. Física para cientistas e engenheiros: Mecânica; Oscilações eOndas, Termodinâmic, volume 1. LTC, 6 edition, 2012.

[9] Max A. Denket. Frontiers in Robotics Research. Nova Publishers, 2006.

[10] Micro Servo. Sg90 9 g micro servo. Disponível em: <http://www.micropik.com/PDF/SG90Servo.pdf>.Acesso em 09 de maio de 2017.

[11] Neoyama. Ak555/11.1pf12r83ce-v2. Disponível em: <http://www.micro-motor-dc-c-cx-red-tensao-1200-vdc-rpm-83-rpm/>. Acesso em 09 de maio de 2017.

Relatório Técnico: Land Tracker 15

[12] Traxxas. Vxl 3607. Disponível em: <https://traxxas.com/products/models/electric/3607-2012>. Acesso em 09 de maio de 2017.

[13] Jing-Yuan Yeh and Chienhua Chen. Support of multimedia services with the ieee 802-11 macprotocol. In Communications, 2002. ICC 2002. IEEE International Conference on, volume 1,pages 600–604. IEEE, 2002.

[14] FrontPage - Raspbian. Disponível em: <https://www.raspbian.org.html:text/html>. Acessoem 13 de junho de 2017.

[15] Raspiberry Pi Documentation. Raspivid. Disponível em:<https://www.raspberrypi.org/documentation/usage/camera/raspicam/raspivid.md>.Acesso em 12 de junho de 2017.

[16] Giovanni Giacobbi. The gnu netcat project. Disponível em:<http://netcat.sourceforge.net/>. Acesso em 12 de junho de 2017.

[17] MPlayer. Mplayer features. Disponível em: <http://mplayerhq.hu/design7/info.html>.Acesso em 12 de junho de 2017.

[18] Arecord. Arecord. Disponível em: <http://linuxcommand.org/man_pages/arecord1.html>.Acesso em 12 de junho de 2017.