前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >资源有限的机器人实现实时LiDAR点云压缩与传输

资源有限的机器人实现实时LiDAR点云压缩与传输

作者头像
点云PCL博主
发布于 2025-02-25 01:31:16
发布于 2025-02-25 01:31:16
2310
举报
文章被收录于专栏:点云PCL点云PCL

文章:Real-Time LiDAR Point Cloud Compression and Transmission for Resource-constrained Robots

作者:Yuhao Cao, Yu Wang and Haoyao Chen

编辑:点云PCL

代码:https://github.com/HITSZ-NRSL/RCPCC.git

摘要

激光雷达(LiDAR)广泛应用于自主机器人,因其能够提供准确的环境结构信息。然而点云数据的庞大规模在数据存储和传输方面带来了挑战。本文提出了一种面向资源受限机器人应用的全新点云压缩与传输框架,称为RCPCC。通过迭代拟合具有相似范围值的点云表面,并通过它们的空间关系消除冗余。接着使用形状自适应离散余弦变换(SADCT)对未拟合的点进行变换,并通过量化变换后的系数来减少数据量。设计了一种基于用户体验(QoE)作为优化目标的自适应比特率控制策略,以控制传输点云的质量。实验表明框架在保持下游应用高精度的同时,实现了40倍到80倍的压缩率。当压缩率超过70倍时,我们的方法在精度方面明显优于其他基准方法。此外在通信带宽受限的情况下,我们的自适应比特率控制策略在用户体验(QoE)方面展现了显著的改善。代码将发布于 https://github.com/HITSZ-NRSL/RCPCC.git。

图1. 资源受限机器人云服务解决方案图(左)。以及使用压缩点云的下游任务结果(右)。

主要贡献

该压缩方法使用深度图像作为点云的基本表示。深度图像利用了激光雷达的固有物理特性,将三维点云投影到二维图像中,从而为后续处理提供了高计算效率。通过迭代拟合表面模型到点云,充分利用深度图像的空间特性进行点云编码。对于未被表面模型拟合的点,对其应用形状自适应离散余弦变换(SA-DCT),避免了零值噪声伪影,并实现了进一步的压缩。本文的主要贡献可以总结为三点:

  • 提出了一个新型的激光雷达点云压缩与传输框架RCPCC,能够处理带宽波动,并提高点云传输的实时性能和稳定性。
  • 提出了一个基于用户体验(QoE)的自适应比特率控制策略,能够应对带宽波动,改善点云传输的实时性能和稳定性。
  • 大量实验表明,与现有最先进的方法相比,RCPCC在实现竞争力的压缩率和高精度的同时,显著降低了传输延迟。

主要内容

系统概述

所提出的面向资源受限场景的实时激光雷达点云压缩与传输框架RCPCC如图2所示。点云首先通过球坐标系投影为深度图像。随后深度图像被划分为宏块,并对每个宏块进行表面模型拟合。拟合宏块中的点会被编码和参数化,同时,已拟合的点从深度图像中移除。对于未拟合的点,应用SA-DCT对数据进行变换,并量化变换后的系数,以平衡压缩率和质量。自适应比特率控制策略以压缩级别和数据队列长度为输入,调整下一帧点云的压缩级别。解码是压缩的逆过程,通过相应的逆变换重构原始点云。

图2. 所提出的RCPCC框架概述。输入的点云首先被转换为深度图像,以加速压缩过程。我们使用表面模型拟合来消除点云中的空间冗余。未拟合的点通过SA-DCT从时域转换到频域,并对变换结果进行量化。最后所有解压所需的数据被序列化并输入到二进制熵编码器中。

点云编码

1、深度图像转换

