Microduck Balance and Push Recovery

The unit, and the gate単位と判定基準

One environment step is one 50 Hz control decision, which is ten physics steps at the model's 500 Hz timestep. Reinforcement-learning budgets are quoted in environment steps, so the gate is written in them, and it was set before measuring:

1 environment stepは50 Hzの制御判断1回分で、モデルの500 Hzのtimestepでは物理step 10回にあたります。 強化学習の予算はenvironment stepで表すのが通例なので、判定基準もその単位で書き、計測の前に決めました。

MuJoCo's step for a sixteen-body model is single-threaded and small enough to stay in cache, so parallelism has to come from processes. Every worker sets OMP_NUM_THREADS=1 before MuJoCo loads, or the workers each spawn a thread pool and fight each other.

16ボディのモデルに対するMuJoCoのstepはシングルスレッドで、キャッシュに収まるほど小さいため、並列化はプロセスで行うしかありません。 各workerはMuJoCoを読み込む前にOMP_NUM_THREADS=1を設定します。そうしないと、各workerがそれぞれスレッドプールを立ち上げて奪い合います。

16 590 × 0.799 (wrapper) = ~13 300 env-steps/s
range 12 600 – 13 800 across the band

Why efficiency falls to 55 %, and what could not be determined効率が55 %まで落ちる理由と、特定できなかったこと

The chip is an Intel Core Ultra 5 225H: fourteen cores, no hyperthreading, heterogeneous — performance cores alongside efficiency cores. The obvious hypothesis is that workers 5–8 land on the slower ones. Pinning four workers to CPUs 0–3 and then to CPUs 10–13 gave a 15 % difference under load and 6 % single-threaded — far too small for a performance/efficiency split, which would show roughly 2×.

チップはIntel Core Ultra 5 225Hです。14コアでハイパースレッディングはなく、Pコア（高性能）とEコア（高効率）が混在する構成です。 すぐに思いつく仮説は、workerの5〜8番目が遅いコアに割り当てられるというものです。4つのworkerをCPU 0–3に固定した場合とCPU 10–13に固定した場合を比べると、 負荷時で15 %、シングルスレッドで6 %の差でした。P/Eコアの差なら約2倍になるはずなので、小さすぎます。

The explanation is that CPU affinity inside WSL2 does not pin to a physical core. sched_setaffinity binds the process to a virtual CPU, and the hypervisor schedules virtual CPUs onto physical cores on its own. So that experiment cannot answer the question, and neither can any other experiment run from inside the guest.

理由は、WSL2内でのCPU affinityは物理コアへの固定にならないことです。 sched_setaffinityはプロセスを仮想CPUに結びつけるだけで、仮想CPUをどの物理コアに載せるかはハイパーバイザーが独自に決めます。 したがってこの実験ではこの問いに答えられず、ゲスト内から行うほかのどの実験でも答えられません。

Pinning was the wrong instrument. Changing the workload worked. The groundcontact sweep loses efficiency earlier and ends thirteen points lower on the same cores in the same session, and a core-type split cannot produce that — which physical core a process lands on does not depend on how much contact solving it does. That points at cache and memory bandwidth over the other candidates. It is one comparison between two variants, not a proof, and it is recorded as unresolved rather than resolved with the plausible-sounding answer. What matters operationally is settled anyway: eight processes is the right choice, because it delivers the most total throughput even at 55 % efficiency.

コアの固定は道具として不適切でした。有効だったのはワークロードを変えることです。 同じセッション・同じコアで、groundcontactのスイープはより早く効率が落ち、13ポイント低く終わります。 コアの種類の違いではこうはなりません。プロセスがどの物理コアに載るかは、接触計算の量とは無関係だからです。 このことから、他の候補よりもキャッシュとメモリ帯域が疑わしいと言えます。ただし2つのモデルを1回比べただけで証明ではないため、もっともらしい答えで決着させず、未解決として記録しています。 運用上重要な点はいずれにせよ決着しています。効率が55 %でも合計throughputが最も高いので、8プロセスが正しい選択です。

Limp — a ragdoll from 25 cm脱力 — 25 cmからのラグドール落下

Actuator gains and biases zeroed so the robot has no muscle at all. Note that commanding ctrl = 0 does not do this: a MuJoCo position actuator produces gain·ctrl + bias₁·qpos + bias₂·qvel, so a zero command is a stiff hold at the zero pose. All three coefficients have to go.

アクチュエータのゲインとバイアスをゼロにして、ロボットから筋力を完全に取り除きます。ctrl = 0を指令してもこうはならない点に注意してください。 MuJoCoの位置アクチュエータはgain·ctrl + bias₁·qpos + bias₂·qvelを出力するため、ゼロ指令はゼロ姿勢での固い保持になります。3つの係数すべてを消す必要があります。

It falls, lands, and comes to rest at trunk height 3.0 cm with 14 contacts and a maximum joint speed of 0.09 rad/s. No sinking, no jitter, no explosion.

ロボットは落下・着地し、胴体の高さ3.0 cm、接触点14、最大関節速度0.09 rad/sで静止しました。沈み込みも振動も発散もありません。

