Implementare rapidamente i progetti IoT con "Alexa Built-In" utilizzando un kit basato su microcontroller

Gli assistenti vocali si sono evoluti rapidamente fino a diventare una funzione importante in qualsiasi prodotto intelligente. Tra le attuali soluzioni basate su cloud, si è imposto il servizio vocale Alexa Voice Service (AVS) di Amazon che fornisce una capacità chiavi in mano sfruttando le risorse cloud di Amazon per il riconoscimento vocale e l'elaborazione del linguaggio naturale.

Per gli sviluppatori, tuttavia, i requisiti prestazionali e la complessità di progettazione di AVS si sono dimostrati un ostacolo non da poco per poterlo introdurre in dispositivi più piccoli basati su microprocessore destinati alla casa connessa e all'Internet delle cose (IoT). Un kit di NXP Semiconductors, concepito come soluzione drop-in e progetto di riferimento per applicazioni personalizzate, fornisce un'offerta Amazon AVS studiata appositamente per dispositivi con risorse limitate.

Questo articolo mostra agli sviluppatori come possono implementare rapidamente progetti "Alexa Built-In" utilizzando una soluzione pronta per l'uso di NXP.

Cos'è la AVS?

La tecnologia degli assistenti vocali si è evoluta rapidamente, da quando ha fatto la sua comparsa una decina di anni fa, alimentando la crescita del mercato degli altoparlanti intelligenti che, secondo le stime degli analisti, interessa già circa un terzo della popolazione statunitense. Tra le soluzioni concorrenti, gli altoparlanti intelligenti Amazon Echo hanno conquistato una quota dominante, sfruttando il successo di Amazon Web Services (AWS) nel fornire risorse basate su cloud per supportare app Echo o Skill di terze parti.

Grazie ad Alexa Skills Kit (ASK) e alle relative interfacce di programmazione delle applicazioni (API), gli sviluppatori possono sfruttare la base installata in rapida espansione degli altoparlanti intelligenti Echo per aggiungere un certo livello di controllo vocale ai dispositivi collegati. Con questo approccio, prodotti connessi come i televisori intelligenti o i termostati compatibili con Alexa possono rispondere alle richieste vocali degli utenti e alle istruzioni ricevute dal cloud Alexa (Figura 1). In sintesi, questo è AVS e questo è il suo potenziale.

Figura 1: Costruendo app Alexa, o Skill, gli sviluppatori possono far sì che i prodotti connessi interagiscano con i comandi vocali degli utenti tramite i prodotti Amazon Echo. (Immagine per gentile concessione di Amazon Web Services)

Progetti Alexa Built-In

A differenza dei prodotti compatibili con Alexa, i prodotti intelligenti "Alexa Built-In" incorporano Alexa direttamente, sono dotati di un'interfaccia più fluida e a bassa latenza tra il dispositivo a controllo vocale Alexa e le risorse AWS. Questi prodotti integrano AVS direttamente nel progetto di un dispositivo connesso. Utilizzando AVS in combinazione con la piattaforma AWS IoT Core, gli sviluppatori possono implementare sofisticate applicazioni IoT che consentono agli utenti di utilizzare comandi vocali con prodotti abilitati per Alexa sia per controllare i dispositivi connessi sia per ricevere le loro risposte vocali (Figura 2).

Figura 2: I dispositivi abilitati per Alexa offrono agli utenti un'interfaccia vocale per controllare i dispositivi (in alto) o per ricevere notifiche dai dispositivi IoT (in basso) connessi alle risorse di Amazon Web Services attraverso AWS IoT Core. (Immagine per gentile concessione di Amazon Web Services)

In passato, tuttavia, i dispositivi abilitati per Alexa, che rappresentano il cuore di questo tipo di applicazione IoT, richiedevano già di per sé grandi sforzi di progettazione. Per utilizzare i servizi Alexa basati su cloud, per rilevare la parola di riattivazione, comunicare con il cloud Alexa ed elaborare le istruzioni per le funzionalità supportate, un dispositivo dovrebbe eseguire le numerose librerie di servizi AVS fornite attraverso il kit di sviluppo software (SDK) per dispositivi AVS in esecuzione su piattaforme Android o Linux (Figura 3).

