From the Hugging Face Hub to robot hardware with Strands Agents and LeRobot
TL;DR · AI 摘要
Hugging Face Hub 与 Strands Agents 和 LeRobot 的集成实现了从数据到物理机器人的端到端流程,简化了机器人开发。
核心要点
- Strands Robots SDK 将 LeRobot 栈作为 AgentTools,实现单个 Strands agent 的集成。
- LeRobotDatasets 在仿真和硬件中使用相同的格式,简化了数据处理。
- 通过一个关键字参数更改,即可将仿真中的代理代码部署到物理机器人 SO-101。
结构提纲
按章节快速跳转。
- §引言
介绍从 Hugging Face Hub 到机器人硬件的集成流程。
Strands Robots 是 AWS 提供的开源 SDK,用于机器人抽象、仿真和 LeRobot 栈的集成。
LeRobot 的脚本处理硬件记录和校准,Strands AgentTools 用于代理的实际协调。
- ·代理流程
代理流程包括构建代理、记录演示、运行策略、部署到物理机器人和广播命令。
- ›示例应用
示例应用可在 GitHub 上克隆,并在仿真环境中运行,无需硬件或 GPU。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- Hugging Face Hub 到机器人硬件
- Strands Robots SDK
- LeRobot 栈集成
- AgentTools
- 代理流程
- 记录演示
- 运行策略
- 部署到物理机器人
金句 / Highlights
值得收藏与分享的关键句。
Strands Robots SDK 将 LeRobot 栈作为 AgentTools,实现单个 Strands agent 的集成。
LeRobotDatasets 在仿真和硬件中使用相同的格式,简化了数据处理。
通过一个关键字参数更改,即可将仿真中的代理代码部署到物理机器人 SO-101。
从 Hugging Face Hub 到机器人硬件:使用 Strands Agents 和 LeRobot
返回文章列表
[0
[-1
企业
]
文章
发布于 2026 年 6 月 17 日
点赞
9
[
- +3
Sundar Raghavan
rsundaraws
关注
亚马逊
Cagatay Cali
cagataydev
Strands 机器人中 LeRobot 集成的逐步指南:从 Hub 数据集到物理机器人的单个代理循环,使用与真实世界相同的磁盘格式的仿真到现实数据集,以及通过字符串切换策略。
你拥有一台机器人、Hugging Face Hub 上的一个演示数据文件夹,以及你想让它学习的新任务。今天,这需要使用五个不同的工具:一个用于记录新的演示,另一个用于训练,第三个用于在仿真中测试,自定义代码用于部署在硬件上,还有一个用于协调多个机器人时的工具。这些工具各自独立工作,但它们之间并不进行通信。
Strands Robots 是 AWS 提供的一个开源 SDK(Apache 2.0 许可证),它将机器人抽象、仿真和 LeRobot 栈作为 AgentTools 暴露出来,你可以将这些 AgentTools 组合成一个 Strands 代理。集成设计得非常轻量:LeRobot 自己的脚本处理硬件记录和校准,而 Strands AgentTools 用于代理实际协调的部分。仿真工具以与 LeRobot 在硬件上写入相同格式的方式记录 LeRobotDatasets。GR00T 和 LerobotLocal 通过通用接口提供策略推断,而 MolmoAct2 的检查点通过 LerobotLocal 路径运行。对等网络将代理扩展到远程机器人。数据集格式保持与 LeRobot 写入的一样;代理循环是连接它们的粘合剂。
本文将带你逐步了解单个代理内部的五个步骤:使用 LeRobot AgentTools 构建代理、在仿真中记录一个演示作为 LeRobotDataset、在同一条机器人上运行策略、通过一个关键字参数更改将相同的代理代码部署到物理 SO-101 上,以及通过 Zenoh 网络在舰队中广播命令。最后,你可以从 GitHub 克隆工作示例应用程序,并在你的笔记本电脑上进行仿真运行。对于默认路径,不需要硬件、不需要 GPU、不需要 Hugging Face 凭证。这篇文章的可运行配套示例位于 examples/lerobot/hub_to_hardware.py 和 hub_to_hardware.ipynb。默认情况下,笔记本仅用于仿真,并使用 Mock-policy。
你将构建的内容
Strands Robots SDK 将 LeRobot 栈作为 AgentTools 暴露出来,你可以将这些 AgentTools 组合成一个 Strands 代理。本文中的示例代理执行四个操作:在仿真中记录新的演示,将结果作为 LeRobotDataset 推送到 Hub,对相同格式在仿真中运行策略,并通过一个关键字参数更改将相同的代理代码部署到物理机器人上。当你拥有多个机器人时,代理可以通过内置的对等网络协调整个舰队。对于硬件记录和校准,LeRobot 自己的命令行工具(lerobot-record、lerobot-calibrate)处理启动;代理从那里继续执行。
图 1. Robot("so100") 默认使用 MuJoCo 支持的仿真;mode="real" 返回由 LeRobot 驱动的硬件机器人。两种模式共享相同的 DatasetRecorder 和相同的策略提供者,因此在仿真中捕获的数据集和在硬件上捕获的数据集使用相同的磁盘 LeRobotDataset 格式。
两个设计选择使得这一切成为可能。首先,默认情况下,Robot("so100") 返回一个模拟环境(没有硬件,没有风险),而 mode="real" 返回由 LeRobot 驱动的硬件机器人。代理代码在这两种模式下是相同的。其次,用于写入 LeRobotDataset 的 DatasetRecorder 在模拟路径和 LeRobot 自己的硬件记录之间是共享的,因此在 MuJoCo 中捕获的数据集和从物理 SO-101 捕获的数据集采用相同的格式。
整个工作流程只需五行 Python 代码:
from
strands_robots
import
Robot
from
strands
import
Agent
arm = Robot(
"so100"
)
# mode="sim" (默认 - 安全,无硬件)
agent = Agent(tools=[arm])
agent(
"Pick up the red cube"
)接下来,我们将逐步介绍在调用过程中实际发生的事情。
先决条件
#### 最小(默认模拟路径)
- Python 3.12+,运行在 Linux 或 macOS 上(支持 Apple Silicon 的 MuJoCo 后端)。
- 用于代理推理的 Strands 兼容模型提供者。Amazon Bedrock(需 AWS 凭证)、Anthropic API、OpenAI 或本地运行的 Ollama。
- 安装 Strands Robots 并包含以下安装扩展:uv pip install "strands-robots[sim-mujoco,lerobot,mesh]"
以上就是全部。本文中的示例可以在具备这三个条件的笔记本电脑上端到端运行。
#### 高级(硬件部署,真实策略,推送至 Hub)
- 一个具有写入权限的 Hugging Face 账户和令牌,用于将数据集推送到 Hub 并从 Hub 拉取策略检查点。
- 对于硬件路径:一个 SO-101 的跟随者和领导者对,或任何其他 LeRobot 支持的机器人。这两台设备都需要校准文件,位于 ~/.cache/huggingface/lerobot/calibration/ 目录下。
- 对于本地 GR00T 推理:一个至少有 16 GB 显存的 NVIDIA GPU,并且已安装 Docker。本文使用 gr00t_inference 工具的 lifecycle="full" 动作,该动作在一个调用中拉取镜像、下载检查点并启动容器。
步骤 1 - 设置示例
安装 Strands Robots 并获取示例文件:
uv pip install
"strands-robots[sim-mujoco,lerobot,mesh]"
git
clone
https://github.com/strands-labs/robots.git
cd
robots如果你希望代理将数据集推送到 Hub 或从 Hub 拉取策略,请导出你的 Hugging Face 令牌。对于本文中的默认模拟路径,这是可选的;示例可以在不连接任何硬件的情况下通过 Mock 策略端到端运行,并将数据集写入你的本地缓存,无需 Hub 访问权限。
export
HF_TOKEN=hf_...可运行的示例位于 examples/lerobot/hub_to_hardware.py(Python 脚本)和 hub_to_hardware.ipynb(笔记本)中,与 MuJoCo 和 LIBERO 示例一起位于 strands-labs/robots 仓库中。建议从笔记本开始:在 JupyterLab 中打开它,并在模拟模式下从上到下运行单元格,无需连接任何硬件。
步骤 2 - 记录演示并推送到 Hub
模拟工具以与 LeRobot 在硬件上写入相同格式的方式记录 LeRobotDatasets。不需要硬件。模拟工具的 start_recording 动作通过相同的 DatasetRecorder 类写入:关节状态和动作的相同 parquet 架构,相同每台相机的 MP4 布局。代理提示几乎相同:
from
strands
import
Agent
from
strands_robots
import
Robot
robot = Robot(
"so100"
)
# 默认 mode="sim"
agent = Agent(tools=[robot])
agent(
"Record a demonstration of 'pick the red cube and place it in the box' "
"using the Mock policy provider at FPS 30. Write the dataset to "
"my_user/cube_picking_sim and push to the Hub when done."
)图 2. MuJoCo 模拟中的录制场景:SO-100 机械臂向地面上的红色立方体伸展,被记录到 LeRobotDataset 中。对于这个默认路径,不需要任何硬件、GPU 或 Hugging Face 凭证。
Mock 策略是故意设置的:它生成占位符关节动作,使工作流程能够端到端运行,而无需训练检查点。机器人通过随机运动移动,而不是完成抓取,录制的结构是完整的(有效的关节状态、有效的相机帧、结构良好的 LeRobotDataset 集合),但演示本身作为训练数据没有用处。下面的步骤 3 会用 GR00T 或 LerobotLocal 替换为真实的抓取行为。要在这个步骤中看到实际的立方体抓取,运行 --policy lerobot_local --checkpoint allenai/MolmoAct2-SO100_101(一个 MolmoAct2 检查点,从其 config.json 自动检测并通过 LerobotLocal 路径路由);提示、数据集格式和代理代码保持不变。
接下来发生的事情就是证明。LeRobot 自己的数据集加载器读取模拟录制的数据,不需要任何 Strands 特定的代码路径:
from
lerobot.datasets.lerobot_dataset
import
LeRobotDataset
dataset = LeRobotDataset(
"my_user/cube_picking_sim"
)
print
(dataset.features)
# {'observation.state': Sequence(...),
# 'observation.images.front': VideoFrame(...),
# 'action': Sequence(...),
# 'episode_index': Value(...), 'frame_index': Value(...), ...}这个 features 字典的形状与任何 Hub 上的 LeRobot 数据集相同:相同的列名、相同的 parquet+MP4 布局、相同的加载路径。消耗硬件录制数据的训练脚本可以无修改地消耗模拟录制的数据。如果需要,从模拟中推送的数据集将与硬件录制的数据集并列在同一个 Hub 仓库中。
从记录的 LeRobotDataset 中播放一个单独的集,从记录器写入的每个摄像头的 MP4 播放,训练脚本读取的磁盘视频是相同的。
#### 在硬件上录制
要在物理 SO-101 上而不是在模拟中录制演示,直接使用 LeRobot 的 record CLI。Strands 集成不会将该命令包装为 AgentTool,因为 LeRobot 已经干净地完成了这项工作:
lerobot-calibrate --robot.type=so101_follower --robot.id=my_follower
lerobot-calibrate --robot.type=so101_leader --robot.id=my_leader
lerobot-record \
--robot.type=so101_follower --robot.id=my_follower \
--teleop.type=so101_leader --teleop.id=my_leader \
--dataset.repo_id=my_user/cube_picking \
--dataset.single_task=
'Pick up the red cube and place it in the box'
\
--dataset.num_episodes=25 \
--dataset.push_to_hub=
true从这个命令上传到 Hub 的数据集与模拟录制的数据集格式相同。要在其上微调策略,运行 LeRobot 的训练 CLI(lerobot-train);训练本身超出了本文的范围,遵循标准的 LeRobot 工作流程。从步骤 3 开始,代理可以交替使用原始检查点或微调后的检查点。有关完整的 SO-101 硬件设置、校准流程和故障排除,请参阅示例文件夹中的 README。
步骤 3 - 在模拟中运行策略
有了 Hub 上的数据集,下一步是运行策略。示例使用默认模拟模式中的 Robot() 工厂,然后附加 gr00t_inference,使代理能够管理推理容器:
from
strands
import
Agent
from
strands_robots
import
Robot, gr00t_inferencerobot = Robot(
"so100"
)
# mode="sim" by default
agent = Agent(tools=[robot, gr00t_inference])
agent(
"Start GR00T inference on port 5555 with the cube-picking checkpoint "
"from my_user/cube-picker. Then ask the robot to pick up the red cube."
)在内部,代理运行 gr00t_inference(action="lifecycle", lifecycle="full", ...) 来拉取 GR00T 容器镜像,从 Hub 下载检查点,并启动推理服务。然后,它在模拟机器人上运行 run_policy 操作,使用 policy_provider="groot",在 policy_config 字典中传递 GR00T 服务的主机和端口(容器可以通过 5555 端口访问)。模拟过程会根据策略的操作块进行,可以通过 Simulation.render 查看结果的渲染。
图 3。使用经过训练的策略(GR00T 或 MolmoAct2 检查点),代理在模拟中驱动 SO-100 抓取红色立方体,这是 Mock 策略所代表的行为。
对于更倾向于本地推理(不使用容器、不使用 ZeroMQ (ZMQ))的开发人员,可以将 gr00t_inference 替换为从 Hub 仓库加载的 LerobotLocalPolicy 实例。提供者会将任何在 lerobot/ 组织下的模型 ID 路由到本地推理路径:
from
strands_robots.policies
import
create_policy
policy = create_policy(
"lerobot/act_aloha_sim_transfer_cube_human"
)LerobotLocalPolicy 支持 ACT、Diffusion Policy、SmolVLA、π0 和 π0.5,任何 LeRobot 自己的策略注册表都可以从 config.json 解析。对于带有 rtc_config 的流匹配策略(π0、SmolVLA),实时分块会自动启用。
NVIDIA 最近发布的 Cosmos 3 也通过相同的接口作为策略提供者可用,因此无论指向哪个提供者,代理代码保持不变。
注意:LerobotLocalPolicy 使用 trust_remote_code=True 加载 Hugging Face 模型。设置 STRANDS_TRUST_REMOTE_CODE=1 以启用此功能,并且仅从您信任的组织加载检查点。
第 4 步 - 将策略部署到物理硬件
这与第 3 步的代码相同,只是更改了一个关键字参数。Robot 工厂返回一个由 LeRobot 的 make_robot_from_config 驱动的硬件支持的机器人:
robot = Robot(
"so100"
,
mode=
"real"
,
port=
"/dev/ttyACM0"
,
data_config=
"so100_dualcam"
,
cameras={
"front"
: {
"type"
:
"opencv"
,
"index_or_path"
:
"/dev/video0"
,
"fps"
:
30
},
"wrist"
: {
"type"
:
"opencv"
,
"index_or_path"
:
"/dev/video2"
,
"fps"
:
30
},
},
)
agent = Agent(tools=[robot, gr00t_inference])
agent(
"Start GR00T inference on port 5555 with the cube-picking checkpoint "
"from my_user/cube-picker. Then ask the robot to pick up the red cube."
)现在,相同的代理提示将针对物理手臂运行。硬件路径使用 LeRobot 的机器人抽象来执行关节命令和摄像头读取,而 GR00T 容器通过 5555 端口可访问,生成操作块。
在向您的 SO-101 运行之前,必须对跟随者和领导者进行校准。每个设备运行一次 LeRobot 的校准命令(lerobot-calibrate);校准文件将保存在 ~/.cache/huggingface/lerobot/calibration/ 下,任何涉及硬件的 Strands 代码路径都会从那里读取它们。如果缺少校准,代理会从 LeRobot 驱动层显示错误。
第 5 步 - 使用 mesh 协调多个机器人
到目前为止,我们一次只控制一个机器人。Mesh 是 Strands Robots 用于同时控制多个机器人的方法。想象一下,你的桌面上有一个 leader 臂,它远程操作另一个房间中的 follower 臂,或者五个 SO-101 同时并行执行同一个仓库任务,或者一个人形机器人与一个移动底盘协同工作。所有这些情况都属于 mesh 模式。Mesh 是基于 Zenoh 构建的,Zenoh 是一个开源的对等协议,你不需要管理 IP 地址、编写发现代码或选择代理;当新机器人上线时,它们会立即出现在 mesh 中,代理可以同时与所有机器人通信。
每个 Robot() 和每个 Simulation() 都会自动加入 Zenoh 的对等 mesh。robot_mesh 工具为舰队操作(如发现、结构化命令、广播和紧急停止)提供了代理的词汇:
agent = Agent(tools=[robot_mesh])
agent(
"列出 mesh 上的每个机器人和仿真。"
"然后并行地向每个机器人发送 'go to home pose' 命令。"
)代理调用 robot_mesh(action="peers") 来枚举本地和发现的对等节点,然后调用 robot_mesh(action="broadcast", ...) 向每个对等节点发送结构化命令,并设置超时时间。添加 [mesh-iot] 附加项,可以通过 AWS IoT Core 路由流量,实现跨网络舰队的通信。项目文档中 robot_mesh 工具的动作参考涵盖了完整的词汇:订阅、监视、收件箱和结构化对等命令。
默认情况下,每个实际执行的 mesh 操作在运行前都会暂停,等待人工批准中断:包括舰队范围的广播和紧急停止,以及单个对等节点的 tell、send 和 stop 操作。你可以通过 STRANDS_MESH_HITL_ACTIONS 环境变量来调整这个集合(设置为 all、none 或逗号分隔的子集)。第一次运行这个示例时,你会在终端看到 robot_mesh-broadcast-approval 提示;输入 y(或 yes / approve)以授权广播。批准是通过 LLM 的工具参数之外的通道进行的,因此试图将批准标志插入命令体中的提示注入尝试无法绕过这个门禁。
传输层可以在不修改代理代码的情况下进行扩展。内置的 Zenoh mesh 是默认的自动回退方案:在局域网中,Zenoh 多播处理对等节点发现,无需代理;添加 [mesh-iot] 附加项后,流量将通过 AWS IoT Core(MQTT5 与 mTLS)进行路由,适用于云舰队,BridgeTransport 通过一个 API 同时支持局域网和云(通过 STRANDS_MESH_BACKEND=bridge 进行选择)。
对于生产舰队,Device Connect 是与 Arm 合作开发的设备感知网络层,它处理发现、存在、结构化 RPC、事件路由和安全性。当 Device Connect 可用时,robot_mesh 工具会通过 Device Connect 进行调度,否则会回退到内置的 Zenoh mesh,因此本文中的代理代码在任何情况下都保持不变。有关设置和当前可用性的信息,请参阅 Device Connect 文档。
使用示例应用程序尝试
完整的示例在 GitHub 上的 strands-labs/robots 项目中的 examples/lerobot/ 文件夹中。它将所有五个步骤打包成一个 CLI 脚本(hub_to_hardware.py)和一个笔记本(hub_to_hardware.ipynb)。CLI 默认使用 Mock 策略在仿真中端到端运行,不需要 GPU、Docker 或 Hugging Face 凭据。
uv pip install
"strands-robots[sim-mujoco,lerobot,mesh]"
git
clone
https://github.com/strands-labs/robots.git
cd
robots
export
STRANDS_MESH_LOCAL_DEV=1
python examples/lerobot/hub_to_hardware.py记录的数据集将保存在 ~/.cache/huggingface/lerobot/local/strands-cube-pick/ 目录下。如果你想将数据集上传到 Hugging Face Hub 而不是本地保存,可以在导出 HF_TOKEN(具有写入权限)后,添加 --hf-user <your-user> 参数。在第 3 步中,若要实现真实的抓取行为,可以使用 --policy groot --checkpoint <hf_repo>(需要 Docker 和 NVIDIA GPU)或 --policy lerobot_local --checkpoint <hf_repo>(需要 GPU 以及设置 STRANDS_TRUST_REMOTE_CODE=1)。
Notebook(examples/lerobot/hub_to_hardware.ipynb)逐步展示了相同的流程,并在每一步之间添加了说明。在 JupyterLab 中打开该 notebook,并以仿真模式从上到下运行。
安全注意事项
在本设置中展示的代码片段只是使用 Strands 机器人和 HuggingFace 进行设置的一个“Hello World”示例。对于更严肃、适合生产环境的使用场景,用户需要注意以下几点:
#### 提示注入(Prompt Injection)
将不可信的数据输入代理可能会导致提示注入,即不可信的上下文被当作 LLM 的指令处理。由于这些机器人在物理空间中执行操作,这是一个需要特别关注的风险。为缓解此类行为,开发者应确保只向机器人提供来自可信来源的数据。如果无法确保所有输入数据都是可信的,开发者应限制代理可用的工具,以防止机器人执行关键安全操作。
#### 机器人网格认证行为(Robot Mesh Auth Behavior)
在本博客文章中代码片段中共享的 STRANDS_MESH_LOCAL_DEV=1 设置会在没有认证或访问控制的情况下初始化机器人网格。这意味着同一网络上的任何设备都可以向机器人舰队发送指令。这在可信的开发环境中是可以接受的,但不适合于不可信的网络或生产环境。对于这些使用场景,需要设置 STRANDS_MESH_AUTH_MODE=mtls。
#### 群组操作的人员批准(Operator approval for fleet-wide actions)
机器人网格工具的物理操作行为会影响网络上的其他节点:broadcast 和 emergency_stop 会发送给所有节点,而 tell、send 和 stop 会发送给一个特定的目标节点。为了防止代理自主执行这些命令(或在提示注入下执行),默认情况下所有五种操作都需要人工干预。当代理调用受限制的操作时,Strands 运行时会暂停代理循环,并要求操作员在带外批准 LLM 工具的参数。你可以通过 STRANDS_MESH_HITL_ACTIONS 环境变量调整受限制的操作集合(all、none 或逗号分隔的子集)。每项操作的速率限制、命令验证和审计记录会与中断机制一同运行。在代理循环之外(如裸脚本或单元测试),受限制的操作将默认失败。
清理
前面的流程启动了一个 GR00T 容器,打开了硬件上的串行端口,并写入了本地数据集缓存。要将你的环境恢复到干净状态:
- 停止 GR00T 推理容器:
agent.tool.gr00t_inference(action="stop", port=5555),或者使用lifecycle="teardown"来移除容器。
- 释放串行端口:如果你运行了硬件路径,请断开 SO-101 的跟随者和领导者。
- 可选地删除本地数据集缓存:记录的数据集保存在
~/.cache/huggingface/lerobot/<repo_id>目录下。你上传到 Hub 的数据集不受影响。
整体结构
以上内容展示了各个组件如何协同工作。
该集成的核心设计选择是 Strands Robots 不会重新实现 LeRobot 已经提供的功能。硬件抽象、校准和数据集格式都保持在上游。Strands 增加了 AgentTool 接口,使这些功能可以通过自然语言进行组合使用。
由此带来了两个结果。对于用户而言,Hub 上的每一个数据集都可以作为代理扩展、微调和部署的资源,无需任何转换步骤。对于开发者而言,仿真数据和硬件数据共享相同的文件格式,因此为一种数据编写的训练脚本可以原封不动地用于另一种数据。仿真与现实之间的界限成为部署的细节,而不是架构上的分界。
下一步
图 4。Strands Robots 的产品目录涵盖了机械臂、人形机器人、四足机器人和机械手,所有这些都在相同的 MuJoCo 仿真环境中,并通过相同的 Robot() 工厂进行创建。本文中提到的 SO-100 是众多支持的实体之一。
完整的 Strands Robots 文档详细介绍了机器人目录、仿真、策略提供者、网格和 Device Connect。对于更大的工作负载,strands-labs/robots-sim 仓库托管了更强大的仿真后端,包括 Isaac Sim 和 Newton,以及一个 LIBERO 基准示例。这两个后端都插入到本文中展示的相同 Robot 抽象中,因此随着规模的扩大,代理代码保持不变。
欢迎在 Apache 2.0 许可下进行贡献。如果您使用此工作流程构建了某些内容,请打开一个问题,说明哪些部分有效,哪些部分无效。当开发者的反馈直接作用于需要改进的接口时,SDK 的改进速度最快。
资源
- Strands Robots(SDK、AgentTools、Robot 工厂):github.com/strands-labs/robots,Apache 2.0
- Strands Robots 文档(完整文档):strands-labs.github.io/robots
- Strands Robots 仿真(示例、仿真后端):github.com/strands-labs/robots-sim
- 示例:examples/lerobot/hub_to_hardware.py 和 hub_to_hardware.ipynb
- 如何构建物理 AI 代理:用于现实世界机器人技术的自然语言:直播和博客
- 深入探讨物理 AI | S1E4 | 使用 NVIDIA NeMo Agent Toolkit 和 Bedrock AgentCore 自动化:直播
- LeRobot:github.com/huggingface/lerobot - 数据集、策略、硬件驱动
- Strands 代理 SDK:github.com/strands-agents/harness-sdk
- SmolVLA:SmolVLA
- Pi0:Pi0
- NVIDIA Isaac-GR00T N1.7:GR00T N1.7
- NVIDIA Cosmos3 Nano:Cosmos 3 Nano
作者
Cagatay Cali 是 AWS 的研究工程师,专注于代理 AI 和机器人技术。他设计了连接 AI 代理与物理机器人的接口,使开发者能够通过自然语言控制机器人系统,并使代理和机器人开发对各个技能水平的开发者都易于上手。
Sundar Raghavan 是 AWS Agentic AI 基础团队的高级解决方案架构师。他领导了 Amazon Bedrock AgentCore 的开发者体验,负责 SDK 和 CLI,并推动框架和生态系统集成策略。他关注开发者如何在 AWS 上构建、部署和扩展生产 AI 代理。他目前正在将这一关注点扩展到物理 AI,与 Strands Robots 合作,将相同的代理开发者体验带入机器人领域。
本文中提到的模型 5
更多来自该作者的内容
AWS 上基础模型训练和推理的构建模块
24
2026 年 5 月 11 日
社区
atsyplikhin
大约 24 小时前
[2
看到这一点真是太棒了!从 MuJoCo 模拟环境切换到 mode="real"(使用相同的智能体代码,相同的 LeRobotDataset 格式端到端)只需一个参数,这正是消除摩擦、让机器人智能体进入真实实验室的关键。像这样的工作让所有人都受益:我们越容易、越开放地实现智能体与硬件的控制,整个行业的发展速度就会越快。Arm 的 Device Connect 团队非常期待与大家合作!
🤝
1
+
回复
sondhiArm
大约 15 小时前
非常酷!
编辑
预览
通过拖拽、粘贴或点击此处上传图片、音频和视频。
点击此处上传图片
评论
· 注册或登录以发表评论