简介：《Velodyne VLP-16 用户手册》面向激光雷达初学者、机器人及自动驾驶开发者与高校研究人员，围绕VLP-16 Puck的安装设置、数据读取和编程应用展开，帮助读者建立从设备认知到点云数据解析的完整参考框架。压缩包内含1个docx文件，大小约12.18MB，正文按安全须知、工作原理、校准反射率与回波模式、安装连接、传感器数据、故障排查、维护及规格、附录等模块编排，目录清晰，便于按主题检索。手册具体说明电源、以太网与GPS连接步骤，并详解数据包格式、时间戳精度、工厂字节和位置数据包解析；附录还覆盖Web服务器GUI、固件更新、Veloview软件与机械图纸，兼顾日常操作和二次开发。已有3691人学习，适合需要排查连接与数据问题、理解点云输出细节，或为基于VLP-16的项目建立维护规范的读者查阅。

1. 每秒 754 个 UDP 包：VLP-16 到底把什么交给主机，又不给什么

接上电，它就开始转。没有配置文件要加载，没有标定文件要下载，也没有一行“开始输出点云”的指令。VLP-16 上电约 5 秒后开始扫描，网口上冒出来的是一串每秒 754 个的 UDP 包——包里装的是距离字节、一个方位角、一个 0-255 的反射率和时间戳，而不是现成的 XYZ 点。这个差异决定了后面所有工作量：主机得自己把球坐标算成笛卡尔坐标，得自己把时间戳拼成 UTC，还得自己在双回波模式下扛住翻倍到 1508 包每秒的数据流。搞懂 VLP-16，关键不在记住接哪根线，而在搞清楚它为什么只肯交出这些原始字节、这些字节里哪些是标定过的、哪些是要你补的。

2. 16 线旋转：360°×30° 视场是怎么被逐帧切出来的

2.1 16 对激光/探测器：垂直视场是固定不变的

VLP-16 的机械方案很朴素：一个紧凑壳体，里面装了 16 对激光/探测器，整个壳体绕垂直轴快速旋转。没有转镜，没有 MEMS 振镜，就是整体转。这个选择带来两个直接后果。水平视场天然是 360°，因为转满一圈就是一圈；垂直视场被 16 个激光器的物理排布固定住，共 30°，不会因为你多等一会儿就变密。

每对激光/探测器以一个固定的俯仰角朝外，16 个角度在 30° 的垂直区间里分布。手册没有把角度表印在数据格式正文里，而是把它和 Laser ID 绑定：你在数据包里读到第几个发射块，就对应第几号激光器，俯仰角查表得到。常见的实现思路是，这 16 个角在 -15° 到 +15° 之间对称、正负交替排布，具体数值以设备随附的标定数据为准。主机端手里必须有一份 Laser ID 到垂直角的映射，而且不是可选项——少了它，z 轴就算不出来。

为什么把垂直角做成设备常数？省带宽。16 条线的俯仰角不随帧变化，不需要每帧传一遍，只需要协议里约定一次。省下来的字节留给距离和反射率。这是 VLP-16 整个数据设计的一个基调：凡是能靠“设备常数 + 位置约定”推出来的，就不放进数据流。

整体旋转还顺带解决了密封问题。手册说壳体做了耐候处理，能挡风雨和其他恶劣天气。如果换成外露转镜，要在旋转部件和静止外壳之间做防风雨密封会麻烦得多。安装底座给了一个 1/4-20 螺纹孔、两个定位销孔，可以任意角度安装；整机按汽车级冲击和振动设计，能承受 500 m/sec² 幅值、11 ms 持续时间的冲击，以及 5 Hz 到 2000 Hz、3G rms 的振动，所以固定在车上时不需要额外做减震。

2.2 转速 5-20 Hz：水平方向的取舍

水平方向不一样，它是变量。壳体转速可以在每秒 5 转到 20 转之间调整。这个区间覆盖了一整段取舍：转得越快，同样一圈里落下的发射次数越少，每帧点越稀；转得越慢，点越密，但相邻两帧的时间间隔越大，对运动平台越不友好。选转速本质是在“帧率”和“单帧密度”之间划线，没有哪个值普适。

一圈 360° 构成一个扫描帧，帧的边界就是方位角回绕。转速直接决定每秒多少帧，发射频率除以转速大致决定单圈的点数。车载建图一般偏好转得快一点，宁可单帧稀一些，也要让相邻帧的间隔小、配准容易；静态扫描或者对细节要求高的场景则反过来，把转速降下来换密度。

