Implémenter rapidement des conceptions IoT « Alexa Built-in » à l'aide d'un kit basé sur microcontrôleur
Avec la contribution de Rédacteurs nord-américains de DigiKey
2020-02-11
Les assistants vocaux ont évolué rapidement et sont devenus une fonctionnalité importante dans tous les produits intelligents. Parmi les solutions actuelles basées sur le cloud, Alexa Voice Service (AVS) d'Amazon a émergé comme l'assistant vocal prédominant, en fournissant une fonctionnalité clés en main qui tire parti des ressources cloud d'Amazon pour la reconnaissance vocale et le traitement du langage naturel.
Cependant, pour les développeurs, les exigences de performances et la complexité de la conception d'AVS se sont avérées être un obstacle important à l'introduction de dispositifs plus compacts basés sur microprocesseur pour la maison connectée et l'Internet des objets (IoT). Conçu en tant que solution clés en main et conception de référence pour les applications personnalisées, un kit de NXP Semiconductors propose une offre Amazon AVS spécialement conçue pour les dispositifs à ressources limitées.
Cet article montre comment les développeurs peuvent implémenter rapidement des conceptions « Alexa Built-in » (avec Alexa intégré) en utilisant une solution prête à l'emploi de NXP.
Présentation d'AVS
Depuis son apparition il y a dix ans, la technologie d'assistant vocal a évolué rapidement et a stimulé le marché des enceintes intelligentes, qui, selon les analystes du marché, inclut déjà environ un tiers de la population américaine. Parmi les solutions concurrentes, les enceintes intelligentes Amazon Echo ont gagné une part dominante, en tirant parti du succès d'Amazon Web Services (AWS) en fournissant des ressources basées cloud pour prendre en charge des applications Echo tierces, ou Skills.
En utilisant le kit Alexa Skills Kit (ASK) et les interfaces de programmation (API) associées, les développeurs peuvent tirer parti de la base installée en rapide expansion des enceintes intelligentes Echo pour ajouter un certain niveau de commande vocal à leurs dispositifs connectés. Avec cette approche, les produits connectés comme les téléviseurs ou thermostats intelligents qui « fonctionnent avec Alexa » peuvent répondre aux requêtes vocales de l'utilisateur et aux directives associées reçues depuis le cloud d'Alexa (Figure 1). Ce schéma résume AVS et fournit un aperçu de son potentiel.
Figure 1 : En créant des applications Alexa, ou des Skills, les développeurs peuvent permettre aux produits connectés d'interagir avec les commandes vocales des utilisateurs grâce aux produits Echo d'Amazon. (Source de l'image : Amazon Web Services)
Conception Alexa Built-in
Contrairement aux produits qui « fonctionnent avec Alexa », les produits intelligents avec « Alexa Built-in » offrent une interface plus fluide et à faible latence entre le dispositif à activation vocale Alexa et les ressources AWS. Ces produits intègrent AVS directement dans une conception de dispositif connecté. En utilisant AVS en combinaison avec la plateforme AWS IoT Core, les développeurs peuvent implémenter des applications IoT sophistiquées qui permettent aux utilisateurs d'utiliser des commandes vocales avec des produits compatibles avec Alexa pour contrôler des dispositifs connectés et pour recevoir des réponses vocales de la part de ces dispositifs (Figure 2).
Figure 2 : Les dispositifs compatibles avec Alexa fournissent aux utilisateurs une interface vocale pour contrôler des dispositifs (en haut) ou pour recevoir des notifications de la part de dispositifs IoT (en bas) connectés aux ressources Amazon Web Services par le biais d'AWS IoT Core. (Source de l'image : Amazon Web Services)
Par le passé, cependant, les conceptions pour les dispositifs compatibles avec Alexa au cœur de ce type d'application IoT exigeaient elles-mêmes des efforts de conception majeurs. Pour utiliser des services Alexa basés sur le cloud, un dispositif devait exécuter plusieurs bibliothèques de services AVS par le biais du kit de développement logiciel (SDK) pour dispositif AVS sur des plateformes Android ou Linux pour détecter le mot d'activation, communiquer avec le cloud d'Alexa et traiter les directives liées aux fonctionnalités prises en charge (Figure 3).
Figure 3 : Ce schéma illustre les composants du kit de développement logiciel pour dispositif AVS et la circulation des données entre eux. (Source de l'image : Amazon Web Services)
Pour prendre en charge ces bibliothèques de services, les conceptions de dispositifs compatibles avec Alexa avaient typiquement besoin d'un processeur d'application hautes performances et d'au moins 50 mégaoctets (Mo) de mémoire pour répondre aux exigences de traitement d'AVS. En outre, ces conceptions intégraient souvent un processeur de signaux numériques (DSP) afin d'exécuter les algorithmes complexes requis pour extraire des voix d'environnements bruyants et prendre en charge les capacités de reconnaissance de voix lointaines que les utilisateurs attendent des assistants vocaux. Au final, les exigences système pour construire un dispositif compatible avec Alexa efficace allaient généralement bien au-delà du coût et de la complexité requis pour des dispositifs IoT pratiques.
Cependant, avec le lancement de son intégration AVS pour AWS IoT Core, Amazon a considérablement réduit la charge de travail du processeur et l'empreinte mémoire requises pour implémenter des produits Alexa Built-in. Avec ce service, les tâches intensives de calcul et celles nécessitant beaucoup de mémoire sont transférées du dispositif compatible avec Alexa vers un dispositif virtuel associé dans le cloud (Figure 4).
Figure 4 : AVS pour AWS IoT Core transfère les tâches nécessitant beaucoup de mémoire et de traitement vers le cloud pour permettre l'implémentation des capacités d'assistant vocal Alexa sur des dispositifs IoT à ressources limitées. (Source de l'image : Amazon Web Services)
Les responsabilités de traitement du dispositif physique sont réduites à la fourniture de services plus basiques comme la messagerie sécurisée, la distribution de données audio fiables vers et depuis Alexa, la gestion des tâches et les notifications d'événement au sein du dispositif et avec Alexa. Le transfert de données, de commandes et de notifications entre le dispositif physique et Alexa s'effectue par le biais de la messagerie MQTT (MQ Telemetry Transport), en utilisant quelques thèmes réservés dans le protocole publication-abonnement MQTT. Enfin, une application mobile auxiliaire interagit avec le cloud d'Alexa pour l'enregistrement du dispositif et toute interaction de l'utilisateur supplémentaire requise avec le dispositif compatible avec Alexa.
Grâce au transfert des lourdes tâches de traitement vers le cloud, AVS pour AWS IoT Core permet aux développeurs de créer des produits Alexa Built-in avec des plateformes qui sont plus familières aux développeurs de systèmes embarqués. Plutôt que d'utiliser des processeurs d'application avec 50 Mo de mémoire s'exécutant sur Linux ou Android, les développeurs peuvent implémenter ces conceptions avec des microcontrôleurs plus modestes, avec moins de 1 Mo de mémoire RAM exécutant un logiciel de système d'exploitation en temps réel (RTOS). En fait, les conceptions compatibles avec Alexa qui sont conçues avec AVS pour AWS IoT Core peuvent atteindre une réduction de 50 % des nomenclatures par rapport à celles qui sont conçues pour exécuter l'ensemble de la suite de services AVS localement.
Bien qu'AVS pour AWS IoT Core prenne en charge une plateforme d'exécution plus économique, l'implémentation d'un produit Alexa Built-In certifié reste une entreprise complexe. Les développeurs qui découvrent AVS et IoT Core peuvent se retrouver face à une courbe d'apprentissage considérable lorsqu'ils s'attellent aux exigences d'AWS en matière de sécurité, de communication, de gestion des comptes, de conception de l'expérience utilisateur (UX), etc. Peu importe qu'ils connaissent ou non l'écosystème AWS, tous les développeurs de produits Alexa doivent s'assurer que leurs conceptions répondent à une longue liste de spécifications et d'exigences pour obtenir la certification Alexa d'Amazon.
La solution basée sur microcontrôleur de NXP pour Alexa constitue une solution système clés en main qui implémente entièrement les exigences matérielles et logicielles côté dispositif pour AVS pour AWS IoT Core d'Amazon.
Solution Alexa basée sur microcontrôleur
Développé autour du microcontrôleur i.MX RT106A de NXP, le kit AVS SLN-ALEXA-IOT de NXP fournit une connectivité AWS prête à l'emploi, des algorithmes audio en champ lointain qualifiés AVS, une annulation de l'écho, la fonctionnalité de mot d'activation Alexa et du code d'application. Basé sur un cœur Arm Cortex-M7, le microcontrôleur i.MX RT106A du kit fait partie de la gamme de processeurs hybrides i.MX RT106x de NXP qui sont spécialement conçus pour l'edge computing IoT. Conçu pour les applications vocales embarquées, le RT106A ajoute une fonctionnalité spécialisée à l'ensemble complet d'interfaces périphériques de l'architecture de base de la gamme de processeurs hybrides i.MX RT1060 de NXP, une mémoire interne étendue et une vaste prise en charge d'options de mémoire externe (Figure 5).
Figure 5 : La gamme de processeurs hybrides i.MX RT1060 de NXP intègre un cœur de microcontrôleur Arm Cortex-M7 avec un ensemble complet d'interfaces périphériques, une mémoire et d'autres capacités généralement requises dans un dispositif IoT. (Source de l'image : NXP)
Grâce à ses fonctionnalités intégrées, le microcontrôleur i.MX RT106A n'a besoin que de quelques composants supplémentaires pour fournir la base matérielle requise pour l'implémentation d'AVS pour AWS IoT Core. Dans son kit SLN-ALEXA-IOT, NXP intègre le microcontrôleur i.MX RT106A dans un module système avec 256 mégabits (Mb) de mémoire Flash, un module d'émetteur-récepteur Wi-Fi/Bluetooth LBEE5KL1DX de Murata Electronics et un convertisseur abaisseur AP2202K-3.3TRG1 de Diodes (Figure 6).
Figure 6 : La conception du module système du kit AVS SLN-ALEXA-IOT de NXP tire parti de l'interface matérielle simple requise pour l'intégration du microcontrôleur i.MX RT106A de NXP avec une mémoire Flash externe et un émetteur-récepteur sans fil. (Source de l'image : NXP)
En complément de ce module système, une carte vocale dans le kit SLN-ALEXA-IOT fournit trois microphones MEMS à modulation d'impulsion-densité (PDM) SPH0641LM4H-1 de Knowles, un haut-parleur AS01808AO de PUI Audio et un amplificateur audio de classe D TFA9894D de NXP. En plus d'un connecteur USB Type-C pour l'alimentation du kit et pour l'exécution d'une console shell à partir d'un ordinateur personnel, la carte vocale fournit des embases pour Ethernet, des périphériques série et des E/S à usage général (GPIO) pour le microcontrôleur i.MX RT106A. Enfin, la carte inclut des commutateurs pour l'entrée de commandes de base ainsi que des LED pour une rétroaction visuelle conforme aux exigences d'AVS UX Attention System d'Amazon grâce à différentes couleurs de LED et/ou différents schémas de cycles on/off.
Avec son module système et sa carte vocale, le matériel SLN-ALEXA-IOT fournit une plateforme complète pour le traitement côté dispositif du logiciel AVS pour AWS IoT Core. Cependant, comme indiqué précédemment, les conceptions de dispositifs IoT compatibles avec Alexa dépendent tout autant d'un logiciel optimisé que du matériel. La création de ce logiciel de A à Z avec l'API AVS pour AWS IoT d'Amazon peut retarder considérablement les projets, car les développeurs doivent concevoir les objets de données requis et implémenter les protocoles associés. D'autres retards peuvent survenir lorsque, dans le cadre de leurs efforts pour obtenir la certification Alexa Built-in, les développeurs essaient de se conformer aux exigences d'AVS UX Attention System, aux pratiques de sécurité d'AWS et à d'autres exigences qui concernent chaque aspect des interactions des utilisateurs avec les services Alexa dans la conception. NXP résout ces problèmes avec son environnement logiciel de commande vocale complet basé sur Amazon FreeRTOS, construit sur une couche de pilotes logiciels pour des composants Flash XIP (exécution sur place), des composants de connectivité et d'autres composants matériels (Figure 7).
Figure 7 : Conçu sur Amazon FreeRTOS, l'environnement de système de commande vocale de NXP fournit un ensemble complet de services intergiciels, notamment des routines micrologicielles pour l'inférence d'apprentissage automatique et le traitement du circuit d'entrée audio. (Source de l'image : NXP)
Pour soutenir les capacités de traitement vocal de cet environnement logiciel, le micrologiciel Intelligent Toolbox de NXP fournit des fonctions optimisées pour toutes les tâches audio, notamment le moteur d'inférence d'apprentissage automatique (ML) et le circuit d'entrée audio ML pour la mise en forme et l'optimisation des signaux audio. D'autres services intergiciels prennent en charge la connectivité sécurisée, les communications AWS et d'autres capacités audio. Par-dessus cette couche de services complète, le logiciel pour AWS IoT Core, l'intégration et d'autres fonctionnalités de contrôle d'application gèrent le démarrage à partir d'un programme d'amorçage à deux phases avec prise en charge des mises à jour sans fil (OTA) reposant sur le service AWS IoT OTA et le client OTA Amazon FreeRTOS.
En utilisant le logiciel installé en usine qui s'exécute dans cet environnement, les développeurs peuvent immédiatement utiliser le kit matériel SLN-ALEXA-IOT avec une application complète compatible avec Alexa conçue pour utiliser un compte de démonstration de NXP pour AWS IoT. La documentation de NXP fournit une présentation détaillée du processus d'utilisation du kit, de provisionnement d'informations d'identification Wi-Fi et d'exécution de l'authentification du dispositif AWS avec le compte de démonstration. Dans le cadre de ce processus, les développeurs interagissent avec le kit et AWS en utilisant une application mobile Android incluse dans le pack logiciel, disponible sur le site de NXP à l'aide d'un code d'activation fourni avec chaque kit SLN-ALEXA-IOT. Après quelques étapes simples, les développeurs peuvent immédiatement commencer à interagir avec le kit via le même type d'interactions vocales Alexa que celles proposées par les enceintes intelligentes Echo.
Pour réaliser rapidement le prototypage de produits avec les capacités Alexa, le kit SLN-ALEXA-IOT et le logiciel installé en usine fournissent une plateforme prête à l'emploi. En même temps, les outils matériels et logiciels du kit servent de plateforme de développement rapide pour la création de conceptions personnalisées compatibles avec Alexa et basées sur le microcontrôleur i.MX RT106A.
Développement personnalisé
Le logiciel pour solutions Alexa basées sur i.MX RT106A tire parti des capacités de l'environnement d'exécution de commande vocale de NXP via le SDK MCU Alexa Voice IoT de NXP fourni dans le cadre du pack logiciel disponible lors de l'activation du produit. Conçu en tant qu'extension de l'environnement de développement intégré (IDE) MCUXpresso basé sur Eclipse de NXP, ce SDK combine du code source complet pour les applications d'exemple, des pilotes et un intergiciel avec des en-têtes pour les distributions binaires de capacités micrologicielles spécialisées, comme Intelligent Toolbox de NXP, le moteur d'inférence ML et le circuit d'entrée audio ML.
Les développeurs qui ont besoin de déployer rapidement un produit compatible avec Alexa peuvent en principe utiliser l'application complète de démonstration Alexa avec des modifications mineures. Dans le cas le plus simple, ces modifications redirigent simplement l'application vers le propre compte AWS du développeur en utilisant ses propres informations d'identification. NXP fournit une description détaillée pour exécuter ce processus.
Pour un développement personnalisé, les applications d'exemple incluses dans le pack logiciel fournissent des exemples exécutables qui montrent comment travailler avec le SDK MCU Alexa Voice IoT de NXP. Au lieu de passer directement dans l'application complète de démonstration Alexa, les développeurs peuvent explorer des applications d'exemple qui leur permettent de se concentrer davantage sur des capacités spécifiques, notamment le circuit d'entrée audio, la connectivité Wi-Fi et Bluetooth, l'amorçage, etc. Par exemple, l'application d'exemple du circuit d'entrée audio illustre les schémas de conception de base pour détecter le mot d'activation à l'aide de tâches Amazon FreeRTOS.
Dans l'application d'exemple du circuit d'entrée audio, la routine principale démontre la façon dont les développeurs peuvent initialiser les sous-systèmes matériels et logiciels, puis utiliser la fonction FreeRTOS xTaskCreate pour lancer la tâche d'application (appTask) principale et une tâche shell de console (sln_shell_task) avant d'envoyer la commande vers le planificateur FreeRTOS (Liste 1). (Remarque : l'appel de vTaskStartScheduler pour démarrer le planificateur FreeRTOS est renvoyé seulement si la mémoire du planificateur est insuffisante.)
Copier void main(void) { /* Enable additional fault handlers */ SCB->SHCSR |= (SCB_SHCSR_BUSFAULTENA_Msk | /*SCB_SHCSR_USGFAULTENA_Msk |*/ SCB_SHCSR_MEMFAULTENA_Msk); /* Init board hardware. */ BOARD_ConfigMPU(); BOARD_InitBootPins(); BOARD_BootClockRUN(); .
.
.
RGB_LED_Init(); RGB_LED_SetColor(LED_COLOR_GREEN); sln_shell_init(); xTaskCreate(appTask, "APP_Task", 512, NULL, configMAX_PRIORITIES - 1, &appTaskHandle); xTaskCreate(sln_shell_task, "Shell_Task", 1024, NULL, tskIDLE_PRIORITY + 1, NULL); /* Run RTOS */ vTaskStartScheduler(); .
.
.
}
Liste 1 : Incluse dans le SDK MCU Alexa Voice IoT de NXP, une application d'exemple de circuit d'entrée audio illustre les exigences d'initialisation de base et la création de tâches FreeRTOS pour la tâche d'application principale et une tâche shell de console. (Source du code : NXP)
Après l'initialisation du sous-système audio, la tâche d'application principale appTask lance à son tour deux tâches FreeRTOS. Une tâche exécute une routine de service, audio_processing_task, qui traite l'entrée audio, tandis que l'autre gère la conversion de la sortie PDM du microphone en modulation par impulsions et codage (PCM). Après quelques opérations internes supplémentaires, appTask se met dans une boucle infinie, en attendant une notification RTOS signifiant que le mot d'activation a été détecté (Liste 2).
Copier void appTask(void *arg) { .
.
.
// Create audio processing task if (xTaskCreate(audio_processing_task, "Audio_processing_task", 1536U, NULL, audio_processing_task_PRIORITY, &xAudioProcessingTaskHandle) != pdPASS) .
.
.
// Create pdm to pcm task if (xTaskCreate(pdm_to_pcm_task, "pdm_to_pcm_task", 1024U, NULL, pdm_to_pcm_task_PRIORITY, &xPdmToPcmTaskHandle) != pdPASS) .
.
.
RGB_LED_SetColor(LED_COLOR_OFF); SLN_AMP_WriteDefault(); uint32_t taskNotification = 0; while (1) { xTaskNotifyWait(0xffffffffU, 0xffffffffU, &taskNotification, portMAX_DELAY); switch (taskNotification) { case kWakeWordDetected: { RGB_LED_SetColor(LED_COLOR_BLUE); vTaskDelay(100); RGB_LED_SetColor(LED_COLOR_OFF); break; } default: break; } taskNotification = 0; } }
Liste 2 : Dans l'application d'exemple de circuit d'entrée audio, la tâche d'application principale, appTask, lance des tâches pour gérer le traitement audio et la conversion des données du microphone, puis attend une notification FreeRTOS (taskNotification) qui indique que le mot d'activation a été détecté (kWakeWordDetected). (Source du code : NXP)
Ensuite, la tâche de traitement audio de cette application d'exemple initialise la fonction micrologicielle du mot d'activation et les paramètres de détection du mot d'activation avant d'entrer également dans une boucle infinie où elle attend une notification FreeRTOS de la tâche de conversion des données du microphone qui indique que les données traitées du microphone sont disponibles. À ce stade, la tâche de traitement audio appelle les fonctions du micrologiciel Intelligent Toolbox qui traitent les données audio et exécutent la détection du mot d'activation en utilisant le moteur d'inférence ML (Liste 3).
Copier void audio_processing_task(void *pvParameters) { .
.
.
SLN_AMAZON_WAKE_Initialize(); SLN_AMAZON_WAKE_SetWakeupDetectedParams(&wakeWordActive, &wwLen); while (1) { // Suspend waiting to be activated when receiving PDM mic data after Decimation xTaskNotifyWait(0U, ULONG_MAX, &taskNotification, portMAX_DELAY); .
.
.
// Process microphone streams int16_t *pcmIn = (int16_t *)((*s_micInputStream)[pingPongIdx]); SLN_Voice_Process_Audio(g_externallyAllocatedMem, pcmIn, &s_ampInputStream[pingPongAmpIdx * PCM_SINGLE_CH_SMPL_COUNT], &cleanAudioBuff, NULL, NULL); // Pass output of AFE to wake word SLN_AMAZON_WAKE_ProcessWakeWord(cleanAudioBuff, 320); taskNotification &= ~currentEvent; if (wakeWordActive) { wakeWordActive = 0U; // Notify App Task Wake Word Detected xTaskNotify(s_appTask, kWakeWordDetected, eSetBits); } } }
Liste 3 : Dans l'application d'exemple de circuit d'entrée audio, la tâche de traitement audio initialise le moteur du mot d'activation du micrologiciel, attend une notification FreeRTOS qui indique que des données du microphone sont disponibles, et appelle finalement le circuit d'entrée analogique du micrologiciel Intelligent Toolbox de NXP (SLN_Voice_Process_Audio) et le moteur d'inférence ML (SLN_AMAZON_WAKE_ProcessWakeWord) pour la détection du mot d'activation. (Source du code : NXP)
Après la détection du mot d'activation, la tâche de traitement audio émet une notification de tâche FreeRTOS pour indiquer cet événement à la tâche d'application principale, appTask. Après la réception de cette notification, appTask fait clignoter momentanément une LED bleue (voir la Liste 2).
L'application d'exemple complète Alexa repose sur les mêmes schémas que ceux décrits pour l'application de circuit d'entrée audio plus simple, mais permet d'étendre considérablement cette base de code basique pour prendre en charge toutes les fonctionnalités d'Alexa. Par exemple, une fois que le moteur d'inférence ML détecte le mot d'activation dans l'application d'exemple Alexa, la tâche de traitement audio émet une série de notifications FreeRTOS associées à chaque phase de la séquence de traitement Alexa (Liste 4).
Copier void audio_processing_task(void *pvParameters) { .
.
.
SLN_AMAZON_WAKE_Initialize(); SLN_AMAZON_WAKE_SetWakeupDetectedParams(&u8WakeWordActive, &wwLen); while (1) { // Suspend waiting to be activated when receiving PDM mic data after Decimation xTaskNotifyWait(0U, ULONG_MAX, &taskNotification, portMAX_DELAY); .
.
.
int16_t *pcmIn = (int16_t *)((*s_micInputStream)[pingPongIdx]); SLN_Voice_Process_Audio(g_w8ExternallyAllocatedMem, pcmIn, &s_ampInputStream[pingPongAmpIdx * PCM_SINGLE_CH_SMPL_COUNT], &pu8CleanAudioBuff, NULL, NULL); SLN_AMAZON_WAKE_ProcessWakeWord((int16_t*)pu8CleanAudioBuff, 320); taskNotification &= ~currentEvent; // If devices is muted, then skip over state machine if (s_micMuteMode) { if (u8WakeWordActive) { u8WakeWordActive = 0U; } memset(pu8CleanAudioBuff, 0x00, AUDIO_QUEUE_ITEM_LEN_BYTES); } if (u8WakeWordActive) { configPRINTF(("Wake word detected locally\r\n")); } // Execute intended state switch (s_audioProcessingState) { case kIdle: /* add clean buff to cloud wake word ring buffer */ continuous_utterance_samples_add(pu8CleanAudioBuff, PCM_SINGLE_CH_SMPL_COUNT * PCM_SAMPLE_SIZE_BYTES); if (u8WakeWordActive) { continuous_utterance_buffer_set(&cloud_buffer, &cloud_buffer_len, wwLen); u8WakeWordActive = 0U; wwLen = 0; // Notify App Task Wake Word Detected xTaskNotify(s_appTask, kWakeWordDetected, eSetBits); // App Task will now determine if we begin recording/publishing data } break; .
.
.
case kWakeWordDetected: audio_processing_reset_mic_capture_buffers(); // Notify App_Task to indicate recording xTaskNotify(s_appTask, kMicRecording, eSetBits); if (s_audioProcessingState != kMicRecording) { s_audioProcessingState = kMicCloudWakeVerifier; } configPRINTF(("[audio processing] Mic Recording Start.\r\n")); // Roll into next state case kMicCloudWakeVerifier: case kMicRecording: micRecordingLen = AUDIO_QUEUE_ITEM_LEN_BYTES; if (u8WakeWordActive) { u8WakeWordActive = 0U; } // Push data into buffer for consumption by AIS task status = audio_processing_push_mic_data(&pu8CleanAudioBuff, &micRecordingLen); .
.
.
} }
Liste 4 : Dans l'application complète Alexa, la tâche de traitement audio étend les étapes de traitement effectuées dans l'application de circuit d'entrée audio avec du code supplémentaire pour la gestion des phases de traitement audio suivantes dans la séquence Alexa. (Source du code : NXP)
Après la détection du mot d'activation ML local, la tâche de traitement audio de l'application complète Alexa envoie une notification à la tâche d'application principale, comme décrit précédemment. En outre, elle doit alors gérer des états de traitement audio où le microphone reste ouvert pour capturer l'ensemble de l'entrée audio pour le traitement de la parole dans le cloud d'Alexa sans perdre le flux de données d'origine qui contient le mot d'activation détecté localement. Ce flux de données complet est transféré vers le cloud d'Alexa pour la vérification du mot d'activation et pour le traitement plus approfondi de la parole.
À chaque phase de cette séquence de traitement, la tâche de traitement audio émet des notifications FreeRTOS correspondantes et les envoie à la tâche d'application principale. Comme avec la tâche de traitement audio, l'application complète Alexa étend le schéma de la tâche d'application principale présenté sous une forme plus simple dans l'application de circuit d'entrée audio. Ici, la tâche d'application principale (appTask) de l'application complète Alexa, génère à la fois les événements pour la transmission vers le cloud d'Alexa et pour la gestion des LED du kit conformément aux exigences d'AVS UX Attention System d'Amazon. Par exemple, si le microphone reste ouvert après la détection du mot d'activation, la tâche de traitement audio envoie une notification à la tâche d'application principale, qui définit l'état d'attention UX approprié (voyant LED cyan fixe) (voir les parties surlignées en jaune dans la Liste 5 et la partie surlignée correspondante dans la Liste 4).
Copier void appTask(void *arg) { .
.
.
// Create audio processing task if (xTaskCreate(audio_processing_task, "Audio_proc_task", 1536U, NULL, audio_processing_task_PRIORITY, &xAudioProcessingTaskHandle) != pdPASS) .
.
.
// Create pdm to pcm task if (xTaskCreate(pdm_to_pcm_task, "pdm_to_pcm_task", 512U, NULL, pdm_to_pcm_task_PRIORITY, &xPdmToPcmTaskHandle) != pdPASS) .
.
.
while(1) { xTaskNotifyWait( ULONG_MAX, ULONG_MAX, &taskNotification, portMAX_DELAY ); if (kIdle & taskNotification) { // Set UX attention state ux_attention_set_state(uxIdle); taskNotification &= ~kIdle; } if (kWakeWordDetected & taskNotification) { if (reconnection_task_get_state() == kStartState) { if (!AIS_CheckState(&aisHandle, AIS_TASK_STATE_MICROPHONE)) { // Set UX attention state ux_attention_set_state(uxListeningStart); .
.
.
// Begin sending speech micOpen.wwStart = aisHandle.micStream.audio.audioData.offset + 16000; micOpen.wwEnd = aisHandle.micStream.audio.audioData.offset + audio_processing_get_wake_word_end(); micOpen.initiator = AIS_INITIATOR_WAKEWORD; AIS_EventMicrophoneOpened(&aisHandle, &micOpen); // We are now recording audio_processing_set_state(kWakeWordDetected); } } else { ux_attention_set_state(uxDisconnected); audio_processing_set_state(kReconnect); } taskNotification &= ~kWakeWordDetected; } .
.
.
if (kMicRecording & taskNotification) { // Set UX attention state and check if mute is active // so we don't confuse the user if (audio_processing_get_mic_mute()) { ux_attention_set_state(uxMicOntoOff); } else { ux_attention_set_state(uxListeningActive); } taskNotification &= ~kMicRecording; } .
.
.
Liste 5 : Dans l'application complète Alexa, la tâche d'application principale organise la séquence de traitement Alexa, notamment le contrôle des voyants LED conformément aux exigences de certification Alexa. (Source du code : NXP)
La routine principale dans l'application complète Alexa étend de la même manière le schéma illustré plus simplement dans l'application de circuit d'entrée audio. Dans ce cas, l'application principale crée également des tâches FreeRTOS supplémentaires pour une procédure d'initialisation plus importante, ainsi que des tâches pour gérer les boutons du kit et pour prendre en charge les mises à jour sans fil (OTA).
En se basant sur ces applications d'exemple, les développeurs peuvent implémenter en toute confiance les fonctionnalités Alexa Built-in à l'aide du SDK MCU Alexa Voice IoT de NXP dans leurs propres conceptions basées sur le microcontrôleur i.MX RT106A. Étant donné qu'elle tire pleinement parti d'AVS pour AWS IoT Core, cette plateforme d'exécution permet aux développeurs de déployer des solutions compatibles avec Alexa à plus grande échelle dans des dispositifs bon marché à ressources limitées qui constituent la base des applications IoT de plus en plus sophistiquées.
Conclusion
Alexa Voice Service d'Amazon permet aux développeurs d'implémenter les mêmes fonctionnalités d'assistant vocal que celles qui sont à l'origine de la croissance rapide des enceintes intelligentes Echo. Par le passé, les produits capables d'obtenir la certification Alexa Built-in tant convoitée nécessitaient des plateformes d'exécution avec une mémoire locale considérable et des capacités de traitement hautes performances. Conçu avec AVS pour AWS IoT Core, un kit de NXP fournit une solution clés en main pour les fonctionnalités Alexa Built-in grâce à un microcontrôleur et à un environnement d'exécution logicielle associé.
Avertissement : les opinions, convictions et points de vue exprimés par les divers auteurs et/ou participants au forum sur ce site Web ne reflètent pas nécessairement ceux de DigiKey ni les politiques officielles de la société.




