企业官网建设流程全解析

做一台能在房间里自己转悠、主动绕开障碍物，还能在发现"目标"的第一时间停下来、扫描确认、再把信号传回手机的小车，可能是Arduino玩家进阶路上最有成就感的一个项目。基于Arduino UNO的自动搜救小车，就是把一辆普通遥控车的壳子拆掉，装上一整套"感知-决策-执行-回传"闭环的典型练习。这篇东西我不想只给你一份零件清单和几段代码，而是把自己从选型、接线、写状态机，到现场调参、排查误报的完整过程都摊开讲。打算入机器人坑的同学、正在做课程设计的读者，可以直接照着这个思路搭一台自己的搜救小车。

1. 从"会动的小车"到"会搜救的小车"，中间差的是整套闭环

1.1 搜救场景对小车提出了什么硬性要求

很多朋友第一次做小车，装个超声波避障就觉得差不多了。但"避障"和"搜救"是两码事。避障只是"别撞上"，搜救要求的是：小车要在未知环境里自主移动、尽量覆盖大部分区域、在行程中发现目标、停下来确认、然后把结果告诉外面的人。这个链条里任何一个环节断了，它都只是一台会动的玩具。

现实中的搜救场景，比如灾害后的室内环境、狭小管道、人进不去的塌陷区，核心诉求其实就几条：体积小、能钻能绕、能持续巡检、发现生命迹象或危险源后能准确上报。我没有能力做一台真正能在废墟里翻越障碍的履带机器人，但我可以把这套逻辑在小尺寸的轮式平台上完整跑通。做出来之后你会发现，换传感器、换底盘都是小事，最难的是让它"自主"地走完整个流程。

1.2 感知-决策-执行-回传：机器人运作的基本盘

搜救小车的自主性，本质上来自一个闭环：传感器负责"看"和"摸"，主控负责"想"，电机负责"动"，通信模块负责"说"。用生活里的例子类比，就像一个人进了一间陌生屋子找东西——眼睛看路、手摸桌角、大脑判断往哪走、找到东西之后张嘴喊人。小车只是把这些动作全部电子化、代码化。

具体到我的方案里：

• 感知层：超声波测距模块负责前方障碍物探测，红外避障传感器负责低处盲区补漏，火焰传感器或人体热释电模块负责搜救目标探测，舵机云台带着超声波左右扫描。
• 决策层：Arduino UNO读取传感器数据，运行一个状态机，决定当前是直行、转向、停止还是发报警。
• 执行层：直流减速电机配合驱动板，完成前进、后退、左右转弯。
• 回传层：蓝牙模块把小车当前状态、检测距离、探测结果实时发到手机。

这个分层思路是通用的，以后你换主控、加摄像头、上ROS，底层逻辑还是这一套。

1.3 为什么在这个项目上选Arduino UNO而不是别的板子

做搜救小车，可以用的主控很多：树莓派、ESP32、STM32，甚至 Jetson Nano。但我最终还是选了 Arduino UNO，原因很实在：

• UNO是5V逻辑电平，跟大量传感器模块、驱动板直接对接，不用做电平转换。这个省掉的麻烦，新手可能体会不到，老手一定懂。
• 生态成熟，资料巨多。超声波、舵机、蓝牙、火焰传感器，每一个模块的样例代码都能搜到，遇到问题排查起来快。
• 8位单片机虽然性能一般，但搜救小车这种任务，实时性要求并不高，测距周期几十毫秒完全够用。把代码组织好了，UNO的16MHz主频和2KB SRAM绰绰有余。
• 课程设计、竞赛展示场景里，UNO的"透明感"本身就是优势——评委一看就明白系统架构，答辩时不用解释主控为什么这么选。

树莓派确实能跑视觉识别，但它的启动时间、供电稳定性、硬件成本都更适合做进阶项目。先把UNO这套跑通，是性价比最高的路径。

2. 硬件选型：这套配置里每一块钱都有它的理由

2.1 底盘与电机：两驱还是四驱，别被参数忽悠了