Hold — commanded to the standing pose保持 — 立ち姿勢を指令

The actuators are commanded to the STAND keyframe, which is where every training episode will begin. It holds for 0.79 s, then topples, and settles face-down at 4.30 s.

アクチュエータにSTANDのキーフレームを指令します。すべての学習episodeの開始姿勢です。 0.79 s保持したあと倒れ、4.30 sでうつ伏せのまま静止しました。

The same test on walk topples at the identical 0.79 s — the dynamics match until the body reaches the floor — and then sinks to −10.5 cm, which is the contact-mask finding again, visible as a number.

walkで同じテストを行うと、まったく同じ0.79 sで倒れます（胴体が床に届くまでは力学が一致しています）。その後−10.5 cmまで沈みます。 先ほどの接触マスクの発見が、数値として改めて現れたものです。

Actions, and a trap in the model fileActionと、モデルファイルの落とし穴

Fourteen outputs in [−1, 1], applied as residuals around the standing pose:

[−1, 1]の範囲の14個の出力を、立ち姿勢からの残差（residual）として適用します。

target = STAND_pose + 0.35 * action        then clipped to the joint limits

A saturated action moves a joint 0.35 rad — about 22 % of the median joint range — in one 20 ms decision. That number is a hyperparameter, not a derived quantity, and step 3 is set up to report what happens at 0.2 and 0.5.

飽和したactionは、1回20 msの判断で関節を0.35 rad（関節可動域の中央値の約22 %）動かします。この値は導出された量ではなくハイパーパラメータで、 step 3では0.2と0.5の場合の結果を報告できるようにしてあります。

Episodes and pushesEpisodeとpush

250 steps at 50 Hz — five seconds — fixed length with no early termination. The usual locomotion setup ends the episode the moment the robot falls. That is right for walking and wrong here: recovery is half the task, and terminating on a fall makes falling unrecoverable by construction. It also keeps returns comparable — every episode is the same length, so a baseline that topples early gets a low return rather than a short episode that looks cheap.

50 Hzで250 step、つまり5秒間で、途中終了のない固定長です。一般的な移動ロボットの設定では、ロボットが倒れた瞬間にepisodeを終えます。 歩行ならそれで正しいのですが、ここでは誤りです。復帰はタスクの半分であり、転倒で終了させると構造上、転倒から復帰できなくなります。 また固定長にすることでreturnを比較可能に保てます。すべてのepisodeが同じ長さなので、早く倒れるbaselineは「短くて安上がりに見えるepisode」ではなく、低いreturnとして現れます。

Three pushes per episode, drawn from the episode seed: magnitude uniform in 0.15–0.45 m/s applied to the trunk's linear velocity, direction uniform in azimuth, timing uniform but held half a second clear of both ends. A push at t = 0 is an initial condition rather than a disturbance, and one at the buzzer is never recovered from inside the episode.

pushはepisodeごとに3回で、episodeのseedから生成します。大きさは0.15–0.45 m/sの一様分布で胴体の並進速度に加え、方向は方位角について一様、 タイミングも一様ですが、両端から0.5秒は空けています。t = 0のpushは外乱ではなく初期条件になり、終了間際のpushはepisode内で復帰しようがないからです。

Observation scaling, and the vector environmentObservationのスケーリングとvector環境

Each group is divided down so no input dominates by unit choice alone: joint positions and projected gravity are already order 1, joint velocity reaches ~20 rad/s in a fall and is scaled by 0.05, and the gyro by 0.25. Whether those scales are right is one of the three open risks below — they are not.

単位の選び方だけで特定の入力が支配的にならないよう、グループごとに割って縮めます。関節位置と投影した重力はもともと1程度、 関節速度は転倒時に~20 rad/sに達するので0.05倍、ジャイロは0.25倍です。このスケールが正しいかどうかは後述の3つの未解決リスクの1つで、結論から言えば正しくありません。

vec_env.py forks N workers over pipes, one environment each, capped at eight. Environment i is seeded seed + i, and a test asserts that N workers reproduce N sequential environments bit for bit — so a run is reproducible at any worker count, and a result cannot quietly depend on how it was parallelised.

vec_env.pyはパイプ経由でN個のworkerをforkし、各workerが環境を1つ持ちます。上限は8です。環境iのseedはseed + iで、 N個のworkerがN個の環境を順番に実行した場合とビット単位で一致することをテストで確認しています。そのため実行はworker数によらず再現でき、 結果が並列化の仕方に黙って依存することはありません。

2 — The reward is informative about standing and nearly flat about getting up2 — Rewardは立つことには敏感だが、起き上がることにはほぼ平坦

Per-step reward while upright (cos > 0.9) is 1.92 ± 0.05; while down (cos < 0.3) it is 0.12 ± 0.04. The level gap is 16×, so the return clearly prefers standing and the task is not degenerate. But upright is floored at 0 past 90°, and height is a 3 cm Gaussian worth about 1e−3 at floor level — so inside the fallen region the reward barely says which way is up. Expect exploration, not reward shape, to decide whether recovery is learned, and expect fall slowly and stay tilted as the competing local optimum. Step 3 replaced the Gaussian with a ramp for this reason.

