ML Kit 및 Gemini Nano를 사용하여 Android에서 Formula E 보조 드라이버 빌드하기

안녕하세요.

제 이름은 알라스테어입니다. 오늘은 작년에 Formula E와 함께 진행한 프로젝트에 대해 이야기해 보려고 합니다.

오늘 이 자리에 올리 님을 모시고 함께 진행한 작업에 대해 이야기를 나누어 보겠습니다.

저는 Google Cloud의 CTO 사무실에서 일하고 있으며, 현재 모바일과 클라우드에서 가능한 것의 한계를 뛰어넘고 이 둘이 어떻게 함께 작동할 수 있는지 알아보고 있습니다.

우리가 무엇을 했는지 간단히 소개하는 동영상을 보여드리겠습니다.

4세대 자동차는 600kW의 레이싱 괴물입니다.

전기 동력, 상시 사륜구동.

엄청나게 빠르다고 표현하고 싶습니다.

자동차에서 전송되는 텔레메트리 데이터에 연결된 Pixel 휴대전화에서 에이전트를 사용할 수 있을까요?

운전자가 굿우드에서 언덕을 올라갈 때 실제로 자동차와 대화할 수 있습니다.

아주 편리한 방식입니다.

Gemma, 내 타이어 상태는 어때?

타이어 압력은 약 1.4bar로 양호합니다.

ECU에 직접 연결된 휴대전화가 운전자인 제가 하는 행동에 관한 수많은 데이터 포인트를 읽고 있습니다.

경주용 자동차에서 이런 일이 발생한 것은 이번이 처음입니다.

이보다 더 좋은 곳은 없다고 생각합니다.

Gemma, 준비됐어?

준비되셨으면 시작하겠습니다.

이 프로젝트에서는 보조 운전자 에이전트를 운전자와 함께 조종석에 배치하려고 했습니다.

근본적으로 여기서 하려는 것은 에지에서 에이전트로 가능한 것의 한계를 뛰어넘는 것입니다. 이는 정말 어려운 과제의 좋은 예이기 때문입니다.

경주용 자동차에서 볼 수 있는 문제는 당연히 높은 열입니다.

경주용 자동차는 열이 많이 발생하는 것으로 유명하며, 이는 가장 큰 과제 중 하나입니다.

연결이 불안정합니다.

그래서 우리는 수십만 명의 모터스포츠 팬이 모여 자동차 경주를 관람하는 굿우드 페스티벌 오브 스피드에서 이 작업을 진행하고 있습니다.

예상하시겠지만, 수십만 명의 사람들이 한곳에 모여 있으면 연결이 원활하지 않을 수 있습니다.

블루투스도 마찬가지입니다.

이 자동차는 기본적으로 패러데이 케이지와 같아서 레이싱 드라이버의 헬멧에 연결하는 것조차 얼마나 어려운지 상상할 수 있습니다.

마지막으로 지연 시간이 짧아야 한다는 요구사항이 있습니다.

이 드라이버는 시속 200km가 넘는 속도로 달리고 있으므로 보조 드라이버 에이전트로부터 받는 답변이 매우 빠르고 간결해야 합니다.

근본적으로 Google이 이 분야에 관심을 갖는 이유는 에이전트가 어디에나 존재하게 될 것이라고 믿기 때문입니다.

이러한 변화는 이미 시작되었습니다.

이제 컴퓨터에만 있는 것이 아닙니다.

스마트폰, 시계, 안경, 스마트 홈, 이제는 자동차에도 있습니다.

따라서 근본적으로 이와 같은 어려운 시나리오에서 무엇을 달성할 수 있는지 확인하고 싶었습니다.

이것을 어떻게 만들지 브레인스토밍할 때, 가속기가 내장된 소형 마이크로컴퓨터를 만들어 모델을 탑재할지 고민했습니다.

필요한 모든 요소가 이미 존재한다는 사실을 갑자기 깨달았는데, 그것이 바로 Android였습니다.

