实景采集系统的一些术语

疯狂理查德

于 2024-05-16 10:33:53 发布

阅读量584

点赞数 21

文章标签：车载系统

本文链接：https://blog.csdn.net/u013490997/article/details/138950956

版权

典型应用：

道路基础设施测绘
路面测量
用于自动驾驶汽车的高精度测图
城市建模
建筑工地和散装物料快速测绘
露天矿测量
GIS测图和资产管理
竣工测量

- 高精度地图采集系统

- rtk

rtk全称是(Real Time Kinematic)，实时动态测量。RTK定位技术是基于载波相位观测值的实时动态定位技术，它能够实时地提供测站点在指定坐标系中的三维定位结果，并达到厘米级精度。

在RTK作业模式下，基准站通过数据链将其观测值和测站坐标信息一起传送给流动站。流动站不仅通过数据链接收来自基准站的数据，还要采集GPS观测数据，并在系统内组成差分观测值进行实时处理。流动站可处于静止状态，也可处于运动状态。RTK技术的关键在于数据处理技术和数据传输技术。

- 组合导航系统单天线和双天线的区别

单天线和双天线系统最大的性能差异在于航向角精度。

原理

这是因为两种系统对于航向角的计算原理从根本上是不同的。
组合导航系统的航向角估算主要是通过GNSS模块，而我们知道GNSS模块的直接输出是定位。

因此，单天线系统只有一个天线（一个点）的位置信息，而一个点是没有方向性的。所以，单天线系统必须通过天线的移动，才能通过移动轨迹计算出航向。

而对于双天线系统，由于有两个点的位置信息，通过两点连成的直线很方便地就可以确认方向。不需要系统有任何的运动，在静止状态下也可以获得准确的航向角。

从原理上你已经可以判断出，单天线系统在低速或者静止状态下，对于航向角的精确判断是有难度的。这在接下来的实测数据中也有明确的展示。

- 时钟同步

- 高级智能网联系统的时间同步原理解析

对于整个自动驾驶系统的时钟同步来说，因为各个传感器时钟源都有钟漂，而且每个时钟源钟漂不同，所以即使把各个传感器时间戳在初始时刻对齐，运行一段时间之后，之前对齐的结果仍会偏离。因此，为了统一各个传感器或芯片的时钟，需进行时间同步。同步过程需要设置相应的同步时钟源。当前，常见的时间同步主要有以下几种方式：

以上同步源中，大家可能对GNSS的定位功能比较熟悉，其实它的授时功能是和定位同等重要的功能，在自动驾驶的传感器配置里，GNSS是一个必备的传感器，它自带秒脉冲发生器，所以可以直接使用。而且GNSS信号能够达到定位要求时，自身时钟也会受到卫星上原子钟的校正，从而进一步提高精度。

其余时钟同步原理我们将在如下章节中进行详细介绍。

域控与传感器时间同步

在当前分布式架构中，通常的时间同步信号式通过CAN/CANFD进行传输，而下一代自动驾驶系统则基本采用以太网进行信号传递。对于融合需要的信息，需要在报文中打上相关的时间戳来进行匹配，时间戳应尽量接近目标被探测到对的实际时刻。

实例：以最通用分布式架构5R1V1D为例说明各个传感器在时间同步上的原理。

方案一：由其中一个传感器融合另外一个传感器数据，将接收时间点在对应位置打上时间戳，然后整体发给域控制器。域控制器在接收到相应的融合目标后，在对应接收点上打上时间戳。

临时时间同步方案：

Tcan：表示通过can总线发送信息到摄像头的时间间隔；

t1：摄像头在本地时间接收到的时间点信息；

T1：摄像头的发送时间-接收测量时间；

t_v：摄像头本地时间测量点；

t_r：雷达本地时间测量点；

t_vs：摄像头发送时间点为融合目标本地时间；

T_abs：最后由传感器发送到域控制器的时间差值；

方案二：基于域控制器底层基础软件Autosar的时间同步解决方案。AUTOSAR 解决方案，ADS 中的时间Master，每个传感器中的时间Slave。带有时间主控的 ECU 将在一个公共时基内同步所有其他从属 ECU。传感器将发送时间戳以告知“何时测量目标对象”。由于所有 ECU 在公共时基通信，域控制器会直接将所有传感器数据置于公共时间坐标中，然后重新计算到其本地时间供其使用。

T_global_V：公共时基中的摄像头测量时间点；

T_global_R: 公共时基中的雷达测量时间点；

Tmeasure: 公共时基中的环境目标测量时间点；

基础GNSS+PPS的组合时间同步原理

本节主要讲解基于组合惯导接收GNSS的授时和PPS时间同步的原理。由于激光雷达通常使用PPS进行同步，高精定位普遍预留PPS。在开发阶段的数据采集中，可考虑使用此方法与域控同步。

1、GNSS授时

一般地，卫星（GPS/北斗…）中会有精准的时间信息（一般为UTC时间）。高精定位系统通过接受多颗卫星的信号，可以获取精准的UTC时间，此过程一般与定位过程一起进行（可能需要时间信息来提高定位精度）。此方式的另外一个可能应用是卫星向数采设备授时。

2、PPS时间同步

