Universidade Federal do Rio de Janeiro. Escola Politécnica. Departamento de Eletrônica e de Computação

Transcrição

1 Universidade Federal do Rio de Janeiro Escola Politécnica Departamento de Eletrônica e de Computação Projeto da Eletrônica Embarcada para um Robô Móvel Aplicado a Atividades de Terapia Ocupacional Autor: Orientador: Rafael dos Santos de Oliveira Coorientador: Ramon Romankevicius Costa, D.Sc. Examinador: Rodrigo Fonseca Carneiro Examinador: Fernando Cesar Lizarralde, D.Sc. Alessandro Jacoud Peixoto, D.Sc. DEL Março de 2014

2 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 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). ii

3 DEDICATÓRIA Dedico este trabalho ao povo brasileiro que contribuiu de forma significativa à minha formação e estada nesta Universidade. Este projeto é uma pequena forma de retribuir o investimento e confiança em mim depositados. iii

4 AGRADECIMENTO Agradeço em primeiro lugar a Deus. Sem sua Graça, eu nada poderia ter feito. Agradeço à minha família, que sempre me apoiou e me incentivou a estudar e a não desistir dos meus sonhos. Sem seu apoio, não teria conseguido trilhar o caminho que me fez chegar até o fim deste curso. Agradeço a meus professores. Cada um deles teve um papel essencial, ensinando importantes lições que vão muito além do conteúdo do curso. Agradeço a meus amigos e a meus colegas. As amizades formadas dentro e fora deste curso facilitam essa caminhada e tornam prazeroso o dia-a-dia em meio a aulas e provas. iv

5 RESUMO O presente trabalho trata do desenvolvimento da eletrônica embarcada necessária para controlar um robô móvel a ser utilizado em atividades de Terapia Ocupacional. Nessas atividades, o robô receberá comandos de um usuário via rede Wi-Fi para realizar pinturas sobre uma tela de papel seguindo uma trajetória aleatória. A velocidade de deslocamento do robô e a cor da tinta sendo utilizada serão selecionáveis pelo usuário a distância a partir de um computador, funcionando como console de comando. Dentre as várias partes desse projeto, envolvendo áreas de eletrônica, mecânica e software, este trabalho apresenta o desenvolvimento da parte principal da eletrônica embarcada: seu módulo de controle. Tal módulo é responsável por receber os comandos do usuário via Wi-Fi e gerar os sinais elétricos correspondentes para o controle dos motores. Além disso, o módulo de controle é responsável pela navegação do robô. Visto que o usuário não guiará o robô, este deverá ter um mínimo grau de autonomia para navegar em seu ambiente de trabalho desviando de obstáculos detectados através de sensores. Portanto, o trabalho também inclui o desenvolvimento de uma parte computacional que guiará o robô em seu trajeto através de sua eletrônica embarcada. Por fim, os desafios da implementação do trabalho e seus resultados serão apresentados. Palavras-Chave: robótica, Wi-Fi, TCP, teleoperação, controle, acionamento de motores DC, pintura v

6 ABSTRACT The present work deals with the development of the embedded electronics required to control a mobile robot to be utilized in Occupational Therapy activities. In such activities, the robot will receive commands from a user via Wi-Fi network to perform paintings on a paper screen following a random trajectory. The user will be able to select the robot s speed and the ink color in use from a remote computer. Among the various parts of this project, involving electronics, mechanics, and software areas, this work presents the development of the embedded electronics main part: its control module. This module is responsible for receiving the user commands via Wi-Fi and for generating the corresponding electric signals to control the robot s motors. Besides that, the control module is responsible for the robot s navigation. The user will not guide the robot. This way, it should have a minimum degree of autonomy in order to navigate its work environment avoiding obstacles detected by sensors. Therefore, this work also includes the development of a computational component that will guide the robot on its path through its embedded electronics. Finally, this work s implementation challenges and its results will be presented. Keywords: robotics, Wi-Fi, TCP, teleoperation, control, DC motor driving, painting vi

7 SIGLAS ASCII - do inglês, American Standard Code for Information Interchange BJT - do inglês, Bipolar Junction Transistor (Transistor Bipolar de Junção) BSS - Basic Service Set (Conjunto Básico de Serviços) COPPE - Instituto Alberto Luiz Coimbra de Pós-Graduação e Pesquisa em Engenharia CPU - do inglês, Central Processing Unit (Unidade de Processamento Central) DC - do inglês, Direct Current (Corrente Contínua) DHCP - do inglês, Dynamic Host Configuration Protocol EEPROM - do inglês, Electrically Erasable Programmable Read-Only Memory IGBT - do inglês, Insulated-Gate Bipolar Transistor (Transistor Bipolar de Porta- Isolada) IP - do inglês, Internet Protocol LABCON - Laboratório de Controle do Programa de Engenharia Elétrica da COPPE/UFRJ. MOSFET - do inglês, Metal-Oxide-Semiconductor Field-Effect Transistor (Transistor de Efeito de Campo de Metal-Óxido-Semicondutor) PC - do inglês, Personal Computer (Computador Pessoal) PWM - do inglês, Pulse Width Modulation (Modulação por Largura de Pulso). RAM - do inglês, Random Access Memory (Memória de Acesso Aleatório) vii

8 SSID - do inglês, Service Set IDentifier TCP - do inglês, Transmission Control Protocol UART - do inglês, Universal Assynchronous Receiver Transmitter UFRJ - Universidade Federal do Rio de Janeiro USART - do inglês, Universal Synchronous Assynchronous Receiver Transmitter WLAN - do inglês, Wireless Local Area Network (Rede de Área Local sem Fio) viii

9 Sumário 1 Introdução Tema Delimitação Organização do Sistema As Atividades Justificativa Objetivos Metodologia Descrição Especificações do Projeto Comunicação Navegação Pintura Componentes Principais Módulo Wi-Fi Módulo RN-XV Sistema de Tração Motores DC Modelo do Motor Torque Drivers Circuito Integrado L298N Driver dos Motores das Bombas ix

10 3.3.1 Bombas Peristálticas Circuito Integrado L293D Microcontrolador Arquitetura Básica de um Microcontrolador ATmega Desenvolvimento Desenvolvimento do Hardware Projeto da Placa de Controle Central Projeto da Placa de Drivers Desenvolvimento Computacional Firmware Comunicação a partir do PC Implementação do Projeto Configuração do Módulo Wi-Fi Implementação do Firmware Implementação do Hardware Dificuldades Encontradas Conclusões e Trabalhos Futuros 47 A Redes Locais Sem Fio 49 B Protocolo IP 51 C Protocolo TCP 55 D Controle de Velocidade via PWM 57 Bibliografia 59 x

