智慧型應用程式

使用 ML Kit 和 Gemini Nano，在 Android 打造 Formula E 副駕駛

喇叭

  • Alastair Breeze

    Google Cloud 技術長辦公室軟體工程師

    LinkedIn

  • Oli Thompson

    Formula E 初級數據資料學家

    LinkedIn

關於

講座簡介

賽車環境嚴苛，有高速、高溫和遙測限制。裝置端代理如何協助處理即時車輛資料，用於運動和工程應用程式？

這場技術講座將探討結合邊緣硬體和雲端代理的實驗性混合架構。我們將逐步說明研究概念驗證，使用 Raspberry Pi 串流 CAN 匯流排遙測資料、Pixel 手機執行由 ML Kit 和 Gemini Nano 驅動的裝置端對話式代理，以及代理對代理 (A2A) 雲端連線，用於賽後工作流程。

摘要

  • Formula E 賽車環境極熱，且要求低延遲，對邊緣 AI 是一大挑戰。Pixel 手機搭載的代理，可回答時速超過 200 公里的駕駛。
  • Android 透過 ML Kit，使用 Agent Development Kit 和 Gemini Nano 託管邊緣架構。邊緣代理可透過 A2A 通訊協定，直接與雲端代理對話。
  • 車輛整合功能會透過 Raspberry Pi 轉送即時 CAN 匯流排遙測資料，並透過 MQTT 發布降採樣的 10 Hz 資料。Android 代理程式會將這項資料與駕駛的語音輸入內容結合，評估查詢並回覆。
  • 在古德伍德賽道測試時，手機在高溫環境下仍能正常運作。在車輛上山前，最後一刻的偵錯作業解決了與駕駛安全帽的藍牙連線問題。

Gemini Notebook

主題

  • gemini-nano
  • ml-kit
  • on-device-ai
  • ai-agents
  • formula-e

轉錄稿

下載轉錄稿

簡介

  • 您好

  • 我是 Alastair，今天很高興能與大家分享我們去年與 Formula E 合作的專案。

  • 今天我們邀請到 Oli，請他談談我們合作的成果。

  • 我在 Google Cloud 的技術長辦公室工作，我們經常嘗試突破行動裝置和雲端的極限，並探討兩者如何協同運作。

  • 我會播放一部短片，簡單介紹我們做了什麼。

  • 第 4 代賽車擁有 600kW 的強大動力。

  • 全電動、永久全輪驅動。

  • 我會說它快得驚人。

  • 我們能否在 Pixel 手機上使用代理，連結車輛傳來的遙測資料？

  • 當駕駛在 Goodwood 爬坡時，實際上可以與車輛對話。

  • 很方便吧！

  • Gemma，我的輪胎狀況如何？

  • 胎壓正常，大約 1.4 bar。

  • 手機直接插入 ECU，讀取我身為駕駛的許多資料點。

  • 這是賽車史上首次出現這種情況。

  • 我認為沒有比這裡更適合展示這項功能的地方了。

  • Gemma，準備好了嗎？

  • 隨拿即用。

在邊緣執行代理的難題

  • 因此，我們想嘗試在駕駛艙中加入副駕駛代理。

  • 基本上，我們想挑戰極限，看看邊緣代理能做到什麼程度，因為這是一個非常困難的挑戰。

  • 賽車面臨的挑戰顯然是高溫。

  • 賽車容易過熱，這是眾所皆知的事，也是我們面臨的最大挑戰之一。

  • 連線不穩。

  • 我們在古德伍德速度嘉年華 (Goodwood Festival of Speed) 舉辦這項活動，現場有數十萬名賽車迷聚集，觀看賽車爬坡。

  • 不難想像，當數十萬人聚集在同一個場地時，連線能力會是一大挑戰。

  • 藍牙。

  • 這輛車基本上就像法拉第籠，因此光是連上賽車手的安全帽，就面臨重重挑戰。

  • 最後是低延遲需求。

  • 這位車手的時速超過 200 公里，因此副駕駛代理必須快速、俐落地回答問題，這點非常重要。

  • 我們對此非常感興趣，因為我們相信代理將無所不在。

  • 我們已開始看到這種情況。

  • 不再只存在於電腦中。

  • 手機、手錶、眼鏡、智慧型住宅，甚至汽車，都看得到這項技術。

  • 因此，我們基本上想看看在這種困難的情況下，能達到什麼成果。

  • 在腦力激盪如何建構這項功能時，我們曾想過是否要建構一個內建小型加速器的微型電腦，以便在其中執行模型？

  • 我們突然意識到，所有需要的元素都已經存在，那就是 Android。