底盘我用的是最常见的亚克力两驱车架，加两个TT直流减速电机、一个万向轮。四驱底盘我也试过，动力确实猛，但在室内平地上反而是负担——电机多两个，功耗高、转向半径大、控制复杂度也上去。搜救场景讲究"钻"而不是"冲"，两驱加万向轮的灵活性足够用了。

电机驱动选的是L298N模块。虽然它有点老、压降大，但胜在皮实、便宜、资料多。接线就两组：电机A和电机B各自的IN1、IN2、ENA、IN3、IN4、ENB，逻辑就两条——ENA给PWM调速，IN1/IN2决定正反转。如果你想让小车跑得细腻一点，可以换成TB6612FNG，体积更小、效率更高，但驱动电流稍小。预算二十块以内，L298N足够。

这里有个新手必踩的坑：L298N板载的5V稳压输出，很多人拿来直接给Arduino供电，结果小车一动，Arduino就重启。因为L298N的稳压芯片在电机启动瞬间压降巨大，输出根本稳不住。我的做法是：电机电源单独一路，Arduino用自己独立的降压模块供电，两边的地线连在一起就行。

2.2 感知层：超声波做"主视觉"，红外做"触觉"

搜救车对感知的要求是"少盲区"，所以我配了三类传感器，各管一段：

• HC-SR04超声波模块，装在舵机云台上，负责前方30厘米到4米范围内的测距。它原理是发出40kHz超声波，测回声返回时间，距离等于时间乘以声速再除以2。注意它有个天生毛病：探测面比较窄，而且对斜面、细杆这类目标容易丢信号，所以不能只靠它一个。
• 两个红外避障传感器，装在车头左右两侧低位，负责探测超声波够不到的近距盲区。红外传感器本质是一个红外发射管加一个接收管，前方有障碍物时反射光增强、输出电平翻转，简单粗暴但有效。
• 搜救目标探测我用了两套方案，大家可以按需选：一套是火焰传感器，探测前方红外火焰光谱，用来模拟"发现火源/危险源"场景；另一套是热释电人体红外模块（HC-SR501），探测生命体的热辐射，更贴近"搜救生命迹象"的语义。两个模块都是数字量输出，接到Arduino数字引脚就行。

舵机云台的作用是让超声波"转头"。固定安装的超声波只能看正前方，装到舵机上之后，小车每走一段就左右扫一遍，相当于把单点测距变成区域扫描，搜救覆盖率完全不一样。

2.3 通信与反馈：让小车把话说清楚

搜救车不是自己闷头跑的，它得把状态告诉外面的人。我用HC-05蓝牙模块做无线串口，手机装个串口调试助手就能实时看到小车发的消息。HC-05默认是AT命令模式，需要先设置波特率和配对密码，然后再切到透传模式。具体怎么配，网上教程一大堆，我只提醒一句：AT模式配置的时候，模块的EN引脚要拉高，否则进不去。

除了蓝牙，我还加了三个反馈元件：一个无源蜂鸣器，找到目标时发出提示音；两个LED指示灯，绿色表示正在巡检，红色表示发现目标；一块0.96寸OLED屏，实时显示当前状态、前方距离和电池电压（通过分压电阻采ADC）。这些小东西成本加起来不到二十块钱，但对调试的帮助是巨大的——你不用每次看手机才能知道小车在想什么，屏幕上直接就有。

2.4 供电方案：最容易翻车的一环，认真看

搜救小车要长时间跑，供电绝不能含糊。我的方案是：

注意几点：第一，舵机启动瞬间电流很大，如果跟Arduino共用一个5V稳压模块，很容易把MCU电压拉垮导致复位，所以我单独给舵机一路供电；第二，电池用两节18650串联（标称7.4V）最省钱，但电压会从8.4V降到6V左右，L298N在低电压下输出功率下降，实测小车速度会明显变慢，所以要么选带保护板的电池组，要么在软件里做低压告警；第三，所有模块的地线必须共地，否则串口通信和传感器读数会乱飘。

3. 状态机控制逻辑：让小车"自主"的不是段代码，而是一套状态

