ROS 2 砍掉了 ROS 1 的中心节点 master，节点之间靠 DDS 中间件自动互相发现：每个节点一启动就往局域网发广播，“我在这儿，我发布/订阅这些话题”，其他节点听到后直接点对点收发数据。取值含义效果= 1只走本机回环网卡（127.0.0.1）只允许同一台电脑内部的节点通信= 0使用全部网卡本机节点可以和局域网里其他机器互相发现、通信hit_probability = 0.55, --

一台移动机器人身上有一堆坐标系：地图系map、里程计系odom、底盘系、激光雷达系laser……激光雷达看到障碍物在"我前方 2 米"，导航模块想知道的是"它在地图的哪个位置"。TF（transform 的缩写，ROS 2 中实际是 tf2）就是负责在这些坐标系之间做换算的系统。TF 的几个核心规则：所有坐标系组织成一棵树（TF Tree）：每个坐标系有且仅有一个父系，不允许成环；每条"边"是一个

粒子贫化（Particle Impoverishment / Particle Depletion）是指在粒子滤波定位过程中，经过多轮重采样后，粒子群中的粒子越来越"雷同"，多样性丧失，导致滤波器失去纠错能力和鲁棒性的现象。

Deskew（De-skewing）即运动畸变校正。激光雷达采集一帧点云需要时间（例如10Hz雷达需100ms），在此期间若机器人发生运动，先发射的点与后发射的点实际上是在不同位姿下采集的。直接将它们视为同一时刻的数据，会导致点云“拖影”或变形，这就是运动畸变。在ROS2 Python客户端库（rclpy）中，“Raw”通常指绕过序列化/反序列化的原始字节流处理模式。常规模式：订阅者收到消息后，r

本周杂七杂八，没有什么大进展，先是换了激光雷达，又发现两个相同型号的激光雷达同时使用会有冲突，这个给解决了激光雷达又坏了，没办法，只得将原来使用的激光雷达换上来。接着就是进行激光雷达外参标定，尝试了各种标定方法，最后暂且使用了墙面拟合标定的数据。接下来就是装读码器并读取二维码数据等等...

这周很疲惫。为了将机器人接入上层调度系统，刚修好调度端目标点收发的时序问题，导航层又暴露出新的逻辑漏洞；导航状态机对齐了，调度端的反馈机制又出岔子。一个人搞的要崩溃了。本周没有什么新东西，积累一些经验叭！

创建一个专用的 Async Delivery Thread，负责从发送队列中取数据并通过传输层（UDP / Shared Memory）发出。没有预算上限的异步发布，就是在用无限 CPU 购买你可能并不需要的额外性能。解决 Fast DDS 异步模式导致的 CPU 激增，不能靠单一手段，而需要一套。不同 Writer 可以有不同的发布模式和流控策略，不必一刀切。没有流控的异步发送线程就像一个没有油

消费端太慢 → 缓冲区堆满 → 压力反向传导回生产端 → 生产端被迫停发。生活类比：你拿水管往杯子里灌水，杯子满了水溢出来。如果杯子有个密封盖（缓冲区有限），水灌不进去，你就被迫关水龙头——这个"被迫关"就是反压。在 DDS 里，Reliable 模式 + 有限队列深度Publisher 发数据进队列Subscriber 消费后回 ACK如果 Subscriber 太慢，ACK 迟迟不来，队列堆满

可以用AI写一个更详细且偏向硬件的监控脚本，对工控机的电源轨、内核状态、串口、总线等进行持续采样并写入日志，以便崩溃后回溯。的方式对深度点云进行稀疏化：将点云所在的三维空间划分为若干个边长为 5 cm（可根据需求调整）的。注意：不同的系统监控会产生大量日志数据，在使用AI写的脚本的时候要特别注意。，将同一体素内所有点的坐标取均值，最终仅用一个点来代表该体素内的所有点。，两帧数据在空间中产生了微小的

RELIABLE 模式可能让你收到的是几百毫秒前的"旧帧"，而 BEST_EFFORT 直接丢弃过期数据，拿到的是最新的。RELIABLE 模式下，一旦网络抖动丢包，DDS 会等待重传，导致数据堆积、回调阻塞，rviz中画面卡死。控制调参时，参数众多且相互耦合，单靠"改一个跑一次"效率较低。，在导航运行时自动采集每个参数在每个时刻的值，最终将各时刻的参数值连线，生成一张。采集完成后，用脚本将数据绘