简介这份毕业设计文档聚焦智能环卫机器人的系统设计与实现面向机械、自动化或计算机相关专业的本科学生与竞赛开发者针对城市垃圾清理人力成本高、环卫作业危险等场景给出从总体方案到模块落地的完整设计思路。文档围绕底盘、视觉识别、机械臂、控制电路、锂电池和垃圾箱六大模块展开重点阐述了基于摄像头颜色特征的白色垃圾识别方法、步进电机与舵机驱动的两自由度机械臂、以及基于双轮差速模型的底盘运动控制适合用于课程设计参考、答辩准备或样机开发前期的方案预研。资源包共1个文件为docx格式整包约240KB正文包含系统框架、模块选型、控制算法推导和Solidworks仿真流程结构紧凑阅读后可快速掌握环卫机器人各子系统的协同逻辑与关键设计参数。当前已有83人浏览学习可作为同类课题的高性价比参考资料。 去年我们在一个城市智慧化试点项目里做智能环卫机器人原型把一台差速AGV底盘硬生生改造成了能自主巡路、识别垃圾、自动清扫的样机。做智能环卫机器人系统设计最容易被低估的往往不是某个算法而是感知、决策、运动控制、远程调度这条链路的咬合。这篇文章我会从整机架构讲起把我在这个项目里踩过的坑、算过的账、验证过的选型逻辑一次说清楚。无论你是正在做同类毕业设计还是准备把样机推向工程化这篇内容都应该能帮你少走几周弯路。1. 整机框架主控分家、传感器堆料之前的第一次取舍1.1 先分清“实时控制”和“非实时计算”的边界很多第一次做机器人的同学喜欢把所有算力塞在一块高性能板子上Jetson 一肩挑视觉、规划、底盘控制。这在实验室里确实能跑但到了真实路面激光雷达数据、电机 PID 中断、IMU 高频采样全挤在同一块 CPU 上一旦视觉推理占满 GPU底盘就开始“思考人生”——该停的时候不停该转的时候迟疑。我的方案是主控分家上层用 Jetson Nano 做感知和路径规划下层用 STM32F407 做底盘实时控制两层之间走串口通信。Jetson 输出目标速度指令比如线速度 0.8 m/s、角速度 0.5 rad/sSTM32 收到后自己跑 PID 闭环、自己处理急停和限位信号。上层就算死机了下层的急停逻辑依然能保证机器人停下来这是安全底线不是性能问题。1.2 传感器组合与硬件架构总览这套原型机的传感器配置如下模块型号/方案作用关键参数主激光雷达单线 360° 雷达建图、全局定位、近距避障测距范围 0.2~8 m扫描频率 10 Hz深度相机Intel RealSense D435i垃圾识别与目标测距深度有效距离 0.3~3 m差分定位消费级 RTK-DGPS室外绝对定位定位精度 ±5 cm开定点时IMU九轴姿态传感器姿态估计、短时位移积分200 Hz 输出轮式里程计增量式编码器局部位移推算1000 线/转超声/红外车身四角近距离补盲探测范围 2~150 cm底层驱动板还留了 8 路 ADC 给电量、风机电流、刷盘堵转检测。整机电源用的 48 V 锂电池组降压到 12 V 给 Jetson 和传感器48 V 直接给直流无刷电机。硬件层面最需要注意的一点是所有传感器必须共地。我有一版样机GPS 和雷达各用各的电源地线结果视觉工作站串口数据隔十几分钟就丢一帧找了两天才发现是地电位差在作祟。2. 感知层激光、视觉、里程计各司其职的融合逻辑2.1 定位不是单一传感器说了算扫地机器人室内的定位相对好做因为墙壁特征丰富。户外街道、公园这种开放环境树荫、建筑遮挡、行人都会让 GPS 信号跳来跳去。我实测过纯 GPS 定位在梧桐树下来回漂移最大偏差能到 2 米这种精度根本没办法让清扫机构对准路缘。所以定位采用的是**“激光里程计轮式里程计IMUGPS”的松耦合融合**Cartographer 的实时激光配准先把点云和已有地图对齐得到局部姿态再和轮式里程计、IMU 一起喂给扩展卡尔曼滤波EKF输出 9 Hz 左右的全局位姿GPS 主要用来修正 EKF 的长期漂移避免激光匹配在空旷区域退化后越走越偏。这套组合调试完之后在标准路段上机器人中心点偏移量稳定在 ±18 cm 以内。注意这 18 cm 是 95% 置信区间下的真实数据不是手册值。如果你做的是纯室内项目GPS 部分可以直接去掉但 EKF 融合轮式里程计和 IMU 这件事不能省否则压过减速带瞬间轮子打滑定位就会跳一块。2.2 垃圾识别YOLOv5s 的部署细节与数据陷阱垃圾识别我选的是 YOLOv5s原因很直接Jetson Nano 跑 yolo v5s 加上 TensorRT 加速推理延迟能压到 40 ms 左右实时性够用模型只有 14 MB方便迭代。训练数据除了公开数据集我们专门在试点园区拍了 3000 张现场照片覆盖落叶堆、饮料瓶、纸团、塑料袋、烟盒五类常见垃圾。部署时有几个细节容易被忽略摄像头需要和深度图对齐。只靠 RGB 图像里垃圾的像素坐标算不准距离要用 RealSense 的深度对齐功能把检测框中心点对应到深度图上再根据相机内参还原机器人坐标系下的三维坐标。检测阈值不要拍脑袋设 0.5。我们实际设的是 0.45因为在树底下光线复杂的场景识别置信度普遍比光照好的时候低 5~8 个百分点阈值卡太死会漏检。模型上板后温度会漂。 Jetson Nano 连续跑一小时GPU 温度到 75 ℃ 后推理延迟会明显变大。我们给散热风扇加了温度控制策略60 ℃ 以上全速转才稳定住帧率。最后模型的 mAP0.5 在测试集上只有 91%看着不算高但这就是开放环境下的正常水平。真正上线的时候比起追求 mAP 高两个点不如先把“近距离低置信度重识别”“雨天反光误检”这类工程问题处理干净。3. 决策与规划从弓字形覆盖到动态避障的算法链路3.1 全局路径先栅格化再 A* 寻路最后平滑环卫机器人的作业不是随便逛它需要在一个区域里“不留死角地走过”。做法是先按网格把作业区域栅格化每个格子的代价值由障碍物膨胀半径、路面类型、历史清扫记录共同决定。然后在这个栅格地图上跑 A* 搜索得到一条起点到终点的无碰撞路径。不过我强烈不建议直接把 A* 的结果丢给底盘控制。A* 出来的路径是由格子中心点组成的折线机器人走起来会原地拐死弯对这个 85 cm 宽的车体来说拐弯时扫刷会漏掉一大片角落。所以我在全局路径上又加了一步优化用“样条曲线平滑 最大曲率约束”把折线变成圆滑曲线控制模块才好跟线。3.2 局部避障动态窗口法 DWA 和它的边界全局路径是静态的但路面上的行人、共享单车、宠物都是动态物体。局部规划我用了比较经典的 DWA 动态窗口法。DWA 的核心思路就是在当前速度范围内采样一组线速度和角速度算出每个组合对应的轨迹然后按“避障代价、朝向代价、速度代价”三个指标打分选最优轨迹执行。实测中要注意DWA 的参数非常依赖机器人物理特性。最大线速度设到 1.5 m/s会出现避障时制动距离不够的情况最后我真值设的是 1.0 m/s最大角速度 0.8 rad/s向前模拟时间 2 s避障半径 0.35 m。这套参数在公园石板路上表现稳妥但是在有落叶的湿滑路面还是明显感觉到刹车距离变长——速度再往下压 20% 会更安全作业效率也不至于下降太多。3.3 状态机把清扫任务拆成几件不会打架的事决策层我是用状态机来组织的状态切换逻辑是待机停在起点收到任务后进入“巡航”巡航按弓字形覆盖路径走同时运行垃圾检测模型发现目标检测到垃圾且置信度超过阈值切换“靠近”靠近减速逼近垃圾坐标距离小于 0.5 m 后触发清扫机构清扫/拾取滚刷启动、风机启动或机械臂夹取持续 3~5 s返回待机确认目标位置无遗留垃圾后回到巡航路径末端继续状态机最关键的规则是任何状态下急停信号优先级最高。STM32 检测到碰撞条、急停按钮或者上位机的紧急停止指令直接切断电机输出这个逻辑必须放在底层不能等 Jetson 来判断否则一次串口卡顿的代价就是撞上路人。4. 运动控制与清扫执行机构让它动得稳、扫得净4.1 差速底盘的运动学拆解底盘是两轮差速结构左右轮独立驱动后面两个万向轮只起支撑作用。正运动学很简单车体线速度 v (v右 v左) / 2角速度 ω (v右 - v左) / 轮距 L。逆运动学就是给定目标 v 和 ω反解左右轮速。STM32 上每个轮子用一个增量式 PID 做速度闭环PWM 输出给直流无刷驱动器。我用的是位置式 PID 和“梯形加减速”结合启动时目标速度按 0.2 m/s² 的加速度斜升避免直接满 PWM 起步把垃圾箱里的东西甩出去。调 PID 时一个容易翻车的点是左右轮各自的摩擦阻力不同同一个 PID 参数左轮响应快右轮响应慢机器人就会跑偏。我最后给左右轮分别标定了 PID 参数并在直线段加上“里程计反馈修正”让两侧编码器累计位移误差保持在 3% 以内。4.2 清扫机构刷盘和风机的配合比你想的更讲究清扫执行部分由三件事组成两侧盘刷把垃圾往中间聚拢中间滚刷把垃圾卷起来风机和集尘箱产生负压把垃圾吸进去。看着简单实际配合起来问题很多。盘刷最核心的变量是转速和倾角。转速太低垃圾到不了滚刷前面转速太高容易把易拉罐打得飞出去。我们的经验是盘刷转速 120~150 rpm倾角往内倾斜 5°~8°让垃圾有一个向中间“滑”的速度分量。风机则要保证集尘箱入口处有足够负压过滤网堵了 40% 之后吸力会断崖式下降软件里必须加一个“风压传感器-点击清理提醒”的联动逻辑否则人看不到集尘箱半天后机器人就纯属在地面画圈了。另外盘刷和滚刷的磨损是隐形成本。试运行 20 小时尼龙刷毛肉眼可见短了 1/3。这不是设计缺陷但你要在维护计划里提前备好易损件不然机器人会越扫越“秃”。4.3 电源整机功耗和电量预估供电设计这块我直接给结论整机额定功耗约 200 W其中底盘电机 80 W、风机 60 W、Jetson传感器 40 W、其他辅助 20 W。按一天连续作业 4 小时算需要 800 Wh再考虑电池放电深度不能超过 80%实际需要 1000 Wh。选 48 V 20 Ah 锂电池刚好稳妥重约 8 kg占车体总重很小。这套系统最大的隐患是风机启动瞬间电流能到额定电流的 2~3 倍如果电池内阻偏大电压瞬间跌到欠压点Jetson 会直接关机。解决办法是风机驱动用软启动PWM 占空比从 50% 到 100% 分 2 秒上升同时把电池管理系统的欠压保护阈值调低 2 V给瞬时大电流留下余量。5. 上位机与调度后台一台样机背后的“车队化”预留很多人做机器人系统只关注车端很少考虑“后台该怎么管”。实际上环卫机器人项目验收时试点方最关心的反而不是算法多强而是“你在办公室能不能看到每台车在哪、还有多少电、任务跑完没有”。这块我基于 MQTT Web 技术搭了一个轻量远程监控与调度平台也给后面接车队运营留了接口。5.1 设备接入层MQTT 消息模型车端和云端用 MQTT 通信主题结构建议按“项目/设备组/设备ID/数据类型”来设计比如robot/group01/robot01/status上报 GPS 坐标、电量、当前状态robot/group01/robot01/cmd接收云端下发的开始清扫、暂停、返航等指令robot/group01/robot01/log上报异常日志与传感器故障码MQTT 的 QoS 我统一用的 QoS 1保证消息至少到达一次。车端网络不稳定的情况很常见比如公园角落 4G 信号差所以车端还有一个本地任务队列云端任务先落盘到本地 SQLite执行完再上报结果网络恢复后自动补报而不是断网就罢工。调度后台的架构其实就是典型的“后端服务 地图前端”前后端分离模式。后端你可以用 Spring Boot也可以换熟悉的 Web 框架核心是做好设备接入层、任务调度和数据库表设计前端用 Vue 这类框架配合 Leaflet/MapBox 加载底图实时显示车辆位置和规划路径。没必要从零写通信协议把 MQTT 的 Broker 用好省下的时间够你把任务调度逻辑好好打磨一遍。5.2 地图可视化与任务下发逻辑后台地图上每一台车是独立的标记点颜色代表状态绿色是巡航黄色是低电量返航红色是故障报警。点击车辆图标能看到最近 5 分钟的轨迹回放、当前电量百分比和本次任务完成率。任务下发不是画个框就完事后台会先要求操作员圈定作业区域然后由服务端调用路径规划算法生成覆盖路径点序列再通过 MQTT 推给对应车辆。还有一个细节远程控制必须先经过“双重确认”。我在后台界面里给手动操作设计了二次确认弹窗防止误触直接把正在作业的车叫回来。这个功能在项目演示的时候尤其重要人多手杂一不留神点错按钮整个演示就翻车了。5.3 电量与故障告警软硬件配合的兜底策略后台要能主动发现异常而不是等人去看。我设计了三个层级的告警策略低电量余电低于 30%后台提示“建议返航”车端同时进入节电模式限制风机功率。严重低电量余电低于 15%车端强制进入返航路径不再执行清扫动作。故障码底盘驱动过流、风机堵转、GPS 长时间失锁分别对应不同颜色告警并推送微信通知。这套兜底策略救过一次场。有一次现场测试时一块电池的 BMS 保护板误触发断开了主输出后台立刻收到“底盘驱动失电”告警不然那台车就瘫在路中央下午演示直接泡汤。6. 实测数据与三个最值得记住的坑6.1 试点场地跑出来的真实数据我们在一个 300 m × 200 m 的市政公园做了连续三周、每天 4 小时的测试核心数据如下指标实测值说明平均定位误差±18 cm融合 EKF 后95% 置信区间垃圾识别 mAP0.591%五类目标现场测试集单任务覆盖完成率96.2%剩余 3.8% 被遮挡路段跳过平均作业速度0.6 m/s兼顾清扫效果与安全无故障运行时长22 小时第三次维护后统计单次充电续航约 3.5 小时40% 时间风机满功率覆盖完成率 96.2% 听起来不错但丢掉的那 3.8% 往往是靠近灌木丛和长椅的边角恰恰是环卫工人最在意的地方。要在这些区域做到 99% 以上需要加一个“贴边模式”或者部署机械臂进行定点拾取这是下一阶段的优化方向。6.2 坑一多机同频干扰让单线雷达直接“瞎了”第一次做双车联调时两台样机同时开机两边的激光雷达都出现了大量的噪点建图直接变成雪花屏。查到最后是两台雷达在相同的频率附近互相干扰发出的激光脉冲被对方的传感器接收产生了一系列假回波点。处理办法有两层第一优先买支持“频偏模式”的雷达A1 和 A2 都能通过命令把采样频率偏移几 kHz多台设备就不会撞车。第二如果雷达不支持调频就在调度后台限制两台机器人的最小作业距离或者错时作业。这个问题在单体样机阶段完全不会暴露一上“车队”就现原形希望你要么提前规避要么选型时直接避开。6.3 坑二扬尘和落叶让视觉识别断崖式下跌公园清晨作业时地面有一层薄薄的水汽和落叶车轮压过去会带起一阵扬尘。我们的 YOLOv5s 模型在干净背景下的单张检测帧率还不错但扬尘起来后检测置信度整体掉得很厉害原因是训练集里几乎没有“灰尘遮挡”的样本。后来我们在训练数据里加了合成噪声把透明灰尘纹理叠加在目标框附近顺便用图像增强模拟低对比度场景。补了 1500 张增强样本后扬尘状态下识别率从 78% 回升到了 87%。如果你在北方城市做类似项目这个数据增强思路可以直接抄。6.4 坑三时间同步问题在联合调试时才暴露车端有多个传感器各自有自己的时钟。视觉检测到垃圾给出目标坐标的时间戳和底盘反馈当前位置的时间戳如果对不齐机器人靠近目标时会“扑空”。我们最初用串口转发的统一时间会有几十毫秒抖动后来直接引入了 NTP 同步方案让 Jetson 作为时间源STM32 和传感器都向它对齐到毫秒级。问题解决后“看到垃圾-停车-清扫”整套流程的响应一致性好了很多。我做这个项目最大的体会是机器人系统设计真正难的不是某个模块而是所有模块一起工作时的那层“缝隙”。感知说自己看到了垃圾规划还没算完路径运动控制已经在执行上一条指令了——每一步都合理合在一起就是乱套。这也是为什么我反复强调主控分家、状态机兜底、时间同步、后台告警这些看似“不酷”的设计因为它们才是系统真正能稳定跑下去的地基。如果你现在准备启动类似项目我的建议是先别急着堆硬件、调模型花一周时间把系统分层和数据流画清楚想明白每一个状态、每一类异常由谁来兜底然后才开始写代码。把基础框架搭对了后面的路会顺畅得多。本文还有配套的精品资源点击获取