2010bEquipe07 Monografia

De Wiki DAINF
(Diferença entre revisões)
(Inclusão da primeira parte da monografia convertida para wiki)
Linha 501: Linha 501:
  
 
:Diagrama de Classes elaborado pela equipe para o programa Tewnta. Nessa versão do diagrama, apresentamos cada pacote Java como um diagrama, para uma versão completa do diagrama [[http://www.dainf.ct.utfpr.edu.br/wiki/index.php/Imagem:Twenta.jpg acesse]].
 
:Diagrama de Classes elaborado pela equipe para o programa Tewnta. Nessa versão do diagrama, apresentamos cada pacote Java como um diagrama, para uma versão completa do diagrama [[http://www.dainf.ct.utfpr.edu.br/wiki/index.php/Imagem:Twenta.jpg acesse]].
 +
 +
=Modificações Executadas=
 +
:Durante o trabalho, buscou-se aperfeiçoar algumas limitações do Tewnta.
 +
:A seguir são apresentadas as correções feitas.
 +
 +
 +
==Validação do Gol==
 +
:A versão 1.3 do Tewnta apresentava uma limitação em relação à validação do gol. Nessa versão, caso a bola passasse atrás do gol -- entre a trave do fundo e o fundo do campo -- , o algoritmo interpretava esse evento como gol.
 +
:Essa imperfeição poderia causar problemas na simulação, uma vez que algumas equipes poderiam ser beneficiadas com gols que não fizeram.
 +
 +
===Arquivos modificados===
 +
   
 +
:*/br/ufrgs/f180/server/Game.java   
 +
:*/br/ufrgs/f180/elements/GameField.java 
 +
 +
====Função modificada====
 +
   
 +
:*''public ScoredGoal goalScored()'' 
 +
 +
====Função criada====
 +
   
 +
:*''public static double getGoalDepth()'' 
 +
 +
====Descrição====
 +
 +
:A condição para validação do gol no código original era que a bola estivesse no retângulo imaginário entre os dois gols no meio do campo e estivesse fora da linha de fundo. A contribuição do trabalho consistiu em incluir a condição de a bola estar entre a linha de fundo e a barra de fundo do gol, em vez de o fundo do campo, como na versão original, como pode ser verificado no código 23.
 +
 +
:Para executar essa correção, é necessária a informação da profundidade da trave do gol na classe ''server.Game'', essa informação era visível apenas na classe ''elements.GameField'' , então criou-se uma função ''getter''  pública que retorna essa informação, como pode ser verificado no código 24.
 +
 +
 +
CODIGO {codigo01a.java}
 +
 +
 +
CODIGO{codigo01b.java}
 +
 +
==Função ''fast-foward'' ==
 +
:Durante os testes dos algoritmos inteligentes no simulador os programadores precisam aguardar os 20 minutos de uma partida para obter os resultados. Um acréscimo interessante ao Tewnta seria acelerar o tempo da simulação. Na versão 1.3, foi implementado um método para desacelerar a simulação e vê-la em câmera lenta, dessa forma, o arcabouço necessário para uma simulação mais rápida já estava pronto nessa versão.
 +
 +
===Arquivo modificado===
 +
   
 +
:*/br/ufrgs/f180/gui/MainWindow.java 
 +
 +
====Função modificada====
 +
   
 +
:*''private void initGUI()'' 
 +
 +
====Descrição====
 +
:Para executar a função de desaceleração do jogo, o Tewnta utilizava uma variável de valor real chamada ''elapsedTimePerCycle''  definida na classe ''gui.MainWindow'' , que representa quanto tempo se passa em um ciclo de jogo. O usuário controla o valor dessa variável através de uma barra de rolagem presente na tela principal do Tewnta, como pode ser visto na figura 25. O valor dessa barra rolagem varia entre 1 e 100, onde 100 representa um segundo por um segundo, isso é, um segundo na simulação significa um segundo no mundo real.
 +
 +
;\begin{figure}
 +
;  \center
 +
;  \includegraphics[height=5.28cm]{ModificacoesExecutadasFig01.png}
 +
;  \caption{Controle do tempo de simulação - Tewnta.}
 +
;  (25)
 +
;\end{figure}
 +
 +
:A contribuição do trabalho ao Tewnta consistiu em modificar o alcance dessa barra de rolagem, como mostra o código 26, mudando de 1-100 para 1-500. Dessa forma, o usuário pode definir uma simulação até cinco vezes mais rápida.
 +
 +
CODIGO{codigo02.java}
 +
 +
 +
==Jogadores voltarem a posição inicial após o gol==
 +
:Uma regra do Futebol de Robôs que não havia sido implementada no Tewnta era a volta dos robôs a seu campo de origem após um gol, como acontece no futebol humano. O posicionamento inadequado dos robôs após um gol pode favorecer ou prejudicar algum time durante uma partida.
 +
 +
===Arquivo modificado===
 +
   
 +
:*/br/ufrgs/f180/server/Game.java 
 +
 +
====Função modificada====
 +
   
 +
:*''public void updateState(double d)'' 
 +
 +
====Funções criadas====
 +
   
 +
:*''private void setUpRobot()''   
 +
:*''private double [ ][ ][ ] initialPositions()'' 
 +
 +
====Descrição====
 +
:Para implementar essa correção, era necessário inicialmente definir quais seriam as posições inicias dos jogadores após um gol. Essas posições foram definidas em termos relativos às dimensões do campo, de forma que cada time tivesse um robô goleiro, dois robôs em posição de defesa e dois robôs avançados.
 +
 +
:Para facilitar a implementação, foi criada a função ''private double [ ][ ][ ] initialPositions'' , que define uma matriz de três dimensões de valores reais, onde a primeira dimensão representa o time ao qual pertence o robô (0-1); a segunda dimensão define o índice daquele jogador dentro do time (0-4); e a terceira dimensão representa a coordenada (X ou Y) do valor real (0-1). Para que as posições dos jogadores não sejam sempre as mesmas a cada gol, foi incluído um fator aleatório na determinação das posições que pode
 +
variar a posição definida em até 10. A implementação da função ''initialPositions()''  pode ser vista no código 27.
 +
 +
CODIGO{codigo03a.java}
 +
 +
:Implementada a definição das posições dos jogadores, o proximo passo foi criar uma função que alterasse as posições dos jogadores. Então, definiu-se a função ''setUpRobot''  que pode ser vista no código 28. Essa função obtém e percorre o vetor de ''MovingElement''  da classe ''MainWindow''  e verifica quais são robôs, e a qual time eles pertencem, então seta a posição de acordo com a definição feita na função ''initialPositions()'' .
 +
 +
 +
CODIGO{codigo03b.java}
 +
 +
:Depois de implementadas as duas funções anteriores era necessário invocá-las no momento certo do código, então alterou-se a função ''updateState'' , que já estava definida desde a versão 1.2 do Tewnta. Essa função, entre outras coisas, define o que deve ser feito após um gol, então foi chamada a função ''setUpRobot()''  dentro do bloco de código que é executado após um gol, como pode ser visto no código 29.
 +
 +
CODIGO{codigo03c.java}
 +
 +
==Dimensões atualizadas do campo==
 +
:No Futebol de Robôs, as dimensões do campo podem ser modificadas a cada ano. Prevendo isso, o Tewnta possui um arquivo texto (''game.properties'' ) que fica no diretório ''/src''  do código fonte onde são definidos os parâmetros do campo.
 +
 +
===Arquivo modificado===
 +
   
 +
:*/src/game.properties 
 +
 +
====Descrição====
 +
 +
:Para adequar o Tewnta às regras 2010 do futebol de robôs foi necessário modificar os seguintes campos no arquivo ''game.properties'' , como
 +
pode ser verificado no código 30:
 +
   
 +
:*''field.height''  -- altura do campo;   
 +
:*''field.width''  -- largura do campo;   
 +
:*''field.border''  -- borda do campo, entre as paredes e as linhas. 
 +
 +
 +
CODIGO{codigo04.properties}
 +
 +
=Modificação implementadas na versão 1.3=
 +
 +
==Colisão==
 +
 +
:Uma das correções propostas pela equipe no início do trabalho foi o tratamento adequado da colisão entre robôs. No entanto, essa correção foi implementada na versão 1.3 do Tewnta.
 +
 +
:Para cálculo da colisão, primeiramente foi implementada uma função booleana na classe ''elements.MovingElement''  para definir se dois objetos estão em vias de se colidir, como mostra o código 31, através do cálculo da distância entre esses dois objetos.
 +
 +
 +
CODIGO{codigo06a.java}
 +
 +
:Caso a função definida no código 31 detecte a colisão entre dois elementos, o cálculo da colisão é feito através de uma colisão não elástica, como mostra o código 32.
 +
 +
CODIGO{codigo06b.java}
 +
 +
==Aceleração==
 +
:Para o cálculo de posição de um elemento, método ''public void calculatePosition(double timeElapsed)'' , no código 33, da classe ''elements.Movingelement'' , o algoritmo calcula primeiro a velocidade em função da aceleração (código 34) no Movimento Linear e então define a nova posição. Para o Movimento Rotacional, a aceleração rotacional é calculada (código 35) e então a velocidade rotacional é calculada, e só depois o novo ângulo é calculado.
 +
 +
CODIGO{codigo07a.java}
 +
 +
CODIGO{codigo07b.java}
 +
 +
CODIGO{codigo07c.java}
 +
 +
:No entanto, a implementação da Aceleração Linear utilizada no Tewnta não considera particularidades de robôs e solo, o cálculo é baseado na equação 36: onde <math>F</math> é a força exercida pelos motores dos robôs, e <math>m</math> é a massa dos robôs. Apesar desses parâmetros serem definidos através do arquivo ''game.properties'', através dos experimentos, pode-se observar que a relação expressa em 36 não expressa adequadamente a relação, porque desconsidera dissipações de energia inerentes ao movimento. Uma possível solução é apresentada em 38.
 +
 +
<center><math>
 +
a = \frac{F}{m}
 +
  (36)
 +
</math></center>
 +
 +
:A implementação utilizada para cálculo da aceleração rotacional (código 35) se baseia na equação 37 onde <math>F</math> é a força de rotação e <math>m</math> a massa do robô. No entanto, essa equação não considera o Momento de Inércia do corpo em rotação, o que afasta da realidade a simulação desse evento físico. Uma alternativa para essa implementação é apresentada em 39.
 +
 +
<center><math>
 +
a = \frac{F}{m}
 +
(37)
 +
</math></center>

Edição de 12h03min de 10 de novembro de 2010

2010bEquipe07

A primeira versão para a monografia foi finalizada e entregue aos professores da disciplina. Abaixo os links para as versões PDF e LATEX:

http://dl.dropbox.com/u/12362738/monografia_final.tex

http://dl.dropbox.com/u/12362738/monografia_final.pdf

Tabela de conteúdo

Resumo

Este trabalho tem como objetivo o aperfeiçoamento do simulador de futebol de robôs Tewnta, baseado nas regras da RoboCup SSL. Foram acrescentados ajustes e novas funcionalidades, que possibilitaram ao software uma melhor simulação do futebol e mais praticidade em seu uso. Além disso, desenvolveu-se um método experimental para obtenção de dados físicos no universo do futebol de robôs, utilizando o analisador de vídeos Tracker.
palavras-chave: Simulação. Futebol de Robôs. RoboCup. SSL. Tewnta. Tracker.

Abstract

This work aims to improve the robot soccer simulator Tewnta, based on RoboCup SSL rules. Tweaks and new features, that enabled a better simulation of soccer and more practical use, were added to the software. Furthermore, it has developed an experimental method for obtaining data on the physical world of robot soccer, using the video analyzer Tracker.
keywords: Simulation. Robot Soccer. RoboCup. SSL. Tewnta. Tracker.

Licenciamento

Este trabalho está licenciado sob uma Licença GNU Lesser General Public License . Para ver uma cópia dessa Licença visite www.gnu.org ou envie uma carta para 51 Franklin Street, Fifth Floor, Boston, MA 02110, USA.

Glossário

  • API - Application Programming Interface
  • IDE - Integrated Development Environment
  • GNU - GNU is Not Unix
  • GPL - General Public License
  • IA - Inteligência Artificial
  • IP - Internet Protocol
  • JVM - Java Virtual Machine
  • MRU - Movimento Retilíneo Uniforme
  • MRUV - Movimento Retilíneo Uniformemente Variado
  • ODE - Open Dynamics Engine
  • POO - Programação Orientada a Objetos
  • SSL - Small Size League
  • SWT - Standard Widget Toolkit
  • UDP - User Datagram Protocol

Introdução

Delimitação do Tema

Softwares simuladores são fortes aliados no avanço da tecnologia. Simular fenômenos da natureza, comportamentos e situações reais sempre foram desafios ao ser humanoSmartSimSelector. Simulações robóticas cada vez mais vêm sendo utilizadas para proporcionar agilidade a eventos experimentaisJAI2009.
O futebol de robôs é uma iniciativa que propõe o desenvolvimento de tecnologia robótica tendo o futebol como motivaçãoKitano.

O simulador de futebol de robôs, em especial, é muito usado por professores de cursos de graduação e em testes de algoritmos inteligentes e o tema deste projeto gira em torno deleBeard.

De maneira genérica o tema a ser tratado é o aperfeiçoamento do software TewntaSiteTewnta, que é um simulador do futebol de robôs da categoria F-180 da Robocupsslrules.
Considerando-se particularidades dos modelos matemáticos do robô e da bola, procura-se ajustar o programa para operar de forma mais fidedigna segundo as características de um robô, campo e bola reais disponíveis na UTFPR, ou seja, torná-lo o mais próximo possível da realidade.

Problema

A dificuldade em reproduzir a realidade é o principal desafio dos desenvolvedores de softwares simuladores. Muitas vezes o problema não é implementar as constantes físicas no programa, mas como calculá-lasBeard.
Softwares simuladores de Futebol de Robôs, de maneira geral, desconsideram detalhes específicos dos robôs e do ambiente presentes numa partida real. Dessa forma, algoritmos tidos como bons em um simulador, podem não obter o mesmo sucesso em um ambiente realBeard.
Os principais problemas enfrentados para a realização desse projeto estão relacionados à determinação e interpretação de constantes e eventos físicos através de um método experimental válido. Outro problema seria a criação de uma interface em que o usuário pudesse transferir esses dados ao software, e esses dados serem interepretados de maneira correta pelo algoritmo.

Justificativa

Aperfeiçoar um simulador de entes robóticos, independentes de quais sejam, é uma tarefa de grande importância científica e tecnológica. Simular é um desafio enorme, pois envolve a abstração e posterior construção de um modelo elaborado de um evento real. Através das simulações pode-se representar processos reais mais rápida ou lentamente (de acordo com a necessidade específica de cada caso) para obtenção de informações de maneira mais prática do que através de experimentos reaisSmartSimSelector.
A decisão de colaborar com a melhoria do simulador de futebol de robôs baseia-se na possibilidade de, além de exercer contribuições científicas e tecnológicas de forma geral, cooperar com as atividades da UTFPR, visto que esse software é utilizado na disciplina de Sistemas Inteligentes, do Departamento Acadêmico de Informática. Esse trabalho também poderia auxiliar os treinamentos da equipe de futebol de robôs da UTFPR, possibilitando melhores resultados nas participações da RoboCup, já que quanto mais próximo for o comportamento simulado dos robôs, mais adequado será o simulador para desenvolver estratégias de controle dos robôs.

Objetivos

Objetivo Geral

O objetivo geral do projeto é aperfeiçoar o software Tewnta, tornando sua simulação mais coerente com uma partida real de futebol de robôs. E também a determinação de uma metodologia adequada para obtenção de parâmetros físicos dos robôs e da bola em uma partida de futebol de robôs.

Objetivos Específicos

Os objetivos específicos do projeto incluem:


  • Corrigir a validação do gol no simulador;
  • Incluir o cálculo das acelerações linear e angular no movimento dos robôs;
  • Tornar parâmetros físicos do software manipuláveis pelo usuário, para que sejam consideradas peculiaridades de diferentes campos e robôs;
  • Implementar uma função fast-forward para facilitar os testes com algoritmos inteligentes, de maneira que as simulações possam ser aceleradas;
  • Criar um manual de introdução ao Tewnta;
  • Elaborar um guia para os experimentos físicos, utilizando o Tracker como ferramenta.

Robocup

História

A ideia de robôs competindo numa partida de futebol vem de longa data. No ano de 1992 RoboCup1 este assunto foi comentado pela primeira vez no artigo On Seeing Robots do Professor Alan Mackworth (University of British Columbia , Canadá), publicado no ano seguinte no livro Computer Vision: System, Theory, and Applications , páginas 1-13, World Scientific Press , Singapura, 1993.
Em Outubro de 1992 em Tóquio RoboCup1, um grupo de pesquisadores japoneses organizou um workshop sobre Grandes desafios em Inteligência Artificial. Durante este evento as discussões guiaram as atenções para o uso de jogos como forma de promover tecnologia e ciência. Em 1993, idealizada por Minoru Asada, Yasuo Kuniyoshi, e Hiroaki Kitano, teve início a primeira competição de futebol de robôs RoboCup1.
Inicialmente chamada de Robot J-League , este evento imediatamente chamou a atenção de pesquisadores do mundo todo que propuseram estender esta iniciativa a um projeto colaborativo internacional. Assim, o evento foi renomeado para Robot World Cup Initiative, também conhecido como RoboCup. No mesmo ano foi feito o primeiro anúncio público sobre esta iniciativa, definidas as primeiras regras e lançada a primeira versão do Soccer Server Version 0 , primeiro simulador aberto que permitiu o desenvolvimento de pesquisas com sistemas multi-agentes, construído em linguagem LISP, seguido pela versão 1.0 construída em C++.
Em 1996, foi realizada a Pre-RoboCup, durante a International Conference on Intelligence Robotics and Systems (IROS-96), realizada de 4 a 8 de novembro em Osaka. Participaram deste evento oito equipes com simuladores e demonstração de robôs médios.
E finalmente, após muitos anos de pesquisas e aperfeiçoamentos nos moldes do campeonato, foi realizado em 1997 o primeiro

RoboCup Games and Conference .

Objetivos

O principal foco da RoboCup é promover pesquisas em robótica e inteligência artificial de uma maneira mais amigável e com certo apelo publicitário. Por entender que estabelecer metas é uma maneira eficaz de desenvolver estas pesquisas, é tido como objetivo à longo prazo:
“By mid-21st century, a team of fully autonomous humanoid robot soccer players shall win the soccer game, comply with the official rule of the FIFA, against the winner of the most recent World Cup.”RoboCup2

As Modalidades da RoboCup

A RoboCup é um tipo de problema padrão que permite que várias teorias, algoritmos e arquiteturas sejam testadas, combinando as complexidades do mundo real dentro de um mundo limitado. Diversas áreas de pesquisa sobre Inteligência Artificial (IA) e robótica Kitano, tais como sensores de tempo real, comportamento reativo, sistemas multi-agentes, reconhecimento de contexto, visão e controle de robôs inteligentes, entre outras, estão envolvidas e para isso existem várias modalidades de campeonato, cada uma com suas particularidades e regulamentação própria. São elas:

RoboCup Rescue

A robocup rescue é dividida em duas categorias principais: a RoboCup Simulation Project e a Real Robots Project ;

que atuam como um padrão para pesquisadores na área de desastresRescue.

Tem como objetivo principal realizar pesquisa e desenvolvimento envolvendo agentes diversos em áreas hostis em vários níveis de interaçãoRescueoficial. Coordenação de equipes de trabalho multi-agentes, busca e salvamento, agentes robóticos físicos e estratégias de salvamento, são alguns exemplos das pesquisas realizadas. Esta competição que segue os moldes da RoboCup Soccer e provome fóruns técnicos e testes competitivos para pesquisadores e praticantes, foi idealizada após o terremoto Hanshi-Awaji que atingiu a cidade de Kobe no Japão em 1995 Rescue.

RoboCup @Home

Considerada a maior competição internacional anual de robôs autônomos AtHome a Robocup @Home teve início em 2006 e está voltada para o ambiente humano diário AtHome2. Esta modalidade tem como objetivo principal desenvolver tecnologias para robôs assistenciais para aplicações domésticas.
A competição testa a habilidade dos robôs em ambientes domésticos desconhecidos AtHome3 em quesitos que envolvem entre outras coisas:
  • interação cooperativa entre humanos e robôs;
  • manipulação de objetos (portas, utensílios de cozinha, copos, etc.);
  • Navegação em ambientes domésticos dinâmicos;
  • visão computacional e reconhecimento de objetos sob luz natural;
  • comportamento adaptativo.


RoboCup Soccer

As competições de futebol são a principal atividade da RoboCup Soccer e permitem que os pesquisadores troquem informações técnicas sobre robótica e inteligência artificial. Esta modalidade envolve as ligas Humanoid , Middle Size Robot , Simulation , Standard Plataform e a Small Size Robot, também conhecida como SSL, a qual é a base de estudo deste trabalho.

Humanoid League

Nesta liga, robôs autônomos bípides com corpo e sentidos parecidos com humanos, competem entre si Humanoid. Eles devem ter a habilidade de correr, andar e chutar a bola ao mesmo tempo em que mantém o equilíbrio e percebem a posição da bola e dos outros jogadores no campo, além de reconhecerem sua própria posição. A Humanoid League é divida em três subgrupos:
  • KidSize (altura: 30-60cm);
  • TeenSize (altura: 100-120cm);
  • AdultSize (altura: 130cm ou mais).

Middle Size Robot League (MSL)

Utiliza robôs com até 50 cm de diâmetro em equipes de até seis jogadores msl. Os robôs devem ter todos os sensores onboard e utilizar rede sem fio para comunicação.

Soccer Simulation League

São utilizados softwares para simular os robôs que jogam uma partida num campo virtual. Esta categoria está divida em quatro sub-ligas Simulador. São elas: 2D, 3D, desenvolvimento 3D e realidade mista onde são utilizados robôs em miniatura fazendo uma ligação entre robôs reais e simulados.

Standard Plataform

É uma liga de futebol onde todas as equipes utilizam o mesmo modelo de robô spl. Este robô é totalmente autônomo,

devendo ser previamente programado e não pode ser controlado externamente nem por humanos nem por computador. Atualmente são utilizados os robôs NAO desenvolvidos pela empresa Aldebaran Robotics. Estes robôs são totalmente programáveis através do software Coregraphe , também desenvolvido pela Aldebaran RoboticsNAO. O software é multi-plataforma e aceita as linguagens C, C++, URBI e PythonNAO2.

Small Size Robot League (SSL ou F180)

Liga formada por robôs pequenos, tem como objetivo estudar problemas de cooperação entre multi-agentes inteligentes e cooperação em ambientes dinâmicos através de um sistema híbrido (centralizado/distribuído) ssl.
De acordo com as regras sslrules, um robô deve ser cilíndrico, ter no máximo 180 mm de diâmetro e 150 mm de altura. A comunicação com o computador é feita por wireless e cada robô deve seguir um padrão de cores no topo identificando equipe e numero do robô. Esta identificação servirá como padrão de reconhecimento para o sistema de visão compartilhada (SSL-Vision ).
Cada equipe é formada por até cinco robôs, já incluído o goleiro. A identificação deve ser clara o suficiente para que o robô possa ser facilmente reconhecido pelo juiz e o goleiro deve ser identificado antes do início da partida. Os robôs devem jogar de forma totalmente autônoma.
\begin{figure}
\center
\includegraphics[scale=0.5]{campo.jpg}
\caption{Campo oficial da liga SSL.}
(1)
\end{figure}
Uma partida é composta de dois tempos com duração de dez minutos cada, com um intervalo de no máximo cinco minutos entre eles. O campo, conforme visto na figura 1, deve ser retangular e medir entre as linhas, 6050 mm de comprimento por 4050 mm de largura, a superfície deve ser recoberta com um carpete verde e é utilizada uma bola de golfe de cor laranja.
\begin{figure}
\center
\includegraphics[scale=0.65]{posicao.jpg}
\caption{Disposição padrão de identificação dos robôs na liga SSL.}
(2)
\end{figure}


  • Matriz de Cores Padrão: Antes do início da partida cada equipe recebe uma cor que pode ser azul ou amarela. As figuras 2 e 3 mostram o padrão que deve ser seguido para que o SSL-Vision reconheça cada robô. Um adesivo com a cor da equipe deve ser colada no centro do topo de cada robô. Além deste, mais quatro adesivos são dispostos no topo de cada robô informando a identificação numérica de cada um.
\begin{figure}
\center
\includegraphics[scale=0.5]{cores.jpg}
\caption{Cores padrão para identificação dos robôs na liga SSL.}
(3)
\end{figure}
  • SSL-Vision: Até a RoboCup 2009 era permitido, e a maior parte das equipes preferia, utilizar câmeras de vídeo em cima ou perto do campo. Normalmente eram utilizadas duas câmeras, uma em cada metade do campo, Isto ocasionava um longo tempo gasto para configurar corretamente as câmeras antes e até durante o jogo -- se em cada campo disputassem cinco equipes, era necessário instalar e calibrar dez câmeras. O comitê organizador resolveu então adotar a partir da RoboCup 2010 um sistema de visão compartilhada chamado SSL-Vision Vision. Este sistema é implementado em linguagem C++ e desenvolvido por integrantes das equipes competidoras. Ele consiste em um único conjunto de câmeras conectadas em um servidor de processamento de imagens que identifica as posiões da bola e dos jogadores, e redistribui estas informações para as equipes participantes, conforme figura 4.
\begin{figure}
\center
\includegraphics[scale=0.65]{dataflow.png}
\caption{Diagrama resumido SSL-Vision.}
(4)
\end{figure}

Ambientes de Simulação Robótica}

Durante o desenvolvimento deste projeto, foram analizados alguns sistemas de simulação de robôs utilizados para a RoboCup. A seguir é apresentado um estudo elaborado sobre estes sistemas.

Sistema Estrategista para Futebol de Robôs

O Sistema Estrategista para Futebol de Robôs foi desenvolvido por Hugo Goveia com o objetivo de tratar assuntos relacionados ao futebol robótico,

dando continuidade à pesquisa iniciada na Faculdade de Informática de Presidente Prudente (FIPP)Goveia.

Em seu trabalho, Goveia desenvolveu um ambiente virtual que simula uma disputa entre um time controlado pelo usuário e outro que obedece às decisões

tomadas pelo Sistema EstrategistaGoveia.

O software foi desenvolvido em Borland C++ Builder. Este está organizado de maneira a permitir o controle dos robôs de um dos times por um usuário humano, que recebe comandos via teclado, enquanto o outro time obedece aos comandos definidos por estratégias implementadasGoveia. As informações de localização dos robôs ficam armazenadas em um vetor de oito posições, cada qual referente a um robôGoveia.
A Figura 5 representa a tela da simulação das estratégias. O campo é constituído por uma escala para as medidas reais da categoria MiroSot, onde são feitos os tratamentos de colisão entre os robôs, bolas e laterais, de maneira que os elementos não saiam do campo.
\begin{figure}
\center
\includegraphics[height=9.32cm]{SoftwareSimulacaoFig01.jpg}
\caption{Tela do aplicativo de simulação de Sistema Estrategista para Futebol Robótico.}
(5)
\end{figure}
Em seu trabalho, Goveia focou o desenvolvimento do Sistema Estrategista. Dessa forma, seu software de simulação é limitado em relação ao Tewnta, objeto de estudo deste trabalho.

Webots

Iniciado em 1996, pelo Dr. Olivier Michel no Instituto Federal Suíço de Tecnologia, Webots é um software de prototipagem e de simulação robótica profissional utilizado para fins educativosFerreiraJunior.
Esse software utiliza o ODE (Open Dynamics Engine ), cuja biblioteca permite simular com precisão as propriedades físicas dos objetos, para detecção de colisões e simulação dinâmica de corpos rígidosWebots.
O programa apresenta uma coleção de robôs modificáveis e, além disso, há a possibilidade de criação de novos modelos. Para a projeção de um novo modelo de robô, o usuário especifica os anúncios gráficos, como forma, dimensões, posição e cores do objeto e propriedades físicas, que abrangem massa, coeficiente de atrito, mola e amortecimentoFerreiraJunior.
O uso de uma prototipagem rápida e software de simulação é muito útil para o desenvolvimento de projeto de robótica mais avançada. Ele realmente permite visualizar previamente o controle inteligente de robôs para, eventualmente, transferir os resultados da simulação em um robô real. Por isso, tanto o tempo de desenvolvimento e a qualidade dos resultados são melhores usando uma prototipagem rápida e software de simulaçãoWebots.
Outra vantagem da Webots é a compatibilidade com diversas linguagens de programação, os programas de controle do robô podem ser escrito em C, C++, Java,

Python e MATLABFerreiraJunior. As Figuras 6 e 7 são um exemplo de simulação feita pela Webots.

\begin{figure}
\center
\includegraphics[height=7.68cm]{SoftwareSimulacaoFig02.jpg}
\caption{Simulação de futebol de robôs da categoria humanóide - Webots.}
(6)
\end{figure}
\begin{figure}
\center
\includegraphics[height=7.68cm]{SoftwareSimulacaoFig03.jpg}
\caption{Simulação de modelos diferentes de robôs em situações diversas - Webots.}
(7)
\end{figure}
Webots é um simulador de cunho genérico. Dessa forma, a representação dos eventos físicos é robusta. No entanto, não é seu intuito simular uma partida de Futebol de Robôs. Outra limitação em relação ao Webots é o seu custo. Por se tratar de um software profissional, possui apenas uma versão demo livre, que não pode ser modificadaWebots.

The Robocup Soccer Simulator

The Robocup Soccer Simulator é simulador oficial da RoboCup, dessa forma é o software mais completo e funcional de todos estudados. É composto por um servidor e por um monitor.
O servidor é um sistema que permite a várias equipes competir em um jogo de futebol. Como o jogo é realizado em um estilo cliente-servidor,

não há restrições quanto à forma como as equipes são construídas. A única exigência é que as ferramentas de suporte de comunicação cliente-servidor sejam via UDP/IP (User Datagram Protocol / Internet Protocol ) pois todas as comunicações entre o servidor e cada cliente são feitas via sockets UDP/IP. Cada cliente é um processo separado e se conecta ao servidor através de uma porta especificada. Depois que um jogador se conecta ao servidor, todas as mensagens são transferidas através desta porta. Uma equipe pode ter até 12 clientes, ou seja, 11 jogadores e um treinadorRoboCupSoccerSimulator.

Os jogadores enviam pedidos para o servidor quanto às ações que desejam realizar, como por exemplo, chutar a bola, girar ou correr. O servidor recebe estas mensagens, processa os pedidos, e atualiza o ambiente em conformidade. Além disso, o servidor fornece a todos os jogadores as informações sensoriais

(por exemplo, informações visuais sobre a posição dos objetos no campo, ou dados sobre os recursos do jogador, como resistência ou velocidade) JanPereira.

É importante mencionar que o servidor é um sistema em tempo real, trabalhando com intervalos de tempo discretos. Cada ciclo tem uma duração específica, e as ações que precisam ser executadas em um determinado ciclo, têm de chegar ao servidor durante o intervalo de direito. Portanto, o desempenho de um jogador lento, que resulta em perda de oportunidades de ação tem um impacto importante sobre o desempenho da equipe como um todoJanPereira.
A tela de visualização apresenta informações de pontuação, nomes de equipe e as posições de todos os jogadores e da bola. A interface é simples para o servidor e possui diversas conveniências. Como pode ser vista nas Figuras 8 e 9. Há a possibilidade de zoom em áreas de campo, para fins de depuração, de mover os jogadores e a bola com o mouse e de imprimir as posições e velocidades atuais dos jogadores e da bola em qualquer momentoRoboCupSoccerSimulator.
Para executar um jogo no servidor, não é necessário um monitor. No entanto, em um mesmo servidor, pode haver vários monitores conectados,

caso haja a necessidade de mostrar o mesmo jogo em terminais diferentesRoboCupSoccerSimulator.

\begin{figure}
\center
\includegraphics[height=7.16cm]{SoftwareSimulacaoFig04.jpg}
\caption{Interface do Robocup Soccer Simulator - 2D}
(8)
\end{figure}
\begin{figure}
\center
\includegraphics[height=7.16cm]{sim3d.png}
\caption{Interface do Robocup Soccer Simulator - 3D}
(9)
\end{figure}

Tewnta

Tewnta é um software de simulação de futebol de robôs, baseados nos parâmetros da modalidade Small Size League (SSL),

também conhecida como F180. Projeto originário da UFRGS, foi desenvolvido por Gabriel Detoni, em 2008, em linguagem Java com o objetivo de simular uma partida de futebol de robôs pequenos nos moldes de RoboCup. É um programa de código aberto e de componente gráfico bem desenvolvidoSiteTewnta.

O Tewnta é utilizado na UTFPR na disciplina de Sistemas Inteligentes I do Curso de Engenharia da Computação, como ferramenta de ensino de algoritmos

de Inteligência Artificial. E também é usado pela equipe de Futebol de Robôs da UTFPR para testes dos algoritmos de controle dos robôs.

Quando o estudo foi iniciado, a versão então disponível do Tewnta\footnote{Versão 1.2 de 2 de Dezembro de 2009} no site oficial

possuia algumas limitações com relação à simulação física e à interpretação de algumas regras do Futebol de Robôs. No entanto, durante o trabalho, uma nova versão do Tewnta foi lançada. A versão 1.3 apresentava algumas melhorias em relação à anterior, como o tratamento adequado das colisões entre robôs e bola; melhor implementação da aceleração dos robôs. Ainda assim, problemas como a validação correta do gol, volta dos jogadores à posição inicial após um gol não foram corrigidos.

Tewnta se destaca dos demais simuladores englobar características como código fonte aberto, sob a licença GNU Lesser General Public License ,

simulação muito próxima da realidade de uma partida de futebol, simplicidade no uso, funcionabilidade e adaptabilidade. Sua interface pode ser visualizada na Figura 10

\begin{figure}
\center
\includegraphics[height=9.00cm]{SoftwareSimulacaoFig05.jpg}
\caption{Interface do Tewnta}
(10)
\end{figure}

Estudo do Código Fonte

O estudo apresentado a seguir foi elaborado pelos integrantes da equipe para melhor compreensão do código fonte, baseando-se principalmente na documentação oficial do Tewnta JavaDocTewnta e no Livro Java Como Programar JavaComoProgramar.

Visão Geral

Tewnta é um software simulador de Futebol de Robôs desenvolvido em Linguagem de Programação Java. Java é uma Linguagem de Programação que trabalha com o paradigma Orientado a Objetos desenvolvido originalmente pela Sun Microsystems, em 1991JavaComoProgramar. Programas Java estão divididos em Pacotes (Packages ), estes estão divididos em Classes (Class ), e as Classes por sua vez, estão divididas em métodosJavaComoProgramar.
O Tewnta trabalha em duas camadas, a primeira atua como Servidor ,e é responsável pela simulação física e interpretação das regras do Futebol de Robôs. Uma segunda camada atua como Cliente , nela estão definidas as ações que devem ser tomadas pelos robôs. Para cada um dos times há uma aplicação cliente sendo executada. (Como pode ser visto na Figura 12). Essas duas camadas são executadas em aplicações diferentes que se comunicam através de protocolo IP (Internet Protocol).
\begin{figure}
\center
\includegraphics[height=4.98cm]{EstudoFonteFig01.jpg}
\caption{Diagrama de Comunicação - Tewnta}
(12)
\end{figure}
O fluxo básico da aplicação consiste em:


  1. Iniciar Servidor;
  2. Iniciar Cliente;
  3. Conexão entre Servidor-Cliente;
  4. Início da Partida;
  5. Servidor computa o estado da partida e o transmite para o cliente(13);
  6. Cliente determina a próxima ação a ser tomada e a passa para o servidor; volta a 13


Um modelo em diagrama de blocos do fluxograma do programa pode ser visualizado na Figura 14.
\begin{figure}
\center
\includegraphics[height=9.79cm]{EstudoFonteFig02.jpg}
\caption{Diagrama de fluxo - Tewnta}
(14)
\end{figure}
A Linguagem de Programação Java trabalha com o conceito de Máquinas Virtuais JavaComoProgramar. As Máquinas Virtuais trabalham como intermediários entre a aplicação e o Sistema Operacional, interpretando os comandos dentro da aplicação e os convertendo para os respectivos comandos do Sistema Operacional. Devido a esse fato, o Tewnta pode ser executado em qualquer Sistema Operacional que possua uma JVM (Java Virtual Machine ).

Pacotes e Classes

A seguir apresentamos a relação dos pacotes e classes em que está dividida a versão original\footnote{Versão 1.3, disponível no site oficial em (28/09/2010} do software Tewnta.

br.ufrgs.f180.math

Pacote de bibliotecas matemáticas comuns utilizadas em todo o programa.

Point

Representa um ponto no plano com coordenadas X e Y (valores reais). Inclui também operações elementares como distância até um ponto, subtração de pontos

Line

Representa uma linha no plano com dois pontos P1 e P2. Inclui operações como distância até um ponto e projeção perpendicular de um ponto

Circle

Representa um círculo no plano com um centro (Classe Point ) e um raio de valor real.

Matrix

Representa uma matriz 2x2, inclui a operação de multiplicação por um ponto (Classe Point ).

Vector

Representa um vetor. É uma especialização da classe Point e implementa a interface Cloneable. Inclui operações matemáticas como cosseno e seno entre dois vetores; rotação de um vetor, soma, subtração e mutiplicação vetores.
Durante a simulação, grandezas físicas como Velocidade, Aceleração e Força são representadas como objetos da classe Vector.

MathUtils

Funções auxiliares úteis genéricas: como normalização de um valor entre 0 e 1 e subtração de radianos.

br.ufrgs.f180.api

Pacote com a API (Application Programming Interface, Interface de Programação de Aplicações ) fornecida aos jogadores para se comunicar com o simulador.

Player

Principal API fornecida aos jogadores (Equipes de Futebol de Robôs) para se conectar e comunicar com o simulador. Seu objetivo é fornecer a mesma visão que se tem em um jogo de futebol de robôs real. As APIs são publicadas como serviço Web e estão disponíveis assim que o sistema é iniciado.
A classe Player é uma Interface Java.
Um fluxo normal de jogo consiste em:


  1. Login da equipe;
  2. Registro de até cinco jogadores;
  3. Fornecimento do movimento (ação) dos jogadores(15);
  4. Ler a posição dos jogadores e informações;volta a 15
  5. Desconectar.


PlayerImpl

Por se tratar de uma Interface, a classe Player necessita de uma Implementação, esse é o papel da classe PlayerImpl .

br.ufrgs.f180.api.model

Pacote com um conjunto de informações sobre os elementos do jogo. As classes desse pacote apenas armazenam informações, não executando ações.

ElementInformation

Classe genérica dentro do pacote, representa qualquer elemento do jogo. Possui informações como posição, velocidade, ângulo.

BallInformation

Especialização da classe ElementInformation para representar informações sobre a bola.

RobotInformation

Especialização da classe ElementInformation para representar informações sobre os robôs. Acrescenta à classe ElementInformation informações acerca das ações dos robôs, como se ele está chutando ou driblando.

GameInformation

Especialização da classe ElementInformation para representar informações sobre o jogo. Contém informações como nomes dos times em campo, listas de objetos da classe RobotInformation .

br.ufrgs.f180.elements

Pacote com os elementos físicos visuais do jogo.

VisualElement

Interface que representa um elemento visual qualquer do jogo, é uma classe genérica especializada pelas demais.

MovingElement

Classe abstrata que representa um elemento que se movimenta no jogo, implementação de VisualElement . Por representar objetos que se movem, possui parâmetros como velocidade, aceleração, força e métodos como calcular velocidade, calcular rotação, calcular colisão.

GameField

Classe responsável por representar tanto a simulação física quanto a apresentação visual do campo de jogo, com origem cartesiana no canto esquerdo inferior da tela. Nessa classe estão contidos todos os elementos do jogo, como a bola, os robôs, as paredes.

Wall

Classe que representa uma parede, implementa VisualElement . Uma parede é representada pela semi-reta entre dois pontos.

WallCollisionPoint

Classe para simular um ponto da parede com massa infinita, especializa MovingElement. É utilizada para melhor simulação da colisão entre a bola e os robôs com as paredes.

Ball

Classe para representar a bola, especializa MovingElement .

Robot

Classe para representar o robô, especializa MovingElement . Contém métodos relativos ao robô, como a instrução para chutar, driblar, andar para frente, rotacionar.

br.ufrgs.f180.gui

Pacote com a GUI (Graphical User Interface ).

AboutDialog

Janela Sobre .

MainWindow

Janela principal do programa, contém o método main do programa e os métodos da atualização da interface. Nela estão contidos todos os métodos responsáveis por desenhar o campo, a bola e os robôs na tela e informar graficamente dados como posição e velocidade dos jogadores.

TrailAnalyserWidget

Janela que exibe um histórico das posições dos jogadores em campo. Pode ser acessada a partir da Janela Principal.

br.ufrgs.f180.resources

Pacote com recursos necessários para o jogo.

GameProperties

Classe responsável por importar do arquivo parâmetros da simulação, como dimensões do campo, velocidade máxima do robôs.

Especializa a classe Properties, genérica do Java.

br.ufrgs.f180.server

Pacote com informações do servidor e do jogo.

Game

Classe que representa o jogo. Nesta classe estão contidos os métodos que controlam o fluxo e as regras jogo. Por conter os métodos de controle da dinâmica do jogo, pode ser considerada uma das classes mais importantes do software.

Server

Classe responsável por implementar o servidor do jogo para comunicação com os clientes. Através dos métodos dessa classe, os algoritmos que controlam os times se comunicam com o Tewnta.

br.ufrgs.f180.team

Pacote para um time de demonstração.

DemoTeam

Representa um time de demonstração.

com.cloudgarden.resource

Pacote para manipulação dos parâmetros do toolkit SWT, Standard Widget Toolkit .

SWTResourceManager

Classe única do pacote para manipulação de recursos gráficos como Fonte, Cor, Imagem e Cursor.

Diagrama de Classes

Diagrama de Classes elaborado pela equipe para o programa Tewnta. Nessa versão do diagrama, apresentamos cada pacote Java como um diagrama, para uma versão completa do diagrama [acesse].

Modificações Executadas

Durante o trabalho, buscou-se aperfeiçoar algumas limitações do Tewnta.
A seguir são apresentadas as correções feitas.


Validação do Gol

A versão 1.3 do Tewnta apresentava uma limitação em relação à validação do gol. Nessa versão, caso a bola passasse atrás do gol -- entre a trave do fundo e o fundo do campo -- , o algoritmo interpretava esse evento como gol.
Essa imperfeição poderia causar problemas na simulação, uma vez que algumas equipes poderiam ser beneficiadas com gols que não fizeram.

Arquivos modificados

  • /br/ufrgs/f180/server/Game.java
  • /br/ufrgs/f180/elements/GameField.java

Função modificada

  • public ScoredGoal goalScored()

Função criada

  • public static double getGoalDepth()

Descrição

A condição para validação do gol no código original era que a bola estivesse no retângulo imaginário entre os dois gols no meio do campo e estivesse fora da linha de fundo. A contribuição do trabalho consistiu em incluir a condição de a bola estar entre a linha de fundo e a barra de fundo do gol, em vez de o fundo do campo, como na versão original, como pode ser verificado no código 23.
Para executar essa correção, é necessária a informação da profundidade da trave do gol na classe server.Game, essa informação era visível apenas na classe elements.GameField , então criou-se uma função getter pública que retorna essa informação, como pode ser verificado no código 24.


CODIGO {codigo01a.java}


CODIGO{codigo01b.java}

Função fast-foward

Durante os testes dos algoritmos inteligentes no simulador os programadores precisam aguardar os 20 minutos de uma partida para obter os resultados. Um acréscimo interessante ao Tewnta seria acelerar o tempo da simulação. Na versão 1.3, foi implementado um método para desacelerar a simulação e vê-la em câmera lenta, dessa forma, o arcabouço necessário para uma simulação mais rápida já estava pronto nessa versão.

Arquivo modificado

  • /br/ufrgs/f180/gui/MainWindow.java

Função modificada

  • private void initGUI()

Descrição

Para executar a função de desaceleração do jogo, o Tewnta utilizava uma variável de valor real chamada elapsedTimePerCycle definida na classe gui.MainWindow , que representa quanto tempo se passa em um ciclo de jogo. O usuário controla o valor dessa variável através de uma barra de rolagem presente na tela principal do Tewnta, como pode ser visto na figura 25. O valor dessa barra rolagem varia entre 1 e 100, onde 100 representa um segundo por um segundo, isso é, um segundo na simulação significa um segundo no mundo real.
\begin{figure}
\center
\includegraphics[height=5.28cm]{ModificacoesExecutadasFig01.png}
\caption{Controle do tempo de simulação - Tewnta.}
(25)
\end{figure}
A contribuição do trabalho ao Tewnta consistiu em modificar o alcance dessa barra de rolagem, como mostra o código 26, mudando de 1-100 para 1-500. Dessa forma, o usuário pode definir uma simulação até cinco vezes mais rápida.

CODIGO{codigo02.java}


Jogadores voltarem a posição inicial após o gol

Uma regra do Futebol de Robôs que não havia sido implementada no Tewnta era a volta dos robôs a seu campo de origem após um gol, como acontece no futebol humano. O posicionamento inadequado dos robôs após um gol pode favorecer ou prejudicar algum time durante uma partida.

Arquivo modificado

  • /br/ufrgs/f180/server/Game.java

Função modificada

  • public void updateState(double d)

Funções criadas

  • private void setUpRobot()
  • private double [ ][ ][ ] initialPositions()

Descrição

Para implementar essa correção, era necessário inicialmente definir quais seriam as posições inicias dos jogadores após um gol. Essas posições foram definidas em termos relativos às dimensões do campo, de forma que cada time tivesse um robô goleiro, dois robôs em posição de defesa e dois robôs avançados.
Para facilitar a implementação, foi criada a função private double [ ][ ][ ] initialPositions , que define uma matriz de três dimensões de valores reais, onde a primeira dimensão representa o time ao qual pertence o robô (0-1); a segunda dimensão define o índice daquele jogador dentro do time (0-4); e a terceira dimensão representa a coordenada (X ou Y) do valor real (0-1). Para que as posições dos jogadores não sejam sempre as mesmas a cada gol, foi incluído um fator aleatório na determinação das posições que pode

variar a posição definida em até 10. A implementação da função initialPositions() pode ser vista no código 27.

CODIGO{codigo03a.java}

Implementada a definição das posições dos jogadores, o proximo passo foi criar uma função que alterasse as posições dos jogadores. Então, definiu-se a função setUpRobot que pode ser vista no código 28. Essa função obtém e percorre o vetor de MovingElement da classe MainWindow e verifica quais são robôs, e a qual time eles pertencem, então seta a posição de acordo com a definição feita na função initialPositions() .


CODIGO{codigo03b.java}

Depois de implementadas as duas funções anteriores era necessário invocá-las no momento certo do código, então alterou-se a função updateState , que já estava definida desde a versão 1.2 do Tewnta. Essa função, entre outras coisas, define o que deve ser feito após um gol, então foi chamada a função setUpRobot() dentro do bloco de código que é executado após um gol, como pode ser visto no código 29.

CODIGO{codigo03c.java}

Dimensões atualizadas do campo

No Futebol de Robôs, as dimensões do campo podem ser modificadas a cada ano. Prevendo isso, o Tewnta possui um arquivo texto (game.properties ) que fica no diretório /src do código fonte onde são definidos os parâmetros do campo.

Arquivo modificado

  • /src/game.properties

Descrição

Para adequar o Tewnta às regras 2010 do futebol de robôs foi necessário modificar os seguintes campos no arquivo game.properties , como

pode ser verificado no código 30:

  • field.height -- altura do campo;
  • field.width -- largura do campo;
  • field.border -- borda do campo, entre as paredes e as linhas.


CODIGO{codigo04.properties}

Modificação implementadas na versão 1.3

Colisão

Uma das correções propostas pela equipe no início do trabalho foi o tratamento adequado da colisão entre robôs. No entanto, essa correção foi implementada na versão 1.3 do Tewnta.
Para cálculo da colisão, primeiramente foi implementada uma função booleana na classe elements.MovingElement para definir se dois objetos estão em vias de se colidir, como mostra o código 31, através do cálculo da distância entre esses dois objetos.


CODIGO{codigo06a.java}

Caso a função definida no código 31 detecte a colisão entre dois elementos, o cálculo da colisão é feito através de uma colisão não elástica, como mostra o código 32.

CODIGO{codigo06b.java}

Aceleração

Para o cálculo de posição de um elemento, método public void calculatePosition(double timeElapsed) , no código 33, da classe elements.Movingelement , o algoritmo calcula primeiro a velocidade em função da aceleração (código 34) no Movimento Linear e então define a nova posição. Para o Movimento Rotacional, a aceleração rotacional é calculada (código 35) e então a velocidade rotacional é calculada, e só depois o novo ângulo é calculado.

CODIGO{codigo07a.java}

CODIGO{codigo07b.java}

CODIGO{codigo07c.java}

No entanto, a implementação da Aceleração Linear utilizada no Tewnta não considera particularidades de robôs e solo, o cálculo é baseado na equação 36: onde <math>F</math> é a força exercida pelos motores dos robôs, e <math>m</math> é a massa dos robôs. Apesar desses parâmetros serem definidos através do arquivo game.properties, através dos experimentos, pode-se observar que a relação expressa em 36 não expressa adequadamente a relação, porque desconsidera dissipações de energia inerentes ao movimento. Uma possível solução é apresentada em 38.
<math>
a = \frac{F}{m}
 (36)
</math>
A implementação utilizada para cálculo da aceleração rotacional (código 35) se baseia na equação 37 onde <math>F</math> é a força de rotação e <math>m</math> a massa do robô. No entanto, essa equação não considera o Momento de Inércia do corpo em rotação, o que afasta da realidade a simulação desse evento físico. Uma alternativa para essa implementação é apresentada em 39.
<math>
a = \frac{F}{m}
(37) 
</math>
Ferramentas pessoais