在GNSS完成授时的同时需要通过GPIO将相应的PPS信号从组合惯导系统ECU发送给中央域控制器HPC，两者进行过程会存在一定的时间差。如上图所示，ECU过CAN/ETH发送当下的UTC时刻给HPC，随即ECU通过GPIO发送PPS给HPC，每次脉冲上升沿为当前秒数开始时间。随后，HPC用PPS信号对UTC时间进行修正，从PPS精度获知能达到10ns。

NEMA中包含有时间信息，一般是秒级别，也有部分带有毫秒
1PPS即每秒输出一个脉冲，图中以高电平触发为例（没画下降沿），接收及处理1PPS脉冲的时间也在ns级别
因为NEMA是通过串口发送和接收，而且一次NEMA数据量也有KB级别大小，处理时间远比1PPS时间长
通过NEMA中的秒级时间和1PPS脉冲相配合，即可实现高精度时间同步（ns级：依据1PPS的响应时间）

基于NTP和PTP的时间同步

NTP即Network Time Protocol，网络时间协议。是通过时钟同步服务器从GPS卫星上获取标准的时间信号，将这些信号通过各种接口传输给自动化系统中需要时间信息的设备（计算机、保护装置、故障录波器、事件顺序记录装置、安全自动装置、远动RTU），这样就可以达到整个系统的时间同步。NTP常用于Windows操作系统的时间同步，在局域网中精度在10ms左右。可用于精度要求不高的数采设备同步（供应商方案）。

PTP 是一种高精度时间同步协议,可以到达亚微秒级精度,有资料说可达到30纳秒左右的偏差精度,但需要网络的节点（交换机）支持PTP协议，才能实现纳秒量级的同步。一般在实际使用中，现有的NTP可以达到5ms以内的精度，对一般的应用都是满足的；对于超高精度设备，可以使用PTP设备提高同步精度。

与NTP主要区别：PTP是在硬件级实现的，NTP是在应用层级别实现的。PTP 是主从同步系统，一般采用硬件时间戳，并配合一些对NTP更高精度的延时测量算法。

NTP时间同步过程如下：

Step1：t1时刻Master（Router A）发送NTP报文，该报文数据在t2时刻被Slave（Router B）收到；

Step2：随后，Router B在t3时刻返回NTP报文，并加入t2/t3值。

Step3：Router A在t4时刻收到并记录t4时刻值。

Step4：Router B可计算传输延时△t=[(t2－t1)＋(t4－t3)]/2（默认往返延时相同）。

Step5：同时Router B可校准时钟偏差offset=t4-t3- △t

PTP时间同步过程如下：

Step1：t1时刻Master（Router A）发送同步报文信号Sync，该报文数据在t2时刻被Slave（Router B）收到；

Step2：几乎同时，Router A发送跟随报文FUP，将时刻t1时间值告知Router B。

Step3：随后，Router B在t3时刻发送DelayReq报文，该报文数据在t4时刻被Router B收到。

Step4：几乎同时，Router A随后发送DelayResp报文，将时刻t4时间值告知Router B。

从钟根据 t1 、 t2 、 t3 、 t4 计算时间偏移 (offset) 以及传输延时 ( delay) ,即 t2 -t1 = offset + delay t4 - t3 = delay - offset 计算出 delay = ( t4 - t3 + t2 - t1) / 2 offset = ( t2 - t1 - t4 + t3) / 2 ，从中根据 offset 从钟可以调整自己的时钟。

基于Autosar的时间同步

在Autosar的软件架构中进行同步的过程需要理清两个比较重要的术语。其一是时间主站Time Master是一个实体，它是某个时基的主站，并将该时基传播到通信网络某个段内的一组时基，作为该时基的源。如果时间主站也是全局基准时间的所有者，所有其他时基都来自该时基，那么它就是全局时间主站。时间网关通常由一个连接到一个或多个时间从站的时间主站端口组成。当将时间实体映射到真实的 ECU 时，必须注意，一个 ECU 可以是一个时基的时间主站（甚至全局时间主站）和另一个时基的时间从站。

总体来说，AUTOSAR完全通过CAN/ETH通讯进行，假设在Autsosar软件架构下通信的两个终端ECU分别为两大不同域端控制器，其一是自动驾驶域控制器HPC，其二是车身区域控制器PDC，假设由自动驾驶域控制器HPC接收世界时钟，并对PDC进行时间同步。

其中进行时间同步的原理需要满足如下过程：

Step1：HPC在t0时刻HPC接收发送当下的UTC时间，并于t1时刻发送给PDC，PDC于t2时刻收到该时间戳信息；

Step2：然后HPC计算跟随时间戳信息FUP并发送Δt=t1-t0给PDC；

Step3：PDC于t3时刻收到该时间戳信息，并计算两次报文的时间差Δt’=t3-t2；

Step4：PDC在时间戳t3时刻通过计算当下的时间=(t3-t2)+t1，随机每隔一段时间进行一次同步；

如上简单描述了整个Autosar简单的同步过程，后续文章将单独针对这一块进行详细的过程说明。

域控内部芯片时间同步

域控内部芯片的时间同步通常是将域控区分成各种不同功能的模块进行，比如针对SOC来说，主要是负责进行相应的图像智能识别和处理，其中包含深度神经网络。这里我们举出一种简单的例子进行说明。

