Isaac LabとPPOで始めるUnitree G1のボトル把持・持ち上げ強化学習プロジェクト：0.62 kgへのMass CurriculumとSafe Approach Policy

はじめに

前回の記事では、Unitree G1 Inspire Handを対象に、Isaac Lab上でボトル形状オブジェクトを把持・持ち上げる強化学習環境を構築しました。

前回までに確認できた主な内容は、以下の通りです。

• fixed-base G1とInspire Handを使ったRL環境
• safe / ingress / grasp / liftを分けたscripted phase controller
• slow contact / squeeze / lift trajectory
• 軽量なbottle-like objectに対するscripted grasp / lift baseline
• 12D hand residual PPO
• fixed initial stateでのdeterministic lift / hold showcase
• self-collisionを考慮したsafe pre-grasp policy

前回の記事の最後では、次の段階として、ボトルの初期位置をx/y方向に±1.5 cm変化させるsmall bounded RandPosへ進む予定としていました。

しかし、実際にRandPos taskを試してみると、単純にhand residualの学習範囲を広げるだけでは解決できない問題が見つかりました。

また、前回使用していた0.08 kgの軽量なbottle-like objectでの成功だけでは、600 ml飲料ボトルに近い質量条件でのgrasp / retentionを説明できません。

そこで今週は、当初予定していたRandPos trainingをそのまま継続するのではなく、課題を以下の二つに分けて取り組みました。

1. 0.62 kg条件まで段階的に適応するMass Curriculum
2. dynamic bottleを倒さずに外側まで近づくSafe Approach Policy

さらに、それぞれのpolicyを個別に評価した後、Stage 1からStage 2へ接続するcontrolled ingressの検証も行いました。

この記事では、今週実施した以下の内容をまとめます。

• hand-only RandPosで見つかった限界
• 0.08 kgから0.62 kgまでのMass Curriculum
• 0.62 kg grasp / lift policyのformal deterministic evaluation
• dynamic RandPos対応のSafe Approach Policy
• Stage 1 policyのformal deterministic evaluation
• Stage 1とStage 2を接続するcontrolled ingress
• integration時に発見したIsaac Labのdecimation問題
• 現在の到達点と次週の予定

本記事の結果は、Isaac Lab上のsimplified rigid-body bottleを使用したsimulation結果です。実際のPETボトル、実機G1の性能、安全性、sim-to-real transferを示すものではありません。

前回からの課題

前回の構成では、armの大きなtrajectoryをscriptedに固定し、PPOにはInspire Handの12D residual actionを担当させていました。

scripted arm trajectory
  + scripted hand target
  + 12D PPO hand residual
  ↓
grasp formation
  ↓
lift
  ↓
retention

この構成は、固定初期位置の軽量ボトルに対して、contact adaptationやanti-slip correctionを学習するためのbaselineとしては有効でした。

一方で、次の二つの制約が残っていました。

1. Arm trajectoryがボトル位置に追従しない

ボトル位置を変更しても、scripted arm trajectoryは同じ位置へ移動します。

そのため、数cm程度の位置ずれであっても、hand residualだけではgrasp positionまで補正できない可能性がありました。

2. 使用していたボトルが軽量だった

前回のbottle-like objectは0.08 kgでした。

これは接触trajectoryのfeasibilityを確認するための軽量proxyとしては有効ですが、600 ml飲料ボトルに近い質量条件ではありません。

今回、簡易的なfull-bottle conditionとして、以下を想定しました。

liquid:
  approximately 0.60 kg

bottle / cap:
  approximately 0.02 kg

total:
  0.62 kg

ただし、これは質量のみを近づけたsimplified conditionです。

実際のPETボトルに存在する以下の要素は含まれていません。

• 内容液の揺れ
• center of massの変化
• PET素材の変形
• labelや表面状態による摩擦変化
• bottle wallの柔軟性
• capやneckの詳細な接触形状

Hand-only RandPosで分かった限界

まず、前回予定していた通り、ボトルの初期位置をx/y方向に±1.5 cm変化させるRandPos taskを実装しました。

条件は以下の通りです。

bottle position:
  x/y ±0.015 m

arm:
  fixed scripted trajectory

hand:
  12D PPO residual

bottle:
  dynamic rigid body

training:
  128 parallel environments
  300 iterations

このtaskでは、PPOはfinger jointのみを補正し、arm trajectoryはボトルのrandom positionに関係なく同じ位置へ移動します。

