大模型+多模态感知：人形机器人TonyPi全功能实战解析
简介：本资源是面向人工智能与机器人开发者的综合性实践项目包，聚焦TonyPi人形机器人平台，解决多模态感知与大语言模型协同控制的工程落地问题，适用于高校AI课程设计、智能硬件竞赛备赛及嵌入式AI开发者进阶学习。压缩包共63个文件（2.85MB），含45个Python核心脚本（覆盖YOLOv5目标检测、语音识别接口、LLM指令解析、动作调度等模块）、6个配置与说明文本、3个语音样本wav文件、1个JPG示例图及配套文档（README.md、附赠资源.docx、LICENSE等），结构清晰，便于按功能模块快速定位代码与配置。已有126人学习下载，提供从机器人端动作调用（robot.py）、PC端LLM代理（agent_go.py）到多模态感知（颜色追踪、人脸识别、标签识别、智能巡线）及特色功能（自动踢球决策逻辑、物体搬运路径规划、动态目标追踪）的完整实现链路，包含可直接运行的utils_llm.py工具库与yolov5.py识别模块，显著降低多模态机器人系统集成门槛。 拿到这个项目标题的时候，我第一反应是“这是一台机器人要干多少个活”——大语言模型对话、语音识别、目标检测、颜色追踪、人脸识别、标签识别、自动踢球、智能搬运，还要巡线，几乎把目前机器人入门阶段能玩的多模态感知任务全塞进了一个系统里。但仔细拆一下会发现，核心思路其实非常清晰：用大语言模型做大脑，用语音做入口，用视觉做眼睛，最后统一驱动TonyPi的运动控制。
这个项目我最看好的地方在于，它不是停留在“某个算法Demo能跑”的层面，而是把感知、决策、执行串成了一条可落地的闭环链路。你做出来的不是一个只会识别图片的模型，而是一个能听懂人话、看懂场景、真能踢球搬东西的实物机器人系统。这篇文章我打算把整个系统的架构设计、核心模块实现、多模态信息怎么对齐、以及我实测中踩过的坑一次说清楚。适合手里有TonyPi或者类似人形机器人平台、想往“多模态交互”方向进阶的开发者参考，也适合第一次接触大语言模型落地方案的爱好者做路线图。
1. 项目整体设计与系统架构思路
1.1 表面是一堆功能“拼接”，本质是四层系统架构
很多人看到标题里十来个功能点就头大，觉得这是一个大杂烩。实际上这个系统剥开来看就是四层：底层是TonyPi的硬件执行层，负责舵机、运动、夹爪动作；往上是多模态感知层，包括摄像头视觉识别和麦克风语音识别；再往上是决策层，也就是大语言模型所在的位置，负责理解自然语言指令、结合感知结果做任务规划；最后是人机交互层，把识别结果、对话回复呈现给用户。
这四层之间是单向依赖关系：交互层接收用户语音，感知层把“看到了什么”编码成结构化信息，决策层综合两者输出“要做什么”，执行层把决策翻译成舵机角度和运动指令。这样设计最大的好处是每一层都可以独立替换。比如今天用YOLOv5，明天换成YOLOv8，决策层完全不用改；今天用离线语音识别，明天换云端ASR，也只是感知层换一个接口。我在做这类机器人项目时最怕的就是模块之间你中有我、我中有你，最后改一个功能牵一发动全身。分层设计能让后续迭代舒服很多。
1.2 为什么选TonyPi做人形机器人基座
市面上做机器人开发的平台不少，最常见的是四轮小车、麦克纳姆轮底盘和机械臂。TonyPi这类人形机器人的优势在于它有“人形”结构，天生适合做人机交互场景。它有一个能转动的头部（云台）、两条能做踢球动作的腿、还能扩展夹爪做搬运。相比纯轮式小车，它有更丰富的执行动作；相比固定机械臂，它又能自由移动，这就把“移动”和“操作”两个能力合到了一起。
从开发友好度看，TonyPi也是不错的选择。它带有Python SDK和基础运动库，底层舵机控制被封装成了相对易用的API，串口通信协议也是开放的。对于做AI算法的开发者来说，不需要花太多时间去啃步态学和控制理论，可以把精力集中在视觉、语音和大模型这层。项目标题里同时出现了“踢球”“搬运”“巡线”三个运动类任务，这恰好是人形机器人能展示、又不需要太复杂双足平衡能力的场景——如果你用过双足步态机器人就会知道，光是让它站稳就已经很头疼了。
1.3 算力分配策略：本地轻量推理 + 云端大模型决策
这个项目里最值得提前想清楚的，是算力怎么分配。TonyPi通常搭配树莓派4B/5或者Jetson Nano/Orin Nano这类嵌入式主控来跑。树莓派4B跑实时目标检测比较吃力，Jetson Nano能跑但也不算宽裕。而大语言模型哪怕是量化版，也不是这种板子能舒服跑起来的。
我的建议是“分级部署”：颜色识别、人脸检测、巡线、标签识别这些时延敏感、计算量相对小的任务，全部放在本地跑，因为它们需要跟运动控制实时联动，容不得几百毫秒的延迟；大语言模型放在云端API或者局域网内一台带GPU的服务器上，因为语音指令本身就不要求毫秒级响应，人是可以接受一两秒思考时间的。这样整个系统既有实时性，又有强语义理解能力。
2. 视觉感知模块：多模态信息的“眼睛”怎么搭建
2.1 颜色识别与颜色追踪：HSV颜色空间是绕不开的第一课
颜色识别是整个系统里最基础也最常用的感知能力。很多人第一次写颜色识别直接用RGB判断，结果一到实际环境就翻车——RGB三个通道对光照太敏感了，同一个红色球在阳光直射和阴影下，RGB数值差异巨大。正确做法是先转换到HSV颜色空间，把色相（H）、饱和度（S）、明度（V）分开，然后主要靠H通道去做颜色分类。
以OpenCV为例，基本流程是先用cv2.cvtColor(frame, cv2.COLOR_BGR2HSV)转换到HSV，再用cv2.inRange()按颜色阈值生成二值掩膜，接着做一下腐蚀和膨胀去掉噪点，最后用cv2.findContours()找轮廓，通过轮廓面积过滤掉太小的干扰区域，算出目标质心坐标。质心坐标就是后续颜色追踪的输入——用PID控制云台转动，让目标始终保持在画面中央。
调HSV阈值时有个实用技巧：在程序里放两个滑动条，实时调节上下限，在目标光照条件下现场标定。红色在OpenCV HSV里有点特殊，它的H值在0附近会有回绕（0和180相邻），所以红色通常要定义两段范围再合并，这是新手最容易卡住的地方。
2.2 目标检测：YOLO系列模型的自定义数据集训练与部署
项目标题里写到的“物体追踪”和“目标检测”，实际落地一般会用YOLO系列。YOLOv5和YOLOv8是目前最主流的两个选择。我自己的偏好是：项目要快速验证用YOLOv5s，要长期维护用YOLOv8n，因为它们都在速度和精度之间取了一个不错的平衡点，在Jetson Nano上也能跑到实时帧率。
目标检测的自定义数据集训练流程说起来不复杂：第一步，准备数据，用相机采集目标物体在不同角度、不同光照下的图片，每类目标尽量凑几百张以上；第二步，标注数据，用LabelImg或LabelStudio画框；第三步，划分训练集和验证集，写一个data.yaml；第四步，选一个预训练权重做迁移学习，比如yolov8n.pt，训练几十个epoch就够了，因为机器人场景里的目标种类很少，没必要从头训。
部署阶段有个容易被忽略的点：别直接把PyTorch的权重文件扔到板子上跑，一定要做模型转换和优化。Jetson平台可以转成TensorRT的engine文件，能明显提升推理速度；树莓派上可以转成ONNX再用ONNX Runtime推理。实测下来推理帧率能差好几倍。我建议至少先做ONNX转换，后面再考虑TensorRT。
2.3 智能巡线：用底部ROI提取路线的偏移量
巡线在这个系统里承担的是“通道内自主移动”的能力。它和颜色识别的技术栈高度重合：先把画面转到HSV，提取出跟地面颜色明显不同的线路颜色掩膜，然后不是在整幅画面里找，而是取画面底部一小块矩形区域作为ROI，对这个ROI做固定行数的分列扫描，找到每一行线路像素的质心，再求平均得到线路在当前视野中的横向偏移量。
这个偏移量就是控制机器人的核心信号：偏移量接近0，说明机器人在线中央，直行即可；偏移量偏左，就向右打方向；偏右，就向左打方向。实际控制里建议加一个PID控制器，P项给基础打角，D项抑制抖动，不然机器人会在线上走蛇形。巡线和目标追踪结合时，还要注意一个问题：机器人转弯的时候，摄像头视角会跟着转，线路偏移量会瞬间产生大跳变，程序里要加滤波或者设定偏移量最大变化率，否则一转弯就失控。
2.4 标签识别与颜色追踪：全局定位和局部跟踪的分工
标签识别我一般用二维码类标记，比如AprilTag或QR Code。AprilTag比普通二维码更适合机器人场景，因为它在远距离、低分辨率、倾斜拍摄下都有更高的检测鲁棒性。标签识别在这里有独特价值：它提供一个绝对坐标锚点。巡线知道的是“我在线偏了多少”，但不知道“我在场地哪个位置”；标签能告诉机器人“我在坐标x、y，朝向多少度”，把这个信息和巡线数据融合起来，机器人的位姿估计才算完整。
颜色追踪则负责局部目标的实时锁定。它的核心逻辑是：目标检测或颜色识别在画面中找到目标后，计算出目标中心和画面中心的像素偏差，这个偏差作为云台PID控制的输入，让云台时刻对准目标。云台对准了，机器人再直行，就能一路追着目标跑。我做过最快的实现是直接把颜色质心偏差映射成运动指令：偏差大就往偏差方向转，偏差小就直行。代码量很少，但效果非常直观。
2.5 人脸识别：本地特征向量比对就能满足Demo需求
人脸识别在这个项目里属于“交互增强”功能，不需要做得太重。OpenCV自带的Haar级联虽然旧，但在嵌入式设备上速度快，能检测人脸位置；如果想稍微Modern一点，可以用OpenCV的DNN模块加载一个轻量人脸检测模型。需要注意的是，对人脸识别而言，检测和识别是两个步骤：检测是找“人脸在哪”，识别是判断“这是谁”。
识别部分如果不想引入庞大的模型，可以在本地预注册人脸特征，用face_recognition这类库提取128维特征向量存起来，运行时提取当前人脸向量，计算和注册向量的欧式距离，小于阈值就认为是同一个人。这个方案在板子上跑起来也还可行，因为人脸识别触发频率低，不需要每帧都算。它能给整个系统增加一个交互维度：机器人看到“认识的人”和看到“陌生人”时，可以给出不同的语音回复，这让“大模型语音交互”不再只是被动应答，而是带上了视觉上下文。
3. 语音交互与大语言模型决策闭环
3.1 语音识别方案：离线轻量识别和云端ASR怎么分工
语音识别是整个系统的“听觉入口”，选择方案时要先想清楚使用场景。如果你希望机器人完全离线工作，那就用离线语音识别库，比如Vosk。Vosk支持中文，模型大小从几十MB到几百MB都有，树莓派上用小模型可以做到准实时转写，但中文识别准确率只能说够用，复杂长句容易翻车。还有一种更轻量的方式是离线唤醒词加固定指令集识别，比如只识别“开始”“停止”“踢球”“搬运”这几个词，准确率很高，但扩展性差。
我的建议是可以做二级方案：本地麦克风队列持续收音，先用Vosk或者本地唤醒词模块做一个轻量判断，一旦检测到有指令性语音，再把这小段音频发给更强大的云端ASR（比如Whisper或者商用语音识别API），拿到高质量文本后再交给大语言模型。这样既避免所有声音都送云端，保证隐私和响应速度，又能获得接近人类水平的识别质量。麦克风硬件上，尽量选带降噪的麦克风阵列，单麦克风在机器人运动状态下会有严重的电机噪声干扰，这一点我在后面排查表里会细说。
3.2 大语言模型接入：先跑通API流程，再考虑本地部署
标题里出现“本地部署大语言模型”这个热词，我估计很多人的目标是离线跑一个大模型。但这里我要泼一点冷水：人形机器人做自然语言交互，真正值钱的不是“模型在你手里”，而是“模型理解意图之后能驱动动作”。所以个人开发者切入时，我应该给一个明确优先级：先用大模型API把系统链路调通，再根据实际需求考虑本地部署。
用API的好处是几乎零门槛，几行代码就可以调用，而且能立刻用上最新最强的模型能力。它的代价是依赖网络、有少量费用、数据要经过第三方服务。如果项目展示场景在网络不好的地方，那本地部署就有必要了。本地部署大语言模型的主流方案是llama.cpp配合GGUF量化模型，在带GPU的电脑上可以跑7B甚至13B量级的模型，没有GPU的话纯CPU也能跑，但速度会比较慢，体验会打折扣。
硬件选择上有个参考：7B量化模型推理需要至少8GB以上内存，速度取决于内存带宽；如果你只有普通笔记本，建议选Q4_K_M量化且参数量不超过7B的模型，这样还有基本的可用性。网络热词里提到的“目标领域知识库微调大语言模型”这个方向，对于机器人项目来说属于进阶玩法，初期没必要做微调，靠Prompt工程就能覆盖大部分交互场景。
3.3 意图解析：让大语言模型输出结构化指令
这应该是整个项目里“大模型味”最浓的地方。传统机器人语音控制的做法是关键词匹配：语音转文字后，代码里判断是否包含“踢球”“红色”等关键词，然后执行固定逻辑。这种做法遇到复杂指令就累死了，比如“把那边的红色球踢到左边那个框里”，关键词拆解非常费劲。
用大语言模型就不一样了。我现在一直建议的做法是：让模型输出JSON结构化的指令。把视觉感知结果拼成一段环境描述，和用户语音转写文本一起放进Prompt里，要求模型输出严格格式的JSON字符串，里面包含意图分类、目标物体颜色、目标位置、动作参数等字段。程序拿到JSON后，前两个字段映射到运动函数，参数直接传给执行层。
比如用户说“踢红色的球”，视觉模块已经检测到画面里有一个红色球，位置在左前方，Prompt里把这个信息带上，模型给出的JSON就是{"intent": "kick", "target_color": "red", "target_position": "left_front", "confidence": 0.9}。代码里写好intent_to_action映射表，踢球、搬运、巡线、追踪这些能力全部注册成函数入口，模型的JSON输出直接决定调用哪个函数。这样系统扩展新功能时，只需要新增一个注册函数，不需要改决策逻辑。
3.4 多模态上下文：视觉信息怎么和大模型对话融合
大语言模型本身是文本输入输出的，它“看不到”图像。所以要让模型理解场景，必须把视觉模块的输出“翻译”成文本描述。这个翻译层可以是简单的规则拼接，也可以是视觉语言模型。我们这个项目里其实两种需求都有。
如果只是告诉模型“前方有红色球”“检测到一张标签”，那规则拼接就足够。把目标检测结果、颜色识别结果、标签ID打包成一个环境列表，塞进Prompt即可。但如果想让模型理解更复杂的场景，比如“房间里有没有人”“球是不是在桌子下”，就需要一个视觉语言模型（VLM）来做图文理解。现在有一些轻量的VLM通过API调用也很方便。我在实际项目中倾向于混合方案：关键的、实时的环境信息靠本地视觉模块规则化输出，偶尔需要深度语义理解时再调用VLM。
这部分的工程实现要点是：视觉信息在进入Prompt前必须做“状态压缩”。你不能每帧都把检测结果往Prompt里塞，一来浪费token，二来模型会被噪声干扰。正确做法是维护一个“环境状态缓存”，只保留最近有效检测结果和置信度，当大模型需要上下文时读取这个缓存。
4. 运动控制与多任务执行逻辑
4.1 自动踢球：视觉引导加位姿对准的完整状态机
自动踢球是标题里最有演示效果的功能，也是把视觉和运动控制串起来最典型的例子。它的本质是一个状态机：搜索球、向球靠近、调整对准角度、接近到打击距离、执行踢球动作。每个状态对应一个视觉条件和运动指令。
搜索球状态里，机器人原地旋转头部云台，颜色识别每帧返回画面中是否有目标色块；一旦检测到球且面积超过阈值，就进入靠近状态。靠近时用球的像素位置做闭环：球在画面左侧就向左转，球在右侧就向右转，球在画面中央就前进，这样球始终保持在视野中心。当球在画面中的色块面积特别大（说明已经很近）时，切换到对准状态——通过标签识别或场地标记确认球门方向，微调机器人朝向。最后，当视觉确认球在正前方且距离合适，触发踢球动作：后摆、加速前摆、收回。整个过程里PID参数和状态切换阈值全都要实测微调，这也是项目标题里一堆功能里最花时间的部分。
4.2 智能搬运：目标识别、夹爪控制和位姿调整的配合
智能搬运的逻辑跟踢球有相似之处，但多了一个关键动作：夹取。这要求视觉不仅要能识别目标，还要能估算目标到夹爪的方位。我的实现思路是，先用目标检测模型识别“待搬运物体”的类别，再用颜色识别锁定目标区域提取质心，然后控制机器人移动到目标正前方，最后在目标接近画面底部时进行微调，让夹爪位于目标正上方或正前方，执行夹取和抬升动作。
这里有一个常被忽略的细节：夹取前机器人要做“横向对准”而不是“随便对准”。因为在人形机器人上，夹爪的横向活动范围其实很窄，目标如果不在夹爪正前方，硬夹很容易夹空。所以我会把对准分成两步：先粗调位置让目标进入画面中央区域，再通过视觉反馈做小步距横移，直到质心坐标和夹爪投影点重合。搬运的结束阶段也要检测——不要靠手感，而是通过舵机电流反馈或者视觉确认目标已经离开原来的位置，再开始移动，否则走两步东西就掉了。
4.3 巡线、追踪、语音指令三者如何协同决策
这个项目里最复杂的情况不是某一个功能，而是多个功能同时触发。比如机器人正在巡线，用户突然说“踢球”，要不要立刻中断巡线？再比如巡线过程中发现目标球出现在线路旁边，是继续巡线还是追球？
我在系统里加了一个简单的“行为优先级”机制：语音指令优先级最高，标签定位其次，目标检测/颜色追踪再次，巡线作为默认行为垫底。每次决策层输出指令前，先查一下当前激活的高优先级事件。比如正在巡线时，如果有语音指令进来，就立刻切到对应行为状态机；巡线过程中如果目标检测发现前方有障碍物，则进入避障状态，避障完成后回到巡线。
这个优先级表在代码里就是一个全局状态变量加一个状态切换管理器。有一点需要特别注意：任何状态切换都必须有“退出条件”和“超时保护”。比如踢球状态如果60秒都没找到球，就要自动回到默认巡线状态，不能死循环。加了超时保护之后，整个系统的鲁棒性会提升一个档次。
4.4 坐标换算：图像像素坐标到机器人运动指令的桥梁
视觉模块输出的是像素坐标，但机器人运动需要的是“向左转多少度”“前进多少厘米”。中间必须有坐标换算这一层。最简单的做法是用一阶近似：定义两条映射曲线，一条是横向像素偏差到转向角度，一条是目标面积到距离估计。
距离估计可以用针孔相机模型：已知目标真实宽度（比如球的直径），测量它在图像中的像素宽度，再结合相机焦距，距离就等于(真实宽度 × 焦距) / 像素宽度。这块需要一个量焦距的标定动作——放一个已知尺寸的物体在已知距离处，反解焦距。不标定也能凑合着用面积做粗粒度距离判断，但如果你想做搬运这种需要精确对准的操作，建议还是花十分钟标定一下。坐标换算写成一个独立模块后，视觉层和执行层就可以解耦，这是保证后面调参时不用到处改代码的关键。
5. 常见问题与排查技巧实录
5.1 多模态数据不同步，机器人“看到了但反应慢半拍”
这是多模态系统最典型的工程问题。原因是不同模块处理速度不同：颜色识别可能跑60帧，目标检测只有15帧，语音识别要200毫秒，大模型要一两秒。如果各模块各跑各的，决策层拿到的最新的视觉信息很可能已经是几百毫秒前的“旧照片”。
我的处理方式是为每个感知模块维护一个带时间戳的“最新结果缓存”，决策层读取缓存时不能只拿数据，还要看时间戳是不是太旧。比如踢球状态里，目标检测结果超过0.5秒没更新，就强制回到搜索状态，避免机器人朝着一个球已经跑开的位置空跑。另外要给不同模块分配独立线程，视觉采集和运动控制放到高频线程，大模型推理放到低频线程，通过一个“指令邮箱”通信，决策结果出来后才唤醒执行层。这样各个模块各司其职，不会互相阻塞。
5.2 光照变化导致颜色识别漂移，白天能用晚上失灵
颜色阈值是固定的话，换个场景就废了。这是我踩得最深的坑。第一版系统在室内实验室灯光下标定的红色阈值，拿到户外阳光下，整个画面被强光打白，色块全被过滤掉了；拿到偏暗的走廊里，又因为明度过低导致掩膜丢失。
解决办法是加一个“自适应曝光”环节：每次启动时先通过摄像头自动白平衡和自动曝光让画面整体亮度归一化，然后在程序里按亮度区间动态加载不同光照环境下的阈值参数。更稳妥的方案是不要只靠HSV阈值，而是结合目标检测模型一起判断——深度学习模型对光照的鲁棒性远好于纯颜色阈值。实际的配色方案可以做成：目标检测模型负责“候选区域找目标”，颜色识别负责“在候选区域内确认颜色”，两者互相印证，误检率会低很多。
5.3 语音识别被电机噪声干扰，机器人一动就听不清人话
人形机器人的舵机在工作时会发出持续的电机噪声，ReSpeaker这类麦克风离舵机又近，直接导致语音识别准确率惨不忍睹。我第一次实际测试时，只要机器人一走路，Vosk识别就完全变成乱码。
排查过程让我学到几个经验：第一，麦克风阵列的降噪算法一定要开，波束成形能明显抑制方向性噪声；第二，尽量给麦克风加减震结构，减少舵机振动传导；第三，也是最实用的，做“前端活动检测加静音期判断”，也就是语音识别只接收“机器人静止期间”的语音。比如唤醒词触发后，先让机器人停止运动，再开始录音，识别完再恢复运动。虽然交互上有一点停顿感，但准确率提升是质变级的。做项目演示的时候，这个停顿反而让交互更有“机器人正在思考”的感觉。
5.4 大模型输出不稳定，同一个指令每次返回的JSON格式都不同
大语言模型本质是概率模型，它可能这次返回合法的JSON字符串，下次就带上一段“好的，我来帮你”之类的废话。这会让解析代码非常痛苦。我的对策是双保险。
第一，Prompt里除了给出“只输出JSON”的明确指令外，还提供一个严格的输出模板示例，用“few-shot”的方式把期望的JSON结构写死。第二，代码里绝不直接信任模型的原始输出，要写一个“JSON提取函数”：从模型响应中尝试抽取大括号包裹的最外层JSON段落，先用json.loads解析，失败就做简单的字符串清理，比如去掉多余的引号、截断解释性文字，实在解析不出来就让模型重新生成一次。实测下来，加上这层容错之后，同一个Prompt连续调用几十次基本都能稳定解析。
5.5 目标检测在板子上跑不到实时帧率
如果模型在Jetson Nano上跑不到15帧以上，运动控制就会感觉很“肉”，机器人反应迟钝。如果不方便换硬件，优先做这几件事：换更小的模型（比如YOLOv5s换成YOLOv5n），把输入分辨率从640降到416甚至320，关闭预处理里的多余环节，只对ROI区域做推理而不对整幅画面做。还有一个容易被忽视的点：并不是所有画面都需要跑目标检测。巡线状态里主要用HSV巡线，完全不用跑目标检测；只有系统需要寻找特定目标时才启动YOLO推理。按需调用模型而不是每帧全跑，是嵌入式系统性能优化最重要的一招。
6. 我的几个实操体会
6.1 跑通一个简单闭环，比追求每个模块的完美更重要
这个项目最大的陷阱是，各个模块单独看都很容易“再优化一下”，但系统集成时才能真正暴露问题。我强烈建议按“最小闭环”的顺序推进：先让颜色识别检测到红色球，然后让机器人转圈找球，找到就踢出去——这一步只用一个摄像头、一个颜色识别、一个踢球动作。跑通之后再加语音，让用户说“踢红球”能触发刚才这套动作。再加目标检测替换颜色识别。最后再接大模型做复杂指令解析。每加一层，系统的稳定性都建立在上一层已经验证过的基础上，排查问题会轻松非常多。
6.2 多模态融合不是“越多越好”，而是“该用什么就用什么”
这个项目标题里功能多到令人眼花缭乱，但实际运行的时候，系统每时每刻都不会同时用所有能力。巡线时只开线路识别，找球时开颜色识别，交互时开人脸检测，搬运时开目标检测。多模态融合的本质是做“信息路由”——根据当前任务选择最合适的感知通道，而不是把所有感知数据一股脑塞给决策层。大模型的价值恰恰体现在它能根据当前场景决定“现在应该问视觉要什么信息”，这才是这个项目真正值得深挖的点。
6.3 后续扩展方向
这个项目做完之后，可扩展的空间还有很大。比如接入SLAM做自主建图导航，让机器人不再依赖巡线；接入视觉语言模型做开集目标检测，让机器人能理解“把那个比盒子小的东西拿过来”这类更抽象的目标描述；把固定状态机换成大模型驱动的任务规划器，让模型自己决定先踢球还是先搬运。每一个方向都是在现有架构上加一个模块的事，这也正是当初坚持做分层架构的价值。如果你正在规划类似的机器人项目，希望上面这些经验能帮你少踩几个坑，先把闭环跑起来，再谈算法深度。
本文还有配套的精品资源，点击获取