在激光雷达(LiDAR)中,点云通常是以笛卡尔坐标(x, y, z)表示的,即相对于传感器原点的位置。然而为了加速压缩过程,将点云通过球面投影转换为深度图像。深度图像是通过将点云映射到一个二维平面来生成的,这样可以有效地简化三维点云的操作,使得后续处理变得更加高效。具体来说,深度图像的每个像素表示点云中的一个点,其中包括该点的距离信息。转换过程涉及使用球面坐标来计算每个点的方位角和俯仰角,同时获取该点的径向距离。这种转换将点云的三维空间信息转化为二维的图像数据,从而使得后续的计算操作更加高效。

2、表面编码

在点云压缩过程中,我们利用空间建模技术来提取点云的结构信息,减少空间冗余。实际上,许多点云中的点会位于同一平面上,例如地面或墙壁上的点。为了更好地利用这一特性,我们将点云通过拟合平面来简化。通过拟合,点云中的大部分点可以近似为平面上的点,从而减少了需要编码的数据量。具体操作是,首先通过拟合平面来预测每个点的深度信息。虽然使用平面模型进行拟合是常见的方法,但它存在一定局限性,因为需要使用三角函数进行复杂的计算。因此提出了一个改进的表面模型,使用更简单的公式来预测每个点的深度值。通过这种方法,可以更高效地捕捉点云的空间结构,减少计算复杂度。在实际编码中,我们将深度图像划分为多个宏块(例如,每个宏块为4x4的区域),并对每个宏块进行表面拟合。如果宏块内所有点到拟合表面的距离都小于一个设定的阈值,那么该宏块就被视为一个表面块。对于在同一行的宏块,使用前一个宏块的表面参数来预测下一个宏块,并进行验证。如果拟合结果通过验证,两个宏块就会合并,共享相同的表面参数。通过这种方法,点云的编码效率得到了显著提高。

3、未拟合点编码

尽管大多数点云可以通过表面拟合来压缩,但仍然会有一些点无法被拟合,这些点就被称为未拟合点。为了有效编码这些未拟合点,我们首先创建一个“未拟合图像”,它记录了所有没有被表面模型拟合的点。这些点的深度信息可以直接进行编码,但如果直接采用传统方法编码,会造成冗余,因为大部分点云已经通过表面拟合得到了压缩。因此采取了更为高效的编码方法,应用了形状自适应离散余弦变换(SA-DCT)来对这些未拟合点进行编码。SA-DCT方法的核心思想是将未拟合点进行时域和频域的变换,通过这种方式,我们可以减少冗余数据,提高压缩率。在实际操作中,未拟合点会被移动到图像的上边缘,并对这些点进行一维的DCT(离散余弦变换)。DCT变换能够将时域数据转换为频域数据,从而有效地压缩数据。通过这种方式,只有那些重要的、非零的变换系数会被保留,从而避免了大量零值噪声的产生。最终,我们对这些变换后的系数进行量化,将数据量进一步减少。量化虽然会引入一定的误差,但能显著减少数据量,提高压缩率。

图3. 范围图像被划分为宏块,不同的颜色表示不同的表面(左)。占用掩码标记了点云在范围图像中的位置,表面块使用四元组进行编码(右)。

基于QoE的自适应比特率控制

在视频流媒体中,自适应比特率(ABR)技术根据网络状况动态调整视频质量,能够避免因网络波动而产生的卡顿,进而提升用户体验(QoE)。对于云服务中的点云传输,服务器的目标是实时接收来自机器人小而高质量的点云数据。在此场景下,我们定义了一个基于实时传输质量的QoE目标函数,用以衡量点云数据传输过程中的质量。QoE目标函数的设计考虑了三个主要方面:

  1. 压缩质量:这部分通过根据压缩级别对点云的质量评分来评估数据质量。压缩级别包括多种配置,例如分辨率、表面阈值和量化级别等。通过动态调整压缩级别,我们能够平衡压缩率和点云数据的质量。
  2. 缓冲队列长度的惩罚:在数据传输中,缓冲队列的长度直接影响传输的流畅度。如果缓冲队列过长,可能会导致延迟增大,从而影响实时性。为了避免这种情况,我们对缓冲队列长度设置了惩罚项,鼓励短队列和较低的延迟。
  3. 频繁质量切换的惩罚:质量切换频繁会导致不必要的资源浪费,并可能带来质量的不稳定。因此,我们对频繁切换质量进行惩罚,以保持传输的稳定性和一致性。

