Controlador AGV para Robots Móviles: Tipos, Especificaciones y Cómo Elegir el Correcto

Cada componente de un sistema de transmisión AGV —servos accionamientos, motores, mecanismos de elevación, módulos de dirección— recibe sus comandos de una única fuente: el controlador del vehículo. El controlador lee la retroalimentación del codificador, interpreta los comandos de navegación del sistema de gestión de flotas, ejecuta perfiles de movimiento, supervisa las entradas de seguridad y coordina simultáneamente todos los actuadores del vehículo. Es el componente que determina no solo lo que el vehículo puede hacer, sino también con qué precisión y fiabilidad lo hace.

A pesar de este papel central, la selección del controlador de AGV a menudo se trata como un problema de integración de software en lugar de una decisión de especificación de hardware. Los ingenieros se centran en el entorno de programación y el soporte de protocolos de comunicación, mientras subestiman la capacidad de procesamiento, la arquitectura de E/S, el rendimiento en tiempo real y la continuidad del suministro a largo plazo, especificaciones que determinan si el controlador puede soportar la capacidad total del vehículo durante toda su vida útil.

Esta guía cubre las principales arquitecturas de controladores utilizadas en aplicaciones de AGV y AMR, las especificaciones de hardware y software que rigen la selección, cómo se integra el controlador con los componentes del sistema de transmisión y los criterios que distinguen a los socios proveedores capaces a largo plazo de los proveedores de placas de productos básicos.

Qué hace un controlador AGV y por qué es importante

El controlador AGV —también llamado controlador del vehículo, controlador de movimiento o controlador maestro, según la arquitectura del sistema— realiza varias funciones simultáneamente en tiempo real.

En cuanto al control de movimiento, recibe comandos de posición, velocidad o trayectoria del sistema de navegación y los traduce en comandos de velocidad y posición coordinados para cada servoaccionamiento del vehículo. Lee la retroalimentación del codificador de las ruedas motrices y los ejes de dirección para mantener la odometría —una estimación continua de la posición y la dirección del vehículo basada en el recorrido de la rueda— y utiliza esta retroalimentación para ejecutar perfiles de movimiento con la precisión y repetibilidad requeridas por la aplicación.

En cuanto a la comunicación, mantiene un intercambio continuo de datos con los servos accionamientos a través de CAN bus, EtherCAT u otros protocolos de bus de campo, procesa las entradas de los sensores de seguridad y los circuitos de parada de emergencia, y comunica el estado del vehículo al sistema de gestión de flotas a través de Wi-Fi o Ethernet cableada.

En cuanto a la seguridad, supervisa las entradas críticas para la seguridad —zonas de escáner láser, contactos de parachoques, botones de parada de emergencia, sensores de presencia de carga útil— y ejecuta respuestas de estado seguro definidas cuando se violan las condiciones de seguridad. En sistemas que requieren certificación de seguridad funcional, el controlador debe ejecutar funciones de seguridad con tiempos de respuesta y niveles de fiabilidad documentados.

El controlador debe hacer todo esto simultáneamente, de forma determinista y sin fallos durante años de funcionamiento continuo en varios turnos. Las decisiones de selección del controlador tomadas en el momento del desarrollo del vehículo no se pueden revertir fácilmente después de la implementación de la producción.

Principales arquitecturas de controladores AGV

Controlador de movimiento AGV dedicado

Un controlador de movimiento AGV dedicado es una unidad de hardware diseñada específicamente para el control de vehículos robot móviles, no adaptada de un PLC, PC industrial o plataforma informática de uso general. Estos controladores suelen integrar el procesamiento de control de movimiento, E/S de seguridad, interfaces de bus de campo y puertos de comunicación en una única unidad reforzada optimizada para el tamaño, la potencia y las limitaciones ambientales de un chasis de robot móvil.

Las ventajas de los controladores dedicados son significativas para los programas de AGV de producción: la combinación de hardware y software está prevalidada para aplicaciones AGV, lo que reduce el esfuerzo de integración y el tiempo de puesta en marcha; el factor de forma mecánico está diseñado para el montaje en el chasis con una tolerancia adecuada a las vibraciones y una gestión térmica; y la estructura de soporte del proveedor se organiza en torno a los requisitos de la aplicación AGV en lugar de la automatización industrial general.

La consideración principal con los controladores AGV dedicados es la dependencia del proveedor: el hardware y el software suelen estar estrechamente acoplados, y cambiar de proveedor de controladores a mitad del programa requiere un esfuerzo de reingeniería significativo.

