具身Gemini本地部署实战：边缘端实时感知-决策-执行闭环-平芜编程栈

1. 项目概述：这不是“跑个模型”那么简单，而是具身智能落地的关键一跃

“刚刚，首个能在机器人上本地运行的具身Gemini来了”——这句话在业内刷屏时，我正蹲在实验室调试一台四足机器人的力控关节。看到标题第一反应不是兴奋，而是立刻抓起笔记本记下三个问题：它真能在ARM架构的嵌入式主控板上跑起来？推理延迟压到多少毫秒级才够实时交互？最关键的是，它到底把哪部分“具身”能力塞进了模型里，又把哪部分交给了底层运动控制器？这根本不是又一个“把大模型搬到边缘设备”的新闻稿，而是一次对“具身智能”定义边界的实质性重划。过去两年，我们见惯了“云端大模型+机器人API”的组合拳：语音指令发到服务器，等几百毫秒返回动作序列，再下发执行——这叫远程遥控，不叫具身。真正的具身，是机器人得自己“看、想、动”闭环，眼睛扫到桌角有水渍，大脑瞬间判断要绕行还是擦拭，腿脚同步调整步态，整个过程必须在200毫秒内完成，否则就不是智能，是卡顿。这个项目干的就是这事：把Gemini的轻量化版本，连同视觉理解、空间推理、动作规划三块核心能力，全量压缩进一块算力不到16TOPS的Jetson Orin NX模组里。它不依赖WiFi，不连云端，断网也能自主导航避障；它能实时解析RGB-D相机流，把三维点云和语义标签对齐，不是只认出“杯子”，而是知道“杯子在桌面右侧30cm，高度低于机械臂末端15cm，需先抬升再前伸”。适合谁？不是给算法研究员看论文的，而是给机器人整机厂的嵌入式工程师、高校机器人竞赛队的硬件组长、以及想做真正自主服务机器人的创业团队——你们不用再为模型部署反复烧板子，不用在ROS2和PyTorch之间写二十层胶水代码，现在有一套开箱即用的推理-控制耦合框架，从模型权重到电机PID参数都给你配好了。

2. 核心技术拆解：为什么非得是“具身Gemini”，而不是“机器人版Gemini”

2.1 “具身”二字的硬性技术门槛：不是加个机械臂就叫具身

很多人看到标题第一反应是：“哦，把Gemini模型量化后跑在机器人主控板上”。错。这是最典型的认知偏差。具身智能（Embodied AI）的核心约束从来不在“模型多大”，而在“感知-决策-执行”的物理闭环延迟与精度。我们拆开看三个硬指标：

感知延迟上限：工业级移动机器人要求视觉处理端到端延迟≤80ms。这意味着从CMOS传感器曝光开始，到图像送入模型、输出语义分割掩码和深度估计，必须在80ms内完成。普通YOLOv8s在Orin NX上跑RGB图是45ms，但加上深度估计（如LeReS）立刻飙到120ms——这已经超限。本项目采用的方案是：用单阶段多任务网络（Shared Backbone + Task-Specific Heads），共享ResNet-18主干，头部并行输出语义分割、表面法向量、深度值三路结果，实测延迟压到63ms。关键技巧在于，它把深度估计从“回归像素值”改为“分类深度区间”（0-0.5m/0.5-1.5m/1.5-3m三档），用交叉熵损失替代L1损失，精度损失仅2.3%，但推理速度提升37%。
决策-执行耦合带宽：传统方案中，大模型输出“去厨房拿水杯”，路径规划模块再生成1000个Waypoint，最后运动控制模块逐点跟踪。这中间每层转换都引入误差累积。本项目直接让轻量Gemini输出的是关节空间轨迹参数，而非高级语义指令。比如输入“把桌上的红苹果移到篮子里”，模型不输出文字，而是直接输出机械臂7个关节在2秒内的50帧目标角度序列（shape: [50,7]），且每帧附带置信度权重。这样运动控制器拿到的就是可直接插值执行的底层指令，跳过了NLP→Task Planning→Motion Planning三层抽象，端到端延迟从1.2秒降至320ms。
物理世界校准刚性要求：模型在仿真环境训得好，一上真机就翻车，根本原因是缺乏“本体感知”（Proprioception）。本项目在模型输入侧硬编码了三项实时传感器数据：IMU三轴角速度（补偿视觉运动模糊）、关节编码器当前角度（提供本体位姿先验）、六维力传感器零漂补偿值（用于抓取力度预判）。这些不是可选特征，而是模型训练时就强制concat进输入向量的固定通道。我们试过关掉IMU输入，同样场景下碰撞率从1.2%飙升至17%——这说明“具身”不是软件功能，是软硬强耦合的系统工程。

