致这个失败的春天

三月份和四月份一下子成了失败的代名词。
三月份参加 OM 结构赛，因为经验不足导致崩盘。经验不足，那是水平的问题，也就算了。但随后的四月，我和同学几乎天天肝到四点准备一场机械赛，结果止步三十二强。
机械赛这件事情，整个失败看上去是如此莫名其妙：在赛前，我们觉得自己的水平最起码也是进四强。这个比赛，概括来说就是造一个机械，在限时内在沙地里移动并挖取物块，并将挖取的物块转移到得分区，根据物块类型和数量计算总分。
从实力上来说，我觉得我们队是真的很强的。队里有两个常年做机器人的大佬，Solidworks 用得得心应手；有好几个擅长码代码的，可以一起调试电控；也有强于修改硬件部分、根据情况实地调整的，总而言之我们并没有碰上过大的技术难题。
另外我们的整个流程，我觉得也足够符合工程规范：

• 在正式动工之前，我们先用木板和零件加工了一台 minimum function 的样机，用它来测算尺寸和测试设计（之所以不用 Solidworks 做这个是因为很多我们用的零件没有现成的模型）。等这些都完成了，我们才开始做正式版。
• 在正式版上，关键的挖掘部件我们改动了很多版本，每一次都尽力让外形设计贴合场地实况。
• 对比很多组混乱的电控系统，我们在电控完工之后的第一件事就是集成和理线。事实证明，很多被淘汰的组别都是因为电控太混乱，上场以后就失控了；拿下来检查才发现是某处的线掉了。
• 整台机械在初赛、复赛和决赛的赛程中可能会有变动，我们因此尽量把电控做得模块化，给后面的调整留好所有接口。这使得我们在复赛前的调整非常轻松。
• 在遥控的设计上，我尽力把操作做得人性化。大部分控制键用的是简单且易于理解的设计语言；少部分重要但不能随意用的功能，用复杂的组合键防止误操作；部分耗费操作员精力的动作直接自动化，并且仍然力求在舒适的操作手感和精细的控制能力之间寻求平衡。

最后的结果是，我们的机械本身运行很稳定，遥控和电控也没有发生故障。
但我们还是输了。
赛后我们想了很久，其实我们这次做得很 engineering，输得也很 engineering。比赛前我室友开玩笑般立下 flag：

我觉得我们很稳，除非……你知道，最坚固的城墙，永远是从内部倒塌的。

他这句话已经成功预言（导致？）了我们 OM 的失败，我怎么也没想到，又预言了机械赛的崩盘。当他这么说的时候，他是想叫我多注意电控的稳定，不要发生上场以后控制出问题的情况。我们当然都这么觉得，所以在电控上花了大工夫。然而真正导致崩盘的却是一个很小的问题：我们的机械底盘不够高。于是它在操作时，有两次满载物块地卡在了我方场地里的一个可互动的道具上。根据规则，我们只能把装载的物块全部倒掉，然后请场务帮忙移动机械本身。于是我们挖了三倍于对方的分数 ，却只有三分之一进了我们的得分区。这么说来，打败我们的，还真是我们自己。
从 engineering 的角度来说，这大约可以叫系统性错误。整个系统，作为系统是完好的，怎么测都不会有故障；但在与外界互动时，系统却遇到了设计时未曾考虑的问题。我们在实地测试的时候，考虑了各种机动性问题，包括陷在沙子里出不来的情况。正是因为我们改造时考虑过这类情况，所以才会觉得底盘已经足够高了，完全不会受干扰。结果最后引起故障的因素是我们在测试时完全没考虑过的己方道具，这个道具是一个「地雷」，对方的机械碰到是会罚时的。但因为我方可以随意触碰它，我们完全忽略了这玩意对操作带来的影响。
总结这堆乱七八糟的失败，从某种程度上是一种自我安慰：虽然我们输得非常不甘，但失败总算教会了我们一点东西。这种自我安慰究竟有几分是有意义的仍待商榷，不过这句话我算是不可能忘记了：

最坚固的城墙，永远是从内部倒塌的。

致这个失败的春天。还有，我恨石楠。