企业官网建设流程全解析

1. 一个扎心的现象：技术栈看着挺全，简历却石沉大海

干了三五年嵌入式，手上有STM32的项目经验，跑过FreeRTOS或者RT-Thread，甚至自己折腾过一块Linux开发板，移植过驱动、写过字符设备、跑过Qt或者LVGL的界面。按理说，这套组合拳放在传统嵌入式岗位里，不说横着走，至少面试邀约不会少。但一旦把简历投向机器人公司——不管是做移动机器人底盘的、做机械臂控制的，还是做无人机飞控的——很多人会发现一个很尴尬的事实：简历关都过不了。

这不是个别现象。我身边就有好几个这样的朋友，其中一个在某工业控制公司做了六年，STM32的裸机程序写得飞起，RTOS的任务调度和信号量机制烂熟于心，Linux下也能自己编译内核、裁剪根文件系统。他投了十几家机器人公司，从初创到中型企业都有，结果只有两家给了面试机会，其中一家还是因为HR看错了岗位。他跟我吐槽的时候说了一句很典型的话：“我什么都会，为什么连个面试都不给？”

问题恰恰出在这个“什么都会”上。嵌入式老兵的技术栈是真实的，项目经验也是真实的，但这些经验和机器人岗位真正需要的能力之间，存在一道看不见的鸿沟。这道鸿沟不是靠多学一个RTOS或者多跑一个Linux驱动就能填上的。它涉及到知识结构的重组、工程思维的转换，以及对机器人这个特定领域核心问题的理解。

这篇文章就是想把这件事拆开来讲清楚。我会从简历筛选的逻辑、机器人岗位的真实需求、嵌入式老兵常见的认知偏差、以及具体的补全路径这几个角度，把“为什么过不了简历关”这个问题一层层剥开。如果你正好是3到8年的嵌入式从业者，正在考虑往机器人方向转，或者已经投了一轮简历但反馈惨淡，那这篇内容应该能帮你省下不少试错的时间。

2. 简历筛选背后的真实逻辑：HR和技术面试官在看什么

2.1 简历关不是技术关，而是匹配关

很多人有一个误解，觉得简历被刷是因为技术不够强。但实际上，大公司的简历筛选通常分两步：第一步是HR或者招聘系统做关键词匹配和基本条件过滤，第二步才是技术面试官或者团队负责人做技术评估。而绝大多数嵌入式老兵的简历，死在第一步。

HR看简历的逻辑和技术人员完全不同。他们手里通常有一份岗位需求文档，上面列着几个硬性条件，比如“熟悉ROS/ROS2”、“有SLAM或路径规划经验”、“了解运动控制算法”、“有机器人项目落地经验”等等。HR不会去深究你的STM32项目有多复杂，他们只做一件事：在简历里找这些关键词。找不到，或者找到的关联度不够，直接pass。

这就解释了一个现象：一个做了六年工业控制、STM32和RTOS经验丰富的人，简历上如果通篇都是“基于STM32的某某控制系统”、“FreeRTOS任务调度优化”、“Linux字符设备驱动开发”，HR扫一眼，发现没有“ROS”、“SLAM”、“运动规划”、“传感器融合”这些词，就会判定为不匹配。哪怕你实际上在项目里做过电机控制、做过PID调节、用过IMU，只要简历上没有用机器人领域的语言表达出来，就会被过滤掉。

2.2 技术面试官关注的三个核心维度

假设简历侥幸过了HR关，到了技术面试官手里，评估维度又会发生变化。根据我和一些机器人公司技术负责人的交流，他们在看嵌入式背景的候选人时，主要关注三个维度：

第一个维度是实时性和确定性的理解深度。机器人系统对实时性的要求跟普通嵌入式系统不一样。普通嵌入式里，你跑一个RTOS，任务周期可能是10ms或者100ms，偶尔抖动一下问题不大。但在机器人控制里，一个控制循环的周期可能是1ms甚至更短，而且抖动必须控制在很小的范围内。面试官会问你：FreeRTOS的任务切换时间是多少？中断延迟怎么测量？如果控制周期是1ms，你的任务优先级怎么分配？这些问题不是背八股能答好的，需要你对RTOS内核有真正的实操级理解。

