Szybka implementacja projektów IoT „Alexa Built-In” z użyciem zestawu na bazie mikrokontrolera

Asystenty głosowe ewoluują w szybkim tempie i stały się ważną funkcją wszelkich produktów inteligentnych. Wśród obecnych rozwiązań opartych na chmurze, Alexa Voice Service (AVS) firmy Amazon stała się dominującym asystentem głosowym, zapewniającym gotowe rozwiązania, które wykorzystują zasoby chmury Amazon do rozpoznawania głosu i przetwarzania języka naturalnego.

Jednak dla deweloperów, wymagania związane z wydajnością i złożoność projektu w przypadku AVS okazały się sporą barierą, utrudniającą zastosowanie tej usługi w mniejszych urządzeniach opartych na mikroprocesorach stosowanych w łączności domów i Internecie rzeczy (IoT). Zaprojektowany jako rozwiązanie typu „drop-in” i projekt referencyjny dla niestandardowych aplikacji, zestaw firmy NXP Semiconductors zawiera usługę Amazon AVS zaprojektowaną specjalnie dla urządzeń o ograniczonych zasobach.

W niniejszym artykule zaprezentowano jak deweloperzy mogą szybko wdrożyć projekty „Alexa Built-in” przy użyciu niestandardowego rozwiązania firmy NXP.

Czym jest usługa AVS?

Od momentu pojawienia się na rynku dziesięć lat temu technologia asystentów głosowych szybko ewoluowała, napędzając rozwijający się rynek inteligentnych głośników, który według szacunków analityków obejmuje około jednej trzeciej populacji USA. Istnieje wiele konkurencyjnych rozwiązań, a wśród nich dominują inteligentne głośniki Amazon Echo, wykorzystując sukces Amazon Web Services (AWS) w dostarczaniu zasobów opartych na chmurze do obsługi aplikacji Echo innych firm, czyli tzw. Skills.

Korzystając z zestawu Alexa Skills Kit (ASK) i powiązanych z nim interfejsów programowania aplikacji (API), deweloperzy mogą skorzystać z szybko rozwijającej się bazy inteligentnych głośników Echo, aby na pewnym poziomie dodać możliwość sterowania głosem do podłączonych urządzeń. Dzięki takiemu podejściu połączone urządzenia, takie jak inteligentne telewizory lub termostaty, które współpracują technologią Alexa (certyfikat „Works with Alexa”), mogą reagować na polecenia głosowe wydawane użytkowników i wykonywać je zgodnie z powiązanymi z poleceniami instrukcjami otrzymywanymi z chmury Alexa (ilustracja 1). Ten przykład podsumowuje mechanizm działania AVS i naświetla potencjał tej usługi.

Ilustracja 1: budując aplikacje w technologii Alexa, czyli Skills, deweloperzy mogą umożliwić podłączonym urządzeniom interakcję z poleceniami wydawanymi przez użytkowników za pośrednictwem produktów Amazon Echo. (Źródło ilustracji: Amazon Web Services)

Projekt Alexa Built-in

W przeciwieństwie do urządzeń współpracujących z technologią Alexa, inteligentne urządzenia „Alexa Built-in” osiągają większą płynność interfejsu i charakteryzują się mniejszymi opóźnieniami pomiędzy urządzeniem Alexa obsługującym głos i zasobami AWS. Produkty te integrują AVS bezpośrednio z konstrukcją podłączonego urządzenia. Wykorzystując usługę AVS w połączeniu z platformą AWS IoT Core, deweloperzy mogą wdrażać zaawansowane aplikacje IoT, które pozwalają użytkownikom na wydawanie poleceń głosowych urządzeniom współpracującym z technologią Alexa zarówno, by sterować podłączonymi urządzeniami, jak odbierać odpowiedzi głosowe z tych urządzeń (ilustracja 2).