提示：所谓“本地运行”，本质是把原本分散在ROS2不同Node里的感知、规划、控制模块，用TensorRT引擎统一调度。模型输出不再是ROS Message，而是共享内存中的Tensor Buffer，下游C++运动控制器直接mmap读取，避免了序列化/反序列化开销。这才是延迟压到300ms内的底层原因。

2.2 Gemini轻量化不是“剪枝+量化”老套路，而是重构计算图

市面上90%的边缘大模型部署，还在用“先剪枝再量化”的线性流程：拿原始模型，用敏感度分析砍掉不重要通道，再用INT8量化权重。这套方法对Gemini这种多模态模型完全失效——它的视觉编码器和语言解码器参数分布差异极大，统一量化会致盲。本项目采用的是分域动态量化（Domain-Aware Dynamic Quantization）：

视觉分支：用FP16保留高频纹理细节。因为RGB-D输入中，深度图的毫米级误差会直接导致抓取失败，所以视觉主干（ViT-Base）的Attention权重和LayerNorm参数全保留FP16，仅FFN层用INT8。实测PSNR下降0.8dB，但抓取成功率提升11%。
语言-动作映射分支：这是真正的创新点。它没用传统Transformer Decoder，而是设计了一个稀疏门控循环单元（SGRU），结构类似GRU但隐藏层被划分为5个专家子网（Experts），每次前向只激活2个。每个专家专精一类动作：抓取类、移动类、避障类、交互类、纠错类。输入指令经词嵌入后，先过一个轻量Router Network（仅2层FC，参数<50K），决定激活哪两个专家。这样既保持了多任务泛化能力，又把参数量从1.2B压到280M，推理速度提升4.3倍。
量化策略：放弃静态校准（Static Calibration），改用在线统计校准（Online Statistical Calibration）。模型启动后，自动采集前100帧真实场景数据（非合成数据），实时计算各层激活值的min/max，生成Per-Tensor Scale。这比用ImageNet校准集生成的Scale，在室内动态场景下精度高2.1个百分点——因为真实机器人看到的，永远是反光的玻璃门、半透明的塑料瓶、还有不断晃动的窗帘。

我们对比过三种方案在Orin NX上的表现：

方案	模型大小	平均延迟	抓取成功率（100次）	能耗（W）
传统剪枝+INT8	1.8GB	410ms	63%	12.4
FP16全精度	3.2GB	890ms	89%	18.7
本项目分域量化	940MB	320ms	92%	9.8

关键发现：延迟降低的同时，成功率反而更高——证明计算效率提升释放了更多资源给实时物理仿真（如Bullet Physics的碰撞检测频率从30Hz提至60Hz），这才是具身智能的正向循环。

2.3 “本地运行”的真实含义：从芯片选型到散热设计的全栈妥协

很多团队以为“本地运行”就是把模型转成ONNX再用TensorRT加载。但实际落地时，第一个拦路虎是供电噪声。Orin NX标称峰值功耗15W，但当GPU满载跑视觉模型、CPU同时处理激光雷达点云、NPU加速动作预测时，瞬时电流尖峰可达8A。我们早期用普通DC-DC模块，结果电机驱动器频发丢步——示波器抓出来是电源纹波高达220mVpp。解决方案是：在Orin NX的VIN引脚前端，硬加一级低噪声LDO（TPS7A83A），把纹波压到12mVpp以下。这增加12元BOM成本，但换来的是运动控制稳定性从91%升至99.7%。

第二个隐形杀手是散热衰减。Orin NX在85℃时会主动降频。机器人作业时，主控板常被封装在密闭腔体内，周围还有电机驱动器散发热量。我们实测：无散热措施下，连续运行23分钟温度突破85℃，GPU频率从1.5GHz降至0.9GHz，延迟飙升40%。最终方案是：定制铜基板（厚度2.0mm）+热管导出+腔体顶部开蜂窝散热孔（孔径1.2mm，间距3mm），配合风扇PWM调速（温度＜70℃停转，＞75℃全速）。这个方案让温升曲线变得平缓，连续运行4小时温度稳定在72±3℃。

