The mismatch became visible when a policy that tracked TCP motion on a lab UR10e produced different paths on customer hardware. Teams ask Neuralzome whether lab policies can run on production robots. Sometimes they can, but adjustment is usually required. This article identifies the discrepancies and our responses.
Cross platform policy transfer remains an active robotics research problem, and production is less tidy than academic benchmarks. Our early access pilots in 2024 and 2025 produced enough cases for a practical framework covering common failures. This approach does not generalize to every robotics task. It is designed for recurring platform transfer.
What Changes Across Platforms
A robot platform combines the manipulator, controller, and interface used by the Neuralzome runtime for commands and state. UR10e and FANUC are both 6 DOF articulated arms with similar reach and payload, yet their differences can change policy behavior.
Kinematic parameters: Link lengths, joint angle conventions, and the definition of the tool-center-point (TCP) frame differ between manufacturers. A policy trained to produce TCP-space velocity commands on a UR uses the UR's kinematic model implicitly. On a FANUC, the same command produces a different end-effector motion because the underlying joint configuration solving is different.
Control interface and latency: UR's RTDE interface delivers state feedback at 500Hz and accepts commands at 125Hz. FANUC's ROBOGUIDE-based PC interface typically runs at 50-100Hz with higher command-to-execution latency. The policy's action space was implicitly calibrated to the interface frequency during training. On a slower interface, the policy needs to be adapted to produce actions that are appropriate for the actual control frequency.
Friction and compliance profile: Each robot's joint friction model is different. A joint position command on a UR produces a motion with different friction-induced trajectory deviation than the same command on an ABB. For tasks with tight positional tolerances, this matters.
Sensor mounting and calibration: If the policy uses a wrist-mounted camera or force/torque sensor, the sensor's position and orientation relative to the robot's TCP differs between platforms. A camera that was mounted at a specific angle on the training platform will have a different field of view and pixel-to-world mapping on the target platform unless remounted identically.
The Observation Space Mismatch
Observation mismatch is the most common subtle failure. A policy maps observations to actions, so systematic differences between training and target observations can cause incorrect behavior even when the nominal task is unchanged.
Suppose the policy observes end effector pose. UR reports it in its base frame with UR conventions, while FANUC uses its base frame and another orientation convention. Feeding FANUC values as UR values corrupts spatial reasoning.
The usual remedy is normalizing observations into a common frame. The difficult part is finding every convention the policy learned. Some are documented in training configuration, while others come from undocumented data consistency. We have seen velocity feedback sign act as an implicit signal, so a platform change made deceleration appear to be acceleration.
Our transfer workflow audits observation space systematically. In a safe target configuration, we log observations during known motions and compare them with equivalent training logs. Differences beyond a threshold prompt normalization work before live deployment.
Action Space Adaptation
A policy outputting joint velocity commands at 125Hz on UR has a different physical effect at 50Hz on FANUC. Joint space intent is unchanged, but lower frequency produces coarser position steps and may alter following error.
An action space adapter sits between policy output and the controller, resampling actions to the target command frequency. It interpolates velocity commands and smooths position commands, preventing abrupt acceleration where command samples meet.
The platform specific adapter leaves policy weights unchanged, allowing deployment across platforms by changing configuration instead of retraining. A calibrated adapter handles 70 to 80% of mechanical discrepancy for most pick and place tasks. Contact sensitive tasks with tight force tolerances may still require target fine tuning.
Fine Tuning or Retraining
If adapter transfer is insufficient, fine tune the existing policy with target demonstrations or train a new target policy from scratch.
Fine tuning updates existing weights with a small target platform demonstration set. Since the task representation is already learned, updates mainly recalibrate actions for new dynamics. It is faster than retraining and usually needs 20 to 40% as many demonstrations.
Retraining suits substantial observation changes, such as training with a wrist camera and targeting only an overhead camera, or a significant task change alongside the platform change.
For the same task on mechanically similar platforms, begin with adapter transfer. If success falls below 85% in a 30 cycle target pilot, fine tune before considering retraining. Our pilot data shows full retraining is needed in roughly 20 to 25% of transfers. Most use an adapter with optional fine tuning.
Documenting Policy Dependencies
The longer term remedy is documenting dependencies during training. With each new policy, we create a policy dependency manifest beside the weights. It records observation variables, conventions, frames, and units, action representation, frequency, and coordinate frame, sensor mounts and calibration, plus controller protocol, command frequency, and feedback latency.
The manifest also supports deployment checks. The Neuralzome runtime compares target configuration with the manifest before enabling the policy. Dangerous mismatches become errors instead of silent discrepancies appearing after a few hundred incorrect cycles.
This process followed a transfer failure in which an undocumented calibration mismatch remained on a target platform for six days. Success was 12% lower than expected. Maintenance had changed the TCP offset. Manifest checks would have detected it at deployment.
The lesson is to make these checks part of deployment, rather than depend on manual inspection. Reviewing a multi parameter manifest every time is easy to skip under production pressure.