Android는 에이전트 개발자 키트인 ADK를 제공하므로 이 작업에 완벽한 호스트입니다.

이 라이브러리는 애플리케이션에 에이전트를 직접 빌드할 수 있는 매우 유용한 라이브러리입니다.

수십억 명의 사용자가 있고, 다양한 폼 팩터에서 쉽게 실행할 수 있으므로 테스트하고 코드를 배포하기가 정말 쉽습니다.

디버그하고 다양한 작업을 시도하며 무엇이 잘못되었는지 찾을 수 있는 개발자 도구

온디바이스 AI, Google Pixel 휴대전화는 이제 휴대전화 자체에 TPU가 탑재되어 출시되며, 휴대전화에 바로 탑재된 온디바이스 모델에 최적화되어 있어 ML Kit와 같은 API를 사용하여 매우 강력한 모델에 쉽게 액세스할 수 있습니다.

또한 텍스트 음성 변환 및 음성 인식과 같은 기능도 있습니다. 이는 강력한 대화형 환경을 제공하는 완전한 오프라인 API입니다.

마지막으로 연결성입니다.

휴대전화는 모바일 네트워크, Wi-Fi 또는 기타 수단을 통해 연결되도록 설계되었습니다.

하지만 에지 에이전트가 모든 것을 할 수는 없다는 문제가 있습니다. 그렇다면 클라우드에 있는 에이전트와 어떻게 연동할 수 있을까요?

하이브리드 솔루션이라면 어떨까요?

휴대전화에 있는 에이전트가 클라우드의 에이전트와 직접 대화하여 더 복잡한 작업을 수행할 수 있다면 어떨까요?

예를 들어 드라이버가 자신의 레이스 순위를 알고 싶어 한다고 가정해 보겠습니다.

자동차 자체는 레이스에서 자신의 위치를 알 수 없지만 클라우드의 에이전트는 알 수 있습니다.

또한 에이전트 간 프로토콜을 사용하면 에지 및 클라우드에서 에이전트를 생성하고 서로 대화하여 더 복잡한 작업을 수행할 수 있습니다.

그렇다면 어떻게 빌드했을까요?

이 시스템의 구성 요소를 살펴보겠습니다.

하네스에서 시작합니다.

여기서 하네스는 기본적으로 Android용 에이전트 개발자 키트를 실행하는 Android 애플리케이션입니다.

두 번째 부분은 모델입니다.

이를 지원하는 모델이 필요한데, 저희는 ML Kit를 통해 Gemini Nano를 사용했습니다. 이는 손쉽게 사용할 수 있는 매우 강력한 온디바이스 모델입니다.

다음은 데이터입니다.

잠시 후에 Oli가 이 부분에 대해 조금 더 설명하겠지만, 자동차에서 들어오는 데이터도 있고 운전자의 음성 인식도 있을 수 있습니다.

마지막으로 에이전트가 수행할 수 있는 작업도 있습니다.

운전자에게 다시 말하고 후속 질문을 하거나 필요한 정보를 제공할 수 있는 TTS(텍스트 음성 변환)일 수도 있고, 앞서 언급한 것처럼 에이전트 간 통신, 클라우드의 에이전트와 통신하여 더 복잡한 작업을 수행하는 것일 수도 있습니다.

이제 올리를 무대로 초대하여 Formula E에서 이 작업을 어떻게 수행했는지에 대해 간단히 이야기해 보겠습니다.

감사합니다, Alastair님.

이제 재료가 준비되었으니 어려운 부분으로 넘어가겠습니다. AI 에이전트를 Formula E 자동차에 실제로 통합하려면 어떻게 해야 할까요?

VCU(차량 제어 장치)에서 시작됩니다.

이제 자동차의 모든 센서와 모든 구성 요소가 CAN 버스라는 것을 통해 다시 보고합니다.

그리고 자동차는 속도, 가속, 스로틀, 제동 등 초당 수천 개의 원격 측정 포인트를 생성합니다.