假设我们在下一代自动驾驶系统中，设计成了相应的行泊一体控制器。其中包含智能行车处理芯片单元，这里假设我们采用英伟达已经量产的较大算力Xavier来进行深度神经网络处理，采用英飞凌MCU芯片TC397来进行逻辑算力的计算，而对于泊车模块可采用德州仪器的TDA4来进行相应的泊车信息处理。

如上如表示了目前在研的高阶自动驾驶系统的域控传输信息同步过程内部架构，其中主要包含摄像头、毫米波雷达、激光雷达、高精地图、超声波雷达几类。各个传感器在对目标检测和发送过程中存在时间延迟，到达域控制器芯片的传感器信号需要在芯片上进行时间同步。

其中参照如上图中的基本连接方式，目标信息及车辆动信息通过CAN或LVDS传入域控，最终智能行车目标信息会在SOC（Xavier）中进行目标前融合，智能泊车信息会在SOC（TDA4）中进行前融合，而最终所有传感器信息则会在MCU（TC397）中进行目标后融合。同时，在轨迹规划中也会在收到最终的融合数据时，根据不同的目标大融合信息进行轨迹规划和预测。因此，对于域控制器来说，需要在终端芯片上分别进行时间同步。同步过程如下：

Step1：在t1时刻传感器探测到目标。其中，摄像头是指该帧曝光的时刻，而雷达是指接收到回波的时刻；

Step2：在t2时刻各传感器发出检测到的目标信息；

Step3：在t3时刻各内部芯片接收到传感器发出的检测信息，然后在t3-t4时间段内，智能行车和智能泊车芯片将各自进行信息前融合；

Step4：在t4时刻智能行车和智能泊车芯片SOC发出相应的前融合信息给MCU芯片进行后融合和轨迹规划；

Step5：在t5时刻，MCU将最终收到智能行车芯片（Xavier）和智能泊车芯片（TDA4）发出的前融合信息。然后在t5-t6时间段内，MCU将根据接收到的环境传感信息进行轨迹规划和行为预测；

Step6：在t6时刻，MCU将最终预测的轨迹和规划的决策控制指令发送给执行器进行控制执行。

- 自动驾驶中的时间同步方案

本文重点讨论自动驾驶中使用比较多的gps+pps+gpsd+chrony+ptpd+gptpd的时间同步方案，本文仅为自己在调试过程中的记录，如有不对地方欢迎讨论：853906167@qq.com

详细方案如下：Tbox端(IMX8系列)的ubxclient接收来自gps(如ublox系列)的GPS时间和PPS信号，Tbox端将接收到gps的NEMA/UBX消息通过udp转发给gpsd,然后chrony在结合gpsd的时间信息还有linux下的pps信息做时间同步和修正，后续Tbox作为server端通过ptpd给自动驾驶算力芯片(如nvida orin/xavier)做时间同步，然后自动驾驶算力芯片在通过gptpd给mcu/lidar等做时间同步，详细的框图如下：

1.PPS信号处理

配置ublox芯片PPS信号输出频率1HZ,实测tbox端pps_in输入信号：

从测试结果来看17次的脉冲信号周期为7.441s+9.564=17.005s,周期精度小于0.001s,精度比较高

linux 打开pps配置：

CONFIG_PPS=y
CONFIG_PPS_DEBUG=n
CONFIG_PPS_CLIENT_KTIMER=n
CONFIG_PPS_CLIENT_LDISC=n
CONFIG_PPS_CLIENT_GPIO=y

note:如果ktimer/ldisc打开注意设备节点可能不一样，kernel log中可以看到具体对应的设备节点，我们这边ktimer/ldisc都没打开，pps_gpio节点是/dev/pps2,后续消除误差需要配置这个节点

dts配置：

pps_ubx{
        compatible = "pps-gpio";
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_pps>;
        gpios = <&gpio4 2 GPIO_ACTIVE_HIGH>;
        status = "okay";
    };

kernel中pps处理相关代码：drivers/pps/clients/pps-gpio.c

linux默认已经在kernel代码中加入了pps的相关处理，重点为触发PPS的中断，本人的项目采用的是上升沿触发中断(因为ublox默认上升沿跟整秒对齐)

中断处理函数：

static irqreturn_t pps_gpio_irq_handler(int irq, void *data)
{
    const struct pps_gpio_device_data *info;
    struct pps_event_time ts;
    int rising_edge;

    /* Get the time stamp first */
    pps_get_ts(&ts);                                          ----获取中断触发的时间信息，后续传给应用层

    info = data;

    rising_edge = gpio_get_value(info->gpio_pin);
    if ((rising_edge && !info->assert_falling_edge) ||
        (!rising_edge && info->assert_falling_edge))
        pps_event(info->pps, &ts, PPS_CAPTUREASSERT, NULL);
    else if (info->capture_clear &&
             ((rising_edge && info->assert_falling_edge) ||
              (!rising_edge && !info->assert_falling_edge)))
        pps_event(info->pps, &ts, PPS_CAPTURECLEAR, NULL);

    return IRQ_HANDLED;
}

pps_event:register a PPS event into the system,后续应用层可以获取pps触发的时间和序号等信息

