ROS多节点LIO-SAM并行运行解决方案-代码聚汇网

ROS多节点LIO-SAM并行运行解决方案

乐正雕漆·2026-08-18·阅读 22 GEO检测（免费）

ROSLIO-SAMSLAM

|难度：普通|阅读约 11 分钟

1. 问题背景与需求分析

在机器人SLAM（Simultaneous Localization and Mapping）开发中，LIO-SAM（Lidar Inertial Odometry via Smoothing and Mapping）是一个广泛使用的激光雷达惯性里程计框架。其建图节点（liosam_mapping）通常作为ROS（Robot Operating System）系统中的核心节点运行。但在实际多机器人协同或复杂系统集成时，我们经常遇到一个典型问题：无法在同一台主控计算机（master）上运行多个liosam建图节点实例。

这个限制主要源于ROS 1.0的命名空间机制和liosam代码的默认设计。当尝试启动第二个节点时，系统会报错提示节点名称冲突，因为所有liosam节点默认都注册为相同的名称（如/laserMapping）。这种设计在单机器人系统中没有问题，但在以下场景会产生严重限制：

多机器人协同建图：当需要多个机器人同时构建同一环境地图时
算法对比测试：需要并行运行不同参数配置的liosam实例进行效果对比
系统冗余设计：为提高可靠性部署主备双节点运行

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. ROS命名空间机制深度解析

2.1 ROS节点命名规则

ROS中的每个节点都必须具有唯一名称，名称解析遵循以下规则：

全局名称：以/开头（如/laserMapping）
相对名称：不以/开头（如laserMapping）
私有名称：以~开头（如~laserMapping）

默认情况下，liosam使用全局名称注册其所有话题和服务，这是导致多实例冲突的根本原因。

2.2 命名空间解决方案对比

解决多实例冲突主要有三种技术路线：

方案	实现方式	优点	缺点
重映射(remap)	启动时通过`__name`参数重命名节点	简单直接	需要维护多个启动文件
命名空间(namespace)	为节点组创建独立命名空间	逻辑清晰	需要修改代码支持相对名称
容器化	每个实例运行在独立容器中	完全隔离	资源开销大

对于liosam这种需要深度定制的情况，命名空间方案最为合适。它能在代码层面彻底解决问题，而不是依赖外部配置。

3. liosam代码改造实战

3.1 关键文件定位

需要修改的主要文件包括：

src/laserMapping.cpp - 主建图节点实现
launch/run.launch - 启动文件
config/params.yaml - 参数配置文件

3.2 核心代码修改步骤

3.2.1 话题和服务名称改造

原始代码中的全局名称声明：

cpp复制ros::Publisher pubLaserCloudSurround = nh.advertise<sensor_msgs::PointCloud2>("/laser_cloud_surround", 1);

修改为相对名称：

cpp复制ros::Publisher pubLaserCloudSurround = nh.advertise<sensor_msgs::PointCloud2>("laser_cloud_surround", 1);

这种修改需要应用到所有话题和服务声明处，大约涉及20-30处代码变更。

3.2.2 参数加载调整

原始参数加载方式：

cpp复制ros::param::get("/laserMapping/mapFilterSize", mapFilterSize);

修改为：

cpp复制ros::param::get("~mapFilterSize", mapFilterSize);

3.2.3 启动文件适配

修改后的launch文件示例：

xml复制<launch>
  <group ns="robot1">
    <node pkg="liosam" type="liosam_mapping" name="laserMapping" output="screen">
      <rosparam command="load" file="$(find liosam)/config/params.yaml" />
    </node>
  </group>
  
  <group ns="robot2">
    <node pkg="liosam" type="liosam_mapping" name="laserMapping" output="screen">
      <rosparam command="load" file="$(find liosam)/config/params.yaml" />
    </node>
  </group>
</launch>

3.3 参数文件隔离处理

为避免参数冲突，建议为每个实例创建独立的参数文件：

code复制config/
  params_robot1.yaml
  params_robot2.yaml

然后在launch文件中分别加载：

xml复制<rosparam command="load" file="$(find liosam)/config/params_robot1.yaml" />

4. 多节点运行验证与调试

4.1 基础功能验证

启动两个节点后，检查以下关键指标：

bash复制rostopic list
# 应看到类似输出：
# /robot1/laser_cloud_surround
# /robot2/laser_cloud_surround
# ...其他话题...

rosnode list
# 应看到：
# /robot1/laserMapping
# /robot2/laserMapping

4.2 常见问题排查

问题1：话题无法互通

现象：节点启动正常但数据不流动
检查：确保所有订阅者都使用相对名称
解决：在回调函数中统一使用ros::NodeHandle的私有句柄

问题2：TF树冲突

现象：出现TF_REPEATED_DATA警告
解决：为每个实例配置不同的frame_id前缀：

yaml复制# params_robot1.yaml
frame_id: "robot1_map"

问题3：资源竞争

现象：系统卡顿或崩溃
解决：调整每个节点的线程数：

cpp复制ros::MultiThreadedSpinner spinner(2); // 原为4

5. 性能优化与高级配置

5.1 资源分配策略

当运行多个liosam实例时，需要合理分配计算资源：

资源类型	单节点配置	双节点建议	调整方式
CPU核心	4线程	各2线程	修改spinner参数
内存	2GB	各1.5GB	限制点云队列大小
GPU	100%	各50%	使用CUDA流隔离

5.2 通信优化技巧

话题压缩：对点云话题启用压缩

cpp复制ros::Publisher pub = nh.advertise<sensor_msgs::PointCloud2>("cloud", 1, true);

QoS配置：调整服务质量策略

cpp复制ros::Subscriber sub = nh.subscribe("imu", 100, &IMUHandler::handler, this, 
                                  ros::TransportHints().tcpNoDelay());

零拷贝优化：使用shared_ptr传递大数据

cpp复制void callback(const sensor_msgs::PointCloud2ConstPtr& msg) {
  // 直接使用指针，避免拷贝
}

6. 扩展应用场景

6.1 多机器人协同建图

通过命名空间隔离，可以实现：

多个机器人在同一物理空间独立建图
中央服务器汇总各节点地图
动态负载均衡（将计算密集任务分配给空闲节点）

6.2 算法参数对比测试

典型应用流程：

启动两个不同参数配置的liosam实例
使用相同的输入话题（通过remap实现）
实时对比两者的轨迹精度和地图质量
自动记录性能指标（如ATE、RPE）

6.3 容错冗余设计

实现主备节点热切换：

主节点和备用节点同时运行
监控主节点健康状态
通过dynamic_reconfigure实现无缝切换
确保TF树的连续性

我在实际部署中发现，这种改造后的系统可以稳定支持3-4个liosam实例同时运行在i7-11800H处理器上，平均CPU利用率保持在70%以下。关键是要合理设置每个节点的点云处理频率和优化器迭代次数。一个实用的技巧是为不同节点设置不同的处理频率（如主节点10Hz，备用节点5Hz），这样可以显著降低系统负载而不明显影响建图质量。