이 원격 분석을 읽기 위해 Raspberry Pi를 이 CAN 연결을 통해 자동차의 VCU에 직접 연결하기로 결정했습니다.

이제 Raspberry Pi는 몇 가지 다른 작업을 수행합니다.

먼저 원시 신호를 디코딩하고 변환한 다음 약 10Hz로 다운샘플링합니다. 이는 보조 운전자에게 충분한 정보입니다.

그런 다음 Raspberry Pi는 이 정제된 데이터를 MQTT를 통해 자동차 조종석에 있는 Pixel 10 Pro에 게시합니다.

이는 에이전트 애플리케이션을 호스팅하는 앱이 수락할 수 있는 입력 중 하나입니다.

두 번째는 Android 음성 인식입니다.

따라서 운전자가 말하면 앱이 입력을 텍스트로 변환하고 Gemini Nano는 이 두 입력을 모두 추론할 수 있습니다.

이제 에이전트는 두 가지 결정을 내릴 수 있습니다. 첫째, Android의 텍스트 음성 변환 엔진을 사용하여 운전자에게 다시 말할 수 있습니다.

둘째, 앞서 알라스테어가 언급한 것처럼 A2A 프로토콜을 통해 클라우드 에이전트와 다시 대화할 수 있습니다.

에이전트 흐름은 매우 간단합니다. 핫워드(이 경우 "Hey, Gemma")를 말하고 질문을 하면 답변을 받습니다.

에이전트는 이후 약 5초 동안 계속 듣고 있으므로 실제 레이스 엔지니어와 대화하는 것처럼 처음부터 다시 시작하지 않고도 후속 질문을 할 수 있습니다.

이 앱은 멀티턴 에이전트이기도 합니다. 즉, 대화 기록에 액세스하여 더 대화형으로 작동할 수 있습니다.

이 코드가 조금 복잡해 보일 수 있습니다.

사실 꽤 간단합니다.

처음 몇 줄은 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도씩 핸들을 움직였습니다.

Gemma, 내 최대 중력 가속도는 얼마야?

코너를 돌 때 최대 중력 가속도는 2.2G였습니다.

Gemma, 내 러닝 어땠어?

댄, 잘 달렸어.

최고 속도 306km/h, 35초 동안 평균 186km/h

전체 시간의 58% 동안 최대 속도로 달렸으며, 최대 2.2G에 도달했습니다.

자,

휴대전화에서 Gemini Nano가 운전자와 대화하며 실시간으로 질문에 답변하고 있습니다.

시뮬레이션 장비와 포뮬러 E 자동차는 완전히 다른 문제입니다.

그렇다면 이 모든 것을 어떻게 통합했을까요?

먼저 차량이 제작되는 파리의 Spark Racing Technology를 방문해야 했습니다.

왼쪽 사진은 제가 Raspberry Pi를 Formula E 차량의 실제 VCU에 연결하는 모습입니다.

지금까지 빌드한 모든 항목은 에뮬레이션된 데이터에서 실행되었고 테스트 세션에서 재생되었으므로 실제 데이터에서 작동할지 여부는 알 수 없었습니다.

그래서 전원을 연결하고 켜고 기다렸습니다. 조금 더 기다렸더니 마침내 기기에서 원격 분석이 시작되어 데이터가 예상대로 시스템을 통해 이동하고 있음을 증명했습니다.

오른쪽에는 완성된 시스템이 표시되며, 운전자가 앉는 자리 바로 옆에 휴대전화가 실제로 조종석에 구현되어 있는 것을 볼 수 있습니다.

굿우드에 갈 준비가 모두 끝났습니다.

그렇다면 그날 실제로 어떤 일이 일어났을까요?

앞서 알라스테어가 언급한 네 가지 과제를 기억하시나요?

굿우드에서는 이 중 두 가지를 테스트했습니다.

첫 번째는 열이었습니다.

