Cache中文一般叫“缓存”。

Axis内部posture_index跨度：约96 Hz↓MocapApi实际Avatar事件：约63 Hz↓MotionInput收到：全部记录↓GMR处理：与收到数量相等↓ZMQ发送：与生成数量相等↓MuJoCo接收：与ZMQ发送数量相等↓MuJoCo应用：与接收数量相等Axis内部姿态索引↓普通BVH/MocapApi Avatar事件进入我们程序之后，数量都能对上。GMRprotobufZ

如果现在就补帧，虽然机器人接收数量连续，但会掩盖采集端真实缺失，导致无法判断MocapApi调用是否已经解决。等到GMR线程读取时，SDK内部缓存可能已经更新成下一帧，最终表现就会类似“只读到最新帧”。每取到一个Avatar事件，就立即把对应姿态深拷贝完成，然后再取下一个事件。即使Avatar事件已经收到，SDK内部姿态也可能在读取几十个关节期间更新。即使GMR短时间变慢，已经采集的帧仍保存在FI

MocapApi 函数问题核心通常就是：其中最需要警惕的是：事件本身和 Avatar 当前缓存姿态是否一一对应。当前程序大致执行：相关代码：[noitom_client.cpp](C:\\Users\\RX01296\\Desktop\\全身控制8_3\\gmr-master_PN_xsenscpp最终版\\gmr-master_PN\\cpp_noitom_g1\\src\\noitom_cli

我检查了现有代码，确认采集和GMR已经分线程，中间FIFO保存的是独立的NoitomFrame，所以数据只要被程序取出来，后面不会再被覆盖。因此准备把固定休眠改成线程让出，并在SDK内部连续排空非Avatar事件，同时增加poll次数、Avatar事件数、空轮询、MoreEvent、重复索引和最大轮询间隔等统计。今天还检查到8_3中的旧CMake缓存仍带有7_28绝对路径，因此后续必须在8_3重新

这不是ZMQ丢帧，因为它发生在ZMQ发送之前。

ONNX 本质上是一个已经训练好的神经网络模型文件，它主要负责机器人控制策略推理，ONNX 在这里通常是一个模型文件，不是主程序。.onnx所以它类似于“游戏程序读取存档/资源文件”：ONNX 文件保存训练成果，但负责通信、循环控制、动捕接收和机器人命令发送的仍然是.exe主程序。ONNX.onnx.exeInputFps可以把 GMR 理解为“人体动作翻译器”，把 ONNX 理解为“机器人学会如

整个改造的核心不是：把gRPC库换成ZMQ库。而是：先明确真实动捕数据入口，用统一输入接口隔离设备差异，恢复完整在线GMR IK，再根据“不能丢任何已收到的数据”的要求采用阻塞FIFO和有序ZMQ传输，最后通过分层计数、frame_id、CRC和MuJoCo审计，证明每一帧到底在哪一层产生、处理、发送、接收和应用。来源统一→ 算法隔离→ 协议稳定→ 有序传输→ 线程解耦→ 队列排空→ 分层计数→

MocapApi可以理解为：诺亦腾官方提供的一套C/C++软件接口，让我们自己的程序能够从Axis Studio中读取已经解算好的人体动作数据。它不是动捕服，不是网络协议，也不是GMR。

可以把GMR只需要知道：你给我一个格式正确的，我就把它转换成G1动作。不是亲自转换，而是的两个具体实现分别负责转换，然后统一返回。