AS5600 Rotary magnetic absolute encoder with 4096 definition steps (12 bits).

[Democrito]

Hola,

En esta ocasión os presento un encoder absoluto magnérico de 12 bits que se llama "AS5600". Funciona por I2C. Tiene una resolución de 4096 puntos por revolución.

Este encoder absoluto es el más utilizado en el mundo de Arduino, por su alta resolución y es muy económico.

En este post os pongo un primer ejemplo en el que uso los leds para visualizar la posición en binario.

Como hemos de representar sólo 8 bits (los 8 leds de la Alhambra FPGA, en mi caso) se ha de descartar los 4 bits más bajos. Por otra parte, el bus es de 16 bits, sin embargo la resolución es de 12, por tanto los 4 bits más altos no se utilizan. He diseñado este driver con un bus de salida de posición de 16 bits porque es estandar, y es menos complicado extraer los bits para las personas que están empezando a usar Icestudio.

La utilidad de usos de un encoder absoluto es brutal. Se puede usar para el control de posición de motores, posición de articulaciones, potenciómetro digital, veletas digitales... y un largísimo etc.

En su interior hay un Atto-I2C, que me ha facilitado el diseño y le he podido sacar casi todo el jugo que tiene el AS5600. Las patillas que no tienen conexión en este primer ejemplo, no son necesarias, pero esas patillas no usadas darán información al usuario avanzado que necesite información de, por ejemplo: Si el imán está presente o no, si el campo mágnético del imán es demasiado fuerte o demasiado débil, se le puede extraer el valor numérico de la intensidad magnética, y también saber el valor de un AGC (control automático de ganancia). Todo esto lo explicaré más adelante en otros post o cuando suba todo esto a mi GitHub, ahora de lo que se trata es de probar y jugar un rato con el AS5600.

El pinout es el siguiente:

• Los pines SCL y SDA se conectan a D0 y D1 de la FPGA, pero como ya sabes, esto lo puedes cambiar de lugar si así lo deseas. En principio y funcionando a 100KHz no necesita resistencias en configuración pull-up, pero si elevamos la frecuencia I2C entonces sí serán necesarias. Todavía no he hecho pruebas de frecuencia, pero según he leído, para usar 400KHz o más, se vuelven necesarias esas resistencias para ayudar a hacer las señales más cuadradas.

• El pin DIR lo has de poner a 1 lógico o a 0 lógico. Si ese pin está a 0 lógico incrementa la cuenta cuando giras en el sentido de las agujas del reloj, y si lo pones a 1 lógico incrementa la cuenta si giras al contrario de las agujas del reloj. De momento déjalo fijo en uno de los dos estados lógicos, no importa cuál si es para probar el funcionamiento.

• He alimentado esta PCB (como el de la imagen) a 5 voltios y a 3.3V sin problemas.

• Los pines PGD y OUT no se utilizan en este proyecto ni tengo de momento pensado hacerlo, pero os explicaré brevemente lo que he leído. El pin PGD es para programar, entre otras cosas, dónde quieres la posición cero. Sólo permite ser programado 3 veces, así que este tema es muy delicado. El pin OUT es una salida PWM, pero según me ha parecido entender, hay que eliminar una resistencia (de 0 ohmios, "R1" en la serigrafía) que hay en la PCB para activar esta parte. Si lo haces, corre bajo tu responsabilidad que luego te lleves sopresas desagradables. Yo todavía no he probado esta parte.

El imán no es el imán normal en el que los polos están en las caras. Se necesita un imán diametral.

En los imanes diametrales los polos están en los costados. Si compras el módulo asegúrate de que también lleve el imán.

El imán que yo uso mide: 6x2 mm. El que yo estoy utilizando lo compré en Aliexpress y están pensado precisamente para los encoders magnéticos rotatorios absolutos. Aparte compré imánes de este tipo para tener. Los compré hace mucho tiempo y no tengo la referencia de la tienda donde hice la compra, pero si alguien está interesado, lo puedo buscar.

Dejo una referencia de una tienda de Aliexpress donde vende el módulo junto con el imán a muy buen precio: https://aliexpress.com/item/1005001621701959.html

No sé cuánto tiempo podrá durar este enlace.

Por otra parte, hacer girar a mano el imán no tiene mucho sentido. Se puede hacer construcciones manuales para que esto no sea un problema, pero si tienes impresora 3D, te puedes descargar estos diseños e imprimirlos. Son tan pequeños que en muy poco tiempo (menos de 20 minutos) lo tienes impreso: https://www.thingiverse.com/thing:4656550

En próximos post pondré otros ejemplos, más explicaciones, cosas que se me hayan olvidado comentar, algún vídeo, etc.

Adjunto ICE.

Saludos!

[Democrito]

Un vídeo demo:

https://www.youtube.com/shorts/qYiRg1CM6ZE

[Devta Singh Khalsa]

Demócrito, una pregunta respecto a este codificador rotativo magnético.

Cual debe ser la magnetización del imán. Si es un cilindro, ¿un polo magnético en cada cara circular (axial) que es la más típica, o lateral?

