TCC Hugo de Freitas Bereta

UNIVERSIDADE FEDERAL FLUMINENSE
HUGO DE FREITAS BERETA
SISTEMA DE LEITURA E TRATAMENTO DE DADOS DE

TELEMETRIA PARA UM SIMULADOR DE CAMINHÃO PARA PC
Niterói
2016

Trabalho de Conclusão de Curso

submetido ao Curso de Tecnologia em
Sistemas de Computação da
Universidade Federal Fluminense como
requisito parcial para obtenção do título
de Tecnólogo em Sistemas de
Computação.
Orientador(a):
Rafael Burlamaqui Amaral
NITERÓI
2016
Ficha Catalográfica elaborada pela Biblioteca da Escola de Engenharia e Instituto de Computação da UFF
B492 Bereta, Hugo de Freitas

Sistema de leitura e tratamento de dados de telemetria para um
simulador de caminhão para PC / Hugo de Freitas Bereta. – Niterói,
RJ : [s.n.], 2016.
80 f.
Projeto Final (Tecnólogo em Sistemas de Computação) –

Universidade Federal Fluminense, 2016.
Orientador: Rafael Burlamaqui Amaral.
1. Telemetria. 2. Jogo em computador. 3. Simulação por

computador. I. Título.
CDD 005.741

Trabalho de Conclusão de Curso

submetido ao Curso de Tecnologia em
Sistemas de Computação da
Universidade Federal Fluminense como
requisito parcial para obtenção do título
de Tecnólogo em Sistemas de
Computação.
Niterói, 20 de Dezembro de 2016.
Banca Examinadora:
_________________________________________
Prof. Rafael Burlamaqui Amaral, Msc. – Orientador
CEFET/RJ - Centro Federal de Educação Tecnológica Celso Suckow da Fonseca
_________________________________________
Prof. Ubiratam Carvalho de Paula Junior, Dr. – Avaliador
UFRRJ - Universidade Federal Rural do Rio de Janeiro
_________________________________________
Prof. Gleiph Ghiotto Lima de Menezes, Msc. – Avaliador
UFF - Universidade Federal Fluminense
Dedico este trabalho à meus pais, esposa e
filho, que sempre almejaram por mais essa
realização.
AGRADECIMENTOS
Primeiramente a Deus, que sempre me

permitiu alcançar meus objetivos em minhas
caminhadas.
À minha esposa e filho, pela paciência,

carinho, compreensão e todo apoio que
sempre me deram durante essa jornada.
Aos meus pais por investirem uma vida em

mim e sempre confiarem em meu potencial.
A meu Orientador Rafael Burlamaqui Amaral,

que comprou essa ideia comigo e me
forneceu todo apoio e direcionamento que
necessitava para progredir.
A meu primo e amigo Wellington Carlos de

Jesus Marmelo, por toda inspiração e ajuda
na construção dos circuitos do protótipo.
A meu sogro José Weliton Costa Leite por

todo auxílio técnico na construção da
estrutura do protótipo.
Ao CEDERJ por me permitir fazer um curso

de qualidade e me proporcionar a realização
de um sonho.
“Não importa quão frio seja o inverno, há
uma primavera adiante”.
Eddie Vedder
RESUMO
Atualmente, os recursos disponíveis aos computadores pessoais permitem o

desenvolvimento de jogos que trazem uma experiência cada vez mais próxima da
realidade. Inúmeros jogos chegam a intitular-se simuladores. Dispositivos de
interação entre o usuário e o simulador, tais como volantes, manches, painéis,
câmbios, etc, aumentam o grau de imersão do jogador no ambiente simulado. Com
um pouco de conhecimento e com baixo custo, um usuário pode criar seu próprio
dispositivo de interação com o simulador utilizando componentes eletrônicos
baratos, controlador de hardware e software livres. O objetivo desde trabalho é criar
um plugin para o jogo/simulador Euro Truck Simulator 2 que extraia as informações
de telemetria do veículo e possibilite a criação de um painel de controle para o
caminhão. O funcionamento básico do plugin consistirá em capturar as informações
de telemetria disponibilizada pelo jogo e escrevê-las em uma porta serial do
computador, onde uma placa controladora conectada fará a leitura desses dados e
os enviará aos respectivos componentes eletrônicos do painel. O plugin será escrito
utilizando o Microsoft Visual Studio Community, uma IDE gratuita e indicada para
projetos livres, com a linguagem C++, utilizando funções do SDK (Software Develop-
ment Kit) fornecido pela produtora do jogo. Uma placa Arduino será utilizada como
controladora de hardware, combinada com componentes eletrônicos simples e de
baixo custo, facilmente encontrados em lojas de eletrônica e automação.
Palavras-chaves: Simulador, Jogos de Computador e Arduino.

ABSTRACT
Currently the available resources for personal computers allow development of

games that bring an experience nearest to the reality. Several of this games are
called simulators. The devices that create an interface between game and player,
such as steering wheel, joystick, panel, gear shift, etc, increase the player's immer-
sion level into the simulated environment. With a little of knowledge and by a low cost
any player can creates your own interface device for the simulator using cheaper
electronic components, free hardware and software. The objective of this work is to
create a plugin for the game Euro Truck Simulator 2 that extracts telemetry data from
the vehicle and allows to create a control panel for the truck. The basic operation of
the plugin consists to capture the telemetry data available from the game, and write it
on a computer serial port where a control board is connected, reading data and send -
ing it to related electronic components from the panel. The plugin will be written using
Microsoft Visual Studio Community, a free IDE recommended to produce free soft-
ware, with C++ language, using functions available by SDK (Software Development
Kit) provided by the game producer. An Arduino board will be used as control hard -
ware combined with simple and cheaper electronic components easily available at
electronic and automation shops.
Key words: Simulator, Computer Games and Arduino.

LISTA DE ILUSTRAÇÕES
Figura 1: Implementação de uma função callback.....................................................25

Figura 2: Conexão serial.............................................................................................30
Figura 3: Conexão paralela.........................................................................................31
Figura 4: Composição de um pacote de dados..........................................................33
Figura 5: Barramento de uma conexão serial.............................................................34
Figura 6: Interligação dos componentes do projeto....................................................35
Figura 7: Tela de confirmação do jogo Fonte: Euro Truck Simulator 2.......................37
Figura 8: Classe Options.............................................................................................39
Figura 9: Diagrama de classes - Parâmetros de inicialização....................................40
Figura 10: Diagrama de estados - Eventos da API de telemetria...............................42
Figura 11: Diagrama de sequência - Registro de eventos..........................................43
Figura 12: Diagrama de atividades - Inicialização do plugin......................................46
Figura 13: Classe Serial..............................................................................................47
Figura 14: Pacote de dados de telemetria..................................................................49
Figura 15: Display LCD 16x2 Fonte: Google Imagens...............................................54
Figura 16: Pinagem do registrador de deslocamento 74HC595 Fonte: [7]................56
Figura 17: Simulação de circuito com CI 74HC595 e uso de transístores.................57
Figura 18: Símbolo de um transístor NPN Fonte: [50]................................................58
Figura 19: Screenshot - Arduino Leonardo como joystick..........................................61
Figura 20: Diagrama de pinagem do 74HC165 Fonte: Datasheet do CI....................62
Figura 21: Simulação de circuito com 74HC165.........................................................63
Figura 22: Modelo do protótipo criado com SketchUp................................................64
Figura 23: Circuito de LEDs do painel........................................................................67
Figura 24: Micro servo Fonte: Site do fabricante........................................................68
Figura 25: Telas do computador de bordo..................................................................69
Figura 26: Foto do circuito de entrada........................................................................71
Figura 27: Foto do circuito de saída............................................................................71
Figura 28: Visão frontal do painel................................................................................72
LISTA DE ABREVIATURAS E SIGLAS
API – Application Programming Interface

ASCII – American Standard Code for Information Interchange
ATS – American Truck Simulator
CI – Circuito Integrado
DLL – Dynamic-Link Library
ETS2 – Euro Truck Simulator 2
GND – Ground (Terra)
IDE – Integrated Development Environment
LCD – Liquid Crystal Display
MIT – Massachusetts Institute of Technology
PC – Personal Computer
RAM – Random Access Memory
SCL – Serial Clock
SDA – Serial Data
SDK – Software Development Kit
TCP – Transmission Control Protocol
UML – Unified Modeling Language
USB – Universal Serial Bus
VCC – Voltage Common Collector
SUMÁRIO
RESUMO......................................................................................................................7
ABSTRACT...................................................................................................................8
LISTA DE ILUSTRAÇÕES............................................................................................9
LISTA DE TABELAS...................................................................................................10
LISTA DE GRÁFICOS................................................................................................11
LISTA DE ABREVIATURAS E SIGLAS......................................................................12
1 INTRODUÇÃO.....................................................................................................15
2 TRABALHOS RELACIONADOS..........................................................................19
2.1 TUKOLK........................................................................................................19
2.2 ETS2 TELEMETRY WEB SERVER 3.2.5 & MOBILE DASHBOARD..........20
3 FUNDAMENTAÇÃO TEÓRICA...............................................................................22
3.1 O KIT DE DESENVOLVIMENTO DE SOFTWARE (SDK)...........................22
3.2 A API DE TELEMETRIA................................................................................25
3.3 ARDUINO E A COMUNICAÇÃO SERIAL.....................................................28
3.3.1 O ARDUINO.........................................................................................29
3.3.2 A COMUNICAÇÃO SERIAL................................................................30
4 O PLUGIN...............................................................................................................35
4.1 O JOGO E A API DE TELEMETRIA.............................................................36
4.2 A INICIALIZAÇÃO DO PLUGIN....................................................................38
4.3 O PLUGIN E A COMUNICAÇÃO SERIAL....................................................47
5 A PLACA CONTROLADORA ARDUINO.................................................................50
5.1 RECEPCIONANDO OS DADOS da porta serial..........................................50
5.2 EXIBINDO AS INFORMAÇÕES DE TELEMETRIA.....................................52
5.2.1 O COMPUTADOR DE BORDO...........................................................53
5.2.2 O GERENCIAMENTO DE LEDS DO PAINEL.....................................54
5.2.3 COMPONENTES ANALÓGICOS.......................................................59
5.3 ENVIANDO COMANDOS AO JOGO............................................................60
6 O PROTÓTIPO........................................................................................................64
6.1 O CIRCUITO DE SAÍDA...............................................................................65
6.1.1 O SISTEMA DE LEDS.........................................................................66
6.1.2 OS INSTRUMENTOS..........................................................................67
6.1.3 O COMPUTADOR DE BORDO...........................................................68
6.2 O CIRCUITO DE ENTRADA.........................................................................69
6.3 UMA VISÃO GERAL DA ESTRUTURA DO PROTÓTIPO...........................70
CONCLUSÕES E TRABALHOS FUTUROS.............................................................73
REFERÊNCIAS BIBLIOGRÁFICAS...........................................................................75
APÊNDICE.................................................................................................................80
APÊNDICE A..............................................................................................................80
APÊNDICE B..............................................................................................................81
15
1 INTRODUÇÃO
A crescente expansão tecnológica vem tornando acessíveis aos

computadores pessoais uma quantidade de recursos muito grande. Tarefas antes
realizadas em empresas especializadas ou laboratórios de computação de
universidades dotados de equipamentos avançados, tais como produções
audiovisuais, desenvolvimento de jogos, automação, etc, hoje podem ser realizadas
no conforto do quarto de um usuário de computador pessoal. Paralelamente a essa
evolução dos computadores pessoais veio a evolução dos softwares disponíveis e,
da mesma forma, dos jogos de computadores.
O primeiro jogo de computador foi criado em 1961, no Massachusetts In-
stitute of Technology (MIT), em um imenso computador DEC PDP-1 de 120.000
dólares. O jogo, denominado “Spacewar!” tinha apenas 2KB e seu idealizador foi
basicamente estimulado a criar o programa devido à chegada do novo computador
dotado de novos recursos, como transistores em vez de válvulas e uma tela[37].
Alguns jogos atuais, como por exemplo o GTA V, lançado pela Rockstar Games para
PC em abril de 2015, graças à expansão dos recursos disponíveis chegam a
recomendar o uso de 8GB de memória RAM e de 65GB de espaço em disco, o
equivalente a 34 milhões de vezes o tamanho do primeiro jogo. Esses jogos rodam
em computadores que cabem na mesa do quarto de um adolescente[32].
Em um determinado ponto dessa linha evolutiva, algumas produtoras
apostaram em jogos que buscassem criar simulações de coisas ou atividades reais.
Segundo o Institute for Simulation & Training da Universidade da Flórida Central[19],
simulações são abstrações da realidade, onde uma determinada parte é focada, em
prejuízo de outra. Tal seletividade se deve à restrições impostas pelos recursos
utilizados ou mesmo para manter a atenção voltada ao aspecto da realidade que
interessa ao caso. As simulações podem ser utilizadas para treinar pessoas para
realizar alguma atividade, para explicar fenômenos ou para entreter. Embora as
simulações cujos objetivos sejam treinar pessoas ou explicar fenômenos exijam um
16
nível de precisão e confiabilidade muito alto, as simulações cujo objetivo é entreter

não deixam a desejar nestes quesitos. Nesse sentido, alguns jogos intitulam-se
simuladores pelo fato de terem como objetivo abstrair uma parte da realidade, tal
como pilotar um avião, dirigir um caminhão, dirigir um ônibus, administrar uma
cidade, ou até mesmo administrar uma família, uma casa e um emprego, enfim, uma
infinidade de coisas e atividades com um grau de precisão bastante satisfatório.
Com o surgimento e evolução dos jogos de simulação, uma vasta gama
de dispositivos controladores de jogos vêm sendo produzida para aumentar o grau
de imersão do jogador dentro de jogos de simulação. Esses dispositivos são
volantes, manches, alavancas de câmbio, pedais, painéis, instrumentos de voo, etc.
Porém, o custo para adquirir esses produtos no Brasil ainda é elevado, visto que
grande parte deles são importados, passando por taxas cambiais e impostos que
elevam seu preço final consideravelmente.
O Euro Truck Simulator 2 é um jogo de simulação para o qual a recepção
no mundo dos gamers foi muito boa graças a, entre outros fatores, o grau de
realismo que o jogo proporciona ao jogador. Lançado em 19 de Outubro de 2012
pela SCS Software o jogo, que vendeu 2 milhões de cópias em apenas 15 horas[41],
promete oferecer ao jogador a chance de se tornar um caminhoneiro, transportando
as mais variadas cargas através das estradas europeias e até mesmo gerenciando
sua própria empresa de transportes, sem sair do conforto da sua casa[30]. Em 16 de
janeiro de 2013, o jogo foi incluído na Steam, uma renomada plataforma de
entretenimento que gerencia mais de 3.500 jogos[34], onde conta com mais de 2,9
milhões de jogadores até o início de agosto de 2016[38].
Caso o jogador queira aumentar o nível de realismo do Euro Truck Simula-
tor 2, vários acessórios estão a sua disposição, como óculos de realidade virtual,
volantes com 900 graus de rotação, pedais com comportamento e peso semelhante
aos reais, alavancas de câmbio em H, odômetros, conta-giros, medidores de
combustível, sensores de movimento para controle da visão do jogador, entre outros.
Porém, apenas um único acessório destes citados pode chegar a custar o
equivalente ao preço de um computador pessoal no Brasil. Boa parte deles só está
disponível para importação direta pelo jogador, o que é um processo demorado e
17
burocrático, cujo custo final do produto pode subir demasiadamente. E o mercado

