一开始接触项目调试时，总被身边人追问机器人编程用什么语言，那会儿手头同时接手了小型教学机器人和工业机械臂两个活儿，没急着跟风选热门语种，反倒抱着设备挨个试，越琢磨越发现不同场景下的选择根本没法一概而论。
最先上手的是教学类的人形机器人，这类设备主要面向入门学习，硬件配置不算高，功能大多停留在动作指令、循迹避障这些基础操作上，最开始随手拿了Python来写代码，代码行简短，语法也宽松，不用纠结复杂的内存管理，敲几行指令就能让机器人完成走位、亮灯、发声的组合动作，哪怕是临时修改动作顺序，改动一两处内容就能立刻看到效果，对调试节奏的适配度特别高，那段时间连着半个多月，日常写控制脚本基本都靠着这门语言推进，没出现过卡顿或者编译报错卡很久的情况，就算是新手接手这些脚本，也能快速看懂并做出简单调整。
换到工业机械臂，情况就完全不一样了。
最开始还惯性的继续用Python编写控制程序，运行起来才发现问题，机械臂需要精准的时序控制，每一个关节转动的毫秒差都会影响作业精度，Python运行时的延迟在这种场景里被无限放大，设备运转起来时不时出现动作错位，反复排查半天，也没法从代码层面彻底消除运行延迟带来得偏差，连着熬了两晚调试，依旧没能把动作误差控制在标准范围内。
后来才反应过来，工业场景看重的是运行效率和实时性，C/C++才是这类机器人的主流选择。底层硬件驱动、运动控制算法几乎都是基于这两门语言开发，编译后的程序运行速度快，对硬件资源的调用也足够直接，没有多余的运行环境拖慢节奏，换成C++重写核心控制代码后，机械臂的动作瞬间变得规整，连续长时间作业也不会出现时序混乱的问题。
也试过给嵌入式微型机器人写程序，这类设备体积小，主控芯片内存和算力都十分有限，复杂语言根本跑不起来。很多人会忽略这种小众设备的需求，一味照搬前面的选择，最后代码根本烧录不进芯片里，白白浪费不少时间。
汇编语言在这时候就派上了用场。
只是汇编语言的写法繁琐，每一步硬件操作都要逐条编写指令，可读性很差，后续维护起来特别费劲，反正除非是硬件资源极度紧张的微型机器人，日常项目里基本不会主动去选用它，身边不少同行只有在优化底层极致性能的时候，才会零星用上几段汇编代码，不会把它当做主力编程语言。另外还有部分商用服务机器人，会结合JavaScript做交互界面搭配底层控制，兼顾人机互动和基础运动，不过这种组合方式大多用在面向大众的服务机型上，工业和教学领域很少这么搭配，实用性算不上突出。
收拾好调试笔记，伸手关掉工作台旁的设备电源。