第二个维度是对机器人系统架构的认知。很多嵌入式老兵的思维还停留在“一个MCU跑所有逻辑”的阶段。但机器人系统通常是分层架构：底层是实时控制层，跑在MCU或者实时内核上，负责电机控制、传感器读取、安全逻辑；中间是感知和规划层，跑在Linux或者高性能计算平台上，负责SLAM、路径规划、决策；上层是应用层，负责人机交互、任务调度、云端通信。面试官会考察你：你做的模块在整个系统中处于什么位置？它和其他模块怎么通信？数据流和控制流是怎么走的？如果你只知道自己那一亩三分地，说不出上下游的关系，就会被认为缺乏系统思维。

第三个维度是对机器人核心算法的基本了解。你不一定要会推导卡尔曼滤波的公式，但至少要理解它的作用、输入输出、以及在实际系统中怎么用。你不一定要自己写一个SLAM算法，但至少要明白激光雷达或者视觉SLAM的基本原理，知道它输出什么、频率是多少、怎么和控制系统对接。很多嵌入式老兵在这方面是完全空白的，简历上没有任何相关经历，面试时一问三不知，自然过不了。

2.3 一个真实的简历对比案例

我拿两份简历做个对比，都是虚构的，但很典型。

A同学，六年嵌入式经验，简历上写的是：

• 基于STM32F4的工业控制器开发，使用FreeRTOS进行任务调度
• 负责CAN总线通信协议设计和实现
• 移植Linux 4.14内核到某ARM平台，开发SPI和I2C驱动
• 使用Qt开发上位机监控界面

B同学，四年嵌入式经验，简历上写的是：

• 基于STM32H7的移动机器人底盘控制器开发，使用FreeRTOS实现1kHz的电机控制循环
• 负责IMU和轮式编码器的数据采集与融合，输出里程计信息
• 在Linux平台上基于ROS开发底盘驱动节点，通过串口与MCU通信
• 参与激光雷达和超声波传感器的数据接入与避障逻辑实现

从技术深度上看，A同学可能比B同学更强，STM32的底层功底更扎实，Linux驱动经验也更硬核。但B同学的简历在机器人岗位的筛选中几乎完胜。原因很简单：B同学的简历里全是机器人领域的语言——“移动机器人底盘”、“电机控制循环”、“里程计”、“ROS节点”、“避障逻辑”。HR能看懂，技术面试官也能立刻判断出他做过什么、能做什么。

A同学的问题不是技术不行，而是他的简历没有翻译成机器人领域的语言。他的CAN总线通信经验，在机器人里对应的是电机驱动器通信；他的FreeRTOS任务调度经验，对应的是实时控制循环的设计；他的Linux驱动经验，对应的是传感器接入和平台适配。但这些对应关系，他没有在简历里建立起来，HR也不会替他去建立。

3. 嵌入式老兵常见的三个认知偏差

3.1 偏差一：把“会RTOS”等同于“懂实时控制”

很多嵌入式工程师觉得，我用过FreeRTOS，调过任务优先级，处理过优先级翻转，那做机器人实时控制应该没问题。但实际上，RTOS的使用经验和实时控制系统的设计能力之间，差距比想象中大得多。

RTOS的常规使用，比如创建几个任务、用信号量做同步、用队列传数据，这些是应用层面的技能。但机器人实时控制要求的是对时间确定性的极致把控。举个例子：一个移动机器人的底盘控制循环，要求每1ms执行一次，每次执行的时间必须稳定在200微秒以内，抖动不能超过50微秒。这就涉及到一系列深层次的问题：你的任务优先级怎么设？中断服务程序里做了多少事？有没有用DMA来减少CPU干预？内存访问有没有可能引起cache抖动？这些问题的答案，不是靠“用过RTOS”就能给出的。

