问题体现

在实际运行中，需要拍摄RGB3张不同亮度的灰度图，再将灰度图融合为一张RGB的彩色图像。但是在某些特殊情况下，就会出现采集回来的3张灰度图与预期的灰度图有差异，造成实际合成的RGB图像有异常的问题
异常出现参考：

问题记录

相机：大恒Mask1840黑白相机。控制模式：line0上升沿触发，line1 Stroke输出。
我历时长达4个月的反复测试和推理验证，总共发现2个问题。
1.嵌入式控制卡与相机的IO交互存在静电干扰
2.大恒相机SDK帧ID排序溢出。

排查过程

首先这个问题之所以很难解决有几个原因。1.偶发性，问题可能发生在任何时候，任意设备上，但是了频率并不高，并且监控难度大；2.呈现出来的效果多样性，并不是一定在拍摄RGB的时候出现异常，从最开始出现比较多的现象，导致我一开始以为是不同原因造成的。3.不确定性，就是刚开始发现问题的时候，不是说每个机台都能复现，有部分机台不能复现，并且也存在出现过问题的设备，很长一段时间又没出现了，导致我刚开始的解决方案认为成功了，导致整个问题反反复复出现。

问题详解：

为什么出现静电干扰，我是通过什么方式发现静电干扰的情况的。

静电干扰是我觉得最难排查的内容，因为我不是电气，嵌入式工程师，我只是软件工程师，对这些其实了解很少。所以初期排查的时候主要是以软件方面的排查为主，而且我需要驱动其他部门的同事去检查，首先我需要给出合理的证据去证明可能是电气的问题。
首先我还是直接从表象出发去剖析整个运行逻辑。首先问题点，偶发性的出现RGB成像效果不正确的问题，那么就直接从RGB图像的来源进行监控。
我首先是对已经出现的非客户设备进行循环测试，将所有的拍照的图像保存在本地中，并且将图像根据时间戳，灯光类型，时间戳进行区分，然后让设备禁止不动进行拍照，循环触发，然后通过监控RGB图的色彩来判断是否存在异常。然后我成功监控到了第一个异常的图像。其中我发现红色和绿色通道明显亮度偏亮了，蓝色通道颜色变暗了，大概在连续拍照15万组后出现的。
由于亮度与预期不一致，所以我首先猜测，问题来自于，偶发性的光源亮度有问题，确实也很符合实际场景，因为不是所有机台有问题，出现频率极其低。所以我做了第二步测试，我仍然让设备禁止不动，然后单个灯点亮测试，为了保证测试一定能复现，所以我加大了测试次数，每个灯硬触发点亮50万次，然后仍然是对采集到的灰度图进行灰度值监控。但是最终的结果是，每个灯单独点亮没有问题。那么在远高于问题场景的测试强度下，仍然能保持正常。那么可以确认不是灯光导致的问题。
然后我重新回到第一步的问题图像与正常图像进行对比，然后我发现异常的绿色通道图像与正常的红色通道图像的灰度值比较相似。在实际拍照中除了RGB我通常还需要拍照其他不同的辅助灯光图像，所以我怀疑可能是其他灯光的可能在相机曝光的时候，由于某种原因造成灯光可能存在提前切换的情况。所以我在拍完一张图像后，我等待100ms的时间，大概是15倍的曝光时间，这样子确保相机完整曝光结束，前后灯光不存在干扰的情况。然后再进行测试的时候仍然出现了同样的问题。那么可以确实，并不是由于光源混合造成的问题。
除了灯光混合的可能还有可能是原本放在红色通道的图像，放在了绿色通道，就是在我选取图像的时候，将原本绿灯的图像放在了红色通道上造成的异常。那么我将所有的回调函数的图像都保存在本地，并通过时间ID帧ID进行区分。经过一段时间测试后发现了另一个独特的现象。就是出现异常的时候图像无缘无故多了一张全黑的，在RGB通道的图像中间，并且对比了一下亮度，连续的4张图像中，其中3张图像是正常的，然后1张是几乎全黑的。而且帧ID是连续的就代表相机确实是连续触发了4张图像。
同时在此处我还发现，我们使用大恒相机时，大恒相机的帧ID上限是2的16次方就是65535，所以当相机帧ID到65535时，下一张照片的帧ID就会变为1，此时会导致我在对拿到的图像进行帧ID排序时会出现异常。再这里我重新对相机获取图像循序的代码进行优化了，不再使用帧ID递增，而是使用环形排序法。

 /// <summary>
 /// 环形序列：同轮次按升序，跨轮次按上轮+下轮
 /// </summary>
 public List<int> SortByRound(List<int> sequence)
 {
     int Threshold = 32768;
     if (sequence == null || sequence.Count <= 1)
         return sequence.ToList();

     // 检查是否存在跨轮次数据（同时包含上轮和下轮数值）
     bool hasUpper = sequence.Any(x => x >= Threshold && x > 60000);
     bool hasLower = sequence.Any(x => x < Threshold && x < 10000);
     bool isCrossRound = hasUpper && hasLower;

     if (isCrossRound)
     {
         // 跨轮次：上轮（大数值）+ 下轮（小数值），各自升序
         var upperRound = sequence.Where(x => x >= Threshold && x > 60000).OrderBy(x => x).ToList();
         var lowerRound = sequence.Where(x => x < Threshold && x < 1000).OrderBy(x => x).ToList();
         return upperRound.Concat(lowerRound).ToList();
     }
     else
     {
         // 同轮次：直接按数值升序排序
         return sequence.OrderBy(x => x).ToList();
     }
 }

