移动设备 IMU 数据采集

手机和平板内置的 IMU 能以很低的部署成本补充“设备当时怎样转动、加速和晃动”。但它不是一条可以脱离采集条件直接训练的通用数值流：同一段动作在不同机型、装夹方向、采样策略和时间基准下，记录的含义可能不同。

对具身智能数据而言，移动端 IMU 的合理角色通常是：与相机、任务事件、机器人状态或人工演示一起记录，作为时间对齐、运动估计、动作切分、质量检查和下游特征的输入。本文聚焦怎样把它采成可复查、可对齐、可复用的数据，而不是把它当成孤立的姿态算法输入。

手机或平板上的原始 IMU 读数经过同一时间轴、会话记录和元数据封装，成为可与视频及任务事件对齐的数据包

IMU 实际记录什么

移动设备的惯性测量单元（IMU）通常至少组合了两类 MEMS 传感器：

加速度计：输出设备坐标系上的三轴比力，单位通常是 m/s^2。设备静止放在桌面上时，它仍会测到重力，因此不能把原始值直接理解成线性移动加速度。
陀螺仪：输出设备绕三轴的角速度，单位通常是 rad/s。它对快速转动很敏感，适合补足视频帧之间的运动。

部分系统还会提供磁力计、气压计、重力、线性加速度、旋转向量或姿态四元数。后几项往往是操作系统融合后的派生传感器，不是独立原始测量。对于要做跨设备复现、视觉惯性里程计或研究传感器误差的数据集，应优先保存未融合的加速度计和陀螺仪流，再把系统融合结果作为可选辅助产物。

单条原始记录至少应包含：

timestamp_ns, ax, ay, az, gx, gy, gz

其中 timestamp_ns 必须说明来自哪个时间基准；轴值还必须有单位、坐标系定义和传感器类型。不要只导出 CSV 数值而省略这些信息，否则之后无法判断重力方向、角速度正负或帧间对齐关系。

采集方式：优先原始流与统一时间轴

Android

Android 通过 SensorManager 订阅 TYPE_ACCELEROMETER 和 TYPE_GYROSCOPE。每个 SensorEvent 都有事件时间戳，采集时应保存这个时间戳，而不是 Java/Kotlin 回调抵达应用的时间。后者会受线程调度、GC 和写盘阻塞影响，不能稳定代表物理测量发生的时刻。

请求采样周期时，SENSOR_DELAY_GAME、SENSOR_DELAY_FASTEST 等只是请求，不是设备一定提供的实际频率。应从保存后的相邻时间戳计算实际间隔、分位数和缺口，记录设备是否发生了节流。若同一应用还采集 Camera2 或 CameraX 图像，需把相机帧的传感器时间戳和 IMU 事件时间戳保存在同一会话时间轴，再在离线阶段建立帧到 IMU 窗口的索引。

Android 也可能提供 TYPE_LINEAR_ACCELERATION、TYPE_GRAVITY 和 TYPE_ROTATION_VECTOR。它们适合原型可视化或低风险交互，但其融合实现和延迟可能随厂商、系统版本变化。数据集规范应把它们标成 derived，并记录具体传感器名称、厂商、版本、报告模式和请求频率。

iOS / iPadOS

iOS 和 iPadOS 通常经由 Core Motion 的 CMMotionManager 或 CMDeviceMotion 获取加速度、陀螺仪与融合后的 device motion。采集应用应记录每个样本对应的时间以及采集会话的单调时钟映射，不能把 UI 更新或文件写入时刻当作样本时刻。

设备运动接口还会提供参考坐标系与姿态。保存时必须写明所选参考系、设备方向和是否启用磁场校正；否则相同的 x/y/z 在横屏、竖屏或不同参考系中并不能直接比较。系统融合姿态适合实时反馈，但若要离线重跑融合或评估算法版本，仍应保留加速度计和陀螺仪原始流。

自建采集应用的最小设计

