机器人软件系统全景：感知、定位、规划、控制与决策如何协作

wangxiaoxuan217

284人浏览 · 2026-11-09 20:03:34

wangxiaoxuan217 · 2026-11-09 20:03:34 发布

机器人软件系统全景：感知、定位、规划、控制与决策如何协作

《机器人软件与具身智能：原理、架构与工程实践》 · 第一部分：机器人基础知识 · 第 01 篇

本篇面向有基础编程经验、准备学习机器人软件的读者。我们用一台带相机、移动底盘和机械臂的机器人，推演一次“把杯子搬到桌上”的任务。计算示例可用 Python 直接复现，不需要连接机器人。

设想这样一个调试现场：视觉画面里的杯子被准确框出，机械臂规划接口也返回成功，手臂运动到目标附近，夹爪却合在了空气中。应该换检测模型，还是调整机械臂控制器？仅凭这个现象还无法判断。检测框正确，不代表深度正确；三维位置正确，不代表坐标系正确；规划成功，不代表规划时使用的环境仍然有效；运动执行结束，也不代表物体已经被抓住。要解释这类问题，需要看清一个机器人系统如何逐层建立、使用和验证信息：测量成为状态，状态与目标生成计划，计划变成指令，物理执行再产生新的测量。 这篇文章沿着这条链路展开，既说明模块分工，也给出能算出结果的例子。

1. 先把全景图中的箭头读懂

机器人软件常被分成感知、定位、规划、控制、决策五类模块。这种划分的价值，在于说明每一步消耗什么信息、产出什么信息。
在这里插入图片描述

图 1：蓝色实线表示目标和指令的传递，绿色虚线表示观测和状态的反馈。图中是功能关系，方框不对应固定进程；“世界模型”在这里指环境与机器人状态的表示。

模块	主要输入	主要输出	一个常见误解
感知	图像、深度、点云等观测	物体、位置、表面与障碍物信息	检测分数高，就一定能抓住
定位与状态估计	里程计、惯性或视觉观测、运动模型	机器人位姿、速度及不确定性	有 TF 坐标树，就已经实现了定位
规划	目标、当前状态、环境和约束	路径或带时间信息的轨迹	终点能够到，中间就一定能通过
控制	参考轨迹、当前反馈、执行器限制	位置、速度或力矩指令	发出轨迹后，实际运动自然会完全一致
决策与任务编排	任务目标、能力状态、执行结果	当前子任务及异常处理分支	接口返回成功，业务目标就已经完成

拿杯子时，这些输出并不是同一种“位置”：视觉可能输出相机中的三维点；规划器需要机械臂参考系中的目标位姿；控制器最终可能消费一串关节角、关节速度和执行时间。
因此，阅读机器人代码时，不妨先追踪一个变量的含义：它是观测到的物体状态、期望达到的目标、计划中的参考值，还是已经测量到的实际值？ 很多集成问题，就是在这几种含义之间发生了偷换。
下面先把“视觉找到了杯子”拆开。

2. 从图像中的杯子，到机械臂能使用的目标

2.1 检测框为什么还不能直接用于抓取

二维检测给出的是像素位置。例如，某个物体表面点在图像中的坐标是 (u, v) = (380, 270)。这两个数没有长度单位，也没有说明物体离相机有多远。在同一条观察方向上，近处的小杯子和远处的大杯子，都可能落在这个像素附近。
在针孔相机模型下，如果已知相机内参，以及该像素对应的轴向深度 Z，就可以反投影得到三维点：

X = (u - cx) × Z / fx
Y = (v - cy) × Z / fy
相机坐标中的点 p_camera = (X, Y, Z)

其中，fx、fy 是以像素为单位的焦距，cx、cy 是主点坐标。这里假设像素已经去畸变，内参与当前图像匹配，深度已对齐到同一个像素坐标系；Z 表示沿光轴的深度，而非任意设备给出的斜向测距值。公式来自针孔投影关系，OpenCV 的相机模型文档给出了它的完整定义。参考：OpenCV 相机标定与三维重建

用一组教学数值计算：

像素：u = 380，v = 270
内参：fx = fy = 600 px，cx = 320 px，cy = 240 px
深度：Z = 0.80 m

X = (380 - 320) × 0.80 / 600 = 0.08 m
Y = (270 - 240) × 0.80 / 600 = 0.04 m
p_camera = (0.08, 0.04, 0.80) m

