Você está na página 1de 74

UNIVERSIDADE FEDERAL DE SANTA CATARINA

TECNOLOGIAS DA INFORMAO E COMUNICAO


STFANI ANTONELLI GOERCK DE FREITAS
DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE EMBARCADO PARA A
EQUIPE DE FUTEBOL DE ROBS ARARANGU INTRUDERS
Ararangu, 22 de fevereiro de 2013
STFANI ANTONELLI GOERCK DE FREITAS
DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE EMBARCADO PARA A EQUIPE DE FUTEBOL
DE ROBS ARARANGU INTRUDERS
Trabalho de Curso submetido Universidade
Federal de Santa Catarina como parte dos
requisitos necessrios para a obteno do Grau
de Bacharel em Tecnologias da Informao e
Comunicao. Sob a orientao do Professor
Anderson Luiz Fernandes Perez.
Ararangu, 2013
Stfani Antonelli Goerck de Freitas
Desenvolvimento de um Sistema de Controle Embarcado para a Equipe de Futebol de
Robs Ararangu Intruders
Trabalho de Curso submetido Universidade
Federal de Santa Catarina, como parte dos
requisitos necessrios para a obteno do Grau
de Bacharel em Tecnologias da Informao e
Comunicao.




Ararangu, 22 de fevereiro de 2013
4

Dedico este trabalho ao meu esposo
Lucas, aos meus pais Julsemar e Jussara, e a
minha irm Natasha.
5

AGRADECIMENTOS
Agradeo a Deus pela vida, salvao e fora as
quais me entregou todos os dias sem nenhum mere-
cimento, simplesmente pelo seu infindvel amor.
meu esposo por tanto carinho, compreenso e com-
panheirismo os quais ofereceu por todo essa cami-
nhada de estudos. meus pais pela base incorrupt-
vel que formaram em mim, pela presena e pelo
apoio. minha irm pela amizade e pacincia.
minha v pelo cuidado incondicional. Universida-
de Federal de Santa Catarina. Ao meu orientador
por conduzir todo esse projeto com pacincia e de-
dicao. Aos meus colegas do LARM, especialmente
ao Marcelo. Aos professores da banca pelas contri-
buies.
6

Em Cristo os coraes podem ser enriquecidos
da plenitude da inteligncia porque Nele esto
escondidos todos os tesouros da sabedoria e
da cincia.
Colossenses 2.2-3;
7

RESUMO
Este trabalho descreve o desenvolvimento de um sistema de controle embarcado para a equipe
de futebol de robs Ararangu Intruders. O futebol de robs possui vrias categorias e uma
delas a F180. A sistemtica do jogo baseada em robs, que esto em campo, e um compu-
tador externo que envia os comandos que devem ser executados por cada rob. Nesse caso os
robs so jogadores passivos, tendo o papel apenas de agir de acordo com a ao que lhe foi
enviada. Este projeto visa fazer com que os robs tenham um comportamento mais inteligen-
te, fazendo com que estes sejam agentes ativos dentro de campo, participando intensamente
do jogo. Para isso foi necessrio o desenvolvimento de um sistema embarcado que levasse em
considerao no apenas informaes vindas do computador tcnico, mas tambm de sensores
embarcados nos robs que os ajudassem na percepo do ambiente. Esse sistema usou tcni-
cas de interrupo e de tempo real. O sistema desenvolvido permite que o rob execute aes,
baseadas em dados recebidos do computador tcnico e do seu prprio sistema em resposta s
ativaes dos sensores. O sistema embarcado foi projetado com dois nveis de controle, as
tarefas de tempo real esto no primeiro nvel formando uma arquitetura hierrquica, enquanto
os sensores e o controle dos atuadores esto no segundo nvel de controle, formando uma ar-
quitetura reativa. O sistema embarcado foi testado e validado e os resultados demonstram que
o nmero de troca de mensagens entre o computador tcnico e o rob diminui, assim tem-se
mais tempo computacional para o processamento da estratgia, tornando a equipe mais com-
petitiva.

Palavras-chave: futebol de robs, sistema embarcado, robtica mvel, categoria F180, micro-
controlador PIC.
8

ABSTRACT
This work describes the development of an embedded control system for the Ararangu In-
truders robot soccer team. The robot soccer has several categories and one of them is the
F180. The game is based on robots, which are in the field and an external computer that sends
the commands to be executed by each robot. In this case robots are passive players acting on-
ly in accordance with the received command. This project aims to make the robots to behave
more intelligent, making them to be active agents in the field, participating intensely game.
For this reason an embedded system was developed that takes not only information from the
computer coach, but also from sensors embodied in the robot that would help the perception
of the environment. The developed system is based on two methodologies, real-time tasks and
interrupts. The system allows that robot perform actions, based on data received from the
computer coach and data coming from their own system in response to activations of the sen-
sors. The embedded system is designed with two levels of control, real time tasks are the first
level of control, forming a hierarchical architecture, while the sensors and control actuators
are on the second level of control, forming a reactive architecture. The embedded system has
been tested and validated, the results, prove that the number of message exchange between the
computer and the robot is less than classical architectures, so it has more computational time
to strategy processing, doing the team more competitive.

Keywords: robot soccer, embedded systems, mobile robots, F180 category, PIC microcontrol-
ler.
9

LISTA DE ILUSTRAES
Figura 1: Representao de um agente. ...................................................................... 20
Figura 2: Arquitetura deliberativa. ............................................................................. 21
Figura 3: Arquitetura reativa. ..................................................................................... 21
Figura 4: Arquitetura hbrida. ..................................................................................... 22
Figura 5: Estrutura de um jogo da categoria F180. .................................................... 25
Figura 6: Dimenses mximas dos robs. .................................................................. 26
Figura 7: Padro para a identificao dos robs da categoria F180. .......................... 26
Figura 8: Esquemtico da categoria F180. ................................................................. 27
Figura 9: Fluxo de informao. .................................................................................. 28
Figura 10: Movimentos bsicos de cada rob. ........................................................... 30
Figura 11: Rob da equipe Ararangu Intruders utilizado na competio de 2011. .. 32
Figura 12: Influncia de Sistemas Embarcados sobre a Computao Ubqua. .......... 37
Figura 13: Fluxo de um Projeto de Sistema Embarcado. ........................................... 39
Figura 14: Desenvolvimento de Projeto em Nveis.................................................... 40
Figura 15: Intermediao feita pelo Sistema Embarcado entre Ambiente Virtual e
Real. .......................................................................................................................................... 42
Figura 16: Sistema Conectado a Sensores e Atuadores. ............................................ 43
Figura 17: Grfico de Utilidade de Tarefas mediante Prazo. ..................................... 47
10

Figura 18: Arquitetura de hardware dos robs da equipe Intruders. .......................... 50
Figura 19: Vista expandida do controle dos motores. ................................................ 52
Figura 20: Arquitetura de Software dos robs da equipe Ararangu Intruders. ......... 53
Figura 21: Esquemtico da simulao do controle de Nvel 1. .................................. 58
Figura 22: Funo de Simulao do Rdio e Comunicao SPI. ............................... 59
Figura 23: Esquemtico da simulao do controle de Nvel 2. .................................. 60
Figura 24: Esquema de posicionamento das rodas e motores no rob. ...................... 61
Figura 25: Funes de Controle. ................................................................................ 63
Figura 26: Tratamento das Interrupes. .................................................................... 64
Figura 27: Esquemtico do programa de exemplo. .................................................... 71
Figura 28: Programa para aceder trs LEDs sem o uso de funes de tempo real. ... 72
Figura 29: Programa para aceder trs LEDs com o uso de funes de tempo real. ... 73

11

LISTA DE TABELAS
Tabela 1: Linguagens de programao utilizadas em sistemas embarcados. Dados de
2006. ......................................................................................................................................... 35
Tabela 2: Sistemas embarcados e sua utilizao em cada mercado. .......................... 36
Tabela 3: Caractersticas das Tarefas de Tempo Real do Sistema Embarcado. ......... 57
Tabela 4: Relao de cores dos LEDS com direo dos motores presentes na
simulao. ................................................................................................................................. 62


12

LISTA DE ABREVIATURAS E SIGLAS
CPU Central Processing Unit
CCS Custom Computer Services
FIRA Federation of International Robot-Soccer Association
GPS Global Position Systems
IBM International Business Machines
LED Light Emitting Diode
PIC Peripheral Interface Controller
PID Proporcional Integral Derivativo
PWM Pulse Width Modulation
RTOS Real Time Operation System
SPI Serial Peripheral Interface
SSL Small Size League
TCC Trabalho de Concluso de Curso
UFSC Universidade Federal de Santa Catarina
VSS Very Small Size


13

SUMRIO
1 INTRODUO ..................................................................................................... 14
1.1. Objetivos .................................................................................................................... 15
1.1.1. Geral ....................................................................................................................... 15
1.1.2. Especficos .............................................................................................................. 15
1.2. Metodologia ................................................................................................................ 15
1.3. Justificativa e Motivao ............................................................................................. 16
1.4. Organizao do Trabalho ........................................................................................... 17
2 Futebol de Robs ............................................................................................... 19
2.1. Sistemas Robticos .................................................................................................... 19
2.2. Arquiteturas de Software ............................................................................................ 20
2.3. Robs Mveis ............................................................................................................ 22
2.4. Futebol de Robs ....................................................................................................... 23
2.5. Categoria F180........................................................................................................... 25
2.6. Equipe Ararangu Intruders ........................................................................................ 30
3 Sistemas Embarcados ....................................................................................... 33
3.1. Definio de Sistemas Embarcados ........................................................................... 33
3.2. Metodologia de Desenvolvimento ............................................................................... 39
3.3. Sistemas Embarcados e Sistemas de Tempo Real .................................................... 44
4 Sistema de controle embarcado para o futebol de robs .............................. 49
4.1 Arquitetura de Hardware dos Robs da Equipe Ararangu Intruders .......................... 49
4.2 Arquitetura de Software dos Robs da Equipe Ararangu Intruders ............................ 52
5 Anlise do Sistema de Controle ....................................................................... 57
5.1. Controle de Nvel 1 ..................................................................................................... 57
5.2. Controle de Nvel 2 ..................................................................................................... 60
6 CONSIDERAES FINAIS E PROPOSTAS PARA TRABALHOS FUTUROS .. 65
6.1. Propostas para Trabalhos Futuros .............................................................................. 66
REFERNCIAS ......................................................................................................... 67
Apndice I ................................................................................................................ 70

14

1 INTRODUO
O desenvolvimento da tecnologia tem sido apresentado para a sociedade de diversas
maneiras e tem se tornando real na vida cotidiana. O uso de robtica tem se popularizado
muito, os robs falam, cantam, danam e at tm a aparncia dos seres humanos. Entretanto,
existe uma tecnologia que ainda mais presente, e que se difunde de maneira discreta, so os
sistemas embarcados. Estes j fazem parte do cotidiano das pessoas, em muitos casos, de mo-
do imperceptvel. Por crescerem e se difundirem em grande nmero os sistemas embarcados
so um campo da tecnologia que merece a devida ateno.
O uso de sistemas embarcados percorre todas as reas de domnio humano, em ativi-
dades simples ou complexas eles tm se apresentado eficientes e importantes, e assim seu
desenvolvimento comea a ser mais valorizado e estudado. Os sistemas embarcados tm a
capacidade de tornar um equipamento simples na casa de algum um aparelho tecnolgico
que ir realizar a tarefa desejada com ainda mais eficincia.
Os sistemas embarcados relacionam-se fortemente com a robtica mvel e com a in-
teligncia artificial. Vrias entidades criam cenrios que so tidos como problemas primrios
a serem estudados, sendo um destes cenrios o futebol de robs. Este ambiente foi escolhido
por lidar com os mais diversos tipos de conhecimento e por contar com uma grande abran-
gncia de informaes, um ambiente desafiador j que todo este escopo deve ser dominado
para formar uma equipe adequada e competitiva (ROBOCUP, 1998).
No futebol de robs existem conceitos que vo desde o projeto e a construo do
hardware at o projeto e o desenvolvimento do software, e um ponto que une esses dois ex-
tremos so os sistemas embarcados, um software que integrado ao hardware e que usa todos
os seus recursos para a realizao de uma tarefa. Por isso a robtica mvel, com o foco no
futebol de robs, uma prtica de estudo difundida por todo o mundo, existem muitas inova-
es que so desenvolvidas nestastas competies. Um desafio dentro da categoria F180 do
15

Futebol de Robs tornar os robs, normalmente passivos, agentes ativos em campo. Isso
pode ser possvel atravs do desenvolvimento de um novo sistema de controle embarcado
para os robs. Dotar o rob de algum grau de inteligncia seria interessante j que aumentaria
a competitividade da equipe, equilibrando adequadamente responsabilidades entre os robs e
o computador tcnico.
1.1. Objetivos
Para um melhor entendimento dos objetivos deste trabalho, esta seo est separada
em objetivo geral e objetivos especficos.
1.1.1. Geral
Desenvolver um sistema de controle embarcado para a equipe de futebol de robs
Ararangu Intruders que permita que os robs sejam agentes ativos em campo, tornando a
equipe mais competitiva.
1.1.2. Especficos
1. Estudar o estado da arte no desenvolvimento de sistemas embarcados, sobretudo aque-
les aplicados ao futebol de robs;
2. Estudar microcontroladores e linguagens de programao para sistemas microcontro-
lados;
3. Especificar um sistema de controle embarcado para a equipe de futebol de robs Ara-
rangu Intruders que considere, alm das informaes provenientes do computador
tcnico, informaes internas aos robs;
4. Projetar um sistema embarcado que seja de tempo real e que atenda os requisitos defi-
nidos em (3);
5. Desenvolver o sistema embarcado projetado em (4);
6. Testar o sistema desenvolvido em (5) e avaliar os resultados obtidos.
1.2. Metodologia
O sistema ser desenvolvido na linguagem de programao C, com o compilador
CCS (Servios Personalizados de Computador, do Ingls Custom Computer Services) para a
16

