- Pi-C.A.R.D es un asistente de voz con IA que se ejecuta completamente en local en Raspberry Pi; es un proyecto que implementa funciones de LLM conversacional en hardware Raspberry Pi
- Hay dos formas de interacción:
main.py, basado en wake word, y main_button.py, basado en un botón GPIO; durante la conversación no hace falta repetir la wake word
- El historial de conversación se puede ajustar en
config.py, y reducir el tamaño de la memoria permite obtener respuestas más rápidas
- Para que sea rápido y ligero, usa implementaciones en C++ como whisper.cpp y llama.cpp; para decidir si acceder a información externa usa
tool-bert2, un BERT fine-tuned
- Las funciones basadas en cámara aparecen configuradas en varias partes del README, pero hay una advertencia de que por ahora fueron eliminadas temporalmente debido a cambios en el soporte de vision models en llama.cpp
Qué hace Pi-C.A.R.D
- Pi-C.A.R.D es un asistente basado en IA que se ejecuta en Raspberry Pi, con el objetivo de procesar localmente las tareas que un LLM estándar como ChatGPT realiza en un entorno conversacional
- El nombre es una sigla de Raspberry Pi - Camera Audio Recognition Device
- El proyecto sigue en desarrollo e indica que acepta issues y pull requests
- Señala que el soporte de Docker agregado recientemente debería facilitar la configuración y las modificaciones
- Aún no hay una presentación en video disponible; se ofrecerá más adelante
Cómo funciona
-
Modo con wake word
- Al ejecutar
main.py, el sistema escucha una wake word e inicia la conversación
- Las wake words predeterminadas son
"raspberry", "barry" y "razbear"
- Una vez iniciada la conversación, no hace falta repetir la wake word cada vez
- Al decir palabras como
"stop", "exit" o "goodbye", la conversación termina
- La wake word y los comportamientos relacionados se pueden cambiar en
config.py
-
Modo con botón
- Con una breadboard, cables y un botón, se puede iniciar la conversación mediante un botón GPIO
- El flujo consiste en presionar el botón y luego decir el comando; según el README, se presenta como una forma de interacción más fluida
- Para configurar el botón, se siguen las indicaciones de
main_button.py
- En la versión con botón, se puede iniciar la conversación con el botón o interrumpir al assistant en cualquier momento
-
Memoria de conversación
- El chatbot tiene una memoria de conversación configurable
- Puede hacer que repita intervenciones anteriores o que profundice en temas tratados antes
- Si se quieren respuestas más rápidas, se puede configurar un valor de memoria más bajo en
config.py
Objetivo y límites de la ejecución local
- El objetivo del proyecto es comprobar qué tan eficientemente se puede crear un asistente de voz completamente offline en hardware relativamente económico como una Raspberry Pi
- Como todo el procesamiento se realiza en local, no es tan potente ni tan rápido como los sistemas basados en la nube
- El README considera que durante el último año hubo grandes avances en modelos LLM pequeños, y que este proyecto también puede mejorar junto con ellos
- La razón para no convertirlo en una app es que ejecutar rápidamente un asistente de voz completamente offline en Raspberry Pi se consideró la parte más difícil
- Explica que, si este enfoque funciona, sistemas similares podrían ejecutarse más rápido en hardware más potente
Ejecución y configuración
- Tras descargar el repositorio y completar los requisitos y la configuración, se ejecuta con el siguiente comando
python main.py
- La versión con botón se ejecuta con este comando
python main_button.py
- La ejecución con Docker se presenta como el método recomendado y usa los siguientes comandos
sudo docker-compose build
sudo docker-compose up
- El soporte de Docker es una función agregada recientemente, por lo que podría no funcionar a la perfección
- El método con Docker solo funciona con la versión de wake word, y todavía no está claro cómo pasar el acceso GPIO al contenedor
Software y herramientas utilizados
- Para crear un sistema rápido y ligero, se usan implementaciones en C++ siempre que sea posible
- Para la transcripción de audio usa whisper.cpp, que debe configurarse siguiendo la guía de quick-start
- El README explica que usa llama.cpp para las funciones de vision, pero la advertencia superior señala que llama.cpp ya no da soporte activo a vision models y por eso la función de cámara fue eliminada temporalmente
- Para que el assistant se comporte de forma más cercana a un asistente real, ofrece algunas funciones de acceso a herramientas
- La decisión de acceder a herramientas se realiza mediante tool-bert
tool-bert2 es un BERT fine-tuned que decide cuándo acceder a información externa- El método para crear este modelo está explicado en el repositorio de tool-bert
- Para activar el acceso a herramientas, hay que revisar las claves y secretos necesarios en
.env.example
Estado de la cámara y las funciones de visión
- El cuerpo del README indica que, si se conecta una cámara a la Raspberry Pi, se pueden tomar fotos, describir lo que se ve y hacer preguntas sobre esa imagen
- La configuración de la función de visión se hace cambiando
vision_model a vlm en config.py
- Se menciona Qwen2-VL-2B-Instruct como modelo utilizable
- Como el tamaño de los tokens de imagen de entrada es dinámico, explica que reducir el tamaño de las fotos tomadas puede acortar el tiempo de inferencia
- Sin embargo, según la advertencia al inicio del proyecto, la función de cámara está actualmente eliminada temporalmente
Hardware necesario
- La configuración básica de hardware incluye una Raspberry Pi 5 Model B, un micrófono USB y un altavoz
- El micrófono USB y el altavoz se conectan a los puertos USB de la Raspberry Pi
- La cámara se conecta al puerto de cámara de la Raspberry Pi
- Los componentes usados en el README son los siguientes
- La Raspberry Pi 5 usa un puerto de cámara nuevo, por lo que se necesita un conector de cámara nuevo
- El conector de cámara es opcional, pero debe comprarse si se quiere usar la función de cámara
- Para configurar el botón GPIO, indica que fue útil la primera parte de este tutorial
- El proyecto se enfoca en funcionar en Raspberry Pi 5, pero explica que también podría funcionar en otros dispositivos
Roadmap y estado de avance
- Entre los elementos marcados como implementados se incluyen la función básica de conversación, la función de cámara, benchmarks de tiempo de respuesta, pruebas de overclocking y la exploración de métodos para reducir el tiempo de whisper
- También figuran como completadas la función para interrumpir al assistant y hacer una nueva pregunta, el uso de un custom tuned model y mejoras en
tool-bert, el modelo de funciones para servicios externos
- También se completaron las pruebas de conexión a energía portátil y la dockerización para probar más dispositivos
- Entre los elementos pendientes están mejores tutoriales y videos, la generación opcional de modelos usando entropix, pruebas en otros idiomas y la adición de más servicios externos
- El tablero de Notion para seguimiento del progreso aún no está terminado y se ofrece este enlace
1 comentarios
Opiniones de Hacker News
Quería crear un asistente de voz completamente offline, que no necesitara conexión a internet en absoluto, para proteger la privacidad del usuario y evitar que los datos fueran a servidores de terceros.
Buen intento, y se agradece.
Me pregunto si esto corre solo en la Pi5, o si también corre en otras placas que no sean Raspberry Pi.
Hablando en serio, el nombre me llamó la atención y, al leer la presentación, pensé: “si es una Alexa que no sube a Amazon todo lo que digo, entonces podría servirme”.
Si la palabra de activación predeterminada es “hey assistant”, sugiero “Computer” :) Por supuesto, la voz debería sonar como https://en.wikipedia.org/wiki/Majel_Barrett.
Lo que hace falta es un asistente de voz que pueda manejarse en una RPi 4, se integre con HomeAssistant y sea solo offline, para que no envíe mis datos a ningún lado.
Comparado con lo que he visto hasta ahora, este proyecto parece cumplir casi todos los requisitos, así que parece muy bien hecho.
Además, me interesa saber si alguien recomienda algún micrófono compatible con RPi que sirva para usos tipo Alexa.
Es difícil correr un modelo de lenguaje grande de forma práctica en una 4B, pero no necesariamente tiene que estar basado en un modelo de lenguaje grande.
En la comunidad de Rhasspy es común el patrón de hacer detección local, barata y liviana de la palabra de activación en dispositivos satélite con micrófono (para eso una 4B debería alcanzar), y luego transmitir la grabación real por la red local a un hub central para obtener mejores resultados.
Se consiguen en eBay por unos 15 a 20 dólares.
NabuCasa contrató al desarrollador principal de Rhasspy para trabajar en esta función, y sigue mejorando con cada actualización.
“¿Por qué Pi-card? Raspberry Pi - Camera Audio Recognition Device”. Parece que se les escapó la oportunidad de usar LCARS.
Podría haber sido LLM Camera Audio Recognition Service y, por supuesto, responder a la palabra clave “computer”. Si corre en algo que no sea una Pi, podría convertirse en LCARS.
Se lee 100% como Picard, y es más fácil de reconocer que LCARS.
Tengo muchas ganas de probar esto.
Por lo que sé, todavía hacen mucha falta asistentes de voz abiertos, estables, flexibles y centrados en la privacidad, así que espero que este proyecto gane impulso.
Hace aproximadamente un año, mi familia tenía muchas ganas de traer una Alexa, pero como no quería tener un dispositivo de vigilancia de Bezos en casa, los convencí de intentar construir uno nosotros. Elegí Mycroft en una Pi 4, pero no salió bien: la detección de la palabra de activación era irregular, le faltaban integraciones y en ese momento parecía prácticamente un proyecto abandonado. Intenté contribuir al proyecto y a las integraciones que nos estaban bloqueando, pero la vida se interpuso y nunca volví a retomarlo; por suerte, mi familia también se olvidó de Alexa.
No recuerdo si era nano o pico; en todo caso, era una placa del tamaño aproximado de un SO-DIMM. No tenía palabra de activación: al presionar el botón iluminado en blanco, cambiaba de color dos veces, una para confirmar la pulsación y otra para indicar que estaba escuchando. Al terminar de hablar, volvía a cambiar de color y decía la respuesta.
En el backend usaba algo de Google, y configurarlo y mantenerlo funcionando era realmente frustrante, pero funcionaba. Tenía dos de esos dispositivos, así que he estado esperando algo que me permita autoalojar algo parecido.
Planeo seguir trabajando más en esto. Hay algunas demos cortas en YouTube que permiten hacerse una idea de la calidad actual: https://www.youtube.com/watch?v=OryGVbh5JZE
Me pregunto si esto se puede ejecutar en una máquina Linux común.
O si alguien conoce algún proyecto parecido que sí pueda hacerlo.
Busqué hace un tiempo, pero este campo es complejo y las restricciones eran sutiles.
En general, Pi-C.A.R.D parece usar Python y C++, así que no creo que haya mayores problemas para hacerlo correr en cualquier lugar donde se pueda ejecutar y compilar Python y C++.
Hace unos 3 años intenté hacer algo así en una RPI 4 de primera generación, pero me topé con las limitaciones del hardware y con mis propios límites de conocimiento.
Ver que ahora realmente funciona es genial.
Sería genial que existiera un raspi hat al que se le pudiera conectar una GPU, aunque no sé bien si sería práctico o posible.
Las tarjetas gráficas de hoy son los residuos electrónicos de mañana, así que podrían tener una segunda vida potenciando este tipo de proyectos DIY con raspi.
Si le agregas una GPU/adaptador/fuente de alimentación para aprovechar núcleos CUDA baratos, es muy probable que en consumo, precio y tamaño termines peor que con una mejor solución SoC o x86 NUC.
No sé qué clase de magia hay dentro de PCIe, pero al menos una placa comercial, la Atomic Pi, tenía una interfaz PCIe “expuesta”.
En todo caso, la GPU iba sobre una PCB pequeña, y esa PCB se conectaba mediante un cable USB3 a una PCB más pequeña en la ranura PCIe de la placa madre. La idea es que, sea lo que sea PCIe, se puede llevar hasta una GPU por un cable USB3 y hacer que funcione.
Veo un parlante en la lista de hardware; me pregunto si también responde hablando.
Por ahora usa https://espeak.sourceforge.net/, así que no es precisamente muy agradable de escuchar.
Además, transmite en streaming las respuestas del modelo de lenguaje grande, así que no se tarda mucho en recibir una respuesta. Como procesa por chunks, a veces llega a pronunciar brevemente solo una parte de una palabra. Por supuesto, el tiempo de espera también depende de qué modelo se use y de qué tamaño tenga el contexto.
¿Por qué Picard siempre tiene que especificar hasta la temperatura de su té Earl Grey?
Si la IA es tan inteligente, ¿no debería haber aprendido ya sus preferencias?
En la serie, muchos personajes le dan instrucciones más flexibles al replicador. “Tea, Earl Grey, Hot” parece una costumbre de Picard, y podría ser un hábito adquirido con dispositivos de comida y bebida más primitivos que el replicador de la Enterprise-D.
¿Seguirán existiendo las demandas en un mundo posescasez? Probablemente.
Parece que la mayoría de la gente de Starfleet no sabe usar bien los replicadores. Tienen un dispositivo así de inteligente, pero lo usan como un electrodoméstico común cuyo manual nunca leyeron, se pierden el 90% de sus funciones y luego se quejan de que la comida replicada sabe mal.
https://i.redd.it/hluqexh3oqc91.jpg
Me pregunto cómo funciona la palabra de activación.
¿Está escuchando todo el tiempo y descarta los últimos segundos si no contienen la palabra o frase de activación?
Más precisamente, es una ventana deslizante (rolling window): guarda varios chunks de audio y va descartando el más antiguo.