企业官网建设流程全解析

常在短视频平台霸榜——最后一公里问题，实现场景有以下几种：人在地面停车后车可以自行停在地库；用户在某地方唤醒、车自行驾驶到该指定地点的视频，当下其实主要依赖的是相机+惯导+GNSS定位的大融合算法（SLAM技术），而在车开出地库后，GNSS如何快速定位，从而辅助车机找到准确的行车路线呢？其面临的问题和GNSS出隧道问题存在一定的区别，在此需要对智驾车在地库中的GNSS模组上电模式问题进行区分：
（1）停车、GNSS模组的主要电源和备用电源均中断的情况（冷启动）；

（2）短时间内（≤2小时）停车、GNSS模组的主要电源中断、备用电源正常工作的情况（星历、时间、定位信息均有效）；

（3）长时间（>2小时）停车、、GNSS模组的主要电源中断、备用电源正常工作的情况（星历可可能无效、时间和定位信息有效）；

1. 热启动模式

在GNSS模组中，备用电源主要是为时钟芯片RTC（Real_Time Clock）供电，可以获得主电中断情况下的计数时间，根据相关FLASH存储信息可以计算出主电中断时间以及断电后的本地时间，实现温、热启动定位模式，可以快速定位，其中热启动首次定位时间一般设置不超过3s。

1.1 热启动工作模式

热启动模式可以理解为定位时有部分有效信息可用，部对于热启动工作模式，其主要必备的有三个元素：星历信息、本地时间信息、定位点信息。

1.1.1 热启动必备信息

按照重要程度排名，可以区分为：
（1）断电后本地时间、星历、定位点信息均有效：定位时间≤3s，基带提供发射时间的ms小数部分后则可以计算出大量卫星的伪距信息，可定位；

（2）断电后星历信息、本地时间有效：定位时间≤3s，LSQ中多迭代几次也可以解算出位置信息，只不过需要增加迭代次数，该情况近似于（1）；

（3）断电后星历信息、定位点信息有效：定位时间≤10s，时间信息可以通过帧同步后卫星的发射时间更新，假设定位系统中有BDS GEO，该定位时间会缩短，GEO的帧同步时间需要0.6s，加上基带捕获跟踪的时间，可以缩短到3s之内；

（4）断电后本地时间信息或定位信息有效：定位时间≤40s，可以近似相当于冷启动模式，在定位过程中星历信息需要用来计算卫星位置；

（5）断电后星历信息有效：定位时间≤10s，更新本地时间的部分同（3），计算本地位置信息同（2），即需要多迭代几次LSQ；

那么，既然这三者信息都这么重要，该如何获取呢？

常用的方法是将断电前GNSS模组获取的星历、本地时间信息、定位点信息存储到flash存储器中，也会有部分模组将基带所使用的部分信息存储到该内存中，上电后可以直接从flash中读取到相关信息，直接注入GNSS模组，便于热启动。

（1）星历信息：即断电前收集的星历信息，同系统的星历有效期不一致，所以接入的卫星信号不一致，定位所需要的时间也不一致，本文中默认的是5系统定位（GPS+BDS+GALILEO+GLONASS+QZSS），一般情况下认为的极限是2小时，在热启动模式下当本地时间有效后，同时需要判断星历的有效性。

（2）本地时间信息：在flash中读出来的时间信息为old_tow，从rtc计数器中可以读到断电的持续间隔delta_rtc，那基于new_tow=old_tow+delta_rtc，即可获取到新的本地时间。注意：rtc计数器存在漂移，所以该处计算的delta_rtc存在一定误差，所以计算的new_tow也存在误差，该处作为后续本文章的一个重点来讨论。

（3）本地定位信息：即断电前的位置、速度等定位相关信息，该信息有利有弊，假设在长时间断电模式下GNSS模组产生了一定位移，再次上电后还使用断电前的信息，可能存在一定影响，如果短时断电并且无位移的情况下，本地定位信息可以辅助计算伪距信息，减少LSQ迭代次数，加速热启动定位时间。

1.1.2 读写flash

讨论完上述三种信息的使用，接下来的重点需要考虑的是对于flash的读写频率设置。flash区分block、sector、page，最小的读写单元是1 page，由于写flash是一个常态化操作，所以在写flash的时候需要考虑到是否影响整个实时线程，即多久写一次？一次写多少的问题？根据上述提到的星历、时间、定位点信息的更新频率来安排。

（1）星历信息：按照不同系统写，将GPS和QZSS记作1个系统，假设每个系统的星历均小于page，那只需要4page，假设1个系统所有的星历大于1page，那就需要分page读写。由于星历更新期比较长，比如GPS更新周期为2小时，BDS更新周期为1小时，所以写的频率可以变慢，比如定位60秒后写一次，后续可以15分钟再写一次。

（2）时间+定位点信息：这两个信息可以结合为1个结构体变量，考虑到时间信息的精确性，可以将其频率变快，比如2分钟写一次。

对于断电后上电，上述信息只会读一次，所以读的时候可以一次性全部读完，根据时间判断星历有效期，根据星历有效期可以更新卫星跟踪列表，将卫星有效列表输出给基带，帮助基带加快捕获速度，再一次加快热启动时间。

