浙江省第九届大学生机器人竞赛 – 切比雪夫探索队赛后总结

备战两个月、熬夜两周、通宵两天、上场两分钟😭😭😭

撰写时间：2025.5.26

请允许我将赛后分析part从末尾提到开头来撰写。

对赛后分析不跟兴趣的可以直接跳转结构与代码分析部分

---

0. 赛后总结：

切记！切记！切记！
千万不要赛前改结构！
千万不要赛前改结构！
千万不要赛前改结构！

0.1 失利的直接分析

0.1.1 关于小车

在比赛开始前，我们的小车有一个比较严重的结构性问题其实一直没有很好的进行解决：我们的小车的车轮使用的是胶轮，并且是直接暴露在外侧，同时由于我们分离结构的设置，导致我们很难在车轮上加装保护罩。这样一来，车轮在比赛过程中就会极易骑到圆环上面，导致小车循迹丢失，甚至圆环卡在车底，导致小车无法继续前进。
对此，在比赛前一天晚上，我们临时更改了小车的发车朝向，决定倒车启动，再调头前进。这样，我们就可以在小车的前轮上添加挡板。

但是，这又引发了另一个问题：我们小车的后方是有一个较高的收纳槽的，这样，收纳槽就会阻挡我们的齿轮齿条，使得发车失败。
对此，我们进一步缩短了收纳槽的高度，并且抬高了分离板。此时，似乎一切问题都解决了。
那一晚，我们也测试了倒车出发的循迹、倒车的分离，以及倒车的收纳等一系列操作，均没有问题。

但是到了第二天早上，车辆一启动，发现循迹出现问题，无论如何调整都无法解决。当时时间只剩半个点，没办法，只能重新将小车的发车朝向改为正向发车，并拆除挡板。
但此时，前面的操作埋下了一个很严重的伏笔：由于为了适应倒置发车，我们的分离板高度被抬高了，这样一来反而会影响小车的正向分离，导致分离失败翻车。

当然，也有可能是回滚代码时，修改了发车的朝向，但是又忘记修改了发车的代码，导致逆向出发，直接翻车。但是已经无法考证了。

但此时，如果一切正常的话，还是有补救方法的：直接启动小车也是可以正常发车的。只不过非常的离谱，电机线掉了，导致小车轮子运动异常。更严重的是，我们旋紧电机线的螺丝位置位于收纳槽的下方，这样一来，收纳槽就会阻挡我们旋紧螺丝，导致短时间内无法旋紧。

至此，小车的问题已经无法解决了。

0.1.2 关于大车

其实大车本身没有什么太多的问题，但是，大车的循迹一直是一个非常迷惑的问题。在实验室测试时，其实循迹都是非常稳定的，但是当来到比赛场地时，无论是在测试场地还是正式场地，都会出现循迹不稳定的问题。
但是当读取循迹的返回值时，又会发现一切都是正常的，非常的诡异。后来我们降低了循迹的高度，这似乎有用！因为当时测试时，我们更改后确实有了所改善，但是在正式比赛时，依然出现了循迹不稳定的问题。
那能怎么办呢？¯\_(ツ)_/¯

其实最终筛选的分界线是四分，如果我们大车能跑正，那也能进入小组赛，但是没有如果了，毕竟这也是这场比赛非常重要的考察指标，不是吗？
补充，AMT1450的循迹内部似乎有一个纠正偏差的功能：由于它是光电传感器，所以它的ADC读取到过大或者过小的值会被判断为错误，也不知道这个有没有影响。

0.2 失利的间接分析

实话讲，这次比赛看下来，绝大多数的队伍其实策略结构都很一般、并且行动迟缓。但是简单也有简单的好处，调试方便、构建方便。并且使用同往常一般的结构，哪需要费这么长的时间去设计构想？
此外，这次的得分分数线也低，并且许多队伍的重点都放在了“阻碍”上，其实我们也不需要特意去强求大车需要机械臂抓取。那这么以来，其实大车可以直接上面做为一个平台而不是开槽，然后小车直接从平台出发即可，这也会使得我们的分离变的异常简单。
其实我们可以进一步简化我们的结构，没必要说使用如此“贪心”渴求更高的分数。

此外，由于我们脑洞打开，我们其实也是花费了很大的时间在方案的筛选和实践上，这其实也间接导致我们在更复杂的结构上花费了更多的少的时间来调试，确实难评。
并且，我们也尝试探索了使用视觉和点激光的方案，虽然最终没有用上，如果但从这轮比赛的结果角度来分析，那就是纯纯的浪费时间。

但实话讲，我觉得这不能算作浪费，总得有人付出点什么，换取团队的进步，总得有人亏欠点什么，换取社团的发展，只是刚好轮到了咱们头上罢了。

不管啦，接下来进入正文吧

---

1. 结构分析：

我们特殊的结构设计全在大车上，主要是为了提升大车的运载能力。

1.1 设计初衷

由于观察到，普遍的队伍都使用了机械臂抓取的方式来进行分离和收纳，使用推车或铲车的队伍也只能收集一路的物块与圆环。
对此，我们想要设计一种结构，能够让大车在一次行进过程中收集两路的物块与圆环，并且能够在大车上进行分离和收纳。