注意：所有散热设计必须避开PCB上的高速信号线（如PCIe x4接口）。我们曾因热管离PCIe走线太近（＜8mm），导致视频流偶发丢帧。后来在热管表面加了一层0.1mm厚的聚酰亚胺绝缘膜，问题彻底解决。这种细节，只有亲手焊过板子的人才懂。

3. 实操部署全流程：从镜像烧录到真机联调的踩坑实录

3.1 硬件准备清单：别被“支持Jetson”四个字骗了

官方文档写“支持Jetson Orin系列”，但实际适配只验证过Orin NX 16GB版本。我们踩过最大的坑是：用Orin AGX 32GB开发板测试时一切正常，换到产线用的Orin NX 8GB模组，直接OOM崩溃。查了三天才发现，模型权重加载时默认申请显存是按AGX规格预分配的，NX版需要手动修改config.yaml里的max_gpu_memory_mb: 6144（原值8192）。所以硬件清单必须精确到型号后缀：

主控板：NVIDIA Jetson Orin NX 16GB（模组型号：P3509-0000-1001-0000，注意不是P3509-0000-1001-1000）
相机：Intel RealSense D455（必须D455，D435深度图分辨率不够，D455的全局快门能消除运动模糊）
IMU：TDK InvenSense ICM-20948（九轴，I2C接口，采样率必须设为1kHz，低于此值会导致姿态解算延迟）
电机驱动器：RoboClaw 2x7A（固件版本7.2.1，旧版不支持CAN FD协议，无法接收模型输出的高频率关节指令）

特别提醒：D455的USB线必须用带磁环的屏蔽线，普通USB线在电机启停瞬间会产生EMI干扰，导致深度图出现白色噪点条。我们试过3种线材，只有Belkin F2CU010（带双磁环）能通过EMC测试。

3.2 镜像烧录与基础环境配置：跳过Ubuntu桌面版

千万别用NVIDIA SDK Manager下载带GNOME桌面的完整镜像！机器人主控不需要图形界面，桌面环境会吃掉1.2GB内存和2个CPU核心。正确做法是：

从NVIDIA官网下载JetPack 5.1.2 Developer Preview（注意是Developer Preview，不是正式版，正式版缺少Orin NX的完整驱动）
解压后进入Linux_for_Tegra目录，编辑flash.sh，在第87行添加--no-flash参数（防止误烧）
执行sudo ./flash.sh jetson-orin-nx-devkit-emmc mmcblk0p1，生成纯净的system.img
用dd命令烧录：sudo dd if=system.img of=/dev/sdX bs=1M status=progress（sdX替换为你的SD卡设备名）

烧录后首次启动，必须立即执行：

# 关闭所有GUI服务 sudo systemctl set-default multi-user.target sudo systemctl disable gdm3 # 启用NVIDIA持久模式（避免GPU上下电延迟） sudo nvidia-smi -i 0 -pm 1 # 设置GPU最大功耗为15W（Orin NX标称值） sudo nvidia-smi -i 0 -pl 15

实操心得：我们曾因忘记设-pl 15，在高温环境下GPU自动降频，导致视觉模块掉帧。后来把这条命令写进/etc/rc.local，确保每次开机生效。

3.3 模型部署与推理引擎配置：TensorRT不是装上就行

模型文件embodied_gemini_v1.2.trt不能直接用trtexec加载。它依赖一个自定义Plugin：SpatialAttentionPlugin，用于处理三维空间注意力机制。编译这个Plugin需要：

安装CUDA 11.4（JetPack 5.1.2绑定版本，别用12.x）
下载TensorRT 8.5.2源码（不是deb包，必须源码）
修改plugin/CMakeLists.txt，在find_package(CUDA REQUIRED)后添加：
```
set(CMAKE_CXX_STANDARD 14) set(CMAKE_CXX_STANDARD_REQUIRED ON)
```
编译命令：make -j$(nproc) && sudo cp libspatial_attention.so /usr/lib/aarch64-linux-gnu/