Android 是理想主機的原因

  • Android 是這項技術的完美平台，因為我們有 ADK，也就是 Agent Developer Kit。

  • 這個程式庫非常實用，可讓您直接在應用程式中建構代理。

  • Android 擁有數十億使用者，而且支援多種板型規格，因此我們能輕鬆執行、測試及發布程式碼。

  • 開發人員工具，可讓您偵錯、嘗試不同做法，以及找出問題所在。

  • Google Pixel 手機現在內建 TPU，專為手機上的裝置端模型最佳化，因此只要使用 ML Kit 等 API，就能輕鬆存取強大的模型。

  • 此外，我們也提供文字轉語音和語音辨識等功能，以及完全離線的 API，讓您能打造出真正強大的對話式體驗。

  • 最後，當然是連線能力。

  • 手機是為了連線能力而設計，無論是透過行動網路、Wi-Fi 或其他方式。

  • 不過，邊緣代理無法處理所有工作，因此如何與雲端代理協作，也是一項挑戰。

  • 如果採用混合式解決方案，會怎麼樣？

  • 如果手機中的代理能直接與雲端中的代理對話，執行更複雜的操作，會怎麼樣？

  • 舉例來說，假設車手想知道自己的排名，

  • 車輛本身不會知道自己在比賽中的排名，但雲端中的代理可能會知道。

  • 我們還有一項名為「代理對代理」的通訊協定，可讓您在邊緣和雲端建立代理，並讓代理直接互相對話，執行更複雜的操作。

代理的核心架構

  • 那麼，我們是如何建構這項服務的呢？

  • 接下來，我會介紹這個系統的組成要素。

  • 從線束開始。

  • 這裡的測試控管程式基本上是執行 Android 版 Agent Developer Kit 的 Android 應用程式。

  • 第二部分是模型。

  • 您需要模型來驅動這項功能，而我們是透過 ML Kit 使用 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。

  • 這是託管代理應用程式的 App Hosting 可接受的輸入內容。

  • 第二個是 Android 語音辨識。

  • 因此，當駕駛說話時，應用程式會將輸入內容轉換為文字，而 Gemini Nano 能夠對這兩項輸入內容進行推論。

  • 現在，代理可以做出兩項決策：首先，它可以使用 Android 的文字轉語音引擎回覆駕駛。

  • 第二，如 Alastair 先前所述，它能透過 A2A 通訊協定與雲端代理通訊。

  • 現在，代理流程相當簡單：說出啟動字詞 (在本例中為「Hey, Gemma」)，提出問題，然後取得答案。

  • 之後，代理會持續聆聽約 5 秒，方便你提出後續問題，不必重新開始，就像與真正的賽車工程師交談一樣。

  • 這個應用程式也是多輪對話代理，可存取對話記錄，提供更自然的對話體驗。

  • 因此，您可能會預期這段程式碼看起來有點複雜，對吧？

使用 ADK 和 ML Kit 實作

  • 其實很簡單。

  • 前幾行會使用 ML Kit 呼叫 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 辦公室模擬器上的實際運作情形。

模擬工具示範

  • Gemma，我的轉向有多激烈？

  • 流暢且音調適中。

  • 最大轉向角度為 48 度，方向盤平均轉動速度為每秒 11 度。

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

  • 過彎時的重力加速度峰值為 2.2 G。

  • Gemma，我這次跑步表現如何？

  • 阿丹，跑得好。

  • 最高時速 306 公里，35 秒內平均時速 186 公里。

  • 你有 58% 的時間全速前進，最高達到 2.2 G。

  • 就是這樣。

  • 手機上的 Gemini Nano 正在與駕駛對話，即時回答問題。

  • 模擬賽車是一回事，Formula E 賽車又是另一回事。

