QTR 8A - Polulu

[artur36]

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.

[dropes]

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

[edeweld]

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 

[jm_araujo]

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

[edeweld]

"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!?

[artur36]

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.

[jm_araujo]

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

[senso]

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