大小论文总算是都搞定了，院审过了送外审了，生死有命富贵在天，希望外审专家大佬们高抬贵手o.O~
我所理解的建图算法的移植，能不能运行起来，大框架上就是把一棵完整的坐标转换关系的TF树给整理“通顺”，TF（Transform）树是用于描述不同坐标系之间转换关系的一种数据结构，它包括了位置和姿态两个方面的变换。在机器人系统中，每个部件（如关节、连杆等）都有一个对应的坐标系，这些坐标系之间的关系通过TF树进行维护。 用常用的坐标系框架REP-105来讲，就是把earth、map、odom、base_link、lase/imu等坐标系转换关系给拼接明白。（关于REP-105坐标系框架的理解是在上一篇文章中已经进行了讲解，详情请移步至这一篇文章~：ROS建图之ROS标准REP-105（官方搬运翻译+个人理解）-CSDN博客）
1 tf树
在REP-105标准中，我们可以看这样一张框架流程图，这张流程图把最基础的坐标系关系描述了出来，再次提醒，尽管在理解中我们会认为map 和 odom 坐标系都应该相对于机器人而言，即被附加到 base_link坐标系上，但实际的map 帧是 odom 的父帧， odom 是 base_link 的父帧。因为每个帧只能有一个父帧。
每个帧只能有一个父帧，但并不一定只有唯一子帧。这也是叫tf树的原因之一吧，比如在多机器人（我的硕士课题：多机器人SLAM建图与路径规划）中，多机器人的简易tf树如下：
两个机器人使用不同的地图进行定位，并具有共同的帧 earth 。为了区分不同机器人的不同坐标系，每一帧的坐标系取用了不同的ID。如何保证最大限度地提高可重用性呢？官方建议在每个robot上使用规范帧id，并使用脚本从robot转发信息。当信息被转发时，帧id应该被重新映射，以消除它们来自和参考的机器人的歧义。
2 tf树节点的数据来源
tf树中各个帧坐标系的转换是怎么来得呢？以下是一些概括性的信息。
2.1 odom 到 base_link
从 odom 到 base_link 的变换由里程计源之一计算和广播。详细的方法和代码见鱼香ROS的教程：：动手学ROS2Description
https://fishros.com/d2lros2/#/humble/chapt17/slam/3.%E5%BB%BA%E5%9B%BE%E5%89%8D%E5%87%86%E5%A4%872-%E5%8F%91%E5%B8%83odom%E7%9A%84TF
2.2 map 到 base_link
从 map 到 base_link 的变换由本地化组件计算。然而，本地化组件不广播从 map到base_link的变换。相反，它首先接收从 odom 到 base_link 的变换，并且使用该信息来广播从map到odom的变换。而刚刚我们获取到了odom到base_link的tf，咦，是不是直接接上了~
2.3 earth到map
从 earth 到 map 的变换是静态发布的，并且通过选择地图框架来配置。如果未特别配置，则后退位置将使用车辆的初始位置作为地图框的原点。如果地图未被地理配准以支持简单静态变换，则定位模块可以遵循与用于发布从 map 到 odom 帧的估计偏移相同的过程来发布从earth到map帧的变换。
3 结束
最后其实还有个机器人坐标系和雷达等传感器的坐标系转换，即base_link 到 雷达或者IMU 之间的坐标转换，这个关系一般使用URDF进行描述，然后使用 robot_state_publisher 进行发布，也可以使用静态TF直接发布。
至此，机器人建图的完整tf树就连接上了，进行相应步骤的相关实现，最后使用cartorgpher等算法，或者slam_toolbox等建图工具包完成数据的处理与传输，建图功能基本就实现了~
刚开始进行长篇博客的叙述，技术上和逻辑上问题很大，大家看一乐呵~
