联系销售
返回Guides

机器人摄像头设置用于远程操作和数据收集

如何设置机器人数据收集的摄像头 <unk>摄像头类型,放置,同步,校准和记录管道.

相机类型的比较

您的选择影响成本,延迟确定性和集成复杂性.

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-50ms,这使得多摄像头录像脱节并降低了政策训练.对于单摄像头或低摄像头速度设置 (<15fps),USB是可接受的.

GigE视觉摄像头 (Basler ace2,FLIR Blackfly S,Allied Vision Alvium) 在硬件触发时提供以太网为止的框架,具有确定性 <1 ms的延迟.Basler ace2 a2A1920-160ucBAS在650美元的价格提供1920x1200的速度为160fps,足够于30fps机器人录制.GigE摄像头需要具有启用 jumbo框架 (T8) 的专用NIC和PoE开关或注射器.

深度摄像头 (RealSense D435,Azure Kinect) 是用于补充3D场景理解的,但不推作为主要录像摄像头.它们的滚动离子,对象边界的深度噪音,以及光/黑暗表面的难度使它们不适合作为唯一的视觉观测.如果您的政策需要深度输入,则使用它们除了RGB摄像头外.

三种摄像机配置

操作任务受益于不同的摄像头安排.以下是RCSV使用的三个验证配置,按复杂性和数据丰富度排序.

配置1:最小 (1 摄像头,预算设置)

  • 卡马:** 1x 超级USB卡马 (Logitech BRIO,200美元)
  • 位置: 坐落于工作场所90-100厘米以上,直向下面
  • 清晰度:** 1280x720 速度为 30 fps
  • 使用情况: 简单的选择和放置,初始原型制造,单臂桌面任务
  • 限制: 没有高度信息,没有自我中心的视图,政策效率15-25%低于复杂任务的3摄像头设置

您可以在投资多摄像头设置之前验证任务定义.

配置2:标准 (3摄像头,建议)

对于标准操纵数据收集,RCSV使用这种配置,并平衡覆盖,分辨率和存储成本:

  • 相机1 -- 固定上空 (上下): 装在工作空间80-100厘米以上,直向下.分辨率1280x960以30fps. 从上方捕捉整个工作空间,对象放置和抓住器的方法.这是大多数选择和位置政策最有信息的视图.
  • 相机2 -- 固定侧 (侧): 安装在工作空间高度,侧面60-80厘米.分辨率1280x960以30fps.提供高度信息,空视图无法.对堆叠,倒和插入任务至关重要.
  • **相机3 - 手腕 (自我中心):**安装在机器人的终端效应器或工具上,面向前.分辨率为640x480以60fps.更高的镜像速度可以捕捉到快速的手腕运动,而不会模糊.自我中心的视图显著提高了模仿学习研究中的抓住和精细操纵政策性能.

对于使用DK1的双手设置,将相机2的相反侧置置第四个固定相机,以覆盖双臂罩.

配置3:全覆盖 (5+摄像头,高级)

  • 相机1-3: 与配置2相同 (上头,侧,手腕)
  • 相机4 - 另一侧: 镜像相机2在工作场所的另一侧. 消除手/臂遮蔽盲点.
  • 相机5 -- 前面角 (45度): 位于前面60厘米,向下角45度. 捕捉到对象接近和抓住器的方向,而上头错过.
  • 相机6 (可选) -- 深度相机: 智能实力Sense D435 安装在空头位置附近,可提供额外的点云数据.

这种配置每集生成3-5倍的数据,但提供了最完整的视觉覆盖.用于多视图政策学习和3D场景重建的研究.存储需求:每相机的15 Mbps约为500 MB/分钟.

终端延迟预算

对于远程操作,总玻璃到玻璃延迟 (从光子撞到传感器到动机运动) 必须保持在150ms以下,以舒适的人员操作,并低于100ms以精确的操纵.

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

对于使用 [OpenArm 1]T40的舒适远程操作,我们建议使用GigeE摄像头或至少确保每个USB摄像头都在专用USB主机控制器上 (查看T9).

协同化方法

通过33毫米的相机在30fps的速度间的脱同步,意味着一个相机落后一个完整的框架.

硬件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进行软件同步

通过使用T11的ROS2时间标签将在机器中一致到+/-10 ms.适合15fps录制,但不适用于60fps手腕摄像头.

接近同步的ROS2消息_过器

