Neste post, em ordem cronológica, do mais novo para o mais velho, colocaremos nossas disputas internas...
A começar pelo Torneio Juvenil de Robótica (USP) 2013 a luta de sumô Inácio vs Osiris. Talvez a luta mais lenta de todo o torneio pois os robôs já estavam sem baterias:
Quem viu o primeiro vídeo não vai acreditar no segundo: Após carregar as baterias, a luta entre o Inácio vs Artemis, a grande surpresa da nossa equipe, no cabo de guerra.
Antes do Torneio tivemos a luta Osiris vs Artemis que terminou 4 a 4. Quem viu o primeiro vídeo nem acredita que é o mesmo robô, isso porque nessa luta a bateria estava com 70% da capacidade.
A Mostra Nacional de Robótica (www.mnr.org.br) é o maior evento de robótica do ano. Reúne diversos trabalhos produzidos ao longo do ano em robótica. Possui uma versão virtual e presencial. Abaixo segue a prévia do vídeo de apresentação do projeto:
Em breve postamos a versão final e o artigo produzido. A ideia do artigo é fornecer informações de como construir um robô para resgate e sumô usando reciclagem e Arduino. Este trabalho é um resumo do que foi feito ao longo de 2012/2013 no projeto.
Primeira luta oficial entre os projetos de robótica da equipe Pequenos Cientistas: Artemis vs Osíris.
A pontuação foi combinada da seguinte forma:
2 pontos - se o robô sai sozinho da arena
4 pontos - se o robô prender o oponente por 3 segundos em um dos cantos, impedindo o movimento
10 pontos - se o robô empurrar o oponente para fora da arena.
Na contagem geral foi 2x1 para o Artemis, apesar que, depois fizemos mais alguns testes que não gravamos e terminou 4x2 para o Osiris.
Round 1
Quando iniciamos a preparação para a OBR de 2013 notamos um problema toda vez que acionávamos os sensores de infravermelho digital junto com o sensor de ultrassom: o robô simplesmente ignorava a leitura de linha e travava o movimento. Para tanto usamos a versão 2.0 do Simulino (santo simulino) e criamos um ambiente de teste, onde os 2 ldr´s da simulação funcionam como sensores IR digitais e o sensor de ultrassom como ele mesmo. Em vez de usarmos os motores, usamos led´s para facilitar a visualização do que está acontecendo, sendo que, o robô deveria reagir conforme fluxograma abaixo:
Para tanto seguimos a seguinte programação:
int emissor=10;
int receptor=9;
long cm1,duracao;
int sensor_d = 6; //conectar ao pino digital
int sensor_e = 7; //conectar ao pino digital
int diff1;
int diff2;
void setup(){
pinMode (emissor, OUTPUT);
pinMode (receptor, INPUT);
pinMode (13, OUTPUT);
pinMode (12, OUTPUT);
Serial.begin (9600);
}
void loop(){
//leitura dos sensores de IR
int linha_d = direita(); //armazena o valor de leitura na viarável linha_d
int linha_e = esquerda();//armazena o valor de leitura na variável linha_e
sonar();
Serial.print (linha_d);
Serial.print (", ");
Serial.print (linha_e);
Serial.print (", ");
Serial.println (cm1);
//se a leitura das linhas corresponder a branco, executa esta função
if (linha_d<800 || linha_e<800){
if (cm1<30){
digitalWrite (13, HIGH); //acende o led no pino 13
digitalWrite (12, LOW); //desliga o led pino 0
}
if (cm1>30){
digitalWrite (13, LOW); //desliga o led no pino 13
digitalWrite (12, HIGH); //liga o led pino 0
}
}
if (linha_d>=800||linha_e>=800){
digitalWrite (13, HIGH); //acende o led no pino 13
digitalWrite (12, LOW); //desliga o led pino 0
delay (10);
digitalWrite (13, LOW); //desliga o led no pino 13
digitalWrite (12, HIGH); //liga o led pino 0
delay (10);
}
}
int sonar(){
digitalWrite (emissor, LOW);
delayMicroseconds (2);
digitalWrite (emissor, HIGH);
delayMicroseconds (2);
digitalWrite (emissor, LOW);
duracao=pulseIn(receptor,HIGH);
cm1=microsecondstocentimeters(duracao);
}
long microsecondstocentimeters(long microseconds){
return microseconds/29/2;
}
int direita(){
pinMode( sensor_d, INPUT );
int leitura_d=digitalRead(sensor_d);
if (leitura_d==HIGH){
diff1=700;
}
else{
diff1=900;
}
return diff1;
}
int esquerda(){
pinMode( sensor_e, INPUT );
int leitura_e=digitalRead(sensor_e);
if (leitura_e==HIGH){
diff2=700;
}
else{
diff2=900;
}
return diff2;
}
Após rodar esta programação, o robô simulou o mesmo erro que observamos nos nossos treinos, onde o robô passa direto pela linha independente de encontrar a linha preta ou não (900 no virtual terminal), acendendo a luz amarela direta.
Para corrigir alteramos os seguintes trechos:
...
void loop(){
//leitura dos sensores de IR
int linha_d = direita(); //armazena o valor de leitura na viarável linha_d
int linha_e = esquerda();//armazena o valor de leitura na variável linha_e
...
Retirando a leitura do sonar e colocando-a de forma a agilizar a leitura dos sensores, fazendo com que a leitura do ultrassom só seja feita se o robô está sobre a linha branca, conforme abaixo:
...
//se a leitura das linhas corresponder a branco, executa esta função
if (linha_d<800 || linha_e<800){
sonar();
...
Além disso, na função sonar mudamos o valor do tempo em HIGH de 2 microssegundos para 10 microssegundos evitando erros de leitura:
...
int sonar(){
digitalWrite (emissor, LOW);
delayMicroseconds (2);
digitalWrite (emissor, HIGH);
delayMicroseconds (10);
digitalWrite (emissor, LOW);
duracao=pulseIn(receptor,HIGH);
cm1=microsecondstocentimeters(duracao);
}
...
O resultado final pode ser visto no vídeo abaixo,com a pequena alteração de colocar um led vermelho para identificar quando está sobre a a linha preta, um led amarelo para representar sobre a linha branca sem nenhum objeto à frente e, o led verde representando sobre a linha branca com objeto a menos de 30 cm:
Ainda assim, você pode notar que os led´s piscam alternadamente, mostrando que há interferência, causada pela leitura dos sensores. Isso pode provocar movimentos involuntários do robô interferindo no planejamento inicial. Para eliminar o problema criamos uma função que interpreta o sinal dos sensores:
...
//função que transforma a leitura dos sensores em uma variável, eliminando erros:
if (linha_d<800||linha_e<800){
estado = 100;
}
if (linha_d>=800||linha_e>=800){
estado = 300;
}
...
Essa função retorna o valor de 100 para branco e 300 para preto, eliminando o defeito anterior. Se baseia no princípio de Máquina de Estados Finitos que pode ser assim definido:
" é um modelo matemático usado para representar programas de computadores ou circuitos lógicos. O conceito é concebido como uma máquina abstrata que deve estar em um de seus finitos estados. A máquina está em apenas um estado por vez, este estado é chamado de estado atual. Um estado armazena informações sobre o passado, isto é, ele reflete as mudanças desde a entrada num estado, no início do sistema, até o momento presente. Uma transição indica uma mudança de estado e é descrita por uma condição que precisa ser realizada para que a transição ocorra. Uma ação é a descrição de uma atividade que deve ser realizada num determinado momento."
31/05/2013
PROJETO ENCERRADO - Oficialmente estamos aposentando o projeto Orion por conta do seu tamanho, fato observado na arena da OBR 2013 e, em seu lugar, iniciamos a construção do projeto: Artemis.
Parabéns aos Orion que nos deu uma medalha de ouro no Torneio J. Robótica 2012.
11/05/2013
A programação do robô para resgate foi construída da seguinte forma:
Os testes começaram com a programação para resgate, conforme atualização da semana passada. Nesta semana desenvolvemos a programação para desviar de obstáculos conforme vídeo abaixo. Os dois leds ficam acesos (azul e verde) quando o robô está seguindo linha. Quando o led verde acende o objeto está a 15cm do robô então se inicia o procedimento de desvio, conforme fluxograma abaixo:
Quando o robô está seguindo linha os dois led´s ficam acesos (azul e verde), quando está sobre a linha preta, os dois led´s desligam e quando encontra um objeto somente o led verde acende e inicia-se o procedimento de desvio. Falta apenas ajustar os tempos e instalar os dois motores na frente para melhorar a tração e seguir linha.
02/05/2013
Os testes do Orion adaptados para resgate apresentaram resultados positivos. Inciamos com um preparativo fazendo com o que o robô ative um sinal luminoso e sonoro quando estiver a 5 cm da vítima, conforme o vídeo abaixo:
Fluxograma do programa:
Após estes testes configuramos o programa em 3 blocos:
Bloco 1 - o robô deve andar para frente durante 3 segundos e girar para direita 1 segundo
Bloco 2 - se o sensor acusar algum objeto entre 15 a 40 cm o robô deve se dirigir até o objeto.
Bloco 3 - se o sensor detecta a vítima a menos de 15 cm e aciona as luzes e emite um alerta parando o robô.
Vídeo do teste:
Após inúmeros testes que envolveram alterar as variáveis como distância e como os blocos construídos liam as distâncias (invertendo os sinais de comparação > ou <), inserindo outras variáveis descobrimos que:
- os tempos do bloco 1 influenciavam a leitura do sensor de ultrassom, ou seja, enquanto estivesse rodando a ordem de andar por 3 segundos e girar por um segundo o sensor não funciona. Para corrigir o problema usamos a técnica de isolamento de blocos onde, separamos o programa em pedaços e o reconstruímos rodando cada pedaço de cada vez e depois inserindo os blocos um de cada vez.
- O bloco 2 apresentava um erro que interferia no processo por isso o removemos o que resolveu os últimos problemas em reconhecer e vítima, visto que, facilitou a programação excluindo ordens de detalhamento excessivo.
Para coroar uma semana em que tudo deu errado, não conseguimos gravar os últimos testes porque o Arduino, após várias execuções parou de funcionar, os pinos não responderam mais. Esperamos que seja só o excesso de uso - os fios dos motores estavam muito quentes e notamos um aquecimento da ponte H que está sem diodo.
Vale um parabéns aqui para o Marcelo que foi o primeiro a analisar a programação e chegar a conclusão de que havia um erro de programação e não problemas com transientes ou ruído causado pelo motor (por falta de espaço e tempo estamos usando a ponte H sem diodos).
Ainda falta instalar os dois motores na parte dianteira para seguir linha mas faremos isso na semana que vem. Essa constatação foi resultado da pesquisa realizada pela equipe avaliando robôs de outros grupos que já participaram da OBR e outras competições.
12/04/2013
Após a falha nos testes para seguir linha do Orion, realizamos uma reunião de revisão de projeto e alguns testes preliminares e chegamos as seguintes conclusões:
- A limitação no ato de virar do chassi é causada não pela distância dos sensores mas pela posição dos sensores que ficam na frente, distantes do motor que realiza a tração e, portanto temos 2 opções
* ou adicionamos 2 motores na dianteira do robô, o que aumentaria a tração e facilitaria o robô virar, em compensação, aumentaria o consumo de bateria do robô (0,2 A em condições normais - 2 motores de 0,1 A - e 0,6 A em condições de motor em stall.
* ou então trocamos a posição dos sensores de linha para seguidor de linha da frente para traseira, invertendo o lado do robô.
O teste de inversão dos sensores não funcionou a contento pois estes ficaram muito altos, o que atrapalhou a sensibilidade, portanto, testaremos a hipótese 1 - mais 2 motores.
05/04/2013
Após um tempo sem mexer no projeto Orion, fizemos algumas alterações importantes:
- Instalação de um drive de motor feito com TIP 110/115 (NPN/PNP) - ponte H
- Nova programação: seguidor de linha
- Alteração da equipe responsável pelo Orion, passando a ser a equipe de 8ª série da EE Elza Facca
Segue abaixo vídeo dos testes "seguir linha" com robô Orion:
Outubro de 2012
O chassi Orion, após o Torneio Juvenil de robótica, sofreu alterações motivadas por 2 fatores fundamentais:
1- Peso - a armação de alumínio e madeira, somada a bateria de chumbo/ácido de 6V, aumentava significativamente o peso do robô e o deixava fora da especificação do torneio (1,5kg).
2- Baterias - a bateria de 6V não alimentava corretamente os sensores e os motores.
Isso nos motivou as 3 mudanças e o novo protótipo do Orion 2.0:
- Instalar uma bateria de 213g - 11,1 V e 1A;
- Instalar 2 breakouts de sensores de linha QR1113 e 4 sensores de ultrassom HCSR04;
- Substituir a base de madeira e alumínio por uma base de acrílico (prancheta usada doada pelas inspetoras do EE Elza Facca M. Bonilha).
Como resultado direto houve um aumento da velocidade (ainda não medimos mas é visível), do torque e a regularidade do funcionamento dos sensores. Apareceram outros problemas que, ainda não divulgaremos. O mesmo vale para o código fonte, pois este robô está sendo preparado para equipe de ensino fundamental e como robô-treino para o nosso novo protótipo.
Sensor de IR (QR1113) instalado para leitura de linha
Sensor IR e Sensor de Ultrassom instalados na base de acrílico
Ainda com a bateria antiga
Sem bateria
Vídeo do Orion 2.0 já com a bateria nova e sensores