famlia de microcontroladores PIC18F que atualmente utilizada pelos robs da equipe Ara-
rangu Intruders.
O ambiente utilizado para testar o sistema embarcado e simular os circuitos eletrnicos
dos robs da equipe Intruders foi o simulador de circuitos Proteus na interface ISIS. Nele todo
o circuito eletrnico foi desenvolvido e todos os testes foram realizados. Para o desenvolvi-
mento do software foi utilizado o PCW, um ambiente de desenvolvimento integrado da CCS
para microcontroladores PIC (Interface Perifrica de Controle, do Ingls Peripheral Interface
Controller).
1.3. Justificativa e Motivao
O futebol de robs possui uma organizao muito grande, existem diversas categori-
as e cada uma conta com algumas particularidades. Uma categoria muito conhecida a Small
Size ou F180 da Robocup, a estrutura desta categoria baseada em um campo em que ficam
cinco robs de cada time, acima do campo ficam duas cmeras que captam todas as imagens
que so processadas por um sistema de viso computacional o SSL Vision (Small Size League)
que envia o resultado deste processamento ao computador tcnico de cada equipe, que ento
determina uma estratgia de jogo que enviada aos robs jogadores.
O futebol de robs exige grande mobilidade dos robs jogadores, seu sistema embar-
cado precisa ler informaes do rdio e controlar os atuadores, que so os motores e, se hou-
ver, o sistema de chute. Alm disso, o sistema de controle interno dos robs deve monitorar
todo o aparato sensrio, uma vez que as informaes lidas dos sensores so utilizadas na to-
mada de deciso para a execuo de uma ao do rob (PAZOS, 2002).
Quando um rob possui a capacidade de planejar e decidir suas aes pode-se afir-
mar que ele possui algum grau de inteligncia. No caso do futebol de robs, na maioria das
equipes, os sistemas embarcados que controlam os robs so apenas reativos, tornando-os
agentes passivos durante todo o jogo. A arquitetura proposta neste trabalho apresenta um dife-
rencial e uma inovao para o futebol de robs, que dotar o rob de capacidade de deciso,
fazendo com que ele seja mais que um receptor, um rob mvel inteligente. Dessa maneira o
sistema garantir certo grau de autonomia ao rob, uma vez que muitas das decises so base-
adas em informaes internas e aes individuais.
Existem vrios objetivos para tornar o rob um agente ativo durante o jogo, o objetivo
cientfico a descoberta de conhecimento e aprofundamento na rea de sistemas embarcados,
17

buscando atingir o mximo potencial desse campo da cincia. O objetivo para o futebol de
robs aumentar a competitividade da equipe, pois alm de retirar algumas responsabilidades
excessivas do computador tcnico, o rob poder ser mais preciso e eficiente.
A equipe pode se tornar mais competitiva, pois poder contar no apenas com a entra-
da de informaes da cmera, mas tambm atravs dos sensores do rob, tornando as jogadas
muito mais precisas.
Tornando o rob um agente ativo possvel diminuir o nmero de troca de mensagens
entre computador tcnico e rob, isso uma vantagem j que quanto mais mensagens mais
processamento de ambos os lados realizado. Assim as energias dos sistemas podem ser vol-
tadas apenas para o jogo e no apenas para a comunicao, isso relevante, pois tanto o rob
quanto o computador tcnico gastam tempo para poder se comunicar, este tempo poderia ser
utilizado na seleo da estratgia no caso do computador tcnico ou na leitura dos sensores no
caso do rob.
No caso do futebol de robs os estudos so realizados para explorar ao mximo o po-
tencial de cada equipe. A maioria dos avanos acontece no sistema estrategista, porm, a evo-
luo no sistema embarcado pode ser um grande passo, j que um rob ativo possui inmeras
vantagens sobre um rob meramente passivo em campo.
Alm de que um rob ativo faz parte da realizao do sonho da Robocup que organi-
zar um jogo em meados do ano de 2050 entre robs humanoides totalmente autnomos e a
seleo campe da Copa do Mundo mais recente, e ver a equipe robtica vencer. Assim, man-
ter embarcada a tomada de decises e a entrada de informaes, faz parte de um objetivo mai-
or, no apenas de uma equipe, mas de toda a instituio responsvel.
Alm de realizar os objetivos propostos para o futebol de robs, manter algumas fun-
cionalidades embarcadas no rob contribui para a tendncia tecnolgica que a humanidade
tem caminhado. Um exemplo disso a automao veicular que tem crescido em grandes pro-
pores, e nesse caso o objetivo que as responsabilidades, antes de um motorista humano,
passem para o controle do sistema. O sistema embarcado realiza a tomada de decises para
executar, por exemplo, o piloto automtico.
1.4. Organizao do Trabalho
Este trabalho est organizado em seis captulos, sendo o primeiro este, a introduo,
que norteia a respeito do tema escolhido abordando os principais aspectos que sero explana-
18

dos, fundamentando a importncia do futebol de robs e orientando a respeito dos objetivos,
justificativa e motivao do presente trabalho.
O Captulo 2 descreve o Futebol de Robs, onde definido o conceito de sistemas
robticos, das arquiteturas de controle, das caractersticas principais dos robs mveis e, por
fim, o futebol de robs com nfase na categoria Small Size da Robocup.
O Captulo 3 descreve as principais caractersticas dos sistemas embarcados abordan-
do os aspectos relacionados ao projeto, implementao e aplicao de tais sistemas. O captu-
lo tambm aborda os sistemas embarcados de tempo real.
No Captulo 4 descrito o projeto e o desenvolvimento do Sistema de Controle Em-
barcado para os robs da Equipe de Futebol de Robs Ararangu Intruders. O sistema est
descrito de acordo com seus blocos funcionais.
No Captulo 5 realizada a anlise do sistema de controle descrito no Captulo 4.
detalhado o desenvolvimento e os resultados atingidos separadamente nos dois nveis de con-
trole do sistema. Tambm feita a comparao entre o sistema ideal e o realizado neste traba-
lho.
No Captulo 6 so apresentando os resultados finais que demonstram que os objeti-
vos determinados foram alcanados. O captulo tambm traz algumas perspectivas para traba-
lhos futuros visando dar continuidade ao sistema desenvolvido neste TCC (Trabalho de Con-
cluso de Curso).
No Apndice I so apresentadas mais informaes sobre tarefas de tempo real utili-
zadas pelo compilador CCS. Para um melhor entendimento foi elaborado um exemplo que
compara um programa com funes sem o uso de tempo real e um programa com tarefas de
tempo real.
19

2 FUTEBOL DE ROBS
Este captulo discorre sobre a definio e conceito de sistemas robticos, as arquiteturas de
controle, as caractersticas principais dos robs mveis e, por fim, o futebol de robs com
nfase na categoria Small Size da Robocup.
2.1. Sistemas Robticos
Um rob mais do que hardware e software combinado para um determinado fim,
possui um sistema de controle que organiza todos os seus recursos e limitaes com a finali-
dade de executar uma tarefa pr-determinada. Dependendo da aplicao os sistemas de con-
trole robticos so simples ou muito complexos, vrios quesitos determinam esse nvel de
complexidade, sendo um dos mais importantes a maneira com que o rob ir relacionar-se
com o meio, pelo fato de que um rob sofre influncia e tambm influencia seu ambiente,
suas entradas e sadas so muito variveis e organiz-las aumenta a complexidade do desen-
volvimento do sistema.
A arquitetura do sistema robtico determinada de acordo com a organizao, sepa-
rao e comunicao de cada um de seus elementos. Um sistema, para ser completo, deve
possuir duas partes principais: uma lgica, composta pelos mdulos de software, e outra fsi-
ca, que formada pelos componentes de hardware (processadores, sensores, atuadores, entre
outros) (MAETA, 2001).
Os sistemas robticos so utilizados nas mais diversas condies e suas tarefas tam-
bm possuem uma grande variedade, em muitos casos existem restries do ambiente que os
resultados devem respeitar. Uma das restries de um sistema robtico so os requisitos de
tempo. Em algumas situaes o sistema deve responder imediatamente, ou seja, ser conside-
rado de tempo real. Portanto o mdulo de software deve, alm de gerenciar todo o, deve ainda
atender a requisitos de tempo.
20

Os sistemas robticos tambm podem possuir autonomia e podem ser representados
como agentes. Um agente definido como a entidade que influencia e influenciada pelo
meio, percebe o ambiente atravs de sensores e age sobre ele atravs de atuadores (RUSSEL;
NORVIG, 2004).

Figura 1: Representao de um agente.
A Figura 1 ilustra a interao de um agente com o ambiente atravs de sensores e
atuadores. Os sensores e atuadores no so padronizados, os agentes os escolhem de acordo
com suas caractersticas fundamentais e de acordo com os objetivos finais, apesar das diferen-
as o papel sempre o mesmo, manter o agente interagindo sempre com o ambiente.
2.2. Arquiteturas de Software
Muito ouve-se falar sobre a arquitetura de hardware, porm pouco se observa a res-
peito da arquitetura do software, este ltimo, tambm possui padres e paradigmas a serem
analisados. Existem trs grandes arquiteturas para software em sistemas robticos, a delibera-
tiva ou hierrquica, a reativa e a hbrida, que a juno das anteriores.
A deliberativa realiza suas aes internas de maneira lgica e sequencial, primeiro
percebendo o ambiente, depois planejando a ao que ser realizada e, por fim, ocorre a ao
de fato. Nesta arquitetura que esta representada na Figura 2, uma tarefa dividida em outras
sub-tarefas que so executadas uma por vez, a reorganizao e juno das subdivises carac-
teriza o objetivo do sistema robtico. Esta arquitetura apresenta resultados positivos se o am-
biente for muito dinmico j que situaes inesperadas foram o sistema a perceber e planejar
novamente para ento agir.
21


Figura 2: Arquitetura deliberativa.
Fonte: Adaptado de (Sousa, 2007).
O sistema tambm pode ser baseado no conceito de ao-reao, no qual suas aes
sero relativas aos estmulos recebidos do ambiente, este conceito conhecido como arquite-
tura de software reativa, que est representada na Figura 3. Os estmulos gerados e percebidos
pelo rob no sero processados para a avaliao e elaborao de um plano, nessa arquitetura
no h fase de planejamento, a sada totalmente relacionada entrada.

Figura 3: Arquitetura reativa.
Fonte: Adaptado de (Sousa, 2007).
22

J na arquitetura hbrida, que foi desenvolvida posteriormente s duas arquiteturas
anteriores, o conceito principal baseado na ideia de que um sistema pode em alguns pontos
precisar de planejamento e em outros deve apenas reagir aos estmulos do ambiente. De acor-
do com esse pensamento partes do sistema devem ser deliberativo, enquanto outras devem ser
reativas.

Figura 4: Arquitetura hbrida.
Na Figura 4 pode ser analisado como a estrutura da arquitetura hbrida. O sistema
continua recebendo informaes de seus sensores e enviando informaes para os atuadores,
mas estes podem estar ligados tanto a mdulos deliberativos como a mdulos reativos. No
caso do Futebol de Robs na categoria F180 da Robocup, esta arquitetura muito utilizada j
que o planejamento essencial para a estratgia, enquanto que para o rob o conceito de ao-
reao adequado.
2.3. Robs Mveis
Os sistemas robticos so um campo muito abrangente e podem ser aplicados em v-
rios setores da economia, como o caso de usinas e indstrias. Em muitos casos era necessrio
que o rob tivesse mobilidade, portanto, aos poucos foi se desenvolvendo a rea dos robs
mveis.
Segundo Dudek e Jenkin (2000) a constituio do rob suprime as barreiras de
hardware e software, ele deve ser analisado de acordo com quatro itens, e, a partir deles, po-
de-se desenvolver o projeto dos mdulos do sistema. Estes itens relacionam-se a fase inicial
de projeto de um sistema robtico.
1. Locomoo: capacidade que o rob tem de se locomover pelo ambiente.
23

2. Percepo: como o rob percebe a si mesmo, seu comportamento e aes, e o
ambiente.
3. Raciocnio: capacidade de mapear e controlar as informaes adquiridas e reagir
segundo as mesmas.
4. Comunicao: forma como o rob se comunica, seja com o ambiente, outros sis-
temas robticos, ou ainda, um operador humano.
Para um rob mvel imprescindvel que seu nvel de locomoo seja positivo. A
maneira como ele vai se mover determina muito a respeito de como ser realizada a tarefa
proposta. O meio para o qual o rob projetado significativo, podendo haver locomoo em
ambientes terrestres, areos e aquticos, dentro dessas possibilidades os robs ainda possuem
vrias maneiras de se mover como no ambiente terrestre em que ele pode andar, correr, saltar,
pular ou ainda rolar Os ambientes tambm podem ser variveis apresentando combinaes
tais quais as citadas em (SIEGWART, NOURBAKHSH, 2004).
Os itens descritos anteriormente so importantes para definir o comportamento do
rob diante de uma determinada situao, j que englobam todos os mdulos que constituem
um sistema robtico. E pelo fato de que os ambientes em que o rob pode estar inserido serem
muito diferentes entre si e sofrerem variaes constantes, os sistemas robticos so primeira-
mente testados e desenvolvidos em ambientes controlados. Em muitos casos mesmo depois de
concludos os robs continuam em ambientes controlados, j que sua aplicao oferece esse
quesito. Esse o caso dos robs para o futebol de robs, o ambiente em que eles atuam
composto por regras, delimitado e normatizado e pode, tambm, ser controlado fornecendo
ao rob informaes essenciais.

2.4. Futebol de Robs
O futebol de robs foi citado pela primeira vez por Alan Mackworth, no artigo intitu-
lado On Seeing Robots (MACKWORTH, 1993), esta ideia surgiu como uma iniciativa de
pesquisadores e cientistas para manter o desenvolvimento de novas tecnologias.
Por muitos anos o grande foco de pesquisa foi o jogo de Xadrez e este estudo chegou
ao pice com a criao de um computador chamado Deep Blue pela IBM (Negcios Interna-
cionais de Mquina do Ingls International Business Machines). Este computador superou um
24