随后我对RGB灯光再次单独测试，这个我循环5万次每个灯光，并记录最终图像总数，我发现多了几张图像，这很明显是不正常的情况。那么就是分析为什么会多图像的问题。首先怀疑是相机问题，然后我单独将相机拆下，使用实验室机台对相机进行20万次硬触发测试，结果是正常的，图像数量是正常的。那么可以排除相机自身存在异常的情况。随后根据相机触发逻辑，我发现一个问题点。我们通过硬触发触发相机，然后相机接受到电信号后，开始曝光，然后曝光结束后，相机进入下一轮循环。因为相机内部是单线程处理的，所以相机拍照一定是一轮一轮进行曝光，所以相机多了图像一定是某个环节给相机多触发了一个信号。然后可以怀疑以下2个问题，一个是控制卡确实给多了信号，一个是某种原因导致相机多接受到了一次信号。
然后求助嵌入式开发的同事，要求他将每次触发进行计数，然后进行15万次的测试，测试结果是图像数量变多了，但是嵌入式的触发次数是正常的，所以可以确认是触发到触发中间的传输产生了异常，然后我在交流的过程中，了解到触发信号本质上是一串电信号，电信号在发出和接受时会受制于硬件的原因，产生信号不稳的情况，所以在嵌入式内部电信号传输中通常会有时间和硬件上的滤波处理，其中在接受信号时一般会有一个微秒级别的等待时间，等待电信号稳定下来，或者通过硬件滤波的形式减少电信号的波动值。然后我发现原本相机是设置了电信号滤波时间为50um，所以把电信号滤波时间加大到500um后再进行测试，就明显没有再出现异常情况。
现在只是在表象上规避了这个问题，根本上仍然没有解决，但是调高相机电信号滤波后确实从表象上解决了这个问题。由于加高滤波时间后，相当长一段时间出现的频率都非常低，属于客户可以接受的程度，直到后续提升设备拍照速度的时候，因为新改的拍照方案，导致异常问题再次出现，进入了下一阶段的找问题。

新版相机触发

因为设备提速计划的原因，从原来的由上位机控制拍照，转换为由嵌入式直接控制拍照全流程。这里简要说一下实现的方式。首先我们已知相机的触发信号是一组方波形的电信号，并且相机的电信号会有一组输入与输出参考下图，大恒1840相机的IO接口

其中我们可以看到IO口7和8是预设的输出IO口，IO口1和3是输入IO口，IO口5是GPIO口。这里简要的解释一下相机的信号原理。相机的触发信号是通过一个三极管实现的。其中光耦输入正负为三极管的基极（B）、发射极（E），其中集电极（C）则接通到相机触发内部。那么将信号线接入光耦输入正时，光耦输入负为0V状态，那么光耦输入常态为低电平，那么BE端没有电压差所以不导通三极管。当触发时光耦输入正为高电平，那么三极管就导通，则相机接受到触发信号。如下图

如上面示波器波形所示。常态下低电平为为不触发状态。随后拉高一个高电平，进入触发状态。
那么同理我们可以看一下输出波形，如下图所示：

