「2019」「RM圆桌」第二期 我们要搞测试

理念2：一个简单评价工程师的方法：定位bug的能力
找bug比较简单，定位才难，就像你在家看跳水比赛一样：看似简单，实际上需要很多知识和经验。
举例3：系统性问题
英雄的云台出现零点附近的突然换向，在经验不足的队员看来就是嵌入式的问题，如果嵌入式队员也是经验不多的队员，就会被甩锅，在嵌入式debug时会发现在靠近中间位置时，电机突然会脱离系统旋转一定角度，是因为机械D型槽顶丝松动导致。
举例4：步兵的云台出现开启摩擦轮时云台会抖动，不开摩擦轮一切正常，debug发现在摩擦轮开启时云台会受一个周期性的力矩，这个力矩是两个摩擦轮的转速差异导致的。而该力矩的频率与云台结构的固有频率相近导致共振，并被IMU放大，导致云台宏观上周期震动，对IMU的计算结果使用低通滤波解决。（就像天线上挂块人肉就能解决信号不好的问题）
举例5（可以分一分）：步兵在换了新结构后云台日常震动，看着很难受，在确定两级PID代码都没有问题的时候开启debug模式，对位置环使用不同频率的正玄波进行测试，在查看50hz附近的结果的过程中发现IMU传感器周期性发生突变的现象。最终发现是因为新结构中轴承与云台间连接不紧密导致微小震动，震动传到了固连在云台上的IMU模块造成了IMU角速度突变导致的控制不收敛现象。（本可以拍一拍就解决的问题非要这么麻烦）
总结：一个问题并不是一个点引起的，会涉及多个错误的叠加，比如机械-机械的错误叠加（嵌软是不可能出bug的，这辈子都不可能的，只能靠甩给机械才能维持生活这样子）

好厉害呀

火钳刘明

这里是我们RM的测试流程，这个已经被优化过了，大家可以直接使用。

登录/注册后可看帖子

图片请大家移步至帖子内观看

民间科学家，修复BUG的重点是重现BUG，你有什么重现BUG的秘籍

主要是下面的几个步骤
1)恢复现场：尽量重现bug出现时的场景
2)分析关联变量：对于比较好复现的问题，分析关联变量比较容易发现问题根源
3)控制变量（排除法）：对于一个稳定的机器人突然出现的，之前没有发生的问题，不要匆忙打开软件撸代码，先尝试换硬件，换线，换机械，换传感器，先排除是他们引起的问题，最后再怀疑软件出了问题
4)多次重现寻找规律

这里我给大家举个例子

从哪些方面去测试一个具有完整运动功能的机器人底盘的性能好坏呢？

Bug描述：机器人发射弹丸时，云台抖动，导致弹道不稳；
1）恢复现场，发现每次开启摩擦轮之前云台稳定，开启摩擦轮后，开始逐渐抖动并且加剧；
2）分析出关联变量是开启摩擦轮，而不是发射弹丸，也不是拨弹机构；
3）控制变量，换一个机器人，同样的程序，发现发射弹丸时，云台不抖动；
说明是硬件和结构引起的问题；分析云台抖动相关的变量：云台PID位置反馈，云台速度环反馈，云台PID输入角度，用jscope 调试，发现开启摩擦轮后云台PID速度环反馈数据周期性抖动，而速度环反馈是陀螺仪反馈的数据，这时保证其他环境不变，更换陀螺仪模块，发现抖动依然存在；至此可以定位问题不在软件，也不在硬件，开始从结构方向去寻找问题产生原因，检查机构是否稳固，最后发现是有一个结构件螺丝松动，摩擦轮开启后，产生共振，导致陀螺仪数据抖动，从而出现bug，最后优化结构件固定方式，解决该问题。