Ilustracja 2: urządzenia współpracujące z technologią Alexa zapewniają użytkownikom interfejs głosowy do sterowania urządzeniami (góra) lub odbierania powiadomień z urządzeń IoT (dół) podłączonych do zasobów Amazon Web Services poprzez AWS IoT Core. (Źródło ilustracji: Amazon Web Services)

W przeszłości jednak projekty urządzeń wykorzystujących technologię Alexa, będących sercem tego rodzaju aplikacji IoT, wymagały dużego wysiłku projektowego. Aby korzystać z usług technologii Alexa w chmurze, urządzenie musiałoby uruchomić wiele bibliotek usług AVS dostarczanych za pośrednictwem zestawu SDK (Software Development Kit) działającego na platformach Android lub Linux, aby wykryć odpowiednie słowo, komunikować się z chmurą Alexa i przetwarzać instrukcje dotyczące obsługiwanych funkcji (ilustracja 3).

Ilustracja 3: schemat przedstawia elementy zestawu AVS Device SDK i przepływ danych pomiędzy nimi. (Źródło ilustracji: Amazon Web Services)

Aby obsługiwać te biblioteki usług, urządzenia współpracujące z technologią Alexa wymagają zazwyczaj wysokowydajnego procesora aplikacji i co najmniej 50MB (megabajtów) pamięci w celu spełnienia wymagań przetwarzania AVS. Ponadto konstrukcje te często zawierają procesor sygnału cyfrowego (DSP) do realizacji złożonych algorytmów wymaganych do wydobywania głosu z dźwięków otoczenia oraz do obsługi poleceń głosowych wydawanych z odległości, czyli właśnie funkcji, których oczekuje się od asystentów głosowych. Ostatecznie wymagania systemowe budowy efektywnego urządzenia współpracującego z technologią Alexa znacznie przekroczyły poziom kosztów i złożoności praktycznych urządzeń IoT.

Wraz z premierą AVS Integration dla AWS IoT Core, firmie Amazon udało się znacznie zmniejszyć obciążenie procesora i ilość pamięci potrzebnej do wdrożenia „Alexa Built-in” do urządzeń. Dzięki tej usłudze obliczenia wymagające dużej ilości pamięci są przenoszone z urządzenia współpracującego z technologią Alexa na powiązane z nim urządzenie wirtualne w chmurze (ilustracja 4).

Ilustracja 4: AVS dla AWS IoT Core przekierowuje zadania wymagające intensywnych obliczeń i pamięci do chmury, aby umożliwić wdrożenie funkcji asystenta głosowego Alexa na urządzeniach IoT o ograniczonych zasobach. (Źródło ilustracji: Amazon Web Services)

Odpowiedzialność za przetwarzanie danych w urządzeniu fizycznym jest ograniczona do bardziej podstawowych usług, takich jak bezpieczne wysyłanie wiadomości, niezawodne dostarczanie danych audio do systemu Alexa i wysyłanie ich z niego, zarządzanie zadaniami i powiadomienia o zdarzeniach w urządzeniu i w technologii Alexa. Przesyłanie danych, poleceń i powiadomień pomiędzy fizycznym urządzeniem a technologią Alexa odbywa się za pomocą wydajnego systemu przesyłania wiadomości MQTT (MQ Telemetry Transport), przy użyciu kilku zasubskrybowanych tematów w protokole MQTT publish-subscribe. Wreszcie, towarzysząca aplikacja mobilna wchodzi w interakcję z chmurą Alexa w celu rejestracji urządzenia i wykonania wszelkich dodatkowych wymaganych interakcji użytkownika z urządzeniem współpracującym z technologią Alexa.

Dzięki przeniesieniu dużych zadań obliczeniowych do chmury, AVS dla AWS IoT Core umożliwia deweloperom stworzenie produktów „Alexa Built-in” z platformami, które deweloperzy systemów wbudowanych znają lepiej. Zamiast procesorów aplikacji z 50MB pamięci działających w systemie Linux lub Android deweloperzy mogą wdrażać te projekty za pomocą skromniejszych mikrokontrolerów pamięcią RAM poniżej 1MB działającą w systemie operacyjnym czasu rzeczywistego (RTOS). Co więcej, urządzenia współpracujące z technologią Alexa z AVS dla AWS IoT Core może zmniejszyć wykaz materiałów o 50% w porównaniu z projektami przygotowanymi do lokalnego uruchomienia pełnej usługi AVS.