常态下，相机输出是高电平，然后相机触发后，相机输出状态被拉为低电平，然后触发结束后相机输出重新回到高电平状态。然后再次进入下一轮触发。
根据上述内容的波形，我们可以发现，相机常态下位输出高电平，触发时输出低电平，然后再触发结束后拉高电平状态。并且低电平持续时间等于相机曝光时间。那么我们可以通过监控相机输出状态，当相机输出进入低电平状态时，则监控相机回到高电平的时间点，当监控到相机回到高电平时就开启下一轮的触发。这一套流程全部都在嵌入式中完成，不需要经过上位机控制，可以极大的压缩整体时间，实际测试中曝光时间13ms，一套流程只需要13.5-14ms之间，可以极大减少上位机对相机触发的控制耗时。
所以问题出现在哪里呢？就出现在监控输出信号上面。当监控输出信号由于静电干扰时，偶发性的突然拉高电平，恰好被嵌入式监控到电平变换了，嵌入式认为相机已经曝光结束，所以开起来下一轮的触发，切换灯光，发送触发指令。那么此时相机并没有曝光结束，灯光就被切换了，导致最终输出的图像亮度有异常。下面详细讲述一下排查的过程。
由于嵌入式是其他小组的同事，而且当时我也没有理由怀疑他们嵌入式的程序有问题，因为同时更新了多台设备，并不是每台设备都有问题，所以仍然是需要我找到理由和方案去推动嵌入式的同事进行排查问题。
首先第一步，我重新走了前面的排查问题的流程，一开始我已知相机图像数量增加会导致最终的选取的图像异常，所以我仍然对RGB进行10万次的触发测试，用于排查是否仍然是相机图像变多导致的问题。结果图像数量是正常的。
第二步我对异常设备老化测试，同时监控相机拍照数量和相机输出的全部图像，直到RGB的成品图出现多次异常为止。此时我仍然发现相机采集的图像数量是正常的。那么可以直接排除不是相机存在多触发异常的问题。
第三步我对出现异常的RGB各个通道的灰度图进行分析。首先仍然是分析图像的灰度值，因为图像没有变多，那问题一定是出在相机曝光时，出现的异常。异常可能有2种原因导致的，1相机曝光异常的问题，2在相机曝光的过程中灯光出现亮度不稳的情况，3在相机曝光的过程中灯光出现了切换。那么我开始逐个排查，优先排查硬件问题。首先我将相机和光源拆下，分别安装在实验室的平台上面进行压力测试。使用常亮光源，对相机进行硬触发20万次。另一个实验室平台，使用拆卸下的光源和实验室已知工作状态良好的相机进行20万次的闪烁曝光。为了防止测试具有偶发性，我在模拟实际机台的温度下重复进行多次试验，仍然确认相机和光源是正常的。排查完硬件后就需要确实是否是光源中途重新切换了灯光的问题。
第四步排查相机在曝光的过程中是否存在偶发性的光源出现被切换的可能。那么我让嵌入式的同事拿着他C语言的代码给我详细的讲解一遍嵌入式与相机的交互和接线控制。就如我上述所说的一样。由于切换灯光一定是与嵌入式控制有关。所以我让嵌入式的同事对 触发，亮灯，切换灯光，接收到曝光结束，这个几个时间节点打下时间戳，并通过通信接口返回上位机中。
第五步使用连续测试，监控问题多次出现后，将时间戳转换为Excel表格的形式对时间戳进行分析。最终我发现，触发时间戳-接受到曝光结束的时间戳的时间间隔会有异常，有问题的时间间隔的次数恰好的发生问题的次数。那么现在就可以确定一定是监控曝光结束信号时出现了异常的情况，并且我们监控到这个时间戳间隔少于曝光时间。所以我要求嵌入式在发送完触发信号后，等待一段时间后再监控曝光结束信号，通过时间滤波将异常情况滤除。
第六步，随后在多台机台上继续开始测试，随后测试了很长一段时间都没有在发送问题了，正当我以为问题要解决的时候，又出现问题了。因为在不同型号的机台上存在相机曝光并不是一致的，所以我们在选取等待时间时，选取所有型号最短曝光时间减1ms作为等待的时间间隔。后面我们在其他曝光时间更长的机台上测试监控时，我们发现仍然会出现异常时间间隔大于我们预先设定的时间间隔的情况，更甚至出现，异常时间间隔很接近曝光时间的情况。所以很明显通过时间进行滤波是不能解决实际问题的。
第七步，问题回到为什么会出现曝光信号被异常拉高的情况的。后续我又去资讯了电气的同事和网上收集了一下资料。由于我们是放在实验室的机台，所以基本可以排除辐射，射频信号的问题，同时我让电气同事对实验机台重新更换全新的线材，用于排除线材异常的问题，最后就剩下可能机台存在的静电干扰和接地不良2种情况。同事电气同事还建议我去监控曝光结束信号的波形，试试看能不能发现异常情况时，电信号的波形是什么样子的。然而很有意思的是，我们用示波器去监控输出信号的波形时就发现了问题的根源。由于当时并没有拍照记录，简单的绘制一下波形。如下图所示：

红色的线代表我们当时监控到的实际波形。我们识别的曝光结束信号的波形居然是倾斜的，而不是正常的方波信号。我们后续资讯了相机厂商这种情况是如何发生的。厂商回应我们说，这种情况通常来自于接入设备的静电干扰非常厉害，接地不良导致的，厂商建议我们重新核查设备接地情况，并且对相机输入电源0V进行实际接地处理。
然后我要求电气的同事按照厂商给的方案重新接线。并且对机台重新拍照接地处理，重新设计接地流程。
我们后续使用厂商的方式处理后，曝光结束信号的波形就正常了，并且后面我们在全部机台进行测试后就再也没有发现问题了。
所以最终我们实际排查设备时候发现，有较多的设备是没有正确做好接地处理的，并且机台金属外壳，嵌入式控制卡中同样能测试到静电异常的问题。

总结

这里主要总结了，如何从软件的角度去寻找硬件问题。所有问题的出现都有可以慢慢的剖析原因的。问题无论是从软件上还是硬件上去开始分析都可以。当然通常表象都是软件这边出现的。比如RGB灯光错乱，问题的表象就是软件偶发性异常。深层次上看就是硬件引发的异常。这个过程如何去排除，可以从表象异常的发生的原因出发。比如RGB图像异常，有以下几种可能：1.RGB图像排序有问题；2.RGB对应的灯光有问题。在我排查的过程中，2种情况都是存在的。

另外最近还会写几篇关于软件提速攻关的笔记。内容可能会很多，长达3个月的软件提速和稳定性问题攻关让我受益非常的大。