项目总结——通电网的质量检测
in 项目 with 0 comment

项目总结——通电网的质量检测

in 项目 with 0 comment

项目介绍

通电网的质量检测。

通电网常常用作拦截动物,网的样式如下:

通电网

图中反光的部分是铁丝,用来导电。

此项目主要检测的是:缺豆与溢胶。在网的制作过程中,线与线之间的交叉点常常需要机器进行点胶(点胶是动词)进行固定,在此过程中如果点的胶太小,那么线与线之间就没有胶进行固定,这是缺豆;如果点胶太多,胶点就会太大,这就是溢胶。

项目难点

此项目的主要难点在于环境比较多变以及绿色的线以及阴影影响比较大。就上图来说,最边缘的线颜色非常深而且比较粗,所以这一根线会严重干扰最边缘点的识别;在晚上,由于灯光照射不均匀,会出现四角比较黑以及光线照射造成阴影的问题(网与背景之间有一定距离),针对前者的解决方案是加灯,尽量让光线均匀,后者则是通过用吸光布解决,虽然最终效果没有完全修复这些问题,但是已经基本达到了不干扰识别的程度。

从图中也可以看到这张图片拍到的部分并不完整。事实上,我们一共采用了四台相机同时进行拍摄以及识别,由于此项目没有使用深度学习(因为没有足够的负样本),而是用的纯图片处理与识别,所以对于算法的速度有一定要求,大概是每张图片从拍摄到得到结果不能超过3秒钟。

四台相机也让项目变得更复杂了一些,每台相机都要单独设置参数,下面的两台相机拍到的是反的画面,所以大概是两套相反的算法四套参数。

还要解决误报的问题。准确来说是图片的类型太多,很难预想到所有图片可能出现的情况,所以每运行一段时间就会出现误报的情况(本来没有问题但是机器报缺豆),所以改的次数相当多。大概是设定好算法后,因为光线不均,出现某个点反光区域比较大或者拍出来的点比较小,在进行完预处理之后得到的二值图片点消失,然后误报的问题。

网在制作过程中还会有“换网”阶段,也就是有一段长度的网没有横线,如下图所示:

换网

可以看到下半部分是空的,正常来说这种图片会报缺豆,但是实际上并没有问题,此外最后一行也可以看到点并不在一条直线上,这样也会对检测造成相当程度的干扰。

项目使用的技术栈

项目中遇到的坑

  1. OpenCV以IMREAD_GRAYSCALE的方式读入图片与以IMREAD_COLOR的方式读入图片然后用cvtColor()函数转为灰度图片的结果竟然不一样!这真是遇到的最大的坑,测试没问题,实际环境总误报,找了好长时间才发现这个问题;
  2. 项目中的数据库查询功能发现在调用查询返回的对象的某个getter方法时返回为空,而实际是有值的。这是因为此属性的getter方法是自己写的,方法名不规范,应该由IDEA自己生成;
  3. 异常处理的catch语句中,使用e.getCause().getMessage()屡次报NullPointerException。这是因为e.getCause()返回了null,最开始一直以为getMessage()出了问题,还是尽量少用getCause()吧;

一些总结

  1. 目前使用的是xml文件作为配置文件,利用dom4j进行读取或者修改存储配置,但是这个项目比较小,配置项不多,用xml有些浪费;
  2. 对log4j单独进行了配置,所以每个需要进行日志记录的文件都有非常类似的好几行的代码:

    private Logger log = LoggerFactory.getLogger(NetCheck.class);
    
    //...
    
    LoggerContext loggerContext = (LoggerContext) LoggerFactory.getILoggerFactory();
    File logConf = new File( resFolderPath + "logback.xml");
    JoranConfigurator joranConfigurator = new JoranConfigurator();
    joranConfigurator.setContext(loggerContext);
    loggerContext.reset();
    try {
        joranConfigurator.doConfigure(logConf);
    } catch (JoranException e) {
        log.error("logback配置文件配置失败");
    }

因为接手项目时项目已经在运行了,测试只能在工厂测试,所以如果大改程序的话测试起来相当麻烦,所以我自己也不太敢动太大的结构。如果让我重新写这个项目的话,我应该:

  1. 用Properties作为配置文件,利用java.util.Properties类作为配置类;
  2. 采用maven或者gradle管理项目;
  3. 代码结构优化以及重构,目前很多函数比较大,类也比较大,还有相当一部分重复代码,而我对代码的整洁程度还有结构还是比较有追求的,所以希望能够把大函数拆分,提高代码的复用程度,减少多余代码;
  4. 采用更多的设计模式。目前只有设置采用了单例模式;
  5. 文件夹结构优化,目前想法是用assets文件夹存储图像等静态文件,config或者其他文件夹存储配置文件,将配置文件分开,目前全都在一个文件里面。在文件夹格式和代码命名规范这方面我一直比较纠结(Java和Python已经有了公认的规范,所以这些不纠结),看了很多相关的书(Google style,华为代码规范)或者项目结构,但是还是没有一个很满意的规范;
  6. 最最最重要的就是界面美化。在刚刚接手这个项目的时候我还感觉学长对于界面都写死了改很费劲,结果我自己在写新界面的时候也发现用Java写一个扩展性好,比较方便的修改而且排版比较好的界面简直是折磨,于是最终我也把界面给写死了。看网上说好像JavaFX“出师未捷身先死”?很少有人谈论的,不过看效果还可以,可能我会采用JavaFX或者其他的包吧;
Responses