Desenvolvimento de Uma Plataforma Aberta de Robô Móvel para Propósitos Gerais

UNIVERSIDADE ESTADUAL PAULISTA JLIO DE MESQUITA FILHO
INSTITUTO DE BIOCINCIAS, LETRAS E CINCIAS EXATAS

PROGRAMA DE PS-GRADUAO EM CINCIA DA COMPUTAO
Takao Matsumura
Desenvolvimento de uma plataforma aberta de rob mvel para propsitos

gerais
So Jos do Rio Preto

2014
Takao Matsumura

gerais
Dissertao de Mestrado apresentada ao
Programa de Ps-Graduao em Cincia da
Computao do Instituto de Biocincias,
Letras e Cincias Exatas, Campus de So
Jos do Rio Preto da Universidade Estadual
Paulista Jlio de Mesquita Filho, como
requisito para a obteno do ttulo de Mestre
em Cincia da Computao.
Linha de Pesquisa: Arquitetura
Computadores e Sistemas Distribudos
Orientador: Norian Marranghello
Coorientador: Humberto Ferasoli Filho
So Jos do Rio Preto

2014
de
Matsumura, Takao.
Desenvolvimento de uma plataforma aberta de rob mvel para
propsitos gerais / Takao Matsumura. -- So Jos do Rio Preto,
2014
131 f. : il.; tabs.
Dissertao (mestrado) Universidade Estadual Paulista
Jlio de Mesquita Filho, Instituto de Biocincias, Letras e Cincias
Exatas
1. Computao. 2. Robtica. 3. Robs mveis. 4. Robs
Sistemas de Controle. I. Marranghello, Norian. II. Ferasoli Filho,
Humberto. III. Universidade Estadual Paulista Jlio de Mesquita
Filho. Instituto de Biocincias, Letras e Cincias Exatas. IV. Ttulo.
CDU 681.51
Ficha catalogrfica elaborada pela Biblioteca do IBILCE
UNESP Cmpus de So Jos do Rio Preto
Takao Matsumura

gerais
Dissertao de Mestrado apresentada ao
Programa de Ps-Graduao em Cincia da
Computao do Instituto de Biocincias,
Letras e Cincias Exatas, Campus de So
Jos do Rio Preto da Universidade Estadual
Paulista Jlio de Mesquita Filho, como
requisito para a obteno do ttulo de Mestre
em Cincia da Computao.
Linha de Pesquisa: Arquitetura
Computadores e Sistemas Distribudos
Comisso Examinadora
Prof. Dr. Humberto Ferasoli Filho, Presidente
Universidade Estadual Paulista Jlio de Mesquita Filho Bauru - SP
Prof. Dr. Teodiano Freire Bastos Filho

Universidade Federal do Esprito Santo Vitria - ES
Prof. Dr. Joo Eduardo Machado Perea Martins

Universidade Estadual Paulista Jlio de Mesquita Filho Bauru -SP
So Jos do Rio Preto
15 de julho de 2014
de
"The machine does not isolate man

from the great problems of nature but
plunges him more deeply into them."
Antoine de Saint-Exupry
AGRADECIMENTOS
Aos meus familiares, especialmente meu pai Tatsuo e minha me Yoshiko que,
alm de fazerem parte da formao do meu carter, priorizaram minha educao, sempre
estiveram ao meu lado quando precisei e me apoiaram em todas as fases da minha vida.
Ao professor Norian, por acreditar na minha capacidade, pela receptividade e
oportunidade de cursar o mestrado e ao aceitar orientar o meu mestrado. Agradeo-o
pela sua orientao, pacincia e suas observaes que contriburam de forma decisiva
no decorrer desses ltimos anos.
Ao professor Humberto, pela sua motivao e incentivos que me apoiaram desde a
graduao e que me conduziram a almejar o mestrado. Agradeo-o por aceitar orientar
meu trabalho de concluso da graduao, e desta vez, coorientar meu mestrado.
Agradeo-o pelos finais de semana e horrios diferenciados dedicados minha
orientao (e cobrana), seus inmeros auxlios e pelo seu tempo cedido para contribuir
diretamente com meu trabalho no laboratrio e na produo dos meus textos. Agradeo
em especial sua dedicao com o laboratrio, ferramentas, materiais e ao seu knowhow sem os quais no teria sido possvel imaginar ou prosseguir com os meus trabalhos
prticos.
Aos professores Ren Pegoraro e Joo Perea, pelas suas colaboraes e auxlios
no laboratrio. Agradeo-os pelos seus emprstimos de componentes, ferramentas e
dispositivos.
Aos meus colegas e amigos de laboratrio, Silas Alves, Rogrio Barbosa e Diego
Voltan, pela convivncia descontrada, reflexes, contribuies diretas e indiretas com
meu trabalho e por me aguentarem ao longo desses anos. Agradeo ao Silas tambm
pelo seu apoio, colaborao no laboratrio (at tarde da noite e finais de semanas) e por
ceder seu tempo e ateno nas revises dos meus textos.
Unesp, ao Departamento de Computao de Bauru, ao Departamento de Cincia
da Computao e Estattica de So Jos do Rio Preto e ao Programa de Ps Graduao
em Cincia da Computao, que por meio de suas estruturas, possibilitaram o

desenvolvimento deste trabalho. Ao corpo docente, que contribuiu atravs de contedos
disciplinares, e aos professores que contriburam com este trabalho, de forma direta ou
indireta.
Aos funcionrios do Lepec e das oficinas da Faculdade de Arquitetura, Artes e
Comunicao, que me deram suporte na utilizao dos laboratrios. Aos funcionrios da
oficina mecnica da Faculdade de Engenharia de Bauru pelo auxlio no projeto e pela
confeco de peas sob medida que foram utilizados neste trabalho.
Aos amigos presentes e aos que passaram pela minha vida. Agradeo a todos
aqueles que me apoiaram, torceram por mim e queles que sempre estiveram presente
quando precisei.
Por fim, agradeo CAPES pelo suporte financeiro ao longo do desenvolvimento
deste trabalho.
RESUMO
A pesquisa em robtica mvel tem sido impulsionada pelo avano tecnolgico. Existem
frentes de pesquisas que abordam diferentes aspectos e desafios da robtica mvel,
dentre as quais esto tpicos como a locomoo, navegao e arquiteturas de controle.
Esse crescimento em pesquisas tambm acarreta uma maior necessidade por bases
mveis, em outras palavras, por plataformas de robs mveis de propsitos gerais,
destinadas pesquisa e, tambm, para fins educacionais. Esta situao aplicvel ao
Laboratrio de Automao e Computao Evolutiva (LACE) do IBILCE, Campus da
Unesp de So Jos do Rio Preto. Este trabalho apresenta o desenvolvimento de uma
plataforma de rob mvel de baixo custo e de arquitetura de hardware, software e
controle aberta, para propsitos gerais. A plataforma almeja a facilitao e flexibilizao
do processo de desenvolvimento de aplicaes robticas e estudos por meio de uma
interface de comunicao simplificada e pela abstrao da heterogeneidade dos
dispositivos perifricos de hardware. Esta plataforma capaz de oferecer maior liberdade
em relao s linguagens de programao, paradigmas de controle e ambientes de
desenvolvimento de seu software de controle, se estendendo aos dispositivos
tecnolgicos de controle.
Palavras-Chave: Arquitetura Aberta. Plataforma de Rob Mvel. Rob Mvel. Interface

de Comunicao.
ABSTRACT
The research on mobile robots has been driven by technological advance. There are research fronts on different aspects and challenges of mobile robots, among which are topics such as locomotion, navigation and control architectures. This growth in research also
leads a greater need for mobile bases, in other words, for mobile robot platforms for general purposes, destined for research and educational purposes. This situation is applicable to the Laboratory of Evolutionary Automation and Computation of IBILCE, Unesp
Campus of So Jos do Rio Preto. This work presents the development of a low cost
mobile robot platform with an open hardware, software and control architecture, intended
for general purposes. The platform aims at facilitating and flexibilizing the development
process of robotic applications and studies through a simplified communication interface
and abstracting the heterogeneity of the peripheral hardware devices. This platform is
able to offer greater freedom in relation to programming languages, control paradigms,
development environments of its control software, extending to the technological control
devices.
Keywords: Open Architecture. Mobile Robot Plataform. Mobile Robot. Communication

Interface.
LISTA DE ILUSTRAES
Figura 1.1 Abrangncia do trabalho proposto. .................................................................................... 21
Figura 2.1 - Exemplos de robs: (a) Rob manipulador; e (b) Rob mvel. ................................ 27
Figura 2.2 Mtricas de avaliao apresentadas por Thueer (2009). ........................................... 36
Figura 2.3 - Paradigmas das arquiteturas de controle na robtica mvel: (a) Hierrquico; (b)
Comportamental; e (c) Hbrido. .................................................................................................................... 41
Figura 2.4 - Topologia fsica de conexes do URB. ................................................................................. 46
Figura 2.5 Arquitetura do framework R2P............................................................................................ 47
Figura 3.1 Disposio da arquitetura e suas camadas. ..................................................................... 51
Figura 3.2 Diagrama em blocos dos dispositivos implementados no Kihon. ........................... 56
Figura 3.3 - Rob Mvel Kihon. ..................................................................................................................... 60
Figura 3.4 (a) Motor CC engrenado utilizado; e (b) Motor acoplado estrutura mecnica do
Kihon........................................................................................................................................................................ 63
Figura 3.5 Formas de ondas dos canais de controle PWM e seus efeitos no motor CC. ....... 64
Figura 3.6 Relao entre forma de onda e posicionamento do eixo de um servo motor. ... 66
Figura 3.7 (a) Servomotor utilizado no Kihon; e (b) Servomotor acoplado ao Kihon. ......... 66
Figura 3.8 Encoder e Sensor de odometria de um pulso por revoluo. .................................... 67
Figura 3.9 (a) Sensor de odometria utilizado; e (b) Sensores acoplados ao sistema de
odometria............................................................................................................................................................... 68
Figura 3.10 Vista superior da odometria junto ao sistema de locomoo do Kihon............. 69
Figura 3.11 (a) Sensor de proximidade empregado; (b) Disposio dos trs sensores; e (c)
Sensores acoplados na parte frontal do Kihon . ...................................................................................... 71
Figura 3.12 Sensores para seguir linhas do Kihon. ............................................................................ 72
Figura 3.13 (a) Sensor Sonar utilizado no Kihon; e (b) Sonar acoplado ao Kihon. ................ 73
Figura 3.14 - Disposio das baterias empregadas. .............................................................................. 76
Figura 3.15 Conector de Recarga, chave L/D e LED de sinalizao na lateral do Kihon. ..... 77
Figura 3.16 Fluxograma do Firmware do Controlador. .................................................................... 78
Figura 3.17 Interfaces de comunicao no Kihon. .............................................................................. 79
Figura 3.18 Formato geral das requisies. .......................................................................................... 81
Figura 3.19 Diagrama da Classe Controlador. ...................................................................................... 83
Figura 3.20 Arquitetura de um Sistema Fracamente Acoplado. ................................................... 85
Figura 4.1 Diagrama cliente-servidor do Experimento 1. ............................................................... 89
Figura 4.2 Disposio dos sensores do Kihon utilizados no Experimento 1. ........................... 90
Figura 4.3 Diagrama do algoritmo reativo de navegao. ............................................................... 91
Figura 4.4 Trajeto percorrido pelo Kihon com o algoritmo implementado. ............................ 92
Figura 4.5 Kihon em execuo do Experimento 1. ............................................................................. 92
Figura 4.6 Disposio dos dispositivos utilizados no Experimento 2. ........................................ 96
Figura 4.7 Vista superior do Circuito elaborado para ser percorrido pelo Kihon. ................ 98
Figura 4.8 Diagrama da arquitetura cliente-servidor do Experimento 2. ................................. 99
Figura 4.9 (a) Vista geral do ambiente onde foi realizado o Experimento 2; e (b) Rob mvel
Kihon executando o Experimento 2. ......................................................................................................... 100
LISTA DE TABELAS
Tabela 3.1 - Requisies enviadas para o Controlador por meio da comunicao serial. ...... 82
Tabela 4.1 Exemplos de chamadas s rotinas da Classe Controlador API utilizadas no
Experimento 1. ..................................................................................................................................................... 91
Experimento 2. ................................................................................................................................................... 101
Tabela 4.3 Valores de temperatura (em C) obtidos no Experimento 2. ................................. 101
LISTA DE ABREVIATURAS E SIGLAS
API
Application Programming Interface (Interface de Programao de

Aplicativos)
CAN
Controller Area Network (Controlador de Rede de rea)
CORBA
Common Object Request Broker Architecture (Intermedirio Comum para

Requisies de Objetos)
CMOS
Complementary Metal-Oxide-Semiconductor (Semicondutor Metal-xido

Complementar)
DARPA
Defense Advanced Research Projects Agency (Agncia de Projetos de

Pesquisa Avanada de Defesa)
DOF
Degree of Freedom (Grau de Liberdade)
FFI
Foreign Function Interface (Interface de Funes Estrangeiras)
GPS
Global Positioning System (Sistema de Posicionamento Global)
IEEE
Institute of Electrical and Electronics Engineers (Instituto de Engenheiros

Eletricistas e Eletrnicos)
I2C
Inter-Integrated Circuit (Circuito Inter-Integrado)
LACE
Laboratrio de Automao e Computao Evolutiva
LISDI
Laboratrio de Integrao de Sistemas e Dispositivos Inteligentes
MARIE
Mobile and Autonomous Robotics Integration Environment (Ambiente de

Integrao de Robs Mveis e Autnomos)
MIRO
Middleware for Mobile Robots (Middleware para Robs Mveis)
NASA
National Aeronautics and Space Administration (Administrao Nacional

do Espao e da Aeronutica)
PC
Personal Computer (Computador Pessoal)
PIC
Programmable
Interface
Controller
(Controlador
de
Programvel)
PYRO
Python Robotics (Python Robtico)
PWM
Pulse Width Modulation (Modulao por Largura de Pulso)
Interface
RDE
Robot Development Environment (Ambiente de Desenvolvimento de

Rob)
RIA
Robotic Industries Association (Associao das Indstrias Robticas)
RSCA
Robot
Software
Communication
Architecture
(Arquitetura
de
Comunicao de Software Robtico)

ROS
Robot Operating System (Sistema Operacional para Robs)
RF
Radio Frequency (Rdio Frequncia)
RT
Robot Technology (Tecnologia Robtica)
RTCAN
Real Time CAN (CAN de Tempo Real)
RT-CORBA
Real-Time CORBA (CORBA de Tempo Real)
SO
Sistema Operacional
SONAR
Sound Navigation and Ranging (Navegao e Determinao da Distncia

pelo Som)
SPI
Serial Peripheral Interface (Interface de Perifrico Serial)
TCP
Transmission Control Protocol (Protocolo de Controle de Transmisso)
TTL
Transistor-Transistor Logic (Lgica Transistor-Transistor)
UPnP
Universal Plug-and-Play (Plug-and Play Universal)
USB
URB
(Barramento Serial Universal)

Universal Robot Bus (Barramento Robtico Universal)
LISTA DE SMBOLOS
Letras Latinas
Centro geomtrico do rob
Sistema de coordenadas local do rob
Sistema de coordenadas de referncia
O mesmo que
O mesmo que
Sistema de coordenadas global ou inercial
Ponto de interseo entre o eixo de simetria e o eixo das rodas
Vetor de coordenadas generalizadas
Vetor das velocidades em coordenadas generalizadas
Raio das rodas
Distncia entre as rodas e o eixo de simetria
()
Matriz jacobiana ou modelo cinemtico
Velocidade linear
max
Velocidade linear mxima
Posio no eixo das abscissas
Velocidade do rob mvel no eixo das abcissas do plano
Posio no eixo das ordenadas
Velocidade do rob mvel no eixo das ordenadas do plano
Letras Gregas
ngulo do rob em relao ao eixo das abscissas
Velocidade angular
ngulo da roda do rob
Velocidade angular da roda direita de um rob de trao diferencial
Velocidade angular da roda esquerda de um rob de trao diferencial
SUMRIO
INTRODUO ............................................................................................................................... 15
1.1
Trabalhos correlatos .......................................................................................................... 16
1.2
Motivao ............................................................................................................................... 17
1.3
Objetivos gerais.................................................................................................................... 18
1.4
Objetivos especficos .......................................................................................................... 18
1.5
Requisitos............................................................................................................................... 19
1.6
Escopo do trabalho ............................................................................................................. 20
1.7
Mtodo..................................................................................................................................... 22
1.8
Organizao do trabalho ................................................................................................... 23
SNTESE DA REVISO BIBLIOGRFICA ................................................................................ 25

2.1
Robs mveis autnomos ................................................................................................. 25
2.2
Composio de um rob mvel....................................................................................... 28
2.3
Ambiente de aplicao....................................................................................................... 32
2.4
Locomoo ............................................................................................................................. 33
2.5
Navegao .............................................................................................................................. 36
2.6
Arquiteturas de controle .................................................................................................. 39
2.7
Sistemas de comunicao na robtica ......................................................................... 45
2.8
Concluses do captulo ...................................................................................................... 48
PLATAFORMA DE ROB MVEL ............................................................................................ 50

3.1
Camada Superior ................................................................................................................. 52
3.2
Camada Intermediria ....................................................................................................... 53
3.3
Camada Inferior ................................................................................................................... 55
3.4
O rob mvel Kihon ............................................................................................................ 57
3.4.1
Aspectos mecnicos e cinemticos .................................................................................... 57
3.4.2
Desenvolvimento do hardware ........................................................................................... 59
3.4.3
Concepo da Camada Intermediria ............................................................................... 78
3.5
Consideraes sobre a Plataforma de Rob Mvel.................................................. 83
3.5.1
Soluo baseada em um nico microcontrolador ........................................................ 84
3.5.2
Escolha da comunicao serial ............................................................................................ 86
3.6
Concluses do captulo ...................................................................................................... 87
TESTES E VALIDAO ................................................................................................................ 88

4.1
Experimento 1 ...................................................................................................................... 88
4.1.1
4.2
Experimento 2 ...................................................................................................................... 95
4.2.1
4.3
Consideraes ............................................................................................................................ 93
Consideraes .......................................................................................................................... 101
Concluses do captulo .................................................................................................... 103
CONSIDERAES FINAIS ......................................................................................................... 105

REFERNCIAS ...................................................................................................................................... 108
APNDICE A MODELO CINEMTICO DE UM ROB COM TRAO DIFERENCIAL ...... 112
APNDICE B CONTROLADOR DE ROBS MVEIS ................................................................ 116
APNDICE C PROTOCOLO DE COMUNICAO ...................................................................... 121
INTRODUO
A pesquisa em robtica mvel tem sido impulsionada pelos avanos tecnolgicos.

Existem frentes de pesquisas que abordam diferentes aspectos e desafios da robtica mvel,
dentre os quais esto tpicos como a locomoo, navegao e arquiteturas de controle. Esse
crescimento em pesquisas tambm acarreta uma maior necessidade por bases mveis, em
outras palavras, por plataformas de robs mveis que possam ser destinadas pesquisa e
tambm para fins educacionais.
Embora existam solues comerciais para essas plataformas de robs mveis, ainda
existem srias limitaes em relao flexibilidade tanto em termos de hardware utilizado,
como sensores e atuadores, como tambm em relao ao software, que costumam ser
proprietrios e fechados. Essas limitaes se estendem em relao s necessidades de
alteraes de hardware que so comuns, como nos mdulos de sensoriamento e de atuadores.
Isso acaba influenciando de forma decisiva sobre a empregabilidade de tais solues tanto
no mbito geral, como no cientfico e em iniciativas didticas. Por outro lado, uma plataforma
de rob mvel que apresente atributos de manobrabilidade, associada facilidade de
alteraes fsicas (de sensores e atuadores), alm de uma arquitetura de controle, de software
e de hardware, aberta, apresenta-se como uma ferramenta no apenas interessante como
tambm essencial no desenvolvimento de aplicaes relacionadas robtica mvel, assim
como no desenvolvimento de pesquisas cientficas e no ensino de robtica e disciplinas
relacionadas.
O Laboratrio de Automao e Computao Evolutiva - LACE, do Departamento de
Cincia da Computao e Estatstica (DCCE), da Unesp de So Jos do Rio Preto, tem
conduzido pesquisas em tpicos como navegao de robs mveis, empregando diferentes
tecnologias para o sistema de controle de robs mveis, como FPGA, microcontroladores,
dispositivos computacionais embarcveis, dentre outras. Desta forma, tal interesse se
resume a uma plataforma de rob mvel para uso geral, incluindo atividades didticas,
tericas ou experimentais, assim como atividades cientficas envolvendo a robtica mvel e
tpicos relacionados. desejvel, portanto, que essa plataforma de rob mvel possua uma
15
arquitetura que oferea facilidades para o desenvolvimento de aplicaes envolvendo

tpicos como navegao e controle.
Este trabalho tem como objetivo apresentar a pesquisa e o desenvolvimento de uma
plataforma de rob mvel de baixo custo, de arquitetura de hardware e software aberta e que
oferea suporte a diferentes cenrios e tecnologias de sistemas de controle atravs de uma
interface padronizada de comunicao. A plataforma de rob mvel apresentada implementa
conceitos simples e bem estabelecidos como arquitetura cliente-servidor, sistema
fortemente acoplado e interface de comunicao serial. Devido a essa simplicidade conceitual
envolvida, esta plataforma pode facilmente ser empregada tanto em aplicaes de carter
geral, de iniciativas didticas ou cientficas. Alm disso, a plataforma capaz de ser
modificada e expandida de acordo com as necessidades das aplicaes devido sua
flexibilidade ainda que dentro de suas limitaes. Assim, esta plataforma de baixo custo se
apresenta como uma alternativa vivel para a facilitao do processo de desenvolvimento de
software de controle, uma vez que motiva o reaproveitamento de mdulos de modo
independente ao esquema ou tecnologia do sistema de controle adotado.
Por fim, dois experimentos foram elaborados e realizados com o intuito de validar a
plataforma apresentada, mostrando a arquitetura proposta empregada em duas iniciativas
que abordam diferentes aspectos envolvendo a robtica mvel. Os software de controle da
plataforma destas aplicaes foram implementados utilizando a linguagem de programao
C++, tanto para ambiente Windows quanto para Arduino.
1.1
Trabalhos correlatos
Existem outras iniciativas na literatura que propuseram ambientes e arquiteturas

voltadas para o desenvolvimento de robs mveis, que objetivaram a facilitao e a
simplificao do processo de desenvolvimento de robs mveis. o caso de trabalhos como
por exemplo, o OROCOS (BRUYNINCKX, 2001), o Player/Stage (GERKEY et. al., 2003) e o
Pyro (Phyton Robotics) (BLANK et. al., 2003), que propem ferramentas e ambientes de
16
programao robticos, com bibliotecas de cdigo aberto concebidas em diversas linguagens

de programao, adquirindo assim, neutralidade em relao plataforma. J Bonarini et. al.
(2013) apresentam o R2P (Rapid Robot Prototyping) com uma abordagem de arquitetura
modular e aberta tanto de hardware como de software, objetivando prototipagem rpida e
baixo custo. Existem outras abordagens, como o caso do URB (Universal Robot Bus)
(SARANLI et. al., 2011), na qual apresentado um framework composto por uma arquitetura
modular de barramento, um protocolo capaz de prover desempenhos em tempo real, e um
conjunto de APIs (Application Programming Interfaces) associados s bibliotecas de interface,
que somados, so capazes de prover modularidade, flexibilidade e desempenho em
aplicaes envolvendo robtica mvel e instrumentao. Uma das caractersticas que se
mostra comum em todos esses trabalhos citados a abstrao obtida por software para
compensar a heterogeinedade dos dispositivos de hardware.
1.2
Motivao
O crescente interesse por pesquisas na robtica mvel tem sido impulsionado pelos
recentes avanos tecnolgicos. Na literatura, existem diversas propostas que objetivaram a
facilitao do processo de desenvolvimento de robs mveis como, por exemplo, projetos
citados em 1.1. Ainda que existam plataformas comerciais e proprietrias destinadas a tal
finalidade, questes como flexibilidade e custo acabam dificultando a aplicabilidade de tais
plataformas em iniciativas didticas ou cientficas.
O LACE o Laboratrio de Automao e Computao Evolutiva do Instituto de
Biocincias, Letras e Cincias Exatas (IBILCE da Unesp de So Jos do Rio Preto), responsvel
por pesquisas na rea de robtica e viso computacional. Uma situao que se passa
atualmente no LACE o interesse por uma plataforma de rob mvel, de baixo custo e flexvel
para ser utilizada em atividades relacionadas robtica mvel. Por ser destinada ao uso geral,
esta plataforma poderia ser empregada tambm em pesquisas e atividades que auxiliem o
aprendizado dos alunos da graduao. Para a pesquisa, esta plataforma de rob mvel
poderia ser empregada para desenvolver e avaliar tcnicas de navegao, controles de
17
tracionamento, arquiteturas de controle, viso computacional, colaborao e interao

humano-rob, dentre outros tpicos. J para o uso didtico, esta plataforma poderia ser
utilizada em atividades prticas voltadas aos alunos da graduao e relacionadas robtica
como eletrnica, circuitos digitais, assim como em algoritmos e inteligncia artificial. Logo, o
desenvolvimento de uma plataforma capaz de atender necessidades gerais e, que ainda possa
explorar iniciativas de estudos, alm de focar no baixo custo e simplicidade, pode contribuir
de forma significativa tanto no processo de aprendizado como em atividades voltadas
pesquisa e outras que envolvam a robtica mvel.
1.3
Objetivos gerais
O objetivo geral do presente trabalho pesquisar, desenvolver e avaliar uma

plataforma de rob mvel de arquitetura de hardware, controle e software, aberta, simples,
flexvel e de baixo custo, destinada a propsitos gerais.
1.4
Objetivos especficos
Os objetivos especficos deste trabalho so:
Investigar a natureza de um sistema robtico, os diversos aspectos como so

tratadas as questes da tecnologia robtica e como tm sido as abordagens das
diversas solues e propostas apresentadas na literatura;
Desenvolver uma plataforma flexvel que facilite e flexibilize o processo de

desenvolvimento de aplicaes e software de controle de robs mveis por meio
de uma interface de comunicao padronizada e da abstrao das camadas de
aquisio de dados e de controle de atuadores;
18
Implementar mdulos essenciais de hardware destinados locomoo e

navegao para robs mveis e seus respectivos mdulos de controle.
1.5
Requisitos
Para que este trabalho possa cumprir todos os objetivos almejados, buscou-se
satisfazer alguns requisitos funcionais, que sero brevemente descritos nesta seo.
Flexibilidade de uso: como j mencionado, em relao finalidade de uso,