我见过一个候选人，简历上写着“精通FreeRTOS”，面试时被问到“如果控制周期是500微秒，你会怎么设计任务架构”，他回答的是“把控制任务优先级设为最高，然后用vTaskDelayUntil来保证周期”。这个回答不能说错，但太浅了。面试官期待的是更深入的讨论：比如是否需要用硬件定时器触发中断，在中断里做最紧急的电机换相，然后把非紧急的计算放到高优先级任务里；比如是否要考虑任务切换本身的开销，在500微秒的周期里，任务切换可能就占了几十微秒，是否值得；比如是否需要用双缓冲或者环形缓冲区来避免数据拷贝带来的不确定性。

这些细节，才是机器人岗位面试官真正想听的。而这些东西，在普通的RTOS应用开发中是很少涉及的。

3.2 偏差二：把“跑过Linux”等同于“能做机器人平台开发”

另一个常见的认知偏差是：我在Linux上写过驱动、编译过内核、跑过应用程序，那做机器人的Linux平台开发应该没问题。但实际上，机器人平台开发和通用Linux开发之间，侧重点完全不同。

通用Linux开发，你可能关注的是文件系统、网络协议、进程间通信、多线程编程。但机器人平台开发，关注的是实时性补丁（比如PREEMPT_RT）、传感器时间同步、数据采集的确定性延迟、以及和底层实时控制器的通信。举个例子：在机器人系统里，激光雷达的数据通过以太网或者USB传到Linux平台，然后SLAM算法处理这些数据，输出位姿信息，再通过串口或者CAN发给底层控制器。这个链路里，每一个环节的延迟和抖动都会影响最终的控制效果。你需要知道怎么测量这些延迟，怎么优化数据通路，怎么保证时间戳的准确性。

很多嵌入式老兵在Linux上的经验，停留在“能跑起来”的阶段。他们能移植内核、能写驱动、能编译应用程序，但对Linux的实时性调优、对高精度时间同步、对传感器数据流的实时处理，缺乏实战经验。而这些恰恰是机器人平台开发的核心技能。

3.3 偏差三：把“做过电机控制”等同于“懂机器人运动控制”

第三个偏差更隐蔽。很多嵌入式工程师在工业控制或者消费电子领域做过电机控制，比如用STM32的定时器生成PWM、用PID调节转速、用编码器测速。他们觉得，机器人的运动控制无非也是电机控制，应该能无缝迁移。

但机器人的运动控制，和单纯的电机控制，是两回事。电机控制关注的是单个电机的转速、转矩、位置精度。而机器人的运动控制，关注的是整个机器人本体的运动学建模、动力学约束、多电机协调、以及和上层规划模块的接口。举个例子：一个差速驱动的移动机器人，你要根据目标线速度和角速度，计算出左右轮的转速，这涉及到运动学正逆解。一个机械臂，你要根据末端执行器的目标位姿，通过逆运动学算出每个关节的角度，还要考虑奇异点、关节限位、轨迹平滑等问题。这些内容，在传统的电机控制项目里是完全不涉及的。

我见过一个做了五年电机控制的工程师，PID调参经验非常丰富，但面试机器人岗位时被问到“差速底盘的运动学模型是什么”，他完全答不上来。这不是他的错，因为他之前的项目里确实不需要这些知识。但机器人岗位的面试官会认为，你连最基本的运动学都不了解，怎么放心让你做运动控制？

4. 机器人岗位真正需要的嵌入式能力图谱

4.1 底层实时控制能力

机器人系统的底层，通常是一个或者多个MCU，负责最紧急的实时任务：电机换相、电流环控制、编码器读取、IMU数据采集、安全逻辑处理。这部分对嵌入式的功底要求很高，也是嵌入式老兵最有优势的地方。但优势要发挥出来，需要补充的是机器人特定的知识。

比如电机控制，工业上常用的可能是直流有刷电机或者步进电机，但机器人上大量使用的是无刷直流电机（BLDC）或者永磁同步电机（PMSM）。BLDC的六步换相和FOC（磁场定向控制）是机器人底层控制的标配。你需要理解Clarke变换、Park变换、空间矢量脉宽调制（SVPWM）这些概念，并且知道怎么在MCU上实现。这些内容在传统的嵌入式教材里可能只是一笔带过，但在机器人岗位面试中却是高频考点。