1.2 早期结构

1.2.1 两路收集结构

最早我们提出过伸出挡板等方案，用来在大车沿着一路运动的时候，能够将另一路的物块与圆环拨到大车上来。示意图如下：

但是这一版有个问题，挡板的装置要比较长，且收纳物块和挡板也需要空间，此时你的循迹传感器会缺少一个合适的位置来放置。（如果你循迹放在大车的后方，那很显然，循迹就很容易不稳定，调整会很是困难，可以参看这一篇博客）

1.2.2 分拣结构

由于根据我们规划的路径，大车在路途中，会依次路过两个物块、两个圆环、两个圆环、两个物块。对此，我们就要提出一个分拣结构，能够在大车行进过程中，将物块和圆环分拣开来。方便我们大车能够既满足1分区收集物块，又满足2分区收集圆环的要求。
下图是我们最早的分拣结构设计方案，用来卡住圆环。

但此时，其实还没有解决如何将物块和圆环分拣开来。但此时我们发现一个特性，物块的高度比圆环高很多，并且我们使用橡皮筋进行尝试，发现可以将物块勾起来并翻越圆环与传感器槽。故此，我们一开始是打算使用齿轮组与拨杆，将物块拨起并翻越圆环与传感器槽。但是话说过于复杂，最终吹了。

不过为此我们买了不少乐高积木，你们也可以闲着没事用这些东西验证验证自己的各种奇思妙想

1.3 迭代结构

这主要是当时的一瞬灵光，通常我们都是保持车身稳定，移动拨杆来收集第二路物块，但其实仔细一想，总会觉得边路的移动时间更长，并且本路的很多空间也是浪费的。再仔细一想，循迹循迹，是谁在循迹？是车身在循迹啊！是循迹！是循迹维持不动！那这么一来，不如我们维持循迹不变，移动车身来收集第二路物块，这样一来，两路的物块都可以收集到，并且空间、时间都可以有比较充分的利用！
对此，我们设计了如下的结构：

这个方案确实非常的好，但是这有一个很大的问题：臂太长了。这会导致末端（在此处即传感器所在位置）会非常的抖，且容易下坠，导致循迹异常不稳定。

1.4 最终结构

最终，我们选择使用步进电机+齿轮齿条+CNC底板的组合来实现最终结构。这样一来，整个系统的稳定性大大提升，并且由于步进电机的精度较高，我们甚至还可以拓展，使用步进电机移动传感器位置，实现自动寻找循迹线。
其中挡板的部分留了两条曲线，用来给螺丝、螺柱留出地方，当齿条移动时，挡板也会跟着移动，但由于螺丝螺柱的存在，挡板会自动张开；当收回的时候，挡板会自动闭合。这样一来，挡板就可以在大车行进过程中自动张开和闭合了。

实话说，这个结构非常的精准且高效，但是问题在于，使用实验室3d打印的方案，打印出来的齿条和齿轮的精度并不高，容易啮合不好。并且3d打印件的强度也不够，容易断裂，尤其是齿轮。

1.5 其它结构分享

这里是分享一下我们在设计过程中想到的有趣并且应该是可行的方案，供大家参考。

呜呜，其中有些结构我当时就像尝试的，但是被队友打回了

1.5.1 高速滚筒方案

起因是看到以前的视频，似乎有一队可以在行进过程中，将本来处在底下的圆环，运输到车辆的顶部。这个想法非常nice啊！所以我就想了如下结构

知道棘轮吗？当旋转速度够快的时候，这个特殊滚筒会甩出来4个钩子，钩住圆环，然后在行进过程中将圆环运输到顶部。我这里就是参照了这么个想法。并且这种不是一直伸出来的钩子也不需要担心圆环卡住的问题。

不过这个方案实际打印了一个效果有点不太理想，可能是尺寸原因吧，还有待验证。

1.5.2 全局定位方案

区别于上面只是一个零部件，这里更像是一个整体的方案。这个方案的核心是分离出一辆占地面积非常小的小车，在启动后移动到场地的角落，充当一个稳定的信号塔。然后其余分离的车辆可以通过这个信号塔来进行全局定位。
或许是激光、或许是热成像、或许是视觉，甚至是无线电波。总之，这个小车可以充当一个信号塔，收集敌我双方的相关信息，并且将信息传递给其余车辆。

---

2. ucos 移植到 hal库

此处不多赘述，引用你们gxd学长的博客。
不过他的博客中没有详细的提及官网工程模板的下载过程，在此简单提一下。

2.1 什么是ucos

UCOSII（μC/OS-II）是由Micrium公司提供的一款源代码开放、可移植、可固化、可裁剪的抢占式多任务实时内核。它是一个实时操作系统（RTOS），旨在为嵌入式系统提供多任务处理能力。UCOSII支持多线程、任务间通信、时间管理等功能，适用于需要实时响应的应用场景。

2.2 文件下载简单介绍

具体文件下载

进入官网，按照如下图依次操作即可寻得。

2.3 使用补充