Chociaż AVS dla AWS IoT Core obsługuje bardziej ekonomiczną platformę wykonawczą, wdrożenie certyfikowanego produktu „Alexa Built-in” nadal pozostaje złożonym przedsięwzięciem. Deweloperzy, którzy nie mają doświadczenia w AVS i IoT Core muszą zmierzyć się z trudnym procesem uczenia się pracy, ze względu na określone wymagania AWS względem bezpieczeństwa, łączności, zarządzania kontem, projektowania UX i wielu innych kwestii. Niezależnie od znajomości ekosystemu AWS, wszyscy deweloperzy produktów Alexa muszą zadbać o to, by ich projekty spełniały długą listę specyfikacji i wymagań koniecznych do uzyskania certyfikatu Amazon Alexa.

Rozwiązanie firmy NXP oparte na mikrokontrolerze dla technologii Alexa stanowi gotowe rozwiązanie systemowe, które w pełni realizuje wymagania sprzętowe i programowe Amazon AVS dla AWS IoT Core.

Rozwiązanie dla technologii Alexa oparte na mikrokontrolerze

Zestaw AVS SLN-ALEXA-IOT firmy NXP, zbudowany na bazie mikrokontrolera i.MX RT106A tej samej firmy, zapewnia niestandardową łączność AWS, algorytmy dalekiego pola akustycznego kwalifikowane przez AVS, usuwanie echa, funkcję „słowa budzącego aplikację” Alexa („Wake Word”) i kod aplikacji. Mikrokontroler i.MX RT106A, oparty na rdzeniu Cortex-M7 Arm, należy do serii procesorów crossover i.MX RT106x firmy NXP, zaprojektowanych specjalnie z myślą o systemach przetwarzania brzegowego IoT. Model RT106A, stworzony z myślą o wbudowanych aplikacjach głosowych, wzbogaca w podstawowej architekturze procesorów crossover i.MX RT1060 firmy NXP złożony zestaw interfejsów peryferyjnych, bogatą pamięć wewnętrzną oraz szeroką obsługę opcji pamięci zewnętrznej o specjalistyczne funkcje (ilustracja 5).

Ilustracja 5: grupa procesorów crossover i.MX RT1060 firmy NXP integruje rdzeń mikrokontrolera Arm Cortex-M7 z pełnym zestawem interfejsów peryferyjnych, pamięcią i innymi funkcjami wymaganymi zwyczajowo w urządzeniu IoT. (Źródło obrazu: NXP)

Dzięki zintegrowanej funkcjonalności mikrokontroler i.MX RT106A potrzebuje tylko kilku dodatkowych komponentów, aby zapewnić podstawę sprzętową niezbędną do wdrożenia AVS dla AWS IoT Core. W zestawie SLN-ALEXA-IOT firma NXP integruje mikrokontroler i.MX RT106A z modułem systemowym z 256-megabitową pamięcią flash (Mb), modułem nadawczo-odbiorczym Wi-Fi/Bluetooth LBEE5KL1DX firmy Murata Electronics oraz przetwornicą obniżająca napięcie AP2202K-3.3TRG1 firmy Diodes (ilustracja 6).

Ilustracja 6: w projekcie modułu systemowego AVS zestawu SLN-ALEXA-IOT firmy NXP wykorzystano prosty interfejs sprzętowy niezbędny do integracji mikrokontrolera i.MX RT106A firmy NXP z zewnętrzną pamięcią flash i bezprzewodowym nadajniko-odbiornikiem. (Źródło obrazu: NXP)