nacional ainda carece de dispositivos controladores de jogos com total
compatibilidade e que forneça uma boa experiência com o simulador de caminhões
da SCS Software.
Ao longo do contínuo desenvolvimento do Euro Truck Simulator 2, a SCS
Software criou e disponibilizou ao público um SDK (Software Development Kit) que
provê funções que acessem em tempo real os dados da telemetria do jogo, ou seja,
é possível conhecer a velocidade atual do caminhão, a rotação do motor, a
quantidade de combustível no tanque, que luzes de emergência estão ou não
acesas no painel, etc. Enfim, têm-se todo o estado atual do veículo e do jogo em si.
Segundo a própria produtora, o SDK fornecido “provê acesso à telemetria do veículo
do jogador a aplicativos de terceiros”[40]. O uso desse kit de desenvolvimento
possibilita a criação de softwares e também dispositivos que interajam com o jogo,
como um painel de controle, um painel de instrumentos, displays, tudo podendo
utilizar componentes eletrônicos baratos e de fácil acesso.
O objetivo deste trabalho é criar um plugin para o jogo Euro Truck Simula-
tor 2, utilizando o SDK fornecido pela produtora do jogo, que extraia as informações
de telemetria do veículo e possibilite a confecção de um painel de controle para o
caminhão.
A linguagem de programação utilizada para escrita do plugin é C++ e o
funcionamento deste consiste em ler os dados da telemetria do veículo através das
funções do SDK e disponibilizá-los em uma porta serial do computador. Uma placa
Arduino conectada àquela mesma porta serial se encarrega de ler esses dados e
enviá-los a um painel confeccionado com componentes eletrônicos simples e de
baixo custo facilmente encontrados em lojas de eletrônica e automação. A mesma
placa também é responsável por viabilizar e gerenciar o envio de comandos ao jogo.
O trabalho foi organizado da seguinte forma. O Capítulo 2 descreve
trabalhos relacionados ao tema e sobre a motivação que levou ao desenvolvimento
deste trabalho. O Capítulo 3 apresenta a fundamentação teórica, com conceitos
sobre o SDK fornecido pela SCS Software, a teoria envolvendo seu funcionamento,
os dados de telemetria disponíveis, além de demais conceitos necessários ao
18
entendimento do projeto. O Capítulo 4 apresenta o plugin e os detalhes de seu

funcionamento para disponibilizar os dados de telemetria à placa controladora. O
Capítulo 5 traz informações sobre a placa Arduino utilizada como controlador de
hardware e explica como ela gerencia as informações recebidas do plugin e os
comandos enviados ao jogo. No Capítulo 6 é apresentado um protótipo de um painel
feito com componentes eletrônicos baratos e acessíveis, que pode ser
confeccionado pelo próprio jogador para melhorar sua experiência com o jogo. No
Capítulo 7 são apresentadas as conclusões e indicações para trabalhos futuros.
19
2 TRABALHOS RELACIONADOS
No sentido de melhor situar este trabalho dentro do panorama atual de

controladores ou dispositivos de interface para jogos, dois trabalhos relacionados
com o tema são citados a seguir. Ambos seguem o contexto de utilização de Arduino
e criação de dispositivos para jogos. Cada qual resolve com êxito os objetivos por
eles propostos, porém, tais trabalhos correlatos serão brevemente analisados aqui
como forma de clarificar a motivação que levou ao desenvolvimento deste projeto.
2.1 TUKOLK
O TuKolk é um projeto de Graduação apresentado à Escola de

Informática Aplicada da Universidade Federal do Estado do Rio de Janeiro (UNIRIO)
para obtenção do título de Bacharel em Sistemas de Informação[14]. O objetivo do
projeto consiste na confecção e programação de um console de videogame baseado
em Arduino, utilizando-se de uma tela touchscreen e display LCD. Em outras
palavras, o projeto propõe uma forma de criar o próprio console de jogos com
componentes eletrônicos disponíveis no mercado, onde o próprio jogador pode
montá-lo e até programar seus próprios jogos.
A utilização do Arduino como plataforma de hardware e a criação de um
dispositivo com componentes eletrônicos simples são os pontos de convergência do
projeto TuKolk com este trabalho. Porém, a utilização de Arduino na criação de jogos
não é uma proposta incomum entre os desenvolvedores e geralmente envolve a
criação de um console próprio ou dispositivo que engloba jogo e controlador em um
único projeto, tal qual o TuKolk. O site Instructables[35], um tipo de rede social para
compartilhamento de criações e tutoriais de diversas naturezas que conta com uma
20
vasta seção de projetos em Arduino, traz uma grande quantidade de jogos similares
ao TuKolk, criados com a plataforma de desenvolvimento de hardware livre, dos
mais variados tipos e com os mais variados componentes eletrônicos e sensores
compatíveis com a placa[36].
O ponto de convergência entre o TuKolk e este trabalho consiste na
criação de um dispositivo de jogo criado com Arduino e componentes eletrônicos
acessíveis, que pode até mesmo ser montado pelo próprio jogador interessado.
Embora o TuKolk tenha essa proposta interessante de criação de um console e jogo
com a plataforma Arduino, a motivação de uso da plataforma neste trabalho diverge
por visar a confecção de um controlador que gerencie comandos e informações de
um simulador de caminhões com um grau considerável de complexidade, onde
recomenda-se o uso de um computador com 6GB de memória RAM e um
processador Quad-Core 3.0 GHz[33].
2.2 ETS2 TELEMETRY WEB SERVER 3.2.5 & MOBILE DASHBOARD
A SCS Software, produtora do Euro Truck Simulator 2, disponibiliza a seus

usuários um fórum para otimizar a interação entre os usuários de seus jogos,
desenvolvedores e representantes da própria empresa. O local é comumente
utilizado para divulgação de modificações ou acessórios criados pelos usuários para
uso com os jogos da produtora. Algumas dessas produções independentes
chegaram a chamar a atenção da produtora tcheca. Talvez o projeto mais famoso
entre os jogadores seja o ETS2 Telemetry Web Server 3.2.5 & Mobile Dashboard.
O projeto ETS2 Telemetry Web Server 3.2.5 & Mobile Dashboard foi
lançado no fórum oficial da SCS Software em 27 de dezembro de 2014 pelo usuário
Funbit[16] e, desde então, vêm se mantendo constantemente entre os tópicos mais
movimentados do fórum, entre mais de 20 mil tópicos da seção ligada ao ETS2. O
sucesso do projeto chamou a atenção da produtora que, em fevereiro de 2015,
lançou uma matéria em seu blog oficial[40] onde a empresa faz menção ao projeto
21
como uma das principais produções de sucesso criadas por jogadores que utilizam o
SDK fornecido pela empresa para melhorar a experiência dos jogadores com o jogo.
O trabalho de Funbit consiste em um plugin escrito em C++ que se utiliza
do SDK fornecido pela SCS Software para ler informações do ETS2 e disponibilizá-
las a um Web Server, escrito em C#, que exibe os dados ao jogador de forma
amigável em qualquer navegador de internet disponível, seja em dispositivos móveis
ou até mesmo em outros computadores. O sistema utiliza skins (opções diferentes
de visuais para o programa) que simulam um painel de caminhão no navegador e
possibilita a personalização pelo jogador.
O plugin desenvolvido para o projeto envia os dados de telemetria para o
servidor web através de arquivos mapeados na memória (Memory-Mapped File), ou
seja, cria-se um arquivo mapeado na memória virtual que possibilita que vários
processos escrevam e leiam dados neste[24].
A ideia de criação de um painel externo, ainda que virtual, a utilização de
um plugin escrito com o SDK fornecido para criar o enlace entre jogo e dispositivo
são os pontos em comum com este trabalho de conclusão. O ponto de divergência
deste trabalho em relação ao projeto do Funbit consiste na criação de um dispositivo
físico (painel de instrumentos), onde a técnica de compartilhamento das informações
de telemetria via arquivo mapeado em memória deixa de ser a mais viável e é
substituída pela comunicação serial entre o PC que roda o simulador e a placa
Arduino. Ressalta-se, ainda, que o dispositivo aqui criado não se limita a receber
informações do jogo, mas também envia comandos àquele.
22
3 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo serão apresentados conceitos teóricos importantes que

serão utilizados ao longo deste trabalho, cujo entendimento é primordial para a
compreensão e desenvolvimento do projeto. Aqui serão apresentados alguns
conceitos sobre o Software Development Kit (SDK) fornecido pela empresa
produtora do jogo, sobre as informações de telemetria disponibilizadas pelo jogo
através do kit de desenvolvimento, além de alguns conceitos relacionados à placa
Arduino e ao painel controlador de jogo.
3.1 O KIT DE DESENVOLVIMENTO DE SOFTWARE (SDK)
Um SDK (Software Development Kit), também conhecido popularmente

por “devkit”, é um conjunto de ferramentas de programação criado para facilitar o
desenvolvimento de aplicações para sistemas operacionais, plataformas de
hardware, consoles de videogames, jogos de computadores, etc[56]. Como
exemplos de SDK renomados no mercado podemos citar Windows SDK e o Android
SDK. Ambos são compostos por metadados, bibliotecas, cabeçalhos de códigos
(headers) e diversas outras ferramentas para auxiliar na produção de aplicativos
para os respectivos sistemas operacionais[57][58]. O SDK fornecido pela SCS
Software é um kit de cabeçalhos de códigos escritos para os jogos Euro Truck Simu-
lator 2 (ETS2) e American Truck Simulator (ATS).
Desde os seus primeiros trabalhos produzidos, a SCS Software sempre
criou formas de facilitar e incentivar que os jogadores criassem modificações para
seus jogos, popularmente chamadas pelos usuários de “mods”, uma abreviação
criada para o termo “modifications”. No ETS2 e no ATS, por exemplo, com a criação
23
de um simples arquivo de texto copiado para um diretório específico dentro da

estrutura de pastas definidas pelo jogo, um jogador pode alterar toda a física do
simulador, ajustando variáveis internas que são lidas e interpretadas pelo motor do
jogo. Dentro dessa proposta, a empresa criou e disponibilizou um SDK que garante
o acesso à API de telemetria do jogo, que consiste em um conjunto de informações
disponibilizadas em tempo real, tais como fabricante e modelo do caminhão
utilizado, velocidade, marcha atual, coordenadas do mapa, informações da carga
transportada, número de rotações do motor (RPM), vetores de aceleração do veículo
e uma série de outras informações. Todas estas podem ser utilizadas para criar
modificações para o jogo e, conforme a própria empresa, “criar uma experiência
mais imersiva”[40].
O princípio de utilização do SDK da SCS Software é através da escrita de
plugins para os jogos. Os plugins devem ser implementados como uma DLL (Dy-
namic-Link Library) que exporta funções requeridas pela API que ele quer utilizar. O
jogo, então, carrega os plugins a partir de uma pasta específica dentro de sua árvore
de diretórios. Quando quer ativar uma API específica, o jogo efetua uma chamada à
função de inicialização para aquela API, a qual exporta as funções requeridas.
Quando quer desativar uma API específica, o jogo efetua uma chamada à função de
finalização. Uma vez concluída a etapa de finalização, o jogo pode descarregar os
plugins, caso necessário. Os plugins devem ser implementados assumindo-se que o
ciclo de inicialização/finalização pode ocorrer várias vezes dentro de um mesmo
ciclo de carregamento/descarregamento do plugin e que vários ciclos de
carregamento/descarregamento podem ocorrer durante o tempo de vida do
processo sob o qual roda o jogo[15].
Para entender o funcionamento do SDK e da API, é preciso entender um
pouco mais sobre o funcionamento de uma DLL, especialmente no que tange à troca
de informações entre a biblioteca de funções e a aplicação que a utiliza.
De forma geral, uma DLL provê códigos e dados que podem ser utilizados
por um ou mais programas ao mesmo tempo[29]. Tal característica gera uma menor
utilização de recursos, visto que o uso simultâneo por diversos programas evita a
duplicação de código carregado na memória e no disco[29].
24
O uso de DLL permite a modularização de um programa em componentes

separados, o que possibilita, por exemplo, que o programa possa ser distribuído na
forma de pacotes contendo somente os módulos de interesse do utilizador. Além
disso, facilita processos de atualização, tendo em vista que as alterações podem ser
aplicadas apenas nos módulos necessários, sem necessidade de modificar todo o
sistema[29]. Ao trazer essa forma de implementação de plugins para seus jogos, a
SCS Software trouxe a seus jogadores a versatilidade na criação de módulos que
extraiam e tratem as informações de telemetria de forma personalizada e otimizada.
Assim, um desenvolvedor pode optar por extrair somente as informações de
telemetria que desejar e compartilhá-las via TCP, por exemplo, enquanto outro
desenvolvedor pode escrever seu módulo de forma a extrair outras informações de
telemetria e que o compartilhamento seja via arquivos mapeados em memória.
Expande-se, portanto, as possibilidades, reduz conflitos e otimiza os recursos
utilizados.
Uma DLL pode ter suas funções chamadas por qualquer programa ou até
mesmo por outras DLL, logo, é natural que ela não tenha conhecimento de quem a
acessa, tampouco das funções existentes naquela aplicação. Pode-se dizer,
portanto, que não há como uma DLL efetuar uma chamada direta a uma função
existente na aplicação que a chama. Para resolver tal questão, são utilizadas
funções conhecidas como callback[39]. De forma genérica, uma callback é uma
função que é passada como parâmetro de outra função através do uso de ponteiros.
Neste caso específico, podemos dizer que é uma função contida na aplicação, cujo
ponteiro é passado como parâmetro de uma chamada de função da DLL permitindo,
assim, que a biblioteca retorne dados para a aplicação que efetua a chamada[39],
conforme ilustra a Figura 1 abaixo.
25
DLL Aplicação
Função da DLL Ponteiro para a
Callback
Implementação
da Callback
Figura 1: Implementação de uma função callback
3.2 A API DE TELEMETRIA
A palavra telemetria tem origem no idioma Grego. O radical “tele” significa

“longe” ou “distância” enquanto “metria” origina das palavras meter ou metron,
ambas de origem grega e que significam “medir”[1][22][2]. Logo, a telemetria
significa obter dados a distância ou de locais, a princípio, inacessíveis[22]. Portanto,
o campo da telemetria foi desenvolvido a partir da necessidade de se obter
informações remotamente de um lugar para o outro de maneira precisa, devido à
inacessibilidade da fonte de dados a ser monitorada[54]. As aplicações da telemetria
vão desde o monitoramento de animais para pesquisas[1], até a obtenção de
informações de veículos tripulados ou não em tempo real[22], passando pela
indústria bélica[54].
No caso dos jogos ETS2 e ATS da SCS Software, o termo telemetria
refere-se à obtenção de informações do jogo e dos veículos em tempo real, como
fabricante e modelo do caminhão, velocidade, marcha, coordenadas de localização,
informações da carga transportada, taxa de rotação do motor, vetores de aceleração
do veículo e mais uma série de outras informações do jogo[40].
Uma API, sigla que se refere ao termo em inglês “Application Program-
ming Interface”, traduzido como “Interface de Programação de Aplicações”, é
comumente definida como um conjunto de rotinas e padrões de programação
26
criados por uma empresa de software de maneira a permitir que aplicações de

