8 月 22 日，我在零一学院深圳总部，参加「创享无界·人人创新」2026 高通开发者城市创享工坊。

和许多技术活动不同，这一天留给产品介绍的时间并不算多，大部分时间都交给了开发板、终端、代码和现场调试。上午，我们尝试用一句自然语言指令调度多台小车；下午，又把视觉识别、目标追踪和电机控制串成闭环。

对我来说，这次活动最直观的感受是：Physical AI 已经不只是“把一个模型跑在板子上”，而是开始进入感知、决策、通信与执行相互配合的系统阶段。

从模型到应用，高通正在缩短Physical AI 的开发链路

活动开场，高通技术公司高级资深工程师李万俊介绍了 QAI AppBuilder AI Agent 一站式开发平台。

过去，将一个 AI 模型真正部署到端侧设备，往往需要依次处理模型获取、格式转换、量化、计算图生成、后端选择、编译以及板端集成。CPU、GPU、DSP、NPU 的能力边界不同，不同高通平台的工具链和接口也需要开发者逐一理解。模型能运行只是第一步，精度、速度、功耗和硬件兼容性还要继续优化。

QAI AppBuilder 想解决的，正是这条链路过长的问题。尤其是其最近更新的v3.0版本，新增对话生成应用功能：开发者可以直接描述目标，由 Agent 拆解任务、选择工具，并完成从模型资产到可运行应用的构建。现场演示中，“对话即开发”并不是简单生成几段示例代码，而是让 Agent 理解高通平台的专用 SDK、模型转换流程和加速后端，再组合出更接近真实部署要求的结果。

这一点给我留下了很深的印象。通用 AI 编程工具擅长写代码，但未必了解芯片平台的具体能力；平台专属的 Skill 和工程经验，则能帮助 Agent 找到更合适的转换、推理和加速路径。端侧开发门槛的下降，不只是少写几行代码，更重要的是少走一些工具链和兼容性上的弯路。

三块开发平台，把Physical AI 从“算力”带到“行动”

这次活动中，我们接触了三款基于高通跃龙™ 处理器的开发平台。

Arduino UNO Q 将高通跃龙™ QRB2210处理器与 STM32U585 集成在同一块载板上，让 Linux 网络应用与确定性的 I/O、电机控制可以协同工作。

搭载高通跃龙™ QCS8550处理器、拥有 48 TOPS AI 算力的犀牛派® X1，可承担更复杂的视觉处理、系统调度与本地大模型任务

瑞莎 Dragon Q6A 则搭载高通跃龙™ QCS6490处理器，提供 12 TOPS AI 算力，面向工业物联网、边缘智能和智能终端应用。

单独看，它们是不同定位的开发板；放进当天的实操场景里，它们更像是一套“感知—决策—执行”链路上的不同角色。高性能处理器负责看懂环境、规划任务，小车主控负责把上层指令稳定地转化为电机动作。Physical AI 因此不再停留在屏幕上的识别框，而是真正推动设备在物理世界中行动。

上午｜一句话，群车开始行动

上午课程由特邀讲师李江浩、宋魏宏从系统架构讲到现场调试，把机器人的“大脑计算”与“小脑运控”拆成可操作的步骤，带着各组开发者从环境配置开始，一步步跑通多车定位、规划、通信和执行。现场使用的犀牛派 X1、多类型小车、功能包和调度案例被组织成一条连续链路，让我们不仅能看到最终编队效果，也能理解每一层为什么这样设计。

传统机器人导航通常要为每台设备配置较完整的传感器和定位方案。这次系统采用顶部相机提供“上帝视角”，通过镜头畸变校正与 AprilTag 识别获取多台小车的位置和朝向。这样的设计减少了单车传感器的复杂度，也让开发者能把更多精力放到路径规划、编队调度和控制逻辑上。

现场系统的分工很清晰：

• 犀牛派 X1 连接顶部相机，处理视觉定位、图像校正和设备识别；

• PC 侧运行全局与局部路径规划、多车调度，以及本地大模型的自然语言解析；

• 小车主控负责底层驱动，将速度指令转换为电机 PWM 信号，并结合实时位置反馈完成闭环控制。

PC 与 X1 之间通过 ROS 2 DDS 交换定位和规划数据，X1 与小车之间则通过 MQTT 下发控制指令。Linux 侧负责网络、Python 应用和高层通信，MCU 侧负责确定性的电机 I/O 控制。把视觉、规划、通信和运动控制分层之后，原本复杂的多机器人系统变得更容易理解。

当然，真正上手并不是按下一个按钮就结束。我们需要连接对应分组的网络，确认设备 IP，在 Ubuntu 20.04 和 ROS 2 Humble 环境中编译工作空间，再依次启动相机、规划节点与调度服务。有人卡在 Wi-Fi 和 SSH，有人需要重新确认小车型号与 IP，也有人借助现场提供的启动盘进入开发环境。

这些看似琐碎的排障，反而让整个体验更真实。机器人系统的稳定运行从来不只取决于某个算法，而是依赖环境、网络、软件包、通信协议和硬件控制共同配合。

