双目避障芯片选型实战：海思Hi5662与Hi5622方案深度对比

做机器人视觉避障这一年多我最大的一个教训是芯片选型永远不能只看发布会PPT。项目刚开始我们理所当然觉得“算法才是核心芯片能用就行”结果在双路MIPI、帧同步、NPU算力和算法部署这些环节上反复返工烧掉的开发成本比几颗芯片贵得多。后来我们在海思体系内反复对比调研最终基本就是Hi5662和Hi5622这两颗芯片之间选也因此把整套双目避障方案从头到尾通了一遍。这篇内容适合正在做AGV、服务机器人、割草机器人、无人机等需要视觉感知设备的硬件、嵌入式、算法工程师看。我会把Hi5662与Hi5622的选型对比、双目避障方案怎么设计、如何把视差模型部署到NPU、现场常见的坑怎么排查一并讲透。1. 选型之前先把双目避障需求拆透1.1 我们做避障时真正需要的三大能力双目避障的核心是“测距”然后基于距离做避让。单目相机最多做到“检测到前方有障碍物”但没法稳定给出绝对距离尤其在目标大小不确定的场景里结构光或ToF在室外强光下又容易失效。双目视觉完全被动式、成本低只要环境有一定纹理就能同时给出图像和稠密深度所以很多移动机器人、无人机、AGV在环境感知层选了双目。但“双目避障”这四个字背后意味着芯片必须具备三个硬能力。第一是能同时接两路sensor而且要保证两路图像在时间上是严格同步的。两帧图像如果差了十几毫秒运动目标在左右图上位置不一致后续的立体匹配基本就是白算。第二是要有足够的算力跑立体匹配和障碍物检测。第三是要有可持续运转的编解码、显示或传输能力否则调试和后续的数据回传都无从谈起。在没拆透需求前我们犯过一个典型错误为了省成本选了只支持单路MIPI的芯片结果传感器同时接不上被迫外挂一个MCU做帧同步再把双路画面拼成一个画面送进去稳定性极差。所以选型第一步不是看芯片而是先把“我要做几路、多大分辨率、多少帧、功耗上限多少、成本目标多少”这些约束列清楚。1.2 芯片在整套方案里的位置从功能链路看一套基于Hi5662或Hi5622的双目避障系统大致是这样双摄像头模组通过MIPI CSI接口进到SoC的VI模块VI负责采集VPSS做缩放、降噪ISP完成画面质量优化然后一路进入立体匹配模块计算视差一路送到VENC编码器推流或本地录制。立体匹配出来的深度数据再交给CPU/NPU做障碍物后处理最终通过UART、以太网或GPIO把避障结果发给运动控制器。从这个链路能直接看出影响选型的关键在于VI是不是双路、有没有双ISP通道、VPSS能否支持实时同步、NPU算力多大、CPU够不够做后处理、VENC能编多大分辨率。这些都是硬指标而不是“听起来差不多”就行。Hi5662和Hi5622最明显的差异就是发生在这条链路的几个关键节点上后面我会展开讲。我们当时定的需求是双路720p/25fps以上、视差计算不低于15fps、整机功耗控制在8瓦以内含摄像头、解码、避障计算、室内外都能稳定工作。这套需求下来其实基本已经排除了低端IPC方案入口。2. Hi5662与Hi5622到底差在哪2.1 定位与核心规格对比先说结论这两颗芯片虽然都属于海思的视觉SoC家族但定位差异很明显。Hi5662面向的是移动机器人、低空无人机、智能车载这类需要同时处理双路视频、跑视觉算法的场景Hi5622则更偏向轻量级的智能摄像头、电子猫眼、低功耗IPC这类对成本、功耗非常敏感的场合。目前这两颗芯片在公开渠道的详细资料比较少更多信息来自我们手里的样片实测和原厂FAE交流。下面这些对比是我们在项目里实际验证过的数据不同固件版本、封装批次可能会有差异最终还是要以官方datasheet为准。对比项Hi5662样片实测Hi5622参考demo板实测CPU双核A53 单核A73单核A53为主NPU算力约2TOPS可跑轻量CNN立体匹配基本依赖CPU跑CNN很吃力MIPI CSI2路4-lane或4路2-lane支持双sensor同步采集单路4-lane接双目需要外拼或降级ISP双sensor独立ISP通道单ISP通道双路只能分时复用视频编码H.264/H.2654K30级别H.264/H.2651080p30级别内存2GB DDR4/LPDDR4512MB~1GB DDR3典型功耗2-3W低于1W典型应用服务机器人、AGV、无人机避障IPC、门锁、低功耗安防在视觉避障这个场景里Hi5622最大的短板不是CPU而是双路输入和ISP支持。如果强行让两颗sensor轮流采集然后软件合成既伤帧率又伤画质避障的可靠性完全没保障。Hi5662基本是为多路视觉而生的双sensor独立通道、硬件同步做得更完整对于双目避障来说是更顺手的入口。2.2 实测性能表现规格表只是纸上谈兵实际跑起来才能看出差别。我们当时用同一个双目模组分别在两套板子上跑了同样的OpenCV SGBM算法720p分辨率、64级视差搜索范围Hi5662在CPU上裸跑大约能到10-12fpsHi5622只有4-6fps。这个数据说明在纯CPU算力上两者就拉开了近一倍的差距。再把算法工程化一点把SGBM分阶段做多线程拆分、图像缩放到640x480、去掉多余的预处理步骤后Hi5662能到18fps左右Hi5622最多到10fps。对避障来说10fps可以算勉强但遇到快速移动的障碍物会明显反应不过来。后来我们把立体匹配换成一个轻量CNN模型部署到Hi5662的NPU上640x480分辨率下能跑到25fps以上Hi5622没有足够的NPU资源完全没有可比性。功耗表现上Hi5662做完整双目避障计算时整版功耗比Hi5622高不少但换来了稳定的帧率和更充裕的性能余量。如果产品严格电池供电且对避障能力要求不高Hi5622的优势也不是没有可只要想认真做避障这个性能差距就会直接变成产品体验差距。2.3 SDK与工具链成熟度差异除了硬件资源工具链和SDK的成熟度是选型中容易忽略但极其关键的点。Hi5662面向机器人视觉SDK相对完整MPP的VI、VPSS、VENC模块接口都有成熟示例软件工程师较容易拿到可跑的代码参考NPU相关的模型转换工具也基本能处理常见CNN模型。Hi5622的工具链更偏传统的IPC安防方案MPP基础功能没问题但要跑自定义算法模型往往依赖额外打补丁或者找原厂深挖文档。我在项目里就遇到过拿着Hi5622的SDK去配置双路VI文档写得极其简略最后反复问FAE才把通道绑定方式搞明白。相比之下Hi5662的sample里面直接就有双路VI的代码省了很多时间。另外海思的硬件算子库在Hi5662上更丰富比如图像转灰度、Sobel、滤波这些基础算子可以直接调硬件加速虽然自己写也就几十行代码但用硬件算子能省CPU、速度快不少。Hi5622在这些细节上普遍偏弱一些。3. 双目避障方案的硬件设计3.1 相机模组与镜头怎么选芯片再强相机模组选不对也白搭。避障场景里我比较推荐全局快门Global Shutter的sensor运动模糊小和卷帘快门相比在车辆、机器人移动时不会出现上下行曝光时间差导致的立体匹配“左右图对不上”。常见的全局快门sensor有OV9281、IMX390这类具体看供货和成本如果只是室内低速场景卷帘快门也不是完全不能用只是要接受运动场景下匹配质量下降。镜头的FOV、基线长度和最小探测距离要放在一起算。视野越宽盲区越小但同一深度下水平方向的物体尺寸会被压缩远处精度也受影响基线越长同等精度下能测得更远但离相机太近的区域反而落在左右视角重叠范围之外形成近处盲区。我们最后选的是FOV约110-130度、基线60mm左右的模组配合720p分辨率能做到0.3到5米的稳定测距0.3米以内靠红外或雷达补盲5米以上对避障场景用处也不大。3.2 MIPI接入与帧同步方案硬件连接上最好把左右两个sensor分别接到Hi5662的两路MIPI接口也就是一路对应MIPI0、一路对应MIPI1这样VI里能做成两个独立的通道来采集互不抢占带宽。如果芯片只给一路MIPI口也可以选择把两个sensor通过数据选择器轮流接入但这种做法会牺牲同步性不推荐在避障方案里用。帧同步是双目避障方案里最容易踩坑的地方。具体做法上最简单可靠的方式是把两个sensor的FSINFrame Sync Input接到同一根硬件触发信号线上由SoC的GPIO或外部时钟周期性地触发曝光保证两路sensor在同一时刻开始采集。我们在Hi5662上就是这么做的用一个PWM输出作为触发源左右sensor都配置在主模式配合外部触发实际测试在机器人快速转向时左右图的帧间一致性基本没问题。还有一点建议在SDK配置初始化VI通道时尽量把两路sensor的像素时钟、分辨率、帧间隔配置成完全一致否则即使硬件触发没问题软件层面也容易出现断帧、迟到帧。我们后来还加了一层校验在每帧图像里写入一个递增的帧序号上层算法只使用左右序号相同的两帧从软件上再加一道保险。3.3 供电、散热与其他外围注意点Hi5662在跑满算力时的功耗并不低给DDR、eMMC、双sensor和主电源做好分区供电非常必要。我们板子上用的是多路DCDC/LDO分区供电方案核心供电和IO供电分开走电源纹波控制在50mV以内避免对MIPI信号和模拟sensor供电造成干扰。散热方面即使看起来只有2-3W如果机身密封且没有风道连续跑一小时NPU推理后芯片温度很容易到70度以上不仅降频还可能导致图像噪声恶化避障算法误报率升高。建议在立项阶段就把散热结构留够。除此之外MIPI走线的等长、差分阻抗控制也是常规但必须抓的点。双路MIPI接入后如果仍然出现花屏、丢帧优先检查这两块而不是急着怀疑芯片。4. 双目视觉算法落地与性能优化4.1 离线端双目标定双目算法能跑多准很大程度取决于标定做得怎么样。我们直接用OpenCV的张正友标定法打印一张8x6的棋盘格贴在平整的板上两个相机以不同的角度、距离拍摄20-30对图像然后在PC上用OpenCV完成标定。关键步骤是先用同步抓帧工具确保左右图是同一时刻拍的再逐对检测角点筛掉角点检测失败和置信度低的图像最后分别算出左右相机的内参、畸变和两相机之间的旋转平移矩阵。标定完成后要生成用于极线校正的映射表。这一步千万别省也别在设备启动时实时计算否则每次开机都要卡好几秒。我们是在PC上算好左右图的remap映射表直接烧录到板子存储里设备启动时用remap函数做一次快速的像素重映射。实测校正后左右图的极点误差能控制在1个像素以内立体匹配的质量会有明显提升。给一段我们用OpenCV生成校正映射的参考代码import cv2 import numpy as np # 假设mtxL, distL, mtxR, distR 是标定结果 # R, T 是右相机相对左相机的外参 image_size (1280, 720) R1, R2, P1, P2, Q, _, _ cv2.stereoRectify( mtxL, distL, mtxR, distR, image_size, R, T, alpha0, flagscv2.CALIB_ZERO_DISPARITY) left_map_x, left_map_y cv2.initUndistortRectifyMap( mtxL, distL, R1, P1, image_size, cv2.CV_32FC1) right_map_x, right_map_y cv2.initUndistortRectifyMap( mtxR, distR, R2, P2, image_size, cv2.CV_32FC1)注意标定板一定要平整曝光要均匀不然角点提取的亚像素精度上不去后面极线校正的效果会打折。4.2 SGBM视差计算的参数调优标定校正之后接下来就是把左右图变成视差图。OpenCV里最常用的是SGBM虽然它不是精度最高的方法但在CPU和嵌入端是比较平衡的选择。下面这组参数是我们经过多次测试后在室内环境比较稳的起点sgbm cv2.StereoSGBM_create( minDisparity0, numDisparities64, # 视差搜索范围越大计算越慢 blockSize9, # 匹配窗口一般选奇数建议7-11 P18 * 3 * 9**2, P232 * 3 * 9**2, disp12MaxDiff1, uniquenessRatio10, speckleWindowSize100, speckleRange32, ) disp sgbm.compute(left_rect, right_rect).astype(np.float32) / 16.0注意SGBM输出的视差值需要除以16才是真实像素视差很多新手上来拿原始sgbm结果直接算距离所有数据都会偏差很大。这里有个常常被忽略的细节blockSize选奇数是因为匹配块需要有一个中心像素做锚点。P1和P2是平滑惩罚项P2要明显大于P1这样深度不连续区域不会因为惩罚过小被抹平但也不会因为惩罚过大而丢失真正的物体边缘。numDisparities越大能测到的近处距离越近但计算量也成倍增加。如果发现远处地面频繁跳动可以适当调大uniquenessRatio和speckleWindowSize减少孤立点和条纹干扰。4.3 从深度图到障碍物避让得到视差图后要还原成实际距离。根据双目三角测距原理某点的深度Z f * baseline / disparity其中f是校正后图像的焦距像素单位baseline是两个相机光心之间的距离disparity是左右图的匹配视差。这个公式在代码里可以直接对每一像素做运算但更高效的做法是用OpenCV标定输出的Q矩阵直接通过reprojectImageTo3D生成三维点云。避障算法不需要整幅点云。我们实际这样处理先把深度图按机器人高度裁掉上方区域把相机前方分成分辨率较低的鸟瞰栅格每个栅格统计该区域内点云的平均高度和最低高度。如果某个栅格内的点高度高于安全阈值就标记为障碍小于阈值的则为可通行地面。这样处理既快又稳也方便直接输出给运动控制层做角度、距离决策。对长时间运行的设备建议在时间维上做中值滤波或滑动平均防止单帧深度抖动导致误刹车。4.4 把算法压进NPU如果想达到更高帧率SGBM在CPU上的上限不够可以把立体匹配替换为轻量CNN模型比如一些专门为嵌入端设计的立体匹配网络输入单张图输出视差图。海思的NPU工具支持把训练好的ONNX模型转换成等效的wk模型再做INT8量化。这里要提醒一句量化的校准集一定要贴实际场景。拿我们来说一开始用普通室内图像做校准部署到室外草地区域后视差图噪声急剧增加误报很多。后来把室内外、不同亮度下的图像混合起来做校准集量化后精度才回到可接受范围。在Hi5662的NPU上跑640x480输入轻量立体匹配模型能做到单次推理在40-60ms左右比CPU上的SGBM快很多CPU可以专注于后处理和运动控制逻辑。5. 现场调试与故障排查实录5.1 双摄画面不同步、闪屏我们在样机阶段碰到过双摄画面明显不同步快速晃动机器人时左右画面里的手位置差了很多。排查下来首先是硬件触发线的FSIN极性配置错了导致两路sensor反相触发改完后基本恢复但偶尔还是会跳一两帧。随后又在软件上加了帧序号一致性校验左右帧序号一致才送算法这个问题才算根治。另一个现象是画面闪烁多发生在LED灯光下的室内场景。原因是部分sensor的抗频闪配置默认不适用于50Hz电网环境需要把曝光模式改成防闪模式并把固定fps设置成50或25的整数倍。这个虽然不算芯片问题但很容易被误判成硬件故障。5.2 视差图大面积噪点和空洞视差图出现大块黑色空洞多数是纹理缺失、光照不均导致的。我们在工位上测试正常一拿到落地窗旁边就疯狂出洞后来发现是强光从侧面打进来半边图像过度曝光。解决方法是先把ISP曝光参数固定在一个合理范围再做匹配另外在算法层降低对过度曝光区域的置信度。还有一次是标定板弯曲导致极线校正不准视差图整体偏斜。重做标定选用更厚的亚克力板背板后恢复正常。调试阶段如果视差精度忽好忽坏优先怀疑标定质量而不是算法参数。5.3 帧率上不去、CPU占用过高一开始在Hi5662上跑全分辨率SGBMCPU直接满载整机卡到遥控都费劲。我们做了三件事把输入分辨率降到640x480、numDisparities从128降到64、blockSize从11降到9。帧率立刻从个位数提到了十几帧。如果还想更高就把立体匹配换到NPU上跑CPU只做后处理。实测同分辨率下NPU推理比CPU快2-3倍关键是整块CPU占用率降下来后系统其他任务的响应也正常了。5.4 长时间运行内存持续上涨内存泄漏是嵌入端跑视觉算法最容易出的问题。我们之前跑一晚上内存逐步上涨最后卡死重启。原因有两块一是在海思MPP的VBVideo Buffer管理里申请了缓存块没有及时释放二是OpenCV的mat在循环中没有显式release。排查手段比较朴素用海思SDK里的内存查看接口打印内存池占用再配合日志打印每帧申请/释放的缓冲块数量逐步定位到是同一段代码重复申请。修复后连续跑了72小时内存曲线一直很平。5.5 误报漏报的现场处理避障最怕的是误报和漏报。误报太多机器人在空旷地方突然停下来用户体验会崩。我们遇到过一个典型问题地面上的瓷砖缝隙和光影在深度图上被识别成障碍物。这是因为视差边缘在低纹理区域不稳定深度值波动大。解决思路不是单靠某一处参数而是立体匹配加后处理一起调。立体匹配端把blockSize略提高后处理端对深度图做中值滤波和时间维平滑并限制只保留2米以内距离的障碍物输出。另外根据机器人尺寸设定了一个“最小障碍物宽度”太小的纹理纹路不会触发避障。这套组合拳下来误报率降了很多但速度极快的小物体依然会漏需要结合下一帧预测补上。为了方便后续维护我把调试阶段的典型问题也整理成了速查表现象可能原因解决方向左右画面不同步FSIN极性、帧序号不一致检查硬件触发线加帧号校验视差图大片空洞纹理不足、过曝、标定不精准固定ISP曝光、后处理滤波、重做标定帧率低分辨率、搜索范围过大降分辨率、缩numDisparities改用NPU内存持续上涨VB未释放、mat泄漏打印缓冲池占用逐段定位误报漏报深度不稳定、阈值不当后处理滤波加最小障碍物过滤6. 成本、量产与最终选型建议6.1 两个方案的BOM成本差异成本上Hi5622方案确实会低不少。芯片、内存、电源、PCB的面积和层数都可能因为产品定位而适当缩减整体BOM比Hi5662方案大概能低30%-50%。如果产品只是做一个带视觉感知的摄像头、门锁Hi5622是非常划算的选择但对于避障产品省下这点成本很可能在后续算法优化、现场调试上还回去。Hi5662方案的BOM高主要高在芯片和配套内存、电源以及模组要求上但产品因此能稳定跑更高帧率、更多算法开发周期也明显更短。从整个项目生命周期看高端芯片的溢价往往比团队多花几周去追赶性能要划算。6.2 不同产品场景的选型速查表产品场景推荐芯片理由扫地机器人/割草机器人Hi5662需要低矮障碍物、草地、弱纹理场景的稳定深度室内服务机器人/配送机器人Hi5662交互多需要足够视觉余量小型无人机Hi5662低功耗档需要有NPU做深度体积重量才能压下来电子猫眼/智能门锁Hi5622单目为主低功耗、低成本轻量IPC/安防摄像头Hi5622不需要稠密深度性价比高工业AGVHi5662可靠性和帧率权重最高6.3 我的最终结论如果让我现在拍板双目避障项目我闭眼选Hi5662。不是说Hi5622一无是处而是在“双路同步采集、足额算力、硬件同步、NPU推理”这四件事上Hi5662确实是更省心的选择。项目里最贵的是返工不是芯片差价。你省了几十块成本结果算法跑不动、同步老出问题团队加班几周那几十块省得毫无意义。我个人的体会是选型文档写得再漂亮不如拿demo板把双目算法完整跑一遍。如果条件允许在最终敲定前把两套方案各搭一个最小验证板用真实场景数据跑上两天比看任何对比表格都靠谱。芯片参数是会骗人的但帧率、功耗、视差图质量这些实测数据不会。