Training結果

最終付近では、以下の値を確認しました。

Mean rewardは正の値になりましたが、strict retention / lift successは0でした。

Deterministic playbackを確認すると、主なfailureは以下でした。

bottle position changes
  ↓
scripted arm moves to the nominal ingress pose
  ↓
hand contacts the bottle from an incorrect position
  ↓
bottle is pushed or toppled
  ↓
finger residual cannot recover the grasp

つまり、PPOのrewardが上昇していても、ボトルを把持・持ち上げるbehaviorが成立しているとは限りません。

なぜhand residualだけでは対応できなかったか

12D hand residualが担当できるのは、主に以下のようなlocal correctionです。

• finger contactの微調整
• thumb oppositionの調整
• grip強度の補正
• lift中のanti-slip correction

一方で、ボトル位置が変化したときに必要になるのは、arm全体のfinal approach positionの補正です。

finger-scale correction
≠
arm-scale positioning correction

この結果から、RandPos対応をhand-only policyに任せるのではなく、以下のように役割を分ける必要があると判断しました。

Stage 1:
  bottle positionに応じたarm approach

Stage 2:
  grasp / squeeze / lift / retention

これは今週の最初の重要なfailure caseでした。

Hand residual policyは、数cm規模のarm positioning errorを補正するpolicyではない。

RandPosより先にMass Curriculumへ進んだ理由

Hand-only RandPosの限界が分かった一方で、もう一つ重要な問題がありました。

前回の0.08 kg bottleで学習したpolicyが、0.62 kgでもgrasp / retentionを維持できる保証はありません。

実際に、scripted zero-residual conditionで0.62 kg bottleを動かしたところ、close / squeeze sequence自体は実行できましたが、意味のあるliftには至りませんでした。

代表的な結果は以下でした。

Hand stiffnessを50から100へ増やしても、lift量はほとんど変化しませんでした。

これは、単純にactuator stiffnessを上げればfull-mass graspが成立するわけではないことを示しています。

また、actual joint positionを確認すると、四指の一部はtargetに近い位置まで動いていましたが、thumb intermediate / distal jointは接触によって大きく制限されていました。

つまり、ボトル質量が増えたときの問題は、単純なtarget angle不足ではなく、以下の要素を含むcontact-richな問題です。

• thumb-to-finger opposition
• handとbottleの相対位置
• contact force distribution
• squeeze中のobject displacement
• lift開始時のslip
• bottle massによるrequired grip forceの増加

そこで、0.08 kgから0.62 kgへ一度に変更するのではなく、段階的に質量を増やすMass Curriculumを採用しました。

0.08 kgから0.62 kgへのMass Curriculum

今回使用したmass stagesは以下です。

0.08 kg
  ↓
0.20 kg
  ↓
0.35 kg
  ↓
0.50 kg
  ↓
0.62 kg

基本となるscripted trajectoryとhand residual actionは、各stageで共通です。

arm:
  safe → ingress → slow lift

hand:
  side-open
  → slow contact
  → slow squeeze
  + 12D PPO residual

self-collision:
  enabled

action:
  12D hand residual

Transfer方法

質量を変更した各stageでは、通常のresumeではなく、weights-only transferを使用しました。

transferred:
  actor weights
  critic weights

reset:
  optimizer state
  training iteration
  log directory

質量変更後は、同じtaskの単純な継続ではなく、異なるdynamic conditionへのadaptationとして扱いました。

Optimizer stateまで引き継ぐと、前の質量条件に対するupdate historyが新しい条件で適切とは限りません。

そのため、network weightsはinitial policyとして再利用しつつ、optimizerとiterationはresetしました。

各Mass Stageで確認したbehavior

各stageの概要は以下です。

0.20 kg

0.20 kg stageでは、formal success signalは約1〜3%程度でした。

実用的な成功率ではありませんが、deterministic playbackではボトルを持ち上げるbehaviorを確認しました。

特に、thumbを使ってボトルをfinger側へ引き寄せるようなbehaviorが見られました。

これは、scripted targetだけではなく、learned residualがcontact conditionに応じて動作を変えている可能性を示しています。

ただし、単一のdeterministic playbackはrobustnessの証明ではありません。

0.35 kg

0.35 kg stageでは、0.20 kg checkpointからweights-only transferを行いました。

Deterministic playbackではliftを確認しましたが、ボトルは大きく傾いていました。