grande desafio, disputou um jogo de Xadrez com o campeo mundial Garry Kasparov em
1997 e o venceu (CAMPBELL, 2002).
Atualmente existem novas propostas de reas para pesquisas e uma delas o futebol
de robs. Muitos desafios de Inteligncia Artificial foram propostos com o objetivo de manter
pessoas motivadas a descobrir e desenvolver inovaes que tragam algum ganho para a hu-
manidade (MACKWORTH, 1993).
De acordo com Salim (2004) o futebol de robs uma proposta que traz grandes ga-
nhos j que um ambiente propcio para testes de novos algoritmos, desenvolvimento de no-
vas arquiteturas de hardware e validao de vrias teorias incluindo de agentes autnomos. A
proposta de desenvolver agentes robticos totalmente autnomos tambm testada e estudada
dentro do ambiente do futebol, o objetivo que em algum momento os robs possam perce-
ber, interagir e aprender com os ambientes, por mais instveis e dinmicos que eles sejam
(SAHOTA, 1994).
Segundo Kraetzchmar (1998) e Cheng (2001) para se formar uma equipe de futebol
de robs so necessrios muitos recursos, na parte de software o sistema sempre deve buscar
facilitar o papel do agente, ento podem ser citados sistemas de controle inteligente para auxi-
liar o rob na descoberta do ambiente, sistemas que relacionem informaes de vrios senso-
res, j que a informao provinda de vrias entradas deste gnero, e ainda, viso computaci-
onal com processamento de imagens, redes neurais e computao evolutiva para a realizao
da estratgia, colaborao multiagentes e sistemas baseados em tempo real. J na parte de
hardware preciso definir o projeto do rob, para isso relevante o conhecimento sobre dis-
positivos mecatrnicos e caractersticas de sensores, atuadores e efetuadores.
Os recursos que devem estar disponveis para a formao de uma equipe de futebol
de robs demonstra o crescimento intelectual que essas competies representam para a soci-
edade. A Robocup
1
e a FIRA
2
(Federao Internacional de Futebol de Robs, do Ingls Fede-
ration of International Robot-Soccer Association) so as instituies que promovem os cam-
peonatos por todo o mundo. Elas surgiram nos anos 90 e o objetivo maior a promoo de
meios de manter a Inteligncia Artificial em evoluo.
A partir da popularizao desse desafio e dos campeonatos que foram ao longo dos
anos sendo realizados em vrias partes do mundo, muitas categorias foram surgindo, popula-

1
Site Oficial: http://www.robocup.org/
2
Site Oficial: http://www.fira.net/
25

rizando a diversidade no meio da robtica. As categorias variam de modelo e tamanho do
rob, regras e at as tecnologias apropriadas, como, por exemplo, no caso de que em uma
categoria a viso se d com uma cmera embarcada no rob, enquanto em outras h uma c-
mera global que alimenta a viso computacional. Dentre as modalidades presentes na Ro-
bocup pode-se citar Humanoid League, Four Legged League, Simulation League, Middle Size
League, Small Size Robot League (F180, Very Small Size Robot League). Devido ao fato de a
Equipe de Futebol de Robs Ararangu Intruders disputar competies de robtica na catego-
ria F180, na Seo 2.5 so descritas as principais caractersticas desta categoria.
2.5. Categoria F180
A categoria F180 foi escolhida devido a possibilidade de desenvolvimento de novas
tecnologias no campo da robtica mvel. Por possuir mais robs e estes serem maiores que a
categoria Very Small Size torna possvel o estudo e utilizao de muitos equipamentos dife-
rentes e inovadores na parte de hardware. Esta categoria tambm representa um desafio para o
desenvolvimento de software, uma vez que deve-se desenvolver o sistema embarcado dos
robs e o sistema de gerao de estratgias.
A categoria Small Size (ou F180) concentra-se na cooperao multi-agente, pois a
equipe deve estar trabalhando como um todo para o mesmo objetivo. O ambiente altamente
varivel, a dinamicidade produzida pelos movimentos da bola e ainda as aes dos robs
jogadores. Na Figura 5 possvel ter uma viso geral de como a estrutura para um jogo.

Figura 5: Estrutura de um jogo da categoria F180.
26

Para formar uma equipe deve-se ter de um at seis robs, sendo obrigatoriamente um
deles o goleiro. As dimenses dos robs so reduzidas, podendo ser no mximo 15 centme-
tros de altura e 18 centmetros de dimetro, conforme ilustrao da Figura 6.

Figura 6: Dimenses mximas dos robs.
Fonte: Extrada de (Robocup, 2012).
O peso varia muito e de carter particular de cada equipe. O campo tem 6,5 metros
de comprimento por 4,5 metros de largura, da cor verde, enquanto que a bola utilizada do
padro de golfe e da cor alaranjada. A identificao vai acima dos robs, e formada por v-
rios crculos, cada um com uma cor, a combinao das cores forma a identidade de cada rob.
As regras determinam onde estar cada crculo e as cores escolhidas so para facilitar o pro-
cessamento de imagens. As identificaes possveis podem ser vistas na Figura 7.

Figura 7: Padro para a identificao dos robs da categoria F180.
Fonte: Extrada de (Robocup, 2012).
Nesta categoria existe um dispositivo de viso global que fica posicionada acima do
campo, esse dispositivo formado por duas cmeras, cada uma responsvel por gerar imagens
de uma metade do campo. Essas imagens so processadas por um computador com o sistema
de viso computacional instalado (SSL Vison). Este ser responsvel pelo processamento das
imagens buscando identificar o posicionamento da bola e de todos os jogadores em campo.
Essas informaes so enviadas pela rede aos computadores tcnicos de cada equipe.
27

O computador conhecido como tcnico o que recebe as informaes do SSL Vision.
A partir dessas informaes determina uma estratgia adequada e envia, a cada rob jogador,
a ao que deve ser realizada. Ou seja, nesse computador tcnico est todo o sistema de estra-
tgia, segundo as informaes recebidas do sistema de viso computacional SSL Vison, ele
escolhe a melhor estratgia para seus robs jogadores, sempre com o intuito de vencer o jogo,
fazendo gols e defendendo-se do adversrio. Na Figura 8 pode ser observada essa descrio.

Figura 8: Esquemtico da categoria F180.
Fonte: Extrado de (Robocup, 2012).
A Figura 8 ilustra uma situao onde a cmera est enviando informaes diretamen-
te ao computador que controla os robs, dentro do especificado nesta Figura o mesmo compu-
tador realiza tanto o processamento da imagem quanto a gerao de estratgia. Essa arquitetu-
ra pode ser utilizada, porm no a mais comum. A partir de 2008, a Robocup disponibilizou
um programa de processamento de imagem a todas as equipes, o SSL Vision, e essas podem
escolher se preferem utilizar seu prprio programa de processamento de imagem ou utilizar o
SSL Vision.
A Robocup escolheu disponibilizar esse programa de processamento de imagens,
pois no havia mais inovao, todas as equipes usavam programas semelhantes e para evitar o
tempo investido em algo que j estava bem consolidado a Robocup criou esse programa e o
disponibilizou. A partir disso as equipes adotaram o SSL-Vision
3
e mesmo no sendo uma
regra passou a ser o meio utilizado por todos os participantes para tratar as imagens.

3
Site Oficial do Sistema SSL-Vision: http://small-size.informatik.uni-bremen.de/sslvision
28


Figura 9: Fluxo de informao.
Fonte: Adaptada de (Sobreira, 2003).
Na Figura 9 pode ser visualizado o fluxo da informao, a partir do momento que a
estratgia foi escolhida o computador tcnico envia pelo rdio a ao individualmente a cada
rob. Para saber a orientao de cada rob o sistema de processamento de imagem relaciona o
formato do rob, sua identidade e as coordenadas do campo.
Percebe-se que nessa categoria o grau de autonomia dos robs limitado, j que re-
cebem a ordem de movimentos que devem ser tomados de outro sistema maior, neste caso, o
computador tcnico. Porm alguns comportamentos no necessitam do controle do computa-
dor tcnico ficando sob o comando do rob mvel, entre esses comportamentos pode se citar
todo o controle do aparato sensrio e todas as decises que so relativas destes. Como, por
exemplo, o domnio de bola, se o sensor de presena indicar que a bola est prxima o prprio
rob decide se ativa ou no o sistema de domnio.
Segundo Novak e Springer (2004) o objetivo sempre minimizar o processo de co-
municao, o foco deve ser manter baixo o nmero de troca de mensagens. Para que isso
29

ocorra necessrio um bom projeto para definir quais funcionalidades ficam no rob e quais
ficam no computador tcnico.
A arquitetura apresentada pela categoria F180 oferece a vantagem para o reconheci-
mento do ambiente j que a cmera central capta todas as informaes do campo, o SSL Visi-
on as interpreta e repassa ao computador tcnico que acaba tendo uma viso bem clara, facili-
tando assim a definio de estratgias. Por outro lado, em alguns momentos, podem deixar a
desejar no tempo de resposta do rob para a execuo da ao que foi enviada pelo computa-
dor tcnico, j que o rob no pode oferecer a reao ao comando em tempo real.
Atualmente, existe a tendncia de utilizar a arquitetura de software hbrida, na estru-
tura do futebol de robs, isso pode ser afirmado pelo fato de partes do sistema serem tratados
com mais prioridade que outros, terem requisitos diferentes e precisarem at, estar alocados
separadamente.
o que ocorre no caso das tarefas do sistema que possuem restrio temporal, como
o desvio de obstculos, o momento do chute e a conduo da bola, estas devem ser tratadas
com o mximo de agilidade e, portanto, devem estar embarcadas no rob e podem ser de tem-
po real. Enquanto as aes que precisam de planejamento so realizadas pelo computador
tcnico, como a gerao de estratgia e o controle de navegao dos robs (BIAZUZ, 2008).
Os movimentos possveis de cada rob variam de acordo com o nmero e estrutura
das rodas. Na Figura 10 podem ser visualizados os movimentos bsicos comuns a todos os
robs. Dependendo da arquitetura de cada rob o acionamento dos motores e a movimentao
pode apresentar algumas diferenas, j que a categoria no determina o nmero de rodas utili-
zado e nem sua posio com relao ao rob.
30


Figura 10: Movimentos bsicos de cada rob.
Os robs recebem as informaes do sistema de estratgia, porm, como j foi dito,
tambm recebem informaes de sensores que podem estar embarcados neles prprios. O
esquema de um rob que recebe informao de ambas as entradas significativo no momento
da competio. Os sensores influenciam na deciso, isso til, por exemplo, quando um rob
est prximo a bola, o computador tcnico no precisa mandar que ele a domine, o domnio
pode ser pr-definido a partir do sensor de presena, ou seja, sempre que o rob estiver perto
da bola vai domin-la, s ser diferente se a estratgia determinar que ele chute, a ento, ele
executa a ao recebida do mdulo de comunicao que sempre tem prioridade.
no momento de projetar a arquitetura de controle da equipe que se deve escolher
qual funcionalidade vai ser tratada em que mdulo, por ser muito essencial para o sistema
como um todo esta etapa deve ser testada e validada.

2.6. Equipe Ararangu Intruders
A Equipe de Competies Tecnolgicas Ararangu Intruders surgiu no ano de 2011
pela iniciativa de professores e alunos da Universidade Federal de Santa Catarina (UFSC)
para desenvolver, inicialmente, robs para competies de futebol. A equipe Ararangu Intru-
ders participa na categoria F180 da Robocup e sua misso participar e conquistar ttulos em
competies de robtica a nvel nacional e internacional valorizando o conhecimento e con-
tribuindo na formao tcnica de seus membros (Intruders, 2012).
O futebol de robs foi escolhido pela proposta de desenvolvimento, formulao de
conhecimento e inovaes. Os grandes investimentos para manter crescente o interesse em
31

Inteligncia Artificial e seus respectivos conceitos chama a ateno de vrios pesquisadores e
mantm esse campo da cincia como um dos auxiliadores no desenvolvimento de novas tec-
nologias.
O projeto de um sistema embarcado para uma equipe de futebol de robs no neces-
sita de alto investimento financeiro para seu desenvolvimento, entretanto o sistema embarca-
do apenas uma das partes que compe uma equipe de futebol de robs. Logo, observa-se
que para formar uma equipe de futebol de robs existe a necessidade de apoio financeiro. A
produo de robs e os recursos necessrios para o desenvolvimento do software de gerao
de estratgias refletem em custos relativamente altos se comparados aos valores de investi-
mento em sistemas embarcados. No caso da equipe Ararangu Intruders contou-se com apoio
financeiro de patrocinadores.
Adquirindo o conhecimento necessrio, gradativamente foram sendo determinados
pontos com relao ao projeto dos robs e paralelamente os equipamentos foram sendo adqui-
ridos. A partir dessa etapa os robs comearam a ser produzidos e os softwares relacionados
desenvolvidos.
Os robs da equipe Ararangu Intruders contam com um sistema embarcado produ-
zido para o microcontrolador PIC18F452, este foi escolhido por ser de baixo custo e atender
os requisitos de hardware dos robs. Este microcontrolador possui 40 pinos e alguns deles
tem funes especiais. Os pinos so separados por portas, que so nomeadas com letras do
alfabeto, cada porta possui 8 pinos correspondentes que vo de 0 a 7. Alguns pinos so anal-
gicos e outros digitais.
O PIC18F452 possui potencial satisfatrio para a aplicao para o qual foi escolhido.
Os pinos que so diferenciados, como os analgicos e os utilizados para o controle de PWM
(Modulao por Largura de Pulso, do Ingls Pulse Width Modulation), so reduzidos, porm
suficientes para os robs jogadores de futebol.
A Figura 11 ilustra um dos robs que participaram da IX Competio Brasileira de
Robtica, realizada em outubro do ano passado na cidade de So Joo Del Rei - MG. Ao todo
foram produzidos seis robs idnticos.
32


