使用机器学习套件和 Gemini Nano 在 Android 上构建 Formula E 副驾驶

大家好！

我叫 Alastair，今天很高兴能与大家聊聊我们去年与 Formula E 合作开展的一个项目。

今天，我邀请了 Oli 来和我们一起聊聊我们共同完成的工作。

我在 Google Cloud 的 CTO 办公室工作，我们经常尝试突破移动设备和云端技术的极限，并探索它们如何协同工作。

我将向您展示一个简短的视频，让您了解我们所做的工作。

第四代赛车拥有 600kW 的赛道猛兽。

全电动，全时全轮驱动。

我会用“快得惊人”来形容。

我们能否在 Pixel 手机上使用一个智能体，让它连接到汽车发出的遥测数据？

当驾驶员在古德伍德爬坡时，他们实际上可以与汽车对话。

这真的是太棒了！

Hey Gemma，我的轮胎怎么样？

胎压正常，大约 1.4 bar。

有一部手机直接插入 ECU，它会读取我作为驾驶员所做的许多数据点。

这是赛车领域首次实现这一突破。

我只是觉得没有比这里更适合展示它的地方了。

Gemma，准备好了吗？

无需等待，即开即用。

因此，我们希望通过该项目尝试将副驾驶智能体引入驾驶舱，与驾驶员并肩作战。

从根本上说，我们在这里要做的是突破边缘智能体的极限，因为这是一个非常具有挑战性的例子。

赛车面临的挑战显然是高温。

赛车容易发热是出了名的，这也是我们面临的最大挑战之一。

网络连接不稳定。

我们实际上是在古德伍德速度节上做这件事，那里聚集了成千上万的赛车运动爱好者，他们前来观看赛车爬坡赛。

可以想象，当一个场地里有数十万人时，网络连接会变得非常困难。

蓝牙。

比如，这辆车基本上就是一个法拉第笼，所以你可以想象，即使只是连接到赛车手的头盔，也会面临怎样的挑战。

最后，还有低延迟要求。

这位车手的时速超过 200 公里，因此，副驾驶智能体必须能够快速、敏捷地给出回答，这一点非常重要。

从根本上说，我们对此非常感兴趣，因为我们相信智能体将无处不在。

这种趋势已经初见端倪。

它们不再只存在于我们的电脑中。

它们存在于我们的手机、手表、眼镜、智能家居中，甚至现在还存在于我们的汽车中。

因此，从根本上说，我们非常想看看在这样的困难场景中能取得怎样的成果。

在构思如何构建这个系统时，我们曾想过：是否可以构建一个内置小型加速器的微型计算机，并在其中运行模型？

我们突然意识到，我们所需的所有要素其实都已经存在，那就是 Android。

Android 是运行这些智能体的理想平台，因为我们有 ADK，也就是智能体开发套件。

这是一个非常棒的库，可让您直接在应用中构建智能体。

我们有数十亿用户，而且可以在不同的设备规格上轻松运行，因此测试和分发代码本身都非常简单。

开发者工具，可让您调试和尝试不同的操作，并找出问题所在。

设备端 AI，Google Pixel 手机现在内置 TPU，专为手机上的设备端模型进行了优化，让开发者能够通过机器学习套件等 API 轻松调用强大的模型。

此外，我们还提供文字转语音和语音识别等功能，这些完全离线的 API 可让您获得真正强大的对话式体验。

最后，显然是连接。

手机专为连接性而设计，无论是通过移动网络、Wi-Fi 还是其他方式。

不过，边缘智能体也面临着一些挑战，比如它们无法完成所有任务。那么，它们如何与云端智能体协同工作呢？

如果采用混合解决方案，会怎么样？

如果手机中的智能体能直接与云端智能体对话，从而执行更复杂的操作，会怎么样？

例如，假设车手想知道自己的比赛排名。

赛车本身并不知道自己在比赛中的位置，但云端智能体可能知道。

我们还提供了一种名为“智能体到智能体”的协议，这意味着您可以在边缘和云端创建智能体，并让它们直接相互对话，以执行更复杂的操作。

那么，我们是如何构建它的呢？

