企业官网建设流程全解析

1. 这份讲义解决的核心问题

先说说我为什么觉得RoboMaster值得单独做一份硬件讲义。很多队伍招新的时候，新队员拿一本《电路原理》或者《模拟电子技术》啃，啃到第三周还在算静态工作点，连一块单片机开发板都没点亮。等到真正开始画板子、焊板子、调板子，又发现学校里教的跟赛场上实际要用的完全是两回事——比赛里根本没人关心你用哪种拓扑结构的Buck电路，只关心你降压模块在电容击穿瞬间会不会把主控一起带走。

我带的队伍在2022年之前也踩过这个坑，后来花了两个赛季把三年积累的硬件设计、调试、故障排查经验整理成了一份内部讲义，也就是现在这版V0.2.1。所谓V0.2.1，准确说是第二版第三次小修订，每次修订都是因为某个知识点写得不够细，或者某张原理图被新队员问出十遍以上的重复问题。

这份讲义的核心定位不是替代教科书，而是给RoboMaster硬件组新队员一条足够明确的“上手指南+进阶路线”。它要解决三个具体问题：

• 新人不知道该学什么：学校里教的模电数电太散，跟机器人硬件直接相关的最小系统、电机驱动、电源管理这些核心模块没有人串成一条线。
• 没有人告诉你怎么选型、怎么画板、怎么调板：选型不是看参数表那么简单，画板不是连上网络标签就行，调板更是有大量经验性的东西在里面。
• 老队员口头传承的知识容易丢失：今年学长带学弟，明年学长毕业，经验就断代了。讲义把踩过的坑沉淀下来，后面的人不用重复踩。

这份讲义适合谁看？如果你是刚入队、准备走硬件方向的新队员，它适合你从第一章看到最后一章，按顺序学；如果你已经有一定基础，负责某个模块（比如电源、电机驱动、传感器接口），可以直接跳到自己负责的章节，里面的选型思路和调试流程比参数本身更有价值；如果你是其他组别想懂一点硬件的电控或算法队员，也有帮助——至少你能看懂硬件组给你的原理图，知道哪些节点不能乱碰。

2. 讲义的整体架构与设计思路

2.1 从系统级需求倒推知识树

我在编这份讲义V0.2.1的时候，一直没有按“元器件大全”的框来组织章节。比如先讲电阻电容晶体管，每种元器件讲两页，这是教材的思路，不是比赛的思路。比赛的思路应该是以一个完整的机器人硬件系统为骨架，一个一个模块去吃透，缺什么补什么。

翻开这份讲义的目录，你会看到它不是按元器件大类排的，而是按一个步兵机器人从供电到执行再到感知的实际链路排的：

• 第一章：电路基础快速复习（给忘光了的同学用的，一周内追上进度）
• 第二章：供电系统设计——从电池到各模块稳压
• 第三章：主控最小系统——以STM32F4/F7系列为例
• 第四章：电机驱动与功率电路——底盘、云台、摩擦轮
• 第五章：通信接口与传感器接口——CAN、UART、SPI、I2C、裁判系统
• 第六章：PCB设计规范与投板流程
• 第七章：硬件调试方法——从样板到手能稳定运行的必经之路
• 第八章：故障案例库——全体队员贡献的经典翻车案例

这个顺序的背后逻辑是：先解决“能不能上电”的问题，再解决“能不能跑”的问题，最后解决“能不能稳定打完一场比赛”的问题。供电系统永远放最前面，因为电源出问题往往是连锁性的，一烧烧一片。

2.2 为什么选STM32而不是其他平台

RoboMaster官方推荐的主控平台，加上大多数强队的实际选择，基本都是STM32系列。世面上也有队伍在尝试ESP32、K210或者其他国产MCU，但STM32因为资料多、生态成熟、内部外设丰富，依然是新队员最友好的入门平台。

讲义里选STM32F4系列作为主讲对象，理由也很实际：

• 硬件资源够用：F4系列主频168MHz，带FPU，硬件浮点运算能力足够跑裁判系统的串口协议解析和简单的运动控制算法。
• 内部外设丰富：多个UART、SPI、I2C、CAN外设，对于机器人这种需要同时接裁判系统、遥控器接收机、陀螺仪、多个电机的情况很合适。
• 参考资料多：无论是ST官方手册还是网上各种开发教程，遇到问题基本都能搜到答案。
• 开发工具生态成熟：Keil、STM32CubeMX、STM32CubeIDE，芯片型号任选，固件库也一直在更新。

