[Hardware] Add Unitree Go2 / Z1 Robot Preset

[DsThakurRawat]

Description

Unitree robots are becoming a standard in low-cost robotics research.

Task

• Create src/reflex/embodiments/presets/unitree_z1.json.
• Define the action space for the Z1 robotic arm.

[lihuawei-topsun]

This issue still matches a useful Unitree integration gap, but the repository has moved since the task was written and the action contract needs one clarification before a safe preset can be authored.

The old target path src/reflex/embodiments/presets/unitree_z1.json no longer exists. Current presets live in both configs/embodiments/ and src/tether/embodiments/presets/; the documented workflow also requires updating the schema enum, ALL_PRESETS, the emitter and validation tests: https://github.com/FastCrest/tether/blob/main/docs/embodiment_schema.md#adding-a-new-preset.

More importantly, the title says Go2 / Z1, while the task only asks for a Z1 arm preset. Could the maintainer confirm which contract is intended?

1. Z1 arm only — six arm joints, plus the exact optional gripper if present; or
2. Go2 + Z1 mobile manipulator — base velocity plus arm/gripper actions in one embodiment.

The current schema describes a flat continuous action vector, but a source-backed Unitree preset still needs these decisions:

• exact Z1 variant and gripper/end effector;
• action ordering and command mode (joint position, velocity, delta, or mixed);
• units and hard joint ranges from the selected hardware/SDK revision;
• state-vector ordering;
• whether base vx/vy/vyaw belongs in the same vector or a separate adapter;
• control frequency, chunk/horizon behavior and stop/hold semantics;
• normalization statistics derived from the target dataset rather than invented placeholder values;
• expected camera names and mounting contract.

Flattening base twist and arm joints without ownership, units and a fail-closed stop contract would create a preset that validates structurally but is unsafe or semantically wrong on hardware.

I work on real Unitree G1/Go2-W secondary development and can integrate arm/sensor payloads. I can help validate the mobile-base and system-integration side, but I do not want to claim access to the exact Z1 variant until the configuration is confirmed.

Is this good-first issue still active after the package rename? If so, please confirm the intended embodiment (arm-only vs combined), exact Z1/gripper model and whether a schema-compatible preset plus tests is sufficient, or whether a runtime adapter/hardware trace is also required. With that boundary I can prepare a scoped PR instead of guessing the action space.

[github-actions]

👋 Thanks for your interest in this issue!

This is a great place to start contributing 🎉

Before you begin, please read our contributing guide:
👉 https://github.com/FastCrest/tether/blob/main/CONTRIBUTING.md

Getting started

• Comment that you're working on it
• Follow the setup steps in CONTRIBUTING.md
• Open a PR when ready

If you get stuck, just ask here — happy to help! 🚀

[gaolebaigao]

Hi, I’m also interested in contributing to this issue. I saw the current discussion about the repository migration and the ambiguity between a Z1 arm-only preset and a combined Go2 + Z1 embodiment. I can help with a schema-compatible preset and validation tests once the maintainer confirms the target contract. I’m also happy to coordinate with @lihuawei-topsun to avoid duplicate work.

[lihuawei-topsun]

Thanks @gaolebaigao — coordinating makes sense. I agree we should not start two competing presets before the maintainer resolves the target contract.

Proposed split after maintainer confirmation:

• You: own the schema-compatible preset, enum/registry/emitter updates and validation tests.
• Me: own the hardware/system contract review: exact Z1 + gripper variant, action/state ordering, units and source-backed ranges, base/arm command ownership, control frequency and stop/hold evidence. I can also prepare a configuration-specific validation manifest for the mobile-base side.

Decision gate for @DsThakurRawat / FastCrest:

1. Z1 arm-only or combined Go2 + Z1 embodiment?
2. Exact Z1/gripper model and command mode?
3. Is the deliverable preset + schema tests only, or does it also require a runtime adapter and hardware trace?

If the answer is arm-only, one PR authored by you with my hardware-contract review should avoid duplication. If it is combined, I suggest keeping the flat dataset/action schema separate from the runtime ownership adapter, and keeping Go2 and Go2-W as different hardware validation profiles. I do not have the exact Z1/gripper configuration yet, so ranges and normalization should remain blocked until a source or trace is selected.

I will not open a competing implementation while we wait for that decision. Once the maintainer confirms the three items above, please tag me and I can turn the hardware side into a concise review checklist or follow-up commit.

[rylinjames]

Thanks for the follow-ups. The maintainable first step here is a Z1 arm-only preset, not a combined Go2 + Z1 preset. I do not want us to invent joint ranges, gripper semantics, normalization, or command modes without an authoritative source because those values are safety-critical.

Proposed split:

• @gaolebaigao: preset/schema scaffolding and tests once the exact Z1 model, gripper, and command contract are cited.
• @lihuawei: hardware-side review of joint order, limits, units, and command mode.
• Go2 + Z1 whole-body support: a separate follow-up after the arm-only contract is stable.

Please add the exact Z1 variant, gripper model, SDK/control mode, joint order, units, and an authoritative limits source. I am keeping this issue open, but removing the implication that a safe preset can be completed from the current information alone.

[gaolebaigao]

Thanks @rylinjames — arm-only + this split works for me. I'll own the preset/schema scaffolding and validation tests once the contract is cited, and leave the hardware-side review to its owner.

To help move that citation forward, here is an authoritative limits source for the six Z1 arm joints, verified today from Unitree's official repo:

Source: robots/z1_description/xacro/z1.urdf in unitreerobotics/unitree_ros (the path in the issue body, z1_robot/urdf/, no longer exists — the URDF has moved).

joint	lower (rad)	upper (rad)	velocity (rad/s)	effort (N·m)
1	-2.6180	+2.6180	3.1415	30
2	0.0	+2.9671	3.1415	60
3	-2.8798	0.0	3.1415	30
4	-1.5184	+1.5184	3.1415	30
5	-1.3439	+1.3439	3.1415	30
6	-2.7925	+2.7925	3.1415	30

Caveats for the hardware review — cc @lihuawei-topsun (the @lihuawei mention above resolves to a different account, so re-tagging to make sure the review request reaches you):

• Community threads #37, #66 and #10 show URDF limits and the ranges actually accepted by z1_controller/z1_sdk don't always line up (and are sometimes misread as deg vs rad), so these values should be cross-checked against the selected SDK revision before they land in action_space.ranges.
• The gripper is a separate z1_sdk interface rather than a 7th joint, so the exact variant, gripper model, command mode, joint ordering and units still need the review to pin them down.

One scope question for the plan: should the preset's normalization stats also come from a dataset/trace (like the joint ranges), or is an engineering default consistent with the existing presets (with the source noted) acceptable for the initial preset? This decides whether my PR can land in one shot or the stats stay blocked behind the trace.

I'll prepare the contract-independent parts locally in the meantime (schema enum / registry / test structure), plus an unrelated small fix to scripts/verify_embodiment_structure.sh, which currently hard-codes 3 presets while 4 ship.

[rylinjames]

@lihuawei-topsun @gaolebaigao, thanks for the detailed Z1 hardware-contract work and for coordinating before opening competing implementations. We have set up a dedicated Tether Discord for contributors and deployment discussion: https://discord.gg/wrPUdcxdPu

Please join us there if useful for faster coordination on the Z1 variant, SDK/control mode, limits, and validation plan. We will keep final technical decisions and acceptance evidence on this issue or the resulting PR so the public record stays complete.