简 介： 本文内容是在8月13日邮件接收到参加全国大学生智能车竞赛同学写来的一封邮件。其中对于公开的山东大学（威海）全向组提交的RT-Thread技术报告中所产生的若干疑点。针对于竞赛中所使用的沁恒单片机在RAM，CPU速度等方面的不足，作者质疑山东大学全向组报告中存在不实之处。

海韵三队同学很快针对提出的疑问进行了书面的回复，具体内容在本文的最后一节。
关键词： RTT，智能车竞赛，质疑，沁恒单片机

01 问题来源

  卓大大你好，这是我阅读您csdn上公布的获得rtt专项奖进入国赛的技术报告后，产生的一些疑问，篇幅问题我写成了word。如果确实有这个问题，希望卓大大能重视，如果是我自身因知识储备不足而产生的误解，希望卓大大乐一乐就好，不要在意。

  下面内容是来自于邮件中WORD文档内容：关于山东大学（威海）全向组海韵三队提交的 RT-Thread 技术报告中的若干疑点。

• 基于RT-Thread全向赛车控制算法开发^[1]

• 第十六届全国大学生智能汽车竞赛RT-Thread创新专项奖^[2]

02 若干疑点

一、关于RAM使用问题

  最明显的一点是RAM的使用情况。文中作者也承认图像处理线程sweep需要存储的数据非常多，却只为其设置了2KB的栈空间，这显然不正常，所以我对其RAM占用空间进行了分析。

  占用RAM的大头是图像数组。从总钻风传回的为灰度图像数组，根据作者提供的屏幕截图，通过初略估计列像素点（数像素点），再通过图像的长宽比例可以计算出图像数组约为100*75。

  我采用逐飞提供的沁恒单片机 RT 开源库，只修改图像数组大小与作者一致，无任何其他处理程序和变量声明，编译后得到的存储占用情况如下

  存入RAM里的包括data和bss的数据，即304 15976≈15.9KB，再加上作者分配的动态进程里的栈空间5.7KB，显然已经超过了单片机的20KBRAM空间。这还是在最保守的情况下估计的RAM占用空间，即图像显示与图像处理共用一个数组，而不是在二值化后重新开辟一个内存空间用来存二值化后的图像数组（CH32V103底层里的BOOL也被typedef成了unsigned char即最小的存储单位是一个字节）。

  而采用共用数组的方法时，会有一个明显的问题，就是在总钻风DMA传回数据时，会更改当前正在写入显示屏的这个数组，造成这个数组有几行是有乱七八糟条纹的。至于DMA的问题，后面还有疑问。

  综上所述，在作者不定义任何全局变量，仅有一些少的可怜的动态内存还缺乏进程间通讯传递变量的情况下，仅仅一个图像和栈空间分配就已经超出了单片机内存，作者是如何做到让小车正常运行不得而知。

二、摄像头采集问题

  作者贴出了总钻风的配置函数，从中可以看出摄像头的帧率是130，即7.8ms传回一帧图像不管单片机接不接收，而作者图像的处理时间显然大于这个间隔时间。

  在图像传回时这就可能有两种情况出现，即场中断优先级大于进程 和 小于进程。

1、场中断优先级大于进程优先级

  优先级大于进程时，场中断都得到响应，打开DMA通道让DMA硬件传输。DMA指向的地址就是上面说的可怜的被共用的显示和处理的图像数组，此时该数组会被从头一个个地更新，要是与此同时正跑着处理或者显示的进程（大多数情况下肯定是的，因为这两个进程优先级高且用时长），会造成显示错误或者处理错误。

2、场中断优先级小于进程优先级

  OK，另一种情况，优先级小于进程，则中断频频得不到响应，好不容易一次所有进程都挂起（太巧了），场中断得到了响应，打开DMA通道，同样面临上面的问题，且DMA中断的优先级如何？

