Robot Lutador de Sumo



LABSIS

2015

Autores:


Fábio Gaspar (Nº1110564)

1110564@isep.ipp.pt


Pedro Simões (Nº1110568)

1110568@isep.ipp.pt

Introdução

Arquitetura

Hardware

Software

Resultados

Conclusões

Referências



  • Introdução

Início

No âmbito da cadeira de LABSIS (Laboratórios de Sistemas) do 3ºano da Licenciatura de Eletrotecnica e de Computadores do I.S.E.P. (Instituto Superior de Engenharia do Porto) foi pedida a realização de um projeto à escolha de cada grupo de alunos. Partindo de um projeto desafiante lançado pelos docente da cadeira decidimos fazer a contrução e respectivo desenvolvimento de software de um Robot Lutador de Sumo.

Para isso foi realizado um estudo prévio dos objectivos desse robot através da análise das regras oficiais da competição internacional "Robot Challenge". Na listagem seguinte estão apresentadas as regras fundamentais da prova, para consultar o regulamento na integra deve aceder a http://www.robotchallenge.org/fileadmin/user_upload/_temp_/RobotChallenge/Reglement/RC-Sumo.pdf .

• Número de Robots por Partida: 2 

• Duração da Partida: 3 minutos 

• Classes Disponíveis: 25g-3 kg

• Dimensões e Pesos Máximos dos Robots (por categoria):  

• Especificações do Dojô* (por categoria): 

A cor do dojô é preta e a linha a delimitar a mesma é branca. Para aproveitar os materiais existentes nos laboratórios foi invertida a cor da pista e da borda, ou seja foi contruída uma arena branca com linha preta.

*Dojô é o nome dado à arena onde ocorrem as lutas de sumo

• Especificações de Controlo: Autônomos ou Rádio-Controlados

O objetivo em concreto destes robots é encontrar e colocar fora da arena o adversário direto dentro do tempo de combate, o primeiro robot a sair com qualquer parte do chassis fora da pista é eliminado.

As regras fundamentais foram seguidas. Todas as regras secundárias foram modeladas de forma a permitir uma competição adaptada à realidade da nossa faculdade.

Optou-se pela contrução de um robot da categoria Mega Sumo e na variante de robots autônomos.

Os objetos alvo de avaliação consistiram no desenvolvimento e implementação do protótipo funcional do trabalho escolhido. O trabalho final deveria incluir um led a piscar à frequência de 1 Hz e o grupo poderia escolher o microcontrolador ou FPGA que pretendesse utilizar, assim como, a linguagem de programação. Era obrigatório o desenho da(s) placa(s) PCB, no entanto, não era obrigatório a sua implementação física.

  • Arquitetura

Início

O seguinte diagrama resume o trabalho desenvolvido, bem como os pinos/função dos pinos (se é uma entrada/saída, se utilizamos interrupção ou não):


Desprezou-se nesta secção a componente de alimentação do robot e o sistema mínimo de funcionamento do ATMega88 a serem abordados mais à frente.

  • Hardware

Início

A robótica é muitas vezes associada a algoritmos complicados e por vezes desnecessariamente. Uma das razões para tal é o desleixo no momento da escolha do hardware, desde sensores que podem facilitar a programação, a chassis que descomplicam alguns pontos do software.

Com o desenrolar do projeto foram estudadas algumas soluções de hardware diferentes mas ou por razões económicas ou por falta de fiabilidade dos componentes optamos por utilizar no robot os seguintes objetos para cumprir as funções necessárias:

  • Microcontrolador ATMega88:
O processamento de sinal e comando é provavelmente a componente mais fundamental na robótica, um microcontrolador mal dimensionado para um projeto pode trazer problemas no desenvolvimento do mesmo. Por isso optamos por utilizar um ATMega88 da Atmel Corporation no seu formato DIP (Dual Inline Package), em que possui:
  • 28 pinos, sendo 23 pinos de I/O divididos em 4 portos;  (só necessitamos de 9)
  • 3 temporizadores/contadores, sendo 2 de 8bits com prescaler e modo de comparação independentes, e 1 de 16bits; (necessitamos apenas de 2)
  • 6 canais de PWM; (necessitamos apenas de 1)
  • Clock interno de 8MHz com possibilidade de redução para 1MHz c/ativação de fusível; (velocidade de execução de ciclo completo suficiente para o projeto)
  • 2 pinos (de I/O) associados a interrupções externas; (necessitamos de 1)
  • 23 pinos PCINT que permitem gerar 4 interrupções diferentes a cada alteração na entrada desse pino; (necessitamos de 2) 
  • Alimentação entre 4.5V e 5.5V (alimentação do sistema lógico é de 5V está dentro da gama)
Para além destas características que foram importantes na escolha do micro pode-se ainda referir que o ATmega88 possui uma memória flash de 8Kbytes de que derivam 32x8-bit de registos, uma memória EEPROM de 512Bytes e uma memória RAM de 1Kbyte. Possui ainda 6 canais de ADC que permitem leituras de sensores analógicos não necessários neste projeto.



Circuito mínimo funcionamento ATMega88:

  • Drive de motor L293D:
Para um robot do qual se espera um movimento está logicamente associadas rodas e para mover as rodas estão acupulados motores. Para controlar a velocidade e sentido a que gira cada um dos motores de forma a permitir manobrar (virar à esquerda, direita e andar para trás) é necessário um controlador para os mesmos. Esse controlador deve seguir algumas "regras de ouro" para evitar dores de cabeça e custos no futuro. O controlador escolhido L293D da Texas Instruments satisfaz todas as necessidades e requisitos do sitema:
  • 600mA de corrente de saída por canal; (cada motor com a carga do robot consome cerca de 400mA por isso é suficiente)
  • 1.2A de corrente de pico; (o pico ocorre com o robot a empurrar o adversário de 3kg, em testes a empurrar uma caixa de 10kg numa superfície com baixo atrito foi atingido um máximo de 1.2A por motor pelo que é aceitável)
  • 4 canais; (necessitamos de 2 canais x 2 motores = 4 canais)
  • 2 PWM distintos; (necessitamos apenas de 1 pois os motores giram com a mesma velocidade)
  • Alimentação entre 4.5V e 7V; (alimentação do sistema lógico é de 5V está dentro da gama)
  • Alimentação dos canais de saída até 36V; (motores alimentados a 12V)


O PWM para a velocidade do motor A é introduzido no pino Enable 1,2 e do motor B é introduzido no pino Enable 3,4. A direção é dada pela conjugação dos bits IN1A e IN2A para o motor A e IN3A e IN4A de acordo com a seguinte tabela:



  • Motores Modelcraft RB350030-0A101R:
O movimento de um robot sumo deve ser ágil para isso os motores devem ser velozes mas também têm de ter força que se traduza num binário suficiente para empurrar o adversário. Este misto de velocidade/força foi encontrado nos RB350030-0A101R da Modelcraft. Estes potentes motores têm:
  • Uma voltagem de funcionamento de 12V; (ideal para a nossa bateria)
  • Um torque máximo de 60 N/cm; (equivalente a 6,11Kg/cm a multiplicar por 2 motores temos 12,22Kg/cm suficiente para aguentar o próprio peso e do adversário)
  • Um consumo aproximado em carga baixa de 300mA; (dentro dos limites do driver L293D)
  • 200 rpm de velocidade nominal e 174 rpm de velocidade em carga; (torna o robot suficientemente rápido no combate)
  • Eficiência de 66%; (aceitável tendo em conta que grande parte da carga da bateria é utilizada pelos motores)


  • Regulador de tensão LM7805:
