LusoRobótica - Robótica em Português
Robótica => Projectos de robótica => Tópico iniciado por: edeweld em 24 de Fevereiro de 2017, 16:07
-
Boas,
Alguém já trabalhou com estes QTR? https://www.pololu.com/product/960 (https://www.pololu.com/product/960)?
Estou a ter problemas com a leitura de linha preta! Ora lê como não lê....
Sugestões?
-
Só com os sensores em si(TCRT5000), e são basicos de usar, provavelmente estás a usar a biblioteca da Polulu e não estás a fazer a calibração..
-
Só com os sensores em si(TCRT5000), e são basicos de usar, provavelmente estás a usar a biblioteca da Polulu e não estás a fazer a calibração..
Exacto. Ando a procura de conseguir fazer isso! Mas ando perdido na documentação...
-
Estou a usar isto:
#include <QTRSensors.h>
#define NUM_SENSORS 6 // number of sensors used
// sensors 0 through 5 are connected to analog inputs 0 through 5, respectively
QTRSensorsAnalog qtra((unsigned char[]) {0, 1, 2, 5, 6, 7},
NUM_SENSORS);
unsigned int sensorValues[NUM_SENSORS];
void setup() {
for (int i = 0; i < 40; i++) // make the calibration take about 10 seconds
{
qtra.calibrate(); // reads all sensors 10 times at 2.5 ms per six sensors (i.e. ~25 ms per call)
}
}
void loop() {
qtra.calibrate(); // reads all sensors 10 times at 2.5 ms per six sensors (i.e. ~25 ms per call)
}
Mas obtenho o mesmo cenário!
-
E o resto do programa? Onde é que estás a fazer a leitura?
A calibração deve ser feita antes de começar as leituras, no mesmo programa. Ela não fica guardada entre programas diferentes (será esse o teu erro?).
-
Para já estou a estudar o exemplos básicos, que vem com a própria biblioteca
#include <QTRSensors.h>
// This example is designed for use with six QTR-1A sensors or the first six sensors of a
// QTR-8A module. These reflectance sensors should be connected to analog inputs 0 to 5.
// The QTR-8A's emitter control pin (LEDON) can optionally be connected to digital pin 2,
// or you can leave it disconnected and change the EMITTER_PIN #define below from 2 to
// QTR_NO_EMITTER_PIN.
// The main loop of the example reads the raw sensor values (uncalibrated).
// You can test this by taping a piece of 3/4" black electrical tape to a piece of white
// paper and sliding the sensor across it. It prints the sensor values to the serial
// monitor as numbers from 0 (maximum reflectance) to 1023 (minimum reflectance).
#define NUM_SENSORS 6 // number of sensors used
#define NUM_SAMPLES_PER_SENSOR 4 // average 4 analog samples per sensor reading
#define EMITTER_PIN 2 // emitter is controlled by digital pin 2
// sensors 0 through 5 are connected to analog inputs 0 through 5, respectively
QTRSensorsAnalog qtra((unsigned char[]) {0, 1, 2, 3, 4, 5},
NUM_SENSORS, NUM_SAMPLES_PER_SENSOR, EMITTER_PIN);
unsigned int sensorValues[NUM_SENSORS];
void setup()
{
delay(500);
Serial.begin(9600); // set the data rate in bits per second for serial data transmission
delay(1000);
}
void loop()
{
// read raw sensor values
qtra.read(sensorValues);
// print the sensor values as numbers from 0 to 1023, where 0 means maximum reflectance and
// 1023 means minimum reflectance
for (unsigned char i = 0; i < NUM_SENSORS; i++)
{
Serial.print(sensorValues[i]);
Serial.print('\t'); // tab to format the raw data into columns in the Serial monitor
}
Serial.println();
delay(250);
}
Mas o resultado é sempre o mesmo:
....
1009 994 985 979 1023 1023
1002 980 966 955 1023 1023
1005 986 973 962 1023 1023
1007 991 981 973 1023 1023
1004 986 974 965 1023 1023
1003 983 969 959 1023 1023
1005 987 974 964 1023 1023
1008 992 982 975 1023 1023
1002 980 966 955 1023 1023
1004 985 972 961 1023 1023
1008 993 983 976 1023 1023
1003 982 969 958 1023 1023
1004 986 972 962 1023 1023
1007 990 978 970 1023 1023
1007 990 979 971 1023 1023
1003 981 968 957 1023 1023
....
Mesmo que mexa os sensores e coloque mais ou menos luz nunca muda muito os valores.
Algum projecto já feito? Ou documentação que possam passar?
Entretanto estou a explorar os tópicos aqui no forum...
-
Para calibrar tens de lhe passar uma folha com uma linha preta.
-
Como desconfiava, nesse programa não chamas a calibração, logo não estás a fazer a mesma!
E já tinha dito isso :)
Com esses valores também me parece que não estavas o suficientemente perto da superfície para os sensores verem o reflexo à volta da linha preta.
Isso, ou confirma as ligações, que o fio que liga do pino 2 (segundo o teu código) ao LEDON e também o GND estão bem ligados.
Se não sabes, os sensores de imagem (camara do telemóvel) conseguem ver um bocado de infravermelho, se encostares a camara a um emissor e estiver ligado vê-se um brilho arroxeado na ecrã. É bom para ajudar a diagnosticar problemas ;)
-
Fazer a calibração é isto? qtra.calibrate();
-
Como o nome bem indica..
E é para estar sempre essa chamada no setup, nunca no loop.
Tal como está nos exemplos da Polulu..
-
Vou ter que continuar a ler a documentação e ver exemplos destes sensores.
Ainda estou muito no início mas pelas conclusões que já fui tirando o sensor nem sempre dá o mesmo valor.
Obrigado
-
Arduino à parte, é possível ler os valores seguindo a lógica do circuito usando um multimetro e uma fonte de 5V, confirma-se o funcionamento dos sensores e a partir daí é apenas código.
Realmente o programa efectua uma calibração em loop, a sequência deveria ser:
Calibração por cada emissor/receptor
Loop de 1 canal
- ligar emissor
- ler receptor
- desligar emissor
- calcular valor com base na calibração
- enviar valor via série
Fim de Loop
Sei que as bibliotecas reduzem muitas destas instruções, o que passa ao lado os pormenores de algo relativamente simples e lá se vai a teoria prás couves.
Ps: Vais fazer um seguidor de linha? Já houveram uns malucos por aqui que se atreveram a fazer :p
-
Arduino à parte, é possível ler os valores seguindo a lógica do circuito usando um multimetro e uma fonte de 5V, confirma-se o funcionamento dos sensores e a partir daí é apenas código.
Realmente o programa efectua uma calibração em loop, a sequência deveria ser:
Calibração por cada emissor/receptor
Loop de 1 canal
- ligar emissor
- ler receptor
- desligar emissor
- calcular valor com base na calibração
- enviar valor via série
Fim de Loop
Sei que as bibliotecas reduzem muitas destas instruções, o que passa ao lado os pormenores de algo relativamente simples e lá se vai a teoria prás couves.
Ps: Vais fazer um seguidor de linha? Já houveram uns malucos por aqui que se atreveram a fazer :p
Estou a programar um robo para esta competição http://roboparty.org/ (http://roboparty.org/)
Já consigo por o bicho a seguir a linha mas o problema é quando chega a uma curva com bastante velocidade. O foto transistor passa na linha mas não dá o valor do preto. Apenas consigo resolver isso se apontar uma luz de lanterna para os sensores. O que concluo que a falta ou excesso de luz ambiente altera o desempenho dos mesmos!
-
Se ignora as curvas é porque o PID não está implementado ou as suas variáveis têm de ser ajustadas.
De qualquer forma o robot tem de varrer a linha preta na calibração para registar os valores extremos dos sensores, a luz ambiente também influencia pelo que os sensores deverão estar a cerca de 1cm da pista e de preferência com isolamento para evitar luz externa.
-
Se ignora as curvas é porque o PID não está implementado ou as suas variáveis têm de ser ajustadas.
De qualquer forma o robot tem de varrer a linha preta na calibração para registar os valores extremos dos sensores, a luz ambiente também influencia pelo que os sensores deverão estar a cerca de 1cm da pista e de preferência com isolamento para evitar luz externa.
PID ainda não percebo o suficiente. Mas é um assunto que tenho que estudar. Tenho andado a ver vários tutoriais e artigos sobre projectos parecidos e tenho tirado várias conclusões. Alguns utilizam PID outros não. Marrão como sou, construi o código, ou melhor, vários códigos para ele seguir a linha. Conclusão, neste momento estou a "bater" nesta questão de luminosidade e na dificuldade em que o pic tem em processar toda a informação quando a velocidade aumenta. Mas já consigo colocar o robo a varrer a linha toda, o problema é que anda muito lentamente e via a snifar a linha toda.
Mas vou continuar a estudar e talvez até comece a construir um robo! :) Para já o que prende são os $$$$
-
O teu problema para o robótica estar sempre a "snifar" a linha toda (oscilação muito grande no loop de controlo) é k o código está muito cru e não responde com a rapidez suficiente (been there done that). Tens de melhorar a resposta desse código, vais ver que não é difícil e que o resultado é bom.
Basicamente tens de transformar as saídas do sensor numa variável única para depois comparares com o que consideras o valor central (setpoint) e obteres o erro, é esse erro que terás de aplicar à fórmula do PID para obteres a saída para os motores, para facilitar a introdução usa apenas a parte proporcional e já terás um resultado aceitável.
-
Bem dito, usando apenas a proporcional já se consegue bom resultado.
O que fiz no meu foi registar a direcção em que fazia a curva, assim se não consegui-se fazer a tempo e já sem linha, continuava a curvar.
http://pdropes.blogspot.pt/2016/09/seguidor-de-linha.html?m=1
-
Sim, estou a ver que a solução passa mesmo pelo PID. Estive a experimentar se funcionava sem PID, mas os resultados são sempre aos solavancos, fica uma coisa muito bruta!
Já estive a ler documentação sobre PID e parece-me uma coisa bonita mas ao mesmo tempo bastante complexa ;D
-
"Entender"* PIDs são duas semestrais da faculdade...
* - Como todas as cadeiras, vai da capacidade do professor e do interesse do aluno. Como todas dá para passar na base do marranço sem preocupação em aprender(ou em ensinar)
-
"Entender"* PIDs são duas semestrais da faculdade...
* - Como todas as cadeiras, vai da capacidade do professor e do interesse do aluno. Como todas dá para passar na base do marranço sem preocupação em aprender(ou em ensinar)
Já tinha percebido isso em relação ao PID. Vejo pessoal a inventar com PID, mas não gosto muito dessa prática. Concordo que no inventar por vezes está a solução, mas grande parte das vezes prefiro ir pelo caminho da lógica e estudo antes de começar a inventar.
Principalmente em programação. Quando começam a inventar tiram-me do sério! "Coloca um ciclo, coloca um array..." Bolas, mas desde de quando é que se consegue programar atirando códigos à sorte!?
-
Vamos lá por partes, primeiro que tudo a aquisição de dados pelo sensor:
- Tens de montar o sensor o mais perto possível da linha, segundo o datasheet no máximo 6mm.
- Tens de ler 8 sinais analógicos.
- Idealmente tens de conseguir comandar os LEDs de forma independente.
- Testa primeiro o sensor fora do robot e ligado a uma porta de série do PC (o Arduíno cria uma virtual sem problemas e podes ler os dados directo na consola sem te chateares), fica aqui o "meu" algoritmo em pseudo-linguagem para obter o sinal "correcto" de um sensor individual:
1. Coloca o sensor em cima do papel mas fora da linha.
2. Lê o sinal analógico do sensor com o led desligado e guarda numa variável;
3. Lê o sinal analógico do mesmo sensor com o led ligado e guarda o valor noutra variável;
4. Subtrai as duas variáveis, assim tens um resultado sem contar com a interferência da luz ambiente, este valor com alguma margem adicionada será o valor zero;
5. Repete tudo com o sensor em cima da linha para teres o valor um.
-
Já tinha percebido isso em relação ao PID. Vejo pessoal a inventar com PID, mas não gosto muito dessa prática. Concordo que no inventar por vezes está a solução, mas grande parte das vezes prefiro ir pelo caminho da lógica e estudo antes de começar a inventar.
Então nunca na vida vais usar PIDs :D
Entender PIDs é mais por desenvolvimento pessoal do que para poder usar os mesmos.
A forma de determinar os parámetros é quase sempre com base em receitas pré-estabelecidas do género, mete assim, faz isto, se deu aquilo muda para assado, sem ter de fazer comboios de equações diferenciais com termos impossíveis de determinar! E nem podia ser de outra forma, senão perdia-se uma ferramenta de controlo extremamente útil! Ou então carrega-se no botão "Autotune" :)
Em engenharia nem tudo é determinístico, tens de ter uma dose de intuição que vais desenvolvendo com o tempo e experiência. Muitas vezes não há uma solução ótima, mas muitas soluções aceitáveis e nenhuma claramente melhor que as outras. Podes passar horas a otimizar um circuito, código ou uma PCB que chegas ao fim e faz exatamente o mesmo. Com a experiência esse tempo vai-se tornando cada vez mais útil para outras coisas. Ou então tens que cumprir um orçamento ou entregar num prazo, e se não segues uns atalhos não duras muito tempo.
-
"Entender"* PIDs são duas semestrais da faculdade...
* - Como todas as cadeiras, vai da capacidade do professor e do interesse do aluno. Como todas dá para passar na base do marranço sem preocupação em aprender(ou em ensinar)
Já tinha percebido isso em relação ao PID. Vejo pessoal a inventar com PID, mas não gosto muito dessa prática. Concordo que no inventar por vezes está a solução, mas grande parte das vezes prefiro ir pelo caminho da lógica e estudo antes de começar a inventar.
Principalmente em programação. Quando começam a inventar tiram-me do sério! "Coloca um ciclo, coloca um array..." Bolas, mas desde de quando é que se consegue programar atirando códigos à sorte!?
E PID para o que vais fazer, e em código é uma dúzia de linhas de código e o inventar é fazer escalamento do input e do output, e ter jeito para afinar o P, I e D.
Se chamas a isso inventar com pid, também andas a inventar com um atmega porque estás a atirar código para cima sem saber bem o que ele faz, e estás a começar a casa pelo telhado...
Se ainda não tens dados confiáveis dos sensores como é que queres testar os teus algoritmos se nem sabes se o robot está a "ver" o mundo como tu achas que ele devia estar?