• 小了甚至轮不到DMA中断触发，根本无从发出摄像头采集完成的信号。
• 大了你怎么保证场中断开启DMA通道的时机摄像头还没开始回传？

  大概率得到的是一帧错位的，不完整的，甚至根本就得不到一帧图像。

  在我调RTT的程序时，就出现了这样的问题，我调了很久最后采用摄像头两个中断优先级最高，疯狂降低帧率到30的方案才勉强协调了这个问题，也可能是我菜，不知道大佬是如何实现的？

  在我看来作者的方案是不现实的，除非去掉处理图像这个占用时间极多且优先级高的进程才有可能，那么这辆车还能运行吗？

三、单片机运行速度问题

  在该章（文章中第8章第3节）中，作者声称采用RTT系统减短了其图像处理的时间和获取图像的时间，这就很离谱了，在CPU没有超频，没有优化算法的情况下，为何采用了一个操作系统就让单片机运算速度加快了？

  我能在文中找到作者比较勉强的解释是：

从并发的角度来看，各个线程在使用delay ,  事件等待这类函数时， 会总动让出CPU给其他需要的线程。不仅书写 delay延时函数操的心少了，整个CPU的利用率也得到了提高，最终提升了并发性。

  这就很奇怪了，图像的处理中还需要延时吗？

  就算有延时，将图像处理进程挂起去执行其他进程，OK，CPU利用率确实得到了提高，但对图像处理这个进程来说，这个延时不是还在吗？？？

  处理完一帧图像的时间根本不会减少甚至会变长！（线程的挂起，调度，压栈出栈等等一切操作都是需要时间的）况且一般简单的算法处理，根本不需要多线程进行，多线程也不会带来效率的提升反而将问题复杂化。

变量 time 代表的是获取一副图像的时间。每获取一幅图像后发送一次数据给上位机，得到的结果如图俗称（纵轴的单位是）。可知RT-Thread操作系统下获取一幅摄像头图像的时间在1000即左右。

  更离奇的是，在采用RTT后，连图像的获取都得到了加速，上面讨论过，在操作系统的情况下要保证图像场中断以及DMA中断的实时性有多么困难，且图像是由摄像头发出的，传输的时间是由摄像头DMA传输的速度决定的，怎么会因为接收方换了个系统就变快了？所以作者根本就是在 无中生有，编造事实 。

03 质疑结论

  该篇论文的槽点简直数不胜数，让人不得不怀疑其真实性。

  我不是说山威的同学就一定写的假论文，可能只是因为我自身的无知，才会有这么多所谓的"疑点"。至少从论文中还是可以看出，作者是学过RTT的。

  我不是计算机专业的学生，这是我第一次使用单片机的操作系统。学习一个新的事物，在CH32V103上移植RTT也让我吃尽了苦头。但是直到现在，我还是坚持认为：在CH32V103这款单片机上像作者这样跑操作系统是不可能的。就算是可能，有些设计也是拍脑袋写出来的，不使用操作系统，可以做到更好。

  我的观点可能有些是错的，或者没有 GET 到山威技术报告的点，但这些都不是空穴来风，而是在我调RTT的过程中遇到过，考虑过的问题。相较于其他组别的单片机，沁恒的这款单片机显然在RTT的适用性上差了不少，也正因此需要投入更多的精力处理而不是滥竽充数。

  所以我希望能要求山威立刻（以防连夜改出来）公开其软件工程，接收全国车友的监督。一旦程序被证实是假的，或者给不出来，取消其资格，并且追究其论文造假的责任。

  但我知道这个诉求大概率不会得到实现，这件事也大概率不了了之，毕竟 RTT的名单是RTT公司给出^[3] 的，可能查阅的专家因为不太了解比赛而以一些其他原因将其评出，组委会也多一件事不如少一件事得过且过。

  怎么说呢，作为一个非利益相关者，山威进不进国赛对我也没什么影响，但既然卓大大公布出来了，我看到了也不吐不快，希望能促成这个比赛往更好的方向发展，能少一些不公平不公正的现象发生。

04 回复质疑

  我是海韵三队的软件队员。现在回复CSDN上对我们队的质疑。