terceiros possam ser integradas a seu produto[28].
Um clássico exemplo de API é a fornecida pelo sistema operacional Win-
dows, cujo objetivo é prover um conjunto de convenções e técnicas de programação
que são conduzidas pela filosofia do sistema operacional da Microsoft [17]. É através
destas convenções e técnicas que se introduz padrões de programação para o
Windows, que inclui padrões de gerenciamento de arquivos, processos, memória e
diversos recursos avançados como sincronização de threads[17]. O uso de API
também traz a vantagem de desacoplar a interface das chamadas reais ao sistema.
Assim, modificações nas chamadas ao sistema não afeta o funcionamento dos
programas existentes devido a essa abstração proporcionada pela API[52].
De forma semelhante à API do Windows, a API de telemetria da SCS
Software fornece rotinas, convenções, técnicas e padrões de programação com
objetivo de permitir que aplicações de terceiros possam acessar a telemetria dos
simuladores de caminhão da empresa[44]. E tal qual a API do Windows, seu grau de
abstração permite que futuras atualizações não afetem o funcionamento de plugins
criados com versões anteriores.
A API de telemetria atualmente é a única fornecida pelo kit da SCS Soft-
ware, cuja versão atual é a 1.6. Ela provê dois tipos de informações: dinâmicas ou
semidinâmicas. Uma informação dinâmica é uma informação que é constantemente
atualizada pelo jogo como, por exemplo, a velocidade do caminhão. Uma informação
semidinâmica é aquela que não é atualizada a todo instante, mas depende de um
evento específico no jogo como, por exemplo, os parâmetros do caminhão
(fabricante, modelo, etc) que são atualizados somente quando o jogador troca de
modelo no jogo[15].
Para tratar as informações dinâmicas e semidinâmicas, a API de
telemetria suporta dois tipos de callbacks[15]:
• Eventos: que indicam uma fase específica do processamento de
informações, tal como início/fim do quadro de dados de telemetria,
além de comunicar a mudança de informações semidinâmicas (por
exemplo, quando um jogador troca de modelo de caminhão).
27
• Canais: que são associados à fontes individuais de informações de

telemetria (por exemplo, velocidade, posição, rotações do motor,
etc), ou seja, à informações dinâmicas.
O cerne do funcionamento do plugin criado com o SDK da SCS Software
consiste em registrar os eventos que ocorrem e os canais de telemetria
disponibilizados para, então, tratar e/ou compartilhar as informações com uma
aplicação-fim, que pode ser um servidor web que exibe os dados numa página no
navegador, uma placa Arduino como a utilizada neste trabalho, um programa local,
uma outra DLL (driver) que controle um hardware, etc.
Uma das convenções definidas pela API, conforme demonstrado nos
exemplos disponibilizados pela SCS Software inclusos no kit e nos comentários
contidos nos arquivos de cabeçalhos, é a de que o plugin (DLL) deve exportar duas
funções básicas, as quais são responsáveis por inicializar e finalizar o suporte à API
de telemetria. O motor do jogo efetua uma chamada à função de inicialização
através da qual ele identifica e valida a versão da API utilizada. Até que seja
inicializada, a telemetria é considerada como “pausada” e a função de finalização,
que encerra um ciclo de processamento da telemetria, só é chamada pelo motor do
jogo se antes ocorreu um sucesso com a função de inicialização. O registro de
eventos e canais ocorrem entre os ciclos de inicialização e finalização da telemetria
e os quadros de dados são tratados por meio de callbacks específicas[15].
Os canais de telemetria podem ser agrupados em canais comuns de
telemetria, canais de telemetria dos caminhões e canais de telemetria dos reboques.
Os canais comuns de telemetria são canais mais gerais que podem ser utilizados
por mais jogos da empresa. Esses canais são responsáveis por informações como
escala de conversão de tempo e distância, data e hora dentro do jogo e tempo até a
próxima parada obrigatória para descanso. Já os canais de telemetria dos
caminhões trazem, obviamente, informações sobre os veículos utilizados pelos
jogadores. Cada canal traz uma informação específica do veículo, como
posicionamento, vetores de velocidade e deslocamento, taxa de rotação do motor,
luzes do veículo, luzes de advertência e emergência, estado de funcionamento dos
freios auxiliares (freio de estacionamento, freio motor, e retarder), estado de
28
funcionamento do motor e acionamento da parte elétrica, entre outras. De modo

similar, os canais de telemetria dos reboques trazem informações sobre o estado da
conexão entre reboque e caminhão (reboque está conectado?), além de
informações físicas específicas, como vetores de velocidade e deslocamento,
coordenadas, fator de dano ao chassi do reboque, além de informações diversas
sobre as rodas e física aplicada a estas.
3.3 ARDUINO E A COMUNICAÇÃO SERIAL
Uma vez que plugin tenha extraído os dados de telemetria, pode realizar
algum processamento local (gestão de logs, por exemplo) ou enviá-los a algum outro
componente de software ou hardware conforme o objetivo proposto. Por exemplo, o
projeto do jogador Funbit, descrito no Capítulo 2 deste trabalho, utiliza-se de técnica
de arquivos mapeados em memória para fornecer os dados a um servidor web que,
por sua vez, disponibiliza-os via conexão TCP para acesso via navegador de
internet[20]. A SCS Software também disponibiliza junto a o seu kit de
desenvolvimento alguns exemplos de manipulação dos dados extraídos do jogo,
demonstrando o uso em arquivos de log e como distribuir os dados através do uso
de arquivos mapeados em memória.
No entanto, como o objetivo neste trabalho é utilizar os dados obtidos do
jogo para gerenciar um painel de comandos para o mesmo, uma nova abordagem
foi utilizada. Uma placa controladora conectada a uma porta USB do computador
onde o jogo roda recebe os dados do plugin via comunicação serial e os utiliza para
gerenciar o painel de comandos. A placa escolhida para o projeto foi a Arduino.
29
3.3.1 O ARDUINO
Arduino é uma plataforma de eletrônica open-source baseada na filosofia

“faça você mesmo” (DIY – Do it yourself) tanto no quesito hardware quanto software,
com foco na facilidade de uso[5]. As placas Arduino são capazes de ler sensores,
botões e até mesmo informações como uma mensagem no Twitter, por exemplo, e
transformar os dados lidos em comandos de saída, ativando um motor, um LED ou
publicando algo online[5]. O projeto integra uma IDE própria baseada em Process-
ing1 e uma linguagem de programação própria baseada em Wiring2, com suporte aos
sistemas operacionais Windows, Linux e MAC.
Desde o lançamento do Arduino Project em 2005, a placa se tornou uma
das plataformas de desenvolvimento de microcontroladores mais popular devido a,
principalmente, sua facilidade de utilização. Mesmo um usuário sem muito
conhecimento técnico podem aprender o básico necessário para desenvolver seus
próprios projetos em um curto período de tempo. Para auxiliar, há uma grande
comunidade de utilizadores da placa que estão constantemente compartilhando
seus códigos e projetos pela internet e dispostos a ajudar outros
desenvolvedores[[23], p.20].
O principal foco do Projeto Arduino sempre foi a facilidade de uso. A
plataforma foi criada no Ivrea Interaction Design Institute, em Ivrea, na Itália, com o
objetivo de fazer com que estudantes sem conhecimento técnico em eletrônica e
programação pudessem realizar seus próprios protótipos e projetos. Rapidamente,
sua popularidade fez com que, sob o conceito de projeto open-source, fosse
amplamente replicado e alcançasse o restante do mundo[5].
O Projeto Arduino foi erguido sob a égide do hardware open-source. Uma
das primeiras decisões tomadas sobre o projeto foi a de que os arquivos de design
do hardware fossem distribuídos livremente para que os usuários pudessem criar
suas próprias versões das placas ou simplesmente fazer uma cópia de uma
placa[13]. Isso gerou uma infinidade de placas clones disponíveis no mercado com
1
Saiba mais sobre Processing em <https://processing.org/>
2
Saiba mais sobre Wiring em <http://wiring.org.co/>
30
preços bastante acessíveis, aumentando a preferência pelas placas Arduino (e

similares).
Este trabalho é pautado pela criação de uma solução de baixo custo e
que possa ser implementada por jogadores que podem não deter conhecimento
técnico em eletrônica e programação. É justamente nesse sentido que a plataforma
Arduino mostra-se indicada, ou seja, pelos pontos convergentes com este projeto,
como baixo custo, facilidade de uso, acessibilidade de materiais para referência e
produção, possibilidade de expansões, com criação de módulos, etc[5].
3.3.2 A COMUNICAÇÃO SERIAL
O plugin criado enviará os dados obtidos do jogo para uma placa Arduino.
Os dados serão transmitidos através de comunicação serial utilizando uma conexão
USB. A comunicação serial detém um conceito bem simples, que a diferencia
essencialmente da comunicação paralela. A porta serial envia e recebe bytes de
informações, um bit por vez[26], conforme ilustra a Figura 2, enquanto a paralela
envia 8 bits (1 byte) de uma só vez, conforme ilustra a Figura 3. Logo, a paralela tem
condições de enviar uma maior quantidade de dados em um menor tempo, porém
está limitada a curtas distâncias de conexões. Já a serial, envia uma menor massa
de dados em uma fração de tempo, mas permite conexões mais distantes devido à
característica do sinal[26].
Conexão Serial
Sentido da Transmissão
TX RX
Origem dos Destino dos
Dados bits Dados
Figura 2: Conexão serial

31
Uma analogia interessante a ser feita para comparar as duas formas de

comunicação é com o trânsito de carros. A comunicação paralela, seria o
equivalente a uma autoestrada com 8 vias por onde os carros trafegam, enquanto
que a serial equivale a uma estrada simples, com uma via única para os carros
transitarem. Em um determinado tempo, a grande autoestrada levaria uma
quantidade de carros muito maior ao destino. No entanto, a estrada simples ainda
que leve mais tempo, poderia levar a mesma quantidade de carros ao destino, com
um custo muito menor de construção[45].
Conexão Paralela
Sentido da Transmissão
TX RX
Origem dos Destino dos

Dados Dados
bits
Figura 3: Conexão paralela
A comunicação paralela, embora tenha muitas vantagens, consome

muitos recursos de E/S (Entrada e Saída) que, no caso de microcontroladores como
o Arduino, podem ser preciosos e escassos. Esse é o principal motivo de
microcontroladores utilizarem-se da comunicação serial[45].
Existem dois tipos de comunicação serial: síncrona e assíncrona. A
comunicação serial síncrona exige que transmissor e receptor estejam sincronizados
para que a troca de informações ocorra. Essa sincronização é feita utilizando um
sistema de clock (relógio) interno que controla o pulso de envio de bits[3]. A
comunicação serial assíncrona, o modo de comunicação serial mais comum, é
aquele onde não existe a necessidade de sincronização entre os dispositivos, tendo
em vista que os dados são transmitidos individualmente e não em blocos, como
32
costuma ser no modo síncrono. Cada transmissão é precedida de um bit de início

(start bit) e um (ou dois) bit(s) de fim ou de parada (stop bit)[42].
A conexão serial possui algumas características importantes, que são a
taxa de transmissão (baud rate), bits de dados (data bits), bit de início (start bit),bits
de parada (stop bits) e bit de paridade (parity). A taxa de transmissão (baud rate) é a
velocidade definida para a comunicação. Ela indica o número de bits enviados por
segundo. Por exemplo, uma taxa de 9600 baud significa que 9600 bits são
transmitidos por segundo. Numa conexão serial síncrona, uma taxa de 9600 baud
também indica que o clock está em uma frequência de 9600 Hz[26]. Em suma, a
taxa de transmissão define o quão rápido os dados são transmitidos em uma
conexão serial[46].
Bits de dados (data bits), como o próprio nome diz, corresponde à
quantidade de bits de dados constantes na transmissão, que nem sempre necessita
ser 8 bits, podendo oscilar entre 5 e 9 bits de dados dentro de um pacote ou quadro
de dados[46]. Por exemplo, numa transmissão baseada na tabela de caracteres
standard ASCII, um pacote contém 7 bits de dados, representando valores decimais
de 0 a 127. Já num pacote baseado na tabela extended ASCII, usam-se 8 bits de
dados, representando valores decimais de 0 a 255[26].
Os bits de início e de parada são também conhecidos como bits de
sincronização. Eles são responsáveis por delimitar o pacote ou quadro de dados,
marcando o início e o fim do pacote. Ressalta-se que o bit de início é sempre um
único bit que marca o começo do pacote. No entanto, o bit de parada pode ser
configurado para um ou dois bits que demarcam o fim do pacote[46].
O bit de paridade é uma forma simples de checagem de erro comumente
utilizada na comunicação serial. Há quatro possibilidades de paridade: par, ímpar,
marcada e espaçada. Além dessas opções, ao se configurar a paridade numa
conexão serial, há a possibilidade de escolher a opção de não utilizar paridade[26].
Em resumo, um bit de paridade é inserido no pacote no transmissor. Ao chegar no
receptor, o bit de paridade é recalculado e comparado com o bit contido no pacote. A
divergência indica um erro na transmissão[46].
33
A Figura 4 abaixo ilustra a composição de um pacote de dados em uma

comunicação serial.
Pacote Bit de início Bits da dados Bit de paridade Bit(s) de parada

Tamanho (bits) 1 5-9 1 1-2
Figura 4: Composição de um pacote de dados
O barramento de uma comunicação serial é composto por duas vias,

sendo uma para enviar os dados (transmissor ou TX) e outra para receber os dados
(receptor ou RX). A Figura 5, extraída da página de tutoriais da SparkFun Electron-
ics[47], empresa americana especializada em produtos para projetos de eletrônica
open-source, demonstra um barramento de uma conexão serial simples entre dois
dispositivos. É importante notar que o transmissor (TX) de um dispositivo conecta-se
ao receptor (RX) do outro dispositivo e vice-versa. Ou seja, diferentemente do GND
(terra), que é conectado também ao GND do outro dispositivo, o transmissor deve se
comunicar com o receptor e não com outro transmissor[47].
Uma interface serial onde os dispositivos podem enviar e receber dados
pode ser classificada como full-duplex ou half-duplex. Uma comunicação full-duplex
significa que ambos os dispositivos podem enviar e receber dados simultaneamente,
enquanto uma comunicação half-duplex significa que os dispositivos devem alternar
envio e recepção[47].
Em alguns casos específicos, não há necessidade de que os dados
trafeguem em ambas as direções. Assim, os dados fluem de um dispositivo
transmissor até um dispositivo receptor por uma única via. Essa comunicação serial
é conhecida como simplex[47].
34
Figura 5: Barramento de uma conexão serial

