点一下浏览器里的按钮，网页UI上那个绿色圆圈亮起来，客厅里那台改了ROS2的小车真的往前蹿了半米——那一刻我直接从椅子上弹起来，差点把笔记本带翻。不是我大惊小怪，而是这台车半个钟头前还只会躺在地板上装死。

这不是什么大厂自动驾驶项目，就是我自己一个人，利用零碎的时间，把一台几百块钱的差速小车改造成了一台可以通过网页远程遥控的ROS2机器人。我给它加了一套ROS2通信链路，写了一个最简单的HTML按钮页面，通过网络把一串坐标数据送到底盘驱动，再变成电机的PWM。这篇文章是“第1期”：不聊高深的SLAM导航，先把“网页按钮到轮子转动”这条最基础也最关键的链路彻底打通。

如果你手里正好有一台吃灰的ROS2小车，或者你正想过几天带一块ARM开发板、两个轮子和一对电机驱动模块从零组装一台能远程操控的移动平台，这篇文章会很适合你。我会把从方案选型、硬件清单、软件架构到实际代码、踩坑记录的整个过程全部拆开来讲，步骤可以直接照着抄。

1. 改造前的思路整理：一台普通小车怎么变成“网页可遥控”的移动机器人

1.1 为什么我选择了ROS2而不是自己写Socket控制

我一开始有过一个很“野”的念头：既然只是想让网页按钮控制车动，那我直接在小车主控上开一个TCP端口，前端页面用WebSocket连上来，收到“forward”字符串就驱动电机正转，收到“left”就往左转，这不是更直接吗？代码量估计一个晚上就能写完。

这个思路对一辆“玩具遥控车”完全成立，但对我手里这台车的目标来说并不成立。原因很现实：我不打算只让它做一台遥控车。后面我还要加摄像头图传、自动避障、里程计反馈，甚至跑简单的巡航逻辑，这些都是ROS2生态里现成的轮子。如果我自己写一个直连协议，第一版可能很爽，做到第二步超音波传感器的时候就会开始怀疑人生：所有数据处理逻辑都要自己一点一点盘上去，后续每一步都在给当初的偷懒买单。

ROS2的核心价值在于，它提供了一整套完整的通信中间件。它不关心你的指令是来自键盘、命令行、手柄还是网页，它只负责一个动作——把“我期望机器人以某个速度前进”这个消息发送到全局的通用的/cmd_vel话题，任何订阅这个话题的节点都能收到并执行。这样就把前端交互和底盘控制彻底解耦了。我可以今天用网页按钮，明天换个手机App，后天连手柄EC，前端换一百遍，底层驱动节点一行不用改。这就是典型的“用一层抽象换可持续扩展空间”。

1.2 硬件选型与成本清单

我先说结论：这套改造真正需要的硬件比想象中简单，我实际用的方案是“ARM开发板 + 两路直流减速电机 + 电机驱动模块 + 差速两轮底盘”。

主控我选了一块性能中等偏上的ARM小板，型号不具体点名，总之能够运行Ubuntu和ROS2就行。强烈不建议用单片机来做ROS2主控，因为资源紧张而且生态麻烦。主板上跑操作系统，负责处理通信、运行rosbridge、之后还要跑画面处理和传感器算法；真正的电机运动控制交给下位机，也就是电机驱动模块甚至更小的控制板去执行，两边各干各的活。

底盘选的是最常见的两轮差速结构，两个带霍尔编码器的直流减速电机加一个万向轮。选霍尔编码器是故意的，它通过脉冲值能反馈轮子实时的转动圈数，后面算里程计不会抓瞎。电机减速比我用的1:30，兼顾了速度上限和转向力度，让车在地砖路面上跑起来不算吃力。

电机驱动模块我选了双H桥驱动，它是我手里价格最合适、接线最简单的选择。它用两路PWM分别控制左右电机的方向和速度。唯一的坑是它压降明显，所以我供电用了大电压的电源组，驱动模块再降压给主板用。这套配置全部加在一起大概在千元以内，其中大头其实是那块ARM开发板。

这整套硬件的核心逻辑是：ARM开发板负责“聪明”的部分，下位机负责“听话”的部分。ROS2节点发布的速度指令，最终在驱动模块那里变成占空比不同的PWM信号，电机收到电流开始转，底盘才开始动。后续如果觉得动力不够，最省事的升级方向是换成带减速箱的电机，硬件接口不用变。

