【本節節錄自飆機器人－－ROS2基礎教材】

TF，全名為TransForm，顧名思義是代表著某種變換。而這變換的對象，是ROS2裡的各種座標系。

為什麼會有多個座標系呢？

我們來稍微想像一下，假設我們有一台帶手臂的機器人，而我們只有一個座標系：以地圖原點為0,0,0的笛卡兒座標系。當我們希望手臂可以搭配底盤移動，到某個點夾持東西時，要怎麼處理呢？

首先，是先讓車體移動到可以夾持的有效距離內，接著確認手臂和夾持點的位置，使用IK（逆運動學）求出各個關節需要旋轉的量。在這過程中，會經過一些痛苦的座標運算，且因為使用的是原點座標系，相對位置都需要經過一次運算才能得到－－這個動作還每個關節都要來上一次。

這個案例中，如果一開始我們直接將原點改為手臂的底座，則後續的相對位置就簡單很多了。但我們還是需要導航，原本的地圖座標系也是有必要的。

所以我們需要TF。

TF會管理機器人需要的各種座標系（在TF中稱為frame），以及各座標系之間的轉換關係。也就是說，設計各個部件的人都可以以自己的部件為0點，用比較好運算的座標系統來處理運動學。當我們需要跨座標系處理數據時，就依賴TF的轉換資訊計算座標即可。

雖然我不是數學家，但這聽起來很不錯對吧。

而在導航上，對於TF也有一個基礎的規範。REP 105標準定義了導航和更大的ROS生態系統所需的框架和約定。應始終遵循這些約定，以利用社群中豐富的定位、里程計和SLAM資源。

• 至少必須為機器人構造一個包含map -> odom -> base_link -> [sensorframes] 的完整的TF樹。
• 全球定位系統 (GPS) 至少要提供 map-> odom 的座標轉換。里程計系統提供 odom -> base_link 的座標轉化。
• 關於base_link 的其餘座標轉換應該是靜態的，並應在 URDF 中定義。

（示意圖，此為當事LIMO的TF樹）

URDF我們的專欄有提及過，此處就不多做展開了。而前述的光達轉換則是包含在base_link -> [sensorframes] 中。接下來的SLAM，則會建立map，最後加上AMCL提供的Odom層轉換就可以符合完整的導航規範。

我知道各位想說什麼，為什麼是AMCL給出Odom層轉換，而不是里程計（Odometry）呢？

這個就牽涉到自己觀測和外部觀測的差別了，我們在AMCL章節裡面再來討論這件事情吧。