Controlador basado en PLC

Los controladores lógicos programables de los principales proveedores de automatización industrial (Siemens, Beckhoff, Omron y otros) se utilizan como controladores de vehículos AGV en algunas aplicaciones, especialmente cuando el vehículo se integra con la infraestructura de automatización de fábrica existente utilizando la misma plataforma de PLC. Los PLC ofrecen entornos de programación maduros, amplia disponibilidad de opciones de E/S y vías de certificación de seguridad establecidas.

Las limitaciones en las aplicaciones AGV se relacionan con el factor de forma, el rendimiento del control de movimiento en tiempo real y el coste. El hardware PLC estándar está diseñado para el montaje en panel en equipos estacionarios, no para la integración en chasis de robots móviles compactos con exposición a vibraciones y limitaciones de espacio. Los tiempos de ciclo de control de movimiento y el procesamiento de retroalimentación del codificador pueden no cumplir los requisitos de rendimiento de las aplicaciones AGV de alta velocidad o alta precisión sin módulos de control de movimiento especializados. El coste total del sistema suele ser mayor que el de las soluciones de controlador AGV dedicadas para una capacidad equivalente.

Controlador SBC integrado

Las plataformas de computadora de placa única (SBC), que normalmente ejecutan Linux con extensiones de kernel en tiempo real, se utilizan como controladores AGV en investigación, desarrollo y algunas aplicaciones de producción donde la flexibilidad del software y la arquitectura abierta son prioridades. ROS (Robot Operating System) se utiliza comúnmente en estas plataformas como marco de software para navegación, procesamiento de sensores y control de movimiento.

Los controladores basados en SBC ofrecen la máxima flexibilidad de software y acceso a un gran ecosistema de código abierto de algoritmos de navegación, percepción y control de movimiento. Las compensaciones son significativas para la implementación de AGV de producción: el rendimiento en tiempo real depende de la calidad de la implementación del software y la configuración del sistema en lugar de las garantías de hardware; la fiabilidad durante un funcionamiento continuo de varios años requiere una gestión térmica cuidadosa y la selección de medios de almacenamiento; y la ausencia de E/S de seguridad de hardware dedicadas complica la certificación de seguridad funcional.

Arquitectura de controlador distribuido

En las arquitecturas distribuidas, las funciones de control del vehículo se dividen en varios nodos de procesamiento (un procesador de navegación y gestión de misiones, uno o varios procesadores de control de movimiento para los ejes de accionamiento y un procesador de seguridad dedicado) conectados a través de una red interna del vehículo. Esta arquitectura proporciona un margen de procesamiento para tareas de navegación y percepción computacionalmente intensivas sin comprometer el determinismo de las funciones de control de movimiento y seguridad, que se ejecutan en procesadores dedicados con tiempos de ciclo garantizados.

Las arquitecturas distribuidas son más complejas de diseñar e integrar que las soluciones de un solo controlador, pero se adaptan mejor a las plataformas AMR de alto rendimiento que combinan una navegación sofisticada con exigentes requisitos de control de movimiento. Son cada vez más comunes en robots móviles autónomos, donde la construcción simultánea de mapas, la evitación de obstáculos y la ejecución precisa del movimiento plantean demandas de procesamiento que un único controlador no puede satisfacer sin compromiso.

Especificaciones clave para la selección del controlador AGV

Rendimiento de procesamiento en tiempo real

El control de movimiento de AGV requiere una ejecución determinista: el controlador debe completar su ciclo de control dentro de un tiempo de ciclo máximo garantizado, independientemente de cualquier otra actividad de procesamiento. Para las tasas de actualización de comandos de servoaccionamiento, los tiempos de ciclo de bucle de control de 1 ms a 10 ms son típicos, según los requisitos de velocidad y precisión de la aplicación. Para la monitorización de funciones de seguridad, los tiempos de respuesta de 10 ms a 100 ms son requisitos comunes según la norma de seguridad aplicable.

Verifique que las especificaciones de rendimiento en tiempo real del controlador estén garantizadas por hardware, no por software. Un controlador cuyo tiempo de ciclo se especifica como típico en lugar de máximo no puede proporcionar la garantía de rendimiento requerida para funciones de control de movimiento críticas para la seguridad.

Soporte de interfaz de comunicación

