<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>ROS on YHY Study Website</title><link>https://ryan.0412.online/en/tags/ros/</link><description>Recent content in ROS on YHY Study Website</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Wed, 30 Sep 2026 21:25:01 +0800</lastBuildDate><atom:link href="https://ryan.0412.online/en/tags/ros/index.xml" rel="self" type="application/rss+xml"/><item><title>Migrating and Consolidating ROS Workspaces</title><link>https://ryan.0412.online/en/blog/ros-workspace-migration/</link><pubDate>Wed, 26 Aug 2026 00:00:00 +0000</pubDate><guid>https://ryan.0412.online/en/blog/ros-workspace-migration/</guid><description>&lt;p&gt;When moving a ROS robot to a new computer or disk, or sharing one codebase across several robots, the easiest trap is not copying the files: it is &lt;strong&gt;leaving the old workspace source chain in the shell&lt;/strong&gt;. When several catkin workspaces overlap on the same machine, especially with identically named packages, you may not discover which copy is actually running until something fails.&lt;/p&gt;
&lt;p&gt;These are my notes from consolidating and migrating workspaces: understand how catkin finds packages, simplify the source chain in order, and finally restore hardware bindings such as udev rules.&lt;/p&gt;</description></item></channel></rss>