[Encoder] incremental con FPGA.

[Democrito]

Hola!

Hace muchos años me puse a hacerme mis propios encoders incrementales (ópticos y magnéticos) y una de las cosas que aprendí era la necesidad de usar disparadores Schmitt para acondicionar las señales A y B que da el encoder. Accidentalmente me he encontrado en la web un diseño a base de flip-flops y puertas xor, y creo que tiene doble función. Por un lado discrimina las señales CP y U/D, y por el otro (esto es una opinión, no sé si lo que digo es cierto) al parecer hace la "pseudo-función" como en los disparadores Schmitt. El esquema es el siguiente.

Metí ese diseño en Icestudio junto a un contador reversible para probarlo y... sencillamente funciona de maravilla, y no sólo eso, además es x4.

Le he hecho todo tipo de pruebas y hasta el momento no falla ni un pulso, cuenta perfecto. He flipado un montón con que no necesite los disparadores Schmitt, eso permite que puedas conectar directamente el encoder a la FPGA. Tenía uno hecho (casero) para 5 voltios, pero lo he alimentado con el voltaje de la Icestick y también funciona bien a 3.3v.

Adjunto ICE.

Saludos!

[Democrito]

Le acabo de quitar los dos primeros flip-flops y sigue contando bien...

[Juan Gonzalez Gomez]

Buenísimo demócrito!!!!!  Estoy deseando probarlo con los robots!!!!  :-D

¡Gracias!

Saludos, Obijuan

El 28 de noviembre de 2016, 2:12, Democrito <spo...@gmail.com> escribió:

Le acabo de quitar los dos primeros flip-flops y sigue contando bien...

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/56906745-7981-47a3-9bbd-94c7f14c8231%40googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Julián Caro Linares]

Es fantástico :)

¡Muchas gracias por compartirlo!

[rafael lozano]

Yo de mayor quiero saber la mitad de lo que tú sabes.

Ya abusando de tu intelecto como podrías controlar un motor por pwm y el encoder

[Democrito]

Hola Rafaél,

Lo del encoder no es mío, el diseño es de otra persona, de hecho no consigo todavía ver razón de porqué funciona tan bien, y me sorprendió grátamente, especialmente porque no necesita disparadores Schmitt, algo que yo lo veía como obligatorio si se hace con electrónica pura (sin microcontrolador).

Sobre experiencias de encoders y control de motores, he probado dos versiones, uno por comparación numérica, que es simplemente un comparador digital que dice si algo es mayor, menor o igual. Es tan simple y funciona tan bien que para la mayoría de cosas que hacemos en plan robótica serviría. Será lo próximo que publique por aquí en unos días. El problema que tiene es que funciona bien para pequeñas cargas, o bien, cuando no necesitas suavidad, porque es darlo todo o nada.

La segunda forma que conozco de controlar motores es por control PID (ello implica un PWM), mucho más suave y con grandes cargas si se ajusta bien puede funcionar estupendo, pero consume muchos recursos en un microcontrolador, y con electrónica pura es lo que ando mirando por las webs ahora mismo, buscando ideas o la propia idea resuelta.

Pero en el control PID, lo que quiero evitar a toda costa es que sea algo tan complejo que consuma la mayoría de puertas y flip-flops de una FPGA como las que estamos manejando. Sobre éste último tema busco algo alternativo y mi cabeza (que son dos neuronas y una hace eco) no para de dar vueltas, pero he visto cosas interesantes, como algo que comentó en cierto momento Julián Caro Linares sobre electrónica bio-inspirada (no estoy muy seguro si lo estoy diciendo bien o metiendo la pata). Googleando me encontré con esta web y sinceramente, no comprendí nada pero me llamó poderosamente la atención; me pareció un camino interesante. Hay proyectos en apariencia sencillos, pero que abordarlos significa aprender muchas cosas que, al menos en mi caso, todavía desconozco.

Saludos!

[Salvador Eduardo Tropea]

Hola!

Hasta donde tengo entendido las entradas de las iCE40 tienen histéresis,
no lo medí, pero en las hojas de datos habla de entradas schmitt trigger.
Es algo que menciona al pasar en la introducción y luego no vi que lo
explique bien, luego en las características dice:

V_HYST (Input Hysteresis) [para V_CCIO = 1.8 V, 2.5 V, 3.3 V] Typ. 200 mV

Esos F/Fs que le sacaste son sincronizadores, están ahí para reducir la
probabilidad de entrar en metaestabilidad. Si las entradas tienen
histéresis no son necesarios.

Saludos, Salvador

El 27/11/16 a las 22:12, Democrito escribió:

> Le acabo de quitar los dos primeros flip-flops y sigue contando bien...
>

> <https://lh3.googleusercontent.com/-BXuZRg0C8Zc/WDuEiuJ1JCI/AAAAAAAAAsg/dRdMydlKmG8gMkWpXkF-ZuMktzFV7jf3gCLcB/s1600/discriminador_encoder_fpga_1.PNG>

>
>
> --
> Has recibido este mensaje porque estás suscrito al grupo "FPGAwars:
> explorando el lado libre" de Grupos de Google.
> Para cancelar la suscripción a este grupo y dejar de recibir sus
> mensajes, envía un correo electrónico a

> fpga-wars-explorando-el...@googlegroups.com
> <mailto:fpga-wars-explorando-el...@googlegroups.com>.

> Para publicar en este grupo, envía un correo electrónico a

> fpga-wars-explora...@googlegroups.com
> <mailto:fpga-wars-explora...@googlegroups.com>.

> Visita este grupo en
> https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.
> Para ver esta conversación en el sitio web, visita
> https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/56906745-7981-47a3-9bbd-94c7f14c8231%40googlegroups.com

> <https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/56906745-7981-47a3-9bbd-94c7f14c8231%40googlegroups.com?utm_medium=email&utm_source=footer>.

> Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/
INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/
Unidad Técnica Sistemas Inteligentes Av. General Paz 5445
Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA
FAX: (+54 11) 4754 5194 Buenos Aires * Argentina

[Democrito]

Hola Salvador,

ciertamente, si las entradas tienen histéresis lo que me refería a que se puede usar como disparador Schmitt sería totalmente falso.

Gracias por ese importante dato!

Saludos.

[Democrito]

Sea como fuere y pensando en cómo solía hacer en el pasado el "discriminador de ondas", me sigue gustando el esquema arriba citado. A nivel de consumo (como recursos) de puertas lógicas y flip-flops lo veo bastante aceptable y da como factor de multiplicación x4, algo que puede ser muy útil en encoders de poca resolución.

[Democrito]

Hola!

Dije que pondría un ejemplo de control de motor "por comparación numérica" con encoder incremental y lo prometido es deuda. No me he complicado mucho la vida y sólo lo he hecho de 8 bits de resolución.

Controlar motores de esta manera es sólo para encoders de muy poca resolución, por ejemplo unos 40 pulsos por vuelta del motor como máximo (esto es dicho a ojo, igual se puede un poco más). No se puede aplicar este método a encoders de mucha resolución porque funciona en plan "o todo o nada" y no tendría un espacio físico para parar el motor de forma estable (se pondría a vibrar).

Yo he usado un motor con encoder "chapuz-casero" de 4 pulsos por vuelta, pero como el "discriminador" o decodificador de onda multiplica por 4, queda como uno de 16 pulsos por vuelta.

Para no andar con 8 cables o interruptores decidí entrar la posición final (posición a la que queremos llevar el motor) a través del PC y el USB, enviando la información a la Icestick (en este caso, porque mañana será Alhambra!). Las conexiones son las siguientes:

Y gráfica, el funcionamiento interno es algo parecido a esto, luego comento detalles sobre cómo funciona exactamente.

Lo importante, y de ahí su nombre, es el comparador. En la entrada A le entra (en este caso) a través del USB un byte de información, que es la posición a la que queremos llevar al motor. La entrada B es la posición actual del motor, y utiliza el mismo esquema que puse en el primer post de ese hilo, pero es de 9 bits. En función del peso de A y B hará girar el motor hacia un lado o hacia el otro y cuando llegue a la posición deseada, parará.

El ICE del circuito real son bloques con funciones específicas. Si hacéis doble clic sobre ellos veréis sus tripas; incluso hay bloques dentro de otros bloques. Esta es una de esas cosas geniales que tiene Icestudio.