Porque me puede servir para hacer un sensor de posición para una ingletadora en la que los ángulos son muy importantes, y con esa resolución... es una maravilla.

Gracias.

Devta Singh Khalsa

http://yogakundalini.com/ - 

http://devta.wordpress.com/ 
http://circulodesanacion.com
http://medicosdelcielo.org

Cantarranas,2
19413 Villaviciosa de Tajuña

Guadalajara / Spain

El sáb, 2 sept 2023 a las 22:42, Democrito (<spo...@gmail.com>) escribió:

Un vídeo demo:

https://www.youtube.com/shorts/qYiRg1CM6ZE

--
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.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/9706b5c2-8d64-4d46-8560-1cf939889d56n%40googlegroups.com.

[Devta Singh Khalsa]

Perdona, no había leído todo el texto.

Está claro.

Gracias.

Devta Singh Khalsa

http://yogakundalini.com/ - 

http://devta.wordpress.com/ 
http://circulodesanacion.com
http://medicosdelcielo.org

Cantarranas,2
19413 Villaviciosa de Tajuña

Guadalajara / Spain

[Jo mo]

Nice, Gracias for sharing Democrito !

These ICs are very interesting for measuring precisely motors rotation position(robots,... )

[Democrito]

Acabo de terminar un módulo que es electrónico puro, no hay líneas de programación y puede llegar a ser realmente rápido pese a funcionar por I2C. He llegado a una frecuencia I2C de 1.5MHz. Según el datasheet la frecuencia máxima es de 1MHz. Los overclocking pueden ser un poco diferente para cada chip.

El circuito oficial será este que presentaré ahora porque es mucho más económico a nivel de recursos y los bytes van más pegados, lo cual significa ganar en frecuencia de muestreo.

Además de la posición del imán, el AS5600 también se puede usar para saber la intensidad magnética del imán, y dos cosas internas de las que hablaremos más adelante.

El funcionamiento es el siguiente. Tiene 4 pines de "start" (st).

Para saber la posición del imán damos un tic en el pin de entrada "stpos" y la patilla de salida "done" nos avisará de que ya están los datos de la posición disponible en la salida "pos[15:0]. Recuerda que de esos 16 bits sólo son útiles los bits 0..11 (12 bits).

Para saber la intensidad magnética damos un tic en la patilla de entrada "stmgi" y la patilla de salida "done" nos avisatá de que ya están esos datos disponible en la salida "img[15:0]". De los imanes que tengo no he conseguido una intesidad magnética mayor de 2100.

Para saber si el imán está presente o no, si el imán es demasiado débil o demasiado fuerte, le daremos un tic en la patilla de entrada "ststt" (estatus), y un tic en "done" nos avisará de que esos datos están disponible y los podremos leer a través de tres pines de salida: "mh" (imán demasiado fuerte), "ml" imán demasiado débil, y "md" (imán detectado). En realidad, internamente estos datos están relacionados con el AGC, cuando el AGC llega a valores límites, estos bits cambian.

Y para finalizar, si damos un tic en el pin "stagc", nos dará un valor interno del control automático de ganancia (AGC), dicho valor es de 8 bits y lo podremos obtener en la salida "agc[7:0]"

Todas las salidas están registradas, esto significa que puedes tomar directamente de la salida los datos sin necesidad de validar con el pin "done". 

Adjunto un zip con ejemplos de cada caso descrito. Sé que lo único interesante es saber la posición, pero por ejemplo, si dudas del imán y quieres saber si es válido para el AS5600, puedes verlo con un simple vistazo mirando los tres bits que comenté antes (ml, md y mh).

Como comenté más arriba, este circuito-driver consume muy pocos recursos. Si, por ejemplo, sólo queremos saber la posición, las demás entradas "start" las ponemos a 0, y cuando vaya a sintentizar el circuito, sólo sintetizará esa parte.

Saludos.

[charli va]

Que bueno Demócrito! tengo pedido el encoder a ver si llega y puedo probarlo.

Por cierto estuve jugando con los nrf y todo super bien! quiero implementarlo en la pi pico y ya te haré el pr correspondiente.

Muuuchas gracias!

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

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/22738de0-ba70-46d2-a09c-5c27e6937b22n%40googlegroups.com.

[Democrito]

Perfecto Carlos! Y gracias por probar el emisor. Ese proyecto ha sido muy satisfactorio. Estoy muy contento con el resultado y la estabilidad dentro de una zona segura de comunicación. Y una de las mejores características es que se pueda compartir datos desde una FPGA a cualquier otro dispositivo sin necesidad de cables.

Sobre el AS5600 voy a intentar ver si consigo contar vueltas de forma fiable a alta velocidad. Con encoders incrementales esto no es ningún problema (conteo actual/4096), pero con encoders absolutos es más complicado, porque de una muesta a otra, a alta velocidad el conteo no es consecutivo, especialmente en cambios de sentido.

[Jo mo]

Ola guys,

Congratulations Democrito, you are a crazily efficient " hardware design machine"  :-),  i just compiled both circuits and we have now 173LC (instead of 662LC for the ATTO version)