Uzupełnieniem tego modułu systemowego jest płyta głosowa, która w zestawie SLN-ALEXA-IOT zawiera trzy mikrofony MEMS z modulacją gęstości impulsów (PDM) SPH0641LM4H-1 firmy Knowles, głośnik AS01808AO firmy PUI Audio oraz wzmacniacz audio klasy D TFA9894D firmy NXP. Wraz ze złączem USB typu C do zasilania zestawu oraz do uruchamiania konsoli powłoki systemowej z komputera osobistego, płyta głosowa posiada listwy umożliwiające podłączenie Ethernetu, wejście-wyjście ogólnego przeznaczenia (GPIO) mikrokontrolera i.MX RT106A oraz szeregowe podłączenie urządzeń peryferyjnych. Płyta zawiera również przełączniki dla podstawowej kontroli wejścia, jak również diody LED dla wizualnego sprzężenia zwrotnego zgodnego z wymaganiami Amazon AVS UX Attention System przy użyciu różnych kolorów LED i wzorów włączania/wyłączania cyklu.

Dzięki modułowi systemowemu i płycie głosowej, sprzęt SLN-ALEXA-IOT stanowi kompletną platformę do przetwarzania AVS po stronie urządzenia dla oprogramowania AWS IoT Core. Jak jednak zauważono wcześniej, sukces projektów urządzeń IoT współpracujących z technologią Alexa zależy w takim samym stopniu od zoptymalizowanego oprogramowania, jak od sprzętu. Tworzenie tego oprogramowania od podstaw za pomocą Amazon AVS dla AWS IoT API może znacząco opóźnić proces projektowania, ponieważ deweloperzy będą pracować nad budową wymaganych obiektów danych i implementacją związanych z nimi protokołów. Dalsze opóźnienia mogą wystąpić, gdy deweloperzy, którzy pracują nad uzyskaniem certyfikatu „Alexa Built-in”, starają się przestrzegać wymagań AVS UX Attention System, praktyk bezpieczeństwa AWS i innych wymagań projektowych obejmujących każdy aspekt interakcji użytkowników z usługą Alexa. Firma NXP rozwiązuje te problemy dzięki wszechstronnemu środowisku oprogramowania wykonawczego do sterowania głosem w czasie rzeczywistym opartemu na systemie Amazon FreeRTOS, zbudowanemu na warstwie sterowników programowych dla układu flash typu „execute-in-place” (XIP), łączności i innych komponentach sprzętowych (ilustracja 7).

Ilustracja 7: środowisko do sterowania głosem firmy NXP oparte na systemie Amazon FreeRTOS zapewnia szeroki zestaw usług oprogramowania pośredniczącego, w tym procedury oprogramowania układowego do uczenia maszynowego i przetwarzania dźwięku na poziomie front-endu. (Źródło obrazu: NXP)

Oprogramowanie układowe Intelligent Toolbox firmy NXP, stanowiące podstawę funkcji przetwarzania głosu w tym środowisku, zapewnia optymalizację wszystkich zadań związanych z dźwiękiem, w tym mechanizmu uczenia maszynowego (ML) oraz audio ML na poziomie front-endu w celu kondycjonowania i optymalizacji sygnału audio. Inne usługi z zakresu oprogramowania pośredniczącego mają na celu zapewnienie bezpiecznej łączności, komunikacji AWS i funkcji audio. Ponad warstwą kompleksowych usług, w uruchomieniu z dwustopniowego programu ładującego z obsługą bezprzewodowych aktualizacji (OTA - over the air) opartego na usłudze OTA dla AWS IoT i kliencie OTA dla Amazon FreeRTOS pośredniczy oprogramowanie dla AWS IoT Core, onboarding i inne funkcje sterowania aplikacją.

