Olá pessoal,
Segue nosso relatório referente ao projeto.
http://www.4shared.com/document/UXEtKEII/Relatrio_de_STR_-_Resgate_em_M.html
Nossa apresentação será no dia 01/12 e estamos ansiosos!
domingo, 28 de novembro de 2010
sábado, 23 de outubro de 2010
Testes e mais testes
Olá.
Trago um vídeo dos testes realizados no percurso oficial. Tivemos imensas dificuldades, algumas resolvidas, outras não, que podem ser claramente percebidas no vídeo a seguir:
1º Problema: Sensor detectou a "curva" mas robô não corrigiu a trajetória em tempo hábil. Vê-se claramente que o robô detecta a borda negra porém sua correção demora a ser aplicada corretamente fazendo com que o robô continue na trajetória anterior e passe extremidade do circuito. Fatores inerentes: Velocidade de robô, sensibilidade dos sensores da linha e principalmente a técnica de programação não concorrente "pooling"(conforme indicação do Prof. Rafael). Como não podemos diminuir a velocidade do robô (temos um deadline a cumprir!!) e a sensibilidade dos sensores já estava pré-definida e qualificada para todo o resto do percurso, aderimos a causa de que a programação por threads (concorrente/quase simultânea) possa resolver o problema. Se o robô ler o sensor de linha e (ao mesmo tempo) corrigir a direção teremos maior eficácia, diminuindo tempo de correção e tempo de detecção de erros. Abaixo, imagem que ilustra o exato momento de "perda dos sentidos" do robô.
2º Problema: "Salto" no final da subida da ladeira. Como o robô está em uma velocidade considerável ele acaba pulando no final da subida da ladeira, o que o deixa com pouco tempo para detectar a curva logo a frente. Cremos que a solução adequada seja a mesma referente ao primeiro problema, pois com a correção simultânea à leitura o robô detectará com mais facilidade.
3º Problema: Mecânica. A mecânica da garra (não presente no vídeo) ficou IMENSA, alterando o centro de massa do robô para frente e impedindo que o mesmo fique estável na descida da ladeira. Solução: REFAZER toda mecânica da garra e sensor de toque (presença do boneco).
Por enquanto é só.
Já fizemos a programação concorrente (em threads) para a movimentação no circuito. Após testes, colocaremos aqui.
See ya!
Trago um vídeo dos testes realizados no percurso oficial. Tivemos imensas dificuldades, algumas resolvidas, outras não, que podem ser claramente percebidas no vídeo a seguir:
1º Problema: Sensor detectou a "curva" mas robô não corrigiu a trajetória em tempo hábil. Vê-se claramente que o robô detecta a borda negra porém sua correção demora a ser aplicada corretamente fazendo com que o robô continue na trajetória anterior e passe extremidade do circuito. Fatores inerentes: Velocidade de robô, sensibilidade dos sensores da linha e principalmente a técnica de programação não concorrente "pooling"(conforme indicação do Prof. Rafael). Como não podemos diminuir a velocidade do robô (temos um deadline a cumprir!!) e a sensibilidade dos sensores já estava pré-definida e qualificada para todo o resto do percurso, aderimos a causa de que a programação por threads (concorrente/quase simultânea) possa resolver o problema. Se o robô ler o sensor de linha e (ao mesmo tempo) corrigir a direção teremos maior eficácia, diminuindo tempo de correção e tempo de detecção de erros. Abaixo, imagem que ilustra o exato momento de "perda dos sentidos" do robô.
 |
