Faster body reactions and cleaner recovery in MetaHuman OS

One model call for a tip or shake#

Fast Body Event is a dedicated node workflow using the configurable Lightweight model category. For tip and rapid-movement events, it receives the original event kind and measurements, selects a preset expression before inference, and uses one model call to choose the spoken reaction.

The configured model is the unadapted Qwen3.5 2B Q8_0 base, not either trained Intent/Task adapter. The graph uses Confused for tipping and Surprised for rapid movement. Those initial faces are configured presets; the spoken words are generated by the model. The approved guidance asks for brief, grounded, self-directed dark humor.

Reactions appear in the live conversation feed and use the existing speech delivery system, without being saved as conversational memories. Boot/wake and explicit manual requests retain their contextual workflow and possible Environment Mode delegation; this is not a replacement for general task planning.

Two inference-only replays took 486 ms for a tipped input and 316 ms for rapid movement, measured from context preparation through parsed output. The answers distinguished the events but still repeated part of their wording. These are not total sensor-to-speaker timings or proof of varied responses. The application and model assignment were activated October 19 without restarting the model servers.

Understanding movement the robot chose#

Body Control now receives timestamped execution context alongside the P4’s IMU measurements. It can identify commanded locomotion and the intended orientation of an authored pose at the time of the sample.

Rapid-motion crossings during Walk, Run, Crawl or Crab do not request an extra shake reaction or consume its notification cooldown. Tipped detection remains active and can compare measured orientation with the motion’s intended body vertical. Where that reference is unavailable, the existing absolute-tilt behavior remains. This changes event interpretation, not permission to move.

The October 19 firmware installation and passive telemetry checks confirmed the motion context. Physical false-event suppression under load still needs its own qualification. Further source work connects repeat-event suppression to the active reaction-face token, so an expression’s lifecycle supplies the boundary. Its separate preparation record leaves a physical shake/face-reset test pending.

Finishing an event is different from achieving its goal#

Some completed body-event work remained visible as unfinished workflows. The investigation found cancelled speech jobs without terminal delivery receipts, visual phases that returned to planning only after a positive assessment, and finite events parked waiting for future user or autonomy input.

The existing execution owners now deliver cancellation/expiry receipts, return accepted negative or uncertain visual assessments to planning, and finish a finite event invocation when its admitted work is drained. A retained objective can still be unresolved; finishing the invocation does not declare success.

After activation, a naturally arriving Fast Body Event completed its face, release and speech receipts and left the unfinished-work list. The recorded queue was empty afterward. That establishes runtime completion, not independent visual or audible confirmation of the reaction.

A later startup repair recognizes an already-settled, correlated speech cancellation instead of rejecting it during recovery. Replays of the three incident records admitted no new work and left their stored state unchanged. The activated application then started without the checked recovery exception.

Semi Auto assesses after inactivity#

Active Operator previously reacted to its own queue bookkeeping by assessing again, even when it selected nothing. Semi Auto now has an editable inactivity interval with a five-minute default. Recorded activity resets the deadline; queue changes reconcile it rather than immediately causing another assessment. The model still determines activation values and choices.

The validated build was prepared for the next normal startup because MetaHuman was stopped at the activation check. The record does not establish live UI use or a real five-minute observation. This setting is separate from the robot’s prepared three-minute inactivity-to-Lay-Down feature.

Recover connections without accumulating offline input#

An observation carrying camera and depth-preview data exceeded the old generic message-size ceiling and caused repeated disconnects during replay. The gateway and Bridge removed that rejection while retaining JSON validation, delivery identity and acknowledgements. Tests preserved larger observations unchanged across reconnect, and the activated transport acknowledged the blocked record.

The next investigation found unsolicited events accumulating while MetaHuman was disconnected. Admission now distinguishes two cases:

• New unsolicited input requires an open authenticated bridge connection before Body Control saves it for delivery.
• Work already admitted while connected survives disconnection, including pending input and correlated results of accepted actions.

The repair uses the existing connection and receipt owners. It does not purge previously accepted work. After Body Control activation on October 20, the Bridge reconnected and the recorded pending-delivery and active-work counts were zero. Connection availability still says nothing about whether an LLM’s decision will be correct.

Remaining companion work#

Boot interpretation still has a recorded case of adopting another execution’s old incident despite correct context attribution. The lifecycle repairs do not fix that model error. Recent recall diagnostics also failed to recover the intended old camera answers through query-prefix or terminal-token changes; they did not qualify a new retrieval configuration or trained adapter.

The October 21 source snapshot identifies the Robot Bible, workflow investigation records and current local code used here. It includes unpublished changes. The companion guide explains the wider intended behavior, with current status tracking the remaining qualification work.