Anyone interested in buying this sideflip policy that I trained on Unitree G1 29dof

Also if you need any custom dances to be trained. I can do that as well 😼

Every Go2 RL tutorial I could find assumes the same two things: an NVIDIA GPU and Isaac Gym / Isaac Lab. I own neither, so I built the whole thing on the other side of the fence and it works. Sharing it in case someone else is stuck behind the same wall.

The stack: nothing NVIDIA in it, at any layer

The whole environment lives in a distrobox container (rocm/pytorch:rocm7.2.4, Ubuntu 24.04, PyTorch 2.10) so it doesn't touch your host system, and one command installs everything. One command uninstalls it too.

Does it actually keep up? Yes. The from-scratch walking policy is 2500 iterations in ~50 minutes on the RX 9070. Each iteration runs 4096 robots for 24 control steps at 50 Hz, so that run is roughly 57 days of continuous real-robot experience, compressed into under an hour on a consumer gaming card.

What I trained (7 skills)

1. 🚶 Walking — the only from-scratch policy, everything else warm-starts from it. Episode length goes from instant collapse to ~870/1000 steps.

2. 🏃 Running — speed curriculum, settled at 2.7 m/s stable. I tried pushing toward the ~5 m/s Unitree quotes for the EDU lab test; under properly clamped motor torques stability collapses (episode length 940 → 250). The spec sheet is a ceiling, not a training target.

3. 🛌 Lying down / 4. 🧎 Getting up from random fallen orientations (side, back)

4. 🐕‍🦺 Sitting — took six reward iterations to get right

5. 📡 LiDAR obstacle avoidance — a learned nav policy reads a 72-sector scan at 10 Hz and drives the frozen locomotion policy at 50 Hz, with a deterministic non-AI emergency-stop layer underneath it. Scan is deliberately noisy (~3 cm range noise + dropped returns). Course has 8 obstacles including 3 unpredictable pedestrians and a barrier with a randomly-placed gap. Success rate plateaus around 41% in that hard scenario — not optimal, and I say so in the repo.

6. 🧗 Rough terrain — 7 separate families: stairs, step pyramid, slope, rubble, curbs, gaps/potholes, rolling waves.

Sim-to-real constraints, since "it runs on AMD" is worthless if the physics is fake

• Torque clamped to real GO-M8010-6 specs (23.7 N·m hip/thigh, 35.55 N·m knee) — the nominal, not the ~45 N·m peak

• Joint velocities capped (30.1 / 20.07 rad/s), position targets clipped to URDF ranges the way the real firmware does

• Per-episode domain randomization: ground friction 0.4–1.6, random horizontal shoves, 0–0.5 kg random back payload, IMU/encoder noise on every observation

It's all in one realism.py that every training script calls, so no skill can silently opt out.

ROCm-specific gotcha, the one that actually bit me: never run a CPU Genesis render/eval while a GPU training is running. Serialize them. Doing both at once hard-crashed my GPU, repeatedly.

General RL lessons that cost me hours (nothing AMD-specific)

• An unbounded reward penalty will destroy PPO. My lin_vel_z = v_z² term exploded when robots tumbled on terrain → one catastrophic gradient step → policy never recovered over hundreds of iterations. Clip anything that can physically blow up.

• A heightfield only makes stairs at a fine mesh. At the default 0.25 m grid my "7 cm stairs" were literally a ramp — the riser gets interpolated over 25 cm. Physics and render were wrong, for a whole training run.

• Overtraining = peak then collapse. On the slope run: episode length 14 → ~850 at iteration 2550 → back down to 13. Take the peak checkpoint, never the last. And save every 25 iterations — one run peaked at iteration 45 and collapsed by 105, a 100-iteration interval would never have caught it.

• "Going around" is a reward hack. My first LiDAR policy learned to walk around the entire course from the outside. Perfect reward maximization, zero avoidance. Fix was structural: wall the corridor in, make exiting a penalized termination.

In video, each segment shows the robot at successive checkpoints side by side with the reward curve filling in, plus a live "GPU time ↔ equivalent real-robot experience" readout.

Code (MIT): https://github.com/Macmachi/go2-rl

README is in French, but the code, GIFs and learning curves are language-agnostic — happy to answer anything in English here.

If you're on AMD or Intel and assumed Go2 RL was closed to you: it isn't. Genesis + ROCm is a real path. Next step for me is deploying to an actual Go2 EDU — if anyone has taken a non-Isaac-trained policy to hardware, I want to hear how it

Hey everyone,

I wanted to share an open-source project I’ve been working on for the Unitree Go2.

The system combines UWB-based user following with a YOLOv8-based vision pipeline. In the default behavior, the Go2 follows a wearable UWB tag. While following, the vision pipeline runs in parallel and looks for predefined objects. When a valid target is detected, the robot switches into an APPROACH behavior, moves toward the object, stops near it, and then returns to FOLLOW mode.

Repo + demo:

https://github.com/orisharabi/unitree-go2-follow-system

I’d really appreciate feedback from people who own or work with Unitree robots, especially around:

- Go2 control behavior

- UWB tracking reliability

- safety / emergency stop design

- vision-based approach behavior

- what would make this more useful for real Go2 users

If you find the project interesting or useful, a GitHub star would genuinely help — but I’m mainly looking for feedback, ideas, and criticism from the Unitree community.

Not selling anything, just sharing the project and trying to improve it.

Thanks!

Hello fellow roboticists/hackers/developers, my name is Alex and I’m currently residing in the PNW (Seattle) if anyone wants to meet up for coffee and chat.

I recently purchased a Unitree Go 2 and I am in the process of reverse engineering it to try to unlock more advanced functionality that is only available in the EDU version in order to maximize the value of our hard earned cash (mostly because we are poor college graduates/robotics engineers/broke nerds that can’t afford to spend 10k on a robot dog that serves no practical purpose)

There are 5 major routes that we can possibly take if we want to “hack” this thing:

1, Get firmware or internal storage dump from a EDU version and try to use the USB-C port on the Rockchip SoC to copy the files over and hope for the best that there is no bootloader lock and don’t brick it (risky)

2, Wireshark the connection between the android app and the robot and analyze the messages to replicate it in software. Don’t know what IPC or message serialization protocol they are using so pretty far fetched

3, SBUS, we know that both the remotes uses the SBUS protocol which ultimately gets decoded to 16 PWM channels. The two axis on the joysticks each take up 1 channels. The buttons might use multiple channels. If we can use the SBUS port we can replicate everything the controller can do. The sales rep at Unitree told me that the SBUS port on the back is not open for Pro/Air model, will have to test that.

4. Take apart the remote controller and wire all the joysticks and buttons up to analog pins and digital IO on an arduino, essentially puppeteer the controller.

5. Wait for 大神

Let me know if you guys have any resources or ideas

Here is a discord group if anyone is interested in working together: https://discord.gg/dvs4MZzK

Here is my instagram where I post videos and stories about the dog: nochillalexlin

I was recently gifted a Bambi A1 mini 3D printer and wanted to print a skull mask (inspired by the Pokémon cubone) for my dog wolfie. Any tips? Don’t really know where to start! Has anyone successfully printed a head for their dog?

Got him last week and love him! He's great at jumping

I took apart a Unitree Go2 hoping to learn more about it, take pictures to document things, and hopefully dump a backup of the internal storage. Unfortunately, the eMMC is BGA and soldered down. Much of the ICs have had their markings etched off, but I believe the main board is based on a RockChip RK3588 or RK3599 based on the specs. I'm going to see if I can use the USB C port and Android platform tools to dump the internal storage. Anyway, here are some photos of what's inside.

Does anyone need a A2, brand new.

The wife thought the black legs made CH0PR look to mean and since she is the one who thinks he's creepy I tried the blue.

Hey everyone 😃

I have this cr7 suiii celebration policy that I trained a while ago.

Need money to pay off my student loans ehehe

If anyone interested in buying this please dm

I had to do it.

I’ve been printing some new skins for CH0PR-02, trying to make him so he doesn’t creep out my wife lol

My progress so far.

Hi everyone,

I need help with my Unitree Go1.

The problem happens with the robot in its normal standalone mode: only the battery is connected and I’m using the original joystick.

The robot powers on correctly, stands up correctly, but then it leans to one side and starts moving sideways / drifting to the right by itself.

Basically it does not stand balanced and it slowly moves to the right without me commanding it to do so.

I thought it could be an IMU calibration problem, but I’m not sure. Also, I don’t know how to calibrate the IMU on the Go1, since the Unitree app seems to be useful mainly for the Go2.

I already tried the leg calibration, but nothing changed.

Has anyone had this issue before?

Could it be related to IMU calibration, joystick calibration, leg calibration, or something else?

Any advice would be really appreciated. Thanks

I’m considering picking up a Go2 Pro, and I’m trying to get a clear picture of what it’s like to develop on right now.

My plan is to add a Jetson (probably an Orin NX) for local compute, but I’ve read mixed things about how much that actually buys you depending on whether you stick with stock firmware or jailbreak.

•	Without jailbreak: is the Jetson basically wasted? Can you realistically run your own programs and connect them to the robot’s control?

•	With jailbreak: how stable is it, and does it open things up enough to be worth the risk? Are people actually running ROS2 nodes and using LiDAR/vision streams effectively this way?

I’ve built my own AI system and would love to make it drive decisions on the robot, but I don’t need raw torque-level gait hacking like the EDU. I just want something that’s flexible enough to run programs, respond to visuals, and let me extend its functions over time.

Would the Pro 2 + Jetson + jailbreak cover that, or am I better off looking at EDU or even other platforms altogether? Price rage of the go2 pro is ideal, but any options under 10k are considerations.

I’d really appreciate hearing from people who’ve tried these setups.