Fonte: [47]
35
4 O PLUGIN
O site Tech Terms Computer Dictionary, uma espécie de dicionário online

para termos computacionais e da Internet, define plugin como sendo uma peça de
software que se integra ao software original a fim de se acrescentar uma nova
funcionalidade[53]. Logo, um plugin pode ser entendido como uma peça que se
encaixa em um software pronto, preparado para receber tais anexos, a fim de lhe
fornecer nova(s) funcionalidade(s).
A funcionalidade adicionada pelo plugin proposto ao jogo é a
disponibilização dos dados do veículo em tempo real através de uma conexão serial
USB para uma placa Arduino, a qual se encarregará de controlar os componentes
eletrônicos do protótipo de painel criado (controlador de jogo).
A Figura 6 abaixo ilustra a interconexão entre os componentes deste
projeto.
Figura 6: Interligação dos componentes do projeto
O ETS2 disponibiliza os dados ao plugin através da API de telemetria. O

plugin, por sua vez, envia os dados para o microcontrolador da placa Arduino via
porta USB. A placa se encarrega de tratar os dados e, com base nestes, enviar
sinais de controle aos respectivos componentes do painel de controle.
Assim, quando um usuário aciona, por exemplo, o freio de estacionamento
(parking break) do veículo, as seguintes ações ocorrem:
36
• O ETS2 disponibiliza ao plugin a informação de que o freio de

estacionamento foi acionado pelo jogador;
• O plugin repassa a informação para a porta USB onde a placa
Arduino está conectada;
• O microcontrolador Arduino lê a informação da porta serial e envia
um sinal elétrico a um LED vermelho existente no painel de controle
que indica que o freio está ativado no veículo.
Este é o princípio básico de funcionamento de todo o sistema, que é
composto pelo jogo, plugin, Arduino e painel de controle.
4.1 O JOGO E A API DE TELEMETRIA
Foi dito na Seção 3.1 do Capítulo 3 que os plugins escritos com o SDK
fornecido pela SCS Software para seus jogos devem ser implementados como uma
DLL. O sistema de modificações através de plugins criados pela empresa requer a
simples cópia da DLL criada para uma pasta pré-definida dentro do diretório raiz do
jogo. Ao ser inicializado, o jogo carrega todas as bibliotecas que estiverem naquela
pasta e exibe uma mensagem de alerta/confirmação de utilização de recursos do
SDK conforme a Figura 7, extraída diretamente do jogo. A partir de então, quando o
jogo quer acionar a API, ele efetua uma chamada à função de inicialização para o
plugin, o qual exporta uma série de funções requeridas pela API (callbacks).
Uma vez que o jogo esteja em execução, com o plugin carregado, é
possível reiniciar a API ou mesmo descarregar o plugin para carregar nova versão,
utilizando-se de linhas de comandos dentro do jogo. Isso permite manipular ou
atualizar o plugin para testes sem ser necessário fechar o jogo[15].
37
Figura 7: Tela de confirmação do jogo

Fonte: Euro Truck Simulator 2
O jogo exige que o plugin exporte apenas duas funções: a de inicialização

e a de finalização[15]. Quando uma informação de telemetria necessita ser utilizada,
o jogo efetua uma chamada à função de inicialização da DLL e utiliza as callbacks
necessárias para disponibilização das informações (eventos e canais de telemetria).
Após efetuadas as trocas de informações, a API é finalizada com a chamada à
função de finalização.
A função de inicialização, quando chamada pelo jogo, recebe dois
parâmetros. O primeiro indica a versão da API de Telemetria utilizada pelo jogo e o
segundo é composto por uma estrutura de dados contendo diversas informações de
inicialização, entre ela o nome, ID e versão do jogo, além das funções callbacks que
são utilizadas para escrever uma mensagem no arquivo de log do jogo e manipular o
registro dos eventos e canais de telemetria (Figura 9). Caso a função de inicialização
38
tenha sido executada com sucesso, o jogo então executa uma chamada à função de
finalização encerrando o ciclo da API de Telemetria.
4.2 A INICIALIZAÇÃO DO PLUGIN
Em 22 de setembro de 2013, um engenheiro de software britânico e

jogador de ETS2 chamado Silas Parker, postou em seu blog um projeto pessoal de
um painel de instrumentos onde ele apresentava um plugin que acessava dados de
telemetria do jogo e os enviava via porta serial a uma placa Arduino[31]. O protótipo
era bem simples, composto apenas de 4 LED's, um display LCD e 2 servomotores.
Porém a ideia por trás do plugin abriu as portas para a criação de novas versões
pelos jogadores e desenvolvedores.
O projeto de Parker utiliza dois LEDs verdes para as luzes indicadoras de
direção (setas), dois LEDs vermelhos para o freio de estacionamento e indicador de
baixo combustível, dois servomotores para velocidade e rotações do motor (RPM),
além de um display LCD para exibir informações como velocidade em milhas por
hora (MPH) e quilômetros por hora (KPH), percentual de combustível no tanque e
indicador de marchas. Ele apresenta uma quantidade reduzida de informações de
telemetria, restrição de uso de algumas portas seriais, aceitando apenas as portas
de COM1 a COM9, funcionamento restrito à versão 32 bits do ETS2 e a falta de
suporte ao novo jogo da SCS Software, o American Truck Simulator (ATS). Além
disso, o painel de instrumentos apresentado como protótipo limita-se a receber
informações do jogo, sem enviar quaisquer comandos para aquele.
O plugin e o protótipo de painel de instrumentos de Parker serviram de
fonte de inspiração para este trabalho, que busca resolver as questões pendentes
naquele projeto inspirador. Assim, o plugin foi ajustado para trazer uma quantidade
maior de informações necessárias à confecção de um painel mais completo, resolver
a questão de acesso às portas seriais acima da COM9 (vide [51]), gerar a versão em
64 bits do plugin, ajustar para funcionamento com o ATS e enviar comandos ao jogo
através do painel.
39
Conforme descrito na Seção 4.1, o plugin proposto exporta unicamente as

funções de inicialização e finalização da API. Uma estrutura de dados armazena as
informações de telemetria obtidas para envio via porta serial e uma série de call-
backs, definidas conforme especificação do SDK, são executadas para registrar os
eventos e canais de telemetria necessários, além de registrar linhas no arquivo de
log do jogo com informações de controle.
O plugin se utiliza de um arquivo de configuração onde é definida a porta
serial utilizada para comunicação e uma série de variáveis utilizadas para calibrar
algumas informações antes de serem enviadas à placa Arduino. O arquivo de
configuração é um arquivo de texto puro, onde cada linha contém uma opção de
configuração, composta por “chave”, “tipo de dados” e “valor”, separados por espaço
ou tabulação. Uma classe denominada “Options”, definida conforme a Figura 8, foi
criada para manipular as opções definidas no arquivo de configuração.
Figura 8: Classe Options
A função de inicialização exportada pelo plugin (scs_telemetry_init)

funciona como um recipiente para as informações de telemetria do jogo. Quando o
jogo quer iniciar o envio de informações, ele efetua uma chamada àquela função.
Um dos parâmetros passados à função de inicialização é uma estrutura de dados
(scs_telemetry_init_params_v100_t) a qual contém uma série de funções callbacks
que permitem a troca de informações com o jogo.
A Figura 9 apresenta um diagrama que modela a estrutura de dados (uma
struct, na linguagem C++) scs_telemetry_init_params_v100_t e suas dependências
40
segundo as especificações da versão 2.5 da UML[27]. Como seu nome bem sugere,
essa estrutura detém os parâmetros comuns de inicialização e callbacks para a
versão 1.00 da API de Telemetria. Sua primeira relação de dependência,
representada com uso de linha contínua, é de herança (generalização) com a
estrutura scs_telemetry_init_params_t, cujo objetivo é demonstrar que não se trata
de uma struct em C e que, portanto, é permitido conter métodos em sua definição. A
segunda relação de dependência, representada com uso de linha tracejada, ocorre
devido ao atributo common da estrutura de dados
scs_telemetry_init_params_v100_t ser definido pela também estrutura de dados
scs_sdk_init_params_v100_t[[27], p.38].
Os métodos contidos na estrutura de dados
scs_telemetry_init_params_v100_t são callbacks responsáveis pelo registro (ou
cancelamento de um registro) de eventos e canais de telemetria, possibilitando a
devida troca de informações com o jogo.
Figura 9: Diagrama de classes - Parâmetros de inicialização
Seguindo o conceito de callback, conforme consta no Capítulo 3, Seção

3.1, essas funções são ponteiros para métodos cuja implementação se dá no lado
da aplicação que efetua a chamada à DLL, nesse caso, no lado do jogo. Ou seja,
quando o motor do jogo efetua uma chamada à função de inicialização ao plugin, ele
41
passa uma série de ponteiros para funções que estão contidas em seu código que
retornam as informações de telemetria ao plugin. Graças a esse nível
encapsulamento proporcionado pelo jogo e seu SDK, o desenvolvedor do plugin
pode registrar, por exemplo, um evento do jogo apenas utilizando parâmetros para a
callback respectiva, sem se importar em como o motor implementa esse método.
Porém, é importante ressaltar que uma callback também pode ser utilizada
no sentido inverso, ou seja, da DLL para o jogo. Para tanto, a DLL disponibiliza ao
jogo ponteiros para funções implementadas em seu corpo de código, ainda que não
exportadas pela via convencional (dllexport, em C++). A prática do uso de callback
no lugar de exportar funções é indicada para situações em que as tarefas são
executadas repetidamente[25].
Diante desse paradigma de implementação, quando a função de
inicialização da API é chamada, o plugin deve registrar as callbacks necessárias
para seu contexto de funcionamento. Isso se dá em duas etapas: a etapa de registro
dos eventos que se deseja capturar e a etapa de registro dos canais de telemetria
que se deseja obter.
O registro de eventos é efetuado através da callback “register_for_event”
contida nos parâmetros passados na função de inicialização. Com esse método,
escolhe-se o evento a ser registrado pelo plugin. Os eventos possíveis são cinco:
• Frame Start: Evento gerado antes dos dados de telemetria serem
incluídos no frame (quadro) de dados;
• Frame End: Evento gerado depois de todos os dados de telemetria
forem incluídos no frame de dados;
• Paused: Evento gerado quando o jogo é pausado (por exemplo,
quando está no menu do jogo), indicando que o jogo parou de
enviar dados de telemetria;
• Started: Evento gerado quando o jogador entra no modo de “dirigir”
no jogo, seja no início ou após efetuar uma pausa no jogo; e
• Configuration: Evento gerado quando alguma configuração do jogo
ou do veículo é alterada.
42
A Figura 10 traz um diagrama de estados que ilustra a ocorrência dos

eventos da API de Telemetria. Observa-se que quando o jogo inicializa a API, ela
entra em estado de pausa e gera o evento PAUSED. Sempre que o jogo estiver
pausado e uma característica do veículo for modificada, o evento CONFIGURATION
é gerado. O evento STARTED indica que o jogador entrou no modo de dirigir, o que
pode ser no início do jogo ou após uma pausa. Se durante o jogo o usuário efetua
uma pausa (ex.: acessa o menu do jogo), a API gera o evento PAUSED novamente,
parando de gerar dados. Quando o jogo está em modo de dirigir, ou seja, já ocorreu
o evento STARTED da API, é hora de gerar os frames de dados que serão lidos pelo
plugin. Antes de inserir qualquer dado no frame, o evento FRAME_START é
disparado. Após todos os dados serem incluídos no frame, o evento FRAME_END é
gerado. A API é finalizada quando o usuário acessa o menu e seleciona a opção de
fechar o jogo.
Figura 10: Diagrama de estados - Eventos da API de telemetria
O plugin deve registrar todos os eventos para os quais deseja receber

informações durante a execução do jogo. Ao registrar um evento específico, o plugin
passa uma callback como parâmetro para a função de registro de eventos. Assim,
quando um evento ocorrer, o jogo coloca em execução a callback passada pelo
43
plugin para aquele evento específico. Em outras palavras, criar um registro para um
evento é passar ao motor do jogo ponteiros para funções contidas no plugin que
devem ser executadas quando um determinado evento ocorrer.
O diagrama de sequência contido na Figura 11 modela uma abstração da
tarefa de registro de eventos. Nos sequenciais 3 e 4 do diagrama, os parâmetros
event e callback da função register_for_event definem, respectivamente, o evento a
ser registrado pelo plugin e o ponteiro para uma função (callback) que o jogo deve
executar quando este evento ocorrer. Em caso de sucesso no registro do evento, a
função retorna a constante SCS_RESULT_ok, que equivale a 0. Um valor diferente
de zero indica uma falha no registro do evento. O registro de um único evento pode
ser suficiente, dependendo do objetivo do plugin. Portanto, o registro de eventos
adicionais é opcional, conforme demonstrado no diagrama.
Figura 11: Diagrama de sequência - Registro de eventos
Como ilustrado na Figura 10, os eventos CONFIGURATION, PAUSED e

STARTED podem ocorrer há qualquer momento do ciclo de vida da API. Já os
eventos FRAME_START e FRAME_END, como os nomes sugerem, delimitam o
início e fim do quadro de dados, ou seja, delimitam o intervalo dentro do qual as call-
backs que registram os canais de telemetria são executadas.
44
Devido à sua proposta de funcionamento, o plugin de que trata este

trabalho cria registradores para os eventos FRAME_END, CONFIGURATION,
PAUSED e STARTED. A callback do evento FRAME_END é responsável por enviar
os dados para a porta serial após preenchido o quadro de dados com os canais de
telemetria registrados. A callback do evento CONFIGURATION encarrega-se de
obter e atualizar as características do caminhão, caso o usuário as modifique no
menu do jogo. Para os eventos PAUSED e STARTED, o plugin registra a mesma
callback (telemetry_paused) para ambos. Essa função tem como objetivo atualizar
uma variável booleana que define se a API está rodando ou em pausa. Com base no
valor da variável, o plugin transmite pela porta serial um bit de controle que indica o
estado da API de telemetria à placa Arduino. O evento FRAME_START não é
registrado por este plugin.
O registro dos canais de telemetria desejados são efetuados através da
callback register_for_channel, também contida nos parâmetros passados na função
de inicialização da API (Figura 9). Através dessa função, o plugin registra as call-
backs que serão chamadas pelo jogo com o valor do canal de telemetria
especificado. Estas callbacks são responsáveis por salvar a informação do canal de
telemetria no respectivo campo da estrutura de dados criada no plugin para
armazenar as informações.
A função register_for_channel contém os seguintes parâmetros:
• name: Nome do canal para o qual se deseja registrar (ex.: speed,
engine_rpm, etc);
• index: Utilizado para canais que utilizam matrizes. Deve ser
utilizado SCS_U32_NIL para canais normais;
• type: Tipo de dados do canal;
• flags: Flags de controle do canal registrado;
• callback: Callback a ser registrada. Será executada pelo jogo toda
vez que o valor do canal em questão for modificado;
• context: valor passado como parâmetro para a callback registrada.
Este parâmetro indica, basicamente, onde o canal será
armazenado. Neste plugin utiliza-se o campo correspondente da
45
estrutura de dados (struct) que armazena as informações de