再比如IMU数据采集，工业上可能只需要读取加速度和角速度的原始值，但机器人上通常需要做传感器融合，把IMU和轮式编码器的数据结合起来，输出更准确的里程计信息。这就涉及到卡尔曼滤波或者互补滤波的实现，以及时间戳对齐、坐标系变换等问题。这些也是嵌入式老兵需要补课的地方。

4.2 通信中间件与系统集成能力

机器人系统是一个典型的分布式系统，各个模块之间需要高效、可靠地通信。底层MCU和上层Linux平台之间，通常通过串口、CAN、或者以太网通信。上层各个模块之间，则大量使用ROS/ROS2的通信机制，比如话题（Topic）、服务（Service）、动作（Action）。

嵌入式老兵往往对底层的通信协议很熟悉，比如自己写串口协议、自己定义CAN报文。但机器人领域有一套成熟的通信中间件，你需要学会使用它，而不是重新造轮子。ROS2的DDS通信机制、QoS配置、节点生命周期管理，这些内容对于没接触过的人来说是全新的。而且，嵌入式设备上跑ROS2，还涉及到资源受限环境下的裁剪和优化，比如使用micro-ROS来让MCU接入ROS2生态。这些技能在传统的嵌入式开发中是不涉及的，但在机器人岗位中却是基本要求。

4.3 传感器驱动与数据预处理能力

机器人上搭载的传感器种类繁多：激光雷达、深度相机、IMU、轮式编码器、超声波、红外、力传感器等等。每一种传感器都有自己的接口方式、数据格式、时间同步要求。嵌入式工程师的优势在于，他们通常对底层接口很熟悉，比如I2C、SPI、UART、CAN、USB、以太网。但机器人岗位要求的不只是“能读到数据”，而是“能读到准确、同步、低延迟的数据”。

举个例子：一个激光雷达通过以太网输出点云数据，频率是10Hz，每帧数据量很大。你需要设计一个数据接收和解析的流程，保证不丢包、不乱序、时间戳准确。这涉及到网络编程、缓冲区管理、多线程或者异步IO。再比如，多个传感器的时间同步，可能需要用到PTP（精确时间协议）或者硬件触发信号。这些内容在普通的嵌入式项目中很少涉及，但在机器人系统中却是必须解决的问题。

4.4 对上层算法的基本理解

嵌入式工程师不需要自己实现SLAM或者路径规划算法，但需要理解这些算法的输入输出、运行频率、资源需求，以及它们对底层控制的影响。比如，SLAM模块输出的是机器人的位姿估计，频率可能是10Hz到50Hz，延迟可能在几十毫秒。底层控制模块需要知道这个位姿的置信度和延迟，才能决定怎么使用它。如果SLAM突然丢失，底层控制应该怎么降级处理？这些问题需要嵌入式工程师和算法工程师紧密配合，如果你对上层算法完全不了解，就很难做好这个接口。

5. 从嵌入式到机器人：一份可执行的补全路线

5.1 第一步：用机器人语言重写你的简历

这是最紧急、成本最低、见效最快的一步。不要改你的项目经历，但要改你的表达方式。把你做过的每一件事，都用机器人领域的术语重新描述一遍。

比如，你做过一个基于STM32的数据采集系统，用了FreeRTOS和CAN总线。原来的写法可能是：“基于STM32F4和FreeRTOS开发数据采集系统，通过CAN总线与多个节点通信。”改成机器人领域的写法：“基于STM32F4和FreeRTOS开发机器人底层控制器，实现1kHz的传感器数据采集循环，通过CAN总线与电机驱动器和IMU模块通信，为上层导航模块提供实时状态反馈。”

再比如，你移植过Linux内核，写过SPI驱动。原来的写法是：“移植Linux 4.14内核到ARM平台，开发SPI和I2C驱动。”改成：“在ARM Linux平台上完成内核移植和传感器驱动开发，实现激光雷达和IMU的数据接入，为SLAM模块提供原始数据流。”

这种改写不是造假，而是把你的经验翻译成目标岗位能理解的语言。HR和技术面试官看到这样的简历，才会认为你的经验和机器人相关，才会给你面试机会。

5.2 第二步：补上机器人运动学和动力学的基础