3.1 为什么必须用状态机，而不是堆一堆if判断

我第一版代码就是"从前往后写"：先避障，再检测，再报警，结果就是一锅粥——小车撞到墙之后，可能永远没机会检测目标。后来我把整个行为改成了状态机，逻辑瞬间清晰了。状态机的核心思想是：小车任何时刻都处于某个明确状态里，每个状态只做一件事，事件触发才切换到另一个状态。

我的搜救小车定义了六个状态：

• IDLE：上电初始化，自检传感器，原地转一圈。
• SEARCH：正常巡检，沿墙或按S形路线走，超声波云台周期性左右扫描。
• AVOID：发现障碍物距离小于安全阈值，进入避障逻辑，先停下判断方向再绕行。
• DETECT：搜救传感器触发，停车，进入检测流程。
• CONFIRM：连续多次采样确认目标，防止误报，同时云台扫描一圈确认。
• REPORT：确认无误后，蜂鸣器响、LED变红、蓝牙发送"发现目标+位置信息"，保持5秒，然后回到SEARCH继续巡检。

用状态机的好处是：每个状态内部代码简单，状态跳转一目了然，出问题的时候通过串口打印当前状态，两分钟就能定位到问题环节。这是做机器人项目非常值得养成的好习惯。

3.2 避障策略的三种取舍，我选了"沿墙走"

避障算法看着简单，其实选择很多。三种主流策略：

• 遇到障碍就原地转向：实现最简单，但小车会像无头苍蝇，覆盖率差，同一个区域反复跑。
• 随机转向加区域记录：逻辑稍微复杂一点，类似扫地机器人，覆盖面广但不可控。
• 沿墙行走（wall following）：保持超声波测距读数在一个目标区间内（比如25-35厘米），远了就往墙靠，近了就往外偏。这个策略在室内走廊、房间场景下覆盖率非常高，而且给人感觉"像在认真搜索"。

我最终用了沿墙为主、盲区扫测为辅的策略。在SEARCH状态里，小车以恒定速度前进，超声波每100毫秒测一次前方距离，舵机每2秒左右扫一遍。如果前方距离小于40厘米，进入AVOID；如果右侧距离读数告诉我墙在右边，我就维持右墙距离目标值。这个策略在规则室内环境里表现很稳，调试也直观。

3.3 搜救检测与确认机制：别让小车"狼来了"

搜救目标探测最怕的就是误报。火焰传感器对阳光、白炽灯光都敏感，热释电模块对温度变化敏感，一次误报就会让整个搜索过程断掉。我的处理方式是三重确认：

• 时间维度：检测信号必须持续1秒以上（软件里连续采样10次），避免瞬间干扰。
• 空间维度：触发后小车原地停车，云台从左到右扫描一遍，要求超声波测得的"目标区域距离"稳定、目标信号持续存在。
• 逻辑维度：进入CONFIRM状态后，如果信号再次触发才确认；如果中途丢失，退回SEARCH状态继续跑。

这套确认机制直接治好了我的"误报焦虑"。事实上后来的实测里，小车在阳光充足的窗边跑，火焰传感器确实误报过几次，但三重确认机制把所有误报都拦在REPORT之前了。

3.4 核心代码框架：可以直接抄的底座

状态机部分我用switch实现，代码结构如下：