telemetria.
Assim, quando um canal é registrado, a callback passada como parâmetro
é relativa ao tipo de dados deste canal, definido pelo parâmetro type. Isso significa
que, se um canal detém uma informação do tipo ponto flutuante (float), a callback
responsável por armazenar na estrutura de dados informações do tipo flutuante
(telemetry_store_float) é passada como parâmetro para a função de registro. De
forma análoga, o mesmo acontece com os demais tipos de dados. Essa técnica
permite que apenas cinco funções sejam suficientes para fazer o armazenamento de
mais de 40 canais de telemetria.
O diagrama de atividades apresentado na Figura 12 ilustra a sequência de
atividades realizada durante a execução da função de inicialização. O jogo envia os
parâmetros de inicialização ao plugin. Ao recebê-los, este checa os parâmetros e
retorna ao jogo os ponteiros para as funções responsáveis pelo registro de eventos
e canais. Se os eventos e canais forem registrados corretamente, a inicialização é
bem sucedida e o plugin foi carregado com êxito. Ou seja, o plugin só permanece
em execução se os registros das callbacks para eventos e canais forem efetuados
com sucesso.
46
Figura 12: Diagrama de atividades - Inicialização do plugin

47
4.3 O PLUGIN E A COMUNICAÇÃO SERIAL
Inicializado o plugin com sucesso, o que significa que o motor do jogo já

sabe exatamente quais funções da DLL deve executar quando um evento registrado
ocorrer ou um canal de telemetria registrado for atualizado, é hora de empacotar os
dados e disponibilizá-los na porta serial para uso pela placa Arduino.
A execução das callbacks registradas para atualizar os canais de
telemetria ocorre entre o início e fim de um quadro de dados de telemetria, ou seja,
entre os eventos FRAME START e FRAME END. Isso significa que quando um
quadro de dados é finalizado (evento FRAME END), os canais de telemetria
registrados foram atualizados na estrutura de dados contida no plugin. Por esse
motivo, esse evento é registrado e sua respectiva callback é a responsável pelo
envio de dados à porta serial.
No plugin, uma classe chamada “Serial” foi implementada para modelar a
conexão serial, conforme Figura 13.
Figura 13: Classe Serial

48
A classe Serial possui um atributo privado com_port responsável por

armazenar o HANDLE3 da porta serial utilizada. Os métodos is_valid, open, close e
write são responsáveis pela checagem da porta serial informada, abertura e
configuração da conexão serial, fechamento da conexão serial e escrita de dados na
porta, respectivamente.
Ainda na função de inicialização da API, a porta serial escolhida é testada
e a conexão serial é estabelecida. Ela é definida com baud rate de 115200bps, um
único bit de parada (stop bit), oito bits de dados e nenhuma paridade é selecionada.
No arquivo de configurações do plugin define-se qual a porta serial a ser
utilizada para conexão com a placa Arduino. Caso o arquivo não contenha essa
informação, o padrão utilizado é a porta COM3.
O pacote de dados gerado pelo plugin possui um limite definido em 720
bytes (ou 5760 bits). Como a linha de conexão possui um baud rate de 115200bps,
isso significa uma taxa de 20 (115200 / 5760 = 20) quadros de dados por segundo
(20 fps ou frames per second).
Quando um quadro de dados da API se encerra no lado do jogo, o evento
FRAME END é disparado e a respectiva callback registrada para aquele evento
(telemetry_frame_end) é executada pelo motor do jogo. A ocorrência deste evento
também significa que todas as callbacks registradas para atualizar os canais de
telemetria já foram executadas e que a estrutura de dados responsável por
armazenar a informação lida (telemetry) encontra-se atualizada.
A implementação da função telemetry_frame_end a torna responsável pela
preparação, empacotamento e envio dos dados à porta serial. Na etapa de
preparação, os dados são devidamente calibrados conforme necessidade. Por
exemplo, é nessa etapa que se converte a velocidade do veículo, inicialmente
expressa em m/s, para k/h ou mph (milhas por hora).
Na etapa de empacotamento, os dados são convertidos para bytes e
inseridos no pacote que será enviado. A Figura 14 ilustra o formato do pacote de
dados gerado pelo plugin. Um cabeçalho com tamanho de três bytes é utilizado para
identificar o pacote. O primeiro byte é o de sincronização (PACKET_SYNC), definido
3
Um HANDLE é um identificador utilizado pelo Sistema Operacional Windows para referenciar
objetos do seu kernel[[17], p.7].
49
com o valor hexadecimal 0xFF (255, em decimal). Esse byte tem a função de marcar
o início do pacote, otimizando o uso do buffer da porta serial e evitando possíveis
erros de leitura e de estouro de buffer. O segundo byte contém a versão do pacote
(PACKET_VER), a fim de garantir que emissor e receptor estejam manipulando a
mesma versão de pacote de dados. O terceiro byte (API_STATE) contém o estado
da API de Telemetria, indicando se está rodando ou em pausa. Se a API estiver
rodando, o plugin envia um byte chamado de STARTED_BYTE. Caso esteja em
pausa, o byte enviado é o PAUSED_BYTE. Este byte permite à placa receptora
Arduino identificar o estado da API e, a partir deste estado, definir seu
comportamento.
Após o cabeçalho, o restante das informações de telemetria são
adicionadas ao pacote, byte a byte. As informações booleanas de telemetria, que
indicam um estado (ligado ou desligado, conectado ou desconectado, etc), são
tratadas cada uma como um bit e empacotadas de 8 em 8 para serem enviadas em
um único byte.
Utilizando esta forma de empacotamento de bits, o plugin envia um byte
contendo o estado das luzes do veículo, como beacon, luz de estacionamento, seta
à esquerda, seta à direita, farol baixo, farol alto, luz de freio e luz de ré. Em outro
byte, ele envia o estado das luzes de advertência, tais como freio de
estacionamento, freio motor, pressão do ar baixa, pressão do ar em estado de
emergência, baixo nível de combustível, bateria em baixa voltagem, pressão do óleo
baixa, alerta de temperatura da água. Um terceiro byte fica responsável por
informações gerais do veículo, como uma indicação se o reboque está ou não
conectado, o estado dos limpadores de para-brisa, se a parte elétrica do caminhão
está ligada ou não e se o motor está em funcionamento ou não.
PACOTE DE DADOS DE TELEMETRIA

CABEÇALHO DADOS
INFORMAÇÕES DE
PACKET_SYNC PACKET_VER API_STATE
TELEMETRIA
Figura 14: Pacote de dados de telemetria
Na etapa de envio dos dados à porta serial, o pacote é carregado no buf-

fer da porta serial para ser lido pelo receptor (placa Arduino).
50
5 A PLACA CONTROLADORA ARDUINO
O jogo está rodando, o plugin está carregado e conectado à porta serial,

pronto para gerar os pacotes de dados da API de Telemetria. Agora é a vez da placa
Arduino fazer a sua parte, recepcionando os dados disponibilizados na porta serial,
exibindo as informações ao usuário através do painel de instrumentos e enviando os
comandos acionados pelo usuário ao jogo.
O modelo de placa escolhido para este trabalho foi a Arduino Leonardo. A
Leonardo é uma placa baseada no microcontrolador ATMEL ATmega32u4. Ela
contem 20 pinos de entrada e saída digitais, dos quais 7 podem ser utilizados como
saídas PWM4 e 12 como entradas analógicas[6].
A Leonardo difere das demais placas antecessoras pelo fato de que o
ATmega32u4 possui um sistema integrado de comunicação USB, eliminando a
necessidade de um segundo processador[6]. Isso permite à placa ser detectada
como um mouse, teclado ou, com alguns pequenos ajustes e implementações, ser
detectado como um joystick. Este é o principal motivo por ter sido a placa
selecionada para este projeto.
5.1 RECEPCIONANDO OS DADOS DA PORTA SERIAL
O código carregado na placa Arduino (sketch) possui uma estrutura de

dados (struct, em C++) semelhante à do plugin, responsável por armazenar os
dados de telemetria enviados.
4
PWM, ou Pulse Width Modulation (Modulação por largura de pulso) é uma técnica para obter
resultados analógicos por meios digitais. Saiba mais em: https://www.arduino.cc/en/Tutorial/PWM
51
Para recepcionar os dados, a placa Arduino deve ler o buffer da porta

serial na qual está fisicamente conectada. Para tanto, uma conexão serial deve ser
estabelecida pela placa. É fundamental que esta conexão tenha o mesmo baud rate
(115200bps) que a conexão serial estabelecida pelo plugin na porta. Isto garante que
escrita e leitura sejam realizadas de forma síncrona.
Uma vez configurada e inicializada a conexão, a placa aguarda até que a
quantidade de bytes disponíveis no buffer da porta serial seja igual ou maior que 16
bytes. Esse limite inferior de 16 bytes é imposto pelo plugin, que define um tamanho
de pacote sempre superior a essa quantidade de bytes. Ou seja, o menor pacote
gerado pelo plugin, definido como um pacote de dados de telemetria vazio, é
composto por exatos 16 bytes, incluindo o cabeçalho. Este pacote é utilizado como
um delimitador de ciclo da API, sendo enviado pelo plugin na função de inicialização
e na de finalização da API para indicar início e fim de ciclo, respectivamente.
Quando a quantidade de bytes disponíveis no buffer da porta serial atinge
a quantidade esperada, a placa inicia a leitura sequencial byte a byte, começando
pelo cabeçalho. O primeiro byte lido deve ser, obrigatoriamente, o byte de
sincronização (PACKET_SYNC), responsável por marcar o início de pacote de
dados, indicando à placa que naquele ponto do buffer inicia-se um pacote.
Identificado o início do pacote, o próximo byte deve ser o byte controlador de versão
(PACKET_VER). Este byte é responsável por garantir que plugin e Arduino estão se
comunicando com a mesma versão de pacote de dados. O próximo byte, indica o
estado da API de telemetria. Se a API estiver rodando, esse byte terá o valor
hexadecimal 0xBB (STARTED_BYTE). Do contrário, o byte contém o valor
hexadecimal 0xAA (PAUSED_BYTE), indicando que a API está em pausa. Nesse
momento, uma variável da estrutura de dados contida na placa armazena essa
informação de estado da API para uso em tomadas de decisões à frente em seu
código.
Uma vez que o cabeçalho é processado, permitindo identificar o início do
pacote, versão e estado da API, a placa prossegue a leitura sequencial dos
próximos bytes os quais contêm as informações de telemetria do jogo. Isto é, da
52
mesma forma que o plugin escreve os dados sequencialmente na porta serial, a

placa deve efetuar a leitura byte a byte obedecendo essa mesma sequência.
Conforme explicado na Seção 4.3, as informações booleanas da
telemetria são tratadas como bits, ou seja, são empacotadas de 8 em 8 para serem
enviadas em bytes. Assim, quando a placa lê esses bytes de informações
booleanas, ela deve checar cada bit, para saber o valor de cada uma das
informações de telemetria e atualizar as respectivas variáveis da estrutura de dados.
Isso é implementado no sketch utilizando-se lógica binária, através de operadores
de bit shift5 (rotação de bits) e de bit wise6 (comparação bit a bit)[[21], p.48]. Desta
forma, ao ler um byte contendo as informações das luzes do veículo, por exemplo, a
placa percorre o byte bit a bit, efetuando as devidas comparações para determinar o
estado de cada bit e, então, preencher os respectivos atributos da estrutura de
dados responsáveis por armazenar as informações das luzes do veículo.
5.2 EXIBINDO AS INFORMAÇÕES DE TELEMETRIA
Preenchida a estrutura de dados de telemetria, a placa já tem todas as

informações necessárias para gerenciar o painel de instrumentos que simula o
painel do veículo e exibir os dados ao usuário. O painel de instrumentos aqui
proposto utiliza-se de componentes eletrônicos simples e acessíveis no mercado, de
forma que qualquer jogador com um pouco conhecimento em eletrônica possa
montar seu próprio painel. Esta Seção aborda a forma como a placa Arduino e os
componentes foram utilizados para exibir os dados no painel, descrevendo
brevemente o funcionamento dos circuitos criados.
5
Saiba mais sobre bit shift com Arduino em <https://www.arduino.cc/en/Reference/Bitshift>
6
Saiba mais sobre bit wise com Arduino em <http://playground.arduino.cc/Code/BitMath>
53
5.2.1 O COMPUTADOR DE BORDO
Um componente eletrônico muito útil para exibição de informações ao

usuário é o display LCD matricial. Neste trabalho é utilizado um display LCD
genérico, com 16 colunas e 2 linhas (16x2). O modelo padrão do display utiliza 6
pinos de dados da placa Arduino, além dos pinos de terra (GND) e alimentação
(VCC). A fim de poupar os recursos da placa, uma versão do display com um módulo
serial I²C integrado é aconselhável, pois diminui o número de pinos utilizados para
apenas 2 (SCL e SDA), além dos pinos de terra (GND) e de alimentação (VCC). O
protocolo I²C implementa um barramento com apenas 2 vias que suporta uma
transferência bidirecional entre um emissor e diversos receptores. O emissor
controla o barramento, em particular a via responsável pelo clock da comunicação
(SCL). Os dados são transferidos entre emissor e receptor através da via de dados
seriais (SDA)[55]. A utilização deste protocolo reduz a utilização de recursos da
placa e possibilita a transferência em velocidades que chegam até a 3.4 Mbps[55].
O display 16x2 é utilizado pela placa para exibir informações de forma
semelhante a um display de computador de bordo dos veículos, trazendo dados
como velocidade do veículo em mph (milhas por hora) ou km/h, velocidade de
cruzeiro, marcha atual, percentual de combustível no tanque, odômetro, autonomia
do veículo, entre outras. As informações são exibidas em páginas, devido ao
tamanho limitado da tela de exibição (16 colunas por 2 linhas). Cada página contém
uma certa quantidade de informações e a troca entre as páginas é feita através de
um botão, de forma cíclica, tal qual ocorre nos painéis dos veículos do jogo.
Para realizar tal controle da troca de páginas, a placa mantém um registro
da página atualmente exibida no componente. Quando o botão é pressionado, a
placa checa se a página mostrada na tela é a última. Se for, volta para a primeira
página, reiniciando o ciclo, do contrário, a próxima página é exibida ao jogador.
O display LCD 16x2 também é utilizado pelo painel para exibir o estado do
sistema. Quando a placa é carregada ou a API está em pausa, uma mensagem é
exibida ao jogador, informando que o sistema está pronto e aguardando dados.
54
Figura 15: Display LCD 16x2

Fonte: Google Imagens
A Figura 15 traz uma foto de um display LCD como o utilizado neste

trabalho. O modelo da foto também já possui o módulo I²C integrado, como é
possível observar pelos quatro pinos visíveis na parte de baixo do componente.
5.2.2 O GERENCIAMENTO DE LEDS DO PAINEL
Além do uso do display para exibição de informações ao jogador, o painel

