做一台能看见标记并开过去的 ROS 2 机器人

做的是什么

把机器人放在房间里的某个位置，它会一直转向，直到在墙上找到一个打印出来的标记，然后朝它开过去——在半米外停下，车身正对着标记所在的平面，而不只是靠得近。

本站其他所有项目都是在单片机上跑一个程序。这一个是一台装了轮子的计算机，这一点改变了项目的性质。难点不再是时序和接线，而是弄清楚各个部件彼此之间的相对位置，以及在几段软件同时运行时让它们互相对得上账。

为什么这台车需要计算机

Arduino 做不到这件事，原因值得说清楚。问题不在于原始算力——而在于一帧图像有四分之一兆，ArUco 检测需要浮点线性代数，而且这一切还得在车轮仍以 50 Hz 接受指令的同时完成。这类工作需要一个拥有真实内存和真正调度机制的操作系统。

作为交换，这台 Linux 机器换来的是钻进正在运行的机器人内部看一眼的能力。任意两部分之间的每一条消息都是一个话题，你可以在笔记本电脑上订阅它。当机器人从标记旁边开过去而不是开到标记上时，你不必再加打印语句、重新烧录——只要用 ros2 topic echo 把位姿打出来，实时看着它出错。

节点图的形状

五项职责，每个对应一个节点：

正是这些接口让这个结构值得好好设计。控制器从不碰相机，也不碰电机——它消费一个坐标变换，输出一个 Twist。这意味着你可以用键盘遥操作同一台机器人，可以在完全没有硬件的情况下用一个假造的变换来测试控制器，日后还能换上一套发布同样话题的导航栈。

在动手画自己那张表之前，先读节点、话题、服务与动作。这个阶段最常见的错误，是把对接控制器做成一个服务——它是一个必须能够取消的长时间运行的目标，而这正是动作存在的意义。

物料清单

这就是那台双脑机器人，物料清单也体现了这一点：一台负责感知的计算机，加上一块微控制器负责那些计算机无法可靠完成的事情。

**合计大约 $145–175。**这是全站最贵的项目，领先幅度很大，其中大部分开销就是树莓派。

**电源是这类机器人最容易出问题的地方，而一旦出问题代价不菲。**在写 SD 卡时电压跌落会损坏整个系统镜像。开关稳压器的额定电流要远高于树莓派的功耗，绝不要和电机共用同一条电源轨，并且要检查 vcgencmd get_throttled——只要返回值不是零，就说明供电不足，接下来很可能就有一张卡被写坏。

**打印出来的标记要量尺寸。**ArUco 位姿解算的结果与你声明的标记尺寸成正比。打印机用“适合页面”功能把标记缩到 95% 再打印，各个距离上的位姿都会偏差 5%，而整条流水线里不会有什么东西提醒你。

制作顺序

**1——让 ROS 2 跑起来，并证明网络可用。**按在树莓派上安装 ROS 2的步骤做。在笔记本上执行 ros2 topic echo 能看到机器人上发布的话题之前，不要往下走。Wi-Fi 上的节点发现是最可能吃掉你一个晚上的东西，最好现在就把它吃掉，而不是在调试视觉的时候再吃。

**2——让轮子听 Twist 的。**把 Arduino、编码器和 TB6612FNG接好线，并搭出 cmd_vel 桥。里程碑：用笔记本上的键盘遥操作就能开动真实机器人。轮距在这一步标定——后面所有环节都会继承这个数值。

**3——标定相机。**要正儿八经地用真实标定板标定，按照相机标定与 ArUco 位姿的流程做。未标定的相机算出的位姿看着都挺像样，但在画面边缘会偏差几十个百分点，这是你能遇到的最糟糕的失效方式。

**4——把标记作为坐标变换发布出去。**不要用一条只装着 x 和 y 的自定义消息。把 camera_link → marker_7 发布到 TF2里，意味着控制器可以问“在 base_link 坐标系中，标记在哪里？”，而答案会自动算上相机的具体安装方式——包括它确实是倾斜安装这一点。

**5——朝标记开过去。**一个基于方位角的比例控制器：转向它、向前开、在预设的停止距离处停下。这能跑通，但它到达时是斜着贴上去的，这正是下一步要解决的问题。

