The Adaptive Behavior Layer

The next robot stack is not only perception, planning, and control. It also needs behavior. A robot may complete the task correctly and still feel too abrupt, too mechanical, too hesitant, or simply wrong in front of a human.

In practice, this missing layer is still buried inside one-off scripts, deployment-specific tuning, and runtime-local parameters. That means behavior quality does not compound. One deployment learns something, and the next one often starts again from scratch.

Motius is built around the claim that this missing layer can be surfaced as software: explicit enough to inspect, narrow enough to deploy above an existing runtime, and structured enough to improve through reference data instead of endless local retuning.

Service robots are the right first wedge because interaction quality is visible immediately. In hotels, lobbies, reception, delivery, and other public-facing environments, people judge not only whether the task is completed, but how the robot approaches, stops, waits, hands over, and exits the interaction.

This makes behavior commercially meaningful before general autonomy is complete. Operators may tolerate hardware limits, but they do not tolerate awkward arrival, poor timing, uncomfortable spacing, or rigid object exchange in front of customers and guests.

Motius turns robot behavior into an adaptive software layer. Instead of treating behavior as a hidden implementation detail, it treats it as something that can be surfaced, adapted, validated, and improved over time.

The same robot should be able to behave more patiently for an elderly guest, more conservatively around a child, and more efficiently in a business-facing exchange, all without changing the robot body underneath.

The product has three persistent layers. First, a profile surface that makes interaction style explicit. Second, a Reference Network that gathers service examples, labels, and validation data. Third, a runtime adapter boundary that writes behavior-facing parameters above the controller while leaving low-level control and hard safety limits below.

The present paper and prototype make a narrow systems claim rather than a full autonomy claim. Motius is instantiated on a Unitree G1 humanoid platform and evaluated through a controlled within-session proof asset.

Within that scope, the paper studies one explicit profile pair, Standard and Gentle. The claim is not that the full learned adaptive stack is already complete, but that one surfaced behavior layer can create legible cross-task differences without rewriting the controller underneath.

The whitepaper is backed by a real preprint and should be read as an extension of that narrower systems argument, not as marketing fiction. The current paper is explicit about what the system already shows and what remains under development.

In particular, the paper is careful about three things that matter for credibility: the proof is within-session rather than overclaimed as broad generalization; the human rating study is real and bounded; and the adaptive system is described as a rule-based instantiation over surfaced fields rather than a fully learned predictor that does not yet exist.

The technical thesis is also beginning to surface in code. A first code skeleton already exists inside the Motius `unitree_lerobot` workstream, where profiles, reference schemas, dataset entries, examples, and tests are implemented as concrete artifacts.

# examples/motius/
gentle_profile_runtime.json
reference_clip_example.json
dataset_entry_example.json

# tests
test_motius_profiles.py

assert runtime["runtime_adapter"]["arrival"]["pause_ms"] == 420
assert entry.dataset_key == "Unitree_G1:gentle:handover:entry_001"

This matters because the project is not only publishing narrative and proof clips. It is beginning to formalize its behavior surface in a way that can later plug into data conversion, runtime execution, and model training workflows.

A strong behavior layer cannot rely only on robot clips. Over time, it needs a broader source of service references for what good robot interaction should actually feel like. That is the role of the Motius Reference Network.

• human service reference clips
• behavior labels and service annotations
• robot behavior validation data

Contributors help grow the network. Better references improve adaptation. Better adaptation improves deployments. Better deployments generate more useful behavior data in return.

This structure is already reflected in the current code surface: `HumanReferenceClip`, `TaskContext`, and `BehaviorDatasetEntry` provide the first schema for routing service clips into a behavior-data system instead of leaving them as raw media.

Every interaction starts with context. Motius treats service behavior as a perception problem first: who is approaching, what setting the robot is in, and what kind of interaction quality is expected.

Motius does not treat profiles as frozen presets. It treats them as coherent behavior bands that can shift within runtime-safe ranges depending on user and scene.

PROFILE_LIBRARY = {
  "standard": InteractionProfile(
    profile_id="motius.standard.v1",
    speed_scale=1.00,
    pause_ms=200,
    approach_distance_m=0.80,
    ee_smoothing=0.90,
    hold_ms=350,
    finish_softness=0.30,
  ),
  "gentle": InteractionProfile(
    profile_id="motius.gentle.v1",
    speed_scale=0.82,
    pause_ms=420,
    approach_distance_m=0.95,
    ee_smoothing=0.96,
    hold_ms=620,
    finish_softness=0.72,
  ),
}

This matters because the adaptive layer is not only narrative. It is already represented in code as explicit runtime-facing fields that can be serialized, compared, and mapped into downstream execution.

Adaptive behavior only matters if it creates observable differences. The current proof keeps the same robot and the same task family while exposing visibly different interaction quality across handover, approach-and-stop, and push-object tasks.

The paper reports an 18.0% reduction in configured speed scale, a 110.0% increase in configured pause duration, an 18.7% increase in configured stopping distance, and a 6.7% increase in configured end-effector smoothing in the Standard versus Gentle comparison. Clip- level proxy checks from the same proof asset partially corroborate these intended shifts through longer visible arrival and exchange windows.

• Gentle is rated more polite and more appropriate across all three tasks.
• Naturalness improves in handover and approach-and-stop, but not uniformly in push-object.
• Clarity is mixed, which suggests the surfaced fields expose real trade-offs rather than one uniformly superior style.
• Preference votes favor Gentle most strongly in approach-and-stop and push-object, while handover judgments are more mixed.

Motius is not a replacement controller. It sits above the runtime and shapes how execution feels while low-level control, actuation, and hard safety limits remain below.

profile: gentle_band_v1
task: guest_handover
runtime_adapter:
  locomotion:
    speed_scale: 0.82
    finish_softness: 0.72
  arrival:
    pause_ms: 420
    stop_distance_m: 0.95
  handover:
    hold_ms: 620
  arm:
    ee_smoothing: 0.96

The adapter does not output torques or trajectories directly. It writes a narrow parameter surface above the controller, which keeps the claim deployable and preserves controller ownership below.

The whitepaper should be read with the same discipline as the paper. The current claim is not that Motius already replaces the controller, solves general autonomy, or proves absolute superiority over every baseline.

The current system makes a narrower claim: behavior can be surfaced as an inspectable adaptive layer above the controller, grounded in reference data and legible to outside observers under controlled comparison.

At this stage, the adaptive logic is still demonstrated through a rule-based instantiation over surfaced profile fields. The full learned predictor remains under development, and multi-robot adapter transfer is still an architectural direction rather than a completed empirical result.

• Reward high-quality reference clips, structured behavior labels, and validated interaction data.
• Support access to adaptive pilot surfaces, future behavior tools, and deployment-related product layers.
• Coordinate contributors, operators, and deployment partners around the behavior-data flywheel.