Zivid SDK 2.18:大规模环境下的稳定性、更快的拍摄速度,以及对开发者的贴心关怀

这段时间以来,Zivid团队一直很忙碌,如今很高兴向大家介绍SDK 2.18。此版本聚焦于正常运行时间、稳定性以及对开发者的关怀——让您能够在现场监控相机状态、降低延迟,并在部署代码前使用虚拟相机进行测试。下面我们来详细看看。

本次发布内容包括:

• 通过相机健康检查,在大规模环境中安全部署
• 通过GPU直接访问,实现更快的拍摄
• 面向Nvidia用户的CUDA安装程序
• 创建您自己的文件相机
• 其他更新

大规模环境下的稳定性:相机健康检查

只要运营过大规模设备的人都知道,真正的难点并不在于搭建单个产线单元,而在于确保分布在场地各处的五十个产线单元都能稳定运行。全新的相机健康检查功能,正是为保障这一点而设计。

相机健康检查在API和Zivid Studio中均可使用,能够从相机读取温度、最大网络速度等指标,从而帮助用户:1)监控已部署相机的老化情况;2)在产线单元出现问题时进行故障诊断。该功能设计轻量,即便在现有监控循环中频繁轮询,对拍摄吞吐量的影响也几乎可以忽略不计。

相机健康检查示例视频

在内部,健康检查会汇总多项独立指标:

• 最大传输速度： 相机与主机电脑之间的端到端链路速度
• 温度： 相机内部温度(摄氏度)
• 风扇： 风扇状态
• 内存： 相机内存是否存在损坏
• 现场校正：距离上次校正是否已超过一年

以上所有检查项会汇总为一个综合状态,该状态反映的是所有单项指标中最差的那一项。因此,只需一眼就能判断某台相机是否需要维护,只需再深入查看一下,就能立即找出原因。

一个具体的例子是数据线缆故障。链路速度突然从10千兆位骤降至100兆位,是线缆损坏的典型征兆,而这正是那种通常需要花费数小时人工排查的间歇性拍摄失败问题。如今,无需等到产线因低速运行才发现线缆损坏,直接在仪表盘上就能一目了然。

通过GPU直接访问,实现更快的拍摄

以往从相机获取点云和RGB数据,必须经过一条影响性能的迂回路径:先将每一帧从GPU复制到CPU,再送回GPU以供自身流水线使用。这种往返过程会增加延迟,进而拖慢节拍时间。

在SDK 2.18中,这条迂回路径可以直接跳过!现在,Zivid的帧数据可以直接在GPU显存中使用——对CUDA而言以device pointer的形式呈现,对OpenCL而言则以cl_mem对象的形式呈现。二维RGB图像和三维点云数据可以直接输入CuPy或PyTorch等框架中的抓取检测或分割模型,无需再经过CPU来回复制数据。

其成果就是更低的延迟。消除这种往返延迟,能够显著缩短端到端拍摄时间,同时释放CPU和PCIe带宽。这对于像拾放或包裹处理这类节拍时间紧张的场景尤为重要。

面向Nvidia用户的CUDA安装程序

虽然并不常见,但偶尔也会有意外之喜。现在同时支持OpenCL和CUDA两种GPU计算后端。CUDA软件包专为Nvidia硬件量身打造,处理流程经过优化,拍摄时间比OpenCL版本更短。如果您使用的是Nvidia GPU,只需选择CUDA安装程序即可——无需修改任何代码,就能获得更佳性能。

GPU计算后端选择界面截图

创建您自己的文件相机

文件相机是一种"虚拟相机",能够像真实相机连接一样回放已拍摄的数据,长期以来一直是Zivid的内部工具。越来越多用户提出了一个理所当然的问题——"我们能不能自己创建?"在SDK 2.18中,这已经成为现实。

文件相机功能现已开放,可通过Zivid Studio和API,基于已保存的数据创建虚拟相机。如今无需连接实体相机,即可运行自动化测试、回归检查和CI流程,开发者之间还可以共享一致的虚拟相机,让所有人基于同一份数据开展工作。对于负责开发和维护代码的团队而言,这意味着可以在提交代码阶段而非客户产线上发现回归问题,并在发布前验证每一项变更。

在Zivid Studio中可上传并查看文件相机。

其他更新

在Studio中调整感兴趣区域,无需重新触发拍摄

现在,在Zivid Studio中调整感兴趣区域(ROI)时,无需重新触发拍摄。只需启用"重新处理"功能并调整ROI即可——无需重新拍摄就能查看哪些点落入框内、哪些点落在框外。框外的所有点都会被设为无效值(NaN)。

ROI实时更新示例

手眼标定的置信度检查

针对手眼标定新增了一项实用的安全保障机制。全新的手眼状态枚举可以判断刚完成的标定结果是否真正可信,并给出以下三种状态之一:

1. OK：标定成功时

2. InsufficientMotion：数据集中运动量不足,导致计算出的解不够明确时

3. InsufficientDataQuality：计算出的解残差过大,表明数据质量偏低时
   

该状态在基于标记点和基于棋盘格的两种标定方式中均会给出反馈。

扩展的条码读取API

我们对条码读取API进行了更灵活的改造,并新增了开发者提出的几项功能需求。主要变化如下:

• 检测与解码现已可分为独立阶段。条码读取可拆分为两个阶段,各自拥有独立的结果类——检测阶段负责在图像中寻找候选区域,解码阶段负责读取这些候选区域。

• 所有条码均提供边界框。所有检测和解码结果现在都会提供以像素为单位的x、y坐标、宽度和高度边界框。借助这一信息,可以在三维空间中确定条码位置,并避免夹爪压在条码上方。

• 支持ITF条码。现已支持ITF交叉二五码(interleaved 2 of 5)线性格式。

Zivid Studio中条码读取示例截图

总结

总而言之,SDK 2.18是一次围绕稳定性、速度以及开发者关怀展开的版本更新。相机健康检查有助于让已部署的系统持续稳定运行,并在问题导致产线停机之前提前发现。GPU直接访问与CUDA安装程序,则让数据能够更快地从相机传输至处理流水线。用户可自行创建的文件相机,让测试、CI流程以及团队协作都变得更加轻松。

希望大家喜欢这次带来的更新内容。我们将继续投入工作,着手准备下一版SDK。