https://blog.hantaotao.top/tag/%E5%B7%A5%E4%BD%9C/ https://blog.hantaotao.top/archives/204/ 2026-07-18T23:08:00+08:00 23年入职培训的时候，陈老师问我们，在工作中应该如何处理与乙方/供应商之间的关系。我当时比较天真，说的大概意思是，如果供应商配合度不好，直接换一家就好了。当时觉得，与供应商关系，就是甲方与乙方之间的关系，何必客气太多呢？后面越来越发现，事情不是这样子的。越来越呈现一种合作、共赢的态势。与供应商的沟通是越来越客气了，不过相当一部分原因是我和人沟通本来就比较客气就是了。在水下机器人这个行业，规模不算大，某一品类的供应商，不算少但可选的范围也确实不算很多。作为一个项目的集成方，有时遇到的问题会很细致，一个人或者一个团队的技术面不可能面面俱到，与一家靠谱的供应商一起讨论（请教）解决方案实在是常见的事，我有时在想，所谓的工作资历，一方面就是在积累行业内供应商资源与人脉。还记得前段时间发生的一件事，我设计的一件产品的外壳，其中一个关键的安装孔位尺寸被我搞错了，应该是7/16的螺纹被我标成了M10，这是我的设计失误，后面外壳到货验收的时候，发现尺寸不对，安装不上去。就和加工商说了这件事，麻烦他帮我扩孔，他爽快答应了。当然这是建立在我一直和他有不错的合作经历的基础上，才愿意帮我这个忙的。有时，我对乙方可能比对甲方还要客气，我不喜欢秉持某一心态（卑微\傲慢）与人沟通，我的理念是无论是甲方还是乙方，大家都该是平等的合作的姿态。当然你作为我的甲方，你的需求我会尽量满足，即便是我认为不可理的，但技术上也能实现的，在我告知你风险前提下你仍能接受，我也会设计方案来实现。不过有时面对一看就是没经过大脑的或者外行的需求，也会驳回就是了。记得有一次，有一个甲方领导提的需求实在是不能接受，我在反驳他，当时比较焦灼，可能我说话声音有点大，丝毫没退步，他愤然离场。（不过没有影响后面的交付）。（我现在在反思这件事，当时应该再委婉一些，语气再和气一些，毕竟他是甲方呢）。 https://blog.hantaotao.top/archives/195/ 2026-01-14T22:45:29+08:00 事件背景：交付给沈阳自动化研究所的一台直径200的AUV进入售后阶段。1月13日，甲方联系我们，说深度数据不太正常，记录的下潜深度数据和实际下潜深度不一致。深度数据产生的链路是这样的。导航段的节点控制板通过485串口接收深度计的数据，和其他数据组包后，再发给我主控段的控制板，主控段内根据协议进行数据解析。这台AUV的硬件及底层代码是我们提供的，主控段内的数据解析程序也是我们提供的，甲方将自己的控制代码部署上去。起初，我们怀疑甲方未使用正确的数据，是不是把惯导输出的Z轴数据作为深度来使用了，甲方声称绝对没有错，使用的就是数据解析程序结构体的depth数据。这样子的话，我们只能说把原始数据也记录下来看看情况。今天，1月14号，甲方把记录了原始数据的日志发给我们后，发现解析值和原始值一致，且甲方再次进行了深度航行试验，深度数据依旧不正确。由于导航段节点控制板未对深度传感器的数据做任何处理，不存在传递错误，说明代码端没有问题。也许是深度计的硬件问题？说实话这不大可能，因为我们使用的深度计，是keller的Paa-10LX，之前的项目也一直在用，用了挺久，没出现过问题，这款设备也很难坏。之后再次一顿分析，同事提出，深度计输出的原始数据单位是什么，查看了一下是bar，这时惊觉，没有把压力单位转换成m，所以数据才会不对。其实我们都清楚深度计输出的原始数据是压力单位，大概是负责节点控制板内的同事和主控段内数据解析的同事都错以为对方已经做了转换，不再需要处理了，才会出现这个问题。没有转换前压力数据是1.几，看着还挺正常，就没发现。从这个问题可以看出测试岗位的重要性。本来团队内是有测试人员的，做事也挺认真，可惜上层领导为了降本增效，把人给开了，这个项目中开发兼测试，有些问题自测很难发现。正如对同事所说的，我们需要一个脱离开发角色的人来专门做测试。只有这样，才能从使用者的角度发现潜藏的问题。 https://blog.hantaotao.top/archives/191/ 2025-12-25T23:43:00+08:00 到沈阳匆匆的来，又是匆匆的走。在12月22日晚，接到在沈阳负责产品交付的同事通知，AUV的组合导航模块无法进入DVL组合模式，产品交付遇阻。当时远程连线，判断问题可能出现在两个方面：（1）DVL未成功对底，无法输出有效数据；（2）DVL输出有效数据了，但是未进入惯导内部。首先让同事排查了DVL的情况，看到DVL表面有油漆污染，需要清理油漆，当时以为就是这个原因导致DVL未产生有效数据，还甚是庆幸。然现场同事清理了油漆后发现故障依旧。此时，让同事先进行拆机，我提交了出差申请，并向领导说明情况，他也是很快就审批通过了，随之订机票。为应对可能出现的问题，携带了负压泵、TTL模块、232转USB模块、422转USB模块、螺丝刀、润滑硅脂及备用的O圈。登机前夕，同事开始拆机。到达现场后，同事说已经用TTL模块排查了DVL设备本身，发现设备正常，可正常产生有效数据。随之，我们用232转USB模块，行出成测试链路DVL——TTL转232——232转USB——个人PC，发现数据正常，则可判断AUV内部的TTL转232模块这部分是正常的。之后使用422模块直接进入惯导内部，使用惯导上位机查看数据，发现确实没有DVL数据。继续排查从TTL转232模块出来的线束到进惯导的接插件这一部分线路，发现也没问题。没招了，进行摇人，让做惯导的同事远程查看上位机的配置，发现是DVL波特率设置消失了，甚是奇怪，设置好波特率之后，问题消失。次日，进行水池测试，DVL组合模式没问题了，但又出现了进入DVL组合后，融合后的经纬度数据不再输出的问题。咨询了惯导同事，她判断是DVL相关的参数配置例如刻度因子之类的数据错误导致的。没办法，再次拆机，直接让她远程配置，发现确实是这个问题。解决后进行整装，问题解决，顺利验收。但是针对于为什么配置参数消失的问题虽有若干猜测，但未有定论，毕竟是第一次出现这种问题；向领导反馈后，他也是承诺，若再是出现问题，可进行更换惯导。自毕业后，也是第一次回到所里，由于导师他们目前不在所里办公，间隙，找了还留在所里的学生，握握手，有缘再见，哈哈。说起来这次的甲方代表是我当时的博士师兄，现在留所工作了，幸好是熟悉的人，不然交付期间出现问题，排查BUG的过程要比这焦灼很多。