不要把 IMU 回调直接同步写入 CSV。较稳妥的应用结构是：采集线程仅追加到有界内存队列，写盘线程批量落盘，监控线程记录队列长度、写入耗时、丢样和热状态。会话开始、暂停、恢复、相机启停、任务开始/结束应写成显式事件，而不是靠文件修改时间推断。

建议一个采集会话目录包含：

session/
  imu_raw.csv                 # t_ns, ax, ay, az, gx, gy, gz
  frames.csv                  # frame_id, t_ns, image_path
  events.jsonl                # start/pause/resume/task/end
  device.json                 # 型号、OS、传感器、安装与坐标约定
  manifest.json               # 文件校验和、格式版本、质量结论

图像链路的元数据和资源管理细节可参考 YUV 算法与 Android 使用；若 IMU 要与相机共同估计轨迹，可再参考视觉惯性 SLAM 数据整理。

采集前必须固定的约定

1. 坐标系与设备安装

手机 API 输出的是设备坐标系，不是相机坐标系、手持夹爪坐标系或机器人基座坐标系。需在 device.json 写清楚：三轴正方向、屏幕朝向、采集时设备如何安装、IMU 到相机或末端执行器的外参，以及坐标变换的记法。

例如手机被夹在夹爪上后若旋转了 90 度，陀螺仪的 z 轴不再天然代表“夹爪朝向变化”。只保存手机的纵横屏状态不够；安装支架、重新插拔和镜头朝向变化都可能改变外参。每次改装都应生成新的硬件配置 ID，并重新做相机-IMU 外参检查。

相机、IMU 和机器人末端或世界坐标之间的空间关系必须用标定和明确的坐标约定保存

2. 时间基准与同步

一段视觉惯性数据不应该依赖“第 N 帧对应第 N 条读数”。正确方式是按单调时间戳建立关联：对每个图像帧取相邻两帧之间的 IMU 序列，或按目标时刻插值、积分、重采样。

移动设备内同一采集进程的相机与 IMU 通常可以共享或转换到稳定的单调时间基准，但跨设备时不能假定它们天然同步。手机与机器人控制器、外置相机或动作捕捉系统共同采集时，至少需要一种可验证的同步证据：共享触发、网络时钟与偏差记录，或在视频和 IMU 中都可观测的敲击/快速转动事件。应保存估计出的时钟偏移、使用的方法和残差，而不是只保存一个“已同步”布尔值。

快速转动是很实用的验收动作：视频中画面角速度变大时，陀螺仪模长也应在附近时刻出现峰值。若两者稳定错开几十毫秒，视觉惯性处理与动作标签都会产生系统性误差。

3. 频率、量程与延迟

先根据下游用途选目标，而不是盲目追求最高频率。视频辅助的动作分析常见做法是记录高于视频帧率的 IMU，然后在离线阶段按时间窗口使用；极快速的手持操作、碰撞或工具接触需要更密的采样和更高量程。过高频率会增加功耗、写盘压力与热节流风险，也可能在某些设备上只得到重复或不稳定间隔的读数。

在预采集阶段分别做静止、缓慢转动、快速转动和预期最大冲击的短测试，检查：

相邻时间戳的实际间隔，而非请求频率。
加速度与角速度是否接近量程上限或出现截平。
持续录制后的频率、温度、电量和丢样是否变化。
相机、IMU、编码和写盘并行运行时是否改变样本间隔。

移动设备采集的主要风险

传感器偏置、噪声与漂移

IMU 的零点并不恒定。陀螺仪静止时仍可能有小角速度，加速度计也有轴向偏差和尺度误差；温度、设备老化与启动状态都可能改变它们。短时积分还能工作，时间越长误差越会积累。因此，采集协议中应安排每个 session 开头和结尾各一段静止数据，用来估计偏置、检查噪声并发现设备异常。

不要为了让曲线“好看”而直接把所有静止均值减掉并覆盖原始文件。原始流必须不可变；偏置估计、滤波和重采样应作为版本化派生文件保存，并说明算法和参数。需要比较不同设备的噪声特性时，可以进一步做 Allan 方差分析，见术语表。