Nevertheless, You wrote: " El circuito oficial será este que presentaré ahora porque es mucho más económico a nivel de recursos y los bytes van más pegados, lo cual significa ganar en frecuencia de muestreo."

May i suggest you to keep also the ATTO version of that design somewhere in your github ! 

And this for 2 reasons:

1- for controlling multiple AS5600 and with some modifications (i2C multiplexing) the Atto design may be more ressources efficient . Also with some more code in the"code" icestudio block we can also control other i2C chips using the same single  ATTO circuit !

2- All those Atto designs are interesting for playing with that processor!   When i will have time i may make my own version of ATTO  ( starting from your version, i have some ideas...)

On my side, i received yesterday my nRF24l01 and my nextion orders!  So i will play a bit with those toys and your nRF designs!

Have a nice day guys!

[Democrito]

Hello Joaquim,

I take your suggestion and will make room for the Atto version. Once you know the sending codes, it is very easy to implement in Atto.

This is an I2C example using AS5600:

The 8-bit writing I2C address is 6C and the reading address is 6D. The 7-bit address (without the RW bit) is 36.

To know the position:
6C, 0C (means you want to know the position)
6D, FF, FF (Read the position, the two bytes FF and FF are arbitrary, which will be the bytes read from the position)

As you can see, it is very simple. And in the same way other commands are applied, such as knowing the AGC, magnetic intensity, etc.

For this reason it was very easy to implement electronically and took up very little space.

When I was learning about the AS5600, I first read about I2C multiplexing, because if you want to know the position of multiple, the address is unique. I need to learn more about this problem and see how it can be addressed.

I also want to make other versions of Atto, but in reality it would be to create small programmable machines dedicated to a very specific objective and that all the instructions can be compatible between the different machines. But this time instead of doing a graphic design, I want to do it in verilog, but inside a code box for Icestudio. If you want, we can collaborate on the new design.

On the nRF24L01, remember to place a larger 10uF capacitor soldered up on the power supply pins. In reality these transceivers are designed to be powered by batteries. On the other hand, you need a good current source greater than 250mA. If that is true it will work the first time and without problems in 8 meters.

I hope it goes well for you and that you tell us what you achieved!

[Democrito]

Fe de erratas:

En un anterior post relacioné la resistencia de 0 ohmios (serigrafiada como "R1") con el PWM. No es así, lo confundí con otros trozos que iba leyendo.

Esa resistencia está ahí puesta para alimentar a 5V, y según parece también funciona a 3.3V. Sin embargo, al eliminar esa resistencia sólo funcionaría con 3.3V

Disculpad la confusión.

[Jo mo]

Ola Democrito

You wrote: " I also want to make other versions of Atto, but in reality it would be to create small programmable machines dedicated to a very specific objective and that all the instructions can be compatible between the different machines. But this time instead of doing a graphic design, I want to do it in verilog, but inside a code box for Icestudio. If you want, we can collaborate on the new design. "

i think we have the same think in mind:

- making one (or more) ~200 LC micro-controller ( processor (~25Mhz,maybe faster, with the help of Plls) + slow type of interfaces (max 1mhz)).  or a kind of programmable state machine!

- with a simple common set of instructions, to avoid the need of learning a new programming language every time!

- And to simplify user coding, we will need a simple assembler tool. Inside an icestudio plugin or just an external script for converting the assembler code (written with a text editor) into an hexadecimal code ready to be pasted inside the icesudio memory block

But be warned, for now, my knowledge on this Atto subject are well behind yours so my help will be limited to :

- supply good or bad ideas of features

- and maybe prepare the assembler tool side !

So if you still want to choose the red pill ! ;-) , You can open a new thread and we can start slowly /gently brainstorming  about those ideas of potential Atto versions!

Big hug and have a great sunday!

[Democrito]

When I finish the projects I have pending I will open a new thread, with something to start. My verilog is very poor, but I think I understand sequential logic well.

I choose the red pill!

A hug!

[Jo mo]

made be an AU (Artificial UnIntellgence) :-)  they are shitty at drawing a simple text !

[Democrito]

Hahahaha!

Thank you Morphée-Joaquim!

[Democrito]

Estoy yendo paso a paso hacia un objetivo. Si el encoder absoluto va colocado en una articulación, ese problema ya está resuelto. Ahora falta la posibilidad de que el encoder absoluto esté en el mismo eje del motor, en vez de en una articulación. En este sentido se convertirá en una especie de encoder incremental, ya no será absoluto.

Son posibilidades de usos y quizás haya alguien que le interese usarlo de esta manera (el imán pegado al eje del motor). Y aquí hay un problema, si fuese un encoder incremental, en todo momento sabríamos los pasos que ha dado, pero en un encoder absoluto y por I2C, esto es imposible a no ser que vaya demasiado lento. Entonces hay que crear un algoritmo que cuente hacia delante si pasa de 4095 a 0, y que cuente hacia atrás si pasa de 0 a 4095. Pero en la realidad y con mucha velocidad esto no es posible, porque vamos a tomar muestras en el tiempo (sample rate).

