ROS2學習筆記之創建工作空間篇
學習目標：創建一個工作空間，並對如果進行開發和測試有一個全面的瞭解
背景
工作空間是一個包含ROS2功能包的一個文件夾。在我們使用ROS2的時候我們必須在終端source安裝目錄的工作空間的配置文件，這樣我們纔可以正常使用ROS2的各種功能。
關於ROS的工作空間，我們稱ROS安裝時候系統的工作空間爲底層的工作空間，我們可以新建一個新的工作空間，在這個空間中編寫自己的功能包，不對安裝的底層工作空間產生干擾。底層的工作空間需要包含新建工作空間的所有依賴，這樣就形成了一種類似繼承的關係。子工作空間會覆蓋父工作空間的包。我們可以建立多個工作空間，他們的關係像一棟摟一樣，最底層爲系統安裝的工作空間，每建立一個新的工作空間依次往上，每一層工作空間繼承他的上一場工作空間。
前期準備
首先需要安裝git
sudo apt install git
然後我們還需要安裝編譯工具colcon
sudo apt install python3-colcon-common-extensions
安裝rosdep
sudo apt install python-rosdep
學習內容
1. Source ROS 2 環境變量
在這篇教程中我們以系統安裝的工作空間作爲底層(並不是底層的工作空間一定要是系統的工作空間，前面我們說過也可以是依次繼承下來的工作空間)
source /opt/ros/eloquent/setup.bash
2. 創建一個新的文件夾
我們創建一個新的文件夾作爲新的工作空間的開始
給每個新的工作空間創建一個新的文件夾是一個好習慣，取上面名字無關緊要，但是最好能從這個名字上看出這個工作空間是幹什麼的。我們取名dev_ws意爲development workspace
mkdir dev_ws
mkdir dev_ws/src
cd dev_ws/src
將功能包放入src也是一個比較好的習慣。我們建立一個工作空間同時建立一個src文件夾，然後進入這個文件夾內。
3. 下載一個簡單的例子
在接下來的教程當中我們會自己建立功能包，但是這本教程中我們主要練習如何將現有的包放入到工作空間中。ROS2改動還是不少，我們一步一來。
我們接下來會使用一個已有的包叫做ros_tutorials和我們之前接觸的turtlesim差不多
我們下載例程需要的代碼，通過-b選項我們選擇我們當前ros版本的分支。注意這個操作要在dev_ws/src文件夾下執行
git clone https://github.com/ros/ros_tutorials.git -b eloquent-devel
現在我們已經下載了ros_tutorials，通過下面命令查看功能包中的內容
ls ros_tutorials
我們看到該功能包的內容如下
roscpp_tutorials rospy_tutorials ros_tutorials turtlesim
現在我們已經將一個包放入了工作空間，但是目前這個工作空間還不是一個完整的工作空間，我們還需要解決依賴關係。
4. 解決依賴關係
在我們對工作空間進行編譯之前，我們首先需要解決相關功能包的依賴關係。
雖然我們可能已經擁有了我們下載的功能包的所有的依賴，但是每次克隆下載包的時候檢查相關依賴是一個好習慣。我們並不希望在編譯了很長時間過後突然報錯。
我們在工作空間的根目錄(例如dev_ws)運行下面的命令可以檢查安裝工作空間中的包的依賴。
sudo rosdep install -i --from-path src --rosdistro eloquent -y
如果我們已經安裝了所有的依賴，控制檯會返回下面的結果，提示我們已經按照了所有的依賴。
#All required rosdeps installed successfully
每個包會在package.xml 聲明相關的依賴，這個命令會根據這個文件檢查是否所有依賴都安裝了。
5. 使用colcon編譯工作空間
在我們檢查依賴安裝過後，我們就可以在工作空間的根目錄(例如dev_ws)通過下面的命令編譯工作空間了，
colcon build
終端顯示下面的消息表示編譯成功
Starting >>> turtlesim
Finished <<< turtlesim [5.49s]
Summary: 1 package finished [5.58s]
colcon build其他一些參數
--packages-up-to編譯我們指定的包，及其所有依賴項，而不是整個工作區（節省時間）--symlink-install避免了每次更改Python腳本時都需要重新編譯--event-handlers console_direct+在編譯時是否在控制檯顯示輸出（如果不顯示我們還是可以在log文件夾看到輸出）
編譯完成過後我們通過下面命令查看工作空間
ls ~/dev_ws
我們可以看到編譯新建了幾個文件夾
build install log src
install文件夾是當前工作空間存放配置文件的地方，這一點和ros1不同，我們通過source相關配置文件可以加載當前工作空間。
6. 加載新建的工作空間
有一點值得注意在我們source我們自己的工作空間的時候不要在編譯工作空間的終端進行，這可以造成一些比較麻煩的問題。
新打開一個終端，我們首先source系統的工作空間，將其作爲底層，如果我們將這句話寫在了.bashrc中我們就不需要再次.bashrc了
source /opt/ros/eloquent/setup.bash
切換到工作空間內
cd dev_ws
在工作空間的根目錄我們source新的工作空間，這相當於第二層(overlay)
source install/local_setup.bash
關於
sourceros1和ros2有很大的不同，在install目錄下會有local_setup和setup兩個文件。local_setup只會把當前工作空間中的可用包添加到環境當中，setup則會把新建該工作空間時候的底層的工作空間也加入到環境當中，這樣就可用同時使用兩個工作空間中的包。
因此，先sourceROS2安裝時系統的setup，然後再sourcedev_ws的local_setup，和sourcedev_ws的setup的效果是相同的，應爲dev_ws這個工作空間的創建時的底層就是系統的setup
對於存在多個工作空間的情況這種區別就會體現出來，官網對於新的工作空間叫overlay，也就是這個一個每個工作空間之間是存在覆蓋累計的情況。
個人推薦首先source系統，然後對於自己創建的工作空間選擇local_setup這樣就會減少自己建立的多個工作空間之間的干擾。這解決了ros1上一個很頭疼的問題。
現在我們可以在覆蓋層的工作空間(overlay)運行turtlesim
ros2 run turtlesim turtlesim_node
現在有關新的問題我們運行的這個turtlesim是系統安裝的還是剛剛編譯的。
我們通過修改上層的turtlesim，以便我們可以觀察效果:
- 修改並且重新編譯時不
source系統的工作空間 - 修改並且重新編譯時
source系統的工作空間
7. 修改新建的工作空間中的包
我們可以修改turtlesim包中海龜界面顯示的標題來進行這個實驗。
我們打開~/dev_ws/src/ros_tutorials/turtlesim/src中的turtle_frame.cpp
我們找打52行的一個函數 setWindowTitle("TurtleSim");更改其中的”TurtleSim” 爲”MyTurtleSim”後保存退出
我們返回我們剛剛編譯的終端再次colcon build進行編譯
然後我們返回剛剛我們source過我們新建的工作空間的終端，重新運行海龜。
ros2 run turtlesim turtlesim_node
我們可以看到窗口的標題欄現在窗口的標題變爲了“MyTurtleSim”
儘管我們之前成功source了系統安裝的部分，但是作爲新source的工作空間會優先於之前的，這就是覆蓋的概念。
我們爲了驗證系統底層的包還是完成的，我們打開一個新的終端，這時候只source系統的配置文件，然後我們再次運行海龜
ros2 run turtlesim turtlesim_node
通過標題我們可以看到我們修改的部分並不影響底層部分的功能。
總結
在這個例程當中我們將系統的工作空間作爲底層空間，我們新建的作爲上層空間，通過修改標題實驗，我們得出了一個結論上層優先於底層。
通常建議每個工作空間不要放太多的包，如果把所有的包都放入一個工作空間的時候編譯會非常慢。