Os motores são alimentados diretamente pela bateria de 12V o mesmo não se pode aplicar aos diversos componentes do sistema (microcontrolador, driver motor, sensores, etc.), estes têm uma voltagem requirida na ordem de 5V. Para aproveitarmos a bateria dos motores e assim alimentar todo o sistema através de uma só fonte é necessário regular essa tensão de entrada de 12V para 5V. Isso é possível graças ao regulador LM7805 da Texas Intruments utilizado por nós, ou a outro com características semelhantes:

  • Tensão de saída de 5V com 4% de tolerância; (no mínimo temos uma saída de 4.8V e no máximo de 5.2V suportados pela escala dos componentes)
  • Tensão de entrada recomendada entre 7V a 25V; (adapta-se à tensão de saída da bateria de 12V)
  • Corrente máxima de saída igual a 1.5A; (o consumo do conjunto microcontrolador, driver de motor e sensores tem um consumo na ordem dos mA não atingindo 1A)


  • Sensor de Distância Ultrassônico HC-SR04:
Para localizar o adversário não há necessidade de um sensor com elevada precisão quanto à distância processada, os pontos mais importantes neste sensor são o raio de ação e ângulo de leitura, já que não necessitamos de saber a distância exata ao adversário só precisamos de avaliar em redor do robot qual a direção onde se encontra um obstáculo. Optamos pelo sensor mais comum e económico para a medição de distâncias, o HC-SR04, um sensor ultrssônico que possui características aceitáveis para ser integrado neste tipo de projeto:
  • Alcance: 2cm a 4m; (no nosso projeto são consideradas leituras até 1,55m sensívelmente o diâmetro da pista, área onde se pode encontrar o adversário)
  • Ângulo de leitura: 15º; (o sensor está colocado de forma a não detetar a superfície da arena, pelo que o ângulo de 15º pode ser desprezado)
  • Precisão: 3mm; (um erro de 3mm não é grave quando se procura um obstáculo num raio de 1,55m)
  • Alimentação: 5V; (alimentação proveniente do LM7805 é de 5V)
Este tipo de sensores funciona de uma forma simples e como o próprio nome indica, à base de ultra sons. São utilizados 2 pinos de ligação ao microcontrolador, o "Trig" ou "Ping" para enviar o ultra som e o "Echo" para receber o eco do ultra som. O tempo de receção do eco permite saber a distância ao objeto que provocou esse eco:


Distância = [Tempo ECHO em nível alto * Velocidade do Som] / 2

  • Sensores de Linha:
Neste projeto estes sensores são a ressalva que o robot tem para se encontrar dentro da arena, como tal foi procurada uma solução que dê garantias de correto funcionamento. Após uma longa procura no mercado foram encontradas umas placas que consistem num fototransistor TCRT5000 e um circuito comparador (LM393) que retorna valores digitais, 0 ou 1 caso o robot se encontre no preto ou no branco respetivamente. Acerca dessas placas sem referência específica foi possivel obter as seguintes características:
  • Leitura de distâncias ente 1 a 25mm; (o chassis está a 2mm da arena por isso será possivel obter leituras sem problema)
  • Tensão de entrada entre 3.3V e 5V; (a saída do regulador de tensão será suficiente para alimentar as 4 placas)

  • Bateria
Por último, mas não menos importante uma vez que tudo o resto está dependente da mesma, foi escolhida uma bateria Ni-MH (níquel-hidreto metálico) que tem uma boa razão peso / capacidade de alimentar o circuito:
  • Tensão de saída de 12V; (tensão para o qual foram dimensionados o regulador de tensão e motores)
  • Debita até 1000mAh; (é suficiente uma vez que cada combate tem a duração de 3 minutos e no máximo são disputados 3 combates seguidos, que equivalem a uma partida)
  • Peso de 250g; (representa cerca de 8% do peso máximo permitido do robot)


  • Interruptor RF
