Cuando los servomotores cumplen con el código: una charla sobre esos momentos de integración que nos hacen rascar la cabeza

¿Alguna vez has tenido una experiencia así? ——El brazo robótico cuidadosamente diseñado de repente "golpea" en el momento crítico, no porque el motor esté roto, sino porque el software de control detrás de él es como un desastre y no se puede ajustar sin problemas. O bien, los parámetros de los servos en la línea de producción son obviamente perfectos, pero hay un retraso que es difícil de rastrear cuando se ejecuta en lotes. Se siente como si faltara la pieza más crítica del rompecabezas, lo que hace que la gente se sienta ansiosa e impotente.

De hecho, cuando muchos proyectos mecánicos llegan a una etapa posterior, el problema a menudo no reside en el hardware en sí. No importa cuán alta sea la precisión del servomotor y cuán rápida sea la respuesta del mecanismo de dirección, si la arquitectura de software detrás de él no puede seguir el ritmo, todo el rendimiento se verá comprometido. En este momento, "escribir las mejores prácticas de microservicios" ya no es solo un tema técnico, sino que se ha convertido en la clave para la implementación fluida del proyecto.

¿Por qué su hardware siempre se atasca en el software?

Imagínese esto: usted diseña un brazo robótico de múltiples articulaciones, en el que cada articulación es impulsada por un servomotor independiente. ¿Qué pasaría si toda la lógica de control se reuniera en un programa enorme? Modificar los parámetros de una articulación puede afectar accidentalmente a otra; Si desea actualizar una función determinada, debe volver a probar todo el sistema. Más a menudo, cuando es necesario reemplazar o ajustar un motor, el esfuerzo de adaptación por parte del software es sorprendentemente grande.

Éste es el clásico dilema de una arquitectura monolítica: ata todo demasiado, no es lo suficientemente flexible y es difícil de mantener. En los sistemas mecánicos, la flexibilidad y la mantenibilidad son las piedras angulares de un funcionamiento estable a largo plazo.

Microservicios: Dale a cada motor una "habitación independiente"

¿Qué cambios pueden traer los microservicios? En pocas palabras, es como asignar una habitación separada a cada módulo funcional. El control del servomotor es un servicio, la supervisión del estado del mecanismo de dirección es otro y la planificación de la trayectoria del movimiento puede ser otro. Se comunican entre sí a través de interfaces claras, en lugar de verse apiñados en un espacio e interferir entre sí.

¿Cuál es el beneficio más directo de hacer esto? Aislamiento. Si se requiere la lógica de conducción de un determinado motor, solo es necesario cambiar el servicio correspondiente sin preocuparse por afectar otras partes. También se ha mejorado la escalabilidad: si una determinada articulación requiere un control de mayor frecuencia, solo es necesario fortalecer los recursos de servicio correspondientes sin reconstruir todo el sistema.

Pero aquí surge la pregunta: los microservicios suenan muy bien, pero ¿por qué muchos equipos terminan en más caos después de probarlos? Porque el método es incorrecto.

Escriba bien los microservicios: evite los errores que "parecen correctos"

Muchas personas quisieron dividir los servicios en detalles extremadamente finos desde el principio, pero descubrieron que las llamadas entre servicios eran tan complicadas como un laberinto. De hecho, en el campo del control mecánico, la clave para dividir no es la cantidad, sino los límites funcionales. Una regla general es dividirlo según la unidad de control del dispositivo físico. Por ejemplo, un módulo servo dual responsable del enlace del eje XY debería existir como un servicio en lugar de dividir el eje X y el eje Y en dos.

Otro malentendido común es la búsqueda excesiva de uniformidad técnica. Los diferentes fabricantes de motores y los distintos modelos de métodos de accionamiento tienen sus propias características. Si insiste en utilizar el mismo protocolo de comunicación para cubrir todos los dispositivos, a menudo se agregarán capas de adaptación innecesarias. Una buena práctica es dar cabida a la especificidad del dispositivo dentro del servicio y proporcionar una API unificada externamente. comokpotenciaComo suele hacerse en las soluciones de integración: maneje las diferencias internamente y manténgalo simple externamente.

También está el desafío de la coherencia de los datos. Los sistemas mecánicos tienen requisitos extremadamente altos en cuanto a temporización y sincronización de estado. Un servicio actualiza la información de ubicación, mientras que otro servicio aún puede utilizar datos antiguos para los cálculos. En este momento, el modelo basado en eventos suele ser más confiable que la simple respuesta a una solicitud. Se envían notificaciones cuando cambia el estado y los servicios relevantes responden por sí solos, lo que puede reducir la espera y la dependencia.

Del papel al taller: Dejemos que la arquitectura cambie de verdad