lift:
  observed

upright retention:
  not confirmed

これは完全なsuccessではありませんが、質量を増やしてもlearned behaviorが完全には失われなかったことを示すcurriculum signalとして扱いました。

0.50 kg

0.50 kg stageでもformal success rateは低い状態でした。

一方で、selected deterministic playbackではmeaningful liftを確認しました。

Training終盤のformal successは約1.56%で、128 environments中およそ2 environmentに相当します。

したがって、この段階では以下のように評価しました。

0.50 kgでもgrasp / lift behaviorは残っているが、practicalまたはrobustなpolicyとはいえない。

0.62 kg

最終stageとして、simplified full-bottle conditionである0.62 kgへadaptationしました。

最初のtrainingでは、episodeをrandom phaseから開始する設定が含まれていました。

しかし、このtaskは以下のようなmulti-phase controllerです。

startup
  ↓
ingress
  ↓
side-open
  ↓
contact
  ↓
squeeze
  ↓
lift
  ↓
hold

このようなtaskでrandom episode length initializationを使用すると、startupやcontact前のphaseを飛ばした状態からtraining episodeが始まる可能性があります。

そこで、次のconsolidation runではrandom episode-length initializationを無効化し、毎回同じphase順序で開始するようにしました。

最後のCheckpointが最良とは限らない

0.62 kg consolidationでは、training前半のcheckpointが比較的高いsuccess signalを示しました。

一方で、trainingを継続すると、後半のcheckpointではbehaviorが低下しました。

early training:
  better retention behavior

late training:
  degraded behavior

この結果から、単純に最終iterationのcheckpointを選択するのではなく、以下を組み合わせて選定しました。

• task-specific training metric
• deterministic playback
• strict termination-based evaluation
• bottle lift量
• object displacement
• retention behavior

RLでは、trainingが最後まで完了したことと、最後のcheckpointが最も良いことは同じではありません。

今回も、最終checkpointではなく、比較的早いpeak付近のcheckpointを正式評価の対象にしました。

0.62 kg Stage 2 PolicyのFormal Evaluation

前回の記事では、deterministic playback videoを主なshowcaseとして使用しました。

しかし、単一のMP4だけでは、policyのsuccess rateを判断できません。

そこで今回は、複数environmentでdeterministic inferenceを実行し、termination managerの結果からsuccessを集計するformal evaluatorを作成しました。

評価条件は以下です。

bottle:
  simplified rigid bottle

mass:
  0.62 kg

initial position:
  fixed nominal position

policy:
  deterministic inference

success:
  strict retention / lift termination

evaluation:
  multiple episodes
  multiple seeds

Evaluation結果

また、合計768 episodesにおいて、object-out-of-workspaceは0件でした。

strict retention / lift success:
  766 / 768

object out of workspace:
  0 / 768

timeout:
  2 / 768

この結果から、選択したStage 2 policyは、評価対象とした固定条件では高い成功率を持つことを確認できました。

この結果は、固定初期位置、固定geometry、固定mass、simplified rigid bottleに対するsimulation結果です。RandPos robustnessや実機性能を意味するものではありません。

Training RolloutとDeterministic Evaluationを分ける

今回、training中のstochastic rollout metricと、formal deterministic evaluationに大きな差がありました。

これはStage 2だけではなく、後述するStage 1でも確認されました。

Training時のpolicy actionにはexploration noiseが含まれます。

training:
  stochastic action sampling

evaluation:
  deterministic actor output

そのため、training rolloutでのsuccess rateと、deployment時に使用するdeterministic policyのsuccess rateは一致しない場合があります。

今回の結果から、以下を分けて記録する必要性を再確認しました。

1. Training-time stochastic rollout
2. Deterministic checkpoint playback
3. Multi-episode formal deterministic evaluation
4. Scripted zero-residual baseline
5. Held-out randomized evaluation

Mean rewardが上昇したことや、training中に一部のenvironmentで成功したことだけでは、deterministic policyがtaskを解けるとは判断できません。

逆に、training rolloutのsuccess rateが低くても、actor meanを使用したdeterministic inferenceでは安定する場合があります。

RandPos対応をSafe Approach Policyとして分離

Stage 2のfull-mass fixed-condition policyを確定した後、再びRandPosへ戻りました。

Hand-only RandPosのfailureから、bottle positionに応じたarm final approachが必要であることが分かっていました。