também conta com uma série de LEDs que indicam estados de componentes do
veículo, sinais de alertas e sinais de emergência. Considerando que há informações
booleanas de telemetria que representam, por exemplo, luzes do caminhão e luzes
de advertência, e desconsiderando outras informações que também podem ser
representadas por sinal de luz (ex.: estado do controle de cruzeiro, estado do freio
retarder, etc), tem-se pelo menos 16 bits (2 bytes) de dados a serem exibidos no
painel de instrumentos através de LEDs.
Neste ponto, observa-se o seguinte problema: a placa Arduino Leonardo
possui 20 pinos de entrada e saída digitais. Destes, excluem-se os pinos 0 (RX) e 1
(TX), os quais são utilizados pela comunicação serial da placa[8]. Dos 18 pinos
restantes, dois deles são utilizados na conexão I²C com o display LCD utilizado
(SDA e SCL), deixando livres 16 pinos de entrada e saída. Caso o painel utilize
55
estes 16 pinos livres, nenhum outro componente eletrônico poderia mais ser
conectado, visto que esgotaram-se os as entradas e saídas da placa.
Ao se deparar com o problema acima, alguns jogadores que vêm
desenvolvendo painéis semelhantes cujos projetos podem ser encontrados na
Internet, adicionam placas extras ao sistema ou optam por placas com maior
quantidade de pinos, como a Arduino Mega. Tais soluções não são ideais, visto que
adicionar placas extras ao sistema, além de encarecê-lo, vai ocasionar maior
trabalho e custo de recursos para tratar a troca de informações entre as placas, além
de prováveis ajustes na implementação do plugin. E optar por placas como Arduino
Mega, levaria à perda do recurso de simulação de mouse, teclado ou joystick, já que
este modelo não emula tais recursos.
Para resolver tal questão, a solução escolhida neste projeto foi utilizar um
conjunto de circuitos integrados (CI) para expandir as portas do Arduino. Para o caso
dos LEDs, o CI utilizado foi o 74HC595. Este CI tem como função, converter uma
entrada de 8 bits serial em uma saída de 8 bits serial ou paralela, atuando como um
registrador de deslocamento (shift register).
Um shift register é um dispositivo que possibilita expandir entradas e
saídas de um microcontrolador. Em outras palavras, um microcontrolador se
comunica com um shift register utilizando informação serializada e este se encarrega
de disponibilizar essa informação de forma paralela em suas saídas. O contrário
também é verdadeiro, quando um shift register lê informações paralelas através de
suas entradas e disponibiliza-as ao microcontrolador de forma serializada[49].
Existem basicamente dois tipos de shift register, que são os do tipo SIPO
(Serial-In-Parallel-Out) e os do tipo PISO (Parallel-In-Serial-Out). O CI 74HC595 é do
tipo SIPO, ou seja, entrada serial com saída paralela. Ele é constantemente utilizado
para controlar um grande número de saídas, tais como LEDs. O tipo PISO, como o
CI 74HC165, é ideal para ler um conjunto de entradas de forma paralela (ex.:
botões) e disponibilizar os dados ao microcontrolador de forma serial[49].
Esses circuitos integrados são chamados de registradores de
deslocamento (shift register) devido à forma como os dados se deslocam através de
56
seus flip-flops7. O 74HC595 é um registrador de deslocamento de 8 bits, ou seja, ele

é capaz de armazenar 8 bits em seus flip-flops, sendo cada bit disponibilizado em
uma porta de saída do CI (Pinos Q0 a Q7 na Figura 16).
Figura 16: Pinagem do registrador

de deslocamento 74HC595
Fonte: [7]
Para controlar as suas 8 portas de saída, o CI 74HC595 depende de

apenas 3 portas da placa Arduino. Ligando a saída serial de um 74HC595 à entrada
de dados de um outro 74HC595, expandem-se mais 8 portas. Cascateando outros
CI do mesmo modelo dessa forma, é possível aumentar consideravelmente a
quantidade de portas de saída disponíveis, acrescentando 8 portas para cada CI
adicional, ao mesmo custo de apenas 3 portas da placa microcontroladora.
Para que o CI funcione corretamente, as 3 portas da placa Arduino devem
estar conectadas às portas latch (ST_CP), clock (SH_CP) e data (DS) do registrador.
A porta data é responsável por receber os dados, bit a bit, através de uma
comunicação serial síncrona (vide Seção 3.3.2). Quando um bit é colocado naquela
porta, ele só será armazenado nos flip-flops do registrador caso seja efetuado um
pulso na porta clock, elevando o sinal lógico desta porta de 0 para 1. O processo de
disponibilizar o bit em na porta DS, seguido de um pulso de clock que o delineia,
deve ser repetido para cada um dos demais bits. Cada bit novo desloca o
7
Circuitos sequenciais elementares capazes de armazenar a informação contida, ou seja,
funcionam como um elemento de memória que armazena um bit (nível lógico)
temporariamente[43].
57
antecessor na direção do bit menos significativo, ocupando seu lugar. Uma vez que
todos os bits tenham sido transmitidos ao registrador, um pulso na porta latch faz
com que os estados (HIGH ou LOW) de cada bit sejam devidamente entregues aos
respectivos pinos da saída paralela do registrador, apresentando o byte de uma só
vez[7].
A IDE do projeto Arduino possui a função nativa ShiftOut que encapsula o
procedimento acima descrito, simplificando a utilização do registrador de
deslocamento[10]. Portanto, é utilizando esse recurso de registradores de
deslocamento que a placa Arduino gerencia os LEDs responsáveis pelas
informações de luzes, indicadores e alertas do veículo. O painel conta com um
circuito criado com 3 CI 74HC595, o que representa um total de 24 saídas digitais. O
circuito é alimentado por uma fonte externa e as saídas são ativadas por meio de
transistores.
Figura 17: Simulação de circuito com CI 74HC595 e uso de transístores
A Figura 17 traz uma simulação criada através do site Autodesk Cir-

cuits[12] a fim de modelar o funcionamento de um circuito criado com uma placa
Arduino e três registradores de deslocamento 74HC595 em cascata, acionando 24
LEDs através de transistores NPN. Os fios laranja, turquesa e amarelo, conectados
respectivamente às portas 8, 7 e 4 da placa Arduino, fazem a conexão com os CI
através das portas latch, clock e data. Os CI são ligados em cascata, o que significa
que compartilham os sinais de latch e clock e a saída serial de um CI está conectado
58
à entrada de dados do próximo CI, fazendo com que os bits se desloquem de um CI

para o outro, do bit mais significativo para o bit menos significativo.
Conforme observações constantes na datasheet do microcontrolador
ATmega32u4[[11], p.384], embora a corrente máxima suportada seja de 40mA por
pino quando operando em 5v, há outros limitadores como restrições da porta USB e
limitação da corrente por bloco de pinos. Portanto, a placa não daria conta de
fornecer corrente elétrica suficiente a todos os componentes eletrônicos do painel
por si só. Por tal motivo, uma fonte de tensão externa, capaz de fornecer tensões e
corrente adequadas foi utilizada na alimentação dos componentes. Uma vez que a
alimentação é externa à placa, foram utilizados transistores NPN para que a placa
controle o estado de cada componente (ligado ou desligado).
Figura 18: Símbolo de um

transístor NPN
Fonte: [50]
Um transístor é, basicamente, um componente eletrônico que atua como

um controlador de passagem de corrente elétrica em circuitos eletrônicos[50]. No
caso do transístor NPN, quando uma corrente elétrica chega em seu terminal
coletor, marcado com uma letra C na Figura 18, ela só passará para o terminal
emissor (E) caso haja tensão no terminal base (B). Do contrário, o dispositivo fica
em estado de corte e a corrente não passa ao emissor (E).
Retornando à Figura 17, tem-se que os fios verdes representam as vias de
dados (Q0 a Q7 de cada CI), totalizando 24 vias, que são conectadas diretamente
ao terminal base de cada respectivo transístor. A fonte de tensão é conectada à pro-
toboard (placa de ensaio ou prototipagem) de forma a fornecer tensão ao terminal
59
coletor de todos os transístores. Os fios cinza conectam os terminais emissores dos

transístores aos respectivos LEDs.
Assim, quando a placa Arduino necessita acender um LED, ela envia um
sinal lógico alto (bit 1) à saída correspondente nos CI. O sinal é, então, repassado
ao terminal base do transístor que, por sua vez, permite a passagem da corrente
elétrica para o terminal emissor, acendendo o LED desejado.
5.2.3 COMPONENTES ANALÓGICOS
Algumas informações de Telemetria advindas do jogo são interessantes

para exibição em instrumentos analógicos, tai como a velocidade do veículo e
rotação do motor. Para exibir estas informações ao jogador, foram utilizados dois
servomotores no protótipo do painel de instrumentos.
Servomotores (ou simplesmente servos) são motores comumente
utilizados em modelos RC (remote controlled). Eles são compostos por um sistema
de engrenagens e um eixo que pode ser precisamente controlado. Os servos padrão
permitem que seu eixo seja posicionado em ângulos, normalmente entre 0 e 180
graus. Existem, também, servos de rotação contínua, onde apenas a velocidade e
direção de rotação do eixo são passíveis de serem controladas[9].
A IDE do projeto Arduino possui uma biblioteca nativa para gerenciamento
de servomotores, a qual possibilita o controle de até 48 servos simultaneamente,
dependendo da placa Arduino utilizada.
Servomotores possuem 3 vias de conexão: alimentação, terra e sinal. A
alimentação é tipicamente identificada por um fio vermelho. O terra é identificado por
um fio preto ou marrom, conforme o modelo, enquanto que a via de sinal é
identificada por um fio branco, amarelo ou laranja, dependendo do servomotor
utilizado[9].
Como os servomotores são componentes que drenam uma energia
considerável, a placa Arduino não conseguirá alimentar mais que um ou dois
motores. Neste caso, os servos devem ser alimentados por uma fonte de tensão
60
externa, enquanto a placa Arduino apenas gerencia sua entrada de sinal. Importante
ressaltar que os conectores de terra da fonte de tensão externa e da placa Arduino
devem estar conectados[9].
O protótipo deste trabalho utiliza dois servomotores para exibir as
informações de velocidade do caminhão (speed) e rotação do motor (engine_rpm).
Ambos são alimentados por uma fonte externa. A placa Arduino recebe as
informações do plugin e as coloca no servomotor convertidas em graus de rotação,
obedecidas as restrições de giro do eixo do motor.
5.3 ENVIANDO COMANDOS AO JOGO
Uma das propostas deste trabalho é que o painel criado não só receba as
informações do jogo, mas que também envie comandos para aquele, como
acionamento de freios auxiliares, freio de estacionamento, sinal de alerta, partida do
veículo, etc. Como o jogo não implementa uma API que receba comandos externos,
uma maneira viável de prover essa função seria emular o teclado e enviar as teclas
para o jogo, como se o jogador estivesse acionando-as via teclado. A placa Arduino
Leonardo já possui esse recurso nativo em seu microcontrolador. Porém, a proposta
neste trabalho é que a placa emule um joystick, de forma que o jogo o identifique
como um controlador e permita configurar seus comandos, independente de como
está a configuração do teclado no jogo.
Em 19 de novembro de 2015, o desenvolvedor Matthew Heironimous
(conhecido como Matthew H.) disponibilizou em seu blog sobre programação um
tutorial de como fazer para que a placas Arduino baseadas no microcontrolador
ATmega32u4 fossem detectadas pelo sistema operacional Windows como um joy-
stick e funcionasse como tal[18].
O simples download e inclusão da biblioteca desenvolvida por Matthew já
é suficiente para que a placa Arduino Leonardo seja detectada como um joystick e
possa ser normalmente configurado no sistema operacional e no jogo. No entanto,
61
para que a placa envie os comandos para o jogo, é necessário que os botões sejam
mapeados via código.
Figura 19: Screenshot - Arduino Leonardo como joystick
A Figura 19 mostra o Arduino Leonardo sendo detectado pelo ETS2 como

um controle para jogos. A configuração das funções dos comandos nas opções do
jogo devem obedecer ao mapeamento realizado via código. Ou seja, se o botão que
aciona o freio de estacionamento no painel está mapeado no índice 0 no código, no
jogo a convenção deve ser obedecida.
62
O protótipo possui atualmente 15 botões. De forma análoga e pela mesma

motivação de solucionar a questão do número de portas do microcontrolador, foram
utilizados 2 CI registradores de deslocamento modelo 74HC165 para efetuar a
leitura dos botões.
O CI 74HC165, cujo o diagrama de pinagem consta na Figura 20, é um
registrador de deslocamento do tipo PISO (Parallel-In-Serial-Out), ou seja, entrada
em paralelo, saída em serial. Porém, o fluxo de dados dessa vez será dos CI para a
placa, isto é, cada CI irá ler 8 botões e enviar um byte correspondente à placa
controladora. Por exemplo, quando a placa ler um byte 0b00000001, significa que
apenas o botão na posição 0 (bit menos significativo) está em estado lógico alto.
Figura 20: Diagrama de

pinagem do 74HC165
Fonte: Datasheet do CI
O funcionamento do 74HC165 exige a utilização de uma porta a mais da

placa Arduino que o 74CH595 sendo, portanto, utilizadas 4 portas. As portas
necessárias para funcionamento são Parallel Load (PL), Clock Enabled (CE), Data
Set (DS) e Clock Pin (CP). As portas data e clock tem o funcionamento descrito para
as do 74HC595. A diferença está nas outras duas portas. Quando a porta PL detecta
um sinal lógico baixo (bit 0), os dados das portas de entrada (D0 a D7) são
carregados no registrador de forma assíncrona. Quando PL é setada para um sinal
lógico alto (bit 1), os dados entram de forma serializada na porta DS, deslocando-se
bit a bit para a direita (no sentido do bit menos significativo), a cada pulso de clock. A
porta Clock Enabled tem a função de permitir que o pulso de clock se propague
através dos flip-flops do CI.
63
Figura 21: Simulação de circuito com 74HC165
A Figura 21 traz uma simulação de um circuito utilizando dois registradores

de deslocamento 74HC165 para controlar 10 botões. O mesmo circuito é utilizado
pelo protótipo do painel de instrumentos para gerenciar os botões de comando.
64
6 O PROTÓTIPO
Uma das propostas deste trabalho é apresentar um protótipo de baixo

custo, criado com componentes eletrônicos acessíveis, de forma que qualquer
jogador com um pouco de conhecimento em eletrônica básica seja capaz de montar.
A função do protótipo é simular um painel de instrumentos e comandos
para o veículo, trazendo informações de computador de bordo, luzes do veículo,
sinais de alerta e emergência ao jogador.
Figura 22: Modelo do protótipo criado com SketchUp
Conforme modelo apresentado na Figura 22, criado com o programa de