因此，我将向您介绍该系统的组成部分。

从线束开始。

现在，这里的测试框架基本上是一个运行 Android 版智能体开发套件的 Android 应用。

第二部分是模型。

您需要一个模型来为其提供支持，而我们使用的是通过机器学习套件提供的 Gemini Nano，这是一款触手可及的强大设备端模型。

然后是数据。

Oli 稍后会对此进行简要介绍，但您不仅可以从汽车中获取数据，还可以从驾驶员那里获取语音识别数据。

最后，还有智能体可以执行的操作。

这可能是文字转语音，以便能够与驾驶员对话并提出后续问题或提供所需信息，或者如前所述，智能体与智能体之间进行通信，与云端智能体进行通信以执行一些更复杂的操作。

现在，我想邀请 Oli 上台，简单介绍一下我们是如何与 Formula E 合作实现这一目标的。

谢谢，Alastair。

现在，我们已经有了这些要素，接下来就是最难的部分：如何将 AI 智能体真正集成到 Formula E 赛车中？

因此，它从 VCU（即车辆控制单元）开始。

现在，汽车上的每个传感器和每个组件都会通过 CAN 总线向其报告。

赛车每秒会生成数千个遥测数据点，包括速度、加速度、油门、刹车等。

因此，为了读取这些遥测数据，我们决定通过 CAN 连接将 Raspberry Pi 直接插入汽车的 VCU。

现在，Raspberry Pi 会执行一些不同的操作。

首先，它会解码原始信号，对其进行转换，并将其降采样到大约 10 Hz，这对于副驾驶来说已经足够了。

然后，Raspberry Pi 通过 MQTT 将这些经过精炼的数据发布到位于赛车驾驶舱内的 Pixel 10 Pro。

这是托管智能体应用的应用可以接受的一种输入。

第二种是 Android 语音识别。

因此，当司机说话时，应用会将输入内容转换为文本，而 Gemini Nano 能够对这两种输入内容进行推理。

现在，智能体可以做出两项决策：首先，它可以使用 Android 的文字转语音引擎向驾驶员回复。

其次，正如 Alastair 之前提到的，它可以通过 A2A protocol 与云端代理进行通信。

现在，围绕这一点，智能体流程非常简单：说出热词（在本例中为“Hey, Gemma.”），提出问题，然后获得答案。

之后，智能体会继续聆听约 5 秒钟，以便您提出后续问题，而无需重新开始，就像与真正的赛车工程师交谈一样。

该应用还是一个多轮对话智能体，这意味着它可以访问对话记录，从而实现更自然的对话。

您可能认为，实现此功能的代码会有点复杂，对吧？

其实很简单。

前几行代码使用机器学习套件调用 onDeviceModel，并将其封装为 Gemini Nano。

val generativeModel: GenerativeModel = Generation.getClient()
val onDeviceModel = GenaiPrompt.create(
    generativeModel = generativeModel,
    name = "gemini-nano",
)
val agent = LlmAgent(
    name = "race_engineer",
    model = onDeviceModel,
    staticInstruction = /* System prompt */,
    instruction = Instruction {
        /* Dynamic context */
    },
    tools = listOf(
        /* Custom tools */
    )
)

然后，我们使用 ADK 定义智能体。

为它命名并提供两种类型的指令：第一种是静态指令，用于定义它的个性和身份。

这可能包括它如何与驾驶员对话，以及一些关于赛道的信息。

第二个是动态指令。

现在，每次查询都会生成包含最新遥测摘要的提示，因此智能体始终知道驾驶员在任何时刻正在做什么。

如前所述，它还包含当前对话记录。

除此之外，我们还定义了一些工具，例如，让它能够与之前的会话数据进行对话，让它能够与云端智能体进行对话，以及让它能够使用文字转语音功能与驾驶员进行对话。

现在，我们来看一个简短的演示，了解一下该智能体在 Formula E 办公室的模拟器上的实际应用。

Hey Gemma，我的转向动作有多激烈？

平稳流畅，音调适中。

最大转向角为 48 度，方向盘平均转动速度为每秒 11 度。

Hey Gemma，我的最大 G 力是多少？