そこで、新しいStage 1では、直接inner grasp poseへ移動するのではなく、ボトルの外側にあるpre-contact waypointをtargetにしました。

dynamic bottle
  ↓
outer safe waypoint
  ↓
controlled ingress
  ↓
grasp-ready pose
  ↓
Stage 2

なぜouter waypointが必要だったか

以前のStage 1 policyでは、graspに近いinner targetへ直接approachさせていました。

Kinematic bottleを使ったtrainingではtargetへ到達できましたが、dynamic bottleへ切り替えると、close前にbottleへ接触し、押したり倒したりするfailureが発生しました。

direct inner approach
  ↓
premature bottle contact
  ↓
bottle displacement / toppling
  ↓
invalid Stage 2 handover

そこで、Stage 1の目的を次のように限定しました。

Open handとsafe wrist姿勢を維持したまま、dynamic bottleを動かさずに外側のpre-contact poseへ到達する。

新しいStage 1 taskの条件は以下です。

bottle:
  dynamic 0.62 kg

bottle position:
  x/y ±0.015 m

wrist:
  yaw 0.0
  roll 0.0
  pitch 0.0

hand:
  open

self-collision:
  enabled

action:
  4D shoulder / elbow

target:
  outer pre-contact waypoint

Stage 1ではfinger contactを学習しません。

目的は、Stage 2へ安全に接続できるarm positionを作ることです。

Stage 1 Safe Approach PolicyのFormal Evaluation

Training終盤のstochastic rolloutでは、pregrasp successはおよそ55〜63%でした。

stochastic training rollout:
  approximately 0.55–0.63

この値だけを見ると、Stage 1はまだ十分ではないように見えます。

しかし、Stage 2と同じようにdeterministic multi-episode evaluatorを作成し、formal evaluationを行いました。

Evaluation条件

bottle:
  dynamic 0.62 kg

RandPos:
  x/y ±0.015 m

wrist roll:
  0.0

hand:
  open

self-collision:
  enabled

policy:
  deterministic inference

Evaluation結果

Failure outcomeは以下でした。

今回評価したbounded RandPos conditionでは、deterministic policyがすべてのepisodeでouter pregrasp targetへ到達しました。

Training rolloutとの差は、stochastic explorationとdeterministic actor meanの違いによるものと考えられます。

この結果を受け、Stage 1 policyは追加trainingを行わず、integration用のfrozen policyとして扱うことにしました。

768/768という結果は、評価した条件におけるempirical resultです。すべての未知条件に対して成功率100%を保証するものではありません。

Stage 1とStage 2の間にControlled Ingressを追加する

Stage 1とStage 2を個別に評価できた後、両者を接続するbridgeを実装しました。

ただし、Stage 1のouter poseからStage 2のinner grasp poseへ瞬間的に切り替えると、dynamic bottleへ大きな衝撃を与える可能性があります。

そこで、Stage 1とStage 2の間にdeterministicなcontrolled ingressを追加しました。

Stage 1:
  outer safe approach
    ↓
  outer hold
    ↓
Controlled ingress:
  slow arm interpolation
  wrist roll 0.0 → -0.25
    ↓
Stage 2:
  side-open
  → contact
  → squeeze
  → lift
  → hold

Stage 1では、bottleへの早期接触を避けるためwrist rollを0.0に保ちます。

Controlled ingress中に、arm positionとwrist rollを同時にStage 2のgrasp-ready poseへ補間します。

最初のBridgeではStage 2 ResidualをZeroにする

最初からStage 2のlearned residualを有効化すると、failureが発生した場合に原因を分けられません。

例えば、以下のどこに問題があるのか判断しにくくなります。

• Stage 1 final pose
• outer hold
• controlled ingress
• wrist interpolation
• hand pre-shape timing
• Stage 2 observation
• learned residual

そこで、最初のbridge diagnosticではStage 2 learned residualを厳密にzeroにしました。

Stage 1:
  learned deterministic policy

controlled ingress:
  enabled

Stage 2 scripted prior:
  enabled

Stage 2 learned residual:
  exactly zero

この構成により、まずStage 1からStage 2までのhandover geometryとbottle stabilityだけを確認しました。

Nominal Zero-Residual Bridgeの結果

Nominal bottle positionで実行した結果、Stage 1はouter gateへ到達し、その後controlled ingressを通ってStage 2へ移行しました。

