一、重建没有报错，模型却沿着墙面“重影”
PoseSyncLab 最初只是一个很小的采集验证页：Camera Kit 连续写入图像帧，SensorService 订阅陀螺仪和加速度计，再把离图像时间最近的一组姿态送进 3DGS 前处理。单看日志，286 帧都写成功；真正把lobby_arc_03放进重建链路，玻璃门边缘却出现两层轮廓。最麻烦的是，这个问题不会抛异常，换一条慢一点的采集轨迹又可能消失。
我最后没有继续调重建参数，而是把“每一帧究竟配到了哪两条传感器样本”做成账本。第 184 帧的图像时间是4821039442000 ns，包围它的姿态样本分别在-4.2 ms和+3.6 ms，可接受；另有 4 帧的最近样本间隔超过12 ms，以前仍被强行写入。换句话说，采集成功只是文件层面的成功，时序上并不一定是有效输入。
这次 Demo 的任务号定为POSE-1507，页面是FramePosePage。我想验证的不是“传感器能否读取”，而是三个更工程化的问题：相机帧和传感器回调的到达时间不能混用；姿态必须由包围帧时间的样本插值；时间线跳变时宁可拒绝帧，也不能把错误姿态悄悄交给重建模块。
二、先分清采样时间和回调到达时间
最早的代码拿Date.now()给相机帧和传感器回调盖章。它适合记录业务事件，却不适合做毫秒级配对：回调排队、线程切换、日志输出都可能改变“代码执行到这里”的时刻。当前实现把设备给出的单调时间戳作为采样时间，另记receivedNs观察投递延迟；两者绝不参与同一比较。
为了解决时间线基准漂移和突发跳变，我在会话开始阶段维护一个小窗口，只估计“相机时间线相对姿态时间线”的偏移中位数。下面这段代码真正参与 Demo，它不追求每帧修正，而是用稳定样本更新偏移，异常值只进入诊断计数。
typeStampPair={cameraNs:number;sensorNs:number};classTimelineCalibrator{privateoffsets:number[]=[];privateoffsetNs:number=0;privatereadonlymaxSamples=31;privatereadonlyjumpNs=8_000_000;calibrateOffset(pair:StampPair):boolean{constcandidate=pair.cameraNs-pair.sensorNs;if(this.offsets.length>7&&Math.abs(candidate-this.offsetNs)>this.jumpNs){returnfalse;}this.offsets.push(candidate);if(this.offsets.length>this.maxSamples)this.offsets.shift();constsorted=[...this.offsets].sort((a,b)=>a-b);this.offsetNs=sorted[Math.floor(sorted.length/2)];returntrue;}toSensorTime(cameraNs:number):number{returncameraNs-this.offsetNs;}}这里用中位数而不是平均数，是因为一次调度抖动不该拖动整个时间线。jumpNs设为 8 ms 也不是通用常数，它来自本机 20 轮走查；量产项目要按机型、采样率和相机模式建立基线。校准器属于一次采集会话，重新创建会话就重新估计，不能跨相机重配复用旧偏移。页面离开时清空窗口，否则第二次进入会把上一段轨迹的状态带进来。
三、最近样本不等于正确姿态
只找最近样本会产生一个不易察觉的方向偏差：相机运动较快时，最近样本可能始终落在图像帧之前。当前做法是保留一个按时间排序的环形缓冲，找到目标时刻左右两侧的姿态，再做线性位置插值和四元数球面插值。Demo 没有把陀螺仪积分写进 UI 层，UI 只消费已经归一化的PoseSample。
下面的interpolatePose解决“有样本却不可用”的边界。它同时检查包围关系、两样本间隔和四元数长度，任何一项失败都返回空值，让上层明确进入拒绝分支。
typeVec3=[number,number,number];typeQuat=[number,number,number,number];typePoseSample={tNs:number;p:Vec3;q:Quat};functioninterpolatePose(left:PoseSample,right:PoseSample,targetNs:number,maxGapNs:number=12_000_000):PoseSample|undefined{constgap=right.tNs-left.tNs;if(gap<=0||gap>maxGapNs)returnundefined;if(targetNs<left.tNs||targetNs>right.tNs)returnundefined;constratio=(targetNs-left.tNs)/gap;constp:Vec3=[left.p[0]+(right.p[0]-left.p[0])*ratio,left.p[1]+(right.p[1]-left.p[1])*ratio,left.p[2]+(right.p[2]-left.p[2])*ratio];constq=QuaternionMath.slerp(left.q,right.q,ratio);if(Math.abs(QuaternionMath.length(q)-1)>0.002)returnundefined;return{tNs:targetNs,p,q:QuaternionMath.normalize(q)};}这段代码的关键不是插值公式，而是把失败变成可观测状态。第 184 帧的两侧间隔为7.8 ms，插值比例约 0.538，最终进入POSE_LOCKED；4 个超过 12 ms 的帧进入FRAME_REJECTED。传感器样本缓冲只保留最近 500 ms，提交后的旧样本会被裁掉，避免长时间采集导致数组无限增长。若姿态来源还包含磁力计或视觉里程计，不能直接往这个函数里塞字段，需要在融合层先统一坐标系和置信度。
四、提交要带代次，不能让旧会话补写新轨迹
第二个坑来自生命周期。测试时快速点了“停止”再“开始”，旧相机回调晚到 22 ms，虽然 PixelMap 已属于上一会话，提交函数却读到了新的任务号。文件最终没损坏，但清单中出现了时间逆序。解决办法是让每次采集拥有不可变generation，帧、姿态、写盘任务都携带它。
下面的提交代码解决旧会话补写和半清单暴露问题。写盘完成并不立即修改正式清单，而是先写.part，验收代次和单调时间后再原子晋级。
classFrameBundleCommitter{privateactiveGeneration=0;privatelastFrameNs=0;privateclosed=false;begin():number{this.closed=false;this.lastFrameNs=0;return++this.activeGeneration;}asynccommitFrameBundle(frame:CameraFrame,pose:PoseSample,generation:number):Promise<'ACCEPTED'|'STALE'|'REJECTED'>{if(this.closed||generation!==this.activeGeneration)return'STALE';if(frame.timestampNs<=this.lastFrameNs)return'REJECTED';constpart=`${frame.id}.bundle.part`;awaitBundleWriter.write(part,{frame,pose,taskId:'POSE-1507'});if(this.closed||generation!==this.activeGeneration){awaitFileGuard.remove(part);return'STALE';}awaitBundleWriter.promote(part,`${frame.id}.bundle`);this.lastFrameNs=frame.timestampNs;return'ACCEPTED';}close():void{this.closed=true;this.activeGeneration++;}}close()先关闭提交资格，再提升代次，随后由页面停止 Camera Kit 输出、注销 SensorService 监听，最后等待正在写入的 Promise 收口。顺序不能反过来：先释放帧资源再关资格，晚到任务仍可能访问已释放对象；只提升代次却不删除.part，磁盘会逐次积累半成品。重复调用close()是允许的，但真正的相机、传感器注销需要单独记录句柄，保证成对执行。
五、调试页只展示能解释重建质量的数据
项目结构没有做成通用采集框架。FramePosePage.ets负责按钮和状态；TimelineCalibrator.ets管偏移；PoseRingBuffer.ets管包围样本；FrameBundleCommitter.ets管最终提交。HiLog 统一使用PoseSync域，关键日志只有五类：OFFSET_LOCKED、POSE_BRACKET、FRAME_ACCEPTED、FRAME_REJECTED、SESSION_CLOSED。
在 DevEco Studio 中注入一次 14 ms 的姿态空洞后，日志会明确显示frame=290 gap=14.3ms action=REJECT，而不是继续打印“采集成功”。右侧模拟器的当前快照仍是任务POSE-1507：偏移+1.8 ms、包围-4.2/+3.6 ms、插值间隔7.8 ms、已接收 286、已拒绝 4、状态POSE_LOCKED。
“注入时间跳变”只在调试构建出现，它让下一条传感器时间增加 10 ms，用来确认校准器不会更新基线；“导出配对清单”输出 CSV，记录 frameId、cameraNs、leftNs、rightNs、ratio、decision。清单不保存原始图像，方便问题复现时先看时序证据，又不会把采集素材复制一份。
六、最终结果和仍然保留的边界
在 42 秒弧线采集里，系统收到 290 个图像回调，286 个进入正式清单，4 个因姿态间隔超预算被拒绝。偏移估计稳定在+1.8 ms，第 184 帧的包围值与日志、页面、导出清单一致。手机页把这些状态集中到一屏，目的是让测试人员不接电脑也能判断当前输入是否适合继续重建。
我还做了三组反例。第一组把传感器频率降到正常值的一半，拒绝数很快上升，但偏移没有被错误拉动；第二组让应用切到后台 3 秒再回来，旧 generation 的 6 个回调全部记为STALE，正式清单没有追加；第三组连续执行两次“注入时间跳变”，校准器维持原有中位数并把会话标成OFFSET_SUSPECTED，只有重新开始采集才解除。三组测试分别验证采样密度、生命周期和时钟异常，避免只用一条顺利轨迹证明自己。
这套实现没有声称用手机 IMU 就能替代完整的视觉惯性里程计。它只解决采集端最容易被忽略的一层：确保交给后续算法的帧与姿态在时间上可解释。设备休眠、相机模式切换、传感器精度变化都会让原有校准失效，必须重新开始会话；长时间后台运行也不在 Demo 边界内。
实际产品还要注意坐标系。屏幕旋转、相机传感器方向和重建世界坐标不是一回事，本篇默认融合层已经输出右手系姿态，配对层绝不自行交换轴或猜测方向。如果设备配置变化触发相机重建，除了刷新时间校准，也要刷新相机内参与坐标变换矩阵。把时间误差和坐标误差混在一个“姿态不准”里排查，往往会在两个模块之间来回试参数。
我最后保留了一个很朴素的验收条件：任何正式帧都能在清单中找到左右样本、插值比例和提交代次；任何不满足条件的帧都有明确拒绝原因。对 3DGS 来说，少四帧通常比多四帧错误姿态更安全。重建质量不再只靠“看起来有没有重影”，而是从采集入口就有一份能追溯的时间线证据。
这份证据也方便课程演示：学生不用先理解完整重建数学，只要沿着一帧的时间戳、左右样本、插值结果和提交决策走一遍，就能看懂异步系统为何需要明确的数据合同。