现在终于有了以米为单位的位置，但还没有得到完整的抓取目标。
第一，这只是一个表面点。杯子的中心、杯柄的位置和夹爪应该接近的位置，可以是不同的点。第二，抓取通常还需要方向：夹爪从上方还是侧面接近，手指朝向哪里，闭合方向是否会穿过杯体。第三，框中心的深度可能来自背景、桌面，或者因反光而无效。直接拿“检测框中心 + 一个深度值”当抓取位姿，会把这些问题全部隐藏掉。
因此，从感知到抓取之间，往往还存在实例分割、三维几何处理、物体姿态估计或抓取候选生成等步骤。具体采用哪些步骤取决于任务；二维检测只是提供了一个入口。

2.2 三个坐标值为什么不能原样交给机械臂

ROS 的常见约定中，机器人本体坐标轴是 x 向前、y 向左、z 向上；相机光学坐标轴则是 x 向右、y 向下、z 向前。这两套轴的语义不同，原点也不同。参考：REP-103 坐标与单位约定
把相机中的点转换到机器人基座坐标系，需要一个旋转矩阵和一个平移向量：

p_base = R_base_camera × p_camera + t_base_camera

R_base_camera 把相机轴方向换成基座轴方向；t_base_camera 是相机原点在基座坐标系中的位置。平移向量也必须用目标坐标系表达，不能把两个坐标系里的偏移直接相加。
为了便于手算，假设相机水平朝前，位于基座原点前方 0.20 m、上方 0.90 m，无其他偏转。轴方向对应关系为：

相机向前 Z  → 基座向前 x
相机向右 X  → 基座向右，即 -y
相机向下 Y  → 基座向下，即 -z

R = [[ 0,  0,  1],
     [-1,  0,  0],
     [ 0, -1,  0]]
t = (0.20, 0.00, 0.90) m

p_base = (Z + 0.20, -X, 0.90 - Y)
       = (1.00, -0.08, 0.86) m

在这里插入图片描述
图 2：同一个物理点，在不同参考系中有不同的坐标值。图中的相机安装关系是为了演算而设定的，实际系统应使用标定或机构模型提供的变换。
这个结果可以读成：目标点在机器人前方 1 米、右方 8 厘米、上方 86 厘米。如果把相机中的 (0.08, 0.04, 0.80) 直接解释成基座坐标，程序不会因为三个数的类型正确就自动发现错误，但实际目标已经换了位置。
当目标带有姿态时，要变换的是完整位姿；当相机安装在云台或机械臂上时，相机到基座的关系还随关节运动改变。这也是为什么工程中通常需要维护一棵坐标关系树。

2.3 TF 与定位究竟有什么区别

TF2 管理坐标关系及其时间历史，提供查询和变换能力。它需要其他模块告诉它“两个坐标系此刻是什么关系”，不会仅凭几个坐标系名称推断机器人在哪里。参考：ROS 2 TF2 入门
这些关系的来源可能不同：固定相机外参来自标定或机构模型；机械臂末端关系来自关节状态与正运动学；机器人在环境中的位姿来自定位或 SLAM。
状态估计常包含两个互相配合的过程：先根据运动模型和里程计预测状态，再用外部观测修正预测。例如，编码器报告车轮转了一段距离，但轮胎可能打滑；视觉或激光与环境特征的匹配，可以为位姿提供另一份约束。融合时还要考虑各观测的不确定性，不能简单地把所有位置做算术平均。
这也解释了 odom 与 map 为什么会同时存在：odom 适合提供连续的局部运动参考，但允许累积漂移；map 提供全局参考，定位修正可能带来跳变。这里的连续性与全局修正是不同需求。参考：REP-105
到这一步，系统才开始拥有可供规划使用的信息：目标在哪里、机器人在哪里、两者各自有多可靠，以及这些判断对应哪个时刻。

3. 规划为什么不只是“画一条不碰障碍的线”

3.1 末端能到达，不等于整条机械臂能通过

移动底盘常用平面位置与朝向描述状态，例如 (x, y, θ)。六关节机械臂则可以用六个关节变量组成的向量描述一个配置：

q = [q1, q2, q3, q4, q5, q6]