当所有节点终于连通，我们可以通过 RViz 或 Web 控制台发送目标点，也可以输入自然语言编队指令。本地模型把人的表达转换成调度任务，规划模块计算每台小车的路径，控制端再把速度命令落实为车轮动作。看到多台小车依次启动、避让并重新列阵时，“端侧大模型+机器人控制”不再是一张架构图，而是眼前真实发生的闭环。

现场让我印象很深的还有“虚拟墙”这一环。顶部相机通过 AprilTag 持续给出每台小车的位置和朝向，但它的主要任务是定位，并不会自动把场地里的每一处障碍都识别出来。讲师没有因此再增加一套传感器，而是让我们启动障碍物绘制工具，直接在相机画面上框选区域：按 r 可以拖出矩形，按 c 可以画圆，画错了还能撤销或一键清空。每完成一次绘制，新的障碍信息就会通过 /obstacles_live 发布出去，控制端的栅格地图和 RViz 随即更新。原本直指目标点的规划线，会在深色障碍区域出现后重新折转，再计算一条绕开的路线。这个变化不是演示视频里的预设效果，而是我们一边画、地图一边变、小车随后改道的即时反馈。

真正动手后才发现，虚拟障碍物也不是“画上去就完事”。现场场地只有一平米多点，规划器还要为小车本身留出安全空间：robot_radius 决定车体需要避让的基本范围，car_radius 表示其他车辆占据的空间，inflation_radius 则在障碍外围形成一圈由高到低的代价梯度。参数设得太大，几台车和虚拟墙的膨胀区很快就会把小场地“吃满”，根本搜索不到可行路径；设得太小，小车虽然有路可走，却更容易擦碰。我们需要对照 RViz 里的占据栅格、规划折线和实际行驶轨迹，一项项缩放半径、观察路径，再重新测试。到这里我才真正理解，这套方案的价值不只是“少装一个传感器”，而是把感知能力的边界摆到开发者面前，再用可视化、可调整的软件工具把它补齐。

下午｜让视觉云台“盯”住目标

下午的瑞莎 Dragon Q6A 视觉云台课程更聚焦单机感知与执行。相机负责获取画面，端侧模型完成颜色、人脸或通用目标检测；系统计算目标框中心与画面中心的像素偏差，再结合相机视场角和标定参数，将偏差换算为云台需要转动的角度。轨迹规划模块限制速度和加速度，双电机控制板通过编码器反馈、PID 与 FOC 控制，让云台稳定跟随目标。

实际调试中，我们仍要处理 Wi-Fi、SSH、SCP 权限和模型路径等问题。但当目标被锁定后，即使短暂遮挡，系统也会尽量保持对原目标的追踪。浏览器里不断变化的候选框、角度误差和推理帧率，最终都转化为云台平稳而及时的转动。

瑞莎总经理王培瑶在分享中提到，瑞莎希望通过开发板、镜像、工具链、文档和社区，把高通提供的底层能力转化为开发者更容易使用的物理 AI 平台。下午的实操正是这种思路的缩影：把高通跃龙QCS6490处理器的端侧算力，与相机、模型、电机和控制算法组合成一个可观察、可修改、可复现的完整项目。

一天之后，我对Physical AI 有了三个更具体的认识

第一，Physical AI 的价值不只在“离线运行”。低时延、数据本地处理和断网可用固然重要，但更关键的是，它能让感知结果直接进入控制闭环。无论是群车编队还是视觉云台，AI 都不是孤立模块，而是系统中的一个实时环节。

第二，工具链正在决定创新速度。芯片算力持续提升之后，模型转换、部署、调试和跨硬件适配会成为新的门槛。借助QAI AppBuilder 这样的 Agent 平台，把高通工程师积累的平台知识稳定沉淀为可调用的能力，就可能把Physical AI 开发从“少数专家才能完成”推向更多开发者可以参与。

第三，真正的开发体验一定包含排障。现场并非所有设备都一次连通，视觉定位也会受到反光和环境影响，模型路径与权限同样可能出错。但正是在这些问题被逐一解决之后，我们才真正理解一套 Physical AI 系统如何运行，也知道下一次应该从哪里开始检查。

让创造力成为Physical AI 的入场券

从上午让多台小车理解指令、协同移动，到下午让一台云台看见目标、稳定追踪，这一天跑通的是两条不同的技术路线，也是同一个完整逻辑：感知现实、理解任务、作出决策，再把结果交给设备执行。

高通提供的芯片算力、统一软件栈和 AI 开发工具，正在缩短从模型到真实设备的距离；生态伙伴则通过开发板、课程、案例和社区，把这些能力带到更多开发者手中。

活动结束后，我带走的不只是几个能够运行的案例，而是一种更清晰的判断：Physical AI 并不遥远。只要工具足够开放、链路足够清楚、实践机会足够多，开发者就能把一个想法，从自然语言、代码和模型，一路推进到物理世界里真正发生的动作。

深圳站收官，但属于开发者的Physical AI 实践，才刚刚开始。

*本文内容来自开发者投稿