遠隔操作とデータ収集のためのロボットカメラの設定
ロボットデータ収集のカメラの設定方法 <unk>カメラタイプ,配置,同期化,校正,記録パイプライン
カメラタイプ 比較
ロボットデータ収集の設定では3つのカメラ技術が一般的に使用されています. あなたの選択はコスト,遅延決定性,統合複雑性に影響します.
| Type | Example Model | Price | レイテンシ | Best For |
|---|---|---|---|---|
| USB (UVC) | Logitech BRIO 4K | ~$200 | 50-200ms variable | Budget setups, low-frequency tasks |
| GigE Vision | Basler ace2 a2A1920 | $400-$1,500 | <1ms deterministic | High-quality datasets, policy training |
| Depth (RGB-D) | Intel RealSense D435 | ~$200 | 30-60ms | Supplemental depth -- not recommended as primary |
USBカメラ (Logitech BRIO, ELP, Arducam) は最もアクセス可能であるが,USBホストコントローラスケジューリングによる変数遅延が原因である.負荷の下,フレーム配信は20~50 msに振動する,これは多カメラ録音を無同期化し,ポリシートレーニングを低下させる.シングルカメラまたは低フレームレートセットアップ (<15 fps) に対して,USBは受け入れられる.
GigEビジョンカメラ (Basler ace2, FLIR Blackfly S, Allied Vision Alvium) は,ハードウェアが触発されたときに決定的な <1 ms遅延を持つイーサネット上のフレームを提供します. Basler ace2 a2A1920-160ucBASは650ドルで 1920x1200を160 fpsで提供します.これは30 fpsロボット記録に十分です.GigEカメラには,ジャンボフレームが有効にされている専用NIC (
深度カメラ (RealSense D435,Azure Kinect) は,補足的な3Dシーン理解に役立つが,主要な記録カメラとして推奨されない.そのローリングシャッター,オブジェクトの境界線での深度ノイズ,輝く/暗い表面の困難により,唯一の視覚観測として不適しています.あなたの方針に深度入力が必要であれば,RGBカメラに加えてそれらを使用してください.
3つのカメラ設定
操作作業は異なるカメラの配置によって得られます RCSVで使用されている3つの検証された構成は,複雑性とデータ豊かさによって順序付けられています.
設定1:最小 (1 カメラ,予算設定)
- カメラ: 1xオーバーヘッドUSBカメラ (ロジテック・BRIO,$200)
- 位置: 90~100cm以上で,直下に向いている作業場
- ** 解像度:** 1280x720 30 fps
- 使用例: シンプルなピックアンド・プレス,初期プロトタイプ作成,単腕のテーブルタスク
- 制限: 高さ情報なし,エゴ中心的な視野なし,複雑な作業で3カメラの設定よりも15~25%低の政策パフォーマンス
これはデータ収集を開始する最も速い方法です.同期化ハードウェアは必要ありません. 多カメラセットアップに投資する前にタスク定義を検証するのに適しています.
設定2:標準 (3カメラ,推奨)
この構成は,標準操作データ収集のためにRCSVで使用され,覆い,解像度,およびストレージコストをバランスします.
- カメラ1 - 固定オーバーヘッド (上から下): 作業場から80~100cm上を並べて,直下に向いている.解像度1280x960は30fps.上から全作業場,オブジェクト配置,グリッパーアプローチを撮影する.これはほとんどのピックアンドプレイスポリシーにとって最も情報提供的なビューです.
- カメラ2 -- 固定側 (横): 作業場の高さで,横に60~80cmを設置する. 解析度1280x960/s30fps. オーバーヘッドビューができない高さの情報を提供する. スタッキング,倒し,挿入作業に不可欠です.
- カメラ3 - 手首 (エゴ中心): ロボットのエンドエフェクターやツールフラングに搭載され,前向き. 解析度640x480 60 fps.より高いフレームレートは模糊なく手首の動きを捕捉します.エゴ中心のビューは模倣学習研究における把握と精巧な操作政策のパフォーマンスを大幅に改善します.
DK1を使用した双手設定では,両腕間の遮蔽をカバーするために,カメラ2の反対側に4番目の固定カメラを追加します.
設定3: 完全カバー (5+カメラ,高度)
- カメラ 1-3: 設定2と同じ (上頭,側,腕)
- カメラ4 - 反対側: 作業場の反対側にある鏡のカメラ2 腕と腕の遮断盲点を排除する.
- カメラ5 -- 前向きの角度 (45°): 45°下向きの角度で60cm前向きに位置する.上向きが欠けている物体の接近とグリッパーの方向を捕捉する.
- カメラ6 (オプション) --深度カメラ: ポイントクラウドデータの補充のために,上空位置に近いインテルRealSense D435を設置.
この構成は,エピソードごとに3~5倍以上のデータを生成しますが,最も完全な視覚的なカバーを提供します.マルチビューポリシー学習と3Dシーン再構築の研究に使用されます. ストレージ要求:カメラあたり15 Mbpsで約500 MB/分.
端から端の遅延予算
遠隔操作では,グラスからガラスまでの合計遅延 (センサーに触れる光子からアクチュエーターの動きまで) は快適な人間の操作のために150ms以下で,精密な操作のために100ms以下でなければならない.典型的なGigeEカメラの遅延の割れ目は以下の通り.
| Stage | Component | GigE Camera | USB Camera |
|---|---|---|---|
| 1 | Sensor exposure | 5-10 ms | 5-33 ms (auto-exposure) |
| 2 | Readout + transfer | <1 ms (Ethernet) | 10-50 ms (USB scheduling) |
| 3 | Driver processing | 1-2 ms | 2-5 ms |
| 4 | ROS2 topic publish | 1-3 ms | 1-3 ms |
| 5 | Policy inference | 10-30 ms (GPU) | 10-30 ms (GPU) |
| 6 | Motor command + execution | 5-10 ms | 5-10 ms |
| Total | 23-56 ms | 33-131 ms |
USBカメラの経路は負荷下で100 msを超えることができる (複数の USB デバイスがホストコントローラーを共有しているため),注意すべきテレオップ遅延を引き起こす. [OpenArm 1]
同期化方法
複数のカメラの同期化は重要です カメラの間の 33msの脱同期化は 30fpsで ひとつのカメラが1フレーム後にあることを意味します 脱同期されたデータに訓練されたポリシーは 誤った時間関連性を学んでいます
ハードウェア GPIO トリガー (GigeEカメラに推奨)
単一のトリガーパルスがマイクロコントローラー (Arduino Unoで25ドルまたはRaspberry Pi GPIO) によって生成され,すべてのカメラのトリガー入力に同時にケーブル接続されます. <1msの同期化を達成します.Pylon (Basler) または SpinView (FLIR) を介して外部トリガーモードでカメラを設定します.トリガーパルスもデータファイルにログインされ,正確な共通のタイムスタンプを提供します.
# Arduino trigger sketch for 30 fps synchronized capture
void setup() {
pinMode(2, OUTPUT); // Trigger pin → all camera trigger inputs
}
void loop() {
digitalWrite(2, HIGH);
delayMicroseconds(100); // 100us pulse width
digitalWrite(2, LOW);
delay(33); // 33ms → 30 fps
}
NTPによるソフトウェア同期化
レーベルを入力する機を共通NTPサーバーに同期する (
ROS2メッセージ_フィルター 接近同期
ハードウェアのトリガーが利用できない場合, ROS2
from message_filters import ApproximateTimeSynchronizer, Subscriber
from sensor_msgs.msg import Image
sub_overhead = Subscriber(node, Image, '/cam_overhead/image_raw')
sub_side = Subscriber(node, Image, '/cam_side/image_raw')
sub_wrist = Subscriber(node, Image, '/cam_wrist/image_raw')
sync = ApproximateTimeSynchronizer(
[sub_overhead, sub_side, sub_wrist],
queue_size=10,
slop=0.033 # 33ms tolerance (1 frame at 30fps)
)
sync.registerCallback(synchronized_callback)
カメラの校正
カリブレーションには2つの要素があります. カメラごとに内在的,および外在的 (カメラとロボットベースとの間の相対的な姿勢).
内部の校正は,各カメラの焦点距離,主点,歪み系数を特徴付けます.OpenCVの校正モジュールを使用して9×7チェッカーボード (25mm平方) を使用します.様々な角度と距離で20-40枚の画像を収集します.再投射エラーをターゲットに <0.5 px (最大1.0 pxまで許容できます). 校正を実行します:
外部の校正は,各カメラフレームからロボットベースフレームに6DOF変換を決定する.いくつかの既知のポーズに搭載された ChArUcoボード (普通のチェッカーボードよりもより良い角検知) を使用する.各カメラでは,作業場体全体で15〜20枚のボードの観測を収集する. 結果となる変換は, ROS2 パラメータファイルに静的な TFフレームとして保存され,政策訓練のための共通のロボット関連座標フレームに観測を投影するために使用されます.
校正を確認する.各カメラ画像にロボットのTCP位置 (前向きのシナマティック) を投影する.投影された点はすべての作業場位置で可視のTCPと5ピクセル以内に一致する.エラー>10pxは通常,誤ったカメラマウントポーズを示します.マウントの硬性を再確認し,外部のデータを記憶します.
ROS2 イメージ トランスポートパイプライン
ROS2 の
| Transport | Bandwidth (1280x960@30fps) | CPU Load | Quality Loss | Best For |
|---|---|---|---|---|
| raw | ~880 Mbps | Minimal | None | Intra-process, shared memory |
| compressed (JPEG 80%) | ~30-60 Mbps | Moderate | Slight (lossy) | Cross-machine recording |
| h264 (ffmpeg_image_transport) | ~10-30 Mbps | High (GPU encode helps) | Moderate (lossy) | Long recording sessions, storage-limited |
| compressed (PNG) | ~300-500 Mbps | High | None (lossless) | Archival, precision-critical data |
**推奨:**標準データ収集では80%の品質でJPEG圧縮輸送を使用します.この品質レベルでの圧縮アーテファクトは,ほとんどの政策訓練パイプラインのノイズ床以下です.最も信頼性の高い研究データセットでは, PNGの損失をなくして,ストレージを10倍増やす計画を立ててください.
模倣学習のための HDF5 録音形式
記録パイプラインは,同期フレーム,ロボットコモンスト状態,アクションラベルをデモごとに単一のファイルに収録する必要があります. HDF5はACT,拡散ポリシー,およびほとんどの模倣学習フレームワークで使用される標準形式です.
推奨されたHDF5構造
/episode_0042/
observations/
images/
cam_overhead # (T, H, W, 3) uint8 JPEG-decoded frames
cam_side # (T, H, W, 3) uint8
cam_wrist # (T, H, W, 3) uint8
joint_positions # (T, 6) float64 — radians
joint_velocities # (T, 6) float64 — rad/s
ee_pose # (T, 7) float64 — xyz + quaternion
gripper_state # (T, 1) float64 — 0.0 closed to 1.0 open
tactile/ # optional
left_finger # (T, 16, 16) uint16 — Paxini pressure
right_finger # (T, 16, 16) uint16
actions/
joint_positions # (T, 6) float64 — target joint positions
gripper_action # (T, 1) float64 — target gripper state
metadata/
timestamp # (T,) float64 — Unix timestamps
trigger_pulse # (T,) uint8 — hardware trigger confirmation
fps # scalar — recording frame rate
camera_intrinsics # dict — per-camera calibration
camera_extrinsics # dict — camera-to-base transforms
Python で HDF5 を 書ける:
import h5py
import numpy as np
with h5py.File('episode_0042.hdf5', 'w') as f:
ep = f.create_group('episode_0042')
obs = ep.create_group('observations')
imgs = obs.create_group('images')
# Store images with chunk-based compression
imgs.create_dataset('cam_overhead', data=overhead_frames,
chunks=(1, 960, 1280, 3), compression='gzip')
obs.create_dataset('joint_positions', data=joint_data)
obs.create_dataset('ee_pose', data=ee_data)
# Actions
acts = ep.create_group('actions')
acts.create_dataset('joint_positions', data=action_data)
# Metadata
meta = ep.create_group('metadata')
meta.create_dataset('timestamp', data=timestamps)
meta.attrs['fps'] = 30
フレームアライナメント: 書き込み時にすべてのデータをトリガータイムスタンプに並べます.誤ったタイムスタンプを使用する代わりに5ms以上の遅刻で到着するフレームを落としてください.落としたフレームは誤ったフレームよりも良い.
管道構造の記録
カメラセンサーから HDF5ファイルまでの完全な記録パイプライン:
- カメラドライバーノード (カメラ1つ):
T15 を T16 と T17 に公開します. - 同期ノード: すべてのカメラのフレームを並べ替えるために
T18 を使用します + T19 + T20 . カスタム T21 メッセージを公開します. - レコーダーノード:
T22 に登録し,メモリにバッファを入れ,エピソード境界線で HDF5にフラッシュします (オペレータボタンを押すか,遠隔操作停止信号によって触発されます). - 圧縮 (オプション): 高解像度で録音する場合は,録音ループをブロックしないように,別々のスレッドでH.264コードを実行します. 10 Mbpsでは,30 fpsのストリームで1280x960はカメラあたり約75 MB/分を使用します.
クラウドストレージとデータセット管理のために,自動アップロード,デプリカリ,データセットバージョンを提供するRCSVのデータサービス (Data Services) を使用します.原始録音はさらに圧縮されます (共同データでは損失なし,ビデオでは H.264が損失なし) 収集日に約40GBに長期ストレージを削減します.
貯蔵計画
データ収集キャンペーンを開始する前に,ストレージの必要性を計算してください.
例: 3 カメラのセットアップは1 15 Mbps/カメラ,8時間収集日: 3 カメラ x 15 Mbps x 3600s/h x 8h / 8ビット/バイト / 1e9 GB = 162 GB/日.平均10 Mbps: 108 GB/日.録画ステーションごとに4 TB NVMe SSDを計画し,夜間RsyncをNASまたはクラウドバケットにします.
| Configuration | Cameras | GB/day (8 hr) | Days on 4 TB SSD | Monthly Cloud Cost (S3) |
|---|---|---|---|---|
| Minimal (JPEG) | 1 | 36 | ~110 | ~$18 |
| Standard (H.264) | 3 | 108 | ~37 | ~$55 |
| Full coverage (H.264) | 5 | 180 | ~22 | ~$92 |
| Full coverage (PNG lossless) | 5 | 900 | ~4 | ~$460 |
照明の設定
一貫した照明は,政策の一般化を劇的に改善します 不一致な照明の下で訓練された政策は,照明条件が異なる場合,部署に失敗することが多い.
- 色温: 5500K 日照を均衡させるLEDリングライトを (例えば,Neewer 18"リングライトは60ドル) 使用する.すべてのライトの色温は,カメラ間のホワイトバランスの変化を防ぐ.
- 位置: ライトを上部カメラ軸から45度角度で位置させ,輝く物体やロボット表面の鏡像反射を最小限に抑える.
- 拡散: 硬い影を排除するために,ライトの前には拡散パネル (凍結したアクリルシート) を追加する.硬い影は,日の異なる時間に一般化しない視覚的な特徴を作成する.
- ** 窓の近くでのラボ設定では,雲と太陽の角度から周囲の光の変化を排除するために,ブラックアウトカーテンを設置します.これはデータ収集品質に最も高いROI投資の一つです.
一般 的 な 問題 や 解決法
| Issue | Cause | Solution |
|---|---|---|
| Dropped frames | USB bandwidth saturation | Move cameras to separate USB controllers; use GigE |
| GigE incomplete frames | Jumbo frames not enabled | ip link set eth0 mtu 9000 |
| Color inconsistency between cameras | Auto white balance enabled | Set manual white balance (5500K) on all cameras |
| Blurry wrist camera | Motion blur from long exposure | Set exposure to <5 ms; increase lighting intensity |
| High CPU during recording | Software JPEG encoding per frame | Use camera-side JPEG encoding or GPU H.264 (NVENC) |
| キャリブレーション reprojection >1 px | Too few or poorly distributed calibration images | Collect 30+ images covering all corners at varied distances |
カメラタイプ 比較
ロボットデータ収集の設定では3つのカメラ技術が一般的に使用されています. あなたの選択はコスト,遅延決定性,統合複雑性に影響します.
| Type | Example Model | Price | レイテンシ | Best For |
|---|---|---|---|---|
| USB (UVC) | Logitech BRIO 4K | ~$200 | 50-200ms variable | Budget setups, low-frequency tasks |
| GigE Vision | Basler ace2 a2A1920 | $400-$1,500 | <1ms deterministic | High-quality datasets, policy training |
| Depth (RGB-D) | Intel RealSense D435 | ~$200 | 30-60ms | Supplemental depth -- not recommended as primary |
USBカメラ (Logitech BRIO, ELP, Arducam) は最もアクセス可能であるが,USBホストコントローラスケジューリングによる変数遅延が原因である.負荷の下,フレーム配信は20~50 msに振動する,これは多カメラ録音を無同期化し,ポリシートレーニングを低下させる.シングルカメラまたは低フレームレートセットアップ (<15 fps) に対して,USBは受け入れられる.
GigEビジョンカメラ (Basler ace2, FLIR Blackfly S, Allied Vision Alvium) は,ハードウェアが触発されたときに決定的な <1 ms遅延を持つイーサネット上のフレームを提供します. Basler ace2 a2A1920-160ucBASは650ドルで 1920x1200を160 fpsで提供します.これは30 fpsロボット記録に十分です.GigEカメラには,ジャンボフレームが有効にされている専用NIC (
深度カメラ (RealSense D435,Azure Kinect) は,補足的な3Dシーン理解に役立つが,主要な記録カメラとして推奨されない.そのローリングシャッター,オブジェクトの境界線での深度ノイズ,輝く/暗い表面の困難により,唯一の視覚観測として不適しています.あなたの方針に深度入力が必要であれば,RGBカメラに加えてそれらを使用してください.
3つのカメラ設定
操作作業は異なるカメラの配置によって得られます RCSVで使用されている3つの検証された構成は,複雑性とデータ豊かさによって順序付けられています.
設定1:最小 (1 カメラ,予算設定)
- カメラ: 1xオーバーヘッドUSBカメラ (ロジテック・BRIO,$200)
- 位置: 90~100cm以上で,直下に向いている作業場
- ** 解像度:** 1280x720 30 fps
- 使用例: シンプルなピックアンド・プレス,初期プロトタイプ作成,単腕のテーブルタスク
- 制限: 高さ情報なし,エゴ中心的な視野なし,複雑な作業で3カメラの設定よりも15~25%低の政策パフォーマンス
これはデータ収集を開始する最も速い方法です.同期化ハードウェアは必要ありません. 多カメラセットアップに投資する前にタスク定義を検証するのに適しています.
設定2:標準 (3カメラ,推奨)
この構成は,標準操作データ収集のためにRCSVで使用され,覆い,解像度,およびストレージコストをバランスします.
- カメラ1 - 固定オーバーヘッド (上から下): 作業場から80~100cm上を並べて,直下に向いている.解像度1280x960は30fps.上から全作業場,オブジェクト配置,グリッパーアプローチを撮影する.これはほとんどのピックアンドプレイスポリシーにとって最も情報提供的なビューです.
- カメラ2 -- 固定側 (横): 作業場の高さで,横に60~80cmを設置する. 解析度1280x960/s30fps. オーバーヘッドビューができない高さの情報を提供する. スタッキング,倒し,挿入作業に不可欠です.
- カメラ3 - 手首 (エゴ中心): ロボットのエンドエフェクターやツールフラングに搭載され,前向き. 解析度640x480 60 fps.より高いフレームレートは模糊なく手首の動きを捕捉します.エゴ中心のビューは模倣学習研究における把握と精巧な操作政策のパフォーマンスを大幅に改善します.
DK1を使用した双手設定では,両腕間の遮蔽をカバーするために,カメラ2の反対側に4番目の固定カメラを追加します.
設定3: 完全カバー (5+カメラ,高度)
- カメラ 1-3: 設定2と同じ (上頭,側,腕)
- カメラ4 - 反対側: 作業場の反対側にある鏡のカメラ2 腕と腕の遮断盲点を排除する.
- カメラ5 -- 前向きの角度 (45°): 45°下向きの角度で60cm前向きに位置する.上向きが欠けている物体の接近とグリッパーの方向を捕捉する.
- カメラ6 (オプション) --深度カメラ: ポイントクラウドデータの補充のために,上空位置に近いインテルRealSense D435を設置.
この構成は,エピソードごとに3~5倍以上のデータを生成しますが,最も完全な視覚的なカバーを提供します.マルチビューポリシー学習と3Dシーン再構築の研究に使用されます. ストレージ要求:カメラあたり15 Mbpsで約500 MB/分.
端から端の遅延予算
遠隔操作では,グラスからガラスまでの合計遅延 (センサーに触れる光子からアクチュエーターの動きまで) は快適な人間の操作のために150ms以下で,精密な操作のために100ms以下でなければならない.典型的なGigeEカメラの遅延の割れ目は以下の通り.
| Stage | Component | GigE Camera | USB Camera |
|---|---|---|---|
| 1 | Sensor exposure | 5-10 ms | 5-33 ms (auto-exposure) |
| 2 | Readout + transfer | <1 ms (Ethernet) | 10-50 ms (USB scheduling) |
| 3 | Driver processing | 1-2 ms | 2-5 ms |
| 4 | ROS2 topic publish | 1-3 ms | 1-3 ms |
| 5 | Policy inference | 10-30 ms (GPU) | 10-30 ms (GPU) |
| 6 | Motor command + execution | 5-10 ms | 5-10 ms |
| Total | 23-56 ms | 33-131 ms |
USBカメラの経路は,負荷下で100 msを超えることができる (複数の USB デバイスがホストコントローラを共有しているため),注意すべきテレオップ遅延を引き起こす. [OpenArm 1]
同期化方法
複数のカメラの同期化は重要です カメラの間の 33msの脱同期化は 30fpsで ひとつのカメラが1フレーム後にあることを意味します 脱同期されたデータに訓練されたポリシーは 誤った時間関連性を学んでいます
ハードウェア GPIO トリガー (GigeEカメラに推奨)
単一のトリガーパルスがマイクロコントローラー (Arduino Unoで25ドルまたはRaspberry Pi GPIO) によって生成され,すべてのカメラのトリガー入力に同時にケーブル接続されます. <1msの同期化を達成します.Pylon (Basler) または SpinView (FLIR) を介して外部トリガーモードでカメラを設定します.トリガーパルスもデータファイルにログインされ,正確な共通のタイムスタンプを提供します.
# Arduino trigger sketch for 30 fps synchronized capture
void setup() {
pinMode(2, OUTPUT); // Trigger pin → all camera trigger inputs
}
void loop() {
digitalWrite(2, HIGH);
delayMicroseconds(100); // 100us pulse width
digitalWrite(2, LOW);
delay(33); // 33ms → 30 fps
}
NTPによるソフトウェア同期化
共同のNTPサーバー (
ROS2メッセージ_フィルター 接近同期
ハードウェアのトリガーが利用できない場合, ROS2
from message_filters import ApproximateTimeSynchronizer, Subscriber
from sensor_msgs.msg import Image
sub_overhead = Subscriber(node, Image, '/cam_overhead/image_raw')
sub_side = Subscriber(node, Image, '/cam_side/image_raw')
sub_wrist = Subscriber(node, Image, '/cam_wrist/image_raw')
sync = ApproximateTimeSynchronizer(
[sub_overhead, sub_side, sub_wrist],
queue_size=10,
slop=0.033 # 33ms tolerance (1 frame at 30fps)
)
sync.registerCallback(synchronized_callback)
カメラの校正
カリブレーションには2つの要素があります. カメラごとに内在的,および外在的 (カメラとロボットベースとの間の相対的な姿勢).
内部の校正は,各カメラの焦点距離,主点,歪み系数を特徴づけます.OpenCVの校正モジュールを使用して9×7チェッカーボード (25mm平方) を使用します.様々な角度と距離で20-40枚の画像を収集します.再投射エラーをターゲットに <0.5 px (最大1.0 pxまで許容できます).校正を実行します:
外部の校正は,各カメラフレームからロボットベースフレームに6DOF変換を決定する.いくつかの既知のポーズに搭載された ChArUcoボード (普通のチェッカーボードよりもより良い角検知) を使用する.各カメラでは,作業場体全体で15〜20枚のボードの観測を収集する. 結果となる変換は, ROS2 パラメータファイルに静的な TFフレームとして保存され,政策訓練のための共通のロボット関連座標フレームに観測を投影するために使用されます.
校正を確認する.各カメラ画像にロボットのTCP位置 (前向きのシナマティック) を投影する.投影された点はすべての作業場位置で可視のTCPと5ピクセル以内に一致する.エラー>10pxは通常,誤ったカメラマウントポーズを示します.マウントの硬性を再確認し,外部のデータを記憶します.
ROS2 イメージ トランスポートパイプライン
ROS2 の
| Transport | Bandwidth (1280x960@30fps) | CPU Load | Quality Loss | Best For |
|---|---|---|---|---|
| raw | ~880 Mbps | Minimal | None | Intra-process, shared memory |
| compressed (JPEG 80%) | ~30-60 Mbps | Moderate | Slight (lossy) | Cross-machine recording |
| h264 (ffmpeg_image_transport) | ~10-30 Mbps | High (GPU encode helps) | Moderate (lossy) | Long recording sessions, storage-limited |
| compressed (PNG) | ~300-500 Mbps | High | None (lossless) | Archival, precision-critical data |
**推奨:**標準データ収集では80%の品質でJPEG圧縮輸送を使用します.この品質レベルでの圧縮アーテファクトは,ほとんどの政策訓練パイプラインのノイズ床以下です.最も信頼性の高い研究データセットでは, PNGの損失をなくして,ストレージを10倍増やす計画を立ててください.
模倣学習のための HDF5 録音形式
記録パイプラインは,同期フレーム,ロボットコモンスト状態,アクションラベルをデモごとに単一のファイルに収録する必要があります. HDF5はACT,拡散ポリシー,およびほとんどの模倣学習フレームワークで使用される標準形式です.
推奨されたHDF5構造
/episode_0042/
observations/
images/
cam_overhead # (T, H, W, 3) uint8 JPEG-decoded frames
cam_side # (T, H, W, 3) uint8
cam_wrist # (T, H, W, 3) uint8
joint_positions # (T, 6) float64 — radians
joint_velocities # (T, 6) float64 — rad/s
ee_pose # (T, 7) float64 — xyz + quaternion
gripper_state # (T, 1) float64 — 0.0 closed to 1.0 open
tactile/ # optional
left_finger # (T, 16, 16) uint16 — Paxini pressure
right_finger # (T, 16, 16) uint16
actions/
joint_positions # (T, 6) float64 — target joint positions
gripper_action # (T, 1) float64 — target gripper state
metadata/
timestamp # (T,) float64 — Unix timestamps
trigger_pulse # (T,) uint8 — hardware trigger confirmation
fps # scalar — recording frame rate
camera_intrinsics # dict — per-camera calibration
camera_extrinsics # dict — camera-to-base transforms
Python で HDF5 を 書ける:
import h5py
import numpy as np
with h5py.File('episode_0042.hdf5', 'w') as f:
ep = f.create_group('episode_0042')
obs = ep.create_group('observations')
imgs = obs.create_group('images')
# Store images with chunk-based compression
imgs.create_dataset('cam_overhead', data=overhead_frames,
chunks=(1, 960, 1280, 3), compression='gzip')
obs.create_dataset('joint_positions', data=joint_data)
obs.create_dataset('ee_pose', data=ee_data)
# Actions
acts = ep.create_group('actions')
acts.create_dataset('joint_positions', data=action_data)
# Metadata
meta = ep.create_group('metadata')
meta.create_dataset('timestamp', data=timestamps)
meta.attrs['fps'] = 30
フレームアライナメント: 書き込み時にすべてのデータをトリガータイムスタンプに並べます.誤ったタイムスタンプを使用する代わりに5ms以上の遅刻で到着するフレームを落としてください.落としたフレームは誤ったフレームよりも良い.
管道構造の記録
カメラセンサーから HDF5ファイルまでの完全な記録パイプライン:
- カメラドライバーノード (カメラ1つ):
T31 を T32 と T33 に公開します. - 同期ノード: すべてのカメラのフレームを並べ替えるために
T34 を使用します + T35 + T36 . カスタム T37 メッセージを公開します. - レコードノード:
T38 に登録し,メモリにバッファーを入れ,エピソード境界線で HDF5にフラッシュします (オペレータボタンを押すか,遠隔操作停止信号によって触発されます). - 圧縮 (オプション): 高解像度で録音する場合は,録音ループをブロックしないように,別々のスレッドでH.264コードを実行します. 10 Mbpsでは,30 fpsのストリームで1280x960はカメラあたり約75 MB/分を使用します.
クラウドストレージとデータセット管理のために,自動アップロード,デプリカリおよびデータセットバージョンを提供する [RCSVのデータサービス]
貯蔵計画
データ収集キャンペーンを開始する前に,ストレージの必要性を計算してください.
例: 3 カメラのセットアップは1 15 Mbps/カメラ,8時間収集日: 3 カメラ x 15 Mbps x 3600s/h x 8h / 8ビット/バイト / 1e9 GB = 162 GB/日.平均10 Mbps: 108 GB/日.録画ステーションごとに4 TB NVMe SSDを計画し,夜間RsyncをNASまたはクラウドバケットにします.
| Configuration | Cameras | GB/day (8 hr) | Days on 4 TB SSD | Monthly Cloud Cost (S3) |
|---|---|---|---|---|
| Minimal (JPEG) | 1 | 36 | ~110 | ~$18 |
| Standard (H.264) | 3 | 108 | ~37 | ~$55 |
| Full coverage (H.264) | 5 | 180 | ~22 | ~$92 |
| Full coverage (PNG lossless) | 5 | 900 | ~4 | ~$460 |
照明の設定
一貫した照明は,政策の一般化を劇的に改善します 不一致な照明の下で訓練された政策は,照明条件が異なる場合,部署に失敗することが多い.
- 色温: 5500K 日照を均衡させるLEDリングライトを (例えば,Neewer 18"リングライトは60ドル) 使用する.すべてのライトの色温は,カメラ間のホワイトバランスの変化を防ぐ.
- 位置: ライトを上部カメラ軸から45度角度で位置させ,輝く物体やロボット表面の鏡像反射を最小限に抑える.
- 拡散: 硬い影を排除するために,ライトの前には拡散パネル (凍結したアクリルシート) を追加する.硬い影は,日の異なる時間に一般化しない視覚的な特徴を作成する.
- ** 窓の近くでのラボ設定では,雲と太陽の角度から周囲の光の変化を排除するために,ブラックアウトカーテンを設置します.これはデータ収集品質に最も高いROI投資の一つです.
一般 的 な 問題 や 解決法
| Issue | Cause | Solution |
|---|---|---|
| Dropped frames | USB bandwidth saturation | Move cameras to separate USB controllers; use GigE |
| GigE incomplete frames | Jumbo frames not enabled | ip link set eth0 mtu 9000 |
| Color inconsistency between cameras | Auto white balance enabled | Set manual white balance (5500K) on all cameras |
| Blurry wrist camera | Motion blur from long exposure | Set exposure to <5 ms; increase lighting intensity |
| High CPU during recording | Software JPEG encoding per frame | Use camera-side JPEG encoding or GPU H.264 (NVENC) |
| キャリブレーション reprojection >1 px | Too few or poorly distributed calibration images | Collect 30+ images covering all corners at varied distances |