1.3 整体架构：浏览器、主控、底盘三层怎么分工

既然只靠一个网页按钮就让车动起来，这中间自然有三层结构，每一层的职责非常清晰。

最上面是浏览器这一层，也就是你的控制端。它运行着一个最简单的网页程序，页面上有前进、后退、左转、右转和停止几个按钮，背后通过WebSocket协议连接ROS2的桥接服务。它只负责一件事：把按钮点击转成机器人可以理解的期望速度指令，发给中间层。

中间是主控层，也就是那块运行着ROS2系统的ARM开发板。它在整个架构中承载一个关键服务——rosbridge_server。你可以把它理解成一座专门把WebSocket消息翻译成ROS2话题消息的“翻译官”。浏览器里发的JavaScript对象到了这里，会被翻译成标准的ROS2消息，发布到对应的Topic上。

最底层是底盘驱动层，它订阅主控上的/cmd_vel话题，每收到一个新的速度消息，就计算左右两个电机各自应该给多少PWM信号，然后通过驱动模块让轮子转起来。有的方案是直接用主控引脚输出PWM，我这边为了稳定，通过一个小的协议由下位机执行PWM输出，不过整体逻辑是一样的。

这三个层级串联起来，就形成了标题里那句话：“点一下网页按钮，车真的动了”。我在设计这个架构时反复提醒自己一件事：每一层都尽量做“哑终端”，只负责自己该负责的事，不在某个层级里塞太多业务逻辑。这样后面无论哪一层出问题，都能第一时间用“断开这一层、测试上一层”的方式定位问题。

2. 核心链路拆解：网页上那“点一下”到底发生了什么

2.1 一条指令的完整旅程

我执念很深地问过自己一个问题：当我按下那个“前进”按钮之后，这半秒钟时间里，整个系统到底经历了什么？后来我把它完整拆了一遍，整个链路是这样走的。

第一步，浏览器捕捉到按钮的click事件，一段JavaScript代码开始执行。它用roslibjs库构建出一个geometry_msgs/msg/Twist类型的消息对象。Twist是ROS2里描述运动速度的标准消息格式，里面有两个六维向量，linear记录线速度（米/秒），angular记录角速度（弧度/秒）。所谓前进，本质就是赋一个linear.x = 0.2的消息。

第二步，这个消息通过WebSocket发送到主控上的rosbridge_server。rosbridge需要事先启动并监听一个端口，比如默认的9090端口。浏览器和这个端口之间建立一条长连接，消息以JSON格式传输。你可以简单理解成，浏览器给主控发了一条“请让机器人以每秒0.2米的速度向前走”的电报。

第三步，rosbridge_server把收到的JSON翻译成正常的ROS2消息，然后以发布者的身份，把这个消息发布到/cmd_vel话题上。这个时候，它的任务就完成了，它根本不关心底下有没有节点在听，有人处理就是发出去，没人处理就只当是把指令丢进了屋子中央的空信箱。

第四步，底盘驱动节点一直在订阅/cmd_vel话题。只要这个话题有新的消息进来，它的回调函数就会被触发。它会取出linear.x和angular.z两个数值，通过一个逆运动学公式，换算成左右两个轮子各自的目标转速，再把这个转速映射成0到255范围的PWM占空比数值。

第五步，PWM信号输出到电机驱动模块，驱动芯片放大功率，直流电机转动，通过减速箱带动车轮。于是车身那一刻真的动了。整个过程算下来，从点击按钮到轮子有响应，延迟只有几十毫秒级别，体感上和按游戏手柄几乎一样。

这五步里，最容易出问题的往往不是最后一步的电机，而是中间某个环节的通信断开。所以我做调试的时候有一条铁律：先验证话题有没有收到消息，再查电机为什么不动。不要在车轮都不转的情况下先怀疑PWM频率不对。

2.2 为什么用rosbridge_server而不是自建WebSocket通道

回到前面那个“自己写Socket”的话题。我后来算是完整体验了一遍有rosbridge和没有rosbridge的差距，这里给后来人一个明确的结论：如果你打算长期折腾ROS2小车，直接上rosbridge，别自己写通道。