6——沿标记法线方向接近。不要直接朝标记转向，而是先算出一个沿标记所在平面的法线方向、停在标记面前的那个航点，开到航点，然后再直线驶入。这一步就是“开到对接点”和“真正对接好”之间的差别。在这里，标记的朝向——也就是位姿里你此前一直用不到的那部分——开始变得重要，你也会在这里遇上位姿歧义。

7——用状态机包起来。搜索、接近、对准、最后进场、完成，再加上每个状态在标记丢失时如何转移出去。面向机器人行为的有限状态机讲的是整体结构；这台机器人特别需要的，是一个标记丢失超时机制：超时就回到搜索状态，而不是继续按最后一次已知的位姿往前开。

值得注意的硬件细节

**相机要刚性安装，并且要量清楚。**机器人算出的每一个位姿都是相对于相机的，TF2 再用你声明的 base_link 到 camera_link 变换，把它换算成相对于车体的位姿。装在柔性支架上的相机会让这个声明的变换变成一个会随加速度变化的谎言。

**把相机向下倾斜，并把这个倾角声明出来。**对着地平线的相机，恰恰会在机器人靠近时丢失标记。向下倾斜十到十五度，能让标记在最后进场阶段始终留在画面里——而且这个倾角要写进静态变换，而不是变成控制器里的一个补偿系数。

**用游标卡尺量标记尺寸。**位姿的尺度与你告诉解算器的标记尺寸成正比。因为打印机缩放以适应页面而按 96% 打印，会让每个距离都偏差 4%，而且悄无声息、系统性地偏。

**树莓派要和电机分开供电。**电机堵转会把电源轨拉低，Arduino 遇到这种情况只是重启，没有实质损失，而树莓派则会损坏文件系统。用独立稳压器或者独立电池包都可以——这里不值得省一个元件。

**让相机排线远离电机线。**这是一条没有屏蔽的高速链路。耦合进去的电机噪声表现为画面损坏，再表现为毫无明显原因的检测闪烁。

做到什么程度算好

其中两行承载着整个项目最核心的教训。

**分辨率不是免费的，而且更高的分辨率往往更糟。**从 640×480 换到 1080p，处理量要涨 4–6 倍，换来的检测距离大约只有 1.7 倍。除非你确实需要看得更远的标记，否则更小的画面能给你更快、更新鲜的结果——而在控制循环里，新鲜度比精度更重要。

**延迟那一行正是双脑分工存在的原因。**在 0.3 m/s 的速度下，100 ms 的视觉延迟就意味着 3 cm 的位移；以 90°/s 转动时则意味着 9° 的转角。视觉测到的每一个量，描述的都是机器人刚才在哪儿。直接拿它去闭合一个快速回路，回路就会振荡。可行的结构正是这台机器人采用的结构：Arduino 用编码器跑快速回路，视觉慢慢地修正它——这与航点车上把 GPS 与里程计融合的思路完全同形，理由也完全一样。

如果机器人边走边看：卷帘快门

标准树莓派相机模块采用卷帘快门：各行依次曝光，因此画面顶部比底部早几毫秒拍到。机器人静止时，这一点看不出来。以 90°/s 转动时，ArUco 标记的四个角是在四种不同的机器人朝向下拍到的——由它们解算出的位姿，其偏差是标定无法修正的。

如果机器人必须在运动中做视觉，那就是全局快门模块的用武之地。如果它能负担得起“停下来看一眼再走”，便宜得多的模块完全够用——而且停下来再看是一个正当的设计选择，不是权宜之计。

出问题时看这张表

开始动手之前不妨先注意这张表的分布：其中几乎没有一条是计算机视觉问题。它们是网络、坐标系、单位和控制——这才是做一台 ROS 2 机器人真正学到的东西，也是ROS 2 基础路线把时间花在通信模式和坐标系上、而不是 OpenCV 上的原因。

如果这一步对你来说跨得太大，微型迷宫鼠在完全不涉及 Linux 的单片机上讲建图与规划，手机遥控车则用少得多的零件讲清“指令通过网络到达”这一半问题。