代表的な結果は以下です。

Stage 1 outer gate:
  reached

controlled ingress:
  approximately 60 environment steps

Stage 2:
  started

unsafe before Stage 2:
  false

workspace violation:
  false

Handover時のbottle stateは以下でした。

この結果から、現在のnominal conditionでは、learned Stage 1からcontrolled ingressを通じてStage 2へ接続できることを確認しました。

一方で、zero-residual conditionではstrict retention / lift successは成立しませんでした。

strict retention / lift:
  false

maximum center-height increase:
  approximately 4.8 mm

final center-height increase:
  approximately 0.04 mm

maximum horizontal displacement:
  approximately 43 mm

つまり、ボトルは意味のある高さまで持ち上がらず、contact phase後に約4.3 cm水平方向へ移動しました。

この結果は、以下の二つを分けて評価する必要があることを示しています。

safe Stage 1-to-Stage 2 handover:
  passed

full-mass grasp / lift without learned residual:
  failed

Zero-residualでliftできなかったことは、今回のbridge全体が失敗したことを意味しません。

むしろ、controlled handover自体は成立している一方で、0.62 kg grasp / retentionにはStage 2 learned residualが必要であることを確認できました。

Integrationで発見したDecimationのTiming問題

Stage 1とStage 2を統合する過程で、Isaac Labのcustom ActionTermに関する重要な実装問題を発見しました。

今回のenvironmentでは、以下の設定を使用しています。

physics step:
  approximately 0.0083 s

environment step:
  approximately 0.0167 s

decimation:
  2

つまり、policyが1回actionを出力する間に、physics simulationは2回更新されます。

Custom ActionTermの実行タイミング

今回使用しているmanager-based environmentでは、概念的に以下の違いがあります。

process_actions():
  environment action stepごとに実行

apply_actions():
  physics substepごとに実行

最初の実装では、controlled ingressやStage 2 phaseのcounterをapply_actions()内でincrementしていました。

そのため、decimationが2の場合、counterが1 environment stepにつき2回進んでいました。

修正前の挙動

設定上は60 stepsのcontrolled ingressでしたが、実際には約30 environment stepsで終了していました。

また、Stage 2のside-open、contact、squeeze、lift timingも、想定のおよそ2倍の速度で進んでいました。

修正方法

process_actions()が呼ばれたときにenvironment-step updateが必要であることを記録し、その後の最初のapply_actions()でのみphase counterを進めるように変更しました。

残りのphysics substepでは、前回計算したjoint targetを保持します。

概念的には以下です。

process_actions():
  new environment action received
  update_pending = true

first apply_actions():
  update phase
  update counter
  compute new targets
  update_pending = false

remaining physics substeps:
  hold previous targets
  do not advance phase counter

修正後の挙動

Controlled ingressは、設定した約60 environment stepsに近い速度で進むようになりました。

Handover時のbottle speedも、およそ半分まで低下しました。

この問題は、simulation上でmulti-phase controllerを実装するときに特に注意が必要です。

Phase counterをphysics substep単位で進めるのか、environment action step単位で進めるのかを明確に分ける必要がある。

単に変数名をstepとするだけでは、そのstepがどの時間軸を表しているのか分からなくなります。

Policy Integrationで遭遇したCheckpoint Contractの問題

もう一つの重要なfailureは、Stage 1 checkpointのnetwork architectureとobservation dimensionを手動で推測してしまったことです。

最初のbridge implementationでは、Stage 1 actorを以下のように仮定していました。

assumed observation:
  21D

assumed actor:
  21 → 256 → 128 → 64 → 4

しかし、実際のcheckpoint tensor shapeを確認すると、正しいcontractは以下でした。

observation:
  24D

actor:
  24 → 128 → 64 → 4

activation:
  ELU

Network architectureを誤って構築した場合、checkpoint weightを正しくloadできません。

また、observation dimensionが同じであっても、各observation termの意味や順序が異なれば、policy inputとしては互換性がありません。

そこで、bridgeではobservationを手動で再構成せず、Stage 1 training taskで使用したpolicy observation groupをそのまま再利用するようにしました。

Stage 1 training task observation
  ↓
exact same observation config
  ↓
integrated bridge runtime observation

今回の経験から、checkpoint compatibilityには少なくとも以下が必要だと分かりました。

• Network layer shape
• Activation function
• Observation dimension
• Observation term order
• Observation semantics
• Observation normalization
• Action dimension
• Action scale / offset