机械臂的路径不是杯子与夹爪之间的一条空间直线，而是一系列完整的关节配置。每个配置都会决定肩部、肘部、腕部和夹爪的位置。
给定末端目标位姿，逆运动学求解“哪些关节配置能够到达它”。结果可能无解，也可能有多组解。即使有一组终点配置合法，从当前配置走到那里时，肘部仍可能穿过桌沿，或者手腕越过关节限制。
所以，“终点逆解存在”“存在无碰撞路径”“规划器在给定时间内找到路径”，是三个不同判断。一次规划超时，也不能直接证明问题在数学上无解。
规划所依赖的世界模型同样重要。真实桌面没有进入碰撞场景时，规划器完全可能正确地通过它所看到的场景检查，却在现实中遇到障碍。MoveIt 的运动规划请求会包含目标和约束，并结合机器人状态与碰撞表示进行检查。参考：MoveIt Motion Planning

3.2 路径给出顺序，轨迹给出时间

用 s 表示从起点到终点的路径进度，0 ≤ s ≤ 1，就可以把路径写成 q(s)。再给进度安排一个随时间变化的函数 s(t)，便得到轨迹 q(s(t))。
这个区别有直接的物理后果：同样一段关节运动，用 1 秒完成与用 3 秒完成，需要的速度、加速度不同。规划出几何路径后，仍需检查时间安排是否符合执行器限制。
在这里插入图片描述

图 3：路径、轨迹、控制分别处理几何顺序、时间安排和执行偏差。数值来自下文的简化数学模型，不是实机性能。

3.3 算一个例子：平均速度没超限，为什么还不行

假设一个关节从 0 rad 运动到 1 rad，允许的最大速度为 0.5 rad/s，最大加速度为 1 rad/s²。

先做一个看似合理的估计：1 rad ÷ 0.5 rad/s = 2 s。但这只是按照平均速度估计，并没有给起步和停止留出速度变化的余地。

选择一个起止速度为零的三次时间缩放模型：

τ = t / T，0 ≤ t ≤ T
q(t) = q0 + Δq × (3τ² - 2τ³)

速度峰值 = 1.5 × |Δq| / T
加速度绝对值峰值 = 6 × |Δq| / T²

这类时间缩放是轨迹生成的基础方法。三次模型在起止处速度为零，但加速度在与静止段连接时会发生跳变；需要更平滑的连接时，要采用其他时间曲线或额外约束。参考：Modern Robotics，第 9 章时间缩放

代入本例，如果选 T = 2 s：

速度峰值为 1.5 / 2 = 0.75 rad/s，超过 0.5 rad/s。
加速度峰值为 6 / 2² = 1.5 rad/s²，超过 1 rad/s²。

在这个模型下，要同时满足两项限制，必须有：

T ≥ 1.5 × 1 / 0.5 = 3 s
T ≥ sqrt(6 × 1 / 1) ≈ 2.45 s

因此选择 T = 3 s：
速度峰值 = 0.5 rad/s
加速度峰值 ≈ 0.667 rad/s²

这就是时间参数化的实际含义。它需要约束整段运动的导数，不能只给路径点随便填上几个时间戳。真实多关节系统还要处理各关节共同的时间安排、负载、力矩和更高阶平滑性；上面的 3 秒只适用于这个单关节数学例子，也不是所有轨迹形式的全局最短时间。

4. 控制器拿到轨迹以后，还在计算什么

轨迹提供的是“此刻应该到哪里”。实际关节受负载、摩擦、驱动器响应和扰动影响，不会始终恰好落在参考值上。

假设某个速度接口允许我们发送关节速度，采用“参考速度 + 位置误差修正”的简化控制律：

位置误差 e = q_ref - q_measured
速度指令 v_cmd = clip(v_ref + Kp × e, -v_limit, v_limit)

clip 表示把指令限制在允许范围内。q_ref 与 v_ref 来自同一时刻的参考轨迹，q_measured 来自实际反馈；Kp 把位置误差换算成额外的速度修正，单位为 1/s。

单独取一个控制时刻演算，假设：

q_ref = 0.50 rad，q_measured = 0.46 rad
v_ref = 0.30 rad/s，Kp = 2 /s，v_limit = 0.50 rad/s

e = 0.04 rad
v_cmd = 0.30 + 2 × 0.04 = 0.38 rad/s