有人可能会问，这几年ST芯片价格波动大，是否要考虑国产替代？讲义里我专门加了一段说明：如果你队伍有足够的时间精力，当然可以用GD32、AT32这些兼容芯片来替换，引脚定义基本兼容，但要注意时钟配置和外设寄存器差异。不过从新队员学习的角度来说，STM32的资料优势还是最明显的。

2.3 每个章节的设计原则

每个章节我尽量保持统一的写作套路，这样新队员看着不累，老队员查起来也方便：

• 先讲这个模块“为什么要存在”，在整个机器人系统里的地位是什么；
• 再讲“原理是什么”，用尽量通俗的语言加必要的公式，但不过度推演；
• 然后给“推荐方案”和“器件选型思路”，附上实际验证过的电路参考；
• 最后加“调试步骤”和“常见坑”，这部分比前面的原理更重要。

举个例子，供电系统这一章，我不会从Buck电路的公式推导讲起，而是先告诉你：比赛电池用的是6S航模锂电池，充满电25.2V，放电瞬间可能抽到几十安培电流，而主控芯片要3.3V、激光测距模块要5V、舵机要6V，你说这些电压从哪来？然后引入稳压拓扑的概念，再讲怎么算压差、怎么算电流需求、怎么选芯片。

3. 核心硬件模块解析与实操要点

3.1 供电系统：机器人的血管和心脏

这一章我写得最厚，因为供电部分出问题，轻则断电重启，重则烧板子冒烟，而且电源问题往往很难排查。整台机器人的用电需求大概分成以下三档：

很多人上来就想用一个降压模块把电池电压降到5V给所有东西供电，这是最省事但也是最危险的做法。大电流负载开关瞬间的压降波动会直接影响主控ADC采样精度，甚至导致单片机复位；同时降压模块本身发热严重，连续工作一段时间后性能下降，又加剧了波动。

讲义里给出了一套推荐的电源树设计方法：

首先要画“电源树”，就是从电池出来，经过哪几级降压，分别供给哪些模块。画完电源树以后，每一级都要做电流估算，把峰值电流乘上1.5倍的裕量作为选型依据。

然后要考虑负载的启动顺序。采用“先主控后外设”的上电时序，或者用负载开关控制关键外设的供电时序，可以有效避免因上电瞬间的电流浪涌导致主控被复位。

实际调试中我们吃过一次大亏：摩擦轮电机用的一体化电调，上电瞬间需要很大的涌流来给大电容充电，结果电压瞬间被拉低，主控还没来得及跑初始化就复位了。后来加了软启动电路，摩擦轮在高电平到来之后延时200ms再上电，问题就没了。

这一章还有个值得提醒的点：永远不要在信号线还接着的时候直接拔电池，尤其是接在I/O口上有感应电压的传感器模块，容易在断开瞬间把主控的I/O口打坏。断电的正确顺序是：先拔信号线或者先让主控进入待机，再断主电源。

3.2 主控最小系统：硬件工程师的基本功

很多队员第一次画板子，拿个STM32最小系统板就往上怼，不知道每一根引脚为什么那么分配，也不知道晶振和去耦电容该怎么布局。这份讲义里把最小系统的设计拆成了几个核心部分：

• 时钟系统：外部晶振选型、负载电容计算、PCB走线要求
• 电源引脚去耦：每对VDD/VDDA引脚附近都要放100nF电容，大容量滤波电容也不能少
• 复位电路：上电复位和手动复位
• 启动配置：BOOT0/BOOT1引脚的接法
• SWD调试接口：预留标准的4针或5针调试座

关于去耦电容，我见过好几个新队员觉得“电容无所谓，能亮就行”，结果画完板子发现跑一会儿程序就莫名卡死，查了半天是电源噪声导致的。经验是：每个电源引脚旁边放一个100nF的0402/0603陶瓷电容，且必须紧贴引脚放置，过孔到电容再到引脚的走线越短越好。同时芯片周围的VDD走线要尽量粗，至少1mm以上，否则大电流下的压降会超过规格书限制。

晶振部分要特别注意负载电容。以8MHz晶振为例，如果晶振的负载电容规格是12pF，那么PCB上两个匹配电容一般选约22pF。这个数值不是随便拍的，计算方法是：C_load = (C1×C2)/(C1+C2) + C_stray，其中C_stray是走线和引脚带来的寄生电容，一般估3-5pF。用22pF的两个电容串联等效11pF左右，加上寄生电容正好接近12pF。晶振走线要尽量短，不要打过孔，周围不要走高频信号线，铺地隔离最好。