El controlador AGV debe comunicarse simultáneamente con múltiples subsistemas: servoaccionamientos a través de bus de campo, sistema de gestión de flotas a través de Ethernet inalámbrica, sensores de seguridad a través de E/S discretas o bus de campo de seguridad, y opcionalmente con sensores de navegación como escáneres láser o cámaras a través de Ethernet o USB.

CAN bus y CANopen siguen siendo las interfaces más utilizadas para la comunicación de servoaccionamientos en aplicaciones AGV debido a su robustez y amplia compatibilidad. EtherCAT se utiliza cada vez más en aplicaciones críticas para el rendimiento que requieren tasas de actualización más rápidas. Confirme que el controlador es compatible con la variante de protocolo específica —no solo con la interfaz física— utilizada por los servoaccionamientos en el tren motriz del vehículo. Como se señaló en la selección de servoaccionamientos, una capa física CAN que ejecuta un protocolo propietario no se comunicará con dispositivos CANopen incluso con conectores idénticos.

Capacidad y expansión de E/S

El controlador debe tener suficientes canales de E/S digitales y analógicas para conectar todos los sensores de seguridad, elementos de interfaz de operador, sensores de carga útil y funciones auxiliares. Cuente los puntos de E/S requeridos para la especificación completa del vehículo, incluidas las características opcionales de la fase de desarrollo, antes de seleccionar un controlador, y elija una plataforma con un margen de expansión significativo. Los controladores seleccionados con la capacidad de E/S mínima para la especificación inicial del vehículo con frecuencia requieren un rediseño cuando se agregan funciones durante el desarrollo o cuando el diseño del vehículo se adapta para una nueva variante de aplicación.

Integración de funciones de seguridad

La mayoría de las aplicaciones de AGV y AMR en almacenes requieren que el controlador del vehículo ejecute funciones de seguridad funcional (parada de emergencia, monitoreo de campo protector, limitación de velocidad segura) que deben cumplir con los niveles de rendimiento definidos en las normas de seguridad aplicables, como ISO 13849 o IEC 62061. Los controladores con E/S de seguridad integradas y bibliotecas de funciones de seguridad certificadas reducen el esfuerzo de ingeniería requerido para lograr la certificación de seguridad en comparación con los controladores de propósito general donde las funciones de seguridad deben implementarse y validarse completamente en el software de aplicación.

Confirme que la arquitectura de seguridad del controlador (redundancia de hardware, cobertura de diagnóstico, mitigación de fallas de causa común) coincide con el nivel de rendimiento requerido para la aplicación prevista. Las afirmaciones de rendimiento de seguridad deben estar respaldadas por documentación de certificación de terceros, no solo por la autodeclaración del fabricante.

Temperatura de funcionamiento y clasificación ambiental

El controlador AGV funciona dentro del chasis del vehículo, un entorno que puede alcanzar temperaturas elevadas debido al calor residual del motor, la producción térmica de la batería y la ventilación limitada. El rango de temperatura de funcionamiento nominal del controlador debe cubrir la temperatura interior esperada del chasis durante un funcionamiento continuo a plena carga, incluida la variación ambiental estacional en la instalación.

Se prefieren los controladores con gestión térmica pasiva (sin ventiladores de refrigeración internos) para aplicaciones AGV donde el fallo del ventilador es un evento de mantenimiento inaceptable y donde el ruido del ventilador es indeseable en entornos logísticos silenciosos. El funcionamiento sin ventilador requiere un diseño de controlador de baja potencia o un acoplamiento térmico adecuado a la estructura del chasis para la disipación del calor.

Cómo se integra el controlador AGV con el sistema de accionamiento

El controlador se sitúa en la parte superior de la jerarquía de control del vehículo: genera comandos de movimiento que fluyen hacia los servodrives, que ejecutan esos comandos a nivel del motor e informan del estado al controlador en tiempo real.

La interfaz de comandos de movimiento entre el controlador y los servodrives debe especificarse en detalle durante el diseño de la arquitectura del vehículo. El tipo de comando —posición, velocidad o par— y la tasa de actualización deben coincidir entre la capacidad de salida del controlador y la capacidad de entrada del servodrive. Un controlador que actualiza los comandos de velocidad cada 10 ms a drives que esperan actualizaciones cada 1 ms causará inestabilidad en el control. Un controlador que envía comandos de par a drives configurados para el modo de velocidad producirá un comportamiento impredecible.