Korzystając z fabrycznie zainstalowanego oprogramowania działającego w tym środowisku, deweloperzy mogą od razu zastosować zestaw sprzętowy SLN-ALEXA-IOT z kompletną aplikacją współpracującą z technologią Alexa, przeznaczoną do wykorzystania konta demonstracyjnego firmy NXP dla AWS IoT. Dokumentacja firmy NXP zawiera szczegółowy opis procesu stosowania zestawu, udostępniania danych uwierzytelniających Wi-Fi oraz uzupełniania uwierzytelniania urządzeń AWS za pomocą konta demonstracyjnego. W ramach tego procesu deweloperzy pracują z zestawem i AWS za pomocą aplikacji mobilnej dla systemu Android zawartej w pakiecie dystrybucyjnym oprogramowania, który można uzyskać z witryny firmy NXP po podaniu kodu aktywacyjnego dostarczanego z każdym zestawem SLN-ALEXA-IOT. Po wykonaniu kilku prostych kroków deweloperzy mogą natychmiast rozpocząć interakcję z zestawem poprzez ten sam rodzaj interakcji głosowych Alexa, które zapewniają inteligentne głośniki Echo.

Zestaw SLN-ALEXA-IOT i fabrycznie zainstalowane oprogramowanie zapewniają gotową platformę umożliwiającą szybkie prototypowanie produktów z funkcjami technologii Alexa. Jednocześnie sprzęt i oprogramowanie zestawu służą jako platforma rozwojowa do szybkiego tworzenia niestandardowych projektów współpracujących z technologią Alexa, opartych na mikrokontrolerze i.MX RT106A.

Niestandardowy rozwój

Oprogramowanie dla rozwiązań w technologii Alexa opartych na mikrokontolerach i.MX RT106A wykorzystuje możliwości środowiska sterowania głosem firmy NXP poprzez zestaw rozwojowy oprogramowania (SDK) MCU Alexa Voice IoT firmy NXP, który jest częścią pakietu dystrybucyjnego oprogramowania dostępnego po aktywacji produktu. Zaprojektowany jako dodatek do zintegrowanego środowiska programistycznego MCUXpresso firmy NXP opartego na Eclipse (IDE), SDK łączy pełny kod źródłowy przykładowych aplikacji, sterowników i oprogramowania pośredniczącego z nagłówkami dla binarnych dystrybucji specjalistycznego oprogramowania sprzętowego, takich jak Intelligent Toolbox firmy NXP, silnik inferencyjny mechanizmu uczenia maszynowego i audio ML na poziomie front-endu.

Deweloperzy, którzy muszą szybko wdrożyć produkt współpracujący z technologią Alexa, mogą w zasadzie korzystać z pełnej aplikacji demonstracyjnej Alexa z niewielkimi modyfikacjami. W najprostszym przypadku modyfikacje polegają po prostu na przekierowaniu aplikacji na konto AWS dewelopera przy użyciu własnych danych uwierzytelniających. Firma NXP udostępnia opis poszczególnych etapów realizacji tego procesu.

Jeśli chodzi o niestandardowy rozwój, aplikacje demonstracyjne w ramach dystrybucji oprogramowania zawierają działające przykłady, pokazujące, jak współpracować z SDK MCU Alexa Voice IoT firmy NXP. Zamiast bezpośrednio skoczyć na głęboką wodę pełnej aplikacji demonstracyjnej w technologii Alexa, deweloperzy mogą badać aplikacje demonstracyjne, które pozwalają im lepiej skupić się na konkretnych możliwościach, w tym na audio na poziomie front-endu, łączności Wi-Fi i Bluetooth, ładowaniu aplikacji i innych. Przykładowa aplikacja audio front-end ilustruje podstawowe wzorce projektowe do wykrywania odpowiednich „słów budzących aplikację” za pomocą zadań Amazon FreeRTOS.

W przykładowej aplikacji audio, główna procedura pokazuje, jak deweloperzy inicjują podsystemy sprzętowe i programowe, a następnie używają funkcji FreeRTOS xTaskCreate do uruchomienia głównego zadania aplikacji (appTask) i zadania konsoli powłoki systemowej (sln_shell_task) przed uwolnieniem sterowania do harmonogramu FreeRTOS (listing 1). (Wskazówka: wywołanie vTaskStartScheduler do uruchomienia harmonogramu FreeRTOS powróci tylko wtedy, gdy harmonogramowi zabraknie pamięci).

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