Figura 3: Questo schema illustra i componenti di AVS Device SDK e i flussi di dati. (Immagine per gentile concessione di Amazon Web Services)

A supporto di queste librerie di servizi, per soddisfare le esigenze di elaborazione AVS i progetti di dispositivi abilitati per Alexa richiedono in genere un processore per applicazioni (AP) ad alte prestazioni e almeno 50 MB di memoria. Inoltre, questi progetti spesso dovrebbero avere un processore di segnali digitali (DSP) per eseguire i complessi algoritmi richiesti per estrarre l'audio vocale da ambienti rumorosi e supportare le capacità vocali far-field che ci si aspetta dagli assistenti vocali. Tutto sommato, i requisiti di sistema per la realizzazione di un dispositivo efficiente abilitato per Alexa sono andati in genere oltre il livello di costo e complessità necessario per dispositivi IoT pratici.

Con il rilascio dell'integrazione AVS per AWS IoT Core, tuttavia, Amazon ha ridotto drasticamente il carico di lavoro del processore e la memoria richiesta per implementare i prodotti Alexa Built-In. Con questo servizio, i compiti ad alta intensità di calcolo e di memoria vengono spostati dal dispositivo abilitato per Alexa a un dispositivo virtuale associato nel cloud (Figura 4).

Figura 4: AVS per AWS IoT Core sposta nel cloud le attività intensive di calcolo e memoria per consentire l'implementazione delle funzionalità dell'assistente vocale Alexa su dispositivi IoT con vincoli di risorse. (Immagine per gentile concessione di Amazon Web Services)

Le responsabilità di elaborazione del dispositivo fisico sono ridotte alla fornitura di servizi più basilari come la messaggistica sicura, la trasmissione affidabile dei dati audio da e verso Alexa, la gestione delle attività e le notifiche di eventi all'interno del dispositivo e con Alexa. Il trasferimento di dati, comandi e notifiche tra il dispositivo fisico e Alexa avviene attraverso un'efficiente messaggistica MQTT (MQ Telemetry Transport), tramite alcuni argomenti riservati nel protocollo MQTT publish-subscribe. Infine, un'applicazione mobile abbinata interagisce con il cloud Alexa per la registrazione del dispositivo e per qualsiasi ulteriore interazione dell'utente richiesta con il dispositivo abilitato per Alexa.

Spostando l'elaborazione pesante verso il cloud, AVS per AWS IoT Core consente di creare prodotti Alexa Built-In con piattaforme più familiari agli sviluppatori di sistemi embedded. Invece di processori di applicazioni con 50 MB di memoria in esecuzione su Linux o Android, gli sviluppatori possono implementare questi progetti con microcontroller più modesti con meno di 1 MB di RAM che eseguono il software del sistema operativo in tempo reale (RTOS). Di fatto, i progetti abilitati per Alexa realizzati con AVS per AWS IoT Core possono permettere di dimezzare la distinta base rispetto ai progetti realizzati per eseguire l'intera suite di servizi AVS a livello locale.

Sebbene AVS per AWS IoT Core supporti una piattaforma runtime più economica, l'implementazione di un prodotto certificato Alexa Built-in rimane un'impresa complessa. Gli sviluppatori che non conoscono AVS e IoT Core potrebbero dover affrontare un impegnativo percorso di apprendimento per venire a capo dei requisiti AWS in materia di sicurezza, comunicazioni, gestione degli account, progettazione dell'esperienza utente (UX) e molto altro ancora. Indipendentemente dalla loro familiarità con l'ecosistema AWS, perché i loro progetti ottengano la certificazione Amazon Alexa tutti gli sviluppatori di prodotti Alexa devono assicurare che soddisfino una lunga serie di specifiche e requisiti.

