LusoRobótica - Robótica em Português
Sistemas específicos => Arduino / AVR => Tópico iniciado por: Ricardo em 10 de Março de 2010, 18:27
-
Tenho estado a trabalhar num projecto pessoal que consiste num veículo semi-autónomo. O chassis é o da Polulu que comprei na loja da lusorobotica, e o controlador é um arduino duemilanove com um motor shield em cima.
A razão pela qual eu o chamo de semi-autónomo é porque quero transferir grande parte da lógica para um PC, que depois enviará as ordens ao veículo, mantendo ainda assim alguma autonomia que permita ao veículo circular mesmo sem a ajuda do PC.
Como tenho mais do que uma placa arduino (na verdade tenho um duemilanove, um roboduino e um arduino nano), já consegui alguns resultados utilizando transmissores/receptores de 315Mhz que adquiri no ebay, cujo alcance e eficiência me surpreenderam pela positiva.
Os testes que tenho feito envolvem, resumidamente, num lado uma pequena aplicação em vb.net, que comunica via série para um arduino nano ligado a um emissor RF, no outro lado um chassis com um arduino duemilanove, com um motor shield e um receptor RF, que recebe as ordens para o movimento dos motores.
Como ainda estou a dar os primeiros passos nesta área da robótica, têm-se levantado algumas questões sobre as quais pedia ajuda aos mais experientes neste assunto.
Acredito que uma parte do problema esteja no código (já há muito tempo que trabalho em VB, em detrimento do C que desde o tempo da faculdade quase não toco), até porque neste momento as ligações e os componentes estão reduzidos ao mínimo.
Assim sendo, entre outras questões que também tenho, pergunto:
1- Qual é a “função” dos delays dentro dos loops? Eu percebo o que fazem, mas são sempre necessários? E o tempo de delay deve depender de algum factor em particular? É que com todos os delays dos vários códigos e dos vários arduinos, acabo por ter demasiado desfasamento entre a ordem dada no PC e a resposta do veículo. E se elimino estes delays (ou se coloco valores muito baixos) passo a ter comportamentos muito estranhos quer no emissor, quer no veículo.
2- O facto de ter o arduino com um motor shield alimentado por 6 pilhas AA, implica algum cuidado no código? Digo isto porque, mesmo quando os valores recebidos estão correctos (uso um terceiro arduino com um lcd shield para o comprovar), o veículo parece ficar “bloqueado” com uma determinada leitura, e não pára!
3- Qual é a forma mais eficiente de enviar informação do VB.net para o Arduino via porta série? Já vi vários exemplos e o código que uso actualmente obriga-me a usar um timer com pelo menos 200 ms de delay, pois de outra forma o arduino “atrapalha-se” com os dados que lhe mando (acredito que esteja relacionado com o problema da 1ª questão…)
Assim que conseguir, coloco aqui algumas imagens do layout, e os códigos que utilizo.
Qualquer observação será bem vinda!
-
1- Qual é a “função” dos delays dentro dos loops? Eu percebo o que fazem, mas são sempre necessários? E o tempo de delay deve depender de algum factor em particular? É que com todos os delays dos vários códigos e dos vários arduinos, acabo por ter demasiado desfasamento entre a ordem dada no PC e a resposta do veículo. E se elimino estes delays (ou se coloco valores muito baixos) passo a ter comportamentos muito estranhos quer no emissor, quer no veículo.
No que toca a comunicação, tens de ter uma periodicidade de envio da informação. Isso é uma forma de garantir a integridade dos dados que recebeste, bem como detectar se os estás a receber ou não.
Esta periodicidade é dada pelos delays...
2- O facto de ter o arduino com um motor shield alimentado por 6 pilhas AA, implica algum cuidado no código? Digo isto porque, mesmo quando os valores recebidos estão correctos (uso um terceiro arduino com um lcd shield para o comprovar), o veículo parece ficar “bloqueado” com uma determinada leitura, e não pára!
Isso parece-me ser um erro de programação ou ligações.
A única coisa que tens de ter em atenção é os sinais que estás a mandar para o Circuito Integrado que controla os motores. Normalmente funcionam por PWM, ou seja, tens de ligar a um pino PWM do Arduino para lhe dares a intensidade dos motores. Talvez te tenhas enganado a ligar isso num pin k nao é PWM.
3- Qual é a forma mais eficiente de enviar informação do VB.net para o Arduino via porta série? Já vi vários exemplos e o código que uso actualmente obriga-me a usar um timer com pelo menos 200 ms de delay, pois de outra forma o arduino “atrapalha-se” com os dados que lhe mando (acredito que esteja relacionado com o problema da 1ª questão…)
Isso depende muito do tipo de comunicação que estás a usar.
Ainda não percebi se por RF estás a usar módulos RF 433MHz, ou se te referes a "comunicação sem fios".
-
Ora aqui estão algumas imagens do que tenho até agora
O emissor:
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.iznogud.com%2Fimagens%2FP1090077-p.jpg&hash=83ebb24044627e70db68ae19f51384a4b1842f6b)
O veiculo com o receptor:
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.iznogud.com%2Fimagens%2FP1090080-p.jpg&hash=e32018c4794082a57cd8bf7a92111f8ce8acbc6b)
O receptor extra para teste:
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.iznogud.com%2Fimagens%2FP1090078-p.jpg&hash=d04c0fd2182ca6b0b3a48e091c51cf994eda7cdf)
A app VB.Net simplificada tem este aspecto:
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.iznogud.com%2Fimagens%2Fcontrol.net%25201.0.png&hash=79f8390966ca9bfd9ff8d74d0805f514bff0f2a7)
E resume-se, para já, ao envio do valor da caixa de texto num intervalo definido pelo temporizador (normalmente 500ms), resumidamente:
SerialPort1.WriteLine("^" & valor.Text & "$")
Este valor é a direcção e a velocidade dos motores esquerdo e direito.
-
O código dos dois arduinos emissor e receptor, respectivamente:
#include <VirtualWire.h>
#undef int
#undef abs
#undef double
#undef float
#undef round
#define START_COLOR_CHAR '^'
#define END_COLOR_CHAR '$'
#define COLOR_SIZE 12
char serialMessage[COLOR_SIZE]="F000F000";
boolean readingSerial;
boolean readingSerial2;
unsigned int count;
unsigned int readChar;
void setup()
{
vw_set_ptt_inverted(true);
vw_setup(2000);
vw_set_tx_pin(3);
Serial.begin(2400);
readingSerial = false;}
void serialReadColor() {
readingSerial = true;
count = 0;
iniReading:
if (Serial.available() > 0) {
readChar = Serial.read();
if (readChar == END_COLOR_CHAR || count == COLOR_SIZE) {
goto endReading;
} else {
serialMessage[count++] = readChar;
goto iniReading;
}
}
goto iniReading;
endReading:
readingSerial = false;
}
void loop()
{
readingSerial2 = false;
if (Serial.available() > 0 && !readingSerial) {
if (Serial.read() == START_COLOR_CHAR) {
readingSerial2 = true;
serialReadColor();
}
}
const char *msg;
msg = serialMessage;
vw_send((uint8_t *)msg, strlen(msg));
vw_wait_tx();
Serial.println(msg);
delay(50);
}
#include <VirtualWire.h>
#undef int
#undef abs
#undef double
#undef float
#undef round
int EN1 = 6;
int EN2 = 5; //Roboduino Motor shield uses Pin 9
int IN1 = 7;
int IN2 = 4; //Latest version use pin 4 instead of pin 8
int ledPin = 13;
void Motor1(int pwm, boolean reverse) {
analogWrite(EN1,pwm);
if(reverse) {
digitalWrite(IN1,HIGH); }
else {
digitalWrite(IN1,LOW); }
}
void Motor2(int pwm, boolean reverse) {
analogWrite(EN2,pwm);
if(reverse) {
digitalWrite(IN2,HIGH); }
else { digitalWrite(IN2,LOW); }
}
void setup()
{
Serial.begin(9600);
pinMode(13, OUTPUT);
int i; //
for(i=4;i<=7;i++) //For Roboduino Motor Shield 6-9//
pinMode(i, OUTPUT);
vw_set_ptt_inverted(true);
vw_setup(2000);
vw_set_rx_pin(2);
vw_rx_start();
}
void loop()
{
uint8_t buf[VW_MAX_MESSAGE_LEN];
uint8_t buflen = VW_MAX_MESSAGE_LEN;
char *msg="F000F000";
char de[2]="F";
char dd[2]="F";
char esq[4]="000";
char dir[4]="000";
if (vw_get_message(buf, &buflen))
{
int i;
for (i = 0; i < buflen; i++)
{
Serial.print(buf[ i ]);
msg[ i ]=buf[ i ];
}
Serial.println("");
}
strncpy(de,msg+0,1);
strncpy(esq,msg+1,3);
strncpy(dd,msg+4,1);
strncpy(dir,msg+5,3);
int a,b;
a=atoi(esq);
b=atoi(dir);
if(de[0]=='F')
{
Motor1(atoi(esq),false);
}
else
{
Motor1(atoi(esq),true);
}
if(dd[0]=='F')
{
Motor2(atoi(dir),true);
}
else
{
Motor2(atoi(dir),false);
}
delay(200);
}
-
Está bastante engraçado, a "#include <VirtualWire.h>" é para os módulos?
-
Antes de mais, obrigado pela paciencia e pela resposta rápida!
1- Qual é a “função” dos delays dentro dos loops? Eu percebo o que fazem, mas são sempre necessários? E o tempo de delay deve depender de algum factor em particular? É que com todos os delays dos vários códigos e dos vários arduinos, acabo por ter demasiado desfasamento entre a ordem dada no PC e a resposta do veículo. E se elimino estes delays (ou se coloco valores muito baixos) passo a ter comportamentos muito estranhos quer no emissor, quer no veículo.
No que toca a comunicação, tens de ter uma periodicidade de envio da informação. Isso é uma forma de garantir a integridade dos dados que recebeste, bem como detectar se os estás a receber ou não.
Esta periodicidade é dada pelos delays...
Certo. Uma coisa que me apercebi ao tentar diferentes buad rates, é que os 2400 parecem dar os melhores resultados, mas entrentanto reparei que comando "vw_setup(2000);" estará também a definir a velocidade de comunicação do emissor/receptor. Deverei aqui colocar também os 2400? Numa primeira análise pensei que o facto de ter baixado o baud rate (inicialmente estava em 9600) resultava numa comunicação com menos erros, e por isso, mais eficiente.Agora já não tenho tanta certeza... Esta combinação dos delay com os baud rates não é fácil :)
2- O facto de ter o arduino com um motor shield alimentado por 6 pilhas AA, implica algum cuidado no código? Digo isto porque, mesmo quando os valores recebidos estão correctos (uso um terceiro arduino com um lcd shield para o comprovar), o veículo parece ficar “bloqueado” com uma determinada leitura, e não pára!
Isso parece-me ser um erro de programação ou ligações.
A única coisa que tens de ter em atenção é os sinais que estás a mandar para o Circuito Integrado que controla os motores. Normalmente funcionam por PWM, ou seja, tens de ligar a um pino PWM do Arduino para lhe dares a intensidade dos motores. Talvez te tenhas enganado a ligar isso num pin k nao é PWM.
Penso que aqui não existem grandes problemas. As ligações são simples, baseadas na sua grande maioria em esquemas vistos na net, e o código também é um copy/paste adaptado de outras experiencias. Mas não garanto nada. Já me tinha esquecido da dificuldade que existe em trabalhar strings em C... :)
3- Qual é a forma mais eficiente de enviar informação do VB.net para o Arduino via porta série? Já vi vários exemplos e o código que uso actualmente obriga-me a usar um timer com pelo menos 200 ms de delay, pois de outra forma o arduino “atrapalha-se” com os dados que lhe mando (acredito que esteja relacionado com o problema da 1ª questão…)
Isso depende muito do tipo de comunicação que estás a usar.
Ainda não percebi se por RF estás a usar módulos RF 433MHz, ou se te referes a "comunicação sem fios".
Provavelmente não me expliquei lá muito bem. A comunicação sem fios de que falo é os tais modulos RF que mostrei que trabalham a 315MHz, se não estou em erro. Mas esse é um trabalho do arduino, que recebe a informação do VB.net via usb/serie.
Para já, não estou muito preocupado com eventuais delays entre a ordem e a acção do veiculo, mas quanto menor for este atraso, tanto melhor. Até porque o próximo passo será a incoporação de uma camera wireless no veiculo que irá enviar imagens para o PC e que vai utilizar esta informação para orientar o veiculo.
-
Está bastante engraçado, a "#include <VirtualWire.h>" é para os módulos?
Sim, é a biblioteca para as funções dos modulos rf. A facilidade com que se trabalha com estes módulos extremamente baratos (à volta de 5 euros cada par) é incrivel.
No meu caso, que ainda não domino muito bem o código do arduino, é ótimo resumir a comunição às linhas:
vw_send((uint8_t *)msg, strlen(msg));
vw_wait_tx();
Para além disso, numa casa como a minha, onde o wifi quase que necessita de repetidores de uma divisão para a outra, consigo comunicar via rf de um extremo ao outro da casa, e com uma improvisação de antenas ridicula!
-
Está com bom aspecto. :)
Também estou a fazer um projecto idêntico, mas com servos e a estrutura meia rectangular feita em acrílico. Mas sem ecrã. :)
-
Estás bem encaminhado :) Parece-me que percebes daquilo que falas e tens tudo bem organizado.
Entretanto não percebi em que parte queres ajuda, podes ser mais específico.
Só uma nota: os baudrates foram "standardizados" e deve tentar-se cumprir com esses standards, ou seja, tal como a comunicação por serial só admite aqueles valores que estão na ComboBox da janela Serial do IDE do Arduino, a comunicação sem fios costuma-se usar esses baud-rates. Isto tudo para dizer que 2000 não é um baudrate standard, mas 2400 já é. ;)
-
Estás bem encaminhado :) Parece-me que percebes daquilo que falas e tens tudo bem organizado.
Obrigado, mas... não será assim tanto. :)
A electrónica não é a minha área. Embora a curiosidade já cá esteja ha algum tempo, só com a descoberta do arduino é que consegui por em prática algumas ideias que com os meus parcos conhecimentos pareciam impossiveis.
De qualquer forma tenho vindo a aprender algumas coisas. E este projecto não é mais que uma desculpa para continuar a explorar este mundo.
Só uma nota: os baudrates foram "standardizados" e deve tentar-se cumprir com esses standards, ou seja, tal como a comunicação por serial só admite aqueles valores que estão na ComboBox da janela Serial do IDE do Arduino, a comunicação sem fios costuma-se usar esses baud-rates. Isto tudo para dizer que 2000 não é um baudrate standard, mas 2400 já é. ;)
Vou tentar "sincronizar" todos os valores e ver o que dá.
Entretanto, aproveitando as simpáticas palavras de apoio do forum e o facto do bébé não estar em casa, fiz um teste com a babycam montada em cima do veiculo e consegui circular por toda a casa (até a babycam perder o sinal...) o que comprovou que a resposta do veiculo não está assim tão atrasada.
Outra constatação é de que terei sempre alguma dificuldade com a precisão do movimento, mas tal como disse antes isso também não é problemático.
Logo colocarei aqui a nova versão com as imagens da camera.
Acrescento que inicialmente a ideia é fazer análise de imagem para, numa primeira fase, seguir o movimento, adaptando o que já fiz antes com uma webcam e um sistema pan&tilt e que me pareceu ter grandes potencialidades! :)
Em relação à navegação pela casa, e antes de tentar algumas ideias "radicais" que me passam pela cabeça (!), alguém tem alguma sugestão?
Obrigado!
-
Está com bom aspecto. :)
Também estou a fazer um projecto idêntico, mas com servos e a estrutura meia rectangular feita em acrílico. Mas sem ecrã. :)
Uma das minhas outras "pancadas" é a de tentar trabalhar com acrilico, que me parece um bom material para criar caixas e estruturas personalizadas. Já fiz algumas tentativas, mas ainda não domino a técnica ;)
Acho uma excelente ideia, e tenho a certeza que também irei seguir esse caminho lá mais para a frente. A "base" em breadboards actual foi apenas uma ideia para permitir futuros "upgrades" ao veiculo. :D
Compreendo que com os servos se consegue muito maior precisão sem grande trabalho, mas para já os dc vão servir para os primeiros testes.
E acredito que tem a velocidade necessária para perseguir... o gato... ;D
-
Uma pergunta, a webcam está a transmitir os dados em tempo real para o pc ou armazena-os em algum lado?
-
Uma pergunta, a webcam está a transmitir os dados em tempo real para o pc ou armazena-os em algum lado?
Os dados são trasmitidos em tempo real.
Neste momento não é bem uma webcam, ou melhor, é uma espécie de webcam wireless.
È um babymonitor que está a venda no continente, que tem uma camera com microfone, mas que se liga via wireless a um receptor usb no PC.
É uma solução de recurso uma vez que esta serve para monitorizar o bébé. Ainda assim surpreendeu-me pela positiva, pelo alcance do sinal.
Assim que puder coloco aqui mais umas fotos
-
Só para dar uma ideia do esquema actual ;D
P1090084.MOV (http://www.youtube.com/watch?v=yCvmr8T78J0#)
O próximo passo é colocar uma câmara com o sistema pan&tilt que tenho aqui, controlável também remotamente, e alguns sensores no veículo que impeçam-no de chocar com as coisas (com o sistema de condução remota perde-se muito a sensação de profundidade)
Embora o emissor/receptor rf estejam a responder às necessidades, ainda não sei como irei conseguir enviar informação do veículo para o pc (sem ser a imagem).
Já alguém experimentou utilizar dois pares de emissor/receptor para simular uma comunicação duplex (mesmo que seja só half-duplex)?
-
Os dados são trasmitidos em tempo real.
Neste momento não é bem uma webcam, ou melhor, é uma espécie de webcam wireless.
È um babymonitor que está a venda no continente, que tem uma camera com microfone, mas que se liga via wireless a um receptor usb no PC.
É uma solução de recurso uma vez que esta serve para monitorizar o bébé. Ainda assim surpreendeu-me pela positiva, pelo alcance do sinal.
Assim que puder coloco aqui mais umas fotos
Eu estou a pensar num sistema análogo e andei a ver isso das camaras wireless, essas baby cams têm boa qualidade? É que o que vi de camaras wi-fi era tudo caríssimo, e como sabem o arduino não consegue suportar video ao mesmo tempo do resto das informações todas de sensores e actuadores de modo que fica o Xbee inviabilizado para a camara...
Fico à espera do teu bitaite :P
-
E que tal uma coisa destas: http://www.asynclabs.com/store?page=shop.product_details&flypage=flypage.tpl&product_id=26&category_id=6 (http://www.asynclabs.com/store?page=shop.product_details&flypage=flypage.tpl&product_id=26&category_id=6)
A "desvantargem" é que só dá para utilizar em redes wifi, ou seja, ao ar livre não é a melhor solução. Mas parece-me ser a solução mais poderosa e barata ao mesmo tempo. Só precisas de um módulo, em vez dos dois XBEE.
Eu mandei vir ontem um shield destes, quando chegar posso fazer uma pequena review caso haja interessados ;)
-
Sim fashabor!!
-
E que tal uma coisa destas: http://www.asynclabs.com/store?page=shop.product_details&flypage=flypage.tpl&product_id=26&category_id=6 (http://www.asynclabs.com/store?page=shop.product_details&flypage=flypage.tpl&product_id=26&category_id=6)
A "desvantargem" é que só dá para utilizar em redes wifi, ou seja, ao ar livre não é a melhor solução. Mas parece-me ser a solução mais poderosa e barata ao mesmo tempo. Só precisas de um módulo, em vez dos dois XBEE.
Eu mandei vir ontem um shield destes, quando chegar posso fazer uma pequena review caso haja interessados ;)
Parece prometedor!
Desde cedo que os módulos xbee parecem ser a melhor solução, mas o preço destes são desencorajadores.
Outro sistema que também gostava de experimentar é um que penso que se chama “apc 220”, que embora também seja carote (+-40€), parece ter um excelente alcance (1000m?).
Outra solução será os transcievers que irei experimentar brevemente.
Assim que puderes testar esse shield, explica como se comportaram. Uma vez que a minha casa já está (quase) toda sob cobertura wifi, essa pode ser uma óptima solução.
Entretanto já coloquei um sensor ultrasónico no veículo, que o impede de chocar com os objectos bypassando a ordem dada por RF (particularmente útil quando o condutor fica cego :)). A minha ideia é usar este sensor como um sonar que ajude a criar uma espécie de mapa virtual com base nas leituras que vai fazendo a cada ponto. Falta o modelo matemático… :)
Tenho lido aqui neste fórum (e noutros) algumas experiências para a navegação indoor, e algumas são bem engenhosas (e complicadas). Continuo com a intenção de utilizar algum tipo de processamento de imagem para o veículo saber onde está, e eventualmente, para onde vai, mas esta também não é técnica simples.
Eu estou a pensar num sistema análogo e andei a ver isso das camaras wireless, essas baby cams têm boa qualidade? É que o que vi de camaras wi-fi era tudo caríssimo, e como sabem o arduino não consegue suportar video ao mesmo tempo do resto das informações todas de sensores e actuadores de modo que fica o Xbee inviabilizado para a camara...
Fico à espera do teu bitaite :P
Pelo preço de 90€ (no caso foi metade pois tinha desconto de 45€ no cartão, passe a publicidade…) não me parece nada mal para uma câmara wireless. Embora esta não seja uma verdadeira câmara IP, pois necessita sempre de um PC, mas com uma simples aplicação webcam dá para fazer o que quiseres. Tem alguma dificuldade em passar de zonas claras para zonas mais escuras, mas quando o consegue fazer, os leds infravermelhos são suficientes para ser ver a poucos metros.
Tem microfone (não testei), e pode ser alimentada por pilhas (4xAAA), o que lhe dá algumas horas de autonomia.
Com estas características, e com outros pequenos truques, já consegui guiar o veículo via Internet, estando no trabalho, a alguns Km de distância de casa. Até a câmara ficar sem pilhas…
Surpreendentemente, o arduino ligado a 6xAA, aguenta muitas horas à escuta (sem qualquer truque de sleep), e com algum movimento esporádico.
-
Boas!
Após algum tempo de muito trabalho e pouco tempo livre, lá consegui brincar mais um pouco com o meu projecto.
Os componentes originais sofreram algumas alterações mas a ideia continua a ser mais ou menos a mesma. Um veículo comandado por radiofrequência, mas com um PC a auxiliar na navegação.
Uma das alterações do projecto inicial foi a utilização de algumas peças de acrílico para dar alguma rigidez ao "chassis" :)
Devido a algumas contas mal feitas ?, a localização actual dos componentes está definitivamente condenada ao fracasso, mas enquanto não preparo uma segunda versão, vai servindo de protótipo as outras ideias.
Já coloquei o mini-servo para o sensor ultra-sónico (urm37), substitui o conjunto emissor/receptor rf por um apc220 conseguindo assim comunicação duplex e eliminando ao mesmo tempo a necessidade der ocupar um arduino no PC para a transmissão, uma vez que os módulos apc vêm em pares e com um adaptador usb para o pc.
Também substituí o duemilanove por um romeo all-in-one, e finalmente comprei um compass module (HMC6352).
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.iznogud.com%2Fimagens%2Fimag0454.jpg&hash=1eaa63687e277ae9f5c8687d351720bc2f53c2e8)
Após alguns testes, e com o “sonar” ainda meio desafinado e algumas alterações na aplicação VB.net, tenho este resultado:
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.iznogud.com%2Fimagens%2Fcontrol.net%25201.1.png&hash=98afa24d3cad766a22c6f557897b157564086e0c)
A ideia é fazer várias leituras pela casa, de forma a criar uma “impressão digital” única de cada ponto fazendo alguns cálculos com a orientação (e por isso o compass module), e com a distância relativa.
Se a isto conseguir juntar a imagem da câmara wireless (que neste momento não está instalada) já deveria ter bastantes dados para trabalhar… mas é tudo muito teórico ainda…
Entretanto a base da polulu está a desviar ligeiramente para um lado, mesmo quando aplico a mesma força nos dois motores… ainda não percebi onde está o problema, mas isso fez-me reconsiderar a necessidade de precisão no movimento.
Alguém me sabe explicar como fazer uma leitura das rotações de cada motor, utilizando o “buraco” que existe na roda dentada de cada motor?
-
Para além do robot, a tua aplicação tem muito bom aspecto.
Como é que desenhaste o "radar" à direita? Qual o objecto que utilizaste?
-
Não encontrei informação sobre os módulos apc220 :S
Outra,se pudesses podias ir editando o primeiro post para acrescentar detalhes da evolução do projecto :) Colocando por exemplo links para os pots onde vais mostrando a evolução do projecto por exemplo.
-
Para além do robot, a tua aplicação tem muito bom aspecto.
Como é que desenhaste o "radar" à direita? Qual o objecto que utilizaste?
A aplicação está toda em VB.net usando as bibliotecas comuns do vb. No fundo não é mais do algumas linhas e elipses que vão sendo criadas à medida que o sensor roda e envia a nova leitura. É tudo muito artesanal, com alguma trignometria à mistura ;D, mas posso sempre criar uma dll com aquilo, se ajudar alguém. :o
Já estou a alterar o desenho inicial para criar um "radar" de 360º, usando o compass module para orientar a posição das leituras.
Também utilizo uma classe (icam.vb) que fui buscar a um site e que agora não me lembro do autor (assim que souber, ponho aqui o link), mas para a captura da imagem da webcam.
O resto são as bibliotecas do opencv para análise da imagem, que ainda não está implementado.
-
Não encontrei informação sobre os módulos apc220 :S
Os módulos de que falo são estes:
http://www.yerobot.com/apc220-radio-communication-module.html (http://www.yerobot.com/apc220-radio-communication-module.html)
Para quem anda a evitar gastar muito dinheiro em xbees e afins, e embora não sejam particularmente baratos parecem-me bastante bons (excelente alcance!) faceis de trabalhar (comunica-se como se fosse a porta série), e o romeo já tem o local reservado para o múdulo. O único problema ainda é ter que montar e desmontar o modulo cada vez que quero fazer um novo upload... :P
Outra,se pudesses podias ir editando o primeiro post para acrescentar detalhes da evolução do projecto :) Colocando por exemplo links para os pots onde vais mostrando a evolução do projecto por exemplo.
Certo. Vou tentar fazer isso!
-
Este módulo realmente parece muito apetecível! O preço em relação a 2 Xbees mais os shields compensa imenso...
Falaste que vêm logo dois, ficas com um ligado directamente por USB ao pc e o outro as entradas tx e rx do arduino?
Para ligar directamente ao pc como é?
-
...
Falaste que vêm logo dois, ficas com um ligado directamente por USB ao pc e o outro as entradas tx e rx do arduino?
Para ligar directamente ao pc como é?
Sim, vem em pares (são duas placas exactamente iguais, que no meu caso até vinha "coladas" uma à outra) sendo que uma delas liga-se a um "adpatador" usb.
(https://lusorobotica.com/proxy.php?request=http%3A%2F%2Fwww.iznogud.com%2Fimagens%2Fimag0458.jpg&hash=955d34459fc424b42fa51e3330f7b244ae5c8d4e)
Basta usar os drivers ftdi e a placa do PC é vista como mais uma porta série.
-
E que tal o resultado destes módulos? Alcance? Erros? São fáceis de usar?
-
Se realmente funcionam a essa distancia têm essa vantagem em relação aos Xbee do mesmo preço assim como poder trazer já um módulo para ligar ao PC. Agora também é mais lento que os Xbee.
-
E que tal o resultado destes módulos? Alcance? Erros? São fáceis de usar?
Para já apenas experimentei em casa sendo que a distancia máxima não terá ultrapassado os 15 metros. No entanto, como pelo meio existem várias paredes, e mesmo o wifi tem dificuldade em chegar aos pontos mais afastados, fiquei bem impressionado com a “qualidade” do sinal (não é uma medição experimental, é mais uma constatação “visual”). Nos testes onde envio cerca de 170 leituras sequencialmente (cada uma corresponde a um ângulo do servo) não tive qualquer perda de valores.
Quanto à facilidade, é como já disse antes. É como se utilizássemos uma vulgar comunicação serial. Nem sequer é necessário utilizar nenhuma biblioteca extra no código. È tão simples como fazer um Serial.print ou um Serial.read.
Neste fim-de-semana vou tentar testa-lo em espaço aberto e tentar aferir o alcance real.
Em relação à velocidade de transmissão, os 9600 parecem-me suficientes. Pela minha (pouca) experiência, os problemas começam quando se quer processar toda a informação que se recebe e envia para o arduino. Valores de bps muito altos “entopem” o código todo… mas acredito que o problema também esteja nesse mesmo código.
Se quiserem que eu faça algum tipo de teste específico digam.
Um dia destes faço uma análise comparativa dos emissores/receptores rf que fui testando até chegar a estes. Sim, porque embora não tenha gasto os 100€ que custariam o par de xbees, com os shields, gastei quase o mesmo com as várias opções mais baratas que fui comprando :P
-
Sim, para uns equivalentes bem que precisavas de 100€.