光栅编码器因为进了金属屑而导致有几个栅格正转有度数反转没读数
滑动变阻器因为接地线虚焊导致输出电压会跟着电机电流漂
电机驱动器输入有个FIFO而且执行速度略慢导致滞后在50毫秒和1秒之间随机变化
激光温度计会告诉你一个烫手的温度是33度
链轮传动轴线不平行，造成其中一个链轮在铝合金外壳上摩擦产生时变阻力
测量角度的连杆在运动中产生的轴向力作用下会产生巨大摩擦力，导致设备转动时连杆弹性弯曲而传感器没读数。停机以后怎么检查怎么都是好的。
MCU上电以后居然在开始的几秒钟里面SPI口不工作
滑台的库伦摩擦太大，却要做力控制
齿轮有大间隙，却要做力控制
P增益设得太大，系统震荡了，然后撞坏了力传感器（好吧，这是我早年犯的最蠢的错误之一）
更不要说：
A/D接口可能烧了当你是某个全新项目上的控制工程师的时候，你就有种对抗全世界的感觉。
D/A接口可能烧了
UART可能烧了
MAX232可能烧了
H桥可能烧了
示波器可能烧了
万用表可能烧了
电机可能烧了
连接线可能断了
电路板可能脱焊了
导线可能短接了
……
做的久了，就会深刻体会到什么叫墨菲定律。于是你就会变成这样：
“这样可以吧。”
“不不不，这两个裸露的端子有可能碰到一起。”
“可是他们是分开的啊。”
“不不不，他们还是有可能碰到一起，比如说万一被撞了一下。”
“撞不到这里吧。而且这里也套不了热缩管了，也没办法贴电工胶带。”
“那我们试试热熔胶？”
“请给我拿两个万用表。”
“拜托在每个地方都做电缆的应力释放点。”
“拜托尽量不要有裸露的触点！！！”
有个英语单词非常完美地描绘了“经过两周的debug和拆机测量仍然没有发现问题出在哪里”的心情：Frustrated ﾍ(;´Д｀ﾍ)
有个汉语词汇非常完美地描绘了“经过四周的控制增益调试和设计了一系列不成功的状态观察器、参数辨识器和补偿算法后终于发现问题出在一个传感器工作不正常”的心情：生无可恋（╯#-_-)╯╧═╧
——————————————————————————————————————
那为什么还要干这个呢
因为当整个系统按照你的预期而完美地运行起来的时候嘛，你就会觉得成就感爆表、简直无所不能(•‾̑⌣‾̑•)✧˖°
简直想从实验室跑回家，拥抱路上见到的每一个人
如果你做的是机器人控制……
这就是做控制工程师的乐趣吧<(￣︶￣)>
————————————————————————————————
做控制工程师的话，除了会盲调PID之外，要会系统建模和制作模拟系统，在模拟系统里大致确定控制系统和控制参数。要和机械工程师合作，尽量减少影响控制的摩擦和阻力，确保机械结构能够提供足够的力/力矩，确定散热良好。要和电路工程师合作，减少任何可能的电路问题，这包括短路、断路、浮地、串扰等等。研发试制过程中最麻烦的是大部分电缆和一部分电路板都是临时制作的，存在很高的故障率，要特别注意应力释放点，避免电缆、焊点受力。要仔细阅读所有部件的手册，确定工作温度、湿度、密封情况是否适宜，量程、破坏极限是否已经考虑。要了解传感器的延迟是多少、驱动器的延迟是多少，是否需要考虑，还是可以忽略不计。要提前考虑自己需要哪些传感器数据。试制阶段宁可传感器冗余，也不要不足，只要开支允许，传感器宁就上限不就下限。在动手做控制算法之前可能要花费大量的时间在这些细节问题的敲定上面，但这个开销是值得的。这会在后面设计控制算法以及实现控制算法的时候带来巨大的便利。
至于控制算法本身，大部分时候都是从一些课本上典型的控制算法开始，根据你的需要进行修改。不排除你能从论文中找到非常合适的算法——如果你所在的领域已经有很多控制论文的话。那样显然事半功倍。但也不要局限于论文。很多时候他们的物理条件和任务需求和你的是不一样的。他们的算法未必是上佳之选。
最后，能用前馈干掉的误差，就不要用反馈控制干掉。能用辨识和补偿干掉的参数变化，就不要鲁棒控制干掉。能用单级控制，就不要用多级控制。系统的快速性往往是问题的关键。
作者：冷哲
链接：https://www.zhihu.com/question/46824735/answer/115202408
来源：知乎
著作权归作者所有，转载请联系作者获得授权。
/3 
