二、硬件平台选型：计算平台与传感器

硬件选型这事儿，我做了快十年了。说实话，每次新项目启动，最头疼的就是这一步。你想想看，一个决策做下去，后面几百万甚至上千万的投入就绑上去了。今天我就把这些年踩过的坑、攒下的经验，跟你好好聊聊。

2.1 计算平台：GPU、FPGA、ASIC 怎么选？

先说说计算平台。很多人一上来就问：「哪个最好？」我的回答是：没有最好，只有最合适。

2.1.1 GPU —— 通用性最强，但功耗是硬伤

GPU 的优势很明显：生态成熟，开发快。我早期做 L4 级 Robotaxi 项目时，用的就是 NVIDIA 的 Drive PX 系列。那时候团队里 Python 工程师多，CUDA 库一调，模型跑得飞快。

但问题也来了。我记得有一次夏天路测，车辆在太阳底下暴晒半小时，GPU 温度直接飙到 85 度。系统为了保护硬件，自动降频了。结果呢？感知延迟从 30ms 跳到了 80ms。嗯，那次差点追尾。

2.1.2 FPGA —— 延迟低，但开发门槛高

FPGA 的好处是确定性延迟。说白了，就是「说一不二」。你用 GPU 跑一个模型，延迟可能 20ms 到 50ms 来回跳。但 FPGA 不一样，它硬件逻辑写死了，延迟就是 10ms，雷打不动。

我个人习惯在传感器预处理阶段用 FPGA。比如摄像头 ISP 处理、激光雷达点云滤波这些。为什么？因为这些算法相对固定，不需要频繁迭代。而且 FPGA 的并行能力，处理多路传感器数据时特别香。

但要注意，FPGA 的 RTL 开发周期长。我见过一个团队，花 6 个月写了一个点云处理模块，结果算法迭代了 3 版，FPGA 代码全得重写。所以我的建议是：算法没稳定之前，别急着上 FPGA。

2.1.3 ASIC —— 效率最高，但灵活性最差

ASIC 是终极方案。功耗低、算力高、成本摊薄后便宜。Mobileye 的 EyeQ 系列就是典型。但 ASIC 有个致命问题：流片一次几千万，改不了。

我参与过一个项目，选了某家国产 ASIC 芯片。结果量产前 3 个月，算法团队发现需要增加一个 Transformer 算子。ASIC 不支持，只能外挂一个 FPGA 做补充。嗯，那叫一个狼狈。

2.2 传感器选型：摄像头、激光雷达、毫米波雷达、超声波

传感器这块，我经常跟团队说一句话：「没有完美的传感器，只有互补的传感器」。每种传感器都有自己的脾气，你得摸透了才行。

2.2.1 摄像头 —— 信息最丰富，但最怕光线

摄像头是自动驾驶的「眼睛」。分辨率高、色彩信息全、能识别交通标志和车道线。但它的弱点也很明显：逆光、黑夜、雨雾天，性能断崖式下跌。

我记得有一次在隧道出口做测试。车辆刚出隧道，阳光直射镜头，画面瞬间过曝。视觉算法直接丢掉了前方 50 米内的所有目标。还好当时有激光雷达兜底，不然就撞上了。

选型时要注意几个参数：

• 分辨率：800 万像素是当前主流，低于 200 万像素的别考虑了
• 动态范围：至少 120dB，否则隧道场景必出问题
• 帧率：30fps 是底线，60fps 更安全

2.2.2 激光雷达 —— 精度之王，但成本高

激光雷达能直接输出 3D 点云，精度毫米级。我做过对比测试：在 100 米外，激光雷达能分辨出 10cm 大小的障碍物，而摄像头只能看到一个模糊的像素块。

但激光雷达也有坑。一是成本，虽然现在降到几千块了，但跟摄像头比还是贵。二是受天气影响大，大雾天激光会散射，点云质量急剧下降。

2.2.3 毫米波雷达 —— 全天候选手，但分辨率低

毫米波雷达最大的优势是「不怕天」。雨雪雾霾，它都能正常工作。而且能直接测速，这是摄像头和激光雷达做不到的。

但它的缺点也很突出：分辨率低。你想想看，一个 77GHz 的毫米波雷达，角度分辨率也就 1-2 度。在 100 米外，它只能告诉你「那里有个东西」，但说不清是行人还是自行车。

所以我的用法是：毫米波雷达做「存在性检测」。比如 AEB（自动紧急制动）功能，毫米波雷达负责快速判断前方是否有障碍物，摄像头负责确认障碍物类型。两者互补，效果最好。

2.2.4 超声波雷达 —— 便宜好用，但只能近距

超声波雷达就是倒车雷达那个东西。成本低、技术成熟，但探测距离只有 3-5 米。我一般只在泊车场景用。

选型时注意两个点：一是盲区，超声波雷达在 20cm 以内是测不准的；二是串扰，多个超声波雷达同时工作时，信号会互相干扰。我见过一个项目，装了 12 个超声波雷达，结果泊车时乱叫。后来加了时分复用方案才解决。

2.3 域控制器与中央计算平台

最后聊聊架构。早期自动驾驶都是「分布式」——每个传感器配一个 ECU。但现在趋势很明显：集中式域控制器。

2.3.1 域控制器：把功能分到「域」里

常见的分法有三种：

• 智驾域：负责感知、规划、控制
• 座舱域：负责 HMI、娱乐系统
• 车身域：负责灯光、门窗、空调

我个人比较推荐「智驾域 + 座舱域」融合的方案。为什么？因为这两个域都需要高性能 SoC，融合后可以共享算力。比如座舱域空闲时，可以把算力借给智驾域做冗余推理。

但要注意，功能安全等级不同。智驾域要求 ASIL-D，座舱域可能只要 ASIL-B。融合后，你得做严格的资源隔离。我见过一个方案，用 Hypervisor 把两个域跑在同一个 SoC 上，但隔离没做好，座舱域死机导致智驾域也挂了。嗯，那叫一个惨。

2.3.2 中央计算平台：终极形态

中央计算平台就是把所有域控制器合并成一个超级计算机。特斯拉的 HW 3.0 就是典型。好处很明显：数据共享零延迟、硬件成本降低、软件升级更方便。

但挑战也大。首先是散热，一个中央计算平台功耗可能到 500W，你得用液冷。其次是冗余，所有功能都集中在一个盒子里，一旦它挂了，整车就瘫痪了。

2.4 小结：选型不是选最好的，是选最合适的

说了这么多，其实就一句话：硬件选型要跟你的算法、成本、量产时间表匹配。别盲目追求高算力，也别为了省钱牺牲安全。

我见过太多团队，选型时拍脑袋，量产时哭鼻子。所以我的习惯是：先做一轮 POC（概念验证），把关键传感器和计算平台搭起来跑一个月。数据说话，比什么都靠谱。

好了，这一章就聊到这儿。下一章我们讲讲软件架构，那又是一个大坑。到时候再跟你细说。