rosbridge_server是ROS2官方生态里的一个套件，它的妙处在于把“Web与ROS2不通”这个问题变成了历史问题。浏览器里没有C++和Python运行时，它天然没有办法直接和DDS层通信，但是WebSocket是浏览器原生支持的，所以rosbridge做的正是把DDS消息包装成WebSocket可以传输的JSON，再在另一头还原。这个方案是唯一能“不折腾浏览器内核”就完成打通的主流做法。

曾经有人建议我用HTTP长轮询或者每个动作发一次HTTP请求来模拟遥控，我先说这个方案的问题：HTTP协议过重，每次请求都有完整的头信息握手过程，不适合高频控制。遥控车要求至少每秒10到20次的速度刷新，HTTP半天建立一次连接还把大量时间花在协议开销上，控制手感一定是一顿一顿的，不是真正的平滑。WebSocket是全双工长连接，一次握手上来回传无开销，非常适合实时控制场景。

更重要的是，rosbridge让前端代码变得非常优雅。你不需要了解DDS、QoS这些底层概念，在前端只需new一个ROSLIB.Ros()连接到服务器，再new一个ROSLIB.Topic()定义一个话题，然后直接publish()。整个过程和调用一个普通JavaScript库没有区别。这也是我选它的最实际原因：后续不管是写一个PC页面还是做手机端适配，这套抽象的接口都能直接用。

2.3 话题、消息、发布订阅：ROS2的通信模型

做这套改造之前，必须要对ROS2的通信模型有点基础认识，否则你在调试的时候会非常痛苦。ROS2里最核心的概念之一就是“话题”（Topic），你可以把它理解成社区公告板上的某个专区。

比如说/cmd_vel这个专区，板上贴的每一张公告都有统一的格式，格式就是消息类型geometry_msgs/msg/Twist，任何人想往这个专区发公告，就可以往板上贴，任何人想获取最新公告，就到这个专区来看。发布方不关心订阅者是谁，订阅者也不需要知道发布方从哪来。这是一种典型的解耦设计，汽车生产和买车的人不需要直接见面，中间通过市场来撮合。

这种模型对整个系统调试特别有价值。如果你在网页上按了“前进”小车没动，你可以打开另一个终端运行ros2 topic echo /cmd_vel，这个命令会实时打印这个话题上所有经过的消息。如果按下按钮，终端出现了linear.x: 0.2之类的滚动输出，就说明从浏览器到ROS2主控这段链路完全正常，问题在底盘驱动。如果没有输出，就说明要么前端没发布成功，要么rosbridge没桥接，要么连不上服务器。这种排查方式能快速把问题框在一个很小的范围内，不用满世界找原因。

还有一个容易忽略的细节是QoS策略，也就是消息传输的可靠性和历史深度配置。在Web控制这种场景下，我选的是“易变”策略，用浅队列加掉旧消息优先的处理方式，避免一条陈旧的速度指令堵在管道里导致小车晚半拍才响应。在实时遥控里，丢一条旧指令问题不大，一直用旧数据控车才是大问题。

2.4 延迟与实时性：这套方案到底跟手吗

我做完第一版之后的第一个疑问是：用浏览器中转一条指令，车还能保持“指哪打哪”吗？实测结果是我把自己的心理预期调低完全多余了。

我这里测过简单的计时方案：在网页上启动前进指令的同一帧记录当前时间戳，同时在小车主控上打印收到cmd_vel消息的时间戳，两者相减。局域网环境下，从浏览器到rosbridge再到订阅节点，延迟大概在10到50毫秒之间，这和你打开一个本地网页时的页面刷新延迟处在同一个量级。体感上，按下按钮到车开始动，几乎察觉不到滞后。

不过有个坑必须单独说：浏览器和车不要相隔太远的物理距离并且不在同一个网段，哪怕局域网Wi-Fi网络拥挤，延迟也会飙升到几百毫秒。我遇到过最夸张的一次是在同一个路由器下又开了一堆设备下载更新，车子的响应时间变得绵软无力，按下按钮仿佛隔了半秒才反应过来。所以实时控制的底线是保证控制端和机器人主控在同一个质量较好的局域网里，带宽不大都行，但延迟必须稳。

实时性带来的另一点是控制频率。底盘的驱动节点我建议让/cmd_vel保持10Hz到20Hz的订阅频率即可，不用刻意提高。因为Web前端不是实时操作系统，过于频繁地发送指令反而会造成CPU空转。真正要让车开起来丝滑，重点不是“发送频率有多快”，而是“速度变换是否平滑”，这一点后面专门会讲到。

