¿Cuál sería un controlador de motor adecuado para este BLDC?

Estoy buscando reemplazar algunos motores paso a paso con un BLDC para obtener un funcionamiento más suave y una mayor velocidad. El motor BLDC que queremos usar es este.

Es un pequeño robot de 2 ejes que requiere un control de posición preciso, pero también quiero tener control de velocidad si es posible (en lugar de solo una entrada de paso y dirección). La velocidad máxima del motor es probablemente inferior a 100 RPM. El motor es sin sensor y encontré algunos controladores sin sensor como este pero no incorporan control de posición. De todos modos, el codificador de este motor es SPI, así que dudo que encuentre un controlador así.

Ya habrá otro procesador (basado en RPi) con la aplicación principal en ejecución, pero no es capaz de cumplir con los requisitos de alta velocidad de este control de motor en tiempo real, por lo que debe haber otro controlador externo. Pensé que un controlador de motor como el de arriba con una pequeña MCU para cerrar el ciclo de posición podría funcionar, pero entonces, ¿por qué no hacer que la MCU haga todo el trabajo (aparte del desarrollo de firmware adicional requerido). Estaba mirando el PIC18F2431 que incluye un módulo de retroalimentación del motor.

En este caso, es probable que use UART o SPI para enviar perfiles de movimiento y obtener retroalimentación de posición y estado hacia/desde la MCU.

¿Alguna otra opción o factor que deba considerar?

Respuestas (1)

Para posicionamiento estático o de bajas revoluciones, no puede utilizar un controlador sin sensor normal porque la señal de fuerza contraelectromotriz es demasiado débil. Sin embargo, su motor tiene un codificador de 14 bits incorporado que mide el ángulo absoluto del rotor, lo que simplifica el diseño del controlador.

Un PIC18F2431 debería hacer el trabajo ya que tiene salidas PWM adecuadas para impulsar un motor BLDC trifásico (a través de un puente FET trifásico). El codificador se lee a través de SPI. No necesitaría el módulo de control de movimiento porque el codificador ya proporciona la información requerida. El firmware sería similar a un controlador de cardán sin escobillas, con la adición de control de velocidad angular.

Tenga en cuenta que los motores de cardán sin escobillas tienen una alta resistencia de devanado, lo que da como resultado una potencia de salida baja y una eficiencia deficiente en comparación con un motor convencional. Normalmente se alimentan con relaciones PWM bajas para evitar el sobrecalentamiento de los devanados.

Gracias @Bruce, buen punto sobre el EMF de baja velocidad. Entonces, ¿el codificador se usaría para la posición y la conmutación? ¿Puedo suponer que la posición estaría referenciada a los devanados de alguna manera físicamente? Noté en la hoja de datos que el codificador se puede poner a cero. Solo me preocupa que la posición del codificador sea arbitraria en relación con los devanados.
Con suerte, el sensor ya se ha programado con la posición cero correcta. De lo contrario, es posible que deba calibrarlo antes del primer uso.
Bruce, ¿tiene alguna idea sobre cómo se haría esa calibración? ¿Sería algo así como ajustar la referencia cero para lograr el par máximo?
Pase la corriente a través de 2 fases para establecer un ángulo específico, o gire el motor y compare los cruces por cero de back-emf con los valores del sensor quantumdevices.wordpress.com/2010/03/17/…
Excelente, gracias. El primer método parece obvio ahora, debería haber pensado en eso.