enum State { IDLE, SEARCH, AVOID, DETECT, CONFIRM, REPORT }; State currentState = IDLE; void loop() { updateSensors(); // 更新超声波、红外、搜救传感器、电压 switch (currentState) { case IDLE: selfCheck(); if (selfCheckOK) currentState = SEARCH; break; case SEARCH: wallFollow(); if (frontDistance < SAFE_DISTANCE) currentState = AVOID; if (detectSignal()) currentState = DETECT; break; case AVOID: avoidObstacle(); if (frontDistance > SAFE_DISTANCE + HYSTERESIS) currentState = SEARCH; break; case DETECT: stopMotors(); if (confirmDetect()) currentState = CONFIRM; else currentState = SEARCH; break; case CONFIRM: scanAndVerify(); if (verified) currentState = REPORT; else currentState = SEARCH; break; case REPORT: reportTarget(); delay(5000); currentState = SEARCH; break; } printStatus(); // 串口/OLED输出状态和传感器值 delay(20); }

超声波测距建议加滤波，我用的是一次去掉最大最小值后的均值滤波，每轮取5个读数：

float readDistance() { const int N = 5; float samples[N]; for (int i = 0; i < N; i++) { samples[i] = measureOnce(); delay(10); } // 简单冒泡去掉最大最小 sort(samples, N); float sum = 0; for (int i = 1; i < N - 1; i++) sum += samples[i]; return sum / 3.0; // 单位: cm }

电机控制建议封装成函数，后续逻辑层只调用forward()、backward()、turnLeft()、turnRight()，不要在状态机里直接写PWM，否则调参的时候会疯掉。

调参参数我放在文件头部：

const int SPEED_NORMAL = 140; // 正常巡检PWM值，范围0-255 const int SPEED_TURN = 120; // 转向时的PWM值 const int SAFE_DISTANCE = 35; // 触发避障的距离阈值(cm) const int HYSTERESIS = 10; // 回滞量，防止状态反复跳变 const int WALL_TARGET = 30; // 沿墙目标距离(cm) const int WALL_TOLERANCE = 5; // 沿墙距离容差(cm)

回滞量这个概念值得说一下。如果没有它，小车在阈值附近来回跳，一会儿避障一会儿前进，状态机就会抖动。加了回滞量之后，进入避障需要距离小于35cm，但退出避障需要距离大于45cm，中间的10cm缓冲区让行为稳定很多。

4. 装配与接线实操：按这个顺序做，翻车概率最小

4.1 先把底盘和电机装利索

我踩过的第一个坑就是装反了电机方向。TT电机有左右之分，但你从外观上看不出来。建议先不固定电机，接上电源分别测试两个电机的旋转方向，把转向一致的电机装到同一边，然后固定。固定方式用底盘自带的螺丝加扎带加固，否则跑起来电机会移位，履带或轮子会蹭到车架，产生很大的异响和阻力。

万向轮的高度要注意：装好之后四个支撑点要基本在一个平面上，否则小车跑起来像"瘸腿"，一边轮子空转一边轮子吃力，续航和直线性都完蛋。我调整的办法是在万向轮和底板之间加垫片，直到用手推车能顺畅直线滑行为止。

电机驱动板L298N我直接叠放在底盘上层，用铜柱垫高，一方面散热，一方面避免电机电刷火花产生的电磁干扰串到传感器线路上。铜柱高度建议10mm以上，让底板下层走电机线、上层走信号线，物理隔离。

4.2 传感器布局决定搜救覆盖率，不是随便粘上去的

布局是整个装配里最有讲究的部分，我总结三条经验：

• 超声波装在车头正中央的舵机云台上，传感器面朝正前方，高度保持在25-30厘米。这个高度对应的探测范围正好覆盖桌面、椅腿、墙体等室内常见障碍，太低容易漏掉高处的障碍，太高测不到地面的小台阶。
• 红外避障传感器装在前轮轴线前方、左右各一个，探头稍微斜向下。斜向下的原因：超声波对小而低的物体（比如地毯边缘、门槛）不敏感，而红外的反射式探测恰恰擅长这个，两者互补。
• 火焰传感器或热释电模块装在车头最前方、靠近地面，因为火源和人体热辐射在地面附近信号最强。注意热释电模块有"感应延迟"特性，装好后需要静止20-30秒让传感器稳定，否则刚上电它自己会乱触发。

走线方面，所有线束沿着车架边缘用扎带固定，绝不能让线在轮子附近晃。我第一版就因为一根杜邦线被轮子卷进去，直接让电机堵转，驱动板发热到烫手。线束固定完之后，用手转动每个轮子检查一遍，确保没有摩擦。

4.3 共地与信号线处理：电机的"脏电"是元凶

接线上最核心的原则是"分开供电、统一共地"。我理一下：

• 电机电源：7.4V电池正极接L298N的12V输入，负极接L298N的GND。
• Arduino电源：电池正极经一个5V降压模块，接到UNO的Vin或5V引脚。我用的是5V引脚直连，因为降压模块输出已经是稳定5V。
• 舵机电源：电池正极经另一个5V降压模块，接到舵机红线，舵机棕线接公共地。
• 所有模块的地线：L298N的GND、Arduino的GND、舵机地、传感器地，全部并到同一个公共地节点。

地线为什么要共地？因为Arduino判断传感器信号要靠电压差，如果两边地电位不一致，读数就乱跳。电机PWM时产生的尖峰噪声，如果没有共同地形成低阻抗回流路径，会通过地线窜进信号线，导致超声波测距出现"幽灵障碍"。

另外，电机线最好用绞线或者粗一点的红黑线，并且跟信号线保持距离。我实测过，电机线贴着杜邦信号线走的时候，超声波测距的最大抖动从±2cm飙升到±15cm，这就是电磁耦合。后来我把电机线改成双绞线，间距拉开，问题立刻缓解。

5. 实测调参全记录：从"原地打转"到"稳定巡检"的血泪史

5.1 第一轮测试：车根本跑不直，问题出在电机上

所有硬件装完的那天晚上，我把小车放到地板上，满怀期待地按下电源。结果小车以肉眼可见的弧度向右偏，走了两米就撞上了椅子腿。我一开始以为是转向逻辑的问题，后来用一块胶带在地上画了条直线，发现小车即使在无障碍的直道上也跑不直。

原因很简单：两个TT电机的转速一致性差，左边比右边快。这是直流有刷电机的通病，不是故障。解决办法有两个层次：硬件上我试着在慢的电机轴上加一个轻质垫圈增加摩擦（治标不治本），软件上才是正解——在forward()函数里对左右电机给定不对称PWM，比如左140、右150，用一个校正系数motorCalibration统一管理；通过实测不断调整，直到小车在2米内偏移小于10cm。

同时也发现开机瞬间电压跌落严重。后来查了下，7.4V锂电池在电机启动瞬间压降很大，Arduino的5V供电模块也会跟着波动。我在代码里加了一个软启动：for (pwm = 0; pwm < target; pwm++)，让电机在200毫秒内逐步提速，既保护电池也避免起步被"拽"一下。

5.2 第二轮测试：避障忽远忽近，机器人像是喝醉了

直线问题解决后，我让小车开始自主巡检。结果超声波测距显示前方障碍时远时近，小车经常在离墙还有半米的时候就紧急转向，有时又几乎贴上墙才反应过来。

排查过程我分了三步：

第一步检查传感器本身。把超声波模块拆下来，对着墙面固定测距，串口输出还是波动。确认问题在读数环节，而不在机械。我加了前面提到的均值滤波之后，静态波动从±3cm降到±1cm，好多了，但动态场景还是不稳。

第二步怀疑供电。舵机扫描时，超声波和舵机共用一路5V，舵机一转电流大，超声波模块的VCC立刻被拉低，导致测距异常。解决办法就是前面说的给舵机单独供电，再在超声波VCC和GND之间加一个100uF电解电容做储能缓冲。这一步做完，超声波读数彻底稳定了。

第三步是动态跟手问题。超声波从发出到接收本身有延迟，小车速度太快的时候，"看到"障碍到"执行转向"之间车已经往前冲了好几厘米。我把正常巡检速度从PWM 180降到140，避障响应立刻从容了。这里记住一个原则：搜索车的首要指标不是速度，而是稳定和覆盖。跑太快，再好的传感器也救不回来。

5.3 第三轮测试：误报频出，"三重确认"成了救命稻草

搜救功能联调的时候，我把一个点燃的蜡烛放在房间角落模拟目标，小车第一次跑过去，确认、报警、蓝牙发消息，一气呵成。我正高兴，第二天白天再测，小车走到窗边突然报"发现目标"——现场的阳光干扰了火焰传感器。

这是火焰传感器最典型的误报场景，红外光谱里阳光成分复杂，传感器无法区分。这时候三重确认机制的威力就体现出来了：阳光干扰通常持续时间短、位置不稳定，小车进入DETECT状态后原地停车扫描，信号一丢就回到SEARCH，不再触发REPORT。我又加了一招：在火焰传感器的模拟输出引脚（AOUT）上做阈值判断，把采样得到的模拟值动态中值滤波，并把检测阈值设成"明显高于环境基线"才认为触发，相当于给传感器加了个自适应门槛。

热释电模块版本也有它的讲究：它在人静止的时候反而可能不触发，因为热释电只响应"变化的红外辐射"。所以如果用它搜"人"，小车必须是移动状态，而且确认阶段最好让小车小幅前后移动来制造相对运动。这个细节很多教程不会写，实际测试中非常关键。

5.4 一次完整的现场实测记录

最后放一段我调试稳定后的完整实测流程，供你对照自己的测试预期：

• 上电，OLED显示"IDLE"，小车原地360度慢速转一圈，超声波扫描环境，LED为绿色。
• 2秒后进入SEARCH，小车以20cm/s左右的速度沿右侧墙面巡检，每2秒用舵机扫描一次前方扇形区域，OLED实时刷新当前距离。
• 遇到第一处障碍（一个纸箱），前方距离小于35cm，进入AVOID，小车停下、右转、向前试探，绕过后回到沿墙。
• 走了大概3米，火焰传感器触发，进入DETECT，小车停车，蜂鸣器短响一声提示"有信号"。
• 云台左右扫描一圈，信号连续稳定，进入CONFIRM，LED变红，蓝牙模块发送"TARGET_FOUND_AT_STATE3"。
• 5秒后自动回到SEARCH，继续巡检，直到手机端发出停止指令。

整个流程从启动到首次发现目标，用时约40秒，期间误报零次。小车在一次完整巡检里的有效覆盖率我用网格法大概估算是75%左右，剩下的盲区主要是墙角回旋处——这个问题留给下一版用螺旋搜索算法解决。

6. 如果继续往下做，这几条路最值得走

6.1 从蓝牙回传到远程图传

目前的回传只有文字和状态信息，看不到现场画面。升级方向很明确：把蓝牙换成ESP32-CAM，或者用Arduino加一个串口摄像头模块，把实时图像通过WiFi传回手机。这样小车就真正具备"现场勘查"能力了。代价是功耗上去了，供电方案要重新设计，建议用带更大容量电芯的电池组。

6.2 给小车装上"记忆"：极简区域记录

现在的小车跑过的地方不会留下任何记忆，容易重复搜索同一片区域。可以用UNO的EEPROM记录大致的时间戳和转向历史，或者外挂一个SD卡模块，把每次转向的传感器数据写到文本文件里。数据量不大，但对后续分析路径覆盖、优化搜索策略非常有用。更进一步是接一个数字罗盘模块（如HMC5883L），让小车知道自己的朝向，配合陀螺仪做闭环转向，转弯角度会精确很多。

6.3 机械结构上的两个实用升级

一是把轮子换成履带模块，越障能力明显提升，能让小车从"室内平地巡检"升级到"模拟废墟翻越"。二是在车顶加一个小型云台摄像头加补光灯，在光线不足的搜救场景里非常实用——搜救场景十有八九是暗的，这也是实际项目里最容易被忽略的需求。

我个人的建议是：先别急着追新硬件，把现有这套状态机逻辑、避障策略、确认机制吃透，再根据自己的实际场景改传感器。机器人的价值从来不在某一个零件多贵，而在整套系统能不能稳定地闭环跑起来。你能把一台基于Arduino UNO的小车调教到"放下去就能自己搜"，后面换任何平台都是水到渠成的事。

最后分享一个小技巧：调试搜救小车时，别只在光线下充足的房间里测。找个傍晚，拉上窗帘，开一盏台灯模拟低照度环境，你会发现很多白天发现不了的问题——传感器盲区、红外干扰、LED指示亮度不够看不清，全都现出原形。把它当成一次"实战演习"，比在完美条件下跑一百遍都有用。