详细pps相关请参考：PPS - Pulse Per Second — The Linux Kernel documentation

pps-tools:http://linuxpps.org , GitHub - redlab-i/pps-tools: User-space tools for LinuxPPS

ppstest/ppswatch使用（同步后的结果）：

2.GPSD部分

GPSD的启动配置：

/usr/sbin/gpsd -n -P /run/gpsd.pid -F /var/run/gpsd.sock udp://127.0.0.1:50000

-n don't wait for client connects to poll GPS 与chrony配合时候必选

-F sockfile specify control socket location

udp://127.0.0.1:50000 接收ubxclientsocket发送的nema、ubx数据，也直接直接通过配置ublox的uart设备节点

3.Chrony部分

Chrony是NTP（Network Time Protocol，网络时间协议，服务器时间同步的一种协议）的另一种实现，与ntpd不同，它可以更快且更准确地同步系统时钟，最大程度的减少时间和频率误差,chrony是两个用来维持计算机系统时钟准确性的程序，这两个程序命名为chronyd和chronyc

chronyd为后台运行守护进程，用于同步系统时间

chronyc提供了一个用户界面，用于监测性能和配置

chrony+gpsd校准的原理：

gpsd从串口或者网络读取gnss数据并进行解析，将解析结果以UNIX socket或者共享内存等方式输出，chrony从UNIX socket或者共享内存取得解析后的gnss，和pps信息结合，校正系统时间

note:chrony校正的原则是通过控制时间的增减率来达到校正时间，较少采用跳变的方式，跳变的方式可能对其他应用有影响，这样可能会导致校正的比较慢点，但是如果偏差过大或者第一次校正也可以配置成有条件的跳变方式

note:chrony和ntp是冲突的不能同时存在，systemd启动配置的时候需要注意

chronyd配置文件/etc/chrony.conf

driftfile chronyd程序的主要行为之一，就是根据实际时间计算出计算机增减时间的比率，将它记录到一个文件中是最合理的，它会在重启后为系统时钟作出补偿，甚至可能的话，会从时钟服务器获得较好的估值

allow/deny 这里你可以指定一台主机、子网，或者网络以允许或拒绝NTP连接到扮演时钟服务器的机器

makestep 通常，chronyd将根据需求通过减慢或加速时钟，使得系统逐步纠正所有时间偏差。在某些特定情况下，系统时钟可能会漂移过快，导致该调整过程消耗很长的时间来纠正系统时钟。该指令强制chronyd在调整期大于某个阀值时步进调整系统时钟，但只有在因为chronyd启动时间超过指定限制（可使用负值来禁用限制），没有更多时钟更新时才生效

rtcsync 启用内核模式，系统时间每11分钟会拷贝到实时时钟（RTC）

refclock 设置时钟源

note:详细完整的说明请查看chrony官方文档：chrony – chrony.conf(5)

chronyc sources -v 命令查看同步结果：

可以看到偏差大概在 125ns左右

自动驾驶汽车激光雷达如何做到与GPS时间同步？

https://www.zhihu.com/question/317551129/answer/2879979737

同步方案

激光雷达与GPS时间同步主要有三种方案，即PPS+GPRMC、PTP、gPTP

PPS+GPRMC

GNSS输出两条信息，一条是时间周期为1s的同步脉冲信号PPS，脉冲宽度5ms~100ms；一条是通过标准串口输出GPRMC标准的时间同步报文。

同步脉冲前沿时刻与GPRMC报文的发送在同一时刻，误差为ns级别，误差可以忽略。GPRMC是一条包含UTC时间（精确到秒），经纬度定位数据的标准格式报文。

PPS秒脉冲为物理电平输出，接收及处理PPS信号的时间在ns级别，依旧可以忽略。但GPRMC数据一般通过波特率9600的串口发送，发送、接收、处理时间tx在ms级别，是时间同步的关键。

以下是使用PPS+GPRMC进行时间同步的原理。

（1）设备收到PPS秒脉冲信号后，将内部以晶振为时钟源的系统时间里的毫秒及以下时间清零，并由此开始计算毫秒时间。

（2）当收到GPRMC数据后，提取报文里的时、分、秒、年、月、日UTC时间。

（3）将收到秒脉冲到解析出GPRMC中UTC时间所用的时间tx，与UTC整秒时间相加，同步给系统时间，至此已完成一次时间同步。下一秒再进行相同的过程，每秒准确校准一次。

聪明的人可能已经恍然大悟，激光雷达需要进行时间同步，就做两根线接上这两个物理接口就妥了，这种方式是可以的，也是很多厂商在用的方案，但是PPS+GPRMC存在如下问题。

（1）PPS是一个低功率的脉冲电平信号，驱动电流少的只有0.5mA，多的也就20mA，带几个同步节点（激光雷达和其他需要时间同步的节点），十几个就很困难了。

（2）PPS是无屏蔽的单线脉冲信号，十几根PPS线穿梭在车内，极易受到车内恶劣电磁环境的干扰，届时根本无法区分出是干扰脉冲还是同步脉冲。

