最近海尔发布了一款名为“AI厨天才”CR3的全自主家用AI烹饪机器人官方宣传的核心点有两个一是能够模仿大厨的颠勺手法二是支持蒸汽自清洁。对于普通消费者这只是一台智能厨电新品但对于开发和机器人技术从业者来说这个产品背后涉及的感知、决策、运动控制、交互设计和清洗维护几乎是家用机器人从“能对话”走向“能干活”的完整缩影。本文不打算做产品评测而是从技术视角拆解这类烹饪机器人可能采用的关键技术并给出一个可以运行的最小原型示例帮助大家理解一台厨房里的机器人到底是怎么把“颠勺”这种看似简单的动作落地的。如果你正在关注 AI 机器人应用开发、ROS2 机器人开发、运动控制算法或机器人仿真平台选型这篇文章可以作为一份工程笔记来读。1. 为什么一台会颠勺的厨房机器人值得关注烹饪是一个典型的“非结构化任务”食材大小不一、锅具位置浮动、火候动态变化、油烟和蒸汽干扰视觉、操作空间又相对狭窄。过去工业机械臂能完成焊接、喷涂、搬运是因为任务环境和目标物体都高度标准化。而“炒菜”这件事天然考验机器人的环境感知、柔性控制和任务规划能力。“颠勺”更是一个技术难点。大厨颠勺不只是把食材抛起来再接住而是通过手腕和手臂的配合让食材在锅内翻转、受热均匀同时利用火焰窜入锅底形成“锅气”。机械臂要模拟这个动作需要解决三件事轨迹生成生成类似手腕翻转的末端轨迹通常是圆弧加抛物线组合。动态控制食材抛起后锅在落点附近要有一个缓冲跟随不能硬接。感知闭环视觉或力传感器需要判断食材位置、锅内重量变化再修正下一轮颠勺参数。从这个角度看海尔 CR3 的发布代表家用机器人开始从“扫地、对话”这类简单交互走向“物理操作 复杂算法 感知闭环”的深水区。这也是为什么一个厨电产品能成为机器人技术圈的讨论话题。另外蒸汽自清洁这个功能听起来偏硬件但它本质上是一个“任务执行后的闭环”机器人需要知道什么时候烹饪结束、内部有哪些残留污染物、蒸汽温度和时长如何设定、清洁后如何烘干。这背后同样是一套状态管理与传感器逻辑。所以把烹饪机器人当作一个完整的智能体来看比单纯把它当家电更合适。2. “AI厨天才”CR3背后的技术定位在展开技术细节之前先把产品定位梳理清楚。根据公开信息CR3 的核心卖点是“全自主家用 AI 烹饪机器人”主打“模仿大厨颠勺手法”和“蒸汽自清洁”。由于官方未公布完整硬件规格本文提到的技术栈属于行业常见方案和工程推测最终参数请以官方发布为准。从技术定位上可以把这类产品拆成四个能力层次能力层次技术目标典型实现手段感知层识别食材、锅具、火候、油烟状态RGB 摄像头、深度相机、温度传感器、气味传感器决策层根据菜谱生成烹饪步骤与参数菜谱知识库、任务规划器、规则引擎与大模型结合执行层控制机械臂和锅具完成翻炒、颠勺、出锅机械臂运动学、轨迹规划、力控、PID 或模型预测控制交互与服务层语音交互、App 控制、自清洁、安全检测语音识别、状态反馈、清洁水路设计与传感器联动“全自主”这三个字重点指决策层和执行层不需要人为干预。用户可能只需要选择菜谱、放入食材机器人自己完成后续的识别、下锅、翻炒、调味、出锅和清洗。注意这里面有一个很容易被忽略的问题所谓的全自主并不是简单“执行固定脚本”而是要在每个烹饪周期里根据食材状态进行调整。比如炒青菜和炒土豆丝需要的加热时间完全不同即使同一道菜食材切得厚一点或薄一点烹饪时间也要相应变化。这就意味着机器人不能只按固定时序执行而是需要“感知-决策-执行-再感知”的循环控制。从开发者的角度看这种产品很适合作为“AI 机器人应用开发”的学习样本。它的算法栈覆盖了计算机视觉、运动规划、控制理论、嵌入式和云端联动几乎每个环节都能单独深入研究。3. 家用AI烹饪机器人的核心架构拆解下面从工程实现的角度把烹饪机器人拆成四个核心模块来讲。这样更容易理解为什么一台“会炒菜的机器人”需要同时具备那么多算法能力。3.1 感知层识别食材、火候与锅气感知层是烹饪机器人的眼睛和鼻子。常见配置包括顶部或侧面 RGB 摄像头用于识别食材种类、颜色、数量。深度相机用于估计食材在锅内的位置和堆叠高度。红外温度传感器用于检测锅底温度和食材表面温度。称重模块或力矩传感器用于感知锅内食材重量变化。在烹饪场景里视觉识别最大的挑战不是“知道这是番茄”而是“判断番茄的状态”。比如番茄是完整的、切块的还是已经炒出汁水的酱汁浓稠度如何这类细粒度状态识别仅靠分类模型很难完成通常需要使用语义分割或实例分割模型来看到食材的区域轮廓。一个更实际的方案是“多模态融合”视觉负责粗粒度状态判断温度传感器负责火候称重模块负责判断水分蒸发程度。当视觉图像因为油烟受到干扰时温度和时间数据仍然能维持决策可靠性。火候识别也是一个典型问题。中式烹饪里的“大火”“中火”“小火”不是精确温度值而是锅气、油烟状态、食材颜色的综合表现。工程上常见的做法是把锅底温度和红外图像结合建立一组“火候状态概率模型”再映射到加热功率和时间参数上。3.2 决策层菜谱知识库与任务规划决策层相当于烹饪机器人的大脑。它需要回答三个问题当前菜谱需要哪些步骤每一步的结束条件是什么如果食材状态和标准菜谱不一致怎样调整参数菜谱知识库通常不是简单文本而是一套结构化的“烹饪状态机”。每个步骤包含触发条件、动作参数和完成条件。例如“煸炒五花肉”这一步骤触发条件是“油温达到指定温度”动作参数是“机械臂翻炒频率 1Hz持续 120 秒”完成条件是“肉片表面颜色变化达到预设阈值”。在这个基础上如果引入大语言模型还可以实现更自然的交互。用户说“今天想吃辣一点的”系统可以自动调整菜谱中的辣椒用量和后段加热时间。但这里要注意大模型输出不能直接作为机械臂控制指令必须经过任务规划器转换成可执行的动作序列并且加上安全校验。一个推荐的做法是用传统状态机作为“安全骨架”用 AI 模型作为“参数调节器”。状态机保证任务边界AI 模型在边界内生成参数。这样既保留灵活性又不会出现大模型幻觉导致的危险操作。3.3 执行层模仿大厨颠勺的运动控制执行层是烹饪机器人的“手”。颠勺这个动作在机器人运动控制里属于“周期性连续轨迹跟踪 动态负载扰动抑制”问题。先来看简单的颠勺运动模型。大厨颠勺时锅的运动轨迹可以近似分解为水平方向的往复平动让食材在锅内滑动。垂直方向的前后移动让食材抛离锅底。手腕的俯仰角变化让食材在空中翻转。在机器人上实现时可以把锅具末端轨迹规划成一条“椭圆弧 修正抛物线”。其中圆弧负责带动食材滑动到锅的前缘抛物线阶段让食材离开锅面落回时锅身主动向前接住。为了模仿得自然还需要在机器人控制中加入“柔性”参数比如在落锅瞬间降低关节加速度避免食材被弹飞。从算法角度看常见的实现路线有三类实现路线特点适用阶段轨迹插补 PID 跟踪简单、稳定原型验证动力学前馈 阻抗控制适合有外力交互颠勺接锅修正模仿学习 / 强化学习动作更自然高端产品迭代模仿大厨手法本质上是希望获得一条更柔顺的轨迹和速度曲线。传统 PID 控制往往会把动作做得僵硬因为控制目标是“严格跟踪预设轨迹”而不是“像人一样顺应锅和食材的物理特性”。所以产品宣传中提到的“模仿大厨颠勺手法”很可能是在轨迹生成层用了模仿学习在执行层使用了阻抗或导纳控制。具体到代码实现最关键的一点是颠勺轨迹不能只规划末端位置还要规划末端姿态和速度曲线。下面第 4 节会给出一个简化示例。3.4 交互与自清洁从“能做饭”到“好打理”自清洁功能看起来简单实际是一个典型的“执行后闭环”案例。蒸汽自清洁需要考虑几个工程问题清洁检测如何判断锅具和腔体已经被污染通常通过红外传感器检测油污面积或通过运行时间估算污染程度。蒸汽生成与喷洒加热盘产生蒸汽后需要控制蒸汽方向覆盖锅具表面同时避免破坏已完成的菜。排水与烘干蒸汽清洗后的废水需要排入污水箱残留水分需要烘干避免细菌滋生。安全互锁清洁过程中蒸汽温度很高必须确保机械臂处于安全位置用户不能误触。这个模块和机器人核心算法关系不大但它的价值在于验证了“一套系统能否完整覆盖繁琐的日常维护”。很多机器人项目实验室跑得很好产品落地后却因为维护成本高而失败自清洁就是解决这个问题的关键设计之一。4. 开发者视角如何从零复现一个“颠勺机器人”原型硬件机器人的研发门槛很高但我们可以用软件原型来理解核心技术。下面我写一个简化版“颠勺机器人原型”用 Python 模拟二连杆机械臂生成颠勺轨迹再叠加视觉识别和任务状态机。建议你跟着代码跑一遍这样对烹饪机器人的整体工作流会有更直观的感受。本文示例不依赖真实硬件只需要 Python 3.9 环境以及 numpy、opencv-python 两个库。安装命令如下pip install numpy opencv-python如果你用的是 Conda可以这样创建环境conda create -n cooking_robot python3.9 conda activate cooking_robot pip install numpy opencv-python版本不需要完全一致示例以常见环境为准重点演示设计思路。4.1 创建项目结构先建一个清晰的项目目录方便后续扩展cooking_robot/ ├── main.py # 主程序入口 ├── arm.py # 二连杆机械臂正运动学与可视化 ├── trajectory.py # 颠勺轨迹生成 ├── vision.py # 视觉识别食材OpenCV 示例 ├── task_state_machine.py # 烹饪任务状态机 └── assets/ └── tomato.jpg # 测试图片可以自己准备每个文件职责单一。这样以后替换算法模块时不需要改动整个项目。4.2 用Python模拟二连杆机械臂先实现一个最简单的“二连杆机械臂”模型。真实烹饪机器人可能不止两个关节但二连杆足以演示正运动学和轨迹生成的基本思想。# 文件路径cooking_robot/arm.py import math class TwoLinkArm: def __init__(self, link1_length0.4, link2_length0.35): self.l1 link1_length self.l2 link2_length def forward_kinematics(self, theta1, theta2): 根据两个关节角计算末端位置。 参数 theta1: 肩关节角度弧度 theta2: 肘关节角度弧度 返回 (x, y) 末端坐标单位米 x self.l1 * math.cos(theta1) self.l2 * math.cos(theta1 theta2) y self.l1 * math.sin(theta1) self.l2 * math.sin(theta1 theta2) return x, y def plot_trajectory(self, trajectory_points): 可视化轨迹点这里只打印关键点真实项目可以接入 matplotlib。 for i, (x, y) in enumerate(trajectory_points): if i % 20 0: print(fstep {i}: end position ({x:.3f}, {y:.3f}))正运动学是机械臂控制的基础。它的作用是根据关节角度计算机器人末端在空间中的位置。如果我们想要末端走出某条颠勺轨迹第一步就是把轨迹点转换成关节角度这属于逆运动学问题。二连杆的逆运动学有解析解但为了控制轨迹平滑度通常在算法层直接做“笛卡尔空间轨迹规划”。4.3 生成颠勺轨迹下面实现一个颠勺轨迹生成器。它的思路是在锅具末端坐标系里先生成一条“圆弧 抛物线”的混合轨迹。垂直方向加入一个向上的抛起分量再让末端在落点用一个下压动作接住食材。# 文件路径cooking_robot/trajectory.py import math import numpy as np def generate_toss_trajectory(duration2.0, steps100): 生成一个简化版颠勺轨迹。 轨迹分为三个阶段 1. 后拉阶段末端向后移动让食材滑向锅前缘。 2. 抛起阶段垂直向上加速模拟食材抛起。 3. 接住阶段末端向前下方运动缓冲接住食材。 返回 numpy.ndarrayshape(steps, 3)每一行为 (x, z, theta) 其中 theta 为手腕俯仰角弧度。 t np.linspace(0, duration, steps) # 水平方向先向后再向前 x 0.15 * np.sin(2 * math.pi * t / duration) # 垂直方向后半段加入一个抛物线 z np.zeros_like(t) for i in range(steps): # 在 40%-80% 时间段执行抛起动作 if 0.4 t[i] 0.8: phase (t[i] - 0.4) / 0.4 z[i] 0.06 * math.sin(math.pi * phase) # 手腕俯仰角简化模拟抛起时前倾接住时回正 theta np.zeros_like(t) for i in range(steps): if 0.4 t[i] 0.8: phase (t[i] - 0.4) / 0.4 theta[i] -0.3 * math.sin(math.pi * phase) return np.column_stack([x, z, theta])这个示例只生成了轨迹没有做动力学校验。真实项目里还需要考虑机械臂最大加速度和负载能力否则轨迹可能无法跟踪。4.4 视觉识别食材OpenCV示例烹饪机器人识别食材的工业级方案通常是用训练好的深度模型进行目标检测或分割。这里我用 OpenCV 的颜色检测做一个简化版示例目标是检测出图像中的“红色食材边界”。这个示例主要用于理解“视觉反馈如何参与任务判断”。# 文件路径cooking_robot/vision.py import cv2 import numpy as np def detect_red_food(image_path): 检测图像中的红色食材示例番茄、辣椒。 image cv2.imread(image_path) if image is None: raise FileNotFoundError(f无法读取图片{image_path}) hsv cv2.cvtColor(image, cv2.COLOR_BGR2HSV) # 红色在 HSV 空间中会分布在两个区间因此需要合并两个掩码 lower_red1 np.array([0, 80, 80]) upper_red1 np.array([10, 255, 255]) lower_red2 np.array([170, 80, 80]) upper_red2 np.array([180, 255, 255]) mask1 cv2.inRange(hsv, lower_red1, upper_red1) mask2 cv2.inRange(hsv, lower_red2, upper_red2) mask cv2.bitwise_or(mask1, mask2) # 计算红色区域面积占比用于后续决策 total_pixels mask.shape[0] * mask.shape[1] red_ratio cv2.countNonZero(mask) / total_pixels # 绘制轮廓方便调试 contours, _ cv2.findContours(mask, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_SIMPLE) for cnt in contours: cv2.drawContours(image, [cnt], -1, (0, 255, 0), 2) cv2.imwrite(vision_result.jpg, image) return red_ratio if __name__ __main__: # 需要准备一张包含番茄或辣椒的图片 ratio detect_red_food(assets/tomato.jpg) print(f红色食材面积占比{ratio:.2%})这个颜色检测示例在生产环境会非常脆弱因为厨房灯光复杂同一个番茄在不同光线下颜色差异很大。真实项目通常会在这一步之后接一个深度学习分割模型但 OpenCV 版本的好处是零依赖、便于快速验证流程。4.5 烹饪任务状态机最后把轨迹生成、机械臂模拟和视觉感知串联成一个简单的烹饪任务状态机。# 文件路径cooking_robot/task_state_machine.py import time from arm import TwoLinkArm from trajectory import generate_toss_trajectory class CookingStateMachine: def __init__(self): self.state INIT self.arm TwoLinkArm() self.recipe_steps [HEAT_OIL, THROW_INGREDIENTS, SEASONING, PLATE] self.current_step 0 def run(self): print(烹饪任务开始) while self.current_step len(self.recipe_steps): step self.recipe_steps[self.current_step] print(f当前步骤{step}) if step HEAT_OIL: # 模拟等待油温到达目标温度 print(检测油温...) time.sleep(0.5) print(油温达到 180℃) elif step THROW_INGREDIENTS: # 生成颠勺轨迹并让机械臂末端按轨迹运动 print(生成颠勺轨迹...) trajectory generate_toss_trajectory() # 这里只是示例将轨迹的第一个点输入机械臂模型 x, z, theta trajectory[0] end_x, end_y self.arm.forward_kinematics(theta, 0.2) print(f末端位置({end_x:.3f}, {end_y:.3f})颠勺开始) elif step SEASONING: print(添加调味料) time.sleep(0.3) elif step PLATE: print(出锅装盘) time.sleep(0.3) self.current_step 1 self.state FINISHED print(烹饪任务完成) if __name__ __main__: machine CookingStateMachine() machine.run()运行这个文件你会看到控制台输出逐步执行了“热油、下料、调味、出锅”四个步骤。虽然它没有驱动真实机械臂但已经具备了一个机器人任务系统的基本框架状态流转、动作生成、简单模拟反馈。cd cooking_robot python task_state_machine.py输出效果类似于烹饪任务开始 当前步骤HEAT_OIL 检测油温... 油温达到 180℃ 当前步骤THROW_INGREDIENTS 生成颠勺轨迹... 末端位置(0.500, 0.537)颠勺开始 当前步骤SEASONING 添加调味料 当前步骤PLATE 出锅装盘 烹饪任务完成这个原型还可以继续扩展比如把真实摄像头图像加入视觉模块或者用 ROS2 的话题机制替换当前的状态机流程。下面简单聊一下仿真平台怎么选。5. 机器人仿真平台怎么选做真实机器人硬件成本高、周期长所以绝大多数机器人算法开发会先走仿真。CR3 这类烹饪机器人如果要做算法验证同样需要一套合适的仿真环境。当前机器人圈常用的仿真平台各有侧重仿真平台特点适用场景Gazebo ROS2物理引擎成熟支持传感器建模机械臂与移动底盘集成仿真MuJoCo接触动力学好运行速度快灵巧操作、颠勺这类接触任务PyBullet安装简单Python 接口友好算法快速验证与教学Isaac Sim基于 NVIDIA Omniverse仿真逼真度高视觉 机器人联合仿真对于烹饪机器人我个人建议优先关注 MuJoCo 和 PyBullet。原因是烹饪过程中的“食材抛接”“锅具接触”非常依赖接触动力学而这两个平台在接触仿真上的效率比 Gazebo 更高。如果你希望同时仿真机械臂和移动底盘比如一个从冰箱取菜再走到灶台的机器人那用 Gazebo ROS2 更合适。ROS2 是另一个绕不开的话题。产品的感知、决策、控制在不同进程之间交互时ROS2 的节点通信机制非常适合做模块解耦。比如视觉节点发布“食材状态”话题规划节点订阅后生成轨迹控制节点再执行轨迹。每个节点可以独立开发、独立测试线上排查时也能快速定位问题。版本方面ROS2 有 Humble、Iron、Jazzy 等多个长期支持版本需要根据你的 Ubuntu 系统和机器人硬件来选。现在不用急着安装先理解它的通信模型等真正做机器人项目时再按官方文档安装即可。6. 常见问题与排查思路在实际开发烹饪机器人相关算法或原型时常见的坑有不少。下面整理几个高频问题并给出排查思路。问题现象常见原因解决思路仿真中机械臂抖动剧烈控制周期过长或高频噪声降低步长检查控制频率与传感器噪声识别食材不准确训练数据与现场光照差异大增加数据增强用域随机化训练颠勺轨迹生成后落点偏差大忽略负载质量和重心变化加入负载估计与轨迹在线修正机械臂突然撞到锅沿只做了位置规划没做碰撞检测开启碰撞检测增加安全包围盒蒸汽自清洁后仍有残留味道清洁温度和时长不足增加传感器反馈建立清洁残留判定逻辑ROS2 节点启动后消息不互通Topic 名称或消息类型不一致使用 ros2 topic list 和 ros2 topic info 检查大模型生成的菜谱步骤无效大模型输出训练数据中的开源菜谱不适配机械结构增加菜谱校验层过滤动作参数先看“仿真中机械臂抖动剧烈”这个问题。很多人会直接调 PID 参数但发现怎么调都不理想。实际上先检查仿真步长和控制周期是否匹配。如果物理仿真步长是 1ms控制器的调用频率只有 10Hz那中间 90ms 完全没有反馈机械臂自然容易振。推荐先把控制频率提到 100Hz 以上再调 PID。“识别食材不准确”也是项目中常遇到的问题。颜色检测方案在实验室环境效果很好但到了真实厨房灯光变成暖色阴影变多同一个阈值可能完全失效。工业界现在主要用域随机化在仿真环境里渲染大量不同光照、不同纹理的食材图片训练出的模型再迁移到真实场景效果会稳定很多。颠勺轨迹落点偏差需要重点解释。简化算法以为食材是一个质点忽略食材在锅里的分布和重量变化。实际烹饪过程中食材会因为水分蒸发而变轻也可能因为水油飞溅而改变摩擦系数。工程做法是在锅具上安装力传感器实时估算食材重量然后在每一轮颠勺前修正抛物线高度和落点。如果你准备用 ROS2 开发这类系统建议提前掌握几条排查命令# 查看所有话题 ros2 topic list # 查看某个话题的消息类型 ros2 topic info /cook_robot/trajectory # 实时打印话题数据 ros2 topic echo /cook_robot/trajectory # 查看节点信息 ros2 node info /cook_robot/control大部分 ROS2 通信问题最后都能通过确认“话题名是否一致”“消息类型是否匹配”“发布频率是否正常”来解决。7. 工程落地的安全与最佳实践烹饪机器人涉及高温、刀具、餐具和用户交互安全边界比普通机械臂项目更严格。无论你是在做原型还是产品下面这些工程建议都值得提前考虑。第一安全设计要分层。机器人不能只依赖一个急停按钮。从上到下至少需要四层安全机制电流/力矩保护关节电机电流超阈值立即停止或减速。碰撞检测通过力矩传感器或电流观测器判断碰撞遇到人或其他物体时主动回退。运动边界限制把机械臂活动范围限制在灶台区域内不进入用户操作区域。热源互锁检测到火焰或高温锅具时限制机械臂靠近速度并开启急停预案。第二控制模块要保证确定性。AI 决策可以不确定但底层执行必须可控。推荐把系统架构拆成两层上层 AI 生成意图下层状态机执行动作。这种设计即使上层模型出现幻觉下层也能拦截无效指令。例如大模型说“颠勺 200 次”任务规划器需要判断这个参数是否超出机械臂安全边界如果超出就自动截断或请求确认。第三数据闭环和隐私要同时兼顾。家用机器人会不断采集厨房图像、食材信息、用户偏好甚至能判断用户饮食习惯。这些数据对提升 AI 模型很有价值但必须做隐私保护。建议在设备端完成敏感图像处理只把抽象后的菜谱状态上传云端上传的数据要做脱敏处理并且让用户能查看、删除历史记录。第四日志和可观测性不可忽视。机器人不像普通软件出问题后可能伴随着物理损坏。现场日志至少要记录每个控制周期的关节角度、速度、力矩。视觉识别结果和置信度。状态机的每次状态切换。异常触发点和急停原因。这些日志能在机器人“翻车”之后帮你快速复现问题。建议使用结构化的 JSON 日志方便后续分析。第五调试接口要保留。很多项目初期只做算法等硬件联调时才发现缺少手动示教模式。建议在软件架构上预留“手动示教”和“自动执行”两种模式。手动示教可以通过拖动机械臂来记录轨迹自动执行再套用强化学习或运动规划算法优化。8. 总结与后续学习建议这篇文章从海尔“AI厨天才”CR3 的发布切入聊了家用 AI 烹饪机器人的四层技术架构感知、决策、执行和自清洁。然后通过一个 Python 原型示例演示了机械臂正运动学、颠勺轨迹生成、视觉识别和任务状态机的基本写法。最后给出了仿真平台选型和常见问题排查思路。对于想进入 AI 机器人领域的朋友我给三个学习建议。第一先把仿真的基础打牢。真机调试成本高仿真环境让你可以随意重置状态、注入噪声、打印数据。建议从 PyBullet 或 MuJoCo 选择一个开始把机械臂的“正逆运动学 轨迹跟踪”跑通再考虑颠勺这类动态任务。第二不要跳过 ROS2 通信机制。机器人系统最终要落到多模块协作上ROS2 的节点通信、参数服务器、Launch 文件都是工程化必备技能。初学者可以先跑官方教程中的小乌龟例程理解话题、服务和动作三个通信模型然后尝试用 ROS2 重写本文的烹饪状态机。第三结合“模仿学习”和“物理仿真”来做动作优化。大厨颠勺手法很难用纯数学公式完全描述更实际的方法是先采集真人颠勺的运动数据再用行为克隆或强化学习在仿真环境里优化。这样出来的动作才更接近产品宣传中的“模仿大厨手法”。如果你准备动手练一个类似项目可以先从“二连杆机械臂模拟颠勺轨迹”入手逐步加入视觉识别、负载估计和安全检查。做完以后你会发现一台会做饭的机器人背后其实是一整套完整且复杂的软硬件工程。希望这篇文章能帮你少走一些弯路也欢迎在评论区分享你自己的机器人落地经验。