Esta série partiu de um aparelho que fica ao lado do teclado e termina no ponto em que ele deixa de ser tutorial e passa a ser seu. Os quatro projetos anteriores entregaram as peças soltas: o panorama de repositórios, o hardware de voz, a energia que sustenta o uso contínuo, o firmware que não trava e a arquitetura híbrida host + periférico. Este fechamento junta tudo num ecossistema próprio — com roadmap, os pontos que derrubam o conjunto na prática, e o salto que vem depois: automação de IDE por voz.
O que a série construiu, em uma frase por camada
- Voz na placa: captura I2S, VAD e wake word rodam localmente, offline, sem depender da nuvem para acordar.
- Energia: LiPo + buck-boost + fuel gauge definem se o assistente fica na mesa sem cabo — e a térmica define se ele sobrevive fechado numa caixa.
- Firmware: FreeRTOS com tasks, filas e watchdog, reconexão de Wi-Fi com backoff e OTA dual-partition fazem o aparelho durar semanas ligado.
- Arquitetura híbrida: o host faz STT/LLM/TTS/ações; o ESP32 faz o mundo físico. A fronteira é o socket.
Arquitetura do companheiro completo
O desenho final tem quatro planos empilhados. Na base, a energia (carga, regulação, medição). Acima, o firmware (tasks determinísticas que nunca bloqueiam o I2S). No centro, a fronteira de transporte (MQTT para controle e estado, WebSocket para fluxo contínuo). No topo, o host cognitivo (Ollama local ou API, Piper para a voz, e a camada de ação que toca o shell, o git e a IDE). O ESP32 nunca “pensa”; ele presencia o ambiente e executa o que o host decide — e faz isso com a latência previsível que um LLM jamais teria no silício.
Tabela de módulos e etapas
Roadmap de construção, do zero ao companheiro integrado. Cada etapa é um incremento verificável — nada de “solda tudo e reza”.
| Etapa | Módulo | Entrega verificável | Depende de |
|---|---|---|---|
| 1 | Áudio I2S | Mic captando e amp reproduzindo um WAV gravado | — |
| 2 | Wake word local | LED acende só quando a palavra-chave é dita | Etapa 1 |
| 3 | Wi-Fi + transporte | Placa publica/consome um tópico MQTT com JSON | Etapa 2 |
| 4 | Host cognitivo | Ollama responde na LAN e a resposta chega em voz | Etapa 3 |
| 5 | Energia | LiPo + fuel gauge: percentual confiável e sem brownout | Etapa 3 |
| 6 | Firmware robusto | OTA pela LAN + reconexão sozinho após queda de roteador | Etapas 3 e 5 |
| 7 | UI/estado | Display mostra idle / escutando / pensando / falando | Etapa 2 |
| 8 | Ação por voz | “roda os testes” executa de fato no host | Etapas 4 e 6 |
Desafios térmicos e de energia ao rodar IA contínua na mesa
O ponto que mais surpreende é que a IA não esquenta a placa — esquenta o host. O ESP32 tem trabalho leve e constante: microfone, rádio, display. Quem vira forno é a GPU que roda o modelo, e o erro comum é dimensionar o companheiro como se o calor estivesse só no microcontrolador. Na prática, o desafio de bancada se divide em três: (1) manter o ESP32 estável com picos de TX e áudio simultâneos, sem brownout; (2) dissipar o host — ou aceitar que ele already existe e trazer a inferência para a máquina que você já tinha; e (3) não deixar a UI/heat da placa encostar no regulador em caixa fechada. A resposta que a série defendeu é econômica: mova o calor para onde ele já mora.
O próximo salto: automação de IDE por voz
A etapa 8 é só o começo. O salto real é transformar o assistente num agente de fluxo de trabalho: além de responder, ele opera a IDE. Isso exige três coisas que a arquitetura híbrida já tem naturalmente — um canal de intenção (voz -> texto), um cérebro que decide a ação (LLM no host) e um executor com contexto do projeto (shell, git, tarefas da IDE). A peça que fecha o ciclo é expor as ferramentas do editor ao LLM por um protocolo de contexto (MCP é o caminho mais direto hoje): o modelo deixa de “adivinhar” e passa a chamar ações reais — abrir arquivo, rodar teste, revisar diff — enquanto a placa física continua sendo o botão de acionamento e o alto-falante do retorno.
A ligação com o ecossistema próprio
Um companheiro de bancada não vive isolado. Ele é a interface física de um ecossistema maior — e é aí que o Projeto Eko entra em cena: a mesma linguagem de UI/estado, o mesmo barramento de áudio e a mesma fronteira host + periférico se reaproveitam na interface física do Eko, alimentada por peças do estoque da antiga INOBOT. Não é coincidência: componentes reais na prateleira (placas S3, mics I2S, amps, displays, células LiPo) definem o que é construível este mês, e o desenho híbrido garante que o software sobreviva à troca do hardware. Quem vem do mundo visual reconhece o parentesco com os cyberdecks — a volta do computador com identidade —, e o crossover entre as duas frentes está explicado em Cyberdecks: A Volta do Computador com Alma, que vale reler como irmão deste material, não como repetição.
Como seguir na sua bancada
- Comece pela etapa 1: valide mic e amp antes de qualquer API. Áudio ruim invalida todo o resto.
- Meça antes de otimizar energia: sem INA219/multímetro você está chutando o consumo.
- Trate OTA como requisito, não extra: é o que separa brinquedo de ferramenta.
- Mantenha a fronteira: se uma tarefa exige GPU, ela mora no host. Se exige determinismo, mora na placa.
- Reaproveite: o mesmo hardware desta série serve à interface física do Eko — projete pensando nas duas frentes.
Se você quer os fundamentos do “cérebro” que roda no host e do “offline sem nuvem”, vale cruzar com LLMs Locais: Sua IA, Seu Hardware, Suas Regras, Edge AI: Inteligência na Ponta dos Dedos e Assistentes de Voz Offline: Seu Jarvis Pessoal. Esta série foi o concreto: da LiPo ao agente que roda testes por voz. O hub da editoria Inobot fica em tiolu.com.br/nucleo-hits.
Não some depois da matéria
Radar do hub: Núcleo Hits, Além do Oculto, Bobinho. Sem spray, sem lista comprada.
Radar do hub
Um e-mail quando sair matéria que importa — sem spray de newsletter genérica.

Deixe um comentário
Entre com Google ou Facebook para comentar. Nome e e-mail vêm da sua conta — sem preencher formulário.
Se o login falhar, configure Google e Facebook em Configurações → Nextend Social Login.
Outras opções de login