La integración de la odometría (acumulación de pulsos del codificador de las ruedas motrices para estimar la posición del vehículo) debe implementarse prestando atención a la resolución del codificador, la calibración del diámetro de las ruedas y el modelo geométrico del tren de transmisión específico del vehículo. Los vehículos de propulsión diferencial, de una sola rueda directriz y de varias ruedas directrices tienen modelos de odometría diferentes, y los errores en los parámetros geométricos del modelo se traducen directamente en una imprecisión de la navegación que no puede corregirse ajustando el sistema de propulsión.

La integración de funciones de seguridad requiere que las salidas de seguridad del controlador (señales de habilitación de accionamiento, comandos de par seguro desactivado, salidas de monitoreo de velocidad) estén conectadas a las entradas de seguridad del servoaccionamiento de una manera que logre el tiempo de respuesta requerido desde la activación del sensor de seguridad hasta la desenergización del accionamiento. Toda la cadena de seguridad (sensor a controlador, a accionamiento, a motor) debe validarse como un sistema, no probarse de forma aislada a nivel de componente.

Errores comunes en la selección de controladores AGV

Seleccionar basándose en la familiaridad con el entorno de software en lugar de la especificación de hardware. Los equipos de desarrollo familiarizados con un lenguaje o marco de programación en particular a veces seleccionan el controlador que admite ese entorno en lugar del controlador cuya especificación de hardware se adapta mejor a la aplicación. Los entornos de software se pueden adaptar; el rendimiento del hardware en tiempo real, la arquitectura de E/S y las características térmicas no.

Infraespecificación de E/S para la variante del vehículo de producción. Los vehículos de desarrollo suelen llevar menos sensores y menos funciones opcionales que las variantes de producción. Un controlador seleccionado para un número mínimo de E/S en un prototipo de desarrollo puede no tener capacidad de expansión para los sensores de seguridad, las interfaces de carga útil y los paneles de operador añadidos en el diseño de producción.

Suponer que la certificación de seguridad se transfiere de componente a nivel de sistema. Un controlador con una arquitectura de seguridad certificada no produce automáticamente un sistema AGV seguro certificado. La certificación de seguridad del vehículo completo depende de la implementación de funciones de seguridad en el software de aplicación, la integración de sensores y actuadores de seguridad y la validación del tiempo de respuesta de la cadena de seguridad completa. La certificación del controlador es una condición necesaria pero no suficiente para el cumplimiento de la seguridad del vehículo.

Ignorar la continuidad del suministro para los programas de producción. Los programas de producción de AGV pueden durar de cinco a diez años. Un controlador basado en un procesador o FPGA de una sola fuente con un ciclo de vida de producción limitado crea un riesgo de suministro que se materializa a mitad del programa, ya que la obsolescencia de los componentes obliga a rediseñar el hardware. Evalúe las políticas de ciclo de vida del producto del proveedor y la estrategia de abastecimiento de componentes antes de comprometerse con una plataforma de controlador para un programa de producción en volumen.

Qué buscar en un proveedor de controladores AGV

Diseños de referencia de aplicaciones AGV y datos de validación. Un proveedor con diseños de referencia documentados para arquitecturas de transmisión AGV —transmisión diferencial, rueda de dirección única, multieje— y datos de validación de implementaciones de vehículos reales proporciona una guía más fiable que un proveedor que ofrece hardware de control de movimiento de propósito general con notas de aplicación AGV como algo secundario.

Soporte de hardware y software integrado. El rendimiento del controlador AGV depende de la interacción entre las capacidades del hardware y la implementación del firmware. Los proveedores que ofrecen tanto el hardware como el firmware, y que consideran la optimización del algoritmo de control de movimiento, la implementación de funciones de seguridad y el desarrollo de controladores de comunicación como parte de su alcance de soporte de productos, reducen significativamente la carga de integración del equipo de desarrollo del vehículo.

Arquitectura de seguridad documentada para aplicaciones de seguridad funcional. Para aplicaciones que requieren certificación de seguridad funcional, el proveedor debe proporcionar un manual de seguridad, documentación FMEA y evidencia de certificación de terceros para la arquitectura de seguridad del controlador. El nivel de documentación proporcionada es un indicador fiable de si las afirmaciones de seguridad del proveedor están respaldadas por ingeniería o son solo de marketing.

Compromiso de suministro de componentes a largo plazo. Confirme la estabilidad de la lista de materiales del controlador y la política del proveedor para gestionar la obsolescencia de los componentes. Un proveedor con una garantía de ciclo de vida del producto documentada (normalmente de cinco a siete años de disponibilidad de producción con aviso anticipado de interrupción) proporciona la visibilidad de planificación de suministro necesaria para programas de producción de AGV de varios años.

