部分可观测：帧堆叠与 RNN

1. 同一位置，不同速度，最优动作相反

四足底盘上只给关节位置、不给速度时，policy 看到 $s_{t} = (q_{t})$ 却要做 $a_{t} = q ˙_{t}$ 的决策——同一 $q_{t}$ 可能来自静止，也可能来自高速接近限位，最优动作完全相反。形式上这是 POMDP：真实 Markov 状态 $x_{t}$ 含速度与接触信息，观测 $o_{t} = π (x_{t})$ 丢信息。仍用 $π (a ∣ o_{t})$ 训，等价于在 belief $b (x_{t} ∣ o_{1 : t})$ 上近似，只是不显式维护 belief。

若按 MDP 假设硬训，loss 会降但 deploy 行为随机——因为同一 obs 对应多个 hidden state，policy 学的是在这些 state 上的平均策略，而不是任一具体状态下的最优动作。上次 locomotion 项目，去掉 velocity 后 flat MLP 在 sim 里 reward 曲线仍缓慢上升，真机却站不稳——根因是 POMDP 未处理，不是 PPO clip 的问题。

2. Frame stacking：最便宜的 Markov 近似

把最近 $k$ 帧 obs 拼接， $o^{'} t = [o_{t}, \dots, o t - k + 1]$ ，用有限历史近似 velocity 与加速度。Gymnasium 一行可试：

python

from gymnasium.wrappers import FrameStackObservation
env = FrameStackObservation(env, stack_size=4)

若加 stack 后 return 从接近零到有信号，基本可断定原 obs 非 Markov。Atari 常见 $k = 4$ ；locomotion 四帧往往够用，再长靠 RNN。Deploy 延迟约 $(k - 1) \times d t$ ——stack 太大增加输入维数、sim 内存和 reactiveness 损失，要在 memory 与响应间折中。Lidar 单 scan 无 velocity，两帧 stack 可近似 speed；三帧以上才稳定估计加速度。

Stack 帧数 ablation 写 README 推荐值；deploy 文档注明 latency = $(k - 1) \times$ control_period，让控制工程师评估是否可接受。

3. Recurrent policy：更长 memory 的代价

LSTM hidden 跨 step 携带历史，episode reset 必须清零 hidden，否则跨 episode 泄漏污染训练。SB3 RecurrentPPO 训练慢、BPTT truncate 限制 memory，deploy 要 batch=1 管理 hidden——非必要不上 RNN。Belief-state 方法（粒子滤波 + RL）仅在 contact 复杂、stack 不够时用；多数 locomotion 四帧 stack 够用。

Recurrent 训练 truncate 太短，长依赖学不到；truncate 太长，梯度 vanish 且 wall-clock 爆炸。Eval 时 hidden state 要正确 carry 和 reset——eval 单帧而 train 用 RNN 等于换分布。Recurrent policy deploy 比 MLP 麻烦，要有 hidden state 持久化与 reset 协议。

4. State estimation：机器人里的第三条路

EKF/粒子滤波先估 full state，再喂 RL。机器人项目里接触复杂、传感器 fusion 已有成熟链路时，有时比纯 end-to-end 稳——代价是多一条估计链路的调参与延迟。State estimation 失败时 RL 收到错误 state，表现比 POMDP 更糟；估计器与 policy 的接口契约要写清（坐标系、延迟、丢包处理）。

5. 诊断：oracle 上界

同一 obs 多次 rollout，若最优动作应不同却 policy 输出相同且 performance 差，优先加 history。做一次 oracle 实验：把真速度（或真 object pose）喂 policy，测 performance 上界；若 oracle 仍差，问题在 dynamics/reward 不在 POMDP。Belief-free baseline：oracle velocity 喂 policy 的上界实验，一次 run 即可判断 POMDP 损失多少 performance。

6. Camera 掉帧与 train/eval 一致

Camera 掉帧会让 history 断档——train 用 stack，deploy 要有 hold-last-frame 并测；train 随机 camera dropout 可增鲁棒。Eval 与 train 观测构造必须一致；eval 单帧而 train 四帧等于换分布。无 camera dropout aug 则 POMDP pipeline 在 deploy 掉帧时脆弱——要有 hold-last-frame 策略并测 shift 程度。

7. 常见失败

stack 太短仍 non-Markov；RNN eval 忘记 reset hidden；Recurrent 与 MLP 混用 eval 脚本。Stack 太大增加 sim 内存，分布式 rollout 时带宽成瓶颈。Belief MDP 理论上用 belief state，实践中 frame stack 是 cheap approximation——够用就别上 RNN。

8. 案例：velocity 未观测导致 sim 训、真机崩

Sim 里 physics 直接给 full state 做 ablation 时误删 velocity channel，policy 在 sim 仍缓慢进步（因为 contact 隐式编码部分速度信息），真机只有 encoder 位置反馈，同一 policy 站不稳。Oracle 实验：喂真 velocity 后 performance 翻倍，确认 POMDP 损失。加四帧 stack 后 sim 与 real gap 缩小——根因是 obs 非 Markov，不是 sim2real domain gap。

9. 验收

故意去 velocity，flat MLP 崩、加 stack 恢复 → POMDP 确诊。
Train/eval/deploy 观测构造一致（stack 长度、掉帧策略）。
Oracle velocity 实验量化 POMDP 损失。
MLP+stack vs LSTM 同任务比 sample efficiency 与 wall-clock。
README 写推荐 stack 帧数与 deploy latency。

10. 与 PPO 的选型

部分可观测下先 stack 再选算法——PPO 与 SAC 都假设输入是 Markov 的近似。Stack 后仍不够再考虑 RecurrentPPO 或 state estimation；别在 obs 非 Markov 时换五个 on-policy/off-policy 算法。Frame stack 的 deploy 契约：inference 端必须维护同样长度的 history buffer，reset 时清空；ROS2 节点里 history 与 RL step 对齐，掉帧时 hold-last 策略要测。Locomotion 项目经验：四帧 stack + MLP 在多数地形够用，contact-rich 攀爬再考虑 RNN。Belief 粒子滤波 + RL 我仅在 stack 与 RNN 都不够时用，工程复杂度高，要有充分 ablation 才上。

11. 录包与 deploy 契约

Deploy 端维护与 train 同长度的 history buffer，reset 清空；ROS2 节点里 history 与 RL step 对齐。录包若行为不稳定，含 obs 各 channel 与 stack 构造——分不清 POMDP 还是 timing 时先对齐 obs 契约。Camera 掉帧 hold-last 要测；train 随机 dropout 增鲁棒。Oracle velocity 实验量化 POMDP 损失，写进 README 推荐 stack 帧数与 deploy latency。