Figura 11: Rob da equipe Ararangu Intruders utilizado na competio de 2011.
Cada rob da Equipe Ararangu Intruders utilizado na competio de 2011 possuia a
seguinte especificao de hardware: microcontrolador PIC18F452, trs motores de corrente
contnua com caixa de reduo, driver dos motores baseado em circuitos de ponte H, sistema
de comunicao da Telecontrolli de 433 MHz. As rodas e o chassi so de alumnio de 3mm e
4mm, respectivamente.

33

3 SISTEMAS EMBARCADOS
Este captulo descreve as principais caractersticas dos sistemas embarcados abordando os
aspectos relacionados ao projeto, implementao e aplicao de tais sistemas. O captulo tam-
bm aborda conceitos relativos aos sistemas embarcados de tempo real.
3.1. Definio de Sistemas Embarcados
Os sistemas embarcados so um tipo diferente de tecnologia, no so perceptveis co-
mo no caso dos computadores, mas fazem parte da vida cotidiana de muitas pessoas. A rotina
do homem est cada vez mais repleta de tecnologia e os sistemas embarcados so a grande
maioria dessa tecnologia, apesar de muitos nem ao menos percebem sua utilizao diria.
Sistema embarcado ainda no um termo popular, porm esta tecnologia muito uti-
lizada pelas pessoas. O prprio nome j consta em si uma definio, ele baseia-se em sistemas
que esto embarcados, ou seja, dentro de um equipamento, isso significa que existe um pro-
grama que faz parte do aparelho. Esses sistemas so interessantes, pois so utilizados para
maximizar as funcionalidades de um determinado equipamento.
Os sistemas embarcados so a reunio de hardware, software e perifricos que tem um
objetivo comum, realizar uma tarefa especfica. A capacidade computacional destes sistemas
est voltada a atender um nico objetivo. So fortemente acoplados ao hardware e se adequam
as caractersticas deste.
Um sistema embarcado utiliza todos os seus recursos e existe para cumprir um prop-
sito especial, como, por exemplo, controlar as funes de aquecimento de micro-ondas ou de
resfriamento do ar-condicionado (CARRO; WAGNER, 2003). O termo embarcado ou embu-
tido utilizado justamente por executar sobre plataformas de hardware, fazendo parte dele. O
dispositivo eletrnico esconde o sistema dentro de si.
34

Um equipamento que possui um sistema embarcado possui seu projeto de hardware
elaborado juntamente com o projeto de software, isso ocorre, pois inerente a sistemas em-
barcados a forte ligao entre o software e o hardware. Ambas as partes adequam-se a carac-
tersticas e limitaes da outra para otimizar ao mximo todos os recursos disponveis. Siste-
mas embarcados tambm podem fazer parte de sistemas maiores objetivando maximizar o
potencial do dispositivo para aumentar a funcionalidade e eficincia.
Os sistemas embarcados so projetados de acordo com critrios e especificidades de
cada aplicao. Segundo Wolf (2001) os requisitos especficos para cada projeto so: o obje-
tivo do sistema, o tempo de resposta, o consumo de energia, o desempenho, a pouca disponi-
bilidade de memria, a portabilidade e a confiabilidade necessitando assim, de uma configu-
rao nica para cada aplicao.
Por existirem tantos pontos a serem observados na construo de um sistema embar-
cado para que ele seja adequado tarefa proposta, importante explorar a arquitetura de
hardware e software avaliando as consequncias no resultado final. Esta prvia avaliao deve
corresponder ao sistema real, portanto necessrio a utilizao de bons estimadores e mto-
dos que tragam resultados concretos, para que a avaliao seja suficiente deve-se explorar o
espao de projeto no nvel mais abstrato possvel (GERVINI, 2003).
De acordo com Taurion (2005), algo que pode determinar o sucesso e a qualidade de
um sistema embarcado, seja ele para qual aplicao for o projeto e o ambiente de constru-
o, estes pontos so relevantes para o resultado final. Pelas muitas limitaes encontradas na
rea dos sistemas embarcados a maioria dos softwares no adota conceitos como orientao a
objetos, e so escritos em linguagens de programao estruturadas como a linguagem C, co-
mo pode ser percebido na Tabela 1.





35

Tabela 1: Linguagens de programao utilizadas em sistemas embarcados. Dados de 2006.
(Extrado de CMP United Business Media 2006).
Linguagem Uso (%)
C 51
C++ 30
Assembly 8
Java 3
BASIC 1
UML, MatLab ou outra
3 linguagem de modelagem
LabView 2
Outras 5
Os sistemas embarcados so projetados, na maioria das vezes, para microcontroladores
que so pequenos dispositivos que contam com quesitos computacionais essenciais, tais como
memria, unidade central de processamento e dispositivos de entrada e sada, provendo assim,
condies de se elaborar um sistema para atender uma demanda especfica.
O sistema embarcado lida com vrias restries, o software, especificamente precisa
contornar o limite de memria disponvel, o desempenho do processador e o consumo de
energia, isso deve ser analisado para determinar a utilizao de uma plataforma para tal apli-
cao. De acordo com a aplicao que deve ser desenvolvida a plataforma e o microprocessa-
dor sero escolhidos.
Da mesma maneira em que o software presente em um sistema embarcado pode variar
muito, o hardware tambm apresenta tal caracterstica, a arquitetura de um sistema computa-
cional embarcado pode conter blocos dedicados, memrias, um ou mais processadores e inter-
faces para perifricos. essencial que todos esses componentes tenham boa comunicao
entre si, esta pode ocorrer atravs de uma estrutura de interligao que pode ser um barramen-
to ou at uma rede complexa (BENINI, 2002).
Geralmente o hardware de um sistema embarcado formado por microprocessador,
memria e perifricos, tornando claro que ele um sistema computacional, as diferenas esto
nos requisitos e nas aplicaes alvos para os quais projetado (BOSA, 2009). O software ,
normalmente, armazenado em uma memria que compe a plataforma que est sendo utiliza-
da. Ele projetado e compilado para a arquitetura do microcontrolador escolhido.
A capacidade computacional de um sistema microprocessado suficiente para muitas
aplicaes como pode ser observado na Tabela 2. Os exemplos de sistemas embarcados vo
36

desde uma simples mquina de lavar at a automao completa de uma residncia. Isso de-
monstra as potencialidades dos sistemas embarcados, apesar de serem pouco notados eles tm
uma grande capacidade computacional. Inclusive possuem integrao com a Internet, esta
uma tendncia natural, j que os sistemas embarcados representam a maior fatia do mercado
de processadores e a interconexo em redes TCP/IP realizada com simplicidade e sucesso
(MACHADO; SIQUEIRA, 2004).

Tabela 2: Sistemas embarcados e sua utilizao em cada mercado.
Extrado de (Noergaard, 2005).
Mercado Dispositivo Embarcado
Automotivo Sistema de Ignio
Controle de Motor
Freios (ABS)
Eletrnica de Consumo Televisores Analgicos e Digitais
DVDs, Vdeo cassetes
Personal Data Assistants (PDAs)
Eletrodomsticos (Refrigeradores, Microondas, Torradeiras)
Brinquedos, Jogos
Telefones, Pagers e Celulares
Cmeras
Global Positioning Systems (GPS)
Controle Industrial Robtica e Controle de Sistemas (Manufatura)
Medicina Bombas de Infuso
Prteses
Equipamento de Dilise
Monitores Cardacos
Redes de Comunicao Roteadores
Hubs
Gateways
Automao de Escritrios Equipamentos de Fax
Copiadoras
Impressoras
Scanners

Conforme Vianna (2009) a proliferao de aplicaes para sistemas embarcados re-
sultado de uma convergncia para a computao ubqua, esse conceito baseado na hiptese
de que a computao pode transcender o escopo dos computadores convencionais e torna-se
parte no cotidiano das pessoas. O cientista Marc Weiser foi o primeiro a usar este termo, ele
37

acredita que neste mundo, deveremos conviver com computadores e no apenas interagir com
eles (WEISER, 1991).
Muitas caractersticas dos sistemas embarcados podem ser encontradas na computao
pervasiva ou ubqua. A Computao Pervasiva visa o uso da informao em todos os lugares
em todo o tempo. Na Figura 12, pode-se ver uma representao grfica de como a Computa-
o Ubqua influenciada pelas Tecnologias da Comunicao e pelos Sistemas Embarcados
(MARWEDEL, 2003).

Figura 12: Influncia de Sistemas Embarcados sobre a Computao Ubqua.
Adaptado de (Marwedel, 2003).
De fato os sistemas embarcados esto hoje em todo lugar e na maioria das vezes no
so ao menos notados, existe a tendncia de que possa haver a convivncia com essa tecnolo-
gia mesmo sem perceb-la. Na maioria dos casos os sistemas embarcados so discretos, a
prioridade manter o foco no objetivo final para o qual foram projetados, ou seja, a prefern-
cia est na tarefa a ser realizada e no na maneira como ser feita.
Este paradigma entre a tarefa e o mtodo algo muito discutido, pois por muitos anos
a tecnologia evoluiu para facilitar a maneira de realizar a tarefa com eficincia. Os computa-
dores so facilitadores no desenvolvimento de atividades enquanto os sistemas embarcados
so catalizadores na realizao da tarefa. Ou seja, enquanto o foco dos computadores auxili-
ar o usurio oferecendo-lhe diversas maneiras prticas de realizar a mesma tarefa com mais
38

eficincia, o objetivo dos sistemas embarcados no ajudar o usurio e sim realizar a prpria
tarefa.
Os computadores oferecem diversas ferramentas de edio de texto, um usurio que
necessite desenvolver um documento textual contar com o auxilio do computador e este l-
timo o auxiliar a produzir um texto da melhor maneira possvel. Os sistemas embarcados no
oferecem opes de como realizar a tarefa para a qual foram criados, simplesmente a execu-
tam. O sistema embarcado de um ar condicionado no ajudar o usurio a refrigerar o ambi-
ente de diversas maneiras, simplesmente, assim que acionado, diminuir ou aumentar a tem-
peratura do recinto o mais eficientemente possvel.
O conceito de tarefa e mtodo leva a outra definio de que, sistemas embarcados so
todos os produtos em que a parte computacional do sistema no o principal do produto, ou
seja, sistemas embarcados servem para deixar o aparelho ou equipamento ainda melhor em
sua atividade. As pessoas compram um equipamento no pelo sistema que est embarcado,
mas pelas funcionalidades que ele oferece. Como foi dito, o objetivo de sistemas embarcados
no a maneira de se realizar uma dada tarefa, mas tornar a realizao da tarefa otimizadaDe-
vido a grande rea em que sistemas embarcados podem atuar a diversidade de possibilidades
para o desenvolvimento torna a tarefa inicial de projetar o sistema um grande desafio, como j
foi dito, deve-se tratar as limitaes de hardware e software, escolher bem o microcontrolador
e definir bem os objetivos para o qual o sistema est sendo criado. A partir de tantos pontos a
serem observados e da imensa diversidade na implementao surgiram as plataformas que
visam facilitar o desenvolvimento dos sistemas embarcados.
Segundo Bosa (2009) uma plataforma uma arquitetura de hardware e software espe-
cfica para determinado domnio da aplicao. Elas so parametrizveis quanto ao nmero e
definio de componentes. Uma plataforma possui todos os dispositivos para o desenvolvi-
mento de um sistema e us-las muito benfico, j que, normalmente j esto de acordo com
normas e padres, deve-se, portanto, estudar e escolher uma plataforma que satisfaa as con-
dies do projeto.
O projeto de um sistema embarcado pode incorporar sofisticadas funcionalidades, co-
mo algoritmos complexos, no caso de um motor de automvel as operaes realizadas pelo
microprocessador so complicadas, existem funes de filtragem para otimizar o desempenho
do carro e ainda minimizar a poluio e utilizao de combustvel. Outra funcionalidade inte-
ressante que pode estar integrada ao projeto so as interfaces, so utilizados com frequncia
39

microprocessadores para controlar a interface como usurio, estas podem incluir menus e
muitas outras opes, um exemplo que pode ser citado o equipamento de navegao conhe-
cido como GPS (Sistema de Posicionamento Global, do Ingls Global Positioning System)
(WOLF, 2001).
3.2. Metodologia de Desenvolvimento
Uma metodologia pode auxiliar o desenvolvedor de sistemas embarcados. Existe um
fluxo que a informao deve seguir, na Figura 13 pode ser visualizada uma metodologia tpica
para o desenvolvimento de projeto de sistemas embarcados criada por Carro e Wagner (2003).

Figura 13: Fluxo de um Projeto de Sistema Embarcado.
Extrado de (Carro e Wagner, 2003).
Tudo se inicia pela especificao funcional, processo de definio das funes do sis-
tema, ou seja, a delimitao da tarefa que ser executada pelo sistema embarcado. vlido
ressaltar que sistemas embarcados so dedicados a um objetivo nico, portanto esse processo
de escolha das funes que sero executadas no trivial, pois deve-se levar em conta as prio-
40

ridades do aparelho que o sistema gerenciar e o pblico-alvo para o qual est sendo desen-
volvido. Esta etapa inicial deve ser feita em uma linguagem formal e deve ser o mais abstrata
possvel, nesse momento no podem ser valorizadas ou descritas as implementaes do siste-
ma, pois o foco na demarcao do alvo. Deve ao final passar pelo processo de validao, se
esse for positivo, ento continuado o fluxo.
Em seguida realizada uma explorao do espao do projeto arquitetural, esse mo-
mento leva em considerao muitas informaes, a validao da especificao funcional, os
requisitos da aplicao, a plataforma arquitetural e as bibliotecas de componentes. Esses con-
juntos de informao servem como auxlio para a determinao da arquitetura ideal para o
projeto.
Se os estimadores indicarem um resultado aceitvel para os projetistas idealizada
uma macro-arquitetura, esta ter uma descrio rpida de quais e como sero cada um dos
componentes que integrar o sistema, tanto de hardware, como de software. Juntamente com
isto, tambm formulado um mapa de todas as funes do sistema, a partir desse mapea-
mento que o desenvolvimento do software pode ser iniciado. Assim que esta etapa passar com
sucesso pela validao se tornar possvel desenvolver os componentes e integr-los. Essa
ordem entre as aes ilustrada no esquema da Figura 14.