Preguntas frecuentes

¿Cuál es la diferencia entre un controlador AGV y un sistema de gestión de flotas?

El controlador AGV está a bordo del vehículo: controla los motores del vehículo, lee sus sensores y ejecuta comandos de movimiento en tiempo real. El sistema de gestión de flotas se ejecuta en una infraestructura externa, normalmente un servidor o una plataforma en la nube, y coordina las misiones, el tráfico y las asignaciones de tareas de múltiples vehículos en la instalación. El controlador y el sistema de gestión de flotas se comunican a través de Wi-Fi o Ethernet cableada, con el sistema de flotas enviando comandos de misión de alto nivel y el controlador del vehículo ejecutándolos localmente.

¿Necesita cada eje del motor AGV su propio controlador?

No. Un único controlador del vehículo suele gestionar todos los ejes de transmisión del vehículo (motores de tracción, motores de dirección y mecanismos de elevación) mediante conexiones de bus de campo a los servodrives individuales. El controlador envía comandos coordinados a todos los drives y recibe retroalimentación de todos los ejes dentro de cada ciclo de control. El control multieje desde un único controlador es estándar en las arquitecturas AGV.

¿Qué protocolo de comunicación es el más común entre los controladores AGV y los servoaccionamientos?

El bus CAN que ejecuta el protocolo CANopen es la interfaz más utilizada para la comunicación de controlador de AGV a servoaccionamiento en aplicaciones de robots móviles de almacén. Es robusto, de baja complejidad de cableado y ampliamente compatible con los fabricantes de servoaccionamientos. EtherCAT se está adoptando cada vez más en plataformas críticas de rendimiento que requieren tasas de actualización de sub-milisegundos. RS485 y Modbus siguen siendo comunes en diseños sensibles al costo.

¿Se puede usar un PLC industrial estándar como controlador de vehículos AGV?

Sí, en aplicaciones apropiadas. Los PLC con módulos de control de movimiento pueden cumplir los requisitos de control de vehículos AGV, particularmente para vehículos más simples que operan en entornos estructurados. Las limitaciones prácticas se relacionan con el factor de forma para la integración del chasis móvil, el rendimiento del tiempo de ciclo de control de movimiento en comparación con los controladores dedicados y el costo total del sistema. Para aplicaciones AMR de alto rendimiento que requieren una navegación en tiempo real sofisticada y una ejecución de movimiento precisa, los controladores AGV dedicados o las arquitecturas distribuidas suelen proporcionar mejores relaciones rendimiento-costo que los PLC industriales generales.

¿Qué norma de seguridad se aplica a los controladores de vehículos AGV?

La ISO 3691-4 es la norma de seguridad principal para los AGV industriales, que especifica los requisitos para el vehículo como sistema, incluidas sus funciones de control. La ISO 13849 y la IEC 62061 proporcionan los marcos de seguridad funcional utilizados para evaluar el nivel de rendimiento de las funciones de seguridad específicas implementadas en el controlador. El marcado CE para los sistemas AGV desplegados en los mercados de la UE requiere el cumplimiento de la Directiva de Máquinas, siendo la ISO 3691-4 la norma armonizada relevante. Los proveedores de controladores dirigidos al mercado de AGV deben estar familiarizados con estas normas y sus implicaciones para el diseño de la arquitectura del controlador.

Conclusión

El controlador AGV no es un componente genérico, es el elemento del sistema que determina la precisión del movimiento del vehículo, el cumplimiento de la seguridad y la fiabilidad operativa a largo plazo. Las decisiones de selección del controlador tomadas durante el desarrollo del vehículo no se pueden revertir fácilmente después del despliegue en producción, lo que hace que acertar la especificación en el momento del diseño sea una de las decisiones de ingeniería de mayor influencia en un programa AGV.

Evaluar los controladores en cuanto a rendimiento de procesamiento, determinismo en tiempo real, compatibilidad de la interfaz de comunicación, arquitectura de seguridad y continuidad del suministro del proveedor —en lugar de la familiaridad con el entorno de software o el costo unitario solamente— produce selecciones que respaldan la capacidad de rendimiento total del vehículo a lo largo de su vida útil y evitan los rediseños de hardware a mitad de programa que resultan de opciones de controlador subespecificadas.