2015年那会儿我刚入行做机器人系统工程师工位上常年摆着一台ThinkPad、一块ST开发板、一堆杜邦线和几个拆了一半的舵机。那时候的机器人行业远没有今天热闹开源社区里谈论最多的还是ROS Indigo怎么配、IMU怎么滤波、PID怎么调参。十年过去这个岗位的边界几乎被重新画了一遍从嵌入式底层到云端大模型从单机调试到数据闭环从什么都会一点到什么都得会一点——听起来好像没变但实际上已经完全不是一回事了。这篇回顾既是整理自己的十年也顺便给打算走这条路的朋友画一张尽量真实的地图。1. 2015年前后的机器人系统工程师一个人就是一支队伍那段时间的机器人项目有一个共同特点系统复杂度不高但涉及的硬件种类极其庞杂。导航、底盘、机械臂、视觉模块各讲各的协议串口、CAN、以太网混在一起一个Demo跑起来往往需要同时伺候五六种硬件。系统工程师的主要工作就是把这些零件缝在一起。1.1 那时候的日常工作流我印象最深的一个早期项目是给某高校实验室做一台轮式移动平台。任务听起来简单底盘能按路径走、能躲障碍、能在地图上显示位置。但真正动手才发现每一个环节都有一堆隐形工作底盘电机选型、驱动器接线、编码器信号接入嵌入式端写电机控制逻辑用串口发速度指令上位机跑ROS节点做激光雷达驱动、里程计推算手工标定陀螺仪零漂、轮距、激光雷达安装角度最后还要写一套简单的行为逻辑让机器人知道看到障碍物就停。那时候的核心技能不是某一个算法的深度而是串起整条链路的广度。你要是能把一块STM32调通、让雷达数据在RViz里显示出来、再让底盘跟着目标点跑起来你就已经是团队里最抢手的系统工程师了。说句实话这十年的起点其实不高。很多今天看起来基础的工程能力——比如消息队列的可靠性保证、传感器的联合标定、故障恢复逻辑——在当时都属于跑起来就行的灰色地带。这也造成了后来很长一段时间里系统工程师的身份更像是胶水层哪里不匹配补哪里哪里不出数盯哪里。1.2 调试靠人肉效率靠体力那时候没有云仿真、没有自动标定工具、也没有数据回放平台。最常用的调试方法是改参数、编译、烧录、跑一遍、看结果不行再来。一个PID参数可能要调一个下午因为每次改完都要重新启动整个系统而系统启动一次往往需要几分钟。当时有个词叫调车半小时看波形五分钟说的就是这种状态。我自己的体会是2015年的系统工程师更像硬件运维嵌入式开发算法搬运工三位一体的角色而这种多面手属性恰恰为后来的演进打下了底子——至少我见过各种诡异的硬件行为知道问题大概出在哪一层的概率高。2. 行业转折点从能跑到能干活的跨越大概从2017年开始行业的风向明显变了。深度学习开始在视觉领域攻城略地机器人不再满足于在实验室里绕桩而是被要求去做一些实际的生产任务仓储搬运、巡检、分拣、跟随。这一下子把系统工程师推到了新的挑战面前。2.1 感知能力第一次成为系统瓶颈过去的避障逻辑很简单激光雷达扫到障碍物就减速或停止。但真实场景远比实验室复杂半透明的玻璃门、反光的地面、移动的行人、堆叠的货物。激光雷达数据不再干净视觉又受光照影响严重。于是系统工程师被迫去理解概率模型、置信度、多传感器融合这些概念。我记得某物流项目遇到的第一个大坑是仓库里的APS货架反光太强2D激光雷达经常把货架腿看丢。那时候算法同事试了各种参数都不奏效最后是我在车辆底盘上多加了一个朝上的单线雷达专门用来识别货架顶部轮廓才勉强把问题压下去。这类问题不会出现在论文里但恰恰是系统工程师价值最好的体现——算法解决能不能识别系统工程师解决在物理世界里怎么稳定识别。2.2 实车测试的时间黑洞那段时间最头疼的效率杀手是实车测试。项目一旦进入功能联调阶段机器人每跑一趟都要有人跟着记录现象、抓日志、回放数据、调整参数然后重跑。一个场景要是涉及三个功能模块同时失效排查链路会拉得非常长。我们当时的做法是用一台旧笔记本电脑专门跑rosbag record把所有传感器原始数据和控制指令全部录下来。问题复现不了的时候就靠回放数据包在办公室里模拟现场一点一点查是哪条消息先出了问题。说实话这个习惯我保持到了现在而且每次跟新人讲都会强调没有好日志的数据闭环系统工程师就是在摸黑走路。这也是后来越来越多公司开始做数据平台、仿真平台的初衷——大家都被现场调参这件事折磨够了。3. 移动机器人爆发期我把系统工程师干成了十项全能2019年前后移动机器人赛道彻底热起来了。仓储机器人、巡检机器人、商用清洁机器人、配送机器人各种品类轮番上场。资本市场热行业对系统工程师的需求也一下子爆发。但与此同时岗位的要求也悄悄变了。3.1 一个系统的可靠性不再是跑通而是7×24小时不宕机实验室里跑30分钟没问题和产品在客户现场连续运行一整天不出故障是两个量级的事情。客户可不在乎你是不是Demo跑通了他们要的是稳定、可预期、能维护.这个阶段我学到的教训特别多随便列几个电机驱动器过温保护不触发会导致底盘突然失控——必须有硬件看门狗兜底雷达安装支架的轻微松动会让定位精度从厘米级恶化到分米级——结构件必须定期校验网络丢包会让机器人停在原地不动——所有关键通信必须有超时重试机制并明确降级策略充电接触不良导致电量耗尽关机——电源管理策略比想象中复杂这些事没有一件涉及高深的算法但每一条都是现场教做人。系统工程师的角色相当于从把功能做出来变成了把产品做的皮实。3.2 工具链开始起飞也是从这几年开始行业里陆续出现了一批好用的工具仿真平台越来越强很多问题不用到实车就能在虚拟环境里暴露自动标定工具逐步成熟传感器外参不再靠人肉量、靠肉眼对齐数据管理平台开始普及采集的数据能统一存储、回放、挖掘日志系统越来越规范分布式追踪的思路也进了机器人领域工具的进步对系统工程师是实实在在的解放。以前调一次激光雷达和相机的外参要花半天时间去对标志板、试偏移量后来一个标定包跑几分钟就出结果。同样的时间能做更多系统的设计与验证而不是消耗在重复劳动里。4. 软件架构的换代从ROS 1单机思维到分布式与微服务这个阶段最深刻的改变是机器人软件架构本身的演进。早期大家用ROS 1节点的调度与通信在单机环境下还能应付可当机器人系统里出现多台计算单元、多个传感器、甚至多机协同的时候问题就来了中心化的roscore单点故障、通信瓶颈、线程不安全、调试困难。4.1 为什么必须从ROS 1迁出去ROS 1是为科研设计的并不适合产品化。它的通信是基于TCP/UDP的节点间数据流一旦变大延迟就会明显增加而且roscore一挂整个系统全挂。对于实验室场景这无所谓但对商业产品来说完全不可接受。所以后来大家逐渐转向了两种路线ROS 2DDS通信、分布式发现、QoS策略解决了ROS 1的很多结构性问题自研中间件很多公司干脆基于微服务思想自研机器人运行时把感知、规划、控制、交互拆成独立服务再靠统一框架调度我所在的团队后期使用的是自研框架核心思路就是把节点式单机进程变成容器化独立服务每个模块有自己的生命周期和数据接口。好处很明显某个感知服务崩了可以单独重启不影响底盘控制某个模块需要升级不用把整个系统都停下来。坏处则是系统工程师要开始懂代码部署、容器网络、服务发现这些以前碰都不碰的东西。4.2 系统工程师变成后端工程师机器人专家那段时间我最明显的感受是日常技术栈开始往后端靠。传统机器人技能新型系统工程师技能C/Python编程容器化部署、CI/CDROS节点通信服务架构、消息中间件传感器调试数据管道、日志监控现场调试仿真验证、自动化测试硬件选型云端资源调度这变化看起来丢了硬件色彩但实际上是把系统的层级抬高了以前你盯着一个电机的电流波形现在你盯的是一个集群里几十台机器人的状态、日志、告警。抽象层级变了但让整个系统稳定工作的目标没变。在架构演进的过程中我踩过一个算是很典型的坑某次把一个核心模块从ROS 1迁移到新框架时只验证了模块功能本身忽略了模块与外部通信的时序变化。结果上车实测时底盘控制指令延迟比之前多了100多毫秒导致急停响应迟钝。后来给所有关键模块都加上了延迟监控和超时熔断才算彻底解决。架构切换不是替换组件而是重新审视系统的边界与依赖。5. 大模型浪潮来袭机器人的大脑换了物种2023年之后行业里最热的关键词变成了大语言模型、多模态大模型、具身智能。机器人系统工程师还没从上一轮架构升级中缓过神来就又站在了新的十字路口。5.1 从规则驱动到数据驱动的彻底转向以前的机器人行为逻辑是什么状态机、行为树、规则引擎。工程师花大量时间枚举场景、写if-else、设计状态转移试图覆盖所有已知的未知。大模型进来之后思路变成了给模型大量感知数据人类操作示范让模型学习看到什么就应该做什么系统工程师负责搭建数据采集链路、处理数据、设计评测标准这个转变非常根本——机器人系统的复杂度从代码复杂度转移到了数据复杂度。系统工程师的主要工作从写逻辑变成了搭数据飞轮设计遥操作平台让人能高效地示范动作为不同传感器数据做时间戳对齐、坐标变换、标注搭建数据存储、清洗、增强的自动化管道设计回放与仿真环境让模型在虚拟空间里先练几万遍在真机上建立安全护栏确保模型学错了也不会闯祸5.2 我角色里新增的DL工程师成分以前我写代码主要是控制流程现在有很大一部分工作量变成了准备模型输入、调试模型输出、分析Bad Case。比如视觉语言模型在机械臂抓取任务里有时候会把抓住杯子理解成捏碎杯子这时候系统工程师要做的是查训练数据里是不是缺少轻柔抓取的示例、检查标注是否正确、调整奖励信号或后处理规则。说实话这十年的最后三年我学的新东西比前面七年加起来都多。但核心能力线没有变把一个复杂系统拆成可运行、可维护、可观测的模块并保证它们之间协作顺畅。只是模块的材质从代码换成了模型从阈值换成了概率。6. 十年演进背后的三条永恒主线回看这十年具体技术变了一茬又一茬但有些东西始终没变。6.1 系统思维永远是护城河机器人系统的复杂度注定了需要有人站在全局视角看问题。算法工程师负责这棵树的叶子系统工程师得清楚整片森林的地形。一个优秀的系统工程师不一定每个方向都钻得最深但必须能在A模块和B模块出冲突的时候快速判断影响范围找出折中方案。这种能力怎么练我自己的经验是必须亲手搭过完整的系统拆过完整的系统也救火救过濒临崩溃的系统。没有这些经历你对系统的直觉就是空中楼阁。6.2 Debug能力是硬通货十年里我换过很多技术栈但有一件事没停下来过做Debug。给电机驱动排查过丢步给SLAM系统查过坐标跳变给大模型推理查过OOM也给网络通信查过丢包。机器人系统的有意思之处在于很多Bug藏在不同模块交互的缝隙里根本不是单一语言、单一框架能够解释的。所以我的建议非常朴素刻意练习自己的排查能力每次出问题不要急着问同事先自己拉日志、复现、二分定位、验证修复这个过程本身就是系统工程师最重要的训练。6.3 学习能力大于存量知识2015年的热门技能——嵌入式、串口通信、PID调参——到今天仍然是基础但已经远不足以撑起一个系统的全部。2025年的系统工程师需要懂的东西越来越多数据工程、模型训练、MLOps、云原生、安全机制。这行不存在学完的那一天。与其焦虑还有多少东西不会不如建立一套自己的学习框架每遇到新技术先问它解决什么问题、放在系统的哪个层级、和现有组件的边界在哪、关键指标是什么然后找个最小场景上手。这个方法论比具体某个工具的知识更复用。7. 想入行或正在转型的朋友一点掏心窝的话如果这篇文章能给你带来一点帮助我想重点讲三件事。第一别只盯技术要盯系统。很多新人容易沉迷于某个算法的效果把大量时间花在刷榜、调参上结果真上了机器人发现部署才是最大的坎。反过来也不要只做调包侠不懂底层原理遇到问题就只能瞎试。系统工程师的系统二字意味着你要有全局视角也要有钻进去的勇气。第二早点学会和不确定性打交道。机器人系统里的一切都有噪声传感器有噪声执行器有偏差模型有概率性错误环境永远有意外。把完美主义放下学会为不确定性设计冗余、兜底和降级是这个职业走向成熟的标志。第三保持对动手的兴趣。无论技术怎么变机器人终究是物理世界里的系统。能亲手接一根线、拧一颗螺丝、蹲在现场看机器人卡在哪个角落这些看起来不够高级的事往往是系统工程师最珍贵的直觉来源。我见过太多只会坐在电脑前敲指令的工程师遇到现场问题就像断了电的机器人。十年走下来我的感觉是机器人系统工程师这门手艺从会焊板子、会调车的朴素阶段长成了懂算法、懂架构、懂数据、懂产品的交叉学科岗位。它一直没有变得轻松也没有变得无聊。如果你正好在这个方向上那就保持好奇保持能动手解决问题的手感——这个职业最迷人的地方就是它永远有新的问题等着你。
阅读完成 · 觉得有帮助?