Bimanual cabinet rl clean squashed

[RijulChaddha9504]

RL system for BiManual Arm

[wilsonchenghy]

@copilot review

[Copilot]

@copilot review

Here is my review of the changes in this PR. I fixed the concrete issues in commit Fix double _inner_edge_contact call, NameError in center_mul, missing newlines, dead _ARM_USD_PATH.

---

Bugs fixed

1. NameError in inner_edge_grip_reward when pose is None (pre-existing, rewards.py)
center_score was only assigned inside the else branch, but center_mul = torch.log(1 + 2*center_score) lived outside the if/else and would crash with NameError if _robot_ee_pose returned None. Moved the log-transform into the else block.

2. _inner_edge_contact called twice per step in pull_distance_reward (rewards.py)
inner_grip_strength(…) calls _inner_edge_contact internally, then pull_distance_reward called it again immediately for dual_mul. This double-read of the contact sensor is wasteful at 4096 envs × 60 Hz. Refactored to call it once and compute both grip_mul and dual_mul from the same result. The debug tracking that previously triggered a third _finger_contact_force call at the peak-f step now reuses the mag7/mag8 tensors already in scope.

3. Previous return grip_mul * distance_score * dual_mul * dual_mul — squaring dual_mul was a bug, correctly fixed in this PR.

---

Other fixes

• Missing trailing newlines in observations.py and bimanual_cabinet_env_cfg.py (both ended without \n).
• Dead code — _ARM_USD_PATH was defined in bimanual_arm.py but never referenced (BIMANUAL_ARM_CFG uses _ARM_URDF_PATH). Removed.

---

Design concerns (not blocking, but worth discussing)

Exponential reward scale may destabilize the critic
The new C*(exp(k*f) − 1) curve with C=1000, k=10 reaches ~22 M per step at f=1.0. With grip_mul ∈ [0,1] and dual_mul ∈ [1, 4], the per-step maximum is ~88 M. The previous piecewise C1 design was explicitly bounded to ≤2000 per step (~96k per episode) to keep the critic stable. An exponential that grows 10,000× over the drawer's travel range may cause value-function divergence — PPO's normalisation (if enabled) or the critic's output layer may not cope. Consider capping the exponent (e.g. min(k*f, 15)) or reverting to the bounded quadratic if training diverges.

TerminationsCfg.success terminates on any out-of-bounds (bimanual_cabinet_env_cfg.py, line 394)
joint_pos_out_of_manual_limit fires when drawer_top_joint < 0 (impossible physics but possible numerical noise) as well as when > 0.39 (true success). If the intent is to end episodes only on success, a tighter check (drawer_pos > 0.38) would be more accurate.

Joint naming inconsistency in bimanual_arm.py
JOINT_POS_LIMITS and LEFT_ARM_JOINTS use "joint1L" (capital L) while every other left joint uses lowercase l (joint2l…joint6l). resolve_joint_name handles the case-flip at runtime, but the inconsistency in the config dicts is confusing and could bite tools that do exact-match iteration.

Debug print() in hot reward path
single_claw_proximity, pull_distance_reward, and debug_inner_edge all call print() unconditionally every 96 steps. With 4096 envs at 60 Hz this is ~2560 prints/second of training, which can noticeably slow wall-clock time. Consider wrapping behind a --verbose flag or using logging.