注意点：
（1）不同版本对于flash的分配大小和空间可能存在不一致：嵌入式层面要对该部分进行梳理，防止升级版本出现异常；

（2）写flash一半的时候断电，导致没有flash信息写全：破坏了原有的flash信息量，嵌入式层面要针对写flash采用备份区的方式；

（3）flash遭到破坏，内容出现大量异常：GNSS算法内部要对参数进行判断，比如星历参数中的个别参数的取值范围、定位模式是否异常等；

1.2 如何更新本地时间

在上述1.1.1节中提到，如果直接用rtc计算中断时间，会存在一定误差，当误差量大于1/2bit（GEO 1ms）的时候，容易影响伪距计算，从而影响LSQ无法迭代出定位信息，导致定位失败。常用的更新本地时间的方法有2种，一是使用帧同步的卫星更新tow；二是将误差量估计出来。

（1）基于帧同步的卫星更新tow，在之前的文章中有提到，即使用帧同步计算的发射时间和估计的传输时间叠加更新：

即

https://blog.csdn.net/weixin_40681914/article/details/154746021?spm=1001.2014.3001.5502

在大量卫星星历有效时，会反算得出卫星的发射时间，再计算出伪距信息来定位。反算过程上述文章也做了一定介绍，在计算过程中需要引入卫星钟差的影响！

（2）将rtc_corr该信息量作为LSQ解算过程中的估计量，作为一个待估计参数求解而来，该方法中重点部分是计算发射时间部分，因为基于rtc计算的tow本身是有误差的，反算的发射时间也是有误差的，所以反算的发射时间计算出的伪距和真实卫星基于帧同步计算出的伪距所表现出的伪距残差是不一致的，该部分需要重点考虑！（可以完全参考 《一种改进的A-GPS快速定位方法设计》实现，可以在知网再查找几篇相关文章，基本可以得出整个流程）

rtc估计方程：

即上述截图中的v^k部分，可以理解为速度在卫地距上的投影，也可直接使用多普勒信息，在具体使用过程中要考虑是否去除接收机钟漂和卫星钟漂的影响。

在计算出rtc_corr时，需要注意：
（1）引入LSQ估计量后，状态量+1，需要判断解算方程的自由度；

（2）判断验后残差以及本次解算的有效性，才将rtc_corr叠加到卫星的发射时间上重新计算出卫星位置；也需要判断估计的rtc_corr差值，需要限制在一定阈值内，因为需要该数值更新本地时间；

（3）判断本次LSQ迭代结束条件，尽量不要影响定位速度；

（4）判断何时彻底终止估计rtc_corr的LSQ解算，即恢复LSQ的估计量只有位置+钟差；

为避免估计次数较多，也会采用在第一颗帧同步卫星成功后，直接使用方法（1）中的方法更新，只不过此时的传输时间需要更精确一点，即使用该发射时间计算出卫星位置，再基于本地位置计算出path_t。

计算发射时间时，需要选择出参考卫星，一般情况下选择高CN0卫星作为参考卫星计算，下文中的r0可以使用path_t计算，z0可以使用基带上报的ms_frac计算，round（）操作在实际计算中需要考虑清楚，因为四舍五入可能会丢失部分信息，所以在对于N0的取值方面需要慎重！

2. AGNSS 模式

热启动模式可以直接和GNSS模组挂钩，假设当前GNSS模组没有上述提到的rtc和存储信息所必备的flash，应该如何操作？和网络rtk一样，上述信息可以通过网络请求得到，比如千寻位置服务和中国移动网络服务，中移可以拿到RTCM协议和自研格式协议的星历、时间信息，在GNSS内部做解码即可使用，使用流程和热启动模式下的处理基本一致。

假设在GNSS算法内部使用AGNSS服务，这也是当前融合算法使用比较多的方式，直接请求AGNSS星历信息。那么什么时候请求？请求的频率如何？

该信息请求入口应为GNSS内部，区分为：

（1）刚上电状态，即地库中的冷启动模式；

（2）星历大量过期状态，即地库中停留时间较长，没有下电状态，可以理解为有时间信息的热启动模式；

请求的频率要和应用该项服务的产品数量直接挂钩，不能在同一时间内大量请求和响应，会影响服务稳定性，也不能多次请求，存储空间总是有限的。

对于（1），开机即可请求AGNSS服务，考虑到信息请求到后是通过嵌入式转发给GNSS内部，所以要考虑到请求间隔，比如上电但是没有定位的状态下，第一次以5秒为间隔请求，第二次以10秒为间隔请求，第3次以及后续以30秒为间隔请求，请求3次后还没有定位的场景下，沉默15分钟后再次开始请求，直到定位后终止。上述的固定间隔也可设置为1~60s中的随机数请求。

对于（2），如何判断大量卫星过期？可以通过判断各个系统的有效星历的卫星数量在全部卫星数量中占比，如果小于50%，则开始请求，请求并且获得星历后需要重复判断上述占比，和（1）请求服务一样，不能频繁请求，可以将间隔设置为30秒，直到占比大于80%。

综上，无论是FLASH中存储的方式，又或者是实时请求AGNSS服务的方式，上述两种方式的关键就是获取到星历信息，可以理解为星历信息是缩短定位时长的关键！