Listing 1: dołączona do dystrybucji SDK MCU Alexa Voice IoT firmy NXP przykładowa aplikacja audio front-end demonstruje podstawowe wymagania w zakresie inicjalizacji i tworzenia zadań FreeRTOS dla głównego zadania aplikacji oraz zadania konsoli powłoki systemowej. (Źródło kodu: NXP)

Po zainicjowaniu podsystemu audio, główne zadanie aplikacji appTask z kolei uruchamia parę zadań FreeRTOS. Jedno zadanie wykonuje rutynowe procesy obsługi - audio_processing_task, które przetwarza dane audio na wejściu - a drugie zajmuje się konwersją danych na wyjściu mikrofonu PDM na modulację impulsowo-kodową (PCM). Po przeprowadzeniu dodatkowych procesów utrzymania systemu, appTask osadza się w niekończącej się pętli, czekając na powiadomienie RTOS sygnalizujące wykrycie „słowa budzącego” (listing 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;
    }
}

Listing 2: w przykładowej aplikacji audio front-end, główne zadanie aplikacji - appTask - uruchamia zadania do obsługi przetwarzania dźwięku i konwersji danych z mikrofonu, a następnie czeka na powiadomienie FreeRTOS taskNotification) o wykryciu „słowa budzącego” (kWakeWordDetected). (Źródło kodu: NXP)

Z kolei zadanie przetwarzania dźwięku w tej przykładowej aplikacji inicjuje funkcję „słowa budzącego” w oprogramowaniu układowym i inicjuje parametry wykrywania odpowiedniego słowa, zanim ono również wejdzie w niekończącą się pętlę, w której czeka na powiadomienie FreeRTOS od zadania konwersji danych z mikrofonu, że przetworzone dane z mikrofonu są dostępne. W tym momencie zadanie przetwarzania dźwięku wywołuje funkcje oprogramowania układowego Intelligent Toolbox, które przetwarzają dane audio i wykrywają „słowa budzące” za pomocą silnika inferencyjnego ML (listing 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);
        }
    }
}

Listing 3: w przykładowej aplikacji audio front-end zadanie przetwarzania dźwięku inicjuje silnik „słowa budzącego aplikację” w oprogramowaniu układowym, czeka na powiadomienie FreeRTOS o dostępności danych z mikrofonu i na koniec wywołuje analogowy front end oprogramowania układowego Intelligent Toolbox firmy NXP (SLN_Voice_Process_Audio) i silnik inferencyjny ML (SLN_AMAZON_WAKE_ProcessWakeWord) do wykrywania „słów budzących aplikację”. (Źródło kodu: NXP)

Po wykryciu „słowa budzącego” zadanie przetwarzania dźwięku wysyła powiadomienie o zdarzeniu w postaci zadania FreeRTOS, aby powiadomić o nim główną aplikację, appTask. Po otrzymaniu tego powiadomienia appTask chwilowo miga niebieską kolorową diodą LED (patrz listing 2).

Kompletna przykładowa aplikacja Alexa opiera się na tych samych wzorcach co w prostszej aplikacji audio front-end, ale znacznie rozszerza podstawową bazę kodu do obsługi pełnej funkcjonalności technologii Alexa. Na przykład, po wykryciu przez silnik inferencyjny ML „słowa budzącego” w przykładowej aplikacji Alexa, zadanie przetwarzania dźwięku wysyła serię powiadomień FreeRTOS związanych z każdym etapem sekwencji przetwarzania Alexa (listing 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);
.
.
.
    }
}