영국에서는 보통 맑은 날씨를 제외한 모든 날씨에 대비합니다.

그래서 당연히, 우리가 얻은 것은 기록상 가장 더운 주 중 하나였고, 폭염의 한가운데에 있었습니다.

포뮬러 E 자동차에 컴퓨터를 탑재하기에 완벽한 시기입니다.

하지만 반전이 있습니다.

휴대전화는 실제로 괜찮았습니다.

Android는 전혀 영향을 받지 않았습니다.

가장 어려움을 겪은 것은 Raspberry Pi였습니다.

그리고 자동차에 직접 연결할 수 없었기 때문에 UPS라는 것을 사용해야 했습니다. UPS는 기본적으로 Pi의 밑면에 부착된 배터리 묶음처럼 보입니다.

다행히 하루 종일 간헐적으로 충전하여 이 문제를 해결할 수 있었고, 그렇지 않았다면 AI 에이전트가 없는 상태에서 언덕을 오르지 못했을 것입니다.

다음은 블루투스입니다.

그 시점에는 블루투스를 통해 앱에 연결되는 운전자 헬멧을 실제로 테스트해 본 적이 없었습니다.

그리고 그것은 약간의 도전이 되고 있었습니다.

이 기능을 테스트하기 위해 잔디밭에 앉았는데, 정말 즐거운 시간을 보내고 있는 것처럼 보이죠?

노트북을 꺼내고 즐겁게 대화를 나누고 있습니다.

사실 그 시기는 제 커리어에서 가장 스트레스가 많았던 시기 중 하나였습니다.

오후에 언덕을 올라가기 전에 코드를 제대로 작동시키고 블루투스 헬멧을 앱에 연결하기 위해 필사적으로 노력했습니다.

하지만 막판에 긴급 수정과 Android의 뛰어난 디버깅 도구 덕분에 제때 수정할 수 있었고, AI 에이전트가 제대로 작동하면서 자동차가 언덕을 올라갔습니다.

이제 알라스테어에게 다시 마이크를 넘기겠습니다. 알라스테어가 프로젝트에서 얻은 교훈에 대해 조금 더 이야기해 줄 것입니다.

감사합니다.

올리, 감사합니다.

이 프로젝트에서 무엇을 배웠을까요?

첫째, Android는 에이전트를 위한 완벽한 호스트입니다.

Android의 다기능성, 사용 가능한 API, 온디바이스 모델, ADK를 활용해 보세요.

이러한 간단한 기능으로 얼마나 강력한 경험을 할 수 있는지 직접 확인해 보세요.

통합 지옥은 여전히 존재합니다.

여기 계신 대부분의 분들이 커리어 중 어느 시점에 이런 경험을 하셨을 겁니다.

모든 하위 구성요소를 개별적으로 빌드한 후 최종적으로 연결할 때 제대로 작동하지 않는 경우가 있습니다.

운전자의 레이싱 헬멧이 바로 이것이었습니다.

다행히 당일에 문제를 해결할 수 있었고, 이를 통해 테스트가 여전히 매우 중요하다는 것을 알 수 있었습니다.

마지막으로 Gemini Nano입니다.

Gemini Nano가 큰 도움이 되었습니다.

이 모델은 매우 효과적이며 기기에서 매우 빠르게 실행되고 복잡한 작업을 수행할 수 있지만, 바로 수행할 수 있는 것은 아닙니다.

여기에는 진지한 고민이 담겨 있습니다.

프롬프트 엔지니어링을 해야 합니다.

테스트해 봐야 합니다.

동적 요청 사항과 정적 요청 사항을 제공하는 방식을 고려해야 합니다.

제공할 도구와 이를 가장 잘 지시하는 방법을 생각해야 합니다.

하지만 적절한 테스트와 평가를 거치면 기기에서 바로 Gemini Nano와 같은 모델을 최대한 활용할 수 있습니다.

감사합니다, 여러분.

나중에 부스에 있을 예정이니 오셔서 질문해 주세요.