pretendido disponibilizar uma plataforma de rob mvel para ser empregada
em iniciativas gerais que envolvam robtica mvel. Para tal, este deve
apresentar caractersticas que o torne flexvel, mas ao mesmo tempo simples,
possibilitando e motivando sua utilizao tambm em outras atividades e
iniciativas
relacionadas.
Em relao
arquitetura
de
hardware,
desenvolvimento e a construo da plataforma de rob mvel, considerou, por

exemplo, a questo da adaptabilidade, de modo que diferentes esquemas de
controle possam ser implementados e investigados, utilizando a mesma
estrutura bsica de hardware embarcada no rob. Foi concebido um nmero
inicial de mdulos de hardware padro de modo que a plataforma oferea
suporte iniciativas essenciais envolvendo robtica mvel e, ainda,
possibilitar alteraes e acrscimos de mdulos de hardware.
Ambiente de aplicao e locomoo: a plataforma de rob mvel concebida ser

destinada a aplicaes terrestres, em superfcies planas com poucas
irregularidades. Logo, em termos estruturais mecnicos, seu sistema de
locomoo dever ser adequado a tal ambiente, e para o seu desenvolvimento.
Sendo assim, foi escolhido um mecanismo de locomoo, levando em
considerao questes como manobrabilidade, graus de liberdade, estabilidade
e alguns aspectos que cada forma de locomoo terrestre acarreta, como, por
19
exemplo, aspectos relacionados eficincia, consumo de energia, dimenses e

custos da plataforma de rob mvel.
Interface de comunicao e abstrao: a plataforma de rob mvel deve oferecer

acesso facilitado aos seus mdulos de hardware atravs de uma interface de
comunicao padronizada e simplificada, somada abstrao dos detalhes
tcnicos relacionados aos dispositivos de hardware implementados. A inteno
no desenvolvimento da plataforma robtica a reduo da necessidade de
conhecimentos avanados de hardware para o programador atravs de um certo
grau de abstrao, e ainda buscar independncia da plataforma de controle
escolhida. Uma vez que o software de controle se adeque ao protocolo de
comunicao disponibilizado, o controle poder ser embarcado, empregando
tecnologias embarcveis como FPGA, microcontroladores, Arduino, Raspberry
PI ou, ainda, ser remoto, empregando tecnologias de transmisso de dados por
RF, como por exemplo, Zigbee, Wi-Fi ou Bluetooth.
1.6
Escopo do trabalho
A proposta deste trabalho abrange o desenvolvimento, concepo e disponibilizao de

uma plataforma de hardware de rob mvel para ser destinada a propsitos gerais. A Figura
1.1 ilustra a plataforma proposta neste trabalho e sua abrangncia.
20
Software de
Controle
Interface de
Comunicao
Firmware
Software
embarcado
Hardware
Expanso
Atuadores
Atuadores
padres
Expanso
Sensores
Microcontrolador
Eletrnica
Sensores
padres
Estrutura Mecnica
Plataforma
proposta no
Trabalho
Controle
API Controlador
Figura 1.1 Abrangncia do trabalho proposto.

Fonte: Elaborado pelo autor.
plataforma
abrange
estruturao
mecnica,
eletrnica,
escolha
do
microprocessador, programao do software embarcado (firmware e interface de

comunicao), e API (Application Programming Interface) do controlador.
Ainda que seja desenvolvido um software de controle bsico, este ser de carter
unicamente para fins de testes de implementao e avaliao da plataforma. Quanto aos
paradigmas de controle robtico, no sero abordados com profundidade as diversas
concepes possveis, como controle direto, indireto e sem estado, controle baseado em
comportamento, mquina de estados finitos, arquiteturas de subsuno, e lgica fuzzy, j que
essas discusses se encontram fora do escopo do que est sendo proposto neste trabalho.
Ainda que o presente trabalho implemente algum mtodo de navegao e de acionamento do
sistema de trao, tais tpicos no sero aprofundados, devido s suas extenses. Desta
forma, questes relacionadas s tcnicas e algoritmos de navegao, por exemplo, ficaro
abertas discusso, podendo desta forma, serem objetos de estudo em trabalhos futuros. Tal
raciocnio se estende tambm em termos do sistema de controle de tracionamento e
locomoo, visando dar uma liberdade maior ao desenvolvedor do software de controle da
plataforma robtica proposta.
21
1.7
Mtodo
Para o desenvolvimento deste trabalho, o mesmo foi dividido nas etapas a seguir:
1. Levantamento de requisitos do trabalho;
2. Sntese da reviso bibliogrfica;
3. Desenvolvimento e implementao da plataforma proposta;
4. Testes de validao;
5. Consideraes finais.
A primeira etapa consta o levantamento dos requisitos do trabalho para tratar das
especificaes e funcionalidades que foram consideradas ao longo do desenvolvimento deste
trabalho. O escopo do trabalho delimita a proposta dos aspectos e tpicos que no foram
abordados neste trabalho.
A segunda etapa abrange o estudo da fundamentao terica, das tecnologias
envolvidas e do estado da arte da robtica mvel. A reviso bibliogrfica abordou alguns dos
aspectos fundamentais a respeito dos robs mveis autnomos, uma vez que trata-se do
tema principal e foco deste trabalho. Neste sentido, foi estudada a definio de robs mveis
autnomos, questes sobre ambiente de aplicao, locomoo, navegao, arquiteturas de
controle e de software que do suporte ao desenvolvimento de aplicaes na robtica mvel,
finalizando com um breve levantamento sobre comunicao de dados na robtica. Atravs
dos estudos realizados envolvendo a parte conceitual da robtica mvel, foram embasadas e
apresentadas as partes que foram escolhidas para compor a plataforma.
A terceira etapa trata do desenvolvimento e concepo da plataforma de rob mvel.
Em termos de hardware foram definidos os tipos de dispositivos essenciais de sensoriamento
e atuao que foram implementados no sistema robtico, abrangendo o sistema de
comunicao de dados e software embarcado. Foram apresentadas as escolhas dos aspectos
22
mecnicos, interface fsica de comunicao e seu protocolo, e por fim, a API da plataforma
que facilitar o processo de desenvolvimento de aplicaes. Nesta etapa foram brevemente
analisadas algumas possibilidades de linguagem de programao, ambientes de
desenvolvimento e tecnologias adotadas. A importncia desta etapa se deve avaliao das
diversas possibilidades existentes, do sistema operacional linguagem de programao e
sistemas de comunicao, incluindo os ambientes de desenvolvimento e ferramentas. Inclui
ainda uma breve descrio das tecnologias adotadas para a construo da parte estrutural
mecnica, dos dispositivos perifricos (sensores e atuadores), concepo do Controlador,
Interface de Comunicao e sua API de suporte. Foi decidido expor no Apndice C o
detalhamento do protocolo de comunicao da plataforma de rob mvel concebida.
A quarta etapa destinada aos testes e validaes da plataforma apresentada, ou seja,
para verificar se os objetivos almejados foram alcanados com a elaborao de dois
experimentos. Cada experimento buscou verificar diferentes propriedades da plataforma. O
primeiro experimento avaliou a capacidade da plataforma de oferecer suporte uma
aplicao genrica envolvendo navegao, assim como a facilidade de uso da API de
plataforma. J o segundo experimento, sua flexibilidade em relao s tecnologias de controle
e facilidade de alteraes de hardware por meio de uma aplicao cientfica hipottica.
Finalmente, a quinta e ltima etapa, consiste na apresentao das concluses da
presente dissertao e discusses sobre algumas possibilidades de trabalhos futuros.
1.8
Organizao do trabalho
O texto desta Dissertao de Mestrado foi organizado da seguinte forma: o captulo 1

trata da apresentao do trabalho; o captulo 2 discute seu arcabouo terico; o captulo 3
apresenta a plataforma de rob mvel proposta e o rob mvel Kihon; o captulo 4 apresenta
os experimentos de validao; o captulo 5 encerra a dissertao. O contedo de cada um dos
captulos mencionados acima descrito a seguir, compondo o texto da dissertao.
23
O captulo 1 apresenta o tema do trabalho proposto, trabalhos correlatos, seus objetivos

gerais e especficos, seguido pelos requisitos, alm de apresentar o mtodo e a organizao
deste trabalho.
O captulo 2 apresenta uma sntese da reviso bibliogrfica na qual analisa
sucintamente alguns aspectos da robtica mvel. Nela, apresentada uma definio de robs
mveis autnomos; a composio de um rob mvel, tratando brevemente sobre ambiente
de aplicao, locomoo e navegao. Ainda apresenta o levantamento realizado a respeito
das arquiteturas de controle e de software no contexto da robtica mvel e encerrando com
os sistemas de comunicao na robtica.
O captulo 3 introduz e discute a plataforma proposta neste trabalho, implementada por
meio da concepo do rob mvel Kihon. Apresenta a arquitetura da plataforma escolhida, o
sistema de comunicao de dados, e a API que dar suporte ao desenvolvimento de aplicaes.
Nesta etapa foram relevados e definidos os aspectos tecnolgicos empregados, evidenciando
desta forma como a plataforma dar suporte aos objetivos almejados neste trabalho e como
cada mdulo foi desenvolvido.
O capitulo 4 apresenta os experimentos prticos realizados com a plataforma de rob
mvel concebida com o intuito de averiguar se esta capaz de satifazer os objetivos
almejados, com a discusso dos objetivos, desenvolvimento e resultados dos experimentos.
Por fim, o captulo 5 finaliza esta dissertao por meio das consideraes finais acerca
do trabalho realizado, e apresenta algumas das possibilidades de trabalhos futuros.
24
SNTESE DA REVISO BIBLIOGRFICA
A robtica, ou seja, o estudo do rob, um campo relativamente novo da tecnologia

moderna (SPONG et. al., 2005). E de fato, suas razes incluem fundamentos de diversas reas
tradicionais do conhecimento, dentre as quais possvel citar a engenharia eltrica,
engenharia mecnica, mecatrnica, cincia da computao e matemtica. Ainda possvel
mencionar reas como a da psicologia cognitiva e neurocincia, por estudar a forma como
organismos biolgicos solucionam problemas similares (DUDEK; JENKIN, 2010), assim como
outros trabalhos na robtica inspirados na biologia, como os apresentados na obra de Habib
(2007). Isso faz da robtica um campo intrinsecamente multidisciplinar e extenso. Assim,
existem diferentes formas de abordar as questes que envolvem a robtica e, portanto, esta
pode vista por diferentes perspectivas. E ainda, a construo de um sistema autnomo mvel
sempre conduz a uma interao de sensores e efetores com o software responsvel pelo
controle (KUBITZ et. al., 1998). Observando as plataformas robticas comerciais disponveis
e as encontradas na literatura revela uma grande variedade de arquiteturas de software
disponveis na robtica. De fato, apesar dos avanos tecnolgicos recentes e das diversas
propostas na literatura, houve pouco avano no estabelecimento de uma padronizao dos
sistemas de controle utilizados, assim como no h sistema operacional robtico
estabelecido (SIEGWART; NOURBAKHSH, 2004), uma vez que robtica mvel uma rea
recente em comparao s areas tradicionais do conhecimento. Este captulo de reviso
bibliogrfica apresenta um estudo a respeito da robtica mvel sob a perspectiva da
computao.
2.1
Robs mveis autnomos
Assim como em muitas outras reas da cincia e tecnologia, no h uma padronizao

e nem mesmo um consenso no que diz respeito prpria definio para rob. A definio
oficial de rob dada pela Robotic Industries Association (RIA) e mencionada em Spong et. al.
25
(2005) pode ser entendida como um manipulador multifuncional reprogramvel

desenvolvido para mover materiais, peas, ferramentas, ou dispositivos especializados por
meio de movimentos programados para executar uma variedade de tarefas. Entretanto, esta
definio se volta basicamente a robs industriais. J Bekey (2005), ainda que vagamente,
apresenta uma breve definio de rob como uma mquina que pensa e age. No entanto,
essa definio abrangente pode caracterizar sistemas automatizados que no so
considerados robs. Uma outra definio dada por Matari (2007) descreve rob como "um
sistema autnomo que existe no mundo fsico e que pode sentir seu ambiente e atuar sobre
ele de modo a alcanar alguns objetivos". A partir de tal definio, possvel deduzir que um
rob possui, alm de um corpo fsico, formas de sensoriamento e atuadores que o permitem,
por meio de um sistema de controle autnomo, coordenar seus recursos de forma a cumprir
determinadas tarefas.
No entanto, tal definio ainda engloba dispositivos robticos, como os considerados
manipuladores, assim como os robs mveis. No manipulador (brao robtico), o rob efetua
operaes de manipulao dentro do seu limite de alcance (volume de trabalho), uma vez
que sua base permanece estacionria, ou seja, fixa. A Figura 2.1 (a) ilustra um exemplo de
rob manipulador. Por outro lado, na robtica mvel, o rob capaz de se locomover atravs
de um determinado ambiente, o que expande o campo de operao. Levando isso em
considerao, a robtica mvel enfatiza questes relacionadas ao entendimento de
ambientes substancialmente maiores se comparado a reas como a robtica de manipulao,
viso computacional ou inteligncia artificial, pois estas ltimas apresentam ambientes
vistos a partir de uma posio vantajosa (DUDEK; JENKIN, 2010). A Figura 2.1 (b) ilustra um
exemplo de rob mvel.
26
(b)
(a)
Figura 2.1 - Exemplos de robs: (a) Rob manipulador; e (b) Rob mvel.
Para que o rob mvel consiga se locomover de forma satisfatria atravs de um

determinado ambiente, necessrio que o mesmo possua mecanismos que o torne capaz de
se mover e coletar informaes a respeito do ambiente no qual est inserido. Alm disso, deve
reconhecer eventuais objetos e obstculos para, ento, tornar possvel sua navegao no
ambiente de forma harmoniosa e livre de colises. J para executar uma determinada tarefa,
o rob necessita de um sistema de controle para coordenar de forma sincronizada a utilizao
de seus mdulos sensores e atuadores. Desta forma, para sua concepo, dever ser levada
em considerao a estruturao de seu corpo, de forma que seja capaz alm de se deslocar,
como interagir adequadamente com objetos, outros robs ou seres vivos.
No contexto da robtica, na qual a autonomia pode ser tratada em termos de regime
operacional, uma definio interessante pode ser obtida segundo Barber e Martin (1999) que
a descreve como "uma capacidade ativa do rob em perseguir seus objetivos sem a
interveno de nenhum outro agente nos processos de tomada de deciso que sero usados
para determinar como tais objetivos devero ser perseguidos". Uma outra definio de
autonomia pode ser entendida como a habilidade de um agente ou indivduo de tomar suas
prprias decises e agir de acordo elas (MATARI, 2007). Alm disso, no incomum que
robs sejam comparados a sistemas biolgicos vivos, uma vez que compartilham os mesmos
desafios no desenvolvimento de suas tarefas (BEKEY, 2005). Afinal, conforme Medeiros
(1998), um rob mvel autnomo deve ser extremamente autossuficiente para operar em
27
ambientes complexos, desafiadores e parcialmente conhecidos, utilizando limitados recursos

fsicos e computacionais. E de acordo com Dudek e Jenkin (2010), a autonomia na robtica
pode ser total ou parcial, onde, na autonomia total, o sistema projetado de forma a operar
sem a necessidade de ser controlado todo o tempo por humanos e, na autonomia parcial, esse
controle humano requerido constantemente. Ainda, conforme os autores, existem poucos
robs mveis que podem ser considerados totalmente autnomos operacionalmente.
2.2
Composio de um rob mvel
A partir da definio de rob mvel autnomo dada por Matari (2007) possvel ter
uma noo dos principais componentes que o compe. esperado que o rob possua um
corpo fsico para que possa efetuar alguma tarefa no mundo fsico. Sensores so
fundamentais para que o rob seja capaz de sentir e perceber o ambiente. Da mesma forma,
atuadores so essenciais para que o rob consiga atuar sobre o ambiente. Por ltimo, para
que o rob seja autnomo, um sistema de controle no supervisionado se faz necessrio.
Um rob deve existir e atuar no mundo fsico (BROOKS, 1991), pois apenas o mundo
real apresenta a riqueza de desafios a serem superados pelo projetista do rob, ao contrrio
dos simuladores, que so limitados pela complexidade do modelo do mundo em sua
implementao por meio de software. Como consequncia, os robs devem obedecer s
mesmas leis fsicas as quais todos se submetem, da mesma forma como os seres humanos,
animais, objetos e outros materiais existentes. Isso inclui os mesmos cuidados em relao s
colises, quedas, objetos e obstculos. Em suma, possuir um corpo adequado que o permita
interagir adequadamente com o ambiente e tudo o que se encontra nele tambm se torna um
aspecto fundamental e que poder definir o sucesso ou o fracasso de uma base mecnica
robtica. Portanto, fundamental conhecer e definir o ambiente em que o rob ser inserido.
Alm disso, o processo de desenvolvimento de um rob deve considerar tanto limitaes
tecnolgicas como financeiras.
28
De modo a objetivar um sistema robtico mvel com elevado nvel de autonomia

operacional e para torn-lo capaz de operar em ambientes desestruturados, necessrio
satisfazer um nvel de independncia de forma que o rob tenha conhecimento a respeito do
que existe ao seu redor, adquirindo e manipulando um modelo detalhado do ambiente de
aplicao. De forma anloga aos animais, que possuem seus prprios mecanismos sensoriais
muito bem adaptados e adequados s suas necessidades, os robs necessitam igualmente de
mecanimos que possibilitem sentir no somente o ambiente, mas tambm coletar
informaes a respeito de si mesmo. Para tal, existe a necessidade de uma variedade de
sensores para ser capaz de interagir com o mundo real, e de mecanismos para extrair
informaes significativas a partir dos dados coletados (ELFES, 1986). Conforme Matari
(2007), na robtica, os sensores so dispositivos fsicos que permitem aos robs coletar
informaes a respeito de si prprios (proprioceptivos) e, tambm, do ambiente que os
cercam (exteroceptivos). E ainda, de acordo com a autora, os termos sentir e perceber so
sinnimos no contexto da robtica. A partir da ponderao de aspectos eletrnicos,
processamento de sinal e computacional, a autora ainda categoriza os sensores de acordo
com trs nveis de processamento, sendo estes: nvel baixo (sensores de contato e
odometria); nvel mdio (sonares e voz) e nvel alto (cmeras). Os sensores eletrnicos
podem ser classificados em dois diferentes tipos, de acordo com o tipo de sinal fornecido em
sua sada: digital e analgico. Sensores digitais podem fornecer uma representao binria
de um dado fenmeno, por exemplo, um boto de contato est pressionado ou no, ou
transmitir a medida por meio de um protocolo de comunicao. Sensores analgicos
necessitam de converso para a forma digital, ainda que possam ser conectados s entradas
de circuitos de converso analgico para digital, ou seja, conversores AD. Sensores que
necessitam processamento de sinal exigem uma etapa de anlise e modificao sobre o sinal
coletado para obter informaes e, assim, torn-los adequados para uma dada aplicao. J
os sensores relacionados computao necessitam de complexos processamentos
envolvendo viso computacional, ou seja, como os sistemas artificiais (mquinas) obtm
informaes a partir de imagens ou dados multidimensionais.
Devido s limitaes intrnsecas apresentadas por qualquer tipo de sensor, existe a
necessidade de utilizar mltiplos sensores e combinar suas informaes obtidas para, ento,
29
estimar um modelo de representao coerente do mundo real. Desta forma, a escolha dos
mecanismos adequados, assim como o devido posicionamento fsico dos mesmos e a
combinao de mltiplos sensores, possibilitam ao rob sentir as informaes necessrias
para que ele possa executar suas tarefas de forma satisfatria.
Os atuadores na robtica so dispositivos fsicos responsveis pela atuao do rob
dentro do seu ambiente de aplicao. Na robtica mvel, os atuadores tambm esto
intimamente ligados ao sistema de locomoo (SICILIANO; KHATIB, 2008). Os efetuadores
permitem que os robs atuem fisicamente sobre seus ambientes, seja para se locomoverem
ou para manipularem objetos. Os efetuadores so compostos por mecanismos bsicos
chamados atuadores (MATARI, 2007). Na biologia animal, possvel relacionar os
efetuadores robticos s pernas, asas, bocas e outras partes que permitam a um dado animal
atuar sobre o ambiente. Nos animais, os atuadores so como os msculos e tendes que
compem braos e pernas. Na robtica, atuadores podem ser atuadores eltricos, cilindros
pneumticos ou hidrulicos, entre outros dispositivos, embora na robtica mvel sejam
utilizados basicamente atuadores eltricos (motores) uma vez que possibilitam a utilizao
de baterias para a sua alimentao.
O sucesso de um sistema robtico influenciado no apenas pelo custo da plataforma,
mas tambm pela qualidade e disponibilidade de seus mdulos e componentes no mercado.
Logo, desejvel que o hardware do rob mvel, assim como seus componentes eltricos e
mecnicos, sejam reaproveitveis, em outras palavras, flexveis para satisfazer diferentes
requisitos e tambm permitir rpidos ajustes a novas aplicaes (MERTEN; GROSS, 2008). A
reutilizao pode tornar o desenvolvimento muito mais rpido, alm de reduzir
substancialmente o ndice de erros. No entanto, ainda de acordo com os autores, a
reutilizao do hardware em sistemas robticos, assim como a possibilidade de adicionar
componentes, ainda continua muito restrita nas solues propostas na literatura. De fato,
como os componentes de hardware empregados na robtica costumam ser altamente
especializados e adaptados s aplicaes finais, isso acaba dificultando na hora de adicionar
novos mdulos de hardware. A soluo de adotar arquiteturas de hardware modulares, em
outras palavras, em subsistemas, ainda que seja uma abordagem vlida, no se mostra
30
flexvel suficiente, alm de possuir um pequeno nmero de funcionalidades (MERTEN;

GROSS, 2008). Por outro lado, as dimenses e espaos bem definidos na base mecnica do
rob podem facilitar a adio e adaptaes exigidas na insero de mais sensores e atuadores
e, assim, ampliar os recursos de um rob, possibilitando o reaproveitamento de sua base
robtica.
A utilidade de um agente robtico autnomo sua habilidade de executar uma tarefa
que lhe foi atribuda, sem a necessidade de superviso constante (NEVES; OLIVEIRA, 1997).
O grau de autonomia na robtica est diretamente relacionado quantidade de sensores de
aquisio de dados, processamento e tomada de deciso (SANTIAGO; MEDEIROS, 2011). Na
robtica mvel, a autonomia proporciona tanto o planejamento como as tomadas de decises
do rob mvel e est diretamente associada ao sistema de computao. E, geralmente, o
sistema de computao fica atrelado a um sistema de comunicao, conferindo assim, a
capacidade de se configurar uma arquitetura distribuda (DUDEK; JENKINS, 2010) ou, ainda,
de embarcar sistemas computacionais.
Uma outra forma de descrever a composio de um rob mvel por meio da
modularizao. Para facilitar o entendimento e o gerenciamento de sistemas complexos,
comum utilizar a tcnica de segregao, dividindo um sistema complexo em subsistemas
menores e mais simples. Aplicando este conceito na robtica, possvel efetuar sua
decomposio em duas categorias de mdulos: fsicos e lgicos. Mdulos fsicos representam
a parte do rob mvel responsvel pela sua manifestao no mundo real, abrangendo
estruturas mecnicas, sensores, atuadores, e sistemas embarcados. J os mdulos lgicos
compreendem recursos essenciais de software para processar os dados provenientes do
mdulo fsico (NIRANJAN et. al., 2012), como por exemplo as arquiteturas de controle e
sistemas de navegao. De fato, robs autnomos so sistemas complexos que requerem a
integrao e interao eficiente entre numerosos componentes heterogneos, tanto de
hardware como software.
31
2.3
Ambiente de aplicao
Um rob mvel, ao contrrio dos agentes de software, que habitam em um ambiente

simulado (como discutido em 2.2) deve ser capaz de executar suas tarefas no mundo real
(KRAMER; SCHEUTZ, 2007), e especificamente, em seu ambiente de aplicao no qual foi
destinado a operar. Portanto, o processo de elaborao do corpo de um rob mvel deve ser
feito de modo a buscar a forma que melhor se adapta aos requisitos da aplicao. Para tal,
fundamental conhecer o ambiente de aplicao. Existem diferentes ambientes nas quais um
rob mvel pode ser projetado para atuar, dentre os quais possvel citar: ambiente aqutico
(seja na superfcie ou submerso), areo ou terrestre. E de modo que o rob mvel seja capaz
de se locomover em um determinado ambiente, tanto sua composio como a disposio de
seus mecanismos devem permitir que o rob mvel coexista e, ainda, oferecer-lhe a
habilidade de se deslocar e navegar satisfatoriamente dentro desse ambiente. Alm disso, o
rob deve ser capaz de executar sua tarefa adequadamente.
Desenvolver um rob mvel um processo criativo e ao mesmo tempo desafiador para
o projetista, uma vez que o fora a pular etapas que o sistema natural de evoluo levou
milhes de anos para atingir resultados timos. Desta forma, o processo de desenvolvimento
do corpo robtico deve levar em considerao aspectos estruturais e mecnicos necessrios
para que o rob mvel consiga alcanar seus objetivos quando inserido em seu ambiente de
aplicao. comum ainda procurar inspiraes em reas como biologia, em busca de
solues particulares (HABIB, 2007). Trata-se de uma tarefa multidisciplinar e complexa, j
que abrange conhecimento de diferentes reas do conhecimento e, muitas vezes, exige
solues criativas por parte dos desenvolvedores.
Alm disso, o desenvolvimento de um rob mvel tambm depende de outros fatores,
como a tecnologia disponvel e as limitaes econmicas. Desta forma, no processo de
desenvolvimento deve-se ter em mente o custo financeiro e a tecnologia disponvel no
momento. Alm disso, a escolha de seus componentes deve ser feita sem perder de vista o
propsito do rob. Isso inclui o dimensionamento adequado de seu corpo e de seus
componentes, incluindo consideraes relacionadas s suas especificaes, como consumo
32
energtico, dimenses, formas, materiais e pesos, e ainda, sem perder de vista o custo. Um
outro aspecto importante a manutenibilidade, ou seja, a facilidade que o sistema oferece
execuo de manuteno.
Centrando nos requisitos levantados em 1.5, este trabalho se limitou a abordar os
aspectos relevantes para a estruturao fsica e mecnica de um rob mvel destinado ao
ambiente terrestre, cujas superfcies so planas e com poucas irregularidades.
2.4
Locomoo
Na robtica mvel, a locomoo refere-se ao modo como o rob se move de um lugar a

