关于山东大学（威海）全向组海韵三队提交的 RT-Thread 技术报告中的若干疑点

Posted 2021-09-14 卓晴

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

海韵三队同学很快针对提出的疑问进行了书面的回复，具体内容在本文的最后一节。

最后质疑者对于海韵三队的回复做了最后的陈述。

关键词： RTT，智能车竞赛，质疑，沁恒单片机

 

§01 问题来源

---

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

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

• 基于RT-Thread全向赛车控制算法开发
• 第十六届全国大学生智能汽车竞赛RT-Thread创新专项奖

 

§02 若干疑点

---

一、关于RAM使用问题

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

▲ 图2.1 单片机RT-Thread 不同进程RAM分配

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

▲ 图2.2 灰度图像尺寸

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

▲ 图2.3 程序编译后所占存储分配

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

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

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

二、摄像头采集问题

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

▲ 图2.2.1 总钻风摄像头配置参数

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

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

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

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

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

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

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

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

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

三、单片机运行速度问题

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

▲ 图2.3.1 论文的第八章第三节

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

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

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

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

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

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

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

 

§03 质疑结论

---

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

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

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

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

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

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

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

 

§04 回复质疑

---

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

一、回应关于RAM使用问题

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

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

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

▲ 图4.1 编译后程序内存分配结果

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

二、回应摄像头采集问题

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

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

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

三、回应单片机速度问题

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

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

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

四、回应质疑总结

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

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

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

 

§05 对回复的回复

---

  以下是提出质疑同学对于海韵三队回复的回复：

一、问题讨论

1、RAM占用问题

  通过队员提供的编译完成截图来看，其未运行的单片机占用的ram就已经达到16.3KB，而众多线程是在单片机上电后初始化时动态划分出一定ram作为其内存栈，而且根据作者文章所述，其线程都是采用死循环模式，

▲ 图5.1 线程为死循环模式

  这就说明所有线程占用的内存空间在后台都是常驻的，因此可能的RAM使用量应该是16.3+5.7KB，已经超出单片机实际RAM空间大小。FLASH的问题不好探究，所以我一直没有提出异议。

2、图像数组占用问题

  原先估计的100*75尺寸确实是出现了计算失误，既然队员给出了真实尺寸大小80*60，那就按此大小继续讨论。队员又提出其开辟了一块数组专门存放二值化后的图像，

▲ 图5.2 队员提出其开辟了一块数字专门存放二值化后的图像

  只可惜该单片机的底层支持最小的变量大小是一个字节，

▲ 图5.3 单片机底层支持数据类型所占的内存大小

  因此会有2*80*60个字节即9.6KB的内存空间用于存放图像数组。就算是在最节省内存情况下，即二值化图像数组是动态的，只在车辆调参时动态创建，那我们就讨论那个时间段内存分配的合理性，即可证明真伪。

▲ 图5.4 RT-Thread OS 优化

  在同样开启os优化的情况下，采用逐飞提供的rtt例程，同样无任何其他程序，声明2个同样80*60字节大小的图像数组 可以发现ram占用空间data+bss已经高达304+18080≈17.9KB，再加上单片机初始化后动态创建的几个线程的栈空间5.7KB，又大大超出了单片机自带ram空间。

▲ 图5.5 图像数组对应的存储空间

  （一个小插曲：只声明无访问的数组，编译时会被os优化掉，编译信息里计算空间不会把他算进去，因此我在main函数里对其访问，这样才会真正为其分配空间）

▲ 图5.6 在程序中对于图像空间进行访问

二、写在最后

  本来以为给卓大大发的文章会石沉大海没有后文，没想到的是卓老师不仅看了还将其公开，这让我对卓老师十分敬佩。

  原来只是随手写了那篇文章，然后删除，退出和取关了所有跟智能车有关的东西，已经完全告别智能车进行下一段旅程了。但在csdn看到这篇文章时，还是从网上下回相关的文件和软件，再对一些疑点进行真实性分析。

  该队员对我提出的一些疑问大多做了解答，我觉得很有诚意，但是他在总结中的一些观点，让我不能苟同，因此写了这篇文章作为最后的回应，后续再有什么回复，我也不会再做出回应，这件事就交给广大车友们评判。

1、为什么我看你的论文？

  首先我今年是做麦轮，并且花了相当的时间对rtt进行了研究，就个人而言在沁恒该款芯片上使用RTT，我觉得难度是比别的组都要高的。作为靠RTT进入国赛的唯一麦轮队伍，我不看你的文章看谁的呢？

  看你文章的目的是想在你的文章中找出能解答我之前遇到问题的解决方案，却得到的是一个比较敷衍没有深度的结果（就论文来看是这样），所以我花了几个小时验证了可行性并写好文章，也算是写出一些我心中一直存在的疑惑。