这一时刻关节落后于参考位置，因此控制器在参考速度上增加修正。下一周期要重新读取实际状态、重新计算误差。把同一个 0.38 rad/s 一直发下去，已经不是上述反馈控制了。

这个例子假设底层速度执行能力可用，省略了动力学和其他限制。它用来说明反馈的作用，并不是实际机械臂的完整控制器。比例增益也不能无限增大：测量噪声、时延、执行器饱和等因素都会影响表现。参考：Modern Robotics，速度输入下的运动控制

ros2_control 的控制器管理器把这一周期组织成读取硬件状态、更新控制器、写入硬件指令。具体输出位置、速度还是力矩，取决于控制器与硬件接口的约定。参考：ros2_control Controller Manager

由此可以区分两类外观相近的问题：

目标本身错了：关节很准确地跟踪轨迹，夹爪仍然到达错误位置。优先检查目标、坐标变换、标定与模型。
目标正确但没跟上：参考轨迹与反馈持续偏离。继续检查指令是否实际下发、硬件是否就绪、轨迹是否超出能力，以及控制与反馈是否正常。

如果不同时记录参考值和实际值，仅看“最后没抓到”，就很难知道偏差从哪一层开始。

5. 决策层管理的是有条件的任务，而不是一串函数名

前面已经有了感知结果、运动方案和控制执行。决策层要把这些能力组织成任务，并规定什么时候能够推进。

以抓取后的搬运为例，可以先写出三项约定：

前置条件：目标观测和坐标关系有效，机器人状态满足本次动作要求。
执行过程：启动抓取任务，跟踪反馈，等待与该任务对应的最终结果。
后置条件：获得有效的持物证据，才允许把状态推进到“可以搬运”。

状态机、行为树或其他任务框架，都可以承载这组约定。但换一种框架不会自动补齐缺失的后置条件。

5.1 请求受理、执行结束、物理目标满足是三层证据

ROS 2 Action 把目标受理、执行反馈、最终结果和取消请求分开。受理表示执行端愿意处理目标；最终结果描述这次动作的结束状态；它具体证明了什么，取决于该动作接口的定义。参考：ROS 2 Actions 设计

例如，某个接口若只承诺“夹爪到达目标开度”，它的成功结果就不能单独证明杯子被抓住。能够移动到某个关节角，也不能单独证明物体已经稳定放在桌面上。
在这里插入图片描述

图 4：沿主线读取“受理 → 执行成功 → 有效确认持物 → 搬运”。超时或断连意味着结果尚未确认，不能直接按成功推进，也不能据此断定物理动作完全没有发生。

持物验证可以综合夹爪位置、力、触觉或视觉信息。关键是区分“确认未持物”和“没有得到可靠结果”：后者可能来自传感器异常、观测过期或不同信号相互矛盾。

八界《三层 SDK 与玩具收纳开发指南》中的抓后核验持物、放后核验空爪，就对应这种验证分层。空爪可以支持“物体已经脱离夹爪”的判断，但若业务关心物体是否落在指定区域、是否稳定，还需要定义相应的证据。

5.2 为什么超时后不能直接重新抓一次

一次调用超时，可能是请求没有到达，也可能是动作正在执行，还可能是已经完成但结果没有传回。调用方只观察到“等待超过期限”，无法由此确定远端和物理世界的状态。

如果此时直接重发抓取指令，可能让第二个动作与尚未结束的第一个动作重叠，或者在已经持物的情况下再次执行抓取。因此，重试策略必须与任务状态查询、去重约定、取消与停止确认相配合，不能只包一层 try / except 循环。

下面这个纯逻辑函数表达了最小的推进规则。它不访问硬件，也不是某个 SDK 的真实接口；上游必须先把具体结果映射为这些状态，并完成观测新鲜度检查。

def next_after_grasp(accepted, terminal, holding):
    if accepted is None:          # 是否受理尚未确认
        return "confirm_state"
    if not accepted:
        return "handle_rejection"
    if terminal == "running":    # 尚未超过本次等待期限
        return "wait"
    if terminal in {"failed", "canceled"}:
        return "handle_execution_result"
    if terminal != "succeeded":  # 超时、断连或未知结果
        return "confirm_state"
    if holding == "attached":    # 有效、新鲜的持物判断
        return "carry"
    if holding == "detached":
        return "handle_empty_grasp"
    return "confirm_state"

