-
2021-12-29 17:57:18
在几年的后端开发及项目管理工作经历中,感觉有些关键点是工作中需要注意的。
首先从我自己的工作内容聊起,自己也负责开发了好几个系统,带过几个团队,但是静下心来了解自己的工作,我的主要工作就两个内容:解决问题,进一步把解决方案自动化。
这个也是我工作的主要思路。
一、用文件的形式固化工作成果,保证工作可复制性,最后进一步实现自动化
平时工作遇到一些问题,一定要转化为脚本和文件,保证下次遇到这种问题,可以快速解决。
而不能遇到问题解决问题,没有后续,这种慢慢就吃不消了。
在文件固定化的过程中,也会遇到一些问题,就是垃圾信息较多的问题,出现垃圾文件的原因是当文件较多时,信息变化时,文件中的信息不能保持一致。所以,有两个解决办法,一个是精简文件,另一个就是不断刷新,把垃圾信息清理掉。
不可用文件程序化解决的问题,后续都会成为你的累赘,慢慢拖得你很累,慢慢就走不动。
查问题,清数据都要文件化,这样程序员的生活才能逐步提高。
要明确,我们是需要解决问题,但是不是无脑地、解决问题,而是要用系统、用工具快速地解决问题。
其实这个和下面的生命周期理论也是共通的,如果一个问题,不能系统化、工具化解决,那这个生命周期就没有结束,如果你需要同步处理几个生命周期的问题,那你肯定是崩溃的。
把自己的工作逐步自动化,是我的最主要的工作任务之一,把自己的工作自动化的过程是一个深刻认识自己工作的过程。程序员一定要不断挑战自己,把自己的工作尽可能拆分,然后自动化,只有这样,我们才能走的更远。
二、明码标价 – 工作具象化
做产品也要明码标价,当业务提出一个需求时,一般的产品会直接听业务的,合格的产品会把满足这个需求会产生哪些影响提示给业务人员,让他们有所取舍。就像做买卖一样,把自己的产品的优劣点都告诉业务,让他们做选择,或者自己来做选择。
明码标价是一个需要极高的能力。需要对项目特别熟悉,对表结构特别熟悉。对流程特别熟悉。
三、生命周期思维
做系统就要有系统化思维,看到一个点,就要想到这个功能的整个生命周期,也可以叫做生命周期思维。
一个功能需求,首先要想到如何实现,然后就是异常场景处理,然后就是数据处理,最后是历史回溯。这样就是整个作业周期。
四、UED(用户体验设计)前置
客户在接触到产品之后,才会真正明白自己的需求。一定要让客户尽可能早地看到问题。
五、好系统一定是简洁的
开发系统和做产品都应该学习苹果的产品理念,简洁、简洁、再简洁。
好系统永远是简洁的。
生活中好的示例是苹果手机,苹果电脑,我是一个果粉,反面示例就是电视遥控器,每当在办公室看到那个电视遥控器,我都很难受,密密麻麻什么玩意。
复杂是由简单演变的。复杂和简洁并不是对立面。产品的简洁恰恰是开发的复杂容错兼容实现的。代码的简洁是工具类、逻辑复杂抽象的产物。两者相辅相成。
六、抽象
抽象是从众多的事物中抽取出共同的、本质性的特征,而舍弃其非本质的特征的过程。具体地说,抽象就是人们在实践的基础上,对于丰富的感性材料通过去粗取精、去伪存真、由此及彼、由表及里的加工制作,形成概念、判断、推理等思维形式,以反映事物的本质和规律的方法。
抽象思考的能力怎么强调都不为过。抽象是认识世界的通行证。
只有对开发系统进行抽象,把握主要矛盾,在迷雾中找到珍珠,才能属于真正的成功。
现实的需求纷繁复杂,如果架构师不能够把这些乱无头绪的需求抽象成一些“概念”,在概念的层次进行思考,系统根本就无法设计。
但是抽象出概念以后还不够,还要看看这个概念是不是正交的,能不能独立变化,如果不能,考虑下新的概念抽象。
“正交”讲的是线性无关,非常重要,就像一个点(x,y),在x轴的变化不会影响y,y轴的变化不会影响x,这就是正交。
“正交”威力巨大,(x,y)可以表达二维平面的所有的点,如果增加一个z轴,不但能表达三维空间中所有的点,并且每个轴都可以独立变化。
如果能做出正交的设计,这个系统的开发和维护会非常舒服,以为可以放心大胆的修改其中一个方面儿不会影响其他。
设计模式一直强调的『发现变化并且封装变化』其实就是这个意思。
抽象能力的训练没有捷径,就是经验的积累,勤于思考和学习。例如:学习Android的程序员可以思考下Android是怎么对未知的,纷繁复杂的应用程序进行抽象的?为什么有Activity、Service、BroadcastReceiver、ContentProvider这四大组件?
七、成为技术专家
你在这个领域耕耘的越深,你越有价值。
成为一个长期主义者。
与时间做朋友。
八、好东西是打磨出来的
程序员就像一个艺术家,一个作家,对自己的作品要反复打磨,不可能一出来就是一个优秀作品,一定要让客户、测试、产品反复使用反馈,慢慢优化,从各个方面进行打磨。
九、优秀的人是筛选出来的,不是培养出来的
参加过几家公司,见过不少人,感觉人和人的差距实在是太大了,有的人一点就通,有的人整天稀里糊涂,不要想着培养人,出力不讨好,最好的方式就是优胜劣汰,不断优化,在抢人这一方面,遇到优秀的人,我一般都想抢过来再说,
优秀的人很多方面都是优秀的,根本不需要管理。
十、人员管理问题
在开发的过程中,有个不可避免的问题就是带团队,团队中的人参差不齐,如何好好利用人的资源,这是一个很严重的事情。如果一个好的流程的效率是不好效率的10倍以上。
现在的一个同事在这个问题做的非常好,对于外包人员的开发任务,就是先把接口和表先定义好,让开发人员进行填充,这样就很好地限制,同时对外包人员的代码进行review。这个是做的特别好的。就是一个思路。后续都要参考这个。
更多相关内容 -
Java代码的30条经验总结
2017-07-10 21:21:23Java代码的30条经验总结 -
寒冷地区排水管网的施工养护和维修经验总结.ppt
2022-05-28 03:22:57寒冷地区排水管网的施工养护和维修经验总结.ppt寒冷地区排水管网的施工养护和维修经验总结.ppt寒冷地区排水管网的施工养护和维修经验总结.ppt寒冷地区排水管网的施工养护和维修经验总结.ppt寒冷地区排水管网的施工... -
4年seo经验总结.docx
2022-05-07 17:42:424年seo经验总结.docx4年seo经验总结.docx4年seo经验总结.docx4年seo经验总结.docx4年seo经验总结.docx4年seo经验总结.docx4年seo经验总结.docx4年seo经验总结.docx4年seo经验总结.docx4年seo经验总结.docx4年seo经验... -
华为公司运作模式详解及经验总结—华为怪胎的启示.pdf
2022-06-12 09:17:29华为公司运作模式详解及经验总结—华为怪胎的启示.pdf华为公司运作模式详解及经验总结—华为怪胎的启示.pdf华为公司运作模式详解及经验总结—华为怪胎的启示.pdf华为公司运作模式详解及经验总结—华为怪胎的启示.pdf... -
智慧社区建设经验总结.docx
2022-06-14 18:05:00智慧社区建设经验总结.docx智慧社区建设经验总结.docx智慧社区建设经验总结.docx智慧社区建设经验总结.docx智慧社区建设经验总结.docx智慧社区建设经验总结.docx智慧社区建设经验总结.docx智慧社区建设经验总结.docx -
金融行业容器云平台需求分析及架构设计经验总结.docx
2022-07-11 13:55:15金融行业容器云平台需求分析及架构设计经验总结.docx金融行业容器云平台需求分析及架构设计经验总结.docx金融行业容器云平台需求分析及架构设计经验总结.docx金融行业容器云平台需求分析及架构设计经验总结.docx金融... -
金融行业容器云平台需求分析及架构设计经验总结.pdf
2022-07-11 12:49:56金融行业容器云平台需求分析及架构设计经验总结.pdf金融行业容器云平台需求分析及架构设计经验总结.pdf金融行业容器云平台需求分析及架构设计经验总结.pdf金融行业容器云平台需求分析及架构设计经验总结.pdf金融行业... -
seo推广经验总结.docx
2022-05-12 12:29:19seo推广经验总结.docxseo推广经验总结.docxseo推广经验总结.docxseo推广经验总结.docxseo推广经验总结.docxseo推广经验总结.docxseo推广经验总结.docxseo推广经验总结.docx -
seo原理三年实战经验总结.pdf
2022-06-11 10:21:37seo原理三年实战经验总结.pdfseo原理三年实战经验总结.pdfseo原理三年实战经验总结.pdfseo原理三年实战经验总结.pdfseo原理三年实战经验总结.pdfseo原理三年实战经验总结.pdfseo原理三年实战经验总结.pdfseo原理三年... -
“美丽乡村”建设路径分析及经验总结.pdf
2022-07-01 15:54:08“美丽乡村”建设路径分析及经验总结.pdf“美丽乡村”建设路径分析及经验总结.pdf“美丽乡村”建设路径分析及经验总结.pdf“美丽乡村”建设路径分析及经验总结.pdf“美丽乡村”建设路径分析及经验总结.pdf“美丽乡村... -
seo原理三年实战经验总结.docx
2022-06-06 20:41:47seo原理三年实战经验总结.docxseo原理三年实战经验总结.docxseo原理三年实战经验总结.docxseo原理三年实战经验总结.docxseo原理三年实战经验总结.docxseo原理三年实战经验总结.docxseo原理三年实战经验总结.docxseo... -
软考高级 学习经验总结 V2.0.pdf
2022-06-20 08:43:55软考高级 学习经验总结 V2.0.pdf软考高级 学习经验总结 V2.0.pdf软考高级 学习经验总结 V2.0.pdf软考高级 学习经验总结 V2.0.pdf软考高级 学习经验总结 V2.0.pdf软考高级 学习经验总结 V2.0.pdf软考高级 学习经验... -
软考高级 学习经验总结 V2.0.docx
2022-06-18 10:15:09软考高级 学习经验总结 V2.0.docx软考高级 学习经验总结 V2.0.docx软考高级 学习经验总结 V2.0.docx软考高级 学习经验总结 V2.0.docx软考高级 学习经验总结 V2.0.docx软考高级 学习经验总结 V2.0.docx软考高级 学习... -
信息系统项目管理师经验总结.docx
2022-05-27 19:22:03信息系统项目管理师经验总结.docx信息系统项目管理师经验总结.docx信息系统项目管理师经验总结.docx信息系统项目管理师经验总结.docx信息系统项目管理师经验总结.docx信息系统项目管理师经验总结.docx信息系统项目... -
信息系统项目管理师经验总结.pdf
2022-05-27 16:48:51信息系统项目管理师经验总结.pdf信息系统项目管理师经验总结.pdf信息系统项目管理师经验总结.pdf信息系统项目管理师经验总结.pdf信息系统项目管理师经验总结.pdf信息系统项目管理师经验总结.pdf信息系统项目管理师... -
华为路由器交换ACL的应用与经验总结.pdf
2022-06-05 19:32:20华为路由器交换ACL的应用与经验总结.pdf华为路由器交换ACL的应用与经验总结.pdf华为路由器交换ACL的应用与经验总结.pdf华为路由器交换ACL的应用与经验总结.pdf华为路由器交换ACL的应用与经验总结.pdf华为路由器交换... -
华为路由器交换ACL的应用与经验总结.docx
2022-06-05 19:11:37华为路由器交换ACL的应用与经验总结.docx华为路由器交换ACL的应用与经验总结.docx华为路由器交换ACL的应用与经验总结.docx华为路由器交换ACL的应用与经验总结.docx华为路由器交换ACL的应用与经验总结.docx华为路由器... -
多年网站经验总结SEO外链的六个阶段.docx
2022-05-25 19:12:34多年网站经验总结SEO外链的六个阶段.docx多年网站经验总结SEO外链的六个阶段.docx多年网站经验总结SEO外链的六个阶段.docx多年网站经验总结SEO外链的六个阶段.docx多年网站经验总结SEO外链的六个阶段.docx多年网站... -
信息系统项目管理师学习经验总结.docx
2022-05-27 16:36:07信息系统项目管理师学习经验总结.docx信息系统项目管理师学习经验总结.docx信息系统项目管理师学习经验总结.docx信息系统项目管理师学习经验总结.docx信息系统项目管理师学习经验总结.docx信息系统项目管理师学习... -
全国大学生数学建模大赛经验总结.docx
2022-05-20 11:40:13全国大学生数学建模大赛经验总结.docx全国大学生数学建模大赛经验总结.docx全国大学生数学建模大赛经验总结.docx全国大学生数学建模大赛经验总结.docx全国大学生数学建模大赛经验总结.docx全国大学生数学建模大赛... -
网站SEO优化:的优化工作经验总结.pdf
2022-05-15 09:56:19网站SEO优化:的优化工作经验总结.pdf网站SEO优化:的优化工作经验总结.pdf网站SEO优化:的优化工作经验总结.pdf网站SEO优化:的优化工作经验总结.pdf网站SEO优化:的优化工作经验总结.pdf网站SEO优化:的优化工作... -
网站SEO优化:的优化工作经验总结.docx
2022-05-12 09:57:32网站SEO优化:的优化工作经验总结.docx网站SEO优化:的优化工作经验总结.docx网站SEO优化:的优化工作经验总结.docx网站SEO优化:的优化工作经验总结.docx网站SEO优化:的优化工作经验总结.docx网站SEO优化:的优化... -
AWSSAA考试经验总结.pdf
2022-06-05 16:14:56AWSSAA考试经验总结.pdfAWSSAA考试经验总结.pdfAWSSAA考试经验总结.pdfAWSSAA考试经验总结.pdfAWSSAA考试经验总结.pdfAWSSAA考试经验总结.pdfAWSSAA考试经验总结.pdfAWSSAA考试经验总结.pdf -
AWSSAA考试经验总结.docx
2022-06-05 15:34:13AWSSAA考试经验总结.docxAWSSAA考试经验总结.docxAWSSAA考试经验总结.docxAWSSAA考试经验总结.docxAWSSAA考试经验总结.docxAWSSAA考试经验总结.docxAWSSAA考试经验总结.docxAWSSAA考试经验总结.docx -
软件测试实战 微软技术专家经验总结
2017-12-06 08:52:08软件测试实战 微软技术专家经验总结,一本微软的好书,经验积累 -
QTP经验总结
2018-05-02 13:03:53QTP经验总结QTP经验总结QTP经验总结QTP经验总结QTP经验总结 -
前端程序员Vue开发经验总结
2022-01-20 13:14:411:ssd项目大屏和管理系统总结 echarts基础样式: 管理系统增删改查: 2:ms协同平台总结 流程开发: element组件操作:1:ssd项目大屏和管理系统总结
echarts基础样式:
管理系统增删改查:
2:ms协同平台总结
流程开发:
element组件操作:
tabs标签:
// 获得标签数组 async getTabarr() { let date = this.date let id = this.diamondBlockId const params = { date: date, diamondBlockId: id } const resFormObj = await DiamondBlockinfo(params)//获取当前菱形块编号下表单数据 const resTableArr = await BlastHoleStatusInfo(id)//获取当前菱形块编号下表格数据 const dataObj = resFormObj.data const dataArr = resTableArr.data let nameArr = this.editableTabs.map(item => item.name) if (nameArr.includes(id)) { this.editableTabsValue = id } else { this.editableTabs.push({ title: id + '日爆破确认', name: id, InfoForm: dataObj, showArr: this.changeList(dataArr), BlastholeData: dataArr }) this.editableTabsValue = id } console.log('tabs数组', this.editableTabs); }, // 移除标签 removeTab(targetName) { let tabs = this.editableTabs let activeName = this.editableTabsValue if (activeName === targetName) { tabs.forEach((tab, index) => { if (tab.name === targetName) { let nextTab = tabs[index + 1] || tabs[index - 1] if (nextTab) { activeName = nextTab.name } } }) } this.editableTabsValue = activeName this.editableTabs = tabs.filter((tab) => tab.name !== targetName) },
后端的数组重新生成新的数组两种方法:
1:foreach 可以生成一个自定义的数组对象
const newlist = this.twolist this.list.forEach(item => { const data = { name_age: item.name + item.age } newlist.push(data) })
可以拿到一个自定义的newlist数组对象
2:map 操作原有的数组生成新数组字符串
this.twolist = this.list.map(item => item.name + item.age)
更深一点的是 拿着返回的数组对象进行数组加字符串的操作:例如下面的函数方法:
changeList(list) { return list.map((hole) => { const item = Object.assign({}, hole) item.holeId = item.holeId.split("_")[1] if (item.holeNumber < 10) { item.holeNumber = "0" + item.holeNumber } return item }) },
操作数组里面对象的值进行字符串的加工,不想更改原数组数据要浅拷贝一层。
父子组件总结:
1:父子组件不涉及相互业务的,只需父组件把查询条件传参到子组件即可,子组件进行接口查询
2:父组件传一个控制子组件的变量参数,实现控制子组件(例如v-for显示或者disable控制是否允许输入)
3:子组件v-for循环,如果循环的每个组件里面的属性不一样,需要在父组件里提前处理后端返回的数据,不应该直接拿后端返回的数据进行循环。思维:有时候后端返回的数据不好操作时,记得先处理一下数据,在渲染
接口返回的res比较杂乱,定义一个数组,拼凑成想要的数组集,再传给子组件循环 $http.getSbfData().then((res: any) => { const data = res.data this.waterPumpCardBoxData = [ { name: '新立-600', xl600CbMonth: data.xl600CbMonth, xl600PowerDay: data.xl600PowerDay, xl600PowerMonth: data.xl600PowerMonth, xl600PriceDay: data.xl600PriceDay, xl600PriceMonth: data.xl600PriceMonth, xl600PslDay: data.xl600PslDay, xl600PslMonth: data.xl600PslMonth, }, { name: '西山-1140', xl600CbMonth: data.xs1140CbMonth, xl600PowerDay: data.xs1140PowerDay, xl600PowerMonth: data.xs1140PowerMonth, xl600PriceDay: data.xs1140PriceDay, xl600PriceMonth: data.xs1140PriceMonth, xl600PslDay: data.xs1140PslDay, xl600PslMonth: data.xs1140PslMonth, }, { name: '西山-435', xl600CbMonth: data.xs435CbMonth, xl600PowerDay: data.xs435PowerDay, xl600PowerMonth: data.xs435PowerMonth, xl600PriceDay: data.xs435PriceDay, xl600PriceMonth: data.xs435PriceMonth, xl600PslDay: data.xs435PslDay, xl600PslMonth: data.xs435PslMonth, }, ]
-
项目工作经验总结
2018-04-15 20:36:44项目工作经验总结由于我在团队中担任了项目经理的职责, 因此在这次项目的开发过程中, 主要由我来进行工作的协调, 安排任务, 考察进度等。通过前段时间的团队合作过程中让我有了一些管理项目与管理团队上的浅薄...项目工作经验总结
由于我在团队中担任了项目经理的职责, 因此在这次项目的开发过程中, 主要由我来进行工作的协调, 安排任务, 考察进度等。通过前段时间的团队合作过程中让我有了一些管理项目与管理团队上的浅薄经验, 在这里做一个小小的总结吧。
我得到的经验有以下几点:
1. 团队成员一定要有明确的分工
在项目的初期就划定好各自具体职责范围是一个很有必要的任务。一旦这个工作完成之后, 一旦在进度上出现任何问题(Ex. 停滞或者跑偏),就可以很轻松的找到分工管辖的那位同学。这样比起可能出现的互相推诿的情况要好太多。
在划分分工的时候有几点需要注意:
尽量保证每个人的总工作量相同或近似。相对的公平是肯定必须的, 但是这就涉及到一个比较麻烦的事情:如何预估每个部分的工作量?
就我们来说, 我们是先经过小组会议, 大体确定每个任务的 人·时 数, 并在组内确认大家一致同意。接着按照大体相同的 人·日 总数进行划分。
尽量保证小组成员的工作都分配到各自现有技能池中已有的任务。尽量降低学习成本。在这一点上, 我们是先采用自主选择任务的方式。最后将大家都需要学习的一些任务均分一下。保证每个人的学习成本都不会太高。
分工一定尽量明确。以往经验告诉我们,在分工不明确有交集的部分,之后的代码合并工作将会十分痛苦。因此我们划分工作任务的时候尽量保证明确。但是在需求文档没有完全完成之前, 要实现完全的分工是比较难的。所以接下来我们将会继续把分工明晰化。
2. 定期的团队会议不可缺少
由于我们组员来自不同的专业方向, 各自的空余时间也不大相同。因此团队会议成为项目的主要讨论时间。团队讨论在项目的初期我认为是十分重要的。首先项目的初期有许多文档需要着手开始,我们需要通过讨论分工才能确定各自负责的制品;其次团队会议可以使早期的需求分析变的更为简单,把大家的意见都摆到桌面上进行一一讨论,总结,就基本完成了需求初步分析的阶段;再者,团队会议可以为我们每周的迭代开发的工作量进行确定。由于我们每周其他课业的任务不同, 因此可能每个人每周的人·时 数是不会每次都相同的。通过会议,大家各自说明一下自己本周大致的空余时间情况, 再据此确定本周的迭代任务。
我们的团队会议流程大致如下:
开始会议→确定会议讨论话题→开始讨论→会议记录整个讨论过程→得到讨论结果→确定下周迭代任务→会议结束,更新项目计划文档→整理会议记录,得到会议记录的制品
我们的会议频率是每周一次,每次会议时常大约90min左右。
3. 作为组织者,需要了解每个人的任务
我觉得这一点算是之前的项目经历得到的经验吧。重点在于如果连任务就不是很清楚,那就没有办法对进度进行及时跟踪。
了解各人任务的方式有许多, 我采用的是以下的几种:
1. 在团队会议时, 组员共同讨论,发言,说明本周迭代自己工作的主要任务,得到哪些制品。 2. 在Tower上发布任务之后, 要求该工作的完成者自行填补上工作细节。 3. 对剩余不清楚的地方,私下找组员询问并记录。
了解任务是为了对每个人的完成工作的能力进行大致的了解, 从而促使任务进行更加合理地安排。简单的说,就是能者多劳,但是要在大致公平的前提下。
4. 偶尔承担额外任务
这个不必多说, 完成项目总会有些时候遇到大家都觉得比较麻烦的“硬骨头”, 这时候组织者有两种选择: 要不指定组员完成, 要不自己完成。 目前这种情况并没有很多, 所以我都选择了自己去把一些简单但是繁琐的任务给完成了。
这种额外任务还可能出现在小组成员突然有些其他的事需要完成(例如猝不及防的其他课程ddl)。这个时候可能也需要有人站出来及时完成这周迭代工作。(这种情况的话下周会适当增加该组员的任务)
5. 及时跟踪团队进度
团队进度的保证是所有团队工作的基础。每次迭代的工作一定要务必确保按时完成。就像老师上课说的:宁可少布置一些迭代任务, 也要保证工作按时完成 。
跟踪团队进度的话,主要有以下几种方式:
- 小组讨论, 汇报工作;这是一种很常见的形式。 当面交流能够很迅速的把工作交代清楚;
- 通过Tower来跟踪每个子任务的完成情况。当然这需要完成者自行添加上自己任务的子任务, 这样之后只需要检视子任务的完成情况(即完成与否), 就能够大致了解本次迭代的进度了。
- 以上是对进度情况打的大致了解, 最终还是需要检查本次迭代的制品。这才是确保任务真实完成最直接有效的方式。制品的检查可以是自己一个人审阅, 也可以是和非该工作的完成者的其他组员 共同审阅,便于发现问题。
以上就是我这几周的项目工作经验总结、目前项目还处于初期阶段, 相信接下来的开发过程应该会有更多经验与大家分享。
-
中国高校智能机器人比赛经验总结与分享——1V1擂台机器人
2020-06-21 18:06:43比赛经验总结1.比赛前期车体安装及调试2.比赛车体调试与经验汇总 比赛简介 智能机器人格斗大赛(Intelligent Robot Fighting Competition,简称IRFC),IRFC将中国武术、竞技运动与人工智能、机器人等技术结合,融...
比赛简介
智能机器人格斗大赛(Intelligent Robot Fighting Competition,简称IRFC),IRFC将中国武术、竞技运动与人工智能、机器人等技术结合,融技术性、对抗性、挑战性、观赏性于一体,参赛队伍进行一对一,多对多等不同项目的角逐,大赛分统一部件组及开放部件组两大类别。
统一部件组
参赛队伍选用统一标准和性能的控制器、传感器、动力模块、供电模块等部件,设计、制作符合规则要求的智能机器人参赛,通过策略的制定及程序的设计,参赛双方的机器人在擂台上对抗,依据竞赛内容与评分规定由裁判进行裁决,采取小组循环赛及淘汰赛相结合的赛制。统一部件组根据比赛形式不同,设置轮式自主格斗、仿人格斗、仿人视觉对抗等三个项目组别。1.总体策略
上台策略:
首先,机器人需要识别自己是否在台下,这里通过前后左右的红外传感器是否被遮挡来判别,在台上时,至多有一个方向的红外传感器被遮挡,而在台下时,一定有两个或以上方向的红外传感器被遮挡,故我们可以通过红外传感器被遮挡的方向数来判断其是否在台下。
如果机器人判断自己在台下便会激活上台操作,先判断自己的朝向,将自己调整成前上台状态,再进行前上台操作。同时机器人还会同时判断敌人是否在阻止自己前上台,并避开敌人的骚扰再进行前上台。备战策略:
机器人在台上时,优先保证自己不会掉下台,通过顶部的四个传感器时刻检测自己处于台上边缘的危险地带,并采取相应的行动避开这些危险地带,确认自己处于安全状态后才会进入与敌人博弈的对战状态。
应敌策略:
机器人通过中部的前后左右四个传感器来判断敌人的位置,当敌人在自己的两翼时立即避让保证自身安全,当敌人在自己前后时加速撞向敌人,将敌人撞下台。传感器策略:
(1)底层传感器(AD1-AD4):
类型:红外光电传感器,返回数字量,当传感器被遮挡时值返回高电平,未被遮挡时返回低电平。
安装位置:四个方向各一个,垂直于小车边沿放置。
作用:①用于小车台下朝向检测;②用于检测小车是否在台上;③用于检测敌人。
(2)中层传感器(AD5-AD8):
类型:红外测距传感器,返回模拟量,传感器距前方物体越近,返回值越大。
安装位置:四个方向各一个,垂直于小车边沿放置。
作用:①用于检测小车是否在台上;②用于小车台下朝向检测;③用于小车台上边缘检测;④用于检测敌人;⑤用于小车搁浅检测。
(3)顶层传感器(AD9-AD12):
类型:红外光电传感器,当传感器被遮挡时值返回高电平,未被遮挡时返回低电平。
安装位置:小车左右两边各放置两个,传感器探头与小车车身成××角度。
作用:用于小车台上边缘检测。
(4)传感器配合使用方案
①检测小车是否在台上:AD1-AD8
获取AD1-AD8的采样值,并转换为相应的数字量(大于500取1,小于500取0)。设置前、后、左、右四个方向值,各方向值为该方向上红外光电传感器返回值取反再与红外测距传感器对应的数字量返回值相或。总判断值为四个方向值相加,根据总判断值判断小车是否在台上。
②小车在台下时朝向检测:AD1-AD8
设置四个阈值,用于判断AD5-AD8四个传感器前方障碍物的情况。,根据AD1-AD8传感器返回值判断小车四周障碍物,以此得出小车在台下的朝向。
③小车在台上时边缘检测:AD5-AD8
根据AD5-AD8的返回值判断各传感器检测到擂台还是地面,以此判断小车是否处于擂台边缘。
④小车搁浅检测:倾角传感器机器人硬件设计:
本机器人主要由执行器、控制器、传感器以及连接件构成。
在执行器方面,底部我们使用开环驱动器将四个电机两两并联,并安装好塑胶轮胎,使得左侧两轮与右侧两轮能够同时同速度转动,为小车提供空间运动驱动。同时可通过调整左右电机转速,达到转弯、加速、后退等运动效果。我们在小车的上半部分固定四个舵机,并为舵机加装了塑料爪,可实现小车的蹬地,使之上台以及克服搁浅情况。
在控制器方面,我们将LUBY控制器与对其供电的白盒电池连接在一起,并将其固定在小车上半部分,压住对驱动器供电的电池。由于我们采用总线控制模式,故我们将四个舵机、两个驱动器串联在一起,并连接在控制器上,同时13个传感器也通过ADC接口逐一连接在控制器端口上。
在传感器方面,我们在底部前后左右分别安装了一个红外光电传感器,向控制器返回非高即低的控制信号,其被遮挡时发射低电平。在上半部分的前后左右我们加入了四个红外距离传感器,向控制器返回模拟信号,距离障碍物越近其值越高。通过这八个传感器我们可进行小车是否在台上以及方向的判断。在小车顶部我们安装了四个向下倾斜的红外光电传感器,目的是为了检测擂台边缘。防止小车运动时掉台。最后我们在小车中部安装倾角传感器,可判断小车是否侧向倾斜。
在连接件方面,我们用螺钉螺母,以及垫圈等固定住两部件,用L型件来固定传感器,舵机嵌入专门的舵机壳。同时也设计了能让顶部红外光电传感器全角度调节的连接结构。2.比赛经验总结
整体来讲我们最后取得的奖项并不理想,现场比赛出现意外较多,尤其是最后决赛,小车线路接触不良,导致最后以一名之差获得三等奖,止步64强,还是颇为遗憾的,所以关于经验这一块也感想颇多。
1.比赛前期车体安装及调试
① 车体安装:
主要参考所给演示视频,但有些地方视频所给有错误,同时也要比对所给说明文档,确定各零件最终安装位置及方向。
车体安装避免不了自己打孔,位置事先要认真较量比对准确。
还有一点需注意,一般最后定型的车,从第一次安装好总免不了经过多次改装,所以有些重要部件不要绝对“粘死”,在保证整个车体安装稳定的情况下,还要考虑到车的“可拆卸性”。
安装时,注意车体的规格是否符合比赛要求。(长宽30cm*30,高度不限,重量4kg,误差不超过5%,即最重可达4.2kg)。车体中心尽可能低,重量尽可能靠近4.2kg(加重可用废弃电机,舵机,锂电池等其他合适部件)。
安装时,要多方考虑,能顾及到许多细节,比如舵机ID标签的放置位置;电池充电口的朝向(至少保证不影响正常充电);四个电机左右的对称性,以保障速度方向的一致性;传感器尽量往里收(避免直接受到外部撞击)等等。
② 车体调试:
基本调试软件 keil,robotservo,luby crater 需掌握调试方法,具体可看参考文件。
#3个软件总结使用要点:
keil点击下箭头才能生成可执行文件。
luby creater 调传感器,用5针杜邦线连接luby upload口,多功能调试器调节r开头模式,也就是第一个。
robot调舵机,端口输入正确,如果找不到控制器,看电源是不是连接了,这个需要用白盒电池充电线给额外供电,以及驱动和舵机连接线是否断开。
其实很多问题可以百度得到,或者问老师,并且参考文件里也有视频教程
③ 调试常见问题:
硬件未实现软件相应功能:极大可能物理结构本身不合理性导致。
舵机运动异常:通电后,手稍用力转动舵机爪,看是否能轻易转动,若能则说明此舵机未供上电,极可能舵机连接线松动或故障。
正常情况下,初始化控制器时,四个舵机红色指示灯亮是正常,此外需注意,舵机通电运动正常情况下,不可用力强行转动舵机,否则会使舵盘及舵机受损。
若调试,轮子不转动,则先检查,驱动指示灯是否正常亮,若亮则说明不是电量原因引起。此时则可以检查驱动ID 号是否正常(ID可能消失或突变),若是正常,则可写一类似move()函数,来检测电机是否能正常工作。
舵机线接触不稳,关于此问题,首先舵机线接口处可以用热熔胶固定,此外,要尽量少的去来回拨动或拧舵机线,避免内部电线受损。
④ 基本常识:
每次调试结束,走之前给小车两个电池充上电,注意蓝电池(给驱动供电电池)开关要打开,指示灯才变红充电,否则就充不上电,以免下次调试时小车没电。
螺钉装卸次数达到一定程度时,自己要主动更换新的螺钉,避免因螺纹磨损而导致螺钉卡住。
调试时发现有哪个零件损坏或工作异常,及时检查和更换。
参考代码的函数务必理清思路,才可根据小车传回参数或者异常表现知是哪些传感器原因导致。
代码中函数功能是调节传感器的的依据,通过调节传感器,才能给出合理的参数。2.比赛车体调试与经验汇总
① 赛前调试
这一天(5.6)都在用于调试,对车的调整可能会比较多,一般没意外的话,小车也基本定型与该天晚上。由于参赛队伍比较多,所以要尽可能的早去场地,让车先在测试场地跑一下,检测上台,攻击,漫游,边缘检测,寻找擂台,寻找敌人功能,然后做相应调整。因为不同的学校的攻击力不同,测试时要注意保护自己车,还有场地可能会被一些铲子比较薄的车破坏,还有台上比较多,可能导致自己车误判,所以要尽可能早的测试这些功能函数,否则之后只能做一做边缘检测和模拟对战。
比赛场地会开放一段时间,要利用好这次机会,检测小车功能和工作情况。
② 小组初赛与决赛淘汰赛
在条件允许的情况下,可以事先观看下对手的实力,可适当做一些策略准备。
每次比赛开始前要确保检查小车功能是否正常,距离自己还有3-7组的时候可以事先去场地观看等待,并注意上场前提前检查小车功能是否正常。
每次比赛上场,兜里要带小螺丝刀,以备不时之需。
比赛时,队友可以分两侧站立,应至少有一个站在自己这一侧,可以帮助自己观察整个场上的情况,帮助场内队友做出正确的抉择,同时应至少有一个站在对手侧,及时反馈对手车况,辅助场内队员战略规划。
在本次比赛,通过观察强者队伍的车的特点,分析他们的物理结构上的优势,同时寻找代码上的优势,很明显的他们的车体,几乎流线型的3d打印结构,把控制器,电源,传感等核心部件几乎包嵌在车体中,车很干净利落,同时硬件保护的也很好,少了“肢爪”结构,可以避免被对方车体“带落”,同时也很大程度避免了卡台。他们的代码很明显的一处,就是加了守台函数,很值得借鉴。