Espressif publicó la versión 0.7 de ESP-Brookesia, su framework para construir dispositivos AIoT con interacción humano-máquina rica sobre la base de ESP-IDF. El cambio no es cosmético: la arquitectura entera fue reorganizada en una pila por capas con puntos de extensión bien definidos, distribuida a través del ESP Component Registry.

¿Por qué Brookesia necesitaba una nueva arquitectura?

ESP-Brookesia apunta a productos AIoT con requisitos exigentes de interacción humano-máquina. En la práctica, eso significa que el framework debe absorber las diferencias de hardware, entregar capacidades de sistema como Wi-Fi, audio, video y almacenamiento, y conectar todo eso a agentes de IA de manera consistente.

A medida que el proyecto creció, se hizo cada vez más necesario delimitar con claridad esas responsabilidades. La v0.7 reordena el framework en una arquitectura por capas con extensiones formalizadas. El resultado es una estructura más fácil de portar, escalar y reutilizar entre distintos productos de interacción con IA.

!ESP-Brookesia architecture overview

¿Cuáles son las tres capas del nuevo stack?

A alto nivel, la arquitectura puede entenderse en tres niveles:

  • Entorno y dependencias: ESP-IDF aporta el toolchain, runtime y drivers; el ESP Component Registry maneja el empaquetado y la gestión de dependencias.
  • Servicio y framework: Utils, HAL, General Service, AI Agent y AI Expression son los módulos centrales que componen el framework propiamente tal.
  • Aplicación: aplicaciones de producto y proyectos de referencia se construyen encima de esos módulos reutilizables.

Las mejoras prácticas que trae el rediseño son cuatro:

  • Separación de responsabilidades más clara: utilitarios, abstracción de hardware, servicios de sistema y lógica de IA dejan de estar mezclados.
  • Bring-up de placas más simple: las interfaces HAL y la configuración a nivel de placa hacen más fácil soportar múltiples targets de hardware.
  • Mejor reutilización: los servicios se exponen uniformemente como funciones y eventos, reutilizables entre llamadas locales, RPC remoto y herramientas MCP.
  • Integración de IA más fuerte: los agentes ahora se conectan a servicios de sistema y capacidades del dispositivo a través de un modelo más limpio y extensible.

Los cinco módulos centrales del framework

Cada módulo tiene una responsabilidad distinta, pero juntos forman una cadena de dependencias internas: Utils y HAL son la base, General Service se apoya en ellos, y AI Agent + AI Expression viven arriba de la pila.

Utils

El módulo Utils aporta la base que el resto del framework reutiliza. No resuelve una feature de producto, agrupa los bloques de construcción que aparecen una y otra vez en desarrollo embebido. Sus componentes principales son:

  • brookesia_lib_utils: librería de utilidades de propósito general con plugins, máquinas de estado, scheduling de tareas, configuración de threads y profiling en runtime.
  • brookesia_mcp_utils: utilidades MCP que exponen funciones de servicio como herramientas MCP.

HAL

El módulo HAL resuelve un problema clásico del embebido: cómo mantener a los módulos de alto nivel independientes de la placa de desarrollo. En la v0.7, HAL se divide en tres partes que cooperan:

  • brookesia_hal_interface: define interfaces de hardware estandarizadas como audio, display, touch y storage.
  • brookesia_hal_adaptor: implementa esas interfaces y ejecuta la inicialización específica de placa.
  • brookesia_hal_boards: describe la topología de placa, pines y parámetros de driver mediante configuración en YAML.

Esta estructura mantiene a servicios y aplicaciones dependiendo solo de interfaces abstractas, mientras las diferencias específicas de placa se resuelven a través de adaptors y configuración. Para productos que necesitan soportar múltiples plataformas de hardware, eso reduce significativamente el esfuerzo de portado.

General Service