Como decía, hay que crear un algoritmo que resuelva este problema. Se trata de tomar como mínimo 3 muestras por cada vuelta que haga el eje del motor a máxima velocidad. El algoritmo "entenderá" que si pasa de el punto 0 ó 4095, y el punto anterior es mayor o menor de 2047 (4096/2-1, es decir, la mitad) debe de entender que ha dado una vuelta completa en un sentido o en el otro.

El ICE que adjunto en este post aplico un algoritmo para contar vueltas completas. Es decir, que hay que dar vueltas completas para contar en un sentido, o para descontar en el otro. El único requisito para que funcione bien es no sobrepasar una velocidad máxima que todavía desconozco (depende de muchos factores, entre ellos la frecuencia I2C), y que el encoder esté parado (quieto) en los primeros 250 milisegundos de cuando se pone en marcha.

En el ejemplo que adjunto, a través de los leds podemos ver contar o descontar vueltas completas. Hay que girar 360º el imán para que cuente o descuente según el sentido en el que giremos. Este proyecto está limitado a 8 bits, pero en realidad tiene una resolución de 20 bits, y no es casualidad el "20" (20+12 = 32, lo limitaré a 32 bits, pero podrían ser más).

En este post sólo contaremos vueltas completas (por cada 360º una vuelta), en el siguiente post contaremos con toda la resolución, es decir, una vuelta será 4096 posiciones y si se sigue dando vueltas, será número_de_vueltas * 4096 + posición_actual_del_encoder_absoluto. Esto es una resolución increíble!

Pero ahora de momento, sólo contaremos una vuelta por cada 360º y adjunto ICE que hace eso. Lo importante aquí es comprender por qué se dan estos pasos hasta llegar al objetivo final. O dicho de otro modo: Imagina que tienes un encoder absoluto y quieres conseguir toda la resolución posible si ese encoder está fijado al eje de un motor. ¿Cómo llegar ahí? pues este es un paso previo a la solución.

Saludos.

[Democrito]

En el anterior post os mostré un contador de vueltas completas (cada 360º una vuelta). En este post os presento un encoder con toda la resolución que da el encoder más los números de vueltas (cada 360º se va sumando 4096 posiciones).

En este ejemplo, para tener toda la resolución (32 bits) lo hago funcionar a través del serial. Os dejo con una imagen de cómo se ve el ejemplo que adjunto.

Cada pin hace lo siguiente:

SDA y SCL se conecta al AS5600 para obtener los datos. Cada vez que tenga un dato lo sacará por la salida sin nombre [31:0] y se validará con un tic de "done".

"Hz" es la frecuencia I2C, que como ya expliqué en el anterior post, se puede elevar la frecuencia hasta 1MHz si así lo deseas (según el datasheet). Si el AS5600 va colocado en el eje de un motor, conviene que el muestreo sea lo más rápido posible. Has de pensar que a máxima velocidad del eje del motor se ha de conseguir al menos 3 puntos de muestra de cada giro completo.

La constante offset nos puede servir para ajustar un punto 0 concreto.  Este punto 0 no tiene en cuenta la cantidad de vueltas que haya dado, esto es importante entenderlo. Aquí estamos usando un encoder absoluto como si fuese un pseudo-encoder incremental. Esto significa que dentro de los 360º tenemos un encoder absoluto, pero si das más vueltas, entonces es como tener un encoder incremental, pero con una parte absoluta. Si has de tocar esta parte, con la experiencia te irás dando cuenta de la funcionalidad del offset. Los valores posibles son de -4095 a 4095. Otros valores, mayores o menores, no tienen sentido (al menos en principio).

Un tic en "rst" pondrá a cero el número de vueltas, pero no pone a cero el encoder absoluto, para ello te has de hacer servir del offset.

Dejo un gif animado de lo que muestra en el terminal serie. Estoy moviendo el encoder con un dedo, por eso se ve que se mueve los números y para, se mueve los números y para.

Debido a que el conversor es "Uint32" (todavía no he creado otro módulo de 32 bits con signo) no salen números negativos, pero si consideras el bit 31 como signo, verías números negativos.

El terminal serie de Icestudio al comienzo tiene problemas para mostrar los números, se queda la pantalla negra sin salir nada. Lo resuelvo dándole al botón "Disconnect" y vuelvo a darle al botón "Connect", entonces aparece lo que véis en el gif de arriba. Este problema (creo que) es debido a que se envía datos al terminal serie con una frecuencia más alta de la que puede soportar y se satura. En realidad este circuito no está pensado para un terminal serie y aquí hace que el serial vaya muy forzado. Parece ser que el terminal serie de Arduino no tiene este problema, o al menos en este caso da los datos desde que conectamos al terminal serie.

He hecho unos cálculos para saber el número total de vueltas máxima que puede dar con 32 bits.

Cada vuelta son 4096 puntos.

360º / 4096 = 0.087890625º en cada paso (de un punto al siguiente).

0.087890625º x 2^32 = 377487360 pasos en total.