Policy checkpointが存在する場合、architectureやobservationを推測せず、checkpoint tensorとtraining task configをsource of truthとして扱う。

これは、異なるtask間でpolicyを再利用するときの重要な教訓でした。

Evaluation Scriptの整備で学んだこと

今回、Stage 1とStage 2の両方に対して、termination-based evaluatorを作成しました。

Official playback scriptはdeterministic behaviorの確認には便利ですが、複数episodeのtermination outcomeを集計する用途には向いていません。

そのため、formal evaluatorでは以下を直接集計しました。

success termination
object-out-of-workspace
timeout
other / multiple outcome

また、実行成功の判定にはprocess exit codeだけではなく、以下を確認しました。

• 明示的なstart marker
• result marker
• completion marker
• Python tracebackの有無
• JSON summary
• episode countの合計
• termination countの整合性

Simulation scriptでは、applicationが起動して終了codeが0であっても、実際のmain loopが実行されていない場合があります。

そのため、以下のようなmarkerを明示的に出力する方法が有効でした。

EVALUATION_START
EVALUATION_RESULT
EVALUATION_COMPLETION=OK

一方で、simulation_app.close()の後にmarkerが出力されることを必須条件にすると、shutdown processによってfalse failureになる場合もありました。

Completion markerはapplication shutdown前に出力し、その後はprocess statusとtracebackの有無を確認する方が適切でした。

今週のFailure Caseまとめ

今週は、単純にsuccess rateを上げるだけでなく、複数のfailureを通じてtask designとevaluation方法を見直しました。

Failure 1：Hand-only RandPos

fixed arm trajectory
  + randomized bottle position
  + hand residual
  ↓
incorrect contact position
  ↓
bottle push / toppling
  ↓
strict success 0

対策：

RandPos compensationをStage 1 arm policyへ分離

Failure 2：0.08 kgから0.62 kgへの直接適用

lightweight grasp prior
  ↓
full-mass bottle
  ↓
insufficient force closure
  ↓
no meaningful lift

対策：

0.20 → 0.35 → 0.50 → 0.62 kg
mass curriculum

Failure 3：Direct inner approach

policy approaches grasp pose directly
  ↓
premature dynamic bottle contact
  ↓
bottle disturbance before close

対策：

outer safe waypoint
  + controlled ingress

Failure 4：Training metricだけでの判断

mean reward increases
  ↓
visual or formal success remains absent

対策：

deterministic playback
  + termination-based multi-episode evaluation

Failure 5：Checkpoint contractの推測

assumed observation / architecture
  ↓
checkpoint incompatibility

対策：

inspect model_state_dict
  + reuse exact training observation config

Failure 6：Decimationによるphase timingの加速

phase counter updated per physics substep
  ↓
ingress / contact / lift execute approximately 2x faster

対策：

phase counter update once per environment action step

現在のPipeline

今週の作業後、pipelineは以下の構成になりました。

dynamic 0.62 kg bottle
  ↓
bounded x/y RandPos
  ↓
Stage 1:
  4D safe outer approach policy
  open hand
  wrist roll 0.0
  self-collision enabled
  ↓
outer hold
  ↓
controlled ingress:
  approximately 60 environment steps
  wrist roll 0.0 → -0.25
  ↓
Stage 2:
  scripted side-open / contact / squeeze / lift
  + frozen 12D learned hand residual
  ↓
strict retention / lift evaluation

現在、Stage 1とStage 2はそれぞれ個別のtaskでformal evaluationを完了しています。

重要なのは、これらのsuccess rateを単純に掛け合わせればintegrated success rateになるわけではないことです。

Stage 1の最終state distributionが、Stage 2のtraining distributionと一致しているとは限りません。

そのため、次の段階では、実際のStage 1 handover stateからStage 2 learned residualを実行し、統合後のformal success rateを測定する必要があります。

今週できたこと

今週の主な成果は以下です。

• Hand-only RandPos taskの実装とfailure分析
• Arm final approachとhand residualの役割分離
• 0.08 kgから0.62 kgまでのMass Curriculum
• Weights-only transfer workflow
• 0.62 kg policyのfixed-condition consolidation
• 0.62 kg Stage 2 policyのformal deterministic evaluation
• Dynamic 0.62 kg bottleに対するSafe Approach Policy
• x/y ±1.5 cm RandPosでのStage 1 formal evaluation
• Outer safe waypointとcontrolled ingressの実装
• Zero-residual nominal handoverの検証
• Checkpoint architecture / observation contractの修正
• Custom ActionTermのdecimation-aware timing修正
• Training metric、playback、formal evaluationの分離