La soluzione per Alexa basata su microcontroller di NXP offre un'opzione per un sistema chiavi in mano che implementa tutti i requisiti hardware e software lato dispositivo per Amazon AVS per AWS IoT Core.

Soluzione per Alexa basata su microcontroller

Realizzato sulla base del microcontroller i.MX RT106A di NXP, il kit AVS SLN-ALEXA-IOT di NXP fornisce connettività AWS pronta per l'uso, algoritmi audio far-field qualificati AVS, cancellazione dell'eco, capacità di parola di riattivazione Alexa e codice applicativo. Basato su un core Arm Cortex-M7, il microcontroller i.MX RT106A del kit appartiene alla famiglia i.MX RT106x di NXP di processori crossover pensati espressamente per l'edge computing IoT. Concepito per applicazioni vocali embedded, RT106A aggiunge funzionalità al set completo di interfacce periferiche dell'architettura di base della famiglia di processori crossover i.MX RT1060 di NXP, ampia memoria interna e supporto esteso per opzioni di memoria esterna (Figura 5).

Figura 5: La famiglia di processori crossover i.MX RT1060 di NXP integra un core microcontroller Arm Cortex-M7 con un set completo di interfacce periferiche, memoria e altre capacità tipicamente richieste in un dispositivo IoT. (Immagine per gentile concessione di NXP)

Grazie alla sua funzionalità integrata, il microcontroller i.MX RT106A necessita solo di pochi altri componenti per assicurare la base hardware richiesta per implementare AVS per AWS IoT Core. Nel suo kit SLN-ALEXA-IOT, NXP integra il microcontroller i.MX RT106A in un modulo di sistema con 256 Mb di memoria flash, il modulo transceiver Wi-Fi/Bluetooth LBEE5KL1DX di Murata Electronics e il convertitore buck AP2202K-3.3TRG1 di Diodes (Figura 6).

Figura 6: Il progetto del modulo di sistema del kit AVS SLN-ALEXA-IOT di NXP sfrutta la semplice interfaccia hardware richiesta per integrare il microcontroller i.MX RT106A di NXP con la flash esterna e un transceiver wireless. (Immagine per gentile concessione di NXP)

A corredo di questo modulo di sistema, una scheda vocale nel kit SLN-ALEXA-IOT offre tre microfoni MEMS PDM (modulazione a densità di impulsi) SPH0641LM4H-1 di Knowles, un altoparlante AS01808AO di PUI Audio e un amplificatore audio di classe D TFA9894D di NXP. Oltre a un connettore USB Type-C per l'alimentazione del kit e per l'esecuzione di una console di shell da un PC, la scheda vocale fornisce basette per Ethernet, periferiche seriali e ingresso/uscita per uso generale (GPIO) per microcontroller i.MX RT106A. La scheda include anche interruttori per l'ingresso di controllo di base e LED per il riscontro visivo conformi ai requisiti di Amazon AVS UX Attention System utilizzando diversi colori di LED e modelli di cicli di accensione/spegnimento.

Con il modulo di sistema e la scheda vocale, l'hardware SLN-ALEXA-IOT è una piattaforma completa per l'elaborazione lato dispositivo del software per AVS per AWS IoT Core. Come osservato in precedenza, tuttavia, i progetti di dispositivi IoT abilitati per Alexa dipendono dall'ottimizzazione del software e dell'hardware. Creare il software da zero con l'API di Amazon AVS per AWS IoT può ritardare moltissimo i progetti perché gli sviluppatori devono costruire i vari oggetti dati richiesti e implementare i relativi protocolli. Se poi devono assicurare la certificazione Alexa Built-in, conformarsi ad AVS UX Attention System, alle pratiche di sicurezza AWS e ad altri requisiti che interessano ogni aspetto delle interazioni degli utenti con i servizi Alexa, i tempi possono allungarsi ulteriormente. NXP risolve questi problemi con il completo ambiente software di controllo vocale runtime basato su Amazon FreeRTOS costruito su uno strato di driver software per flash XIP (Execute-In-Place), connettività e altri componenti hardware (Figura 7).