Listing 4: w pełnej aplikacji Alexa zadanie przetwarzania dźwięku pomnaża kroki przetwarzania wykonywane w aplikacji audio front-end o dodatkowy kod zarządzający kolejnymi etapami przetwarzania dźwięku w sekwencji technologii Alexa. (Źródło kodu: NXP)

Gdy lokalny mechanizm ML wykryje „słowo budzące”, zadanie przetwarzania dźwięku pełnej aplikacji Alexa powiadamia główne zadanie aplikacji, jak opisano powyżej. Ponadto, teraz musi zarządzać stanami przetwarzania dźwięku, w których mikrofon jest uruchomiony, by przechwycić kompletne dane audio na wejściu i przetworzyć mowę w chmurze Alexa bez utraty oryginalnego strumienia danych zawierającego lokalnie wykryte „słowo budzące aplikację”. Kompletny strumień danych jest przekazywany do chmury Alexa w celu weryfikacji „słowa budzącego aplikację”, jak również dalszego przetwarzania mowy.

Na każdym etapie tej sekwencji przetwarzania zadanie przetwarzania dźwięku wysyła odpowiednie powiadomienia FreeRTOS do głównego zadania aplikacji. Podobnie jak w przypadku zadania przetwarzania dźwięku, pełna aplikacja Alexa rozszerza główny wzór zadania aplikacji przedstawiony w prostszej formie aplikacji audio front-end. W tym przypadku główne zadanie pełnej aplikacji Alexa - appTask - zarówno generuje zdarzenia, które będą przesyłane do chmury Alexa, jak i zdarzenia zarządzające diodami LED zestawu zgodnie z wymaganiami Amazon AVS UX Attention System. Na przykład, gdy mikrofon pozostaje włączony po wykryciu „słowa budzącego”, zadanie przetwarzania dźwięku powiadamia główne zadanie aplikacji, które ustawia odpowiedni stan uwagi UX (stały wskaźnik LED w kolorze cyjanu) (patrz żółte podświetlenie na listingu 5 i odpowiadające mu podświetlenie na listingu 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;
        }
.
.
.

Listing 5: w pełnej aplikacji Alexa, główne zadanie aplikacji zarządza sekwencją przetwarzania Alexa, w tym kontrolowaniem lampek LED zgodnie z wymogami certyfikacji Alexa. (Źródło kodu: NXP)

Główna procedura w pełnej aplikacji Alexa podobnie jest rozszerzona względem pokazanego uproszczonego wzoru aplikacji audio front-end. W tym przypadku, główna aplikacja tworzy również dodatkowe zadania FreeRTOS dla bardziej zaawansowanej procedury inicjalizacji, jak również zadania do obsługi przycisków zestawu i obsługi aktualizacji OTA.

Opierając się na przykładowych aplikacjach, deweloperzy mogą śmiało wdrożyć funkcjonalność „Alexa Built-in” za pomocą SDK MCU Alexa Voice IoT firmy NXP w swoich własnych projektach opartych na mikrokontrolerach i.MX RT106A. Ponieważ platforma wykonawcza w pełni wykorzystuje AVS dla AWS IoT Core, umożliwia ona deweloperom szersze zastosowanie rozwiązań w technologii Alexa w tanich urządzeniach o ograniczonych zasobach u podstaw coraz bardziej zaawansowanych zastosowań IoT.

Podsumowanie

Usługa Amazon Alexa Voice Service umożliwiła deweloperom wdrożenie tej samej funkcjonalności asystenta głosowego, która jest motorem szybkiego rozwoju inteligentnych głośników Echo. W przeszłości produkty zdolne do uzyskania pożądanego certyfikatu „Alexa Built-in” wymagały platform wykonawczych z dużą pamięcią lokalną i wysokowydajnymi możliwościami przetwarzania. Stworzony na podstawie AVS dla AWS IoT Core, zestaw firmy NXP to rozwiązanie umożliwiające uzyskanie funkcjonalności „Alexa Built-in” za pomocą mikrokontrolera i związanego z nim środowiska wykonawczego oprogramowania.