（3）GPRMC通过RS232串口发送同步报文，RS232是一种1对1的全双工通信形式，也可以通过主从形式实现1对几数据传输。但对十几，实属罕见，只能通过试验验证到底可不可行。但至少线束工程师是打死不愿答应的。

（4）当时钟源丢失的时候，所有需要时间同步的设备都一下子没有了主心骨，每个小弟都可以自立门户，没有二当家的及时站出来，主持大局。这对功能安全要求极高的自动驾驶系统来说，根本无法接受。

PTP

因此基于单纯的PPS和GPRMC实现整个自动驾驶系统的时间同步，具有理论可行性，但并不具有实际可操作性。

而基于网络的高精度时间同步协议PTP(Precision Time Protocol，1588 V2)，同步精度可以达到亚微秒级。这对于主干网络为以太网的全域架构来说，简直是万事具备，只欠各域控制器的硬件PHY芯片支持了。

PTP是一种主从式的时间同步系统，采用硬件时间戳，因此可以大幅减少软件处理时间。同时PTP可运行在L2层（MAC层）和L4层（UDP层），运行在L2层网络时，直接在MAC层进行报文解析，不用经过四层UDP协议栈，从而大幅减少协议栈驻留时间，进一步提高时间同步精度，对于自动驾驶系统来说非常友善。

全域架构下的一种架构方案如下图。

设备中运行PTP协议的网络端口称为PTP端口，PTP主端口用来发布时间，PTP从端口用来接收时间。同时定义了三种时钟节点，边界时钟节点（BC，Boundary Clock）、普通时钟节点（OC，Ordinary Clock）和透明时钟节点（TC，Transparent clock）。

（1）边界时钟节点拥有多个PTP端口，其中一个用来同步上游设备时间，其余端口用来向下游设备发送时间。当边界时钟节点的上游时间同步设备是GNSS接收机时，此时的边界时钟节点就是一个主时钟节点（最优时钟）。

（2）普通时钟节点只有一个PTP端口，用来同步上游时钟节点的时间。

（3）透明时钟，人如其名，具有多个PTP端口，收到什么时间，转发什么时间，不进行协议解析，内部不参与时间同步。PTP通过在主从设备之间交互同步报文，并记录下报文发送时间，从而计算网络传输延迟和主从设备间时钟的偏差。

PTP定义了四条同步报文：Sync、Follow_Up、Delay_Req、Delay_Resp，精确同步过程如下。

（1）PTP主端口向从端口发送Sync报文，同步记录下Sync发送的时间t1。从端口收到Sync报文后，记录下收到的时间t2。

（2）紧接着主端口将t1时间放到Follow_Up报文发送给从端口，从端口收到此报文后就可以解析出t1，并由此得到第一个方程式：t1+网络延时+时钟偏差=t2。

（3）从端口向主端口发送Delay_Req报文，同步记录下Delay_Req发送的时间t3。主端口收到报文后，记录下收到的时间t4。

（4）紧接着主端口将t4时间放到Delay_Resp报文发送给从端口，从端口收到此报文后就可以解析出t4，并由此得到第一个方程式：t3+网络延时-时钟偏差=t4。两个未知数，两个方程组，应用初中数学知识可以解出：网络延时=[(t2-t1)+(t4-t1)]/2，时钟偏差=[(t2-t1)-(t4-t3)]/2。

gPTP

gPTP（generalized Precision Time Protocol，广义精确时间同步协议），基于PTP（IEEE 1588v2）协议进行了一系列优化，形成了更具有针对性的时间同步机制，可以实现μs级的同步精度。

gPTP定义有两种设备类型，Time-aware-end Station和Time-aware Bridge。每种设备都具有本地时钟，本地时钟都是通过晶振的振荡周期进行度量的，设备内部硬件计数器负责对振荡周期进行计数。设备中用来发布时间同步报文的网络端口称为主端口，用来接收时间同步报文的端口称为从端口。

（1）Time-aware-end Station，既可以作为主时钟，也可以作为从时钟。

（2）Time-aware Bridge，既可以作为主时钟，也可以作为桥接设备，类似交换机。桥接类设备在收到gPTP报文后，会请报文搓个澡，然后再送出去。而报文在桥接设备内搓澡消耗的时间，称为驻留时间。gPTP要求桥接设备必须具有测量驻留时间的能力。

下图展示了一个简单的gPTP系统，包含一个时钟源、1个主时钟，2个桥接设备，4个从时钟。主时钟是系统内的时间基准，一般具有更高精度的本地时钟，同时需要能够被高精度准时钟源（如卫星系统、原子钟等）授时。主时钟在系统内可以动态分配，也可以预先分配（对于车载固定拓扑应用场景，多采用预先分配的原则）。

gPTP中规定的主时钟动态分配机制为BMCA(Best Master Clock Algorithm，最佳主时钟选择算法)。系统上电唤醒之后，系统所有设备都可以通过发送一条报文来参与主时钟竞选，报文中含有各自设备的时钟信息。每一个参选设备都会比较自己的时钟信息和其它设备的时钟信息，并判断是否具有优势，如果不具有，则退出竞选，直到综合能力最强的武林盟主诞生。

同步过程