不需要学到能推导公式的程度，但至少要理解基本概念和常用模型。推荐从差速底盘的运动学模型入手，这是最简单的，也是移动机器人最常用的。理解线速度、角速度和左右轮转速之间的关系，理解里程计的计算方法。然后可以看看阿克曼转向模型、全向轮模型。如果是机械臂方向，就从DH参数和逆运动学开始。

学习方式建议：找一本机器人学的基础教材，比如《现代机器人学》或者《机器人学导论》，重点看运动学部分。同时，在GitHub上找一个开源的差速底盘控制器项目，把代码读一遍，看看运动学模型是怎么实现的。理论加代码，理解会快很多。

5.3 第三步：上手ROS/ROS2，做一个完整的demo

ROS是机器人领域的事实标准，不会ROS，基本上很难找到机器人开发岗位。但学习ROS不要停留在看教程、跑例程的阶段，要做一个完整的、能说明问题的demo。

我的建议是：用一台差速底盘（可以是真实的，也可以是Gazebo仿真），实现一个完整的闭环。底层用STM32或者树莓派做电机控制和编码器读取，跑一个实时控制循环。上层用ROS2，写一个底盘驱动节点，发布里程计话题，订阅速度指令话题。然后跑一个SLAM节点，比如slam_toolbox或者cartographer，建一张地图。最后跑一个导航节点，让机器人自主导航到目标点。

这个demo做下来，你会接触到机器人系统的完整数据流：传感器数据采集、底层控制、通信中间件、SLAM、路径规划、导航控制。你会遇到各种问题：时间同步、坐标系变换、通信延迟、参数调优。这些问题和解决过程，就是你面试时最好的素材。

5.4 第四步：深入一个方向，建立差异化优势

机器人岗位有很多细分方向：底盘控制、机械臂控制、无人机飞控、传感器驱动、系统集成等等。嵌入式老兵的优势在底层，所以建议从底盘控制或者传感器驱动入手，先建立根据地，再向外扩展。

底盘控制方向，需要深入的是：BLDC/PMSM的FOC控制、多电机协调、运动学正逆解、里程计融合、实时控制循环设计。传感器驱动方向，需要深入的是：激光雷达/深度相机的数据接入、时间同步、点云预处理、多传感器标定。选一个方向，做到能独立完成一个模块的设计和实现，这样在面试时才有深度可讲。

5.5 第五步：积累机器人领域的项目经验

如果你现在的公司没有机器人项目，那就自己造一个。开源项目是最好的切入点。你可以参与一些知名的开源机器人项目，比如ROS2的某个驱动包、某个SLAM算法的优化、某个仿真环境的搭建。参与开源项目的好处是，你的贡献是公开可查的，面试时可以直接展示。

如果时间有限，也可以自己做一个完整的个人项目，从硬件选型、电路设计、嵌入式开发、ROS集成到算法调试，全部走一遍。这个项目不需要很复杂，但一定要完整，要能体现出你对机器人系统的整体理解。

6. 面试中高频出现的五个问题及应对思路

6.1 “你做过机器人相关的项目吗？”

这个问题几乎是必问的。如果你没有直接做过机器人项目，不要硬编，但也不要简单回答“没有”。你可以这样组织回答：先承认没有直接做过机器人整机项目，然后说明你在之前的项目中做过哪些和机器人底层控制相通的事情，比如实时控制循环、电机控制、传感器数据采集、通信协议设计。接着说明你为了转机器人方向做了哪些准备，比如自学了ROS2、做了差速底盘的demo、研究了运动学模型。最后表达你对机器人领域的理解，以及你认为自己的嵌入式功底能怎么迁移过来。

这个回答的逻辑是：承认差距，展示迁移能力，证明学习意愿和行动力。面试官通常能接受没有直接经验但准备充分的候选人，但不能接受既没有经验又没有准备的人。

6.2 “如果控制周期是1ms，你怎么设计任务架构？”

