简介：面向同步定位与建图（SLAM）及运动恢复结构（SfM）研究者的安卓数据采集工具，可一体化捕获视频、惯性测量单元数据和相机参数，帮助解决三维重建中的数据来源问题。该应用以约三十赫兹录制H.264/MP4视频，以约一百赫兹采集IMU数据，并同步到同一时钟，帧元数据与IMU信息共同存储于protobuf3格式文件，便于后续离线处理。工具特别关注现代智能手机普遍配备的光学防抖（OIS）功能，因为OIS使得每帧相机参数不同，且多数设备无法关闭或提供镜头移动数据；应用会给出明确警告，并尽可能输出OIS信息，也讨论了与数字视频稳定（DVS）的差异，对使用摄像头API（Camera2 API）做图像稳定的开发者很有参考价值。压缩包共一百二十一个文件，以Java源码、XML界面配置、Python脚本、Gradle构建描述和Docker运行环境为主，整体大小三点三七兆字节，结构紧凑，适合学习与二次开发。目前已有六百一十五人学习下载，适合需要快速搭建数据采集流程的研究生、算法工程师和移动视觉爱好者。 讲到视觉SLAM和三维结构恢复，很多人第一反应是算法怎么调、回环检测怎么设计，但真正上手跑实验的人都知道，数据采集的质量才是决定整套pipeline上限的环节。我最初做视觉惯性建图时，随便拿手机的系统相机录视频，再用第三方App记录IMU，结果跑标定的时候重投影误差大得离谱，排查了整整两天，最后发现视频开了电子防抖，画面每帧都在被裁切和位移。后来换了VideoIMUCapture-Android这类专门面向Motion研究的采集工具，把视频、IMU数据、相机参数以及OIS相关信息统一在同一个时间基准下录下来，实验的可复现性和数据质量才算真正稳定。这篇内容我会从实际使用的角度，把这类工具的设计逻辑、上手配置、以及容易被忽略的硬核细节拆开讲清楚。
如果你是做SLAM建图、视觉惯性里程计、三维重建或者相机标定相关工作的Android开发者或研究者，这篇文章应该能帮你少踩不少坑。
1. SLAM实验里最容易被低估的一环：数据采集到底难在哪
1.1 为什么"拍段视频+记个陀螺仪"完全行不通
很多非嵌入式背景的同学刚开始做视觉惯性SLAM，都会觉得数据采集没什么技术含量。但真要把数据喂给算法，第一个暴露的问题就是时间基准不统一。手机系统相机录出来的视频，文件本身没有每一帧对应的精确采集时刻；第三方IMU记录工具用的又是另外一个时钟体系，两者之间差出来的不是固定偏移，而是随着系统负载、传感器批量上报不断漂移的随机延迟。这就导致图像和IMU的关联关系天生就是错的，后续做视觉惯性对齐、标定、紧耦合优化，都会病从根上。
第二个问题是相机参数不稳定。手动对焦、自动曝光、画面裁切这些看起来不起眼的功能，会直接影响特征点的像素位置和相机内参。特别是电子防抖——很多手机默认把它开着，你以为自己在录原始图像，实际上每帧都经过了裁剪、平移甚至形变校正，标定板在画面里的位置和形貌都被悄悄改过了。
1.2 VideoIMUCapture-Android这类工具解决了什么
VideoIMUCapture-Android的核心定位很明确：面向SLAM和Structure from Motion研究场景，在一个Android应用里同时完成视频采集、IMU采样、相机参数记录，并尽可能把OIS（光学图像稳定）相关信息也纳入同一套采集流程。它不是一个花哨的相机应用，更像是一个"带时间戳的数据记录仪"。
从项目结构上看，它主要做了三件事。第一，用Camera2 API接管相机，保证每一帧画面都能拿到底层传感器时间戳；第二，用SensorManager监听加速度计和陀螺仪，把事件时间戳按纳秒精度落盘；第三，把相机的内参、分辨率、支持的防抖能力等信息统一导成配置文件，方便后续喂给标定工具或SLAM前端。这些数据凑齐之后，你手里的数据集就是一个时间对齐、参数齐全、可复现的实验样本。
1.3 采集质量如何影响SLAM算法表现
这一点我拿自己的经历举例。同一段走廊数据，我用系统相机录了一版，用采集工具录了一版，跑同一个ORB-SLAM3的视觉惯性模式。系统相机那版轨迹在地图初始化阶段就开始飘，回环检测时不时误触发；采集工具那版虽然运动模糊和光照条件完全一样，但初始化成功率明显高，轨迹平滑度也好了很多。差异主要来自三个方面：图像时间戳是否真实、IMU数据是否完整连续、防抖是否可控。这三项全对，算法才有机会发挥正常水平。
2. 从源码视角拆解VideoIMUCapture-Android的采集核心模块
2.1 视频录制模块：不止是MediaRecorder
很多人以为Android里录视频就是new一个MediaRecorder然后start，但对SLAM场景来说，问题在于MediaRecorder是一个相当黑盒的组件——你很难获得每一帧视频图像对应的精确时间戳。VideoIMUCapture-Android这类项目通常会走Camera2 + CaptureSession的路子，在onCaptureCompleted回调里读取CaptureResult.get(CaptureResult.SENSOR_TIMESTAMP)，这个数值和SensorEvent.timestamp同属单调时钟纳秒基准，可以直接用来做图像与IMU的时间对齐。
我自己改造时是这样处理的：用一个CaptureRequest.Builder打开相机预览，同时把MediaRecorder作为视频编码目标挂到同一个CaptureSession上，每次onCaptureCompleted把SENSOR_TIMESTAMP追加写入一个txt文件，并把循环缓冲区里的帧序号和时间戳对应起来。这样最后得到的，是"视频文件+逐帧时间戳文件"的组合，而不是一个孤零零的mp4。
2.2 IMU采集模块：SENSOR_DELAY_FASTEST背后有讲究
IMU采集比很多人想象中简单，也比很多人想象中麻烦。简单在于注册一个SensorEventListener就能拿到加速度计和陀螺仪数据；麻烦在于采样频率并不可靠。SENSOR_DELAY_FASTEST只是告诉系统"尽量快地给我数据"，但实际采样间隔在不同设备上可能从2ms到10ms不等，甚至在同一台设备上，某一时刻的数据也可能被批量合并在一个时间戳下。
我建议像这样处理原始数据：
override fun onSensorChanged(event: SensorEvent?) { val sensor = event?.sensor ?: return val timestampNs = event.timestamp val x = event.values[0] val y = event.values[1] val z = event.values[2] // 按传感器类型写入不同的CSV }关键点只有一个：直接使用event.timestamp，不要用System.currentTimeMillis()去"补充"时间。前者是硬件事件发生时刻，后者是当前墙钟时间，两者在异步回调里混用会产生不可控的抖动。采集CSV文件按行记录时间戳和三维数据，后续分析时再根据时间戳做重采样和插值，不要依赖系统给固定采样率。
2.3 OIS与相机参数记录：标准API能拿到的和拿不到的
VideoIMUCapture-Android项目名里最特别的就是OIS。Android标准Camera2 API允许你通过CaptureRequest.LENS_OPTICAL_STABILIZATION_MODE请求开启或关闭OIS，也能在CaptureResult里读到当前实际生效的模式。但要说真正把镜头模组的位移量、微调量一条条输出出来，标准API是不提供的，甚至不同厂商对OIS数据的开放程度差异巨大。有的高通平台会通过额外的传感器或厂商扩展接口输出稳定状态，但这类数据不具备跨机型通用性。
所以这个项目的可行做法是：在采集开始时检查CameraCharacteristics.get(CameraCharacteristics.LENS_INFO_AVAILABLE_OPTICAL_STABILIZATION)，记录设备是否支持OIS；在录制过程中记录请求的OIS模式和实际生效的OIS模式；把这些元数据连同视频、IMU一起保存。这样虽然拿不到"镜头位移了多少微米"，但至少能追踪"这组数据是在OIS开启还是关闭状态下采集的"，对实验可复现性来说已经前进了一大步。
采集结束后，输出目录大概长这样：
session_20250120_153000/ ├── video.mp4 ├── frame_timestamps.txt ├── imu_accel.csv ├── imu_gyro.csv ├── ois_status.csv ├── camera_info.json └── sensor_info.json3. 上手实操：从下载代码到跑出一份可用的SLAM数据集
3.1 环境准备与设备选型
先用Android Studio打开项目，确认SDK版本和targetSdkVersion匹配项目要求。建议直接在一台真机上跑，不用去折腾模拟器——绝大多数模拟器根本模拟不出真实的IMU和相机硬件传感器。设备选型上有几个优先级：优先选择Camera2 API支持完整、能稳定关闭电子防抖的机型；优先选择IMU采样率能稳定达到200Hz以上的机型；如果研究OIS相关课题，则优先选择明确标注支持光学防抖的旗舰机型。选一台"传感器齐全、厂商魔改少"的设备，能省下大量后期补数据的痛苦。
3.2 权限和初始化流程
Android 6以上需要动态申请CAMERA权限，IMU传感器属于普通权限，不需要在运行时申请。存储方面，如果你用targetSdkVersion 30以上的SDK，别硬写公共目录，直接用getExternalFilesDir()申请应用专属目录就行，既省去MANAGE_EXTERNAL_STORAGE的麻烦，也满足大部分研究场景的需求。
启动后的推荐顺序是：先初始化Camera2会话并设置防抖相关参数，再注册SENSOR_DELAY_FASTEST的传感器监听，最后才允许用户点击"开始录制"。这样能保证在用户按下录制键时，所有数据通路已经就绪，不会丢前几百毫秒的IMU数据。
3.3 一次规范的数据采集流程
实际采集时，不要拿起手机就随便转。我一般按下面这套流程操作，后续处理会省心很多：
- 把手机固定在三脚架或滑轨上，尽量保证运动稳定，避免剧烈抖动叠加在实验运动上；
- 用一个明亮的棋盘格或AprilTag贴在场景中，先录一小段静态视频用来做相机内参标定；
- 标定用数据采集时，把OIS关闭，DVS关闭，保证画面未经任何裁切变形；
- 正式SLAM数据采集时，按照"静止保持3秒→缓慢平移→旋转扫视→再静止3秒"的节奏录制，每段30到60秒；
- 录完之后检查一下CSV的行数是否正常、视频每一帧时间戳是否单调递增、OIS状态是否和预期一致。
这套流程跑下来，输送到标定和SLAM前端的数据就已经是干净的了。后面做相机-IMU外参标定或IMU内参标定时，你可以直接把采集到的bag或者数据回放流程交给kalibr、imu_utils这类工具处理，效率会高很多。
4. OIS和DVS之间的微妙差异，以及它对SLAM造成的真实影响
4.1 一个是移动镜头，一个是裁剪画面
OIS光学防抖和DVS电子防抖，名字听起来都在"防抖"，原理完全是两回事。OIS是物理层面的补偿，镜头模组或传感器会根据陀螺仪数据反向移动，抵消手持抖动带来的光线路径偏移。它确实让画面稳了，代价是光轴和主点位置随着帧变化——对SLAM来说，相当于每一帧的相机内参都在微变。DVS则是电子层面的处理，在传感器读出的图像上直接做裁剪、平移、变形校正。它不会改变镜头物理状态，但会改变有效FOV和图像的几何映射关系。
4.2 关键差异对照
| 维度 | 光学防抖（OIS） | 电子防抖（DVS） |
|---|---|---|
| 作用层 | 镜头/传感器物理移动 | 图像后处理 |
| 是否改变内参 | 是，主点/光轴随帧变化 | 是，FOV和几何映射变化 |
| 对SLAM影响 | 关键帧内参漂移，重投影误差增大 | 特征点位置偏移，标定被破坏 |
| 能不能事后补偿 | 比较难，需要知道微调量 | 裁剪参数或原始画面可以恢复 |
| 采集建议 | 高精度标定时关闭 | 关闭 |
4.3 为什么项目里要专门提OIS
VideoIMUCapture-Android项目名里带OIS，本质上说明OIS不是一句"关掉就行"那么简单。很多旗舰手机的OIS默认跟随系统相机参数，你哪怕设置了OIS OFF，某些场景下系统仍会强制启用。如果你不做任何追踪，采集到的数据和算法报告之间根本无法对应。更现实的是，OIS在手持场景下确实能显著提升图像清晰度——如果一个SLAM实验主题就是"手持运动下如何提高定位鲁棒性"，那反而应该在开启OIS的状态下采集，因为这才是真实使用条件。此时如果把OIS开启状态记录在案，研究者就能分析它带来的正面收益和负面畸变，而不是简单二选一。
4.4 拿OIS数据的现实做法
想拿到真正意义上一帧一帧的OIS位移数据，尝试方向有两个。一个是检查设备厂商是否提供专用传感器API，比如某些机型在系统日志或底层驱动里有OIS校准值，但这通常需要厂商文档配合，可遇不可求。另一个是通过录制开启OIS的视频和关闭OIS的视频，在特征匹配、重投影误差、轨迹漂移等维度做对比实验，用统计差异来还原OIS的影响。对你的研究来说，后者往往比追求底层数据更实用。
5. 踩坑实录：从时间戳错位到防抖悄悄开着的排查链路
5.1 时间戳错位：第一个要排查的嫌疑犯
我自己第一次跑这套采集流程时，图像和IMU的时间差直接差了几十秒，一开始还以为是算法问题。冷静下来排查，把时间戳来源列成一张表，问题立刻清楚了：
| 时间戳来源 | 单位 | 时钟基准 |
|---|---|---|
| SensorEvent.timestamp | 纳秒 | CLOCK_BOOTTIME（单调时钟） |
| Camera2 SENSOR_TIMESTAMP | 纳秒 | CLOCK_MONOTONIC（单调时钟） |
| System.currentTimeMillis() | 毫秒 | 墙钟（可能被NTP/手动调整） |
| 视频文件元数据时间 | 毫秒 | 墙钟，且精度低 |
问题往往出现在"墙钟时间"和"单调时钟时间"混用的地方。SensorEvent.timestamp和SENSOR_TIMESTAMP都是纳秒级单调时钟，可以直接对齐；但有人在不理解单位的情况下先转成毫秒，再和System.currentTimeMillis()做差，就会得出一个巨大的偏移量，然后强行平移数据，浪费时间。排查思路应该是：先确认两路时间戳是否同源，再做插值，而不是先怀疑算法参数。
5.2 防抖悄悄开着：到底从哪里开始查
如果你发现标定误差始终下不去，而时间戳又没问题，下一个怀疑对象一定是图像防抖。查的时候先从运行日志看CaptureResult.LENS_OPTICAL_STABILIZATION_MODE的实际输出，再检查video帧有没有明显裁切痕迹。有个容易忽略的细节是：系统相机App里的"视频稳定"开关和第三方App调用Camera2时的CONTROL_VIDEO_STABILIZATION_MODE是两套不同的东西。你哪怕在系统设置里关了防抖，只要你的采集App没有显式设置CONTROL_VIDEO_STABILIZATION_MODE_OFF，系统依然可能默认开启电子稳定。所以代码里确认一下这个字段很有必要。
5.3 存储与文件容量的坑
IMU高频数据写CSV，看起来不占多少空间，但如果你不强制flush，进程一旦被系统杀掉，几十分钟的缓存全没了。建议每写入一定行数或每隔几百毫秒执行一次flush，牺牲一点IO性能换数据安全。另外，很多手机默认的FAT32/exFAT文件系统对单个文件有4GB大小限制，长时间录制视频很容易撞上这个上限。稳妥做法是监听MediaRecorder的MAX_FILESIZE回调，按时自动分段。分段之后别忘了在文件命名里加上序号，避免后续处理时顺序错乱。
最后分享一个我自己的习惯：每次采集后，我都会把camera_info.json和sensor_info.json备份一份到与视频相同目录，并在实验记录里写好设备型号、固件版本、OIS设置和DVS设置。这听起来像是洁癖，但等你要复现三个月前的实验结果时，就会感谢当初记得记录这些边缘信息。数据的价值，一半在采集得对不对，另一半在于还能不能还原当时到底采集了什么。
本文还有配套的精品资源，点击获取