outro (MATARI, 2007). Como mencionado em 2.3, os robs mveis podem se locomover
sobre o solo, na gua e no ar com o uso de mecanismos adequados. Existe uma variedade de
formas possveis de se fazer isso e muitas delas se baseiam em sistemas biolgicos
encontrados na natureza, sejam areos, aquticos ou terrestres. Robs mveis aquticos so
os que permanecem sobre a gua, enquanto que os capazes de locomover sob a superfcie
so categorizados como sub-aquticos. Robs mveis areos e sub-aquticos so mais
difceis de se controlar, uma vez que podem se mover em mais dimenses (3D), assumindo
posicionamentos mais complexos, uma vez que, quanto maior o grau de liberdade (do termo
em ingls: Degree Of Freedom, DOF), mais difcil se torna o controle.
No caso da locomoo em ambiente terrestre possvel citar mecanismos como andar,
pular, deslizar e rolar, que so bastante comuns na natureza. No entanto, h uma exceo cuja
inveno atribuda ao ser humano, e que alcana elevado nvel de eficincia para locomoo
em superfcies planas: a roda (SIEGWART; NOURBAKHSH, 2004). As rodas se apresentam
como uma alternativa em relao s outras formas de locomoo, como as encontradas na
natureza. O sistema de locomoo baseado em rodas explora a frico do ponto de contato
de suas rodas com o cho para deslocar. Tal sistema de locomoo apresenta alguns aspectos
interessantes, como maior eficincia em relao aos mecanismos de locomoo baseados em
pernas, baixa complexidade na implementao e despreocupao com o balano do rob.
33
Trs rodas em contato permanente com o cho o suficiente para estabilizar o equilbrio. O
uso de quatro ou mais rodas necessitam de sistemas de suspenso para manter o contato de
todas as rodas com a superfcie. Com a utilizao de rodas, a preocupao se volta
basicamente a problemas de tracionamento, estabilidade, manobrabilidade e controle.
Robs mveis com rodas so mais eficientes em termos de consumo de energia em
superfcies planas e lisas, quando comparados a robs mveis que utilizam pernas e esteiras
(KALE; SHRIRAMWAR, 2009). Alm disso, requerem componentes relativamente mais
simples, o que os tornam mais fceis e baratos de se construir. E a tarefa de controlar a trao
das rodas menos complexa que a de controlar e coordenar os atuadores de pernas com
mltiplas articulaes. Entretanto, em terrenos irregulares, sistemas robticos que utilizam
pernas se apresentam mecanicamente superiores em termos de locomoo quando
comparados a sistemas baseados em rodas e esteiras (HABIB, 2007). Siegwart e Nourbakhsh
(2004) afirmam que, geralmente, a locomoo por pernas requer maior grau de liberdade, e
portanto, apresenta maior complexidade mecnica do que a locomoo por rodas. possvel
observar que a escolha da abordagem adotada, assim como o devido direcionamento
aplicao, so aspectos importantes na concepo do sistema de locomoo de um rob
mvel. Questes relacionadas locomoo robtica baseada em pernas no sero
aprofundadas por se tratar de um tpico relativamente extenso e complexo que foge do
escopo da proposta e, ainda, questes relevantes relacionadas a robs mveis baseados em
pernas podem ser encontradas em Habib (2007).
Diferentemente da robtica de manipulao, a robtica mvel traz consigo um grande
desafio que a estimao do posicionamento, j que de acordo com (SIEGWART;
NOURBAKHSH, 2004), no existe uma forma direta ou instantnea de determinar o
posicionamento de um rob mvel. Logo, segundo os autores, para estimar a movimentao
do rob, deve-se recorrer compreenso e modelagem cinemtica do modelo de locomoo
adotado. A robtica mvel deve necessariamente recorrer cinemtica para compreender
sua locomoo. A cinemtica o estudo do comportamento de sistemas mecnicos, sendo,
portanto, essencial no projeto mecnico do robo mvel para torn-lo apto a cumprir suas
tarefas e tambm para desenvolver o software de controle responsvel por sua locomoo.
34
Ainda, conforme Siegwart e Nourbakhsh (2004), no caso dos robs mveis baseados
em rodas, este processo comea com a descrio da contribuio que cada roda oferece
movimentao. Um rob que possui mltiplas rodas acarreta mltiplas formas de manipular
essas rodas. Muitos robs mveis empregam um mecanismo de locomoo chamado trao
diferencial (differential drive), no qual duas rodas ativas so alinhadas a um mesmo eixo,
empregando uma ou duas rodas passivas para apoio. A trao diferencial consiste na
habilidade de controlar o acionamento das rodas de modo individual e independente, de
modo que sua resultante movimenta e manobra o rob. O termo diferencial significa que a
rapidez com que o rob executa uma manobra determinada pela diferena entre a
velocidade das duas rodas ativas. Uma anlise detalhada a respeito das modelagens
cinemticas e suas restries pode ser encontrada em Siegwart e Nourbakhsh (2004) e
tambm em Dudek e Jenkin (2010).
Ainda em relao locomoo, existe a questo da estabilidade, uma vez que a maioria
dos robs no pode balanar, inclinar e nem tombar (MATARI, 2007). A estabilidade est
associada ao centro de massa dos corpos e pode ser esttica ou dinmica. Na estabilidade
esttica, o rob pode facilmente permanecer parado sem tombar, no entanto, exige que o
corpo do rob possua formas de prover pontos de contatos suficientes para isso. J na
estabilidade dinmica, o rob deve ativamente se balancear ou mover-se para manter-se
estvel.
Existem algumas mtricas utilizadas para avaliar objetivamente a capacidade de
locomoo de sistemas robticos baseados em rodas. No trabalho de Thueer (2009), algumas
mtricas so apresentadas no intuito de comparar os diferentes arranjos de rodas em
terrenos variados. Estas mtricas, que esto sintetizadas na Figura 2.2, no sero usadas no
decorrer deste trabalho por fugir de seu escopo.
35
Mtricas Tradicionais
Mtricas de Mobilidade
Requisitos de atrito
Sistema
Torque mximo
Altura mxima dos obstculos
Controle
Deslisamento
Estabilidade
Operacional
Violao das restries de velocidade
Figura 2.2 Mtricas de avaliao apresentadas por Thueer (2009).

Fonte: Adaptado de Thueer (2009).
2.5
Navegao
Na locomoo autnoma existe uma variedade de atividades para solucionar problemas,

como o planejamento do caminho de curto e longo prazo, desvio de obstculos, deteco de
emergncias, dentre outras (ELFES, 1986). E essas diferentes atividades so resolvidas por
mdulos que executam servios especficos. A navegao na robtica mvel pode ser
sumarizada em 3 questes: "onde estou?", "para onde vou?" e "como chego l?" (LEONARD;
DURRANT-WHYTE, 1991).
A primeira questo "onde estou?" se refere a uma tcnica de localizao que retorna a
posio do rob dentro do ambiente. A localizao um dos problemas fundamentais na
robtica mvel e no planejamento de caminho (GANGANATH; LEUNG, 2012), uma vez que o
rob mvel no capaz de se mover com preciso (BETKE; GURVITS, 1995), de forma que a
sua posio e orientao real nunca a mesma da posio e orientao desejada.
As tcnicas de localizao podem ser categorizadas em dois grupos: relativas e
absolutas (BORENSTEIN et al., 1996). Tcnicas de navegao relativas fornecem dados de
36
posicionamento em relao localizao inicial do rob. Por outro lado, tcnicas de

navegao absolutas fornecem dados de posicionamento em relao ao ambiente como um
todo. Tcnicas combinadas entre esses dois grupos podem, de forma complementar,
aumentar a preciso da estimativa de localizao do rob.
Borenstein et. al. (1996) categoriza as tcnicas relativas de localizao entre:
Odometria. Trata-se de uma das tcnicas mais comuns para se estimar o quanto um
rob mvel se deslocou (DUDEK; JENKIN, 2010). A odometria feita por meio de encoders
ou seja, codificadores pticos, que medem a quantidade de rotao efetuada pelas rodas ou
pelos motores, para ento, o sistema estimar a distncia percorrida. Trata-se de uma tcnica
simples do ponto de vista matemtico. No entanto, devido sua impreciso, sua taxa de erro
cumulativa ao longo do percurso, no sendo adequado para longas distncias.
Navegao inercial. Este mtodo utiliza acelermetros e giroscpios para medir a taxa
de rotao e acelerao para, ento, estimar a variao do deslocamento de um rob mvel.
Assim como na odometria, no indicado para uso por longos percursos j que os erros se
acumulam ao longo do deslocamento em funo de sua impreciso, pois necessita integrar os
dados medidos para obter a localizao.
J as tcnicas absolutas podem ser:
Marcadores ativos (active beacons). Este mtodo estima a posio global do rob, por
exemplo por triangulao utilizando ultrasom, luz estruturada ou RF a partir da recepo de
sinais de pelo menos trs emissores. Como mtodos recentes de localizao global, possvel
utilizar tecnologias de comunicao de dados sem fios para uso em ambientes internos, como
o Bluetooth, proposto por Raghavan et. al. (2010), o Wi-Fi ou o Zig-Bee, proposto por
Rodrigues et. al. (2012). Tais mtodos utilizam o modelo de propagao de sinal de RF em
ambientes fechados para estimativar a localizao do rob mvel.
Bssolas magnticas. Teoricamente so capazes de localizar um rob mvel em
qualquer parte do globo terrestre, em virtude do campo eletromagntico natural do planeta.
No entanto, apresenta problemas de preciso em ambientes internos, uma vez que o campo
37
eletromagntico terrestre pode sofrer distores nas proximidades de objetos metlicos e

cabos de redes eltricas.
Casamento de modelos. Neste mtodo, a estimativa da localizao obtida com a
comparao das informaes adquiridas por sensores embarcados no rob com um mapa ou
modelo de representao do ambiente, seja geomtrico ou topolgico. Na representao
geomtrica, o ambiente representado por um sistema de coordenadas globais enquanto que
na representao topolgica, o ambiente representado por meio de uma rede de ns e
vrtices.
Pontos de referncia (landmarks). Este mtodo utiliza caractersticas, sejam naturais
(LEONARD; DURRANT-WHYTE, 1991) ou artificiais (MEYER-DELIUS, 2011) do ambiente
para servir como pontos de referncia ao rob mvel. O ambiente deve ser conhecido
antecipadamente (BOREINSTEIN et. al., 1996), seja no uso de pontos naturais ou artificiais.
Sistema de Posicionamento Global (GPS). Utiliza a rede de satlites artificais como
marcadores ativos. O GPS amplamente utilizado para rastrear objetos em ambientes
externos, uma vez apresenta boa estimativa de localizao em locais abertos. Dispositivos
GPS que apresentam alguns cm de impreciso possuem elevado custo atualmente. J os
dispositivos GPS de custo acessvel no mercado possuem impreciso da ordem de alguns
metros (PESSIN et. al., 2011). E segundo Rodrigues et. al. (2012), o GPS no apropriado para
ambientes internos.
Para melhorar a preciso dos sistemas de localizao, comum a utilizao de tcnicas
probabilsticas, como o filtro de Kalman (RODRIGUES et. al., 2012), cadeias de Markov, e o
mtodo de Monte Carlo (MEYER-DELIUS et. al., 2011), assim como h propostas que utilizam
redes neurais artificiais (PESSIN et. al., 2011).
A segunda questo "para onde vou?" est relacionada diretamente com a aplicao do
rob mvel. Usualmente, assume-se que as tcnicas de navegao sejam implementadas uma
vez que se conhece a aplicao do rob e seu ambiente (ALVES et. al., 2012). J a terceira
questo "como chego l?", diz respeito ao planejamento do caminho, ou seja, traar a rota
que o rob mvel dever seguir para cumprir sua tarefa. Considerando que a proposta deste
38
trabalho o desenvolvimento de uma plataforma de rob mvel que oferea suporte s

tcnicas de navegao, ou seja, independe da aplicao, uma discusso a respeito dessas duas
ltimas questes fogem do escopo deste trabalho.
2.6
Arquiteturas de controle
De acordo com Matari (2007), o termo arquitetura na robtica pode ser empregado da
mesma maneira que na computao, uma vez que refere-se concepo de um dispositivo
complexo a partir de um conjunto de blocos bem compreendidos. De fato, a arquitetura tem
sua utilidade na robtica com a organizao formal de blocos e ferramentas disponveis, de
modo a facilitar o desenvolvimento e o entendimento de um sistema robtico.
A arquitetura de controle uma parte essencial da robtica mvel, por prover um
mtodo formal na organizao do sistema de controle (MATARIC, 1992), incluindo
importantes aspectos da reatividade e arquiteturas de subordinao ou subsuno (do termo
em ingls, subsumption) (BROOKS, 1986), e tambm por determinar o fluxo de informaes
dentro de um sistema robtico mvel (MURPHY, 2000). Portanto, a arquitetura de controle
define os componentes arquiteturais do rob mvel e como tais componentes se comunicam
e se relacionam.
O controle de um rob pode ser implementado diretamente em hardware ou em
software. No entanto, quanto maior a complexidade do controle, h uma maior tendncia que
este seja implementado em software (MATARIC, 2007), devido sua flexibilidade e facilidade
de programao. O hardware tende a no oferecer flexibilidade ou adaptabilidade em vista
do seu elevado grau de especializao. Assim, o controle robtico implica na utilizao de
programas (software), sendo executados em tempo real em sistemas computacionais
embarcados ou remotos. No caso remoto, a comunicao pode ser estabelecida com a adoo
de tecnologias de conectividade sem fio (wireless) por RF. Entretanto, a comunicao sem fio
por RF no garante conectividade confivel e em todas as situaes por diversas razes, logo,
no se apresenta como uma alternativa confivel por completo. Por esta razo, mais
39
confivel embarcar o sistema computacional responsvel pelo controle no rob mvel para
garantir tal conectividade.
Na robtica, assim como na computao, a tarefa de solucionar um determinado
problema realizada por meio de programas. Uma sequncia finita de instrues e
procedimentos, executados passo a passo, chamado de algoritmo. Um algoritmo pode ser
executado por uma pessoa, autmato ou por um sistema computacional. A robtica tambm
recorre ao uso de algoritmos para executar tarefas especficas, como de locomoo,
navegao, manipulao, dentre outras. Como a programao robtica faz uso da
programao computacional para executar suas tarefas, ela pode ser implementada nas
mesmas linguagens de programao utilizadas na computao. As linguagens de
programao, como ferramentas de gerao de algoritmos e programas, podem se
apresentar nos diversos padres e usos. Portanto, no existe uma linguagem de programao
tima ou ideal para a robtica, uma vez que existem linguagens destinadas a usos genricos
e outras, desenvolvidas para uma aplicao especfica. Devido diversidade de arquiteturas
de controle, Mataric (2007) afirma que o que realmente importa no a linguagem utilizada
para programar o rob, mas a arquitetura de controle usada para implementar o controle.
A classificao das arquiteturas de controle na robtica mvel em relao organizao
da inteligncia diz respeito relao entre trs primitivas: sentir, planejar e agir (MURPHY,
2000). A partir das primitivas da primeira viso, Murphy (2000) apresenta 3 paradigmas:
Controle Hierrquico;
Controle Comportamental;
Controle Hbrido.
A Figura 2.3 ilustra os trs paradigmas apresentados por Murphy (2000).
40
Planejar
Sentir
Planejar
Agir
Sentir
Agir
Sentir
Agir
Mundo Real
Mundo Real
Mundo Real
(a)
(b)
(c)
Figura 2.3 - Paradigmas das arquiteturas de controle na robtica mvel: (a) Hierrquico; (b)
Comportamental; e (c) Hbrido.
Fonte: Adaptado de Murphy (2000).
No paradigma de controle hierrquico, ilustrado na Figura 2.3 (a), a informao segue

progressivamente o fluxo "sentir-planejar-agir" de forma cclica e deliberada sobre o
ambiente, na qual os sensores alimentam um sistema de planejamento que, por sua vez,
coordena os atuadores do rob (FAYEK, et. al., 1993). Com a presena da primitiva planejar,
este paradigma dedica uma etapa para projetar suas aes futuras, e portanto, sua
reatividade passa a depender do tempo que se leva para se fazer esse planejamento. Essa
demanda de tempo pode se apresentar de forma negativa na reatividade do rob s
alteraes do ambiente. No paradigma de controle comportamental, ilustrado na Figura 2.3
(b), o fluxo da informao se d em "sentir-agir", caracterizado pela ausncia do mdulo
responsvel pelo planejamento, uma vez que o comportamento se estabelece atravs da
forma reativa. Logo, o mapeamento entre os mdulos atuadores e os sensores estabelecida
diretamente, dando a este paradigma capacidade de reagir em tempo real s alteraes
ambientais. O paradigma comportamental similar aos reflexos que no envolvem raciocnio
(Mataric, 2007). J no paradigma hbrido, ilustrado na Figura 2.3 (c), a informao segue o
fluxo na ordem "planejar, sentir-agir", na qual as etapas de sensoriamento e atuao ocorrem
de forma simultnea, enquanto o planejamento ocorre parte, por meio de uma relao entre
as primitivas "sentir-planejar". Logo, este paradigma capaz de apresentar caractersticas de
reatividade do paradigma comportamental ao mesmo tempo que capaz projetar suas aes
futuras.
41
De acordo com Mataric (2007), basicamente, trs aspectos so relevantes na escolha de

qual arquitetura de controle utilizar: escala de tempo, modularidade e representao. Em
termos de escala de tempo, relacionado o tempo de resposta do rob s alteraes
ambientais com a velocidade de reao do rob. A modularidade diz respeito ao modo como
o sistema de controle dividido em componentes funcionais e ainda, como tais componentes
interagem entre si. Por ltimo, a representao se refere forma como as informaes so
armazenadas e codificadas dentro de um sistema robtico. Em discusses relacionadas ao
desenvolvimento da arquitetura de controle, devem ser ponderadas questes como:
diagrama
de
controle,
informao
centralizada
ou
descentralizada,
reatividade,
programabilidade, dentre outros (CHATILA; CAMARGO, 1990). No entanto, devido

extenso deste tpico, este estudo no aprofundar os aspectos relacionados ao
desenvolvimento de arquiteturas de controle, uma vez que este encontra-se fora do escopo
da proposta. Apesar da proposta deste trabalho no conter necessariamente o
desenvolvimento ou a implementao de um mtodo de controle especfico, a importncia
de um estudo sobre arquiteturas de controle neste trabalho se d na medida em que conhecer
as diversas abordagens na literatura fundamental para o desenvolvimento de uma
plataforma capaz de suportar os diversos paradigmas de controle.
As arquiteturas de controle definem o fluxo de informao dentro de um sistema
robtico atravs de um mtodo formal de organizao dos elementos de controle e
estabelecem como os elementos se relacionam. No entanto, a arquitetura de controle no
considera as tcnicas que podem ser empregadas em sua implementao. Isso significa que
a arquitetura de controle estabelece "o que" deve ser feito em relao ao controle, porm no
determina "como" o controle ser formado. Sendo assim, fica a cargo da arquitetura de
software, determinar a composio e a organizao da arquitetura de modo a suportar uma
determinada arquitetura de controle.
De acordo com Santiago e Medeiros (2011), a arquitetura de software na robtica mvel
responsvel pelo gerenciamento de algoritmos de tomada de deciso enquanto a
arquitetura de hardware gerencia os processos de captura de sensores, suas configuraes e
a entrega das informaes dos processos de deciso aos atuadores de movimento. Logo, a
42
arquitetura de software determina como os dados so distribudos e processados,

influenciando diretamente sobre a facilidade de desenvolvimento e reutilizao de cdigo. A
arquitetura de software sempre atua de forma determinante no projeto e na complexidade
do hardware, de modo que uma arquitetura de software bem estruturada pode resultar em
uma tima performance e simplicidade do hardware (NIRANJAN et. al.; 2012).
No contexto da robtica mvel, existem diferentes abordagens no que diz respeito
composio da arquitetura de software na literatura. Geralmente, podem ser classificadas
como bibliotecas, sistemas operacionais, middlewares e baseadas em protocolos de redes de
computadores (ALVES et. al., 2012).
Bibliotecas de software so constitudas por uma coleo de cdigos fonte reutilizveis
e escritas em uma linguagem de programao. Num caso simples de biblioteca, esta
compilada junto ao aplicativo do usurio e integrada ao aplicativo. Isso acaba limitando o
desenvolvimento de software, uma vez que exige uma codificao em uma nica linguagem
de programao. Por outro lado, bibliotecas podem se apresentar na forma de cdigo externo,
oferecendo assim vantagens como a modularidade e no-replicao de cdigo. Entretanto,
ainda se prendem a uma nica linguagem de programao. Ainda que tal dependncia possa
ser superada com a utilizao de tcnicas de FFI (acrnimo de Foreign Function Interface, ou
Interface de Funes Estrangeiras) ou ligao de linguagens. O suporte do SO (Sistema
Operacional) fundamental, j que cada SO gera binrios (executveis) diferentes. Existem
bibliotecas, conhecidas com cross-plataform, que preocupam em gerar cdigo que possa ser
compilado em diversos SOs. O projeto CLARAty (NESNAS et. al., 2003) da NASA um exemplo
de arquitetura cross-plataform aplicada em robs mveis.
Na abordagem de sistema operacional, diferentemente das bibliotecas, as
funcionalidades do rob so vistas como mdulos do sistema operacional e funcionam
apenas internamente ao SO. Suas funcionalidades podem ser invocadas em diversas
situaes por diferentes aplicativos, e o acesso aos mdulos depende da interface de
programao suportada pelas linguagens. O ROS (Robot Operating System) (GUIGLEY et. al.,
2009), um exemplo de sistema operacional para rob de cdigo aberto.
43
J em arquiteturas baseadas em middleware, os diferentes componentes de software

so vistos como aplicativos independentes, que podem ser executados na mesma mquina
ou atravs da rede. Nela, um componente responsvel por intermediar a comunicao entre
os mdulos, o middleware. O MIRO (Middleware for Robots) (UTZ et. al., 2002) e o RTMiddleware (Robot Technology Middleware) (ANDO et. al., 2005) so exemplos de
middlewares robticos baseados no CORBA, um middleware de uso mais genrico e destinado
a sistemas distribudos (OMG, 1995). O CORBA ainda possui especificaes como o minimum
CORBA e o RT-CORBA (Real Time CORBA) v.1.1 (SCHMIDT et. al., 1997) capazes de prover
mecanismos de comunicao em tempo real a componentes distribudos e heterogneos,
caracterstica muito interessante no contexto da robtica mvel. No entanto, o principal
aspecto a considerar sobre o CORBA seu carter genrico, acarretando software extensos e
complexos, que o prejudica na questo de facilidade de uso (NAMOSHE et. al., 2008). Ainda
existem outros middlewares, como RSCA (Robot Software Communication Architecture) (YOO
et. al., 2006), destinado utilizao em sistemas robticos distribudos.
Arquiteturas baseadas em redes fundamentam-se na popularizao da Internet e seus
protocolos para propor suas infraestruturas. Conforme Mohamed et al. (2008) relata em seu
trabalho, em antigas geraes de robs, estes eram projetados para serem capazes de
executar tarefas especficas e, para tal, eram desenvolvidos como uma nica unidade,
enquanto nas geraes modernas, alm dos robs serem autnomos, so tambm ubquos,
ou seja, so capazes de se conectarem s redes e usufruirem dessas conexes. E pelo fato de
serem constitudos por um conjunto integrado de sofisticados dispositivos de hardware e
mdulos de software, os robs modernos so considerados sistemas distribudos complexos,
segundo Elkady e Sobh (2012) e Mohamed et al. (2008). Sistemas robticos distribudos
utilizam subsistemas, que so mdulos embarcados e independentes, que compartilham
recursos e operam como um nico sistema, visando ao mesmo objetivo (NIRANJAN et. al.,
2012). Apesar de no ter sido desenvolvido especificamente para a robtica, padres como a
arquitetura UPnP (Universal Plug-and-Play) oferecem conectividade peer-to-peer (ponto-aponto) em ambientes computacionais distribudos e dinmicos. Na robtica, o UPnP pode ser
utilizado na criao de mdulos reusveis e de fcil manuteno (MOK; WU, 2006), em vista
44
de sua capacidade de monitoramento e descoberta dinmica de servios disponveis ao longo

da rede.
Arquiteturas abertas objetivam prover uma interface comum para os componentes do
rob, tais como mdulos de sensoriamento e atuao, de modo que seja possvel diferenciar
e identificar caractersticas, como funes e especificaes de cada componente. possvel
relacionar isso ao plug-and-play ("conectar e usar") dos computadores (BEKEY, 2005).
2.7
Sistemas de comunicao na robtica
A comunicao de dados entre os diversos mdulos que compem um sistema robtico

de fundamental importncia, uma vez que por meio desta comunicao que dispositivos
de diferentes funes iro se comunicar. Entretanto, a robtica usualmente requer a
integrao de diferentes mdulos, fabricados por diferentes indstrias, portanto, possuem
diferentes padres de alimentao e adotam diferentes conectores fsicos. Essa questo de
incompatibilidade se estende comunicao de dados nos quais os dipositivos adotam
diferentes conexes de dados e empregam ainda, diferentes protocolos de comunicao. Em
suma, alm das incompatibilidades de alimentao, o problema da conectividade tanto
fsica quanto lgica. Essa heterogeneidade justificvel uma vez que muitos dos
componentes adotados na robtica no so produtos ou tecnologias que foram
desenvolvidos visando a sua aplicao na robtica. Uma forma de contornar essa situao
atravs de uma padronizao, obtida por meio de uma arquitetura que emprega padres de
comunicao j estabelecidos e tambm por meio de mdulos de software responsveis pela
abstrao dessa heterogeinedade dos dispositivos.
Muitas vezes, sistemas robticos necessitam executar tarefas de processamento e
comunicao em tempo real, como por exemplo, mapeamento e nagevao. Logo, para
garantir a reatividade e a capacidade de resposta s alteraes em um ambiente em tempo
real, o trfego de informao entre os mdulos de sensoriamento, planejamento e atuao
deve ser mantido o menor possvel, de forma a evitar atrasos na comunicao (FAYEK et. al.,
45
1993). Isso sugere que a troca de informao deva assumir elevado grau de abstrao. A
comunicao entre os processos pode ser feita por meio de protocolos de comunicao
sncrona ou assncrona. A maioria dos sistemas utilizam controladores embarcados que
suportam a forma assncrona e utilizam um barramento serial comum para a comunicao.
A forma serial de comunicao de dados substituiu o tradicional uso da comunicao por
meio do barramento paralelo, uma vez que esta forma necessita de mais recursos de
hardware e tambm mais suscetvel a efeitos capacitivos.
Nesse contexto, um dos trabalhos analisados foi o URB (Saranli et. al., 2011), na qual
apresentada uma arquitetura modular de barramento de comunicao em tempo real
destinada robtica e outros domnios similarmente estruturados. A topologia fsica das
conexes do URB mostrada na Figura 2.4.
Sensores Atuadores
Sensores Atuadores
Mdulo
Firmware local
Mdulo
Firmware local
...
uplink
RS-232
Ponte URB RS-232