El módulo General Service es la superficie unificada de runtime para capacidades de sistema reutilizables. El framework de servicios usa un modelo Manager + Helper:

  • brookesia_service_manager: administra el ciclo de vida de los plugins de servicio, registro de funciones, despacho de eventos, llamadas locales y RPC remoto.
  • brookesia_service_helper: provee llamadas a funciones type-safe y suscripción a eventos para uso desde la aplicación.

Sobre ese framework, ESP-Brookesia entrega un set de servicios listos para usar:

  • Wi-Fi: gestión de conexión, escaneo y aprovisionamiento SoftAP.
  • Audio: captura, reproducción y procesamiento relacionado.
  • Video: codec y capacidades vinculadas al display.
  • NVS: almacenamiento no volátil.
  • SNTP: sincronización de hora vía red.
  • Custom: mecanismo liviano de extensión para servicios propios.

Este modelo de servicios es particularmente útil para AIoT por dos razones. Todas las capacidades se expresan uniformemente como funciones y eventos, lo que vuelve la integración y el debugging más consistentes. Y los mismos servicios pueden invocarse tanto localmente como a través de RPC remoto basado en TCP/JSON, lo que abre escenarios de lógica intra-dispositivo y multi-dispositivo.

AI Agent

El módulo AI Agent entrega un modelo unificado para integrar múltiples backends de IA. En vez de atar el framework a un único proveedor, está diseñado en torno a la integración multi-agente, el cambio entre ellos y la gestión de su ciclo de vida.

En la implementación actual:

  • brookesia_agent_manager maneja el registro de plugins de agente, el control de ciclo de vida con máquina de estados (activación, inicio, sleep, wake-up, shutdown).
  • brookesia_agent_helper provee APIs type-safe para interacción con funciones y eventos.
  • Los agentes soportados hoy incluyen Coze, OpenAI y Xiaozhi.

El cambio arquitectónico clave es que la IA pasa a ser una capacidad de sistema, no una feature aislada. Los agentes pueden integrarse con servicios fundacionales como audio o sincronización horaria, y acceder a capacidades del dispositivo a través de Function Calling y MCP. Eso le da a las aplicaciones basadas en LLM una ruta directa desde la interacción con el usuario hasta la ejecución de servicios en el dispositivo.

AI Expression

Si AI Agent define cómo un dispositivo piensa y actúa, AI Expression define cómo el usuario lo percibe. La implementación actual gira en torno a brookesia_expression_emote, que entrega:

  • Gestión de assets de emoji y animación.
  • Cambio de expresión y control de reproducción de animaciones.
  • Mostrar y ocultar códigos QR.
  • Presentación visual de mensajes de evento.

Este módulo es especialmente valioso para asistentes de voz, dispositivos compañeros, robots de escritorio y productos HMI con pantalla. Permite que el dispositivo no solo responda, sino que también exprese estado e intención de manera visual.

¿Qué chips Espressif soportan ESP-Brookesia v0.7?

El framework corre sobre la familia ESP-IDF, lo que en la práctica habilita los SoC con recursos suficientes para audio, video y stack de IA. Para hobbistas y desarrolladores en Chile y la región, los más relevantes en distribución local son ESP32-S3 (con vector instructions útiles para inferencia liviana), ESP32-P4 (orientado a HMI con display), y ESP32-C6 cuando se quiere combinar Wi-Fi 6 y bajo consumo. Los módulos están disponibles en MercadoLibre Chile y distribuidores locales que importan desde Aliexpress, con precios que arrancan desde aproximadamente 8.000 CLP para módulos ESP32-S3 básicos.

¿Cómo empezar a probar la nueva arquitectura?

Brookesia v0.7 incluye varios ejemplos que ejercitan los distintos módulos. Los dos puntos de entrada recomendados por Espressif son examples/service/console, útil para entender el modelo de servicios, y los ejemplos de agentes que demuestran la integración con Coze, OpenAI y Xiaozhi. La distribución se realiza vía ESP Component Registry, por lo que basta agregar la dependencia en el archivo idf_component.yml del proyecto.