这是考察实时控制能力的经典问题。回答时不要只讲RTOS的任务优先级，要展开讲整个控制循环的设计。可以从这几个方面入手：硬件层面，用哪个定时器触发中断，中断里做哪些最紧急的事；RTOS层面，任务怎么划分，优先级怎么分配，任务间怎么通信；算法层面，电流环、速度环、位置环的执行频率怎么分配，哪些放在中断里，哪些放在任务里；优化层面，怎么用DMA减少CPU干预，怎么用双缓冲避免数据拷贝，怎么测量和优化抖动。

回答时最好能结合你实际做过的项目，给出具体的参数和测量结果。比如“我在之前的项目里，用TIM1触发中断，中断里做电流采样和SVPWM输出，耗时大约15微秒。速度环和位置环放在一个优先级最高的任务里，用vTaskDelayUntil保证1ms周期，实测抖动在20微秒以内。”这样的回答才有说服力。

6.3 “ROS2的通信机制了解吗？QoS怎么配置？”

这是考察系统集成能力的问题。你需要了解ROS2的DDS底层、话题/服务/动作的区别、QoS策略的含义和配置方法。重点要理解QoS中的可靠性（Reliability）、持久性（Durability）、历史（History）、深度（Depth）这几个策略，以及它们在不同场景下的选择。比如传感器数据通常用Best Effort，控制指令通常用Reliable。如果能在回答中结合你在实际项目中遇到的通信问题，比如丢包、延迟、乱序，以及你怎么通过QoS配置解决的，那就更好了。

6.4 “IMU和轮式里程计怎么融合？”

这是考察传感器融合能力的问题。你需要了解卡尔曼滤波或者互补滤波的基本原理，知道状态方程和观测方程怎么建立，知道怎么调参。更重要的是，你要能说清楚在实际系统中怎么实现：IMU和编码器的时间戳怎么对齐，坐标系怎么统一，融合后的里程计怎么发布给上层。如果你做过实际的融合项目，把调试过程中遇到的问题和解决方法讲出来，比如IMU的零偏怎么校准、轮式里程计的标定怎么做、融合后的轨迹怎么评估，这些都是加分项。

6.5 “你对我们公司的机器人产品有什么了解？”

这是考察你对该岗位的诚意和准备程度。面试前一定要做功课，了解这家公司的机器人产品是什么形态、用什么技术栈、解决什么问题。如果可能的话，找到他们的技术博客或者开源项目，了解他们的技术路线。回答时不要泛泛而谈，要具体到他们的产品和技术，说明你的哪些经验和他们的需求匹配，你能为他们解决什么问题。这个问题回答好了，能很大程度上弥补项目经验的不足。

7. 一些实操层面的避坑建议

7.1 不要试图在简历上堆砌所有关键词

我见过一些候选人，为了过HR关，在简历上堆了一大堆机器人相关的关键词，但每个都只是“了解”或者“接触过”。这种做法风险很大，因为技术面试官一眼就能看出来哪些是真正做过的，哪些是临时补的。一旦被问到细节答不上来，反而会留下不好的印象。正确的做法是：选两到三个你真正有深入理解的方向，用具体的项目经历来支撑，其他方向可以提，但不要作为重点。

7.2 不要忽视C++和Linux系统编程

机器人领域的上层开发，大量使用C++和Linux。如果你的C++停留在C with class的水平，Linux只会几个基本命令，那即使过了简历关，面试也会很吃力。建议花时间补一下现代C++（C++11/14/17）的常用特性，比如智能指针、lambda、多线程、移动语义。Linux方面，重点掌握多线程编程、进程间通信、网络编程、性能调优工具。这些内容在机器人岗位的笔试和面试中出现的频率很高。

7.3 不要只盯着大公司

机器人行业的头部公司竞争非常激烈，对候选人的要求也很高。如果你刚转方向，项目经验还不够丰富，可以考虑先从中小型机器人公司或者机器人相关的创业公司入手。这些公司通常更看重实际能力，对学历和背景的要求相对宽松，而且你能接触到更完整的系统，成长速度更快。等积累了一两年机器人项目经验，再跳到大公司，成功率会高很多。

7.4 不要停止动手