为了解决这个在线优化问题,我们提出了一个自适应比特率控制策略,主要包括以下几个方面:

  1. 质量提升尝试:如果在较长时间内,队列长度保持稳定,我们会尝试提升压缩质量。这意味着服务器会提高压缩的精度,以获得更高的点云质量。然而,如果质量提升后的结果不符合预期,系统会恢复到之前的压缩状态,以避免过度增加延迟或损失质量。
  2. 历史记忆:决策不仅基于当前的队列状态,还要考虑历史数据,特别是历史缓冲队列的长度。这种方式可以帮助系统做出更加稳妥的决策,避免仅根据当前状态做出可能带来长远影响的决策。
  3. 缓冲切换管理:质量切换并不会立即影响缓冲队列的长度,因此在进行质量切换时,系统会设置一个缓冲期,以减少频繁切换质量所带来的负面影响。这个缓冲期有助于平稳过渡,避免系统不断因质量调整而造成过多的延迟和不必要的惩罚。

实验设置

网格重建

我们的压缩方法在网格重建上优于其他方法,取得了更好的映射性能和更高的压缩比。我们使用F-score来评估网格重建中的表面质量,压缩比则计算为原始点云大小与最终二进制大小的比值。

图4展示了不同方法在不同压缩比下的F-score比较。我们的压缩方法能够达到100.5倍的压缩比,并保持95.94%的F-score。在压缩比为198.4倍时,F-score仍然保持在91.70%。相比之下,表现最好的Draco在压缩比为100.7倍时实现了94.07%的F-score,随着压缩比的进一步增加,其他方法的F-score迅速下降,而我们的压缩方法仍然保持稳定的F-score性能。即使在非常高的压缩比(最高可达557倍)下,我们的方法仍能保持稳定的F-score。

图4. 各种方法的网格重建F-score与压缩比比较。

定位

当压缩比大于100倍时,我们的压缩方法在平均平移误差上低于其他基准方法。图5显示了在不同压缩比下,不同方法在KITTI数据集上的平移误差百分比。由于PCL在此测试中失败,因此没有显示PCL的结果。从图5中可以看出,在36.3倍的压缩比下,我们的方法保持了与原始点云几乎相同的平移误差百分比。当压缩比增加时,我们的方法在定位性能上保持稳定,而JPEG2000和Draco的平移误差百分比分别增加到4.29%和9.62%,约在100倍时出现显著上升。相反,我们的方法在99.7倍压缩比下保持了0.71%的低误差率,优于所有其他基准方法。

图5. 各种方法的平均平移误差与压缩比比较。

目标检测

当压缩比超过36.4倍时,我们的方法在目标检测精度上优于其他方法。我们评估了KITTI目标检测数据集上不同方法在不同压缩比下的目标框平均精度(AP)。图6显示了不同压缩比下,各方法在KITTI目标检测数据集上的BBox AP百分比。与原始点云的80.89%精度相比,我们的方法在14.4倍的压缩比下达到了79.03%的竞争性精度。随着压缩比的增加,我们的方法在41.4倍压缩比下保持了68.8%的精度。相比之下,PCL和JPEG2000的精度迅速下降,在压缩比大于40倍时降至40%以下。

图6. 各种方法的物体检测边界框平均精度(BBox AP)与压缩比比较。

消融实验

为了验证前面提到的各个模块的影响,我们在KITTI数据集的1000帧上进行了实验,并记录了相关数据。

平面模型与表面模型。表I展示了平面模型和表面模型在不同距离阈值下与地面真实值的点云预测的平均误差(MAE)。在相同的距离阈值下,表面模型产生的MAE比平面模型低。