3.3 电机驱动与功率电路：最容易烧钱的地方

RoboMaster里面用到的电机类型有好几种：底盘的无刷电机（或者有些队伍用带减速箱的有刷直流电机）、云台的直驱无刷电机、摩擦轮的高速无刷电机。不同电机的驱动方案完全不同。

对于有刷直流电机，最常见的是用大功率NMOS搭H桥，通过PWM调速。这里有一个非常关键的“半桥死区”概念：H桥同一侧的上管和下管绝对不能同时导通，否则电源直接短路，立刻就烧。“死区时间”就是在上下管切换时插入的一个短暂延时，防止开关管的关断延迟导致直通。

对无刷电机，比赛队伍现在绝大多数用一体化电调（比如大疆自带电调）或者分体式电调，自己设计驱动电路的比例反而小了。但讲义里还是写了大功率MOS驱动的基本原理，方便新队员理解为什么电调那么大一块、为什么需要散热片，也为以后自己设计驱动板留个基础。

功率电路里最容易忽略的是续流二极管和吸收电路（Snubber）。电机是感性负载，断开瞬间会产生很高的反向电动势，如果没有续流二极管给它一个释放回路，高压会把MOS管击穿。如果你买的驱动模块没带反接保护，那建议自己加一个防反接的PMOS电路，或者直接用自恢复保险丝。

底盘电机驱动我们曾经踩过一个经典的坑：用两路PWM驱动一个直流电机，一路给正转，一路给反转，FPGA/单片机的PWM初始化顺序没配好，导致上电瞬间两个PWM都输出了高电平，H桥直通，四个MOS管烧了一对。后来统一改成了“单路PWM+方向引脚”的控制方式，而且把两个输出的初始电平都拉低，这个坑才算填上。

3.4 通信接口与传感器硬件设计

一台完整的步兵机器人，内部通信链路大致长这样：主控（STM32）通过CAN总线连接各个电机电调，通过UART连接裁判系统、陀螺仪（或IMU）、激光测距传感器，通过SPI/I2C连接传感器和存储芯片。硬件工程师得理解每条总线在硬件层面的注意事项。

CAN总线在RoboMaster里应用最广，因为电机电调基本都是CAN接口。CAN硬件设计有几个要点：

• 终端电阻：CAN总线两端要各接一个120欧姆终端电阻。很多队用的电调内置了终端电阻（或用跳线帽切换），如果你用一根线串多个电调，要搞清楚哪个是末端，确保末端有且只有一个120欧姆电阻。
• 总线电容和线缆长度：CAN总线走线尽量短且粗，最好不要在底盘内绕一大圈再回去，双绞线最好。
• 共模电感：主控端可以加一个CAN共模电感，提高抗干扰能力，不过要选好器件参数，别买那种参数不够的劣质货，反而弄巧成拙。

UART是调试和连接裁判系统的主干。硬件设计上的一个常见坑是电平不匹配：裁判系统串口的TXD/RXD是3.3V TTL电平，但某些传感器模块是5V TTL电平，直接互相连可能会烧坏IO，要做好电平转换。另外UART的TX和RX要交叉连接，电源地必须共地，不然数据收发会乱跳。

SPI和I2C在硬件上相对简单，但也要注意上拉电阻。I2C总线的SDA和SCL需要接上拉电阻，一般用4.7kΩ；SPI通信受走线长度和电容影响，在机箱内部短距离传输问题不大。还有一个经验是：给传感器供电一定要干净，尤其SPI陀螺仪这种对电源噪声敏感的芯片，最好单独用LDO供电，别直接用DCDC输出的带纹波的电源。

4. 实操过程与核心环节实现

4.1 一张控制板的完整设计流程

很多新队员拿到电路图软件就开始画，画了两小时发现规则错误报了200个，心态直接崩了。我建议把控制板设计拆成清晰的流程，按部就班做，效率和成功率会高很多。

第一步是写需求文档。哪怕这张板子只是把开发板的功能做成一块集成板，也要列出所有接口：

• 主控型号和最小系统占用的引脚
• 需要几路UART：哪路接裁判系统、哪路接IMU、哪路留作调试
• CAN总线路数：接几个电机电调
• PWM输出路数：是否有舵机，是否有需要调速的风扇
• 电源输入输出的电压和电流要求
• 板子的物理尺寸和安装孔位置