377487360 / 360º = 1048576 vueltas posibles. Como comienza de 0, en realidad son 1048575 vueltas posibles.

Eso son muchas vueltas! Quizás las ruedas del Perseverance de la NASA, dé ese número de vueltas a lo largo de su vida útil.

Adjunto ICE.

Saludos.

[Democrito]

Se me olvidó comentar que el algoritmo contador de vueltas que usé en un post anterior lo he cambiado por otro algoritmo mucho mejor, muy estable y con el que no he tenido ningún problema.

Cuando termine de hacer pruebas subiré todo esto a GitHub con todos los ejemplos aquí expuestos actualizados a al nuevo algoritmo (el que he usado en el último ICE).

[charli va]

Buenas Demócrito!  puedes trabajar a mucha más velocidad, como no tengo aún el encoder no puedo hacer la prueba pero yo estoy trabajando para varias cosas a 3Mbits y 12Mbits sin ningún problema.

Me da la sensación que como estás trabajando a 100Khz y transmitiendo a 115200bps, son frecuencias muy cercanas y si no tienes algún tipo de buffer igual se te pisan al comienzo o algo similar.

Prueba a subir la velocidad del puerto serie , por ejemplo ponte a 1Mbit y prueba a ver si te funciona. 

A ver si me llega el encoder y puedo probar todo esto bien.

Un abrazo!

El lun, 11 sept 2023 a las 15:08, Democrito (<spo...@gmail.com>) escribió:

Se me olvidó comentar que el algoritmo contador de vueltas que usé en un post anterior lo he cambiado por otro algoritmo mucho mejor, muy estable y con el que no he tenido ningún problema.

Cuando termine de hacer pruebas subiré todo esto a GitHub con todos los ejemplos aquí expuestos actualizados a al nuevo algoritmo (el que he usado en el último ICE).

--

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.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/d4aec0c0-0e27-4559-bbbc-98da830b3250n%40googlegroups.com.

[Democrito]

Efectivamente Carlos, también pensé en eso, en que se puede acelerar más el terminal para evitar que la velocidad del encoder "pise" al terminal. Todavía no lo he probado, pero es tal como comentas.

La velocidad máxima para el serial TX está a 115200, sé cómo modificarlo a baudios superiores, pero ahora estoy con otras cosas (diseñando unas piezas en 3D) y no es algo que me preocupe. Tal como has dicho, si se aumenta los baudios del terminal ese problema desaparecería.

Gracias por el comentario!

Un abrazo!

[Democrito]

Este post es sólo un anuncio. Mañana o pasado, os presentaré un control PID (muy muy simple) en el que aplico el AS5600 para el control de posición de un motor DC (con escobillas). Todo junto "pesa" unos 1600 LCs (es decir, muy poco para lo que realmente es).

Abriré un nuevo hilo para ello, porque no sólo pondré el circuito, también los STL que he creado, aquí el problema está en que el diámetro del motor sea el mismo (en mi caso es de 31.7mm de diámetro), sea como fuere, servirá de idea para que lo podáis adaptar a otros motores.

Me queda por hacer algunos test para validarlo, y si los supera, entonces lo publicaré todo. En realidad sólo buscaba experimentar y validar el AS5600 para frecuencias de giro. De momento he trabajado con 100KHz de frecuencia I2C y funciona perfectamente. Pero como decía, me quedan por hacer más pruebas. Las realizadas hasta ahora son completamente satisfactorias, tanto por la parte del AS5600 como del control PID.

Tenía hecho un "pseudoPID" en FPGA para motores con encoder de unos 330 pulsos por revolución (en este caso era un encoder incremental) y no cumplía las espectativas si utilizaba un encoder de 4096 puntos de resolución (en este caso es un encoder absoluto), así que estuve mirando la manera de mejorar la respuesta, y por el camino hice un "descubrimiento". Pero ese descubrimiento todavía es un tema completamente a parte y que cuando indague en él también lo compartiré con vosotros/as.

De momento, las pruebas sobre el diseno ("ICE" publicado en post anterior) del AS5600 ha pasado las pruebas para cierta velocidad no muy rápida, falta comprobar a mucha velocidad y ver si hay que tocar la frecuencia de muestreo del I2C.

Saludos.

[charli va]

No tengo impresora 3D pero será impresionante ver todo el trabajo en su conjunto.

Muchas felicidades Demócrito!

--

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.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/eb8cdc40-d3fa-43da-bbc0-a6d4c915e119n%40googlegroups.com.

[Democrito]

Pensaba que tenía un PID como dios manda y cuando he pasado a alimentar el motor de 5V a 12V, pufff... Mi gozo en un pozo. No funciona bien.

De todas formas os muestro unas imágenes de cómo hice para encajar el motor con el encoder.

Puedes usar un motor como eje o mando para mover el encoder en plan Jostick (es sólo una idea).

Voy a ir paso a paso:

Esto son todos los imanes diametrales que tengo. Los compré hace mucho tiempo, quería tener este tipo de imanes por si los necesitaba algún día, ya que en la época que los compré, cuando comprabas el encoder venían sin imán diametral. Hoy en día puedes comprar ambas cosas juntas y es lo que recomiendo. El vendedor te ofrece el encoder y el imán en el mismo paquete (todo junto). Son de 6x2mm y creo que son los habituales.

Para poder colocar el imán en el eje trasero de un motor, un modo de hacerlo para que quede completamente plano es usar un piñón o engranaje. Usa cualquier cosa que te permita poner el imán completamente plano en el eje. Hice unas pruebas imprimiendo una pieza para esto, con una impresora 3D, pero el agujero para el eje no sale de forma satisfactoria en piezas muy pequeñas. El diamétro de los ejes de motores DC del tipo "juguetes" suele ser de 2mm.

Esto es sólo un ejemplo.

Este es el motor que estoy usando. Es de 32 mm de diámetro (en realidad 31.8 mm). Creo que la referencia que tiene es "RC500-KW/16260". Los hay con eje trasero y sin él. Hay que elegir que tenga eje trasero, si no no nos serviría.

Aquí se aprecia el eje trasero. Le soldé un condensador de 100nF entre los bornes de alimentación del motor para tratar de minimizar los chisporroteos de este tipo de motor (con escobillas).

Aquí puedes ver que al eje trasero le he colocado un piñón que hace de base para el imán; esta es su única función. El imán, al ser diametral, lo puedes colocar como quieras, no necesitas fijarte en la polaridad del imán. Pegas el imán con pegamento al piñón y eso es todo. Lo importante es que quede bien centrado el imán, que cuando gire el motor no haga "bamboleos".

A la izquierda las dos piezas de plástico que fueron impresas en una impresora 3D. Debido a su construcción (no se puede imprimir en una única pieza, al menos con impresoras de filamento) se han de imprimir por separado, por eso son dos piezas.

Esta es la forma en que se han de unir ambas piezas de plástico. Cuando lo tengas bien nivelado, le echas unas gotas de pegamento para fijarlo a la pieza mayor.

En esta foto ya he metido el motor dentro del cilindro de plástico para que se vea cómo queda el imán con respecto al conjunto. No hace falta que sobresalga del plano-base del cilindro. De todas formas una vez que lo tengas todo montado, empujas el motor hacia abajo hasta que haga tope con el encoder, y una vez que hagan contacto lo separas un poco, eso es todo. Hay más margen de lo que parece en este sentido.

Aquí montamos el encoder y quedaría de esta forma.

Visto desde arriba sin el motor.

Esta es una vista delantera con el motor metido dentro del cilindro de plástico.

Y aquí lo podemos ver de lado.

Para otros tipo de motores que fuesen de menor diámetro, lo que se puede hacer es diseñar un relleno para que quede justo en medio el eje dentro del cilindro.

Adjunto el STL por si alguien le sirve esto como mando para controlar el encoder. Como ya comenté al comenzar, el PID que diseñé no es funcional, por eso no adjunto ICE. Según parece tuve "la suerte" de utilizar una tensión lo suficientemente baja como para que el PID que diseñé, en ese caso, fuese bien.

Saludos.

[Democrito]

Se me olvidó adjuntar el STL...

[Democrito]

Pese a todo os dejo con un vídeo de cómo va el motor que según el fabricante es de 12V, cuando lo alimento a 5V:

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

[Jo mo]

hola Democrito,

Congratulation, this is a great 3d print job !

For the pid, i imagine that it is not easy with this small dc motors !

1- They turn fast up to 20"000 rpm

2- they do not stop quickly, continue to turn when we stop powering them !

3- You need to reverse the voltage(or apply a negative voltage) to make it turn in the opposite direction !

4- they are powered/ controlled by a single voltage/ one coil  (vs two for the stepper motors)! so its much more difficult to set the good angle for the last turn !

But if this motor drive gears for speed reduction you can achieve precision, for an angle movement or for a linear movement (like in your 3d printer).

Some precision will be given by the high number of turns. (and we do not care to much for the last turn)

as i see it, in short, with dc motors, the as56000, can count turns accurately.

and if you really, need more precision (on the angle of the last turn), then you need a stepper motor

Big hug and have a good night !

[Democrito]

Bounjour Joaquim,

In Arduino I have solved all the problems related to the PID, and in this sense what I need to investigate and implement is a soft start (without using libraries).

I love stepper motors and they are very useful, but they weigh a lot, have a notable current draw, and the more power you need, the heavier and bulkier they are.

Although not always necessary, controlling a stepper motor in a "closed loop" is turning the stepper motor into a nearly perfect motor.

In FPGA what happens to me is that I am a stingy with resources and I am looking for a "magical" way to solve the main problem which is stability under any circumstances. A priori it requires many calculations and in an FPGA we already know what it means. When I give this up will be when I use math modules instead of tricks. The truth is that looking for other ways of doing things gives me a lot of mental life and is like an addiction. In this sense I think you understand me.

Another big hug!

[Jo mo]

Ola Democrito,  

i am not well in those motors subjects Now, i just still remember a bit technical scool Times, where i shortly played with motors (measuring their efficiency with load, without load)!