1 stepあたりのrewardは、直立時（cos > 0.9）で1.92 ± 0.05、倒れているとき（cos < 0.3）で0.12 ± 0.04です。水準の差は16倍あるため、 returnは明らかに立つことを好み、タスクとして破綻してはいません。しかしuprightは90°を超えると0で頭打ちになり、heightは幅3 cmのガウス関数で床の高さでは約1e−3にしかなりません。 そのため倒れた領域の中では、rewardはどちらが上かをほとんど教えてくれません。復帰を学習できるかどうかはrewardの形ではなく探索で決まり、 対抗する局所最適解としてゆっくり倒れて傾いたままでいる挙動が現れると予想されます。この理由から、step 3ではガウス関数を線形のランプに置き換えました。

3 — The observation scaling is a guess, and the measurement says it guessed wrong3 — Observationのスケーリングは推測で、計測によるとその推測は外れている

Group RMS under random actions: projected gravity 0.577, previous action 0.575, gyro 0.211, joint position 0.094, joint velocity 0.044. A 13× spread — with the 28 dimensions that describe the body's configuration carrying the least variance of all, so an unnormalised first layer attends mostly to the policy's own previous output. Step 3 carries a running observation normaliser rather than a better fixed guess.

ランダムaction時のグループ別RMSは、投影した重力0.577、直前のaction 0.575、ジャイロ0.211、関節位置0.094、関節速度0.044でした。 13倍のばらつきがあり、しかも体の形を表す28次元の分散が最も小さいため、正規化しない第1層は主にpolicy自身の直前の出力に注目してしまいます。 Step 3では、より良い固定値を推測し直すのではなく、running observation normaliserを導入しました。

What steps 1 and 2 did not prove, and what step 3 did about itStep 1と2で証明できなかったことと、step 3での対応

• Steps 1 and 2 trained nothing. Throughput was measured with random actions around STAND. The training loop adds policy forward passes, advantage computation and optimiser steps on top, and the section on the fifth revision below says what that cost.
• The 13 300 figure had one inherited factor (a wrapper cost measured single-core) and was missing two more: the eight pipe round trips per step and the policy forward pass.
• Neither sustained run reached a steady state. One was still falling 1.0 % per window after twelve; the other bottomed out at window 11 and was still climbing 0.6 % after eighteen. The 9 % plateau band is the honest uncertainty on the budget rate.
• The throughput figure has been wrong five times. Treat any number here as provisional until a script in the repository reproduces it on the workload it is quoted for.
• The 0.79 s fall time is one deterministic rollout from one keyframe. It is a baseline to beat, not a distribution — the 108.7 ± 2.9 return over twenty seeds is the distributional version.
• At the end of step 2 the reward had never had anything optimise against it. Three of its four penalties were measurably inert and the fallen region nearly flat; both were written up rather than quietly retuned. Step 3 then changed the reward in the open, as version 2, and re-measured the baseline under it.
• No observation noise, no domain randomisation, no actuator variation. One nominal physics model. Step 4 adds the spread.
• Run-to-run spread is about 1 % from two runs seven minutes apart — not enough samples to call it a distribution, and it says nothing about spread across days, where the host power state is the dominant term and has already moved these numbers by 40 %. Two significant figures is all any of this supports.

• Step 1と2では何も学習していません。throughputはSTAND周辺のランダムactionで計測しました。学習ループではさらにpolicyの順伝播、advantageの計算、 optimizerの更新が加わります。そのコストは後述の「5回目の修正」の節で示します。
• 13 300という数値には、引き継いだ係数が1つ（シングルコアで計測したwrapperのコスト）含まれ、さらに2つが抜けていました。 1 stepあたり8回のパイプ往復と、policyの順伝播です。
• どちらの連続負荷実行も定常状態に達していません。一方は12区間後もまだ区間ごとに1.0 %下がり続け、もう一方は11区間目で底を打ったあと18区間後もまだ0.6 %上昇していました。 9 %の横ばい帯が、計画に使う速度の正直な不確かさです。
• throughputの数値は5回間違えています。リポジトリのスクリプトが、その数値の対象となるワークロードで再現するまでは、ここにあるどの数値も暫定値として扱ってください。
• 0.79 sという転倒時間は、1つのキーフレームからの決定論的なrollout 1回分です。超えるべきbaselineであって分布ではありません。 分布として見るなら、20 seedでのreturn 108.7 ± 2.9がそれにあたります。
• Step 2の終了時点では、rewardに対して最適化をかけたことが一度もありませんでした。4つのpenaltyのうち3つは計測上効いておらず、倒れた領域はほぼ平坦でした。 どちらも黙って調整し直すのではなく、文書に残しました。その後step 3でrewardをバージョン2として公開の形で変更し、それを使ってbaselineを再計測しました。
• Observationのノイズも、domain randomisationも、アクチュエータのばらつきもありません。公称の物理モデル1つだけです。ばらつきはstep 4で加えます。
• 実行ごとのばらつきは約1 %で、7分空けた2回の実行から得たものです。分布と呼ぶにはサンプルが足りず、日をまたいだばらつきについては何も言えません。 日をまたぐ場合はホストの電源状態が支配的で、すでにこれらの数値を40 %動かしています。ここにあるどの数値も、有効数字2桁までしか裏付けられません。