第二步是画原理图。画之前先在纸上把模块框图摆一遍，哪些模块在物理上要靠近，哪些信号线不能交叉。原理图画完以后，最最重要的一步是认真读一遍ST官方的芯片数据手册和勘误表，把引脚功能、电气参数、参考设计全部过一遍，再对照原理图检查。我见过有人画完原理图发现VCAP引脚没接电容，芯片直接无法上电，就因为没有查参考设计。

第三步是PCB Layout。布局时要先放连接器，因为连接器的位置决定了安装是否方便，再放主控和电源芯片，最后放其他外围。走线优先走电源线和地线，信号线次之。电源线和地线尽量加宽，走顶层和底层互相垂直，避免平行贴近产生耦合。地平面一定要完整，高速信号线（比如SPI时钟）尽量避免跨分割区。

第四步是投板和焊接。打样回来后第一件事不要急着上电，先用万用表量一遍电源和地之间有没有短路，把板子所有裸露焊盘正反面检查一遍。确认无短路后，先焊电源部分的元件，单独验证各输出电压是否正确，再接主控和其他部分。上电的时候用可调电源限流，先把电流限制在500mA以内，防止短路烧板。

4.2 从点亮LED到打通CAN指令

这是我最推荐新队员做的第一个完整练习：用自己画的板子点亮一颗LED，然后用CAN总线控制一个电机转动。

点亮LED看起来简单，其实包含了主控最小系统验证、GPIO配置、程序下载三个关键环节。如果LED能顺利点亮，说明最小系统基本没问题。我推荐新队员不要直接用现成的开发板模板，而是从空工程开始，在STM32CubeMX里选好芯片型号，把外部晶振、时钟树、LED引脚逐一配置好，生成代码以后再编译下载。走完这一遍，最小系统最少跑通一遍，后面出问题的时候排查范围就小了很多。

CAN调试这块，很多人上来就挖坑：买了USB转CAN适配器，插到电脑上发现虚拟串口驱动装不上，折腾半小时。其实多数USB转CAN适配器用的是标准的CH340或者CP2102芯片，驱动装好以后要确认一下设备管理器的端口号，再打开对应的调试上位机软件。

硬件层面确认CAN物理链路正常的方法是：用示波器量CAN_H和CAN_L两个引脚，正常空闲状态下，两个引脚之间大概有2.0V电平差；发送数据时能看到差分信号。如果波形有严重振铃或者电平漂移，检查一下是不是终端电阻缺失，或者线缆太长。我当时因为两米长的CAN线在底盘里绕了几圈，终端电阻又漏焊，导致通信时好时坏，最后才查出来是波形质量太差。后面所有CAN线都换成双绞线，并按标准在末端接好120欧姆电阻，波形干净了很多，通信率也上去了。

一本正经讲一下CAN实际调通的流程：

1. 在板子上引出CAN_H和CAN_L两个测试点；
2. 焊接好终端电阻（如果电调上没有启用）；
3. 用USB转CAN适配器连接电脑，上位机软件里安装波特率（我们统一用1Mbps，和电调默认一致）；
4. 先用最简单的标准帧发送一个电机使能指令，观察电调是否有回应；
5. 如果无回应，先用万用表量CAN_H和CAN_L之间是否有约2.5V左右的电压，再查软件配置。

4.3 示波器和万用表的基本调试套路

硬件调试离不开工具，但百分之九十九的新队员不会用示波器。讲义里我专门写了一段“示波器基础用法”，不教几十个参数怎么调，只教最常用到的几种触发方式和测量方法。

首先是电源纹波测量，用示波器看电源是否稳定。探头用弹簧地线（不是鳄鱼夹长地线，那个会引入很大的噪声），耦合方式设为交流，带宽限制设为20MHz，用峰值检测模式看纹波幅度。如果纹波超过芯片数据手册的建议范围（一般是输出电压的1%-2%），就要检查滤波电容是否足够、开关电源布局是否存在环路面积过大等问题。

其次是信号完整性测量，比如UART的波特率是否正确。把探头夹在TX引脚上，用下降沿（或上升沿，取决于空闲态）触发，抓一帧数据的波形，量最小位的脉宽。如果设置的波特率是115200，那么每个bit脉宽应该接近8.68微秒。脉宽偏差超过10%基本就是时钟配置错了，可能是晶振没起振，也可能是CubeMX时钟树配错了外部晶振频率。

万用表的使用看似简单，但也有几个经验：