Já considerado um extra mas com bastante utilidade, decidimos aplicar ao robot um interruptor para corte da energia via RF e com isso diminuir problemas causados com a necessidade de clicar num botão local no robot para iniciar prova influenciando nas leituras de distância obtidas pelo mesmo.
Tendo 4 canais optamos por usar um modo de funcionamento "inter-lock" em que é premido o botão A para fechar o interruptor e o botão B para o abrir.
Sendo considerado um extra e não tendo influência o seu dimensionamento apenas fica a sua imagem, o seu esquema elétrico e a tensão de funcionamento que é 12V (alimentado pela bateria):

  • PCB (Placa Circuito Impresso)

Para a assemblagem dos componentes e desenvolvimento de software (código), inicialmente foi utilizada uma breadboard, algo prático para quando se pretende efetuar pequenos testes da funcionalidade do sistema.


Como se percebe pela imagem este sistema é um pouco confuso e pouco víavel para um robot que estará sujeito a forças exercidas pelo adversário. Por essa razão logo após a atribuição correta dos pinos aos componentes e depois dos ensaios foi realizada a placa PCB cujo esquemático (desenhado pelo software EAGLE) se encontra na imagem seguinte. 



X1-1 e X1-2: Saída Motor 1
X2-1 e X2-2: Saída Motor 2
SL_FE: Jumper Entrada Sensor Linha Frente Esquerdo (1-GND; 2-VCC; 3-Sinal)
SL_FD: Jumper Entrada Sensor Linha Frente Direito (1-GND; 2-VCC; 3-Sinal)
SL_TE: Jumper Entrada Sensor Linha Trás Esquerdo (1-GND; 2-VCC; 3-Sinal)
SL_TD: Jumper Entrada Sensor Linha Trás Direito (1-GND; 2-VCC; 3-Sinal)
SONAR: Jumper entrada sensor ultrassons (1-GND; 2-ECHO; 3-TRIGGER; 4-VCC)

Após o desenho do equemático este foi exportado para um layout de PCB (Placa de Circuito Impresso) que depois de algumas otimizações deu origem à placa final do nosso projeto.


A imagem da esquerda apresenta a camada "bottom" da placa com o "footprint" dos componentes. Na imagem da direita encontra-se o desenho pronto a imprimir e a transferir para a placa pre-sensibilizada.
  • Chassis

Com todos os componentes anteriores adquiridos/construídos, o hardware encontrava-se pronto a ser fixo, era necessário então o desenvolvimento de um chassis que se adapta-se a este tipo de prova, que fosse rebusto e que cumpri-se o regulamento quer em dimensões como em peso. Para isso foi utilizada uma base de alumínio (material leve e robusto) onde foram fixados os motores através de suportes também eles em alumínio. Para tornar o lutador de sumo compacto o chassis foi apenas dividido em duas peças únicas, a base e a cobertura que contempla extremidades laterais do robot. Fica em baixo a foto de cada uma das peças na fase de construção.





Como perceptivel no recorte traseiro o chassis possuí dois leds, um que indica se a alimentação está ligada (vermelho) e outro que pisca à frequência de 1Hz.

O chassis com todo o hardware no seu interior tem as dimensões finais de 19,5 por 19,8 cm e pesa 1,80 kg.

  • Software

Início


Como anteriormente referido um hardware bem dimensionado pode culminar num código simples, esse é o nosso caso. Com a escolha feita dos componentes e desenvolvimento de uma PCB que evita problemas relacionados com ruído elétrico, o nosso código reduziu-se a 5 objetivos:

  1. Ler sensores de linha;
  2. Ler distância para detetar adversário;
  3. Efetuar manobras com o motor para ir em direção ao adversário;
  4. Colocar o led a piscar a uma frequência de 1Hz (1 em 1 segundo);
  5. Efetuar as configurações de interrupções e timers/contadores utilizados;
Sendo que umas ações desencadeam outras a melhor forma de efetuar o código é realizar um fluxograma do funcionamento do mesmo antes de o começar a desenvolver:



  1. Ler sensores de linha
