Automodelo de Controle Remoto Controlado por Acelerômetros
Henrique Martins1 & Leandro Piqueira2.
Orientador: Prof. Renato Giacomini.
TG-01-2012-EP
1,2
Graduandos do Curso de Engenharia da Computação da USJT, turma de 2012.
e-mail1:[email protected]; e-mail2: [email protected]
Resumo -. Este trabalho descreve o uso de dispositivos móveis comerciais (terminais de telefonia celular)
aplicados ao controle de um automodelo. Os dispositivos são utilizados sem nenhuma alteração de hardware, de
forma que seu uso não fica restrito à aplicação. O automodelo é controlado através do acelerômetro integrado a
um dos dispositivos, o dispositivo de operação, dotado de Sistema Operacional (SO) Android. Os dados de
controle trafegam em rede Wi-fi e são entregues ao outro dispositivo móvel, também com sistema operacional
Android, que está acoplado ao automodelo. Os comandos são repassados então via comunicação Bluetooth a
uma placa eletrônica, que aciona os motores do automodelo. O dispositivo de operação exibe imagens de vídeo
capturadas do dispositivo acoplado ao automodelo, o que possibilita monitorar o percurso do automodelo mesmo
sem estar próximo a ele. Neste artigo será relatado como é possível a integração entre esses dispositivos e a
possibilidade de se usar o sistema operacional Android para integrar sistemas tão complexos e poderosos como
smartphones com motores elétricos e outras cargas.
Abstract -. This paper describes the use of commercial mobile devices (mobile terminals) applied to control an
automodel. The devices are used without any hardware modification, so that its use will not be restricted to the
application. The automodel is controlled by the integrated accelerometer of one of the devices, the operational
device, with Operational System (OS) Android. The control data travels over Wifi Network and are shipped to
the other mobile device, with Android operational system too, that is attached to the automodel. The commands
are forwarded through Bluetooth communication to an electronic board, which drives the automodel motors. The
operational device shows video frames captured from the device attached to the automodel, this allow to
monitoring the automodel route even without being close to it. In this paper will be reported how is possible the
integration between this devices and the possibility to use Android operational system to integrate complex
systems and powerful smartphones with electric motors and another loads.
(Palavras-chave: Android, Acelerômetro, Wifi, Bluetooth, Arduino)
Introdução
Controlar um automodelo é uma tarefa
relativamente simples. Uma implementação com
dispositivos de Radio Frequência e alguns botões
(push bottons) permite criar um controle com cerca
de 20 metros de alcance. Porém, adotar uma
abordagem diferente torna mais interessante a
criação desse controle, tanto do ponto de vista de
custo, como de desempenho. Utilizar outro meio de
comunicação do controle com o automodelo como,
por exemplo, uma rede Ethernet Wifi, deve levar
em consideração o custo de processamento e do
protocolo de comunicação requerido, pois pode
haver certa morosidade na comunicação entre os
dispositivos. Porém, se o objetivo do automodelo
não requerer altas velocidades e atuação em tempo
real restrito, utilizar esse meio traz benefícios.
Redes Ethernet Wifi possuem um alcance de cerca
de 250 metros. Uma vantagem dessas redes é a
capacidade de estendê-las por repetidores ou, até
mesmo, por Access Points (dispositivo em uma
rede sem fio que realiza a interconexão entre todos
os dispositivos móveis) interconectados como, por
exemplo, em uma rede Wifi de um grande edifício
corporativo.
Para controlar um automodelo pode-se
desenvolver um controle capaz de simular um
volante, ou seja, os comandos laterais (esquerda e
direita) podem ser gerados pela inclinação do
controle. Os dados de inclinação podem ser
fornecidos por algum sensor capaz de medir a
inclinação de um eixo perpendicular ao eixo da
aceleração da gravidade.
Acelerômetros são sensores capazes de
medir a aceleração em até três eixos no espaço.
Esses sensores permitem que dispositivos possam
se basear na aceleração da gravidade para obter
uma referência de seu posicionamento.
Smartphones vêm se popularizando muito
nos últimos anos, evoluindo cada vez mais e
sempre com recursos que tornam a interação do
usuário com o dispositivo uma experiência menos
virtual e mais realista. Recursos como
acelerômetros, giroscópios, acesso a redes Ethernet
Wifi, Bluetooth, GPS e câmera de vídeo tornaram
simples celulares poderosas máquinas portáteis. O
Android, Sistema Operacional para dispositivos
móveis desenvolvido pela Google, integra com
excelência os recursos desses dispositivos e permite
a programadores desenvolverem softwares que
acessam e utilizam esses recursos de maneira
rápida, simples e objetiva.
É possível a utilização de Smartphones
para o controle de um automodelo valendo-se de
seus recursos de conexão à redes Ethernet Wifi e
captura dos dados de seu acelerômetro integrado.
Esse artigo apresenta o desenvolvimento
de um controle para um automodelo com
acelerômetro e comunicação por redes Ethernet
Wifi utilizando dispositivos móveis com Sistema
Operacional Android e seus recursos.
Motivação
O interesse pelo trabalho, da forma como foi
concebido está relacionado tanto ao aspecto social
quanto à questão de sustentabilidade. Por um lado,
demonstrar ao público a aplicabilidade de
Smartphones Android, normalmente utilizados e
adquiridos para sua finalidade fundamental de
comunicação e encorajar desenvolvedores a criar
soluções que contribuam para sociedade como um
todo. Por outro, otimizar o uso de energia,
utilizando um sistema (máquina e sistema
operacional) que são em essência desenvolvidos
visando ao baixo consumo. O Android é um
Sistema Operacional criado para equipamentos de
baixo consumo de energia elétrica. Este Sistema
Operacional foi concebido para gerenciar recursos
de maneira a economizar o máximo de energia
possível, maximizando a autonomia dos
dispositivos móveis em que é aplicado.
Expandir o domínio de aplicações para
Smartphones ajuda na diminuição de geração de
lixo eletrônico, pois torna desnecessários
dispositivos caros para realizar tarefas específicas.
A ideia para o controle de um automodelo
utilizando acelerômetros integrados a um
dispositivo com SO Android surgiu graças a um
jogo de corrida para Android chamado GT Racing:
Motor Academy, desenvolvido pela Gameloft, no
qual o veículo é conduzido através dos
acelerômetros do dispositivo com SO Android.
Essa ideia já havia sido explorada e inclusive em
carros de Formula 1. Desenvolvedores utilizaram
conceitos semelhantes ao deste projeto para o
desenvolvimento
de
um
aplicativo
para
Smarthphones capaz de controlar um automodelo a
partir do acelerômetro integrado ao dispositivo.
Esse projeto foi modificado por engenheiros da
escuderia MacLaren e, assim, foi possível que o
piloto Lewis Hamilton controlasse uma MacLaren
sem estar em seu cockpit.
Metodologia
Para montagem do automodelo os
componentes principais utilizados foram:
• Chassi de um automodelo radio controlado
com, apenas, motor DC 12V de tração
traseira e rodas;
• Suporte automotivo de GPS para suportar
o dispositivo Android embarcado;
• Placa microcontroladora ( no protótipo,
uma
placa
Arduino
Uno
com
Microcontrolador ATMega328);
• Módulo Bluetooth (EGBT-046S);
• Atuador em ponte H (CI Ponte-H L293D);
• 2 Smartphones com Sistema Operacional
Android 2.2 ou superior;
• Servomotor (Futaba S3004);
Montagem
•
Arduino: Parafusado o chassi do
automodelo. Foi montada uma protoshield
sobre o Arduino para facilitar a instalação
dos componentes eletrônicos.
•
Servomotor: Acoplado ao chassi do
automodelo. Alimentação ligada na saída
de 5v do próprio Arduino.
•
Ponte H (CI L293D): Para alimentação do
CI foi utilizada a saída de 5V do próprio
Arduino. Ao pino Vs (Supply Voltage), de
alimentação do Motor DC, foi conectada
uma fonte de 12V composta por 8 pilhas
alcalinas comuns. Dois pinos de entrada
foram conectados a duas saídas digitais do
Arduino para o chaveamento dessas
(saídas que fornecerão 12V ao Motor DC).
•
Motor DC: Cabos de alimentação do
Motor foram conectados as saídas do CI
L293D (mencionados no item anterior).
•
Módulo Bluetooth (EGBT-046S): Para
alimentação do módulo foi utilizada a
saída de 5V do próprio Arduino. O
módulo foi conectado aos pinos Rx/Tx de
comunicação via Serial RS232 com o
Arduino.
Controle de Motor DC com Arduino e Ponte
H
Os pinos de entrada da ponte H são
controlados pelos pinos de saídas digitais do
Arduino. De acordo com o nível lógico nessas
entradas são definidos os valores das saídas
conectadas ao Motor DC. Por exemplo: Se o nível
lógico na Entrada1 for 1, e na Entrada2 for 0, a
tensão na Saída1 será Vs (Suply Voltage) e na
Saída2 será 0 (neutro) e vice-versa.
As saídas digitais do Arduino são capazes
de fornecer um sinal PWM (Pulse Width
Modulation) que possibilita o controle da largura do
pulso fornecido periodicamente. Com isso é
possível controlar o valor da alimentação entregue
ao Motor DC, possibilitando o controle da
velocidade de rotação deste.
Para controlar a velocidade do Motor DC o
ciclo de trabalho do sinal PWM nas saídas digitais
do Arduino foi dividido em quatro valores os quais
foram denominados de Marchas, em analogia ao
uso de marchas em automóveis. As marchas
definidas foram:
•
•
•
•
Marcha I (Marcha 3): O ciclo de trabalho
do motor é 100%. O automodelo avançará
em sua velocidade máxima.
Para o movimento regressivo do
automodelo, ou Ré, o controle por marchas não é
considerado. O Motor DC recebe uma tensão
proporcional ao ciclo de trabalho do PWM em
78%, para que o automodelo não se movimente
rápido demais, o que não é necessário neste tipo de
movimento.
Controle do Servomotor Direcional
Ao iniciar o Sistema do Automodelo o
Arduino posiciona o Servomotor em um ângulo
inicial de 90 graus (referência).
O Arduino recebe, via Serial, o ângulo e a
direção do giro. O ângulo é recebido como
caracteres ASCII e convertido para Integer parar
Figura 1 - Esquema do circuito de controle dos motores
possibilitar os cálculos. Em seguida é realizado o
Marcha N (Marcha neutra): O ciclo de
cálculo do ângulo a ser enviado ao Servomotor de
trabalho do PWM é 0%. Ou seja, o
acordo com a direção, por exemplo:
automodelo não se movimenta caso receba
- Girar 35 graus para direita:
um comando de avanço.
- Soma-se 90 mais 35, então 125
graus;
Marcha G (Marcha 1): O ciclo de trabalho
- Ângulo é enviado ao
do PWM é de 56,86%. O suficiente para o
Servomotor que se posiona em
automodelo avançar lentamente.
125 graus (35 graus a mais da
referência);
Marcha H (Marcha 2): O ciclo de trabalho
- Girar 10 graus para esquerda:
do motor é 66,66%. O que faz o
- Subtrai-se 10 de 90, então 80
automodelo avançar a uma velocidade
graus;
razoavelmente rápida.
- Ângulo é enviado ao
Servomotor que se posiona em 80
graus (10 graus a menos da
referência);
Recebimento de dados pelo Arduino via
Serial (RS232)
Para estabelecer a comunicação entre os
dispositivos que se comunicam via wifi com o
Arduino, foi utilizado o módulo bluetooth EGBT046S. Sua função é passar os comandos enviados
pelo Controle via serial (RS232) para o Arduino.
Sua principal função e muito importante está em
fechar a ponte de comunicação entre os
dispositivos.
O software recebe os comandos via Serial
RS232, ou seja, diretamente do Modulo Bluetooth
ligado a porta serial do Arduino.
O Software possui um sistema de
segurança para impedir que o automodelo
permaneça em movimento em caso de perda de
comunicação entre os dispositivos.
O sistema de segurança funciona como um
Watchdog, que incrementa uma variável caso não
haja informação chegando pela Serial. Ao chegar
informação pela Serial, essa variável é zerada,
porém, caso não chegue informação, a variável é
incrementada até um determinado limite. Quando o
limite é atingido o sistema manda o automodelo
parar e a variável é zerada.
Software de Controle (Arduino)
Software de Controle - Cliente (Android)
O software de controle elaborado para
Arduino controlar o automodelo foi feito para atuar
sobre os motores ao receber determinados
comandos. Os comandos são compostos por
caracteres ASCII e todos possuem 3 (três) bytes.
Comando
FRT
TRA
PAR
Exx
(xx 00 à 90)
Dxx
(xx 00 à 90)
MCN
MCG
MCH
MCI
Observações
Faz o automodelo andar para
frente na velocidade
especificada pelo ultimo
comando Myy recebido.
Faz o automodelo ir para trás na
velocidade máxima. A Marcha
não interfere nesse movimento.
Faz o automodelo parar caso
esteja em movimento para frente
ou para trás.
Faz o Servomotor que controla a
direção do automodelo virar
para esquerda na quantidade de
graus informado.
Faz o Servomotor que controla a
direção do automodelo virar
para direita na quantidade de
graus informado.
Seleciona marcha neutra –
Automodelo não se move.
Seleciona primeira marcha –
Automodelo se move em
velocidade baixa.
Seleciona segunda marcha –
Automodelo se move em
velocidade média.
Seleciona terceira marcha –
Automodelo se move em
velocidade alta.
O Software de comunicação entre os
dispositivos móveis foi desenvolvido em Java
versão 1.5. O Software possui integradas as funções
de Cliente (controle do automodelo) e Servidor
(dispositivo móvel acoplado ao automodelo).
O controle utiliza o acelerômetro interno
do dispositivo móvel a fim de detectar suas
variações para determinar para qual lado o usuário
está virando o automodelo.
O dispositivo utilizado como controle deve
ser utilizado em Landscape, ou seja, na horizontal
e, na maioria dos dispositivos, com os botões de
acesso a funções do dispositivo virados para a
direita.
Figura 2 - Dispositivo móvel em Landscape
mostrando como o controle está disposto.
Foi utilizado o eixo Y do acelerômetro do
dispositivo para verificar o lado e inclinação com a
qual o aparelho está sendo girado. O eixo Y corta o
aparelho longitudinalmente na direção do topo à
base do aparelho, portanto ideal para a coleta da
informação para controlar o automodelo.
Figura 3 - Exibindo como o Eixo do acelerômetro
está disposto nos dispositivos móveis.
A informação capturada do eixo Y é a
aceleração que está sendo captada nele, ou seja, se
o dispositivo estiver na vertical, uma leitura em Y
irá fornecer exatamente a aceleração da gravidade
no local, ou seja, um valor em torno de 9,8 (que
significa 9,8 m/s²).
Figura 4 - Dispositivo na vertical de cabeça para
cima – O valor lido em Y é positivo, pois está na
mesma direção que a força da gravdiade.
Figura 5 - Dispositivo na vertical de cabeça para
baixo – Valor lido em Y é negativo, pois está na
direção contrária a força da gravidade.
Figura 6 - Dispositivo na horizontal – Valor lido em
Y é zero, pois o eixo está perpendicular a força da
gravidade.
A geração dos comandos direcionais é
feita da seguinte maneira:
1. Soma os dois primeiros valores coletados
do eixo Y e tira a média;
2. Soma os dois próximos valores coletados
do eixo Y e tira a média;
3. Subtrai o valor da 1° média pelo valor da
2° média tirando o valor absoluto do
resultado;
4. Se o valor absoluto da diferença for maior
que 0.5, então envia o valor da 2° média
para gerar o comando de direção, pois a
variação detectada foi significativa (o
controle foi girado/movimentado);
5. Se a variação foi significativa, divide-se o
valor da 2° média por 10 (valor próximo
ao máximo lido pelo acelerômetro) e
multiplica-se o resultado por 60 (grau
máximo de giro enviado para o
Servomotor);
6. Se o valor da 2° média for negativo então
manda girar para a Esquerda no grau
calculado, do contrário manda girar para a
Direita;
7. Caso a variação não seja significativa,
obtém-se os próximo dois valores do
acelerômetro e calcula-se a 2° média
novamente, e comparando-a com a 1°
média até que se detecte uma variação
considerável
Por exemplo:
1. Valores lidos em Y: -7,3 e -6,8
2. Média My1: -7,05
3. Valores lidos em Y: -5,0 e -4,6
4. Média My2: -4,8
5. Valor absoluto da diferença entre My1 e
My2: 2,25
6. Variação de 2,25 maior que 0,5, então
divide-se My2 por 10 e multiplica por 60:
-28
7. Retira o valor absoluto: 28
8. Concatena a String de direção: E28
No controle é possível selecionar dois
modos de controle do automodelo, modo Normal e
modo Free Navigation (FV).
No modo Normal de controle os comandos
direcionais de avanço para frente e para trás são
gerados a partir de botões dispostos na tela do
controle.
No modo Free Navigation os comandos de
avanço para frente e para trás são gerados a partir
da inclinação, para frente ou para trás, do controle.
Isso é possível, pois são feitas leituras do Eixo Z do
acelerômetro integrado ao dispositivo de controle.
O Eixo Z é disposto transversalmente ao dispositivo
e sua leitura é análoga à do eixo Y.
O System Core é o núcleo do sistema.
Possui duas filas internas de dados – Frame Queue
(Fila de Frames de vídeo) e Command Queue (Fila
de Comandos). A Frame Queue é a fila responsável
por receber os Frames via Ethernet e disponibilizar
os Frames para que sejam processados e exibidos
ao usuário. A Command Queue é a fila responsável
por receber os comandos gerados pelos eventos do
acelerômetro e botões de controle e disponibilizar
esses comandos para que sejam enviados através da
rede Ethernet Wifi.
Figura 7 - Diagrama exibindo a integração entre os módulos do Software de Controle
A seleção das marchas está disposta a
direita no painel do controle. O automodelo possui
4 possíveis marchas (0 à 3), sendo que 0 é marcha
neutra (o automodelo não se move caso receba
algum comando de avanço) e 3 é a maior marcha
(velocidade máxima).
O controle do automodelo também exibe,
em tempo real, os Frames de vídeos capturados pela
câmera do dispositivo Servidor. Os Frames são
recebidos através da rede Ethernet Wifi como
arrays de bytes no formato JPEG e são convertidos
para bitmaps (mapa de bits) para a exibição ao
usuário na tela do aparelho.
O software do controle, ou Cliente, é
dividido nos seguintes módulos:
• Socket Gate;
o Receiver Worker;
o Sender Worker;
• System Core;
o Frame Queue;
o Command Queue;
• Frame Viewer;
• Accelerometer Listener;
• Command Buttons Listener;
O Socket Gate é o módulo responsável por
criar e manter as tarefas Trabalhadoras de envio e
recebimento de dados via rede Ethernet Wifi. A
tarefa de envio de dados (Sender Worker) trabalha
retirando os dados disponíveis na Command Queue
do System Core e enviando-os ao dispositivo
Servidor através da rede Ethernet Wifi. A tarefa de
recebimento de dados (Receiver Worker) trabalha
recebendo os Frames de vídeo enviados pelo
Servidor e colocando-os na Frame Queue.
O Frame Viewer é o módulo responsável
por retirar os Frames de vídeo disponíveis na Frame
Queue do System Core, processar e desenha-los no
painel de visualização de vídeo do controle.
O Accelerometer Listener é o módulo
responsável pela captura de dados do acelerômetro
e geração dos comandosde controle do automodelo.
Após processar os dados e gerar os comandos, esse
módulo os coloca na Command Queue do System
Core para disponibilizá-los para envio ao Servidor.
O Command Buttons Listener é o módulo
responsável pela captura dos eventos de
pressionar/soltar os botões de comando do controle.
Após capturar os eventos, esse módulo os processa
gerando os comandos e os insere na Command
Queue do System Core para disponibilizá-los para
envio ao Servidor.
Software de Controle - Servidor (Android)
O dispositivo móvel Servidor recebe os
comandos de controle do automodelo via rede
Ethernet Wifi e os transmite para o Arduino via
Bluetooth.
•
Bluetooth Gate;
o Sender Worker;
System Core, como no Software do
Controle, é o núcleo do sistema e, também, possui
as duas filas internas para transição de comandos e
Frames de vídeo.
Neste caso a Frame Queue é alimentada
com os Frames de vídeos capturados pela câmera
do dispositivo em tempo real e disponibilizados
para envio ao Controle do automodelo.
O
Módulo
Bluetooth
EGBT-046S
conectado ao Arduino possui apenas a função de
Slave (escravo), ou seja, somente recebe dados, não
possui capacidade de envio de dados ao Master
(Mestre – nesse caso, o dispositivo Server).
A Command Queue recebe os comandos
enviados pelo Controle e os disponibiliza para
envio ao automodelo ou processamento interno.
Além de efetuar a ponte entre o dispositivo
de controle e o Arduino, o dispositivo Servidor
também acessa sua câmera integrada para captura e
transmissão dos Frames para o dispositivo de
controle em tempo real. Os Frames de vídeo são
O Socket Gate é o módulo responsável por
criar e manter as tarefas Trabalhadoras de envio e
recebimento de dados via rede Ethernet Wifi. A
tarefa de envio de dados (Sender Worker) trabalha
retirando os Frames de vídeo disponíveis na Frame
Queue do System Core o os enviando ao Controle
Figura 8 - Diagrama exibindo a integração entre os módulos do Software Servidor
capturados no formato NV21 (alta qualidade) e são
convertidos para JPEG (baixa qualidade) para
serem enviados através da rede Ethernet Wifi.
A taxa de captura é de 5 frames por segundo e a
resolução da imagem capturada é de 240x160.
O software do dispositivo Servidor, ou
simplesmente Servidor, acoplado ao automodelo, é
divido nos seguintes módulos:
•
•
•
•
Socket Gate;
o Sender Worker;
o Receiver Worker;
System Core;
o Frame Queue;
o Command Queue;
Camera Viewer;
Internal Commad Resolver;
do automodelo através rede Ethernet Wifi. A tarefa
de recebimento de dados (Receiver Worker)
trabalha recebendo os dados através da rede
Ethernet Wifi e os inserindo na Command Queue
do System Core para disponibilizá-los para envio
ao automodelo ou processamento interno.
O Camera Viewer é o módulo responsável
por capturar os Frames de vídeo da câmera
integrada do dispositivo móvel, compacta-los e
inseri-los na Frame Queue do System Core para
disponibilizá-los para envio ao Controle. Os Frames
são capturados diretamente da câmera no formato
NV21 e convertidos para o formato JPEG a fim de
compacta-los para facilitar o envio através da rede.
O Internal Command Resolver é o módulo
responsável por receber e processar comandos
destinados apenas ao dispositivo Servidor, como
por exemplo, acionamento da luz do flash do
dispositivo móvel.
O Bluetooth Gate é o módulo responsável
por efetuar a conexão via Bluetooth com o Módulo
EGBT-046S conectado ao Arduino e, também, criar
e manter a tarefa de envio dos dados de comandos
destinados ao automodelo. A tarefa de envio de
comandos (Sender Worker) retira os comandos
destinados ao automodelo da Command Queuer do
System Core e os envia via Bluetooth ao Arduino
para que este controle os motores do automodelo.
Como protocolo de comunicação através
da rede Ethernet Wifi havia sido adotado o TCP/IP
(Transmition Control Protocol / Internet Protocol).
O protocolo TCP/IP efetua uma conexão entre um
Cliente e um Servidor e todo frame de dados
enviados necessitam do recebimento de um frame
de Acknoledge (reconhecimento) do destinatário
para confirmar o recebimento ao remetente. Como
a rede Ethernet Wifi possui vários dispositivos
conectados é comum que alguns frames de dados
demorem a ser recebidos e confirmados, pois a rede
está constantemente ocupada. Devido a essa
peculiaridade, ocorriam travamentos no envio dos
Frames de vídeo e comandos de controle através da
rede. Isso causou uma mudança na abordagem e o
protocolo de comunicação através da rede Ethernet
foi alterado para UDP (User Datagram Protocol). O
UDP utiliza o envio de Datagramas como padrão
que são equivalentes aos frames TCP/IP, porém não
necessitam de confirmação de recebimento. Numa
comunicação UDP não há definição de um Cliente
e um Servidor, pois não há necessidade de criar
uma conexão entre os dispositivos. A utilização de
Datagramas UDP permitiu que os Frames de vídeo
e
os
comandos
fossem
transmitidos
satisfatoriamente sem ocorrência de travamentos.
Resultados
O testes foram executados de acordo com
a
planilha
de
testes
TG-01-2012EP_Planilha_Testes, documento com testes
unitários gerados para auxiliar na validação dessa
etapa, e gravados em vídeo.
Nos testes foram utilizados dois access
points para simular duas redes Wifi diferentes, uma
padrão 802.11g, com cerca de 54MBps (com uma
potência consideravelmente baixa) de taxa de
transferência e outra padrão 802.11n, com cerca de
300MBps (com uma potência consideravelmente
alta).
Em ambas as redes, os comandos foram
recebidos e interpretados adequadamente e os
frames de vídeos trafegaram sem maiores
problemas.
Na rede Wifi 802.11g foi possível
visualizar certa latência. O automodelo demorou
alguns instantes para interpretar os comandos e os
Frames de vídeo também demoravam alguns
instantes até serem exibidos. Isso causou certo
desconforto do usuário ao controlar o automodelo,
mas, como dito no inicio deste artigo, em redes
Wifi é sempre esperada uma certa latência o que
torna ligeiramente difícil o controle do automodelo
em alta velocidade. Já na rede Wifi 802.11n a
latência era irrisória. O automodelo apresentou uma
ótima resposta e os Frames de vídeo trafegaram
quase que instantaneamente. O usuário sentiu-se
muito confortável ao controla-lo em velocidades
mais elevadas. O alcance da rede também foi
superior (cerca de 30 metros na rede 802.11n,
contra 20 metros na rede 802.11g). E mesmo com
certa distância entre o automodelo e o acces point,
não houve morosidade que atrapalhasse o controle.
Discussão e Conclusões
O projeto foi implementado aproveitandose dos recursos de conexão a redes Wifi, acesso ao
acelerômetro integrado e comunicação via
Bluetooth,
disponíveis
pela
maioria
dos
dispositivos com sistema operacional Android,
assim como foi proposto no inicio deste artigo.
Também foi utilizado o recurso de concorrência (ou
pseudo
paralelismo)
disponibilizado
pela
linguagem de programação Java, o qual permite a
execução de tarefas simultaneamente. O que
permitiu a separação do sistema em tarefas mais
simples e especificas.
O tempo de resposta em uma rede Wifi
802.11n foi satisfatório, tendo tanto o envio de
comandos quanto a transmissão de imagens
ocorrido rapidamente.
Utilizando o mesmo conceito de
comunicação entre dispositivos Android é possível
efetuar a comunicação através da rede de internet
GPRS das operadoras de telefonia celular. Porém
devido ao desempenho dessa rede (baixíssima
velocidade) seria necessário alterar a abordagem de
controle, dando mais autonomia ao dispositivo
acoplado ao automodelo para que este tome
decisões em casos de perda de sinal e gaps na
comunicação.
No geral o projeto atendeu os requisitos
especificados tornando possível a integração de
Smartphones
com
uma
placa
Eletrônica
microcontrolada, o que permitiu o controle de
motores elétricos através do acelerômetro integrado
ao Smartphone de controle sem alteração de
hardware nos dispositivos móveis e ainda valendose de seus recursos de comunicação via redes
Ethernet Wifi e Bluetooth.
Agradecimentos
Agradecemos ao nosso Professor e
Orientador, Renato Giacomini. Que nos apoiou e
nos auxiliou no desenvolvimento desse projeto
desde o começo, em 2011, quando nossas ideias
ainda eram obscuras e incertas.
Agradecemos ao Professor Alexandre
Brincalepe que, junto com o professor Renato, no
guiou no começo para a escolha e um bom e
tangível projeto.
Agradecemos ao Professor Nuncio
Perrella, que sem a apresentação de seus conceitos
sobre Tempo Real, Concorrência e Sistemas
Operacionais seria muito difícil buscar as linhas de
raciocino que originaram este projeto.
Agradecemos a toda equipe dos
laboratórios da Universidade São Judas Tadeu, em
especial ao Renato Falango, que nos auxiliou muito
na manutenção mecânica do automodelo sempre
com muita paciência e dedicação.
Referências Bibliográficas
1.Android Developers – Application Fundamentals,
http://developer.android.com/guide/topics/fundame
ntals.html (acessado em 01/12/2011).
2.Android Developers – Hello, World Tutorial,
http://developer.android.com/resources/tutorials/hel
lo-world.html (acessado em 05/12/2011).
3.Android Developers – Notepad Tutorial,
http://developer.android.com/resources/tutorials/not
epad/index.html (acessado em 16/12/2011).
4.Elec Freaks - Communication Between Android
and
Arduino
With
Bluetooth
(1),
http://www.elecfreaks.com/677.html (acessado em
20/12/2012).
5.Elec Freaks - Communication Between Android
and
Arduino
With
Bluetooth
(2),
http://www.elecfreaks.com/829.html (acessado em
20/12/2012).
6.Vídeo – Experiência Arduino + Bluetooth +
Android
–
parte
1/3,
http://www.youtube.com/watch?v=IwnofqvGKow
(acessado em 22/12/2012).
7.Video – Experiência Arduino + Bluetooth +
Android
–
parte
2/3,
http://www.youtube.com/watch?v=R6o1UlC-ztg
(acessao em 22/12/2012).
8.Video – Experiência Arduino + Bluetooth +
Android
–
parte
3/3,
http://www.youtube.com/watch?v=hWUSloIi6gg
(acessado em 22/12/2012).
9.The Box - Control Small DC Motors - Workshop
Motors
1,
http://www.thebox.myzen.co.uk/Workshop/Motors
_1.html (acessado em 05/01/2012).
10.SZYM - Ad-hoc Wifi in Android,
http://szym.net/2010/12/adhoc-wifi-in-android/
(acessado em 23/01/2012).
11.Android Developers – WifiDirectDemo – Wifi
Direct
Demo,
http://developer.android.com/resources/samples/Wi
FiDirectDemo/index.html
(acessado
em
23/01/2012).
12.TechRepublic – A quick tutorial on coding
Android’s
accelerometer,
http://www.techrepublic.com/blog/app-builder/aquick-tutorial-on-coding-androidsaccelerometer/472 (30/01/2012).
13.m3-stream – Android video streaming and
encoder – Source Code,
http://code.google.com/p/m3stream/source/browse/#svn%2Ftrunk%2Fsrc%2For
g%2Fm3 (acessado em 01/02/2012).
14.Ipcamera-for-android, Enabling your Android
phone to an IP-Camera,
http://code.google.com/p/ipcamera-for-android/
(acessado em 02/02/2012).
15.Stackoverflow – Image Processing on Android,
http://stackoverflow.com/questions/2043019/image
-processing-on-android (acessado em 05/02/2012).
16.Android Developers – Lunar Lander (Source
Code),
http://developer.android.com/resources/samples/Lu
narLander/src/com/example/android/lunarlander/Lu
narView.html (acessado em 15/02/2012).
17.Lecheta, Ricardo R. Google Android – Aprenda
a Criar Aplicações para Dispositivos Móveis com o
Android Sdk – Segunda Ed 2010 – Editora Novatec
– ISBN: 9788575222447
18.Elgo – Lock Screen Orientation in Android,
http://eigo.co.uk/NewsArticle.aspx?NewsArticleID=103 (acessado em
22/02/2012).
19.Arduino - Learning Examples | Foundations |
Hacking | Links
http://arduino.cc/en/Tutorial/HomePage (acessado
em 23/02/2012).
20.Makebits – Ligar motores DC com uma Ponte H
ao arduino, http://makebits.net/ligar-motores-dccom-uma-ponte-h-ao-arduino/
(acessado
em
01/03/2012).
21.MARGOLIS, Michael (2011). Arduino
Cookbook – Recipes to Begin, Expand, and
Enhance Your Projects – Editora O'Reilly
Media - ISBN: 978-0-596-80247-9
22.Mmaciel – Controlando motor DC com Ponte H
(L293D) com arduino via porta serial,
http://www.mmaciel.com.br/2011/02/27/controland
o-motor-dc-ponte-h-l293d-arduinoporta-serial/
(acessado em 03/03/2012).
23.Eletromaniacos – Leitura Serial de Entrada
Analógica
com
Arduino,
http://www.eletromaniacos.com/modules.php?name
=News&file=article&sid=157
(acessado
em
05/03/2012).
24.Android Issues – Issue 5427: can’t initiate SPP
Communication without SDP (Problemas com
Bluetooth),
http://code.google.com/p/android/issues/detail?id=5
427 (acessado em 20/03/2012).
25.Stackoverflow – How to prevent Android
Bluetooth RFCOMM connection from dying
immediately
affeter
.connect()?,
http://stackoverflow.com/questions/2660968/howto-prevent-android-bluetooth-rfcomm-connectionfrom-dying-immediately-after
(acessado
em
22/03/2012).
26.Stackoverflow – How to send an int through
UDP
in
Java,
http://stackoverflow.com/questions/5236620/howto-send-an-int-through-udp-in-java (acessado em
26/03/2012).
27.Javafree.org – Programando em sockets com
Java
–
parte
02,
http://javafree.uol.com.br/artigo/2910/Programando
-em-sockets-com-java-parte-02.html (acessado em
27/03/2012).
28.Datasheet Ponte H L293D. SGS-Thompson
Microelectronics.
Dados Biográficos do (s) autor (es)
Henrique Martins Prado
17 de julho de 1989 – São Paulo
– SP
Segundo Grau: Colégio Técnico
Lavoisier.
Trabalha na Scopus Tecnologia
Ltda., atuando como técnico de
laboratório e Campo. Exerce
atividades focadas em manutenção de hardware,
configurações e monitoramento de sistemas
financeiros do Banco Bradesco. Participou de
projetos de implementação de sistemas bancários
padronizados em todo território nacional e projetos
focados em upgrades de equipamentos como
atualizações de firmware e upgrades de hadwares
em clientes como Lexmark, Telefônica, Bradesco
Seguros, Porto Seguro, CIEE, Hipercard, Dell e
Microlog.
Leandro Piqueira
23 de outubro de 1988 – São
Paulo – SP
Segundo Grau: Colégio Técnico
Lavoisier.
Trabalha na T-Systems do
Brasil Ltda como Analista de
Sistemas
de
Automação
Industrial desenvolvendo softwares para integração
de dispositivos de chão de fábricas como PLCs
(Programmable Logic Controllers), com Sistemas
Corporativos. Participou de projetos como a
transformação da fábrica de carros da Mercedes
Benz de Juiz de Fora para fábrica de caminhões e
outros projetos de linhas de produção de indústrias
como Magneti Marelli, Benteler, Goodyear, Ambev
entre outras.