En el ICE que adjunto verás el siguiente esquema.

No es tan complicado como aparenta. Lo que sucede es que el comparador lo tuve que dividir para no tener problemas. He añadido 8 leds para poder ver lo que envía el ordenador (la posición deseada); y las tres puertas lógicas es para evitar que el motor se pase en las posiciones finales (cuando llega a 0 y 255). Para poder tener todo el recorrido es importante que el lector de encoder sea de un bit de más, por eso es de 9 bits (Q0..Q8).

Adjunto también el programa (en FreeBasic) por si alguien se anima a probarlo. Con las teclas puedes hacer que haga incrementos/decrementos de 1, 4 y 8. También permite ir directamente a la posición 0, 126 y 255. Funciona a un baudrate de 115200.

Os dejo un vídeo. Piensa que estoy comandando el motor a través del teclado del PC. Le hago moverse con incrementos/decrementos y 3 posiciones absolutas, como expliqué antes. Los leds rojos es la posición que recibe la Icestick desde el PC. Verás que una de las aspas del encoder es de color negra, esa es la referencia y has de comprobar que cuando es 0, esa aspa siempre está en la misma posición, lo cual quiere decir que no pierde ningún pulso.

https://www.youtube.com/watch?v=7LCj__UI_s4

Saludos!

[Democrito]

Ya es una costumbre que se me olvide adjuntar el ICE y tb el programa del PC....

Adjuntos quedan.

[Juan José Luna Espinosa]

Impresionante. Mola mucho cómo se balancea alrededor de la posición neutra.

[Juan Gonzalez Gomez]

Woala!! Cómo mola!! Gracias Demócrito!!  :-)  plas plas plas plas

Saludos, Obijuan

El 9/12/2016 7:35 a. m., "Juan José Luna Espinosa" <juanj...@gmail.com> escribió:

Impresionante. Mola mucho cómo se balancea alrededor de la posición neutra.

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.

Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/5e3ca5c4-e939-4000-9c4f-9ea4d36379c0%40googlegroups.com.

[Jose Antonio Vacas Martinez]

Gracias Demócrito, intentado montar uno en 3,2,1 ...

[Democrito]

Este mensaje va dirigido a los que tratan de controlar un motor con encoder por primera vez.

Cuando todo está montado y listo para hacerlo funcionar puede suceder una cosa y es que se ponga a dar vueltas y en apariencia no deja de hacerlo. O estando inicialmente quieto y movemos con el dedo un poco el encoder, se pone a dar vueltas sin parar. Todo esto es síntoma de que o bien los dos cables del encoder, o bien los dos cables del motor, se han de enrocar (intercambiar) porque están invertidos. Esto sólo hay que hacerlo o bien con los cables del motor, o bien con los cables del encoder (señal A y B), nunca los dos a la vez.

Ahora ha de funcionar bien.

Ocho bits es muy pobre. Voy a ver si saco tiempo este finde y adjunto uno de 16 bits, con el que ya se puede hacer alguna cosa interesante, como por ejemplo que lleve reducción (engranajes), de esta manera el balanceo se minimiza, y si se añade un poco más de resolución, se minimiza más, pero en esto último existe un límite.

Para motores con mucha resolución no hay más remedio que usar un control PID. Aunque existe maneras (poco ortodoxas) para aplicar este mismo método (comparación numérica) de eliminar resolución, que sería poniendo un contador reversible de N bits donde los primeros bits no se utilizaría, ello permitiría margen para poder parar el motor.

Saludos!

[Democrito]

Para el que tenga ganas de aprender, este tío explica muy bien cómo funcionan los encoders y maneras de hacerlo eficiente. Él usa Arduino y control PID, pero lo que me interesa exponer aquí es sobre el principio de funcionamiento.

https://www.youtube.com/watch?v=dPBKTZw_xi4

[Jesús Arroyo]

Demócrito es una pasada!!!

Esto lo tengo que probar.

[Julián Caro Linares]

Es genial, había hecho encoders similares al del video con Arduino, pero con hardware es todavía más interesante :)

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/aIefIaWLewc/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.

Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/d52743c6-cb09-4016-8bc8-a160f4d91a75%40googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Julián Caro Linares

email->jcarol...@gmail.com