Figura 7: Realizzato sulla base di Amazon FreeRTOS, l'ambiente del sistema di controllo vocale di NXP offre una nutrita serie di servizi middleware, comprese routine firmware per l'inferenza di apprendimento automatico e l'elaborazione audio front-end. (Immagine per gentile concessione di NXP)

Alla base delle capacità di elaborazione vocale di questo ambiente software, il firmware Intelligent Toolbox di NXP fornisce funzioni ottimizzate per tutte le attività audio, compreso il motore di inferenza di apprendimento automatico (ML) e il front-end audio ML per il condizionamento e l'ottimizzazione dei segnali audio. Altri servizi middleware supportano la connettività sicura, le comunicazioni AWS e le capacità audio. Al di sopra di questo livello di servizio completo, il software per AWS IoT Core, l'onboarding e altre funzionalità di controllo dell'applicazione mediano l'avvio da un bootloader a due stadi con supporto per aggiornamenti via etere (OTA) basati sul servizio OTA AWS IoT e sul client OTA Amazon FreeRTOS.

Utilizzando il software installato in fabbrica in esecuzione in questo ambiente, gli sviluppatori possono realizzare immediatamente il kit hardware SLN-ALEXA-IOT con un'applicazione completa abilitata per Alexa, progettata per utilizzare un account dimostrativo NXP per AWS IoT. La documentazione di NXP offre un percorso dettagliato che descrive il processo di realizzazione del kit, il provisioning delle credenziali Wi-Fi e il completamento dell'autenticazione del dispositivo AWS con l'account dimostrativo. Come parte di questo processo, gli sviluppatori interagiscono con il kit e AWS utilizzando un'applicazione mobile Android inclusa nel pacchetto di distribuzione del software, disponibile sul sito di NXP tramite un codice di attivazione in dotazione con ogni kit SLN-ALEXA-IOT. Dopo alcune semplici azioni, possono iniziare immediatamente a interagire con il kit tramite lo stesso tipo di interazioni vocali Alexa fornite dagli altoparlanti intelligenti Echo.

Il kit SLN-ALEXA-IOT e il software installato in fabbrica offrono una piattaforma pronta per prototipare rapidamente prodotti con capacità Alexa. Allo stesso tempo, l'hardware e il software del kit servono da piattaforma di sviluppo rapido per realizzare progetti personalizzati abilitati per Alexa basati sul microcontroller i.MX RT106A.

Sviluppo personalizzato

Il software per soluzioni Alexa basate su i.MX RT106A sfrutta le capacità dell'ambiente runtime di controllo vocale di NXP tramite l'SDK basato su MCU di NXP per Alexa Voice IoT fornito come parte del pacchetto di distribuzione software disponibile all'attivazione del prodotto. Progettato come add-on dell'ambiente di sviluppo integrato (IDE) MCUXpresso basato su Eclipse di NXP, questo SDK combina il codice sorgente completo per applicazioni, driver e middleware di esempio con intestazioni per distribuzioni binarie di funzionalità firmware specializzate come l'Intelligent Toolbox di NXP, il motore di inferenza ML e il front-end audio ML.

Gli sviluppatori che devono implementare rapidamente un prodotto abilitato per Alexa, in linea di massima possono utilizzare l'applicazione dimostrativa completa Alexa apportando solo lievi modifiche. Nel caso più semplice, queste modifiche non farebbero altro che reindirizzare l'applicazione sull'account AWS dello sviluppatore utilizzando le sue credenziali di sicurezza. NXP fornisce una descrizione passo-passo per completare questo processo.