嵌入式工程师最大的优势就是动手能力强。在转机器人的过程中，这个优势不能丢。看再多的书、学再多的理论，如果不自己动手做一个完整的机器人系统，就很难真正理解其中的细节和难点。我的建议是：给自己定一个项目目标，比如“用三个月时间做一个能自主导航的差速底盘”，然后围绕这个目标去学习、去实践。做的过程中会遇到各种问题，解决这些问题的经验，就是你面试时最宝贵的素材。

7.5 关于时间投入的预期管理

从嵌入式转到机器人，不是一两个月能完成的事情。如果你每天能投入两到三个小时，周末能投入一整天，大概需要六到十二个月才能达到能通过机器人岗位面试的水平。这期间你需要学ROS2、做项目、补理论、改简历、准备面试。这个过程会很辛苦，但每一步的投入都会有回报。最重要的是保持耐心，不要因为投了几份简历没回音就放弃。简历被刷是常态，关键是从反馈中调整策略，持续改进。

8. 一个虚构的转行时间线参考

假设A同学，五年嵌入式经验，STM32和FreeRTOS很熟，Linux会用但不深入，没有机器人项目经验。他给自己定了一个八个月的转行计划。

第一个月到第二个月：每天下班后花两小时学ROS2，从官方教程开始，跑通基本的话题发布订阅、服务调用、参数配置。周末用Gazebo仿真一个差速底盘，写一个简单的速度控制节点。同时开始改简历，把之前的项目经验用机器人语言重新描述。

第三个月到第四个月：买了一套真实的差速底盘套件，包括STM32主控、电机驱动器、编码器、IMU、激光雷达。开始做底层控制，用FreeRTOS实现1kHz的电机控制循环，通过串口和上位机通信。上位机跑ROS2，写底盘驱动节点，发布里程计和IMU数据。这个阶段会遇到很多问题：串口通信丢包、时间戳不同步、坐标系对不上。一个个解决，记录下来。

第五个月到第六个月：在底盘上跑SLAM，先用slam_toolbox，再用cartographer。调参、建图、评估精度。然后跑导航，用Nav2，配置代价地图、规划器、控制器。让机器人能自主导航到指定点。这个阶段会深刻理解机器人系统的数据流和各个模块之间的关系。

第七个月到第八个月：整理项目文档，把做的过程、遇到的问题、解决的方法写成技术博客。更新简历，把项目经验写进去。开始投简历，先投中小公司练手，积累面试经验。根据面试反馈，查漏补缺，重点补C++和Linux系统编程。同时继续优化项目，比如加入多传感器融合、加入动态避障。

这个时间线是理想情况下的参考，实际执行中可能会有各种延误。但核心思路是：理论学习和动手实践交替进行，用项目驱动学习，用面试反馈调整方向。八个月后，A同学的简历上就有了完整的机器人项目经验，面试时也有具体的技术细节可以讲，通过率会大大提高。

9. 最后说几句实在的

嵌入式转机器人，难的不是技术本身，而是知识结构的重组和表达方式的转换。你的STM32功底、RTOS经验、Linux技能，在机器人领域都是有用的，但需要重新组织、重新表达。简历被刷不代表你不行，只代表你的简历没有把你的能力翻译成目标岗位能理解的语言。

我见过太多嵌入式工程师，技术很扎实，但因为简历上全是“工业控制”、“数据采集”、“通信协议”这些词，被机器人公司的HR直接过滤掉。也见过一些技术深度一般，但简历上全是“机器人底盘”、“ROS节点”、“传感器融合”的候选人，拿到了面试机会，然后在面试中展现出真实水平，最终成功转行。

所以，如果你真的想往机器人方向走，从现在开始，做三件事：第一，把你的简历用机器人语言重写一遍；第二，动手做一个完整的机器人项目，哪怕是最简单的差速底盘；第三，系统地补一下机器人运动学、ROS2、传感器融合这些基础知识。这三件事做下来，少则半年，多则一年，你就能跨过那道看不见的门槛。

这个过程不会轻松，但每一步都算数。我在这个领域见过太多从嵌入式转过来的人，最后都做得很好。他们的共同点是：动手能力强、学习意愿高、愿意花时间补短板。如果你也是这样的人，那机器人行业的大门迟早会为你打开。