一、调参利器参数波动图控制调参时参数众多且相互耦合单靠改一个跑一次效率较低。这里分享一个实用思路用 AI 写一个参数记录脚本在导航运行时自动采集每个参数在每个时刻的值最终将各时刻的参数值连线生成一张参数波动图。如此可清晰观察到每个参数在导航过程中的动态变化趋势快速定位哪个参数在什么阶段出现异常波动。实现思路参考# 伪代码示意可让AI生成完整版本 import rclpy from rclpy.node import Node import csv, time class ParamLogger(Node): def __init__(self): super().__init__(param_logger) self.timer self.create_timer(0.5, self.log_params) # 每0.5s采集一次 self.csv_file open(param_log.csv, w, newline) # 通过 ros2 param 接口动态读取目标节点的参数 ... def log_params(self): # 记录时间戳 各参数当前值 ...采集完成后用脚本将数据绘制为多子图折线图横轴为时间纵轴为参数值很清晰。二、系统意外重启启用 journald 持久化存储调试机器人时最怕的就是系统突然崩溃/断电日志全丢根本不知道崩溃前发生了什么。解决方案启用 systemd-journald 的持久化存储实时追踪系统日志即使意外关机也能保留本次启动的完整日志。2.1 开启持久化# 创建持久化日志目录 sudo mkdir -p /var/log/journal # 设置正确的权限和属性 sudo systemd-tmpfiles --create --prefix /var/log/journal # 重启 journald 使配置生效 sudo systemctl restart systemd-journald2.2 验证是否生效# 检查日志存储位置应显示 /var/log/journal/... 而非 /run/log/journal/... journalctl --header | head -5补充如果路径是/run/log/journal说明仍在内存中重启即丢失看到/var/log/journal才表示持久化成功。2.3 崩溃后查看上一次启动的日志# 查看上一次启动的完整日志 journalctl -b -1 # 查看上次启动的最后 200 条错误日志warning 及以上逆序不分页 journalctl -b -1 -p warning..emerg -n 200 -r --no-pager # 从崩溃点往前追溯逆序查看最后 200 条 journalctl -b -1 -r -n 200 --no-pager更多实用命令# 按时间范围查看 journalctl -b -1 --since 2026-07-21 14:00 --until 2026-07-21 14:30 # 只看某个服务的日志 journalctl -b -1 -u nav2_controller # 实时跟踪当前日志类似 tail -f journalctl -f # 查看磁盘上日志占用空间 journalctl --disk-usage # 手动清理只保留最近 3 天 sudo journalctl --vacuum-time3d三、journald 常用配置主配置文件路径/etc/systemd/journald.conf[Journal] # 日志最大占用磁盘空间所有 journal 文件总和 SystemMaxUse2G # 磁盘至少保留的可用空间防止日志撑满磁盘 SystemKeepFree1G # 日志最长保留时间超期自动清理 MaxRetentionSec30day # 刷盘间隔日志从内存缓冲写入磁盘的频率 SyncIntervalSec5min # 是否压缩旧日志节省磁盘空间推荐开启 Compressyes修改后重启生效sudo systemctl restart systemd-journald验证当前运行配置journalctl --show-cursor --header | head -10补充机器人主控如树莓派、RK3576 等磁盘空间有限建议将SystemMaxUse设为500M~1GMaxRetentionSec设为7day避免日志撑爆存储。四、流式传感器 QoS 设置BEST_EFFORT vs RELIABLE深度摄像头、激光雷达等流式传感器在 ROS2 中发布话题时QoS 的 Reliability 策略选择非常关键策略行为适用场景RELIABLE保证每帧数据送达丢包会重传配置参数、服务调用、低频关键指令BEST_EFFORT尽最大努力交付丢就丢不重传深度图、点云、IMU 等高频流式数据为什么流式传感器要用 BEST_EFFORT避免卡顿RELIABLE 模式下一旦网络抖动丢包DDS 会等待重传导致数据堆积、回调阻塞rviz中画面卡死。保证实时性传感器 30fps 持续出数据我们只关心最新一帧。RELIABLE 模式可能让你收到的是几百毫秒前的旧帧而 BEST_EFFORT 直接丢弃过期数据拿到的是最新的。降低 CPU/内存开销无需维护重传队列和确认机制。代码示例from rclpy.qos import QoSProfile, ReliabilityPolicy, HistoryPolicy # 订阅深度图像时使用 BEST_EFFORT sensor_qos QoSProfile( reliabilityReliabilityPolicy.BEST_EFFORT, historyHistoryPolicy.KEEP_LAST, depth1 # 只保留最新1帧进一步降低延迟 ) self.subscription self.create_subscription( Image, /camera/depth/image_raw, self.depth_callback, sensor_qos )补充如果发布端用 BEST_EFFORT订阅端用 RELIABLE两者 QoS 不兼容订阅端将收不到任何消息且不会报错排查话题有数据但订阅不到时记得检查下 QoS 是否匹配。