方位角也不是每次发射都报。手册写得很明确：水平角在每隔一次发射序列的开头报出。这又是一个省带宽的取舍——相邻两次发射之间壳体转过的角度很小，协议上默认接收端可以按发射间隔把中间的角度插出来。如果解析代码把“每个发射块都带自己的方位角”当前提，轻则错位，重则角度系统性偏移。这类错误有个共同特征：点云看着是连续的，能出图，但整幅点云会轻微地“拧”一下，很难一眼看出来，等发现时往往已经调了半天别的参数。

2.3 用位置编码 Laser ID：为什么协议里没有“我是几号”字段

一个自然的追问是：既然 Laser ID 这么关键，为什么不在包里用一个字节明写“我是第几号激光器”？答案还是带宽和确定性。数据包是定长布局，每个发射块在包里的偏移固定，第 n 个块就是第 n 号激光器。接收端按固定步长切包，Laser ID 就是切出来的下标，不用读字段，不用判断。这种“用位置编码身份”的做法在实时数据流里很常见：解析退化成纯偏移计算，没有分支，嵌入式端和主机端都跑得快。

从工程视角看，这也解释了手册为什么花那么大篇幅讲包结构和附录 A。对 VLP-16 来说，协议本身就是 API。包结构对了，剩下的全是数学。而且这个设计把“设备常数”压到了极致：垂直角是常数，Laser ID 是位置，方位角是半速率上报，接收端要做的是补插值和查表，而不是解码一堆描述性字段。代价是包结构一旦理解错，错误会以“整体偏移”的形式出现，而不是某个字段读错那么容易被发现。

3. 反射率与回波模式：256 级数值和双回波背后的物理与取舍

3.1 0-100 与 101-255：反射率为什么分成两段而不是一条直线

反射率是 VLP-16 输出里最容易被当成“附带信息”的一项，但它经过了一套明确的标定。手册说，传感器以 256 级分辨率测量目标反射率，这个值不随激光功率和距离变化，覆盖 1 米到 100 米。绝对标定用的是市售的反射率标准和回反射器，标定结果存进设备 FPGA 里的标定表。

关键在分段。0 到 100 对应漫反射体 0% 到 100% 的反射率；101 到 255 留给回反射器，255 是理想回反射器，101 到 254 是部分遮挡或不完美的回反射器。这不是随手划的阈值，而是两类目标在物理上就不一样：漫反射体把光散向各个方向，回反射器把光原路送回。用同一段线性刻度去覆盖它们，要么把回反射器顶到饱和，要么把漫反射体压到最低几位分辨不出来。分段等于用“数值区间”同时编码了“反射类型”和“反射强度”。

实际用起来，这个分段有很直接的后果。如果你拿反射率做地物分类，先要看值落在哪一段——落在 101 以上的点，大概率是交通标志、反光背心、车牌这类回反射器，不能和普通路面放在同一个线性尺度上比较。我一般会把它拆成两个通道看：漫反射通道用 0-100 的线性值，回反射通道用 101-255 单独标记，两套阈值分开调，比混在一起硬拟合稳得多。

3.2 标定表为什么放进 FPGA，而且与距离、功率无关

“与激光功率和距离无关”这句话值得停一下。激光打到目标上的回波强度，物理上同时取决于目标反射率、距离、入射角、大气衰减和设备自身的激光功率。如果直接报回波强度，那是一个被距离和功率调制过的量，主机端要反推反射率，得先知道距离、再做距离补偿，还得知道当前激光功率。VLP-16 的做法是在设备内部先把这些因素归一化掉，只把“标定后的反射率”交出来。

把标定表放在 FPGA 里，而不是让主机加载一个标定文件，是一个有确定性的选择。主机端零初始化——插上网线就能拿到已经标定好的反射率，不用先找文件、对版本、算补偿。FPGA 又离探测器足够近，可以在数据出包之前完成归一化，不占用主机 CPU。代价是标定表被固化在设备里，主机端无法自查它用的是哪版标定，只能信任设备。这个取舍在车载和户外场景里是合理的：少一个配置项，就少一类现场故障。

要注意的是“1 米到 100 米”这个范围。手册里有一句：距离小于 1 米的点应当被忽略。所以反射率的标定区间和有效测距区间是绑在一起的，拿 1 米以内的回波去做反射率分析没有意义，数据本身就不该在那。100 米是标称的有用距离，实际能到多远取决于目标反射率和应用场景，别把 100 米当成硬保证。

3.3 双回波：大于 1 米才能分开两个目标