modelagem 3D SketchUp, a estrutura possibilita o encaixe em móveis de
computadores de até 2,5cm de espessura, bastando ajustar as presilhas para se
prender ao móvel e impedir movimentos indesejados durante sua utilização.
A criação de um modelo 3D facilitou a criação do protótipo, possibilitando
planejar a estrutura do painel, posicionamento dos componentes e espaço
65
necessário para uso antes mesmo de criar o modelo físico para experimentação.
Aliados à este modelo 3D criado, a criação de esquemas elétricos, simulação de
circuitos e experimentos com componentes eletrônicos através das ferramentas Ev-
ery Circuit8, Autodesk Circuits9 e Fritzing10, viabilizaram a elaboração dos circuitos
elétricos, inclusive facilitando os cálculos envolvendo os circuitos, componentes e
demais variáveis, sem exigências de profundos conhecimentos em eletrônica.
Para alimentação dos circuitos elétricos, foi utilizada uma fonte de
computador ATX. A vantagem de utilização desta fonte é que ela provê tensões
estratégicas para o projeto, como 3.3v, 5v e 12v, com corrente suficiente para o
sistema criado. Como essas fontes são feitas para rodarem dentro de um gabinete,
ligadas apenas quando o botão de power é acionado, uma adaptação faz-se
necessária para que elas liguem externamente. É necessário, para tanto, criar um
jumper entre fios específicos que armam a fonte. Em fontes ATX, geralmente os fios
são verde (PS_ON) e preto (COM ou Terra). Neste caso, uma chave foi colocada
entre o fio de ativação (cor verde) e um dos fios terra da fonte para controlar o
processo de ligar e desligar.
6.1 O CIRCUITO DE SAÍDA
O circuito de saída, responsável pela exibição dos dados de telemetria ao

jogador, é composto por um sistema de LEDs em paralelo para as luzes e alertas do
painel do veículo, dois servomotores para simular velocímetro e conta-giros, além
um display LCD 16x2 simulando um computador de bordo.
Todo o circuito é alimentado pela fonte externa ATX com uma tensão de
5v. A placa Arduino que, por sua vez, é alimentada pela porta USB, ocupa-se apenas
em enviar sinais lógicos, sem necessidade de fornecer tensão e corrente para
nenhum componente do painel. Em outras palavras, enquanto a fonte externa se
8
Saiba mais em http://everycircuit.com
9
Saiba mais em https://circuits.io/
10
Saiba mais em http://fritzing.org/home/
66
encarrega da alimentação dos componentes, a função da placa Arduino limita-se a

controlar os estados dos LEDs, posição angular dos servomotores e informações
exibidas no display LCD.
6.1.1 O SISTEMA DE LEDS
Foram utilizados 3 circuitos integrados 74HC595 que possibilitam o

controle de até 8 saídas cada. As 24 saídas gerenciam os transístores responsáveis
pelo acionamento dos LEDs. Os LEDs são gerenciados pela placa na forma descrita
na Seção 5.2.2 e a ligação segue o esquema contido na Figura 17.
A Figura 23 traz uma simulação do circuito montado para controle dos
LEDs no painel criada com o aplicativo Every Circuit. No momento capturado na
figura, os LEDs acesos, consumem uma corrente de 231mA. Os círculos vermelhos,
contendo um bit 1 em seu interior, indicam uma fonte lógica fornecendo um sinal
lógico alto para o terminal base do respectivo transístor, possibilitando passagem da
corrente do terminal coletor para o emissor, acendendo o LED conectado. Os
círculos azuis, contendo um bit 0 em seu interior, indicam uma fonte lógica
fornecendo um sinal lógico baixo (bit 0) para o terminal base do respectivo transístor,
o qual retém a passagem da corrente do terminal coletor para o emissor, mantendo
o LED apagado enquanto este estado lógico permanece. Como, no momento, o
sistema utiliza apenas 17 LEDs, os componentes conectados às portas lógicas azuis
na figura não estão sendo utilizados no painel.
67
Figura 23: Circuito de LEDs do painel
Na simulação apresentada, é possível observar a tensão e corrente que

chega em cada componentes, o que facilitou o cálculo dos resistores a serem
utilizados, visando oferecer corrente e tensão adequadas a cada LED conforme suas
especificações. Todos os LEDs foram conectados de forma que compartilhem o
negativo (cátodo comum) no circuito. Os terminais positivos (ânodo), foram
conectados cada a um a seu transístor correspondente.
6.1.2 OS INSTRUMENTOS
Para exibição da velocidade e rotação do motor, a placa Arduino utiliza os

bytes correspondentes recebidos do plugin e os converte em ângulos a serem
enviados aos servomotores que, geralmente, atuam com medidas de 0º a 180º. O
painel conta com 2 micro servomotores 9g SG90 da Tower Pro comumente
68
utilizados em aeromodelos e facilmente encontrados no mercado. Como esses

motores operam com tensões entre 3v e 7,2v, foram alimentados com 5v oriundos
da fonte externa.
Figura 24: Micro servo

Fonte: Site do fabricante
6.1.3 O COMPUTADOR DE BORDO
Para simular o computador de bordo do caminhão, o display LCD utilizado

foi de 16 colunas e 2 linhas, com texto branco e luz de fundo azul, conforme Figura
15. Ele funciona conforme descrito na Seção 5.2.1 e é facilmente encontrado à
venda na internet juntamente com seu módulo I²C. O componente necessita de uma
tensão entre 4,5v e 5,5v. Portanto, uma tensão de 5v é provida pela fonte externa,
enquanto a placa Arduino gerencia suas informações utilizando-se apenas de dois
pinos de saída seguindo a implementação do protocolo I²C. Um push button
localizado à direita possibilita a troca das informações exibidas na tela e o contraste
desta pode ser regulado através de um trimpot (componente semelhante a um
pequeno potenciômetro) contido no módulo I2C acoplado ao display.
Abaixo, na Figura 25, são apresentadas fotos das telas do display LCD
utilizado no painel. A tela superior demonstra a mensagem exibida quando o sistema
está pronto, aguardando dados do jogo para iniciar. Essa mensagem também é
exibida quando o jogo é pausado.
69
Figura 25: Telas do computador de bordo
As quatro telas seguintes correspondem às telas do computador de bordo

do painel, trazendo as informações de velocidade em mph ou km/h, controle de
cruzeiro em mph ou km/h, qual a marcha engatada no veículo, percentual de
combustível no tanque, quantidade de combustível, em litros, no tanque, odômetro,
autonomia e consumo médio.
6.2 O CIRCUITO DE ENTRADA
O circuito de entrada de dados é composto pelo conjunto de botões e

chaves utilizados pelo jogador para entrada de comandos a serem transmitidos ao
jogo. O circuito utiliza dois CI 74HC165 para gerenciar os 15 botões (máximo de 16)
do painel.
Conforme o circuito base demonstrado na Figura 21, todos os botões e
chaves recebem uma tensão da placa controladora em um de seus terminais. Em
seu outro terminal, uma via é conectada à entrada correspondente nos CI 74HC165
ligados em cascata. Outra via, partindo do mesmo terminal do botão ou chave, é
70
ligada em um resistor de pull down (conectado ao terra). Quando um botão ou chave

é acionado, a corrente passa de um terminal para o outro e a entrada
correspondente no CI detecta essa tensão como um sinal lógico alto (bit 1). Quando
o botão é liberado, o CI descarrega a tensão no terra via resistor de pull down,
passando a ter um bit 0 naquela porta correspondente do CI. A placa Arduino recebe
essas informações do CI e envia um comando correspondente ao jogo emulando um
joystick.
6.3 UMA VISÃO GERAL DA ESTRUTURA DO PROTÓTIPO
A estrutura base do protótipo ocupa um espaço de 36cm de largura, 25cm

de comprimento e 11cm de altura. Foi construída com restos de compensado de
madeira MDF, geralmente descartados em madeireiras ou doados a interessados,
como foi o caso.
O circuito fica acomodado na parte traseira da estrutura, distribuídos em
duas protoboard, afixadas na base da estrutura. Os cabos que saem dos
componentes eletrônicos são conectados em bornes afixados à base do protótipo. A
partir dos bornes, os cabos são ligados às protoboards. A placa Arduino Leonardo
fica também na parte traseira, entre as duas protoboards, de forma que o cabo USB
possa ser conectado ao computador sem problemas. O cabeamento da fonte
externa também chega pela parte traseira, onde se conecta aos circuitos e
componentes.
A Figura 26 traz uma foto do circuito de entrada de dados, onde os botões
e chaves utilizados pelo painel são conectados e gerenciados. Na parte de baixo
encontram-se os bornes onde os cabos que vêm dos botões são conectados. A
partir destes conectores bornes, jumpers fazem a ligação com os circuitos
integrados anexos à protoboard.
71
Figura 26: Foto do circuito de

entrada
A Figura 27 apresenta uma foto do circuito de saída, onde é possível

observar os 3 CI 74HC595 conectados em cascata, distribuindo as conexões com os
transístores que acionam os LEDs do painel.
Figura 27: Foto do circuito de saída
A Figura 28, por fim, traz uma foto da visão frontal do painel, em
funcionamento, aguardando dados do jogo. Nessa foto, é possível observar todos os
72
componentes afixados ao painel, já conectados e alimentados, pronto para

execução.
Figura 28: Visão frontal do painel

73
CONCLUSÕES E TRABALHOS FUTUROS
Neste trabalho, foi desenvolvido um plugin em linguagem C++ com o

objetivo de extrair as informações de telemetria dos caminhões do jogo de simulação
Euro Truck Simulator 2 da produtora tcheca SCS Software, utilizando o SDK
fornecido pela empresa para acesso à API de Telemetria. O objetivo deste plugin é
viabilizar a produção de um painel de instrumentos acessível, de baixo custo e de
fácil construção, que interaja com o jogo, acionando comandos no veículo, exibindo
informações do caminhão ao jogador em tempo real, enfim, aumentando o grau de
imersão. Uma placa microcontroladora Arduino Leonardo foi utilizada para fazer a
ponte entre painel de instrumentos e jogo. Para isso, a placa recebe os dados do
plugin os envia ao painel para exibição nos componentes eletrônicos, ao mesmo
tempo em que envia ao jogo comandos acionados pelo jogador no painel.
A fim de facilitar a compreensão do funcionamento do sistema composto
por plugin, microcontrolador e painel, foram apresentados conceitos teóricos
importantes sobre o kit de desenvolvimento fornecido pela produtora do jogo, sobre
a API de telemetria do jogo, conceitos relacionados à placa Arduino e sobre o
funcionamento do protótipo criado para o painel.
Conclui-se que o SDK fornecido possibilita uma gama de possibilidades e
que o plugin desenvolvido mostra-se capaz de obter quaisquer informações
disponibilizadas pelo jogo, podendo ser facilmente expandido e adaptado. Por
consequência, o plugin atinge seu objetivo de viabilizar a construção de um painel
de instrumentos, seja simples e de baixo custo, ou mesmo um painel mais complexo
com maior investimento.
A placa Arduino Leonardo demonstra elevado potencial para a proposta de
interação com jogos em geral, uma vez que aqui foi demonstrado que a mesma é
capaz de emular de forma simples um complexo joystick.
O protótipo criado funcionou como o esperado, demonstrando a
viabilidade do projeto, atingindo seu objetivo, considerando que seu custo estimado
do projeto ficou bem atraente, girando próximo de R$300,00.
74
Como trabalho futuro, pretende-se a melhoria do fator estético bem como

a implementação de novos recursos, com criação de uma estrutura maior, que
possibilite uma maior quantidade de instrumentos e componentes, simulando com
mais propriedade um painel real de caminhão. Pretende-se, ainda, criar uma
documentação para os códigos-fontes a fim de disponibilizá-los na Internet para
aqueles que quiserem desenvolver seus próprios controladores ou executar o
projeto proposto.
Objetiva-se também a continuidade deste projeto em cursos de pós-
graduação, buscando melhorias e otimizações que elevem o grau de funcionalidade
do projeto.
75
REFERÊNCIAS BIBLIOGRÁFICAS
[1] ABECASIS, David. Telemetria – Conceitos e Aplicações. Disponível em
<http://cfrg.ccmar.ualg.pt//documents/Telemetry%20concepts%20and
%20applications.pdf> Acesso em 21 set. 2016.
[2] AFONSO, Diógenes. Radicais Greco-Latinos. Disponível em
<http://www.educacional.com.br/upload/blogsite/5094/5094442/9140/radicais
%20greco-latinos.pdf> Acesso em 21 set. 2016.
[3] ANTONIO, Marco. Apostila de programação de microcontroladores PIC
usando linguagem C. Disponível em
<http://www.pictronics.com.br/downloads/apostilas/Apostila-Pic-C.pdf> Acesso
em 08 out. 2016.
[4] Arduino Website. SN74HC165N. Disponível em
<http://playground.arduino.cc/Code/ShiftRegSN74HC165N> Acesso em 02
dez. 2016.
[5] Arduino Website. Arduino - Introduction. Disponível em
<https://www.arduino.cc/en/Guide/Introduction> Acesso em 30 set. 2016.
[6] Arduino Website. Arduino Leonardo – Overview. Disponível em
<https://www.arduino.cc/en/Main/ArduinoBoardLeonardo> Acesso em 29 nov.
2016.
[7] Arduino Website. Arduino Playground – LearningShiftOut. Disponível em
<http://playground.arduino.cc/Portugues/LearningShiftOut> Acesso em 01
dez. 2016.
[8] Arduino Website. Serial. Disponível em
<http://playground.arduino.cc/Referencia/Serial> Acesso em 29 nov. 2016.
[9] Arduino Website. Servo. Disponível em
<https://www.arduino.cc/en/Reference/Servo> Acesso em 02 dez. 2016.
[10] Arduino Website. ShiftOut(). Disponível em
<https://www.arduino.cc/en/Reference/shiftOut> Acesso em 01 dez. 2016.
[11] Atmel Website. ATmega32u4 Datasheet. Disponível em
<http://www.atmel.com/Images/Atmel-7766-8-bit-AVR-ATmega16U4-
32U4_Datasheet.pdf> Acesso em 01 dez. 2016.
76
[12] Autodesk Circuits. Disponível em <https://circuits.io/> Acesso em 01 dez.

2016.
[13] BANZI, Massimo. Send in the clones. Disponível em
<https://blog.arduino.cc/2013/07/10/send-in-the-clones/> Acesso em 30 set.
2016.
[14] CARVALHO, Fabrício Kolk; OLIVEIRA, André Alves. TuKolk: Um jogo de
console utilizando a plataforma Arduino. 2014. Trabalho de Conclusão de
Curso - Bacharel em Sistemas de Informação, UNIRIO, Rio de Janeiro, RJ.
[15] Documentação do SDK da SCS Software,versão 1.6. Disponível em
<http://download.eurotrucksimulator2.com/scs_sdk_1_6.zip> Acesso em 21
set. 2016.
[16] Fórum Oficial da SCS Software. ETS2/ATS Telemetry Web Server +
Mobile Dashboard. Disponível em <http://forum.scssoft.com/viewtopic.php?
f=41&t=171000> Acesso em 07 set. 2016.
[17] HART, Johnson M. Windows system programming, 40 ed. Westford:
Addison-Wesley, 2010.
[18] HEIRONIMUS, Matthew. Arduino Joystick Library. Disponível em
<http://mheironimus.blogspot.com.br/2015/11/arduino-joystick-library.html>
Acesso em 02 dez. 2016.
[19] Institute for Simulation & Training. What is simulation? Disponível em:
<http://www.ist.ucf.edu/background.htm> Acesso em 06 ago. 2016.
[20] ETS2 Telemetry Web Server 3.2.5 + Mobile Dashboard. Disponível
em:<https://github.com/Funbit/ets2-telemetry-server> Acesso em 07 set. 2016.
[21] KERNIGHAN, Brian W; RITCHIE, Dennis M. The C Programming
Language, 2nd ed. New Jersey: Prentice-Hall, 1988.
[22] MATTOS, Alessandro Nicoli. Telemetria e conceitos relacionados. São
José dos Campos. 2004.
[23] MCROBERTS, Michael. Arduino Básico. Tradução de Rafael Zanolli.
São Paulo: Novatec Editora, 2011. Título original: Beginning arduino.
77
[24] Microsoft Developer Network. Arquivos mapeados em memória.

