Q6A, chassis work, and a more active loop

I’m working on the Q6A SBC integration, the Ainekio v2 chassis, and how to make the robot more active between LLM turns. YOLO is part of that research. The aim is to keep useful perception and movement running while the slower planning work catches up.

Q6A and the body#

Intended communication split: remote desktop inference connects to the Q6A host, which keeps the gateway and Environment Bridge local and uses the preferred direct Wi-Fi link to the P4 body controller. Host placement and loaded-link validation remain in progress. — Intended deployment, September 30. The Bridge–gateway connection stays local to Q6A. Dashed boxes and links mark integration work; service placement and concurrent Wi-Fi load still need validation. Open full-size diagram · Integration record

The current connection choice is direct Wi-Fi between the P4 and Q6A. USB stays an alternative, and ROS 2 is an optional integration layer. Gait execution stays on the P4; the host takes on perception and heavier planning. That split still needs testing under the combined camera, audio, and motion workload.

The latest chassis work adds Q6A mounting space and revises the shoulder geometry. All 47 motion sources were regenerated. The recorded checks cover software tests, model parity, and a P4 build; that geometry has not been flashed or tested on the powered body. Fit, balance, and loaded movement are still open.

From turns toward an active loop#

An earlier observe, decide, act and check sequence compared with current source foundations: newest-frame camera processing, a pending recognition backend and local task producer, bounded gateway updates and ongoing P4 movement. MetaHuman carries a saved task and receives parent-action results through the gateway. — Solid cyan marks source foundations; dashed amber marks work still to connect. Camera processing and movement updates have desktop/simulated-body coverage. Updates change speed or stride/cadence, keeping the gait, direction, action, and lease. The return arrow is parent-action feedback; update acknowledgements are not cognitive feedback. Physical-loop acceptance is still open. Open full-size diagram · Gateway · Workflow owners

The gateway can now process fresh camera frames outside its receive loop. It also has an authenticated path for adjusting an ongoing walk’s speed or its stride/cadence settings while keeping the original action and body lease. Cancellation, expiry, and session checks still apply.

MetaHuman’s newly pushed workflow code carries an execution across waits and correlated results. New input can steer that saved execution, and visual observations can carry their frame IDs and timestamps forward. Those are useful pieces for moving beyond isolated request-and-response turns.

The recognition backend and MetaHuman’s local task producer still need joining up. No YOLO detection pipeline is selected or running through the gateway CLI, and the source checks do not establish an autonomous physical loop. Portable IMU estimation is also in the tree, but live acquisition and balance feedback are not connected yet.

Next on the bench#

Fit the revised body and check movement under load
Bring up the intended Q6A services and measure them together
Try recognition models on the assembled prototype, then connect fresh results to bounded movement updates

The original eight-servo S3 Ainekio remains supported alongside the twelve-servo Ainekio v2 work. The project index keeps the current work and source links in one place.

Source snapshot#

Reviewed September 30 pushes: Ainekio 6437b24 and MetaHuman c3f56d4. Details: body integration, September 29 geometry checks, and MetaHuman workflow ownership. These pushes include earlier recorded work; the push date is not a new hardware-test date.