簡介VideoIMUCapture-Android是一款面向SLAM與SfM研究者的Android數(shù)據(jù)采集工具可同步捕獲視頻、IMU及相機元數(shù)據(jù)并對光學防抖OIS導致的逐幀相機參數(shù)漂移問題提供警告與OIS數(shù)據(jù)支持適合需要構建高質量3D重建數(shù)據(jù)集的開發(fā)者、科研人員學習使用。資源共121個文件以Java源碼、XML資源、Python腳本和Gradle構建配置為主涵蓋Camera2 API調用、protobuf數(shù)據(jù)格式定義、Dockerfile及Shell輔助腳本壓縮包僅3.37MB工程結構緊湊便于按模塊閱讀或二次開發(fā)。目前已有618人學習下載。借助這套工程讀者可快速掌握同步時鐘下H.264視頻與約100Hz IMU數(shù)據(jù)的采集框架理解OIS與DVS的差異并基于現(xiàn)成代碼擴展自己的數(shù)據(jù)記錄流程為后續(xù)SLAM算法測試或視覺慣性里程計實驗提供可直接復用的基礎實現(xiàn)。1. 錄SLAM數(shù)據(jù)為什么必須關OISVideoIMUCapture-Android 解決的不是“能錄視頻”用 ORB-SLAM3 跑手機上錄好的視頻軌跡卻直接飛掉這是我在測試視覺慣性里程計時最常見的翻車現(xiàn)場。后來才意識到問題多半不在算法而在采集端手機默認開了 OIS 和 DVS畫面穩(wěn)了內參卻變了。VideoIMUCapture-Android 就是為這個場景準備的——一次抓齊視頻、IMU 數(shù)據(jù)、相機參數(shù)并把設備是否支持、當前是否開啟 OIS 一并告訴下游。它要解決的不是“能錄像”而是“錄出來的數(shù)據(jù)能被 SLAM 與 Structure from MotionSfM直接使用”。適合兩類人跑 VIO/SLAM 算法做數(shù)據(jù)集驗證的以及用 SfM 重建需要干凈視頻源的。2. OIS 與 DVS 的差別兩種防抖如何毀掉 SLAM 與 SfM 的內參和時間戳要理解這個采集工具為什么把 OIS 和 DVS 單獨拎出來講得先把這兩種防抖的本質說清楚。光學圖像穩(wěn)定OIS是物理層面的錄制時鏡頭模組或感光元件會沿 XY 方向平移用來抵消手部抖動。數(shù)字視頻穩(wěn)定DVS是算法層面的相機先把整個傳感器畫面讀出來再做邊緣裁剪和幀間對齊最終輸出一幀“看起來沒抖”的圖像。兩者最直接的區(qū)別是作用對象不同但它們的副作用對 SLAM/SfM 是一樣的——毀內參、亂時間戳。2.1 OIS 是鏡頭漂移DVS 是畫面裁剪兩者都讓內參“時變”先看 OIS。當鏡頭模組為補償抖動而平移時光線到達傳感器的路徑改變了等效焦距和主點坐標都在微變也就是內參矩陣不再是常量。SLAM 里三角化、PnP、光束法平差全都建立在“內參恒定”這個前提上一旦內參隨每一幀波動特征點的幾何關系就被系統(tǒng)性污染。更要命的是Android 公共 Camera2 API 通常只能讀出 OIS 的開關模式拿不到鏡頭平移的位移量。這意味著你無法在后處理里補償它只能關掉它。再看 DVS。數(shù)字穩(wěn)定典型的實現(xiàn)是“先多讀幾行再裁剪平移窗口”。裁剪窗口每幀都可能不一樣等效焦距就跟著變幀間對齊還會引入時間緩沖讓視頻幀的真實曝光時間被平移了幾個幀周期。對 SfM 來說裁剪只是損失一點 FOV但特征點匹配本身還能做對基于慣性數(shù)據(jù)緊耦合的 VIO 來說視頻幀的時間戳一旦和 IMU 時間戳不對齊視覺和慣性的約束關系就錯位了軌跡發(fā)散是必然的。兩者對 SLAM/SfM 的影響差異可以放在一起看對比項OIS 光學防抖DVS 數(shù)字穩(wěn)定作用機制鏡頭/傳感器物理平移畫面裁剪與幀間對齊對內參影響等效焦距和主點微變裁剪窗口變化導致 FOV 變化對時間戳影響影響較小主要是曝光時刻改變引入幀緩沖時間戳明顯偏移是否可補償公共 API 一般拿不到位移量可通過關閉算法避免SLAM 采集合適性必須關閉必須關閉有一類設備支持“OIS 數(shù)據(jù)輸出”這也是標題里特別強調的點。所謂“可以提供 OIS 數(shù)據(jù)”指的是系統(tǒng)能在 CaptureResult 里返回當前幀 OIS 是否生效、生效模式是哪種。這個信息對算法有實際價值即便你忘了關 OIS下游至少能通過這個字段把可疑的幀過濾掉。但請注意大多數(shù)手機不會把鏡頭位移的原始數(shù)值開放給應用層所以別指望拿它做精確補償。2.2 用 Camera2 檢測設備是否支持 OIS一份可控的 Kotlin 代碼理解了這兩種防抖的原理落地第一步就是在采集前檢測設備能力。VideoIMUCapture-Android 這類工具一般會在啟動時把相機能力讀出來寫入 sensor_info.json方便后續(xù)排查。檢測 OIS 和 DVS 支持情況的代碼不難用 Camera2 的兩個固定字段即可fun checkStabilizationSupport(cameraId: String): PairBoolean, Boolean { val characteristics cameraManager .getCameraCharacteristics(cameraId) // OIS 支持列表LENS_INFO_AVAILABLE_OPTICAL_STABILIZATION val oisModes characteristics.get( CameraCharacteristics.LENS_INFO_AVAILABLE_OPTICAL_STABILIZATION ) ?: intArrayOf(CameraMetadata.LENS_OPTICAL_STABILIZATION_MODE_OFF) // DVS 支持列表CONTROL_AVAILABLE_VIDEO_STABILIZATION_MODES val dvsModes characteristics.get( CameraCharacteristics.CONTROL_AVAILABLE_VIDEO_STABILIZATION_MODES ) ?: intArrayOf(CameraMetadata.CONTROL_VIDEO_STABILIZATION_MODE_OFF) val oisSupported oisModes.any { it ! CameraMetadata.LENS_OPTICAL_STABILIZATION_MODE_OFF } val dvsSupported dvsModes.any { it ! CameraMetadata.CONTROL_VIDEO_STABILIZATION_MODE_OFF } return oisSupported to dvsSupported }這段代碼先通過LENS_INFO_AVAILABLE_OPTICAL_STABILIZATION拿到設備支持的 OIS 模式數(shù)組。數(shù)組里出現(xiàn)OFF之外的模式比如ON、AUTO說明硬件支持光學防抖。同理CONTROL_AVAILABLE_VIDEO_STABILIZATION_MODES用于確認是否支持數(shù)字穩(wěn)定。代碼里?: intArrayOf(...)的兜底寫法很關鍵部分低端設備或定制 ROM 不實現(xiàn)這兩個字段返回 null按“不支持”處理而不是崩潰。要注意的是這個檢測結果只代表“硬件/系統(tǒng)能力”不代表錄制時 OIS 真的開啟。是否生效要看每一幀 CaptureResult 里的LENS_OPTICAL_STABILIZATION_MODE實際值。我一般會在每一幀的回調里把這個值拉出來寫入日志道理后文會講OIS 不是設置了就一定生效個別設備的 HAL 層會偷偷改回 AUTO。本節(jié)這個函數(shù)只是“設備畫像”真正起約束作用的是后面采集時的 CaptureRequest 設置。3. 從零搭建采集管線VideoIMUCapture-Android 的最小可用配置這一章解決“怎么跑起來”的問題。VideoIMUCapture-Android 通常是一個 Android Studio 工程Gradle 構建核心模塊一般分成 camera相機預覽與控制、sensorIMU 采樣、recorder編碼落盤、calib參數(shù)導出幾塊。多數(shù)情況下你不需要改核心邏輯只需要配置好權限、選對目標設備就能開始錄第一段數(shù)據(jù)。但配置過程中有幾個位置很容易踩坑下面按順序展開。3.1 工程結構與權限AndroidManifest 里必須聲明什么采集應用要碰的外設很直接相機、陀螺儀、加速度計有時還有麥克風MediaRecorder 在部分版本上即使不錄音頻也可能要求聲明音頻權限。先看一份最小可用的 AndroidManifest 配置uses-feature android:nameandroid.hardware.camera.any android:requiredfalse / uses-feature android:nameandroid.hardware.sensor.gyroscope android:requiredfalse / uses-permission android:nameandroid.permission.CAMERA / uses-permission android:nameandroid.permission.WRITE_EXTERNAL_STORAGE android:maxSdkVersion29 / uses-permission android:nameandroid.permission.RECORD_AUDIO /三點說明。第一相機和陀螺儀都聲明為requiredfalse這樣應用可以安裝到沒有陀螺儀的低端設備上運行時再做能力檢測并降級處理。第二WRITE_EXTERNAL_STORAGE加maxSdkVersion29是給 Android 10 及以下版本用的Android 11 之后強制分區(qū)存儲應用直接寫自己的外部目錄不需要這個權限。第三錄音權限看著多余但 MediaRecorder 在視頻源設置為 SURFACE 時部分 OEM 驅動仍會檢查RECORD_AUDIO不聲明會直接啟動失敗所以寧可保留。權限的動態(tài)申請建議在進入錄制頁面前一次性完成不要在錄制中途彈窗。原因很簡單彈窗會打斷錄制倒計時而且 Camera2 的打開流程和權限回調交織在一起代碼會變得很難維護。錄制過程中一旦出現(xiàn)權限被撤回部分國產 ROM 有“后臺權限回收”MediaRecorder 會以異常結束數(shù)據(jù)文件全部作廢。3.2 錄制 H.264 視頻與高頻 IMU兩套時鐘域的統(tǒng)一方案采集管線的核心工作有兩件用 Camera2 MediaRecorder 錄 H.264 視頻用 SensorManager 以最高頻率收加速度計和陀螺儀數(shù)據(jù)。先看 MediaRecorder 的配置片段val recorder MediaRecorder() recorder.setVideoSource(MediaRecorder.VideoSource.SURFACE) recorder.setOutputFormat(MediaRecorder.OutputFormat.MPEG_4) recorder.setVideoEncoder(MediaRecorder.VideoEncoder.H264) recorder.setVideoEncodingBitRate(20 * 1000 * 1000) recorder.setVideoFrameRate(30) recorder.setVideoSize(1280, 720) recorder.setOrientationHint(0)參數(shù)上我一般這樣定編碼選 H.264 MP4這是所有 SLAM 工具鏈和后處理腳本最容易解析的組合碼率給 20 Mbps 對 720p 30fps 足夠不要盲目拉到 50 Mbps會讓中端手機寫入卡頓、掉幀更嚴重分辨率選 1280x720 而不是 4K因為視覺里程計和 SfM 用的特征點分辨率并不需要多高720p 在室內紋理下已經能提取充足特征還省存儲空間。真正需要花心思的是 IMU 的時鐘域問題。SensorManager 的SensorEvent.timestamp單位是納秒但它的時鐘起點因設備而異有芯片直接給 boot time也有驅動換算過。直接把event.timestamp寫進 CSV會遇到“同一秒內 IMU 時間戳和視頻幀時間戳對不上”的怪問題。我一般不用它作為 CSV 主時間戳而是在回調到達時取SystemClock.elapsedRealtimeNanos()val listener object : SensorEventListener { override fun onSensorChanged(event: SensorEvent) { // event.timestamp 只用于同一傳感器隊列內的排序 val unifiedTimestampNs SystemClock.elapsedRealtimeNanos() imuWriter.writeLine( event.sensor.type, unifiedTimestampNs, event.values[0], event.values[1], event.values[2] ) } override fun onAccuracyChanged(sensor: Sensor, accuracy: Int) {} } sensorManager.registerListener(listener, accelerometer, SensorManager.SENSOR_DELAY_FASTEST) sensorManager.registerListener(listener, gyroscope, SensorManager.SENSOR_DELAY_FASTEST)這段代碼里的關鍵是“統(tǒng)一用elapsedRealtimeNanos()落盤”。elapsedRealtimeNanos()基于系統(tǒng)單調時鐘包含休眠時間原生支持跨傳感器比較。event.timestamp則保留用于調試——如果它和你寫入的elapsedRealtimeNanos()之間存在固定偏移且漂移穩(wěn)定說明驅動時鐘沒毛病如果偏移亂跳那是設備驅動的問題換機比換代碼快。IMU 采樣率上SENSOR_DELAY_FASTEST是能申請到的最高頻率實際收到的頻率通常在 200 Hz 到 500 Hz 之間取決于設備型號。對 VIO 算法來說 200 Hz 的陀螺儀已經夠用不需要更高。還要提醒一句注冊監(jiān)聽時不要漏了onAccuracyChanged回調里至少要記錄精度等級精度突然變?yōu)?0不可信時對應的 IMU 片段最好在數(shù)據(jù)集說明里標注出來。3.3 落盤文件組織video、imu.csv、camera_params 各放哪采集結束不能只有一個視頻文件。SLAM 算法需要的是視頻、IMU、相機參數(shù)、設備信息多路對齊的數(shù)據(jù)包。我習慣按會話建目錄每次錄制生成一個時間戳命名的文件夾session_20250101_153000/ video.mp4 imu.csv frames.csv camera_params.json sensor_info.json每個文件的職責要明確。video.mp4是 H.264 編碼的視頻流imu.csv保存加速度計和陀螺儀的逐條數(shù)據(jù)frames.csv是每一幀視頻的捕獲時間戳camera_params.json放相機內參和畸變參數(shù)sensor_info.json記錄設備能力檢測結果和錄制時實際生效的 OIS/DVS 狀態(tài)。這套組織結構的好處是后續(xù)跑標定或數(shù)據(jù)集轉換時所有信息都在一個目錄里不用翻聊天記錄找參數(shù)。camera_params.json的內容通常長這樣{ camera_id: 0, resolution: [1280, 720], fps: 30, camera_matrix: [[fx, 0, cx], [0, fy, cy], [0, 0, 1]], dist_coeffs: [k1, k2, p1, p2, k3], ois_mode: OFF, dvs_mode: OFF }注意ois_mode和dvs_mode記錄的是錄制過程中實際生效的模式不是設備支持列表。這兩個字段是后處理程序判斷數(shù)據(jù)可信度的依據(jù)如果發(fā)現(xiàn)某一段視頻的ois_mode變成了ON那這段的幾何約束必須打上標記。這里也回應了標題里的那句“如果設備支持則可以提供 OIS 數(shù)據(jù)”——設備支持 OIS 時你至少能把這種“每幀是否被防抖污染”的狀態(tài)信息給到下游。4. 從視頻到 SLAM 數(shù)據(jù)集幀時間戳與相機標定的補齊方法錄完原始視頻到真正能喂給 VINS-Mono 或 ORB-SLAM3中間還差兩步補逐幀時間戳、標定相機內參。這一步也是視頻采集工具和普通錄像 App 拉開差距的地方。MediaRecorder 寫出來的 MP4 文件本身不含你想要的“每一幀的真實曝光時間”相機標定也不能只靠 JSON 里那幾個占位符得實際算出來。4.1 MediaRecorder 不給你逐幀時間戳從 CaptureResult 里撈MediaRecorder 封裝得太徹底應用層拿不到“這一幀是什么時候曝光的”這種信息。常見做法是在錄制的同時通過 Camera2 的CaptureCallback把每一幀的時間戳撈出來單獨寫一個frames.csv。代碼核心是重寫onCaptureCompletedprivate val captureCallback object : CameraCaptureSession.CaptureCallback() { override fun onCaptureCompleted( session: CameraCaptureSession, request: CaptureRequest, result: TotalCaptureResult ) { val sensorTimestampNs result.get( CaptureResult.SENSOR_TIMESTAMP ) ?: return // 同時記錄單調時鐘用于把 sensor 時間戳統(tǒng)一到同一時基 val wallClockNs SystemClock.elapsedRealtimeNanos() framesWriter.writeLine($sensorTimestampNs,$wallClockNs) } }這里有兩個時間戳它們不是一回事。CaptureResult.SENSOR_TIMESTAMP是傳感器曝光開始時刻來自相機 HAL 的時間基準SystemClock.elapsedRealtimeNanos()是應用層收到回調的時刻。后者的作用是提供一條“換算橋”離線處理時用兩種時間戳的對應關系擬合出偏移量再統(tǒng)一到單調時鐘。不要指望SENSOR_TIMESTAMP直接能用它和 IMU 數(shù)據(jù)的時基在不同設備上有不同表現(xiàn)。落盤之后校驗幀率是否穩(wěn)定再談對齊。frames.csv行數(shù)應該接近“錄制秒數(shù) × 幀率”時間戳差值的中位數(shù)應該等于幀間隔。如果發(fā)現(xiàn)大量時間戳差值超過兩倍幀間隔說明錄制過程中存在掉幀最好重錄而不是指望算法去修復。掉幀對視覺 SLAM 是嚴重的輸入質量問題輕則軌跡抖動重則尺度漂移。4.2 棋盤格標定腳本用 OpenCV 解出內參與畸變時間戳對齊只是第一步還得知道相機內參。VideoIMUCapture-Android 輸出的camera_params.json里的內參矩陣和畸變系數(shù)一般是錄制一段棋盤格視頻后離線算出來的。先抽幀mkdir -p frames ffmpeg -i video.mp4 -vf fps8 frames/%04d.jpg抽幀頻率建議在 5-8 fps太密了相鄰幀的棋盤格角度幾乎一樣對求解沒有增量信息。完成后用下面的 OpenCV 腳本做標定import cv2 import json import glob chessboard (9, 6) criteria (cv2.TERM_CRITERIA_EPS cv2.TERM_CRITERIA_MAX_ITER, 30, 0.001) pattern_pts np.zeros((np.prod(chessboard), 3), np.float32) pattern_pts[:, :2] np.indices(chessboard).T.reshape(-1, 2) obj_pts, img_pts [], [] frames sorted(glob.glob(frames/*.jpg)) for fname in frames: img cv2.imread(fname) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) found, corners cv2.findChessboardCorners( gray, chessboard, None ) if found: obj_pts.append(pattern_pts) corners cv2.cornerSubPix( gray, corners, (11, 11), (-1, -1), criteria ) img_pts.append(corners) ret, K, dist, rvecs, tvecs cv2.calibrateCamera( obj_pts, img_pts, gray.shape[::-1], None, None ) print(json.dumps({ camera_matrix: K.tolist(), dist_coeffs: dist.tolist() }, indent2))腳本做的事情是遍歷所有抽出的幀用findChessboardCorners找棋盤格內角點找到就用cornerSubPix做亞像素精化最后喂給calibrateCamera解出內參矩陣 K 和畸變系數(shù)。這里我沒寫全import numpy as np你跑腳本時補上即可。幾個參數(shù)需要按你的棋盤調chessboard (9, 6)是內角點數(shù)不是棋盤的格子總數(shù)買棋盤時商家標的是格數(shù)內角點要各減 1。如果一幀都沒檢測到先檢查棋盤是不是反光材質或者抽幀分辨率夠不夠。成功檢測的幀數(shù)至少要 20 張并且要覆蓋畫面的中心、邊緣和俯仰角度邊緣區(qū)域的角點對畸變系數(shù)收斂尤其重要。4.3 IMU 與相機的對齊檢查錄制自檢三要素相機內參有了最后還要確認 IMU 和視頻之間是否真的能對上。SLAM 后端一般有一個 imu-camera 外參標定過程但外參標定之前你得先保證兩路數(shù)據(jù)的對齊是可解的。我自己的習慣是錄制時安排三個固定動作回放時快速判斷數(shù)據(jù)質量而不是錄完就急著跑算法。這三個動作分別是靜止 3 秒、繞豎直軸緩慢轉一圈、左右快速擺頭。用一個小腳本檢查import pandas as pd imu pd.read_csv(imu.csv) frames pd.read_csv(frames.csv, headerNone, names[sensor_ts, wall_ts]) static imu.iloc[:1000] # 開始靜止段 print(gyro mean:, static[[gyro_x, gyro_y, gyro_z]].mean()) frame_dt_ns frames[sensor_ts].diff().median() print(median frame interval ms:, frame_dt_ns / 1_000_000) print(imu first ts:, imu[ts_ns].iloc[0]) print(frame first ts:, frames[sensor_ts].iloc[0])第一個輸出檢查陀螺儀零偏靜止時陀螺均值應該在 0.02 rad/s 以內超出這個量級說明設備自身零偏大或靜止段混入了手抖。第二個輸出檢查幀間隔720p 30fps 的視頻幀間隔中位數(shù)應該是 33.33 ms波動超過 20% 就要懷疑掉幀。第三個輸出只是粗略看兩路起始時間差差得太多會影響標定收斂。這套自檢十分鐘內能做完能篩掉大半錄制返工的情況。5. 數(shù)據(jù)不對齊先排查這 5 個采集坑采集工具用起來不難但數(shù)據(jù)問題幾乎都出在不起眼的地方。下面五條是我在不同設備上踩過的坑每條都按“現(xiàn)象、原因、解決”整理你錄制前對照著檢查一遍能省下好幾輪無效實驗。5.1 畫面越穩(wěn)軌跡越飛OIS 未關閉現(xiàn)象錄出來的視頻在手機上看非常穩(wěn)定但放進 ORB-SLAM3 跑軌跡在 10 秒內就偏到畫面外。原因手機相機默認開啟了 OIS鏡頭在每一幀都在做微小平移等價于內參矩陣不斷變化而 SLAM 后端完全不知道這種變化只能把誤差算進位姿。解決創(chuàng)建CaptureRequest時顯式設置LENS_OPTICAL_STABILIZATION_MODE_OFF同時把CONTROL_VIDEO_STABILIZATION_MODE_OFF也設上。不要只關一個個別廠商的驅動會“好心”地把另一個模式也改掉。錄制開始前再從CaptureResult里讀一次兩個模式值確認不是設置后未生效。5.2 IMU 條數(shù)與幀數(shù)對不上時鐘域混用現(xiàn)象IMU 數(shù)據(jù)看起來是連續(xù)采的視頻也正常錄完但拿時間戳比較時發(fā)現(xiàn)兩端的時間基準是錯開的整條數(shù)據(jù)對不齊。原因IMU 的event.timestamp與 Camera2 的SENSOR_TIMESTAMP不一定同一時基直接把兩個值做差會得到無意義的結果。解決所有落盤時間戳統(tǒng)一用SystemClock.elapsedRealtimeNanos()傳感器原始時間戳另存?zhèn)溆?。如果已經錄錯了可以在離線階段用兩路時間戳做線性擬合求出偏移但遇到驅動時鐘跳變的設備就得重錄。5.3 畫面偏色或過曝自動白平衡和自動曝光在后臺改參數(shù)現(xiàn)象錄制前期畫面正常中段開始偏綠或過曝而且色彩突變的時間點與手機轉動的時刻重合。原因沒有鎖 AWB 和 AE相機的自動算法根據(jù)場景動態(tài)調整了增益和白平衡導致相鄰幀之間的色彩和亮度響應不一致。解決在CaptureRequest.Builder里把CONTROL_AE_MODE設為CONTROL_AE_MODE_OFFCONTROL_AWB_MODE設為CONTROL_AWB_MODE_OFF然后手動固定SENSOR_EXPOSURE_TIME和SENSOR_SENSITIVITY。注意鎖參數(shù)要在采集前做不要在錄制中途改否則會出現(xiàn)一幀跳變。5.4 陀螺儀數(shù)據(jù)全為 0傳感器監(jiān)聽被系統(tǒng)靜默回收現(xiàn)象錄制結束時看imu.csv前幾分鐘有數(shù)據(jù)后面全是一串 0 或沒有新行。原因部分手機上傳感器監(jiān)聽器沒有持有喚醒鎖系統(tǒng)在喚醒與休眠切換的邊界直接把監(jiān)聽掛起或者進程被低內存回收Listener 成了空殼。解決錄制期間拿PARTIAL_WAKE_LOCK保持 CPU 喚醒并且在 Service 而不是 Activity 里持有傳感器監(jiān)聽。錄制停止時再釋放鎖不要用應用進入后臺就被清理的組件持有 IMU 數(shù)據(jù)鏈路。5.5 MediaRecorder 掉幀碼率設太高與 IO 阻塞現(xiàn)象視頻文件的幀時間戳間隔分布不均勻中間出現(xiàn)明顯斷層但界面預覽看不出問題。原因MediaRecorder 的編碼器跟不上寫入速度或者手機存儲寫入遇到瓶頸內部緩沖區(qū)溢出后直接丟幀。解決先把碼率降到 12-20 Mbps分辨率控制在 720p。另外確保輸出目錄在設備內置存儲而不是慢速 SD 卡錄制過程中不要同時做大量文件拷貝。如果懷疑編碼器問題換一臺芯片更新的設備對比測試同一場景能快速定位卡點。6. 進階一次三分鐘自檢讓 SLAM 軌跡不再飛錄制的最后一環(huán)是把這套采集鏈路變成你實驗流程里的標準動作。我現(xiàn)在每次正式采集前都會做一個三分鐘的自檢流程跑完再去碰算法事半功倍。自檢流程分三段錄制第 1 段手機平放在桌面上靜止 3 秒第 2 段手持手機對著紋理豐富的墻面緩慢平移加轉動第 3 段快速左右甩動手機 10 次。錄完立刻檢查三組指標檢查段檢查指標正常范圍靜止段陀螺儀均值各軸小于 0.02 rad/s平移段幀時間戳中位數(shù)30fps 對應 33.3 ms波動在 10% 內甩動段幀時間戳連續(xù)性無超過兩倍幀間隔的斷層這三組指標分別對應 IMU 零偏、錄制幀率穩(wěn)定性、以及快速運動下編碼器是否丟幀。零偏大說明設備本身質量不行數(shù)據(jù)錄出來也會帶著系統(tǒng)性誤差幀間隔不穩(wěn)說明編碼器或存儲跟不上甩動段斷層說明在高速場景下采集鏈路存在瓶頸。任何一項不過關都不建議直接進入算法實驗。除了數(shù)據(jù)自檢還有一個技巧很實用在正式場景錄制前先對著一個打印的棋盤格錄 20 秒。這段視頻不參與 SLAM 實驗只用來反復確認內參標定的穩(wěn)定性。如果兩次標定的焦距偏差超過 0.5%說明相機設備狀態(tài)有變化比如鏡頭模塊松動或溫漂這時候要排查設備而不是改算法參數(shù)。我在此前項目里就吃過標定漂移的虧后來把這一步固定成采集前置動作再沒出現(xiàn)過“算法調了三天最后發(fā)現(xiàn)是標定不對”的情況。這條鏈路走順之后VideoIMUCapture-Android 的意義才會真正體現(xiàn)出來它不只是一個錄像工具而是一套把視頻、IMU、相機參數(shù)和 OIS 狀態(tài)對齊的數(shù)據(jù)采集方案。愿你少踩幾個采集坑錄出來的數(shù)據(jù)一次就能跑通。希望幫到你。本文還有配套的精品資源點擊獲取