BEV 环视（Bird's Eye View）在方案评审里经常被一句话概括："装四颗鱼眼，拼一张俯视图。"真正进入整机集成阶段，才会遇到一连串具体问题：车体正下方为什么是盲区、重叠区留多宽才够、四路视频走什么线、拼接放在哪里算。这些问题的共同根源，是把环视当成一次相机采购，而不是一条从机位到算力的链路。
本文按工程实施顺序拆解 BEV 环视的硬件搭建：先明确它在什么场景下不可替代，再逐项讨论机位设计、视场重叠、传输链路、同步方式与算力带宽，最后给出一份可对照的选型与验证清单。全文面向嵌入式与机器人工程师，不涉及具体型号与厂商参数，所有数值均需以整机实测为准。
一、先界定场景：环视解决的是"厘米级"问题
环视的价值集中在低速、近距离、需要贴边通行的场合，典型包括 AMR 在窄巷道内会车、AGV 沿货架边缘通道行驶、叉车进出托盘位、清洁与服务机器人进入家具底部。
这些场景的共性是：障碍距离小、姿态约束强、失败代价高。远距离测距方案在这类场景下作用有限，因为它们看不到紧贴车体的那一圈。环视的定位不是替代远距离感知，而是补齐"身体周围"这段盲区。
因此需求要先写清楚：需要感知哪几个方向、离车体多近、允许多大的拼接误差、在什么速度下工作。这些指标会直接决定相机路数、分辨率、帧率与同步精度要求。
二、机位设计：高度与俯角决定可视范围
机位是环视设计的第一颗扣子。常见做法是四路相机分别装在车体的前、后、左、右，每颗的水平视场覆盖 180° 以上，相邻两颗的画面互相压住形成重叠区。
机位设计要同时满足三个条件：
- 看得见：安装高度决定画面里地面的可视距离，俯角决定地面与近处车身的比例；
- 挡不住：相机不能被裙边、护角、云台、举升机构遮挡，也不能让自身结构进入画面；
- 够得着：走线路径、安装面刚度、拆装空间必须在结构设计阶段就预留。
高度与俯角是一对矛盾。装得高，地面可视范围大，但车体正下方的盲区随之扩大；装得低，近处更清楚，但视场容易被自身结构切掉。工程做法通常是在整机三维模型里先摆一遍机位，把四颗相机的视场锥投到地面，检查覆盖与盲区，再回到结构侧确认安装点。
三、视场重叠：覆盖不等于可用
四颗 180° 以上的相机围一圈，几何上已经覆盖 360°，但"覆盖"和"可用"是两件事。鱼眼画面的畸变随视场角增大而加剧，越靠边缘，单位像素对应的空间角度越大、有效分辨率越低。重叠区里真正能用于对齐的，往往只是靠近画面中心的那一部分。
所以重叠区不能按"刚好接上"来留，而要留出足够冗余，让拼接环节有足够的像素做对齐与融合。重叠不足的典型表现是接缝错位、物体在接缝处被拉断或出现重影。
另外，环视是俯视视角，地面的成像质量与墙面、立体的成像质量差异很大。评估重叠时要按最不利的观察目标来算，而不是只看地面。
重叠区还牵扯到外参标定。四颗相机的相对位姿必须通过标定确定，拼接才能把四张画面投到同一个俯视平面上。标定通常在两种路线之间选择：一是铺设标定布或使用标定板，一次性获得较高的对齐精度；二是利用地面纹理等自然特征做在线自标定，便于现场维护。无论哪种路线，安装公差都会直接影响标定结果------相机装偏一点，标定就要多花时间，甚至无法收敛。因此在结构设计阶段就要明确安装定位方式与公差要求，而不是等装完再补救。
四、传输链路：GMSL 与千兆以太网的取舍
四路相机同时出图，线束是第一个现实约束。两条主流路线各有明确取舍。
| 维度 | 车载串行链路（GMSL 类） | 千兆以太网 |
|---|---|---|
| 线缆 | 同轴或屏蔽双绞线，一线多能 | 通用网线，便宜易得 |
| 供电 | 可同缆供电（PoC），省一路电源线 | 通常需单独供电或走 PoE |
| 触发与控制 | 可随链路下发，布线简洁 | 需额外触发线或走网络报文 |
| 带宽 | 固定链路带宽，路数与分辨率受通道数约束 | 共享带宽，多路满帧时需核算总量 |
| 拓扑 | 点对点为主，需解串与汇聚 | 交换机组网，拓扑灵活、可扩展 |
| 工程代价 | 需要配套解串板与芯片方案 | 需处理交换机延迟与拥塞 |
| 适用倾向 | 线束重量敏感、模块化程度高的整机 | 路数多、拓扑分散、复用现有网络的整机 |
选型时容易被忽略的是线束重量与固定方式。移动机器人是运动平台，线束要跟着振动和转弯，固定点间距、弯折半径、连接器锁止方式都会影响长期可靠性。链路确定之后，走线方案要和结构同步出图。
五、同步：环视最要命的一环
四颗相机不在同一时刻曝光，而车体一直在动，拼出来的图必然错位。同步问题在静止标定时看不出来，只有动起来才会暴露。
常见两条路径：
其一，硬件触发。 由主控或专用同步盒发出同一个脉冲，四颗相机同时曝光。优点是时序干净、抖动小；代价是多一路触发线，且要求所有相机都支持外部触发输入。
其二，时间戳对齐。 每帧图像附带精确时间戳，算法侧按时间对齐后再拼接。优点是布线简单；代价是对时钟同步精度、时间戳精度和运动补偿能力要求更高。
即便曝光同步，还有一层运动差异：四颗相机装在车体不同位置，转向时各自的线速度不同，画面之间存在视差。低速小转向时可以忽略，速度提高或转弯半径变小时，就必须引入运动补偿，否则接缝处会出现撕裂。
与整机的时间基准对齐同样重要。如果环视的曝光节奏和导航、里程计、其他传感器各自为政，后续融合会因为时间基准不一致而引入额外误差。
还有两个细节值得在选型阶段确认。其一是触发抖动 ：同步信号从发出到四颗相机真正开始曝光之间存在延迟，若各路延迟不一致，就会出现"名义同步、实际错拍"。其二是曝光时间与动态范围：仓库里常有灯带、窗口强光与背光区域，曝光时间越长，运动带来的模糊越明显，需要在曝光策略上做取舍。
六、算力与带宽：先算账，再选路
拼接放在哪里做，是典型的架构选择题。
| 方案 | 优势 | 代价 | 适用 |
|---|---|---|---|
| 机器人主 SoC 承担 | 省一颗芯片，数据不过网络 | 与导航感知抢资源，调度需重排 | 算力有余量、路数不多的整机 |
| 独立边缘计算盒子 | 边界清晰、便于替换与验证 | 增加成本、功耗与一路通信 | 模块化产品、多路高分辨率场景 |
带宽要按最坏情况倒推：分辨率 × 帧率 × 路数 × 每像素位宽，得到的是原始数据量，再乘以链路开销才是真实占用。直觉上的"四路视频"往往比预算大得多，而带宽一旦不够，表现是掉帧、延迟抖动，而不是干脆黑屏。
算力同理。拼接本身包含去畸变、投影、对齐、融合几步，每一步都有计算量；分辨率越高、路数越多，前端预处理的价值就越大。
七、选型与整机验证清单
| 检查项 | 要确认的内容 | 验证方式 |
|---|---|---|
| 场景定义 | 需要感知的方向、最近距离、工作速度 | 需求评审 |
| 机位 | 高度、俯角、自身遮挡、安装面刚度 | 三维模型视场投图 |
| 视场重叠 | 重叠区宽度是否够对齐与融合 | 实拍画面重叠检查 |
| 链路 | 带宽总量、线束重量、固定与弯折半径 | 预算核算 + 走线评审 |
| 同步 | 触发方式、触发抖动、时间基准 | 动态场景实拍验证 |
| 运动差异 | 转弯时视差是否需要补偿 | 极限转弯工况测试 |
| 算力 | 拼接耗时、资源占用、最坏情况余量 | 满帧压力测试 |
| 环境 | 振动、温度、防护与清洁方式 | 整机环境试验 |
还有两项系统级检查容易被遗漏。第一是多路叠加 ：多颗相机同时工作时的供电与散热要按最坏情况留余量。第二是维护性：镜头一旦被灰尘或油污遮挡，环视画面会出现局部盲区，设计阶段就要考虑清洁与更换的可行性。
八、小结
BEV 环视的硬件搭建是一道从机位算到算力的链路题。先用场景定义约束，再用机位和视场把"无盲区"落成可验证的画面；链路决定线束与供电形态，同步决定动态场景下是否可用，算力与带宽决定能不能稳定跑起来。
它不靠某一颗高性能相机解决，而靠每一环都留出余量。真正决定成败的，是在设计早期就把最坏情况算进去。
【备选标题】
- BEV环视硬件搭建全解析：机位、视场、链路与同步
- 四颗鱼眼怎么拼出360度？环视硬件的五个关键环节
- 机位差一点，环视就错一片：BEV环视硬件设计要点