Figura 14: Desenvolvimento de Projeto em Nveis.
41

Adaptada de (Wolf, 2001).
A fase de arquitetura muito essencial, um bom projeto do mapeamento funcional e
da macro-arquitetura torna o desenvolvimento dos componentes mais simples, tornando har-
moniosa a integrao destes. Os componentes somente sero iniciados se a validao da fase
anterior for aceita no somente pelo cliente, mas tambm pela equipe tcnica.
A etapa de desenvolvimento dos componentes acontece de maneira paralela, ou seja, o
software, o hardware e a comunicao sero criados e implementados juntos. Esta etapa, por-
tanto, subdivida em trs processos de criao: a gerao do software e aplicativo de tempo
real, se este for necessrio aplicao; a sntese de comunicao, como o sistema ir se co-
municar com o ambiente e como ser a comunicao dos componentes entre si; e, por fim, a
sntese da micro-arquitetura, ou mais comumente chamado, desenvolvimento e escolha do
hardware.
A partir de todo esse fluxo de processo para desenvolver um sistema embarcado pos-
svel visualizar quais informaes so necessrias e em que momento, este processo torna o
desenvolvimento de sistemas algo organizado e claro. Utilizando uma metodologia para servir
de auxlio torna-se mais simples identificar os erros e as possveis melhorias, mantendo o de-
senvolvimento de sistemas embarcados um processo otimizado e alcanvel.
Os custos tecnolgicos para o desenvolvimento de sistemas embarcados so conside-
rados baixos, pois, o avano da tecnologia em reas como a engenharia eltrica e a micro ele-
trnica tornou possvel a miniaturizao e o barateamento do hardware para sistemas compu-
tacionais, dando a oportunidade de expanso aos sistemas embarcados (VIANNA; MACHA-
DO, 2009). A partir disso torna-se plausvel a multiplicao de sua utilizao no meio da so-
ciedade.
Levando-se em considerao que os sistemas embarcados so imprescindveis em
muitas atividades humanas, e por serem a maioria das tecnologias que circundam o homem,
acredita-se que precisam continuar evoluindo, buscando novas solues e resultados com as
mesmas condies.
Os sistemas embarcados podem trazer lucros atravs de economias, pode-se citar, por
exemplo, um sistema que controla toda a rede eltrica de um prdio desligando e ligando lu-
zes e equipamentos. Essa economia tambm pode ocorrer nas casas, pois existe a possibilida-
de de conexo de um ambiente virtual com o real e a intermediao ser realizada pelo sistema
embarcado, conforme o exemplo ilustrado na Figura 15. O sistema pode receber comandos do
42

ambiente virtual e realiza-los no real, tambm pode perceber que no h ningum no ambiente
e apagar as luzes, por exemplo.

Figura 15: Intermediao feita pelo Sistema Embarcado entre Ambiente Virtual e Real.
Extrado de (Vianna; Machado, 2009).
A evoluo da microeletrnica e o barateamento das CPUs (Unidade Central de Pro-
cessamento, do Ingls, Central Processing Unit) viabilizaram o emprego de sistemas compu-
tadorizados nos diversos equipamentos. Os crebros desses aparelhos modernos so os com-
putadores que esto neles embutidos (CAIXETA, 2006). Eles so a excelente combinao de
hardware e software para executar uma tarefa especfica e este fato um dos grandes diferen-
ciais do sistema embarcado para outros sistemas computacionais.
Pelo benefcio na integrao da computao com os eletrodomsticos comuns muito
comeou a ser estudado para que em ambientes monitorados por sistemas embarcados estes
pudessem no s controlar, mas tambm interferir no ambiente. Foi dito que a conexo entre
os ambientes virtuais e reais pode ser interessante do ponto de vista financeiro e isso um
fato, a maneira como isso realizado atravs da conexo no apenas de entradas aos siste-
mas embarcados, mas tambm sadas para que possa haver interveno por parte do sistema
ao ambiente.
Da mesma maneira que sistemas computacionais possuem entrada, processamento e
sada, os sistemas embarcados tambm, e estas entradas podem vir de um ambiente, de senso-
res ou de outro sistema, enquanto as sadas podem ser emisses de sinais ou ainda podem es-
tar conectadas a atuadores. Estes atuadores so os que influenciam verdadeiramente no espao
delimitado, so os que vo atuar sobre o ambiente. Cada sistema embarcado possui sua apli-
43

cao, portanto cada um pode ou no ter atuadores, como tambm os atuadores podem ser
diferentes de um sistema para outro.
Na Figura 16 pode ser visto um sistema embarcado que possui sensores e atuadores.
Ele recebe informaes de um ambiente virtual e tambm dos sensores e reage atravs dos
atuadores. O sistema deve ser capaz de gerenciar instrues de acionamento de dispositivos
recebidas do servidor, executar os acionamentos, verificar possveis falhas no acionamento,
checar variveis de ambiente e informar ao servidor as modificaes encontradas (COSTA;
VIANNA, 2008).

Figura 16: Sistema Conectado a Sensores e Atuadores.
Extrado de (Costa; Vianna, 2008).
Nesse caso o sistema mais complexo do que um sistema embarcado de um ar condi-
cionado, por exemplo, isso apenas uma comparao para que possa ser percebido como sis-
temas embarcados esto em todo o lugar e podem ter inmeras aplicaes. As entradas e sa-
das do seu processamento podem trazer realmente timos resultados, mas para que isso ocorra
fundamental que tenha ocorrido um bom planejamento do sistema, tanto na parte de softwa-
re como de hardware.
Um sistema embarcado formado por uma entrada, uma CPU e uma sada. Essa uni-
dade de processamento pode ser um microcontrolador, e a escolha desse microcontrolador
muito importante para o sistema embarcado, uma vez que o prprio microcontrolador possui
desempenho, que muitas vezes, suficiente a determinados aparelhos com funes especfi-
cas. Porm, na maioria dos casos, um sistema embarcado desenvolvido para aumentar a efi-
44

cincia e eficcia do aparelho no desempenho da funo especfica. Na concepo de um sis-
tema embarcado, procura-se adotar um microcontrolador cujas portas de comunicao sejam
suficientes em nmero e compatibilidade com os outros componentes controlados no sistema
(SANTOS, 2010).
A escolha do microcontrolador deve ser determinada de acordo com os requisitos do
sistema a ser desenvolvido ainda no incio do desenvolvimento do projeto. O tratamento de
erros, que percorre todo o desenvolvimento do sistema embarcado, deve ser considerado,
principalmente, quando este est lidando diretamente com a vida de algum.
Pode-se citar um sistema embarcado que vai atuar em um marca-passo, este no pode
ter erro algum, j que qualquer espcie de falha pode gerar consequncias graves e at irrever-
sveis, a qualidade do sistema deve ser altssima. Por outro lado, um jogo utilizado pelo celu-
lar no pode ter erros para no frustrar o usurio, porm suas consequncias so bem mais
amenas. A complexidade envolvida, os prazos definidos e os custos so totalmente diferentes
nas situaes citadas, o que influencia em escolhas diferentes para cada aplicao. Enquanto
um deve ter mais qualidade e pode ter maior preo, o outro pode ter qualidade inferior, porm
preo muito mais acessvel (TAURION, 2005).
Se o sistema tiver outro propsito como troca de informao com as pessoas, o projeto
deve ser bem diferente, ser atravs de interfaces como teclados ou displays que o usurio
poder interagir com o programa. Mesmo havendo interao, por se tratar de um sistema em-
barcado nunca o usurio ter acesso direto aplicao que foi embutida no dispositivo.
Um sistema embarcado no possui muita flexibilidade, pois produzido para um obje-
tivo nico, entretanto, mesmo possuindo tal caracterstica as atualizaes so muito desejadas.
Isso ocorre pela aceitao do fato de que a tecnologia ir evoluir e o sistema deve aceitar no-
vas funes para no ser rotulado como ultrapassado. Assim torna-se importante que este tipo
de sistema seja flexvel para o uso de novas verses.
3.3. Sistemas Embarcados e Sistemas de Tempo Real
Os sistemas embarcados possuem modos de funcionamentos, isso est relacionado
como eles vo desempenhar suas funes no meio para o qual foram projetados. Este ponto
de fundamental importncia na avaliao de como desenvolver o sistema para determinada
45

aplicao. Existem dois modos de funcionamento: o Reativo e o Controle em Tempo Real
(FARINES; FRAGA; OLIVEIRA, 2000).
O modo de funcionamento Reativo quando o sistema espera pelas influncias do
meio no qual est inserido, ou seja, ele tem seu funcionamento como resposta a eventos ex-
ternos. Isso pode acontecer enviando algum sinal de rdio para um rob, por exemplo. Nesse
caso existe a necessidade da entrada de dados, e o sistema precisa receber e saber interpretar
cada um desses dados.
Por esperar a influencia externa no tem limites de tempo de entrada, porm existem
os limites de tempo para sada, ou seja, ele precisa apresentar a reao quando ativado, isso
deve acontecer, normalmente, aps os dados de entrada comearam a ser executados. Os
eventos externos podem ser peridicos, como nos controles de loop, ou assncronos, como no
caso de pressionar um boto.
O modo de funcionamento de controle em Tempo Real quando um sistema requer
que os resultados cheguem em um prazo especfico. Resultados que chegam depois do prazo
expirado so inteis. Pode-se citar como exemplo um rob explorador, que est em uma su-
perfcie estranha para desbravamentos cientficos, seu papel coletar informaes, mas ao
mesmo tempo em que coleta os dados precisa avaliar o ambiente em que se encontra, ele pre-
cisa receber informaes sobre obstculos que possivelmente podem atrapalhar seu objetivo,
como uma rocha que impea o caminho, se ele receber a informao de que existe uma rocha
a frente depois de j ter colidido com ela, a informao foi intil, pois deveria ter sido recebi-
da e interpretada antes, para que o impacto no acontecesse.
Esta noo de programao dentro de prazos simples, mas tambm exigente, isto po-
de ser afirmado, pois se a resposta certa for recebida fora do prazo ela deixa de estar correta.
Ou seja, se o programa no produz a sada requerida dentro do prazo, ento o programa no
funciona, mesmo que a sada produzida funcionalmente correta, portanto esse conceito torna
o sistema rgido e vlido (WOLF, 2001).
A computao dita de tempo real quando realiza a gerencia de recursos com o obje-
tivo de atingir o trmino da operao diante de uma restrio de tempo. Assim o tempo faz
parte da lgica do sistema, o tempo real e fsico, absoluto ou relativo. O sistema precisa ter a
garantia de que as tarefas sero executadas dentro das restries temporais, independente se o
46

sistema estiver sobrecarregado, isso se chama determinismo, um dos pontos fundamentais em
um sistema de tempo real. As tarefas podem variar em prioridade e tambm em periodicidade,
ou seja, algumas tarefas vo ser executadas de maneira sncrona, com uma frequncia j esta-
belecida, enquanto outras so espordicas, ou seja, assncronas. Para tratar de tantos requisitos
e ainda conseguir garantir o determinismo, a maioria dos sistemas embarcados de tempo real
baseada em multitarefa que o conceito de vrias tarefas concorrendo entre si (MAETA,
2001).
Em algumas aplicaes a utilizao de sistemas com multitarefa essencial, como, por
exemplo, no caso de sistemas multimdia. Se as tarefas no conseguirem executar de forma
sincronizada no prazo estipulado a percepo de toda a apresentao pode estar comprometi-
da. O conceito de multitarefa determina que vrias atividades precisam ocorrer ao mesmo
tempo, para que todas executem dentro de seus prazos o sistema deve controla-las, a execuo
deve ser concorrente mesmo que as taxas de limite de tempo sejam diferente.
O requisito de tempo real tambm muito utilizado na indstria automobilstica, como
no caso do sistema controlador de velocidade de cruzeiro em automvel. Este sistema regula a
velocidade do carro percebendo as rotaes do eixo dianteiro, o velocmetro, a chave de con-
trole, o acelerador e o pedal do freio, claramente ele tem restries temporais entre outras co-
mo desempenho e segurana (SHAW, 2001).
Os sistemas de tempo real podem ser de dois tipos: crticos, que quando as tarefas
devem responder em um prazo especfico, porque se no o fizerem podem levar a srias con-
sequncias, normalmente ligado vida de pessoas. E, o no crtico (brando), que quando as
tarefas podem ser executadas no limite de tempo, mas se no o fizerem no causaro conse-
quncias graves.
No grfico da Figura 17 possvel visualizar o contraste entre os sistemas de tempo
real crtico, no-crtico e os sistemas operacionais de propsito geral com relao a utilidade
da tarefa se o prazo for ultrapassado e a tarefa no ter sido cumprida. Como j foi explanado
sistemas de tempo real so aqueles que possuem prazos de execuo para as tarefas, nesta
categoria existe uma subdiviso que os organiza em crticos e no-crticos. Para os crticos a
tarefa fora do prazo intil, enquanto que para os no-crticos ela ainda pode ter utilidade,
mesmo que reduzida.
47


Figura 17: Grfico de Utilidade de Tarefas mediante Prazo.
Extrado de (National Instruments, 2011).
Para o sistema de tempo real crtico a partir do momento em que o prazo foi ultrapas-
sado a utilidade da tarefa passa a ser zero, ou seja, deixa de ter utilidade j que o tempo limite
foi ultrapassado. No caso de sistemas de tempo real no-crticos a tarefa perder a utilidade
conforme o tempo de atraso for aumentando com relao ao prazo principal.
Atualmente o nmero de sistemas com requisitos de tempo real tem crescido muito,
existem sistemas mais simples como os sistemas embarcados em utilidades domsticas, tais
como videocassetes e micro-ondas, como tambm na outra extremidade do quesito complexi-
dade os sistemas militares de defesa e de controle de trfego areo e ferrovirio. Muitos equi-
pamentos eletromecnicos incorporam sistemas embarcados para terem sua funcionalidade
aumentada, agregando valor e exibindo um diferencial diante dos competidores (CAIXETA,
2006).
Todos os sistemas embarcados, independente do seu modo de funcionamento devem
ser confiveis. Segundo Marwedel (2003) esses sistemas devem ser a prova de falhas e j que
existe a interao com o meio o impacto deve ser sempre positivo. Para considerar o sistema
confivel quatro itens fundamentais devem ser observados:
1. Fiabilidade: define a probabilidade de que o sistema no ir falhar;
48

