电赛经验总结
2022年10月13日--18日，参加了为期六天的上海市大学生电子设计竞赛，选题为B题——具有自动泊车功能的电动小车，成绩为市二等奖，不尽如人意。在此简单总结一下比赛的收获与经验，反思一下失败的主要原因。
非技术层面
方案评估与选择
该场比赛方案选择共花费大概半天时间，当时敲定方案为双摄像头分工与参考 VEX 底盘轨迹规划，由于”看似“时间紧迫，而且抱有希望提前完赛的投机心理，没有进行多方案的推敲与选择。
理想的方案选择应该选取至少两个方案，进行至少两个方面的推敲。推敲的方面有：硬件需求、实现难点、现有技术支持（是否足够可靠），理想效果等等。上述方面的重要性从前至后，重要性依次递减。
一般情况下，往往硬件需求较多，现有技术支持充分的方案，容易在后期暴露出意料之外的实现难点，这一点是难以在方案评估时期确定的。故此类方案应该退而求其次。
在该次比赛中，我们在场景识别上首选了双摄像头方案，不仅陷入了如上可能的困境，疲于优化上层图像处理的算法的输出结果，而且没有进行细致的需求分析，导致错误的系统功能划分（将 巡线行驶 与 车库特征分析 划分为两个独立的子系统）。
后续实践证明，但摄像头方案，只需要更改摄像头的朝向，在二值化的图像基础上，用不同的图像信息提取手段，即可同时实现巡线，车辆绝对位置控制与车库特征识别。
半场开香槟
在赛程期间，我负责小车的底盘规划，在第三天下午基本实现了大致的底盘轨迹规划功能。
由于赛期的延长以及我对现有轨迹规划程序的过分信心，我转而去研究精度更高的轨迹规划模型，并且寄希望于 PID 调参。
在此处研究更高精度的轨迹模型，不仅是因为预期精度的估算错误，同时新的方案开发目的是推翻现有的工作成果以达到更好的效果，这在短时期的比赛流程中是不推荐的。
在研究过程中，没有做好完善的版本管理，导致原有的第一版轨迹规划程序不能复现（由于轨迹规划程序同时依托于软件的PID模块与底盘电机模块，导致仅仅恢复轨迹规划模块并不能实现完全复现）。
制定模块测试计划
为了避免半场开香槟情况的出现，需要对每一功能模块，在方案确定后，当即制定对应的测试计划。在对应模块开发完成后，需要逐一完成上述测试，才能够移交整合，并做好完整的版本存储。
在本次比赛中，需要对轨迹规划程序提前提出测试目标：直线行驶xxx距离（距离应包括，大中小三个测试目标，囊括后续需要的全部轨迹）精度误差达到xxx，曲线行驶xxx精度误差达到xxx，连续目标动作序列是否可实现。
完整的版本存储
抛开使用 git 进行成熟的版本管理的技术不够娴熟，在基本的头文件划分式分工中，保存某一功能模块需要保存该功能对应的自身模块，调用模块，测试代码（main.c），才算完整的模块保存。
保持合理的作息
在短期比赛中，不到特殊情况，不要打破原有的作息习惯。
在原有的作息习惯下，可以保证大脑的休息，可以保证注意力与创造力的活跃，这在比赛期间对于高强度代码书写或是代码BUG疑难杂症的解决是极为重要的。如果现有方案出现技术难点或困惑，除了继续钻研，也可以尝试与队友讨论或是做一些赛题补充任务（比如文档的书写），来放松神经，恢复创造力。
自动补位能力
比赛为三人合作开发，在初期的功能开发阶段可以三人协同分工，同时编写设计，但是鉴于不同的功能开发难度不同，某个人的功能率先开发完成后需要承担起工作整合，比赛推进控制，文档书写控制，物资整理等工作。
自动补位能力针对上述工作量较为离散的工作项目，但是实现的前提是该队员的主要功能已经开发并且测试完成，有精力分散到其他工作上面。
技术层面
轨迹规划的双闭环
为了避免车辆受到电池电压，路况（路面平整度）的影响，在位置闭环控制中，需要加入速度闭环控制。
控制逻辑为：位置偏差，位置闭环输出，速度偏差，速度闭环输出，电机PWM占空比。
电机控制与编码器更新
在控制代码中，需要将电机PWM占空比与编码器数值更新放入一个独立的中断中，定时更新。该定时中断一般选取 2ms—5ms 。
使用无线模块远程调试
使用无线转串口模块，实现串口指令实时更改车辆内部PID等参数，并同时通过串口传回车辆速度，位置等信息，可以采用 SerialPlot 实现图像化现实。
定期排除硬件故障
这一步是在完整的软件测试工作完成后，在之后的步骤中，难以对保存完好的历史版本进行复现时，重点考虑的问题。
标签：10,轨迹,2022,电赛,方案,xxx,模块,规划,比赛 From： https://www.cnblogs.com/sosoeeee/p/16820505.html