Controlador
de tarefas
Caixa de
mensagens
Downlink I2C, CAN, RS-485, etc
...
Driver
RS-232
Driver
USB
Bibliotecas URB
Software de
Controle
Caixa de
mensagens
uplink
USB
Ponte URB USB

Controlador
de tarefas
Downlink I2C, CAN, RS-485, etc
Caixa de
mensagens
Firmware local
Mdulo
Sensores Atuadores
...
46
Firmware local
Mdulo
Sensores Atuadores
Figura 2.4 - Topologia fsica de conexes do URB.

Fonte: Adaptado de Saranli et. al. (2011).
Caixa de
mensagens
Nesta arquitetura, a comunicao pode ser dividida em duas categorias: uplink e

downlink. O uplink responsvel pela comunicao entre o Software de Controle e o
Controlador de Tarefas, na qual pode ser estabelecida por meio de padres como o RS-232 e
o USB. J o downlink remete ao barramento de conexo estabelecido entre o Controlador de
Tarefas e os mdulos de hardware (sensores e atuadores), conexo esta que pode ser
estabelecida por meio de padres como I2C, CAN ou RS-485.
Um outro trabalho interessante o R2P (Rapid Robot Prototyping) (BONARINI et. al.,
2013) na qual empregado o RTCAN. O RTCAN (Real-Time CAN) (MIGLIAVACCA et. al., 2013)
foi desenvolvido a partir dos protocolos do barramento CAN e direcionado a aplicaes
robticas. O RTCAN capaz de explorar tanto o paradigma de transmisso time-triggered
(disparado por tempo) como o event-triggered (disparado por evento), oferecendo, desta
forma, suporte a trs tipos distintos de mensagem: mensagens peridicas em tempo real,
mensagens disparadas por eventos e mensagens sem prioridade. A arquitetura do R2P
mostrada na Figura 2.5.
Figura 2.5 Arquitetura do framework R2P.

Fonte: Adaptado de Bonarini et. al. (2013).
47
possvel observar que tanto o URB como R2P adotam uma abordagem na qual suas
funcionalidades so implementadas modularmente tanto em termos de hardware quanto em
termos de software. Desta forma, componentes frequentemente utilizados como controle dos
motores, sensores de proximidade, etc, podem ser implementados em mdulos padronizados,
com seus respectivos firmwares locais. Esses mdulos so conectados a um barramento
comum de perifricos, no qual existe um mdulo responsvel pelo seu controle e interface
com o software de controle.
2.8
Concluses do captulo
Este captulo apresentou uma sntese a respeito da definio de robs mveis

autnomos, a composio caracterstica dos mesmos, abordando tpicos como locomoo e
tcnicas de localizao comumente utilizadas na robtica mvel, e ainda levantou aspectos
relevantes acerca das arquiteturas de controle e software. Alm disso, por meio de um breve
estudo, observou como a comunicao um aspecto fundamental na arquitetura robtica.
Observando os tpicos abordados, possvel notar a extenso e a contribuio de cada um
deles para o campo da robtica mvel.
A questo da reutilizao dos mdulos de software e mecanismos de controle de outras
plataformas na robtica pode facilitar o processo de desenvolvimento, no entanto,
normalmente acaba inviabilizado pela especificidade, uma vez que os mdulos de software
normalmente so destinados a um determinado hardware (KUBITZ et. al., 1998). Alm disso,
existe o problema da abstrao dos recursos de hardware, que se torna mais difcil com o
aumento da complexidade tanto do sistema de controle como da interface de hardware.
De acordo Coste-Manire e Simmons (2000), os sistemas robticos frequentemente
necessitam satisfazer requisitos em tempo real e essa necessidade costuma ser complexa
demais para ser desenvolvida e operada utilizando tcnicas convencionais de programao.
Alm disso, diferentes aplicaes possuem diferentes necessidades, que devero ser
48
satisfeitas por meio de diferentes arquiteturas. Isso explica a razo pela qual existem
diferentes abordagens para a composio de arquiteturas de software na literatura.
Considerando o objetivo deste trabalho, que o desenvolvimento de uma plataforma
de rob mvel de arquitetura aberta, foi dada maior ateno a questes relacionadas a
tpicos como composio, locomoo, arquiteturas de controle e comunicao. Tais tpicos
so abordados com maior detalhamento no captulo seguinte, onde so apresentadas as
tcnicas e os mtodos escolhidos para o desenvolvinmento deste trabalho.
49
PLATAFORMA DE ROB MVEL
Considerando que o objetivo da plataforma proposta sua utilizao em aplicaes de

propsito geral, apropriada a adoo de uma arquitetura que oferea facilidade de
entendimento e utilizao aos usurios ao mesmo tempo que permita um grau de
flexibilidade de hardware, para ser modificada de acordo com as necessidades das aplicaes.
Desta forma, buscou-se uma arquitetura visando sua simplicidade conceitual e tcnica, de
modo que permita fcil compreenso e implementao, caractersticas que motive a
utilizao da plataforma em diversas iniciativas. Logo, a disposio da arquitetura da
plataforma do rob mvel foi dividido em trs camadas, sendo estas:
Camada Superior. Camada na qual implementado o software de controle,

responsvel pelo processamento dos dados e leituras dos sensores, tomada de
decises e pelo controle de acionamento dos atuadores;
Camada Intermediria. Camada responsvel por estabelecer a comunicao

entre a Camada Superior e a Camada Inferior, atravs de uma interface comum
de hardware, um protocolo de comunicao padronizado e APIs e bibliotecas de
interface que abstraem os detalhes especficos de todos os dispositivos
perifricos localizados na Camada Inferior;
Camada Inferior. Corresponde aos dispositivos perifricos de hardware

implementados e funcionais, abrangendo tanto sensores como atuadores.
A disposio da arquitetura descrita e suas camadas ilustrada na Figura 3.1.
50
Camada Superior
Sistema de Controle
Bibliotecas de Interface
Baramento de
Comunicao
Servidor
Cliente
...
Atuador N
Atuador B
Interface
Comunicao
Atuador A
...
Sensor N
Sensor B
Sensor A
Controlador
Camada Intermediria
Camada Inferior
Figura 3.1 Disposio da arquitetura e suas camadas.

Esta plataforma prope uma arquitetura de software do tipo cliente-servidor, onde o

Cliente representa a base do rob mvel e o Servidor corresponde ao sistema disponvel para
o controle. O Servidor pode tanto ser embarcado, com a conexo sendo estabelecida
diretamente no barramento de comunicao, ou remota, sendo a comunicao estabelecida
com a utilizao de tecnologias de conexo sem fio, como RF, Wi-Fi ou Bluetooth.
Nesta arquitetura, o Servidor composto pelo Sistema de Software de suporte para a
Arquitetura de Controle, APIs e bibliotecas responsveis pela interface e abstrao da
comunicao estabelecida com o Cliente. A Camada Superior compreende tecnologias
computacionais como computadores pessoais, computadores portteis ou dispositivos
embarcveis de processamento, como microcontroladores, FPGA, Arduino e Raspberry Pi.
J o Cliente corresponde base do rob mvel, onde se encontra o Controlador e os
mdulos de hardware perifricos. Para o Controlador, foi adotado o conceito de sistema
fortemente acoplado, atribuindo a um nico agente a tarefa de gerenciar todos os
dispositivos de sensoriamento e atuao. Isso confere plataforma menor complexidade em
51
comparao abordagem conceitual que um sistema fracamente acoplado acarreta. Um

outro fator que levou a essa escolha a necessidade de um nmero reduzido de dispositivos
dedicados de gerenciamento dos dispositivos perifricos, e portanto, menor custo de
implementao e manuteno, alm da mitigao de erros e falhas relacionadas ao
desenvolvimento, implementao e alteraes dos mdulos localizados na Camada Inferior.
A adoo de uma abordagem fracamente acoplada, apesar de apresentar maior flexibilidade,
por sua vez, necessita de um barramento dedicado conexo dos dispositivos perifricos ao
mdulo de gerenciamento, alm de um protocolo de comunicao comum para estas
conexes, como mostrado em 2.8.
Com esta disposio de arquitetura mostrada na Figura 3.1, possvel implementar e
experimentar diferentes paradigmas de controle, uma vez que a arquitetura adotada capaz
de oferecer recursos essenciais para suportar qualquer um dos trs paradigmas: hierrquico,
reativo ou hbrido deliberativo/reativo (Murphy, 2002).
Cada uma das trs camadas so melhor descritas nas sees seguintes.
3.1
Camada Superior
A Camada Superior refere-se aos mdulos responsveis pelas tarefas como

processamento do dados obtidos pelos sensores, tomada de decises e acionamento dos
dispositivos atuadores. Esta camada compreende tecnologias computacionais utilizadas para
a realizao dessas tarefas, que podem ir desde dispositivos embarcveis de processamento
a complexos sistemas computacionais. De um modo geral, o processo de tomada de decises
realizado por meio de computadores. Isso se deve popularizao dos computadores,
alavancada pelo contnuo avano tecnolgico e reduo dos custos de produo. Alm disso,
possvel mencionar outros fatores implcitos, como miniaturizao, aumento da capacidade
de processamento, comunicao e memria, assim como a reduo do consumo e otimizao
dos recursos energticos. Com essa popularizao dos computadores, surgem novas
linguagens de programao, provendo diferentes formas de abstraes de estruturas de
52
dados, assim como paradigmas de programao. A robtica faz uso da programao em

computadores, escritos em linguagens de programao, para desenvolver suas arquiteturas
de controle. Logo, a escolha de uma arquitetura de software impacta sobre a implementao,
manuteno e reaproveitamento de cdigo, alm de determinar o modelo de processamento
e a plataforma tecnolgica computacional.
Ao deixar em aberto as questes como arquitetura de controle e arquitetura de software,
esta plataforma oferece neutralidade em relao implementao de qualquer paradigma de
controle, implicando tambm em uma neutralidade em relao linguagem de programao
utilizada. Essa abordagem permite ao usurio, maior liberdade na escolha da linguagem de
programao que melhor atenda s necessidades da aplicao ou simplesmente em razo da
familiaridade com determinada linguagem ou ambiente de desenvolvimento. E essa
liberdade, por sua vez, se estende tambm tecnologia de controle empregada.
O desenvolvimento e implementao da arquitetura de controle junto a uma
arquitetura de software para este trabalho foi conduzido unicamente com o intuito de
averiguar se a plataforma proposta capaz de suportar cenrios de aplicaes empregando
diferentes abordagens em aplicaes distintas. Duas situaes de aplicao foram
elaboradas: a primeira relacionada a uma aplicao de um experimento envolvendo
navegao e outra para uma aplicao cientfica hipottica, situaes que so discutidas com
mais detalhes no captulo 4.
3.2
Camada Intermediria
O sistema de comunicao de dados uma parte essencial para robs mveis, uma vez
que responsvel pela interface de comunicao entre seus mdulos. Esta seo apresenta o
sistema de comunicao de dados adotado para efetuar a comunicao entre a Plataforma do
Rob Mvel e o Sistema de Controle.
53
A comunicao de dados adotada foi a serial, compatvel e com suporte ao padro RS232, embora existam outros padres de comunicao serial, como o padro USB. De acordo
com Saranli et. al. (2011), o RS-232 uma interface cuja conectividade pode ser direcionada
em aplicaes que exijam pouca ou mdia largura de banda. Alm disso, este padro pode ser
encontrado em dispositivos computacionais embarcveis, como FPGAs. J o USART
(acrnimo do termo ingls: Universal Synchronous Asynchronous Receiver Transmitter de
Transmissor Receptor Universal Sncrono Assncrono) um padro de comunicao de
dados serial ponto a ponto, sendo comumente empregado em conjunto com o padro RS-232,
RS-485, dentre outros. O USART pode operar em modo full-duplex ou half-duplex. O full duplex
uma comunicao assncrona, na qual dois canais fsicos so utilizados para o envio de
dados, um canal para cada sentido, podendo deste modo, ocorrer transmisso e recepo
simultnea de dados. Neste modo, a taxa de comunicao de ambos os dispositivos
conectados devem ser comuns. J o modo half-duplex caracteriza uma comunicao sncrona
estabelecida entre dispositivos na configurao mestre-escravo, na qual um canal fsico
empregado para a transmisso bidirecional dos dados, e um outro canal dedicado
sincronizao estabelecida pelo dispositivo mestre. Esta comunicao limita a transmisso e
recepo para um nico sentido de cada vez e suporta taxas de comunicao inferiores ao
modo assncrono.
De forma a oferecer maior flexibilidade em relao sua conectividade, uma linha de
comunicao direta d ao usurio do Kihon, acesso ao terminais EUSART (acrnimo do termo
ingls Enhanced Universal Synchronous Asynchronous Receiver Transmitter, ou
Transmissor Receptor Universal Sncrono Assncrono Aprimorado) do microcontrolador
utilizado, dando maior liberdade de acoplar diferentes esquemas fsicos de plataformas de
controle ou dispositivos de comunicao sem fio (rdio, Wi-Fi ou bluetooth).
Como mencionado anteriormente, o padro do tipo serial apresenta aspectos
favorveis em relao ao tipo paralelo e at mesmo, em relao a padres mais modernos,
como o prprio USB. O principal aspecto considerado para tal escolha foi sua simplicidade,
uma vez que o porto serial apresenta-se como uma alternativa de fcil entendimento,
implementao e uso. Alm disso, padres mais modernos como o USB, por possuir diversos
54
modos de operao, conectividade e recursos como plug-and-play, apresentam extensas

documentaes e acabam exigindo conhecimentos mais avanados. Por outro lado, a
simplicidade oferecida pelo USART em conjunto com o padro RS-232 interessante e
conveniente, permitindo fcil compreenso, implementao e utilizao aos usurios. Com
isso, possvel concentrar a maior parte dos esforos nas questes relacionadas robtica
ou ao tpico de interesse, e sem desestimular o usurio.
A proposta deste trabalho se limita concepo do firmware do Controlador, desta
interface de comunicao e protocolo e, por fim, de uma API, cuja funo abstrair e
especificar como os componentes do software de controle devem interagir com os
dispositivos localizados na Camada Inferior.
3.3
Camada Inferior
A Camada Inferior refere-se aos mdulos perifricos de hardware. O conjunto desses

mdulos foi escolhido para compor o Kihon, seguindo critrios como baixo custo e facilidade
de aquisio no mercado atual. A escolha dos mdulos tanto de sensoriamento como atuao
foi feita objetivando a concepo do Kihon, de modo que este apresente funcionalidades
essenciais para suportar iniciativas diversas envolvendo a robtica mvel e tpicos
relacionados.
Os atuadores escolhidos foram:
Dois motores CC com caixa de reduo, para a trao diferencial;
Um servomotor para alterar a direo do sonar acoplado em seu eixo.
Os sensores escolhidos foram:
Dois sensores de odometria (encoders), acoplados aos eixos dos motores CC

antes da reduo;
55
Um sonar acoplado ao servomotor;
Trs sensores de proximidades posicionados na parte frontal do Kihon;
Dois sensores de solo.
A Figura 3.2 mostra o diagrama em blocos dos dispositivos de hardware implementados

no rob Kihon.
Motor CC Esquerdo
Ponte H
Servomotor
Controlador de Rob Mvel
Serial
Motor CC Direito
Sensor Odometria Esquerdo

Sensor Odometria Direito
Sensor Proximidade Esquerdo
Sensor Proximidade Centro
Sensor Proximidade Direito
Sensor Solo Esquerdo

Sensor Solo Direito
Sonar
Figura 3.2 Diagrama em blocos dos dispositivos implementados no Kihon.

Por questes de praticidade, facilidade de implementao e custo, um nico

microcontrolador foi adotado para coordenar e gerenciar todos os recursos de hardware
localizados na Camada Inferior. Portanto, para esta proposta, optou-se por adotar um sistema
56
centralizado e fortemente acoplado, ainda que, num segundo momento, seja possvel
implementar um sistema fracamente acoplado, baseado em uma rede de microcontroladores
com funes especficas.
3.4
O rob mvel Kihon
Nesta seo apresentado o rob mvel Kihon, concebido com o propsito de servir
como uma plataforma bsica de rob mvel. O nome formado a partir dos kanjis (caracteres
chineses utilizados na lngua japonesa) (ki), que pode significar fundamental ou fundao,
e (hon), que pode significar principal ou origem. Assim, Kihon () um termo do
idioma japons que no contexto educacional pode ser traduzido como princpios bsicos ou
fundamentos. Portanto, no contexto deste trabalho, o nome Kihon se deu em virtude dos
recursos essenciais oferecidos pela plataforma proposta, de modo a permitir que esta possa
servir como uma ferramenta de aprendizado de conceitos, os quais podero ser explorados
e praticados por meio do rob mvel Kihon.
O Kihon corresponde base do rob mvel e se enquadra no bloco de Estrutura
Mecnica apresentada da Figura 1.1 e Camada Inferior da arquitetura apresentada na
Figura 3.1. Sua construo foi motivada para averiguar se a plataforma aberta do rob mvel
apresentada neste captulo pode ser concebida de modo a oferecer os requisitos almejados.
Para sua concepo, foram considerados o propsito de utilizao da plataforma,
caractersticas como flexibilidade e, por fim, a neutralidade em relao s tecnologias de
controle.
3.4.1 Aspectos mecnicos e cinemticos
O tamanho do corpo fsico do rob determina o que poder ser embarcado ou acoplado
sobre o mesmo. Considerando o propsito de uso do rob mvel, uma situao prevista sua
57
utilizao em aplicaes empregando plataformas de controle embarcados, como por

exemplo, netbook, Raspberry Pi, Arduino ou FPGA. Para dar suporte a tais situaes, iniciouse um estudo para o dimensionamento do rob, ou seja, seu porte fsico. Para permitir o
acoplamento de tecnologias de sistemas de controle variados, foi estimado seu porte fsico,
de modo a possibilitar o acoplamento do sistema de controle que, dentre os previstos, requer
maior espao fsico. E dentre as possibilidades previstas para o sistema de controle, o maior,
em termos de dimenses, foi determinado pelo netbook adotado, o Eee PC 900 da Asus,
disponvel no LISDI, e cujas dimenses aproximadas so de 32720 cm (ALP).
Para a locomoo do Kihon, dentre outras alternativas possveis, adotou-se a
locomoo baseada em rodas. Mecanismos de locomoo baseados em rodas so os mais
comumente encontrados na robtica mvel por uma srie de fatores, dentre as quais
possvel citar baixo custo, seja na implementao como manuteno, estabilidade e,
finalmente, por sua simplicidade mecnica e de controle. As rodas apresentam elevado grau
de eficincia em aplicaes terrestres, especificamente em superfcies planas. E para este
trabalho, tal escolha ainda se deu por se adequar ao ambiente de aplicao no qual o Kihon
ser destinado e, ainda, pela facilidade de implementao e uso.
Alm disso, decidiu-se pela adoo do modelo de trao diferencial por ser comumente
empregado na robtica mvel, uma vez que seu modelo cinemtico menos complexo em
comparao s outras disposies possveis. possvel citar algumas caractersticas dessa
disposio, como simplicidade, relativo baixo custo e facilidade de construo. E, ainda, sua
compreenso mais intuitiva, o que facilita o desenvolvimento de seu controle de locomoo.
O clculo das velocidades linear e angular do centro geomtrico (C) de robs com
sistema de trao diferencial e aplicvel ao Kihon mostrado na equao (3.1). O
detalhamento a equao apresentado no Apndice A.
1

[ ] = [
1

] [] ,

58
(3.1)
onde de ambas as rodas ativas empregadas no Kihon corresponde a 4,445cm e a distncia

do Kihon corresponde a 11,5cm.
Sabendo-se que o raio da roda empregada de 4,445cm, o motor CC com caixa de
reduo empregado apresenta nominalmente 80rpm, e que a roda acoplada por meio de
uma ponta de eixo sada da caixa de reduo do motor CC, possvel determinar a
velocidade linear mxima max do rob mvel como sendo 37,144cm/s
(clculos no
Apndice A).
Por ltimo, o peso um item que deve ser ponderado, uma vez que componentes de
hardware pesados acarretam em um maior esforo que dever ser destinado ao sistema de
locomoo. Assim, um motor com maior torque e mais pesado dever ser empregado. Isso
afeta tambm o sistema de alimentao de energia do sistema, que necessitar de baterias de
maior capacidade de fornecimento de carga, mas que so maiores e mais pesadas. A questo
do peso envolve a escolha adequada dos componentes, devendo, alm de minimizar os custos
econmicos, satisfazer os requisitos funcionais do rob. Outros detalhes do modelo
cinemtico do rob mvel Kihon pode ser encontrado no Apndice A.
3.4.2 Desenvolvimento do hardware
O rob mvel Kihon foi construdo basicamente a partir de materiais previamente

disponveis no LISDI. Os materiais utilizados incluem baterias, placa de circuito impresso
padro, componentes eletrnicos, motores CC, servomotor, barras de alumnio,
microcontrolador, parafusos, dentre outros itens. O custo total de material utilizado para a
construo do Kihon foi de aproximadamente R$500,00. No entanto, foram desconsiderados
os custos do seu desenvolvimento e da sua montagem. Este valor serve para elucidar o baixo
custo relativo do rob, pois o valor real depende de variveis de mercado que fogem do
escopo deste trabalho.
59
A princpio, para fins de validao, o Kihon embarca uma quantidade mnima de

dispositivos que o permita apoiar iniciativas gerais relacionadas robtica mvel. E ainda, o
Kihon apresenta uma API prpria que torna sua programao facilitada. A API escrita para o
Kihon contm rotinas essenciais para efetuar a leitura de suas entradas e tambm, controlar
dispositivos atuadores. A Figura 3.3 mostra o rob mvel Kihon.
Figura 3.3 - Rob Mvel Kihon.

De modo a alcanar os objetivos almejados em 1.3 e 1.4, foi implementado um conjunto

inicial padro de mdulos sensores e atuadores no Kihon. Esses mdulos tm a finalidade de
oferecer funcionalidades essenciais ao Kihon, como possibilitar sua locomoo com a adoo
de um sistema de locomoo, e suporte a tcnicas relativas de localizao e navegao. A
seguir, sero discutidos de forma objetiva os mdulos escolhidos para compor o conjunto
inicial padro de mdulos, justificando brevemente as razes que levaram escolha de
implement-los no Kihon.
Os mecanismos atuadores escolhidos foram:
Dois Motores CC com caixa de reduo para o sistema de tracionamento: como

atuadores na robtica mvel, motores CC podem facilmente ser empregados como
atuadores das rodas. Uma vez delimitado o ambiente terrestre de aplicao para
60
superfcies planas e com a adoo do sistema de tracionamento diferencial, dois

motores so suficientes para habilitar a locomoo do rob mvel. Motores CC com
caixa de reduo so baratos, abundantes no mercado e possuem diversos tamanhos
e relaes de reduo. Alm disso, so fceis de implementar e usar. Para compor o
sistema de tracionamento do Kihon, decidiu-se empregar dois motores CC com caixa
de reduo;
Um Servomotor para o direcionamento do Sonar: um servomotor foi empregado para

direcionar um Sonar de modo a varrer a regio frontal do Kihon. O eixo do servo
usualmente limitado a uma amplitude de rotao de cerca de 180 graus. Alm disso,
seu eixo pode assumir posies especficas dentro desse intervalo de amplitude de
rotao. Desta forma, com a fixao de um Sonar sobre o eixo do servomotor,
possvel detectar a distncia de eventuais objetos e obstculos da regio frontal do
Kihon.
Os mecanismos de sensoriamento escolhidos foram:
Dois encoders (codificadores pticos) para a odometria: pela simplicidade conceitual

e facilidade de implementao e manuseio, optou-se por implementar a tcnica da
odometria como mtodo de estimativa de localizao relativa do Kihon. A odometria
uma tcnica de localizao relativa comumente empregada na robtica mvel. Nos
robs mveis baseados em rodas, usualmente, a implementao da odometria acopla
encoders diretamente aos eixos de rotao dos motores de tracionamento ou no eixo
das rodas do rob. Atravs da combinao de informaes de rotao das rodas com
o modelo cinemtico do rob, possvel estimar a movimentao do rob mvel;
Trs mdulos pticos digitais de sensores de proximidade: para a deteco de objetos

e obstculos prximos ao Kihon, decidiu-se acoplar trs mdulos sensores de
proximidade na parte frontal do Kihon. Esses mdulos utilizados, atravs do princpio
de reflexo da luz, so capazes de detectar a presena de objetos apresentando
determinado nvel de sinal lgico digital em suas sadas e nvel lgico contrrio na
ausncia de objetos detectados;
61
Sensores para seguir linhas com o emprego de dois sensores pticos reflexivos: na
robtica mvel, comum haver experimentos de navegao envolvendo a tarefa de
seguir linhas ou efetuar leituras do solo como parte da aplicao. Alm disso, comum
o emprego de dispositivos de sensoriamento que fornecem nveis de sinais analgicos
em suas sadas. De modo a oferecer uma funcionalidade ao Kihon aliada ao fato de
oferecer uma forma de sensoriamento analgico simples e til plataforma, decidiuse pela implementao de dois sensores ticos reflexivos em sua base;
Sonar: sonares so comumente empregados na robtica mvel para auxiliar no

processo de navegao dos robs mveis e deteco de obstculos. Como uma
implementao de um dispositivo sensor de distncia, decidiu-se empregar um Sonar
em conjunto com o servomotor.
A descrio detalhada de cada um dos mecanismos citados acima e implementados no
rob mvel Kihon dada a seguir.
3.4.2.1 Motores CC
Dois motores CC de 12V com caixa de reduo so utilizados para compor o sistema de
locomoo do Kihon. Com a caixa de reduo, o motor empregado capaz de oferecer em sua
sada 80rpm a 3kgfcm. A Figura 3.4 (a) mostra o motor utilizado e a Figura 3.4 (b) os dois
motores CC engrenados instalados na estrutura mecnica do Kihon.
62
Figura 3.4 (a) Motor CC engrenado utilizado; e (b) Motor acoplado estrutura mecnica
do Kihon.
O acionamento de ambos os motores CC feito atravs do L298, um circuito integrado