| Imagem do momento exato do problema 1 |
2º Problema: "Salto" no final da subida da ladeira. Como o robô está em uma velocidade considerável ele acaba pulando no final da subida da ladeira, o que o deixa com pouco tempo para detectar a curva logo a frente. Cremos que a solução adequada seja a mesma referente ao primeiro problema, pois com a correção simultânea à leitura o robô detectará com mais facilidade.
3º Problema: Mecânica. A mecânica da garra (não presente no vídeo) ficou IMENSA, alterando o centro de massa do robô para frente e impedindo que o mesmo fique estável na descida da ladeira. Solução: REFAZER toda mecânica da garra e sensor de toque (presença do boneco).
Por enquanto é só.
Já fizemos a programação concorrente (em threads) para a movimentação no circuito. Após testes, colocaremos aqui.
See ya!
quinta-feira, 14 de outubro de 2010
Comunição - Parte II
Conforme dito na postagem de terça-feira, 28 de setembro, segue o programa que faz a comunicação Bluetooth (escravo e mestre). Trata-se apenas de um teste da interface dos dois aplicativos.
Segue!
Codigo do Mestre
#include "NXCDefs.h"
#define INBOX 1
#define OUTBOX 5
sub BTCheck(int conn){
if (!BluetoothStatus(conn)==NO_ERR){
TextOut(5,LCD_LINE2,"Erro");
Wait(1000);
Stop(true);
}
}
task main(){
//Definindo sensores
SetSensor(IN_1,SENSOR_TOUCH);
string in,out="START";
BTCheck(1); // Verifica conexão
TextOut(10,LCD_LINE1,out);
SendRemoteString(1,OUTBOX,out);
while (1){
OnFwd(OUT_AB, 100);
//Se sensor de toque ativado, envia mensagem escravo
if (SENSOR_1 == 1) {
out = "GIRE!";
SendRemoteString(1,OUTBOX,out);
while(in != "GIRO COMPLETO"){
ReceiveRemoteString(INBOX, TRUE, in);
Wait(100);
}
in = "";
OnRev(OUT_AB, 75);
Wait(1000);
OnFwd(OUT_A, 75);
OnRev(OUT_B, 75);
Wait(500);
}
}
}
Codigo do Escravo
#define INBOX 5
#define OUTBOX 1
sub BTCheck(int conn){
if (!BluetoothStatus(conn)==NO_ERR){
TextOut(5,LCD_LINE2,"Erro");
Wait(1000);
Stop(true);
}
}
task main(){
string in,out="OK!";
BTCheck(0); //Verifica conexão
while (in != "START"){
Wait(100);
TextOut(10,LCD_LINE1,"ESPERANDO START MESTRE");
ReceiveRemoteString(INBOX, true, in);
}
out = "OK";
SendResponseString(OUTBOX, out);
TextOut(10,LCD_LINE1,"START MESTRE OK");
while(1){
TextOut(10,LCD_LINE1,"ANDANDO FRENTE");
OnFwd(OUT_AB, 100);
ReceiveRemoteString(INBOX, TRUE, in);
if (in == "GIRE!"){
TextOut(10,LCD_LINE1,"GIRANDO");
OnRev(OUT_AB, 75);
Wait(1000);
OnFwd(OUT_A, 75);
OnRev(OUT_B, 75);
Wait(500);
in = "";
out = "GIRO COMPLETO";
TextOut(10,LCD_LINE1,"GIRO COMPLETO);
SendResponseString(OUTBOX, out);
}
}
}
Segue!
Codigo do Mestre
#include "NXCDefs.h"
#define INBOX 1
#define OUTBOX 5
sub BTCheck(int conn){
if (!BluetoothStatus(conn)==NO_ERR){
TextOut(5,LCD_LINE2,"Erro");
Wait(1000);
Stop(true);
}
}
task main(){
//Definindo sensores
SetSensor(IN_1,SENSOR_TOUCH);
string in,out="START";
BTCheck(1); // Verifica conexão
TextOut(10,LCD_LINE1,out);
SendRemoteString(1,OUTBOX,out);
while (1){
OnFwd(OUT_AB, 100);
//Se sensor de toque ativado, envia mensagem escravo
if (SENSOR_1 == 1) {
out = "GIRE!";
SendRemoteString(1,OUTBOX,out);
while(in != "GIRO COMPLETO"){
ReceiveRemoteString(INBOX, TRUE, in);
Wait(100);
}
in = "";
OnRev(OUT_AB, 75);
Wait(1000);
OnFwd(OUT_A, 75);
OnRev(OUT_B, 75);
Wait(500);
}
}
}
Codigo do Escravo
#define INBOX 5
#define OUTBOX 1
sub BTCheck(int conn){
if (!BluetoothStatus(conn)==NO_ERR){
TextOut(5,LCD_LINE2,"Erro");
Wait(1000);
Stop(true);
}
}
task main(){
string in,out="OK!";
BTCheck(0); //Verifica conexão
while (in != "START"){
Wait(100);
TextOut(10,LCD_LINE1,"ESPERANDO START MESTRE");
ReceiveRemoteString(INBOX, true, in);
}
out = "OK";
SendResponseString(OUTBOX, out);
TextOut(10,LCD_LINE1,"START MESTRE OK");
while(1){
TextOut(10,LCD_LINE1,"ANDANDO FRENTE");
OnFwd(OUT_AB, 100);
ReceiveRemoteString(INBOX, TRUE, in);
if (in == "GIRE!"){
TextOut(10,LCD_LINE1,"GIRANDO");
OnRev(OUT_AB, 75);
Wait(1000);
OnFwd(OUT_A, 75);
OnRev(OUT_B, 75);
Wait(500);
in = "";
out = "GIRO COMPLETO";
TextOut(10,LCD_LINE1,"GIRO COMPLETO);
SendResponseString(OUTBOX, out);
}
}
}
Programa para seguir linha
Bem,
Ainda não aplicando os conceitos de Sistemas de Tempo Real fizemos uma rotina de interpretação e correção com intuito de seguir a linha. A idéia era testar a mecânica do robô interagindo com o ambiente a qual este será utilizado.
O programa é em linguagem estruturada utilizando pooling, ou seja, linha por linha, testando os sensores luz e corrigindo a rota.
Segue programa:
#include "NXCDefs.h"
#define THRESHOLD 35 // ver range
byte velA, velB;
void corrigeRota(byte dir){
if (dir == 1){
OnRev(OUT_A, 45);
OnFwd(OUT_B, 75);
Wait(100);
TextOut(5,LCD_LINE3,"motor A rev ");
}else{
OnRev(OUT_B, 45);
OnFwd(OUT_A, 75);
Wait(100);
TextOut(5,LCD_LINE3,"motor B rev");
}
}
void segueRota(){
OnFwd(OUT_A, velA);
OnFwd(OUT_B, velB);
}
task main(){
TextOut(5,LCD_LINE1,"START");
//Definindo sensores
SetSensor(IN_1,SENSOR_TOUCH);
SetSensorLight(IN_3);
SetSensorLight(IN_2);
while (true)
{
if ((Sensor(IN_3) < THRESHOLD) && (Sensor(IN_2) > THRESHOLD)){
corrigeRota(1);
TextOut(5,LCD_LINE2,"rota 1");
}else{
if ((Sensor(IN_2) < THRESHOLD) && (Sensor(IN_3) > THRESHOLD)){
corrigeRota(0);
TextOut(5,LCD_LINE2,"rota 0");
}
}
if ((Sensor(IN_3) >= THRESHOLD) && (Sensor(IN_2) >= THRESHOLD)){
TextOut(5,LCD_LINE2,"Sensores fora linha preta");
velA = 90;
velB = 90;
TextOut(5,LCD_LINE3,"vel 100");
}
if ((Sensor(IN_3) < THRESHOLD) && (Sensor(IN_2) < THRESHOLD)){
TextOut(5,LCD_LINE2,"Sensores na linha preta");
velA = 90;
velB = 90;
TextOut(5,LCD_LINE3,"vel 100");
}
segueRota();
}
}
Ainda não aplicando os conceitos de Sistemas de Tempo Real fizemos uma rotina de interpretação e correção com intuito de seguir a linha. A idéia era testar a mecânica do robô interagindo com o ambiente a qual este será utilizado.
O programa é em linguagem estruturada utilizando pooling, ou seja, linha por linha, testando os sensores luz e corrigindo a rota.
Segue programa:
#include "NXCDefs.h"
#define THRESHOLD 35 // ver range
byte velA, velB;
void corrigeRota(byte dir){
if (dir == 1){
OnRev(OUT_A, 45);
OnFwd(OUT_B, 75);
Wait(100);
TextOut(5,LCD_LINE3,"motor A rev ");
}else{
OnRev(OUT_B, 45);
OnFwd(OUT_A, 75);
Wait(100);
TextOut(5,LCD_LINE3,"motor B rev");
}
}
void segueRota(){
OnFwd(OUT_A, velA);
OnFwd(OUT_B, velB);
}
task main(){
TextOut(5,LCD_LINE1,"START");
//Definindo sensores
SetSensor(IN_1,SENSOR_TOUCH);
SetSensorLight(IN_3);
SetSensorLight(IN_2);
while (true)
{
if ((Sensor(IN_3) < THRESHOLD) && (Sensor(IN_2) > THRESHOLD)){
corrigeRota(1);
TextOut(5,LCD_LINE2,"rota 1");
}else{
if ((Sensor(IN_2) < THRESHOLD) && (Sensor(IN_3) > THRESHOLD)){
corrigeRota(0);
TextOut(5,LCD_LINE2,"rota 0");
}
}
if ((Sensor(IN_3) >= THRESHOLD) && (Sensor(IN_2) >= THRESHOLD)){
TextOut(5,LCD_LINE2,"Sensores fora linha preta");
velA = 90;
velB = 90;
TextOut(5,LCD_LINE3,"vel 100");
}
if ((Sensor(IN_3) < THRESHOLD) && (Sensor(IN_2) < THRESHOLD)){
TextOut(5,LCD_LINE2,"Sensores na linha preta");
velA = 90;
velB = 90;
TextOut(5,LCD_LINE3,"vel 100");
}
segueRota();
}
}
terça-feira, 28 de setembro de 2010
Comunicação
Olá!
Como previsto nas regras do programa Resgate Marte é necessário que o robô trabalhe tanto como escravo (recebe as informações do seu mestre e age conforme solicitado) e como mestre(envia dados par ao escravo). Assim precisamos de um modo de comunicação padrão (protocolo de comunicação) entre os dois programas (robôs). Como o CLP da MindStorms já possui um módulo Bluetooth, nós desenvolvemos um protocolo simples para comunicação dos robôs.
Vale ressaltar que apenas UM dos robôs serão da nossa equipe (ora ele será mestre, ora será escravo), ou seja, o protocolo tem que ser igual para todas equipes. Assim que testarmos e terminarmos o nosso protocolo estaremos disponibilizando para as outras equipes como sujestão a ser seguida para a padronização.
Basicamente, durante o percurso, o mestre ficará parado na área de resgate dos astronautas apenas informando ao escravo para que ele inicie o processo de captura e repita a ação quando resgatar cada astronauta.
Já já postaremos nosso programa revisado para vocês.
See ya.
Como previsto nas regras do programa Resgate Marte é necessário que o robô trabalhe tanto como escravo (recebe as informações do seu mestre e age conforme solicitado) e como mestre(envia dados par ao escravo). Assim precisamos de um modo de comunicação padrão (protocolo de comunicação) entre os dois programas (robôs). Como o CLP da MindStorms já possui um módulo Bluetooth, nós desenvolvemos um protocolo simples para comunicação dos robôs.
Vale ressaltar que apenas UM dos robôs serão da nossa equipe (ora ele será mestre, ora será escravo), ou seja, o protocolo tem que ser igual para todas equipes. Assim que testarmos e terminarmos o nosso protocolo estaremos disponibilizando para as outras equipes como sujestão a ser seguida para a padronização.
Basicamente, durante o percurso, o mestre ficará parado na área de resgate dos astronautas apenas informando ao escravo para que ele inicie o processo de captura e repita a ação quando resgatar cada astronauta.
Já já postaremos nosso programa revisado para vocês.
See ya.
Mecânica e Imagens
Olá!
Vejam como ficaram os acoplamentos das esteiras e a instalação do CLP. Tentamos manter-lo sempre ao centro da estrutura do robô devido a sua massa ser maior que as outras estruturas, fazendo com que a futura adição da garra+sensores de toque+ultrassom não alterassem significativamente em seu centro de massa, o que faria com que o robô tendesse a "capotar" nas curvas e rampas.
Vejam como ficaram os acoplamentos das esteiras e a instalação do CLP. Tentamos manter-lo sempre ao centro da estrutura do robô devido a sua massa ser maior que as outras estruturas, fazendo com que a futura adição da garra+sensores de toque+ultrassom não alterassem significativamente em seu centro de massa, o que faria com que o robô tendesse a "capotar" nas curvas e rampas.
 |
| Detalhe da Esteira |
 |
| Vista Frontal c/ Sensores de Luz acoplados |
Novidades na mecânica
Olá Pessoal!
Estamos caminhando com o nosso Robô!
Depois de alguns testes acabamos reforçando a idéia da tração ser traseira e com esteiras com três pontos de apoio. Essa decisão se deu ao fato de as rodas serem mais pesadas, maiores e pouco eficientes quando o robô passava do plano inclinado para um outro horizontal.
Com a reinstalação das esteiras sugiu um novo problema; o terceiro ponto de apoio.
Precisávamos colocar o 3º ponto de apoio para que a mesma ficasse tracionada independentemente do terreno, mas depois de alguns ajustes conseguimos adequar o famigerado com uma roda sem tração motora.
Até!
Estamos caminhando com o nosso Robô!
Depois de alguns testes acabamos reforçando a idéia da tração ser traseira e com esteiras com três pontos de apoio. Essa decisão se deu ao fato de as rodas serem mais pesadas, maiores e pouco eficientes quando o robô passava do plano inclinado para um outro horizontal.
Com a reinstalação das esteiras sugiu um novo problema; o terceiro ponto de apoio.
Precisávamos colocar o 3º ponto de apoio para que a mesma ficasse tracionada independentemente do terreno, mas depois de alguns ajustes conseguimos adequar o famigerado com uma roda sem tração motora.
Até!
Assinar:
Postagens (Atom)