1、扫地机项目概述：项目背景、硬件架构、软件分层架构
大家好，我是这次课程的主讲人。咱们直接进入正题——扫地机这个项目，到底是个什么东西？
说实话，我最早接触扫地机项目是在2018年。那时候市面上主流的方案还比较粗糙，经常撞墙、卡线、回不了充。嗯，这几年进步确实很大。但不管产品怎么变，底层的测试逻辑其实没怎么动。今天我就带大家把这块地基打牢。
1.1 项目背景：为什么选扫地机？
你可能觉得，一个扫地机而已，能有多复杂？
我跟你讲，它其实是个典型的嵌入式系统——有传感器、有电机、有控制逻辑、还有通信。说白了，它就是一个会跑的小机器人。你想想看，它要自己规划路径、避开障碍、识别地毯、判断脏污程度……这些功能背后，全是嵌入式软件在支撑。
我个人习惯把扫地机项目当作嵌入式测试的“样板间”。为什么？因为它的模块足够多，测试场景足够丰富。你在一个扫地机上练熟了，换到其他嵌入式产品，基本就是换个壳。
核心要点：扫地机项目覆盖了嵌入式测试的绝大多数典型场景——传感器采集、电机控制、状态机切换、异常处理、低功耗管理。学透它，你就掌握了嵌入式测试的通用方法论。
1.2 硬件架构：MCU、传感器、电机
先看硬件。扫地机的硬件架构，说白了就是三大部分：大脑、眼睛、手脚。
1.2.1 MCU——大脑
MCU是整台机器的控制核心。我在项目中遇到过用STM32F4系列的，也有用国产GD32的。选型主要看几个指标：主频、Flash大小、RAM大小、外设接口数量。
举个例子，一个中端扫地机，MCU的主频一般在200MHz左右，Flash至少512KB，RAM至少128KB。为什么？因为要跑路径规划算法，还要存地图数据，内存小了根本不够用。
| MCU型号 | 主频 | Flash | RAM | 典型应用 |
|---|---|---|---|---|
| STM32F407 | 168MHz | 1MB | 192KB | 中高端扫地机 |
| GD32F450 | 200MHz | 512KB | 256KB | 性价比方案 |
| ESP32 | 240MHz | 4MB | 520KB | WiFi联网机型 |
测试小贴士：MCU选型阶段就要考虑测试覆盖率。比如Flash和RAM的边界值测试，我建议在项目初期就定好用例，不然后期改硬件成本很高。
1.2.2 传感器——眼睛
扫地机上的传感器种类很多。我列几个常见的：
- 激光雷达（LDS）：测距用，精度一般在±1cm。测试时要关注盲区和多径反射。
- 红外传感器：检测悬崖、碰撞。注意环境光干扰。
- 超声波传感器：检测透明物体（比如玻璃门）。我曾经踩过这个坑——激光雷达扫不到玻璃，全靠超声波补位。
- 陀螺仪/加速度计：用于姿态检测和航迹推算。测试时重点关注零漂和温漂。
- 地检传感器：识别地毯和地板材质。这个在测试时容易忽略，但用户反馈中经常出现“扫地机在地毯上不增压”的问题。
你想想看，这么多传感器，每个都有不同的输出协议（I2C、SPI、UART），每个都有不同的精度和响应时间。测试的时候，光传感器这块就能写出一百多个用例。
1.2.3 电机——手脚
扫地机一般有3-4个电机：
- 驱动轮电机（左右各一个）：控制行走。测试重点：速度控制精度、堵转保护、差速转弯。
- 边刷电机：把墙角的垃圾扫到中间。测试重点：转速稳定性、堵转恢复。
- 滚刷电机：主刷，负责把垃圾卷进尘盒。测试重点：负载变化时的转速保持。
- 风机电机：产生吸力。测试重点：PWM控制精度、噪音与吸力的平衡。
我记得有一次，驱动轮电机的堵转保护阈值设得太高，结果机器卡在电线上一动不动，用户以为死机了。后来我们把阈值调低，并增加了“自动后退+旋转”的脱困逻辑，问题才解决。
注意：电机测试一定要做长时间老化测试。我见过一个项目，电机在连续工作4小时后，因为散热不良导致PWM控制失效，机器直接原地打转。这种问题，短时间测试根本发现不了。
1.3 软件分层架构
软件架构这块，我习惯把它分成三层：驱动层、中间件层、应用层。每一层的测试重点都不一样。
1.3.1 驱动层（BSP）
驱动层直接跟硬件打交道。包括MCU的外设驱动（GPIO、Timer、ADC、PWM）、传感器驱动、电机驱动等。
测试重点：
- 寄存器配置是否正确
- 中断响应时间是否达标
- DMA传输是否稳定
- 低功耗模式切换是否正常
说白了，驱动层测试就是“裸机测试”。我建议用单元测试框架（比如Unity、CMock）来做，把每个驱动模块单独拎出来测。
1.3.2 中间件层
中间件层是连接驱动和应用的关键。包括：
- RTOS（实时操作系统）：任务调度、信号量、消息队列。测试重点：任务优先级是否合理、是否有死锁、是否有优先级反转。
- 通信协议栈：比如WiFi模块的AT指令解析、蓝牙的GATT服务。测试重点：协议一致性、异常包处理。
- 算法库：比如SLAM建图、路径规划。测试重点：算法精度、内存占用、执行时间。
中间件层的测试，我个人习惯用“黑盒+白盒”结合的方式。黑盒测功能，白盒测代码覆盖率。
1.3.3 应用层
应用层是用户直接感知的部分。包括：
- 状态机：待机、清扫、回充、暂停、错误等状态的切换。测试重点：状态转换是否合法、异常状态是否能恢复。
- 业务逻辑：比如“检测到地毯→增大吸力”、“电量低于20%→自动回充”。测试重点：逻辑分支是否覆盖全。
- 用户交互：按键响应、APP指令解析、语音播报。测试重点：响应时间、指令容错。
我的经验：应用层的bug往往是最多的，但也是最容易修复的。真正难搞的是驱动层和中间件层的bug——它们往往需要反复复现、抓波形、看日志。所以，我建议测试资源分配上，驱动层和中间件层要占大头。
1.4 小结
这一章我们聊了扫地机项目的背景、硬件架构和软件分层。你可能会觉得内容有点多，但没关系，后面每一章都会围绕这些内容展开。
记住一句话：测试不是最后才做的事，而是从项目第一天就要开始的事。下一章，我会带大家看看扫地机项目的测试策略和测试计划怎么制定。
嗯，今天就到这里。有什么问题，咱们评论区见。