Um carro de corrida é um ambiente exigente de alta velocidade, calor e restrições de telemetria. Como um agente no dispositivo pode ajudar a processar dados de veículos em tempo real para aplicativos de esportes e engenharia?
Esta sessão técnica aborda uma arquitetura híbrida experimental que combina hardware de borda e agentes de nuvem. Vamos mostrar uma prova de conceito de pesquisa usando um Raspberry Pi para transmitir telemetria de barramento CAN, um smartphone Pixel executando um agente de conversação no dispositivo com tecnologia do Kit de ML e do Gemini Nano, e uma conexão de nuvem de agente para agente (A2A) para fluxos de trabalho pós-corrida.
Transcrição
Olá!
Meu nome é Alastair e hoje estou muito feliz em falar com vocês sobre um projeto que realizamos no ano passado com a Fórmula E.
O Oli está aqui hoje para falar um pouco sobre o que fizemos juntos.
Eu trabalho no Google Cloud, no escritório do CTO, e estamos sempre tentando ampliar os limites do que é possível fazer em dispositivos móveis e no Cloud, e como eles podem funcionar juntos.
Vou mostrar um vídeo rápido que apresenta um pouco do que fizemos.
O carro da 4ª geração tem 600 kW de potência.
Energia totalmente elétrica, tração integral permanente.
Eu diria que é rápido pra caramba.
Poderíamos usar um agente em um smartphone Pixel conectado aos dados de telemetria do carro?
Enquanto o motorista sobe a colina em Goodwood, ele poderá conversar com o carro.
Isso é bem legal!
Ei, Gemma, como estão meus pneus?
A pressão dos pneus está boa, em torno de 1,4 bar.
Há um smartphone conectado diretamente à ECU, que está lendo muitos pontos de dados do que estou fazendo como motorista.
É a primeira vez que isso acontece em um carro de corrida.
Acho que não há lugar melhor para mostrar isso.
Oi, Gemma, está tudo pronto?
Quando você quiser.
O que vimos foi um projeto em que queríamos colocar um agente copiloto no cockpit com o motorista.
No fundo, o que estamos tentando fazer aqui é testar os limites do que é possível com agentes na borda, porque esse é um ótimo exemplo de um desafio realmente difícil.
Os desafios que você encontra em um carro de corrida são, obviamente, o calor intenso.
Os carros de corrida são conhecidos por esquentar, e esse é um dos maiores desafios.
Conectividade instável.
Estamos fazendo isso no Goodwood Festival of Speed, onde centenas de milhares de fãs de automobilismo se reúnem para assistir a carros subindo a colina.
E, como você pode imaginar, quando há centenas de milhares de pessoas em um campo, a conectividade pode ser um grande desafio.
Bluetooth.
Por exemplo, esse carro é basicamente uma gaiola de Faraday, então imagine os desafios para conectar o capacete do piloto.
E, por fim, os requisitos de baixa latência.
Esse piloto está a mais de 200 km/h, então é muito importante que as respostas do agente copiloto sejam rápidas e precisas.
E, fundamentalmente, estamos muito interessados nisso porque acreditamos que os agentes vão se tornar onipresentes.
Já estamos começando a perceber essa mudança.
Eles não estão mais apenas nos nossos computadores.
Eles estão nos nossos smartphones, relógios, óculos, casas inteligentes e até mesmo nos nossos carros.
Então, basicamente, queríamos ver o que poderíamos alcançar em um cenário difícil como esse.
E quando estávamos pensando em como criar isso, pensamos em criar um microcomputador com um pequeno acelerador para ter um modelo?
Percebemos que todos os ingredientes de que precisávamos já existiam, e era o Android.
O Android é o host perfeito para isso porque tem o ADK, que é nosso Kit de Desenvolvimento de Agente.
Essa é uma biblioteca muito boa que permite criar agentes diretamente no seu aplicativo.
Há bilhões de usuários, então, você sabe, diferentes formatos em que podemos executar isso com muita facilidade, então é muito fácil testar isso e distribuir o próprio código.
Ferramentas para desenvolvedores que permitem depurar, testar diferentes opções e encontrar o que está errado.
A IA no dispositivo, os smartphones Google Pixel agora vêm com uma TPU integrada, otimizada para o modelo no dispositivo que fica no smartphone, facilitando o uso de APIs como o Kit de ML para acessar um modelo realmente poderoso.
Além disso, temos recursos como conversão de texto em voz e reconhecimento de fala, APIs totalmente off-line que permitem criar experiências de conversa incríveis.
E, por fim, a conectividade.
Os smartphones são criados para conectividade, seja por redes celulares, Wi-Fi ou outros meios.
Um dos desafios é que os agentes na borda não podem fazer tudo. Como eles trabalhariam com agentes na nuvem?
E se a solução fosse híbrida?
E se um agente que vive em um smartphone puder falar diretamente com um agente na nuvem para realizar ações mais complicadas?
Por exemplo, imagine que o piloto queira saber em que posição está na corrida.
O carro em si não sabe em que posição está na corrida, mas talvez um agente na nuvem saiba.
E temos um protocolo chamado agente para agente, o que significa que você pode criar agentes na borda e na nuvem e fazer com que eles conversem entre si para realizar ações mais complexas.
Como criamos isso?
Vou mostrar os ingredientes desse sistema.
Começando pelo chicote elétrico.
O harness aqui é basicamente um app Android que executa o Kit de Desenvolvimento de Agente para Android.
A segunda parte é um modelo.
Você precisa de um modelo para isso, e nós usamos o Gemini Nano pelo Kit de ML, um modelo no dispositivo muito eficiente e fácil de usar.
Depois, os dados.
O Oli vai falar um pouco sobre isso em um minuto, mas você tem os dados que vêm do carro, mas também, potencialmente, o reconhecimento de fala do motorista.
Por fim, você também tem as ações que o agente pode realizar.
Pode ser uma conversão de texto em voz para responder ao motorista e fazer perguntas complementares ou fornecer as informações necessárias. Ou, como mencionado anteriormente, a comunicação entre agentes, com um agente na nuvem para realizar algumas das ações mais complexas.
Agora, gostaria de convidar Oli ao palco para falar um pouco sobre como fizemos isso com a Fórmula E.
Obrigado, Alastair.
Agora que temos os ingredientes, vem a parte difícil: como integrar um agente de IA a um carro da Fórmula E?
Então, começa aqui na VCU, ou unidade de controle do veículo.
Agora, todos os sensores e componentes do carro se comunicam com ele por meio de algo chamado barramento CAN.
E o carro gera milhares de pontos de telemetria por segundo, como velocidade, aceleração, aceleração, frenagem e muito mais.
Para ler essa telemetria, decidimos conectar um Raspberry Pi diretamente à VCU do carro usando essa conexão CAN.
O Raspberry Pi faz algumas coisas diferentes.
Primeiro, ele decodifica os sinais brutos, os transforma e reduz a amostragem para cerca de 10 Hz, o que é suficiente para um copiloto.
O Raspberry Pi publica esses dados refinados por MQTT em um Pixel 10 Pro que fica no cockpit do carro.
Essa é uma entrada que o App Hosting que hospeda nosso aplicativo de agente pode aceitar.
O segundo é o reconhecimento de fala do Android.
Assim, quando o motorista fala, o app converte a entrada em texto, e o Gemini Nano consegue processar as duas entradas.
Agora, o agente pode tomar duas decisões: primeiro, usar o mecanismo de conversão de texto em voz do Android para responder ao motorista.
Em segundo lugar, como Alastair mencionou, ele pode se comunicar com o agente de nuvem usando o protocolo A2A.
O fluxo do agente é bem simples: diga a hotword, neste caso "Ok, Gemma", faça uma pergunta e receba uma resposta.
O agente continua ouvindo por cerca de 5 segundos para que você possa fazer uma pergunta complementar sem precisar começar de novo, como se estivesse conversando com um engenheiro de corrida de verdade.
O app também é um agente de vários turnos, o que significa que ele pode acessar o histórico de conversas para ser mais interativo.
Então, você deve estar esperando que o código para isso seja um pouco complicado, certo?
Na verdade, é bem simples.
As primeiras linhas chamam o onDeviceModel usando o Kit de ML e o encapsulam como 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 */
)
)Em seguida, definimos nosso agente com o ADK.
Dê um nome e dois tipos de instruções: a primeira é a instrução estática, que define a personalidade e quem ele é.
Isso pode incluir como ele responde ao piloto e algumas informações sobre a pista.
A segunda é a instrução dinâmica.
Agora, isso é gerado em cada consulta com o resumo de telemetria mais recente, para que o agente sempre saiba o que o motorista está fazendo a qualquer momento.
Ele também inclui o histórico da conversa atual, como mencionado anteriormente.
Além disso, também definimos algumas ferramentas, por exemplo, para que ele possa se comunicar com dados de sessões anteriores, com o agente de nuvem e com o motorista usando a conversão de texto em voz.
Agora vamos ver uma demonstração rápida do agente em ação nos nossos simuladores no escritório da Fórmula E.
Ei, Gemma, quão agressiva é minha direção?
Suave e medido.
O bloqueio máximo foi de 48 graus, e você estava movendo o volante a 11 graus por segundo, em média.
Ei, Gemma, qual é meu pico de força G?
A força G máxima foi de 2, 2 G nas curvas.
Oi, Gemma, como foi minha corrida?
Boa corrida, Dan.
Velocidade máxima de 306 km/h, com média de 186 em 35 segundos.
Você acelerou ao máximo em 58% do tempo e atingiu o pico de 2, 2 G.
É isso!
Esse é o Gemini Nano em um smartphone conversando com um motorista e respondendo às perguntas dele em tempo real.
Um simulador é uma coisa, mas um carro da Fórmula E é algo totalmente diferente.
Como juntamos tudo isso?
Primeiro, tivemos que ir até a Spark Racing Technology em Paris, onde nossos carros são fabricados.
Aqui, à esquerda, estou conectando o Raspberry Pi à VCU do carro da Fórmula E.
Tudo o que criamos até agora foi executado em dados emulados e reproduzido de uma sessão de teste. Por isso, não sabíamos se funcionaria com o dispositivo real.
Então, conectamos o dispositivo, ligamos, esperamos um pouco e, finalmente, a telemetria começou a aparecer no dispositivo, provando que os dados estavam se movendo pelo sistema como esperado.
À direita, você pode ver o sistema finalizado e que o smartphone está realmente implementado no cockpit, bem ao lado de onde o motorista vai se sentar.
Então, estávamos todos prontos para Goodwood.
Então, o que realmente aconteceu no dia?
Lembra dos quatro desafios que o Alastair mencionou?
Goodwood testou dois deles.
O primeiro foi o calor.
Na Grã-Bretanha, costumamos nos preparar para qualquer clima, exceto o sol.
Então, naturalmente, o que tivemos foi uma das semanas mais quentes já registradas, bem no meio de uma onda de calor.
O momento perfeito para colocar um computador dentro de um carro da Fórmula E.
Mas aqui está a reviravolta.
O celular estava em perfeito estado.
O Android não sofreu nada.
O Raspberry Pi foi o que teve mais dificuldade.
Como não podíamos conectá-lo diretamente ao carro, tivemos que usar um no-break, que, se você não sabe, é basicamente um monte de baterias presas à parte de baixo do Pi.
Mas, felizmente, conseguimos corrigir isso recarregando o carro esporadicamente ao longo do dia. Sem isso, o carro provavelmente não teria subido aquela colina sem nenhum agente de IA.
Depois veio o Bluetooth.
Até aquele momento, nunca tínhamos testado o capacete do motorista, que se conecta ao app por Bluetooth.
E isso estava se mostrando um desafio.
Para testar isso, sentamos na grama, e parece que estamos nos divertindo muito, certo?
Pegamos nossos laptops e começamos a conversar.
Na verdade, esse foi um dos períodos mais estressantes da minha carreira até agora.
Estávamos tentando desesperadamente fazer o código funcionar e conectar o capacete Bluetooth ao app antes que o carro subisse a colina à tarde.
Mas, graças a algumas correções de última hora e às ótimas ferramentas de depuração do Android, conseguimos corrigir o problema a tempo, e o carro subiu a colina com o agente de IA funcionando perfeitamente.
Agora, vou passar a palavra para o Alastair, que vai falar um pouco mais sobre as lições aprendidas com o projeto.
Obrigado.
Obrigada, Oli.
E o que aprendemos com esse projeto?
Bem, o primeiro é que o Android é um host perfeito para seus agentes.
Recomendo que você use a versatilidade do Android, as APIs disponíveis, os modelos no dispositivo e o ADK.
Teste-os, porque você vai se surpreender com o poder das experiências que pode ter com algo tão simples.
O inferno da integração ainda existe.
A maioria das pessoas nesta sala provavelmente já passou por isso em algum momento da carreira.
Você cria todos os subcomponentes separadamente e, quando finalmente os conecta, algo não funciona.
E o capacete de corrida do piloto era exatamente assim.
Mas, felizmente, conseguimos corrigir o problema no mesmo dia, o que prova que os testes ainda são muito importantes.
E, por fim, o Gemini Nano.
O Gemini Nano foi um verdadeiro herói aqui.
É um modelo muito eficaz, que roda rapidamente no seu dispositivo e pode realizar tarefas muito complicadas, mas não faz isso de imediato.
Isso é que é pensar bem.
Você precisa fazer engenharia de comandos.
Você precisa testar.
Você precisa pensar em como quer alimentar a instrução dinâmica em comparação com a estática.
Você precisa pensar nas ferramentas que vai fornecer e em como instruí-lo da melhor forma para fazer isso.
Mas com o tipo certo de testes e avaliações, é possível aproveitar muito um modelo como o Gemini Nano diretamente no dispositivo.
Muito obrigado a todos.
Estaremos no estande mais tarde, então você pode vir, participar e fazer algumas perguntas.
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 */
)
)