最关键的一步是引擎序列化。模型第一次运行时，TensorRT会根据当前GPU型号生成优化后的engine文件（约2.1GB），这个过程耗时8-12分钟。必须确保在此期间系统不休眠、不被kill。我们在/etc/systemd/system/trt-init.service里写了守护脚本：

[Unit] Description=TRT Engine Initialization After=multi-user.target [Service] Type=oneshot ExecStart=/bin/bash -c 'cd /opt/embodied-gemini && python3 init_engine.py --model embodied_gemini_v1.2.trt' RemainAfterExit=yes TimeoutSec=900 [Install] WantedBy=multi-user.target

启用：sudo systemctl daemon-reload && sudo systemctl enable trt-init.service

3.4 真机联调：从“能跑”到“可靠运行”的临门一脚

联调不是把代码跑起来就完事。我们定义了三个验收层级：

Level 1（能跑）：模型加载成功，ros2 topic echo /gemini/action_cmd能看到关节角度输出。耗时约2小时。
Level 2（可用）：在空旷场地完成10次“移动到指定坐标+抓取物体”闭环，成功率≥90%。这里暴露出两个问题：一是D455深度图在强光下饱和，解决方案是加装ND8滤光片；二是机械臂末端TCP（Tool Center Point）标定误差，我们用棋盘格+手眼标定法重做，把误差从3.2mm降到0.7mm。
Level 3（可靠）：连续72小时无人值守运行，每小时执行一次“环境扫描+随机抓取+归位”任务，故障率＜0.5%。这时发现新问题：Orin NX的eMMC存储在长期读写后出现坏块。对策是把模型权重和日志全部迁移到外接NVMe SSD（用PCIe转接卡），eMMC只存系统。

最致命的Bug出现在Level 3：连续运行36小时后，机器人突然原地旋转不停。抓取日志发现，/gemini/action_cmd输出的角度序列里，第37帧的yaw角突变为inf。追查到是IMU数据在长时间运行后发生数值溢出（ICM-20948的陀螺仪积分误差累积）。解决方案是在ROS2节点里加一道滤波：

# 在action_publisher节点中 def _filter_yaw_spikes(self, yaw_list): # 检测连续3帧yaw变化＞15度，视为异常 for i in range(2, len(yaw_list)): if abs(yaw_list[i] - yaw_list[i-1]) > 15 and \ abs(yaw_list[i-1] - yaw_list[i-2]) > 15: # 用前一帧有效值线性插值 yaw_list[i] = yaw_list[i-1] + (yaw_list[i-1] - yaw_list[i-2]) return yaw_list

这个补丁让72小时故障率从3.2%降至0.3%。

4. 应用场景深度延展：不止于实验室Demo，而是产线级解决方案

4.1 工业质检场景：把“看缺陷”变成“判责任”

某汽车零部件厂采购了5台搭载该系统的四轮巡检机器人。传统方案是：机器人走到工位，用工业相机拍照，传回服务器识别划痕，再由MES系统派单维修。问题在于，服务器识别只能告诉你“有划痕”，但无法判断是铸造工序的砂眼，还是机加工的刀具磨损，更别说定位到具体哪台CNC机床。本系统改造后：

机器人停在工件前1.2米处，D455拍摄RGB-D图，模型不仅输出“划痕位置”，还结合工件CAD模型，反推划痕在三维空间的法向量方向（精度±1.5°）
根据法向量与工件坐标系夹角，判定划痕成因：若夹角＜10°，大概率是铸造冷隔；若夹角在35-55°，指向某台CNC的刀具轨迹，触发“刀具磨损预警”
自动关联MES中的设备维护记录，生成《划痕成因分析报告》，包含建议更换的刀具编号、预计影响良率百分比

上线3个月，该厂刀具非计划更换次数下降42%，因为系统能在刀具磨损初期（划痕宽度＜0.08mm）就预警，而人眼检测阈值是0.15mm。

4.2 养老陪护场景：安全边界比功能更重要

某养老社区部署了12台服务机器人，负责送药、提醒服药、跌倒监测。之前用的方案是“云端识别+本地报警”，但遇到网络抖动时，跌倒识别延迟达3.2秒，错过黄金救援时间。本系统改造后：

