做这个小车的想法其实来得挺简单——手头刚好有一块吃灰的 ESP32 开发板又刷到别人玩的全向轮移动视频那种“横着走、斜着走、原地转圈”的灵活劲儿确实很戳人。于是干脆组了一台三轮全向轮机器人用手机连 WiFi 直接控制整个过程从硬件搭建到写代码、调车前后花了大概两个周末。这篇就把完整的方案、原理、代码和踩坑记录都整理出来给想做同款或者正在纠结“ESP32 到底能不能带动全向轮平台”的朋友一个参考。先说结论ESP32 做全向轮机器人的主控非常合适。它自带 WiFi 和蓝牙双核 240MHz 的处理能力跑运动学解算绰绰有余GPIO 也够用最关键的是 Arduino 生态成熟代码写起来不费劲OTA 无线升级也方便后期想加摄像头、加传感器都不用换主控。这篇教程适合有一定 Arduino 基础、想玩移动机器人但不想上树莓派那么重负担的爱好者也适合正在做课设或比赛底盘验证的同学。我会把三轮全向轮的运动学公式、手机端虚拟摇杆的实现、WebSocket 低延迟通信这些核心细节都讲清楚尽量做到照着操作就能跑起来。1. 项目整体设计与思路拆解1.1 三轮全向轮 vs 四轮麦克纳姆轮现在市面上常见的全向移动底盘主要有两种一种是三轮全向轮Omni Wheel另一种是四轮麦克纳姆轮Mecanum Wheel。我在这个项目里选了三轮全向轮原因很直接结构简单、驱动少、逻辑清楚。全向轮的特点是轮子外圈安装了一圈小滚子滚子轴线与轮子转动方向垂直。这意味着轮子可以在主动驱动方向正常转同时在滚子的被动方向上几乎无摩擦滑动。三个轮子按 120 度均布在底盘上通过三个轮的转速组合机器人就能实现平面内的任意方向平移和自转——也就是全向移动。四轮麦克纳姆轮固然承载能力和稳定性更好但它需要四个电机和四个驱动硬件成本更高代码里要处理的电机数量也翻倍。对于手机遥控这种应用场景三轮全向轮的机动性完全足够而且运动学公式更简洁调试起来也快。如果你打算后期加机械臂、加沉重负载再考虑换四轮底盘但如果只是为了玩控制、验证算法三轮全向轮是性价比最高的起点。1.2 为什么主控选 ESP32做 WiFi 无线控制的小车主控的选择其实不多。传统 Arduino Uno 这类板子没有 WiFi需要外接 ESP8266 模块做串口透传构架复杂且延迟不好控制树莓派算力强但启动慢、功耗大、成本高对小尺寸底盘来说有点杀鸡用牛刀。ESP32 把 WiFi、蓝牙、双核处理器、丰富的外设接口全集成在一块板子上价格却只要几十块。实际测试下来WebSocket 通信加运动学解算加 PWM 输出ESP32 的 CPU 占用率还不到 20%运行得相当轻松。更关键是 ESP32 的 LEDC 硬件 PWM 模块支持多路独立输出三路电机控制信号可以直接由硬件产生不占用 CPU 时间这对后续扩展传感器和算法很有价值。还有一个非常实用的点ESP32 支持 OTA 无线升级。小车装好之后改代码不用再拆壳子接 USB 线直接在 Arduino IDE 里选择网络端口就能烧录新固件调试效率高了一个量级。这一点在后面我会单独讲配置方法。1.3 整体系统架构这个项目的系统架构不算复杂分三层控制端手机浏览器打开一个本地网页页面上有一个虚拟摇杆。手指在摇杆区域滑动页面通过 WebSocket 把摇杆的偏移量对应机器人期望的 Vx、Vy 和角速度发送给 ESP32。主控端ESP32 同时扮演 WiFi 接入点和 WebSocket 服务器。它接收控制指令后先做运动学反解把 Vx、Vy、ω 换算成三个轮的转速再通过 LEDC 生成 PWM 信号驱动电机。执行端三个带减速箱的直流电机分别由一路 TB6612 驱动模块控制电源由 7.4V 锂电池统一供给。选 WebSocket 而不是普通的 HTTP 请求是因为控制类的指令对实时性要求高。HTTP 每次通信都要建立连接、发送请求头、等待响应一轮下来几十毫秒就过去了遥控手感会明显发肉。WebSocket 建立一次长连接后数据以帧为单位直接推送实测从手机摇杆变化到电机响应延迟能控制在 50 毫秒以内虽然不能和有线遥控比但日常玩足够跟手了。2. 硬件准备与底盘搭建2.1 核心硬件清单这个项目的硬件清单不算复杂我把选型和一些关键参数列出来方便你照着采购或替换部件型号/规格数量说明主控板ESP32 DevKitC / NodeMCU-32S1任选一款 GPIO 引出完整的开发板即可电机N20 减速电机 6V1:30 减速比3带霍尔编码器版本更好后续可以做闭环电机驱动TB6612FNG 模块2一块驱动两路三路用两块不推荐 L298N全向轮45mm 或 60mm 三轮全向轮3带滚子注意孔径要和电机轴匹配锂电池7.4V 2S 锂电池1容量 1200mAh 左右就够玩半小时降压模块MP1584 / LM259615V 降压给 ESP32 供电底盘亚克力板或 3D 打印底盘1三轮 120 度均布结构其他杜邦线、铜柱、开关、焊锡若干用于固定和接线电机我选的是 N20 减速电机主要看中它体积小、自带减速箱、转速合适。全向轮小车不需要太高的转速配合 1:30 减速比输出轴转速大概在每分钟 200 转左右配上 48mm 的小轮子线速度大约 0.5 米每秒室内遥控刚好合适。如果你手头只有 28BYJ-48 步进电机理论上也能用但那个电机转速太低、发热大控制起来不如直流减速电机顺手不建议优先考虑。2.2 电机驱动的选择为什么不用 L298N电机驱动这块我踩过不少坑最想提醒的就是别用 L298N。市面上最常见的 L298N 模块压降太大电源输入 7.4V到电机端可能只剩下 6V 左右扭力损失明显而且模块上自带的 5V 稳压输出纹波大直接给 ESP32 供电容易导致 WiFi 模块工作不稳定。TB6612FNG 是更好的选择。它的导通内阻低压降小同样 7.4V 输入能更有效地传到电机而且逻辑电压输入可以直接接 ESP32 的 3.3V 引脚不需要额外电平转换。TB6612 的缺点是一块模块只能驱动两路电机三路电机需要两片多花十来块钱但换来的稳定性和效率完全值得。接线方面每片 TB6612 有 PWMA、AIN1、AIN2 三个控制脚和 AO1、AO2 两个电机输出脚。另外要特别注意 VM 接电池正极、VCC 接 3.3V 逻辑电源、GND 要跟 ESP32 共地。这个共地问题很关键如果驱动板和 ESP32 的地没连在一起PWM 信号参考电位不一致电机会出现抖震或直接不转。2.3 供电方案与布线注意事项供电方案我踩过好几次坑这里展开讲一下。三轮车满负荷运行时三个电机同时启动的瞬时电流能达到 1.5A 到 2A如果直接把 7.4V 电池接到 ESP32 的 5V 引脚上轻则稳压芯片发烫重则直接烧板。我的做法是电池正极先接总开关然后分成两路。一路接 TB6612 的 VM 电机电源端另一路经过 MP1584 降压模块降到 5V再给 ESP32 的 5V 引脚供电。这样电机的大电流和逻辑电源完全隔离电机启停造成的电压波动不会影响 ESP32 的稳定运行。实测在电机堵转瞬间电池电压最多掉到 6.5V 左右但 ESP32 端依然稳定在 5V 附近没有再出现过随机重启的毛病。布线的时候还有几个细节要注意。第一所有功率线的线径不要小于 0.5 平方毫米特别是电池到驱动板的线细线在大电流下发热明显。第二电机两端要并联一个 104 瓷片电容或者电解电容吸收换向产生的反向电动势这个对减少 ESP32 的复位问题和电机干扰有很大帮助。第三PWM 信号线尽量远离电机线和电池线如果空间实在紧张就用杜邦线交叉绑扎的走法避免平行长距离走线。3. 全向轮运动学基础3.1 三轮全向布局的运动学反解推导做全向轮机器人绕不开运动学。好在这个项目的三轮全向布局公式推导并不复杂只要理解了方向关系代码就是几行三角函数的事。设定机器人的坐标系以底盘中心为原点正前方为 X 轴正方向朝左为 Y 轴正方向逆时针旋转为角速度 ω 正方向。三个轮子的安装角分别为 0 度、120 度和 240 度也就是说一号轮在正前方二号轮在左后三号轮在右后。每个全向轮的驱动方向沿着安装点所在圆的切线方向。机器人的整体速度 (Vx, Vy, ω) 投影到每个轮的切线方向上就能得到这个轮需要的线速度。公式如下v1 -Vx·sin(0°) Vy·cos(0°) L·ω v2 -Vx·sin(120°) Vy·cos(120°) L·ω v3 -Vx·sin(240°) Vy·cos(240°) L·ω其中 L 是轮子安装点到机器人中心的距离。代入三角函数值后v1 Vy L·ω v2 -0.866·Vx - 0.5·Vy L·ω v3 0.866·Vx - 0.5·Vy L·ω这个结果可以当作自行车转向那种直觉来理解机器人要正着往前走一号轮正前方这个其实是不转的它的驱动方向和前进方向正好垂直全靠在二号、三号轮的差动配合下被动滚动过去。要往左边平移一号轮就是主力三号轮配合。要原地转圈三个轮子朝同一个圆周方向一起转。这种特性第一次接触会觉得反直觉但实际跑起来运动非常顺滑。3.2 从摇杆输入到轮速的换算流程手机上虚拟摇杆的输出量是一个二维向量摇杆偏离中心越远向量越大。我把它映射成机器人的期望速度摇杆前后拨动对应 Vx左右拨动对应 Vy另外用一个滑块或者摇杆旋转手势来控制角速度 ω。为了让操作更直观我直接采用“摇杆方向决定机器人平动方向”的映射不做相机视角跟随避免新手一上来就晕头转向。换算流程是这样的手机端把摇杆位移归一化到 -255 到 255 的整数值和角速度值一起打包成字符串比如vx:128,vy:-64,rot:32通过 WebSocket 发给 ESP32。ESP32 收到后先做归一化再套入上一节的反解公式算出三个轮的线速度最后根据电机减速比和轮径换算成 PWM 占空比。这里有个重要细节反解公式算出的是线速度单位是米每秒但实际控制电机用的是 PWM 值。这两者之间是近似线性关系需要在实机上调一个比例系数。我的办法是先用 50% 占空比让小车跑直线用秒表和卷尺实测出实际线速度算出“PWM 值到线速度”的换算系数然后把这个系数写进代码里作为常量。这样遥控软件端可以直接以物理速度为单位下发指令语义清楚后续调整也更加方便。4. 软件架构与核心代码实现4.1 开发环境与整体框架软件部分我用的 Arduino IDE 2.xESP32 开发板支持包直接在“开发板管理器”里搜索 ESP32 安装即可。注意安装后要选择正确的开发板型号我用的 NodeMCU-32S对应的板卡选项是ESP32 Dev ModuleFlash 大小默认选 4MB 就行。整个固件逻辑分为几个模块WiFi 连接模块负责开启热点或连接路由WebSocket 服务模块负责接收手机指令运动学解算模块把 Vx、Vy、ω 换算成轮速电机控制模块负责输出 PWM 和方向信号。模块之间通过全局变量传递数据WebSocket 收到新指令就更新期望速度主循环里做一次解算并更新 PWM 输出。这种设计简单直接也方便以后加入 PID 闭环或传感器融合。代码里我用了几个现成的库最核心的是 Arduino WebSockets在库管理器里搜 WebSockets 安装即可。这个库同时支持 WebSocket 客户端和服务器对 ESP32 适配得很好开箱即用不需要自己处理握手协议和帧解析。4.2 WiFi 接入方式AP 模式还是 STA 模式ESP32 作为控制对象WiFi 接入方式有两种选择一是让 ESP32 开热点AP 模式手机直连 ESP32 的热点二是让 ESP32 连接家里路由器STA 模式手机和 ESP32 在同一局域网内通信。两种方案我都试过各有适用场景。AP 模式的优势是极简、零配置小车通电后手机就能搜到名为 OmniBot 的热点连上就能控制适合户外、实验室、比赛场地这些没有现成路由器的场合。缺点是手机连了 ESP32 热点后就不能正常上网了而且 ESP32 热点的覆盖范围有限隔一堵墙就容易丢包。STA 模式的优点是可以借助路由器扩展通信距离手机不用切换网络就能边上网边控制后期如果要做室内定位、多机器人协作这些功能也更方便。缺点是第一次要给 ESP32 配置 WiFi 账号密码我建议把配网信息做成一个简单的配置页或者直接写死在代码里方便调试。考虑到教程的通用性我把默认方式设为 AP 模式然后在代码里留了 STA 模式的配置入口你只需要把两个 ssid、password 变量改成自己路由器的信息就行。AP 模式的密码我建议设简单一点毕竟是局域网控制用的搞太复杂每次连接都难受。4.3 手机端网页与虚拟摇杆的实现手机控制端我直接写了一个网页不依赖任何 App手机浏览器打开就能用。网页部分存在 ESP32 的 SPIFFS 文件系统里也可以通过代码里的 HTML 字符串直接输出为了少一个文件烧录步骤我选择把网页代码直接拼成一个字符串常量存在固件里这样只刷一次固件就全搞定。网页的核心是一个虚拟摇杆实现思路是用一个圆形区域和一个小圆点。手指在屏幕上滑动时通过 touch 事件算出触点相对圆心偏移量映射到 -255 到 255 的范围再以 50 毫秒的间隔通过 WebSocket 发送给 ESP32。这里有个手感细节摇杆的返回中心需要加死区处理。手指离开屏幕时如果摇杆直接归零可能导致电机瞬间反转小车会抖一下。我加了 15 的阈值判断摇杆偏移量小于这个值的都当作归零处理这样电机不会因为细微抖动来回摆动。另一个细节是虚拟摇杆区域要设置touch-action: none否则手机浏览器默认手势会干扰摇杆操作。4.4 电机控制与运动学解算的代码实现电机驱动的代码我单独封装了两个函数一个负责设置某路电机的方向和 PWM另一个负责接收三个速度值并做解算输出。方向控制通过两个 IN 引脚的组合实现PWM 值则用到 ESP32 的 LEDC 硬件通道。这里特别说明一下 ESP32 的 PWM 用法。LEDC 模块分为 0 到 15 共 16 个通道先通过ledcSetup(channel, freq, resolution)配置频率和分辨率再用ledcAttachPin(pin, channel)把引脚绑定到通道。分辨率我选了 8 位也就是 0 到 255 的占空比频率选 5000Hz这个频率下电机噪声适中控制线性度也不错。下面是省略了引脚定义和头文件的电机控制核心代码void setMotor(int pwmPin, int in1, int in2, int speed) { // speed 范围 -255 到 255正数正转负数反转 speed constrain(speed, -255, 255); if (speed 0) { digitalWrite(in1, HIGH); digitalWrite(in2, LOW); } else { digitalWrite(in1, LOW); digitalWrite(in2, HIGH); speed -speed; } ledcWrite(pwmChannelMap[pwmPin], speed); } void updateWheels(float vx, float vy, float rot) { float L 0.105f; float v1 vy L * rot; float v2 -0.866f * vx - 0.5f * vy L * rot; float v3 0.866f * vx - 0.5f * vy L * rot; // 乘以速度系数把线速度换算成 PWM setMotor(MOTOR1_PWM, MOTOR1_IN1, MOTOR1_IN2, v1 * PWM_PER_MPS); setMotor(MOTOR2_PWM, MOTOR2_IN1, MOTOR2_IN2, v2 * PWM_PER_MPS); setMotor(MOTOR3_PWM, MOTOR3_IN1, MOTOR3_IN2, v3 * PWM_PER_MPS); }运动学解算写完之后一定要先做一轮“空转验证”。把小车架起来不让轮子碰地给三个轮子分别下发纯前向、纯横向、纯旋转的速度指令用肉眼观察三个轮子的转向是否符合公式预期。比如下发纯前向 Vx1 时应该有如图所示的特征一号轮不转二号轮反转三号轮正转。如果转向不对多半是电机接线方向反了交换一下该路电机的两个 IN 引脚就行。WebSocket 接收指令的部分也贴一下核心就是解析收到的字符串并调用更新函数void wsEvent(uint8_t num, WStype_t type, uint8_t* payload, size_t length) { if (type WStype_TEXT) { char* data (char*)payload; float vx 0, vy 0, rot 0; sscanf(data, vx:%f,vy:%f,rot:%f, vx, vy, rot); updateWheels(vx / 255.0f, vy / 255.0f, rot / 255.0f); } }手机端网页发送数据的核心代码也很短这里展示关键部分完整代码我整理后可以发在评论区或网盘if (ws.readyState WebSocket.OPEN) { ws.send(vx: vx ,vy: vy ,rot: rot); }为了省电和降低干扰我还加了一个超时保护机制ESP32 在 500 毫秒内没有收到新的控制指令就默认把三个轮子全部停止。这个机制非常重要因为手机网页在锁屏或切后台时 WebSocket 会断连如果不加这个保护小车会保持最后一条指令状态变成一个脱缰的野马。4.5 OTA 无线升级配置OTA 是 ESP32 最实用的功能之一尤其对车载设备来说避免频繁插拔 USB 线这件事能省下大量时间。Arduino 环境下配置 OTA 非常简单只需要引入 ArduinoOTA 库在 setup 里初始化在 loop 里调用处理函数。#include ArduinoOTA.h void setup() { // ... 其他初始化 ArduinoOTA.setHostname(omni-bot); ArduinoOTA.setPassword(admin123); ArduinoOTA.begin(); } void loop() { ArduinoOTA.handle(); // ... 其他循环逻辑 }配置好之后在 Arduino IDE 的端口列表里会多出一个网络端口选择它再点上传就会通过 WiFi 把新固件推送到 ESP32。第一次烧录 OTA 必须用 USB 线但之后只要不把 OTA 功能弄崩基本可以彻底告别 USB 线。要注意的是OTA 升级期间 ESP32 会短暂重启断开 WiFi手机端的 WebSocket 连接会自动断开升级完成后需要刷新网页重新连接这是正常现象不用慌。还有一点如果你启用了 OTA一定要保证固件里没有在 setup 阶段阻塞太久的操作比如长时间的业务逻辑初始化。因为 OTA 需要 ArduinoOTA.handle() 在 loop 里持续运行才能维持网络协议。我曾经因为一段卡 5 秒的配置读取把 OTA 搞废过一次最后只能重新接 USB 线救回来。血的教训提醒大家 OTA 的循环一定不能阻塞。5. 实机联调与参数标定5.1 通电前的硬件安全检查清单硬件装好、代码写完之后千万别急着通电。我这个项目前后改了五版接线前两版都因为低级错误返工总结出一个通电前检查清单照着走一遍能避免九成事故电池电压是否正常7.4V 锂电充满约 8.4V低于 6V 说明电池亏电或保护板触发了。电机驱动板 VM 和 ESP32 的电源是否分开绝对不能把电机驱动板的 VM 直接接到 ESP32 的 5V 引脚。所有 GND 是否已经共地包括电池负极、驱动板 GND、ESP32 GND。电机线是否短路用万用表蜂鸣档测电机两端电阻短路的电机上电就会烧驱动。PWM 信号线是否接错脚位对照代码里的引脚定义逐根核对。螺旋桨效应检查轮子和电机轴的顶丝是否锁紧如果没锁紧上电后轮子会原地打滑飞出去。检查通过后先不要通电用手转动每一个轮子感受是否有卡顿。全向轮的滚子在转动时如果被卡住运动学就会失效表现为小车往特定方向推不动或者跑偏。5.2 电机方向与速度的逐一标定第一次通电后不要急着用手机控制先在串口监视器里手动下发指令逐个检查每个电机的转向。我这里写了一个简单的测试指令发送t1 128表示让一号轮正转 128 占空比发送t1 -128表示反转。逐个测试时要先确定“正方向”的定义。在运动学公式里一号轮的线速度正方向约定为沿着安装点切线的某个方向。如果你接电机线接反了公式里的符号就会反小车往前的指令会变成往后往左的指令会变成往右。这种错误在最终整车测试时才会暴露排查起来很费劲。所以我的建议是在标定阶段就为每个轮子定义一个“正方向”并记录在文档里让代码里的公式、实机转向和文档完全对应避免一错错到底。方向确认后再标定 PWM 最低启动值。直流减速电机都有启动电压PWM 占空比太小的时候电机不转加大到某个值才开始动这个值我实测在 60 到 90 之间8 位分辨率下约 25% 到 35%。这个最低启动值是运动学线性化的关键参数如果你在反解公式里直接用了 0 到 255 的全范围就会发现小速度指令下轮子纹丝不动只有指令超过阈值才有反应整个摇杆手感会特别差。我的处理办法是把速度值做一个映射将 [-255, 255] 映射到 [-255, -(min20)] 和 [min20, 255] 两个区间保证指令不为零时电机一定在转。5.3 无线控制延迟的实测与优化装好之后第一件事肯定是拿手机连上热点控制一下。初次上手你会发现几个问题延迟、抖动、还有方向感混乱。我这里先把延迟问题说清楚。我用手机拍了一段包含摇杆移动和车轮转动的慢动作视频通过逐帧分析估算整个控制链路的延迟。实测 AP 模式下摇杆移动到轮子响应约在 40 到 60 毫秒这个数字对遥控来说还算可以但还有优化空间。优化手段主要有三个一是把 WebSocket 数据发送间隔从 50 毫秒缩短到 30 毫秒提高指令刷新率二是取消网页端不必要的动画帧让摇杆位移直接读取原始 touch 坐标三是把 ESP32 的 CPU 频率从默认的 160MHz 提升到 240MHz减少解算时间。值得注意的是AP 模式的延迟和 STA 模式差异不大因为 ESP32 的 WiFi 模块本身延迟就很低瓶颈往往在手机端浏览器的触摸事件采样频率上。如果追求极致的实时性可以考虑把 WebSocket 换成 UDP 协议但那样又要处理丢包对一般的遥控场景收益不大。5.4 开环控制下的直线与转向调校由于这个版本没有装编码器反馈属于开环控制小车的直线行走并不会非常直。造成跑偏的因素很多三个电机的一致性问题、轮子滚子的摩擦差异、底盘重心偏移、地面不平整等等。开环状态下我实测跑 3 米直线横向偏移大约在 10 到 15 厘米作为玩具绰绰有余但如果想更稳就得做闭环控制。最简单的补救方案是给每个轮子加一个速度补偿系数。我让小车分别以正向和反向跑 2 米记录实际走的位移偏差然后微调每个轮子的 PWM 系数让三个轮子在实际地面上的线速度尽量一致。这个方法能在一轮调校内把 3 米直线偏移压到 5 厘米以内。如果你后期想追求更高的控制精度建议换用带霍尔编码器的 N20 电机在 ESP32 上通过 PCNT 脉冲计数模块读取编码器再加上一个简单的 PID 闭环。这个扩展方向所需硬件改动不大编码器信号接 ESP32 的 PWM 输入捕获引脚即可固件里只需要新增一个速度环的 PID 函数。这个后面可以单独开一篇来说这里就不展开了。6. 常见问题与排查实录6.1 问题速查表做这个项目过程中遇到的坑不少我把最典型的几类整理成了一个速查表方便你先自查再问问题现象可能原因排查方法解决方案电机完全不转驱动板供电断开、共地缺失万用表测 VM 和 GND 电压重新接线确保共地部分电机不转PWM 引脚配置错误或驱动通道损坏用测试指令分别驱动每路电机核对引脚定义更换驱动板电机抖动但不转PWM 占空比低于启动阈值串口打印占空比数值增加最低启动值映射WiFi 搜不到热点ESP32 未能正常启动或热点崩溃看串口日志复位重启检查电源稳定性手机连上热点但打不开网页静态 IP 未配置或网页服务未启动手机浏览器访问 192.168.4.1检查 server.begin() 是否调用控制指令有延迟发送间隔太长或 CPU 降频查看 WebSocket 日志时间戳缩短发送间隔提高 CPU 频率小车跑偏严重电机一致性差或轮子打滑逐轮测转速加补偿系数或换编码器电机小车突然狂转不停控制指令丢失确认网页连接状态启用超时停止保护机制电池掉电快电机堵转或驱动板静态功耗高测工作电流避免长时间堵转选用低功耗待机6.2 几个值得记录的实战心得第一个心得是电源问题永远是 ESP32 项目的第一大坑。这个项目里 80% 的“ESP32 莫名其妙重启”“WiFi 连接不上”的故障最后都追查到了供电上。ESP32 的 WiFi 发射瞬间电流可以冲到 300mA 以上如果供电端压降太大芯片就会进入欠压复位循环。所以做移动机器人的时候电源这一块宁可多花点心思也不要图省事直接并电池。第二个心得是运动学公式的符号定义比公式本身更容易出错。我在第一次整车调试时发现前移变成斜移查了很久才发现是二号轮的正方向定义搞反了。后来我养成了习惯用一个简单的正向运动学验证反解给定一组轮速算出理论上的机器人速度再对照实机运动方向全部对上了才进行下一步。第三个心得是手机热点的兼容性问题比想象中多。有些手机开放热点时会启用 AP 隔离导致连上热点的 ESP32 无法和手机上的其他设备互通。排查这个问题的方法是看手机端能否从 ESP32 获取到网页如果打不开网页但 WiFi 信号又是满格基本就是 AP 隔离在作怪。这种情况建议改用 ESP32 的 AP 模式或者换成普通路由器测试。6.3 WiFi 掉线的排查思路最后单聊一下 WiFi 掉线问题这是所有无线控制项目里最常见的幺蛾子。我在调试过程中遇到过好几种掉线表现连上之后几秒钟就断开、运行一段时间后随机断开、以及指令卡顿但不完全断开。针对不同表现排查思路也不一样。对于“连上就断”的情况优先怀疑供电。把 ESP32 的供电改成单独的 5V 2A 电源适配器测试如果问题消失就基本坐实了供电不足。对于“运行一段时间后随机断开”的情况优先怀疑 WiFi 信道干扰。ESP32 默认的信道可能和附近路由器重叠我在代码里手动指定了信道 1 到 6 之间比较空闲的一个掉线概率明显降低。对于“指令卡顿但不完全断开”的情况通常是手机端网页在后台被系统省电策略挂起了这个问题只能靠提醒自己保持网页前台运行来解决手机浏览器端没法完全绕过系统策略。另外一个非常实用的排查思路是在 ESP32 固件里加状态日志。我在 WebSocket 断开和重连的回调函数里都加了串口打印记录断开时间和原因编号。跑了几个小时之后通过分析日志就能发现掉线的规律比盲猜要有用得多。这也是我在做任何 ESP32 通信项目时都会保留的调试手段。用了一个多月之后这台小车现在成了我桌子上最常开机的东西。周末改改代码、换个控制界面或者单纯推着它在阳台地砖上转两圈都挺解压。我的建议是先照着开环版本把整套流程跑通把 WiFi 通信和运动学这两块底座打稳再根据自己的兴趣往闭环、传感器、自动导航这些方向延伸。全向轮底盘的乐趣不在于车本身多高级而在于它验证控制逻辑的速度足够快让你今天写完公式明天就能看到车按你的预期做出动作。这种即时反馈的成就感就是继续往下做的最大动力。