Devido a exigência de adicionar LEDs ao circuito e de utilizar um display LCD para exibir as opções de trajeto, por meio de um menu, a placa Arduino UNO deixou de atender as nossas necessidades, devido ao pequeno número de entradas e saídas. Optou-se por usar um Arduino MEGA, que possui 53 saídas digitais, sendo que dessas 13 são PWM, possui também 16 entradas analógicas, quantidades estas que satisfizeram e irão satisfazer nossas nossa demandas nos trabalhos práticos.

Figura - Arduino MEGA

Para a nova placa de prototipagem foi construído um shield. Esse shield contém:

• Dois CIs de ponte-H L293D, que podem ser usados para acionamento de até 4 motores DC ou 2 motores de passo;

• 3 botões conectados a uma mesma entrada analógica, que são diferenciados pela tensão que chega até a porta, já que cada botão está conectado a um resistor, e dependendo de qual botão for apertado tensões diferentes chegarão a porta analógica, podendo assim serem diferenciados na progrmação;

• Barra de pinos fêmea,para alojar e acionar um display LCD 16×2;
• 2 LEDs de 3mm;
• 1 diodo retificador, para evitar que quando o Arduino estivesse conectado a porta USB este tentasse alimentar os CIs de ponte-H, ou seja, apenas tensão no sentido baterias»Vin(Arduino) são permitidas, tensões no sentido contrário são bloqueadas.

Figura - Shield para Arduino MEGA

Para projetar o shield foi utilizado o software Fritzing, que consiste em uma ferramenta open-source para design e prototipagem de PCB/Placa de fenolite, testes em protoboard e simulação de circuitos. Além disso esse software também contém ferramentas para confecção de circuito impresso, que sempre foi um dos objetivos da equipe para os nosssos circuitos eletrônicos.

Figura - Software Fritzing

Figura - Projeto e Desenho do Shield

No primeiro trabalho prático, foi notada a necessidade de uma chave que integrasse ou fizesse o isolamento entre a fonte de alimentação e o circuito eletrônico. Isso foi notado devido a dificuldade em se reprogramar o Arduino, tendo sempre que retirar os cabos de alimentação e da saída dos motores, caso contrário poderia acontecer sobretensão de alimentação do Arduino ou que as portas digitais tentassem alimentar os motores, podendo queimá-las já que estas fornecem apenas 40mA e um motor necessita mais que isso para funcionar.

Cabos e pontos de solda, mesmo que tenham sido reforçados com tubos termo retráteis, são os pontos mais frágeis dos circuitos e podem facilmente apresentar mau contato. Estes nunca devem ser utilizados em partes do sistema que estejam sujeitas a constantes mudanças. Sendo assim, as chaves e botões são componentes que podem aumentar a vida útil do circuito e facilitar os testes e programação.

Para facilitar o encaixe dos fios foram utilizados conectores do tipo kk molex, que podem ser encaixados apenas de uma maneira, impedindo reversão de polaridade e mau fucionamento do circuito.

Figura - Ítens necessários pra construção de um conector kk molex

Visto isso, foi projetado um circuito para ligação das baterias em série, com uma chave que é responsável pela liberação de tensão para o regulador, e uma saída para monitoramento de bateria.

Figura - Desenho da Placa de Alimentação

Para evitar que a tensão ficasse abaixo da qual não se consegue mais recarregar a bateria (tensão recomendada pelo fabricante da bateria), a bateria foi monitorada constantemente ao decorrer da tarefa que estivesse em execução e quando essa tensão estava abaixo da desejada acendia-se um LED pra indicar que a bateria deveria ser recarregada ou substituída.

Figura - Placa de Alimentação

Na placa há espaços para serem conectadas 4 baterias em série. Como usamos apenas duas ou três baterias, de tensão 3.7V, os pinos não utilizados foram curto-cicuitados para fechar o circuito.

O regulador de tensão utilizado é do tipo step-down, ou seja, é um abaixador de tensão. Fornecemos uma tensão acima de 7V e este regula pra a tensão que necessitamos. Essa regulagem é feita através de um trimpot, que nada mais é que um resistor variável, presente na placa. Sendo assim, nunca deve ser fornecida tensão inferior a 7V.

Durante os testes, foi usado uma fonte de tensão de tomada de 9V para evitar sobrecarregar as baterias ou ter que recarregá-las frequentemente.

Como desta vez a proposta era um robô móvel, foi criado um carrinho. Este possuía três rodas para garantir a estabilidade estática: duas normais e uma castor. A escolha dessas foi devido a praticidade que ela confere ao projeto, uma vez que seria necessário dois motores aliados com uma roda cada para as manobras e uma terceira roda sem motor apenas para servir de apoio. Cada motor controlava uma das rodas, que giravam juntas para fazer a translação ou em direções opostas para a rotação.