I encourage you to continue your findings. And i will just have a visual look at your block sée if i Can understand somethink!

About the addiction subject i understand very well😁. Everyone love to leave in a plaisant world where he feals he understand the rules and has everithink under control!

-junkies are taking drugs to just get a virtual perception of that!

-gamers play vidéo games, to be the master of their word(which are made of a limited amount of rules, not so difficult to understand)

- and there are people like you that got a crazy Idea to try understanding every rules available in the real universel! Good Luck!😁 

Hug!

--

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.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/543a8ca2-f5ed-4484-8829-8f2605c896f3n%40googlegroups.com.

[charli va]

Hola Demócrito! yo no sé mucho de motores, pero siempre es algo que he tenido pendiente, si nos cuentas un poco la teoría de lo que quieres hacer o nos indicas cómo lo resolviste en arduino, igual se me puede ocurrir algo o alguna estrategia que te pueda ayudar.

Un abrazo!

--- 

Hi Democrito! I don't know much about motors, but it's always something I've had on my mind. If you tell us a little about the theory of what you want to do or tell us how you solved it on Arduino, maybe I can think of something or a strategy that can help you. .

A hug!

--

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.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/543a8ca2-f5ed-4484-8829-8f2605c896f3n%40googlegroups.com.

[Democrito]

Muchas gracias Joaquim & Carlos por vuestra calidez humana. Al final he conseguido hacer un PID que funciona de forma totalmente convencional. En este sentido soy más exigente, pero de momento es lo que tengo y funciona bastante bien, independientemente de la potencia del motor. Está todo calibrado para un encoder absoluto de 12 bits y no hace falta  tocar ningún parámetro PID, pero he dejado el "Sample Time" por si alguien necesita algún ajuste más fino. Le he hecho multitud de pruebas y funciona como uno esperaría. Lo que no he logrado es que haga una parada suave, y por eso digo que es un "PID convencional".

Al abrir el ICE os encontraréis con esto:

Tiene las I/O del puerto I2C (SDA y SCL) que van al encoder magnético absoluto AS5600, en el que por defecto irá a una frecuencia de 100KHz, si quieres aumentar la frecuencia ponle resistencias de 1K5 en modo pull-up a los pines SDAy SCL (es una estimación, pueden ser de alrededor de ese valor) para conseguir que la onda cuadrada de la frecuencia I2C sea realmente cuadrada. En principio no es necesario tocar la frecuencia I2C, pero si crees que tienes un motor especialmente rápido, entonces súbele la frecuencia. El límite es de 1MHz, más allá de eso es overcloking, que como muchos sabéis, cada  chip tiene su propio límite en este sentido.

El "rst" lo he llevado a cero. En la vida real el reset nos serviría para encontrar la posición cero real, pero al ser un encoder absoluto, sólo pondrá a cero el número de vueltas. Para centrar el encoder a una posición cero real, hay que modificar el parámetro "offset".

A través del serial podemos introducir números positivos y negativos, desde -2^31 hasta (2^31)-1. Eso son muchísimas vueltas en la realidad. De todas formas, si alguien quiere rozar esos límites, ha de saber que por inercia del motor las puede sobrepasar, es decir, que hay que evitar llegar a esos límites, restando al menos una vuelta (4095 al número máximo de vueltas, sea en positivo o negativo). En realidad no hace falta que sea tanto, pero por seguridad...

Los pines "G" y "L" van al puente H. 'G' viene de "mayor que" y 'L' de "menor que", en inglés. Si tu puente H contiene pines llamados "enables" ponlos a 1s lógico. En este proyecto el PWM va directo en las salidas G y L.

Si al ponerlo en marcha no para de girar el motor, eso significa que los pines G y L hay que enrocarlos, es decir, que donde estaba G pones L y donde estaba L pones G. Hay muchas formas de hacer esto, también se puede hacer desde el encoder, cambiando de lógica (si estaba a 0 ponerlo a 1, o si estaba a 1 ponerlo a 0) el pin "Dir" del AS5600.

Recomiendo fehacientemete que si tienes poca experiencia con puentes en H, lo primero de todo es que hagas mover el motor en un sentido y al contrario de forma manual y directa desde el puente H, sin electrónica de por medio. Una vez que estés familiarizado con el puente en H entonces lo puedes conectar a la FPGA. Aunque esto parezca una tontería, hay muchas personas que fallan en este punto. Como hay dos tensiones, la del motor (>5V) y la lógica (5V o 3.3V), ahí hay gente que confunden esto y meten 12V como si fuese un 1 lógico, esto quemaría la lógica del puente en H. Repito, si tienes dudas en el manejo de puentes en H, echále un ojo a vídeos de youtube que hablen de ello.

El parámetro "Sample_Time" es el tiempo de muestreo. Tienes una holgura desde 300 hasta 1200 us. El PID ya está sintonizado para un encoder de 4096 posiciones posibles, independientemente de la potencia del motor. No hace falta tocar nada, pero he dejado el tiempo de muestreo para ser modificado por si acaso alguien lo necesita hacer por algún motivo que desconozco ahora.