3. 实操记录：从零启动你的第一台网页遥控ROS2小车

3.1 环境准备：系统、ROS2、依赖

到了实操环节，我先说一说我在主控板上准备好的基础环境。系统用的是Ubuntu 22.04版本，ROS2用的对应该版本的分发版。ROS2版本和系统版本必须严格对应，这是新手最容易踩的第一个坑——装错版本之后到处报错，还以为自己配置有问题，其实就是系统与发行版不匹配。

安装好ROS2基础系统之后，我再装几个额外的功能包。一个是rosbridge_suite，这个包就是提供rosbridge_server服务的核心套件，安装命令是sudo apt install ros-<版本代号>-rosbridge-suite。另一个是teleop_twist_keyboard，它虽然不是必须的，但它能帮你最快速地本地测通底盘，这个包允许你在终端里按键盘方向键直接控制小车，相当于用键盘验证底盘没问题，再上网页控制。

除了ROS2相关的包，前端依赖的事情和主控系统没太大关系，但我会在本地维护一个静态页面文件夹，里面放好roslibjs库。需要注意的是，roslibjs在浏览器端使用，不需要在主控上安装，只需要在写页面的时候通过CDN引入或者把源文件下载到本地页面目录，保证打开页面时有网络能加载到它。

最后检查一下主控和其他硬件之间的串口权限。Linux系统里访问串口需要权限，常见报错是打不开/dev/ttyUSB0类似class错误，那就是当前用户不在dialout用户组里。把用户加入dialout组再重新登录，这条坑我当年被绊了一个小时。

3.2 底盘节点：把/cmd_vel转成电机速度

底盘节点是整个系统里最关键的一段代码，我就用一个最直白的方式来实现：Python脚本加一个一直运行的循环，订阅/cmd_vel话题，每次收到消息就通过串口把速度指令发给下位机，下位机再把指令转成PWM。

先看一个极简版的底盘节点写法：

import rclpy from rclpy.node import Node from geometry_msgs.msg import Twist class SimpleDriveNode(Node): def __init__(self): super().__init__('simple_drive_node') # 订阅/cmd_vel，队列长度设置为1，保证速度指令是新鲜的 self.subscription = self.create_subscription( Twist, '/cmd_vel', self.cmd_callback, 1) self.subscription self.wheel_base = 0.14 # 左右轮距，单位米 def cmd_callback(self, msg): vx = msg.linear.x wz = msg.angular.z # 差速模型逆解：左轮速度 = 线速度 - 角速度 * 轮距/2 v_left = vx - wz * self.wheel_base / 2.0 v_right = vx + wz * self.wheel_base / 2.0 left_pwm = self.speed_to_pwm(v_left) right_pwm = self.speed_to_pwm(v_right) # 把PWM数值通过串口/IO发出去，这里是伪代码 self.send_pwm(left_pwm, right_pwm) self.get_logger().info(f'收到指令: vx={vx:.2f}, wz={wz:.2f}') def speed_to_pwm(self, speed): # 简单线性映射，把速度值映射到PWM范围 max_speed = 0.5 ratio = max(-1.0, min(1.0, speed / max_speed)) return int(ratio * 255) def send_pwm(self, left_pwm, right_pwm): # 真正驱动电机，具体实现取决于硬件 pass def main(): rclpy.init() node = SimpleDriveNode() rclpy.spin(node) rclpy.shutdown() if __name__ == '__main__': main()

这段代码里最核心的是差速模型逆解：对于一个两轮差速底盘，给定整车线速度vx和角速度wz，左右轮的速度分别满足“线速度加减角速度乘以半个轮距”的公式。wheel_base要你实际量一下左右两个驱动轮中心之间的距离，这个值直接影响转向角度是否准，不要偷懒瞎填。算完速度之后，通过一个映射函数把它转化成PWM范围，然后真正写到底盘的IO口上。

有了这个节点，你就可以先测试一下：启动节点后在另一个终端运行ros2 topic pub /cmd_vel geometry_msgs/msg/Twist "{linear: {x: 0.2}}"，如果车动了，说明底盘环节完全正常。这一步先确认好了，再往下弄网页就踏实很多。

3.3 启动rosbridge并验证连接

底盘能动了，接下来把网页和ROS2之间的桥架起来。

先在第一个终端运行rosbridge服务，命令是：

ros2 launch rosbridge_server rosbridge_websocket_launch.py