Figura - Roda Castor

O chassi foi construído de forma retangular onde foi possível montar uma caixa de redução satisfatória: diminuindo a velocidade para garantir um torque suficiente, além de abrigar as baterias, o Arduíno, seu shield e as outras placas como o regulador de tensão e a proteção das baterias. Devido a altura da roda castor o robô ficou em formato de torre. Os motores utilizados foram os da marca pololu, os quais já possuíam o eixo de adaptação as rodas montados. Esses foram fixados com abraçadeiras em uma peça de lego já furada.

Figura - Eixo com adaptação.

Figura - Imagem frontal do carro e de parte da caixa de redução do motor 1.

O mais importante na estrutura é que mantivesse o centro de equilíbrio do carro entre as três rodas e algumas peças especiais de lego mais pesadas foram acrescentadas para garantir isso. Garantido isso, colocamos o lápis no centro do robô para garantir um desenho mais certo. A segunda característica mais importante é que a estrutura, assim como a caixa de redução e encaixe com o motor, fosse rígida e minimizasse os efeitos das folgas e encaixes das peças. Tais características foram alcançadas.

Propostas de melhoria

• A roda castor, que servia apenas para garantia do equilíbrio e não era movida por motores, poderia ficar na parte de trás do carro e ser carregada. Assim, sua influência na direção do carro seria mínima e o controle do carro tornaria-se muito mais fácil.
• Diferentes movimentos exigem quantidades diferentes de reduções. A rotação do carrinho acontecia tranquilamente com as reduções existentes, no entanto, a precisão da translação poderia ser maior se o carro se movimentasse de forma mais lenta e com mais força. A interferência da posição das rodas também seria menor.
• O aumento da largura do robô também poderia abrigar uma caixa de redução maior, além de garantir um centro de massa mais inferior, o que aumentaria a sua estabilidade.

Dado a natureza dos percursos dessa tarefa, o robô deveria ser capaz de realizar dois movimentos básicos: translação e rotação. Como o robô foi montado com duas rodas controladas, o movimento de translação consistia em girar ambos os motores na mesma direção, enquanto no de rotação, os motores deveriam ser girados em sentidos opostos. Para facilitar a tarefa de programação dos percursos e testes, foram criadas duas funções para abstrair os movimentos do robô. A função walk e a função spin.

Ambas funções recebiam um parâmetro de potencia a ser a plicada no motor e um valor de 1 ou -1 para determinar a direção de giro. As funções utilizavam em seu calculo de tensão constantes globais de fator de correção dos motores, afim de deixar o torque gerado pelos dois motores o mais próximo possível. As funções giravam os motores usando a função spinMotor do trabalho anterior.

A navegação do menu foi feita usando duas funções: enterMenu() e selectMenu(). A função select navegava entre as opções do menu, ou seja, dado a opção sendo exibida no momento, ele determinava qual a próxima opção a ser exibida e a mostrava no lcd. A função enter era responsável por selecionar a opção sendo exibida, ou seja, dado a opção sendo exibida no momento, ela determinava a ação a ser tomada, como iniciar uma rotina de percurso ou acessar um submenu por exemplo.

A função justDOIT(int task) era responsável por executar os percursos e tarefas programados. Cada tarefa era representada por um id. Ao ser chamado, a função usava o id passado para decidir qual tarefa executar. Como algumas tarefas deviam executar multiplas funções simultaneamente, a função delay() do Arduíno não foi utilizado, por ser blocante. Desta forma a temporização foi feita manualmente usando um timer interno. Quando uma nova tarefa era selecionada para execução, o timer interno era resetado para 0 e a tarefa era executada.

Para compreensão do movimento do carro e da linearidade em função da potência, foram extraídos os seguintes dados e plotados em gráficos de Translado x Potência e Rotação x Potência.

O robô foi dimensionado para uma potencia de aproximadamente 44% e atingia uma distância entre 30 e 33 cm/unidade de tempo. Portanto, sua capacidade de movimento ia muito além da distância percorrida e toda a estrutura possibilitava isso: pouco atrito, superfície regular e rigidez na montagem das engrenagens.

Como citado anteriormente, o robô foi calibrado para um funcionamento em torno de 44% de sua potência máxima e, portanto, sua capacidade de translação/unidade de tempo também era maior do que o necessário.

Até então, o tempo limite das etapas era bem superior ao tempo utilizado para realizar cada tarefa e, portanto, a utilização de uma potência baixa e um movimento mais lento era mais interessante do ponto de vista de fornecimento de energia e sensibilidade do que altas potências com altas velocidades. Por isso, o não funcionamento em potências muito baixas não é um impedimento para o projeto.

• Triângulo

• Quadrado