Aprendizaje de robots vs. robótica clásica: cuándo usar cada uno (2026)
Aprendizaje robótico vs robótica clásica: un marco de decisión práctica que cubre las líneas de control de la percepción-planamiento-control, políticas aprendidas de extremo a extremo, arquitecturas híbridas y cuándo cada enfoque gana en 2026.
[← Blog]
El debate no se centra en saber qué paradigma es mejor, sino en saber cuál es el que se debe buscar en una situación determinada y, cada vez más, en cómo combinarlos en un solo sistema.
Robótica clásica: el flujo de percepción-planamiento-control
La robótica clásica sigue una línea de tuberías explícita y diseñada a mano. Los algoritmos de percepción (a menudo procesamiento estructurado de nube de punto, coincidencia con el modelo CAD o visión estéreo calibrada) producen una representación geométrica de la escena. Una capa de planificación (RRT*, CHOMP, optimización de trayectoria o control predictivo de modelo) calcula un camino libre de colisión hacia el objetivo. Una capa de control (PID, control de impedancia o control de par computado) rastrea la trayectoria planificada con garantías estrictas en tiempo real.
Los controladores clásicos operan a velocidades de control de 1 kHz con latencia determinista. proporcionan garantías formales de estabilidad a través del análisis de Lyapunov, restricciones de seguridad a través de funciones de barrera de control y óptimalidad de trayectoria a través de funciones de costo bien entendidas. No requieren datos de entrenamiento. Y cuando fallan, el modo de falla es típicamente interpretable: un error de percepción, un plan infactible o un desbordamiento de seguimiento. Para cualquier persona que despliegue robots en entornos donde un regulador le preguntará "por qué el robot hizo eso", el control clásico proporciona respuestas que las políticas aprendidas no pueden.
Las limitaciones son igualmente claras. Cada tubería diseñada a mano es frágil a condiciones que su diseñador no anticipó. Un módulo de percepción ajustado para piezas de metal cepillado falla en objetos transparentes. Un planificador de movimiento optimizado para una estación de trabajo estructurada falla en desorden. Un controlador de impedancia ajustado para agarrar rígido falla en objetos deformables. Extendiendo los sistemas clásicos a situaciones nuevas requiere más ingeniería, no más datos, y las escalas de costos con el número de casos de borde que necesita manejar.
Inmersión profunda con herramientas clásicas: IK, Planificación de movimiento, Control de fuerza
Comprender las herramientas específicas de la pila clásica es esencial para que los equipos evalúen qué componentes reemplazar con aprendizaje y cuáles conservar.
** Kinemática inversa (IK).** Dado un efecto final deseado, IK calcula los ángulos articulares que lo logran. Existen soluciones analíticas IK para robots 6-DOF con geometrías específicas (la mayoría de los brazos industriales) y se ejecutan en microsecondas. IK es fiable, rápido y bien entendido - casi nunca hay una razón para reemplazarlo con un componente aprendido. Incluso las políticas completamente aprendidas generalmente producen objetivos de efecto final que se convierten en comandos conjuntos a través de IK.
** Planificación de movimiento.** RRT* (Rápidamente explorando el árbol aleatorio, variante óptima) y sus derivados (BIT*, CHOMP, STOMP) computa trayectorias libres de colisión en el espacio conjunto o en el espacio de tareas. La limitación clave: el planificador necesita un modelo de colisión preciso de la escena, que requiere una geometría de objetos conocida (desde un modelo CAD) o percepción en tiempo real. En entornos desordenados y desconocidos, el cuello de botella de percepción hace que la planificación clásica sea frágil. MoveIt2 es el marco estándar de planificación de movimiento de código abierto, con soporte para la mayoría de los brazos de investigación.
** Control de fuerza.** El control de la impedancia y la admisión regula la interacción mecánica entre el robot y su entorno. El control de admisión invierte esto: el robot lee los datos del sensor de fuerza y par y genera correcciones de posición proporcionales al error de fuerza medido. Estos controladores son matemáticamente elegantes, ajustables y probables, pero requieren un conocimiento preciso de la dinámica del robot y los parámetros del modelo de contacto. Para una inmersión más profunda en la integración de la detección de fuerza, vea nuestra guía de detección de F/T.
El Clásico Percepción Pipeline. Una pila de percepción estructurada típica: cámara RGB-D captura una nube de puntos. Segmentación de plano elimina la tabla. Cluster Euclidiano aisla objetos individuales. Cada grupo de objetos se combina con una biblioteca de modelos CAD conocida (utilizando ICP o PPF) para estimar la posición de 6-DOF. Este pipeline es rápido (10-30ms por fotograma), preciso para objetos conocidos (estimación de postura submilimétrica), y falló por completo para objetos que no están en la biblioteca de modelos.
El aprendizaje de robots: políticas aprendidas de extremo a extremo
El aprendizaje robótico reemplaza las tuberías de ingeniería manual con modelos basados en datos. En [imitación de aprendizaje]
La ventaja definitorio de las políticas aprendidas es que manejan la complejidad perceptual y la variación ambiental de manera implícita. Una política entrenada en 500 demostraciones de "recoger la taza" en 30 tazas diferentes, 5 condiciones de iluminación y posiciones de mesa variadas aprende una representación que se generaliza a la taza 31 sin ninguna ingeniería de características explícita. La política no tiene un módulo de percepción, un módulo de planificación y un módulo de control. Tiene un único modelo que mapea los píxeles y la propriocepción a comandos conjuntos, y las abstracciones pertinentes se aprenden de los datos en lugar de diseñadas por ingenieros.
Las políticas aprendidas son opacas: cuando fallan, es difícil diagnosticar si el fracaso es perceptivo, relacionado con la planificación o un error de ejecución del control. Requieren datos de capacitación sustanciales, generalmente cientos a miles de demostraciones para el aprendizaje de imitación o millones de pasos de simulación para el aprendizaje de refuerzo. No ofrecen garantías formales de seguridad. Y su comportamiento puede cambiar de manera impredecible cuando el entorno de despliegue cambia incluso ligeramente de la distribución de la capacitación.
Cuando la robótica clásica gana
** Ensamblaje y mecanizado de precisión.** Tarea que requieren repetibilidad submilimétrica en geometría conocida. Cuando el entorno está completamente especificado y la física bien modelada, el control clásico es más rápido de implementar y más confiable en el funcionamiento.
Entornos conocidos y estructurados. Las líneas de montaje de automóviles, los envases farmacéuticos y los sistemas de clasificación logística con iluminación controlada, posiciones fijas de objetos y física predecible son el dominio natural de la robótica clásica. No hay razón para recopilar datos de entrenamiento cuando puedes escribir un controlador determinista que maneje cada situación que tu robot se encuentre.
Aplicaciones críticas para la seguridad. La robótica quirúrgica, los robots colaborativos que operan cerca de los seres humanos y cualquier implementación que requiera certificación regulatoria se benefician de las herramientas de verificación formales disponibles para el control clásico. Las funciones de barrera de control, el análisis de accesibilidad y los límites de trayectoria en el peor de los casos dan a los sistemas clásicos un nivel de seguridad que las políticas aprendidas aún no han logrado.
Requisitos de baja latencia. Las aplicaciones que requieren una respuesta de control de submillisecondas, como la selección y ubicación de alta velocidad, el equilibrio o el ensamblaje sensible al contacto, necesitan el tiempo determinista que proporcionan los bucles de control clásicos.
Cuando el aprendizaje del robot gana
Entornos no estructurados. La clasificación de artículos mixtos en contenedores de almacén, la navegación en hogares desordenados, la operación en cocinas o restaurantes donde los diseños de objetos cambian constantemente. La formación de una política aprendida sobre diversas demostraciones es un proyecto de recopilación de datos con rendimientos decrecientes pero continuos.
** Manipulación externa.** Las tareas que requieren coordinación a nivel de los dedos, manipulación de objetos deformables o interacción rica en contactos. Las políticas aprendidas que observan el resultado físico de sus acciones y se adaptan implícitamente a través de datos de capacitación manejan estas tareas de manera mucho más natural que cualquier controlador de ingeniería.
** Generalización entre instancias de objetos.** Cuando su robot necesita recoger cualquier taza, no una taza específica. Cuando su robot móvil necesita navegar por cualquier oficina, no un plano de piso específico. Cuando su robot de cocina necesita manejar cualquier marca de caja de pasta. En el momento en que su despliegue requiere manejar nuevas instancias dentro de una categoría, las representaciones aprendidas de diversos datos de capacitación se vuelven esenciales. La percepción clásica necesitaría una reingeniería para cada nueva variante de objeto.
Tascas que son difíciles de especificar programáticamente. "Lanejar la mesa hasta que parezca limpia". "Embala los artículos para que nada se mueva durante el envío. " "Arreglar las flores de manera atractiva". Estas tareas tienen criterios objetivos de éxito que los humanos evalúan fácilmente pero que son difíciles de expresar como funciones matemáticas de costo. El aprendizaje de imitación evita el problema de especificación por completo aprendiendo la tarea implícitamente a partir de demostraciones del comportamiento deseado.
Tabla de comparación de enfoque
| Dimension | Classical Robotics | Learned Policies | Hybrid |
|---|---|---|---|
| Control frequency | 1 kHz deterministic | 10-50 Hz variable | 100-1000 Hz (classical inner loop) |
| Novel objects | Requires new models | Generalizes from data | Learned perception + classical plan |
| Safety guarantees | Formal verification available | No formal guarantees | Classical safety envelope |
| Setup time | Weeks-months (engineering) | Days-weeks (data collection) | Weeks (both) |
| Debugging | Inspect each module | Black-box, need ablation | Learned modules harder |
| Deformable objects | Very difficult to model | Learns from demonstrations | Learned contact + classical motion |
| Scaling cost | O(edge cases) engineering | O(data diversity) | Both, but reduced |
Comparación de herramientas para equipos existentes
| Tool Category | Classical Stack | Learning Stack |
|---|---|---|
| Middleware | ROS2 Humble/Iron | LeRobot, RoboCasa, robomimic |
| Motion planning | MoveIt2, OMPL, Drake | N/A (end-to-end) |
| Perception | PCL, Open3D, FoundationPose | DINOv2, SigLIP (learned backbone) |
| Simulation | Gazebo, Drake | Isaac Sim, MuJoCo, Genesis |
| Control | ros2_control, impedance/admittance | ACT, Diffusion Policy, VLA inference |
| Languages | C++ (real-time), Python (scripts) | Python (PyTorch), C++ (deployment) |
El enfoque híbrido: percepción aprendida + planificación clásica + control aprendido
Los sistemas robóticos más capaces desplegados en 2026 son híbridos, y la arquitectura híbrida específica que ha surgido como dominante vale la pena entenderse en detalle.
Capa de percepción aprendida. Una red neuronal (a menudo un modelo de base de visión pre-entrenado como DINOv2 o CLIP, afinado en datos específicos de tareas) procesa imágenes de la cámara y produce una representación estructurada de escena: poses de objetos, etiquetas semánticas, normales superficiales, candidatos de captura. Esto reemplaza la percepción frágil de los sistemas clásicos con representaciones aprendidas que se generalizan a través de la iluminación, las texturas y las instancias de objetos.
Clasica capa de planificación. Un controlador predictivo modelo (MPC) o un planificador basado en muestras toma el estado de escena percibido y calcula una trayectoria sin colisiones y dinámicamente factible para lograr el objetivo de la tarea. Esta capa opera sobre la representación geométrica limpia del módulo de percepción y aplica todas las restricciones de seguridad, límites conjuntos y criterios de óptimalidad en los que la planificación clásica sobresale.
Control de bajo nivel aprendido. Para las tareas ricas en contactos, una política de residuos aprendida ajusta en tiempo real los comandos del controlador clásico basándose en la retroalimentación y las observaciones visuales del contacto. El controlador clásico proporciona la estructura de trayectoria general y el envoltorio de seguridad.
Esta arquitectura captura las fortalezas de ambos paradigmas. La percepción aprendida maneja la complejidad visual. El planificador clásico proporciona garantías de seguridad y comportamiento interpretable. El controlador residual aprendido maneja la dinámica de contacto que no se puede modelar analíticamente. Los sistemas de manipulación de Google DeepMind, varias células robóticas de almacén de Amazon desplegadas en producción y múltiples plataformas robóticas quirúrgicas utilizan variantes de esta arquitectura en 2026.
Camino de transición para los equipos de robótica clásica existentes
Si su equipo tiene una pila de robótica clásica en funcionamiento y quiere agregar capacidades de aprendizaje, aquí está el camino incremental recomendado que minimiza el riesgo:
- Fase 1: sustituye sólo la percepción. Cambiar su detección de objetos de ingeniería manual y la estimación de pose con un modelo aprendido (FoundationPose, Grounding DINO, o un detector DINOv2 ajustado). Mantenga su planificador y controlador clásico sin cambios. Esta es la introducción de aprendizaje de menor riesgo y generalmente proporciona la mayor mejora inmediata (el manejo de objetos nuevos sin modelos CAD). Línea de tiempo: 2-4 semanas de trabajo de integración.
- Fase 2: Agregue la planificación de la captura aprendida. reemplace su planificador de captura analítica (si lo hay) por un predictor de calidad de la captura aprendida (GraspNet, Contact-GraspNet o AnyGrasp).
- Fase 3: Agregue el control residual aprendido. Para tareas ricas en contacto donde su controlador de impedancia clásico tiene dificultades, entrene una política residual que añade correcciones a la salida clásica. Recoge 100-200 demostraciones de la fase de contacto solo (no la tarea completa). Línea de tiempo: 4-8 semanas, incluida la recopilación de datos.
- Fase 4: Evalúa de extremo a extremo. Una vez que tenga experiencia con los componentes aprendidos, evalúe si una política aprendida de extremo a extremo (ACT o Política de difusión) supera su pila híbrida en sus tareas específicas. Para las tareas de precisión, el enfoque híbrido suele seguir ganando.
RCSV puede proporcionar la recopilación de datos para cualquiera de estas fases a través de nuestros [servicios de datos]
Un marco de decisión práctico: cinco preguntas
Cuando inicie una nueva aplicación de robot, responda estas cinco preguntas para determinar su enfoque.
1. ¿Es el entorno completamente específico y estable? Si es así (línea de fábrica, sala limpia, celda de almacén estructurada), comience con el control clásico. Se desplegará más rápido y con mayor fiabilidad que cualquier enfoque aprendido. Si no (casas, restaurantes, almacenes no estructurados), se necesita aprender al menos en la capa de percepción.
2. ¿Necesitas manejar nuevas instancias de objetos? Si el robot se encuentra con objetos que nunca ha visto antes, necesitas una percepción aprendida y posiblemente una política aprendida. La percepción clásica requiere modelos explícitos de cada objeto.
3. ¿La tarea es rica en contacto o implica objetos deformables? Si es así, se necesita aprender en la capa de control. Los modelos de contacto clásicos son inadecuados para la manipulación deformables, el manejo de alimentos o tareas textiles.
4. ¿Necesita garantías formales de seguridad o certificación regulatoria? Si es así, su arquitectura de sistema debe incluir una capa de seguridad clásica, incluso si se aprenden otros componentes. Las funciones de barrera de control, la lógica de parada de emergencia y la aplicación de los límites del espacio de trabajo deben ser clásicas y verificadas formalmente. Los componentes aprendidos funcionan dentro del envolvente de seguridad definido por la capa clásica.
5. ¿Cuál es su presupuesto de datos? Las políticas aprendidas requieren demostraciones (cientos para [aprendizaje de imitación](
Aplicación de la taxonomía: elegir un algoritmo
Dentro del paradigma de aprendizaje, la elección del algoritmo tiene implicaciones dramáticas para los requisitos de datos, los costos de computación y las características de implementación. Esta taxonomía mapea el paisaje a partir de 2026.
| Algorithm | Data Source | Eficiencia de Muestreo | Reward Required? | Best Use Case |
|---|---|---|---|---|
| Clonación de Comportamiento (BC) | 50-500 demos | High | No | Short-horizon tasks with consistent strategy |
| ACT (Action Chunking) | 50-200 demos | High | No | Bimanual tasks, long-horizon with action chunks |
| Diffusion Policy | 200-1000 demos | Medium | No | Multimodal tasks with multiple valid strategies |
| VLA Fine-Tune (Octo/OpenVLA) | 20-200 demos | Very High | No | Novel object generalization, language-conditioned tasks |
| PPO (on-policy RL) | 10M-100M sim steps | Low | Yes (dense preferred) | Locomotion, continuous control with clear reward |
| SAC (off-policy RL) | 1M-50M sim steps | Medium | Yes | Dexterous manipulation in sim, sample-efficient RL |
| GAIL / IRL | 10-50 demos + sim | Medium | Learned from demos | Few demonstrations + good simulator available |
| Model-Based RL (Dreamer, MBPO) | 100K-1M steps | High (for RL) | Yes | Data-limited RL where world model can be learned |
La decisión práctica para la mayoría de los equipos de manipulación en 2026: comenzar con ACT o Política de difusión (aprendizaje de imitación), pasar a VLA afinado si necesita generalización entre objetos o condicionamiento de lenguaje, y reservar RL para la locomoción o casos en los que usted tiene un simulador preciso y una función de recompensa clara. GAIL y RL basado en modelos ocupan papeles de nicho por ahora.
Modos de falla de tuberías clásicos por etapas
Comprender exactamente cómo fallan las líneas de conducto clásicas ayuda a los equipos a identificar qué etapas reemplazar con aprendizaje y cuáles mantener.
| Pipeline Stage | Failure Mode | Trigger Condition | Impact |
|---|---|---|---|
| Perception | Object not detected | Novel object geometry, transparent/reflective material | Complete task failure (no target) |
| Perception | Pose estimate off by >5mm | Symmetrical objects, partial occlusion, glare | Grasp misalignment, placement error |
| Planning | No feasible path found | Dense clutter, narrow passages, conflicting constraints | Task abort or timeout |
| Planning | Stale scene model | Dynamic environment, objects moved between perception and execution | Collision with moved objects |
| Control | Tracking overshoot | Aggressive trajectories, under-damped PID gains | Impact damage, position error at target |
| Control | Inadequate contact model | Deformable objects, unknown friction, compliant surfaces | Crush damage, slip, grasp failure |
| Integration | Timing desync between modules | High CPU load, ROS2 DDS congestion, GC pauses | Stale data used for planning, jerky execution |
El patrón es claro: las fallas de percepción dominan en entornos no estructurados, las fallas de planificación dominan en escenas desordenadas y las fallas de control dominan en tareas ricas en contacto. Los equipos deben reemplazar con el aprendizaje la etapa que causa más fallas en su despliegue específico, y mantener clásicas las etapas que están trabajando confiablemente.
El patrón de política residual: añadir aprendizaje al control clásico
El patrón de política residual es la forma más segura de introducir el aprendizaje en un sistema clásico existente. En lugar de reemplazar el controlador clásico, una política residual aprendida agrega correcciones en la parte superior de la salida clásica. La acción total ordenada es:
# residual_policy.py -- Classical + learned residual controller
import numpy as np
import torch
class ResidualPolicyController:
"""Adds learned corrections to classical impedance controller."""
def __init__(self, classical_controller, residual_model, max_residual=0.005):
self.classical = classical_controller
self.residual = residual_model # Trained policy network
self.max_residual = max_residual # 5mm max correction
def compute_action(self, obs, ft_reading, target_pose):
# Classical controller: impedance control toward target
a_classical = self.classical.compute(obs["joint_pos"], target_pose, ft_reading)
# Learned residual: correct for contact dynamics
with torch.no_grad():
residual_input = torch.cat([
torch.tensor(obs["joint_pos"]),
torch.tensor(ft_reading), # Force-torque sensor
torch.tensor(obs["wrist_image"]).flatten()
])
a_residual = self.residual(residual_input).numpy()
# Safety clamp: residual cannot exceed max_residual per joint
a_residual = np.clip(a_residual, -self.max_residual, self.max_residual)
return a_classical + a_residual
Este patrón se ha implementado con éxito en tareas de inserción (peg-in-hole, apareamiento de conectores), donde el controlador clásico maneja la trayectoria de aproximación y la política residual maneja las correcciones de fase de contacto que requieren sensibilidad para forzar la retroalimentación. En RCSV, utilizamos este patrón con el [OpenArm 1]
Comparación de los requisitos computacionales
El coste de la infraestructura de cada enfoque es muy diferente, y los equipos deben comprender estos requisitos antes de comprometerse con una arquitectura.
| Resource | Classical Pipeline | IL (ACT / DP) | VLA Fine-Tune | RL (Sim) |
|---|---|---|---|---|
| Training GPU | None | 1x RTX 3090/4090 | 1-4x A100/H100 | 1-8x A100 (Isaac Sim) |
| Training time | N/A (hand-tuned) | 2-8 hrs | 12-48 hrs | 24-120 hrs |
| Inference GPU | None (CPU only) | 1x RTX 3060+ | 1x A100 or H100 | Same as IL at deploy |
| Inference latency | < 1 ms | 20-100 ms | 200-500 ms | Same as IL at deploy |
| Disk/storage | < 100 MB (URDF, configs) | 50-200 GB (dataset) | 200 GB-2 TB | 50-500 GB (replay buf) |
| Engineering labor | High (weeks-months) | Medium (data + train) | Low-medium (fine-tune) | High (sim engineering) |
| Cloud cost estimate | $0/month | $50-200/train run | $500-3,000/train run | $1,000-10,000/run |
Estos costos son para un ciclo de capacitación de una sola tarea. Las políticas de tareas múltiples, barridos de hiperparámetros y recopilación de datos iterativa multiplican los números en consecuencia. Los equipos con presupuestos ajustados deben considerar el servicio de recopilación de datos de RCSV (T15), que amortiza los costos de hardware y operador en múltiples proyectos.
Análisis de los modos de falla: diagnóstico de sistemas clásicos frente a los sistemas aprendidos
Cuando un sistema robótico falla, el diagnóstico de la causa raíz sigue vías fundamentalmente diferentes dependiendo del paradigma.
Modos de falla de tuberías clásicos:
- ** Fallo de percepción.** La nube de puntos es ruidosa, el objeto no se detecta, o la estimación de la posición está fuera de la tolerancia del controlador.
- ** Fallo de planificación.** El planificador no devuelve ninguna solución (infectible), tiempo fuera o produce una colisión. Diagnóstico: visualizar la escena de planificación y los objetos de colisión en RViz2.
- ** Fallo de control.** El robot sobrepasa el objetivo, oscila o no mantiene contacto. Diagnóstico: error de seguimiento de la posición de la articulación de la trama, perfiles de velocidad y señales de fuerza-torque.
- ** Fallo de integración.** Problemas de tiempo entre módulos - el planificador utiliza una salida de percepción obsoleta, o el controlador recibe una actualización de trayectoria a mediados de la ejecución.
Modos de fallas de políticas aprendidos:
- Cambio de distribución. El objeto está en una posición, orientación o condición de iluminación que no está suficientemente cubierta por los datos de entrenamiento. Diagnóstico: compara la observación de fallas con la distribución de entrenamiento (por ejemplo, mediante el cálculo de distancias integradas utilizando el codificador de visión de la política).
- Mode averaging. La política de salida de la media de dos estrategias válidas, produciendo una trayectoria que coincide con ninguna de las dos.
- Erro de composición. La política se desvía de la trayectoria después de 20-30 pasos y no se puede recuperar. Diagnóstico: rastrear el error de acción por paso a lo largo del tiempo y observar la divergencia acelerada.
- ** Desajuste de calibración.** Los extrínsecos de la cámara se desplazaron entre la recopilación y el despliegue de datos, causando una constante compensación espacial en las acciones de política.
Una trampa común: los equipos a menudo culpan al componente aprendido por fallos que son realmente causados por problemas de infraestructura clásica (transformaciones TF estables en ROS2, extrínsecas de cámara calibradas incorrectamente, límites articulares incorrectos de URDF). Esta "control de cordura clásica" captura el 30-40% de las fallas informadas del sistema aprendido en RCSV.
La asimetría clave: las fallas clásicas son generalmente más rápidas de diagnosticar porque cada módulo tiene entradas y salidas inspectables. Las fallas de políticas aprendidas requieren inferencia sobre la distribución de datos de entrenamiento, lo que es inherentemente más difícil.
Estudios de casos en el mundo real
Estos ejemplos ilustran cómo la elección entre enfoques clásicos, aprendidos y híbridos se desarrolla en la práctica.
Caso 1: inserción de conectores electrónicos (ganas clásicas). Un fabricante contratado necesitaba un robot para insertar conectores USB-C en tomas de PCB. Un controlador de impedancia clásico con búsqueda en espiral en el punto de inserción logró un 99,2% de éxito en 10.000 ensayos. No se necesitaban datos de entrenamiento.
Caso 2: Recoger contenedores de almacenamiento (aprender ganancias). Un centro de cumplimiento de comercio electrónico necesitaba un robot para recoger artículos arbitrarios de contenedores que contenían más de 50 categorías de SKU. Los artículos iban desde bolsas blandas a cajas rígidas hasta electrónica de forma extraña. Una estimación de postura clásica + plan de planeamiento de agarre logró un 78% de éxito en la recopilación, limitado por fallos de percepción en objetos nuevos y reflectores. Un sistema aprendido con una columna vertebral DINOv2 logró un éxito de selección del 93% en todas las categorías, incluidos los elementos nunca vistos durante el entrenamiento.
Caso 3: Plaqueo de alimentos (ganas híbridas). Una empresa de preparación de alimentos necesitaba un robot para placar los ingredientes de la ensalada en un arreglo estéticamente agradable. Un planificador de alto nivel ha generado la composición basada en imágenes de entrenamiento de comidas envasadas. El sistema híbrido ha logrado una tasa de aceptación del 87% de los evaluadores de calidad humana, en comparación con el 62% para un sistema completamente clásico basado en reglas y el 79% para una política de extremo a extremo completamente aprendida.
MoveIt2 + Percepción Aprendizaje: Un ejemplo híbrido mínimo
Para los equipos que buscan construir su primer sistema híbrido, aquí está el patrón de integración mínimo usando MoveIt2 para la planificación de movimiento con un detector de objetos aprendido que reemplaza la percepción clásica.
# hybrid_pick.py -- Minimal hybrid: learned perception + classical planning
import rclpy
from moveit2 import MoveIt2
from groundingdino import GroundingDINO
import numpy as np
def hybrid_pick(node, moveit, detector, camera, prompt="the red mug"):
# --- Learned perception layer ---
rgb, depth = camera.capture()
detections = detector.predict(rgb, prompt) # GroundingDINO
best = max(detections, key=lambda d: d.confidence)
# Back-project 2D detection center to 3D using depth
cx, cy = best.center
z = depth[int(cy), int(cx)] / 1000.0 # mm to meters
x = (cx - camera.cx) * z / camera.fx
y = (cy - camera.cy) * z / camera.fy
target_pose = [x, y, z, 0, 0, 0, 1] # position + quaternion
# --- Classical planning layer (MoveIt2) ---
# Pre-grasp: approach from above
pre_grasp = target_pose.copy()
pre_grasp[2] += 0.10 # 10cm above
moveit.move_to_pose(pre_grasp)
# Grasp: descend with impedance control
moveit.move_to_pose(target_pose, velocity_scaling=0.3)
moveit.close_gripper(force=20.0) # 20N grip
# Lift
lift_pose = target_pose.copy()
lift_pose[2] += 0.15
moveit.move_to_pose(lift_pose)
Este ejemplo de 25 líneas captura la esencia del patrón híbrido: un modelo aprendido (GroundingDINO) maneja la complejidad perceptual de encontrar objetos arbitrarios a partir de descripciones de lenguaje, mientras que MoveIt2 maneja la planificación de trayectorias sin colisiones con límites conjuntos y restricciones de velocidad adecuadas. En RCSV, nuestros [OpenArm 1]
Los requisitos de datos comparados
El control clásico requiere datos de identificación del sistema: posición conjunta, velocidad, par y lecturas de sensores de fuerza-torque de experimentos de calibración cuidadosamente diseñados.
El aprendizaje de imitación normalmente requiere de 200-1,000 episodios de demostración por tarea, cada uno con imágenes de cámara sincronizadas y estado del robot a 30-50 Hz. El tiempo de recogida oscila entre 2 horas (200 demostraciones de una tarea simple) y 2 semanas (1,000 demostraciones de una tarea compleja con diversos objetos). La calidad de los datos domina la cantidad: 200 demostraciones limpias superan a 1,000 ruidosas. Para obtener más información sobre el coste de la recogida, consulte nuestro [Costo por análisis de demostración]
El ajuste del modelo de fundación (desde Octo, OpenVLA o RT-2) requiere mucho menos demostraciones específicas de tareas, típicamente 50-200, porque el modelo pre-entrenado proporciona un fuerte previo visual y conductual. Este es el enfoque más práctico para los equipos con presupuestos de datos limitados que necesitan comportamiento aprendido. Los modelos pre-entrenados están disponibles a través del ecosistema [Open X-Embodiment]
El aprendizaje de refuerzo requiere un entorno de simulación que modelen con precisión la física de las tareas. El reto es [transferencia sim-a-real]
Aprendizaje de políticas residuales: lo mejor de ambos mundos
El aprendizaje de políticas residuales es una arquitectura híbrida específica que coloca una corrección aprendida en la parte superior de un controlador clásico. El controlador clásico proporciona un comportamiento de base (por ejemplo, moverse a la posición de destino, aplicar la fuerza de inserción), y la red residual aprendida produce pequeñas correcciones (normalmente +/- 5 mm en posición, +/- 5 grados en orientación) que adaptan el comportamiento para manejar la variabilidad que el controlador clásico no puede.
Esta arquitectura tiene varias ventajas concretas sobre el aprendizaje de extremo a extremo:
- Seguridad por construcción. El residual está limitado - la red aprendida sólo puede desviarse en una cantidad limitada de la trayectoria clásica. Incluso si el componente aprendido falla por completo (salida ceros), el controlador clásico sigue ejecutando un comportamiento razonable.
- Eficiencia de muestra. La red residual sólo necesita aprender la corrección, no toda la trayectoria de manipulación. Esto reduce las demostraciones necesarias de 200-500 (fin a fin) a 50-100 (aprendizaje residual) para muchas tareas.
- Modos de falla interpretables. Cuando el sistema falla, puede comprobar si el controlador clásico o la corrección residual es culpable ejecutando el controlador clásico solo y comparando.
- ** Despliegue incremental.** Comience con el controlador clásico en producción, y luego añada la corrección residual cuando sea validada.
# residual_policy.py -- Classical + learned residual
import numpy as np
class ResidualPolicy:
"""Wrap a classical controller with a learned residual correction."""
def __init__(self, classical_controller, residual_network,
max_pos_residual=0.005, max_rot_residual=0.087):
self.classical = classical_controller
self.residual_net = residual_network
self.max_pos = max_pos_residual # 5mm
self.max_rot = max_rot_residual # 5 degrees in radians
def predict_action(self, observation):
# Classical controller produces baseline action
base_action = self.classical.compute_action(observation)
# Learned residual predicts correction from visual observation
raw_residual = self.residual_net(observation['image'])
# Clip residual to safety bounds
pos_residual = np.clip(
raw_residual[:3], -self.max_pos, self.max_pos)
rot_residual = np.clip(
raw_residual[3:6], -self.max_rot, self.max_rot)
# Apply correction to classical action
corrected_action = base_action.copy()
corrected_action[:3] += pos_residual
corrected_action[3:6] += rot_residual
return corrected_action
En las evaluaciones de RCSV, las políticas residuales logran consistentemente un 90-95% del rendimiento de extremo a extremo con 25-50% de los datos de entrenamiento. Excelen en tareas donde se conoce el comportamiento grueso (mover a objetar, insertar, colocar) pero se necesitan ajustes finos para la variabilidad de los objetos.
Camino de migración: pasar del clásico al híbrido al aprendido
Para los equipos con sistemas de robots clásicos existentes, la migración a componentes aprendidos debe seguir un enfoque gradual que gestione el riesgo y capte los beneficios del aprendizaje.
- Fase 1: Percepción aprendida, todo lo demás clásico (2-4 semanas). Substituir su pipeline de visión fija (segmentación, estimación de la posición) con un detector aprendido (GroundingDINO, SAM2) manteniendo la planificación y el control de impedancia de MoveIt2. Esto solo mejora típicamente la tasa de éxito en 10-25% en tareas que involucran objetos nuevos, sin cambios en la pila de control crítica para la seguridad. Riesgo: bajo.
- Fase 2: Agregar correcciones residuales (4-8 semanas). Recolectar 50-100 demostraciones donde el sistema clásico tenga éxito pero pueda ser más preciso o manejar más variantes de objetos.
- Fase 3: Política de aprendizaje de extremo a extremo con una capa de seguridad clásica (8-16 semanas). Para tareas en las que el límite de rendimiento de los enfoques híbridos es insuficiente, entrenar una política de aprendizaje de imitación completa en 200-500 demostraciones. El riesgo: moderado.
- Fase 4: ajuste del modelo de base (continuo). A medida que los modelos de base maduren, ajuste Octo o OpenVLA en sus datos específicos de tareas para una generalización máxima con una recopilación mínima de nuevos datos. Utilice la capa de seguridad clásica de la fase 3.
La mayoría de los clientes de RCSV están en la fase 1-2. El principio clave: nunca reemplace un componente clásico en funcionamiento por uno aprendido a menos que la versión aprendida demuestre que lo supera en su distribución de implementación específica. Los componentes aprendidos añaden capacidad pero también añaden modos de falla - el compromiso debe ser positivo.
La tendencia: el aprendizaje se expande, el clásico no desaparece
La trayectoria del campo es clara. El aprendizaje de robots se está expandiendo a dominios previamente dominados por el control clásico: montaje de fábrica, logística, inspección de calidad. Los modelos fundacionales están reduciendo los requisitos de datos que antes hacían impractical el aprendizaje para muchas aplicaciones. Y el patrón de arquitectura híbrida está haciendo posible añadir capacidades aprendidas incrementalmente a los sistemas clásicos sin reemplazar la infraestructura de seguridad y control clásica.
Pero la robótica clásica no está desapareciendo. Se está convirtiendo en el sustrato de seguridad y precisión sobre el que se superponen las capacidades aprendidas. El debate entre el aprendizaje y el clásico se está resolviendo en una cuestión de arquitectura: qué componentes se aprenden, qué son diseñados y cómo se interactúan.
Pruebas de sistemas híbridos: Protocolo de evaluación
La evaluación de un sistema híbrido requiere probar cada componente de forma independiente y luego probar el sistema integrado.
- Nivel 1: Evaluación de componentes. Prueba el módulo de percepción aprendido solo: ejecutalo en 100 imágenes retrasadas y mide la precisión de detección y el error de localización. Prueba el controlador clásico solo: déle poses de objetos de verdad y mide la tasa de éxito de captura. Ambos deben exceder el 90% individualmente antes de probar el sistema integrado.
- Nivel 2: Evaluación de integración. Conecte la percepción aprendida al controlador clásico y ejecute 50 ensayos de extremo a extremo. La tasa de éxito integrada será menor que la tasa individual de cualquiera de los componentes porque los errores de percepción se componen a través del controlador. Un sistema bien integrado pierde 5-15% de la tasa independiente del componente más débil.
- Nivel 3: Evaluación de robustez. Prueba el sistema integrado bajo perturbaciones: objetos nuevos, iluminación cambiada, posición de cámara desplazada.
Para los equipos que inician nuevos proyectos, RCSV apoya ambos paradigmas. Nuestros [servicios de datos]
Lectura relacionada
Guía de aprendizaje de imitación · Guía de detección de fuerza-torque · Guía de transferencia de Sim a realidad · Lista de verificación de despliegue · Comparación de brazos · Servicios de datos · Plataforma RCSV
Construye tu aplicación de robots
Ya sea que su proyecto necesite control clásico, políticas aprendidas o un híbrido de ambos, RCSV proporciona el hardware, datos y soporte de ingeniería para llevarlo a la implementación.
[Vea los servicios de datos]