这里最有价值的不是函数写法，而是它拒绝了两个不成立的等价关系：未知结果不能当作失败后直接重试，执行成功也不能自动当作持物成功。 后续怎样确认、怎样终止或恢复，仍需由任务设计明确规定。

6. 一切数值都正确，为什么仍然可能抓偏

还有一个容易漏掉的维度：时间。

假设图像在 t_capture 采集，经过传输、排队和推理，到 t_use 才被任务模块使用。这段时间内，机器人、机械臂或物体都可能已经运动。于是，“数值正确”需要加上一个前提：它对哪个时刻正确？

ROS 的 sensor_msgs/Image 定义明确要求图像时间戳表达采集时间，坐标系标识表达相机光学参考系。这些元数据是测量含义的一部分。参考：Image 消息定义

6.1 旧图像应该配哪个时刻的变换

把旧图像中的点变换到固定地图坐标系时，应使用采集时刻的关系：

p_map = T_map_camera(t_capture) × p_camera(t_capture)

这里使用齐次坐标，T_map_camera 表示从相机到地图的完整变换。如果随后需要把一个静止目标表达在当前机器人基座中，再使用当前的 T_base_map(t_use) 做转换。前提是物体在两时刻之间确实静止；如果它在移动，还需要跟踪或重新观测。

一个细节是：固定安装的相机到基座的外参本身可以不变，但机器人在地图中的位姿会变。不能把“外参固定”误解成整条相机到地图的变换链都固定。

此外，时间戳只有在时钟基准一致时才可比较。系统时钟、仿真时钟和设备自身时钟若未正确关联，两个看似合法的时间值也可能没有可比较的含义。

6.2 200 毫秒到底意味着多大的位置变化

用一个匀速平移例子估计量级：

速度 v = 0.30 m/s
观测年龄 Δt = 0.20 s
这段时间内的平移距离 d = v × Δt = 0.06 m = 6 cm

这个 6 厘米是运动距离，不是所有系统都会出现的最终抓取误差。正确的时间变换和状态预测可以补偿其中一部分影响；转动、目标运动和模型误差又会引入其他项。

反过来，如果某个设计只允许未补偿平移贡献不超过 1 cm，在同样 0.30 m/s 的假设下，仅由这一项就有 Δt ≤ 0.01 / 0.30 ≈ 33 ms。这不是通用延迟指标，而是把空间误差预算换算为时间约束的一种方法。

6.3 为什么不能让控制周期等待视觉推理

感知、状态估计、轨迹跟踪和任务推进通常有不同的更新节奏。它们需要交换有时间信息的结果，但不必全都锁在同一轮串行调用里。
在这里插入图片描述

图 5：三类反馈分别解决“接下来做什么”“原方案是否仍适用”“当前是否跟上参考”。图中不规定固定频率，也不对应固定线程划分。

假设一个设计将控制周期设为 10 毫秒，而某次视觉推理耗时 80 毫秒。如果把推理放进同一个串行控制周期，单是推理时间就已经占了八个目标周期，无法维持原定更新节奏。这是调度示例，不是对某类机器人的实际频率描述。

把任务异步化之后，还要继续处理数据年龄、等待期限、缓冲区、结果顺序和过期结果的丢弃。例如，较早发起的检测较晚返回，不能仅因“最后收到”就覆盖更新的观测。异常响应也要有明确归属：局部执行问题由对应层及时报告或响应，任务层据此决定后续目标。

7. 从全景图落到代码：框架位置与排查顺序

7.1 ROS 2、Nav2、MoveIt 和 SDK 各自承接哪一段

ROS 2 的 Topic、Service、Action 解决不同交互需求。连续观测可以通过 Topic 传播，短请求与应答可以用 Service，带反馈和取消语义的长任务可以用 Action。机制选择仍取决于具体接口约定，不能仅根据函数是否“执行得久”替接口补上任务语义。

Nav2 组织移动机器人导航所需的组件，例如从目标生成路径，再结合当前环境与状态计算运动指令。MoveIt 面向机器人操作，组织机器人模型、场景、运动规划和执行等能力。SDK 则把这些下层能力封装成应用容易使用的类型、调用和结果。它们对应的是不同层次，不应把一个工具名称等同于整个机器人系统。参考：Nav2 导航服务器、MoveIt Planning Scene Monitor

