人工智能在数字领域的辉煌成就已是众所周知，而现在，各大科技巨头正将焦点转向机器人技术的实体世界应用。Google的PaLM项目和特斯拉的Optimus机器人便是其中的佼佼者。
01
—
基于Agent的机械臂控制
去年末，我创建了一个集成了智能代理Agent的机械臂演示程序（详情见《当AI进入物理世界：让你用嘴而不是用程序操作机械臂》），并将这段简单的演示视频分享到了B站。它的火速流行超出了我的预期——那短短的几十秒视频竟吸引了成千上万的观看次数，不少观众通过私信表达了他们对开源代码的期待。
当时，我认为程序还远非成熟，加之代码是临时写在一个无直接关联的代码库中，我选择了不开源。
但鉴于大家的热情，我抽出时间创建了一个名为mnlm（https://github.com/small-thinking/mnlm）的代码仓库，专门用于整理并分享相关的代码。在这个仓库中，我不仅整理了之前演示的代码，还引入了新的功能，比如仿真模拟和基于RAG的指令集检索。
以下是使用RAG + 函数调用的基于Agent的机械臂控制演示。与之前的尝试不同，这次我使用了模拟的机械臂进行演示。同样的算法也可以应用于实体机械臂。
在仿真方面，我利用ROS2的仿真系统Gazebo构建了一个虚拟机械臂，使我们无需实体机械臂即可进行操作实践。这个机械臂在审美上可能不太讨好，但请尝试以抽象的美来欣赏它。
至于RAG，这是一次初步的探索。在先前的研究中，我注意到即使是OpenAI GPT，面对特定领域的API——例如特定型号机械臂的API，以及特定的需求——比如通过自然语言生成API调用序列时，生成的代码质量通常不尽人意。对于稍微复杂一些的任务，模型往往显得力不从心。
02
—
MNLM：木牛流马？
MNLM，简称自古代中国的木牛流马——那些传说中由诸葛亮或其团队制造的机械，用以自动搬运粮食，显示了早期工程学的非凡智慧。这些机械以木头为材料，拟造牛的形态，得以沿坡而下，毫不费力地运送重载，因而得名。它不仅代表着技术的进步，也象征着创新精神的传承。
这里只用了MNLM而没有用木牛流马，因为我不想把这个名字浪费掉了。正式的名字还是留给更加配得上的项目吧。
03
—
总体架构
对于有兴趣进一步了解技术细节的朋友，我们可以继续往下看。下图是一个系统的总体结构。我把这个系统拆成了两部分，远程控制端以及机械臂端。
之所以有这样的架构，是因为我现有的机械臂性能还很弱，核心部件是Nvidia Jetson Nano，只有2G显存。这是我能找到的具有GPU的性价比最高的硬件了。让这个小巧的硬件运行复杂的Agent程序显然是不太现实的。因此，我只在机械臂端保留了最基本的物理控制部分，并将逻辑处理任务转移至远程端。
这种分工，其实连土豪的Google在PaLM-SayCan(https://blog.research.google/2022/08/towards-helpful-robots-grounding.html)项目中也是这么干的。我有幸参加了PaLM-SayCan作者的讲座。他们也提到如果把所有逻辑都放在机器人端，他们的硬件也是满足不了需求的。因此他们也是把大模型放在云端，而机器人端放了一个小模型主要作为执行。
04
—
远程控制
远程控制端实际上就是我的笔记本电脑。目前，远程控制逻辑依赖于OpenAI的Whisper技术来处理语音识别和生成。当然我们也可以用我在《让我们来做一个流浪地球中的MOSS》一文中介绍的本地方案来处理。
此次更新中，我在本地增加了机械臂知识库，并采用了RAG技术来提升机械臂执行复杂任务的能力。虽然目前这一部分还处于初步阶段，它已经能够执行一些基本的任务。
未来，我们可以在RAG中嵌入多个元逻辑单元，每个单元专注于完成一个基础动作，并可根据输入的参数进行定制。Agent通过重复调用这些逻辑单元，能够组合出完整的命令序列，这不仅提升了指令生成的可靠性，同时也克服了传统RAG的局限性。
比如，一个复杂的任务，LLM会先把它拆解成足够小的元任务，而每个元任务的信息是存放在知识库的。这时候LLM需要通过去抽取元任务模板，然后填入参数发送给远端。这样就是一个RAG+function call的过程。
05
—
机械臂端
在机械臂端，由于大部分逻辑处理都通过远程的Assistant API完成，它的角色主要是执行命令。关键在于要合理解耦各逻辑模块，以便独立进行迭代和升级。为了提高测试效率，我引入了命令解析和分发机制，确保相同的命令既可以用于仿真环境，也可以用于实际的机械臂硬件，保持操作的一致性和高效性。
06
—
一些启示：技术融合的艺术与挑战
这个项目的工作量，远远超出了我最初的预估。我第一个demo大概是在一个漫长的周末完成的，而这个项目则是在碎片化的时间中，跨越了一个月才得以完成。我认为这背后的主要原因是，为了让一个机器人项目顺利运行，所需涉猎的知识范围极其广泛。当前这个项目已经触及了软件架构、机器学习、建模、仿真模拟以及机器人技术等领域，每个部分我可能只触及到表层，但单是将这些不同的技术整合在一起，就已经是一项不小的挑战了。这还没有包括到更深层次的硬件设计。在这一点上，我不禁要对稚晖君那种从电路设计到软件开发的全栈能力表示敬佩。
做架构是一项复杂的任务。可能每个领域的专家都会认为，架构师在他们的专业领域知之甚少。但架构师的角色是作为不同领域之间的“粘合剂”，而非单一领域的专家。
06
—
需要改进的地方
至于改进的空间，这涵盖了项目的方方面面。举例来说，就是之前提及的RAG。当前的实践方式过于固定，基本上是让机械臂严格按照指令集执行任务。如果我们能将检索内容改成可参数化和可组装的，那么我们就能为Agent提供更大的自由度和灵活性。当然，这也要求Agent拥有更强的推理能力，能够将复杂的任务分解得更为彻底。
目前，机械臂端仅负责执行命令，没有反馈机制。在现实操作中，机器人可能会遇到需要互动和校正的情况，这就要求控制端和执行端保持持续的沟通。如何让机器人在最小化沟通的同时，也能自适应地执行任务，是我们需要重点关注的问题。
当前系统还缺少视觉功能。有了视觉能力之后，机器人的适应性应该会得到显著提升。即使只有2GB显存，实现Yolo算法也是可行的。随着最近Yolo V9的推出，我们有机会探索这一新领域。Yolo V9引入了可编程梯度信息（PGI）和通用高效层聚合网络（GELAN），其中PGI确保数据不丢失，精确地更新梯度，而GELAN则优化了轻量级模型的梯度路径规划。
现在还没有视觉，在加上视觉后机器人的适应能力应该更强。2G的显存报一个Yolo还是可以的。正好最近Yolo9出来了，可以试一试。
一周前新鲜出炉的Yolo V9，项目可见于https://github.com/WongKinYiu/yolov9
虽然RAG在当前阶段似乎足够应对一些基本情景，但在机械臂缺乏反馈和自适应能力时，它的效果会受到限制。一旦应对的场景稍有复杂，就需要具备更高级“智能”的机械臂。这将是我们未来工作的重点，目标是使机械臂不仅仅是简单的命令执行者，而是能够感知、思考并自主做出决策的智能伙伴。
06
—
展望未来
在谷歌和特斯拉之后，Nvidia也宣布加入智能机器人的行列。近日，Jim Fan宣布他将领导Nvidia的全新GEAR团队，专注于具身智能的开发。如果人工智能想要更直接地改变每个人的生活，它就必须跨入物理世界，这是一个我们都已经意识到的趋势。