gPTP定义有两类报文，事件类型报文（包括Sync、Pdelay_Req、Pdelay_Resp三条）和一般类型报文（包括Follow_UP、Pdelay_Resp_Follow_UP二条）。gPTP定义设备工作在网络七层模型中的第二层数据链路层的MAC（Media Acess Control，媒介访问控制）子层。

当设备MAC层接收或发送事件类型报文时，会触发对硬件计数器进行采样，从而获得时钟振荡周期计数值，结合时钟振荡频率及基准时间，可获得此时的时间戳。而一般类型报文仅用来携带信息，不会触发内部硬件计数器的采样操作。

时钟偏差测量

gPTP定义的五条报文中，Sync和Follow_UP为一组报文，周期发送，主要用来测量时钟偏差。Sync由主端口发送，在报文离开主端口MAC层时，触发主端口记录此时的时间戳t1。从端口MAC层收到Sync报文后会记录此时的时间戳t2。随后，主端口将t1值附到Follow_UP报文里发送给从端口。

如果没有网络传输延迟或延迟、可以忽略，则从端口将本地时钟值加上时钟偏差（t1-t2的值）就完成时间同步，也就没有后面的碎碎念了。但是对于μs级时间同步精度的gPTP来说，传输延迟显然无法视若不见。

传输延迟测量

gPTP采用P2P（Peer to Peer）的方法来测量传输延迟。在P2P方法中，测量的是相邻设备间的传输延迟，报文不允许跨设备传输，这也就要求gPTP网络内的所有设备都需要支持gPTP功能。同时定义一组独立的报文专门负责传输延迟测量，分别为周期发送的Pdelay_Req、Pdelay_Resp和Pdelay_Resp_Follow_UP。

从端口首先发送Pdelay_Req报文，标志传输延迟测量的开始，在报文离开从端口MAC层时，触发从端口记录此时的时间戳t3。主端口MAC层收到Pdelay_Req报文后会记录此时的时间戳t4，随后，主端口通过Pdelay_Resp报文将值t4发送给从端口，同时在Pdelay_Resp报文离开主端口的MAC层时，触发主端口记录此时的时间戳t5，从端口MAC层收到Pdelay_Resp报文后记录此时的时间戳t6。随后，相同的套路，主端口通过Pdelay_Resp_Follow_Up报文将值t5发送给从端口。至此，一次传输延迟测量过程已经结束。在假设路径传输延迟是对称的前提下，可由如下公式计算相邻设备间的传输延迟。

频率同步

上文的传输延迟测量是基于从端口与主端口的时钟振荡频率一致的前提下得到的。现在我们考虑一下如果主从端口时钟振荡频率不一致的时候，会导致什么灵异事件发生。假设从端口的时钟振荡频率是25MHz,则一个时钟振荡周期是40ns。主端口的时钟振荡频率是100MHz，则一个时钟时钟振荡周期是10ns。

假设在一次传输延迟测量过程中，从端口在t6和t3时刻记录的振荡周期差值若为200个振荡周期。由于主端口的时钟频率是从端口的4倍，因此从端口收到t5和t4时刻的振荡周期差值大概800个。以从端口的40ns一个时钟振荡周期为基准进行计算的话，传输延迟则为-24μs（[200x40-800x40]/2）。传输不仅没有延迟，反而提前知道了，从端口大仙无疑了。

除了主从端口时钟振荡频率的先天不一致，温度、老化等原因也会导致晶振振荡频率的不稳定。为了解决频率不同步的问题，gPTP通过频率同步来实现从端口对主端口的时钟振荡频率同步。

频率同步复用传输延迟测量过程的Pdelay_Resp和Pdelay_Resp_Follow_UP报文。通过采用两组答复，最终可以获得t5,t6,t9,t10的值，由下面公式可得主从端口的频率比。

主从端口频率同步的情况下，频率比等于1。如果大于1，说明主端口走得快，如果小于1，说明主端口走的慢。从端口根据频率比的值，调整自己的时基，从而获得正确的时间戳。

- 一文了解自动驾驶中的时间同步

为什么需要时间同步？

在自动驾驶中，需要用到很多传感器的数据（Lidar，Camera，GPS/IMU)，如果计算单元接收到的各传感器的消息时间不统一，则会造成例如障碍物识别不准等问题。

时间同步包含哪些内容？

自动驾驶中，时间同步可以分为几部分的内容：统一时钟源，硬件同步，软件同步。其中硬件时间同步主要针对相机。

1.统一时钟源

图片来源： @喝苦咖啡的小阿飞

假设各传感器都有自己的内部时钟，但由于每个时钟的钟漂不一样，导致各时钟之间存在时间差，所以需要统一各传感器的时间源。

一般采用GPS时间作为统一时间源，通过GPS给各个传感器提供基准时间，各传感器根据提供的基准时间校准各自的时钟时间。

各传感器根据已经校准后的各自时间为各自独立采集的数据加上时间戳信息，来做到所有传感器时间戳同步。

统一时钟源的常见方式有两种，一种是基于GPS的“PPS+NMEA”，另一种是基于以太网的IEEE 1588（或IEEE 802.1AS）时钟同步协议。

a.PPS+NMEA

GPS能够从卫星获得高精度的时钟信号，因此通常作为整个系统的时钟源。常规的GPS单元都支持输出精确到毫秒的秒脉冲信号PPS和包含年月日时分秒信息的NMEA指令，通过PPS和NMEA的组合就能够实现对激光雷达或主机的毫秒级时钟同步。