对于循迹，这是我个人的观察结果：使用操作系统后，读取传感器的速度会变慢，导致循迹的响应速度变慢。这对应的就是原来使用的 pid 参数需要重新调整。

相应速度变慢的后果，直观一点：
假设每次读取的间隔是小于 1ms，此时实际可能每次读取之间会偏差 1mm，那么当套用操作系统，并配置系统时钟为 1ms时，那很显然读取的间隔就拉大了，那么你的偏移量就会变大，导致循迹开始摆动。这个时候我直观的感觉，你的pid是应该要变小的。

---

3. K230 视觉方案

关于图片标注使用的软件，我们选择了Labelme
由于此处代码文字比较多，所以单独开了一个博客来进行详细的介绍。点击这里即可跳转。

---

4. 机械臂解算与步进电机控制

参考你们gxd学长的博客，链接如下：
– 机械臂结算
– 步进电机控制

5. 点激光配置

以下内容感谢zjc学长的撰写

在我们的代码中，已经配置好了点激光（STP23L）的代码，其实都是原来的学长配置好的，想用的话只管调用即可，这里我就讲讲配置的整个过程。去年我们使用的是万向轮，使用四个点激光用来定位，对应代码中uart1、3、5、6接受数据，由于数据量较大，因此使用DMA来进行数据传输。因此cubemx配置时加上DMA接受中断，接受方向为外设到寄存器，波特率230400，这个跟硬件本身有关，其他设置没什么特别的。接着在uart初始化的函数中加入HAL_UART_Receive_DMA(&huart3,Uart3_Receive_buf,195);用以将串口接受到的数据存储到Uart3_Receive_buf当中，对DMA的原理，不做过多介绍（主要自己用的也不是很熟，每次忘了都要重新看一遍，网上博客一大堆都有教的，还是自己看吧）。

接着在接受中断的回调函数中，调用get_data这个函数，这个函数是照搬官方给的案例。

最后点激光获得的距离，存储在下面四个变量中。直接对这四个变量进行使用即可。

接下来讲一下在使用点激光遇到的一些问题，首先是我们可以看到接受的数据量较大，这些数据处理起来是很费时的，众所周知，中断中不应处理特别复杂的函数，因此在实际使用中，发现在使用上点激光后，循迹会出现问题。我们组的解决方法是，在中断回调函数中，设置一个变量作为标志位，接受完成标志位置1。

紧接着，由于我们使用了ucos操作系统，在新建的task中判断标志位并进行数据处理，在进行如上操作后，循迹模块与点激光就不冲突了。（但实际上也不一定要操作系统，任务并行，直接在main中的while进行判断标志位也是一样的）。

然后就是怎么合理的使用点激光（虽然我觉得点激光一点都不好用，可能是我太菜了，没搞明白咋用，但还是说说个人的理解），向我们这次并没有使用万向轮，因此用点激光来完全脱离循迹全图跑就不现实了，我的想法是可以用点激光来矫正，因为垂线段最短，所以在小车自旋转的过程中，点激光检测到的值最小，即矫正成功。但是实际跑的时候，成功是成功了，就是不够正，这就跟点激光精度啊，单片机的处理速度有关了，既然矫正不够正，那就完全失去了最初的意义了，所以也没用上。
还有感觉可行的方案是，可以判断自身小车是否卡住了，即判断点激光的值，如果长时间没有变化，那么就认定为卡住了。这个方法也是可行的，我们也是成功了的。
综上，点激光还是有很多用法等待去探索的，不过就是搭配万向轮更佳了（但是万向轮又会出现摩擦太小，不稳定的缺点）。

6. 配件&机器人展示

6.1 配件展示

6.2 整车展示

6.3 未使用到场上的视觉part展示

7. 结语 & 祝福

致切比雪夫探索队的战友们：
这两个月的汗水、凌晨三点的实验室、反复推翻的方案、最后一刻的挣扎，或许没能换来理想的奖杯，但换来了比奖杯更珍贵的东西——那些“如果当初”的反思、那些“原来如此”的顿悟、那些“还能这样”的脑洞，都成了我们独有的勋章。这次失利不是终点，而是社团技术迭代的起点——我们的齿轮齿条结构、视觉方案探索、ucos移植经验，都会成为下一届学弟学妹的垫脚石。

致未来的参赛者：
请大胆拆解这篇总结里的每一个“坑”和“火花”：

• 胶轮暴露的隐患、结构复杂度的权衡、传感器稳定性的玄学…

• 但更要看到那些“差点成功”的闪光点：两路收集的巧思、步进电机的精准控制、视觉方案的潜力…
  记住：机器人竞赛从来不是“完美方案”的比拼，而是“快速试错”的较量。愿你们能站在我们的肩膀上，少走弯路，多闯新路——哪怕最终依然跌倒，也要跌出更精彩的姿势！

最后，用一句切比雪夫多项式拟合出的祝福：
愿你们的努力永不收敛于遗憾，
愿你们的好奇心始终发散向星辰！
🚀 切比雪夫永不认输，我们赛场再见！

—— 2025.5.26 切比雪夫探索队全体

_{（小声摊牌：其实这里是AI写的，我可写不出这么肉麻的话…）}