que desempenha a funo de duas pontes H completa. Os canais de Controle 0-3 do
Controlador so conectados s entradas do L298, enquanto que as sadas PWM0 e PWM1 so
conectadas aos pinos habilitadores (enable) do L298. Por meio desta conexo, possvel
alterar tanto o sentido de rotao de cada motor CC como as tenses mdias aplicadas aos
mesmos.
A Figura 3.5 ilustra as combinaes possveis de controle e acionamento do motor. O
canal PWM 0 efetua o controle de acionamento (enable) do motor enquanto os canais de
Controle 0 e 1, conectados s entradas Input 0 e Input 1 do L298 definem o sentido de rotao
do motor.
63
Figura 3.5 Formas de ondas dos canais de controle PWM e seus efeitos no motor CC.
A Figura 3.5 (a) ilustra o comportamento do motor quando o Enable est a 50%, Input
0 setado (nvel alto) e Input 1 resetado (nvel baixo). Nessas condies, o motor opera em
sentido anti-horrio com uma tenso mdia de 6V, equivalente a 50% do ciclo de trabalho
PWM da tenso de alimentao de 12V. J a Figura 3,5 (b) mostra o comportamento do motor
quando o Enable est a 80%, Input 0 resetado (nvel baixo) e Input 1 setado (nvel alto). Essas
condies resultam em uma tenso mdia de 9,6V sobre o motor, que agora opera em sentido
horrio. A Figura 3.5 (c) ilustra uma continuidade do estado mostrado em (b), no entanto,
opera a 100% do ciclo de trabalho, alimentando o motor com tenso mdia de 12V,
permanecendo a rotao no sentido horrio.
A Figura 3.5 (d) ilustra a configurao necessria para que o motor opere em estado de
breque. Para que isso ocorra, o ciclo de trabalho do PWM deve ser 100% e o Controle 0 deve
ser igual ao Controle 1. Um motor eltrico opera em estado de breque quando seus terminais
esto em curto-circuito. Tal comportamento ocorre devido capacidade do motor em
produzir corrente quando seu eixo rotacionado por foras externas (fora eletromotriz fem). No entanto, quando um motor cujos terminais esto curto-circuitados tem seu eixo
64
rotacionado, uma corrente gerada pelas bobinas do motor, realimentando-a no sentido

contrrio ao sentido rotacionado, forando o motor a girar no sentido contrrio. Isso faz com
que o motor oferea uma resistncia s variaes do estado de seu eixo, na chamada fora
contra eletromotriz (fcem). Assim, o motor parado tende a permanecer parado quando seus
terminais esto em curto-circuito, bloqueando a rotao das rodas e atuando com freio.
Finalmente, a Figura 3.5 (e) mostra o comportamento do motor quando o PWM est
desabilitado, ou seja, seu ciclo de trabalho 0%. Nestas condies, a ponte-H desabilitada,
logo, independentemente dos estados dos Controle 0 e Controle 1, no h nenhuma conexo
dos terminais do motor, permanecendo este desligado e, seu eixo, livre.
3.4.2.2 Servomotor
Um servomotor foi utilizado para controlar a direo do sonar. Por meio desse
direcionamento, possibilita-se ao Kihon uma cobertura frontal e lado a lado de
aproximadamente 180 graus da sua parte dianteira.
Servomotor um motor de corrente contnua que possui internamente um circuito
responsvel pelo controle de seu eixo. Os servomotores operam por meio de pulsos
peridicos de 5V, usualmente, no intervalo de 500s a 2500s e repetidos a cada 20ms. Esses
pulsos correspondem linearmente posio do eixo do servo motor, que costumam ser
limitados no intervalo de 0 a 180 graus. A Figura 3.6 ilustra a relao entre forma de onda e
o posicionamento do eixo de um servomotor.
65
5V
5V
5V
0.5s
Esquerda
1.5s
Centro
2.5s
Direita
20ms
20ms
Figura 3.6 Relao entre forma de onda e posicionamento do eixo de um servo motor.
No entanto, existe uma enorme variedade de servomotores no mercado, com diferentes

especificaes, que incluem diferentes intervalos dos pulsos. O envio de pulsos fora do
intervalo suportado pelo servomotor pode danificar as engrenagens do componente,
comprometendo-o permanentemente. O servomotor HS-81, da Hitec, utilizado no Kihon
capaz de operar entre 0,9 a 2,1ms, no entanto opera no intervalo de 1,1ms a 1,9ms. Essa
limitao foi estipulada pelo software de controle, uma vez que o Controlador permite o
intervalo usual. No rob Kihon, o servomotor utilizado foi conectado ao canal Servo 0 do
Controlador. O servomotor utilizado no Kihon mostrado na Figura 3.7 (a), e a Figura 3.7 (b)
mostra o servomotor j acoplado estrutura mecnica do Kihon.
Figura 3.7 (a) Servomotor utilizado no Kihon; e (b) Servomotor acoplado ao Kihon.
66
3.4.2.3 Sensores de odometria
Como uma tcnica comum de localizao relativa, a odometria responsvel por

estimar a distncia percorrida pelas rodas, a partir de um ponto inicial. No Kihon foram
implementados dois sensores de odometria, um para cada motor CC do sistema de locomoo.
O sistema de odometria consiste no conjunto motor CC, encoder e emissor-receptor de luz
infravermelha. Para o encoder, foi elaborado um pequeno disco circular, dividido radialmente
em duas partes iguais de modo que uma metade de sua superfcie seja preta e outra metade,
branca. Cada disco foi acoplado a um motor CC engrenado, em seu eixo antes da caixa de
reduo. Para determinar o quanto esse eixo rotacionou, um componente emissor-receptor
de luz infravermelha foi posicionado perpendicularmente superfcie do disco do encoder,
de modo a detectar cada transio da luz refletida de preto-branco e branco-preto.
Conhecendo a relao da caixa de reduo do motor CC, para cada giro do eixo do respectivo
motor, o sensor infravermelha capaz de detectar essas transies, tornando possvel
determinar matematicamente o quanto a respectiva roda girou. A Figura 3.8 ilustra o
conjunto encoder e sensor de odometria.
Figura 3.8 Encoder e Sensor de odometria de um pulso por revoluo.

67
Quando o emissor-receptor infravermelho incide perpendicularmente sobre a

superfcie preta, maior parte da luz emitida absorvida pela superfcie escura e, com isso,
praticamente no h reflexo do feixe de luz para o receptor. O receptor nada mais que um
foto-transistor de luz infravermelha. Com pouca luz refletida, no h excitao do fototransistor, cortando-o. Por outro lado, quando o emissor-receptor infravermelho incide
sobre a superfcie branca, maior parte da luz emitida refletida pela superfcie clara. Nessa
situao, o receptor recebe a maior parte do feixe de luz refletida na superfcie, excitando o
foto-transistor. O foto-transistor, quando em estado de corte, apresenta em sua sada, tenso
prxima alimentao neste caso, 5V. Quando excitado, o foto-transistor apresenta tenso
prxima de 0V.
O componente utilizado para efetuar a leitura do encoder foi o OPB705, composto por
um LED e um foto-transistor, ambos operando no espectro de luz infravermelha. Pelo fato
desses componentes utilizarem esta faixa especfica de frequncia luminosa, eles so imunes
maior parte dos rudos luminosos do ambiente. No entanto, o foto-transistor empregado,
responsvel pela recepo do feixe, no apresenta nveis de sinais bem definidos em sua sada,
apresentando faixas de tenses prximas a 1V quando excitado e 4V em corte. De modo a
garantir nveis lgicos bem definidos em sua sada, empregou-se o ULN2004, um circuito
integrado com 7 canais de drivers NPN Darlington. A Figura 3.9 (a) ilustra o componente
OPB705, e a Figura 3.9 (b), mostra os OPB705 acoplados ao o sistema de odometria do Kihon.
Figura 3.9 (a) Sensor de odometria utilizado; e (b) Sensores acoplados ao sistema de
odometria.
68
A partir dessa disposio de motor, disco de odometria e emissor-receptor, quando o

eixo do motor rotacionado, ocorre uma srie de alternncias entre absoro e reflexo na
superfcie do disco de odometria. Essa alternncia gera na sada do circuito ondas quadradas
cujos perodos so inversamente proporcionais velocidade de rotao do eixo do motor CC.
Em outras palavras, quanto mais rpida a velocidade de rotao do eixo do motor, menores
so os perodos das ondas quadradas e, portanto, estas apresentam maiores frequncias. A
frequncia obtida pode ser correspondida a uma estimativa de velocidade de deslocamento
do rob enquanto que a quantidade de ciclos de ondas quadradas podem ser relacionadas
uma estimativa da distncia percorrida pelo rob. A Figura 3.10 mostra a vista superior do
sistema de odometria do rob Kihon e sua relao com o sistema de locomoo do rob mvel
Kihon.
Figura 3.10 Vista superior da odometria junto ao sistema de locomoo do Kihon.

69
Como o encoder (disco de odometria) foi acoplado ao motor CC antes da reduo, no

eixo que gira em alta rotao, quando alimentado com 12V DC a 7600 rpm sem carga, foi
decidido capturar apenas a transio de subida da onda quadrada, ao invs de ambas as
rampas, de subida e descida. Isso significa que em sua velocidade mxima esperado que o
odmetro capture cerca de 7600 pulsos por minuto.
O motor CC utilizado, quando alimentado com 12V, sem carga, executa 7600rpm antes
da reduo e 80rpm aps a reduo, assim, possvel estabelecer a relao da caixa de
reduo, de 127:1. Sabendo-se que o eixo de sada do motor CC (aps a reduo) conectada
por meio de uma ponta doe eixo roda, e que a roda possui dimetro de 8,89 cm, e que so
capturados 127 pulsos por rotao completa da roda, possvel calcular a resoluo do
contador de 1,5099 mm/pulso, conforme a Equao 3.2.
8,89
127 127
(3.2)
Obviamente, tal clculo desconsidera o fator de deformao da roda, uma vez que a roda
empregada utiliza pneu inflado base de borracha. Esta parte de borracha da roda
suscetvel a deformaes conforme a presso que lhe exercida, e que, neste caso, ocorre em
funo da massa do rob Kihon. Alm disso, a massa do rob varia com a embarcao de
dispositivos ou Sistemas de Controle.
As sadas dos dois sensores de odometria esto conectadas ao Contador 0 e Contador 1
do Controlador. Com isso possvel que o software de controle consiga estimar tanto a
distncia percorrida como a velocidade de cada roda do rob Kihon.
3.4.2.4 Sensores de proximidade
Para deteco de coliso, foram posicionados trs mdulos digitais de sensores de

proximidade na parte frontal do rob Kihon. O sensor de proximidade adotado foi do tipo
70
infravermelho, modelo HWBZCGQ da Robox. A Figura 3.11 (a) ilustra o mdulo, a Figura 3.11
(b) a disposio dos trs mdulos na estrutura mecnica, e a Figura 3.11 (c) os sensores j
acoplados na parte frontal do Kihon.
Figura 3.11 (a) Sensor de proximidade empregado; (b) Disposio dos trs sensores; e
(c) Sensores acoplados na parte frontal do Kihon .
O princpio de funcionamento desse mdulo sensor de proximidade similar ao

conjunto emissor-receptor utilizado na odometria, no entanto, este montado sobre uma
pequena placa de circuito impresso; alm disso, possui ajuste de sensibilidade e seus
terminais se resumem ao Vcc, Out e Gnd, o que facilita sua utilizao. Quando o foto-sensor
obtiver retorno da luz emitida, e exceder o limiar definido pelo ajuste de sensibilidade, o nvel
lgico em sua sada ser 0, caso contrrio, apresentar nvel lgico 1. Em outras palavras,
quando o sensor detecta objeto, o mesmo retornar nvel lgico 0, caso contrrio, retornar
nvel lgico 1. Nominalmente, este sensor capaz de detectar objetos a at 20cm. No entanto,
a reflexo, como fenmeno ptico, depende do tipo e cor da superfcie dos objetos onde se
incide o feixe, e ainda, do ngulo de incidncia do feixe. No caso do sensor de proximidade e,
quanto ao seu posicionamento em relao aos objetos, quanto mais perpendicular
superfcie, maior o seu alcance de deteco e, de modo similar, quanto mais reflexiva a
superfcie dos obstculos, maior a distncia de deteco. Na prtica, este sensor se mostrou
pouco eficaz, sendo capaz de detectar objetos a distncias muito inferiores do esperado, como
5 ou 7 cm, para o tipo de superfcie existente no ambiente onde fora realizados os
experimentos.
71
As sadas dos sensores frontais de proximidade so conectados s portas digitais do

Controlador. O sensor esquerdo conectado I/O Digital 2; o sensor central conectado
I/O Digital 3; e o sensor direito conectado I/O Digital 4.
3.4.2.5 Sensores para seguir linhas
Para acrescentar ao rob mvel a habilidade de seguir linhas, foram utilizados dois
OPB705 da Optek Technnology, o mesmo empregado para compor a odometria. A Figura 3.12
ilustra os dois sensores para seguir linhas, acoplados estrutura mecnica do Kihon.
Figura 3.12 Sensores para seguir linhas do Kihon.

No entanto, para a leitura do solo, as sadas destes sensores foram acopladas s

entradas do ADC do Controlador. As conexes das sadas dos foto-transistores s entradas
analgicas do Controlador permitem que o rob Kihon possa navegar em superfcies que
possuam colorao e tons diferentes (preto e branco), uma vez que superfcies com colorao
dentro do intervalo entre branco e preto pode resultar em valores proporcionais de 0 a 5V
na sada do foto-transistor. A estrutura mecnica do Kihon permite que os sensores possam
ser posicionados de modo a otimizar a leitura do solo, permitindo que os sensores possam
ser aproximados ou afastados em relao ao solo e tambm permite ajustes na distncia entre
os sensores. Os sensores para seguir linhas esquerdo e direito do Kihon foram conectados,
respectivamente, aos canais ADC1 e ADC2 do Controlador.
72
3.4.2.6 Sonar
O Sonar - acrnimo de Sound Navigation and Ranging (navegao e determinao de

distncia pelo som), utilizado na robtica mvel para auxiliar na sua localizao relativa e
no mapeamento de regies prximas ao rob. Como descrito em 3.5.1, um sonar acoplado ao
eixo de um servomotor permite ao rob Kihon medir distncias de eventuais objetos ou
obstculos, que surjam na regio frontal do rob. Para o sonar, foi utilizado o HC-SR04, um
sonar monoesttico, direcional, ativo e ultrassnico, capaz de mensurar distncias no
intervalo de 2cm a 4 m e preciso de at 3mm. A Figura 3.13 (a) ilustra o mdulo empregado,
e a Figura 3.13 (b), mostra o Sonar j acoplado ao servo motor e embarcado no Kihon.
Figura 3.13 (a) Sensor Sonar utilizado no Kihon; e (b) Sonar acoplado ao Kihon.
O processo de deteco e/ou localizao de objetos a partir do Sonar chamada de

ecolocalizao. A ecolocalizao baseia-se na propagao fsica do som, na qual, aps emitido,
sua reflexo e retorno ao emissor como eco utilizada para estimar a localizao de objetos
ou obstculos.
Quando o Trigger do sonar acionado, seu transmissor emite um pulso direcionado de
som ultrassnico e, ento, iniciada a contagem de tempo. Este som se propaga pelo
ambiente, e ao atingir um obstculo, ocorre uma reflexo do som, que retorna ao receptor do
73
sonar. O sonar registra o intervalo de tempo decorrido entre a transmisso e a recepo do

som propagado, possibilitando a medio da distncia entre o sonar e o objeto mais prximo
detectado. Por fim, atravs do terminal de Echo, o sonar informa a distncia mensurada. A
Equao 3.3 mostra o clculo para determinar a distncia detectada pelo sonar.
1
1 340
4 8 1
,
48
2
(3.3)
onde TMR1 corresponde ao timer encarregado de contar o tempo decorrido entre o envio da
onda e seu retorno.
De modo a tornar a resposta requisio de medio do sonar mais rpida e no deixar
a cargo do microcontrolador efetuar clculos que consumiro ciclos de clock extras, foi
decidido no atribuir ao Controlador a tarefa de efetuar esse clculo. Portanto, o valor do
TMR1 ser o valor retornado pelo Controlador cada vez que o sonar acionado para efetuar
a medio. Isso quer dizer que existe a necessidade do Software de Controle efetuar a
converso da distncia para metros ou centmetros.
Os terminais de Trigger e Echo do Sonar foram conectados aos terminais I/O Digital 7 e
Contador 3 do Controlador, respectivamente. Mais detalhes a respeito do funcionamento do
sonar podem ser encontrados no datasheet do componente utilizado. O Controlador
concebido dispe de contadores de 2 bytes, sendo assim, sua contagem em decimal vai at
65535. Isso quer dizer que, para o Sonar, possvel medir distncias de objetos a at 7,4
metros, sem que o contador estoure. E, de modo a no limitar a contagem para o alcance
mximo de 4m do sonar utilizado, foi decidido no resetar o contador caso o sonar no receba
o eco aps contagem atingir 35295, valor este equivalente s interrupes necessrias para
aguardar o eco de objetos localizados a at 4 metros de distncia. Assim, possvel acoplar
sonares com alcance de at 7,4 metros para esta configurao do contador do Controlador.
O gerenciamento dos mdulos perifricos apresentados acima realizado por meio de
um nico agente, o Controlador de Rob Mvel. Para este Controlador de Rob Mvel,
buscou-se um microncontrolador que possusse uma quantidade suficiente de recursos de
74
E/S (entrada e sada) e que, somados sua capacidade de processamento, programabilidade

e perifricos de comunicao, permitisse sua utilizao de forma descomplicada para os
usurios, sejam alunos ou pesquisadores. Tendo isso em mente, dentre outras possibilidades
de escolha, optou-se pela utilizao do PIC18F4550, um modelo de microcontrolador da
famlia PIC produzido pela Microchip. Diversos fatores contriburam para sua escolha, como
enquadramento ao escopo do projeto, baixo custo, baixo consumo, disponibilidade no
mercado, disposio imediata no LISDI, dentre outros. Alm disso, este microcrontrolador
possui funcionalidades que permitem programao otimizada em compiladores C, por meio
do compilador MPLAB da Microchip.
3.4.2.7 Fonte de energia
De nada adiantaria satisfazer os requisitos da composio de um rob mvel, se o

mesmo no tiver uma fonte de energia para aliment-lo. Possuir uma fonte de fora motriz
essencial para que todos os componentes funcionais do rob mvel possam operar
satisfatoriamente. Para tal, uma grande parcela dos robs mveis fazem uso de baterias para
o
fornecimento
de
energia
eltrica
seus
sistemas,
que
incluem
circuitos,
microcontroladores, motores, sensores, dentre outros dispositivos e componentes.

Baterias armazenam energia qumica e a convertem em energia eltrica sob demanda.
Existem baterias comerciais de tipo recarregvel e no recarregvel. As baterias
recarregveis podem ser compostas por diferentes composies qumicas e, por conta disso,
apresentam diferentes paradigmas de descarga e recarga. No entanto, todas elas esto
sujeitas a atingir um ponto em que sua recarga no mais efetivamente possvel, sendo assim,
necessria a sua substituio. Em vista de seu custo relativamente baixo, e tambm por
razes de praticidade, comum a utilizao de baterias recarregveis na robtica mvel.
Alm do baixo custo e da facilidade de acesso no mercado, existem diversos tipos e tamanhos
de baterias recarregveis, desde as menores, empregadas, por exemplo, na telefonia mvel e
computadores portteis, at as de maior porte, comuns na indstria automobilstica.
75
Para a concepo do rob mvel Kihon, foi decidido combinar serialmente duas
baterias comerciais de 6V/4,5Ah, seladas de chumbo cido, frente s outras alternativas,
como por exemplo, adotar uma nica bateria de 12V/7Ah. Os 12V obtidos atravs da
disposio serial das baterias empregadas possibilitam alimentar motores de corrente
contnua de at 12V, alm de gerar tenso suficiente para alimentar reguladores de tenso
para nveis TTL e CMOS.
Alguns fatores foram considerados na adoo da disposio escolhida, como o custo
relativamente baixo em relao s outras opes e boa relao entre capacidade de carga,
dimenses, peso e tamanho. Um ltimo aspecto que influenciou na sua escolha foi devido
sua imediata disponibilidade para uso no GISDI. Alm disso, em termos de espao e
disposio fsica, apesar de empregar 2 unidades, foi possvel distribu-las de forma mais
conveniente em virtude de suas dimenses individuais. A Figura 3.14 ilustra a disposio
fsica das baterias utilizadas.
Figura 3.14 - Disposio das baterias empregadas.

Considerando a questo da autonomia da configurao adotada, visto que os motores

empregados consomem individualmente, aproximadamente 50mA quando em operao
(sem carga e desconsiderando os picos de corrente de partida), somados aos circuitos
eletrnicos e ao sistema de controle embarcado, foi estimada uma autonomia energtica da
plataforma de cerca de pelo menos 5 horas de utilizao contnua da mesma. Isto , supondo
76
que consumo aproximado mdio seja inferior a 800mA de toda a parte eletro-mecnica e
computacional embarcada, j que somente o rob mvel Kihon apresenta consumo em torno
de 220mA quando ligado e, pelo menos, 450mA quando em movimento e sem carga.
De modo a oferecer facilidade de uso ao rob mvel Kihon, foi dimensionado um
sistema de recarga das baterias empregadas. O sistema de recarga se resume a um simples
circuito de recarga e a uma fonte de tenso contnua externa. O circuito de recarga foi
elaborado de modo a ser alimentado por uma fonte externa de corrente contnua de 16V,
sendo composto basicamente por um limitador de corrente resistivo, de modo que a corrente
de recarga no ultrapasse 10% da capacidade de carga das baterias (carga rpida), ou seja,
450mA. Logo, o tempo mximo de recarga de cerca de 10 horas para carga completa das
baterias empregadas. A Figura 3.15 ilustra o conector disponibilizado para a recarga das
baterias do Kihon, alm da chave liga/desliga e do LED indicador de estado operacional do
Kihon.
Figura 3.15 Conector de Recarga, chave L/D e LED de sinalizao na lateral do Kihon.
O LED bicolor posicionado ao lado da chave liga/desliga do rob mvel Kihon foi
empregado para sinalizar visualmente as 4 situaes possveis de uso do rob mvel Kihon.
Na primeira situao, com o rob com sua chave na posio desligado e com o carregador
desconectado, este LED permanecer apagado. Na segunda situao, com sua chave na
posio ligado e o rob mvel Kihon operacional, o LED assumir a cor verde. Na terceira
situao, com a fonte de recarga plugada na tomada e conectada ao rob mvel Kihon, e com
a chave na posio desligada, o LED acender a cor vermelha, indicando que o recarregador
est plugado. Por ltimo, com a fonte de recarga na tomada e conectada ao rob mvel Kihon,
77
e este com a chave na posio ligada, o LED acender simultaneamente as cores vermelha e
verde, j que pela implementao do LED indicador e do circuito de recarga, o LED acender
vermelho sempre que o recarregador estiver plugado ao rob mvel, independentemente da
posio da chave liga/desliga.
3.4.3 Concepo da Camada Intermediria
Para averiguar a arquitetura da plataforma proposta neste trabalho, foi necessria a

implementao da Camada Intermediria, apresentada em 3.2. Para tal, contou-se com o
desenvolvimento do firmware do controlador, protocolo de comunicao e tambm da
concepo de uma API para o software de controle, este ltimo que pode ser remoto ou
embarcado no Kihon.
O firmware como Controlador de Robs Mveis compe o software embarcado da
plataforma, atuando como cliente na arquitetura proposta, e foi desenvolvido no
microcontrolador PIC18F4550 da Microchip. O ambiente de desenvolvimento utilizado
para a concepo do firmware foi o MPLAB C Compiler for PIC18 MCUs da Microchip, um
componente integrvel IDE do MPLAB tambm da Microchip. O funcionamento geral do
firmware implementado descrito por meio do fluxograma apresentado na Figura 3.16.
Mensagem
Erro
N
Incio
S
Mensagem?
Segue
Protocolo?
Extrao:
Comando e
Parmetros
Execuo
Requer
Resposta?
Figura 3.16 Fluxograma do Firmware do Controlador.

78
Envio
Resposta
3.4.3.1 Interface de comunicao e canais de alimentao de baixa potncia
A comunicao da plataforma de rob mvel Kihon ao sistema de controle

estabelecida atravs de sua interface de comunicao serial. Neste trabalho, foi adotado o
padro de comunicao RS-232 em conjunto com o padro DB9 de conector fsico. O padro
USART implementado em modo full-duplex dedica um canal para envio e outro para recepo
de dados, possibilitando envio e recepo simultneo. Adicionalmente, os canais de
comunicao TX e RX do microcontrolador, ou seja, seus respectivos pinos 25 e 26 do
PIC18F4550, foram dispostos diretamente a um conector genrico na tampa de acrlico do
rob mvel. O nvel de tenso de operao desses terminais TX e RX o TTL, ou seja, de 5V
CC. A Figura 3.17 ilustra o conector DB9 localizado na lateral do Kihon e o conector genrico
na tampa no Kihon.
Figura 3.17 Interfaces de comunicao no Kihon.

Ainda neste conector genrico, junto aos canais TX e RX, foram dispostas linhas de 5V,
3.3V e GND. As tenses de 5V e 3.3V so comuns na eletrnica digital, uma vez que a
padronizao de componentes TTL (acrnimo de Transistor-Transistor Logic, ou seja, Lgica
Transistor-Transistor) adota a tenso de 5V, e tecnologias CMOS (acrnimo de
Complementary
Metal-Oxide
Semiconductor,
ou
seja,
Semicondutor
Metal-xido
Complementar) adota tenso de 3.3V. Por meio dos reguladores LM7805 e LP2905, para a
disponibilizao de 5V e 3.3V, respectivamente, o fornecimento de ambas as tenses oferece
79
proteo contra quaisquer problemas de dimensionamento de carga, uma vez que ambos os
reguladores possuem internamente circuitos de proteo contra curto-circuitos e
limitadores de corrente. Desta forma, a plataforma capaz de alimentar sistemas
embarcados de baixa potncia de forma segura, alm de oferecer uma interface de
comunicao serial por meio de um conector fsico genrico.
Esta interface genrica foi implementada visando o fornecimento de alimentao de
tecnologias de baixa potncia como microcontroladores, Raspberry Pi e Arduino, atuando
como plataforma de controle embarcada. O emprego de outras tecnologias como netbook
embarcados no necessita das linhas de 5V e 3.3V, uma vez que o equipamento dispe de
bateria e autonomia energtica prpria.
A alternativa de fornecer uma linha de alimentao de 12V foi considerada, no entanto,
a disponibilizao dessa linha de 12V implicaria em uma linha obtida diretamente a partir
das baterias empregadas. Para o fornecimento seguro de uma linha de tenso de 12V, seria
necessrio o uso de reguladores, como o LM7812, mas estes reguladores de 12V, de acordo
com os fabricantes, necessitam que sua alimentao seja de pelo menos 19V, tenso esta que
no pode ser obtida por meio da associao serial das baterias empregadas, de 6V cada uma.
Logo, nesta implementao, no possvel obter a tenso de 12V de forma segura para o
usurio do rob mvel Kihon. O fornecimento de uma linha de 12V direta pode ser
disponibilizada ao usurio, desde que este tenha plena cincia de que est lidando com uma
linha desprotegida contra eventuais problemas de dimencionamento de carga e/ou curtocircuito uma prtica no to incomum em usurios em fase de iniciao eletrnica e
circuitos digitais. Nestas condies, qualquer situao imprpria e sem o uso adequado de
componentes de proteo poderia resultar em danos permanentes aos componentes do
circuito e fiao e, na pior hiptese, perigos de incndio e exploso das baterias utilizadas.
Um simples componente de proteo que poderia ser empregado na linha de 12V o fusvel,
cuja corrente poder ser dimensionada de acordo com o consumo de carga do dispositivo a
ser alimentado.
80
3.4.3.2 Protocolo de comunicao
O protocolo de comunicao adotado enxuto, ainda que implemente recursos de