过弯时的峰值重力加速度为 2.2 G。

Hey Gemma，我这次跑步表现如何？

Dan，跑得不错。

最高时速 306 公里，35 秒内平均时速 186 公里。

你有 58% 的时间都在全速行驶，峰值加速度达到 2.2 G。

就是这样。

这是手机上的 Gemini Nano 与司机对话，实时回答他们的问题。

模拟器是一回事，Formula E 赛车则是另一回事。

那么，我们是如何将这些元素整合在一起的呢？

首先，我们必须前往巴黎的 Spark Racing Technology，我们的赛车就是在这里制造的。

左边是我，我正在将 Raspberry Pi 连接到 Formula E 赛车的实际 VCU。

到目前为止，我们构建的所有内容都是在模拟数据上运行，并从测试会话中重放，因此我们并不真正知道它是否能与真实数据一起运行。

于是，我们插上电源，开机，等待，再等待，终于，设备上开始显示遥测数据，这证明数据正在按照我们的预期在系统中传输。

右侧是最终完成的系统，可以看到手机实际上已安装在驾驶舱内，就在驾驶员座位旁边。

所以，我们已经为古德伍德做好了准备。

那么，当天实际发生了什么？

还记得 Alastair 之前提到的四大挑战吗？

古德伍德赛道对其中两款车进行了严苛的测试。

首先是热量。

在英国，我们通常只为除晴天以外的任何天气做准备。

所以，我们自然而然地迎来了有记录以来最热的一周，正好赶上热浪来袭。

现在正是将计算机装入 Formula E 赛车的绝佳时机。

但事情发生了转折。

手机其实没问题。

Android 并没有受到任何影响。

结果发现，Raspberry Pi 的表现最差。

由于无法直接将其插入汽车，我们不得不使用一种名为 UPS 的设备。如果您不了解 UPS，它基本上就像是一堆电池，粘在 Pi 的底部。

但幸运的是，我们通过在一天中不时地给它充电，成功解决了这个问题。如果没有这样做，这辆车可能根本无法在没有 AI 智能体的情况下爬上那座山。

接下来是蓝牙。

当时，我们从未实际测试过车手的头盔，该头盔通过蓝牙连接到应用。

事实证明，这有点挑战性。

为了测试这个，我们坐在草地上，看起来我们玩得很开心，对吧？

我们拿出笔记本电脑，愉快地聊着天。

实际上，那可能是我职业生涯中压力最大的时期之一。

我们拼命地尝试让代码正常运行，并在下午车辆上山之前将蓝牙头盔连接到应用。

不过，多亏了最后时刻的紧急修复和 Android 出色的调试工具，我们及时解决了问题，赛车顺利上山，AI 智能体也表现出色。

现在，我将把时间交还给 Alastair，他将与我们分享更多从该项目中获得的经验教训。

谢谢。

谢谢 Oli。

那么，我们从这个项目中收获了什么？

首先，Android 是智能体的绝佳运行平台。

我强烈建议您充分利用 Android 的多功能性、可用的 API、设备端模型和 ADK。

试试看吧，你会惊讶地发现，如此简单的东西竟然能带来如此强大的体验。

集成地狱依然存在。

在座的大多数人可能在职业生涯的某个阶段都经历过这种情况。

您分别构建了所有子组件，但当您最终将它们连接在一起时，却发现有些地方不太对劲。

而车手的赛车头盔正是这样的。

但幸运的是，我们当天就解决了这个问题，这也证明了测试仍然非常关键。

最后是 Gemini Nano。

Gemini Nano 在这里发挥了关键作用。

这是一个非常有效的模型，它在设备上运行速度非常快，可以执行非常复杂的任务，但它并不会立即执行。

这背后有真正的思考。

您必须进行提示词工程。

您必须对其进行测试。

您需要考虑如何提供动态指令和静态指令。

您需要考虑要为它提供哪些工具，以及如何最好地指示它执行任务。

但只要进行适当的测试和评估，您就能直接在设备上从 Gemini Nano 等模型中获得巨大价值。

非常感谢大家。

我们稍后会在展位，欢迎大家前来交流和提问。