Goodwood 部署和賽道測試

  • 我們如何整合所有內容？

  • 首先，我們必須前往巴黎的 Spark Racing Technology，我們的賽車就是在這裡製造的。

  • 左邊是我將 Raspberry Pi 連接到電動方程式賽車的實際 VCU。

  • 到目前為止，我們建構的所有內容都是在模擬資料上執行，並從測試工作階段重播，因此我們不確定是否能與實際資料搭配使用。

  • 因此，我們接上電源、開機、等待，再等一下，最後裝置開始傳送遙測資料，證明資料確實如預期在系統中移動。

  • 右側是完成後的系統，可以看到手機實際安裝在駕駛艙中，就在駕駛座旁邊。

  • 我們已為古德伍德做好萬全準備。

  • 那麼，當天究竟發生了什麼事？

  • 還記得 Alastair 先前提到的四項挑戰嗎？

  • Goodwood 賽道確實考驗了其中兩項。

  • 首先是熱能。

  • 在英國，我們通常只會為晴天以外的天氣做準備。

  • 因此，我們自然而然地迎來了有記錄以來最熱的一週，正好處於熱浪的中間。

  • 在 Formula E 賽車中安裝電腦的最佳時機。

  • 但事情沒那麼簡單。

  • 手機其實沒問題。

  • Android 幾乎沒有受到影響。

  • 結果發現，Raspberry Pi 的表現最吃力。

  • 由於無法直接插入車內，我們必須使用 UPS，也就是看起來像一堆電池黏在 Pi 底部的裝置。

  • 幸好，我們在一天中不時補充燃料，才解決了這個問題。如果沒有這麼做，車子可能就無法在沒有 AI 代理的情況下爬上那座山。

  • 接著是藍牙。

  • 當時我們從未實際測試過車手的安全帽，安全帽是透過藍牙連線至應用程式。

  • 這項工作有點難度。

  • 為了測試這項功能，我們坐在草地上，看起來玩得很開心，對吧？

  • 我們拿出筆電，愉快地聊著天。

  • 但實際上，那段時間可能是我職涯中壓力最大的時期之一。

  • 我們拼命想讓程式碼順利運作，並在下午上山前將藍牙安全帽連上應用程式。

  • 不過，多虧了最後一刻的緊急修正和 Android 的強大偵錯工具，我們及時修正了問題，車子順利上山，AI 代理也運作良好。

  • 現在，我將交棒給 Alastair，他將與我們分享更多從專案中學到的經驗。

  • 謝謝。

重點回顧和經驗談

  • 謝謝 Oli。

  • 那麼，我們從這項專案中學到了什麼？

  • 首先，Android 是代理程式的完美主機。

  • 我非常鼓勵大家善用 Android 的多功能性、可用的 API、裝置端模型和 ADK。

  • 試試看吧，你會驚訝地發現，這麼簡單的東西竟然能帶來如此強大的體驗。

  • 整合地獄依然存在。

  • 在座各位可能都曾在職涯中遇過這種情況。

  • 您分別建構所有子元件，最後將它們組合在一起時，卻發現有些部分無法正常運作。

  • 而駕駛的賽車安全帽正是如此。

  • 幸好我們當天就解決了問題，這也證明測試仍然非常重要。

  • 最後是 Gemini Nano。

  • Gemini Nano 在這方面真的幫了大忙。

  • 這項模型非常有效率，在裝置上執行速度很快，還能執行非常複雜的工作，但並非一開始就能做到。

  • 這需要認真思考。

  • 您必須進行提示工程。

  • 你必須測試。

  • 您必須思考如何提供動態指令和靜態指令。

  • 您必須思考要提供哪些工具，以及如何以最佳方式指示代理執行工作。

  • 不過，只要進行適當的測試和評估，就能直接在裝置上充分運用 Gemini Nano 等模型。

  • 非常感謝大家。

  • 我們稍後會在攤位，歡迎前來提問。

程式碼

程式碼片段

「Implementation with ADK and ML Kit」影片 07:45 處的 Kotlin 程式碼片段
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 */
    )
)