Opcionalmente puedes visualizar el estado el motor a través de los leds. Es completamente normal que veas los leds del medio parpadear junto a "mayor que", o "menor que". Lo importante es que el motor en estado de reposo no vibre. Si no vibra estando en reposo, todo está bien.

Adjunto ICE.

Saludos.

[Jo mo]

Ola Democrito,

Congratulations for your results and thanks for all the details like the "H" connection of this DC motors (i didn't know about that)!
Inside this design there are plenty of nice blocks, that i will reuse one day!

For this incredibly precise motor control you are using around 1400 LC.

Just thinking, In case some people as an application with less precision needed.
It should be possible to decrease quite a lot the Fpga ressources.
An idea will be to count only the turns (losing all the angle precision) by replacing the as5600 by a much simpler hall effect sensor like KY-003 (no i2C needed)

If we say a little DC motor turns at 20'000 RPM and we use gear/belts (to reduce the speed, and increase the torque):

a - to make a linear movement, (eg of 1 meter in 6 second)  every motor turn will make a move of 0.5mm.

b - to make an angular movement, (eg of 360 degree in 6 second)  every motor turn will make an angle move of 0.18 degrees.

Those precision are already high taking in account the loose in the gears/and belts assembly.
Of course if the application needs faster movements (the precision and torque will be reduced)

So everything depends on everyone's application needs!

Thanks again Democrito for this incredible job !

Have good evening guys!

[FPGAwars: explorando el lado libre]

Thanks for your comment Joaquim,

There are many ways to count turns. What you tell me (KY-003), putting two, you get an encoder. There are magnetic and photoelectric ones. I have experimented with both for many years.

It has always fascinated me that something that can rotate very quickly can control its rotation position.

A hug!

[charli va]

Muchas gracias Demócrito por la explicación! un grandísimo trabajo.

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

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/b86ac4eb-dc1a-4f95-9c71-4894b58208b8n%40googlegroups.com.

[charli va]

Hi Demócrito! i found this twit that appears very interesting, i don't knew that is possible monitorize the motor position without sensors. I don't know if could be useful for you but i think you should waste some minutes in review it:

https://twitter.com/RueNahcMohr/status/1665395273198346240

[Democrito]

Hi Carlos,

Yes, I knew this form of control, but only to control speed, not position. The truth is that controlling the position through EMF (ElectroMotive Force, in spanish FEM) seems like magic and is what has left me speechless as a project.

The point is that at the motor control output there are very small times in which it would be in tri-state and during that time the voltage produced by the motor would be read (like an electric generator due to its own inertia). It is a very interesting control method.

Thanks for the tweet, I'll repost it!

[Democrito]

Now, looking more closely, I have seen that when moving the motor with your finger, the position is offset. Anyway, the system itself is very interesting.

[Jo mo]

A little video for fun

What can we do with small but good dc motors!

have nice weekend

[Democrito]

It's impressive what those electronic mice do. What fascinates me are the algorithms they must use (I don't know them). I also published that video but in Spanish at the beginning of August.

First they recognize the path, and then they try to get there as quickly as possible, taking the route map they made before. These kinds of things surprise me beyond measure.

Other things that I follow closely are these:

English: https://www.youtube.com/watch?v=16W7c0mb-rE
Spanish: https://www.youtube.com/watch?v=bxNdgknvK90

Greetings and good night Joaquim.

[Jo mo]

Yes Democrito, we bumped on the same video! This web is a small place for us who are navigating at the speed of the light ;-) !

"how stupid things become smarter together" 

 Well,  i will be a bit less optimistic!

In fact all those stupid things seem to be driven by law that increases the chances of survival of these things/species in a quite short term !

- Cancer cells grow, up to killing their host--> with the end result that the cancer cells colony will die too !

- And Humans will grow up to the point of destruction of their earth --> with the plaisant end for humans that we can imagine!

We all may just need some kind of PIDs ;-) to find the right points of balances (if  they exist) ! 

Sorry guys, tonight i saw once more the movie " schindler's list " at it reminded me a bit how all that human history is quite hard!

I see too much collective stupidity across all those century's ! 

Even the people who think/invent the future (eg: like us) are doing things blindly (thinking very short term). (we have created torture machines, ziklon B, the atomic bomb, pesticides that finally are killings not only insects (yes, insect are animals like us:-) ), ... )

Again, Sorry for the bad ambiance I am putting here today ;-)

Let us continue playing with FPGAs, even if we don't really know why we are doing it :-))

Have a nice weekend !

Ps: Tomorrow, maybe i will see the " Openheimer" movie. And to finish beautifully the day, i may even see "Barbie" just after :-))

--

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.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/088db8ce-219b-4589-a634-0e1d08acc775n%40googlegroups.com.

[Democrito]

Este post es sólo para la gente que lo lea en el futuro y esté interesada:

(continúa en este nuevo hilo)

Smooth position PID control with AS5600: https://groups.google.com/g/fpga-wars-explorando-el-lado-libre/c/0G47sEt-7WY