Veículo semi-autónomo RF

[Ricardo]

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!

[microbyte]

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".

[Ricardo]

Ora aqui estão algumas imagens do que tenho até agora

O emissor:


O veiculo com o receptor:


O receptor extra para teste:


A app VB.Net simplificada tem este aspecto:


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.

[Ricardo]

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);
}

[metRo_]

Está bastante engraçado, a "#include <VirtualWire.h>" é para os módulos?

[Ricardo]

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.

[Ricardo]

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!

[n3lThon]

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ã.

[microbyte]

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á é.

[Ricardo]

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!

[Ricardo]

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. 

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... 

[VascoP]

Uma pergunta, a webcam está a transmitir os dados em tempo real para o pc ou armazena-os em algum lado?

[Ricardo]

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

[Ricardo]

Só para dar uma ideia do esquema actual 
 

P1090084.MOV	Small | Large

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)?

[VascoP]

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