SA-DCT。表II比较了未压缩的未拟合图像(No Compr.)和使用SA-DCT压缩未拟合图像之间的MAE及相应的压缩比。使用No Compr.(仅由表面模型拟合生成),该管道实现了32.40×的压缩比,MAE为3.68。使用SA-DCT时,当量化步长为0.10时,压缩比提高到40.86×,MAE略微增加至5.29。实验表明,我们的方法在压缩比上实现了显著的提高,同时误差增加在可接受范围内。

传输实验

对于传输,我们评估了点云传输过程中的QoE,这是云服务质量的关键。我们比较了在有无策略情况下,点云压缩方法的传输性能,其中压缩等级是根据不同参数从精细到粗略(0到5)预定义的。图7中带宽变化的时间点用垂直虚线标记。实验开始时带宽为300KB/s,在55秒时急剧下降到100KB/s(模拟干扰或机器人进入信号质量较差的封闭建筑物);在120秒时,带宽略微增加到130KB/s;在245秒时,带宽升高至160KB/s(表明机器人已远离干扰或退出封闭建筑物)。在图7中,当带宽下降时,由于我们自适应比特率控制策略的缓冲切换特性,压缩等级逐渐从0增加到5,以适应带宽的变化。相比之下,在没有策略的情况下,带宽下降时压缩等级保持在0,导致数据队列增长,最终导致传输延迟增加。当125秒时带宽上升时,我们的策略通过质量改进尝试逐步降低压缩等级,从而提供更高质量的点云。然而,这一质量改进可能会引发延迟,在160秒时,将压缩等级降低到0会导致队列长度增加。我们的历史记忆方案通过回滚压缩等级,防止过度使用质量改进尝试,从而保持数据队列的稳定性。

图7. 带有和不带有基于QoE的自适应比特率控制策略的点云传输实验结果比较。

运行时分析

表III比较了我们的方法与其他基准方法的运行时。我们方法的参数设置为(0.5, 0.5, 0.3, 0.2),所有方法都设置为实现相似的压缩比(大约60×)。我们方法的编码时间为41.05毫秒,解码时间为11.35毫秒。我们方法的速度足够支持当前激光雷达的实时点云压缩。

图8详细展示了我们方法的编码和解码过程的运行时细分。管道中最耗时的部分是SA-DCT及其逆变换。

图8. 该方法的模块运行时细分

总结 本文提出了一种新型的实时LiDAR点云压缩与传输框架,称为RCPCC。高效的点云压缩与自适应比特率控制策略相结合,使该方法能够帮助资源受限的机器人实现实时点云传输。该方法实现了高达80倍的压缩比,并且在保持高应用精度的同时,实时压缩速度超过10 FPS。它在压缩比、速度和精度方面超越了现有的点云压缩标准。

相关阅读:2024年度历史文章大汇总

以上内容如有错误请留言评论,欢迎指正交流。如有侵权,请联系删除

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2025-02-24,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 点云PCL 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
Linux进程间通信--管道(pipe和fifo)
       通过管道来实现进程间的通信的方法很经典,因为多个进程共享3-4G中的内核,所以在内核中存在一个管道(缓冲区),然后进程通过连接管道的两端从而实现通信。假如说我们现在有一根管道,我们从左端放入一个小球,那么它会从右端滚出来,那么如果我们同时向两端都放入一个小球,那么就不可能实现交叉传递了,所以管道是半双工通信(即双方都可以发送信息,但是双方不能同时发送信息),因此管道的两端一端是读端,一端是写端。那么要实现两个进程的同时读写操作,就需要用两个管道。