PPS+NMEA的优点是协议简单，容易实现；缺点是必须基于RS232。多个设备之间实现同步比较困难。

b.PTP（IEEE 1588或IEEE 802.1AS）

PTP(Precision Time Protocol，1588 V2)是基于以太网的高精度时钟同步协议，能够实现以太网中多个从节点（各种传感器）与主节点（主机）之间的亚微秒级时钟同步，前提是所有节点之间都通过以太网互联，交换机支持PTP协议，并且每个节点都支持PTP协议。

与PTP同时出现的还有一种NTP，即网络时间协议，不同的是PTP是在硬件级实现的，NTP是在应用层级别实现的。

2.硬件同步

图片来源： @喝苦咖啡的小阿飞

由于每种传感器的采样频率不一致，如lidar通常为10Hz，camera通常为25/30Hz，不同传感器之间的数据传输还存在一定的延迟，那么可以通过寻找相邻时间戳的方法找到最近邻帧，但如果两个时间戳相差较大，且传感器或障碍物又在运动，那么最终会得到较大的同步误差。这个情况可以采用硬件同步触发的方法来缓解查找时间戳造成的误差现象。

那如何实现硬件同步呢？也就是在激光雷达和相机的时间源都统一到GPS时间后，如何保证他们同步触发采集呢？方式是以PPS信号为触发信号，实现激光雷达和相机均在PPS信号上升沿的时候采集数据，且打上各自时钟的时间戳。由于PPS的频率只有1Hz，所以通常需要一个设备把PPS信号转发为任意频率、但是跟PPS信号同相位的方波，这样就可以控制相机的采集频率了。

用外部信号触发相机比较好理解，那如何保证激光雷达在PPS信号上升沿的时候采集数据呢？激光雷达制造商想出了一个相位锁定功能，也就是输入PPS，但PPS上升沿到来时，激光雷达的激光束恰好旋转到一定的角度。
于是乎，我们设置激光雷达的相位锁定角度为相机视野中央，如果相机视野朝着车辆正前方，激光雷达的坐标系也是朝着车辆正前方的话，相位锁定角度应该是0度。那么问题就这样解决了，每当激光雷达的激光束旋转到0度位置，也就是相机视野正中央，PPS上升沿刚好到来，相机也因此触发，就这样就实现了激光雷达和相机的同步采集
但是，由于激光雷达和相机采集数据的方式不同，我们只能近似地保证激光雷达和相机的同步采集。如下图所示，激光雷达的激光束不断地360度旋转，假设帧率为10Hz的话，那么一帧点云中采集时刻最早的一个点和采集时刻最晚的一个点时间相差100ms。而相机就不同了，相机是瞬间曝光的，因此图像里面所有像素点的采集时刻都是一样的。这就导致了我们只能近似地保证激光雷达和相机的同步采集。具体方法就是当激光束旋转到相机视野中央的时候，触发相机，这样就保证了相机视野内的点云采集时间是跟图像采集时间是近似的。为什么说是近似的呢？对于相机视野中央的那些点云，它们的采集时间是跟图像采集时间一致的，但是对于相机视野边缘的那些点云，它们的采集时间就跟图像采集时间要有一定的时间偏差了，根据相机视野的大小和点云采集帧率的不同，时间偏差可能会有5ms~20ms左右。

图片来源：CSDN打工人小谢

3.软件同步

图片来源：CSDN是安澜啊

当两传感器的采集时刻不一致，但又想得到同一时刻下两传感器的结果，就可以使用软件同步的方式。目前常采用的软件同步方式为内插外推法，此方法适用于传感器间帧率不存在倍数关系的情况，或者传感器有帧率不稳定的情况。主要利用两个传感器帧上的时间标签，计算出时间差，然后通过包含有运动信息的目标帧与时间差结合，对帧中每一个目标的位置进行推算，推算出新的帧时各个目标的位置，并于原有的两帧之间建立新的帧。

略作补充的是，Apollo的每一个感知初始阶段，都会采用的内插外推这个经典方法。

时间同步的第一步，其主要目的是，用传感器的时间，在localization/pose中查找该时刻所对应的位姿数据，继而通过坐标系换算，使传感器的局部数据能够映射在全局坐标系上。举例而言，Lidar会感知到物体的位置，但这个位置仅仅是对于lidar而言的，但首先需要通过外参将其转化为物体对于车辆的位置，这才是感知所关心的。其间就涉及到了Lidar与Localization的时间统一。

我们可能比较好奇的是，Lidar的时间已经经过pps授时，那么localization的时间是从何处获取的呢？二者又是如何进行匹配的呢？

实际上，每次查询定位时间时，都会传入Lidar这帧数据的采集时间，在绵绵无长的Localization时间中，去寻找一个插值。而Localization的时间记录，则是实时存在在系统里的，所以系统必须授时，则localiaziton的时间戳就与lidar的时间戳保持了同步。

在此，apollo对ROS经典的tf2:buffer类采用了一次外包装，以实现激光雷达坐标系到定位坐标系的转换。从该源码中，我们稍微窥探一下其背后的原理，便是经典的内插外推原理。

