Pessoal,

Estou construindo encoder´s IR para medição de rotação de dois micro-motoredutores de um robô de duas rodas.
Estou a meses me debatendo com interrupções indevidas geradas no Arduino.

O projeto:

A leitura é feita nas rodas, através de codewheel impresso em laser.
Estou utilizando o TCRT5000 (pack reflexivo) para os sensores. Com eles consigo um sinal senoidal bastante boa, quase perfeita, oscilando aproximadamente entre 0,4 e 3,9 volts. A frequência é baixa (1 a 20 Hz).

O sinal gerado pelo Receptor do TCRT passa por um Schmitt Trigger (74HC14) e a onda quadrada gerada vai para o pino do Arduino.

O problema é na leitura do tempo entre pulsos no Arduino.

Utilizando "pooling" (lógica no loop()) não ocorrem problemas e consigo obter a leitura necessária, embora a técnica deixe a desejar em performance geral do robô.

Utilizando interrupção Externa ocorre detecção de interrupções indevidas. Utilizando interrupção Pin Change, a quantidade é menor, mas também ocorrem.

Porque interrupções Indevidas ?

Bem, com esse problema eu acabei comprando um Osciloscópio USB (20 MHz) e consigo com ele detectar que nos
momentos em que não há transição de estado no pino do Arduino ocorre interrupção mesmo assim, às vezes duas em um meio período do sinal.

Já utilizei várias técnicas para delimitar esse problema, sendo a mais simples e direta (na minha opinião) a seguinte:


. Na rotina de interrupção (ISR) eu apenas inverto a condição de uma variável booleana.
. No loop() eu analiso esta variável e aciono ou não uma saída digital do Arduino descarregando ao GND através de um resistor de 10k. Leio a forma de onda deste pino com o osciloscópio.

Assim consigo comparar o sinal gerado pelo TCRT, na saída do 74HC14, na entrada do pino de interrupção do Arduino e nesta saída digital que representa a informação houve ou não interrupção.

Só ocorre problema detectável - por esse osciloscópio - nesta saída digital! Todos os demais sinais estão conforme esperado.

Já utilizei direto no robô e em protoboard, Arduinos Uno, Nano e Mega. Todos apresentam o mesmo problema.
Já utilizei sensores IR como o TCRT, bem como TIL´s e uma Chave (de interrupção do feixe).
Já utilizei cabo blindado entre a placa de IR e o Arduino, com capacitor de 100nF e até 1uF descarregando o sinal no GND e nada. No caso do uso de capacitores, ocorre um pequeno arredondamento da forma de onda, mas continua sendo detectado normalmente pelo Arduino.

Considerando que o problema seja de algum transiente gerado no circuito - preciso girar um motor acionado por PWM para que o sensor IR possa gerar o sinal necessário - pergunto o que mais poderia fazer para tentar resolver esse drama ?

No motor estou utilizando capacitores de 100nF na sua alimentação, de cada fase da alimentação para GND e de sua carcaça para GND. Estou utilizando pinos para o PWM em 1KHz para frente e 500 para trás. Não há mudança do problema com isso.


Não sei se ficou claro a explicação. Para quem leu até aqui me desculpe a extensão do texto. O fato é que já procurei na internet inteira e não encontro ninguém relatando problema semelhante, pelo menos com uma "solução" para tentativa. A única informação boa que encontrei, mas mesmo assim apenas uma afirmação, é de que as interrupções do Arduino são "muito sensíveis".

Vejo em materias e vídeos na internet que inúmeras pessoas utilizam essa tecnica com aparente sucesso, portanto seria essa sensibilidade tão elevada assim ?

Já ia me esquecendo, mas dos meses em que me debato com isso, me preocupei muito com um provável transitente gerado no receptor do TCRT. Fiz inúmeros experimentos travando uma condição anormal, se existisse, e concluí que esta ppossibilidade esta descartada, pelo menos na bancada.

É problema de ruído ou pode ser alguma outra coisa ?

Idéias são muito bem vindas,

Obrigado,

Wilmar

Exibições: 8028

Anexos

Responder esta

Respostas a este tópico

É isso ai.

Tem que ter paciência.

Recomendo usar vários fusíveis em todas placas, durante a fase de desenvolvimento e testes.

Se houver algum curto, pode-se evitar que ela se queime.

Essa técnica de retirar partes do circuito, para que possa descobrir algum problema mais complicado é muito usada na IBM (onde trabalho). 

Ela se chama minimum configuration test. Por exemplo quando algum servidor esta com um problema que não foi solucionado pelas técnicas normais, recomenda-se que deixe-o com a configuração mínima. Por exemplo retiramos adapters (placas PCI), HDs, memória ou processadores.

Pois é Gustavo, eu sou meio "esquentadinho" e tem horas que me irrito com esses probleminhas aparentemente "insolúveis".

A questão dos fusíveis foi falha mesmo de procedimento.

Eu os tenho no chassi do robô, mas apenas dois, uma para os motores e outro que alimenta a fonte de 5volts na "placa de expansão".

Como colocar porta fusível nessas placas que têm que ser "pequenas" é difícil, eu pensei em utilizar fusível eletrônico ou mesmo a utilizada pelas placas da Arduino (esquecí o nome !).

Como não tenho educação formal em eletrônica, teria que pesquisar, fazer uns testes ...

Acabei deixando de lado e coloquei os fusíveis mencionados.

Esse é mais um aprendizado que tirei desse problema com os encoder´s.

Outra coisa que eu falhei foi na documentação / metodologia dos testes que efetuei até aqui. Eu documento muita coisa (para meu entendimento) mas concluí agora que poderia ter detectado que a protoboard mini que estou utilizando colada no chassi do robô para testes, poderia ser a "fonte" do problema (isso se realmente for problema de contato).

Aprendizados à parte, ainda preciso consertar a placa queimada para a conclusão final, pois vai que é ela!?

Muito obrigado pela ajuda.

Com essa imersão nos testes do robô ainda não testei o Analisador Lógico, mas vou fazê-lo.

Wilmar

Bem, eu consertei a placa que entrou em curto e a coloquei para rodar, voltando a utilizar todo o hardware do robô dos últimos tempos.

As interrupções (externa) estão sendo detectadas sem problemas de aparecimento das indevidas!.

Portando posso concluir que realmente era um tipo de mal contato na protoboard, utilizando aqueles cabinhos com pontas redondas. 

Digo um "tipo" de mal contato, porque pela frequência de trabalho podia-se perceber que ela não sumia e voltava, na verdade ele mais "voltava" que sumia, pois ocorriam interrupções extras!.

Outro ponto discutível, é que esse "mal contato" ocorria no feedback das interrupções (uma saída digital acionada pela ISR para indicar a ocorrência da interrupção e monitorada em osciloscópio). Portanto, esse sinal não deveria impactar nas interrupções, uma vez que ele não as gera e sim as monitora!!  Talvez um tipo de interferência originada nesses contatos que estivesse impactando o sinal de entrada do Arduino para a interrupção ?!?!

Vou começar a medir os tempos entre interrupções no Arduino e verificar como estão.

RSS

© 2024   Criado por Marcelo Rodrigues.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço