Meu Simples Controle de posição com o PIC12F675

[MOR_AL]

Olá Carmo Munhoz.
Apesar de cadastrado já há algum tempo, seja bem-vindo às participações com postagens.
Pelas suas colocações, você deveria participar mais. Achei-as interessantes e gostaria de comentá-las:
Antes, porém, apresento minhas diretivas para este projeto. Elas limitam o uso de muitas opções... Eu tinha que partir de algum ponto!

0 – Projeto puramente didático. A intenção é mostrar que é possível fazer muito com pouco.
1 – Usar um dos mais simples PIC’s, o PIC12F675, com 8 pinos, frequência de oscilação interna (4Mc/s) e sem PWM.
2 – Variáveis com apenas um byte e, no máximo, com mais um bit para o sinal. A consequência é que o CAD possui 8 bits de resolução, e a fonte de referência tem que ser apropriada.
3 – Sistema com realimentação negativa, abrangendo o maior loop possível, evitando medidas indiretas.
4 – Usar o mínimo de hardware possível.
5 – Redução de custos, empregando componentes disponíveis em minha casa.

Consequentemente, este encoder forneceria uma resolução de 1,2401mm

É um bom valor. Meu potenciômetro possui cerca de 300mm de comprimento, o que dá uma resolução de 300mm / 255 faixas = 1,18mm de resolução.
Esta opção vai de encontro às diretivas 1 (só disponho de uma entrada para medir a posição do carrinho, pois a outra será usada para medir o ângulo do pêndulo) e 3 (a realimentação é indireta. Não mede a posição do carrinho e sim o ângulo do eixo do motor. Certamente que a mecânica de polia e correia com dentes é quase que imune a deslizes. Sob este aspecto seria uma boa idéia, transferindo a conexão do fio central do potenciômetro, com a informação da posição, para um local fixo, o que não ocorre com a minha opção).

Teria que levar também em consideração que, no start, o carrinho deverá procurar pela posição de referência e ...

Do modo que está, o sistema mede e tenta corrigir a posição do carrinho, cerca de 2000 vezes por segundo, com a medição diretamente no carrinho. Poderia ter esta mesma taxa com a sua opção, caso não retornasse o carrinho ao “zero” para ter a certeza da posição. Para esta certeza, devo aceitar que a mecânica de acoplamento não dê problemas. Apesar de ser quase certo que não dará, ainda fica a falta de certeza.

MOR_AL

[guest2003]

Apesar de eu entender que não é a intenção do MOR_AR usar o encoder, queria apenas deixar uma sugestão para resolver o problema de se usar um encoder simples e barato (mouse) e aumentar a resolução dele...

Ao invez de acoplar diretamente no eixo do motor, pode-se fazer o acoplamento com 2 polias, com diametros digamos 5x diferentes... uma com 1cm e a outra com 5cm de diametro... com isso você aumentaria a resolução do encoder em 5 vezes ! por exemplo iria de 1.24mm para 0.248mm !!

[]'s

[Carmo Munhoz]

Obrigado pelas Boas Vindas

Vamos lá:
Um encoder se enquadra nas diretivas:
0 - pelo reaproveitamento de material disponível ou de baixo custo (mouse)
2 - apesar de resolução, o PIC pode ler e armazenar apenas os 8 MSb
3 - seria por posição relativa e não absoluta
4 - esta seria questionável
5 - custo zero se você tiver um mouse sucateado, aliás, se não tiver, o vizinho tem, ou o primo, ou ...

A única diretiva totalmente fora é a 1. Um encoder usará, pelo menos, 1 I/O a mais que o potenciômetro e provavelmente o 12F675 não teria I/O's suficientes

Uma outra sugestão, que melhora a diretiva 3, mas continua com as mesmas limitações, seria utilizar uma régua escolar transparente fixa na carcaça e com o conjunto de IR preso no carrinho, mas isso fica pra próxima.

Com relação à posição zero (referência) só é necessário chegar até ela no Power On. A partir daí atribui-se zero à variável posição, mede-se os deslocamentos e atualiza-se esta variável. A qualquer momento essa variável pode ser usada para se obter a posição do carrinho.

Caso algum dia você precisar usar encoder para posicionamento, já vou te passar uma dica: ligue os sinais do encoder em interrupções por mudança de estado. Se fizer a leitura fora das interrupções correrá um grande risco de perder algum pulso. É claro que isso não irá acontecer se a frequencia máxima dos pulsos for bem baixa.

Aproveitando pra comentar a sugestão do guest2003:
Pelo que eu entendi, você sugeriu que o eixo do encoder seja ligado ao eixo do motor através de engrenagens que façam a rotação do eixo do encoder ser mais alta que a do motor.
Eu vejo aqui 2 situações a serem verificadas.
A primeira seria a folga natural de acoplamento mecânico que deverá ser minimizada.
A segunda, deve-se verificar a velocidade máxima do encoder pra não perder nenhum pulso.


Abraços

[MOR_AL]

Guest2003.

A parte mecânica desta opção é mais trabalhosa. As polias e correia são difíceis de se obter. Duas engrenagens dentadas também. Acertar o diâmetro dos furos para o eixo, fixação dos eixos, etc. O encoder exige mais uma entrada, que não disponho.

Carmo Munhoz

Vamos lá:
Um encoder se enquadra nas diretivas:
0 - pelo reaproveitamento de material disponível ou de baixo custo (mouse) (ok!)
2 - apesar de resolução, o PIC pode ler e armazenar apenas os 8 MSb (ok!)
3 - seria por posição relativa e não absoluta (medida indireta)
4 - esta seria questionável (ok!)
5 - custo zero se você tiver um mouse sucateado, aliás, se não tiver, o vizinho tem, ou o primo, ou ... (ok! Acrescentar uma mecânica móvel é que é o problema.)

A única diretiva totalmente fora é a 1. Um encoder usará, pelo menos, 1 I/O a mais que o potenciômetro e provavelmente o 12F675 não teria I/O's suficientes (ok!)

Finalizando:
Realmente um encoder poderia ser usado e muito já foi exposto aqui sobre o assunto. Além do fato de que este detalhe já se encontrar resolvido. Devo agora me concentrar nos ítens que faltam resolver, até alcançar o meu objetivo.
Quando tiver alguma coisa pronta voltarei ao assunto.
Agradeço a todos pelas colaborações.
Abraços.
MOR_AL