• 判断单片机IO是否损坏：用电阻档测IO到地之间的二极管压降，正常IO在0.4V-0.7V左右，如果测出来是0V或者短路，基本就是芯片完了。
• 判断电解电容是否损坏：若看不到外观鼓包，用电流档测电容两端漏电流，如果漏电流特别大（高于标称），本体基本已经击穿，需要更换。
• 上电前先打一次阻值，正负极之间不应该有低于100欧姆的阻值，如果阻值极低，不要贸然上电，先排查。

5. 常见问题与排查技巧实录

5.1 五个出现频率最高的硬件故障

我在讲义最后专门整理了一个“故障案例库”，从过去三年的实际故障记录里挑了出现频率最高的几类问题。这里挑其中几个典型的分享给大家：

5.2 一个典型故障的完整排查实录

这里讲一个我们队伍在2022赛季季后赛前遇到的实际问题：步兵机器人底盘在高速移动时主控偶尔死机重启，低速时完全正常。这个故障很幽灵，平时测试怎么都不复现，一到对抗测试（大电流放电时）就随机出现。

排查过程是这样的：

第一步，怀疑电源电压跌落。用示波器同时测电池电压和主控3.3V，发现电池电压在急加速瞬间确实有明显跌落，但3.3V输出还算稳定，没有达到复位电压以下。于是暂时排除了主控电源的原因。

第二步，怀疑电磁干扰。急加速时底盘大电流通过线路，产生很强的空间电磁干扰，可能辐射到主控附近的信号线上，或者直接干扰到晶振电路。我们用示波器在死机瞬间抓主控附近信号线的波形，果然发现有明显的振铃尖峰，幅度接近3V。

第三步，查清干扰源。急加速时动静最大的就是底盘电机的驱动线，电流变化特别快，而底盘电机线恰好从主控板正上方走线，十几厘米的距离，成了天线一样的存在。

解决方法是把电机动力线和信号线彻底分开，动力线走底盘下层，信号线走上层，交叉时垂直通过；同时在主控板的电源输入端加了TVS管，在12V和5V之间加磁珠，把高频干扰滤掉一部分。改完以后急加速复测了20多次，没有再出现死机。

5.3 调试阶段的资源配置与工具清单

新队员入队的时候，我强烈建议先把手头工具配齐。很多人在淘宝买了一套二三十块的电工工具，焊个排针都费劲，焊盘推起来一大坨，后面肯定会吃亏。

推荐的最低配置如下：

• 恒温焊台（至少60W，温度可调，配刀头和一个尖头）
• 万用表（有二极管档和电容档，能测频率最好）
• 示波器（带宽100MHz左右，双通道够用。预算有限的话可以先买便携式的，比如几十块的那种口袋示波器，至少能看波形和频率）
• 热风枪（拆焊贴片元件用，至少能稳定400℃出风）
• 助焊剂（中性的，别用那种带卤素的，会腐蚀电路板）
• 优质焊锡丝（63/37含铅焊锡优先，无铅的熔点高，新手操作难度大）
• 镊子、斜口钳、剥线钳、绝缘胶带

除了这些硬件工具，软件上也要备齐：STM32CubeMX、Keil（或STM32CubeIDE）、立创EDA（画原理图和PCB）、一个串口调试助手、一个CAN调试上位机。工具到位以后，调试效率能提升一个档次，尤其是示波器，我反反复复强调，没有示波器调硬件等于摸黑走路。

6. 关于讲义版本更新与实际使用的体会

V0.2.1这个版本相比V0.1.x主要做了几方面改动：把供电系统的篇幅扩了一倍，增加了多个实测波形图；故障案例库从原来的8个增加到了20个；程序例程统一改用STM32CubeMX生成的HAL库工程，不再维护标准库版本。改这些的起因，都是新队员在实际操作中反复遇到的问题——比如HAL库和标准库混用的新队员经常把库配置文件弄混，导致代码编译报错一大堆。

我想说的是，讲义这个东西，写成什么样其实不重要，重要的是整个队伍都愿意一起维护它、更新它。每次比赛打完，无论成绩如何，硬件组都聚在一起复盘，把本年度遇到的问题、解决方案、新发现的知识点补充进讲义里。我自己当硬件组负责人的时候，最得意的事情不是某场比赛拿了奖，而是看到第二年新队员拿着讲义，从一开始就能直接上手画板子，把以前至少要三个月才能走完的路缩短到一个半月。

如果你也在带队伍，建议就不用从零开始编了。市面上有公开的RoboMaster技术文档和开源硬件资料，完全可以拿来当骨架，把自己队伍的踩坑经验和选型心得填进去，形成自己内部的知识库。关键是每场比赛结束后的复盘一定要做记录，不然明年又是从零开始。