【原创】总结大创项目-基于深度学习的智能红绿灯调控系统

一、产品定位分析
　　（注：以下调研均发生于2017年5月前。）
　　由于此次项目最初是为了参加Intel举办的某届基于深度学习的创新应用比赛，当时召集了小组成员集思广益，想一些具有创意的点子作为此次项目的立项定题的方向。最终确立下来的有两个，一个是“智能垃圾箱”（大概构思是垃圾箱盖附近的摄像头检测欲扔进垃圾箱的垃圾类别，实时反馈到显示屏或者语音提示将其扔往正确的垃圾箱入口），但是由于被导师认为在实际投入应用中受人为因素影响太大（因为国民普遍素质仍有待提高……），进而此立意夭折；另一个项目就是我们已经做的“智能红绿灯调控系统”，最初的灵感就是来源于北京令人痛苦不堪的交通拥堵问题。
　　接下来，正式进入对这个题目的前期调研和分析工作。
　　首先，正式描述下项目的构思来历（截取自项目计划书）：“现阶段，交通拥堵已成为世界性“城市病”，不仅各国每年因交通拥堵蒙受的损失十分惨重，而且交通拥堵还带来了一系列的环境问题。所以在这样的大背景下，十字路口的交通调度就变得格外重要。于是我们希望通过深度学习的方式实现对交通灯的智能调控。同时，再深入的，我们可以综合整体数据，统计分析，调控红绿灯，为如救护车、消防车开辟最优‘绿色通道’为急救争取时间。”
　　项目的目的和意义：“让机器来检测路口车辆的数量，帮助我们有效的动态调整红绿灯时间,尽可能扩大路口流量。这样，不仅能节约现有的硬件检测成本，而且实现了城市交通管理智能化，控制便捷化，能更加有效地解决交通拥堵的难题。”
　　然后，调研了目前市场上主要运用的检测交通拥堵程度的方法，有三种，分别是基于线圈技术（不能进行多车道检测）、基于视频技术（根据视频背景灰度变化检测，不能检测多车道）、和基于微波技术（不能准确检测单一车辆速度）。细节就不详述了，总结就是现在的传统检测技术硬件维护成本较高且不能进行多车道检测。但利用深度学习图像识别就可以实现检测车辆数目以及解决多车道检测的问题。另一方面，我们还调研了现实中红绿灯使用调度情况：目前红绿灯在一个较长的周期内都是遵循一个固定的交替变更规则的，都是根据之前长期的历史数据积累进而判断例如高峰时段的存在，进而以这种情况下制定的规则沿用较长一段时间直到下一次积累数据的变化。这样存在的问题很明显，就是很好地应对突发状况，一旦此路口在非高峰时段突然遭遇异常拥堵，则就算快速调用警力来疏通也是相当费时费力的。要知道，当今这个时代，时间就是金钱啊！！所以，要是能够及时监控各路口的各方向的拥堵情况，红绿灯智能地根据拥堵状况变更运行规则，则能极大地增大拥堵时的通过率，乃至，最后没有拥堵情况的存在了。
　　根据调研，我们划分出这个系统的三大主要功能：
　　　　1.检测车辆数动态调控信号灯：截取路口摄像头拍摄的画面，自动识别每个车道上的车辆数量，根据四个待放行方向的车流量动态变换信号灯切换时间；
　　　　2.实时路况分析：根据检测出的车辆数量，给出各路段的实时路况热点图；并提供在紧急情况下，根据实时路况，及时规划出一条最合适的可应用于医疗消防等领域的绿色通道。
　　　　3.以往车流量分析：保存车流量记录，分析得出易拥堵的特殊时段与路段。
　　“此项目的创新性在于改变了传统的定时信号灯系统，结合深度学习，识别每个方向每个车道的车辆数，通过特定算法给出合适的信号灯切换时间，利用不同行驶方向车流量的差别，充分提高路口通过率从而舒缓交通压力；同时利用数据和技术的便捷，提供紧急情况时的绿色通道服务。” 嗯，这还是计划书中的原话。

　　总结：
　　　　优：

1. 1. 由于才结束大二小学期J2EE学习。所以对于Web开发有少量的知识储备。
   2. 团队成员都很踏实勤奋。都在很卖力的想点子。所以我们小组的进度一直都比其他小组快。　　　　　　　
   3. 学校支持度高。特别是导师，给予丰厚的经费支持。　

　　　　不足：

1. 1. 由于几乎是第一次参加这种大型的竞赛，也是第一合作很正规地走流程完成一个完整的需要验收结题的项目，再加上当时还没有学习《软件项目管理》、《软件过程改进》、《软件工程导论》等这一系列对于一个较大的软件项目的指导课程，所以，缺乏经验。
   2. 具体的，需求阶段：
   • • • 不清晰的需求说明，进而导致目标不清晰和不切实际的期望。主要体现在未编写需求说明文档，借助了原型模型，但是搭配的几乎是瀑布模型。　　解决方案：即时竞赛未要求提交需求说明书，自身也需要通过（无论是简略的还是详细的，根据具体开发模型而定）需求文档来统一和再次巩固考证需求的完整性好合理性。对于短期的需求很明确的项目，应使用完整详细的需求说明书来描述需求；但对于此次非短期的需求可能会变化的项目，首先应该借助原型模型（Rapid Protyping Model）最大程度的减少需求的变更，但是原型法也无法保证需求是稳定的，另外其他的不确定性因素也很多，所以也同时考虑增量/迭代模型（Incremental / Iterative Model），用增量/迭代模型和原型法综合使用，来确保把风险降低，同时还必须保证每一次增量或迭代都有明确的交付和出口的准则。
       • 缺少用户参与。由于我们团队项目的涉众不仅仅是普通民众，主要还有交警部门，但是当时联系渠道有限，最后只能去到路口询问值班交警获取信息。所以导致需求不够准确。而且对涉众进行调研的时间也不合理，已经在编码之后……所以导致返工。然后就是团队内这样的对话（还要考虑这个吗？实现不了了吧……）对于一群菜鸟，感到无比地绝望……        解决方案：在需求前期，也就是在大概确定立题方向的时候，就应该组织对涉众进行调研。
       • 需求变更。由于以上几个问题以及欠缺专业的配置管理，导致需求变更频繁，进而是不断的返工+逐渐增加的压力。     解决方案：加强对需求过程的管理以及沟通过程的管理。避免需求变更以及沟通过程中的需求失真。
       • 缺乏足够的需求验证……

　　　　　　3. 设计阶段:

　　未完……

原文地址：https://www.cnblogs.com/nicoleynh/p/9504711.html