Skip to content

Physical AI

Maturity: Experimental — Simulation Only

All physical AI components are software-only simulations or planning utilities. There is no validated hardware integration for real robots, PLCs, GPIO, cameras, lidar, serial, Modbus, ROS, ROS2, Isaac, or PyBullet in this release. adapt_physical_ai uses an in-memory simulation driver, and motor_control gates software actions; neither component controls physical actuators. Generated trajectories, G-code, and device commands require human review and a separate validated hardware integration layer before use on physical equipment.

Eight components implementing simulated motor control, embodiment schemas, and physics prediction — architectural patterns for future hardware integration.

Overview

Physical AI explores architectural patterns for reasoning about physical systems inside G6 pipelines. Currently all components operate in simulation or structured software-only planning modes.

motor_control (better named "action_gating") gates software actions through a motor-control-inspired pipeline — it does not drive physical actuators. embodiment provides body schema representations as a data structure. physics_prediction uses heuristic models for simple forward prediction. sensory_fusion combines structured data inputs (not real sensor streams). tactile_fusion consumes caller-supplied taxel grids and force profiles; it does not read tactile hardware, estimate validated friction coefficients, or provide safety-rated slip detection.

No real hardware integration exists in this release. Future work (P6-5) would add validated robotics or simulator backends.

For mesh3d specifically, treat it as a software utility for mesh arrays, simple primitives, rough slicing/toolpath artifacts, and G-code syntax checks. It is not a production CAD/CAM stack, slicer, STL/OBJ import/export pipeline, or machine-control system.

Components

Component Description MCP Tools
adapt_physical_ai Physical AI orchestration layer --
motor_control Simulated action gating for software, G-code, and PLC-style requests --
embodiment Body schema and capability mapping --
tactile_fusion Simulation-only tactile-grid heuristics --
physics_prediction Deterministic simulation-only physics estimates and Genesis fallback paths --
sensory_fusion Multi-modal sensor integration --
mesh3d In-memory mesh utility for prototype geometry and syntax checks --
adapt_synthetic_world Simulated environments for testing --

Architecture

graph TD
    PAI[adapt_physical_ai] --> MC[motor_control]
    PAI --> EMB[embodiment]
    PAI --> PP[physics_prediction]
    MC --> TF[tactile_fusion]
    MC --> SF[sensory_fusion]
    TF --> SF
    PP --> ML[ML & Optimisation cluster]
    EMB --> AFF[affordance_kb<br/>simulation KB]
    PAI --> MESH[mesh3d]
    PAI --> SYN[adapt_synthetic_world]
    SYN --> PP

Key Patterns

Sense-Plan-Act Loop. Physical AI operations follow the classical robotics cycle as a software pattern: sensory fusion produces a percept, physics prediction evaluates candidate actions, and motor control gates the selected action as a simulated approval artifact. Each step returns Result[T], so failures at any stage propagate cleanly without partial execution.

Simulation-First Testing. adapt_synthetic_world allows agents to assemble lightweight synthetic scenes before any separate physical execution path is considered. It is useful for rehearsal, visualization, and workflow state, but it is not a validated physics simulator. Safety-critical operations still require a dedicated simulator, hardware validation, and human review before any real-world actuation.

Body Schema Abstraction. embodiment decouples cognitive plans from specific body-schema data. A "reach for object" command can be translated into simulated joint-specific trajectories, but connecting those trajectories to real robot morphologies is outside this release.