2、为什么要求提交工程文件？

  其他队伍的文章我也多少看了点，确实多多少少有问题，但我知道举报这东西要讲究时效和证据要难以翻案，其他单片机相对来说资源多的多，给点时间可能人家就真的复现出来了，而沁恒的这款单片机，就这么点资源，文章里写多了说不定就把可行性写死了。

  所以我当时希望卓老师能够立刻要求你们提交工程文件，防止你们后期修改真搞出来了，谁也不知道是先有鸡还是先有蛋。其实到了现在这个时候，真相已经无法查出了，过了这么久都够从头再写程序了，这此举报已经失去了意义。

  至于说眼红山威的成绩，那我只能说太度君子之腹了，你们拿几个国奖对我没有任何影响，你们取消成绩了我这个省三也不会因此得到国奖，我承认我省三是很菜，但你也得承认这个世界就是爱开玩笑。别人没被举报，不代表你被举报就委屈了，也没见翟天临有多冤是吧，想拿别的组当挡箭牌，想一起拉下水，这个心态不太对把。

3、需要营造更好比赛环境

  营造一个好的比赛环境只能说是人人有责，要靠每个人自觉维护，自觉监督，作为一个985学生，更要注重学术道德的培养，可能你的车真是用的RTT跑，但你的这篇论文出了问题你还是要对此负责。公开源代码，本来就是我们这个比赛一直有要求的，只是没有得到很好的贯彻，这就是导致了强校和弱校“奖级固化”，比赛不公平的根本原因。

  只有开源竞争，才能激发创造力，促进比赛更好的发展。作为一个没保研资格学校的学生，做智能车只能说是靠情怀，明年我也不做了谁在乎你的程序呢？这个比赛牵涉到太多学校太多人的利益，所以强校肯定不情愿公开程序，也只能维持这个现状，很无奈，但总有人要发出声音。

  此外，看了长春理工同学的经历，只能说是有感而发却深深无奈。这个社会向来是不公平的，对大多数人来说失败才是生活的常态，作为普通人能做的只有欺骗自己或者咽到肚子里，成功只是属于少数人的。表达能力有限，只能写成这样，希望这件事能有个好的结果，国二和省三，我们都有光明的未来。

---

■ 相关文献链接:

• 基于RT-Thread全向赛车控制算法开发
• 第十六届全国大学生智能汽车竞赛RT-Thread创新专项奖
• 第十六届全国大学生智能车竞赛RT-Thread创新专项奖获奖名单

● 相关图表链接:

• 图2.1 单片机RT-Thread 不同进程RAM分配
• 图2.2 灰度图像尺寸
• 图2.3 程序编译后所占存储分配
• 图2.2.1 总钻风摄像头配置参数
• 图2.3.1 论文的第八章第三节
• 图4.1 编译后程序内存分配结果

■ 微信留言

转载本博文的公众号-TSINGHUAZHUOQING

• 不弃 ：开卷？
• JR ：开卷？
• rabbit2016 ：看到最后，我只能说太看得起自己了。别人提出质疑，作为工程师就用相应的论据回应就好了，而不是在最后发一顿牢骚，针对山威啥的，没必要
• 格格巫 ：在争论中学习，在辩论中成长
• EI ：属实是节目效果拉满
• jumping ：回答者给人一种又当又立的感觉，提问者却一直挺谦逊的，两个人水平和言语高下立判。
• 王天真- Tianzhen Wang ：很好的交流互动。
• CS雨人 ：很简单，由组委会核查代码和技术报告一致性
• 白商柿红 ：你质疑就质疑，事情怎么处理是组委会的事。张口公布源码，闭口不了了之。不知道的还以为比赛有多黑暗呢这波节目效果拉满
• LG5 ：摄像头组的思路不都是取出来一个中心线，控制舵机角度，调车的时候，适当减速。出现道路元素特征的时候特殊处理。
  每个小车硬件调节的不一样，一些控制参数出来的都不一样。
  有啥别的思路需要保密吗。
• 爨邯汕寺武穆云籍鞲 ：神仙打架
• 统一面渣 ：大家还可以去看看海韵二队的文章，通读全篇，除去在百度、CSDN上复制粘贴下来的，我看到的就是复制粘贴几个.c与.h文件到逐飞库，封装几个无关痛痒的函数。而海韵四队就更加可笑了就纯搬运别人的文章而且篇幅巨短。明年真的要加强应用部分的监管部分，感觉压根就没用RTT就一纸空文而已
  • 统一面渣 ：卓大，我看了今年RTT大部分论文，除了重大以外，没有一个学校的论文关于RTT部分是有任何价值的，有没有用真得让人怀疑，除该篇论文的海韵三队，还有山威的海韵二队、海韵四队，浙工大的BOOM6队等关于RTT的部分简直水得不能再水，建议明年组委会加强应用部分的监管部分，到底有没有用到RTT呢？
• 碗里来 ：评论区比文章精彩多了啧啧啧，一边是没有人会针对山威的言论，一边是有人举例RTT全体灌水刚好例子就包含山威的其他两个队，精彩太精彩了！！
• 大仔. ：这件事情还会得到妥善处理吗？
• Lntano ：当时就觉得应该在比赛之前上交RT-Thread论文，而不是在比赛之后，这样有没有用到都可以写论文，并且上场比赛前应有专门的人来检查你是否真的用了RTT。
• 未署名 ：我觉得很简单啊，rtt公司不是有源程序吗，那就让他们拿着源程序在车模上下载重跑一遍不就行了吗
• weiwei ：节目效果是有了的，加油智能车