动作和画面时间最近，就能配成训练样本吗？
把 机器人 日志按时间排序，为每帧图像找最近的一条动作，表格看起来就对齐了。但这条动作的时间，可能是希望到达目标的时刻；画面的时间，却可能是主机收到帧的时刻。两列数字接近，并不证明这条动作造成了下一帧的变化。
Diffusion Policy 的真实机器人实现提供了一个具体入口：同一组时间戳，一边作为机器人的 target_time，一边写入动作记录；后续轨迹插值又可能因速度约束推迟端点。计划、控制指令和传感器反馈属于不同事件；统一采样网格不能自动把它们变成已验证的因果配对。
本文核对官方仓库固定提交 5ba07ac6，并运行两个小型构造计算。没有连接机器人、 训练模型 或测量相机延迟；下面的数值用于暴露配对假设，不是该项目的机器人实验结果。
同一时间戳，先被用来做了什么
在 RealEnv.exec_actions 中，已经过时的请求先被过滤。剩下的 new_timestamps 进入两条路径：
python
self.robot.schedule_waypoint(
pose=new_actions[i],
target_time=new_timestamps[i]
)随后，动作累积器保存 new_actions 和同一组 new_timestamps。这段调用链能够确认：这里记录的是传给调度器的计划时间；它不是从机械臂反馈里读取的"动作已经达到"时间。1
一个容易误读的细节是：TimestampActionAccumulator.put 的注释把参数描述为动作将被发出的时间，区别于完成时间。但这个具体调用传入的，正是前面作为 waypoint target_time 的数组。阅读数据时，只看工具 类 注释不够，还要追到调用者究竟传了哪一列。所以即使工具属性叫 actual_timestamps，也要核对赋值和消费者，不能译为机械臂实际到达。这里不裁决所有调用场景，也不据此宣布项目存在控制故障。2
再往控制端走，调度器把传入时间从墙钟转换到单调时钟，然后交给插值器。转换发生在这一进程的调用路径中；这不是跨设备全局时钟已经同步的证明。控制循环按插值轨迹取当前位姿命令，再调用 servoL；收到的机器人状态另记 robot_receive_timestamp。因此，数据中的计划点、连续生成的控制命令、接收到的状态，不能仅凭一个 timestamp 字段互相替代。3
给时间列附一个事件定义
一份数据字典应同时说明时间单位、时钟来源、采集位置和事件。例如目标时间来自请求方，描述希望轨迹到达哪一刻；控制采样时间描述何时取出参考命令；接收状态时间描述主机何时读到反馈。单位统一只是便于表示，不会将三种事件统一成一个动作完成时刻。
过时请求过滤也应留意。发送方给了一组动作，接入方仅接受未来时间的部分，训练记录若另从发送端保存完整数组，就可能包含根本未进入调度的计划。本文固定源码证明过滤发生，但没有测某次真实请求被丢掉多少。实际审计应比较原请求与接受结果，保留索引关系，不能让被过滤对象看起来像已执行动作。
可以用一段短记录逐项写：原动作ID、请求时间、是否被接受、进入哪个控制队列、记录到了哪列。控制命令与反馈有独立采样频率时，再列相应来源。没有到达测量就保持未知，不能为了让表格每格都有值，将最近反馈时间无条件补成完成时间。
时钟转换也只是特定代码路径的一次映射。控制器用墙钟与单调钟关系转换目标，支持它内部的调度语义； 相机 设备时钟、其他主机和历史记录是否可比，需要额外证据。若只知道各列都是秒，仍不能直接求差作为端到端时延。先明确映射适用范围，再进行时间比较。
计划 100 毫秒到达，不等于轨迹端点就是 100 毫秒
插值器会比较请求时长与位移、旋转所需的最短时长，取其中最大值，再生成新的轨迹端点。关键位置是：
python
duration = max(duration, max(pos_min_duration, rot_min_duration))
last_waypoint_time = end_time + duration这意味着，即使调用端保存了原始计划时刻，限速后的轨迹端点也可能更晚。它仍是规划结果，不是机械臂实测到达时刻；即使端点未延长，设备仍可能有自己的 跟踪 过程，延长端点也不意味着中间命令都等到最后一刻。4
我把这条公式收窄成一维整数案例：从 0 毫米走到 100 毫米，不旋转；当前轨迹末端记为 0 毫秒，最大速度设为 500 毫米/秒。它至少需要 200 毫秒。脚本只计算公式，没有导入机器人控制器。
| 项目 | 构造值 |
|---|---|
| 请求到达时刻 | 100 毫秒 |
| 请求留出的时长 | 100 毫秒 |
| 位移与限速要求的最短时长 | 200 毫秒 |
| 公式生成的轨迹端点 | 200 毫秒 |
| 实测机械臂到达时刻 | 未测量 |
若把"计划 100 毫秒"直接改名为"100 毫秒已生效"，误差不是最近邻匹配精度不够，而是列的含义已被换掉。反过来，也不能把这张表解读为机器人前 200 毫秒完全不动：插值轨迹可以在到达端点前持续改变命令。开始运动、目标到达、图像能看见变化，本来就不一定是同一个时刻。
延迟不能只用一个数代替
在构造例子里，位移除以速度得到最短时长，再与请求时长比较。这只支持设定条件下的算术结果；速度参数不是实测平均速度，位移也不是相机反推。若真实动作还含旋转、不同路径或重规划，应按实际插值器与日志核对。不能把演示二百毫秒当成 项目 延迟标定值。
对目标位姿动作，标签表示希望到达哪里，而不是每步施加多少位移。对直接控制输入，标签可能对应持续区间。两类动作的数据列即使都叫action，配对方法也可能不同。先把动作空间与控制保持定义写清楚，再讨论是否需要考虑端点、开始时刻或某段反馈。
若下一条计划在前一条完成之前到达，参考轨迹还可能被重排或替换，原请求端点不能自动代表后来真正采用的路径。本文没有运行这类重规划案例，只建议把实际接受队列和参考轨迹版本作为排查线索。研究实际对齐时，不能仅从请求表还原所有控制过程。
因此本节给出的反证很具体：计划列不能被无证据改名为完成列。要进一步声称动作造成某帧变化，还须从轨迹到反馈及图像记录继续追。保留这几层关系，才能知道下一项测量是控制跟踪、视觉时序还是数据重采样。
错一拍，数据表会怎样变
下面与前面的限速端点是两个独立构造反例，不是同一条机器人轨迹。在这个更简单的系统里，所有事件共享同一个理想整数时钟，每100毫秒一步。k为步编号，x[k]为第k步边界的位置（任意单位，初始x[0]=0），动作u[k]是该步期望施加的位移。设备恰好延迟一步，所以实际位置满足：
x[k+1] - x[k] = u[k-1]，初始历史动作 u[-1] = 0。
这里的"一步延迟"是作者明确设定的规则，不是从 Diffusion Policy 日志估计出来的。给定四条动作 +1、+1、-1、-1，脚本得到：
| 画面区间（毫秒） | 按区间起点配到的当前动作 | 在本构造规则下生效的前一动作 | 位置变化 |
|---|---|---|---|
| 0→100 | +1 | 0 | 0 |
| 100→200 | +1 | +1 | +1 |
| 200→300 | -1 | +1 | +1 |
| 300→400 | -1 | -1 | -1 |
最有信息的一行是 200→300：输入标签是 -1，状态却增加 +1。按错的规则组织转移样本，就会把"负动作与正变化"放在一起。这个矛盾来自配对契约，不能直接归因于 模型 不懂物理。
但第三行之外还有同样重要的提醒：100→200 和 300→400 看起来是对的，因为相邻动作相同。只抽查长时间保持动作的片段，固定的一拍错位也可能隐藏起来。更有诊断价值的是方向切换、启动和停止附近的片段：没有前序动作怎样初始化、停止后是否保持旧控制，也应保留为实际审计问题。
把本表标签后移一拍可以恢复作者设定的关系；它不构成真实数据一律 shift(1) 的修复方案。真实系统可能有可变延迟、不同频率、丢帧和重规划，动作本身也可能是目标位姿而非位移。该计算没有训练损失、成功率或轨迹质量结果。5
动作切换提供更强的诊断线索
这种线索还不是延迟测量。真实系统出现负标签与正位移，可能来自惯性、坐标系、目标跟踪或多个命令，不必只有错一拍。本文构造系统排除了这些因素，才可明确归因于设定的一步延迟。分析真实记录时要逐项列竞争解释，不能拿示例表强制套在机械臂上。
实际动作采样和图像频率不同，一帧区间可能覆盖多条控制命令。简单挑一条最近动作，已经把区间压成点。对于状态转移数据，可明确如何表示区间内的命令与保持；若选的是未来目标动作作为模仿监督，则解释预测范围即可。两者关注不同对象，不能统一说越近越对。
把标签整体移动一拍，会让构造表符合已知规则，但真实可变延迟可能让某些片段改善、另一些退化。修改前保留原配对、索引和假设版本，修改后在独立片段检查，不覆盖原始日志。没有真实标定时，候选配对方案应写待验证，不能输出"对齐已修好"的结论。
画面这一侧，也不是随便找最近点
固定实现的相机采集代码同时记录 camera_capture_timestamp 和 camera_receive_timestamp；写入对外使用的 timestamp 时，取的是主机的 receive_time。保留采集字段并不意味着后续对齐默认用它，更不意味着设备时间与主机时间天然可比。6
get_obs 为相机生成对齐时刻后，并没有调用"绝对距离最近"的匹配。它优先选择严格早于目标时刻的最后一个候选；若不存在，则回退到第一个候选。这是明确的采样规则，连"等于目标时刻"也与严格早于不同。7
此处应分开看两个问题：采样规则决定哪帧进入一个输入位置；控制日志决定某个动作时间字段表示什么。二者共同影响数据契约，却都不能单独回答哪个动作造成了后继画面的变化。若接收延迟变化、动作持续保持，或者一段时间里控制命令多次更新，一帧间隔里就可能没有唯一的一条"对应动作"。
把采样边界显式保存
没有早于目标的候选时回退第一个，值得在审计输出里单独标记。回退不等于证明那帧是正确的因果前件，只说明代码在边界上选了一个可用候选。若样本位于记录开始处，是否保留、标记或排除，要根据训练任务决定并说明，不能悄悄把它当普通采样。
多个网格位置可能选到同一原帧，图像看起来重复不一定来自静止场景，也可能是可用帧和采样规则共同产生。丢帧或频率不同时，序列的有效信息密度会变化。实际应列帧索引与采样间隔，保留重复及缺失信息；本文没有据此估计真实相机帧率或丢帧比例。
主机receive_time包括主机看到数据的时点，不能直接替代设备曝光时点。捕获时间另存有助于分析，但设备钟若无可靠映射，不能将两列差直接称为相机延迟。首先确认时间定义和跨钟关系，必要时保留不确定区间，避免精确的小数位制造已测准确的错觉。
观察窗口还涉及模型决策时可见范围。若用离目标最近的后继帧作输入，可能把之后才产生的画面放入当时决策。未来图像用作预测目标可以合法，用作当前观察则要核对任务定义。输入与监督分开检查，比只看整张对齐表更能发现未来信息混入。
可运行：计算端点、错拍转移与采样索引
下面的单文件依次计算限速端点、一步延迟转移和严格早于/回退采样，全部采用作者设定的整数数据与synthetic_host时钟，不是机器人或相机日志。全部输入在内存中：三条原帧时间为 100、190、210 毫秒，四个目标网格位置为 90、100、150、210 毫秒。它们共享作者设定的 synthetic_host 时钟，不是相机采集记录。
单文件仅需 Python 标准库，保存为 alignment-toy.py 后可用 python3 alignment-toy.py。在本仓库根目录，实际运行附件的命令如下：
bash
python3 08-publishing-pipeline/generated-packages/PKG-20261005-0004-action-alignment/examples/alignment-toy.py完整代码：
python
"""Constructed arithmetic only: no robot, controller import, GPU or model calls."""
import json
requested_ms=100
end_ms=0
distance_mm=100
max_speed_mm_s=500
minimum_ms=distance_mm*1000//max_speed_mm_s
endpoint_ms=end_ms+max(requested_ms-end_ms,minimum_ms)
u=[1,1,-1,-1]
x=0
rows=[]
for k,a in enumerate(u):
active=0 if k==0 else u[k-1]
before=x
x+=active
rows.append(dict(interval_ms=[k*100,(k+1)*100],current_label=a,applied_previous_action=active,position_before=before,position_after=x,delta=x-before))
assert endpoint_ms==200
assert [r['delta'] for r in rows]==[0,1,1,-1]
print(json.dumps(dict(scope='constructed_integer_arithmetic_not_robot_or_model_experiment',shared_ideal_clock_assumed=True,one_step_delay_assumed=True,endpoint=dict(requested_ms=requested_ms,requested_duration_ms=100,distance_mm=distance_mm,max_speed_mm_s=max_speed_mm_s,minimum_ms=minimum_ms,reference_endpoint_ms=endpoint_ms,measured_robot_arrival_ms=None),rows=rows),ensure_ascii=False,indent=2))
# Author's finite index calculation, not RealEnv or numpy execution.
frame_ms = [100, 190, 210]
target_ms = [90, 100, 150, 210]
sampling = []
for target in target_ms:
before = [i for i, t in enumerate(frame_ms) if t < target]
selected = before[-1] if before else 0
nearest = min(range(len(frame_ms)), key=lambda i: abs(frame_ms[i] - target))
sampling.append(dict(target_ms=target, strict_before_index=selected,
selected_raw_ms=frame_ms[selected], fallback=not before,
equal_time_indices=[i for i, t in enumerate(frame_ms) if t == target],
nearest_index=nearest, nearest_raw_ms=frame_ms[nearest]))
assert [r['strict_before_index'] for r in sampling] == [0, 0, 0, 1]
assert [r['nearest_index'] for r in sampling] == [0, 0, 1, 2]
assert [r['fallback'] for r in sampling] == [True, True, False, False]
# Equal timestamps fail <; fallback can nevertheless return the first equal frame.
assert sampling[1]['fallback'] and sampling[1]['selected_raw_ms'] == 100
assert sampling[3]['equal_time_indices'] == [2] and sampling[3]['strict_before_index'] == 1
mismatch = [k for k, r in enumerate(rows) if r['current_label'] != r['delta']]
assert mismatch == [0, 2]
assert [k for k, r in enumerate(rows) if r['current_label'] == r['delta']] == [1, 3]
# Only same declared clock AND unit qualify in this fixture; no offset inferred.
def comparable(frame_clock, frame_unit, grid_clock, grid_unit):
return frame_clock == grid_clock and frame_unit == grid_unit
assert comparable('synthetic_host', 'ms', 'synthetic_host', 'ms')
assert not comparable('synthetic_device', 'ms', 'synthetic_host', 'ms')
assert not comparable('synthetic_host', 's', 'synthetic_host', 'ms')
print(json.dumps(dict(scope='finite arithmetic and index fixture; no robot/camera/model/training',
frame_raw_ms=frame_ms, sampling=sampling, current_label_mismatch_indices=mismatch,
held_action_match_indices=[1, 3], time_contract=dict(clock='synthetic_host', unit='ms',
device_to_host_mapping='UNKNOWN', measured_arrival_ms=None, measured_latency_ms=None),
self_check_groups=6), ensure_ascii=False, indent=2))本机 Python 3.11.6 实际运行退出码 0，stderr 为空。stdout 完整原文如下；第一个 JSON 与原构造计算结果逐字节相同：
text
{
"scope": "constructed_integer_arithmetic_not_robot_or_model_experiment",
"shared_ideal_clock_assumed": true,
"one_step_delay_assumed": true,
"endpoint": {
"requested_ms": 100,
"requested_duration_ms": 100,
"distance_mm": 100,
"max_speed_mm_s": 500,
"minimum_ms": 200,
"reference_endpoint_ms": 200,
"measured_robot_arrival_ms": null
},
"rows": [
{
"interval_ms": [
0,
100
],
"current_label": 1,
"applied_previous_action": 0,
"position_before": 0,
"position_after": 0,
"delta": 0
},
{
"interval_ms": [
100,
200
],
"current_label": 1,
"applied_previous_action": 1,
"position_before": 0,
"position_after": 1,
"delta": 1
},
{
"interval_ms": [
200,
300
],
"current_label": -1,
"applied_previous_action": 1,
"position_before": 1,
"position_after": 2,
"delta": 1
},
{
"interval_ms": [
300,
400
],
"current_label": -1,
"applied_previous_action": -1,
"position_before": 2,
"position_after": 1,
"delta": -1
}
]
}
{
"scope": "finite arithmetic and index fixture; no robot/camera/model/training",
"frame_raw_ms": [
100,
190,
210
],
"sampling": [
{
"target_ms": 90,
"strict_before_index": 0,
"selected_raw_ms": 100,
"fallback": true,
"equal_time_indices": [],
"nearest_index": 0,
"nearest_raw_ms": 100
},
{
"target_ms": 100,
"strict_before_index": 0,
"selected_raw_ms": 100,
"fallback": true,
"equal_time_indices": [
0
],
"nearest_index": 0,
"nearest_raw_ms": 100
},
{
"target_ms": 150,
"strict_before_index": 0,
"selected_raw_ms": 100,
"fallback": false,
"equal_time_indices": [],
"nearest_index": 1,
"nearest_raw_ms": 190
},
{
"target_ms": 210,
"strict_before_index": 1,
"selected_raw_ms": 190,
"fallback": false,
"equal_time_indices": [
2
],
"nearest_index": 2,
"nearest_raw_ms": 210
}
],
"current_label_mismatch_indices": [
0,
2
],
"held_action_match_indices": [
1,
3
],
"time_contract": {
"clock": "synthetic_host",
"unit": "ms",
"device_to_host_mapping": "UNKNOWN",
"measured_arrival_ms": null,
"measured_latency_ms": null
},
"self_check_groups": 6
}看第二个 JSON 时，先读原时间和索引，再读目标位置。150 毫秒目标的严格早于规则选 index 0、原时间 100；绝对最近会选 index 1、原时间 190。后一帧更近，却发生在目标之后。210 毫秒目标则选 index 1，不选恰好等时的 index 2；如果把 < 改成 <=，这一行就会变化。代码没有调用 RealEnv 或 numpy，作者只把固定源码中这条有限索引规则写成标准库枚举，不能据此证明真实图像路径或性能一致。
90 和 100 毫秒两行是另一种情况：没有严格更早候选，都回退 index 0。90 的回退帧在目标之后；100 的回退帧恰好等时。等时被 < 排除，不等于最终输出永远不可能等时；首条回退可以再次返回它。fallback 标记因此不能省略，也不能从"选到一个索引"推出该观察在决策时可用。多个网格位置重复 index 0，还说明网格长度不等于独立帧数量，并未测任何丢帧率。
代码另外检查长保持片段在 index 1、3 看似匹配，但 index 0、2 会暴露设定的一拍错位；这只验证既定规则的算术，不估计真实延迟。原公式使用整数除法，100000 在此能被 500 整除；不能把向下取整的写法推广为任意位移的安全最短时长。参考端点 200 毫秒与 measured_arrival_ms=null 同时保留，没有拿计算结果补到达反馈。
comparable 也只是本例的准入约束：声明的时钟或单位不同，就不直接比较。声明一致仍不是硬件同步证明；设备到主机映射保持 UNKNOWN，实测延迟保持 null。实际需要怎样换算单位、估计偏移或漂移，要有额外标定记录。不要把本例的 synthetic_host 名称或理想时钟当成现场事实。这个附件适合先检查样本选了哪个原索引，不负责给真实数据盖"因果已对齐"的章。
修改配对前，先留下能反驳它的记录
面对一份现有数据，我会先挑一段动作发生明显切换的短片段，追踪动作从调用参数到调度队列、控制命令和反馈记录的路径。原始列名保留，同时写明时间单位、时钟来源及事件语义；对于没有测量的生效时间，直接记为未知，不用计划时间补齐。
接着把同一片段的原始时间与采样网格时间并排输出，标出每个样本实际选择的帧、动作索引和边界回退。这样才能看清，错位来自记录时间、重采样选择，还是训练样本把动作放在了另一侧。若不同设备时钟没有可靠映射，先保留偏移和漂移的不确定性，不能只把单位统一成毫秒就做因果判断。
最后，根据任务定义决定标签。预测状态转移时，需要说明动作覆盖的是哪个区间，以及是否含控制保持或多条命令；模仿学习时，未来目标动作可以是有意设计的监督目标，不能因为它时间晚于观察就判为错误。两者都必须明确模型在决策时可见什么，避免把未来观测误接入输入。
对真实延迟的修正还需要额外的标定或日志证据。在此之前，最稳妥的产物不是一份声称"已对齐"的 CSV，而是一段能逐行追溯的样本：为什么选这帧、为何配这条动作、时间表示哪件事、还有哪项尚未测量。最近的数字，只能证明数字接近。
一段可逐行追溯的审计样本
审计样本可以保留原动作、被接受动作、原帧索引、原始时间、网格时间和回退标记，并关联控制及反馈来源。字段多少由实际记录决定，缺哪层就写缺哪层。重点不是造一个完整表，而是每项结论能回到原始对象与对应代码路径。
先选择切换短片段，再包含一个平稳片段作为对照。切换帮助识别错位，平稳片段解释为什么旧抽样可能没发现问题。两段都保留采样规则和时钟映射条件，不能只展示最能说明新方案正确的一小段。本文提供的是选择逻辑，没有声称已经从真实日志挑出样本。
修改标签契约时，也要检查训练输入生成位置。观察窗口是否使用决策时可得帧，动作目标是否有意来自未来，状态转移区间是否含保持，多处规则应共同解释。若只能确认采样代码而缺控制反馈，结论就停在采样语义已核对，不推到因果配对已验证。
最后留一个能推翻方案的问题：在未参与选择的切换片段，按新规则配对是否仍与可观察反馈相容；如果延迟变动，方案怎样标识未知。答案需要真实测量或日志，不能从CSV排得整齐获得。原数据保留、新规则有版本、未知边界明确，才能让后续标定继续接上。
来源与复算
2026-10-13 重新取得官方固定提交的五个完整源码文件，原字节摘要与原核查一致；本次取得的默认分支对应五文件也相同。这只说明这些文件的这次快照，不代表整个项目或以后默认分支保持不变，本文所有行号仍绑定 5ba07ac6661db573af695b419a7947ecb704690f。原两项算术与新增索引自检实际运行，没有机器人、相机、模型、训练或延迟测量。未来训练效果须另行验证，不从本文配对假设推断。
-
Diffusion Policy RealEnv，固定提交，L324--342，2026-10-05 原核对，2026-10-13 同固定源码复核。 ↩︎
-
动作累积器 L179--202。注释与具体调用参数分别核对，不把网格时间当执行回执。 ↩︎
-
上文已提供可直接保存运行的完整扩展代码和对应输出。2026-10-05 的原探针 alignment-toy.py 与结果 alignment-toy-result.json、2026-10-13 的扩展版本继续保留在作者研究归档，原字节与原结果前缀保持；本文不提供单独附件下载。均为纯 Python 构造计算，不是机器人或模型实测。 ↩︎