Demonstrado na secção Arquitetura, a leitura dos sensores de linha é feita através da função PCINT (Pin Change Interrupt) do microcontrolador, como o nome indica este tipo de interrupção ocorrerá quando houver uma mudança no estado do pino escolhido. No atmega88 existem 3 vetores de interrupção para esse tipo de interrupção estando cada um deles está ligado a um PORT. Consequentemente, caso dois pinos de um mesmo PORT estejam utilizando essa interrupção ambos compartilharão a mesma rotina de interrupção. Por isso utilizamos 2 portos diferentes para os sensores de linha, os dois da frente associados ao PORTD e os dois de trás associados ao PORTB.
Ficamos assim com o vetor de interrupção PCINT2 para alterações nos sensores da frente e PCINT0 para alterações nos sensores de trás.



Na "main" para além de fazermos o TRIGGER é necessário verificar o estado das variáveis FE e FD e colocar os motores a girar conforme necessário. Esta operação não foi feita dentro do vetor de interrupção pois o ciclo "while" impedia o código de entrar noutras interrupções como por exemplo a do "led pisca".



Resumindo:
Quando detetada a linha por um sensor de trás é dada ordem para os motores andarem para a frente durante 300ms;
Quando detetada a linha por um sensor da frente, verifica qual dos sensores foi e efetua a manobra de girar sobre si mesmo (rodando apenas um motor) até encontrar o sensor de trás do lado contrário ao detetado;
  1. Ler distância para detetar adversário
Como explicado na secção de análise ao Hardware, o tempo durante o qual o pino do micro que lê o pino ECHO do sonar se encontra a 1 (estado HIGH) está relacionado com a distância ao objeto que provocou a geração desse eco.
Por esse fator decidimos utilizar o pino INT1 (interrupção externa 1), com esta interrupção a acontecer no flanco ascendente sabemos o momento no qual começou a receção do ECHO, iniciamos um timer, no nosso caso o timer 1 (sem prescaler), que contará o tempo até voltar a ocorrer essa transição mas desta feita no flanco ascendente, com esse valor de tempo dividimos por 2 (porque esse valor é o tempo que demorou o som na ida e na volta) e multiplicamos pela velocidade do som. Devido às unidades de medida serem diferentes foi utilizada uma fórmula genérica disponibilizada pelo fabricante em  que se dividide o tempo retornado pelo timer por 58 e já se tem a distância em centímetros.



Para além disso é preciso fazer o envio do ultra som através do TRIGGER, para isso é colocado o pino PD2 ativo durante 10uS, tempo que deve ter o som enviado.
Outra nota neste capítulo de código é o uso do vetor de overflow do timer 1 que ao ser chamado incrementa uma variável, isto acontece pois dependendo da distância ao objeto o timer pode ultrapassar o seu limite. A nível de cálculo basta multiplicar essa variável pelo tempo máximo contado pelo timer.



Enqunto a distância não for inferior ao diâmetro da pista o robot vai continuar a rodar sobre si para obter novas leituras, quando detetar o adversário vai parar a rotação e seguir em direção a ele.


Resumindo:
Roda o robot a uma velocidade que permita a leitura de distância;
Envia um sinal de TRIGGER durante 10uS;
Espera a receção do ECHO e aquando a chegada do mesmo efetua contagem de quanto tempo demora a receção;
Efetua o cálculo da distância em centímetros;
Se a distência for menor ao limite da pista o robot para a rotação e segue em frente;

  1. Efetuar manobras com o robot
As manobras a realizar já foram contempladas nos outros objetivos do código, resta agora explicar como é dada a ordem para que essas manobras sejam efetuadas.
Poupando texto a reescrever o funcionamento do controlador de motor apenas resta explicar quais os pinos a ativar (e como o fazer) para que a ordem dada pelo micro ao controlador de motores e consequentemente aos mesmos:

Motores -> PORTC
Bit 2:  Motor Esquerda Trás
Bit 3: Motor Esquerda Frente
Bit 4: Motor Direita Trás
Bit 5: Motor Esquerda Frente

