从ROS1到ROS2 Dashing：跨越鸿沟的安装与迁移实战

1. 为什么需要从ROS1迁移到ROS2 Dashing？

作为一个从ROS1时代走过来的老开发者，我至今还记得第一次用ROS1搭建机器人时的兴奋感。那时候觉得，能用几行代码就让小乌龟在屏幕上爬行简直是魔法。但随着项目复杂度提升，ROS1的局限性逐渐暴露——尤其是在2018年参与一个工业分拣机器人项目时，我们需要协调3台机械臂和5台AGV小车，ROS1的单Master架构直接成了性能瓶颈。

ROS2 Dashing的设计正是为了解决这些痛点。它用DDS（Data Distribution Service）替代了ROS1的Master中心化架构，就像把单车道乡村公路升级成了立交桥。实测下来，在多机器人通信场景中，ROS2的延迟比ROS1降低了60%以上。安全性方面更是质的飞跃——现在你可以像网上银行一样为通信通道设置加密和权限控制。

不过要注意，ROS2不是简单的版本升级，而是一次架构革命。这就好比从功能手机切换到智能手机，虽然打电话还是核心功能，但整个交互逻辑都变了。我在第一次迁移项目时，就因为在ROS2里习惯性找roscore命令而卡了半天。

2. 双系统共存的环境配置实战

2.1 基础安装避坑指南

很多教程会直接让你安装ROS2，但根据我的踩坑经验，一定要先做好这些准备：

bash复制# 必须设置的locale配置（中文环境常见问题）
sudo locale-gen en_US en_US.UTF-8
sudo update-locale LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8
export LANG=en_US.UTF-8

安装时最容易被忽略的是时区设置。有次我在UTC+8时区编译节点，结果和UTC时区的同事死活连不上，排查了两天才发现是DDS的默认时间同步策略导致的。建议安装后立即执行：

bash复制sudo apt install chrony
timedatectl set-ntp true

对于国内开发者，更推荐使用清华源加速安装：

bash复制sudo sh -c '. /etc/lsb-release && echo "deb https://mirrors.tuna.tsinghua.edu.cn/ros2/ubuntu/ `lsb_release -cs` main" > /etc/apt/sources.list.d/ros2-latest.list'

2.2 与ROS1的和平共处方案

我强烈建议保留ROS1环境进行过渡测试。通过这个智能切换脚本，可以优雅地管理双环境：

bash复制# 在~/.bashrc中添加以下内容
ros_switch() {
    if [ "$1" = "1" ]; then
        source /opt/ros/melodic/setup.bash
        echo "ROS melodic activated"
    elif [ "$1" = "2" ]; then
        source /opt/ros/dashing/setup.bash
        echo "ROS2 dashing activated"
    else
        echo "Usage: ros_switch 1|2"
    fi
}

实际使用中，我发现有些ROS1的包会在ROS2环境里产生冲突。这时候可以用docker容器隔离运行环境，这是我常用的启动命令：

bash复制docker run -it --net=host --env="DISPLAY" --volume="$HOME/.Xauthority:/root/.Xauthority:rw" osrf/ros:melodic-desktop-full

3. 核心概念迁移的思维转换

3.1 从Master到DDS的认知升级

刚开始用ROS2时，我最不习惯的就是找不到roscore了。后来才明白，DDS的分布式架构就像微信群聊——每个节点都是平等的参与者，不需要群主（Master）也能互相通信。这种设计带来的优势非常明显：

1. 单点故障消除：Master崩溃导致全系统瘫痪成为历史
2. 网络拓扑更灵活：支持NAT穿越，适合IoT设备
3. 服务质量(QoS)可配置：可以精确控制丢包策略

但要注意，DDS也引入了新概念。比如Domain ID就相当于微信群号，只有相同Domain ID的节点才能通信。有次调试时忘了设置，两个节点明明在同一台机器却互不可见：

bash复制export ROS_DOMAIN_ID=42  # 所有设备必须相同

3.2 消息通信的深层变化

ROS2的消息机制表面看和ROS1相似，但底层实现完全不同。这个差异在传输图片消息时特别明显——ROS1的sensor_msgs/Image在ROS2里需要额外配置QoS策略：

python复制# ROS2必须显式设置QoS
image_pub = node.create_publisher(Image, 'camera/image', 
    qos_profile=qos_profile_sensor_data)

实测发现，默认QoS设置下，ROS2的图像传输延迟比ROS1高20ms左右。但经过优化后，反而能降低30%的延迟。这是我总结的调优公式：

code复制可靠传输：qos_profile_reliable_latched
实时数据：qos_profile_sensor_data
尽力传输：qos_profile_services_default

4. ros1_bridge的实战应用

4.1 搭建混合通信桥梁

ros1_bridge是迁移过程中的救命稻草，它就像个翻译官，让ROS1和ROS2的节点能互相聊天。但编译时有个大坑——必须同时source两个环境：

bash复制# 关键步骤！
source /opt/ros/melodic/setup.bash
source /opt/ros/dashing/setup.bash
colcon build --symlink-install --packages-select ros1_bridge

我在实际项目中发现，不是所有消息类型都能自动桥接。复杂消息需要手动声明映射关系，比如：

bash复制ros2 run ros1_bridge dynamic_bridge --print-pairs | grep "sensor_msgs/Image"

4.2 性能优化技巧

默认配置下，桥接转发会有约50ms的延迟。通过以下方法可以优化：

1. 提升线程优先级：

bash复制sudo apt install rt-tests
cyclictest --mlockall --smp --priority=80 --interval=100 --distance=0

2. 调整DDS配置：

xml复制<!-- 在XML配置文件中添加 -->
<participant>
    <rtps>
        <sendBuffers>
            <physicalSendBuffers>32</physicalSendBuffers>
        </sendBuffers>
    </rtps>
</participant>

3. 选择性桥接：只转发必要话题，减少性能开销

5. 典型迁移案例解析

去年我将一个仓储物流系统从ROS1迁移到ROS2，整个过程耗时3个月。最大的挑战是导航栈的移植，这里分享关键步骤：

1. 消息适配层：为所有自定义消息创建ROS2版本
2. 依赖项重构：将catkin_make改为colcon构建
3. 线程模型改造：ROS1的全局回调队列要改为ROS2的多线程模型
4. 生命周期管理：实现rclcpp_lifecycle的节点状态机

性能对比结果令人惊喜：

• 网络断连恢复时间从15s缩短到2s
• CPU利用率降低40%
• 通信带宽节省35%

但也要注意，不是所有ROS1包都能平滑迁移。比如gmapping这类严重依赖ROS1架构的算法，建议直接改用ROS2原生实现如slam_toolbox。