当硬件触发功能不存在时,使用ROS2 T12包,以按时间标签约同步相机主题:

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)

摄像头校准

校准有两个组成部分:每相机的内在和外在 (相机和机器人基之间的相对姿势).

内在校准标志着每个相机的焦距,主点和扭曲系数.使用OpenCV的校准模块,使用9×7棋盘 (25毫米方形).在不同角度和距离收集20-40张图像.目标重投射错误 <0.5 px (可接受高达1.0 px).运行校准使用: T13.

外观校准确定了从每个摄像头框架到机器人基架的6DOF转换.使用一个安装在几个已知姿势的ChArUco板 (比普通棋牌更好的角落检测).每个摄像头,收集15-20个板观测在整个工作空间的体积. 结果转换将作为静态TF框架存储在您的ROS2参数文件中,并用于将观察投影到一个共同的机器人相关坐标框架中,用于政策培训.

通过将机器人的TCP位置 (从前进动力学) 投影到每个相机图像中,验证校准.投影点应在所有工作空间位置上与可见的TCP保持在5像素内.错误>10px通常表明相机安装姿势是错误的 - 再检查安装的刚性,然后回忆出外部数据.

运输管道

T14包在ROS2中提供可插电式压缩的摄像头主题.选择正确的运输减少了录音机的带宽和CPU负载.

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上.
  2. 同步节点: 使用T18来对齐所有摄像头的框架 + T19 + T20. 发布一个自定义的T21消息.
  3. 记录节点: 订阅T22,缓冲器在内存中,并在事件边界上向 HDF5 冲动 (由操作员按键或电话操作停止信号触发).
  4. **压缩 (可选):**如果在高分辨率录音时,在单独的线程中运行H.264编码以避免阻塞录音循环.在10Mbps时,一个30fps的1280x960流每相机使用约75MB/分钟.

对于云存储和数据集管理,使用[RCSV的数据服务]T41) 提供自动上传,减倍和数据集版本.原始录音进一步压缩 (联合数据没有损失,视频损失H.264) 减少长期存储到每日收集约40GB.

存储规划

在开始数据收集活动之前,计算您的存储需求:

** 举例:每部相机设置3摄像头15 Mbps,每部相机收藏8小时的日期:** 3摄像头x15 Mbps x3600s/h x8hr / 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

相机类型的比较

您的选择影响成本,延迟确定性和集成复杂性.

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-50ms,这使得多摄像头录像脱节并降低了政策训练.对于单摄像头或低摄像头速度设置 (<15fps),USB是可接受的.

GigE视觉摄像头 (Basler ace2,FLIR Blackfly S,Allied Vision Alvium) 在硬件触发时提供以太网为止的框架,具有确定性 <1 ms的延迟.Basler ace2 a2A1920-160ucBAS在650美元的价格上提供1920x1200的速度为160fps,足够于30fps机器人录音.GigE摄像头需要具有启用 jumbo框架 (T24) 的专用NIC和PoE开关或注射器.

深度摄像头 (RealSense D435,Azure Kinect) 是用于补充3D场景理解的,但不推作为主要录像摄像头.它们的滚动离子,对象边界的深度噪音,以及光/黑暗表面的难度使它们不适合作为唯一的视觉观测.如果您的政策需要深度输入,则使用它们除了RGB摄像头外.

三种摄像机配置

操作任务受益于不同的摄像头安排.以下是RCSV使用的三个验证配置,按复杂性和数据丰富度排序.

配置1:最小 (1 摄像头,预算设置)

  • 卡马:** 1x 超级USB卡马 (Logitech BRIO,200美元)
  • 位置: 坐落于工作场所90-100厘米以上,直向下面
  • 清晰度:** 1280x720 速度为 30 fps
  • 使用情况: 简单的选择和放置,初始原型制造,单臂桌面任务
  • 限制: 没有高度信息,没有自我中心的视图,政策效率15-25%低于复杂任务的3摄像头设置

您可以在投资多摄像头设置之前验证任务定义.

配置2:标准 (3摄像头,建议)