机型和系统差异

同样叫“加速度计”或“陀螺仪”的硬件，在量程、噪声、最高输出速率、内部滤波和时延上都可能不同。Android 设备还可能有多个同类传感器，或把硬件传感器与软件融合传感器混在 API 列表中。数据集应记录传感器 name、vendor、version、最大量程、分辨率、最小延迟、实际请求与实际观测频率，以及 app/OS 版本。

跨机型训练时，建议按设备或至少按硬件配置划分训练、验证和测试集。否则模型可能记住某款手机的噪声纹理，离开该机型后失效。若目标就是跨设备泛化，应该把设备变化作为明确的评估维度，而非随机混入同一条轨迹的相邻样本。

屏幕旋转、系统融合与权限

屏幕自动旋转改变的是 UI，不一定改变传感器原始轴；开发者若在显示层又旋转一次，很容易导致记录与预览坐标不一致。传感器读取、相机图像、保存文件和标注界面应各自记录方向，但坐标变换只在一个可审计的位置执行。

此外，后台限制、省电策略、来电、相机占用、权限收回和应用生命周期事件都可能中断或降频。采集应用要把这些事件写入日志，并在恢复后标出数据缺口；不要把恢复后的数据与前一段无缝拼接成连续轨迹。

隐私、安全与现场可用性

移动设备采集往往同时记录视频、位置线索、语音或操作者动作。采集前应明确被拍摄者同意、场景授权、数据保留期限和脱敏策略。具身操作数据还应评估设备掉落、碰撞、过热和电量耗尽风险。对长 session，电源、散热、存储空间和安装牢固性是数据质量条件，不是事后运维细节。

质量控制与验收

移动 IMU 原始流需要检查时间完整性、静止偏置、动态范围、跨模态对齐和元数据，之后再决定通过、复采、降级或剔除

建议把质检分成自动检查和人工复核两层。自动检查适合发现结构性问题：

检查项	建议判据	对下游数据的影响
时间戳	单调递增，统计间隔与大缺口	缺口会破坏积分、帧间窗口和动作对齐
轴值与单位	六轴齐全，单位与量纲在合理范围	单位或轴错误会让训练特征与标定失真
静止片段	陀螺仪均值和方差可解释，重力模长稳定	用于偏置估计和设备健康检查
动态范围	无持续截平、无大量异常尖峰	饱和会丢掉高速动作与接触信息
视频对应性	转动/振动事件与画面变化时间一致	时间偏移会误导 VIO、标注和策略学习
元数据	设备、传感器、安装、时钟和版本完整	缺元数据的数据难以复现或安全合并

人工复核则应抽看原始视频与 IMU 曲线：开始拿起设备、快速扫视、放下设备等事件是否可对应；异常峰值是否来自真实接触；同一任务中的方向变化是否符合安装约定。质量结论应写到 manifest 中，并允许 pass、recollect、usable_with_warning、reject 等状态，而非只保留成功数据。

面向训练、标注与评估的交付

原始 IMU 不应被强行压成“每帧一个六维向量”。更稳妥的训练样本可以保留图像时刻附近固定长度的 IMU 窗口，并明确窗口端点、重采样方法、是否去偏、是否转到相机/世界坐标系。不同任务可能需要不同表示：视觉惯性定位要用高频原始序列；动作分段可能只用模长、频域统计或短时积分；策略学习则要与观测和动作延迟共同建模。

标注工具至少应能显示图像帧、IMU 曲线、任务事件和质量标记在同一时间轴上。评估时除了任务成功率，也应按机型、温度/时长、运动速度、安装配置和同步误差分桶报告；这能区分“模型不懂任务”与“数据采集条件改变”。

交付给数据使用者时，建议同时给出：不可变原始流、派生特征或重采样流、完整 schema、单位/坐标系/时间基准说明、传感器与安装元数据、同步报告、质检结果及处理代码版本。这样数据集才能支持重处理、故障追溯和跨设备比较。