所有视觉分析（人体姿态估计、重心偏移计算、地面接触检测）全在本地完成
关键创新是多模态置信度融合：当视觉检测到跌倒姿态时，同步读取IMU的加速度突变值（＞8g持续150ms）和六维力传感器的地面冲击力（＞120N），三者置信度加权平均，单一模态失效不影响判断
最重要的是安全熔断机制：一旦检测到跌倒，机器人立即停止所有运动（包括底盘移动和机械臂动作），并以最高优先级向护理站发送加密告警（含GPS坐标、现场视频流URL、跌倒姿态3D重建图）。整个过程从检测到告警发出，实测210ms。

三个月内，该社区实现跌倒事件100%及时响应，其中76%的案例在老人自行起身前完成告警——这得益于本地化带来的确定性低延迟。

4.3 教育科研场景：让本科生也能复现顶级成果

某高校机器人实验室采购了8套开发套件。教授反馈：以前学生做具身智能课题，光是配通ROS2+PyTorch+Open3D环境就要两周，真正做实验只剩一周。现在：

预装镜像已集成所有依赖，git clone后make run即可启动
提供三套渐进式实验手册：
▪ Level 1：修改prompt_config.yaml里的指令模板，观察机器人对“请把蓝色方块放到红色圆圈上”的理解差异
▪ Level 2：在/src/core/planner.py里替换自己的路径规划算法，模型自动适配新输出格式
▪ Level 3：用提供的calibration_tool标定新相机，一键生成适配模型的内参矩阵

最惊喜的是，学生用这套系统复现了ICRA 2023一篇顶会论文（关于动态障碍物预测），原论文需要4块A100训练3周，他们用Orin NX微调2天就达到92%原精度——因为模型架构已针对边缘计算优化，学生只需专注算法逻辑。

5. 常见问题与独家排障指南：那些文档里绝不会写的真相

5.1 “模型加载失败：CUDA out of memory”——别急着加swap

现象：python3 main.py报错CUDA out of memory，但nvidia-smi显示显存只用了30%。
真相：Orin NX的显存是LPDDR5，与CPU共享内存总线。当CPU大量使用内存（如ROS2节点缓存激光雷达点云），会挤占GPU可用带宽，导致TensorRT申请显存失败。
解决方案：

限制ROS2节点内存：export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp（CycloneDDS比FastRTPS省内存35%）
给GPU预留专用内存：在/boot/extlinux/extlinux.conf里APPEND行末尾加video=tegrafb0:1920x1080@60 fbcon=map:0 console=tty1 no_console_suspend=1 mem=6G@2048M cma=2G（重点是cma=2G，为GPU预留2GB连续内存）
启动后执行：echo 1 | sudo tee /sys/devices/virtual/misc/tegra_fb/mem_pool/enable

实测效果：加载失败率从100%降至0。

5.2 “动作指令乱码：关节角度忽大忽小”——检查IMU安装朝向

现象：机器人静止时，机械臂关节角度在±5°范围内无规律抖动。
真相：ICM-20948的坐标系必须与机器人基座坐标系严格对齐。出厂时Z轴默认指向上方，但如果把IMU倒装（Z轴向下），模型内部的姿态解算就会符号反转。
排查步骤：

运行ros2 run rqt_reconfigure rqt_reconfigure，打开/imu_node配置页
查看orientation_covariance矩阵，若对角线元素（0,0）（1,1）（2,2）为负值，说明坐标系错误

物理调整IMU安装方向，或在imu_node的launch文件中添加：

<param name="frame_id" value="base_link"/> <param name="orientation_reverse_z" value="true"/> <!-- 倒装时启用 -->

我们曾因此返工3台机器人，每台耗时4小时重新标定。

5.3 “深度图大面积空白”——D455的红外发射器被遮挡

现象：D455在暗光环境下深度图正常，但在明亮室内出现大片黑色区域（尤其对白墙）。
真相：D455依赖红外散斑投射器（IR Projector）辅助深度计算。当环境光中红外成分过强（如LED灯含850nm波段），会淹没散斑信号。
解决方案：

第一招：关闭机器人附近的LED灯，或贴ND8滤光片（透光率12.5%）
第二招：在realsense2_cameralaunch文件中，把enable_infra1设为true，ir_emitter_enabled设为false，强制切换到纯被动红外模式（此时深度精度下降15%，但稳定性提升）
第三招（终极）：用胶带物理遮住D455的IR Projector镜头（位置在摄像头右下角的小圆孔），只留红外接收器工作。这招在强光仓库场景实测有效，深度图空白区消失。