学习这些框架时，可以抓住几个接口对象：图像的时间戳和坐标系，位姿的参考系，机器人关节状态，带时间的轨迹，以及任务的目标标识、反馈和终态。它们正好对应前面讲过的信息边界。

7.2 “检测正确却抓空”，按什么证据往下查

回到开头的假设场景。不要仅凭现象给某个模块定责，可以沿数据链比较同一次任务中、对应时刻的记录：

观察到的证据	优先核对什么	为什么能缩小范围
检测框对，但三维点落在桌面或背景	深度有效性、RGB 与深度对齐、取点区域	问题出现在目标进入规划器之前
相机点合理，变换到基座后方向或高度不合理	变换方向、轴约定、外参、单位	坐标变换已经改变了目标的空间含义
静止时合理，底盘或云台运动时偏差明显	采集时刻、变换时刻、观测年龄、时钟	运动放大了时间不一致的影响
末端目标正确，但规划失败	起始关节状态、逆解、关节限制、碰撞场景	目标位置只是规划条件的一部分
轨迹合理，实际关节明显没有跟上	指令链路、驱动状态、参考与反馈、能力限制	需要解释计划到实际运动之间的偏差
运动符合预期，但持物验证失败或未知	抓取候选、夹爪接触、对象移动、验证信号	执行目标成立，仍不等于抓取物理条件成立

这张表列的是排查方向，不是互斥的故障分类。同一次失败可能包含多个原因。实际排查最好保存一组能串起因果的记录：

同一任务标识
→ 原始观测及采集时间
→ 相机中的目标和有效性
→ 使用的坐标变换及时间
→ 规划目标、起始状态与环境版本
→ 参考轨迹与实际反馈
→ 执行终态与持物验证

只保存最后一个错误码，会丢掉“错误从哪里开始”的信息；只保存一张成功检测截图，也不足以证明整条抓取链路正确。

8. 用一个可运行的小实验检验理解

下面的 Python 代码只做数值计算，用标准库就能运行。它把本篇的像素反投影、坐标变换和轨迹时长约束放在一起；所有参数都是教学设定。

from math import sqrt

# 像素 + 轴向深度 → 相机中的三维点
u, v, z = 380.0, 270.0, 0.80
fx, fy, cx, cy = 600.0, 600.0, 320.0, 240.0
x, y = (u - cx) * z / fx, (v - cy) * z / fy
p_camera = (x, y, z)

# 本文设定的水平相机安装关系，不代表任意机器人的外参
p_base = (z + 0.20, -x, 0.90 - y)

# 单关节三次时间缩放，分别计算速度和加速度所需时长
delta_q, speed_limit, accel_limit = 1.0, 0.5, 1.0
duration = max(1.5 * abs(delta_q) / speed_limit,
               sqrt(6 * abs(delta_q) / accel_limit))
peak_speed = 1.5 * abs(delta_q) / duration
peak_accel = 6 * abs(delta_q) / duration**2

print("camera (m):", tuple(round(a, 3) for a in p_camera))
print("base (m):", tuple(round(a, 3) for a in p_base))
print(f"T={duration:.2f} s; vmax={peak_speed:.3f} rad/s; "
      f"amax={peak_accel:.3f} rad/s^2")

这段代码的输出是：

camera (m): (0.08, 0.04, 0.8)
base (m): (1.0, -0.08, 0.86)
T=3.00 s; vmax=0.500 rad/s; amax=0.667 rad/s^2

可以再改两个参数验证自己是否理解了机制：

把深度从 0.80 m 改成 1.00 m。相机中的点变成 (0.10, 0.05, 1.00)，基座中的点变成 (1.20, -0.10, 0.85)。像素没变，三个空间坐标却都会随深度或坐标变换发生变化。
只把速度上限从 0.5 rad/s 提高到 1 rad/s。本例所需时长变成约 2.45 s，此时加速度限制主导，不能仅按新的速度上限推断完成时间。

这两个小实验分别对应机器人软件中的两条基本原则：空间数值必须带上参考系，运动方案必须带上时间和约束。 再把有效性与执行结果补齐，才有条件把单个算法组织成能够持续运行的系统。

下一篇将进一步展开本篇最基础的空间关系：《机器人如何描述空间：坐标系、位置、姿态与参考系》。