Ch_Zaqdt
2020/03/03
3.9K0
【Linux进程#1】IPC 进程间通信(一):管道(匿名管道&命名管道)
✨ 无人扶我青云志,我自踏雪至山巅 🌏
IsLand1314
2025/06/02
1350
【Linux进程#1】IPC 进程间通信(一):管道(匿名管道&命名管道)
【Linux】IPC 进程间通信(一):管道(匿名管道&命名管道)
为了实现两个或者多个进程实现数据层面的交互,因为进程独立性的存在,导致进程通信的成本比较高
IsLand1314
2024/11/19
4350
【Linux】IPC 进程间通信(一):管道(匿名管道&命名管道)
Linux:进程间通信(一.初识进程间通信、匿名管道与命名管道、共享内存)
这种双重性使得管道既具有机制的灵活性,又具有文件的可操作性。它可以在不同的进程之间建立连接,实现数据的传递和共享,同时也可以通过标准的文件操作接口进行访问和控制。
是Nero哦
2024/07/09
5750
Linux:进程间通信(一.初识进程间通信、匿名管道与命名管道、共享内存)
Linux 的进程间通信:管道
本文介绍了管道(pipe)在Linux系统中的实现方式,从三个方面进行了详细阐述:管道的原理,命名管道,以及通过匿名管道进行的进程间通信。同时,文章还探讨了管道在Linux系统中的实际应用,包括shell脚本、cron任务以及Linux中的各种守护进程等。
邹立巍
2017/07/31
8.5K3
Linux 的进程间通信:管道
进程间通信(一)/管道
有时候需要多进程协同,让每一个进程专注于自己的事,然后把结果交给另外一个进程去处理。比如使用管道,让多进程协同,简单的有:
二肥是只大懒蓝猫
2023/03/30
5290
进程间通信(一)/管道
Linux 进程间通信之管道(pipe)、命名管道(FIFO)与信号(Signal)
管道可用于具有亲缘关系进程间的通信,有名管道克服了管道没有名字的限制,因此,除具有管道所具有的功能外,它还允许无亲缘关系进程间的通信。
用户6543014
2020/12/21
2.6K0
Linux 进程间通信之管道(pipe)、命名管道(FIFO)与信号(Signal)
【linux学习指南】 进程间通信&&匿名管道&&理解管道的本质
在 Unix/Linux 系统中,我们可以使用 fork() 系统调用来创建子进程,并通过共享管道(pipe)进行进程间通信。下面是使用 fork() 来共享管道的原理:
学习起来吧
2024/11/18
1510
【linux学习指南】 进程间通信&&匿名管道&&理解管道的本质
进程间通信
什么是管道? 可以理解为内存中的一个缓冲区,用于将某个进程的数据流导入,由某一个进程导出,实现通信。 再通俗的说,看图:
看、未来
2020/08/26
9030
进程间通信
C++进程间通信 详解2
Linux环境下,进程地址空间相互独立,每个进程各自有不同的用户地址空间。任何一个进程的全局变量在另一个进程中都看不到,所以进程和进程之间不能相互访问。
Freedom123
2024/03/29
9830
C++进程间通信 详解2
进程通信(一)无名管道和有名管道
《王道考研复习指导》 管道通信是消息传递的一种特殊方式。所谓“管道”,是指用于连接一个读进程和一个写进程以实现它们之间通信的一个共享文件,又名pipe文件。向管道(共享文件)提供输入的发送进程(即写进程),以字符流的形式将大量的数据送入(写)管道;而接受管道输出的接受进程(即读进程),则从管道接受(读)数据。为了协调双方的通信,管道机制必须提供一下三个方面的协调能力:互斥、同步和确定对方存在。 下面以linux的管道为例进行说明。在linux中,管道是一种频繁使用的通信机制。从本质上讲,管道也是一种文件,但它又和一般的文件有所不同,管道可以克服使用文件通信的两个问题,具体表现为: 1)限制管道的大小。实际上,管道是一个固定大小的缓冲区。在Linux中,该缓冲区的大小为4KB,使得它不像文件那样不加检验的增长。使用单个固定缓冲区也会带来问题,比如在写管道时可能变满,当这种情况发生时,随后对写管道的write()调用将默认的阻塞,等待某些数据被读取,以便腾出足够的空间供write()调用写。 2)读进程也可能工作的比写进程快。当所有当前进程数据已被读走时,管道变空。当这种情况发生时,一个随后的read()调用将默认设置为阻塞,等待某些数据被写入,这解决了read()调用返回文件结束的问题。 注意 :从管道读数据是一次性操作,数据一旦被读走,它就从管道中被抛弃,释放空间以便写更多的数据。管道只能采用半双工通信,即在某一时刻只能单向传输。要实现父子进程双方互动,需要定义两个管道。
lexingsen
2022/02/24
1.6K0
进程通信(一)无名管道和有名管道
从零开始:实现进程间管道通信的实例
匿名管道(Anonymous Pipe)是进程间通信(IPC)的一种机制,它主要用于本地父子进程之间的通信。
绝活蛋炒饭
2024/12/16
2180
从零开始:实现进程间管道通信的实例
进程间通信Linux
首先自己要用用户层缓冲区,还得把用户层缓冲区拷贝到管道里,(从键盘里输入数据到用户层缓冲区里面),然后用户层缓冲区通过系统调用(write)写到管道里,然后再通过read系统调用,被对方(读端)读取,就要从管道拷贝到读端,然后再显示到显示器上。
ljw695
2024/11/15
2880
进程间通信Linux
【Linux】基于管道进行进程间通信
进程间通信是两个或者多个进程实现数据层面的交换。但是由于进程间存在独立性,所以导致进程间通信的成本比较高。
YoungMLet
2024/03/01
2620
【Linux】基于管道进行进程间通信
深入了解linux系统—— 进程间通信之管道
本篇博客所涉及到的代码一同步到本人gitee:testfifo · 迟来的grown/linux - 码云 - 开源中国
星辰与你
2025/06/08
760
深入了解linux系统—— 进程间通信之管道
C语言第四章(进程间的通信,管道通信,pipe()函数)
本文讲解的是C语言的进程之间的通信,这里讲解的是管道通信,和相关的函数pipe().
GeekLiHua
2025/01/21
2070
Linux进程间通信之管道
1,进程间通信 (IPC ) Inter-Process Communication   比较好理解概念的就是进程间通信就是在不同进程之间传播或交换信息。 2,linux下IPC机制的分类:管道、信号、共享内存、消息队列、信号量、套接字 3,这篇主要说说管道:本质是文件,其他理论什么的网上已经有一大堆了,我就只写一点用法吧。 3.1 特点      1)管道是最古老的IPC,但目前很少使用      2)以文件做交互的媒介,管道分为有名管道和无名管道      3)历史上的管道通常是指半双工管道 3.2 管
xcywt
2018/01/11
2.7K0
Linux进程间通信之管道
【Linux】进程间通信——管道
而我们所说的不同通信种类本质就是:上面所说的资源,是OS中的哪一个模块提供的。如文件系统提供的叫管道通信;OS对应的System V模块提供的…
平凡的人1
2023/10/15
3400
【Linux】进程间通信——管道
进程间通信--管道
有时候我们需要多个进程协同的去完成某种任务,因此需要进程之间能够相互通信。但是进程之间具有独立性,要让进程之间能通信就要打破这种独立性,所以通信的代价一定是不低的。打破这种独立性就是要让两个不同的进程看到同一份资源,这个资源只能由操作系统来提供。因为如果是某个进程来提供因为独立性,这个资源就只能被提供这个资源的进程看到。
始终学不会
2023/10/17
2450
进程间通信--管道
Linux进程通信之管道解析
管道是 UNIX系统 IPC的最古老的形式,所有的UNIX系统都提供此种通信。所谓的管道,也就是内核里面的一串缓存,从管道的一段写入的数据,实际上是缓存在内核中的,令一端读取,也就是从内核中读取这段数据。对于管道传输的数据是无格式的流且大小受限。对于管道来说,也分为匿名管道和命名管道,其中命名管道也被叫做 FIFO,下面则分别阐述这两种管道。
wenzid
2021/07/20
1.4K0
Linux进程通信之管道解析
推荐阅读
相关推荐
Linux进程间通信--管道(pipe和fifo)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档