注意：遮住IR Projector后，D455会自动切换到长曝光模式，帧率从30Hz降至15Hz。必须同步修改config.yaml里的depth_fps: 15，否则ROS2节点会报错丢帧。

5.4 “连续运行24小时后模型崩溃”——eMMC寿命预警

现象：机器人稳定运行24小时后，某次trtexec调用突然卡死，dmesg日志出现mmcblk0: error -110。
真相：Orin NX开发套件的eMMC是TLC颗粒，擦写寿命约3000次。模型权重文件频繁读取（每秒约200次IO），24小时后eMMC的某个Block已接近寿命极限。
根治方案：

立即迁移：sudo mkdir /mnt/nvme && sudo mount /dev/nvme0n1p1 /mnt/nvme
创建符号链接：sudo ln -sf /mnt/nvme/embodied-gemini /opt/embodied-gemini
修改所有路径引用，确保模型、日志、缓存全在NVMe上
为eMMC启用TRIM：sudo fstrim -v /（每周执行一次）

我们给eMMC加了监控脚本，当smartctl -a /dev/mmcblk0 | grep "Life"显示剩余寿命＜20%时，自动发邮件告警。

6. 性能边界实测与未来演进：它到底能走多远？

6.1 当前性能天花板：用数据说话，拒绝模糊描述

我们在标准测试场（10m×10m，含4个动态障碍物、2个光照变化区、1个反光地板区）做了72小时压力测试，结果如下：

测试项	数值	说明
端到端延迟（感知→动作）	298±12ms	从D455曝光开始计时，到机械臂关节开始转动结束，95%分位数
动态避障成功率	99.3%	对速度≤0.8m/s的移动障碍物，1000次测试失败7次（均为极端角度切入）
抓取成功率（小物体）	92.1%	直径2cm的金属螺母，100次测试失败8次（6次因反光，2次因遮挡）
连续运行稳定性	99.97%	72小时无故障运行，仅1次因外部电源波动重启
功耗（典型工况）	9.8±0.3W	包含Orin NX、D455、IMU、机械臂驱动器全部负载

关键发现：延迟瓶颈已不在模型推理，而在D455的USB3.0传输带宽。当开启RGB+Depth+Infra1三路流，USB带宽占用率达92%，此时任何USB设备（如U盘）插入都会导致深度图丢帧。解决方案是：禁用Infra1流，改用RGB图做运动模糊检测——虽然精度略降，但系统鲁棒性大幅提升。

6.2 下一代演进方向：不是堆算力，而是改范式

团队内部Roadmap已明确下一代不追求更大模型，而是三个根本性转向：

从“模型理解世界”到“世界教会模型”：当前模型在仿真环境预训练，真机部署后需在线微调。下一代将内置神经辐射场（NeRF）实时建图模块，机器人每走一步，自动构建带语义标签的3D地图，并用新地图数据反哺模型训练。这样模型越用越懂这个特定环境，无需重新训练。
从“单机智能”到“群体涌现”：当前是单机器人闭环。下一代将开放跨机器人知识蒸馏接口。比如A机器人在仓库东区学会识别新型包装箱，其特征提取层权重会自动压缩成128KB的Diff Patch，通过LoRa无线推送给B、C机器人，3秒内完成知识迁移。这比上传云端再下发快17倍。
从“执行指令”到“质疑指令”：当前模型对用户指令无条件执行。下一代将加入物理可行性验证器（Physical Feasibility Verifier）。当收到“把10kg箱子举到2.5m高”指令，模型先调用内置的刚体动力学求解器，确认当前电池电量、电机扭矩、重心位置是否允许，若不可行，会主动回复：“当前电量仅支持举到1.8m，是否调整目标？”——这才是真正的人机协作。

我个人在实验室摸爬滚打八年，见过太多“PPT智能”项目：演示时丝滑流畅，交付后天天救火。这个具身Gemini项目最打动我的，是它把“智能”的定义拉回物理世界——不看参数多炫，只问在真实光照、真实噪声、真实磨损条件下，能不能连续72小时不出错。它可能不是最强的模型，但绝对是目前最“结实”的具身智能底座。如果你也在做机器人，别纠结要不要上，先问自己：你敢不敢把它放进客户现场，然后关上门，一星期后再打开？