Para o controlo de velocidade é utilizado o controlo PWM (Modo Phase Correct) associdado ao OCR2. Para isso é enviado um valor entre 0 a 255 no pino OCR2A que vai ligar ao pino de ENABLE do controlador do motor e que vai fazer variar a tensão de saída para os motores controlando a sua velocidade.

Por exemplo: OCR2A=255;

Resumindo:
Se se pretender andar para a frente com os dois motores ativa-se os pinos 3,5 do PORTC e desativam-se os bits 2,4 do mesmo porto;
Se se pretender andar para a trás com os dois motores ativa-se os pinos 2,4 do PORTC e desativam-se os bits 3,5 do mesmo porto;
Se se pretender rodar para a esquerda ativa-se o pino 5 do PORTC e desativam-se os bits 2,3,4 do mesmo porto;
Se se pretender rodar para a direita ativa-se o pino 3 do PORTC e desativam-se os bits 2,4,5 do mesmo porto;
A velocidade é controlada pela saída PWM OCR2A, o valor 0 equivale ao motor parado e 255 ao motor à máxima rotação;

  1. Colocar o led a piscar a uma frequência de 1Hz
Um dos objetivos impostos pelos docentes era o de colocar um led a piscar a uma frequência de 1Hz para que fosse identificado qualquer problema de hardware caso o mesmo parasse de piscar.
Para realizar essa tarefa foi necessário utilizar a interrupção gerada pelo timer 0 configurado de forma a 500 em 500ms alterar o estado do led fazendo-o piscar com um período de 1segundo equivalente a 1Hz. (f=1/T)


Resumindo:
De 500 em 500 ms é gerada uma interrupção;
A interrupção contém código responsável por efetuar o "toogle" do led;


  1. Configurações
Para realizar as funções anteriormente descritas são necessárias algumas configurações prévias, nomeadamente dos "timers/counters" e interrupções.
Saltando a parte das configurações dos portos/pinos em que se define apenas se são entradas ou saídas, segue a explicação das restantes configurações efetuadas:

Timer Counter 0 (responsável pelo led a piscar):
TCCR0A=0b00000010;                   // Modo CTC (Clear Timer Compare Match), Normal port operation, OC0A desligado
TCCR0B=0b00000011;                   // Prescaler=64, interrupção gerada de 5 em 5 ms
OCR0A=77;                                     // 1+OCROA = (0,005*1000000)/64 <=> 78-1 = 77
TIMSK0 = 1<<OCIE0A;                 // Ativar a interrupção TC0

Só é necessário salientar que a interrupção é gerada 5 em 5 ms e é incrementada uma variável ("flag_500"), quando esta atingir o valor de 100 (100*5=500ms) significa que foram atingidos 500ms e aí faz-se o "toogle" do led.

Interrupções PCINT0 e PCINT2 (responsáveis pelos sensores de linha):
PCICR |= (1<<PCIE2)|(1<<PCIE0);   // Ativa as interrupções PCINT0 e PCINT2
PCMSK2 =0b11000000;                    // Define os pinos 6 e 7 do PORTD como responsáveis pela interrupção PCINT2
PCMSK0 =0b11000000;                    // Define os pinos 6 e 7 do PORTB como responsáveis pela interrupção PCINT0

Da explicação acima deduz-se que o PORTD está associado à interrupção PCINT2 mas só com alterações nos pinos 6 e 7, o mesmo acontece para o PORTB associado à interrupção PCINT0 mas que só é atuada caso existam alterações nos pinos 6 e 7. Os pinos 6 e 7 de ambos os portos são onde se encontram ligados os sensores de linha.

Interrupção externa INT1 (responsável pelo sonar):
EICRA|= (0 << ISC11) | (1 << ISC10);               // Configura a interrupção para qualquer alteração na entrada do micro ascendente ou desccendente
EIMSK|= (1 << INT1);                                       // Ativa a interrupção INT1   
TCCR1A=0;                                                       // Coloca o TCCR1A a zero
TCCR1B|=(0<<CS12)|(0<<CS11)|(1<<CS10); // Ativa o timer sem prescaler
TCNT1 = 0;                                                       // Reinicia o TCNT1
TIMSK1|= (1<<TOIE1);                                   // Ativa a interrupção gerada pelo TIMER1