一、回应关于RAM使用问题

  质疑者对我们图像数组长宽比例的判断直接目测估计100*75这一点未免也太不严谨了，我们真实使用的是80*60的数组，差出来的这些空间能放多少全局不量我就不说了。

  当时我们还开了os优化这一点非常重要，没有在论文里提到。没开优化的话肯定是超出这个芯片的RAM及FLASH大小了，因为没有对os能优化多少空间有研究就不给出计算了。

  最后所有程序编译一遍是刚好卡在超出大小边缘了，以下是我刚刚编译的结果而且并没有临时修改什么代码的，RTT公司的人员应该有我们的源程序可以让他们编译一遍。

  至于说公开源程序的话我是觉得不太合适的，如果要公开那也应该公开所有通过RTT进国赛的人。如果要复现也应该是所有人进行复现。我也看了其他人写的RTT论文，说实话写的也非常优秀，但并不是所有人都对RTT的使用部分做了详细说明，我们也是第一次研究RTT所以某些地方可能写得不是那么严谨，当时忙着交RTT论文也并没有对所有贴上去的图片进行检查。

二、回应摄像头采集问题

  我坦白一点，可能是对RAM的分配还不怎么合理，所以小车在发10 次车还是会出现1次的死机现象，可能是因为内存爆了吧。但是出现的概率比较低所以我们就没有再对RAM分配进行最好的优化了。然后质疑者还提到了场中断优先级的问题，说实话当时我们并没有想到是这个问题，所以这可能是造成我们还会偶尔死机几次的原因，谢谢你提出来了。

  然后质疑者还提到了什么共用数组会有乱七巴糟的条纹，现在我澄清一下。首先我在原有的数组 mt9v034_image下又创建了一个放二值化数据的数组，应该是因为os优化的原因bss和dec确实没有超，如果超了我们就用备用的双核方案了。这个数组仅仅是方便我对比灰度图和二值化图，并不是时时刻刻在用的！！只有在调参系统里按下了图像显示页面选项时才会跳到那个函数进行二值化并显示，平常车在跑的时候是只用到了mt9v034_image数组的而且并不需要对数组进行二值化赋值，因为我的算法是用mt9v034_image数组灰度值大小直接跟二值化阈值进行比较来判断这个点是趋于黑还是趋于白，这样做的好处是省下了对数组每一个像素点赋值的时间。

  质疑者还提到同时跑着处理和显示的线程，额...实际上因为算法原因显示线程是和调参系统挂钩的，只在我需要调试看图像及参数的时候才会同时开着图像显示，当然不会让小车跑的同时开着图像了，这个明显是常识问题我肯定不会犯错。

三、回应单片机速度问题

  这篇论文并不是全都是我写的，有一部分是另一个队友写的，但他并没有参与软件开发，所有软件算法、调参、控制全都是我一个人写的，没有那么牛逼也包揽其他杂活了。

  那个延时的问题我当然不可能在图像处理里面延时这不是傻子吗。这一小部分可能是我队友为了水的字数写上去的，但是我还是要为当时因为时间紧凑没有严格删掉水的部分而为大家道歉。

  然后质疑者提到了处理完一帧的时间压根不会减少，这一点我其实是同意的，但是可能是我放测试运行时间的代码位置不对，上位机给出的结果确实是少了，但是当时要到交论文的截止时间了所以并没有深入探究严谨性，造成了质疑者的误解这一点我要道歉。

四、回应质疑总结

  最后在总结一下，说实话突然被告知自己的队伍被举报了还挺意外的，为什么只举报我们山威的而不专门发一篇文章也举报其他队呢？其他队的论文我也看了说实话能举报的点比我的论文多得多吧，这一点也不经让我产生质疑，是有人眼红山威今年的成绩而专门挑刺吗？

  公开源程序的话我是觉得不太合适的，这设计到了我们的核心算法，如果要公开那也应该公开所有通过RTT进国赛的人，然后质疑者就可以从中”参考”他们的代码了？

  这篇文章临时写出来的可能在用词上和行文结构上不太严谨请各位见谅。

参考资料

[1]基于RT-Thread全向赛车控制算法开发: https://zhuoqing.blog.csdn.net/article/details/119652068

[2]第十六届全国大学生智能汽车竞赛RT-Thread创新专项奖: https://zhuoqing.blog.csdn.net/article/details/118506454

[3]RTT的名单是RTT公司给出: https://zhuoqing.blog.csdn.net/article/details/119544099