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

创建一个专用的 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中画面卡死。控制调参时，参数众多且相互耦合，单靠"改一个跑一次"效率较低。，在导航运行时自动采集每个参数在每个时刻的值，最终将各时刻的参数值连线，生成一张。采集完成后，用脚本将数据绘

在默认情况下，节点与节点之间的通讯只有在运行了ROS核心库的环境下才能够实现，与非ROS环境通信就需要rosbridge进行消息传递，例如，使用 roslibjs 在浏览器中实时显示雷达点云、摄像头画面或机器人状态、开发手机APP远程控制机器人、将本地ROS节点的数据传输至云端服务器处理等等。目前只是通过粗暴的定期重启rosbridge来避免内存泄漏，这个解决办法只能治标，不能满足大量数据高实时性

今天下午在进行激光雷达标定，标定软件不太好用，运行出来还是各种bug，好不容易用AI修复好了结果在标定的时候怎么选墙面方向都不对，这里解释一下，这个标定算法是通过将激光雷达的数据与旁边的墙面拟合计算出激光雷达的朝向角度，所以在进行墙面选取的时候要选取正确的墙面。然而，我实际在标定的时候，明明墙面在小车的右侧并且与X轴平行，当我把墙面选取成右侧的时候标定出来的数据反而是错误的。但是我们又怎么知道激光

各个坐标系的转换，不同的传感器会有不同的坐标，要让他们的数据在同一坐标系下表示，就需要使用到坐标转换，例如我装了个新的激光雷达，不同的坐标系下，点云的坐标表示不同，我们把视角切换到激光雷达自身，以雷达自身为原点，建立二维坐标系，此时的点云坐标是在雷达坐标系下表示的，其含义是：对于激光雷达来说，点云在激光雷达的哪个方向。为什么要使用坐标系的转换？AI：模块化设计，用AI写代码之前，记得告诉他在写代码