verificao de erros de comunicao, como conexo, transmisso e recepo das mensagens.
Neste protocolo, todas as mensagens enviadas pelo Sistema de Controle (e no pelo
Controlador) devem ser iniciadas e finalizadas por caracteres especficos. O caracter de incio
foi definido como sendo o <, ou seja, o sinal de menor. J o caractere de fim foi definido
como sendo o >, ou seja, o sinal de maior. Desta forma, a comunicao sempre iniciada
pelo software de Controle, que envia um vetor de bytes iniciados e finalizados,
respectivamente, pelos caracteres < e >. J as mensagens enviadas pelo Controlador no
possuem essa estruturao, ou seja, qualquer dado de resposta transmitido pelo Controlador
feita sem esses caracteres de incio e fim. O Controlador nunca inicia uma transmisso de
dados, mas responde s requisies e comandos recebidos pelo Sistema de Controle quando
necessrio.
O Controlador, ao receber uma dada mensagem, interpreta o primeiro byte aps o
caracter de incio <. De acordo com o comando especificado por este primeiro byte, o
Controlador tratar os demais bytes como parmetros, enviando uma resposta ao Sistema de
Controle quando necessrio. O formato geral das requisies enviadas pelo software de
controle mostrado na Figura 3.18.
<
Comando
Parmetros
>
Incio Msg
Byte 0
Bytes 1 a 3
Fim Msg
Figura 3.18 Formato geral das requisies.

Um resumo das requisies apresentada na Tabela 3.1. O detalhamento de cada

requisio descrito no item F do Apndice C.
81
Tabela 3.1 - Requisies enviadas para o Controlador por meio da comunicao serial.
Requisio
Byte 0
Byte 1
Byte 2
Byte 3
Leitura das entradas ADC
0 ASCII
-----
-----
-----
Leitura dos Contadores
1 ASCII
-----
-----
-----
Medio do Sonar
2 ASCII
-----
-----
-----
Configurao da frequencia PWM
3 ASCII
Perodo
Prescaler
-----
Configurao dos ciclos PWM
4 ASCII
DcycleA
DcycleB
DcycleC
Configurao de controle PWM
5 ASCII
Estado
-----
-----
Configurao do tempo do Servo 0
6 ASCII
Tempo A
Tempo B
-----
7 ASCII
Tempo A
Tempo B
-----
8 ASCII
Tempo A
Tempo B
-----
9 ASCII
Tempo A
Tempo B
-----
Configurao I/O Digitais
10 ASCII
Sentido
-----
-----
Leitura I/O Digitais
11 ASCII
-----
-----
-----
Escrita I/O Digitais
12 ASCII
Estado
-----
-----
A API do Controlador da Plataforma de Rob Mvel foi elaborada com o intuito de

intermediar e facilitar o processo de comunicao entre o software de Controle e o
Controlador. Esta API tem a funo de abstrair o envio de comandos, interpretar os dados de
resposta enviados pelo Controlador, e ainda encarregado de efetuar eventuais clculos e
converses necessrios para a configurao dos dispositivos do PIC, de modo a aliviar a carga
de processamento do microcontrolador utilizado. Uma vez o usurio utilize esta API, ele no
precisa conhecer a fundo os detalhes tcnicos dos mdulos de dispositivos de hardware para
fazer uso da plataforma. A API foi escrita em linguagem C++, uma vez que esta linguagem
oferece uma srie de facilidades de comunicao com portos de E/S (entrada e sada) e
tambm por se tratar de uma linguagem popular ensinada na maior parte das universidades,
alm de possuir uma base vasta de conhecimento na internet. Isto a torna uma forte
linguagem para fins educativos, embora ainda haja muita discusso sobre qual a melhor
linguagem para ensinar programao aos alunos.
Para o desenvolvimento da API, foram utilizados o complilador MinGW 5.1.6 , a IDE
(Integrated Development Environment) Eclipse Kepler, e a API nativa do Windows. Apesar de
82
existir a possibilidade de utilizar um ambiente Linux, o ambiente Windows foi escolhido

devido sua popularidade.
O diagrama da classe Controlador ilustrada na Figura 3.19.
Figura 3.19 Diagrama da Classe Controlador.

3.5
Consideraes sobre a Plataforma de Rob Mvel
Existem diversos aspectos da Plataforma de Rob Mvel que podem ser melhorados
futuramente. Nesta seo, sero expostos e discutidos alguns destes aspectos.
83
3.5.1 Soluo baseada em um nico microcontrolador
O Controlador concebido neste projeto tem como base um nico microcontrolador, o

PIC18F4550, conferindo-lhe uma arquitetura embarcada fortemente acoplada. Isso ainda
confere ao projeto uma reduzida quantidade de componentes, resultando em um baixo custo
de construo e manuteno de hardware, alm de reduzir as chances de problemas de
conectividade e falhas. No entanto, o desempenho obtido pode no ser o melhor possvel, j
que o Controlador possui suas prprias limitaes. O procedimento de interrupo dos
contadores consomem, no melhor caso, 56 ciclos de instruo, o que, teoricamente, permitem
a contagem de pulsos a uma frequncia mxima de 214kHz. A frequncia mnima alcanada
pelos mdulos de PWM de 2,9kHz, um valor significativamente maior do que o requerido
por muitas aplicaes. Alm disso, a aquisio de dados analgicos (ADC) no ocorre em
canais dedicados, dependendo do chaveamento (multiplexao) de canais do conversor, e
sua execuo demanda uma parte considervel do processamento do PIC nesta arquitetura.
Com a utilizao de componentes e dispositivos dedicados para separar cada uma
dessas funcionalidades (contador de pulsos, mdulo de PWM e ADC), ou seja, por meio da
explorao da modularizao e da granularizao dos dispositivos, existe a possibilidade de
se obter ganhos no desempenho do Controlador, uma vez que o mesmo deixar de
compartilhar a CPU para processar as diferentes rotinas de cada mdulo. Tal arquitetura
mostrada na Figura 3.20.
84
Servo
Motores A
Servo Motor A
Digital I/O
Atuador/Sensor E
Atuador/Sensor D
Mdulo
Sonar
Sonar A
Odometria B
Contadores
A
Motor D
Ponte H B
Motor C
Motor B
Motor A
Odometria A
Canais PWM
B
Canais PWM
A
Ponte H A
Conversores
AD B
Sensor C
Conversores
AD A
Sensor B
Sensor A
Controlador
Barramento Perifricos
Figura 3.20 Arquitetura de um Sistema Fracamente Acoplado.

No entanto, por necessitar de microcontroladores dedicados para cada mdulo de

dispositivo perifrico, tal abordagem necessita de uma maior quantidade de
microcontroladores. Isso acarreta em um custo relativamente maior quando comparado
uma arquitetura fortemente acoplada. E ainda, um outro fator o barramento de
comunicao entre o Controlador e os dispositivos perifricos, que precisar ser
implementado, seja criando um ou adotando padres de barramentos j existentes, como por
exemplo o I2C, CAN ou SPI. Nesta disposio, os mdulos conectados ao barramento de
perifricos so capazes de enviar e receber dados do controlador, mas no simultaneamente.
Como possvel observar, essa abordagem tambm visivelmente mais complexa em
comparao adotada neste trabalho.
85
3.5.2 Escolha da comunicao serial
O porto serial um padro de comunicao que, em virtude de sua concepo,

apresenta uma srie de restries. O primeiro aspecto seu carter de legado, junto ao porto
paralelo. Ambos os padres, serial e paralelo, so limitados conectividade ponto a ponto e,
nos dias atuais, suas taxas de transferncia so relativamente muito inferiores, quando
comparados como, por exemplo, ao USB (Universal Serial Bus). O porto serial apresenta taxa
de transferncia de at 115,2 Kb/s e o porto paralelo, chega a 2 Mb/s. J o USB, ainda na
verso 1.0 capaz de atingir 1,5 Mb/s, o USB 2.0 pode chegar a 470Mb/s e finalmente, o USB
3.0 pode alcanar 4,8Gb/s.
O USB, por exemplo, oferece uma srie de vantagens em comparao ao porto serial e
paralelo, como a capacidade de conectar vrios dispositivos perifricos e reconhecer o
dispositivo automaticamente pelo computador. No entanto, de modo a oferecer tais
vantagens, o USB acaba trazendo uma srie de preocupaes inexistentes em comparao
aos portos legatrios, como maior complexidade e uma extensa documentao, devido aos
seus diferentes modos de operao e configurao, alm de necessitar de componentes
dedicados para a comunicao. O PIC18F4550 utilizado possui registradores, instrues e
hardware interno dedicado para a comunicao USB 2.0. Entretanto, o USB necessita que o
usurio conhea uma srie de conceitos, que podem desmotivar sua utilizao.
Existem outras alternativas de comunicao alm do USB 2.0, como o padro I2C e o
SPI, que so suportados pelo PIC18F4550 utilizado. O I2C, acrnimo de Inter-Integrated
Circuit, permite a conexo de mltiplos dispositivos escravos e opera em half duplex no modo
mestre-escravo com apenas duas linhas bidirecionais de 3,3V ou 5V ainda que outros
valores de tenso sejam possveis. Alm disso, o I2C empregado majoritariamente em
dispositivos embarcados e pode operar com vrias taxas de comunicao, incluindo
100kbit/s no chamado Standard Mode e pode chegar aos 3,4Mbit/s no chamado High Speed
Mode. J o SPI, acrnimo de Serial Peripheral Interface, um barramento serial sncrono e full
duplex de comunicao que permite ao microcontrolador se conectar a diversos dispositivos
tambm em modo mestre-escravo, apesar de necessitar de pelo menos 4 canais de
86
comunicao. O SPI no define uma taxa de comunicao mxima, no entanto, sendo full
duplex, capaz de atingir velocidades muito superiores em relao ao I2C que half duplex.
No entanto, ambas as alternativas, de forma similar ao caso do USB, possuem vasta
documentao e suas utilizaes so significativamente mais complexas em relao ao porto
serial, o que as tornam at certo ponto desestimulantes aos usurios.
Portanto, apesar da sua limitada taxa de comunicao, optou-se pela utilizao do
porto serial em virtude de sua simplicidade, facilidade de implementao tanto em termos
de hardware como software.
Em trabalhos futuros, possvel implementar o Controlador utilizando protocolos
como o I2C, SPI e USB, j que o PIC utilizado possui mdulos que do suporte a tais padres
de comunicao.
3.6
Este captulo apresentou a plataforma do rob mvel e detalhou os mdulos que

compem a plataforma. Como j mencionado, por limitao de tempo e oramento, sua
implementao visou oferecer suporte as iniciativas essenciais relacionadas robtica mvel.
O captulo 4 destinado aos testes e verificaes se a plataforma concebida foi capaz de
alcanar os objetivos almejados e que motivaram o seu desenvolvimento.
87
TESTES E VALIDAO
Neste captulo so discutidos os testes de validao da plataforma proposta do rob

mvel Kihon e a anlise dos resultados obtidos. Os experimentos foram elaborados com o
intuito de averiguar os quesitos da plataforma que motivaram seu desenvolvimento.
Inicialmente, avaliou-se a capacidade da plataforma em oferecer suporte s tarefas
estabelecidas pelas aplicaes, alm de verificar a questo da sua facilidade de uso, tanto em
termos de hardware como de software.
Do ponto de vista de hardware, os aspectos
observados foram sua adaptabilidade e facilidade de manuteno, importantes

principalmente em vista do direcionamento dado a este trabalho. J do ponto de vista de
software, os aspectos observados foram se a plataforma oferece liberdade, por ser de cdigo
aberto, e independe da linguagem de programao do Sistema de Controle, uma vez que a
interface de comunicao permite tal caracterstica. Por ltimo, se a arquitetura de
comunicao apresenta flexibilidade quando submetido a diferentes tecnologias de Sistema
de Controle. A partir dos experimentos, foi possvel verificar se a plataforma satisfaz todos
os requisitos e objetivos almejados em 1.3 e 1.4.
4.1
Experimento 1
O primeiro experimento teve como objetivo averiguar a capacidade da plataforma de

oferecer suporte a uma aplicao hipottica e, neste caso, buscando uma situao prxima a
um estudo bsico sobre navegao. A questo da usabilidade da API concebida tambm foi
verificada. Para tal, foi elaborado um experimento no qual verifica-se a capacidade da
plataforma de navegar atravs de um ambiente, respondendo aos estmulos do ambiente em
tempo real, quando controlado de forma remota. Um dos aspectos que tambm pode ser
observado neste experimento se a disposio dos sensores e dos atuadores escolhidos e
implementados no rob mvel o torna capaz de se locomover e navegar apropriadamente
atravs de seu ambiente de aplicao. Neste sentido, como tarefa escolhida para o
88
experimento, foi determinado que o rob deveria navegar pelo ambiente seguindo uma
parede e evitando colises. A averiguao se deu tendo como base o comportamento do rob
mvel Kihon ao interagir com o ambiente. Este experimento foi realizado empregando um
notebook atuando como uma base computacional remota e sua comunicao sem fio foi
tecnologicamente estabelecida por meio de mdulos Xbee.
O diagrama de conexo cliente-servidor estabelecido neste experimento, entre o rob
mvel Kihon ao sistema de controle ilustrada na Figura 4.1.
Comunicao wireless
Cliente
Servidor
Notebook
Rob Mvel Kihon
Figura 4.1 Diagrama cliente-servidor do Experimento 1.

Este experimento buscou se aproximar das condies usuais, nas quais os usurios
utilizam seus computadores pessoais para desenvolver experimentos envolvendo, por
exemplo, tcnicas de navegao e locomoo de robs mveis. A base computacional remota
executa o software do Sistema de Controle em um computador cujo sistema operacional o
Microsoft Windows 8. Computadores pessoais, em especial os notebooks, em conjunto com o
sistema operacional da plataforma Windows, costumam ser familiares na maior parte dos
usurios, tornando tais ambientes uma alternativa comum para o desenvolvimento de
software, seja por parte dos usurios, como alunos e, at mesmo, pesquisadores. A linguagem
de programao empregada foi a C++, uma vez que a API do Controlador j havia sido
concebida anteriormente nessa linguagem. Alm disso, o C++ frequentemente se apresenta
89
como uma linguagem didtica no desenvolvimento de algoritmos, sendo comum em

disciplinas da graduao e, tambm, como linguagem para desenvolvimento de software.
Para realizar este experimento, foi utilizado um sensor de distncia (Sonar) acoplado
ao servomotor para realizar a varredura da parte frontal do rob mvel e auxiliado pelos trs
sensores de proximidade frontais. A Figura 4.2 ilustra a vista superior do Kihon e a disposio
dos sensores frontais de proximidade, sonar e do servomotor.
Figura 4.2 Disposio dos sensores do Kihon utilizados no Experimento 1.

A arquitetura de controle concebida para o experimento se enquadra na arquitetura de

subordinao (ou subsuno) apresentada por Brooks (1986), caracterstico do paradigma
comportamental, uma vez que baseia-se no comportamento observado em animais. A partir
disso, um simples algoritmo de seguir parede foi implementado. Neste algoritmo, uma srie
de 5 medies do sonar coletada ao longo dos 180 graus (sendo uma medio a cada 45
graus) da parte frontal da base do rob mvel Kihon, realizado com auxlio do servomotor.
Essas medies so feitas de modo a detectar a presena da parede em conjunto com leituras
dos sensores de proximidade, na deteco de uma coliso frontal iminente. A partir das
medies levantadas pelos sensores, o rob navega contornando e acompanhando a parede
90
encontrada. A velocidade de trao dos motores foi controlada por modulao de largura de
pulso PWM (acrnimo do termo em ingls Pulse Width Modulation). O diagrama de
execuo do algoritmo usado mostrado na Figura 4.3.
Sensores IR
Evitar coliso
Sonar
Contornar
Supresso
Motores
Trao
Figura 4.3 Diagrama do algoritmo reativo de navegao.

Por meio de chamadas s rotinas contidas na Classe Controlador da API (descrito em

3.4.3), o algoritmo de navegao capaz de ter acesso aos mdulos de hardware do Kihon.
Algumas das chamadas utilizadas neste experimento so exemplificadas na Tabela 4.1.
Experimento 1.
Exemplo de Requisio
Chamada API
Retorno
Config. Angulo do servo motor 0 a 35
controlador->servoAngulo(0, 35)
-----
Medio do Sonar
controlador->Sonar()
Distncia em cm
Config. Movimentao Kihon p/ frente
controlador->pwmControl(frente)
-----
Config. Ciclo PWM: 85% Esq e 65% Dir
Controlador->pwmCiclo(0.85, 0.65)
-----
Leitura Portas I/O Dig. (sensors prox.)
Controlador->ioRead()
Estado de todas I/O

Digitais
O trajeto percorrido pelo Kihon neste experimento com o algoritmo implementado

mostrado na Figura 4.4.
91
Kihon
m
0
2
Figura 4.4 Trajeto percorrido pelo Kihon com o algoritmo implementado.
A Figura 4.5 ilustra o Experimento 1 em andamento com o Kihon navegando atravs do

ambiente.
Figura 4.5 Kihon em execuo do Experimento 1.

92
4.1.1 Consideraes
Analisando a capacidade da plataforma em oferecer suporte a uma aplicao hipottica

envolvendo navegao de robs mveis, que de certa forma culminam na escolha da
arquietura de hardware e tambm na disposio dos dispositivos de sensoriamento e atuao
escolhidos, o rob mvel Kihon se mostrou capaz de se locomover bem atravs do ambiente,
observando-se os seguintes aspectos:
1. Os motores CC empregados no tracionamento se mostraram capazes de operar
com ciclos de trabalho acima dos 50% em virtude da elevada frequncia PWM
gerada pelo Controlador, de aproximadamente 2.93kHz. Esta frequncia a
menor possvel obtida no microcontrolador utilizado. Por causa disto, o rob
apresentou dificuldades em se locomover ou arrancar em baixas velocidades.
2. Os sensores de proximidade frontais empregados no rob mvel apresentam
uma sensibilidade cujo limite de deteco de objetos e paredes se mostrou
prximo de 5 cm, inferior aos 20 cm nominais do fabricante. Isso, somado ao
posicionamento dos mesmos, ocasionou algumas colises nas laterais do rob
mvel. Essas colises ocorreram em funo do ngulo de aproximao do rob
mvel em relao s paredes, principalmente nas ocasies em que as medidas
realizadas pelo sonar no foram suficientes para detect-las. Vale ressaltar que,
apesar do sonar utilizar-se do ultra som, e do sensor de proximidade basear-se
na emisso de luz infravermelha, tanto a propagao direcional do som como da
luz se sujeitam a fenmenos fsicos pticos similares em relao aos ngulos de
emisso e reflexo, devido natureza especular das superfcies.
3. Quanto ao tempo de resposta do sistema, que engloba o processamento remoto
e comunicao feita por meio sem fio, isto no comprometeu o objetivo da
93
aplicao. Apesar do atraso mdio de 20ms nas respostas aos estmulos

ambientais, ocasionados pelo sistema de comunicao Xbee, o rob mvel Kihon
foi capaz de se locomover atravs do ambiente conforme planejado, evitando
colises na maior parte dos casos, apesar das situaes descritas.
4. Por fim, em relao facilidade de uso, o rob mvel se mostrou capaz de prover
conectividade remota de forma descomplicada. A interface de comunicao
usada para estabelecer a conexo cliente-servidor apresenta terminais simples
e objetivos, com funes estabelecidas como TX, RX e GND. Isso permite aos
usurios voltarem seus esforos aos tpicos de interesse, no demandando
tempo em extensas documentaes apenas para estabelecer uma comunicao.
O intuito deste experimento foi verificar a capacidade da plataforma em oferecer
suporte a uma atividade envolvendo a navegao do rob mvel. O Kihon foi capaz de
responder aos estmulos do ambiente em tempo real, quando controlado de forma remota,
apesar das dificuldades que ocorreram em vista dos sensores de proximidade utilizados e
tambm da limitada velocidade de sua interface de comunicao. vlido mencionar que
essa disposio de conexo remota estabelecida para este experimento apresenta diversas
vantagens ao usurio, como o fato de poder desenvolver aplicaes em um ambiente familiar,
como um computador pessoal (notebook), e ainda, sem a necessidade de manusear o rob
mvel a cada nova reprogramao de seus algoritmos de controle, j que o sistema de
controle executado no prprio notebook do usurio. Por outro lado, a reprogramao de um
sistema de controle embarcado no rob mvel exige maiores cuidados, alm de tempo e
trabalho por parte dos usurios.
O rob mostrou ser apto a se locomover em seu ambiente de aplicao apesar do seu
sistema de tracionamento se limitar a velocidades acima de 50% dos ciclos PWM. Quanto ao
problema envolvendo colises laterais, uma alternativa para contornar tal situao, alm do
uso de controle diferente de velocidade de deslocamento ou de outro algoritmo de controle
do rob, pode ser a substituio destes sensores digitais por sensores de proximidade
analgicos, como o caso do GP2D12 da Sharp. Apesar de mais caro em relao aos sensores
empregados, o GP2D12 capaz de medir distncias de 10cm a 80 cm, de acordo com o
94
fabricante, tambm pelo processo de reflexo de feixe de luz. Alm disso, suas sadas
poderiam ser conectadas nas entradas ADC do Controlador, permitindo aquisies dos dados
analgicos destes sensores, e no digital (binria), como foi realizado neste experimento.
Uma outra alternativa ainda em termos de hardware, poderia ser a adoo de sensores
analgicos ou ainda, empregando uma quantidade maior de sensores de proximidade. Essa
possibilidade em acoplar e experimentar diversos tipos de dispositivos perifricos pode ser
vista como um fator positivo, uma vez que estimula os usurios a desenvolverem e
implementarem suas prprias solues. Tal possibilidade somada facilidade de uso obtida
atravs da conectividade remota, mostram-se interessantes, principalmente em ambientes
de desenvolvimento, na qual capaz de permitir e motivar os usurios da plataforma a
explorarem na prtica, outras atividades envolvendo assuntos relacionados locomoo e
navegao de robs mveis utilizando o Kihon.
J em relao API do controlador utilizado, este foi capaz de oferecer acesso aos
mdulos de hardware implementados no Kihon de forma descomplicada. Essa facilidade
apresenta-se como um fator positivo na utilizao da plataforma concebida.
4.2
Experimento 2
O segundo experimento teve como objetivo averiguar a capacidade da plataforma em

oferecer suporte uma aplicao cientfica. Nesse contexto, este experimento foi baseado em
um trabalho realizado por Voltan et. al. (2011), onde os autores coletaram e estudaram a
umidade relativa do ar dentro de uma estufa agrcola, esta que teve sua rea mapeada e
dividida em 114 pontos de medio. De modo a se obter sua variabilidade espacial, cada um
desses pontos tiveram suas medies coletadas manualmente em trs diferentes alturas em
relao ao solo, sendo estas, 30cm, 120cm e 200cm em trs horrios ao longo do dia. Nesse
contexto, foi atribudo ao rob mvel, a misso de executar uma tarefa em um cenrio similar,
seguindo um circuito determinado com linhas pretas no cho e coletando amostras de
temperatura em trs diferentes alturas, e em determinados pontos de seu plano de
navegao. A partir dos dados levantados, possvel, por exemplo, fazer um levantamento
95
espacial da variao de temperatura de uma estufa ou um ambiente qualquer, em diferentes

condies como horrios, estaes, climatizaes, etc. Tanto a objetividade como a anlise
dos dados coletados podem ser vistas em Voltan et. al. (2011), j que fogem do escopo
proposto neste trabalho e, portanto, no sero aprofundados ou discutidos aqui.
Adicionalmente, este experimento foi elaborado de forma a avaliar a flexibilidade da
plataforma de rob mvel em termos de tecnologias de sistemas de controle e sua
usabilidade. Para tal, empregou-se um RLRduino para realizar o Sistema de Controle.
Produzido pela RLRobotics, o RLRduino uma verso brasileira e equivalente ao Arduino
Uno R3. Adicionalmente, o sistema de controle foi embarcado no rob mvel, fixando-o sobre
o suporte do rob mvel Kihon. E por meio de seu porto serial, o RLRduino foi conectado
diretamente interface de comunicao do rob mvel Kihon. A disposio dos dispositivos
utilizados neste experimento no Kihon so mostrados na Figura 4.6.
Figura 4.6 Disposio dos dispositivos utilizados no Experimento 2.

Para a realizao deste experimento, trs sensores de temperatura foram adicionados

