=====Day 3=====
<font size='1' color='brown'>loading......</font>
<font face = "kaiti">
<!--此处为日后写正文的位置-->今天的内容为完成自编舞蹈，根据要求我们大概需要编一段一分半左右的舞蹈连续表演两次，总时间大概三分钟。不得不说，根据昨天编写一个动作调试半个多小时的节奏来说，一天三个小时的时间可能只能写出十几秒钟的内容，但是既然老师下了这样的要求，那就说明一定是有完成的办法的，否则这个任务就没有意义。抱着这样的心态，我想到了前天安装软件时U盘里附带的那部分基础动作，比如我们昨天完成的俯卧撑时也参考了官方给出的动作，如果这些动作库里的东西作为舞蹈的一部分，那么在断时间内完成舞蹈动作的编写就不是不可能了。 我依然选用的昨天已经定好的《小苹果》作为BGM，开始进行“舞蹈排练”。尽管库里已经给出了一些动作，但是这些是零散、单纯的动作，它们的节律、时长与某首具体的音乐并不相符，某些参数也与我的机器人有所差异（舵机零点不同），因此我需要调整动作、改变间隔、增减关键帧，使得这些动作与《小苹果》的节奏基本一致，当然我也深知自己没有什么音乐天赋，机器人的舞蹈可能看上去没什么美感，但我尽可能做到我的动作与音乐歌词的分句相符，我在写程序时用注释标明了歌词、时间、动作，以便在连贯排练时能够更好的反馈出节奏问题所在。为此，我将翻滚、拥抱、欢呼等动作库里的东西以及自己写的原地踏步、抱苹果、伸手等动作进行结合，经过反复调试调整节奏，使得最终能有一套连贯的动作和音乐基本契合。 在我自己调整动作时，我也注意观察了下动作库里给出的动作，因为这些动作可能都经过多次演练、不断升级而成，我相信我从中一定能有所收获。果然，在逐步调试每一帧后，我发现这些动作特点非常鲜明：这些东西的关键帧非常多，并且频繁切换速度，达到了动作的连贯性以及近人性，尤其是将动作分解得更为细微后，可以让本来一帧也可以做到的动作用三四帧来分解，出现明显的加速减速过程，这样使得动作更为稳定。反观我自己写的动作，虽然经过数次角度调整后基本能做到连贯不摔倒，但是每个动作飞速完成后机器人往往会全身一颤，让人看上去就觉得动作很悬，这大概就是因为速度和帧数没有做到位的缘故。 最终的比赛是一场遥控足球赛，今天已经开始铺设场地，并且让我们上场试了试，我用一个简单的踢球动作进行踢球尝试，不料一脚踢出球沿斜线滚走不说，机器人自己还往前摔倒了，这表明原来的动作平衡性还是有所不足，看似已经完成了踢球动作，但实际上最终一脚踢出后自己重心却没有落实，这样的动作无法面对最终的比赛，在接下来的日子里我需要重写踢球动作，使得机器人踢球后仍能移动到目标位置，达到“亢龙有悔”的神效。
</font>
----
=====Day 4=====
<font size='1' color='brown'>loading......</font>===Day 4=====
<font face = "kaiti">
<!--此处为日后写正文的位置--今天我们先给了一小段时间编写踢球的动作，然后讲解了教育版的用法以及传感器的使用。 我们组内进行分工后，我负责的是试图写出一个右前快走和左前快走，希望机器人在这个状态下可以走出一个近似的圆形轨迹，以求在球场上达到很好的拐弯效果。为了做出这个效果，我在原有的向前快走的基础上进行调试，主要调整行走时的脚步动作来达到收脚后朝向改变的效果。仔细观察自带的拐弯动作，可以发现这些拐弯主要还是出脚时控制好脚的方向，真正拐弯发生在最后收脚的时候。循着这个思路，我试图先写出一个左前行进的动作，我将快走时机器人的脚踝处舵机和大腿处舵机进行细致调整。 这个过程并不容易，主要是自带的快走动作如果逐帧调试，会发现这些动作并不都是平衡动作，换言之我在调试动作库里的快走时机器人会失去重心摔倒。但是可以注意到，库里的动作调节速度是很频繁的，并且某些动作试图把速度调到100，通过速度来弥补临时的重心不稳。这样做对于调试来说负担很大，但是在行进时看上去并没有什么问题。经过无数次调节，我终于调好了一个看上去没有问题的左前快走，并且在地面上进行测试，然后尴尬的一幕发生了：下达左前快走指令后，机器人没有像我想象的那样向左前画个逆时针方向的圆，而是向右前画了个顺时针的圆！并且在一次循环后机器人的偏转角度基本是理想的45°，所以我顺势把这个原计划的左前快走改名为右前快走。在做完这个事情后，我试图把程序中的A和B反转、C和D反转使得舵机角度左右对称过来，希望通过这样的方式直接完成左前快走，然而果然如同第一节课上老师所说那样，不同舵机零点不同，动作移植可能需要全部重新调参：右前快走的参数转移到左前快走后，机器人不但直行不拐弯，而且收脚时直接摔了一跤。 很快到了讲教育版软件的时候，和我第一天的印象一样，这是一个框图控制的程序，但是从授课内容中，我知道了更多之前没有注意到的细节，比如遥控器的调用方式等。操作方面我们完成的主要工作是对某几个传感器的使用，包括最初用地磁传感器来完成机器人定向移动、用火焰传感器和风扇完成自动灭火的动作。在这个过程中，我注意到这个程序所暴露出的一个不足之处：判断句语法似乎有所缺陷。比如之前就注意到的FOR只能给出具体数字，但今天看见的更麻烦的问题是IF的判断不能在判断符号右边写表达式。比如以下就是软件支持的和不支持的语法例子： //以下为支持语法 INT A A = 3 IF A >3 THEN //条件体 ENDIF //以下为不支持语法 INT A A = 3 INT B B = 2 IF A > 3 + B THEN //条件体 ENDIF 好消息是我发现教育版是可以不理会框图，直接对代码框进行编辑的！这就意味着教育版几乎可以当作专业版使用——除了不支持GOTO语句。这样做的后果是代码将无法通过软件的文件保存，但是可以自己另行写文档进行保存，每次烧程序时再将代码复制到代码框里，这样一来几乎就是C一般的码代码了，并且和专业版一样是支持函数式编程的，用JUMP可以调用不同的函数。这个软件不支持定义数组，并且变量只支持整型，但是对这个机器人的编程来说完全足够了。我想，通过灵活的程序编写，在最终的足球赛中我们可能能在软件层面取得一定的优势。
</font>
----
=====Day 5=====
<font size='1' color='brown'>loading......</font>===Day 5=====
<font face = "kaiti">
今天开始全力投入足球动作编写当中。能够供我们使用的按键一共就那12个，大家可能都比较容易相当一些基础动作，但是想要取胜，在自认遥控技术不高的情况下，就必须从软件层面取得一定的优势。我认为，想要在软件上更胜一筹，可以考虑采用即时打断的连招方式。 首先，我们已经确定要写出可以沿圆形轨迹行走的“左前快走”“右前快走”，为了使得动作连贯性更强，我们选择用打断时操作，即按下对应按键后，机器人将会在一个循环里反复执行这个操作，直到接收到特定指令才会停止。最容易想到的办法就是写一个死循环，然后需要停止的时候按一下'''back'''强行让机器人恢复站立姿态。但是，这个办法绝不是一个好办法，至少不会是最佳办法，因为按下'''back'''后机器人会将速度调为一个极低的速度然后恢复站立姿态，这在紧张高节奏的足球赛中效率是非常低的。为此，我想到的一个办法是在这样的转弯快走状态下再按下转弯快走的键，让机器人收到指令后跳出循环，执行正常的快走收尾动作。然而这样做遇到的问题是程序中并没有'''BREAK'''指令，这对我们写程序造成了不小的麻烦。所幸，我昨天已经注意到，在教育版里是可以直接写代码的，采用函数式编程的话我可以将收尾动作独立写一个函数，然后在拐弯快走的动作里写一个死循环，再在接收到相应指令后跳转到收尾函数，这样就解决了这个问题。 但是采用这个方法实际上还不是最佳选择，我可以想到更好的设计，比如机器人右前方一定距离处是足球，我希望机器人可以右前快走跑过去然后顺势一脚踢出，这样的场面连贯高效，并且也和人们印象中的踢球场景非常相像。除了我举的这个例子之外，还有很多可以形成“连招”的例子，事实上我们能够想到非常非常多的踢球动作，但是只有12个按键，所以不可能一个动作对应一个按键（事实上，就算只是12个按键，要记下每个动作和按键的对应也不容易），为此我们可能需要采用很多游戏里的连招模式，比如先按“左前快走”，然后在机器人跑动的时候按下“左踢”，达到无缝衔接，机器人借着奔跑的架势和重心直接一脚踢出。但是要做到这一点并不容易，首先从编程实现难度来说，为了追求高效率，我们可能需要在任意两个动作之间都插入一个衔接动作来达到二连的效果，因为这个很难做到一个好的归一化处理。（更多内容此处暂且不提，毕竟wiki这东西双方都能看见嘛） 今天补充一点昨天的内容，昨天我注意到这个软件对于某些语法支持性很不好，但是今天我注意到如果我们将语法稍微改改其实就OK了，比如说以下两种情况： <!--此处为日后写正文的位置--nowiki>//以下为不合法语法INT AA = 120INT BB = ID 5IF A < B + 20 THEN//条件体ENDIF //以下为合法语法INT AA=120INT BB = ID 5INT CC = B + 20IF A < C THEN//条件体ENDIF</nowiki>换言之，我只需要提前先把所需计算算完再写条件，就可以解决昨天我提出的问题，FOR循环同理。 在对这些语法近一步了解后，我更加确定教育版的代码框支持一套完全的逻辑体系，我今天开始写架构，为最后的足球赛动作整合做好了准备，并且准备好了一份代码规范以便队友合作开发，另外由于教育版代码框的代码无法保存，我们统一用notepad++进行编程，为此我写了一份针对这个程序代码的语言格式，效果如下图：[[文件:Aelos_xml.png|none|400x450px]]这些内容我准备比赛结束后上传到GitLab。
</font>
----
=====Day 6=====
<font size='1' color='brown'>loading......</font>===Day 6=====
<font face = "kaiti">
明天就要开始试炼了，今天无疑是调整动作、做好一系列准备工作的最后机会了，已经到了临阵磨枪的时候，如果不把所有BUG解决掉，那么明天场上程序崩溃的话，无疑会对后天的比赛造成无穷大的压力。但不幸的是，在我不断的调试中，发现这款软件存在的BUG超出我的想象。 采用函数式编程，本身是比较容易的，逻辑简单，遇到需要分支的情况直接跳转即可，并且我上星期已经将这个程序支持的语法基本摸透了，一套完备的逻辑系统也有了，也就是说，目前除了缺乏一些常见的语法糖，函数没有办法传入参数之外，其他基本可以做到C语言早期能做到的事情。基于这样的机制，要做到动作之间的无缝衔接、强行打断、圆润过渡等是非常容易的。然而我今天突然发现，在一个函数中插入IF条件时，会发生奇怪的BUG，这种BUG的触发条件尚不明确，我的测试情况都是在某动作函数的FOR循环中加入了读取遥控器后根据遥控器的值进行跳转的JUMP函数，但是在我没有按下遥控器的时候它也会进行跳转。 为此，我不断控制变量进行DEBUG，最终发现一个残酷的事实：我只要在这种情况系加入一个IF句，就会出现BUG！也就是说，哪怕我只是写了如下的代码： <!--此处为日后写正文的位置--nowiki>IF 1==0 THENENDIF</nowiki>这样的代码在正常的编译器中会直接被优化掉，永远不会执行，可是在这个软件之下却会出现随机跳转，莫名其妙随机执行某个函数，完全无法使用。这个机器人底层是一个STM32F103系列的单片机，这块板不至于产生性能障碍导致不支持我所写的内容，并且我看了下生成的用于STM32运行的hex文件也不过五六KB而已。那么，排除掉硬件性能本身的问题之外，剩下的就只能是IDE本身的缺陷，将一些伪代码翻译为C代码时出现了BUG。当然有这样的BUG并不奇怪，毕竟我用的是教育版软件强行当专业版用，在这个版本里直接写代码可能算是开发者没有意料到的一个feature，因为本身这个软件是将框图转化为代码，而这个过程是用单函数写的，自然也就不会产生各种奇奇怪怪的问题。但是单函数写出来的效果和直接用简化版没有什么区别，我们实际上需要的依然是一个能支持突变式跳转的架构，那么在这个方法行不通的情况下这个想法只能被迫放弃。 不得不说，经过一周摸索，基本弄清了这个伪代码的函数式写法后，最终发现它内在BUG导致我的架构无法实现，这个结局是很让人沮丧的。但是，学了一年C/C++后，这是我首次面临这种情况，拿着一款软件的伪代码不断摸索语法、试图用C的思路写出更为复杂的代码、自行规定代码风格、写出简单的框架，这样的一个经历是让人难忘的，并且对于我加深对不同语言代码的理解有着重要的意义。 最后的时间我们将一些动作进行了微调，因为最初版本的动作在跨机器人后由于参数导致了失衡，为此我花了很长时间将一些动作进行优化，以及不必要的DELAY进行删除或缩短。其中花费时间最长的右踢和左踢，这两个动作是对称的用力射门动作，但是我的左踢有着从一个球门踢到另一个球门的优良效果，可是右踢却会在踢出去后摔倒。我不断调试最终优化了右踢，但也只是在摔倒方面优化了，射程却是减小了将近1/3。我想，射程和脚踢出时与地面的最近距离可能有很大关系，或者更确切地说，和踢球瞬间时脚的高度有关，而踢球脚的高度和整个从后往前的踢的过程中脚的最低高度是正相关的。原来摔倒是因为脚最低高度太低，狠狠地踢到了地面上导致摔倒，现在则太高，踢球时脚完全不擦地，所以无力，那么明天我的改进空间将在把脚的最低高度设成一个轻微擦地的程度，这样可能就能够在平衡性和射程之间找到一个好的平衡点。
</font>
----
=====Day 7=====
<font size='1' color='brown'>loading......</font>===Day 7=====
<font face = "kaiti">
<!--此处为日后写正文的位置-->因为时间的调整的缘故，原定在明天的比赛调整到了今天，明天早上只有15分钟的表演赛时间，因此今天下午我们就要进行最终比赛。 今天下午仍然是匆忙的调试，昨天发现函数里的IF会导致BUG后，我删掉了那一系列的判断句，将函数作为单纯的遥控指令动作，也就是说我实现的功能与简化版没有区别。但我发现，在教育版下用函数编程写出来的有一个绝对的优势:它可以在单个动作的衔接之间进行强行跳转，比如DELAY的时候，或者ENDFOR的时候。比方说有一个动作连续右前快走五步，队友用这个动作时只有用'''back'''强行终止动作恢复站立姿势然后再做下一个东西，这个方法固然可行，但是其恢复动作时速度极慢，实际在球场上我认为效果并不好。而我所用的这个代码模式，自带有强行跳转动作的效果，执行右前快走时，我连续按别的按键，可以将动作直接跳转到别的动作上。正如我昨天所说的，这个软件有着非常多的BUG，包括这一个，我就无法理解这种跳转是怎么实现的，我在写程序的时候并没有写读取遥控器事件的代码，理论上不可能成功的，可实际上它就是发生了动作跳转，这意味着这个软件把伪码翻译成C时仍然有着我想象不到的漏洞。 所为有失必有得，有得必有失，删掉了所有的IF后我发现这个特性，本来很开心，以为终于找到了直接写代码的一个优势，不料这个本来意义重大的优势很快被另一个BUG覆盖了——在我强行跳转后，机器人出现了我无法理解的行为，经常执行一些奇怪的动作组合，比如说我只发送了一个右踢指令，然后关上了遥控器，但是机器人会在右踢结束后进行一系列的动作，包括右前快走、左铲、前倒地起身等，完全处于失控状态。虽说这时候也可以用'''back'''法恢复，但是真正到了赛场上每次执行任务都用back终究不是一个好的选择。无奈之下，我只能放弃这个满是BUG的函数式编程模式，选择直接用简 化版进行原始的操控模式。当然，少了原计划的强行跳转，也只是让我的程序不能像之前那样灵活，这让我少了一个相对优势，但是也不至于落得太惨的地步，终究把人物回归到了动作细节调整上面。 昨天我在写wiki时想到，如果把右踢动作脚的最低点调低或许会使得这一踢更为有力，今天我进行了尝试，发现我的猜想基本正确，这样的调整确实有着很明显的效果。但是出于之前摔倒的恐惧，我也不敢像左踢那样擦地而行，最终仍然与地面保持了一定距离，腾空踢出，比昨天的射程大了一些，但是仍然比不上左踢。我到球场上试验了一下，总的来说能够满足基本的传球动作——尽管我很怀疑我对这个机器人的掌握能否称作“传球”，感觉更像是一个简单的把球踢走。除此之外我将左铲等动作进行优化，修改了速度和延时，使得相关的动作更为迅速，不过也只是微调，看上去效果不是很明显。 今天下午最终我们进行了3V3的足球赛，但是场面一度十分混乱，场地小而机器人大，实际上大家挤到一起，最终对方进了乌龙球，我们也进了普通球，但是场面过于混乱，且踢球逐渐演变为想办法让对手出界回不来，我们总是处于以多欺少的状态，也不知道老师会怎么算最终结果。
</font>
----
=====Day 8=====
<font size='1' color='brown'>loading......</font>===Day 8=====
<font face = "kaiti">
<!--此处为日后写正文的位置-->今天早上来了不少观众，我们开始了表演赛。所幸，今天的比赛不像昨天那么乌龙，大家的操作都明显娴熟了很多，昨天总提示tf卡丢失那位同学也初步解决了问题。 上半场的3V3比赛当中，我成功趁着混乱踢出一脚，进了一个球，但是从那之后就再也没有见到别的球了。不过比赛仍然十分激情，双方在场上不再是像昨天下午那样一拥而上相互试图把对方摔出去，而是千方百计试图进球，因此也不乏出现了一些传球、截球、守门的激情时候，当然迫于一些实际问题球还是一到角落就会死球，但是相对而言对于一个没有踢到底的球我们仍然有机会把它救活，使得比赛可以继续。 在这个过程中大家的操作水平越来越高，最初想出了在赛场边缘用前倒地起身把对手的机器人摔出去的方法，今天在场上我面对被人摔倒后三次卡着边缘把机器人救回来了。本来大家都以为被完全摔出去的机器人注定要离场，但是今天场上又见到了机器人被摔出去后成功从外侧翻进来的操作，让大家大开眼界。但是，堪称MVP的操作还是在最后下半场比赛基本结束的时候，当时是2V2，对方一个机器人被摔出场地，但是它仍然没有放弃，从场面不断干扰贴着边界的球，使得我无法进攻，我们陷入了焦灼。而此时支云峰控制的3号机器人拖住了对手一个机器人，在持续的摔倒过程中，对方突然惊叫一声："我的机器人怎么控制不了了？"这个时候比赛时间也刚好结束了，大家上去一看，发现它的开关竟然被关掉了。原来，在互摔过程中3号在后倒地起身动作挥手时，竟然把对手的开关给关掉了！这也堪称一绝了。 最终比赛定格在了1：0，相当有表演赛的风范，我们也开心地结束了这个小学期。
</font>
----