A reward is a specification, and this one had never had anything optimise against it. Step 2 closed with three measured facts about it and a note that changing it was a step-3 decision, because a new reward invalidates the 108.7 baseline. Here is the decision, with one more measurement taken while making it.

rewardは仕様そのものですが、このrewardに対して最適化をかけたことはまだ一度もありませんでした。Step 2は、rewardに関する3つの計測事実と、 「変更はstep 3で判断する」という注記で締めくくりました。新しいrewardにすると108.7のbaselineが無効になるからです。以下がその判断で、判断の過程でもう1つ計測を追加しています。

1. Three of four penalties are dead. posture, effort and joint_vel are each under 0.25% of the return under both the PD controller and random actions.
2. The fallen region is nearly flat. 0.12 ± 0.04 reward per step while down against 1.92 ± 0.05 upright. The height term is a 3 cm Gaussian about 0.12 m, worth about 1e−3 at floor level.
3. The observation scaling guessed wrong, a 13× rms spread across groups. This one is answered in the training loop, not the reward.
4. Measured for this decision: over 1,248 fallen steps in six episodes, the fallen duck lies with trunk cosine between 0.0 and 0.3 and trunk height between 3.1 and 6 cm. The cosine never went below −0.06. It lands on its front or side, trunk near horizontal, and does not roll past 90°.

1. 4つのpenaltyのうち3つが効いていない。posture、effort、joint_velはいずれも、PD controllerでもランダムactionでもreturnの0.25%未満です。
2. 倒れた領域がほぼ平坦。倒れているときの1 stepあたりのrewardは0.12 ± 0.04、直立時は1.92 ± 0.05です。heightの項は0.12 m中心・幅3 cmのガウス関数で、床の高さでは約1e−3にしかなりません。
3. Observationのスケーリングの推測が外れている。グループ間でrmsに13倍の差があります。これはrewardではなく学習ループ側で対処します。
4. 今回の判断のために計測したこと：6 episode・1,248 stepの転倒状態を調べると、倒れたロボットは胴体のcosineが0.0〜0.3、胴体の高さが3.1〜6 cmの範囲に横たわっていました。 cosineが−0.06を下回ったことは一度もありません。うつ伏せか横向きに着地し、胴体はほぼ水平で、90°を超えて転がることはありません。

The loop is the one from the earlier cart-pole project: generalised advantage estimation, orthogonal initialisation, the clipped surrogate objective, several epochs of minibatch updates per batch, and a learning rate that anneals to zero. Gaussian policy, separate actor and critic, each two hidden layers of 256 tanh units. Entropy bonus zero, because a Gaussian's differential entropy is unbounded below and a bonus would push the action noise up without a floor.

ループは以前のcart-poleプロジェクトのものです。GAE、直交初期化、clipしたsurrogate目的関数、batchごとに数epochのminibatch更新、ゼロまで減衰させる学習率。 policyはガウス分布で、actorとcriticは別々のネットワークで、それぞれ256ユニットのtanh隠れ層を2層持ちます。entropyボーナスはゼロです。 ガウス分布の微分エントロピーには下限がなく、ボーナスを入れるとactionのノイズを際限なく押し上げてしまうからです。

What resume promises and what it does not. Two resumes from the same checkpoint are bit-identical; a test asserts it. A split run is not bit-identical to an uninterrupted one, because the workers' physics state is not checkpointed and the resumed chunk starts fresh episodes. Stated rather than papered over.

再開機能が保証すること、しないこと。同じcheckpointから2回再開した結果はビット単位で一致し、テストで確認しています。 一方、分割した実行は中断なしの実行とビット単位では一致しません。workerの物理状態はcheckpointに含まれず、再開したchunkは新しいepisodeから始まるからです。 取り繕わずに明記しておきます。

Throughput is logged every update, and the log says so when the rolling rate falls more than 20% below the mean of the first five updates. On this machine that is the only visible sign of a thermal or power limit, and it looks identical to contention from another process, so the warning names both. The box check refuses to start above a one-minute load average of 4.

throughputは更新ごとに記録し、移動平均の速度が最初の5回の更新の平均より20%以上下がると、ログにその旨を出します。 このマシンでは、それが熱や電力の制限を示す唯一の目に見える兆候です。他のプロセスとの競合とも見分けがつかないため、警告では両方の可能性を挙げます。 起動前のチェックは、1分間のload averageが4を超えていれば開始を拒否します。

How the run is scored実行の採点方法

Metrics are defined once in metrics.py and imported by both the in-training evaluation and eval_policy.py, so the learning curve and the final table cannot disagree.