11 Lista de Figuras 1.1 Diagrama de blocos geral do sistema em que o trabalho está envolvido Exemplos de acionadores (PELOSI, 2011) Esquema de uma área de trabalho Topologia de uma ponte H (Fonte: Arquitetura básica de um microcontrolador Diagrama esquemático da placa de controle central Diagrama esquemático da placa dos drivers Fluxograma principal do firmware Diagrama de transição de estados da Máquina Diagrama de transição de estados da Máquina Disposição dos sensores de colisão Módulo Wi-Fi RN-XV (Fonte: Adaptador USB para o Módulo Wi-Fi (ROGERCOM, 2014) Programador para microcontroladores PIC utilizado no projeto (Fonte: Manual do fabricante, fornecido com o produto) Plataforma robótica utilizada para testes Diagrama esquemático do circuito de testes Conjunto de baterias de 2500 mah Conjunto de baterias de 2300 mah Robô de testes montado B.1 Camadas da suíte de protocolos da Internet (STRABELLO, 2010) D.1 Exemplos de sinais PWM (OLSON, 2013)) xi

12 Lista de Tabelas 3.1 Estimativas da parte mecânica do robô Especificações de um motor que atende às estimativas de torque do projeto B.1 Exemplo de endereço IP xii

13 Capítulo 1 Introdução 1.1 Tema Este trabalho trata do projeto de sistemas de controle. No presente caso, a ênfase se dá no controle digital de dispositivos robóticos semiautônomos telecomandados por meio de uma infraestrutura de rede sem fio. 1.2 Delimitação Pessoas portadores de deficiência física ou mental têm sua capacidade de expressão limitada devido à perda de movimentos ou a limitações na capacidade de raciocínio. A Terapia Ocupacional visa cuidar da melhoria da qualidade de vida dessas pessoas utilizando recursos variados, tais como atividades de entretenimento. Com esse fim, professoras do curso de Terapia Ocupacional da UFRJ encomendaram à empresa júnior Fluxo Consultoria desta universidade o projeto de um robô para ser utilizado em atividades de expressão artística envolvendo pintura. A Fluxo e o Laboratório de Controle (LABCON) do Programa de Engenharia Elétrica (PEE) da COPPE estão desenvolvendo este projeto em conjunto e com o auxílio de alunos, cada um destes encarregado de uma das três partes principais: eletrônica embarcada, software e mecânica. O presente projeto visa a desenvolver a parte principal da eletrônica embarcada: o módulo de controle do robô. Um projeto de graduação anterior (STRACHAN, 2012) já havia sido realizado a esse respeito. Nesse trabalho, no entanto, foram utilizados motores de passo 1

14 para a tração do robô e um módulo Bluetooth para a comunicação com o PC do usuário. O trabalho atual apresenta uma solução utilizando motores DC do tipo brushed para tração e um módulo Wi-Fi para a comunicação Organização do Sistema A Figura 1.1 apresenta o diagrama de blocos geral do sistema em que este trabalho está envolvido. A equipe de software é responsável pelos programas que estarão em execução no computador do usuário. Contudo, o driver de comunicação, que implementa a troca de dados com o robô através de protocolos específicos, constitui parte das responsabilidades da equipe da eletrônica. Esta também desenvolverá a parte relacionada aos sensores, módulo de controle, bateria e driver de acionamento. A equipe da mecânica é responsável pela especificação dos motores e das bombas de tinta, além de toda a parte estrutural do robô. Figura 1.1: Diagrama de blocos geral do sistema em que o trabalho está envolvido Neste trabalho, será abordado o projeto do módulo de controle e dos drivers de acionamento do do robô. 2

15 1.2.2 As Atividades As atividades de Terapia Ocupacional em que o robô estará envolvido consistirão de um usuário acionar comandos de seleção de velocidade e cor e enviá-los para o robô através de uma interface gráfica num computador pessoal. O robô, então, executará uma trajetória aleatória liberando a tinta sobre a tela que portará a pintura. Ao longo do trajeto, a velocidade e a cor da tinta poderão ser mudadas através dos controles na interface. Esses comandos serão enviados do computador do usuário para o robô via rede Wi-Fi. Como os usuários em que se foca esse trabalho serão pessoas portando as mais diversas deficiências físicas e motoras, os controles da interface deverão ser simples. Por isso, as professoras pretendem utilizar dispositivos de tecnologia assistiva chamados acionadores (PELOSI, 2011). Na Figura 1.2, são mostrados alguns exemplos de acionadores que poderão ser usados no projeto. Estes dispositivos são basicamente diferentes espécies de botões adaptados a diversos tipos de deficiências físicas e motoras. Desse modo, os controles serão apenas comandos de seleção, sem envolver controles de direção e de velocidade lineares e iterativos, como joysticks. Embora existam alguns modelos de joysticks utilizados em tecnologia assistiva, estes não serão utilizados neste projeto. Com isso, para gerar uma certa forma de expressão artística, o robô deverá mover-se por si próprio sem necessitar de um usuário indicando cada direção para onde ir. Tal aspecto requer um nível mínimo de autonomia do robô para que ele não seja danificado ou acabe ficando preso num canto após uma colisão. Figura 1.2: Exemplos de acionadores (PELOSI, 2011). 3

16 Nas atividades de Terapia Ocupacional, o robô atuará, a princípio, dentro de uma área retangular delimitada (ver Figura 1.3). Pequenas tábuas podem ser dispostas no entorno, formando paredes, para impedir que o robô saia de sua área de trabalho e acabe derramando tinta em local indesejado. Figura 1.3: Esquema de uma área de trabalho 1.3 Justificativa Com o desenvolvimento e a redução de custos da tecnologia computacional, robôs móveis hoje em dia são capazes de integrar uma grande quantidade de periféricos para auxiliá-los em sua navegação e controle. Dentre estes, dispositivos de comunicação via redes sem fio vêm ganhando destaque nos últimos anos, como é o caso dos dispositivos Zigbee (BARONTI et al., 2007), por exemplo, que se tornaram bastante populares nessa área. Além deles, entretanto, o emprego de dispositivos que fazem uso de padrões de rede já existentes, como Bluetooth e Wi-Fi, vem crescendo, devido ao barateamento dessas tecnologias e à sua popularidade. Com isso, tornouse possível a construção, a relativo baixo custo, de robôs teleoperados por meio de rede sem fio. Inclusive, alguns modelos comerciais já se encontram disponíveis no mercado há alguns anos (BONA; PRENTICE, 2009). Empregando a tecnologia de rede Wi-Fi para comunicação, um robô pode ser controlado a distância a partir de computadores pessoais e dispositivos móveis, como smartphones, sem a necessidade de hardware adicional por parte do operador remoto, devido à presença dessa tecnologia já integrada nesses dispositivos. Para 4

17 isso, contudo, vários desafios têm de ser superados, de modo a poder oferecer um produto final funcional e utilizável para usuários leigos quanto à área de redes. Além dos desafios por parte da comunicação, a interface com dispositivos mecânicos encontrados em sistemas robóticos utilizando motores elétricos também envolve desafios relacionados à eletrônica de potência. Esta área lida com o acionamento e o controle de dispositivos de potência elevada em relação ao dispositivo controlador. Cuidados com o interfaceamento e a possibilidade de interferências dificultam os projetos nessa área. Estas questões também serão abordadas neste trabalho. Por fim, o algoritmo necessário para prover o robô com certo grau de autonomia durante a execução de suas tarefas também será abordado no trabalho. Isto requererá o emprego de algumas técnicas simples de navegação autônoma. Desse modo, o estudo apresentado neste trabalho envolverá diversas áreas da Engenharia Eletrônica e sua integração num único projeto. 1.4 Objetivos Este trabalho objetiva desenvolver um circuito eletrônico capaz de receber comandos via rede Wi-Fi e decodificá-los em sinais elétricos para o acionamento de motores de tração e de bombas de tinta e controlar a navegação empregando sistemas de detecção de colisão. A unidade de controle central deste circuito também deverá ser capaz de gerar os movimentos que o robô executará durante seu deslocamento. 1.5 Metodologia Para cumprir os objetivos especificados, a seguinte sequência de tarefas foi planejada para o projeto da eletrônica embarcada do robô como um todo. Especificação das funcionalidades Primeiramente serão levantadas as especificações quanto às funcionalidades do projeto com base nas exigências das atividades de terapia ocupacional em que o robô estará envolvido. 5

18 Especificação de hardware Com base nas funções esperadas da parte eletrônica do projeto, um hardware eletrônico mínimo poderá ser especificado. Dentre essas especificações, podemos ter as características necessárias da unidade de controle central do robô, do módulo de comunicação, dos drivers dos motores, das baterias etc. Projeto do hardware Nesta fase, temos o projeto e construção dos circuitos principais do hardware eletrônico com base nas especificações levantadas anteriormente. Desenvolvimento do firmware Com a unidade de controle central e seus circuitos de interface construídos, o trabalho prosseguirá para o desenvolvimento e teste das rotinas de código que serão executadas na unidade de controle central. Tais rotinas serão desenvolvidas para controlar os motores e outros atuadores que vierem a ser incluídos no robô, detectar obstáculos, comunicar-se com o PC do usuário e decodificar os comandos recebidos. Com os testes, novas especificações podem ser levantadas para o hardware. Finalização do hardware Tendo sido testadas e desenvolvidas as rotinas, especificações resultantes para o hardware serão levantadas a partir de testes com a parte mecânica do robô, que já deverá estar pronta a esse ponto. A bateria e os circuitos de alimentação serão desenvolvidos. Com isso, o trabalho prosseguirá para ajustes no projeto do hardware e a implementação de um sistema final. Desenvolvimento de biblioteca para comunicação com o robô pelo o software do PC Uma biblioteca com funções para a comunicação entre o computador do usuário do robô será desenvolvida em uma última fase para que as funcionalidades do robô possam ser acessadas pela programa que contém a interface gráfica. Testes finais Após o desenvolvimento do protótipo, testes gerais serão realizados para avaliar a integração das partes mecânica e de software com a eletrônica embarcada 6

19 do robô. Com esses testes, ajustes poderão ser feitos no hardware para a finalização e entrega de um dispositivo funcional e utilizável. Neste trabalho, entretanto, serão abordadas apenas as tarefas descritas até o item Desenvolvimento do firmware. As outras tarefas são dependentes da conclusão dos trabalhos das outras equipes do projeto, responsáveis pela mecânica e pelo software, para ajustes e integração. 1.6 Descrição No capítulo 2, serão apresentadas as especificações do projeto, descrevendo suas partes principais e os requisitos necessários. O capítulo 3 apresenta os componentes principais da parte de controle da eletrônica embarcada e aspectos teóricos de seu funcionamento. Já o desenvolvimento do projeto a partir das especificações, fazendo uso dos componentes principais, é apresentado no capítulo 4. A seguir, o capítulo 5 descreve como se deu a implementação do trabalho realizado e os testes. Por fim, a conclusão é feita no capítulo 6 com recomendações para trabalhos futuros. 7

20 Capítulo 2 Especificações do Projeto Estes capítulo descreve as especificações básicas do projeto com base nas exigências das atividades em que o robô estará envolvido. 2.1 Comunicação Para que haja troca de dados entre o robô e o computador do usuário, o robô deverá estar conectado a uma rede Wi-Fi. Para que isso ocorra, existem basicamente duas possibilidades: 1. O robô se conecta a uma rede Wi-Fi pré-existente. 2. O usuário conecta seu computador a uma rede Wi-Fi em que o robô é o ponto de acesso. Ambas as opções possuem vantagens e desvantagens. Na opção 1, o usuário poderia fazer uso de sua rede Wi-Fi já existente ou criar uma nova. O robô, no entanto, teria que ter as informações de acesso da rede, como, por exemplo, o nome da rede e a senha, armazenadas em sua memória. Portanto, de alguma forma transferir esses dados teriam que ser previamente transferidos para o robô. Ou, no caso de ser criada uma rede nova, o robô poderia ser programado a se conectar sempre a uma rede com nome e senha já pré-programados em sua memória. O usuário, então, quando quisesse se conectar ao robô, criaria essa rede com informações de acesso predeterminadas. 8

21 Na opção 2, o robô lançaria sua própria rede e o computador do usuário seria conectado a esta. Com isso, o usuário teria que desconectar seu computador de qualquer rede a que já estivesse conectado. Algo que poderia acontecer seria o usuário perder sua conexão com a Internet, caso estivesse tendo este acesso por meio de uma conexão compartilhada proveniente de um roteador, por exemplo. Existem problemas também relacionados ao endereço IP que o robô estaria utilizando. Contudo, uma análise mais detalhada dessas opções e mais detalhes sobre redes Wi-Fi, envolvendo suas características e sua arquitetura, serão apresentados na Seção 3.1. Os comandos a serem enviados ao robô serão números correspondentes à velocidade de deslocamento do robô e à cor da tinta utilizada. Estes comandos serão enviados para o robô por meio da rede Wi-Fi utilizando estruturas de dados com formato padronizado de modo que o robô saiba identificar os pacotes de dados certos e extrair as informações que precisa. Mais detalhes sobre os comandos e sua implementação serão discutidos na Seção Navegação O robô deverá ser capaz de calcular seus próprios movimentos, mantendo uma velocidade de deslocamento determinada pelo usuário. Para isso, o robô poderia seguir formas geométricas pré-definidas, como círculos, retângulos e outros polígonos, ou gerar movimentos aleatórios, sem seguir um padrão em particular. Segundo as exigências feitas pelas clientes, no entanto, a forma escolhida seria a de gerar movimentos aleatórios. Por outro lado, para qualquer uma das opções de movimentação, o robô necessitaria de um certo grau de autonomia para detectar colisões e corrigir sua trajetória. A detecção de colisões, ou possíveis colisões, com obstáculos pode se dar de várias maneiras. Todavia, para este trabalho foram consideradas algumas das mais simples, utilizando sensores de toque ou sensores de proximidade e a detecção sem sensores (DOISY, 2012), que baseia-se no monitoramento do torque exercido pelos motores da tração. 9

22 2.3 Pintura Para realizar a pintura, pretende-se que o robô utilize bombas peristálticas. Elas apresentam mecanismos simples e relativamente compactos para serem incluídos no robô, além de geralmente serem controladas por motores DC. Devem ser utilizadas quatro cores para a pintura. O usuário selecionará a cor pela interface, e o computador enviará o comando correspondente via Wi-Fi para o robô. Este, a partir da decodificação do comando, acionará a bomba correspondente. Cada bomba funcionará como um injetor independente. O controle das mesmas será feito a partir da velocidade de rotação de seu motor. Deste modo, poderá ser feito um controle de dosagem de cada tinta. Existe também a possibilidade de se oferecer uma gama maior de cores para o usuário a partir do acionamento simultâneo de mais de uma bomba de tinta e o controle da vazão de cada uma. Tendo quatro cores básicas, como ciano, magenta, amarelo e preto, do modelo CMYK (Cyan Magenta Yellow black ), seria possível, a princípio oferecer qualquer cor de pigmentação ao usuário (GALER; HORVAT, 2003). Embora o foco deste trabalho não esteja na arte visual em si, o hardware do robô pode ser preparado para ter essa opção futuramente implementada a nível de firmware, isto é, a nível de programação do microcontrolador. 10

23 Capítulo 3 Componentes Principais Neste capítulo serão apresentados os componentes principais da eletrônica embarcada do robô e alguns dos princípios teóricos que regem seu funcionamento. 3.1 Módulo Wi-Fi Redes Wi-Fi TM estão amplamente presentes em uma diversidade de ambientes modernos, envolvendo desde casas a empresas de grande porte, por si só ou sendo parte de uma rede maior. Isto inclui a conexão à Internet, que acaba sendo um grande fator motivador para o emprego dessa tecnologia. Devido a essa popularização, tem-se facilitado a implementação de redes Wi-Fi pela redução de custos e a diversificação de produtos capazes de se comunicar via Wi-Fi. O acesso à Internet permite monitorar e controlar dispositivos à distância. O termo Internet das Coisas identifica as tecnologias que têm sido desenvolvidas com o fim de formar redes envolvendo dispositivos do mundo real de todos os tipos, tais como eletrodomésticos, redes de sensores, televisores etc., conectados à Internet, acessíveis de qualquer lugar (BRECH et al., 2013). Com isso, tem ocorrido um aumento no número e na diversidade de ferramentas de desenvolvimento disponíveis para a criação de produtos capazes de se conectar à rede. Uma delas é o módulo Wi-Fi utilizado neste projeto. Em comparação com o Bluetooth R, a capacidade de se conectar via Wi-Fi é mais facilmente encontrada em laptops, por estes serem dispositivos portáteis e muito utilizados para acesso à Internet. Redes Wi-Fi são inerentemente expansíveis, 11

24 enquanto o Bluetooth é voltado para a comunicação ponto-a-ponto. A troca de dados em redes Wi-Fi pode ser feita utilizando os já bem estabelecidos protocolos para comunicação via Internet em redes cabeadas. Estes e outros aspectos estão mais detalhados nos apêndices A, B e C deste documento. Além disso, dispositivos Wi-Fi apresentam maior alcance via rádio e menor consumo de energia quando não estão trocando dados (FRIEDMAN; KOGAN; KRIVOLAPOV, 2013) Módulo RN-XV O módulo de rádio RN-XV (ROVING NETWORKS, 2012) é um dispositivo de acesso a redes locais sem fio. Algumas características desse módulo são listadas abaixo. Suporta os padrões IEEE b/g Implementa pilha TCP/IP completa internamente; Possui baixo consumo de potência; Possui sistema de gerenciamento de consumo inteligente; Faz interface de hardware via TTL UART; Pode ser configurado via Wi-Fi ou UART usando comandos ASCII simples; Conecta-se a redes operando em modo ad hoc ou infraestrutura. Suporta mecanismos de autenticação: WEP, WPA-PSK (TKIP) e WPA2- PSK. Suporta operar como Ponto de Acesso; Possui várias aplicações de rede embutidas: TCP, UDP, cliente HTTP, Telnet, cliente e servidor (no modo Ponto de Acesso) DHCP, entre outras. Este módulo foi escolhido para o projeto por: suportar os padrões Wi-Fi b/g, largamente empregados por computadores pessoais, celulares e tablets; 12

25 ter uma interface de hardware simples de utilizar via UART (Universal Assynchronous Receiver Transmitter); implementar a pilha TCP/IP por completo internamente; possuir uma interface de comandos ASCII simples de utilizar; e por ter um custo de aquisição relativamente baixo. Os padrões IEEE b e g são emendas ao padrão IEEE original que estabelecem especificações para a comunicação via Wi-Fi utilizando técnicas de modulação diferentes para a transmissão dos sinais. A principal diferença, no entanto, está na taxa de transmissão de dados que cada padrão consegue atingir. O b alcança um taxa de dados bruta de 11 Mbits/s, enquanto o g chega a 54 Mbits/s. Contudo, ambos os padrões utilizam sinais de portadora na banda de frequência de 2.4 GHz, que é compartilhada por outros sistemas de comunicação sem fio a curta distância, tais como o Bluetooth, telefones sem fio etc. Deste modo, os padrões b/g estão sujeitos a interferência de dispositivos operando em sistemas totalmente diferentes. Por outro lado, há menores exigências quanto ao hardware do que em outros padrões, como n, que operam em frequências mais altas. A capacidade de comunicação via UART é facilmente encontrada pela maioria dos microcontroladores para uso em sistemas eletrônicos embarcados atualmente. Estes, geralmente, oferecem periféricos internos que lidam com essa comunicação para o firmware do usuário de maneira automática, sem serem necessários muitas configurações, e utilizando poucos pinos do microcontrolador. 3.2 Sistema de Tração Os motores de tração formarão um sistema de direção diferencial (RIBEIRO; LIMA, 2012). Neste tipo de sistema, duas rodas motrizes independentes produzem a tração para mover o robô. A direção que o robô segue é controlada pela diferença entre as velocidades de rotação das rodas. Por exemplo, se a roda da esquerda está girando a uma velocidade menor que a da direita, o robô tenderá a virar para a esquerda. Semelhantemente, o robô pode girar em torno de seu eixo vertical, sem 13

26 se deslocar, ao fazer as duas rodas girarem na mesma velocidade, mas em sentidos de rotação opostos em relação ao eixo horizontal que as une Motores DC Motores DC são motores elétricos operando à base de corrente contínua. Eles podem ser encontrados em diferentes tipos, dentre eles, temos alguns principais: motores com escova (brushed) e motores sem escova (brushless). Os motores brushed são constituídos por um eixo girante contendo um ou mais enrolamentos de fios conectados a comutadores acionados por escovas em meio a um campo magnético fixo (CONDIT, 2010). Tal conjunto de enrolamentos é chamado armadura. A corrente elétrica flui por um enrolamento quando os contatos dos comutadores fecham circuito com as escovas, que são fixas e estão ligadas aos terminais do motor. Nisto, um campo magnético desalinhado com o campo fixo é gerado, forçando o rotor a se mover. Logo que um enrolamento perde contato, outro é acionado. Este ciclo se repete, e o motor segue girando. Motores brushless utilizam na verdade corrente alternada para produzir um campo magnético girante em enrolamentos fixos que propulsiona um rotor de ímãs permanentes (YEDAMALE, 2003). Estas correntes são geradas, no entanto, a partir de circuitos inversores alimentados por tensões elétricas DC. A perda de contato momentânea nos motores brushed várias vezes seguidas a cada segundo acabam produzindo ruído na corrente do motor que pode passar para as linhas de alimentação ou se propagar por ondas eletromagnéticas (WONG, 2012) e interferir em outras partes do circuito, que podem ser sensíveis a ruído. Isto os torna menos vantajosos para operações com circuitos de comunicação em relação aos motores brushless. Estes possuem comutação eletrônica, gerando muito menos ruído (YEDAMALE, 2003). No entanto, este tipo de comutação exige drivers de hardware muito mais complexos, o que proporciona aos motores brushless um custo maior que os do tipo brushed em geral. Motores de passo também podem ser classificados como um tipo especial de motores DC do tipo brushless, por operarem à base de corrente contínua em suas bobinas e por não apresentarem escovas para o contato elétrico. Este tipo de motor é encontrado em tipos diferentes no mercado (CONDIT; JONES, 2004). Contudo, 14

27 como característica geral, eles rotacionam em passos discretos. Seus estatores são constituídos por um número de bobinas responsáveis por gerar o campo magnético que irá impulsionar o rotor. Para que haja rotação, é necessário que haja um acionamento em sequência dessas bobinas para que o rotor entre em rotação um passo após o outro. Deste modo, é possível conhecer a posição e a velocidade de rotação do rotor, mesmo em sistemas de malha aberta, a partir da contagem e da frequência dos pulsos, respectivamente, o que seria vantajoso em diversas aplicações. Motores de passo apresentam algumas desvantagens em relação aos outros tipos de motores apresentados (NI, 2011). Dentre elas, esse tipo de motor consomem corrente independentemente da carga, visto que suas bobinas precisam estar sendo sempre chaveadas para este girar. Portanto, mesmo a uma carga mecânica reduzida, o motor continuará consumindo uma corrente elevada para se manter parado ou girando. Eles também necessitam de uma eletrônica de chaveamento e sequenciamento, mesmo no controle em malha aberta, que é mais complexa que a necessária para os motores DC do tipo brushed. Para este trabalho, foram escolhidos motores DC do tipo brushed por seu custo relativamente baixo, sua eletrônica de controle simples e por seu relativamente baixo consumo de energia. Além disso, neste trabalho, não será necessário um monitoramento preciso da posição e da velocidade de rotação dos motores de tração, tirando as vantagens em se utilizar motores de passo Modelo do Motor O torque e a velocidade angular de um motor DC do tipo brushed podem ser calculados em função da corrente de armadura e da intensidade do fluxo magnético atravessando a mesma. Num motor cujo estator é composto por ímãs permanentes, a intensidade do fluxo magnético do estator é constante. Para este trabalho, assumiremos o motor operando em regime permanente, ou seja, desprezaremos os transitórios dinâmicos e eletromagnéticos. Em sistemas com redução mecânica, o torque devido à carga a ser girada pelo motor também é consideravelmente reduzido. No caso do robô em questão, este pode ser desprezado para fins de eletrônica de controle. Portanto, a partir das formulações de RASHID (2011), com as condições assumidas, os motores de tração podem ter uma modelagem simplificada em função 15

28 da corrente de armadura i a pelas seguintes equações: τ = k τ I a (3.1) ω = k ω I a (3.2) onde τ corresponde à quantidade de torque eletromagnético, ω à velocidade angular do rotor, e k τ e k ω são constantes de proporcionalidade dependentes de diversos fatores inerentes ao motor, mas que podem ser medidas experimentalmente. Além disso, em regime permanente, a tensão de armadura pode ser modelada como: V a = R a I a + E a (3.3) onde R a corresponde à resistência elétrica da armadura e E a é a força contraeletromotriz produzida pelo motor em rotação. Esta é dada por: E a = k v ω (3.4) onde k v é uma constante que depende, dentre outros fatores, da quantidade de fluxo magnético atravessando a armadura Torque O torque máximo necessário é um valor importante de ser estimado para levantar as especificações do driver dos motores de tração. Na Tabela 3.1, se encontram as estimativas da parte mecânica do robô elaboradas por seu projetista. De acordo com essas estimativas, o torque requerido foi calculado em 8,3 kg-cm. Este valor de torque pode ser considerado como o torque máximo que o motor deverá exercer para tirar o veículo da inércia e acelerá-lo até a velocidade máxima desejada dentro do tempo de aceleração esperado. Para o valor de torque estimado foram encontrados alguns modelos de motor DC disponíveis no mercado, inclusive modelos com caixa de redução acoplada. Uma caixa de redução é necessária para aumentar a capacidade de torque do motor, ao custo de redução da velocidade de rotação. Um dos motores encontrados (RO- BOTSHOP, 2013b) com redução acoplada possui as especificações encontradas na 16

29 Peso bruto do veículo 6,5 lb (3 kg) Peso em cada roda 3,25 lb (1,5 kg) Raio da roda 10 in (25 cm) Velocidade máxima desejada 4 ft/s (10 cm/s) Tempo de aceleração desejado 1 s Ângulo máximo de inclinação do piso 2 graus Pior superfície de trabalho Concreto Fator de resistência do motor 1,1 Coeficiente de atrito com o solo 0,5 Tabela 3.1: Estimativas da parte mecânica do robô Tabela 3.2. Tensão de operação 6V 12V Velocidade de rotação livre 50 rpm 100 rpm Corrente em rotação livre 250 ma 300 ma Torque máximo 110 oz-in (7,93 kg-cm) 220 oz-in (15,8 kg-cm) Corrente máxima 2,5 A 5,0 A Tabela 3.2: Especificações de um motor que atende às estimativas de torque do projeto Drivers O acionamento de motores DC do tipo brushed pode ser feito de algumas formas diferentes. No entanto, para um controle de velocidade e sentido de rotação, a forma mais utilizada é o acionamento através de circuitos de chaveamento em ponte H (CONDIT, 2010). Uma ponte H é constituída de quatro elementos de chaveamento dispostos como no circuito da Figura 3.1. Fechando chaves em posições diametralmente opostas (S1:S4 ou S2:S3) na ponte H, o motor gira em sentido horário ou anti-horário, dependendo do par de chaves ligadas. As outras chaves são mantidas abertas, nesse caso. Por outro lado, fechando chaves paralelas (S1:S3 ou S2:S4), o motor tem uma parada forçada. Enquanto que, se todas as chaves forem abertas, o motor tem uma parada gradual em movimento livre. Os elementos de chaveamento são em geral de estado sólido. Dependendo principalmente da potência da carga a ser acionada, podem ser utilizados transistores 17

30 Figura 3.1: Topologia de uma ponte H (Fonte: BJT, MOSFETs ou IGBTs. Há também alguns tipos de drivers integrados no mercado (TEXAS INSTRUMENTS, 2014). No caso de chaveamento a MOSFET, por exemplo, encontram-se circuitos integrados chamados gate drivers, que geram os níveis de tensão necessários para ativar os gates dos MOSFETs, tanto do lado inferior quanto do lado superior da ponte. Por outro lado, para níveis baixos de potência, isto é, até algumas poucas dezenas de watts, podem ser encontrados drivers na forma de um único circuito integrado contendo a ponte e circuitos de interface de baixa tensão para a lógica de controle do motor. Quando comparadas às pontes feitas com componentes discretos, pontes H integradas, além do tamanho reduzido, têm a vantagem de já virem balanceadas de fábrica. Isto significa que seus transistores internos são dimensionados e polarizados de maneira que haja uma simetria praticamente perfeita entre os dois lados da ponte. Com isso, a ponte pode fornecer ao motor o mesmo nível de potência em ambos os sentidos rotação Circuito Integrado L298N O circuito integrado L298N (ST MICROELECTRONICS, 2000) é um exemplo de driver para motores DC com a ponte H e uma interface para a lógica de controle do motor integradas. Ele foi escolhido para este projeto pelas seguintes características: Popularidade no mercado, sendo fácil de encontrar nos principais distribuidores de componentes eletrônicos; 18

31 Baixo custo; Possui duas pontes H completas integradas; Capaz de fornecer até 2A de corrente contínua, suportando até 3A de pico não repetitivo. Neste integrado, cada ponte H tem uma entrada de controle para habilitá-la. Com a ponte desabilitada, todas as suas chaves são abertas. O motor entra, então, em movimento livre, podendo parar, se essa condição se manter. Desta forma, pode ser implementado um controle de velocidade via PWM. Maiores detalhes quanto à técnica de controle de velocidade por PWM são descritos no Apêndice D. 3.3 Driver dos Motores das Bombas Bombas Peristálticas Para ejetar tinta sobre a superfície que o robô irá pintar, foram escolhidas bombas peristálticas (VERDERFLEX, 2014). Tais dispositivos possuem mecanismos relativamente simples, sendo movidos por motores DC do tipo brushed (RO- BOTSHOP, 2013a), geralmente, assim como os motores de tração. Portanto, foi utilizado o mesmo tipo de driver que o dos motores de tração Circuito Integrado L293D O integrado L293D (ST MICROELECTRONICS, 1996) possui quatro drivers do tipo push-pull que podem ser acionados individualmente. Cada um destes é capaz de entregar até 1A de corrente na saída. Além disso, este circuito integrado já possui em si diodos para proteção contra sobretensão devido à força contraeletromotriz. Pelo motor ser constituído de enrolamentos de fios condutores, este apresenta características de uma carga indutiva. Portanto, quando sua corrente é interrompida, é gerada uma força contra-eletromotriz, que pode danificar o circuito do driver caso não haja uma proteção. Este integrado foi escolhido para o projeto devido às características descritas acima e à sua disponibilidade no mercado. Cada um de seus drivers internos será usada para acionar uma das quatro bombas de tinta que o robô irá comportar. 19

32 3.4 Microcontrolador Microcontroladores são dispositivos que integram um núcleo de processamento, memórias e os mais diversos periféricos num único chip (BRAIN, 2013). Eles são encontrados em uma diversidade de aparelhos e sistemas eletrônicos embarcados, como os presentes em automóveis. Além disso, microcontroladores também são largamente utilizados em projetos na área de robótica, devido à sua versatilidade e grau de miniaturização Arquitetura Básica de um Microcontrolador A Figura 3.2 apresenta o diagrama de blocos da arquitetura básica de um microcontrolador. Esta varia principalmente quanto às conexões, podendo alguns periféricos terem acesso direto às portas ou à memória de dados, por exemplo. Além disso, pode estar presente mais uma memória para dados, dessa vez, não volátil, sendo, geralmente, uma EEPROM (do inglês, Electrically Erasable Programmable Read-Only Memory). Figura 3.2: Arquitetura básica de um microcontrolador 20

33 As portas de entrada/saída são a conexão entre o microcontrolador e o mundo exterior. Elas são conectadas aos pinos do circuito integrado designados para funções de entrada/saída. Contudo, elas podem ter suas funções multiplexadas internamente com diversos periféricos(microchip, 2008), podendo funcionar como entradas analógicas para um conversor A/D, por exemplo, ou como terminais de comunicação via protocolo I 2 C (do inglês, Inter-Integrated Circuit) (NXP, 2012). A memória de dados é, geralmente, do tipo RAM (do inglês, Random Access Memory). Ela guarda os dados do microcontrolador de forma temporária, sendo estes perdidos após a alimentação ser desligada. Dentre esses dados podem estar variáveis do programa sendo executado pela CPU e registradores de controle internos que guardam configurações da CPU e de seus periféricos. A CPU (do inglês, Central Processing Unit), ou unidade de processamento central, compreende os componentes centrais do microcontrolador responsáveis pela execução do programa armazenado na memória. Dentre eles, podemos encontrar a unidade de lógica e aritmética, o registrador de instrução, sistemas de interrupção, circuitos para geração de sinal de clock etc.. Os periféricos podem ser desde temporizadores à conversores analógico-digital (A/D) de vários bits de precisão, incluindo módulos de comunicação implementando os mais diversos protocolos para troca de dados entre dispositivos, como o I 2 C, mencionado anteriormente. Essa diversidade de periféricos é um dos principais fatores motivadores para o uso de microcontroladores. A possibilidade de ter um sistema completo para amostragem, processamento e armazenamento de dados, além da implementação de protocolos de comunicação variados, em um único chip reduz consideravelmente a necessidade de componentes externos nos projetos envolvendo microcontroladores. A memória de programa é responsável por armazenar de forma persistente as instruções de máquina que formam o programa a ser executado pelo microcontrolador. No entanto, alguns microcontroladores oferecem a opção de se escrever nessas memórias em tempo de execução a partir do próprio programa (MICROCHIP, 2008). Isto torna possível a utilização da memória de programa para armazenar valores de variáveis temporárias durante a execução do programa. No entanto, isso não é uma prática comum, visto que as mesmas tem quantidades de ciclos de escrita e apa- 21

34 gamento limitada, as escritas e apagamentos são feitas em blocos, além de serem muito mais lentas que numa memória do tipo SRAM. Um uso mais eficaz para essa funcionalidade torna-se armazenar variáveis que precisam ter seus valores armazenados persistentemente quando não há uma memória de dados não-volátil disponível (NXP, 2011). O uso mais comum para a escrita em tempo de execução, entretanto, é para a criação de bootloaders. Estes são programas executados logo após o reset do microcontrolador que permitem que este seja programado por meio de periféricos, como módulos de comunicação UART, por exemplo (BENINGO, 2012) ATmega32 Para este trabalho, o microcontrolador deveria apresentar as seguintes características mínimas: 3 canais PWM independentes para controle dos motores das rodas e das bombas; 1 UART para comunicação com o módulo Wi-Fi; Encapsulamento DIP para montagem em placa de circuito impresso artesanal, sem a necessidade de equipamento especial para montagem em superfície; Memória de programa de tamanho suficiente para conter o firmware necessário. Quantidade de pinos de entrada/saída suficiente para controle dos drivers, do módulo Wi-Fi, interface com sensores de colisão e LEDs para indicação de status. Uma infinidade de modelos de microcontroladores no mercado atenderia a essas especificações. No entanto, havia disponível o microcontrolador ATmega32-16pu da Atmel (ATMEL, 2011) no LABCON. Portanto, este foi escolhido para controlar a eletrônica embarcada do robô. Dentre as principais características deste microcontrolador(atmel, 2011), podemos citar as seguintes: Execução de até 16 milhões de instruções por segundo (MIPS); 32 KB de memória de programa do tipo Flash; 22

35 1024 B de memória de dados não-volátil do tipo EEPROM; 2 KB de memória de dados do tipo RAM estática (SRAM); 2 temporizadores/contadores de 8 bits; 1 temporizador/contador de 16 bits; 4 canais PWM; Conversor A/D de 10 bits com 8 canais; 1 Módulo USART; Encapsulamento PDIP de 40 pinos. 23

36 Capítulo 4 Desenvolvimento Este capítulo descreve o hardware projetado para atender às especificações do projeto e o firmware necessário para exercer essas funcionalidades. 4.1 Desenvolvimento do Hardware O hardware para a eletrônica embarcada do robô foi projetado de acordo com as seguintes especificações: ser controlável via rede Wi-Fi; controlar 2 motores DC brushed de tração em modo de direção diferencial; controlar 4 motores DC brushed em bombas de tinta; detectar colisões em sua navegação utilizando sensores de colisão. Para implementar tais especificações, foram elaboradas duas placas: uma para fornecer controle a um nível central e outra dedicada ao controle dos motores. A primeira contém o microcontrolador e se comunica com o computador do usuário utilizando o Wi-Fi. A segunda recebe os comandos da placa central e aciona os motores. Separar o projeto do módulo de controle do robô em duas placas, estando a placa dos dispositivos de potência separada, evita interferências geradas por ruído na corrente dos motores. 24

37 4.1.1 Projeto da Placa de Controle Central O projeto da placa de controle central foi centrado em torno dos seus componentes principais: o módulo Wi-Fi e o microcontrolador. O esquemático final do circuito é apresentado na Figura 4.1. Para controlar o módulo Wi-Fi, foram utilizados seu pino de reset e os pinos TX (transmissor) e RX (receptor) de seu periférico UART. Utilizando o reset, seria possível reiniciar o módulo sempre que o microcontrolador fosse reiniciado. Deste modo, pode haver sincronismo entre a operação dos dois sistemas Conversão de Níveis Lógicos Uma das primeiras dificuldades encontradas é o fato do módulo Wi-Fi trabalhar a um nível de tensão de alimentação mais baixo que o do microcontrolador. O primeiro trabalha com uma lógica de 3,3V, enquanto o segundo utiliza o padrão de 5V. Consequentemente, ligar os terminais de comunicação dos dois diretamente poderia causar problemas na interpretação dos níveis lógicos de tensão pelos circuitos de entrada de suas portas. Por isso, foram utilizados circuitos a diodo entre o microcontrolador e o módulo Wi-Fi para adaptar os níveis de tensão gerados por ambos Controle das Bombas de Tinta Para controlar as quatro bombas de tinta via PWM, o que permitiria regular o fluxo de cada uma, seria necessário compartilhar um dos canais PWM do microcontrolador. Este possui apenas quatro canais com essa função. Dois destes já estão reservados para controlar os motores de tração. Portanto, restariam apenas dois, o que não é suficiente para controlar diretamente quatro bombas. A solução para esse problema foi multiplexar o controle das bombas de tinta utilizando um demultiplexador (comumente abreviado como demux) digital. A entrada deste foi ligada ao pino PWM do microcontrolador e as saídas ligadas aos drivers das bombas. O circuito integrado que atendia minimamente a essas especificações foi o CD4555. O CD4555 é composto por dois demultiplexadores de uma entrada e quatro saídas. Apenas um dos demux foi utilizado no projeto. 25

38 Figura 4.1: Diagrama esquemático da placa de controle central 26

39 Cada demux do CD4555 tem uma entrada enable (E) que habilita a seleção de suas saídas. Isto é, quando um dos demux está desabilitado (E=1), todas as saídas são mantidas desativadas. Neste caso, com o integrado em questão, elas apresentam nível lógico 0. Por outro lado, quando o demux utilizado está habilitado (E=0), a saída selecionada pelos pinos A e B é ativada, apresentando nível lógico 1, enquanto as demais permanecem em 0. Deste modo, pode-se transmitir um sinal chaveado em lógica inversa para a saída selecionada através do pino enable. Para implementar o controle das bombas, então, um dos canais de PWM do microcontrolador (OC0) gera o sinal de entrada para o demux no seu terminal enable (E). Outros dois pinos do microcontrolador, funcionando como saídas digitais, selecionam uma das saídas do demux através de suas entradas de endereçamento (A e B). Cada uma das saídas do demux (Q0 a Q3) está ligada a uma das quatro bombas de tinta, através de seu driver correspondente, na outra placa Controle do Sistema de Tração Os sinais para o controle do sistema de tração diferencial são transmitidos diretamente ao circuito integrado L298N na placa dos drivers. Dois canais de PWM do microcontrolador (OC1A e OC1B) geram os sinais para os pinos de enable de cada ponte H do driver, provendo o controle de velocidade conforme discutido no item Outros dois pares de saídas digitais do microcontrolador geram os sinais para as entradas que controlam o sentido de rotação do motor em cada ponte H Sensores Não foram incluídos circuitos para sensores na placa para garantir certa flexibilidade ao projeto. No entanto, para se conectar a sensores externos, foram disponibilizados conectores compartilhando vias de alimentação e canais de conversão analógico-digital do microcontrolador. Isso permitiria uma certa flexibilidade ao sistema para se conectar a sensores que têm uma saída de tensão analógica, como alguns sensores de proximidade por reflexão de sinais de luz infravermelha. 27

40 Indicação de Estado Por último, foram disponibilizados três LEDs para indicação de estado do sistema pelo microcontrolador. Cada um foi escolhido com uma cor diferente, para indicar um tipo de informação, tais como, estado da conexão, recepção de dados, transmissão de dados etc Projeto da Placa de Drivers O projeto da placa dos drivers foi relativamente simples, e se baseou nas especificações dadas pelo manual do fabricante de cada circuito integrado desta. O diagrama esquemático da placa é apresentado na Figura 4.2. Cada um dos drivers push-pull do L293D é conectado a um dos terminais de cada motor das bombas de tinta. O outro terminal de cada motor é conectado ao 0V do sistema. Dessa forma, quando um dos drivers tem sua entrada em nível lógico alto ( 1 ), o motor em sua saída é ligado. Caso contrário, o motor permanece desligado. Como o sinal PWM gerado pelo microcontrolador na placa de controle central é transmitido aos drivers pelo pino de enable do demux, pino este que é ativo em 0, este será implementado em lógica inversa pelo firmware do microcontrolador. Os dois motores de tração são ligados as saídas das pontes H do integrado L298N. De acordo com o manual do fabricante, cada uma destas precisa ser ligada a uma ponte de diodos quando uma cargas indutivas são acionadas. Isso evita danos aos circuitos internos do driver causados pela força contra-eletromotriz do motor quando este é desligado subitamente, como no caso de chaveamento via PWM. Portanto, o projeto teve de incluir pontes de diodos de proteção associados a cada motor do sistema de tração. No caso do L293D, utilizado para acionar as bombas, isto não foi necessário por este já incluir diodos de proteção internamente na saída de cada driver. 4.2 Desenvolvimento Computacional O sistema computacional deste projeto é composto de duas partes: o firmware do microcontrolador e o software para o PC do usuário. Quanto a este último, no 28

41 Figura 4.2: Diagrama esquemático da placa dos drivers entanto, a parte da interface está sendo desenvolvida por outra equipe. A equipe da eletrônica está encarregada apenas do software necessário para a comunicação da interface com o robô Firmware O firmware corresponde ao código fixo presente na memória de programa do microcontrolador. Tal código implementa a inteligência do robô, o controle dos motores e a codificação e decodificação dos dados para a comunicação via módulo 29

42 Wi-Fi. O fluxograma principal do programa a ser executado pelo microcontrolador é apresentado na Figura 4.3. Quando o microcontrolador inicia sua operação, o programa inicializa suas variáveis e os periféricos que serão utilizados. As velocidades iniciais são zeradas. Paralelamente, o módulo Wi-Fi, previamente configurado, é inicializado e lança um ponto de acesso Wi-Fi automaticamente. O robô entra, então, em modo de espera por uma conexão TCP de um computador remoto com o módulo Wi-Fi. Após uma conexão via TCP ser estabelecida, o robô entra num ciclo central do programa. Primeiramente, este checa as leituras dos sensores de colisão para verificar se o robô colidiu com algum obstáculo antes de enviar qualquer comando aos motores de tração. Deste modo, o robô pode desviar do obstáculo antes de dar prosseguimento à sua operação. Logo após a verificação e a abordagem de colisões, o programa verifica se algum novo comando foi recebido via Wi-Fi através de rotinas próprias para recepção de comandos via serial. Dentre os comandos possíveis, estão os de atualização de configuração, cor e velocidade do robô. Caso o comando recebido não tenha sido nenhum desses, ou não esteja no formato ou faixa de valores correto, um erro é registrado e sinalizado ao usuário Comunicação A recepção de dados via UART pelo microcontrolador foi desenvolvida na forma de máquinas de estados. Estas verificam os dados recebidos byte a byte, comparando com as strings que notificam abertura ou fechamento de conexão, ou verificando se é um comando de velocidade ou de cor através do formato. Há uma máquina de estados responsável pelo monitoramento da conexão TCP com dois estados possíveis: 1. Aguardando Conexão 2. Conexão Estabelecida Chamaremos esta de Máquina 1. 30

43 Figura 4.3: Fluxograma principal do firmware 31

44 No último estado desta, é executada outra máquina de estados com três possíveis estados: 1. Aguardando Comando 2. Recebendo velocidade 3. Recebendo Cor Esta chamaremos de Máquina 2. Quando uma conexão TCP com o módulo Wi-Fi é aberta, este notifica o microcontrolador via porta serial enviando a sequência de caractéres (string) *OPEN*. Do mesmo modo, quando a conexão é fechada, a string *CLOS* é enviada. Com isso, o microcontrolador foi programado para identificar essas strings na sua rotina de recepção de dados via UART para detectar uma mudança de estado da conexão. Ao ser detectada essa mudança de estados, a rotina principal do programa, detalhada no fluxograma da Figura 4.3, é avisada através de uma variável que funciona como um flag de sinalização. Figura 4.4: Diagrama de transição de estados da Máquina 1 A Máquina 1 funciona conforme o diagrama apresentado na Figura 4.4. Inicialmente, a máquina é inicializada no estado Aguardando Conexão. Quando a string *OPEN* é recebida, o estado da Máquina 1 passa para Conexão Estabelecida. Nesse momento, um flag é setado de modo que o loop principal do programa possa 32

45 detectar a mudança. A partir daí, a Máquina 2 entra em execução conjunta, sendo inicializada em Aguardando Comando, conforme o diagrama na Figura 4.5. Figura 4.5: Diagrama de transição de estados da Máquina 2 Ao receber um comando de velocidade ou de seleção de cor da tinta, a Máquina 2 passa para o estado correspondente e aguarda a recepção por inteiro de um desses comandos. Após isso, ou caso a recepção falhe, por receber uma string em formato diferente, a Máquina 2 volta ao seu estado inicial. Pode ocorrer também que a string *CLOS* seja recebida. Neste caso, o estado da Máquina 1 é alterado para o inicial, e a Máquina 2 deixa de ser executada. Os comandos de velocidade são strings da forma vxx, onde XX é um número decimal de dois dígitos em caracteres ASCII que pode valer de 00 a 10. Por exemplo, v05, indica que o robô deve mudar sua velocidade para o valor 5, que significa 50% do máximo atingível. Quanto à seleção das cores, os comandos são da forma cx, onde X é um dígito decimal de 0 a 4. O comando c0 indica que nenhuma bomba de tinta deve ser acionado. Já os comandos c1 a c4 indicam que a bomba de tinta correspondente, dentre uma das quatro bombas disponíveis, deve ser acionada. Estes comandos são mutuamente exclusivos. Ou seja, se a bomba 3 estiver acionada, e o robô receber o comando c2, a bomba 3 é desligada e a bomba 2 é ligada. 33

46 Geração de Movimentos Aleatórios Foi adotado para o robô o modelo cinemático do uniciclo(carona; AGUIAR; GASPAR, 2008), dado por: ẋ cos(θ) 0 ẏ = sin(θ) 0 v (4.1) ω θ 0 1 onde v corresponde à velocidade de deslocamento linear, θ, ao ângulo de orientação, ω, à velocidade de deslocamento angular em relação ao mesmo eixo da orientação, e x e y são as coordenadas da posição do robô no plano. A velocidade a ser mudada pelos comandos é a velocidade de deslocamento linear do robô. A velocidade angular foi tornada a parcela aleatória do sistema. A intervalos de tempo de duração pré-determinada, um novo valor de velocidade angular é gerado para o robô. Dessa forma, este pode descrever uma trajetória curva e relativamente suave Controle dos Motores de Tração por PWM Adaptando o modelo do uniciclo ao caso de um robô com direção diferencial, podemos encontrar a relação entre as entradas (v e ω) e as velocidades de cada roda (v 1 e v 2 ), que serão nesse caso as saídas. No caso do programa a ser executado pelo microcontrolador, o que importa saber, no entanto, é o cálculo do duty cycle de cada PWM a ser transmitido aos motores do sistema de tração. Assumindo um robô de duas rodas simétricas e com um referencial posicionado no centro do eixo entre as duas rodas, podemos deduzir as seguintes equações: v = v 1 + v 2 2 (4.2) ω = v 2 v 1 R A (4.3) onde v 1 e v 2 são as velocidades lineares da roda à esquerda e da roda à direita do referencial. R A corresponde à distância entre o centro do eixo das rodas e cada roda, que é simétrica. Precisamos, no entanto, das relações envolvendo as velocidades de 34

47 rotação de cada roda (ω 1 e ω 2 ), que são diretamente proporcionais ao duty cycle de cada sinal PWM dos motores de tração. Sabemos que v 1 = R w ω 1 (4.4) v 2 = R w ω 2 onde R w corresponde ao raio das rodas. Substituindo 4.4 em 4.2 e 4.3, obtemos o seguinte sistema v ω de onde podemos obter a inversa = R w R A 1 R A ω 1 (4.5) ω 2 ω 1 = R A R w ω 2 1 R A R A 2 v ω (4.6) A partir deste sistema, podemos ver que ω 1 = av bω ω 2 = av + bω (4.7) onde a e b são constantes que dependem das dimensões físicas do robô. Entretanto, como o intuito é apenas desenvolver um algoritmo capaz de gerar movimentos aleatórios, os valores de a e b podem ser arbitrados. Dessa forma, sabendo que o duty cycle do PWM é proporcional a velocidade angular da roda, podemos adotar as seguintes equações: n 1 = a 1 v + b 1 ω (4.8) n 2 = a 2 v + b 2 ω onde n 1 e n 2 correspondem aos valores de duty cycle de cada PWM, e a 1, a 2, b 1 e b 2 são constantes que dependem, neste caso, da potência de cada motor. Estes podem ter pequenas diferenças quanto à capacidade de torque e à velocidade máxima atingível, fazendo com que respondam de maneira diferente a variações no valor do duty cycle do PWM. Portanto, o sistema permite esse ajuste para compensação, de modo que o movimento do robô não tenda para o lado do motor mais potente. 35

48 Navegação A lógica de navegação do robô consistiu do emprego de uma técnica simples reativa. A cada iteração do loop principal do programa, o robô checa o estado de seus sensores de colisão. Foram considerados dois sensores de toque, ambos frontais, estando um no canto esquerdo e outro no direito, como na Figura 4.6. Caso estes indiquem uma colisão, o robô inicia uma sequência de movimentos para se desviar do obstáculo que atingiu. A sequência é simplesmente recuar, e virar o veículo em direção oposta à do obstáculo. Após isso, o robô volta à sequência de movimentos aleatórios. Figura 4.6: Disposição dos sensores de colisão Comunicação a partir do PC O desenvolvimento do driver para o PC do usuário foi deixado para um trabalho futuro. Para testes, no entanto, foi utilizado o protocolo Telnet para a comunicação entre o computador e o robô através do software PuTTY. Com o Telnet, é possível abrir um canal de comunicação entre dois hosts numa rede TCP/IP para troca bidirecional direta de dados entre terminais (POS- TEL; REYNOLDS, 1983). O software PuTTY oferece um terminal para que dados codificados em texto ASCII possam ser enviados e recebidos do módulo Wi-Fi. Isso possibilitou testar o protocolo de comunicação elaborado para a transmissão de comandos ao robô. 36

49 Capítulo 5 Implementação do Projeto A implementação do projeto foi gradativa, iniciando pelo teste e configuração do módulo Wi-Fi, e seguindo até a montagem de um protótipo para testes da eletrônica a ser embarcada no produto final. Não foi possível, entretanto, obter o hardware mecânico completo do robô para implementar e testar o projeto. Este ainda não estava concluído pela equipe responsável pela parte mecânica. Por isso, foi utilizada uma plataforma robótica desenvolvida pelo aluno para projetos pessoais. 5.1 Configuração do Módulo Wi-Fi O módulo RN-XV da Roving Networks (ver Figura 5.1) que foi utilizado no projeto apresenta formato físico e pinagem semelhante(roving NETWORKS, 2012) ao dos módulos XBee R da Digi International (DIGI, 2014). Deste modo, o RN-XV torna-se compatível com a maioria das ferramentas de desenvolvimento disponíveis para os módulos XBee. Dentre elas, temos os adaptadores USB, dos quais o modelo oferecido por (ROGERCOM, 2014) foi utilizado (ver Figura 5.2). Um dos primeiros procedimentos a fazer antes de começar a utilizar as funcionalidades oferecidas pelo módulo é atualizar seu firmware. Para fazer isto, é necessário acessar o módulo em modo de comando e enviar-lhe uma determinada sequência de comandos (ROVING NETWORKS, 2013). O acesso ao módulo, por sua vez, pode ser realizado através da porta serial ou de uma conexão TCP. A porta serial pode ser acessada através de uma conexão USB com o adaptador mencionado anteriormente. Quanto ao acesso via TCP, no 37

50 Figura 5.1: Módulo Wi-Fi RN-XV (Fonte: Figura 5.2: Adaptador USB para o Módulo Wi-Fi (ROGERCOM, 2014) entanto, o módulo ainda não está configurado para se conectar a alguma rede Wi- Fi em particular no primeiro uso. Portanto, para acessá-lo via TCP é necessário inicializá-lo em modo Soft AP, que o faz funcionar como ponto de acesso, ou Ad Hoc, dependendo da versão do firmware presente originalmente (ROVING NETWORKS, 2013). Isto pode ser feito via hardware utilizando pinos específicos do módulo, o que torna possível essa configuração no primeiro uso. O firmware do módulo foi atualizado para a versão 4.0 neste trabalho, que era a mais recente na época em que se iniciou o uso do dispositivo. No momento, já existe uma versão mais nova. Esta, no entanto, apresentou problemas no modo Soft AP que desencorajaram seu uso. Para que um computador remoto se conecte ao robô, existem algumas maneiras possíveis, como descrito na Seção 2.1. Utilizar o módulo em modo Soft AP corresponde à opção 2 descrita, em que o robô lança sua própria rede. Neste caso, o módulo Wi-Fi pode utilizar um endereço IP fixo sem conflitos, já que o próprio 38

51 módulo distribui os endereços IP via DHCP às estações clientes da rede. Com isso, o módulo atua como um servidor, e o computador do usuário, como cliente. Esta opção se mostrou a mais conveniente para o projeto. A única desvantagem seria a possível perda do acesso à Internet pelo computador do usuário. Todavia, durante as atividades em questão, este deve ser reservado somente para o controle do robô. 5.2 Implementação do Firmware Para desenvolver o firmware, este foi implementado utilizando um microcontrolador PIC18F4620 da Microchip que o aluno possuía em casa. Desta forma, foi possível dedicar mais horas a esta etapa do projeto do que seria possível no laboratório. O ATmega32-16pu será utilizado para a implementação final do produto que será entregue às clientes do projeto. Tanto o PIC (MICROCHIP, 2008) quanto o ATmega (ATMEL, 2011) são programáveis em linguagem C. Ambos os modelos utilizados são microcontroladores de 8 bits e com características semelhantes. Dentre as principais diferenças, no entanto, temos que o PIC18F4620 tem o dobro da quantidade de memória de programa do ATmega32-16pu e quase o dobro também de memória SRAM (3968 B contra 2048 B), tendo, contudo, apenas dois canais PWM independentes e velocidade de operação máxima de 10 MIPS a um clock de 40 MHz. Para contornar essas diferenças, podemos manter o tamanho do programa em termos de instruções e de dados dentro do compatível entre os dois microcontroladores. Outra medida necessária foi a mudança do controle das bombas de tinta para um do tipo on/off (liga/desliga), em vez de PWM, já que o PIC utilizado possuía apenas dois canais PWM. O ambiente de desenvolvimento integrado MPLAB X da Microchip, fabricante do PIC, foi utilizado para o desenvolvimento do firmware. Ele oferece ferramentas para o gerenciamento de projetos de firmware, a edição e a compilação de código e a programação de microcontroladores PIC. Dentre essas, o compilador XC8, também da Microchip, proveu os meios para utilizar a linguagem C na programação do microcontrolador. Ambas as ferramentas são disponibilizadas em versões gratuitas e pagas. As diferenças entre as versões estão basicamente no nível de otimização 39

52 do código de máquina gerado. Na versão gratuita, utilizada no presente projeto, a otimização é mínima. No entanto, isso não veio a atrapalhar o desenvolvimento do firmware neste trabalho. Para programar o microcontrolador, foi utilizada a ferramenta PKBurner (ver Figura 5.3), fabricado pela Carelle. Este é um programador e debugger para PICs que utiliza o firmware PICKit2 da Microchip. Ele permite programação via ICSP, sigla, em inglês, para In-Circuit Serial Programming (MICROCHIP, 2003). Com isso, é possível programar o microcontrolador, sem retirá-lo do circuito, através de um cabo próprio. Figura 5.3: Programador para microcontroladores PIC utilizado no projeto (Fonte: Manual do fabricante, fornecido com o produto) 5.3 Implementação do Hardware Foi utilizada uma plataforma robótica experimental, apresentada na Figura 5.4, para testes. Esta é constituída de dois motores com caixa de redução originários de servomotores de aeromodelismo para tração. Há uma roda de livre do tipo castor para apoiar o robô. Chaves de fim-de-curso são utilizadas como sensores de colisão. O chassis é feito de alumínio. O software Eagle da Cadsoft foi utilizado na diagramação dos circuitos eletrônicos 40

53 Figura 5.4: Plataforma robo tica utilizada para testes projetados. Este software e fornecido em verso es gratuitas e pagas por sua empresa. A versa o gratuita, que foi utilizada, na o ofereceu limitac o es que viessem a interferir negativamente no desenvolvimento do projeto. Para testar o projeto, na o foi montado o circuito da Figura 4.1 em conjunto com o da Figura 4.2, mas sim o da Figura 5.5, em uma protoboard. Os motivos para tal alterac a o foi a utilizac a o de outro microcontrolador, a inclusa o de um adaptador para o mo dulo Wi-Fi, que o torna utiliza vel em protoboard, e a ause ncia de motores de bombas perista lticas para testes. Contudo, o circuito montado mostrou-se suficiente para provar os conceitos a serem implementados no produto final e fazer os ajustes necessa rios no firmware, que tambe m sera adaptado para a versa o de entrega. Os LEDs indicam o estado do programa. O LED1 se mante m piscando durante a execuc a o do loop principal. o LED2 acende quando uma conexa o TCP e estabelecida pelo mo dulo e reconhecida pelo microcontrolador. Este LED se mante m aceso ate que a conexa o venha a se fechar. Na o foi empregado o integrado L293D, ja que na o estavam disponı veis os motores das bombas perista lticas ou outros motores que se pudessem utilizar para testes. Contudo, a parte responsa vel pelo acionamento dessas cargas foi implementada no firmware. A alimentac a o do circuito foi providenciada por dois conjuntos de baterias de nı quel metal-hidreto (NiMH) em se rie, cada um fornecendo uma tensa o de 4,8V. O conjunto inferior, com baterias de 2500mAh (ver Figura 5.6), fornece alimentac a o diretamente para os motores, que demandam maior capacidade de corrente. Indire41