Localization的时间会以缓存的形式进行存储，图中的小盒子，就是我们理解的每一截缓存。在缓存的开始时间，我们称之为Earlist_time,缓存的结束时间，我们称之为Latest_time; 下一个阶段的缓存，又是如此的循环往复。

如果我们传入进来要做查询的时间，也就是Lidar时间，在盒子时间的左右边界外，对于当前盒子而言，已经要采用外插法来做推断。

如果我们传入进来做查询的时间，对于当前盒子而言，在盒子时间的左右边界内，对于当前盒子而言，我们便采用内插法来做推断。

使用内插法时，其原理可以用下图概括：虚线为存储的localization数据的相关时间，而t1和t2，是该时刻缓存的边界。我们可以利用缓存边界内的数据，抽象一个函数f(t）出来，而Lidar(t0)传入的值便可用f（t0）求解

使用外推法时，其原理可以用下图概括，尽管我们可以用t1，t2内的时间抽象出函数f(t)，假设外推的时间距离边界较近，我们仍可以采用该模型所求得的值，但假如时间已经过远，之前推导的模型就不再有效，往往会产生较大的误差，Apollo在这里，也在配置中规定了外插法的最大可信任时间，如果时间超过该值，则会报错

各传感器的时间戳

图片来源：CSDN是安澜啊

自动驾驶常用的时间同步方案

主机通过PPS+NMEA实现与GPS的时钟同步；
激光雷达若支持PTP，则主机作为PTP的master，激光雷达作为PTP的slave，以此完成对激光雷达的授时。若激光雷达不支持PTP，则通过PPS+NMEA完成对激光雷达的授时；
相机可以：①若相机支持PTP协议，通过PTP确保相机的时钟与主机同步。然后为每一帧图像都增加一个时间戳，并确保在主机上能够读取到这个时间戳，这样就可以避免编码/解码、以及传输延时引入的同步误差。②想要更高的同步精度，需采取硬件同步触发的方式，根据激光雷达的帧周期同步触发相机的拍摄，实现雷达和相机的完全帧同步，实现完全的毫秒级同步。

以下是某智驾系统的时间同步系统架构

软件介绍

gpsd：gpsd的功能是解析NMEA信息和pps信号，获取当前GPS时间，但是它没有办法给系统授时；

chrony：chrony能够给系统授时，但是需要从gpsd获取当前GPS时间，chronyd和gpsd的通讯是通过共享内存实现的，这需要对chrony做一定的配置；同类软件还有ntpd

ptp4l：ptp4l是PTP同步，即精确网络时间同步协议的软件，它需要从chronyd获取系统当前时间，然后发布到局域网，给相机或其他局域网内的工控机授时，ptp4l与chronyd的通讯也是通过共享内存。

统一时间源的操作步骤

硬件配置

通过串口将NEMA（GPRMC）和PPS信号给到工控机。其中工控机上的引脚定义如下：DB9的1号针脚：PPS信号

DB9的2号针脚：发来的NEMA（GPRMC）信号

DB9的5号针脚：接地

其中华测（组合导航）的A串口输出NEMA（GPRMC）信号，SMA接口输出PPS信号，需要自己做线将他们组合在一起给到工控机。

由于此次接到了工控机的COM2口，所以对应系统中的 /dev/ttyS1。如果接到COM1口，则对应的是 /dev/ttyS0。下面软件配置中需要做相应更改，将下面所有 ttyS1 改成 ttyS0

软件配置

主要参考：github.com/linuxonly199

准备工作

2.配置gpsd

3.配置chrony

参考文献

激光雷达与相机标定时的时间同步问题怎么进行解决? - 知乎

在自动驾驶领域，如何实现激光雷达和相机的时间同步呢? - 知乎

时间同步，自动驾驶里的花好月圆

关于GPS的1PPS时间同步功能探索与测试_学一点IOT-CSDN博客_1pps

激光雷达与相机时间同步问题的低成本完整解决方案_打工人小谢的博客-CSDN博客

【多传感器融合理论】02自动驾驶中多传感器同步理论_是安澜啊-CSDN博客

激光雷达与相机标定的时间戳同步问题_3D视觉工坊-CSDN博客

github.com/linuxonly199

- 什么叫做GPS周秒

-拜耳阵列（Bayer Pattern）简介

拜耳阵列（Bayer Pattern）简介

所谓拜耳阵列指的是 CCD（charge coupled device）或者 CMOS 器件作为光传感器的时候，采集数字图像时用到的一种常见的方法。

介绍一下背景，人们有了可以感受光强度的传感器以后，就可以制造出能拍出黑白照片，也就是灰度图的相机。但是如果需要彩色图像，这种技术就无能为力了，因为当时的传感器只能感知光的强度，而无法感知颜色，也就是频率或波段。如果想要获得不同波段的光，最直接的做法是加入不同颜色的滤镜，从而滤出 RGB 三个通道的颜色。但是用这种方法如果对每个pixel都获得三个通道的光强的话，则需要对每个pixel都应用三个滤镜，成本过高。柯达公司的工程师Bryce Bayer ，也就是拜耳阵列的发明人，想到了一种解决方案，就是Bayer pattern：