Com o pino do ECHO do sonar ligado ao microcontrolador através do pino de interrupção externa 1 e com esta configuração, a interrupção externa INT1 será ativada sempre que existir uma alteração no pino de interrupção externa. O código responsável por verificar se é efetuada uma alteração no flanco ascendente ou descendente está dentro do vetor da própria interrupção.

          OC2A (responsável pelo PWM enviado ao controlador dos motores):
          TCCR2A|=0b10000001;                    // |1|0|X|X|X|X|X|X| Set OC2A no flanco ascendente, Clear no flanco descendente // |X|X|X|X|X|X|0|1| Modo 1 - PWM Phase Correct
          TCCR2B|=0b00000001;                    // |X|X|X|X|0|X|X|X| Modo 1 - PWM Phase Correct // |X|X|X|X|X|0|0|1| Timer/Counter sem prescaler

           Depois de alguns testes realizados foi preferido o modo de funcionamento 1 (PWM Phase Correct) uma vez que cumpria o necessário não sendo então preciso o Modo Fast PWM.

  • Resultados

Início

Após todo o processo de planeamento e desenvolvimento chegou a "hora da verdade".

Sem outro robot lutador de sumo para se opôr ao nosso foi arranjada uma solução de recurso para efetuar os testes. Essa solução consiste numa caixa (com aproximadamente 3kg de peso) a simular o adversário:

(clique na imagem para ver o vídeo)

Com estes testes podemos afirmar que o nosso robot se encontra apto para competição.


  • Conclusões

Início


O tempo de realização deste projeto foi de 3 meses, considerando 5 horas de trabalho por semana. Um processo demoroso devido à análise dos componentes, desenvolvimento de software e construção do chassis, que poderia ser reduzido caso se replique o projeto para futuros robots.

O orçamento gasto para a realização deste projeto encontra-se descriminado na seguinte tabela:


Apesar do aparatoso valor, ainda faltam micro componentes como os ligadores da PCB, o microswitch da malha de reset, etc., e o custo da realização da PCB. Contudo para muitos destes componentes são disponibilizadas amostras por parte do fabricante a estudantes que estejam a desenvolver projetos semelhantes. Outros dos componente já tinhamos pelo que a poupança foi maior.

No final do projeto é satisfatório quando vemos traduzido todo o nosso esforço e dedicação num robot desenvolvido completamente do zero e de forma autónoma.

Num projeto mais ambicioso poderiam ser acrescentados sensores de distância nas superfícies laterais e na traseira do robot para evitar o movimento circular em busca do adversário, adivinhando-se assim um robot com uma resposta mais rápida do que o atual.  

Para qualquer dúvida contacte via email para 1110568@isep.ipp.pt  

  • Referências

Início

            [1] Atmel, http://www.atmel.com/images/doc2545.pdf - Datasheet Atmega88
             [2] Texas Instruments, http://www.ti.com/lit/ds/symlink/l293.pdf - Datasheet L293D
            [3] Texas Instruments, http://www.ti.com/lit/ds/symlink/lm7805c.pdf - Datasheet LM780

            [4] Robot Challenge, http://www.robotchallenge.org/fileadmin/user_upload/_temp_/RobotChallenge/Reglement/RC-Sumo.pdf - Regulamento Prova Robot Sumo
             [5] Adororobotica, http://www.adororobotica.com/ARQUIVOS/robocore__regras_sumo_570.pdf - Regras Adaptadas Prova Robocore Sumo
            [6] Robôtica Autônoma - Sumô de Robôs, http://pt.scribd.com/doc/241756401/307-973-1-PB-PDF#scribd - Dicas de Robótica (Lutadores de Sumo)


Início