NT-X-Integration

Status: Katalog, Simulation und serieller Transport sind in der NT-X-Harness-Umgebung verifiziert (make ntx-smoke). Um den physischen Roboter aus einer NT-X-Session zu öffnen, ist eine Änderung am NT-X-Kern nötig (siehe unten).

packages/strido-ntx ist eine NT-X-Erweiterung. In die NT-X-Umgebung installiert, steuert sie Folgendes bei:

Einstiegspunkt	Beitrag
ntx.assets → strido_ntx	robots/strido.yaml (RobotSpec), robots/models/strido.xml + Meshes (MJCF), skills/strido-stand.yaml
ntx.adapters → strido_ntx.plugin:register	Roboter-Adapter strido-serial → StridoSerialPort
ntx-extension.yaml	Manifest für ntx ext info/doctor strido

In NT-X installieren

cd ../../ntx-harness
uv pip install -e ../workspace/robot/packages/strido-core -e ../workspace/robot/packages/strido-ntx
uv run ntx ext doctor strido
uv run ntx robots show strido

make ntx-smoke führt dieselben Prüfungen aus, ohne das NT-X-Virtualenv zu verändern (uv run --project ntx-harness --with-editable …): Der Roboter wird aus dem Katalog geladen, in eine NT-X-MuJoCo-Welt kompiliert und steht 2 s lang, der Adapter ist registriert, und der serielle Port steuert eine simulierte MCU auf Protokollebene (Befehl → Zustand → Schutzstopp → Schließen).

Roboter-Spezifikation

Erzeugt von python -m strido_ntx.build_assets aus dem CAD-abgeleiteten MJCF (make models führt es aus; make drift prüft es):

• Gelenke in MCU-Reihenfolge FL, FR, RL, RR × (Hüfte, Oberschenkel, Unterschenkel), Grenzen aus dem Kollisions-Sweep, Standardwerte = 170-mm-Standpose;
• SPT5435LV-Grenzen: 3,43 N·m Kraft, 7,48 rad/s Geschwindigkeit; PD-Verstärkungen aus dem MuJoCo-Servomodell;
• Füße FL_foot … Körper in den Fußmittelpunkten; hardware_status: unverified, bis ein Roboter qualifiziert ist.

RobotPort-Semantik (StridoSerialPort)

NT-X erwartet	Strido liefert
read_state().q, dq, tau	q = der Winkel, den die MCU nach ihren Begrenzungen anwendet (Hobby-Servos melden nichts zurück); dq Nullen; tau leer
Basispose / Geschwindigkeit	Orientierung + Drehraten des Körpers aus der IMU; Position und Lineargeschwindigkeit nicht gemessen → has_odometry = False. Ein Zustand mit gelöschtem imu_ok rastet den Schutzstopp ein und löst ImuUnavailableError aus (sicherer Zustand bei Fehler)
apply(JointCommand)	nur Positionsziel. Positive kp/kd gelten als feste Steifigkeit des Servos, und tau_ff (die Schwerkraft-Vorsteuerung von pd-pose) wird verworfen; ein dq ungleich null oder kp <= 0 wird abgelehnt; nicht endliche Ziele rasten einen Schutzstopp ein
hold()	sendet das letzte Ziel erneut (MCU-Watchdog hält 200 ms, entspannt nach 2 s)
protective_stop()	eingerasteter MCU-Not-Halt: PCA9685 OE high, alle Servopulse aus. Servos werden schlaff (keine Dämpfung)
release(), close()	Not-Halt aufheben; serielles Gerät stoppen und freigeben
Aktualität	der Eingangspuffer wird beim Öffnen geleert und bei jeder Abfrage ausgelesen (der neueste Frame gewinnt); TimeoutError, wenn innerhalb von 0,2 s kein Zustands-Frame eintrifft

Odometrie-Prüfung. NT-X-Sessions verweigern Nicht-Gantry-Skills an einem Port ohne Odometrie (ntx.runtime.session._check_port_support). strido-stand ist ein frei stehender Skill, läuft auf der Hardware also erst, wenn ein Basis-Schätzer existiert, oder als Gantry-Variante mit dem Körper auf einem Ständer und frei hängenden Beinen. Simulations-Sessions sind nicht betroffen (der MuJoCo-Port misst die Basis).

Was NT-X für Hardware-Sessions ändern muss

NT-X öffnet Hardware über ntx.deploy.open_robot_port, das immer den Unitree-SDK2-Port erzeugt, und TargetSpec.transport.kind akzeptiert nur unitree-sdk2. Um Strido live aus einer Session zu betreiben, sollte NT-X Hardware über seine Adapter-Registry ansteuern:

1. transport.kind-Werte zulassen, die einen registrierten robot-Adapter benennen (z. B. strido-serial);
2. in open_robot_port, registry.create("robot", target.transport.kind, spec=robot, device=…);
3. ein Target config/targets/strido-desk.yaml mit den Qualifikationsprüfungen (Identität, Not-Halt, Shadow) für einen gebauten Roboter hinzufügen;
4. eine Basispose-Schätzung (IMU + Beinkinematik) oder eine Gantry-Variante von strido-stand für die ersten Hardware-Sessions bereitstellen.

Diese Änderung gehört in das NT-X-Repository und wird in TODO verfolgt; nichts in diesem Repository verändert NT-X.

Training in NT-X

Die NT-X-Vorlage locomotion-velocity trainiert jeden Vierbeiner aus dem Katalog: uv run ntx train run --template locomotion-velocity --set spec.robot_id=strido. Dort trainierte Policies verwenden das Observation-Format von NT-X; der Strido-ROS-2-policy_node führt Policies aus strido_sim.rl.train aus (Observation ohne Rückmeldung). Die Verbindung beider Laufzeitumgebungen ist noch offen.