指標はmetrics.pyで一度だけ定義し、学習中の評価とeval_policy.pyの両方がそれをimportします。そのため学習曲線と最終的な表が食い違うことはありません。

OMP_NUM_THREADS=1 nice -n 10 python ppo.py --total-steps 50000000 --chunk-steps 25000000 --tag v2 --reward v2
OMP_NUM_THREADS=1 nice -n 10 python ppo.py --resume runs/ppo_v2.ckpt.pt --tag v2 --target-kl 0.02 --chunk-steps 12500000   # chunk 2, until 50M
python eval_policy.py runs/ppo_v2.pt --variant groundcontact      # -> runs/eval_v2_groundcontact.json

Configuration: 8 workers, batch 2,048, 5 epochs × 8 minibatches, learning rate 3e−4 annealed, γ 0.99, λ 0.95, clip 0.2, entropy 0, initial log-std −0.5. Evaluation: 100 episodes × 5 seeds, deterministic mean actions, the PD controller on the same seeds.

設定：8 worker、batch 2,048、5 epochs × 8 minibatches、学習率3e−4（減衰あり）、γ 0.99、λ 0.95、clip 0.2、entropy 0、初期log-std −0.5。 評価：100 episodes × 5 seeds、決定論的な平均action、同じseedでのPD controller。

After the first 25M-step chunk, PPO scored 332.6 ± 5.1 of 500 against the PD controller's 175.8 ± 0.2 under the same reward and kept the trunk up for 74% of steps (PD 47%), 100 episodes × 5 seeds. The push column reads 100% against 88%, but with a 0.00 s time to recover it measures push resistance, not standing back up: 797 of the 801 pushes that landed on the standing policy never moved the trunk out of the upright band at all, and the 100% is 0.995 rounded. After the second chunk the policy scores 344.8 ± 2.9, and all five evaluation seeds went up, by 8.6 to 16.0. Survival did not move (0.73 against 0.74, about 1.3 standard errors). Pushes on a fallen robot fell from 699 to 629, and the upright fraction rose from 0.47 to 0.50. That is a little more time standing, not a new behaviour, and getting up after a fall is still not shown.

最初の25M stepのchunkを終えた時点で、PPOは同じrewardで500点中332.6 ± 5.1を記録し、PD controllerの175.8 ± 0.2を上回りました。胴体を立てていたstepの割合は74%（PDは47%）で、100 episodes × 5 seedsでの結果です。 pushの列は100%対88%ですが、復帰時間が0.00 sなので、測っているのは押しへの耐性であって起き上がる能力ではありません。立っているpolicyに当たった801回のpushのうち797回は、胴体を直立の範囲から一度も外に出しておらず、100%は0.995を丸めた値です。 2つ目のchunkのあと、policyは344.8 ± 2.9となり、5つの評価seedすべてで8.6〜16.0上昇しました。survivalは変わっていません（0.73対0.74、標準誤差の約1.3倍）。 倒れたロボットへのpushは699回から629回に減り、直立していた割合は0.47から0.50に上がりました。立っている時間が少し延びただけで、新しい挙動ではありません。転倒後に起き上がる能力は依然として示されていません。

What the log showed on the way学習途中のログが示したこと

The rolling 50-episode return rose from 155 at the first update to about 350 by 2.5M steps and peaked at 374 near 7.8M, against the PD controller's 175.2 (its 20-seed baseline; the 175.8 above is the same controller under the 100-episode × 5-seed evaluation). Then it stopped: the five 5M-step blocks averaged 337, 342, 332, 332 and 328, and the in-loop 20-episode evaluation averaged 354 with 0.83 survival over the first 5M steps against 330 with 0.69 over the last 5M. Those are block means on purpose: one evaluation is 20 episodes, and the last seven of them span 346 down to 313, so no pair of single rows would be evidence of anything.

直近50 episodeの移動平均returnは、最初の更新時の155から2.5M stepまでに約350へ上がり、7.8M付近で374のピークに達しました。 PD controllerは175.2です（20 seedでのbaseline。上の175.8は同じcontrollerを100 episodes × 5 seedsで評価した値）。そこで伸びが止まりました。 5M stepごとの5つのブロックの平均は337、342、332、332、328で、学習ループ内の20 episode評価の平均は、最初の5M stepで354（survival 0.83）、最後の5Mで330（survival 0.69）でした。 あえてブロック平均を使っています。1回の評価は20 episodeで、最後の7回は346から313まで幅があるため、単独の行を2つ比べても何の根拠にもならないからです。

The optimiser statistics say why. The clip fraction, the share of samples whose ratio hit the 0.2 clip, had a median of 0.48 over the first 5M steps and 0.73 over the last 5M. The approximate KL between consecutive policies went from a median of 0.07 to 0.76 with spikes above 50, and the policy's standard deviation shrank from 0.61 at the first update to 0.08 at the last. After roughly 5M steps every update moved the policy further than the clipped objective is meant to allow, and the extra distance bought nothing. That is the finding of this chunk: the step size, not the budget, is what to fix. So the second chunk resumed from runs/ppo_v2.ckpt.pt with an approximate-KL stop on the epoch loop (--target-kl 0.02), because two more hours at the same settings would repeat the same mistake.