2. Manutenibilidade: tambm pode ser entendida como Recuperao, j que se
refere probabilidade de que uma falha no sistema ser reparada em certo in-
tervalo de tempo.
3. Disponibilidade: o sistema deve estar sempre disponvel. Para aumentar esse
quesito deve-se elevar os dois anteriores.
4. Segurana: este termo possui dois aspectos, primeiramente que se o sistema
falhar no causar dano algum ao ambiente em que est, ou seja, o meio deve
estar sempre seguro. E posteriormente, que o sistema deve manter seus dados
com confidencialidade e garantir a comunicao com autenticidade.
Um sistema que engloba esses pontos torna-se mais interessante tambm do ponto de
vista econmico, j que representam vantagens para os clientes. Um equipamento que possua
um sistema embarcado considerado confivel ainda mais valorizado. Os sistemas embarca-
dos devem atender a tarefa para os quais foram projetados, seu sistema de controle deve iden-
tificar e atingir o objetivo por completo, porm vale ressaltar que a confiabilidade do sistema
interfere se o resultado atingido foi com sucesso ou apenas com suficincia.
Os sistemas embarcados so muito importantes no meio social, representam a maior
parte da tecnologia que o homem tem contato diariamente, apenas por isso j uma rea al-
tamente relevante e interessante. Levando em conta que existem meios de facilitar seu projeto
atravs de metodologias e que seu desenvolvimento tem um baixo custo torna-se um campo
ainda mais atraente. Porm todos esses pontos positivos no devem permitir que um sistema
por pressa, seja utilizado sem ser confivel mantendo inseguro o ambiente em que se encon-
tra, portanto, apesar dos pontos para o sistema atingir um estado confivel tornarem mais
complexo e lento seu desenvolvimento um ponto essencial e que deve ser mantido.

49

4 SISTEMA DE CONTROLE EMBARCADO PARA O FUTEBOL
DE ROBS
Este captulo descreve o sistema de controle projetado para a Equipe de Futebol de Robs
Ararangu Intruders. Para um melhor entendimento do captulo ser utilizada um abordagem
bottom-up, ou seja, de baixo para cima, sendo inicialmente explicado o hardware que com-
pem os robs. Em seguida ser explicado o sistema de controle.
4.1 Arquitetura de Hardware dos Robs da Equipe Ararangu Intruders
O projeto dos robs da equipe Ararangu Intruders conta com 6 (seis) robs holon-
micos compostos por 4 (quatro) motores de corrente contnua, 2 (dois) microcontroladores,
1(um) rdio transceptor, sistema de chute e domnio de bola e sensores. Esta configurao de
hardware foi a proposta para ser utilizada em 2012 na X Competio Brasileira de Robtica
em Fortaleza CE. A Figura 18 ilustra o projeto da arquitetura de hardware de cada rob da
equipe Intruders.
50


Figura 18: Arquitetura de hardware dos robs da equipe Intruders.
A arquitetura de hardware composta por 2 (dois) nveis de controle, sendo cada nvel
controlado por um microcontrolador PIC modelo 18F452. Essa diviso permite aumentar a
capacidade de processamento e o tempo de resposta.
O primeiro nvel composto pelo sistema de comunicao (rdio), o sistema de chu
te e domnio de bola e a comunicao com o microcontrolador do segundo nvel, inti-
tulado de microcontrolador escravo.
O sistema de comunicao composto por um mdulo de rdio transceptor nRF24L01
de 2.4 GHz da Nordic responsvel pelas comunicaes entre o rob e o computador tcnico e
vice versa. O fato de haverem muitas mensagens foi um dos principais motivos pelo qual foi
escolhido utilizar dois microcontroladores ao invs de apenas um. O objetivo fazer com que
todas as mensagens sejam processadas o quanto antes possvel, devido ao processamento de
uma mensagem ser uma atividade de alta prioridade, muitas outras funes podem ser deixa-
das de ser executadas.
O sistema de chute e domnio de bola composto por um solenoide que serve para
chutar a bola, um motor de corrente contnua acoplado a um rolete que serve para manter a
bola dominada e um sensor de infravermelho que acusa a presena da bola prxima ao rolete
de domnio. O microcontrolador, ao receber o sinal do sensor de infravermelho, aciona o role-
te de domnio de bola.
51

Outra funo que realizada pelo primeiro nvel a comunicao com o microcontro-
lador do segundo nvel, esta uma comunicao SPI (Interface Serial Perifrica, do Ingls,
Serial Peripheral Interface) e o contedo da mensagem a direo e a velocidade linear de
cada roda acoplada aos motores de corrente contnua.
O segundo nvel composto pelo monitor de bateria, controle dos motores e sensores
de infravermelho.
O monitor de bateria avalia periodicamente o nvel da carga da bateria. Essa funo
foi adicionada, pois existem robs que gastam mais bateria do que outros durante a partida.
Com o monitoramento da bateria o rob pode avisar o computador tcnico para ser substitu-
do ou trocar de funo, j que normalmente todos os robs possuem os mesmos itens de
hardware. Com isto possvel obter informaes do rob sem precisar tir-lo de campo, j
que um dos pontos que aumenta a competitividade possuir o time completo em campo para
jogar. Os robs da equipe Intruders utilizam baterias de LiPo de 3 (trs) clulas de 11.1V
2200 mAh e 14.8V 5000 mAh.
O controle dos motores realiza a ativao dos motores individualmente. O microcon-
trolador do primeiro nvel repassa ao segundo nvel a informao referente a direo e a velo-
cidade de cada motor. Essa informao um valor que determina a variao PWM (Modula-
o por Largura de Pulso, do Ingls, Pulse Width Modulation) de cada motor. Como os moto-
res no so todos iguais h casos de variao da rota, por exemplo, uma roda pode girar mais
do que a outra e o rob no ir para a direo que deveria. Para tratar este problema cada motor
possui um encoder, um sensor responsvel por enviar o nmero de rotaes do motor para o
microcontrolador.
O controle dos motores um sistema em malha fechada, ou seja, quando o microcon-
trolador envia a velocidade linear para cada motor ele no finaliza o seu controle, pelo contr-
rio, ele aguarda confirmaes do encoder. Como pode ser visto na Figura 19 o comando
passado aos motores, os encoders, por sua vez, monitoram a rotao das rotas e repassam essa
informao ao microcontrolador, que conclui se a rota est de acordo com o que foi definido
pelo tcnico. Portanto quando se trata do controle dos motores, o microcontrolador do segun-
do nvel recebe informao do microcontrolador do primeiro nvel e tambm dos encoders.
52


Figura 19: Vista expandida do controle dos motores.
Os sensores de infravermelho localizados frontalmente so uma das estratgias esco-
lhidas para diminuir o nmero de troca de mensagens entre o rob e o computador tcnico.
Existe uma situao clssica em que o rob est indo em frente e existe um obstculo adiante,
ao invs do rob esperar pela mensagem de que deve desviar, ele mesmo pode chegar a esta
concluso atravs dos sensores frontais.
Se o computador tcnico no possuir a responsabilidade de desvios pode concentrar
suas operaes na realizao de gols e em defesas mais estratgicas. O principal objetivo
que o rob no venha a sofrer nenhuma coliso que possa prejudicar seu estado. O microcon-
trolador do segundo nvel controla essa funo, pois se perceber que pode colidir acionar os
motores para fazer um desvio de rota, assim o prprio sistema gera um comando que se exe-
cutado evita a possvel batida, tornando esse controle de rota mais rpido e eficiente.
4.2 Arquitetura de Software dos Robs da Equipe Ararangu Intruders
Um Sistema de Controle coordena as aes realizadas pelo rob. Toda e qualquer in-
formao, seja recebida ou enviada passa pelo sistema de controle. Na maioria dos casos os
sistemas embarcados presentes nos robs das equipes de futebol de robs so apenas reativos,
reagindo aos comandos recebidos do tcnico, porm, o sistema de controle proposto neste
trabalho possui uma arquitetura hbrida, logo algumas diferenas sero significativas.
O controle de software possui vrias maneiras de ser desenvolvido, como foi detalhado
na Seo 3.2 do Captulo 3. Para o projeto do sistema de controle embarcado dos robs da
Equipe Ararangu Intruders a metodologia escolhida foi a desenvolvida por Carro e Wagner
(2003). O sistema composto pela combinao entre interrupes e tarefas de tempo real.
53

Para um melhor detalhamento do sistema de controle optou-se por compatibilizar a ar-
quitetura de software com a arquitetura de hardware descrita na Seo 4.1. Desta forma as
funes do sistema de controle foram separadas em dois nveis. A Figura 20 ilustra o sistema
de controle projetado em que possvel perceber a diviso das funcionalidades.

Figura 20: Arquitetura de Software dos robs da equipe Ararangu Intruders.
O Controle Nvel 1 possui duas tarefas principais, a Funo 1 responsvel pelo Con-
trole do Sistema de Chute e Domnio de Bola e a Funo 2 responsvel por enviar e receber
mensagens. Alm dessas duas tarefas o Nvel 1 do sistema responsvel por repassar infor-
maes referente a direo e a velocidade linear de cada roda para o Nvel 2 via comunicao
SPI.
O Controle Nvel 2 formado por quatro tarefas, a Funo 1 o Monitor de Bateria, a
Funo 2 o Controle dos Motores, a Funo 3 a Leitura dos Sensores de Infravermelho e a
Funo 4 o Controle Central. Esta ltima Funo possui a mais alta prioridade no sistema e
a partir dela as outras funcionalidades do sistema so ativadas.
No Controle Nvel 1 a Funo 2 de Recepo de Mensagens a que ocupa a maior
parte do processamento, e as outras funcionalidades acontecem a partir dela. Para o sistema de
54

controle ser uma tarefa de tempo real, pois existe um prazo para o comando ser recebido,
interpretado e comunicado, para que depois seja atendido.
As mensagens estaro chegando a todo o momento via rdio, ento o primeiro passo
conhecer em que padro de formatao a mensagem ser enviada do computador tcnico.
Cada equipe projeta o seu prprio protocolo de comunicao, no caso da Equipe Ararangu
Intruders o primeiro dado passado a identificao do rob, porque os comandos so diferen-
tes para cada um, portanto, por mais que o rob capte outras mensagens s pode executar a
que for definida para ele mesmo. Outras informaes que vo presente na mensagem a dire-
o e a velocidade linear de cada um dos motores.
A partir do momento que as mensagens so recebidas pelo sistema de comunicao
devem ser imediatamente interpretadas, se a identificao no for a do rob, a mensagem
ignorada, se for para o rob em questo ela prossegue na interpretao. Entenda-se por co-
mando a parte da mensagem destinada a determinar a ao do rob, portanto, dependendo do
comando a tarefa reagir de maneiras distintas.
Se o comando for para algum direcionamento a Funo 2 repassa essa informao via
comunicao SPI para o Controle Nvel 2, porm, se for para chutar a Funo 2 manda a in-
formao para a Funo 1, que o controle do sistema de chute e domnio de bola.
O domnio de bola muito importante para todos os robs e a maioria das equipes j
possuem esse dispositivo, pois a nica maneira que o rob tem para conseguir conduzir a
bola, portanto, deve ser utilizado sempre que possvel. No interessante manter o domnio
ligado o tempo todo, pelo gasto excessivo de bateria, ento achar o equilbrio para essa funci-
onalidade fundamental, e o encontrado nesse projeto foi o uso de uma interrupo, ou seja,
assim que o sensor 1 indicar a presena da bola a interrupo acionada e ento o motor que
controla o rolete de domnio ligado.
A partir do momento em que a bola est dominada o computador tcnico pode esco-
lher o momento adequado para chutar, portanto este um comando recebido pelo rdio.
Quando a mensagem de chute for interpretada o microcontrolador ativar o sistema de chute.
No controle Nvel 2 a Funo 1, Controle do Nvel de Bateria, ser uma tarefa que
monitorar periodicamente a bateria. Foi escolhido designar essa funo como uma tarefa,
pois a bateria no precisa ser monitorada constantemente, apenas em alguns momentos, assim
a tarefa ter um intervalo grande entre uma verificao e outra.
55

A Funo 2, Controle dos Motores, uma funo auxiliar que levar em conta duas
entradas, o comando que ser passado pela chamada da funo e a informao vinda dos en-
coders. Inicialmente ocorrer a interpretao do comando para o correto acionamento dos
motores. As informaes lidas a partir dos encoders so consideradas para o sistema fazer
eventuais correes de rotas.
Fazer o controle da rota identificar, atravs das informaes dos encoders, se as ro-
das esto na rotao correta, ou seja, a rotao que deveriam estar para executar o comando
desejado. Portanto, a funo deve calcular o que fazer para corrigir a rota, reenviando a in-
formao aos motores para que a execuo do comando seja adequada.
Como a velocidade dos motores no ser necessariamente a mesma em todos os mo-
mentos, o meio mais rpido de controlar a rota acelerar ou desacelerar a roda que est reali-
zando o desvio. Por exemplo, se o rob deveria ir em frente e na prtica est em uma linha
diagonal direita, porque a roda da esquerda est girando com mais velocidade que a da
direita, assim deve-se, ou acelerar a roda direita ou desacelerar a esquerda.
Para resolver essa situao ser utilizado o controle PID (Proporcional Integral Deriva-
tivo) de maneira que o valor desejado comparado com o valor da atuao da varivel do
processo atual. O que indica que ele controla as rodas, como foi descrito anteriormente, com-
parando a sada atual com a desejada pelo Controle de Nvel 2.
Esta escolha de acelerao ou desacelerao definida a partir dos limites abrangidos
pela velocidade, isto ocorre porque se a roda direita j est em rotao mxima e ainda est
mais devagar que a esquerda o possvel a desacelerao do lado esquerdo. A ao comanda-
do pela funo Controle dos Motores continuar sendo a mesma, porm a velocidade repassa-
da para cada motor sofrer as alteraes segundo o que for interpretado dos encoders.
A Funo 3, Leitura dos Sensores de Infravermelho, foi projetada como uma interrup-
o. O sistema precisa dessa funcionalidade para no depender do computador tcnico para
desviar dos outros robs ou outros obstculos.
A interrupo ocorre assim que os sensores captarem a existncia de algum obstculo
a frente, por ser uma interrupo ser tratada imediatamente, o comando de desvio para os
motores ser gerado automaticamente e executado, depois de no haver mais obstculos o
comando enviado pelo computador tcnico volta a ser executado. Portanto nesse momento, a
informao do rob executada independente do controle do sistema estrategista, por mais
56

