Hardware: test the parts before committing to a body#

V1 provides the starting point. It runs prepared poses and movement sequences, and the owner reports useful motor turning force, or torque, on the existing 5 V / 5 A supply. Current, voltage, and temperature still need measurements under representative loads before that supply informs the V2 design.

V2 adds three joints per leg: hip roll for sideways movement, hip pitch for forward and backward movement, and a knee. Local OpenHarmony Puppy V2 models and Blender conversions provide the leg reference. The September 6 design note reports an experimental leg print. Its fit, range, and stiffness need testing before the rest of the chassis is designed around it.

The ESP32-P4 has been selected as the new body controller, but the firmware and shared movement code still target the eight-servo S3. Twelve-channel motion, board wiring, communication, camera, and audio support need implementation. The final battery or power bank is also undecided.

One correction to older documentation: Frame8 Blender and STL design files are now tracked in the repository. They record V1 enclosure work; that does not establish which enclosure is installed. The local 12servo/ files are separate V2 design work. See the hardware guide for the existing parts and the V2 plan for the proposed changes.

Software: keep a request intact while work happens#

A request may need more than one command. The robot can move, wait for an image, and then decide whether another step is necessary. The redesign saves that progress so a delay or restart does not erase the original request.

• Saved workflows: SQLite stores progress and results. LangGraph runs the connected software steps. A workflow can wait for an event, receive a result from another workflow, retry eligible work, and recover after interruption.
• Choosing what happens next: Full mode can start a robot objective, speech, or a finite specialist job. Goal Review can now choose among available workers after a result, and specialist answers return to the same saved request.
• Truthful progress: the current execution owns its goal. Robot Status now includes the execution’s lifecycle, keeping failed or completed work from appearing as an active objective. A command result updates the facts even when the model leaves the broader goal unchanged.
• Command recovery: the adapter no longer abandons result tracking after a fixed 30 seconds. It follows the original command until final feedback or connection loss. Saved gateway and robot-session identities prevent a later command from being mistaken for the old one; recovery does not resend motion.
• Finite Desire work: the optional Desire system now requires an observable outcome and a reviewed plan. Native robot steps carry the originating Desire, plan version, and step identity back to outcome review. Pending ideas remain visible without becoming standing instructions for the body.
• Voice and vision: available camera images and their identities reach the decision context. Speech delivery has saved results. Live records show these paths operating, while repeated room conversations and visually verified goals remain separate tests.

The simulator experiment was unsuccessful and has been completely retired. It is outside the current system and the V2 plan. The July article preserves its history.

What the live run showed#

The September 8 inspection after a rebuild found camera images and all eleven then-available worker choices in later Controller inputs. The adapter reported completed walks, generated motion plans, and a turn. Eight saved speech deliveries were acknowledged on their first attempt. These are runtime and adapter records, without independent observation of each movement or audible confirmation of every response.

The same run exposed an old failed goal in new decision context. Goal Review was skipped when no current objective had been saved, and unresolved desires repeatedly influenced new movement choices. Later source changes repair those context and lifecycle paths. A user command expiring before dispatch and intermittent backend availability remain separate diagnostic findings.

What the recorded tests establish#

The September 8 repair records describe these passing groups. They belong to different snapshots and overlap; their counts should not be added together.

The MetaHuman reviews also record graph validation, type checks, architecture checks, and, for the goal-context repair, an isolated Site build. An isolated cross-system check verified that late completion or cancellation releases the original body job and admits the queued next action without repeating model calls. These tests use controlled model replies and simulated physical effects. They do not establish reliable model judgment or physical Full Auto success.

This website update inspected the current implementations and those dated records; it did not rerun the robot or MetaHuman suites. The later Desire and goal-context repairs still need deployment verification. Ainekio’s completion repair needs the host gateway restarted; rebuilding the website or MetaHuman Site alone does not activate it. The original missing body completion remains unexplained.

What comes next, and why#

1. Assemble and measure one leg. Check the fit, the servo’s output arm (horn), joint travel, stiffness, bearing support, weight, and reachable foot positions. Measure backlash—the unwanted play in a joint—before repeating the design four times.
2. Measure power on V1. Startup, standing, walking, and demanding normal motions place different loads on the supply. Record voltage and temperature as well as current so brief voltage drops are not missed.
3. Bring up the P4 in stages. Verify signals, calibration, and peripherals, then test one loaded leg, two legs, and all twelve servos.
4. Fit the chassis and tune movement. Check cables, clearance, power distribution, and repair access. Standing, sitting, walking, turning, and stopping must avoid binding, voltage drops that reset electronics (brownouts), and routine operation near a motor’s stall limit.
5. Run a complete request on the revised software. Follow it from dispatch through feedback and review, including interruption, restart, cancellation, and direct stop. A visual goal needs an image showing the result; a spoken response needs feedback from actual playback.
6. Verify that Desire work ends. Run a reviewed finite plan, confirm its outcome, and check that completion stops further work for that intention. An unanswered question or an uncertain movement result must not authorize another attempt.

Sources and scope#

The inspected checkouts on September 9 were Ainekio 0592ca4 and MetaHuman a94fbfdd, both with additional uncommitted work. Public repository links may not contain all the local changes described here.

• Owner’s Ainekio v2 design document, updated September 6: design choices, build report, test sequence, and deferred features.
• ESP32-S3 Build & Firmware Reference, updated September 2.
• Ainekio source: firmware, body core, CAD, adapter code, and the September 8 completion-recovery entry in docs/BRIDGE_HARDENING_PLAN.md.
• MetaHuman source: saved execution, Agency, robot workflows, and the September 8 Full Auto and Desire-to-robot outcome reviews under docs/audits/, including their implementation follow-ups.

For the design behind these changes, read how MetaHuman controls Ainekio and how its autonomy modes differ.