理由はoptimizerの統計に表れています。clip fraction（比率が0.2のclipに当たったサンプルの割合）の中央値は、最初の5M stepで0.48、最後の5Mで0.73でした。 連続するpolicy間の近似KLの中央値は0.07から0.76になり、50を超えるスパイクもありました。policyの標準偏差は最初の更新の0.61から最後には0.08まで縮みました。 およそ5M stepを過ぎてからは、どの更新もclipした目的関数が本来許す以上にpolicyを動かしており、その余分な移動は何の成果も生んでいません。 これがこのchunkでの発見です。直すべきは予算ではなくstep sizeです。そこで2つ目のchunkはruns/ppo_v2.ckpt.ptから再開し、 epochループに近似KLによる停止（--target-kl 0.02）を入れました。同じ設定でさらに2時間回しても、同じ失敗を繰り返すだけだからです。

What the KL stop changedKL stopで何が変わったか

Over chunk 1 the mean approximate KL per update was 0.53 and the mean clip fraction 0.66. Over chunk 2 they were 0.032 and 0.28, and the largest KL was 0.24 against 173. The clip fraction's median fell from 0.40 over the first 5M steps of chunk 2 to 0.16 over the last 5M, and the policy's standard deviation held at 0.08 to 0.09. The rolling return's five block means went 331, 332, 337, 344, 347, against chunk 1's flat-to-falling 337, 342, 332, 332, 328. This run has two confounds and cannot separate them. The learning rate anneals to zero over the same span, and there is no chunk 2 without the stop to compare against. So the claim is that chunk 2 improved with the stop in place, not that the stop caused all of the gain.

chunk 1では、更新あたりの近似KLの平均が0.53、clip fractionの平均が0.66でした。chunk 2ではそれぞれ0.032と0.28で、KLの最大値は173に対して0.24でした。 clip fractionの中央値はchunk 2の最初の5M stepで0.40、最後の5Mで0.16まで下がり、policyの標準偏差は0.08〜0.09で安定していました。 移動平均returnの5つのブロック平均は331、332、337、344、347で、chunk 1の横ばいから下降の337、342、332、332、328とは対照的です。 ただしこの実行には2つの交絡要因があり、切り分けられません。同じ期間に学習率がゼロまで減衰しており、またstopなしのchunk 2という比較対象もありません。 したがって主張できるのは「stopを入れた状態でchunk 2は改善した」ということであり、「改善のすべてがstopによる」ということではありません。

Chunk 2 ran as three invocations of under an hour each: 58 min, then a 4-minute run stopped by hand right after a checkpoint, then 60 min. The runner rested the machine 30 minutes after every 2.5 hours of work. The throughput warning fired on 86 of 12,207 updates, against 4,296 of 12,208 in chunk 1's single 2.4-hour run, which is more evidence that chunk 1's slowdown was heat or power. The chunk-1 policy is kept byte-identical as runs/ppo_v2_chunk1.pt; the step 4 gap table and the step 5 export were measured on it. The action-scale question step 2 left open, 0.2 and 0.5 against the 0.35 default, is a --action-scale flag and two more runs; whether it is answered or dropped is recorded in the repository's issues.

chunk 2は1時間未満の起動3回に分けて実行しました。58 min、checkpoint直後に手動で止めた4分間、そして60 minです。実行担当は2.5時間の作業ごとにマシンを30分休ませました。 throughputの警告は12,207回の更新中86回しか出ず、2.4時間通しで回したchunk 1の4,296/12,208回とは大きく異なります。chunk 1の速度低下が熱か電力によるものだったという、さらなる根拠です。 chunk 1のpolicyはruns/ppo_v2_chunk1.ptとしてバイト単位で同一のまま保存しており、step 4の差分の表とstep 5のexportはこれで計測しています。 Step 2で残したaction scaleの問い（デフォルト0.35に対して0.2と0.5）は、--action-scaleフラグと追加の2回の実行で答えられます。答えたか取りやめたかはリポジトリのissueに記録しています。

The first chunk ran at 3,000 to 3,750 env-steps/s with the policy in the loop. The log's own throughput warning, which fires when the last three updates average under 80 % of the first five, fired on 4,296 of the 12,208 updates: 9 % of the first two thousand, 84 % of the last four thousand, as the mean rate fell from 3,407 to 3,024 env-steps/s. The box check at the start recorded a 1-minute load of 0.64 and nothing else ran for the whole chunk. The process table said where the time went: the single Python main process at 76% of one core, each of the eight workers near 20%. The workers spend most of their time waiting for the main loop to generate the next action batch and read the last one back. Physics is not the bottleneck; the interpreter between the physics and the network is.

