★ FEATURED ARTICLE 1. 机器人行业嵌入式岗位的真实需求拆解1.1 从招聘市场看机器人嵌入式岗位的分层这两年机器人行业的招聘需求变化非常明显。我翻过不少招聘平台上的岗位描述也跟几个做机器人产品的团队负责人聊过一个很直观的感受是企业挂出来的岗位名称越来越细分但真正卡人的地方往往不在岗位名称上而在岗位背后那几项硬能力上。很多做嵌入式的朋友看到机器人公司的岗位第一反应是“是不是要会ROS2”。这个判断其实有偏差。ROS2在机器人系统里确实重要它承担的是节点通信、消息分发、系统集成这一层的工作。但企业真正花高薪去抢的人往往不是只会在ROS2里写节点、调话题的人而是能在更底层把问题解决掉的人。原因很简单ROS2是开源的学的人多能上手的人也多供给相对充足而底层的东西涉及芯片、实时性、驱动、控制、功能安全这些能力培养周期长能真正扛住产品落地压力的人少。我认识一个做移动机器人底盘的团队负责人他跟我说过一句话招一个会ROS2的工程师面试十个人能挑出三个招一个能把电机控制环路和实时调度都吃透的工程师面二十个人未必有一个合适的。这句话基本概括了当前机器人行业嵌入式岗位的供需结构。所以这篇文章想做的事情是把“机器人行业真正缺哪几类嵌入式工程师”这个问题拆开来讲。我会从岗位分层、能力要求、技术细节、实操要点几个角度展开尽量把每一类岗位背后的真实工作内容讲清楚。如果你正在考虑往机器人方向转或者已经在机器人行业做嵌入式但想往上走这些内容应该能帮你判断自己该补哪一块。1.2 为什么ROS2不是高薪的决定性因素先把ROS2这件事说清楚。ROS2是一套机器人中间件框架它解决的是分布式节点之间的通信、参数管理、生命周期管理这些问题。在机器人系统里它更像是一个“神经系统”负责把感知、决策、控制各个模块连起来。会用ROS2说明你能在这个框架下做集成开发这是一个合格机器人软件工程师的基础能力。但问题在于ROS2本身是标准化的、文档齐全的、社区活跃的。一个有一定编程基础的人花几个月时间就能把ROS2的基本用法掌握得差不多。企业招聘时ROS2往往是一个“加分项”或者“基础项”而不是“决定薪资高低的核心项”。真正拉开薪资差距的是那些ROS2覆盖不到的层面。举个例子一个机器人在实际运行中出现了关节抖动ROS2层面看到的是控制指令正常下发、状态反馈正常回传但抖动依然存在。这时候要解决问题就得往下走是电流环带宽不够是编码器采样有延迟是实时线程被抢占是机械谐振这些问题ROS2帮不了你得靠嵌入式底层的能力去定位和解决。企业愿意为能解决这类问题的人付高薪因为这类问题不解决产品就没法交付。再比如机器人产品要过功能安全认证涉及安全控制器、安全IO、故障诊断、冗余设计这些内容跟ROS2基本不在一个层面上。能扛这类工作的人市场上非常稀缺。所以我的判断是ROS2要会但不要把它当成核心竞争力。真正决定你在机器人行业嵌入式岗位能走多高、拿多少的是下面要讲的这几类能力。2. 第一类实时控制与运动控制嵌入式工程师2.1 这类岗位到底在做什么实时控制与运动控制嵌入式工程师是机器人行业里最核心、也最难招的一类人。这类岗位的工作内容简单说就是让机器人的关节、轮子、末端执行器按照预期精确运动。听起来简单做起来涉及的东西非常多。具体来说这类工程师要负责的东西包括电机驱动器的底层控制电流环、速度环、位置环、实时操作系统的任务调度与优先级管理、编码器/霍尔/旋变等传感器的信号处理、运动学与动力学的嵌入式实现、轨迹规划与插补、多轴同步控制、以及跟上层控制器之间的实时通信。我拿一个典型的协作机械臂关节来举例。一个关节模组里通常包含无框力矩电机、谐波减速器、双编码器电机端和关节端、制动器、温度传感器以及一块驱动控制板。这块驱动控制板上跑的代码就是这类工程师要写的东西。它要在微秒级的时间尺度上完成电流采样、Clarke/Park变换、PID或更复杂的控制算法计算、SVPWM输出同时还要处理编码器解码、故障检测、与关节间总线的通信。这些任务对实时性的要求极高任何一个环节的延迟或抖动都会直接反映到关节的运动品质上。2.2 核心技术点与参数计算这类岗位最核心的技术点我归纳为三个实时性、控制环路、多轴同步。先说实时性。很多人对实时性的理解停留在“跑得快”其实实时性的关键是“确定性”。也就是说任务必须在规定的时间内完成不能有时快有时慢。在电机控制里电流环的周期通常是几十微秒级别比如50微秒或者100微秒。如果这个周期出现抖动电流环的性能就会下降表现为噪音增大、发热增加、动态响应变差。要保证实时性硬件上要选带FPU和DSP指令的MCU比如Cortex-M4/M7或者专用的电机控制芯片软件上要用RTOS或者裸机中断调度把电流环放在最高优先级中断里确保不被其他任务打断。这里有个经验电流环中断里尽量不要做浮点除法、不要调用可能阻塞的函数、不要动态分配内存。我见过有人在电流环中断里打印调试信息结果电机直接啸叫这就是典型的实时性被破坏。再说控制环路。电流环、速度环、位置环的带宽设计是有讲究的。一般来说电流环带宽最高速度环次之位置环最低三者之间要拉开足够的频率间隔通常是5到10倍的关系否则环路之间会相互干扰导致系统振荡。举个例子如果电流环带宽是2kHz速度环带宽大概在200到400Hz位置环带宽在20到40Hz。这个关系不是随便定的背后是控制理论里串级控制系统的设计原则。参数整定的时候我习惯先用理论计算出一个初始值再在实际系统上微调。比如电流环PI参数可以根据电机电感、电阻和期望带宽算出来但实际因为采样延迟、PWM延迟、死区效应算出来的值往往偏激进需要往下调。这个“算出来再调”的过程比纯试凑要快得多。多轴同步是另一个难点。协作机器人通常有6个或7个关节每个关节都有自己的控制器关节之间要通过总线同步。如果同步没做好就会出现某个关节滞后导致末端轨迹偏差。同步的实现方式有几种一种是主从同步一个主控制器发同步信号各关节在收到信号后同时更新另一种是分布式时钟同步比如用EtherCAT的分布式时钟机制。不管哪种方式关键是要保证各关节的控制周期对齐抖动控制在微秒级以内。2.3 实操要点与避坑经验这类岗位在实操中有几个坑我踩过或者见别人踩过值得说一下。第一个坑是编码器采样和电流采样的时序问题。电流采样通常要在PWM周期的特定时刻进行比如下桥臂导通时采样才能采到真实的相电流。如果采样时刻不对采到的电流是错的控制效果自然好不了。这个时序要对着芯片手册和驱动电路仔细确认不能想当然。第二个坑是死区补偿。MOSFET或IGBT上下桥臂切换时要插入死区时间防止直通但死区会导致输出电压畸变尤其在低速时影响明显。死区补偿的做法是根据电流方向对占空比进行修正但电流过零附近方向判断容易出错处理不好反而引入震荡。我的经验是低速轻载时如果发现转矩脉动大先查死区补偿。第三个坑是RTOS任务优先级分配。有些人把所有任务都放在一个优先级上靠时间片轮转结果电流环被其他任务拖累。正确的做法是电流环用最高优先级中断通信和状态机用中等优先级任务非实时的事情放到最低优先级。优先级分配好了系统的确定性才有保障。提示实时控制类岗位面试时面试官经常会问“电流环周期是多少”“为什么选这个周期”“如果周期抖动会怎样”这些问题答不上来基本就暴露了没有真正做过底层控制。3. 第二类嵌入式驱动与BSP工程师3.1 机器人产品对驱动层的特殊要求第二类稀缺的嵌入式工程师是驱动与BSP方向的。BSP是Board Support Package的缩写直译是板级支持包说白了就是让操作系统能在特定硬件板上跑起来的那层代码。在机器人产品里这层代码的重要性经常被低估。为什么机器人行业需要专门的BSP工程师因为机器人产品用的硬件平台往往比较特殊。它可能用的是定制的SoC外设配置跟标准开发板不一样可能要在同一个系统里跑实时任务和非实时任务涉及异构多核的调度可能对接的传感器接口五花八门有MIPI、有LVDS、有CAN、有EtherCAT可能对启动时间有要求比如要求上电后几百毫秒内就能响应安全信号。这些需求通用的BSP往往满足不了需要针对性地裁剪和开发。我接触过一个做AGV的团队他们的主控板用的是某款带实时核的应用处理器Linux跑在应用核上实时任务跑在实时核上两个核之间通过共享内存通信。这套东西的BSP就是他们自己从头调的。调的过程中遇到的问题包括实时核的中断延迟优化、共享内存的缓存一致性、Linux侧驱动对实时核的干扰、启动时序的配合等等。这些问题没有扎实的BSP功底根本无从下手。3.2 驱动开发的核心能力项这类岗位的核心能力我拆成几块来讲。第一块是启动流程与引导程序。机器人主控板从通电到系统跑起来要经过引导程序、引导加载程序、内核启动、根文件系统挂载这几个阶段。每个阶段都可能出问题。比如引导程序阶段要初始化DDRDDR参数配错了系统就起不来引导加载程序阶段要加载内核和设备树设备树写错了外设就识别不了。我见过一个案例板子偶尔启动失败查了很久发现是DDR初始化时序在低温下不满足调整参数后才稳定。这种问题没有对启动流程的深入理解很难定位。第二块是外设驱动。机器人上常见的外设包括IMU惯性测量单元、激光雷达、摄像头、编码器接口、CAN收发器、EtherCAT从站控制器、GPIO扩展、ADC/DAC等等。每个外设的驱动都有讲究。比如IMU驱动要考虑采样率、数据同步、时间戳精度激光雷达驱动要考虑数据吞吐量、DMA传输、缓冲区管理EtherCAT从站驱动要考虑实时性和同步精度。写驱动不是把数据读出来就行还要考虑性能、稳定性、异常处理。第三块是实时性优化。Linux本身不是实时操作系统但在机器人产品里又经常要用Linux因为它生态好、开发效率高。这就需要在Linux上做实时性优化比如打实时补丁、用线程化中断、设置CPU隔离、调整调度策略。这些优化做完Linux的实时性可以做到几十微秒的抖动满足很多机器人应用的需求。但优化过程需要对内核调度、中断处理、内存管理有深入理解。3.3 调试手段与常见问题BSP和驱动调试最依赖的是工具和手段。我常用的手段包括串口打印、示波器/逻辑分析仪抓时序、内核日志分析、性能分析工具比如ftrace、perf、以及硬件调试器JTAG/SWD。串口打印是最基础的但要注意在实时路径上不要用打印因为串口输出很慢会破坏实时性。实时路径上的调试我一般用GPIO翻转配合示波器或者用内存缓冲区记录事件事后导出分析。逻辑分析仪在调外设时序时特别好用。比如调SPI通信可以直接看到时钟、数据、片选的时序关系判断是模式配错了还是时序不满足。调CAN总线可以看到帧间隔、错误帧判断总线负载和冲突情况。内核日志里有很多有用的信息但要会看。比如看到“irq XX: nobody cared”说明中断没有被正确处理看到“BUG: scheduling while atomic”说明在原子上下文里调用了可能睡眠的函数。这些日志背后对应的问题都需要有经验才能快速定位。注意BSP调试中硬件和软件的边界往往很模糊。一个问题可能是硬件设计缺陷也可能是软件配置错误。我的经验是先用示波器确认硬件信号正常再查软件配置这样能避免在软件里绕圈子。4. 第三类功能安全与可靠性嵌入式工程师4.1 功能安全为什么成为刚需第三类稀缺的嵌入式工程师是功能安全与可靠性方向的。这类岗位在几年前还比较小众但这几年随着机器人产品进入更多场景需求增长很快。功能安全的核心思想是让系统在出现故障时能够进入安全状态而不是造成伤害。对于机器人来说安全状态可能是停止运动、限制力矩、或者切换到安全监控模式。功能安全不是简单地加一个急停按钮而是要从系统架构、硬件设计、软件设计、开发流程多个层面去保证。为什么机器人行业对功能安全的需求在增长因为机器人正在从工业围栏里走出来进入协作场景、服务场景、物流场景。在这些场景里机器人跟人共享空间一旦控制失效后果可能很严重。所以产品要满足相应的安全标准要拿到认证才能进入市场。而功能安全的开发需要专门的工程师来做。这类工程师稀缺的原因在于功能安全涉及的知识面很宽要懂硬件失效模式要懂软件安全机制要懂安全标准的要求还要懂认证流程。同时功能安全的开发流程比普通开发严格得多需要大量的文档、分析、验证工作。很多人不愿意做或者做不来。4.2 安全机制的设计与实现功能安全在嵌入式层面的实现主要围绕几个机制展开。第一个是安全监控。系统里要有一个独立的监控通道持续检查主控制通道是否正常。监控的内容包括CPU是否跑飞、内存是否损坏、任务是否超时、指令是否合理、传感器数据是否在合理范围。监控通道一旦发现异常就要触发安全反应。监控通道本身也要有足够的诊断覆盖率不能自己坏了还不知道。第二个是冗余与多样性。对于高安全等级的应用关键通道要做冗余比如双CPU、双传感器、双通信通道。而且冗余通道最好做多样性设计比如用不同厂商的芯片、不同的算法实现避免共因失效。共因失效是指同一个原因导致多个冗余通道同时失效比如同一批次的芯片有同样的缺陷或者同一份代码有同样的bug。第三个是安全通信。机器人系统里控制器和驱动器之间、控制器和传感器之间的通信要保证数据的完整性和时效性。常用的做法是加CRC校验、加序列号、加超时监控。如果通信中断或数据错误系统要能检测到并进入安全状态。第四个是安全IO。急停、安全门、使能开关这些安全信号要接到专门的安全IO上由安全逻辑处理不能跟普通IO混在一起。安全IO的电路要有诊断能力能检测短路、断路等故障。4.3 认证流程中的实操经验功能安全认证的流程通常包括定义安全需求、做危害分析、设计安全机制、计算诊断覆盖率、做验证测试、准备文档、接受审核。这个过程很繁琐但有几个点如果提前注意能省很多事。第一安全需求要尽早明确。安全需求是从危害分析里推导出来的而危害分析要在产品定义阶段就做。如果产品都开发了一半才想起来做功能安全很多架构上的东西改不动了只能打补丁成本和风险都很高。第二诊断覆盖率要算清楚。不同的安全机制有不同的诊断覆盖率比如看门狗、CRC、双核锁步覆盖率不一样。认证机构会审查你的计算依据所以每个机制的覆盖率都要有出处不能拍脑袋。第三测试要留痕。功能安全的验证测试要求有完整的测试用例、测试记录、测试结果。测试要覆盖正常情况和故障注入情况。故障注入测试尤其重要要模拟各种硬件故障和软件故障验证安全机制能正确响应。这些测试记录是认证审核的重点。提示功能安全工程师的薪资通常比普通嵌入式工程师高不少但入行门槛也高。如果你有嵌入式基础想往这个方向转建议先从学习相关安全标准入手再结合实际项目积累经验。5. 第四类传感器融合与感知嵌入式工程师5.1 感知层嵌入式的独特挑战第四类稀缺的嵌入式工程师是传感器融合与感知方向的。这类岗位处在嵌入式与算法的交界处既要懂底层硬件和驱动又要懂数据处理和算法实现。机器人感知涉及多种传感器IMU、轮式编码器、激光雷达、深度相机、超声波、力/力矩传感器等等。每个传感器都有自己的特性、接口、数据格式、误差模型。感知嵌入式工程师的工作是把这些传感器的数据采集上来做时间同步、做预处理、做融合输出机器人系统能用的状态估计结果。这类岗位的挑战在于它不像纯算法岗位那样可以只在PC上跑仿真也不像纯嵌入式岗位那样只关心底层。它要求你既能把传感器驱动调通又能把融合算法在嵌入式平台上跑起来还要满足实时性和资源约束。这种复合能力市场上比较稀缺。5.2 时间同步与数据对齐传感器融合里最基础也最容易出问题的是时间同步。不同传感器的采样率不一样IMU可能1kHz轮式编码器可能100Hz激光雷达可能10Hz相机可能30Hz。这些数据要融合必须先对齐到同一个时间基准上。时间同步有几个层面。硬件层面可以用触发信号让多个传感器同时采样或者用PTP、gPTP这类时钟同步协议。软件层面要给每个数据打上时间戳时间戳的来源要统一。如果时间戳不准融合结果就会出错。我见过一个案例一个移动机器人在转弯时定位漂移查了很久发现是IMU和轮式编码器的时间戳差了20毫秒。20毫秒听起来不多但机器人转弯时角速度变化快20毫秒的偏差足以导致融合结果明显偏离。后来把时间戳对齐后问题就解决了。时间戳对齐的做法通常是用一个统一的时钟源比如系统单调时钟在每个传感器数据到达时打时间戳。如果传感器有自己的时间戳要跟系统时钟做校准。校准的方法可以是硬件触发也可以是软件估计比如用互相关分析估计延迟。5.3 嵌入式平台上的算法实现传感器融合算法常见的有互补滤波、卡尔曼滤波、扩展卡尔曼滤波、粒子滤波等。这些算法在PC上跑不难但在嵌入式平台上跑要考虑计算量、内存占用、数值稳定性。以扩展卡尔曼滤波为例它的核心步骤包括状态预测、雅可比矩阵计算、协方差更新。状态维度越高矩阵运算量越大。在MCU上跑要用定点数或者单精度浮点要注意矩阵求逆的数值稳定性要避免频繁的动态内存分配。我的经验是状态维度控制在合理范围内能用简化模型就用简化模型不要盲目追求高维状态。如果MCU算力不够可以考虑把融合算法放到带DSP或者NPU的芯片上或者用协处理器分担计算。现在有些MCU带硬件浮点单元和DSP指令跑中等复杂度的融合算法没问题。再复杂一些的可以用带Cortex-A核的应用处理器但要注意实时性。算法实现时还要考虑异常处理。传感器可能丢数据、可能出野值、可能饱和。融合算法要能检测这些异常并做相应处理比如丢数据时用预测值顶替出野值时做剔除。这些处理逻辑在仿真里往往被忽略但在实际产品里必不可少。5.4 标定与误差补偿传感器融合的效果很大程度上取决于标定。IMU有零偏、尺度因子、非正交误差轮式编码器有轮径误差、轮距误差相机有内参、外参。这些参数不标定融合结果就会有系统偏差。标定的方法有基于转台的有基于手眼的有基于优化的。不管哪种方法关键是要有足够的激励让待标定的参数可观测。比如标定IMU零偏要让IMU在多个姿态下静止采集数据标定轮式里程计要让机器人走各种轨迹。误差补偿是标定之后的步骤。比如IMU零偏会随温度变化要做温度补偿轮式里程计在打滑时误差大要做打滑检测和补偿。这些补偿逻辑都要在嵌入式代码里实现。注意感知嵌入式工程师面试时经常会被问到“你怎么保证多传感器时间同步”“卡尔曼滤波在MCU上怎么优化”“标定怎么做”这些问题能答清楚说明有实际经验。6. 四类岗位的能力对比与转型建议6.1 能力矩阵对比把这四类岗位放在一起对比能更清楚地看出各自的侧重点和门槛。岗位类型核心能力主要工具/平台入门门槛市场稀缺度实时控制与运动控制控制理论、电机驱动、实时调度MCU、RTOS、EtherCAT高很高嵌入式驱动与BSP启动流程、外设驱动、内核优化Linux、设备树、调试器中高高功能安全与可靠性安全标准、失效分析、安全机制安全MCU、诊断工具高很高传感器融合与感知传感器原理、融合算法、标定IMU、编码器、DSP中高高从表里能看出实时控制和功能安全这两类的门槛最高稀缺度也最高。驱动BSP和感知融合的门槛稍低一些但依然比普通的ROS2应用开发要高。6.2 不同背景的转型路径如果你现在做的是纯上层软件想往机器人嵌入式转我的建议是先补C语言和MCU基础再从驱动或者感知入手。驱动和感知对控制理论的要求相对低一些更容易上手。等有了底层经验再往实时控制或者功能安全方向深入。如果你现在做的是普通嵌入式比如消费电子或者工业控制想往机器人转其实基础是相通的。你需要补的是机器人领域的特定知识比如运动学、动力学、传感器特性、安全标准。这些知识可以通过项目实践来积累不一定非要脱产学习。如果你已经在机器人行业做嵌入式想往上走我的建议是选一个方向深耕。这四类岗位任何一类做到资深都不愁机会。怕的是什么都懂一点什么都不精。企业招资深岗位看的是你在某个方向上的深度而不是广度。6.3 学习资源与实操项目建议学习资源方面我不太建议一上来就啃大部头。更有效的方式是找一个实际项目边做边学。比如想学实时控制可以买一套小型的电机驱动板加电机自己写电流环、速度环、位置环用示波器看波形调参数。这个过程能让你把理论跟实际对上。想学驱动BSP可以找一块带Linux的开发板自己移植引导程序、配置设备树、写外设驱动。遇到问题查手册、查社区、查内核源码。这个过程能让你理解Linux在嵌入式上的运行机制。想学功能安全可以先学习相关安全标准然后找一个开源的安全相关项目研究理解安全机制的设计思路。如果有机会参与实际的安全认证项目那是最好的。想学感知融合可以从IMU和轮式编码器的融合入手做一个简单的状态估计器再逐步加入激光雷达、相机。标定和误差补偿要实际做一遍才能理解其中的细节。7. 企业招聘视角下的筛选逻辑7.1 简历筛选阶段看什么从企业招聘的角度看筛选简历时最看重的是项目经历跟岗位的匹配度。如果岗位是实时控制简历里没有电机控制、没有实时系统、没有控制算法的项目基本过不了。如果有相关项目还要看项目的深度是只调了现成的库还是自己写了控制环路是只跑了仿真还是在实际硬件上验证过。项目描述里具体的数字和细节很重要。比如“实现了电流环控制”就不如“实现了50微秒周期的电流环带宽2kHz在XX电机上验证转矩脉动小于X%”。后者能看出你真的做过而且知道自己在做什么。7.2 面试中的关键考察点面试环节技术面试官通常会从项目入手往深里问。问的目的是判断你是真做过还是只是参与过。比如你说做过电机控制面试官会问电流环周期怎么定的PI参数怎么整定的遇到什么问题怎么解决的这些问题只有真正做过的人才能答得具体。除了项目面试官还会考察基础知识。实时控制岗位会问控制理论、实时系统、电机原理驱动BSP岗位会问操作系统、计算机体系结构、总线协议功能安全岗位会问安全标准、失效模式、诊断技术感知融合岗位会问传感器原理、滤波算法、标定方法。这些基础知识是判断候选人潜力的重要依据。7.3 薪资谈判中的价值锚点薪资谈判时候选人能拿多少取决于几个因素岗位的稀缺度、候选人的匹配度、候选人的经验深度、以及公司的紧迫程度。这四类岗位里实时控制和功能安全的薪资通常最高因为稀缺度最高。驱动BSP和感知融合稍低但也高于普通的嵌入式应用开发。谈判时我建议候选人把重点放在自己能解决什么问题上而不是自己会什么技术。企业付高薪买的是解决问题的能力不是技术清单。如果你能说清楚“我能解决机器人关节抖动问题”“我能让产品过功能安全认证”“我能把多传感器融合的定位精度做到厘米级”这些都是价值锚点。提示不要只盯着薪资数字还要看岗位的成长空间。有些岗位起薪高但天花板低有些岗位起薪一般但能积累核心能力。机器人行业的嵌入式岗位整体成长空间是不错的选对方向比短期薪资更重要。8. 我个人的一些观察和体会写了这么多最后说几点我自己的观察。第一机器人行业的嵌入式岗位正在从“通用”走向“专用”。几年前一个嵌入式工程师可能什么都能做现在企业更倾向于招有特定方向经验的人。这个趋势对深耕某个方向的人有利对什么都做一点的人不利。第二底层能力的重要性在上升。ROS2这类上层框架会的人越来越多竞争越来越激烈。而底层的东西因为门槛高、培养周期长反而越来越值钱。如果你还在犹豫要不要往底层走我的建议是尽早走。第三实际项目经验比证书和课程重要得多。我见过不少人考了一堆证、上了一堆课但一到实际项目就露怯。企业招人最终看的是你能不能把东西做出来。所以与其花时间考证不如花时间做项目。第四这个行业变化很快但底层的东西变化相对慢。控制理论、操作系统原理、电路基础、传感器原理这些东西十年二十年不会有大变化。把底层打扎实不管行业怎么变你都有立足之地。第五不要被“高薪”两个字冲昏头。高薪对应的是高要求和高压力。这四类岗位每一类都需要持续学习和积累不是学几个月就能拿高薪的。如果你真的对这个方向感兴趣愿意投入时间那这条路是走得通的。如果只是冲着薪资来可能会失望。最后分享一个小技巧如果你在准备机器人嵌入式岗位的面试可以把自己做过的项目按照“问题-方案-结果”的结构重新梳理一遍。每个项目都问自己当时遇到的核心问题是什么我用了什么方案为什么选这个方案结果怎么样有没有更好的方案这样梳理下来面试时就能讲得清楚、有说服力。
阅读完成 · 觉得有帮助？