ao rob mvel, de modo que o permita coletar amostras de temperatura do ambiente em trs
alturas diferentes a partir do solo. Para isso, uma coluna de alumnio foi fixada sobre o
96
suporte da plataforma do Kihon e cada sensor foi fixado na coluna de modo que sua posio
em relao ao solo corresponda s alturas de 50cm, 100cm e 150cm, respectivamente. O
sensor de temperatura usado foi o LM35DZ, um modelo calibrado em graus Celsius que
apresenta resoluo de 10mV/C e erro tpico de 0,9C em temperaturas superiores a 25C.
Os sensores de temperatura tiveram as sadas de seus circuitos conectadas s entradas ADC
do RLRduino, sendo estas A0, A1 e A2. As entradas analgicas do RLRduino possuem
resoluo de 10 bits que, no intervalo de 0V a 5V, assumem resoluo (degrau) de
4,88mV/degrau.
Apesar do Controlador basear-se no microcontrolador PIC18F4550, que nesta
utilizao, dispe de 8 canais de converso AD de 10 bits de resoluo e dos quais 5 ainda
disponveis para uso, escolheu-se por utilizar os conversores do RLRduino. A leitura dos
canais AD do RLRduino levam cerca de 100 s, o que permite efetuar at 10 mil medies por
segundo. J a leitura dos canais AD do Controlador, que tem como base o PIC18F4550, e que
devido aos processos de chaveamento e pelas configuraes dos seus registradores do
mdulo AD, o ciclo completo de converso AD do microcontrolador demanda 20s,
permitindo efetuar at 50 mil medies por segundo. A deciso por utilizar o ADC do
RLRduino se deu uma vez que, apesar da plataforma de rob mvel ainda ter disponveis
recursos vagos de entrada e sada, pode haver a necessidade de empregar outros tipos de
dispositivos no implementados no Kihon, como por exemplo, uma cmera de vdeo, ou um
sistema GPS. Portanto, apesar da plataforma dispor de recursos similares neste caso, ou seja,
de conversores ADC, decidiu-se por utilizar recursos do prprio RLRduino e externos ao
Kihon.
Como parte da tarefa da aplicao, determinou-se que o rob deveria seguir um circuito
determinado por uma linha sobre seu plano de navegao. O circuito possui demarcaes que
determinam os locais onde devem ser coletadas medies de temperaturas do ambiente. A
linha foi demarcada com fita adesiva preta de forma contnua, colada sobre a superfcie de
navegao, sendo esta plana e de cor clara, de modo a se obter suficiente contraste. Foi
definido que tal traado no possui curvas acentuadas e nem bifurcaes, no entanto, a cada
trecho, o percurso possui demarcaes que determinam os locais onde devem ser coletadas
97
medies de temperatura do ambiente. Para seguir o traado, foram utilizados os dois

sensores de seguir linhas implementados no rob mvel Kihon. Como descrito no item 3.4.2.5,
a sada destes dois sensores so conectados s entradas dos canais ADC do Controlador. A
Figura 4.7 ilustra o circuito elaborado para o experimento.
Figura 4.7 Vista superior do Circuito elaborado para ser percorrido pelo Kihon.
A seta indica o sentido e a posio inicial do circuito. Em cada trecho demarcado do

trajeto, o rob realiza uma parada para coletar 10 amostras de temperatura de cada um dos
trs sensores, calcular suas respectivas mdias e enviar os resultados obtidos a uma base de
coleta de dados remota; ento o rob mvel prossegue pela linha at o prximo ponto
demarcado, sucessivamente, at concluir o trajeto e retornar ao ponto inicial. O envio dos
resultados foi necessrio, uma vez que no havia possibilidade de armazenamento de dados
em um arquivo diretamente no RLRduino, j que a manipulao de arquivos no RLRduino
requer o uso do shield SD card, indisponvel no LISDI. Essa transmisso dos dados foi
realizada por meio de um dispositivo Xbee, que foi conectado a um segundo porto serial
emulado via software pelo RLRduino. Para a recepo dos dados foi utilizado outro mdulo
Xbee conectado a um notebook, onde um software ficou responsvel por armazenar os dados
recebidos em um arquivo de registro (log), este que tambm registra a data e a hora do incio
de cada volta. A Figura 4.8 ilustra a arquitetura cliente-servidor, desta vez embarcada,
adotada para o Experimento 2.
98
Comunicao wireless
Servidor
Cliente
Notebook
Rob Mvel Kihon
Figura 4.8 Diagrama da arquitetura cliente-servidor do Experimento 2.

As Figuras 4.9 (a) ilustra o ambiente onde foi realizado o Experimento 2 e a Figura 4.9
(b) ilustra o rob mvel Kihon executando o Experimento 2.
99
Figura 4.9 (a) Vista geral do ambiente onde foi realizado o Experimento 2; e (b) Rob
mvel Kihon executando o Experimento 2.
Em relao ao algoritmo, utilizou-se a programao em linguagem baseada em C/C++

adaptada para o ambiente Arduino, j que o RLRduino utilizado 100% compatvel IDE
disponibilizada para o Arduino. A escolha por essa linguagem C++ se deu em vista da
familiaridade em relao ela, e tambm porque a API do Controlador j havia sido
previamente concebida em C++, exigindo pequenas alteraes. Apesar de ser possvel
implementar outra arquitetura de controle, pela prpria facilidade de implementao, este
experimento enquadrou-se novamente no paradigma comportamental, conforme Brooks
(1986).
De modo similar ao modo como foi realizado no Experimento 1, por meio de chamadas
s rotinas contidas na Classe Controlador da API (descrito em 3.4.3) adaptadas ao Arduino, o
algoritmo de navegao foi capaz de ter acesso aos mdulos de hardware do Kihon. Algumas
das chamadas utilizadas neste experimento so exemplificadas na Tabela 4.2.
100

Experimento 2.
Exemplo de Requisio
Chamada API
Retorno
Leitura dos Sensores de Solo
controlador->leADC()
Config. Movimentao Kihon p/ parar
controlador->pwmControl(bloqueio)
-----
Config. Ciclo PWM: 75% Esq e 75% Dir
Controlador->pwmCiclo(0.75, 0.75)
-----
Leitura de todos
canais AD
Os dados obtidos no Experimento 2 so apresentados na Tabela 4.3.

Tabela 4.3 Valores de temperatura (em C) obtidos no Experimento 2.
Sensor 1.5m
Sensor 0.5m
Sensor 1.0m
Sensor 1.5m
Sensor 0.5m
Sensor 1.0m
Sensor 1.5m
Volta 3 - hora 17:30
Sensor 1.0m
Medio pto 1
Medio pto 2
Medio pto 3
Medio pto 4
Medio pto 5
Medio pto 6
Medio pto 7
Medio pto 8
Volta 2 - hora 16:55
Sensor 0.5m
Volta 1 - hora: 16:30
31.04
30.99
30.79
30.89
30.79
30.79
30.79
30.79
31.28
31.28
31.28
31.28
31.28
31.28
31.28
31.28
30.79
30.79
30.79
30.79
30.79
30.79
30.79
30.79
30.79
30.74
30.40
30.35
30.30
30.30
30.30
30.30
30.79
30.74
30.74
30.74
30.74
30.74
30.65
30.74
30.30
30.30
30.30
30.30
30.30
30.30
30.30
30.30
30.30
30.30
30.30
30.30
30.30
30.30
30.30
30.30
30.40
30.50
30.55
30.45
30.30
30.30
30.30
30.30
29.91
30.16
30.21
30.25
30.25
30.21
30.06
30.11
4.2.1 Consideraes
Os resultados obtidos por meio deste experimento mostraram que o rob mvel Kihon
foi capaz de realizar o experimento satisfazendo os requisitos levantados pela tarefa
estipulada, observando-se os seguintes itens:
1. Quanto capacidade em oferecer suporte aos experimentos voltados pesquisa,
o rob mvel foi capaz de fazer uso adequado de seus sensores de solo ao seguir
corretamente o traado estipulado e, em conjunto com sensores acoplados
101
diretamente plataforma de controle (realizada pelo RLRduino), a aplicao foi

capaz de realizar as medies de temperatura nos determinados pontos do
plano de navegao. Essa capacidade da plataforma proposta de atuar como uma
base de rob mvel o torna apto a suportar experimentos envolvendo a robtica
mvel, uma vez oferece funcionalidades essenciais de navegao, locomoo e
ainda, sua arquitetura de hardware aberta o possibilita operar em conjunto com
dispositivos externos, que neste caso foram a base de coleta de dados remota, e
trs sensores de temperatura conetados diretamente ao Sistema de Controle,
mas que em outro cenrio, poderia ter sido uma cmera de vdeo ou um mdulo
GPS.
2. A flexibilidade oferecida em termos de conectividade permitiu que uma
tecnologia de Sistema de Controle fosse embarcada no rob mvel de forma
descomplicada e rpida, por meio de seu conector de interface serial. Por
apresentar uma interface de conexo serial genrica e um protocolo enxuto, a
plataforma de rob mvel se apresenta como uma alternativa interessante, e
ainda, sem comprometer a viabilidade tcnica e financeira. Esse aspecto
interessante na robtica mvel e afeta diretamente na usabilidade da plataforma,
uma vez que tal liberdade aliada simplicidade pode oferecer aos
pesquisadores condies de escolher diversos aspectos do desenvolvimento de
suas aplicaes, como empregar o sistema de controle de sua escolha, a prpria
linguagem de programao, a arquitetura de controle desejada, e seu ambiente
de desenvolvimento (IDE).
Com o sistema de controle embarcado, o rob mvel foi capaz de executar
adequadamente a tarefa determinada pelo experimento. Alm disso, o envio e recepo dos
dados coletados a uma base de dados remota pde ser estabelecida sem dificuldades com o
Sistema de Controle embarcado, j que o uso da tecnologia Xbee de comunicao sem fio
empregada j era familiar. A conexo remota entre o Arduino e o Notebook foi estabelecida
por meio de um porto serial, replicado utilizando a biblioteca SoftwareSerial do Arduino. J
a conexo do Arduino, como Sistema de Controle, ao rob mvel, como base da plataforma
102
de rob mvel, foi estabelecida diretamente atravs do porto serial USART nativo do Arduino.
Ainda que o porto serial tenha uma taxa de comunicao limitada para os padres modernos
de comunicao, a interface de comunicao apresentou desempenho suficiente para a
transmisso dos dados deste experimento, j que apenas 3 pares de bytes foram transmitidos
a cada ponto de medio do circuito.
4.3
Da forma como a plataforma foi concebida, ela ainda apresenta limitaes tanto em
termos de flexibilidade como em seu tempo de resposta. Caracterizando um sistema
fortemente acoplado, seu Controlador foi concebido tendo como base um nico
microcontrolador, responsvel tanto pelo gerenciamento de todos os recursos (sensores e
atuadores), como pela comunicao com o Sistema de controle. Esse gerenciamento se torna
custoso ao microcontrolador, na medida que lhe atribuda a tarefa de efetuar o
processamento das mensagens e ainda ter de se preocupar com todas as atividades dos
perifricos, como interrupes externas (contador), gerao dos ciclos PWM, gerao dos
tempos dos servomotores, converso ADC, etc. Essa abordagem traz consigo certas
limitaes, ainda que, a princpio, reduza o custo e simplifique o entendimento, e que foram
parte dos objetivos deste trabalho.
Apesar de oferecer suporte s iniciativas essenciais envolvendo a robtica mvel, a
plataforma ainda tem muito a melhorar, como por exemplo, com a explorao mais
granularizada oferecida por uma arquitetura fracamente acoplada. Uma plataforma na qual
possua, por exemplo, um dispositivo microcontrolador dedicado coordenao dos recursos
de hardware e microcontroladores dedicados cada dispositivo perifrico, podendo oferecer
ainda, maior liberdade principalmente em relao flexibilidade de hardware. Essa
flexibilidade diz respeito tambm s possibilidades de adicionar ou remover hardware de
perifricos, podendo apresentar caractersticas de operabilidade PnP (do termo em ingls:
plug and play, conectar e usar). Essa arquitetura fracamente acoplada poderia ser explorada
em trabalhos futuros.
103
Um dos itens que se exigiu especial ateno na concepo do rob mvel Kihon foi a
embarcao de dispositivos padres de sensores e atuadores, de forma que o tornasse
operacional, permitindo-o experimentar diferentes conceitos prticos relacionados
robtica mvel. Essa tarefa compreendeu tanto a escolha como a disposio dos itens de
hardware para compor o rob mvel, sem perder de vista o foco no reduzido custo dos
perifricos escolhidos, como pode ser verificada em 3.4.2.
No entanto, devido s restries de tempo e oramento, o hardware implementado no
foi explorado totalmente. O Controlador do rob mvel, apesar de suas limitaes em virtude
da arquitetura adotada, suporta uma quantidade maior de dispositivos perifricos do que foi
implementado neste trabalho. Portanto, em trabalhos futuros e ainda explorando a
arquitetura fortemente acoplada implementada neste trabalho, outros dispositivos sensores
e atuadores podero ser implementados e embarcados no rob mvel para aumentar sua
funcionalidade, de modo similar forma como foi realizado no Experimento 2. Existem
inmeras possibilidades para tais dispositivos perifricos, tais como sensores de choque,
sensores de luz, servomotores para compor um brao mecnico, dentre outros.
104
CONSIDERAES FINAIS
Com os recentes avanos tecnolgicos e a reduo dos custos de produtos tecnolgicos,

a robtica mvel tem se mostrado uma rea em crescimento e com isso, tem despertado
interesse cada vez maior em diversas aplicaes, como domsticas, agrgolas e industriais.
Em muitas dessas aplicaes, os robs so desenvolvidos de modo a realizarem tarefas
tediosas e at mesmo perigosas para os seres humanos. Exemplos comerciais ou cientficos
desses esforos no faltam, como robs que aspiram o cho da casa, veculos inteligentes
como os desenvolvidos para o desafio DARPA e o Google Self-Driving Car Project, robs de
explorao de solo marciano com o Mars Exploration Rover da NASA, dentre outros. No
entanto, a robtica mvel ainda apresenta diversos desafios para a comunidade cientfica.
Um dos desafios que, apesar dos diversos trabalhos propostos na literatura, ainda no h
uma padronizao de tcnicas, arquiteturas de controle ou software e nem mesmo uma
linguagem de programao estabelecida para a robtica mvel. Essa ausncia de um
consenso justificvel, uma vez que cada aplicao possui necessidades especficas que
podem ser alcanadas de uma maneira, e outras aplicaes que exigem outra abordagem.
Neste contexto se inseriu a proposta deste trabalho, que uma arquitetura de controle e
software aberta e flexvel, destinada ao desenvolvimento de iniciativas envolvendo a robtica
mvel. Em virtude de sua destinao, aspectos como simplicidade e baixo custo foram
consideradas, de modo a tornar seu uso mais acessvel e motivador. Por apresentar uma
soluo de baixo custo, seu hardware implementado apresenta poucos componentes, como
sensores e atuadores, os quais podem ser encontrados sem dificuldade no mercado. Logo,
uma replicao da plataforma apresentada pode facilmente ser efetuada at mesmo por
estudantes. E, ainda, com a facilidade oferecida pelo ICSP, possvel fazer a reprogramao
do Controlador utilizado sem a necessidade de desmontar o rob mvel e remover o
microcontrolador do circuito.
A plataforma proposta foi averiguada atravs da concepo do rob mvel Kihon. O
Kihon apresenta, dentro das limitaes j discutidas em 3.4 e 3.5, flexibilidade para
implementao de um conjunto de dispositivos perifricos adicionais, propriedade verificada
105
no Experimento 2 (ver 4.2). E de modo a suportar tais iniciativas, a implementao do Kihon

buscou oferecer condies essenciais de operao, como navegabilidade, sem perder de vista
a facilidade de se efetuar manuteno e
usabilidade, caractersticas estas que foram
averiguadas nos dois experimentos realizados (captulo 4). Apesar do Kihon ter apresentado
algumas dificuldades no experimentos realizados, alguns se deram em virtude das limitaes
apresentadas, devido s restries de oramento, com o emprego de sensores de baixo custo
e em pouca quantidade. Sendo assim, em termos de hardware, ainda possvel por exemplo,
experimentar o uso de outros componentes tanto sensores como atuadores, ou ainda,
adicionar mdulos de hardware, uma vez que a quantidade de entradas e sadas do
controlador no foi totalmente explorada neste trabalho.
A interface de comunicao adotada mostrou-se suficiente para realizar a comunicao
de dados entre a plataforma e o software de controle sem comprometer sua reatividade.
Apesar das evidentes limitaes trazidas com a escolha de um padro legatrio, o resultado
satisfatrio se deu em virtude do simples protocolo de comunicao e tambm com a
abstrao das requisies e dos dados. Alm disso, atribuindo API do Controlador a tarefa
de efetuar clculos e converses permitiu aliviar a carga de processamento sobre o
microcontrolador, otimizando seu tempo de resposta aos comandos (requisies) de
controle. A interface de comunicao adicional oferecida por meio de um segundo conector
fsico mostrou ser uma alternativa interessante para conexo de dispositivos que no
utilizam o padro de conector DB9, alm de oferecer opes para alimentao de dispositivos
de baixa potncia.
A API do Controlador foi capaz de realizar a interface do software de controle com a
plataforma de forma adequada, obtendo resultados dentro do esperado, averiguados atravs
dos resultados obtidos com os Experimentos 1 e 2 (ver 4.1 e 4.2). Essa API pode ser
reaproveitada para desenvolver novas aplicaes, implementar novas funcionalidades
plataforma, assim como ser adaptada para outras linguagens de programao de modo a
suportar outras plataformas e tecnologias para o controle da plataforma.
Ao deixar em aberto os paradigmas de controle e de software, a plataforma oferece
maior liberdade, permitindo a explorao de diferentes paradigmas no desenvolvimento de
106
suas aplicaes. Situao esta que seria dificultada com a definio e adoo de uma
determinada arquitetura de controle ou de software, j que acabaria restringindo as
possibilidades de desenvolvimento, manuteno e reutilizao do software, alm de acabar
limitando a plataforma a algumas tecnologias e ambientes de desenvolvimento.
Atravs dos resultados obtidos, possvel concluir que a plataforma concebida neste
trabalho capaz de se apresentar como uma alternativa vivel para facilitar o
desenvolvimento de aplicaes envolvendo a robtica mvel. Com a adoo de conceitos
simples e ainda com o emprego de um nmero reduzido de componentes, possvel obter
uma plataforma que apresente, dentro de suas limitaes, um certo grau de flexibilidade e
ainda oferecer recursos, de modo a torn-la funcional para execuo de aplicaes
envolvendo locomoo e navegao. Conforme j considerado em 3.5 e 4.3, este trabalho
ainda pode ser melhorado significativamente, com a adoo de outras tecnologias para a
comunicao de dados, ampliao e otimizao do protocolo de comunicao, de modo que a
plataforma suporte uma variedade maior de dispositivos de hardware, implementao de sua
API em outras linguagens de programao e ainda, com uma abordagem que explore a
moduralizao dos dispositivos de hardware da plataforma, ainda isto signifique aumento da
complexidade e custo.
O presente trabalho contribui com a implementao da API do Controlador de Rob
Mvel, suas bibliotecas bsicas de controle, com protocolo bsico de comunicao, e com o
rob mvel Kihon concebido, de modo a averiguar suas arquiteturas abertas de controle e de
software simples e de baixo custo, em conformidade com a proposta apresentada. Este
trabalho, junto ao rob mvel Kihon, apresenta-se como uma base para trabalhos futuros sob
a perspectiva computacional para o desenvolvimento de aplicaes e experimentos
envolvendo no apenas a robtica mvel, mas tambm de tpicos relacionados.
107
REFERNCIAS
ALVES, S.; ROSRIO, J. M.; FILHO, H. F.; NUNES, I.; TAO - a software plataform for autonomous
mobile robots. IEEE International Conference on Control, Automation and systems (ICC), out
2012.
ANDO, N.; SUEHIRO, T.; KITAGAKI, K.; KOTOKU, T.; YOON W. RT-Middleware: distributed
component middleware for RT (Robot Technology), IEEE/RSJ International Conference on
Intelligent Robots and Systems (IROS), ago 2005.
BARBER K. S.; MARTIN C. E. Specification, measurement, and adjustment of agent autonomy: theory and implementation. Autonomous Agents and Multi-Agent Systems, may 1999.
BATLLE, J. A.; BARJAU, A. Holonomy in mobile robots. Robotics and Autonomous Systems,
v. 57, n. 4, p. 433-440, 30, abr 2009.
BEKEY, G. A. Autonomous robots: from biological inspiration to implementation and control.
[S.l.]: MIT Press, 2005.
BETKE, M.; GURVITS, L. Mobile robot localization using landmarks. abr 1995.
BLANK D.; KUMAR D.; MEEDEN L.; YANCO H. Pyro: an integrated environment for robotics
education. Proceedings of the National Conference on Artifical Intelligence, Vol. 20, No. 4,
2005.
BLANK D.; KUMAR D.; MEEDEN L.; YANCO H. Pyro: a Python-based versatile programming
environment for teaching robotics. Journal on Educational Resources in Computing, Vol. 3,
No. 4, dez 2003.
BONARINI, A.; MATTEUCCI, M.; MIGLIAVACCA, M.; RIZZI, D. R2P: an open source hardware
and software modular approach to robot prototyping. Robotics and Autonomous Systems,
2013.
BORENSTEIN, J.; EVERETT, H. R.; FENG, L. Where am I? Sensors and techniques for mobile
robot positioning. University of Michigan, abr 1996.
BROOKS, R. A. A robusted layered control system for a mobile robot. IEEE Journal of Robotics and Automation, Vol. RA2, No. 1, mar 1986.
BROOKS, R. A. Intelligence without reason. Proceedings of 12th International Joint Conference on Artificial Intelligence, p. 569-595, ago 1991.
CHATILA, R.; CAMARGO, R. F. Open architecture design and inter-task/inter-module
communication for an autonomous mobile robot. IEEE International Workshop on Intelligent Robots and Systems - IROS, 1990.
108
DUDEK, G.; JENKIN, M. Computational principles of mobile robotics. [S.l.]: Cambridge University Press, 2010.
ELFES, A. A distributed control architecture for an autonomous mobile robot. Artificial
Intelligence in Engireering, Vol. 1, No. 2, p. 99-108, 1986.
ELKADY, A.; SOBH, T. Robotics middleware: a comprehensive literature survey and attribute-based bibliography. Journal of Robotics, 2012.
FAYEK, R. E.; LISCANO, R.; KARAM, G. M. A system architecture for a mobile robot based
on activities and a blackboard control unit. Proceedings of 1993 IEEE International Convference on Robotics and Automation, p. 267-274, 1993.
FUJITA, M.; KAGEYAMA, K. An open architecture for robot entertainment. D21 Lboratory,
Sony Corporation, 1997.
GERKEY B.; VAUGHAN R.; HOWARD A. The Player/Stage project: tools for multi-robot and
distributed sensor systems. Proceedings of the 11th International Conference on Advanced
Robotics, jun 2003.
HABIB, M. K. Bioinspiration and robotics: walking and climbing robots. I-Tech Education
and Publishing, p. 227-317 set 2007.
KALE, S.; SHRIRAMWAR, S. S. FPGA-base controller for a mobile robot. International Journal of Computer Science and Information Security, Vol. 3, No. 1, 2009.
KRAMER, J; SCHEUTZ, M. Development environments for autonomous mobile robots: a
survey. Autonomous Robots 22.2, p. 101-132, 2007.
MARTINS, N. A. Controle adaptativo e robusto de robs mveis com rodas. Florianpolis,
Universidade Federal de Santa Catarina, 2010.
MATARI, M. J. Interaction and intelligent behavior. Ph. D. Thesis - MIT, Mai 1994.
MATARI, M. J. The robotics primer. [S.l.]: MIT Press, 2007.
MEDEIROS, A. A. D. A survey of control architectures for autonomous mobile robots.
Journal of the Brazilian Computer Society, Vol. 4, No. 3, abr 1998.
MERTEN, M.; GROSS, H-M. Highly adaptable hardware architecture for scientific and industrial mobile robots. Proceedings of 2008 IEEE Conference on Robotics, Automation and
Mechatronics (RAM 2008), p. 1130-1135, 2008.
MEYER-DELIUS, D.; BEINHOFER, M.; KLEINER, A.; BURGARD, W. Using artificial landmarks
to reduce the ambiguity in the environment of a mobile robot. IEEE Conference on Robotics and Automation (ICRA 2011), p. 5173-5178, 2011.
109
MIGLIAVACCA, M.; BONARINI, A.; MATTEUCCI, M. RTCAN: A real-time CAN-bus protocol for
robotic applications. Proceedings of 10th International Conference on Informatics in Control,
Automation and Robotics (ICINCO 2013), 2013.
MOHAMED, N.; AL-JAROODI, J.; JAWHAR, I. Middleware for robotics: a survey. IEEE 2008.
MOK, S. M.; WU, C.-HAUR. Automation integration with UPnP modules. Third IEEE International Workshop on Electronic Design, Test and Applications, 2006.
MURPHY, R. Introduction to AI robotics. [S.l.] MIT Press, 2000.
NAMOSHE, M.; TLALE, N. S.; KUMILE, C. M.; BRIGHT, G. Open middleware for robotics, 15th
International Conference on Mechatronics and Machine Vision in Ptractice, dez 2008.
NEVES, M. C.; OLIVEIRA, E. A control architecture for an autonomous mobile robot. Proceedings of the First International Conference on Autonomous Agents, ACM, p. 193-200, fev
1997.
Object Management Group (OMG). The common object request broker: architecture and
specification, Revision 2.0, 1995.
PESSIN, G.; OSRIO, F. S.; UEYAMA, J.; WOLF, D. F.; BRAUN, T. Mobile robot indoor localization using artificial neural network and wireless networks. First Brazilian Conference on
Critical Embedded Systems (I CBSEC), p. 89-94, 2011.
QUIGLEY, M.; CONLEY, K.; GERKEY, B.; FAUST, J.; FOOTE, T.; LEIBS, J.; BERGER, E.; WHEELER,
R.; NG, A. ROS: an open-source robot operating system. ICRA workshop on open source software, Vol. 3, No. 3.2, mai 2009.
RAGHAVAN, A.; ANANTHAPADMANBAN, H.; SIVAMURUGAN, M.; RAVINDRAN, B. Accurate
mobile robot localization in indoor environments using bluetooth. IEEE International
Conference on Robotics and automation (ICRA), p. 4391-4396, mai 2010.
RODRIGUES, M. L.; VIEIRA, L. F. M.; CAMPOS, M. F. M. Mobile robot localization in indoor
environments using multiple wireless technologies. IEEE Brazilian Robotics Symposium
and Latin American Robotics Symposium (SBR-LARS), 2012.
ROSS, J. The book of wireless: a painless guide to Wi-Fi and broadband wireless. No Starch
Press, 2008.
SANTIAGO, G. S.; MEDEIROS, A. A. A proposed hardware and software architecture for a
robotic system. development 1: 2, 2011.
SARANLI U.; Avci, A.; O ztu rk, M.C. A modular real-time fieldbus architecture for mobile
robotic platforms. IEEE Transactions on Instrumentation and Measurement, Vol. 60, mar
2011.
110
SIEGWART, R.; NOURBAKHSH, I. R. Introduction to autonomous mobile robots. MIT Press,

