<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>系统设计 on 笔记本子</title><link>https://tianshihao.github.io/tags/%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1/</link><description>Recent content in 系统设计 on 笔记本子</description><generator>Hugo -- gohugo.io</generator><language>cn</language><copyright>Copyright © 2025</copyright><lastBuildDate>Mon, 07 Jul 2025 10:05:00 +0800</lastBuildDate><atom:link href="https://tianshihao.github.io/tags/%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1/index.xml" rel="self" type="application/rss+xml"/><item><title>多源输入对齐方案</title><link>https://tianshihao.github.io/posts/%E5%A4%9A%E6%BA%90%E8%BE%93%E5%85%A5%E5%AF%B9%E9%BD%90%E6%96%B9%E6%A1%88/</link><pubDate>Mon, 07 Jul 2025 10:05:00 +0800</pubDate><guid>https://tianshihao.github.io/posts/%E5%A4%9A%E6%BA%90%E8%BE%93%E5%85%A5%E5%AF%B9%E9%BD%90%E6%96%B9%E6%A1%88/</guid><description>&lt;h1 id="多源输入对齐方案">多源输入对齐方案&lt;/h1>
&lt;p>这个东西其实看起来挺简单的，不过整理一下能有一个更好的全局认知，也能提高架构设计方面的能力。&lt;/p>
&lt;h2 id="1-背景">1. 背景&lt;/h2>
&lt;p>假设一个多源输入对齐的场景需要接收的输入有 Lidar、图像以及其它传感器和 Topic，这些数据需要组成一帧数据，然后喂给模型。在设计对齐方案的时候，已知的信息还有：&lt;/p>
&lt;ol>
&lt;li>Lidar 点云的频率被硬件限制为 10Hz。&lt;/li>
&lt;li>图像的帧率可以提升到 30Hz。&lt;/li>
&lt;li>真值车的数据是以 Lidar 帧尾时间戳（以下简称为 Lidar 时间戳）为基准对齐的。&lt;/li>
&lt;li>这里我的理解是，一帧 Lidar 有很多点云，但是每一个点云的时间戳又不一样，帧尾时间戳指的是一次点云数据中最后一个点云的时间戳。LidarService 里面也只这样的。&lt;/li>
&lt;li>同时与之相对的还有一个（帧首时间戳），LidarService::Preprocess 中的 frame_head_timestamp。&lt;/li>
&lt;li>已上线代码是以前视 120 度相机图像的曝光结束时间戳（以下简称为图像时间戳）为基准对齐的。&lt;/li>
&lt;li>动态模型希望对齐的数据与 Lidar 同频，以保证 Lidar 数据的有效利用，并希望多帧消息的发送间隔尽量稳定。&lt;/li>
&lt;/ol>
&lt;p>上面是一些已知信息和需求。&lt;/p>
&lt;h2 id="2-消息的提取和缓存">2. 消息的提取和缓存&lt;/h2>
&lt;p>然后就是一些思考：&lt;/p>
&lt;ol>
&lt;li>所有参与对齐的消息都需要缓存，以便提取与基准对齐的帧。&lt;/li>
&lt;li>消息的对齐和提取可以抽象为单例，方便在多模块间异步调用。&lt;/li>
&lt;li>建议实车保留运行时的对齐的帧信息，方便回灌时提供一致的输入。&lt;/li>
&lt;li>可能的对齐方法有最近邻对齐、插值、最新，图像较为特殊，将单独讨论。&lt;/li>
&lt;/ol>
&lt;h3 id="21-最近邻">2.1 最近邻&lt;/h3>
&lt;p>最近邻可以概括为两步：更新和获取。&lt;/p>
&lt;ul>
&lt;li>更新：将收到的消息按时间顺序插入缓存队列。&lt;/li>
&lt;li>获取：按照给定的时间戳，从缓存队列中返回最接近的消息。
伪代码的话使用 std::queue 就可以了，实际代码的话，Lidar 和其它数据使用的是 std::list，图像是一个 Image Msg Pool。
对一时间一致性要求更高的输入，可以做一些额外的补偿，例如 Lidar 点云按照图像时间戳对齐时的运动补偿，或者还可以使用精度更高的插值法。
这个方法的缺点是精度一般，占用一定的空间。&lt;/li>
&lt;/ul>
&lt;p>好吧，其实对齐代码我从来没有仔细看过，反正也不会出什么问题，数据也不了解。既然我的策略是摸鱼，看不看代码又有什么区别呢？是的，可以摸鱼，但不可以不会。先看吧，就当杀时间了。&lt;/p>
&lt;h3 id="22-插值">2.2 插值&lt;/h3>
&lt;p>在最近邻的基础上，获取时需要按照一定方法插值。
当数据不足时，需要特殊处理：&lt;/p>
&lt;ul>
&lt;li>直接返回空。&lt;/li>
&lt;li>返回最接近对齐时间戳的消息（相当于退化为最近邻）
这个方法与最近邻相比，精度更高，但计算量增大。里程计 Odometry 比较适合插值，模型的训练和推理都用插值。&lt;/li>
&lt;/ul>
&lt;h3 id="23-最新">2.3 最新&lt;/h3>
&lt;p>只缓存一帧数据即可，需要解决的主要问题是异步的读写，并不存在对齐问题。
适用的情况：&lt;/p>
&lt;ul>
&lt;li>精度要求不高，允许较大的误差。&lt;/li>
&lt;li>与对齐误差相比，更关注时效性。&lt;/li>
&lt;li>待对齐消息的时延远大于对齐基准的间隔，即使用最近邻返回的永远也只是最新元素。&lt;/li>
&lt;/ul>
&lt;h3 id="24-特例图像的缓存和提取">2.4 特例：图像的缓存和提取&lt;/h3>
&lt;p>累了，明天看图像的对齐吧，为什么感觉很简单的东西，别人文档写了那么多。&lt;/p>
&lt;h2 id="3-以-lidar-时间戳为基准的对齐方案">3. 以 Lidar 时间戳为基准的对齐方案&lt;/h2>
&lt;p>这也是现行的方案。&lt;/p>
&lt;h3 id="31-概述">3.1 概述&lt;/h3>
&lt;ul>
&lt;li>接收 Lidar 点云，并以帧尾时间戳作为对齐基准。
&lt;ul>
&lt;li>这里帧尾时间戳就是用帧头时间戳床加一个固定的时间间隔取得，固定值是 48.285。&lt;/li>
&lt;/ul>
&lt;/li>
&lt;li>按照对齐基准寻找满足对齐条件的图像、里程计、V2 地图、惯导、子车状态、Radar 消息等输入。&lt;/li>
&lt;li>部分消息需要做预处理（例如 Lidar 点云、图像、地图），可以并行操作。&lt;/li>
&lt;li>所有输入准备完成之后，组装成消息帧，喂给模型。&lt;/li>
&lt;li>Lidar 在获取了帧尾时间戳之后就可以将对齐基准发出，然后 Lidar 并行做预处理。&lt;/li>
&lt;/ul>
&lt;h3 id="32-实现细节">3.2 实现细节&lt;/h3>
&lt;ul>
&lt;li>实际实现的时候，是收到 Lidar 的 DDS 数据，计算帧尾时间戳，存在原始的 frame 里面，原始的点云也存到 frame 里面。然后运行 taskflow，开始并行处理对齐图像、Lidar 和各种传感器，这时用到的时间戳就是原始 frame 里面的 lidar 帧尾时间戳。&lt;/li>
&lt;li>从对齐基准发出到对齐消息组装的链路必须适用 FIFO，保证对齐的一致性。&lt;/li>
&lt;li>需要给组装好的 frame 一个 frame id 和 time stamp，作为这一帧的标识信息。&lt;/li>
&lt;/ul>
&lt;h2 id="4-以图像时间戳为基准的对齐方案">4. 以图像时间戳为基准的对齐方案&lt;/h2>
&lt;p>差不多，当满足发图条件的时候，找到最新的对齐图像数据，发送对齐基准。&lt;/p>
&lt;p>Lidar 时间戳对齐和图像时间戳对齐的比较
主要有两点：&lt;/p>
&lt;ul>
&lt;li>由于 Lidar 的帧率只有 10Hz，所以帧率的拓展性方面，以 Lidar 时间戳对齐仅支持不高于 10Hz 的帧率，图像的帧率是 28Hz/30Hz，所以帧率拓展性更高。&lt;/li>
&lt;li>链路时延方面，用 Lidar 帧尾做起始时间，需要调整当前链路时延系统的计时逻辑。&lt;/li>
&lt;/ul>
&lt;p>Lidar 时间戳对齐的优势和不足：&lt;/p>
&lt;ul>
&lt;li>优势：对齐方式与训练数据一致直，消息发送和对齐基准间隔均匀。&lt;/li>
&lt;li>不足：目前的功能需求不完善，缺乏对于无 Lidar 输入、分时复用等情况的系统定义；改动较大，不支持较高的帧率。&lt;/li>
&lt;/ul>
&lt;p>图像时间戳：&lt;/p>
&lt;ul>
&lt;li>优势：已经上线很长时间，稳定可靠。支持的帧率范围广。&lt;/li>
&lt;li>不足：间隔的均匀性取决于上游发图的频率，对齐方式与训练数据不一致。&lt;/li>
&lt;/ul></description></item></channel></rss>