Cuando un robot coloca una pieza en una línea de montaje, evita chocar con un operario y al mismo tiempo ajusta la fuerza para no deformar el material, no está “pensando” en abstracto. Está ejecutando ciclos estrictos de control en milisegundos, tomando decisiones con sensores ruidosos y actuadores que nunca obedecen con exactitud perfecta. Ese mundo, el de la computación y robótica en tiempo real sobre sistemas embebidos, es más prosaico que la ciencia ficción y bastante más exigente. Exige entender el hardware, dominar el software de bajo nivel y aceptar que cada milisegundo cuenta.
He pasado semanas puliendo controladores que reaccionan en 500 microsegundos, y otras tantas persiguiendo un jitter que parecía fantasmal pero terminaba siendo un bus SPI mal terminado. Uno aprende a desconfiar de las suposiciones, medir todo y priorizar lo que de verdad importa: la seguridad, la determinismo temporal y la robustez frente a fallos.
Qué significa “tiempo real” en robotica
La pregunta “qué es robotica” suele responderse con un catálogo de brazos, móviles y drones. La respuesta más útil para ingeniería separa la función cognitiva del control temporal. Tiempo real no significa “rápido” a secas, significa que una tarea debe completarse dentro de una ventana temporal conocida. Hay dos sabores: en tiempo real duro, un incumplimiento es inaceptable, por ejemplo en el control de estabilidad de un dron. En tiempo real blando, hay margen de degradación, como en una interfaz gráfica.
En robotica y automatizacion y robotica industrial, gran parte del sistema cae en tiempo real duro. El lazo de control de una articulación necesita ejecutar a 1 kHz, el módulo de seguridad debe cortar potencia en menos de 10 milisegundos si se abre una compuerta, y el bus de comunicación con los drives tiene que garantizar latencia acotada, no el promedio. Esta diferencia entre latencia media y peores casos distingue a un robot robusto de un prototipo simpático.
Sistemas embebidos: donde vive el control
Un sistema embebido es un computador específico integrado en la máquina. No hay teclado ni escritorio, hay placas con microcontroladores, FPGAs, SoCs y buses de campo. En robotica educativa, un kit con un microcontrolador ARM Cortex-M y algunos sensores sirve para enseñar conceptos. En una célula de ensamblaje, la arquitectura se compone de un PLC de seguridad, controladores de motor, un HMI, y a menudo un ordenador industrial para visión y planificación.
Las decisiones de arquitectura importan. Un microcontrolador M7 a 400 MHz con RTOS puede cerrar lazos a 10 kHz sin despeinarse, pero sufrirá con visión por computadora. Un SoC con Linux en tiempo real soporta ROS 2, redes TSN y modelos de IA ligeros, aunque requerirá más trabajo para acotar la latencia. He visto brazos con diseño híbrido: FPGA para el lazo de corriente y velocidad, MCU para el lazo de posición y coordinación, y un PC industrial para percepción y planificación. Es más complejo, pero cuando se necesita precisión de micras y movimientos suaves, esa separación rinde.
La cadena de control: de sensores a actuadores
Sensar, estimar, decidir, actuar. Ese ciclo, a intervalos regulares, es la esencia. Los sensores llegan con ruido, retardos y sesgos. Un codificador incremental de 20.000 pulsos por vuelta puede ofrecer gran resolución angular, pero sus flancos pueden perderse si la lectura por GPIO no está debidamente filtrada o si hay rebotes eléctricos. Un IMU barato en un robot móvil sirve para estabilización básica, pero necesita fusión con odometría y, si es posible, con visión o Lidar para corregir deriva.
En un proyecto de AGVs, el estimador que más estabilidad dio combinaba un EKF para estado de pose con un filtro complementario rápido para el cabeceo. El truco fue sincronizar sellos de tiempo en hardware, no confiar en el reloj del sistema operativo. La deriva de pocos milisegundos entre sensores se notaba en curvas cerradas y provocaba oscilaciones. Sincronización primero, fusión después.
La decisión se materializa en controladores. PID bien sintonizados siguen siendo reyes para la mayoría de los ejes industriales. La ley no es el problema, la discretización, el anti-windup y la compensación de fricción sí lo son. Cuando se trabaja con pórticos pesados, la fricción estática rompe la linealidad. Un feedforward de fricción de Coulomb y viscosa, combinado con un planificador de trayectoria con jerk limitado, evita tirones. Para manipuladores flexibles o robots blandos, el control robusto o basado en modelos, incluso MPC simplificado, ayuda a manejar dinámica acoplada. Pero cada kilobyte en un sistema embebido cuesta, y un optimizador cuadrático en microsegundos obliga a simplificar modelos, aprovechar tablas precalculadas y vectorizar con cuidado.
Determinismo, jitter y por qué arruinan buenas intenciones
El jitter, esa variación en el momento real de ejecución de una tarea periódica, convierte un controlador estable en uno torpe. Una tarea programada a 1 kHz con ±50 microsegundos de jitter quizá soporte un sistema mecánico pesado, pero en un dron o un robot delta rápido ese margen rompe la fase de lazo y dispara vibraciones. Es común que la gente culpe al PID cuando el verdadero culpable es un bus compartido que bloquea la CPU con una ISR mal diseñada o una cola de mensajes sin prioridad.
Las herramientas importan: un RTOS que permita prioridades, herencia de prioridad para evitar inversión, y temporizadores basados en hardware. En Linux, los parches PREEMPT_RT, el aislamiento de CPUs, el uso de clock monotonic raw y la afinidad de hilos reducen jitter. Aun así, para lazo de corriente submilisegundo, prefiero sacarlo del dominio de la CPU y usar PWM y control en FPGA o en el propio drive.
Comunicaciones en la práctica: buses, topologías y tiempos
EtherCAT, CANopen, PROFINET, Modbus, TSN sobre Ethernet. Cada opción tiene latencias y garantías distintas. EtherCAT brilla cuando se necesita sincronización precisa de múltiples ejes, con jitter en el rango de microsegundos y ciclos de 250 microsegundos sin drama. CAN es robusto y simple, ideal para móviles con muchas ECU, pero su ancho de banda limita. He desplegado redes con CAN FD a 2 Mbps para sensores y comandos de bajo volumen, y EtherCAT para drives, dejando Ethernet estándar para HMI y registro.
En ambientes ruidosos, el cableado y la conexión a tierra explican más fallos que el software. Una vez, un brazo fallaba aleatoriamente cada 3 horas. Tras descartar el código, medimos con un osciloscopio: transitorios de 200 V inducidos por arranques de motores cercanos entraban por el cable de señal de un encoder sin trenzar ni blindar. Cambiar el cable y añadir ferritas resolvió el misterio. Antiestético, pero efectivo.
Seguridad funcional: la capa que nunca se negocia
La seguridad no es una función opcional ni un “modo demo”. En automatizacion y robotica industrial, normas como ISO 13849 o IEC 61508 fijan niveles de Performance Level o SIL. Esto impacta en componentes y software: dupla de canales redundantes, diagnósticos periódicos, paradas de emergencia cableadas, relés de seguridad, PLCs certificados. El mejor patrón que he visto es separar el control funcional del control de seguridad. El primero puede correr ROS 2, planificar rutas, hacer visión. El segundo detecta puertas abiertas, cortinas de luz, velocidad segura, y corta energía sin pedir permiso.
El diseño de software lo refleja. Las rutas de error deben ser cortas, con watchdogs independientes que vigilen el lazo crítico. En un cobot, la función de “velocidad y separación” exige estimar distancia persona-robot con fiabilidad y latencia acotada. Si la percepción duda, el robot desacelera. Los límites blandos del software nunca reemplazan a un relé de seguridad cableado, pero sí pueden reducir falsas paradas y mejorar la ergonomía.
Energía, térmica y longevidad de los embebidos
Un tópico que se ignora hasta que aparece tarde: disipación térmica y suministro estable. Un control embebido trabajando al 80% de CPU por horas en un gabinete mal ventilado terminará haciendo throttling o fallando. Si la CPU reduce frecuencia, el lazo pierde su periodo. Medir potencia, prever picos y sobredimensionar fuentes con margen del 30% ahorra disgustos. En una célula con servos grandes, la regeneración de energía al frenar ejes puede reinyectar tensión en el bus. Sin resistencia de frenado adecuada, se disparan protecciones y todo se detiene.
También cuentan la suciedad y la humedad. Conectores con IP correcto, respiraderos con filtros y conformal coating en PCBs cuando el ambiente es agresivo. Nada más frustrante que bugs fantasma causados por condensación.
El rol de ROS 2 y el software moderno, con los pies en la tierra
ROS 2 ha conquistado gran parte de la computacion y robotica no puramente industrial. Permite modularidad, descubrimiento automático, tipos de mensajes bien definidos y herramientas de depuración. Su modo de comunicaciones DDS con QoS configurables da control sobre fiabilidad, persistencia y latencia. El problema es su huella y la complejidad. En control duro aconsejo una frontera clara: los nodos que corren lazo rápido en C o C++ con RTOS, y ROS 2 para coordinación, planificación y telemetría. El middleware no es un sustituto del determinismo de hardware.
En mis proyectos, un patrón efectivo es exponer al mundo ROS 2 una interfaz desacoplada: sendas de posición, estados discretos, alarmas. Debajo, un scheduler de tiempo real maneja los hilos críticos. Si ROS 2 se reinicia o pierde la red, el core del robot continúa en un estado seguro definido.
Educación: de robotica educativa a criterio de ingeniería
“Que es robotica” no se aprende solo con definiciones, se aprende con la primera vez que un robot hace algo inesperado por un delay escondido. En robotica educativa, se puede enseñar bien el concepto de tiempo real con ejercicios sencillos: leer un sensor a 1 kHz, medir jitter con un pin de diagnóstico y un osciloscopio, observar cómo una función de logging mal colocada rompe el ciclo. Mostrar imágenes de robotica con montajes limpios, cableado ordenado y esquemas de tierra ayuda, pero la experiencia de medir y corregir arraiga mejores prácticas.
A estudiantes les propongo una meta concreta: un seguidor de línea que mantenga el error RMS por debajo de un valor en un circuito, con límite de latencia para el lazo. No vale solo “funciona”, vale “funciona dentro de estos tiempos”. Ese cambio de mentalidad los aproxima a la realidad de un entorno industrial.
Percepción en tiempo real: visión y sensores en el borde
Integrar visión en tiempo real en sistemas embebidos ya no es exótico. Un SoC con GPU modesta puede ejecutar modelos de detección compactos y extraer pose de piezas para pick-and-place. El reto es la latencia de extremo a extremo: exposición de cámara, transferencia, inferencia, postproceso y comando al actuador. En una célula que armaba packs, recortar 15 milisegundos al pipeline permitió elevar el throughput un 8%. Se logró bajando la resolución justo al mínimo que conservaba la tasa de aciertos, ejecutando inferencia en lotes de 2 y usando preprocesamiento en la ISP del sensor en lugar de la CPU.
Otra técnica subestimada es la predicción. Si la cámara te da la pose de una pieza con 30 milisegundos de retraso y el conveyor se mueve a 0,5 m/s, tu estimación está desplazada 15 milímetros. Un simple modelo de movimiento más timestamping preciso corrige el error. No hace falta un gran modelo si el reloj y la cinemática están bien.
Planificación de movimiento con límites reales
Planificadores polinomiales con límites de velocidad, aceleración y jerk producen trayectorias suaves que la mecánica agradece. La sorpresa llega cuando el drive o el lazo no sostienen la frecuencia de muestreo requerida. Una trayectoria que exige actualizaciones a 2 kHz pero el canal solo entrega 500 Hz genera microparadas que se sienten como vibraciones. Por eso insisto en cerrar lazo lo más cerca del motor posible y transmitir consignas a una frecuencia que el bus garantiza.
El tema de singularidades en manipuladores también necesita criterio. En una empresa de embalaje, un pick-and-place fallaba esporádicamente en una esquina del espacio de trabajo. No era “mala suerte”, era la cercanía a una singularidad de velocidad. El planificador fue modificado para evitar ciertas configuraciones Ver sitio web y añadir replanificación local si el Jacobiano perdía condición. Menos del 1% del tiempo de ciclo cambió, y los fallos desaparecieron.
Mantenimiento predictivo y registro de datos sin romper el tiempo real
Registrar datos a alta frecuencia permite diagnosticar y robotica anticipar fallos, pero escribir a disco o a red dentro del hilo crítico es mala idea. Un patrón probado: un buffer circular lock-free captura muestras con timestamp, y un hilo de baja prioridad drena hacia almacenamiento. Cuando hay presión, se descartan muestras con estrategia clara, nunca se bloquea el lazo. Con 64 kB por canal, se pueden mantener segundos de historial a 2 kHz, suficiente para post mortem. Para tendencias, tasas más bajas con agregados estadísticos funcionan bien.
El valor real aparece cuando se combina vibración, corriente de motor y temperatura. Un aumento paulatino de corriente RMS a igual carga y una firma de vibración con armónicos específicos suele indicar alineación deficiente o rodamientos fatigados. Con alertas que no generen ruido, el equipo de mantenimiento actúa antes de que una parada inesperada consuma un turno.
Pruebas, validación y lo que de verdad detecta fallos
Las pruebas en mesa ayudan, las pruebas con hardware real descubren lo que importa. Hago tres tipos: pruebas unitarias con temporizadores falsos y modelos de sensor para capturar lógica; pruebas de integración con hardware en condiciones controladas; pruebas de estrés con ruido, cortes de red, picos térmicos y variaciones de suministro. Un robot al que le simulas perder el encoder durante 50 milisegundos te enseña si el sistema hace una parada segura o entra en pánico.
El etiquetado de versiones y la trazabilidad son serios. En una planta, dos robots “iguales” respondían distinto. La diferencia era una compilación con optimizaciones conservadoras que alteraba la latencia de ISR. Desde entonces, parte del procedimiento de entrega incluye hash del binario, configuración del compilador y versión de firmware de cada drive. No es burocracia, es repetibilidad.
Sostenibilidad y consumo: más allá del marketing
En fábricas grandes, reducir consumo es dinero. A veces basta con bajar la corriente en reposo de servos, apagar iluminación de HMI fuera de turno, y optimizar trayectorias para minimizar picos de aceleración. Otras veces, la oportunidad está en evitar rechazos. Un calibrado estable que sostenga tolerancias evita retrabajos y desperdicio. En robótica móvil, planificar rutas que reduzcan giros cerrados alarga la vida de ruedas y baterías. El mejor kilovatio es el que no se usa, y al diseñar controladores con jerk limitado, no solo se cuida la mecánica, se baja la potencia pico.
Visualización y comunicación sin saturar al equipo
Las imágenes de robotica que vemos en catálogos son limpias, pero operar un robot exige interfaces que muestren lo esencial. En la HMI, prefiero tres vistas: estado del sistema con semáforos claros, vista de alarmas con descripciones accionables y tendencias de señales clave. Nada de menús interminables. Un operario debe entender qué hacer ante una alarma sin leer un manual. La documentación técnica sí debe existir, versionada y accesible, pero la primera línea es la interfaz.
Para el equipo de ingeniería, un dashboard de telemetría con latencias, tasas de paquetes perdidos y CPU por hilo ayuda más que cien logs crípticos. En un arranque, una gráfica simple que mostraba jitter del lazo principal permitió correlacionar picos con tareas de visión que se disparaban en paralelo. Ajustar prioridades y afinidad resolvió el cuello de botella.
Cómo decidir la plataforma correcta: ejemplos concretos
- Si construyes un brazo de 6 ejes para carga media y precisión submilimétrica, usa drives con lazo de corriente interno, EtherCAT para sincronización de ejes, un MCU con RTOS para interpolación a 2 kHz y un PC industrial con ROS 2 para planificar y supervisar. Mantén la seguridad en un PLC separado. Si desarrollas un robot móvil ágil, combina un SoC con Linux RT para percepción ligera y navegación, un microcontrolador dedicado al control de motores y freno, y CAN FD para sensores distribuidos. Implementa fusión de sensores con timestamp en hardware y watchdogs independientes.
Estas dos configuraciones capturan la mayoría de necesidades en automatizacion y robotica industrial y también escalan hacia equipos más modestos o más ambiciosos.
Riesgos típicos y cómo evitarlos
El primer riesgo es sobrecargar el sistema con ambición tecnológica. Meter un modelo enorme de visión en el mismo procesador que cierra el lazo suele terminar en latencias variables. Separar preocupaciones y, cuando sea posible, separar hardware. El segundo riesgo es subestimar la EMC. Probar en laboratorio limpio no predice el entorno industrial con variadores, soldaduras y picos. Cables trenzados, blindajes, tierras bien pensadas, y pruebas con inyección de ruido ahorran meses.
El tercer riesgo es humano: interfaces confusas y falta de formación. Una sesión corta de capacitación que muestre patrones de fallo y respuestas estándar eleva la disponibilidad. La robotica educativa, cuando se hace con cariño técnico, forma operadores y técnicos que no solo “usan”, también entienden y resuelven.
Qué queda por delante
Los límites entre control clásico y aprendizaje se van difuminando. Métodos de identificación de modelos online, controladores que ajustan parámetros en tiempo real y herramientas de verificación formal para tareas críticas se vuelven más accesibles. Las redes deterministas con TSN integradas en switches comunes prometen reducir costos de integración. Aun así, los principios no cambian: medir, garantizar tiempos, diseñar para fallos y mantener la seguridad como norte.
Para quien empieza y pregunta “que es robotica” o “que es la robotica” con ganas de construir, la respuesta útil es esta: es el arte de lograr que una máquina perciba, decida y actúe a tiempo, siempre, bajo incertidumbre. Es también un oficio que se aprende con práctica, con osciloscopio, destornillador y perfiles de CPU, no solo con simulaciones. Un buen sistema embebido no se nota, y esa discreción es señal de que alguien hizo su trabajo con cuidado.