Pulsos, grados, milímetros: Escalado de unidades

Uno de los temas que en ocasiones nos hace perder más el tiempo es el el escalado, o conversión de unidades de encoder (o resolver) a unidades de usuario (o de ingeniería), especialmente… cuando tenemos mecánicas o unidades con relaciones numéricas digamos que… poco agraciadas.

Los sistemas de realimentación de posición pueden se de muchos tipos, con diferentes construcciones mecánicas, pricipios físicos, con diferentes funcionalidades y protocolos: A/A, B/B, Z/Z, incremental, absoluto, marcas-codificadas, SSI, Endat, Tamagawa, lineal, rotativo, encoder, resolver, etc.. (dedicaremos un (o más de uno) post específico a este tema)

Pero… al final.. sea cual sea la naturaleza del sistema de realimentación, acabará traduciéndose en un valor de posición del motor que el motion controller utilizará para por ejemplo calcular el error de seguimento (bondad del perfil de movimiento) o por ejemplo para juzgar si se ha llegado a la posición comandada.

El valor que el servo sistema entrega al controlador de movimiento acostumbra a ser un valor en cuentas de encoder, es decir, un valor discretizado en función del número de bits de resolución del encoder.

Imaginemos un motor con un encoder de 13 bits de resolución. En este caso estamos hablando de un encoder que es capaz de de dividir (discretizar) la posición del motor dentro de una revolución en 8192 pulsos (2^13=8192).

Pero… en general nos resultará más agradable trabajar en unidades de usuario, p.e. una una revolución son 360º, no… 8192 pulsos, hay que tener en cuenta que existen encoders de 16,17,18,20 y más bits!… por lo que… sería deseable… poder trabajar en unidades de usario, más ‘humanas’, como p.e. los grados, revoluciones, etc…

La conversión entre cuentas de encoder y unidades de usuario es sencilla… por ejemplo para el caso del encoder de 13 bits (8192 pulsos por revolución) bastara con aplicar la siguiente conversión:

Conversión de 360º a 13 bits

Por tanto si por ejemplo queremos movernos 100º el controlador enviará un comando de posición al servosistema de (100º x (2^13)/360) y a su vez el controlador convertirá la realimentación del motor (codificada en 13 bits) a grados aplicando la relación inversa (360/2^13).
Con toda seguridad… el lector se habrá percatado de que 360/2^13 no da como resultado un número entero… por lo que en teoría a cada revolución se acumulará un error de cálculo de ésta.

Con toda seguridad el error propagado por la división no entera se traducirá en un error en la estimación que el controlador realiza de la posición del motor, es decir… por ejemplo en el caso de un eje rotativo que trabaje indefinidamente y que tenga un error de cálculo de un ‘pequeño’ pulso por vuelta, al cabo de 8192 revoluciones acumulará un error de 1 revolución!. (El caso de un eje lineal con recorrido finito pasa más desapercibido).

Imaginemos ahora que para más inri (y como acostumbra a ocurrir en la vida real) entre el motor y la carga tenemos reductores mecánicos, con relaciones de reducción que aún nos generen valores más ‘feos’…

Resulta claro… que el hecho de trabajar con decimales… es un problema…

SOLUCIÓN:

En la mayoría de servosistemas, es posible definir una relación de pulsos de entrada del controlador y pulsos de salida hacia el motor (Gear Ratio, Encoder Ratio,…)

Esta relación se puede definir en el propio servo, ó en el controlador, o en ambos…

Volviendo al ejemplo anterior, tenemos que:

Unidades de usuario 360 º por revolución

Pulsos por revolucion son 8192 (2^13).

Por tanto, lo que el servo (o el Motion controller) deberá hacer es un manejo de las unidades y los pulsos sin errores de cálculo. y en todo momento realizar las acciones o correcciones necesarias para asegurar que 8192 unidades de encoder correspondan con 360º, para ello, muchas veces lo que el dispositivo realiza son correcciones constantes teniendo en cuenta el resultado de la division entera MOD , y el RESTO.

Muchas veces resulta útil asignar éste trabajo al Servo (cuando el servo tiene parámetros para el gear ratio) de modo que el controlador trabajará con conversiones de unidades ‘enteras’ sin decimales.

En otras ocasiones será también posible definir en el propio controlador el ‘gear ratio’ del eje.

Sea como fuera, lo que no es recomendable es definir escalados de unidades con decimales. Para ello, la mayoría de controladores disponen de un par de parámetros en los que se define la relación entre cuentas de encoder y unidades por vuelta.

¿Qué hacer con las transmisines mecánicas?

Se puede dar el caso de tener un encoder de 13 bits (8192 pulsos por vuelta) y un engranaje con una relación 1:3 entre motor y carga.

Existen dos estrategias:

-Una opción es incluir el reductor en la relación de cuentas de encoder en el Controlador:
Cada (3 x 8192) cuentas se corresponde con 360º de revolución de la carga

-Otra opción (si el servo lo permite) es insertar la relación 1:3 en el el gear ratio del servo.

RESUMEN

En Definitiva, lo realmente importante es que seamos conscientes de que muchos de los problemas que puedan aparecer en una aplicación de control de ejes se deben a errores en la definición de la relación entre unidades de usuario y cuentas de encoder, por tanto debemos ser extremadamente cuidadosos en el momento de establecer dicha relación en el servo y el controlador.