看到终端出现类似WebSocket server started on port 9090这类日志，说明桥服务已经听在9090端口上了。这个端口就是前端页面要连接的WebSocket地址。

我再补一个非常有用的验证方法：直接在浏览器里打开http://<主控IP>:9090，你会看到一串JSON格式的服务信息返回，那说明服务是活的。如果打不开，先检查主控的防火墙和端口是否被占用。这一步验证好了再接前端，总比自己连不上就怀疑代码更有效率。

还要注意一个细节：如果你希望外部设备连到小车主控，需要确保自己的电脑和主控在同一个局域网内。在另一个终端可以查看主控IP地址，通常类似192.168.x.x。如果是在一个局域网下，这个IP就是你前端连接rosbridge的地址。别在主控上用localhost，因为最终你会在另一台电脑或手机上打开网页，localhost指向的是那台设备自己，连不上远端的。

3.4 前端页面：几行按钮一个文件

前端侧我说的“简易”，是真的极其简单。不需要框架，不需要编译，一个HTML文件直接搞定。我当时的页面结构就是四个方向按钮加一个停止按钮，每个按钮的onclick事件里构造一个Twist消息发布到/cmd_vel。

这里给出一个可以直接复制的关键代码：

<!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title>ROS2 小车网页遥控</title> <script src="https://cdn.jsdelivr.net/npm/roslib@1.4.1/build/roslib.min.js"></script> </head> <body> <h2>ROS2 小车遥控台</h2> <button id="forward">前进</button> <button id="left">左转</button> <button id="stop">停止</button> <button id="right">右转</button> <button id="back">后退</button> <script> // 连接rosbridge，IP换成主控实际IP let ros = new ROSLIB.Ros({ url: 'ws://192.168.1.100:9090' }); ros.on('connection', () => console.log('已连接')); ros.on('error', (e) => console.log('连接错误', e)); ros.on('close', () => console.log('连接关闭')); // 定义速度话题 let cmdVel = new ROSLIB.Topic({ ros: ros, name: '/cmd_vel', messageType: 'geometry_msgs/msg/Twist' }); function sendTwist(vx, wz) { let twist = new ROSLIB.Message({ linear: { x: vx, y: 0, z: 0 }, angular: { x: 0, y: 0, z: wz } }); cmdVel.publish(twist); } document.getElementById('forward').addEventListener('mousedown', () => sendTwist(0.2, 0)); document.getElementById('forward').addEventListener('mouseup', () => sendTwist(0, 0)); document.getElementById('left').addEventListener('mousedown', () => sendTwist(0.08, 0.4)); document.getElementById('left').addEventListener('mouseup', () => sendTwist(0, 0)); // 其他按钮同理 </script> </body> </html>

这里有一个极其重要的设计细节：我在按钮上绑定的是mousedown和mouseup而不是click事件。为什么？因为click事件在鼠标按下并松开之后才触发，我想要的效果是：按住按钮车就走，松开按钮车就停。用mousedown发送前进速度、mouseup发送零速度，这在遥控交互上是最自然的手感。如果你只绑定click，每按下一次车只会短暂动一下，操控差很多。这个细节是我在实车测试时被“按一下只动一点”这个怪现象逼出来的。

另一个细节是左转时我给了一个很小的前进速度搭配角速度，这样转向过程中车是边前进边转弯的，不会原地打转。如果你的空间很窄，也可以把线速度设成0让它原地旋转，取决于你的使用场景。

3.5 速度映射与安全限制

多数新手会忽略速度映射和安全限制，但我在这上面摔过跟头，值得单独写一段。

Twist消息里的速度和角速度不是随便填的，底盘驱动节点最终会把它们转成PWM，如果数值过大就会导致电机全速猛冲。我在第一版测试时直接把前进速度填了1.0，结果按下按钮小车原地弹射，差点撞上墙。后来我规定自己所有按钮的最大线速度不超过0.3米/秒，最大角速度不超过0.6弧度/秒，这个量级在室内测试足够安全，既能看到运动效果又不会失控。

同时我在前端加了一个急停按钮，按下后立即发送全零速度。紧急情况下，你不需要去找“停止”按钮，直接同时松开所有按键或者点一下急停就能让车停下来。我在底盘节点端也做了兜底：如果连续2秒没有收到新的/cmd_vel消息，就自动把输出电机速度清零。这样即使前端突然断连或者用户关闭网页，车也不会一直处在某个速度上傻跑。