最初のchunkは、policyをループに入れた状態で3,000〜3,750 env-steps/sで動きました。直近3回の更新の平均が最初の5回の80 %を下回ると出るログのthroughput警告は、 12,208回の更新中4,296回出ました。最初の2千回では9 %、最後の4千回では84 %で、その間に平均速度は3,407から3,024 env-steps/sに下がっています。 開始時のチェックでは1分間のloadが0.64で、chunkの間ほかには何も動いていませんでした。時間の行方はプロセス一覧が示していました。 Pythonのメインプロセス1つが1コアの76%を使い、8つのworkerはそれぞれ20%前後でした。workerは時間の大半を、メインループが次のaction batchを生成し、前回の結果を読み戻すのを待つことに費やしています。 ボトルネックは物理演算ではなく、物理演算とネットワークの間にあるインタプリタです。

The C++ backend project measured the same thing from the other side a few hours earlier: this Python vector environment delivers about 6,400 env-steps/s at eight processes under random actions, half of the 13,300 that had been budgeted, before any network is involved. Its own threads reach 1.9 to 2.0× that. Neither number was in the composition that produced 13,300, because the composition multiplied a physics rate by a wrapper factor and never ran the thing it was estimating.

C++バックエンドのプロジェクトでは、その数時間前に同じことを反対側から計測していました。 このPythonのvector環境は、ネットワークが関わる前のランダムactionの段階で、8プロセスで約6,400 env-steps/sしか出ません。計画していた13,300の半分です。 C++版のスレッド実装はその1.9〜2.0倍に達します。どちらの数値も13,300を導いた計算には入っていませんでした。その計算は物理演算の速度にwrapperの係数を掛けただけで、見積もろうとしている対象そのものを一度も動かしていなかったからです。

Domain randomisation varies the physics at every reset so the policy cannot tune itself to one exact robot. The question step 4 asks is whether that buys anything measurable: a policy trained on one nominal model and a policy trained under randomisation are both evaluated on models neither has seen, and the difference in how much each loses is what randomisation is worth on this robot.

Domain randomisationはresetのたびにphysicsを変え、policyが特定の1台のロボットに合わせ込まれないようにします。Step 4の問いは、それで計測可能な何かが得られるかどうかです。 公称モデル1つで学習したpolicyと、ランダム化のもとで学習したpolicyを、どちらも見たことのないモデルで評価します。それぞれがどれだけ性能を落とすかの差が、このロボットにおけるランダム化の価値です。

The spread is wide exactly where the hardware people disagree and narrow where they agree, and it is applied to all fourteen servos together, the way a batch of the same servo would vary. Nominal values are captured once at construction, so every apply is relative to the vendored model and nothing compounds; restore() puts every array back bit for bit, and a test checks that.

幅はハードウェア担当者の意見が分かれる箇所でちょうど広く、一致する箇所では狭くなっています。また、同じサーボのロットがばらつくのと同じように、14サーボすべてに同じ値を適用します。 公称値は構築時に一度だけ記録するため、どのapplyも同梱のモデルを基準にしており、変化が累積しません。restore()はすべての配列をビット単位で元に戻し、それをテストで確認しています。

OMP_NUM_THREADS=1 nice -n 10 python ppo.py --total-steps 50000000 --chunk-steps 25000000 --tag v2dr --reward v2 --dr
python eval_gap.py --nominal runs/ppo_v2_chunk1.pt --dr runs/ppo_v2dr.pt   # -> runs/gap.json

Both policies are the first 25M-step chunk of a 50M run (the nominal one is runs/ppo_v2_chunk1.pt; its second chunk is in section 13, but this table compares like with like): one training seed each, and the same configuration apart from randomisation. The randomised run is set up as 50M in two chunks, not as a single 25M run, so that its learning-rate anneal matches the nominal policy's. It took 2.4 hours at about 3 300 environment steps per second. Each cell is 100 episodes × 5 seeds, the same seeds everywhere, and ± is the spread of the five per-seed means.

どちらのpolicyも、50Mの実行の最初の25M stepのchunkです（公称のものはruns/ppo_v2_chunk1.pt。その2つ目のchunkは13節にありますが、この表では条件を揃えて比較しています）。 学習seedはそれぞれ1つで、ランダム化以外の設定は同じです。ランダム化した実行は、学習率の減衰を公称のpolicyと揃えるため、単独の25M実行ではなく2 chunkの50Mとして設定しています。 約3 300 environment steps/sで2.4時間かかりました。各セルは100 episodes × 5 seedsで、seedはすべて共通、±は5つのseed別平均のばらつきです。

Upright is the share of steps with the trunk within about 26° of vertical. Survival is the share with the trunk above the 4 cm fall height. Trunk height is the median of per-episode medians, and 12 cm is standing. Push recovery is left out because it reads 0.93–1.00 in every cell, the degenerate metric from section 13.

Uprightは胴体が鉛直から約26°以内にあるstepの割合、survivalは胴体が転倒判定の高さ4 cmより上にあるstepの割合です。 胴体の高さはepisodeごとの中央値のさらに中央値で、立っている状態は12 cmです。pushからのrecoveryは、どのセルでも0.93–1.00となり13節で述べた退化した指標なので、表から外しています。

