The robot programming gap separates the demonstration that starts a program from the program running in production six months later. An integrator or internal engineer translates the demonstration into joint targets, I/O triggers, and conditional branches. That translation loses information. The amount depends on programming skill and demonstration precision, but some loss is unavoidable when physical motion becomes a coordinate list.
We saw this cycle often enough to question the translation step. In many cases, it is unnecessary. A robot can learn directly from the demonstration instead of a programmer's interpretation.
Why Translation Exists
The robot programming gap begins with teach pendant programming, which requires a person to convert the task into robot language: joint angles, tool center point positions, approach vectors, and departure velocities. This specialized skill is often separate from manufacturing knowledge. Large automation shops manage that handoff. Small and mid sized manufacturers with one or two automation specialists face a bottleneck.
Kinesthetic demonstration, also called lead through programming, lowers the skill barrier. The operator moves the robot through the path while it records joint positions. This better reflects intent than manually coded waypoints, but it remains a fixed program. The positions are recorded, not understood. A moved part records an error, while changed grip pressure at a critical moment provides no usable context.
Learning from demonstration, or LfD, extracts task structure from demonstration data into a form the robot can generalize from. It has been researched for over two decades, yet the gap between research results and factory deployment remains wide.
Where the Gap Lives
The demonstration to deployment gap has several components. Identifying the dominant one determines which solution can help.
The first component is coordinate sensitivity. A world coordinate program assumes a fixed workpiece position. Fixturing drift by a few millimeters can make it fail. This is a common early production failure after integration handoff, and it does not require full LfD to address. Vision guided correction can register the program to the actual part position.
The second component is missing intent. The demonstration records physical motion, not why it took that shape. Slowing during approach may reflect changing force torque feedback and a search for insertion depth. The program records velocity, not the sensing behavior behind it. When geometry shifts, it lacks the cue that should trigger slowdown.
The third component is distributional mismatch between demonstration and production. Lighting, surface finish, and fixturing tolerances can differ. A policy trained in one context degrades in another unless it explicitly tolerates those factors.
What Our Approach Handles
In Neuralzome's learning pipeline, each demonstration becomes a trajectory of sensorimotor pairs. At each time step, we record sensor state, including vision, force torque, and joint position, plus the demonstrator's action. The extracted policy maps sensor state to action rather than storing positions. It learns when to slow from force feedback, not from a fixed velocity at time T.
The trained policy therefore generalizes better to small changes in part position, orientation, and surface properties. It does not handle arbitrary variation. It handles variation between demonstrations and production, including fixturing tolerances, part batch changes, and normal process drift. Deployed policies perform well on their demonstrated task within the covered operating envelope.
In an early access program, an assembly team demonstrated a PCB insertion task using 30 sample boards across two sessions. Occasional warping affected about 8% of samples. The policy handled warped boards without special cases because demonstrations included them and insertion force feedback captured the difference. A fixed program from a nominal board would have failed on warped ones.
The Deployment Workflow Problem
Moving from demonstration to policy is a technical problem. Moving from policy to production is a workflow problem. Offline validation is not enough. The policy must be qualified on the production line, and the production team needs confidence in its safe behavior before unsupervised operation.
We stage deployment. First, the policy runs in shadow mode beside the existing program, recording outputs without acting. Engineering compares its action distribution on live parts with validation results and detects significant distributional shift before production impact. Next, it runs with a human able to override actions. Fully autonomous operation comes last, after the ops team accepts behavior on its line.
This is slower than "train a demo, deploy a policy." It matches production software deployment in manufacturing. Skipping steps creates the trust deficit that can end an automation project after an unexpected event.
What This Does Not Solve
Learning from demonstration is not a replacement for good process design. It handles more variation than a fixed program, but low variation demonstrations will struggle with highly variable upstream geometry or surface finish. High variation belongs in the upstream process, not the robot control layer.
Some tasks need another input modality. Precision assembly with tight tolerances benefits from explicit geometric programming, where insertion depth is specified analytically rather than inferred. We do not advocate LfD everywhere. Choose the method that fits the task: explicit programming for repetitive, high precision work in stable settings, and learning from demonstration for varied, contact rich manipulation in changing settings.
Where We Are Now
The current demonstration pipeline handles pick and place, insertion, and light assembly where sensorimotor behavior carries useful task information. We are extending it to tasks combining visual and force based information, fused at the policy level rather than handled as separate channels. That work is harder, and we will update these notes as it progresses.