设置安全限制的另一个考虑是保护电机和驱动模块。电机如果长时间满负荷运转，驱动芯片会发烫，严重时会直接烧毁。PWM在最开始阶段还要做一个软启动：让它从0慢慢升到目标值，而不是一步拉到最大，这既能保护齿轮箱也能避免车身起步时“弹跳”。软启动在前端体现为一条斜坡函数，在底盘端体现为对速度变化做限幅，两种方式可以同时做。

3.6 让车开起来像人开的：平滑曲线与手感优化

第一版改完能跑之后，我很快就发现了一个问题：车走起来非常“生硬”。按下按钮就全速前冲，松开就立刻刹停，原地转向时车身还会抖。这种生硬感在遥控车里很常见，但真正开起来一点手感都没有，更像一个玩具而不是机器人。

生硬的原因其实很简单：速度指令发生了突变，从一个值瞬间跳到另一个值，底盘的电机没有时间做缓冲就被命令全力加速，自然会产生顿挫感。方向盘在汽车里本身就有一个转向机构做机械缓冲，这些小车可没有，所以需要软件层面把突变变成渐变。

我的做法是在底盘节点里加一个速度限幅器：每次读入/cmd_vel的新目标速度，并不是直接输出给电机，而是让电机的输出速度在短时间内逐步向目标值逼近。每次回调里，比较当前输出速度和目标速度的差值，如果差值超过最大变化量，就只允许变化这么多。这个把线性加速度限制住的思路，在机器人控制里有个专门说法叫accel limit。

再进一步，我还在前端做了“缓释”逻辑：按键按下后不立即输出全速，而是在几十毫秒的时间里按斜坡速度逐渐升高到目标值。这样可以模拟出“油门渐进”的效果，车的起步明显顺滑了。实测下来，加了这两层缓冲之后，车的整体控制手感从“卡点车”变成了“线性车”，舒服了不止一个档次，转向也不再抖。

这一点值得亲手调：变化量太小会显得车反应迟钝，太大又退回到生硬，我最终调下来取了一个临界值，每次速度变化不超过0.05米/秒，既能保持响应速度又不至于突兀。

4. 调试过程与常见问题速查表：我被这些坑耽误过的时间

4.1 点按钮车不动：四级排查法

遇到“网页点击了，车纹丝不动”的问题时，我建议按这四级来排查，每级排查完都能缩小问题范围。

第一级查前端连接。打开浏览器的开发者工具，看Console面板有没有报错。最常见的前端问题是WebSocket地址写错，比如把端口写成了8080或者IP地址填错了。如果Console里报错Error: WebSocket connection to 'ws://xxx:9090' failed，就说明连不上rosbridge。这个时候回到主控终端确认服务还在跑，再在本地浏览器里访问http://主控IP:9090看能否返回信息。

第二级查话题消息。如果前端连接正常，但车依然不动，就去主控终端执行ros2 topic echo /cmd_vel，然后在前端按一下按钮。如果这个终端里哗啦哗啦滚出一堆速度消息，说明从浏览器到rosbridge再到话题通信这一整段都通了，问题基本锁定在底盘驱动节点。如果没有消息，就用ros2 topic list确认话题名称是不是拼错了。我当时就犯过一个低级错误，前端订阅的话题名是/cmd_vel，但底盘节点订阅的是/cmd_vel_test，两个名字风马牛不相及，消息全发到黑洞里去了。

第三级查底盘节点状态。回到运行底盘节点的终端窗口看有没有报错日志。如果是串口权限问题，一般是权限类报错；如果是驱动节点根本没启动，那话题自然没人订阅。用ros2 node list可以查看当前活动的节点都有哪些，确保drive_node之类名称的节点在线。

第四级查硬件连接。PWM引脚接线不对、供电电压不足、电机驱动模块使能引脚没有被拉高等问题都可能导致软件一切正常但车不动。用最简单的方法：直接给电机接入一个直流电源，看电机能不能转。如果电机基本运动正常，再回到驱动模块测PWM波形。硬件排查往往是最后一步，也往往是最容易让人烦躁的一步，别一上来就拆线。

4.2 网页经常断开或者连接迟缓