Disponível em <https://msdn.microsoft.com/pt-
br/library/dd997372(v=vs.110).aspx> Acesso em 07 set. 2016.
[25] Microsoft Developer Network. Callback Functions. Disponível em
<https://msdn.microsoft.com/en-us/library/d186xcf0(v=vs.110).aspx> Acesso
em 29 out. 2016.
[26] National Instruments. RS-232, RS-422, RS-485 Serial Communication
General Concepts. Disponível em <http://www.ni.com/white-
paper/11390/en/>. Acesso em 08 out. 2016.
[27] Object Managment Group Official Site. Documents Associated With
Unified Modeling Language (UML) Version 2.5. Disponível em
<http://www.omg.org/spec/UML/2.5/> Acesso em 15 nov. 2016.
[28] O que é API? Disponível em <http://canaltech.com.br/o-que-e/software/o-
que-e-api/> Acesso em 20 set. 2016.
[29] O que é uma DLL? Disponível em: <https://support.microsoft.com/pt-
br/kb/815065> Acesso em 19 set. 2016.
[30] Página Oficial do Euro Truck Simulator 2. Truckers Wanted! Disponível
em <http://www.eurotrucksimulator2.com/> Acesso em 06 ago. 2016.
[31] PARKER, Silas. Euro Truck Simulator 2 - Prototype Real Dashboard.
Disponível em <http://skyhisi.blogspot.com.br/2013/09/euro-truck-simulator-2-
prototype-real.html> Acesso em 21 out. 2016.
[32] Portal da Loja Steam. Grand Theft Auto V. Disponível em
<http://store.steampowered.com/app/271590/?snr=1_5_9__205> Acesso em
06 ago. 2016.
[33] Portal da Loja da Steam. Euro Truck Simulator 2. Disponível em
<http://store.steampowered.com/app/227300/?snr=1_7_15__13> Acesso em
08 ago. 2016.
[34] Portal da Loja da Steam. Bem-vindo ao Steam. Disponível em
<http://store.steampowered.com/about/> Acesso em 07 ago. 2016.
[35] Portal Instructables. Disponível em <http://www.instructables.com/>
Acesso em 23 ago. 2016.
78
[36] Portal Instructables. Arduino game Search Results. Disponível em

<http://www.instructables.com/howto/arduino+game/> Acesso em 23 ago.
2016.
[37] Portal UOL Jogos. A história dos videogames. Disponível em:
<http://jogos.uol.com.br/reportagens/historia/1961.jhtm> Acesso em 06 ago.
2016.
[38] Portal SteamSpy. App Data – Euro Truck Simulator 2. Disponível em
<http://steamspy.com/app/227300> Acesso em 09 ago. 2016.
[39] REISDORPH, Kent. Using callbacks in DLLs. Disponível em:
<http://bcbjournal.org/articles/vol3/9902/Using_callbacks_in_DLLs.htm>
Acesso em 18 set. 2016.
[40] SCS Software Blog. A look on the technical side: Telemetry SDK.
Disponível em <http://blog.scssoft.com/2015/02/a-look-on-technical-side-
telemetry-sdk.html> Acesso em 07 set. 2016.
[41] SCS Software Blog. SCS is celebrating. Disponível em
<http://blog.scssoft.com/2012/10/scs-is-celebrating.html> Acesso em 06 ago.
2016.
[42] Silicon Labs – Support Documents. Serial Communications. Disponível
em <http://www.silabs.com/Support
%20Documents/Software/Serial_Communications.pdf> Acesso em 14 set.
2016.
[43] SILVA, Luiz Marcelo Chiesse. Análise de Circuitos Digitais – Flip-Flops.
Disponível em <http://www.cp.utfpr.edu.br/chiesse/Sistemas_Digitais/Flip-
flop.pdf> Acesso em 01 dez. 2016.
[44] Site Oficial da SCS Software. Documentation/Engine/SDK/Telemetry.
Disponível em
<http://modding.scssoft.com/wiki/Documentation/Engine/SDK/Telemetry>
Acesso em 07 ago. 2016.
[45] Sparkfun Tutorials Website. Serial Communication - Introduction.
Disponível em <https://learn.sparkfun.com/tutorials/serial-
communication/serial-intro> Acesso em 08 out. 2016.
79
[46] Sparkfun Tutorials Website. Serial Communication – Rules of Serial.

Disponível em <https://learn.sparkfun.com/tutorials/serial-
communication/rules-of-serial> Acesso em 08 out. 2016.
[47] Sparkfun Tutorials Website. Serial Communication – Wiring and
Hardware. Disponível em <https://learn.sparkfun.com/tutorials/serial-
communication/wiring-and-hardware> Acesso em 08 out. 2016.
[48] Sparkfun Tutorials Website. Serial Communication – UARTs. Disponível
em <https://learn.sparkfun.com/tutorials/serial-communication/uarts> Acesso
em 08 out. 2016.
[49] Sparkfun Tutorials Website. Shift Registers. Disponível em
<https://learn.sparkfun.com/tutorials/shift-registers> Acesso em 30 nov. 2016.
[50] SparkFun Tutorials Website. Transistors. Disponível em
<https://learn.sparkfun.com/tutorials/transistors> Acesso em 01 dez. 2016.
[51] Support Microsoft. HOWTO: Specify Serial Ports Larger than COM9.
Disponível em <https://support.microsoft.com/en-us/kb/115831> Acesso em
21 out. 2016.
[52] TANENBAUM, Andrew S. Sistemas operacionais modernos, 3 ed. São
Paulo: Pearson Prentice-Hall, 2009.
[53] TechTerms online dictionary. Plug-in. Disponível em
<http://techterms.com/definition/plugin> Acesso em 18 out. 2016.
[54] Telemetry Applications Handbook. Disponível em
<http://www.dtic.mil/dtic/tr/fulltext/u2/a193741.pdf> Acesso em 21 set. 2016.
[55] Texas Instruments Official Website. Overview for I2C. Disponível em
<http://www.ti.com/lsds/ti/interface/i2c-overview.page> Acesso em 27 nov.
2016.
[56] What is SDK. Disponível em <http://www.codefuel.com/glossary/sdk/>
Acesso em 09 set. 2016.
[57] Windows 10 SDK. Disponível em <https://developer.microsoft.com/en-
us/windows/downloads/windows-10-sdk> Acesso em 09 set. 2016.
[58] <https://developer.android.com/studio/releases/sdk-tools.html> Acesso em
09 set. 2016.
80
APÊNDICE – Tabela de Componentes Eletrônicos e Custos
APÊNDICE A – TABELA DE COMPONENTES ELETRÔNICOS E CUSTOS

CUSTO DO PROJETO
Componentes Qtde Valor Unit. Valor Total
Arduino Leonardo R3 1 R$ 44,75 R$ 44,75
LED difuso amarelo 5mm 5 R$ 0,11 R$ 0,55
LED difuso verde 5mm 4 R$ 0,11 R$ 0,44
LED difuso vermelho 5mm 5 R$ 0,09 R$ 0,45
LED alto brilho azul 5mm 1 R$ 0,35 R$ 0,35
LED alto brilho vermelho 5mm 2 R$ 0,25 R$ 0,50
Resistor de 220ohm 20 R$ 0,04 R$ 0,80
Transístor NPN BC517 24 R$ 0,12 R$ 2,88
Capacitor de disco cerâmico 0,01uF 2 R$ 0,01 R$ 0,02
Circuito Integrado 74HC165 2 R$ 0,93 R$ 1,86
Circuito Integrado 74HC595 3 R$ 1,95 R$ 5,85
Display LCD I²C 16x2 1 R$ 26,90 R$ 26,90
Micro servo 9g SG9 Tower Pro 2 R$ 10,99 R$ 21,98
Botão freio de mão 1 R$ 12,50 R$ 12,50
Botão retarder 1 R$ 7,90 R$ 7,90
Chave alavanca reboque 1 R$ 4,00 R$ 4,00
Chave alavanca geabox 2 R$ 10,90 R$ 21,80
Push button Ignição 1 R$ 0,91 R$ 0,91
Push button computador de bordo 1 R$ 0,93 R$ 0,93
Push button beacon 1 R$ 7,56 R$ 7,56
Push button alerta 1 R$ 6,49 R$ 6,49
Chave farois 1 R$ 9,30 R$ 9,30
Chave gangorra limpadores 1 R$ 3,88 R$ 3,88
Chave gangorra freio motor 1 R$ 3,23 R$ 3,23
Tampa chave do reboque 1 R$ 4,35 R$ 4,35
Jumpers (pacote com 65) 1 R$ 14,99 R$ 14,99
Espague termo retrátil (metro) 1 R$ 0,70 R$ 0,70
Cabinho (rolo) 1 R$ 11,99 R$ 11,99
Protoboard 830 pontos 1 R$ 13,80 R$ 13,80
Protoboard 400 pontos 1 R$ 7,99 R$ 7,99
Conector sindal com 12 bornes 4 R$ 3,50 R$ 14,00
Fonte ATX 450w (genérica) 1 R$ 49,90 R$ 49,90
CUSTO TOTAL R$ 304,15
81
APÊNDICE B – LEGENDA DO PAINEL
Figura 29: Modelo do protótipo - visão frontal
Legenda de componentes:
1. Chave de acionamento dos faróis;
2. Botão de acionamento da luz giratória (beacon);
3. Luz indicadora de funcionamento do beacon;
4. Conta-giros;
5. Servomotor do conta-giros;
6. Luz indicadora de direção à esquerda (seta esquerda);
7. Luz indicadora do farol alto;
8. Luz indicadora do farol baixo;
9. Luz indicadora do farol de estacionamento;
10. Luz indicadora de direção à direita (seta direita);
11. Servomotor da velocidade;
12. Velocímetro;
13. Luz indicadora de conexão com reboque;
14. Chave de trava do reboque;
15. Chave de acionamento do freio de mão;
82
16. Chave de acionamento dos limpadores de para-brisa;

17. Botão de acionamento das luzes de alerta;
18. Botão de acionamento do freio motor;
19. Computador de bordo;
20. Botão de ignição;
21. Chave de controle do freio retarder;
22. Chave de troca de caixa de marchas (normal - reduzida);
23. Chave de troca de caixa de marchas (baixa – alta);
24. Controle do computador de bordo;
25. Luz indicadora do controle de cruzeiro;
26. Luz indicadora dos faróis auxiliares do teto;
27. Luz indicadora de acionamento do retarder;
28. Luz indicadora de acionamento do freio motor;
29. Luz de advertência de baixa pressão de ar nos freios;
30. Luz de emergência de baixa pressão de ar nos freios;
31. Luz de advertência de baixa pressão de óleo;
32. Luz de advertência de temperatura da água;
33. Luz indicadora de acionamento do freio de estacionamento;
34. Luz de advertência de baixa quantidade de combustível.

TCC Hugo de Freitas Bereta

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC Hugo de Freitas Bereta

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL FLUMINENSE

HUGO DE FREITAS BERETA

SISTEMA DE LEITURA E TRATAMENTO DE DADOS DE

SISTEMA DE LEITURA E TRATAMENTO DE DADOS DE

Trabalho de Conclusão de Curso

B492 Bereta, Hugo de Freitas

Projeto Final (Tecnólogo em Sistemas de Computação) –

1. Telemetria. 2. Jogo em computador. 3. Simulação por

SISTEMA DE LEITURA E TRATAMENTO DE DADOS DE

Trabalho de Conclusão de Curso

Niterói, 20 de Dezembro de 2016.

Primeiramente a Deus, que sempre me

À minha esposa e filho, pela paciência,

Aos meus pais por investirem uma vida em

A meu Orientador Rafael Burlamaqui Amaral,

A meu primo e amigo Wellington Carlos de

A meu sogro José Weliton Costa Leite por

Ao CEDERJ por me permitir fazer um curso

Atualmente, os recursos disponíveis aos computadores pessoais permitem o

Palavras-chaves: Simulador, Jogos de Computador e Arduino.

Currently the available resources for personal computers allow development of

Key words: Simulator, Computer Games and Arduino.

Figura 1: Implementação de uma função callback.....................................................25

API – Application Programming Interface

A crescente expansão tecnológica vem tornando acessíveis aos

nível de precisão e confiabilidade muito alto, as simulações cujo objetivo é entreter

burocrático, cujo custo final do produto pode subir demasiadamente. E o mercado

entendimento do projeto. O Capítulo 4 apresenta o plugin e os detalhes de seu

No sentido de melhor situar este trabalho dentro do panorama atual de

O TuKolk é um projeto de Graduação apresentado à Escola de

2.2 ETS2 TELEMETRY WEB SERVER 3.2.5 & MOBILE DASHBOARD

A SCS Software, produtora do Euro Truck Simulator 2, disponibiliza a seus

Neste capítulo serão apresentados conceitos teóricos importantes que

3.1 O KIT DE DESENVOLVIMENTO DE SOFTWARE (SDK)

Um SDK (Software Development Kit), também conhecido popularmente

de um simples arquivo de texto copiado para um diretório específico dentro da

O uso de DLL permite a modularização de um programa em componentes

Figura 1: Implementação de uma função callback

3.2 A API DE TELEMETRIA

A palavra telemetria tem origem no idioma Grego. O radical “tele” significa

criados por uma empresa de software de maneira a permitir que aplicações de

• Canais: que são associados à fontes individuais de informações de

funcionamento do motor e acionamento da parte elétrica, entre outras. De modo

3.3 ARDUINO E A COMUNICAÇÃO SERIAL

Arduino é uma plataforma de eletrônica open-source baseada na filosofia

preços bastante acessíveis, aumentando a preferência pelas placas Arduino (e

3.3.2 A COMUNICAÇÃO SERIAL

Figura 2: Conexão serial

Uma analogia interessante a ser feita para comparar as duas formas de

Origem dos Destino dos

A comunicação paralela, embora tenha muitas vantagens, consome

costuma ser no modo síncrono. Cada transmissão é precedida de um bit de início

A Figura 4 abaixo ilustra a composição de um pacote de dados em uma

Pacote Bit de início Bits da dados Bit de paridade Bit(s) de parada

Figura 4: Composição de um pacote de dados

O barramento de uma comunicação serial é composto por duas vias,

Figura 5: Barramento de uma conexão serial

O site Tech Terms Computer Dictionary, uma espécie de dicionário online

Figura 6: Interligação dos componentes do projeto

O ETS2 disponibiliza os dados ao plugin através da API de telemetria. O

• O ETS2 disponibiliza ao plugin a informação de que o freio de

4.1 O JOGO E A API DE TELEMETRIA

Figura 7: Tela de confirmação do jogo