数値としては、以下の結果を確認しました。

Stage 2 fixed-condition:
  766 / 768 strict retention / lift success

Stage 1 bounded RandPos:
  768 / 768 pregrasp success

Nominal controlled ingress:
  reached Stage 2
  no pre-Stage-2 safety violation

一方で、以下はまだ未確認です。

learned Stage 2 from actual integrated handover
integrated RandPos pick-and-lift success
realistic PET bottle behavior
perception-based bottle localization
real robot evaluation
sim-to-real transfer

次週：Integrated Pick-and-Liftの最終評価へ

次週は、このsimulation-first projectの最終integrationを進める予定です。

まず、今週metricで確認したzero-residual controlled ingressを動画でも確認します。

その後、同じnominal handover conditionで、固定済みのStage 2 learned residualを有効化します。

learned Stage 1
  ↓
controlled ingress
  ↓
learned Stage 2
  ↓
grasp
  ↓
lift
  ↓
retention

Nominal conditionでstrict retention / liftが成立した場合、次にx/y ±1.5 cm RandPosを含むintegrated multi-episode evaluationを実施します。

次週の評価では、以下を分けて記録する予定です。

• Stage 1 outer gate success
• Unsafe disturbance before Stage 2
• Controlled ingress completion
• Strict retention / lift success
• Object-out-of-workspace
• Timeout
• Bottle horizontal displacement
• Maximum lift height
• Uprightness
• Final hold duration

本シリーズの次回記事では、以下をまとめる予定です。

1. Learned Stage 2を接続したnominal integrated result
2. Integrated RandPos multi-episode evaluation
3. Failure distribution
4. Simulation-first project全体の最終評価
5. Real robotへ進む前に必要な追加検証

実機評価へ進む場合も、simulation policyをそのまま実機へ接続するのではなく、hardware configuration、joint mapping、control interface、velocity / torque limit、emergency stop、operator supervisionを別途確認する必要があります。

また、実機上でonline RL explorationを行う予定はありません。

まとめ

前回の記事では、0.08 kgの軽量bottle-like objectに対して、scripted grasp / lift baselineと12D hand residual PPOを構築しました。

今週は、そこからsmall bounded RandPosへ進もうとしましたが、hand residualだけではarm positioning errorを補正できないことが分かりました。

さらに、軽量bottleでの成功を600 ml飲料ボトルに近い条件へ拡張するため、0.20 kg、0.35 kg、0.50 kg、0.62 kgのMass Curriculumを実施しました。

その結果、0.62 kgの固定条件において、Stage 2 policyは766/768のstrict retention / lift successを記録しました。

RandPos対応については、grasp poseへ直接approachするのではなく、dynamic bottleの外側にあるsafe waypointをtargetとするStage 1 policyへ再設計しました。

Stage 1 policyは、x/y ±1.5 cmのbounded RandPosにおいて、768/768のpregrasp successを記録しました。

さらに、Stage 1とStage 2の間に約60 environment stepsのcontrolled ingressを追加し、nominal conditionでStage 2 handoverまで安全に到達できることを確認しました。

Integrationの過程では、checkpoint architectureやobservation semanticsを推測してはいけないこと、custom ActionTermのphase timingをphysics substepとenvironment stepで区別する必要があることも学びました。

現時点での到達点は、以下です。

0.62 kg bottleに対するStage 1 Safe ApproachとStage 2 Grasp / Liftを個別に構築・評価し、nominal conditionで両者をcontrolled ingressによって接続できることを確認した。

一方で、actual handover stateからlearned Stage 2を実行したintegrated grasp / liftと、RandPosを含むend-to-end evaluationはまだ完了していません。

次週は、learned Stage 2を接続したnominal integrated evaluationと、bounded RandPos multi-episode evaluationを実施し、このsimulation-first bottle pick-and-lift projectの最終結果をまとめる予定です。

成功したbehaviorだけでなく、hand-only RandPos、full-mass scripted grasp、direct inner approach、checkpoint contract、decimation timingなどのfailureも分けて記録しながら、simulation結果を過大評価しない形で引き続き検証を進めます。