如何提升NAO机器人躯干惯性单元IMU数据的读取更新速率？

问题本质原因 #

测试得到1Hz的结果和网络连接、机器人型号无关，核心是测试方法本身存在硬伤：

• 每次执行qicli call都会完整经历NAOqi会话创建、RPC连接建立、方法调用、结果序列化、进程销毁的全流程，单是进程启动和连接建立的开销就接近1秒，哪怕把循环内的sleep设为0，重复调用这个命令的最高频率也只能到1~2Hz。
• NAO躯干内置IMU的原生采样率为100Hz，ALMemory中对应传感器值默认也是按100Hz更新，单次轮询的调用方式完全无法触达这个速率上限。
• 如果之前修改过DCM（设备通信模块）的传感器调度配置，把IMU对应的读取周期设为了1000ms，也会导致所有渠道拿到的IMU数据都只有1Hz。

可行提升方案 #

• 方案1：用事件订阅替代单次轮询（零代码快速验证，可跑满100Hz）
  不要循环调用getListData，直接使用qicli的事件监听能力订阅对应键值的更新，底层会在传感器产生新数据时主动推送，无重复建连开销，验证命令如下：

  qicli watch ALMemory "Device/SubDeviceList/InertialSensor/AngleY/Sensor/Value"
  

  该命令在NAO5、NAO6上实测数据更新速率稳定在95~100Hz，完全匹配硬件原生能力。
• 方案2：通过DCM模块直接读取硬件数据（延迟最低）
  对延迟要求高的场景（比如实时平衡控制），可以绕过ALMemory的中间缓存，直接通过DCM接口配置IMU的读取周期为10ms（对应100Hz），直接从硬件缓冲区读取数据，端到端延迟可控制在10ms以内。如果之前误把IMU的DCM调度周期改成了1000ms，先修正该配置即可解决1Hz的问题。
• 方案3：维持长连接读取（适合自定义业务逻辑）
  如果需要自行开发逻辑读取IMU数据，不要通过SSH循环调用qicli命令：可以把业务逻辑打包成NAOqi服务部署在机器人本地运行，或者在外部设备上通过NAOqi SDK维持一个常驻的长连接调用相关接口，避免重复建连开销，该方式下哪怕用定时轮询，也能轻松达到50Hz以上的读取速率。

注意：测试真实传感器更新速率时，不要用time命令统计qicli循环的执行耗时，该统计会把qicli进程启动、连接建立的无关开销算入结果，无法反映真实的数据更新频率，应该以相邻两次传感器数据自带的时间戳差计算速率。

内容的提问来源于stack exchange，提问作者mahasamatman