que ele tenha enviado o comando de ir para frente, o rob atender primeiramente seus senso-
res, para depois executar o comando.
Para evitar que o rob entenda a bola como um obstculo e acabe desviando dela ao
invs de domin-la e executar a jogada de acordo com o computador tcnico, foi definido que
sempre que a bola passasse na frente dos robs o computador tcnico enviaria uma mensagem
alertando sobre essa situao. Portanto essa interrupo gerada pelos sensores s seria tratada
se no houvesse a mensagem referindo-se a proximidade da bola.
A Funo 4, Controle Central, uma funo especial que rege todo o Controle Nvel
2, ela que receber as mensagens vindas da comunicao SPI e chamar a funo de Contro-
le dos Motores, tambm ela que tratar a interrupo vinda da Leitura dos Sensores de In-
fravermelho. A Funo 4 somente sai de execuo quando precisa ceder processamento para o
Monitor de Bateria.
O Controle Central o responsvel por chamar a Funo 2 e passar para ela o que
deve ser feito. O que deve ser feito depende da informao que foi recebida da comunicao
com o Controle Nvel 1, porm caso a Funo 3 seja ativada, a informao que ser passada
para a Funo 2 ser gerada pelo prprio Controle Central para desviar do obstculo encon-
trado. A Funo 4 torna o rob mais ativo dentro de campo, j que tem autonomia para, em
certos momentos, decidir no fazer o que o computador tcnico mandou, mas sim, executar
aes de acordo com as informaes percebidas pelo rob.
57

5 ANLISE DO SISTEMA DE CONTROLE
Este captulo analisa o sistema de controle descrito no Captulo 4. Detalha o desenvolvimento
e os resultados atingidos separadamente no Controle de Nvel 1 e 2 do sistema. Tambm faz a
comparao entre o sistema ideal e o realizado neste trabalho.
5.1. Controle de Nvel 1
O controle de Nvel 1 a parte do sistema embarcado que possui arquitetura de sof-
tware hierrquica, como visto no Captulo 2, na Seo 2.2. nessa parte do sistema que ficam
as tarefas de tempo real, que controlaro, conforme o Captulo 4, Seo 4.2, a recepo das
mensagens recebidas do Computador Tcnico, e o monitoramento da bateria. Maiores deta-
lhes das tarefas podem ser visualizadas na Tabela 3.
Tabela 3: Caractersticas das Tarefas de Tempo Real do Sistema Embarcado.
Tarefa Perodo Prazo
Simula_radio 5 ms 5 ms
Monitor_de_bateria 10 s 5 ms

Os nomes expostos na primeira coluna da Tabela 3 so nomes correspondentes aos pa-
rmetros das funes de tempo real do RTOS. Perodo corresponde ao Rate que um parme-
tro das diretivas do RTOS (Sistema Operacional de Tempo Real, do Ingls Real Time Opera-
tion System), ele delimita o prazo mximo que a tarefa deve entrar em execuo, ou seja, a
tarefa simula_radio deve entrar em execuo uma vez a cada cinco milissegundos. E a tercei-
ra coluna Prazo correspondente ao parmetro Max, que indica qual o tempo mximo que a
tarefa ficar executando, quanto tempo ela usar o processador. Mais informaes a respeito
do RTOS do CCS podem ser vistas no Apndice I.
58

Na Figura 21 pode ser visualizada o esquemtico da simulao no Proteus do sistema
que cabe ao controle do Nvel 1. Existe um microcontrolador PIC18F452 que controla as fun-
es do Monitor de Bateria que composto pelo conjunto da bateria, os trs LEDs (Diodo
Emissor de Luz, do Ingls, Light Emitting Diode) ligados as portas D0 a D2 do microcontro-
lador e o LCD (Display de Cristal Lquido, do Ingls Liquid Crystal Display); Sistema de
Chute que representado por um LED ligado ao pino B6; e o Sistema de Domnio de Bola
formado por um conjunto de LEDs mais boto, ligados respectivamente aos pinos B5 e B0.

Figura 21: Esquemtico da simulao do controle de Nvel 1.
Em um sistema ideal o Controle de Nvel 1 analisa o monitor de bateria para que
quando este perceber a bateria em um nvel crtico mande uma mensagem via rdio para o
computador tcnico. Porm, no caso da simulao foi utilizado para representar esta mensa-
gem de retorno o LCD e trs LEDs, quando a bateria estiver com a capacidade reduzida, os
LEDs sero ligados e ser impresso uma mensagem no LCD informando o nvel da bateria.
O monitor de bateria visto pelo sistema como uma tarefa que entra em execuo uma
vez a cada dez segundos, este um tempo suficiente para o monitoramento de bateria, j que
os robs precisam ser dotados de baterias potentes, sendo assim, no mudam significativa-
mente seu estado dentro de dez segundos. Assim, conforme o nvel de bateria for baixando o
59

sistema emitir um aviso, se o nvel for crtico o sistema embarcado pode chegar ao ponto de
no executar alguns comandos vindos do computador tcnico.
O sistema de chute est sendo representado por um LED, no caso de um rob real ao
invs do acionamento direto do LED quando a mensagem recebida for de chute, a interrupo
ser ativada e o solenoide ser acionado. Quanto ao domnio, ao invs de um boto ativar a
interrupo externa, ser o sensor de infravermelho, e o que ser acionado no ser um LED,
mas sim um motor que far girar o rolete de domnio, mantendo a bola prxima.
Quanto ao fluxo da informao no sistema embarcado importante salientar que, por
no existirem no Proteus mdulos de rdio que pudessem representar fielmente o sistema, foi
utilizada uma funo que gera nmeros aleatrios, a partir desses nmeros o sistema carrega
uma mensagem e a repassa para outra funo para que essa repasse o comando, via comuni-
cao SPI para o Controle Nvel 2. Se a mensagem gerada for a de chute, o Controle de Nvel
1 se encarregar de ativar o sistema de chute ao invs de repass-la ao Controle de Nvel 2.
A funo simula_radio uma tarefa para o sistema, ela entra em execuo uma vez a
cada cinco milissegundos. Esse tempo no pode ser considerado pelo sistema como um atra-
so, visto que o tempo para que o rob execute o ltimo comando maior do que o perodo em
que a tarefa no est executando.

Figura 22: Funo de Simulao do Rdio e Comunicao SPI.
60

Na Figura 22 pode ser visualizada a funo que simula a execuo do rdio e seu tra-
tamento, no caso desta simulao as mensagens j esto prontas e apenas so escolhidas de
acordo com o nmero gerado aleatoriamente. A funo comunicao_spi aproxima-se do sis-
tema ideal, visto que filtra a mensagem antes de repass-la e se no for o comando de chute, a
repassa atravs da funo spi_write, como seria em um sistema real.
5.2. Controle de Nvel 2
O controle de Nvel 2 a parte do sistema embarcado que possui arquitetura de sof-
tware reativa. nessa parte do sistema que ficam as relaes do rob com o meio, relaes
provindas das entradas do rob, ou seja, a qualquer contato externo com o ambiente. impor-
tante salientar que esse contato externo pode vir dos sensores ou do comando recebido do
Controle Nvel 1, que por sua vez a mensagem interpretada do Computador Tcnico.
A Figura 23 ilustra o esquemtico da simulao no Proteus do sistema que cabe ao
controle do Nvel 2. Existe um microcontrolador PIC18F452 que controla, o sinal dos senso-
res infravermelho que tem o objetivo de evitar colises, essa funcionalidade composta por
dois botes ligados, respectivamente aos pinos B0 e B1, e o sistema dos atuadores, formado
por 8 LEDS, ligados aos pinos D0 a D7.

Figura 23: Esquemtico da simulao do controle de Nvel 2.
61

Os sensores de infravermelho so os sensores ideias para reconhecimento do ambiente,
no caso dessa categoria do futebol de robs, seria bem adequado o recebimento e interpreta-
o do sinal, visto que o nmero de colises seria muito reduzido. Para representar esse sis-
tema foram utilizados dois botes, quando pressionados o sistema os trata da mesma maneira
que trataria o sinal vindo do sensor.
Neste prottipo foram utilizados dois botes para simular os dois sensores que ficam
nas laterais do rob. Se o sensor da esquerda captar alguma proximidade o sistema Nvel 2 ir
controlar os atuadores para irem a direita. Se for captado algo no sensor direito os atuadores
iro a esquerda, se ambos estiverem pressionados a mensagem repassada a funo de Controle
Central ser ir para trs. Neste caso, o boto, ao ser pressionado, caracteriza a aproximao de
algo a cerca de 5 cm de distncia no sistema real.
Como no caso da simulao no existe a possibilidade de ambos os botes serem pres-
sionados ao mesmo tempo, foram feitas duas interrupes externas e cada uma muda a men-
sagem de comando de acordo com a posio do seu sensor. Por terem sido utilizadas interrup-
es externas, foi analisada a arquitetura do microcontrolador PIC18F452 para verificar quais
eram os pinos com essa funcionalidade, atestou-se que eram os pinos da Porta B, por isso os
botes foram colocados nos pinos B0 e B1.
Quanto ao sistema dos atuadores, parte-se do princpio que um motor tem sempre dois
sentidos para girar a roda qual est ligado, portanto foi utilizado dois LEDs para representar
cada sentido do motor. Por exemplo, os LEDs ligados aos pinos D0 e D1 representam os dois
sentidos possveis de rotao do Motor 1 e isso ocorre na representao de todos os quatro
motores. Os motores so distribudos no rob segundo a Figura 24.

Figura 24: Esquema de posicionamento das rodas e motores no rob.
62

E para interpretar os resultados da simulao pode-se consultar a Tabela 4, que de-
monstra a combinao de cores visualizada no simulador e qual a direo representa para um
rob real. Foram apresentadas apenas as principais direes, porm possvel desenvolver
vrias direes, j que as rodas do rob so holonmicas.
Tabela 4: Relao de cores dos LEDS com direo dos motores presentes na simulao.
Motor 1 Motor 2 Motor 3 Motor 4
Frente Trs Frente Trs Frente Trs Frente Trs
R
o
b


Frente








Trs








Direita






Esquerda








O Controle Nvel 2 tem seu fluxo de informao relacionado a funo contro-
le_central. Isso porque esta funo tem como parmetro o comando que deve ser executado e
ento dispara as funes de controle dos atuadores de acordo com esse comando.
A funo que recebe as mensagens diretamente do Controle Nvel 1 a le_msg, esta
funo recebe via spi o comando e o interpreta, determinando qual a ao que deve ser rea-
lizada. A partir disso ela chama a funo controle_central passando por parmetro uma vari-
vel carregada do valor referente a ao que deve ser efetuada. Por sua vez, a funo contro-
le_central entra em execuo, interpreta o valor do parmetro e executa a ao corresponden-
te, como pode ser visualizado na Figura 25.
63


Figura 25: Funes de Controle.
A funo controle_central tambm executada pelo tratador de interrupes, o que
ocorre que quando uma interrupo acionada, ela carrega a varivel msg com o comando
que vai satisfazer o tratamento da interrupo e chama a funo controle_central. Ou seja, se
o sensor esquerdo, ou o boto ligado ao pino B0, for ativado, o rob deve ir para a direita,
ento a varivel msg carregada com o valor 3 e a funo controle_central chamada, como
seu parmetro est selecionado com o valor 3, chamada a funo de controle dos atuadores
para ir a direita.
A funo controle_central chamada, portanto, pelos tratadores das interrupes,
como pode ser visualizado na Figura 26, ou pela funo le_msg que a recebedora dos co-
mandos via SPI, que por sua vez, so os comandos vindos do computador tcnico.
64


Figura 26: Tratamento das Interrupes.
Como havia sido descrito no Captulo 4, os sensores sero tratados com prioridade
em relao ao comando do sistema estrategista, visto que esta uma forma de minimizar o
nmero de mensagens e de proteger o rob. Portanto o controle dos sensores feito por inter-
rupes e os comandos do tcnico so tratados por uma funo que executada dentro do lao
while(1).


65

6 CONSIDERAES FINAIS E PROPOSTAS PARA TRABA-
LHOS FUTUROS
Neste trabalho foi apresentado o sistema de controle embarcado desenvolvido para a
Equipe de Futebol de Robs Ararangu Intruders. O sistema desenvolvido tinha o objetivo de
tornar o rob um agente ativo, ou seja, com mais responsabilidades do que comumente acon-
tece no futebol de robs.
Para tornar o rob um jogador participativo ao invs de apenas reativo foi desenvol-
vido um sistema de controle embarcado que levasse em considerao no apenas informaes
advindas do computador tcnico, mas tambm informaes internas e externas lidas dos sen-
sores embarcados no rob.
O sistema embarcado visa auxiliar o computador tcnico no objetivo de vencer o jogo,
para isso assumiu maiores responsabilidades, mas qualquer atitude realizada no pelo bem
de um rob, mas sim da equipe. Dessa maneira pode-se perceber, que mesmo dotado de sen-
sores e tendo um papel mais ativo em campo, o sistema embarcado submete-se estratgia do
computador tcnico.
Pelo fato do futebol de robs ser um ambiente dinmico, todas as aes e reaes dos
robs ocorrem muito rapidamente, por conta disso, o sistema embarcado deve conciliar a
quantidade de informaes de entrada com as aes de sadas que devem ser condizentes com
a estratgia da equipe.
As mensagens recebidas do computador tcnico so muito constantes, mesmo assim
o sistema embarcado conseguiu gerenciar os comandos e executou cada um deles. Mesmo
tratando as informaes vindas dos sensores, a capacidade computacional do microcontrola-
dor deu ao rob o tempo suficiente para executar tanto o controle dos sensores e dos atuado-
res, quanto receber e agir de acordo com as mensagens do computador tcnico.
66