Per lo sviluppo personalizzato, le applicazioni incluse nella distribuzione del software forniscono esempi di eseguibili che mostrano come lavorare con l'SDK basato su MCU di NXP per Alexa Voice IoT. Invece di passare direttamente all'applicazione dimostrativa completa di Alexa, gli sviluppatori possono esplorare applicazioni di esempio che permettono loro di concentrarsi maggiormente su capacità specifiche, tra cui il front-end audio, la connettività Wi-Fi e Bluetooth, il bootloading e altre. Ad esempio, l'applicazione audio front-end illustra i modelli di progettazione di base per eseguire il rilevamento delle parole di riattivazione utilizzando i task di Amazon FreeRTOS.

Nell'applicazione di esempio audio front-end, la routine principale dimostra come gli sviluppatori dovrebbero inizializzare i sottosistemi hardware e software e usare poi la funzione FreeRTOS xTaskCreate per lanciare il task dell'applicazione principale (appTask) e un task shell della console (sln_shell_task) prima di rilasciare il controllo allo scheduler FreeRTOS (Listato 1). (Nota: la chiamata vTaskStartScheduler per avviare lo scheduler FreeRTOS ritornerà solo se lo scheduler non ha memoria sufficiente).

Copy
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();
.
.
.
}

Listato 1: Un'applicazione audio front-end di esempio inclusa nella distribuzione SDK basata su MCU di NXP per Alexa Voice IoT dimostra i requisiti di base per inizializzare e creare task FreeRTOS per il task dell'applicazione principale e un task shell della console. (Codice per gentile concessione di NXP)

Dopo aver inizializzato il sottosistema audio, il task dell'applicazione principale appTask lancia a sua volta una coppia di task FreeRTOS. Uno esegue una routine di servizio, audio_processing_task, che elabora l'ingresso audio, mentre l'altro gestisce la conversione dell'uscita del microfono PDM in modulazione impulso/codice (PCM). Dopo un'ulteriore gestione interna, appTask si inserisce in un loop infinito, in attesa della notifica RTOS che la parola di riattivazione è stata rilevata (Listato 2).

Copy
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;
    }
}

Listato 2: Nell'applicazione audio front-end di esempio, il task dell'applicazione principale, appTask, avvia i task per gestire l'elaborazione audio e la conversione dei dati del microfono, dopodiché attende la notifica FreeRTOS (taskNotification) che la parola di riattivazione è stata rilevata (kWakeWordDetected). (Codice per gentile concessione di NXP)

Da parte sua, il task di elaborazione audio in questa applicazione di esempio inizializza la funzione firmware parola di riattivazione e inizializza i parametri di rilevamento di tale parola prima che entri in un loop infinito in cui attende una notifica FreeRTOS dal task di conversione dati del microfono che confermi la disponibilità di tali dati elaborati. A quel punto, il task di elaborazione audio richiama le funzioni del firmware Intelligent Toolbox che elaborano i dati audio ed eseguono il rilevamento della parola di riattivazione con il motore di inferenza ML (Listato 3).

Copy
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);
        }
    }
}

Listato3: Nell'applicazione audio front-end di esempio, il task di elaborazione audio inizializza il motore delle parole di riattivazione del firmware, aspetta la notifica FreeRTOS che i dati del microfono sono disponibili e infine richiama il front-end analogico del firmware NXP Intelligent Toolbox.(SLN_Voice_Process_Audio) e il motore di interferenza ML (SLN_AMAZON_WAKE_ProcessWakeWord) per il rilevamento della parola di riattivazione. (Codice per gentile concessione di NXP)

Dopo il rilevamento della parola di riattivazione, il task di elaborazione audio emette una notifica di task FreeRTOS per notificare quell'evento al task dell'applicazione principale appTask. Quando riceve la notifica, appTask fa lampeggiare momentaneamente un LED di colore blu (vedere di nuovo il Listato 2).