Backlash: the randomised policy barely notices it (+3.2 return, −0.04 upright), while the nominal one loses 15 and 0.09 and falls more often. That is the robustness randomisation is meant to buy, and it bought it, but around a worse posture. The nominal policy on backlash is still upright more often than the randomised one on the model it trained on. Rollers: the randomised policy collapses, losing 165 of return, with its median trunk 2 mm above the fall line. The nominal policy does better on rollers than on its own model, so for a policy that actually stands this is not a harder physics model at all. A crouch held up by randomised foot friction has nothing to push against on free-rolling contacts. That is a hypothesis, not a measurement.

Backlash：ランダム化したpolicyはほとんど影響を受けません（return +3.2、upright −0.04）。一方、公称のpolicyは15と0.09を失い、倒れる頻度も増えます。 これはランダム化で得ようとしていた頑健性そのもので、実際に得られましたが、より悪い姿勢を軸にしたものでした。backlash上の公称policyでさえ、学習に使ったモデル上のランダム化policyより直立している時間が長いのです。 Rollers：ランダム化したpolicyは崩壊し、returnを165失い、胴体の高さの中央値は転倒ラインのわずか2 mm上でした。公称のpolicyはrollersの方が自分のモデルより良い結果なので、 実際に立てるpolicyにとっては、これはまったく難しい物理モデルではありません。ランダム化した足の摩擦に支えられたしゃがみ姿勢は、自由に転がる接触では踏ん張る先がない、と考えられます。これは仮説であり、計測ではありません。

Net: on this robot, under this reward, at half the schedule and one seed, domain randomisation made the policy worse. That is the question step 4 was built to answer, and it is reported as it came out. What it does not settle: both runs share step 3's step-size problem, milder here (approximate KL rising to 0.32 against 0.76), and neither used the KL stop added afterwards. The likely cause is the reward. Its height term is linear and blind to tilt, so a crouch at 9 cm earns about 1.2 per step every step, against 2.0 for a stand that sometimes ends on the floor near 0.5. Randomised physics makes standing harder to learn and bracing safe under every sample. Testing that needs a new reward version with its own baseline, not a tweak to this one.

結論：このロボット、このreward、予定の半分の学習量、seed 1つという条件では、domain randomisationはpolicyを悪化させました。 これがstep 4で答えるべき問いであり、出た結果をそのまま報告しています。未解決の点もあります。2つの実行はどちらもstep 3のstep sizeの問題を抱えており（ここでは近似KLが0.76に対して0.32まで上昇と軽め）、 後から加えたKL stopはどちらにも使っていません。原因として最も考えられるのはrewardです。height項は線形で傾きを見ないため、9 cmのしゃがみ姿勢は毎step約1.2を稼ぎ続けます。 これに対し、立つ姿勢は2.0を得られるものの、ときどき床に倒れて0.5付近になります。ランダム化したphysicsのもとでは立つことの学習が難しくなり、踏ん張る姿勢はどのサンプルでも安全になります。 これを検証するには、このrewardを微調整するのではなく、独自のbaselineを持つ新しいrewardバージョンが必要です。

export_onnx.py writes one ONNX graph from the raw 48-dim observation to the 14-dim mean action, with the normaliser folded in as (obs − mean) / std, clipped. A policy shipped without its normaliser is a different policy, and a controller on the robot should not have to know the normaliser existed.

export_onnx.pyは、生の48次元observationから14次元の平均actionまでを1つのONNXグラフとして出力します。normaliserは(obs − mean) / std（clip付き）として組み込みます。 normaliserなしで出荷したpolicyは別のpolicyです。ロボット側のcontrollerが、normaliserの存在を意識しなくて済むようにすべきです。

Verification comes before timing. 1,000 observations from the policy's own rollouts, not white noise, whose range the normaliser has never seen, go through both paths and the maximum difference must be under 1e−5. test_export.py proves the fold with a random actor: the graph disagrees with the un-normalised actor and agrees with the training-time path, and a huge observation gives the same finite answer both ways, so the clip survived export. Then ONNX Runtime latency on one intra-op thread, batch 1, p50 and p99 over 2,000 calls, which is the shape an on-robot controller runs at 50 Hz.

時間計測より先に検証を行います。normaliserが一度も見たことのない範囲のホワイトノイズではなく、policy自身のrolloutから取った1,000個のobservationを両方の経路に通し、 最大差が1e−5未満であることを求めます。test_export.pyはランダムなactorで組み込みを証明します。グラフは正規化なしのactorとは一致せず、学習時の経路とは一致します。 また極端に大きなobservationを入れても両方で同じ有限の値が返るので、clipがexport後も残っていることがわかります。そのうえで、ONNX Runtimeのlatencyを1 intra-opスレッド・batch 1で2,000回呼び出し、p50とp99を計測します。 これはロボット上のcontrollerが50 Hzで動くときの形です。

python export_onnx.py runs/ppo_v2_chunk1.pt   # -> runs/policy_v2.onnx, runs/onnx_v2.json

Measured on the chunk-1 policy:

chunk 1のpolicyでの計測結果：