As tarefas de tempo real foram imprescindveis para a adequada recepo das men-
sagens, percebe-se que a partir dos resultados, o tempo de envio de mensagem do computador
tcnico maior do que o perodo em que a tarefa no est executando.
O sistema embarcado cumpriu com os requisitos bsicos de controle que se resumi-
am em executar adequadamente as aes recebidas e superou o que era pretendido quanto ao
tratamento de sensores. Dotar o rob de mais fontes de informao fortaleceu o sistema em-
barcado e tambm o computador tcnico, porque algumas responsabilidades passaram do con-
trole do sistema externo para o interno.
O sistema demonstrou interdependncia para com o computador tcnico ao invs da
dependncia comum categoria. E atestou-se que, nesse projeto o nico tipo de mensagem
que foi trocado entre o computador tcnico e o rob foram as aes que compe a estratgia
para fazer o gol, atingindo o objetivo de manter a troca de mensagens no menor nvel poss-
vel.
Assim a capacidade de processamento do computador tcnico ficou mais focada na
interpretao dos dados provenientes do sistema de viso e consequentemente na gerao de
estratgias, fazendo com que a equipe se torne mais competitiva.
6.1. Propostas para Trabalhos Futuros
Nesta Seo so listadas algumas propostas para trabalhos futuros.
1) Testar o sistema implementado nos robs reais;
2) Comparar a arquitetura proposta e os resultados apresentados com outros sis-
temas embarcados com arquitetura reativa, que no utilizam tarefas de tempo
real e diferentes nveis de controle.
3) Usar um sistema operacional embarcado para gerenciar as tarefas de tempo re-
al;
4) Comparar os resultados, principalmente o tempo de resposta, entre o sistema
embarcado proposto e os obtido com o uso de um sistema operacional embar-
cado.
67

REFERNCIAS
ARARANGU INTRUDERS. Misso. Disponvel em:
http://www.araranguaintruders.ufsc.br/ Acessado em: 10 out, 2012.
BENINI, Luca; MICHELI, Giovanni. Networks on chips: A new SoC paradigm. Computer,
v. 35, n. 1, p. 70-78, 2002.
BIAZUZ, Claudio J. Desenvolvimento de uma Arquitetura Hbrida e Distribuda para
Sistemas Multiagentes e sua Aplicao no Futebol de Robs. Dissertao (Mestrado)
Curso de Cincia da Computao, Universidade Federal de Santa Catarina, Florianpolis,
2008.
BORGES, Rodrigo W. Aplicabilidade de Sistemas Operacionais de Tempo Real (RTOS)
para sistemas embarcados de baixo custo e pequeno porte. Dissertao (Mestrado) Cur-
so de Cincias, Programa de Engenharia Eltrica, Universidade de So Paulo, So Carlos,
2011.
BOSA, Jefferson L. Sistema Embarcado para a Manuteno Inteligente de Atuadores
Eltricos. Dissertao (Mestrado) - Curso de Cincia da Computao, Universidade Federal
do Rio Grande do Sul, Porto Alegre, 2009.
CAMPBELL, Murray; HOANE, Joseph A. J; HSU, Feng-hsiung. Deep Blue. Artificial Intel-
ligence, , v. 134, n. 1, p. 57-83, 2002.
CARRO, Luigi; WAGNER, Flvio Rech. Sistemas computacionais embarcados. Jornadas
de atualizao em informtica. Campinas: UNICAMP, 2003.
CHENG, Gordon; ZELINSKY, Alexander. Supervised autonomy: A framework for human-
robot systems development. Autonomous Robots, v. 10, n. 3, p. 251-266, 2001.
CMP United Business Media. 2006 Embedded System Design State of Embedded Market
Survey. Pesquisa de Mercado, CMP United Business Media, 2006.
COSTA, Anna Helena Reali; PEGORARO, Ren. Construindo robs autnomos para par-
tidas de futebol: o time GUARAN. SBA Controle & Automao, Campinas, 2000.
DUDEK, Gregory; JENKIN, Michael. Computational principles of mobile robotics. Cam-
bridge University Press, 2010.
68

FERREIRA, Ivo A; Sistema de Controle e Superviso de Sistemas Embebidos: Tipo
SCADA. Dissertao (Mestrado) Curso de Engenharia Eltrica e de Computadores, Univer-
sidade do Porto, Porto, 2008.
GERVINI, Alexandre I. et al. Avaliao de Desempenho, rea e Potncia de Mecanismos
de Comunicao em Sistemas Embarcados. SEMISH'03XXX Seminrio Integrado de
Software e Hardware, 2003.
KRAETZCHMAR, G. et al. The ULM Sparrows: Research into Sensorimotor Integration,
Agency, Learning, and Multiagent Cooperation. ROBOCUP WORKSHOP. 1998
MACKWORTH, Alan, K. 1993. On seeing robots. Computer Vision: Systems, Theory, and
Applications, World Scientific Press: Singapore, pp. 113.
MACHADO, Guilherme Bertoni; SIQUEIRA, Frank. Integrao de Sistemas Embutidos
utilizando Web Services. Universidade Federal de Santa Catarina, 2004.
MAETA, Silvio M. Desenvolvimento da Infraestrutura Embarcada do Projeto AURO-
RA. Dissertao (Mestrado) Curso de Cincia da Computao, Universidade Estadual de
Campinas, Campinas, 2001.
MARWEDEL, Peter. Embedded system design: Embedded systems foundations of cyber-
physical systems. Springer, 2010.
MURPHY, Robin R. Introduction to AI Robotics. The MIT Press: London, England, 2000.
NOERGAARD, Tammy. Embedded System Architecture A comprehensive guide for engi-
neers and programmers. Newnes, 2005.
NOVAK, Gregor; SPRINGER, Richard. An I ntroduction to a Vision System used for a Mir-
oSOT Robot Soccer System. IEEE International Conference on Computational Cybernetics,
2004.
PAZOS, Fernando. Automao de Sistemas e Robtica. Editora Axcel, 2002.
ROBOCUP; KITANO, Hiroaki (ed). Robocup-97: Robot Soccer World Cup I. Springer,
1998.
RUSSEL, Stuart; NORVIG, Peter. Inteligncia Artificial. Editora Campus, 2004.
SALIM, Antonio; FUENTES, Olac; MUNZ, Anglica. Development of Local Vision-based
Behaviors for a Robotic Soccer Player. IEEE. Anais da Quinta Conferncia do Mxico em
Cincia da Computao, 2004.
SAHOTA, M. K. & MACKWORTH, A. K. Can Situated Robots Play Soccer? Anais da Inte-
ligncia Artificial Canadense, 1994.
SANTOS, Tlio L. Desenvolvimento de um Sistema Embarcado para Medio de Cor-
rente. Dissertao (Mestrado) Curso de Engenharia Eltrica, Universidade Federal de Santa
Catarina, Florianpolis, 2010.
69

SHAW, Alan C. Sistemas e Software de Tempo Real, 2001. Porto Alegre. Editora Book-
man.
SIEGWART, Roland; NOURBAKHSH, Illah R. Introduction to Autonomous Mobile Ro-
bots. 2004
SOBREIRA, Rodolfo M; SILVA, Francisco A; ROS, Renato L. Futebol de Robs, uma
aplicao de robtica. 2003.
TAURION, Cezar. Software embarcado: oportunidades e potencial de mercado. Rio de Ja-
neiro. Brasport, 2005.
VIANNA, Alexandre SG; MACHADO, Liliane S. Controle e Gerenciamento de Ambien-
tes Reais Educacionais Atravs de Ambientes Virtuais. International Conference on Engi-
neering and Computer Education (ICECE2009), Buenos Aires, Argentina. 2009.
WEISER, Mark., The Computer for the 21st Century. Scientific American, 1991.
WOLF, Wayne. Computers as Components: Principles of embedded computing system de-
sign. 2001
70

APNDICE I
Neste apndice so apresentadas mais informaes sobre tarefas de tempo real utili-
zadas pelo compilador CCS. Para um melhor entendimento foi elaborado um exemplo que
compara um programa com funes sem o uso de tempo real e um programa com tarefas de
tempo real.
As tarefas de tempo real so utilizadas em situaes onde vrias funcionalidades de
um programa devem entrar em execuo dentro de um prazo especfico. O RTOS possui um
ncleo central que se assemelha ao kernel de um SO, ele o encarregado por controlar a exe-
cuo das tarefas, se houver mais de uma tarefa, ele deve selecionar a tarefa que ser executa-
da segundo critrios estabelecidos no desenvolvimento da tarefa pelo programador.
O RTOS utilizado pelo compilador CCS permite que o microcontrolador PIC seja
dotado de um sistema embarcado que possua tarefas de tempo real. Para tanto, so necessrias
algumas diretivas inicias para a execuo das tarefas. A primeira a diretiva de pr-
processamento de delimitao de prazos e tempo de processamento #USE RTOS na qual os
parmetros em questo so o timer e o minor_cicle que delimitam o menor ciclo de execuo
do RTOS.
Para o sistema, as tarefas so simples funes, porm, acima da sua assinatura inicial
possui uma linha de cdigo que determina que a funo a seguir ser uma tarefa. As funes
que sero consideradas tarefas no devem ter nenhum parmetro alm dos especficos para o
ncleo do RTOS e tambm no devem ter retorno.
Deve-se utilizar a diretiva de pr-processamento #TASK, com os parmetros rate,
max, queue que informam, respectivamente o prazo de execuo da tarefa, quantas vezes ela
deve entrar em execuo dentro de um espao determinado de tempo, o tempo mximo de
execuo que ela pode atingir e quantos bytes sero alocados para as mensagens recebidas da
tarefa, por padro utilizado zero.
71

Depois de utilizar as duas diretivas acima e determinar quais funes sero tarefas de
tempo real, basta realizar a chamada da funo rtos_run que coloca em execuo o RTOS do
CCS.
Da mesma maneira que a execuo das tarefas de tempo real so acionadas pela fun-
o rtos_run, elas tambm podem ser encerradas durante a execuo de um programa. Se o
sistema embarcado contiver tarefas de tempo real e funes, as tarefas de tempo real so exe-
cutadas e depois de finalizadas, so encerradas, para que outras funcionalidades do programa
entrem em execuo. Para isso deve-se utilizar a funo rtos_terminate que encerra a execu-
o do ncleo do RTOS.
As tarefas de tempo real esto sempre relacionadas a prazos especficos, porm atra-
vs da funo rtos_await(Expre) uma tarefa de tempo real pode ficar em estado de espera.
Nesse caso, a tarefa finalizada, deixando o processador livre, caso seu parmetro, a expres-
so lgica Expre seja verdadeiro, ela volta a executar para ento finalizar completamente.
Para um melhor entendimento do RTOS do CCS foi desenvolvido um programa que
controla trs LEDS, conforme esquemtico da Figura 27. O programa dispe de uma organi-
zao totalmente distinta, usando funes executadas a partir da funo main() ou tarefas de
tempo real executadas pelo funo rtos_run().

Figura 27: Esquemtico do programa de exemplo.
72

A Figura 28 ilustra o cdigo fonte do sistema embarcado para ligar os trs LEDs.
Neste caso, o programa foi desenvolvido somente com funes, ou seja, no utilizada ne-
nhuma tarefa de tempo real. Cada funo do sistema entra em execuo seguindo a ordem em
que foram especificadas na funo main().

Figura 28: Programa para aceder trs LEDs sem o uso de funes de tempo real.
Pode ser notado que as chamadas das funes so feitas pela funo principal do
programa, a funo main(), porm, o cdigo se torna menos organizado, com mais dificulda-
des de manuteno, e tambm no supre algumas necessidades, como no caso em que os trs
LEDs necessitassem ser acessos ao mesmo tempo. A maior diferena encontrada entre as fun-
es e as tarefas de tempo real a certeza da execuo dentro de prazos especficos. Se as
funcionalidades devem ser tratadas de forma peridica pode-se utilizar timers e interrupes,
porm o controle sobre todas as funes se torna muito mais difcil para o programador, j
que os clculos de execuo de cada tarefa devem ser projetados por ele para que no entrem
em conflito.
No caso do RTOS as tarefas vo sendo simplesmente lanadas com seus respectivos
parmetros, e a execuo dessas tarefas ser responsabilidade do RTOS. O mesmo programa
desenvolvido para o exemplo da Figura 28 foi adaptado para usar tarefas de tempo real. A
Figura 29 ilustra o programa desenvolvido com o uso de tarefas de tempo real que so respon-
sveis por acender os LEDs.
73


Figura 29: Programa para aceder trs LEDs com o uso de funes de tempo real.
As tarefas entram em execuo dentro do seu prprio prazo obedecendo as restries
de prazo estipulado no programa.
74



Concede-se Universidade Federal de Santa Catarina UFSC, a permisso para reproduzir
cpias deste trabalho e emprest-las to somente para propsitos acadmicos e cientficos.
Direitos reservados. Leis 9.609/98 e 9.610/98. Autoriza-se copia, para utilizao exclusiva-
mente com finalidade didtica, desde que com a citao da fonte.
____________________________________
Autor
Freitas, Stfani A. G.
Tipo do Trabalho
Ararangu, __/__/ 2012.
n pg.

Você também pode gostar