激光有光束发散，一次发射打出去，光斑往往同时罩住多个物体，于是产生多个回波。VLP-16 分析这些回波后，可以报最强回波、最后回波，或者两者都报。这里有个硬约束：只有当两个物体之间的距离大于 1 米时，传感器才会记录两个回波。光斑在近处小、远处大，1 米这个阈值本质上是在“光斑在时间上把两个回波分得开”和“不要把同一个目标拆成两个”之间取的平衡。

三种模式对应三种用法。最强回波适合大多数建图和感知任务，它给出回波能量最大的那个面；最后回波适合看“最远的那个面”，比如穿过稀疏遮挡看后面的墙；双回波则把两个都留下。手册给的例子很典型：光束大部分打在近墙上，小部分打到远墙，只有两墙间距大于 1 米才会记录两个回波。如果最强回波恰好就是最后回波，传感器报的是第二强的回波——这条规则是为了保证“最后回波”这个位置上始终有一个可用的测量，而不是因为最强和最后重合就交白卷。

3.4 双回波让数据率翻倍，这是个要用户自己承担的取舍

手册里的数据率表很直白：最强回波和最后回波都是每秒 754 个包、约 8 Mb/s；双回波是每秒 1508 个包、约 16 Mb/s。也就是说，开双回波不是“多一点点信息”，是把数据率直接翻倍。这个翻倍要由网卡、主机解析和下游存储一起承担，任何一环处理不过来都会丢包，而丢包在点云里表现为“某些角度整段缺失”，很容易被误判成传感器故障。

回波模式是在 web 服务器界面里选的，不在数据包里动态切换。这个设计也有它的道理：模式是会话级的配置，切换意味着数据率变化，放在数据流里逐包标记反而增加解析复杂度。林业是双回波的典型场景——激光打到树冠外层、穿进枝叶、最后打到地面，双回波能同时拿到冠层高度和地面高程，单回波做不到。但反过来说，如果应用只是做室内建图，开双回波除了翻倍带宽没有收益，这时候老老实实选最强回波更稳。

4. 时间与坐标：PPS、$GPRMC 和从 (r,ω,α) 到 XYZ 的那一步

4.1 外部同步只认两个信号：PPS 和 $GPRMC

VLP-16 可以把每个激光点的发射时刻同步到 GPS 时间，前提是外部给两个信号：一个是每秒一次的同步脉冲 PPS，0-5V、上升沿；另一个是每秒一条 NMEA 标准的 $GPRMC 语句。手册说得很硬：GPS 的其他输出消息一律不接受，只认 $GPRMC。

这个“挑食”是有原因的。PPS 提供秒边界，精度在微秒级，但它本身不带“现在是几点”；$GPRMC 带时间，但语句到达有延迟和抖动。两者配合，用 PPS 的边沿对齐秒，用 $GPRMC 里的时分秒填充“这是哪一秒”，才能得到既准又绝对的时间。只认一种语句，是为了让解析逻辑足够简单、足够确定——多支持几种 NMEA 语句，就多几种格式变体和出错可能。

接线上有两条路。要么自己准备 GPS 接收器，把信号接到接口盒内部的螺钉端子，用之前要拧开盒盖、看清丝印；要么用预编程好的接收器，带连接器直接插进接口盒，它已经按 VLP-16 要的格式输出 $GPRMC 和 PPS。前者省钱但要自己配语句和电平，后者省事但选择少，看项目更在乎哪一头。

4.2 没有 GPS 时，时间戳从上电开始数

不接 GPS 的时候，传感器照样出数据，时间戳从一个本地起点开始累计。这个起点是上电时刻，不是绝对时间。所以如果你的系统里有多个传感器、或者要把点云和别的传感器做时间对齐，没有 GPS 同步的时间戳只能保证“同一设备内相对可比”，跨设备就对不上。

$GPRMC 里的时间字段是 UTC 的时分秒，格式 hhmmss 或 hhmmss.s。传感器读的是分钟和秒，然后把自己的时间设成“每小时过去多少微秒”。注意这里没有日期，也没有小时以外的绝对时间——同步的粒度是“小时内的微秒偏移”。这对点云配准够用，因为同一小时内的时间戳是连续可比的；跨小时的拼接要靠上层自己处理。

手册把时间戳精度单列了一节，说明这件事在系统集成里是个正经问题。我的经验是：只要涉及多传感器融合，PPS 和 $GPRMC 就要在布线阶段一起规划，别等到数据对不上再回头补。上电 5 秒后才开始出数据这件事也要在时间对齐逻辑里考虑到，别把启动阶段当成设备没反应。

4.3 从 (r,ω,α) 到 XYZ：垂直角那一步不能省

本文还有配套的精品资源，点击获取