对于标准操纵数据收集,RCSV使用这种配置,并平衡覆盖,分辨率和存储成本:

  • 相机1 -- 固定上空 (上下): 装在工作空间80-100厘米以上,直向下.分辨率1280x960以30fps. 从上方捕捉整个工作空间,对象放置和抓住器的方法.这是大多数选择和位置政策最有信息的视图.
  • 相机2 -- 固定侧 (侧): 安装在工作空间高度,侧面60-80厘米.分辨率1280x960以30fps.提供高度信息,空视图无法.对堆叠,倒和插入任务至关重要.
  • **相机3 - 手腕 (自我中心):**安装在机器人的终端效应器或工具上,面向前.分辨率为640x480以60fps.更高的镜像速度可以捕捉到快速的手腕运动,而不会模糊.自我中心的视图显著提高了模仿学习研究中的抓住和精细操纵政策性能.

对于使用DK1的双手设置,将相机2的相反侧置置第四个固定相机,以覆盖双臂罩.

配置3:全覆盖 (5+摄像头,高级)

  • 相机1-3: 与配置2相同 (上头,侧,手腕)
  • 相机4 - 另一侧: 镜像相机2在工作场所的另一侧. 消除手/臂遮蔽盲点.
  • 相机5 -- 前面角 (45度): 位于前面60厘米,向下角45度. 捕捉到对象接近和抓住器的方向,而上头错过.
  • 相机6 (可选) -- 深度相机: 智能实力Sense D435 安装在空头位置附近,可提供额外的点云数据.

这种配置每集生成3-5倍的数据,但提供了最完整的视觉覆盖.用于多视图政策学习和3D场景重建的研究.存储需求:每相机的15 Mbps约为500 MB/分钟.

终端延迟预算

对于远程操作,总玻璃到玻璃延迟 (从光子撞到传感器到动机运动) 必须保持在150ms以下,以舒适的人员操作,并低于100ms以精确的操纵.

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

对于使用 [OpenArm 1]T42的舒适远程操作,我们建议使用GigeE摄像头或至少确保每个USB摄像头都在专用USB主机控制器上 (请查看T25).

协同化方法

通过33毫米的相机在30fps的速度间的脱同步,意味着一个相机落后一个完整的框架.

硬件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进行软件同步

通过使用T27的ROS2时间标签将在机器中一致到+/-10 ms.适合15fps录制,但不适用于60fps手腕摄像头.

接近同步的ROS2消息_过器

当硬件触发功能不存在时,使用ROS2 T28包,以按时间标签约同步相机主题:

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)

摄像头校准

校准有两个组成部分:每相机的内在和外在 (相机和机器人基之间的相对姿势).

内在校准标志着每个相机的焦距,主点和扭曲系数.使用OpenCV的校准模块,使用9×7棋盘 (25毫米方形).在不同角度和距离收集20-40张图像.目标重投射错误 <0.5 px (可接受高达1.0 px).运行校准使用: T29.

外观校准确定了从每个摄像头框架到机器人基架的6DOF转换.使用一个安装在几个已知姿势的ChArUco板 (比普通棋牌更好的角落检测).每个摄像头,收集15-20个板观测在整个工作空间的体积. 结果转换将作为静态TF框架存储在您的ROS2参数文件中,并用于将观察投影到一个共同的机器人相关坐标框架中,用于政策培训.

通过将机器人的TCP位置 (从前进动力学) 投影到每个相机图像中,验证校准.投影点应在所有工作空间位置上与可见的TCP保持在5像素内.错误>10px通常表明相机安装姿势是错误的 - 再检查安装的刚性,然后回忆出外部数据.

运输管道

T30包在ROS2中提供可插电式压缩的摄像头主题.选择正确的运输减少了你的录音机带宽和CPU负载.

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上.
  2. 同步节点: 使用T34来对齐所有摄像头的框架 + T35 + T36. 发布一个自定义的T37消息.
  3. 录音节点: 订阅T38,缓冲器存储,并在事件边界上将HDF5调到线 (由操作员按或电话操作停止信号触发).
  4. **压缩 (可选):**如果在高分辨率录音时,在单独的线程中运行H.264编码以避免阻塞录音循环.在10Mbps时,一个30fps的1280x960流每相机使用约75MB/分钟.

对于云存储和数据集管理,使用[RCSV的数据服务]T43) 提供自动上传,减倍和数据集版本.原始录音进一步压缩 (联合数据没有损失,视频损失H.264) 减少长期存储到每日收集约40GB.

存储规划

在开始数据收集活动之前,计算您的存储需求:

** 举例:每部相机设置3摄像头15 Mbps,每部相机收藏8小时的日期:** 3摄像头x15 Mbps x3600s/h x8hr / 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