No importa cuánta teoría hables, serán palabras vacías si no se ponen en práctica. En la operación real, hay varios nodos a los que vale la pena prestar especial atención:

En la etapa inicial, no se apresure a desmantelarlo. Primero utilice un servicio para ejecutar los procesos centrales, especialmente aquellos enlaces de control que requieren el mayor rendimiento en tiempo real. Por ejemplo, primero asegúrese de que un solo servomotor pueda ejecutarse completamente desde instrucciones hasta acciones, y luego considere cómo dividir la coordinación de múltiples ejes en servicios independientes.

Al dividir los servicios, pregúntese: "¿Cuánto código se debe cambiar si este módulo se cambia a un motor diferente?" Si la respuesta es un cambio importante, puede que no sea lo suficientemente independiente. Un buen servicio debería poder proteger los detalles del hardware.

En términos de métodos de comunicación, en escenarios de control mecánico, las colas de mensajes livianas suelen ser más adecuadas que los marcos RPC pesados. Porque es más capaz de adaptarse a las fluctuaciones ocasionales de la red entre dispositivos y no es fácil bloquearlo todo porque un determinado servicio está temporalmente ocupado.

Durante el proceso de prueba, no olvide simular el entorno de hardware. El hecho de que el servicio funcione sin problemas en un entorno de software puro no significa que no habrá problemas cuando se conecte un motor real. Establecer un proceso de prueba con un emulador puede detectar de antemano muchos riesgos de integración.

Cuando se trata de integración, este es probablemente el paso que requiere más paciencia. Los diferentes fabricantes de servomotores tienen sus propios hábitos de comunicación. Algunos prefieren el bus CAN, otros usan EtherCAT y otros proporcionan un SDK personalizado. El valor de los microservicios aquí es encapsular esta diversidad, de modo que las aplicaciones de la capa superior no necesiten preocuparse por cómo se comunica la capa inferior con el motor.kpotenciaEn algunos casos incluso mantuvieron un servicio de controladores independiente para un modelo de motor antiguo pero fiable, no por moda técnica, sólo por la estabilidad del sistema.

Hablemos: Intuición y racionalidad en la selección de tecnología

Elegir una arquitectura de microservicio a veces es como elegir un motor; por supuesto, hay que observar los parámetros, pero la experiencia y la intuición son igualmente importantes. No puedes esperar hasta que se completen todas las pruebas antes de tomar una decisión, el progreso del proyecto no espera a nadie. En este momento, aquellos modelos de práctica probada se convierten en referentes importantes.

Por ejemplo, en un bucle de control con altos requisitos en tiempo real, la granularidad del servicio debe ser aproximada en lugar de fina; en el lado de la recopilación y el análisis de datos, puede ser mejor para facilitar la expansión posterior. Por poner otro ejemplo, el manejo de errores no consiste en que cada servicio haga lo suyo, sino en establecer un mecanismo unificado de informe de fallas y de degradación; al igual que cuando un motor está sobrecargado, no se detiene inmediatamente, sino que se desacelera gradualmente de acuerdo con un plan preestablecido.

Estos detalles no serán demasiado específicos en el libro, pero son exactamente la clave para el éxito del proyecto. Requiere no sólo que usted comprenda la tecnología, sino también los equipos, los procesos e incluso algunos hábitos operativos en el taller.

Entonces, la próxima vez que se enfrente a un montón de servomotores y servos y le preocupen los problemas de integración, también podría cambiar de opinión: tal vez el problema no esté en la maquinaria, sino en los códigos que controlan ellos.构的好坏,不在于用了多新的技术,而在于它是否真的理解了这个行业的脾气.

Un pequeño consejo: el valor de la tecnología siempre surge a la hora de resolver problemas reales. Si también ha explorado escenarios de integración similares, puede comprender que detrás de esos principios arquitectónicos aparentemente aburridos se encuentra la condensación de problemas específicos. Encontrar un método práctico que se adapte a su propio escenario es más importante que perseguir una teoría perfecta.

Establecido en 2005,kpotenciase ha dedicado a un fabricante profesional de unidades de movimiento compacto, con sede en Dongguan, provincia de Guangdong, China. Aprovechando las innovaciones en tecnología de accionamiento modular, Kpower integra motores de alto rendimiento, reductores de precisión y sistemas de control multiprotocolo para proporcionar soluciones de sistemas de accionamiento inteligentes eficientes y personalizadas. Kpower ha brindado soluciones de sistemas de accionamiento profesionales a más de 500 clientes empresariales en todo el mundo con productos que cubren diversos campos, como sistemas domésticos inteligentes, electrónica automática, robótica, agricultura de precisión, drones y automatización industrial.