2004.
SPONG, MARK. W.; HUTCHINSON, S.; VIDYASAGAR, M. Robot modeling and control. Wiley,
2005.
THUEER, T. Mobility evalutation of wheeled all-terrain robots. Robotics and Autonomous
Systems, 2009.
UTZ, H.; SABLATNG, S.; ENDERLE, S.; KRAETZSCHMAR, G. MIRO - middleware for mobile
robot applications. IEEE Transactions on Robotics and Automation, Vol. 18, No. 4, 2002.
VOLPE, R.; NESNAS, I.; ESTLIN, T.; MUTZ, D.; PETRAS, R.; DAS, H. The CLARAty architecture
for robotic autonomy. Proceedings of 2001 Conference in Aerospace Conference, Vol. 1, p1121, 2001.
VOLTAN, D. S.; BARBOSA, R. Z.; MARTINS, J. E. M. P.; ZIMBACK, C. R. L. Anlise da
distribuio espacial da temperatura do ar em uma casa de vegetao. II Simpsio de
Geoestatsitica Aplicada em Cincias Agrrias, mai 2011.
YAMAMOTO, Y.; YUN, X. Coordinating locomotion and manipulation of a mobile
manipulator. Automatic Control, IEEE Transactions on, Vol. 39, No. 6, p. 1326-1332, 1994.
YOO, J.; KIM, S.; HONG, S. The robot software communications architecture (RSCA): QoSaware middleware for networked service robots. SICE-ICASE Internation Joint Conference,
2006.
111
APNDICE A MODELO CINEMTICO DE UM ROB COM TRAO

DIFERENCIAL
O modelo cinemtico desenvolvido em coordenadas retangulares descreve as

caractersticas geomtricas do rob, e obtido a partir de estudos relacionados ao
deslocamento realizado por seus atuadores. A Figura 1 ilustra o modelo matemtico do
sistema de trao diferencial, conforme Martins (2010).
Figura 1 - Modelo matemtico de robs mveis que adotam trao diferencial.

Fonte: Adaptado de Martins (2010).
De acordo com a notao utilizada para ilustrar o modelo matemtico da Figura 1,

representa o sistema de coordenadas global ou inercial do rob, e representa
o sistema de coordenadas local do rob; o centro de massa do rob; o raio das rodas
ativas; a distncia entre as rodas e o eixo de simetria; e correspondem,
respectivamente, s velocidades angular e linear para a roda ; a velocidade linear do rob
e a velocidades angular do rob, tendo = (, )T ; e o vetor de coordenadas
generalizadas onde = [1 2 ]T . A posio do rob dada por ( , , ), na qual
e so as coordenadas de em e o ngulo de em relao a , onde ( , ) =
( , ).
112
Em termos cinemticos, o modelo e suas restries so discutidos por Siegwart e

Nourbakhsh (2004). A trao diferencial apresenta trs restries cinemticas (YAMAMOTO;
YUN, 1994), onde a primeira restringe sua movimentao apenas na direo normal ao eixo
das rodas ativas, como mostra a equao (3), e as outras duas restries dizem respeito
restrio de rolamento puro das rodas esquerda e direita, respectivamente, conforme as
equaes (4) e (5).
cos sen = 0
(3)
cos + sen + = 0
(4)
cos + sen + = 0
(5)
Uma vez que = cos + sen e que = , possvel obter as velocidades linear
e angular do centro de massa C do rob a partir das equaes (4) e (5), podendo assim,
ser descrito como:
1

] [ ]
[ ] = [
1

(6)
Uma outra forma de expressar o modelo cinemtico atravs das velocidades nos eixos do
plano e de rotao, ou seja, , e , resultando em:
= cos
= sen
=
113
(7)
Ainda possvel expressar em termos de coordenadas generalizadas , como mostra a

equao (8), ou seja:
= ()()
(8)
onde
cos() 0
() = [sen() 0]
0
1
(9)
De acordo com as especificaes do motor CC com caixa de reduo empregado, 127

rotaes equivalem a um giro completo da roda que est conectada aps a caixa de reduo.
Considerando apenas a rampa de subida da onda quadrada gerada pelo sensor de odometria,
so necessrios 127 pulsos para completar uma rotao completa da roda. Com isso,
possvel determinar o quanto o eixo do motor girou para um dado sentido, conforme mostra
a equao (10). Considerando o dimetro da roda empregada, de 8,89cm, cada transio
corresponde a:
= 2, = 4,445
360
(10)
(11)
= 2,8346
(12)
onde = 127 pulsos, logo
114
Proporcionalmente, possvel determinar o quanto cada roda deslocou o rob. Como o

deslocamento d da roda para uma volta completa dada por = 2, o deslocamento d de
27,928 cm a cada giro completo da roda.
E o erro mximo que cada roda apresentar a 2,8346 ser:
2,8346 27,928
= 0,2199
360
(13)
A velocidade nominal de operao da sada do motor CC utilizado, aps sua caixa de

reduo, de 80rpm. Atravs da Equao (14) obtm-se sua velocidade angular de 1,33 rad/s.
Com isso, possvel determinar a velocidade linear mxima de deslocamento do rob,
de 34,91cm/s, obtida por meio da equao (15).
75
= 1,33 /
60
1,33 27,928
= 37,144 /
1
(14)
(15)
Esta de 37,144cm/s corresponde velocidade plena do rob mvel. Nela so

desconsideradas as perdas e variaes, como as atribudas carga ou resistncia mecnica
sobre o motor CC, ou o rob locomovendo-se em superfcies irregulares ou inclinadas, assim
como outros fatores como patinao e deformaes da roda.
115
APNDICE B CONTROLADOR DE ROBS MVEIS
A plataforma de rob mvel proposta opera sobre uma arquitetura cuja funo atuar
como um agente de interface entre o sistema de controle e a camada de hardware do rob
mvel. Essa interface estabelecida atravs de uma conexo serial, cuja programao
facilitada por uma API escrita em linguagem C++.
A princpio, o hardware da plataforma foi desenvolvido e implementado de modo a
oferecer recursos, como atuadores e sensores, para prover suporte s funcionalidades
essenciais relacionadas mobilidade e navegao, tais como sistema de tracionamento e
sensores de proximidade, sensores de solo, odometria e sonar. Essa configurao inicial
suficiente para prover condies da plataforma em ensaiar experimentos fundamentais de
robtica, e ainda, apresentar flexibilidade de modo a permitir alteraes de hardware. Para
tornar tais recursos funcionais, uma API implementada em C++ responsvel tanto pela
comunicao de dados, como pela abstrao dos comandos, e tanto de leitura dos sensores
como de atuao. O tipo de interface de comunicao escolhido foi o tipo serial, pois o padro
de comunicao serial RS-232, apesar de suas limitaes, pode facilmente ser implementado
ou adaptado em vista da sua simplicidade.
O microcontrolador
Como mencionado em 3.4.2, para o desenvolvimento do hardware do controlador,

optou-se por empregar o microcontrolador PIC18F4550 da Microchip. A opo por este
componente em particular se deu devido a alguns fatores, como seu enquadramento ao
escopo do projeto, baixo custo, facilidade de aquisio no mercado brasileiro e, ainda, por
oferecer diversos dispositivos de entrada e sada, dentre os quais se destacam:
- Um conversor analgico-digital (ADC) de 13 canais e 10 bits de resoluo;
- At trinta e seis linhas de entrada e sada digitais reconfigurveis;
116
- Quatro temporizadores, um de 8 bits e trs de 16 bits;

- Suporte aos barramentos USB, I2C, Master Synchronous Serial Port (MSSP) e SPI;
- Dois mdulos de Modulao por Largura de Pulso (PWM).
Alm das caractersticas mencionadas, outros fatores influenciaram de forma decisiva
na escolha deste microcontrolador. Em primeiro lugar, a familiaridade com o
desenvolvimento do software embarcado com microcontroladores da famlia PIC da
Microchip. Em segundo lugar, a disposio imediata destes componentes para o uso no
laboratrio onde o trabalho de desenvolvimento foi realizado LISDI (Laboratrio de
Integrao de Sistemas e Dispositivos Inteligentes). Por ltimo, o laboratrio dispunha de
materiais e dispositivos necessrios para a gravao dos firmwares e manuseio destes
microcontroladores.
Desenvolvimento do circuito
A partir dos recursos oferecidos pelo microcontrolador empregado, foram selecionados

os perifricos necessrios para que o controlador oferecesse suporte aos diferentes tipos de
sensores e atuadores, e ainda possibilitar a comunicao com o sistema de controle. Assim, o
circuito desenvolvido oferece suporte aos seguintes perifricos:
- Oito entradas para converso analgico-digital com resoluo de 10 bits (ADC0ADC7);
- Oito canais de dados digitais reconfigurveis (DADOS0-DADOS7);
- Quatro canais de sada de dados digitais (CONTROLE0-CONTROLE3);
- Dois mdulos de PWMs (PWM0-PWM1);
- Quatro mdulos para servomotores (SERVO0-SERVO3);
117
- Trs contadores digitais de 16 bits (CONTADOR0-CONTADOR2);

A gerao dos pulsos de clock para o PIC 18F4550 feita a partir de um cristal de 20MHz,
que o transforma em 48MHz por meio de um circuito PLL (Phase-Locked Loop). Desta forma,
o microcontrolador capaz de operar a 12MIPs.
De modo a permitir a gravao do firmware do microcontrolador, foi implementada a
funcionalidade ICSP no circuito. O ICSP (acrnimo de In Circuit Serial Programming) permite
que operaes de leitura e gravao do microcontrolador sejam realizadas sem a necessidade
de desmontar o rob mvel Kihon, e sem remover o microcontrolador da placa de circuito.
Desta forma, uma interface ICSP foi disposta na lateral do rob mvel Kihon, permitindo fcil
acesso s operaes de leitura e gravao do PIC utilizado. Para tal, basta conectar qualquer
dispositivo gravador, programador e depurador, como o Pickit 2 ou o Pickit 3 da
Microchip. O diagrama do circuito eltrico ilustrado na Figura 1 .
118
Figura 1 - Diagrama do circuito eltrico do Controlador da plataforma de rob mvel.

119
Firmware do controlador
Com o circuito definido, foi dado incio ao desenvolvimento do firmware. A linguagem

de programao escolhida foi o C, uma vez que a maior parte dos compiladores C possuem
bibliotecas consolidadas que permitem a utilizao do porto serial. Optou-se pela utilizao
do compilador C18 da Microchip, j empregado pelo laboratrio LISDI no desenvolvimento
de outros trabalhos e atividades.
Por meio da implementao do recurso ICSP (acrnimo do termo em ingls: In Circuit
Serial Programming), permitiu-se a possibilidade de gravao sem a necessidade de
desmonte do Kihon e remoo do microcontrolador da placa de circuito. O ICSP permite que
o firmware do Controlador possa ser lido, escrito ou reescrito de forma fcil e descomplicada,
uma vez que se disponha do dispositivo de gravao que suporte a famlia de
microcontroladores PIC18 da Microchip, na qual est incluso o PIC18F4550. A Figura 2
ilustra a interface de conexo ao ICSP do microcontrolador PIC no Kihon.
Figura 2 Conector ICSP no Kihon.

120
APNDICE C PROTOCOLO DE COMUNICAO
Esta seo apresenta os detalhes da comunicao de dados, ou seja, como feita a

estruturao dos dados na arquitetura cliente-servidor concebida, representados
respectivamente pelo Controlador e pelo Sistema de Controle. A viso geral do protocolo de
comunicao apresentado em 3.4.3. A seguir sero detalhados cada um dos elementos.
Leituras das entradas ADC
Ao receber uma requisio de leitura dos conversores analgico-digital, o PIC efetua a

aquisio dos 8 primeiros canais (AN0-AN7) e os serializa para retornar ao Sistema de
controle. Ainda que fosse possvel solicitar a leitura de apenas um canal, optou se apenas por
realizar a leitura de todos os canais utilizados por uma questo de otimizao de tempo.
Desconsiderando a taxa de comunicao, uma srie de requisies enviadas pelo Sistema de
Controle, de modo a obter as leituras de cada canal analgico-digital individualmente,
demandaria 5 bytes para concluir a comunicao, dos quais seriam 3 bytes para a requisio
e 2 bytes para a resposta ao Sistema de Controle, que multiplicada pelos 8 canais, totalizaria
40 bytes. Por outro lado, utilizando uma nica requisio para obter a leitura de todos os 8
canais analgico-digitais, seriam necessrios apenas 19 bytes, dos quais seriam 3 bytes da
requisio e 16 bytes de resposta ao Sistema de Controle.
O comando de requisio de leitura utiliza apenas o byte identificador, que contm o
valor 0 ASCII. A resposta enviada pelo Controlador tem 16 bytes de comprimento, dos quais
cada dupla de bytes corresponde leitura de um dos canais. O comando de requisio e a
resposta so mostrados na Tabela 1 e Tabela 2 abaixo.
121
Tabela 1 Organizao dos bytes da requisio de leitura dos canais ADC.

Byte
0
Descrio
Cdigo ASCII 0
Tabela 2 Organizao dos bytes da resposta da leitura dos canais ADC.

Byte
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Descrio
Canal AN0: byte mais significativo
Canal AN0: byte menos significativo
Foi implementado em hardware um circuito para medir o nvel de tenso da bateria

obtidos pela conexo serial de 2 baterias de 6V empregadas para alimentar toda a plataforma
de rob mvel. O circuito divisor de tenso foi obtido por meio de uma associao simples de
resistores, pode ser observado no diagrama eltrico do Controlador (Figura 1 do Apndice
B), cuja sada conectada entrada do canal AN0 do conversor analgico-digital do PIC.
Assim, cada vez que uma requisio de leitura dos canais ADC recebida pelo Controlador,
os bytes de resposta 0 e 1 correspondentes s leituras do Canal 0, sempre retornaro o nvel
de tenso da alimentao da plataforma de rob mvel.
122
Leitura dos contadores
Ao receber uma requisio para leitura dos contadores, o Controlador serializa o valor
dos trs contadores e, aps o envio, reinicia todos os contadores. Assim como descrito
anteriormente, a leitura unificada dos contadores foi preferida em relao leitura isolada
para obter melhor proveito da comunicao serial.
O comando de requisio de leitura utiliza apenas o byte identificador, que contm o
valor 1 ASCII. A resposta enviada pelo Controlador possui 6 bytes de comprimento, onde cada
dupla de bytes corresponde ao valor de cada um dos contadores. O comando de requisio e
a resposta so mostrados, respectivamente, na Tabela 3 e Tabela 4.
Tabela 3 Organizao dos bytes da requisio de leitura dos contador.
Byte
0
Descrio
Cdigo ASCII 1

Byte
0
1
2
3
Descrio
Contador 0: byte mais significativo
Contador 0: byte menos significativo
Medio do Sonar
Ao receber uma requisio de medio do Sonar, o Controlador retorna como resposta

2 bytes contendo a medio do Sonar. O comando de requisio e resposta mostrado na
Tabela 5 e Tabela 6.
123
Tabela 5 Organizao dos bytes da requisio de leitura dos contador.

Byte
0
Descrio
Cdigo ASCII 2

Byte
0
1
Descrio
O clculo necessrio de converso do valor numrico obtido para metros

apresentado na Equao 1.
1
1
4 8 1 340
48
2
(1)
onde:
corresponde distncia em metros;
1 corresponde quantidade de interrupes contabilizadas.
A utilizao do Sonar est associada ao Servo 0, uma vez que o direcionamento do
Sonar obtido atravs do posicionamento do eixo do Servo motor 0.
Configurao da frequncia PWM
A frequncia de operao dos PWMs do PIC18F4550 gerada pelo temporizador

Timer2. O Timer2 pode ser modificada alterando-se os valores dos registradores PR2 e TCON.
O registrador PR2 armazena o perodo de contagem do Timer2, podendo variar no intervalo
124
de 0 a 255. J o registrador TCON armazena o valor de prescaler do Timer2. O prescaler

uma forma de reduzir a frequncia de clock dos temporizadores do PIC, possibilitando que
os temporizadores sejam capazes de aguardar intervalos de tempo mais longos.
O clculo da frequncia apresentado na Equao 2.
1
((2) + 1) 4 (2 )
(2)
onde
corresponde frequncia de operao do PWM
= (48 106 )1 ; 0 2 255, 2 ; 2 {1,4,16}
Considerando que a frequncia de clock do PIC18F4550 utilizado 48MHz
(resultando em um perodo aproximado de =20,83ns), as frequncias mnimas e
mximas dos mdulos de PWM so de, respectivamente 2929,6875MHz e 12MHz. No entanto,
quanto maior a frequncia, menor ser a resoluo do ciclo de trabalho dos PWMs, de modo
que a frequncia de 12MHz, ainda que possvel, no apresentar resultados satisfatrios.
O comando de configurao da frequncia dos PWMs passa ao Controlador como
parmetros o valor do perodo do temporizador Timer2, e o valor de prescale. A organizao
dos bytes mostrada na Tabela 7. O controlador no envia nenhum byte de resposta para
este comando.
Tabela 7 Organizao dos bytes da requisio de configurao dos PWMs.
Byte
0
1
2
Descrio
Cdigo ASCII 3
Byte que ser copiado para registrador PR2
Bits 7-2
No usados
Bits 1-0
TCON bits: T2CKPS1 e T2CKPS0
125
Configurao dos ciclos PWM
Os ciclos de trabalhos PWM0 e PWM1 podem ser alterados atravs da escrita nos
registradores CCPR1L e CCP1CON para o PWM1, e CPPR2L e CCP2CON para o PWM2. A
resoluo em bits dos PWMs varia de acordo com a frequncia e dada pela Equao 3. J o
clculo do ciclo de trabalho dos PWMs dado pela Equao 4.
() =
log( )
log(2)
= (: < 5: 4 >) (2 )
(3)
(4)
O comando de configurao do ciclo de trabalho do PWM envia ao firmware uma nica

requisio, passando como parmetro 3 bytes, dispostos de modo a conter 2 sequncias de
10 bits uma sequncia para o PWM0 e uma sequncia para o PWM1. A organizao dos
bytes mostrada na Tabela 8.
Tabela 8 Organizao dos bytes da requisio de configurao dos ciclos PWMs.
Byte
0
1
2
3
Bits 7-4
Bits 3-0
Bits 7-2
Bits 1-0
Bits 7-0
Descrio
Cdigo ASCII 4
No usados
4 Bits mais significativos do PWM0
6 Bits menos significativos do PWM0
2 Bits mais significativos do PWM1
8 Bits menos significativos do PWM1
126
Configurao de controle PWM
O controle de estado dos PWM pode ser configurado atravs de uma requisio de
escrita nas portas digitais que foram destinadas a essa funo. O controle PWM nada mais
que uma requisio de escrita direta sobre o estado de sada lgica de 4 portas digitais.
Quando relacionada ao PWM, esta requisio tem como objetivo determinar o sentido de
rotao dos PWM0 e PWM1.
O comando de configurao do controle PWM permite que o PWM0 e PWM0 possuam
individualmente 4 estados: bloqueio, parado, para frente e para trs. Assim, o nico
parmetro passado a essa requisio um byte, dentre os quais foram destinados os quatro
bits menos significativos para definir tais estados, dos quais os bits 3 e 2, correspondem aos
estados do PWM0, e os bits 1 e 0 correspondem aos estados do PWM1. A organizao dos
bytes mostrada na Tabela 9. O controlador no envia nenhum byte de resposta para este
comando.
Tabela 9 Organizao dos bytes da requisio de configurao de Controle PWM.
Byte
0
1
Bits 7-4
Bits 3-2
Bits 1-0
Descrio
Cdigo ASCII 5
No usados
Estado do PWM0
Estado do PWM1
Configurao do tempo dos servomotores
O PIC18F4550 no possui nenhum mdulo de hardware que suporte o controle de

servomotores. Para que o Controlador fosse capaz de oferecer tal suporte, foi necessrio
escrever rotinas prprias de gerao de sinais de controle. Essas rotinas permitem gerar
127
pulsos no intervalo de 920us a 2120us com resoluo de 333,33 ns. Para isso, as rotinas
fazem uso do temporizador Timer0, de 16 bits de resoluo do PIC.
O comando de configurao do servomotor indica qual servo ser alterado e qual sua
nova constante de tempo (com 16 bits). Ao receb-lo, o Controlador atualiza as constantes de
tempo para o servomotor especificado. A descrio deste comando mostrada na Tabela 10.
O controlador no envia nenhum byte de resposta para este comando.
Tabela 10 Organizao dos bytes da requisio dos servo motores.
Byte
0
1
2
Descrio
Cdigo ASCII 6 para o Servo motor 0
Byte mais significativo da nova constante de tempo
Byte menos significativo da nova constante de tempo
Configurao I/O digital
O comando de configurao das portas de entrada e sada digitais permite que se

altere a direo do das portas digitais, ou seja, que se alterne a funo das portas entre sada
e entrada. Ao todo, so 8 canais de dados digitais bidirecionais. O comando de requisio de
configurao I/O digital envia ao firmware passando como parmetro um byte no qual cada
bit corresponde configurao da respectiva porta digital sendo o bit com nvel lgico 0 para
sada e o bit com nvel lgico 1 para entrada. A organizao dos bytes deste comando
mostrada na Tabela 11. O controlador no envia nenhum byte de resposta para este comando.
128
Tabela 11 Organizao dos bytes da requisio de configurao I/O das Portas Digitais.
Byte
0
1
Bit 7
Bit 6
Bit 5
Bit 4
Bit 3
Bit 2
Bit 1
Bit 0
Descrio
Cdigo ASCII 10
Direo da Porta Digital 7
Leitura I/O digital
As portas I/O digitais cujas configuraes de direo foram definidas como entrada
podero ter seus nveis binrios de estados lgicos (0 ou 1) lidos atravs do comando de
requisio de leitura I/O Digital. Ainda que a direo de uma dada porta digital esteja
configurada como sada, a requisio de leitura I/O Digital retornar o ltimo valor lgico
escrito na respectiva porta digital. Ao receber o comando de leitura I/O Digital, o Controlador
serializa e envia ao Sistema de Controle o estado atual presente de todos os canais digitais
em seu respectivo bit.
O comando de leitura I/O Digital e a respectiva resposta so mostradas na Tabela 12
e Tabela 13, respectivamente.
Tabela 12 Organizao dos bytes da requisio de Leitura I/O Digital.
Byte
0
Descrio
Cdigo ASCII 11
129
Tabela 13 Organizao dos bytes da resposta da requisio de Leitura I/O Digital.

Byte
0
Bit 7
Bit 6
Bit 5
Bit 4
Bit 3
Bit 2
Bit 1
Bit 0
Descrio
Estado lgico da Porta Digital 7
Escrita I/O digital
As portas I/O digitais cujas configuraes de direo foram definidas como sada
podero ter seus nveis binrios de estados lgicos (0 ou 1) alterados atravs do comando de
requisio de escrita I/O Digital. O comando de escrita I/O Digital envia como parmetro um
byte contendo os novos estados lgicos binrios, cada um em sua respectiva posio no byte.
Ao receber uma requisio de escrita I/O Digital, o Controlador escreve na respectiva porta
digital seu novo valor binrio recebido. Se a direo de uma dada porta digital estiver
configurada como entrada, o respectivo bit de escrita no ter efeito de escrita sobre o estado
lgico da porta digital de entrada, mantendo inalterado o seu estado lgico.
O comando de escrita mostrado na Tabela 14. O controlador no envia nenhum byte
de resposta para este comando.
130
Tabela 14 Organizao dos bytes da requisio de Escrita I/O Digital.

Byte
0
1
Bit 7
Bit 6
Bit 5
Bit 4
Bit 3
Bit 2
Bit 1
Bit 0
Descrio
Cdigo ASCII 12
Novo valor lgico da Porta Digital 7
131

Desenvolvimento de Uma Plataforma Aberta de Robô Móvel para Propósitos Gerais

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Desenvolvimento de Uma Plataforma Aberta de Robô Móvel para Propósitos Gerais

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE ESTADUAL PAULISTA JLIO DE MESQUITA FILHO

INSTITUTO DE BIOCINCIAS, LETRAS E CINCIAS EXATAS

Desenvolvimento de uma plataforma aberta de rob mvel para propsitos

So Jos do Rio Preto

Desenvolvimento de uma plataforma aberta de rob mvel para propsitos

So Jos do Rio Preto

Desenvolvimento de uma plataforma aberta de rob mvel para propsitos

Prof. Dr. Teodiano Freire Bastos Filho

Prof. Dr. Joo Eduardo Machado Perea Martins

"The machine does not isolate man

em Cincia da Computao, que por meio de suas estruturas, possibilitaram o

Palavras-Chave: Arquitetura Aberta. Plataforma de Rob Mvel. Rob Mvel. Interface

Keywords: Open Architecture. Mobile Robot Plataform. Mobile Robot. Communication

LISTA DE ABREVIATURAS E SIGLAS

Application Programming Interface (Interface de Programao de

Controller Area Network (Controlador de Rede de rea)

Common Object Request Broker Architecture (Intermedirio Comum para

Complementary Metal-Oxide-Semiconductor (Semicondutor Metal-xido

Defense Advanced Research Projects Agency (Agncia de Projetos de

Degree of Freedom (Grau de Liberdade)

Foreign Function Interface (Interface de Funes Estrangeiras)

Global Positioning System (Sistema de Posicionamento Global)

Institute of Electrical and Electronics Engineers (Instituto de Engenheiros

Inter-Integrated Circuit (Circuito Inter-Integrado)

Laboratrio de Automao e Computao Evolutiva

Laboratrio de Integrao de Sistemas e Dispositivos Inteligentes

Mobile and Autonomous Robotics Integration Environment (Ambiente de

Middleware for Mobile Robots (Middleware para Robs Mveis)

National Aeronautics and Space Administration (Administrao Nacional

Personal Computer (Computador Pessoal)

Python Robotics (Python Robtico)

Pulse Width Modulation (Modulao por Largura de Pulso)

Robot Development Environment (Ambiente de Desenvolvimento de

Robotic Industries Association (Associao das Indstrias Robticas)

Comunicao de Software Robtico)

Robot Operating System (Sistema Operacional para Robs)

Radio Frequency (Rdio Frequncia)

Robot Technology (Tecnologia Robtica)

Real Time CAN (CAN de Tempo Real)

Real-Time CORBA (CORBA de Tempo Real)

Sound Navigation and Ranging (Navegao e Determinao da Distncia

Serial Peripheral Interface (Interface de Perifrico Serial)

Transmission Control Protocol (Protocolo de Controle de Transmisso)

Transistor-Transistor Logic (Lgica Transistor-Transistor)

Universal Plug-and-Play (Plug-and Play Universal)

(Barramento Serial Universal)

Centro geomtrico do rob

Sistema de coordenadas local do rob

Sistema de coordenadas de referncia

Sistema de coordenadas global ou inercial

Ponto de interseo entre o eixo de simetria e o eixo das rodas

Vetor de coordenadas generalizadas

Vetor das velocidades em coordenadas generalizadas

Raio das rodas

Distncia entre as rodas e o eixo de simetria

Matriz jacobiana ou modelo cinemtico

Velocidade linear mxima

Posio no eixo das abscissas

Velocidade do rob mvel no eixo das abcissas do plano

Posio no eixo das ordenadas

Velocidade do rob mvel no eixo das ordenadas do plano

ngulo do rob em relao ao eixo das abscissas

ngulo da roda do rob