运行一长段时间之后，网页端偶尔会提示“连接关闭”。最直接的原因是rosbridge和前端的WebSocket长连接在没有心跳机制的情况下，被网络设备当成空闲连接清理了。这种掉线不是立刻能察觉的，但当你需要按下按钮时才发现车已经不受控。

我的解决办法是在前端代码里加一个定时ping操作。每隔几秒向rosbridge发送一个空消息或者固定心跳指令，让连接一直处于活跃状态。同时给ros.on('close')事件加上自动重连逻辑，一旦断开了就在几秒后重新创建连接。这两者配合起来，网页控制端的稳定性会有质的提升。

另外还有一类连接迟缓的问题，原因是两个设备之间走了不同的网络带宽，异常带宽拥堵会造成消息延迟放大。建议在做运动控制测试时，尽量让路由器只有这三四个设备在线，不要再开高清视频流之类的大流量应用。我实测过，带两台设备的同时播放视频再控制小车，延迟从几十毫秒直接飙升到三四百毫秒，体感非常明显。

还有一个偏冷门但值得注意的点：浏览器对WebSocket连接数和重连频率做了限制，如果页面里频繁地创建新连接而不断开旧连接，可能会打满连接数。我建议在页面初始化时创建一次ROSLIB.Ros实例，全局复用，不要每次点击按钮都去new一个新的连接。很多新手的WebSocket相关问题就是这么来的。

4.3 小车走不直的调参经验

改完遥控能走直线吗？说实话，刚装好的车没有一个能完全走直线的。这里有两个主要原因：一是左右电机的制造和装配参数存在细微差异，同样的PWM值输出到左右轮，实际转速并不完全一致；二是差速底盘的齿轮箱摩擦力和轮子与地面的附着系数在两边不一样，导致两边累计的里程不同。

解决的第一层是“里程计修正”：利用编码器反馈算出左右轮实际的转速，然后做一个闭环PID控制，让左右轮的实际转速稳定在相同目标值附近。这一步做完之后，直线偏差会有明显改善，但还是会有微小的累计漂移。

第二层是“速度比例校准”：在小车自由直线行驶的一段固定距离上，记录左右轮编码器的计数，算出左右轮速度的实际比例关系，然后在输出PWM之前乘以一个校正系数。比如发现左轮总是跑得比右轮快5%，就给左轮的PWM乘以0.95。这个系数需要在硬地面上测量，地毯和瓷砖的结果都不一样。

最有效的还是把两侧轮子的基础PWM特性做一次全面标定，生成“PWM到实际速度”的映射曲线。这条曲线越准，底盘的控制精度越高。我做的时候花了不少时间在硬地面上跑大量来回关系测试，但换来的是之后每次调试其他功能都不用再回来怀疑底盘不直，这笔时间花得值。

4.4 新手避坑清单

拿我这一路踩过的坑，做了个速查表，你遇到类似问题时直接照着看。

这七个问题里，我浪费时间最多的是第二个：话题名不一致。后来我养成了一个习惯，每次调试前先在终端里执行ros2 topic list和ros2 node list，把当前的通信拓扑看一眼，再开始动手。这个习惯救了我很多次。尤其是新手，不要它有它的道理，但也别被它折腾傻，先确认名字对了再排查其他复杂原因。

调试这件事本质上就是“分层排查，逐段隔离”。从浏览器到话题是一段，从话题到电机是另一段。把每一段独立验证好，再把两端连起来，问题就能被快速定位。这也是我这套方案最大的好处，因为我选择了ROS2的话题机制，中间所有环节都是标准化的，任何时候都可以用工具手动注入一条测试消息来验证某一段是否工作。

这套改造做完之后，我对“网页控制机器人”这件事的信心变足了很多。以前总觉得远程操控机器人需要一套特别复杂的专用协议，做了之后才明白，底层通信交给通信协议栈就好，上层只需要把速度消息推给话题，剩下的事情底盘自己会处理。这种“前端只管发指令，底盘只管执行”的彻底分工，让一个人同时搞定整套系统的难度骤降。

下一期我想在这个基础上加一个摄像头画面传输，把“按钮控制”升级成“第一视角驾驶”，让网页不仅能看到车动了，还能看到车开去哪了。那条链路又要牵涉到画面压缩、码流传输、前端渲染，折腾起来估计又是一整篇文章的量，不过底盘的这套话题通信架构不用改，前端接收画面之后再往/cmd_vel发指令就行。到时候接着聊聊图传和显示延迟的事。