L'intera l'applicazione di esempio Alexa si basa sugli stessi modelli descritti per la più semplice applicazione audio front-end, ma estende sostanzialmente quella base di codice di base per supportare tutte le funzionalità di Alexa. Ad esempio, dopo che il motore di inferenza ML rileva la parola di riattivazione nell'applicazione di esempio Alexa, il task di elaborazione audio esegue una serie di notifiche FreeRTOS associate a ogni fase della sequenza di elaborazione Alexa (Listato 4).

Copy
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);
.
.
.
    }
}

Listato 4: Nell'applicazione Alexa completa, il task di elaborazione audio aumenta le fasi di elaborazione eseguite nell'applicazione audio front-end aggiungendo il codice per la gestione delle successive fasi di elaborazione audio nella sequenza Alexa. (Codice per gentile concessione di NXP)

Dopo il rilevamento locale della parola di riattivazione ML, il task di elaborazione audio dell'intera applicazione Alexa notifica il task dell'applicazione principale come descritto in precedenza. Inoltre, ora deve gestire gli stati di elaborazione audio in cui il microfono rimane aperto per acquisire l'intero ingresso audio per l'elaborazione vocale nel cloud Alexa senza perdere il flusso di dati originale che contiene la parola di riattivazione rilevata localmente. Questo intero flusso di dati viene trasmesso al cloud Alexa per la verifica della parola di riattivazione e per un'ulteriore elaborazione vocale.

In ogni fase di questa sequenza di elaborazione, il task di elaborazione audio emette le notifiche FreeRTOS corrispondenti al task dell'applicazione principale. Come per il task di elaborazione audio, l'applicazione completa Alexa estende il modello di task dell'applicazione principale presentato in forma più semplice nell'applicazione audio front-end. Qui, il task dell'applicazione principale completa Alexa, appTask, genera sia eventi per la trasmissione al cloud Alexa che per la gestione dei LED del kit in conformità con i requisiti di Amazon AVS UX Attention System. Ad esempio, quando si tiene aperto il microfono dopo il rilevamento della parola di riattivazione, il task di elaborazione audio notifica il task dell'applicazione principale, che imposta lo stato di attenzione UX appropriato (indicatore LED ciano fisso). Vedere nuovamente le evidenziazioni gialle nel Listato 5 e la corrispondente evidenziazione nel Listato 4.

Copy
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;
        }
.
.
.

Listato 5: Nell'applicazione Alexa completa, il task dell'applicazione principale orchestra la sequenza di elaborazione di Alexa, compreso il controllo delle luci LED in conformità con i requisiti di certificazione Alexa. (Codice per gentile concessione di NXP)

La routine principale nell'applicazione Alexa completa estende analogamente il modello dimostrato in forma più semplice nell'applicazione audio front-end. In questo caso, l'applicazione principale crea anche ulteriori task FreeRTOS per una procedura di inizializzazione più sostanziosa, oltre a task per gestire i pulsanti del kit e supportare gli aggiornamenti OTA.

Basandosi su queste applicazioni di esempio, gli sviluppatori possono implementare con sicurezza le funzionalità Alexa Built-in utilizzando l'SDK basato su MCU di NXP per Alexa Voice IoT nei progetti basati su i.MX RT106A. Sfruttando pienamente i vantaggi di AVS per AWS IoT Core, questa piattaforma di esecuzione consente di implementare soluzioni abilitate per Alexa in un maggior numero di dispositivi a basso costo e con risorse limitate, che stanno alla base di applicazioni IoT sempre più sofisticate.

Conclusione

Amazon Alexa Voice Service ha permesso agli sviluppatori di implementare la stessa funzionalità di assistente vocale che sta alimentando la rapida crescita degli altoparlanti intelligenti Echo. In passato, i prodotti in grado di ottenere l'ambita certificazione Alexa Built-in richiedevano piattaforme di esecuzione con grande memoria locale e capacità di elaborazione ad alte prestazioni. Un kit di NXP, costruito con AVS per AWS IoT Core, fornisce una soluzione drop-in per la funzionalità Alexa Built-in utilizzando un microcontroller e il relativo ambiente di esecuzione software.