Schnelle Implementierung von 'Alexa Built-In'-IoT-Designs mit einem Mikrocontroller-basierten Kit

Sprachassistenten haben sich schnell zu einem wichtigen Bestandteil eines jeden intelligenten Produkts entwickelt. Unter den aktuellen Cloud-basierten Lösungen hat sich Amazons Alexa Voice Service (AVS) als der dominierende Sprachassistent herauskristallisiert. Er bietet eine schlüsselfertige Funktion, die die Amazon-Cloud-Ressourcen für die Spracherkennung und die Verarbeitung natürlicher Sprache nutzt.

Für die Entwickler haben sich jedoch die Leistungsanforderungen und die Komplexität des Designs von AVS als eine bedeutende Eintrittsbarriere für kleinere mikroprozessorbasierte Geräte für das vernetzte Heim und das Internet der Dinge (IoT) erwiesen. Ein Kit von NXP Semiconductors ist als Drop-in-Lösung und Referenzdesign für kundenspezifische Anwendungen konzipiert und bietet ein Amazon-AVS-Angebot, das speziell für Geräte mit eingeschränkten Ressourcen entwickelt wurde.

Dieser Artikel zeigt, wie Entwickler "Alexa Built-in"-Designs mit einer Out-of-the-box-Lösung von NXP schnell implementieren können.

Was ist AVS?

Seit ihrem Erscheinen vor einem Jahrzehnt hat sich die Sprachassistententechnologie rasant entwickelt und einen Wachstumsmarkt für intelligente Lautsprecher geschaffen, der nach Schätzungen von Marktanalysten bereits etwa ein Drittel der US-Bevölkerung umfasst. Unter den konkurrierenden Lösungen haben die intelligenten „Echo“-Lautsprecher von Amazon einen dominierenden Anteil gewonnen, indem sie den Erfolg der Amazon Web Services (AWS) bei der Bereitstellung von Cloud-basierten Ressourcen zur Unterstützung von Echo-Apps, auch „Skills“ genannt, von Drittanbietern genutzt haben.

Mit dem Alexa Skills Kit (ASK) und den zugehörigen Anwendungsprogrammier-Schnittstellen (APIs) können Entwickler die schnell wachsende installierte Basis von intelligenten „Echo“-Lautsprechern nutzen, um ihre angeschlossenen Geräte um eine gewisse Sprachsteuerung zu erweitern. Mit diesem Ansatz können angeschlossene Produkte wie intelligente Fernseher oder Thermostate, die „mit Alexa arbeiten“, auf die von der Alexa-Cloud empfangenen Sprachanfragen der Benutzer und die damit verbundenen Anweisungen reagieren (Abbildung 1). Dies fasst die AVS zusammen und gibt einen Einblick in ihr Potenzial.

Abbildung 1: Durch die Erstellung von Alexa-Apps oder Skills können Entwickler angeschlossene Produkte in die Lage versetzen, über Amazon Echo-Produkte mit den gesprochenen Befehlen der Benutzer zu interagieren. (Bildquelle: Amazon Web Services)

Design mit Alexa-Integration („Alexa Built-in “)

Im Gegensatz zu Produkten, die "mit Alexa arbeiten", erreichen intelligente Produkte mit "Alexa Built-in" eine nahtlose, latenzarme Schnittstelle zwischen dem sprachaktivierten Alexa-Gerät und den AWS-Ressourcen. Diese Produkte integrieren AVS direkt in ein angeschlossenes Gerätedesign. Durch die Verwendung von AVS in Kombination mit der AWS IoT-Core-Plattform können Entwickler anspruchsvolle IoT-Anwendungen implementieren, die es den Benutzern ermöglichen, Sprachbefehle mit Alexa-fähigen Produkten zu verwenden, um sowohl angeschlossene Geräte zu steuern als auch Sprachantworten von diesen Geräten zu erhalten (Abbildung 2).

Abbildung 2: Alexa-fähige Geräte bieten Benutzern eine Sprachschnittstelle zur Steuerung von Geräten (oben) oder zum Empfang von Benachrichtigungen von IoT-Geräten (unten), die über AWS IoT Core mit Amazon Web Services-Ressourcen verbunden sind. (Bildquelle: Amazon Web Services)

In der Vergangenheit haben die Entwürfe für die Alexa-fähigen Geräte, die das Herzstück dieser Art von IoT-Anwendung bilden, jedoch allein schon einen großen Designaufwand erfordert. Um die Cloud-basierten Alexa-Dienste zu nutzen, müsste ein Gerät mehrere AVS-Dienst-Bibliotheken ausführen, die durch das AVS Device Software Development Kit (SDK) bereitgestellt werden, das auf Android- oder Linux-Plattformen läuft, um das Wake-Wort zu erkennen, mit der Alexa-Cloud zu kommunizieren und Direktiven für unterstützte Funktionen zu verarbeiten (Abbildung 3). 

Abbildung 3: Dieses Diagramm veranschaulicht die Komponenten des AVS Device SDKs und den Datenfluss zwischen ihnen. (Bildquelle: Amazon Web Services)

Zur Unterstützung dieser Servicebibliotheken benötigen Alexa-fähige Geräteentwürfe in der Regel einen leistungsstarken Anwendungsprozessor und mindestens 50 Megabyte (Mbyte) Speicher, um die Anforderungen der AVS-Verarbeitung zu erfüllen. Darüber hinaus enthalten diese Designs oft einen digitalen Signalprozessor (DSP), um die komplexen Algorithmen auszuführen, die für die Extraktion von Sprachaudio aus verrauschten Umgebungen und die Unterstützung von Fernfeld-Sprachfunktionen, die für Sprachassistenzgeräte erwartet werden, erforderlich sind. Letztendlich sind die Systemanforderungen für den Bau eines effektiven Alexa-fähigen Geräts in der Regel weit über das Kosten- und Komplexitätsniveau hinausgegangen, das für praktische IoT-Geräte erforderlich ist.

Mit der Veröffentlichung seiner AVS-Integration für AWS IoT Core hat Amazon jedoch die für die Implementierung der Alexa Built-in-Produkte erforderliche Prozessorauslastung und den Speicherbedarf drastisch reduziert. Mit diesem Dienst werden rechen- und speicherintensive Aufgaben von dem Alexa-fähigen Gerät auf ein zugehöriges virtuelles Gerät in der Cloud verlagert (Abbildung 4).

Abbildung 4: AVS for AWS IoT Core verlagert speicher- und verarbeitungsintensive Aufgaben in die Cloud, um die Implementierung der Alexa-Sprachassistentenfunktionen auf ressourcenbeschränkten IoT-Geräten zu ermöglichen. (Bildquelle: Amazon Web Services)

Die Verarbeitungsverantwortung des physischen Geräts wird auf die Bereitstellung grundlegenderer Dienste wie sichere Nachrichtenübermittlung, zuverlässige Audiodatenlieferung von und zu Alexa, Aufgabenverwaltung und Ereignisbenachrichtigungen innerhalb des Geräts und mit Alexa reduziert. Die Übertragung von Daten, Befehlen und Benachrichtigungen zwischen dem physischen Gerät und Alexa erfolgt durch effiziente MQTT-Nachrichten (MQ Telemetry Transport), wobei einige wenige reservierte Themen im MQTT-Publish-Subscribe-Protokoll verwendet werden. Schließlich interagiert eine begleitende mobile App mit der Alexa-Cloud für die Geräteregistrierung und jede zusätzlich erforderliche Benutzerinteraktion mit dem Alexa-fähigen Gerät.

Durch die Verlagerung intensiver Datenverarbeitung in die Cloud ermöglicht AVS for AWS IoT Core den Entwicklern, Alexa-Built-in-Produkte mit Plattformen zu erstellen, die den Entwicklern von eingebetteten Systemen vertrauter sind. Anstatt Anwendungsprozessoren mit 50 MByte Speicher unter Linux oder Android können Entwickler diese Designs mit bescheideneren Mikrocontrollern mit weniger als 1 MByte RAM und Echtzeitbetriebssystem-Software (RTOS) implementieren. Tatsächlich können Alexa-fähige Designs, die mit AVS for AWS IoT Core erstellt werden, eine 50%ige Reduzierung der Stückliste im Vergleich zu Designs, die für den lokalen Betrieb der gesamten Palette von AVS-Diensten erstellt wurden, erreichen.

Obwohl AVS for AWS IoT Core eine kostengünstigere Laufzeitplattform unterstützt, bleibt die Implementierung eines zertifizierten Alexa Built-in-Produktes ein komplexes Unterfangen. Entwickler, die neu bei AVS und IoT Core sind, können eine beträchtliche Lernkurve durchlaufen, wenn sie sich mit den AWS-Anforderungen für Sicherheit, Kommunikation, Kontoverwaltung, User Experience (UX)-Design und vieles mehr befassen. Unabhängig von ihrer Vertrautheit mit dem AWS-Ökosystem müssen alle Alexa-Produktentwickler sicherstellen, dass ihre Designs eine lange Reihe von Spezifikationen und Anforderungen erfüllen, um die Amazon Alexa-Zertifizierung zu erhalten.

NXPs Mikrocontroller-basierte Lösung für Alexa bietet eine schlüsselfertige Systemlösung, die die geräteseitigen Hardware- und Softwareanforderungen für Amazon AVS for AWS IoT Core vollständig implementiert.

Mikrocontroller-basierte Alexa-Lösung

Das um den NXP i.MX RT106A-Mikrocontroller herum aufgebaute NXP SLN-ALEXA-IOT AVS-Kit bietet eine vorkonfigurierte AWS-Konnektivität, AVS-qualifizierte Fernfeld-Audio-Algorithmen, Echounterdrückung, Alexa-Wake-Word-Fähigkeit und Anwendungscode. Der auf einem Arm Cortex-M7-Kern basierende i.MX RT106A-Mikrocontroller des Bausatzes ist ein Mitglied der i.MX RT106x-Familie von NXP, die speziell für IoT-Edge-Computing entwickelt wurde. Der RT106A wurde für eingebettete Sprachanwendungen entwickelt und erweitert die Basisarchitektur der Crossover-Prozessorfamilie NXP i.MX RT1060 um spezielle Funktionen, wie z.B. einen umfassenden Satz von Peripherieschnittstellen, einen umfangreichen internen Speicher und eine breite Unterstützung für externe Speicheroptionen (Abbildung 5).

Abbildung 5: Die Crossover-Prozessorfamilie NXP i.MX RT1060 integriert einen Arm Cortex-M7-Mikrocontrollerkern mit einem vollständigen Satz von Peripherieschnittstellen, Speicher und anderen Fähigkeiten, die normalerweise in einem IoT-Gerät benötigt werden. (Bildquelle: NXP)

Mit seiner integrierten Funktionalität benötigt der i.MX RT106A Mikrocontroller nur wenige zusätzliche Komponenten, um die Hardwarebasis für die Implementierung von AVS für AWS IoT Core zu schaffen. In seinem SLN-ALEXA-IOT-Kit integriert NXP den Mikrocontroller i.MX RT106A in einem Systemmodul mit 256 Megabit (Mb) Flash-Speicher, das Wi-Fi/Bluetooth-Transceivermodul LBEE5KL1DX von Murata Electronics und den Abwärtswandler AP2202K-3.3TRG1 von Diodes (Abbildung 6).

Abbildung 6: Das Design des NXP SLN-ALEXA-IOT AVS-Kit-Systemmoduls nutzt die Vorteile der einfachen Hardwareschnittstelle, die für die Integration des NXP i.MX RT106A-Mikrocontrollers mit externem Flash und einem drahtlosen Transceiver erforderlich ist. (Bildquelle: NXP)

Als Ergänzung zu diesem Systemmodul bietet eine Sprachkarte im SLN-ALEXA-IOT-Kit drei Knowles SPH0641LM4H-1 PDM-MEMS-Mikrofone, einen PUI Audio AS01808AO-Lautsprecher und einen NXP TFA9894D Klasse-D-Audioverstärker. Zusammen mit einem USB-Typ-C-Anschluss zur Stromversorgung des Kits und zum Betrieb einer Shell-Konsole von einem Personal Computer aus bietet das Voice-Board Anschlüsse für Ethernet, serielle Peripheriegeräte und den i.MX RT106A-Mikrocontroller für allgemeine Ein-/Ausgabe (GPIO). Schließlich enthält das Board Schalter für grundlegende Steuereingänge sowie LEDs für visuelles Feedback, die den Anforderungen des Amazon AVS UX Attention System entsprechen und verschiedene LED-Farben und Ein-/Aus-Zyklusmuster verwenden.

Die SLN-ALEXA-IOT-Hardware bietet mit ihrem Systemmodul und der Sprachkarte eine vollständige Plattform für die geräteseitige Verarbeitung von AVS für die AWS IoT Core-Software. Wie bereits erwähnt, hängen Alexa-fähige IoT-Gerätedesigns jedoch ebenso sehr von optimierter Software wie von Hardware ab. Die Erstellung dieser Software von Grund auf mit Amazons AVS for AWS IoT-API kann Projekte erheblich verzögern, da die Entwickler den Prozess der Erstellung der erforderlichen Datenobjekte und der Implementierung der zugehörigen Protokolle durchlaufen. Weitere Verzögerungen können entstehen, wenn Entwickler, die auf die Alexa Built-in-Zertifizierung hinarbeiten, versuchen, das AVS UX Attention System, die AWS-Sicherheitspraktiken und andere Anforderungen, die jeden Aspekt der Interaktion der Benutzer mit den Alexa-Diensten im Design berühren, zu erfüllen. NXP begegnet diesen Bedenken mit seiner umfassenden Laufzeit-Sprachsteuerungs-Softwareumgebung auf der Basis von Amazon FreeRTOS, die auf einer Schicht von Softwaretreibern für XIP-Flash, Konnektivität und andere Hardwarekomponenten basiert (Abbildung 7).

Abbildung 7: Die auf Amazon FreeRTOS aufbauende NXP-Systemumgebung zur Sprachsteuerung bietet einen umfangreichen Satz von Middleware-Diensten, einschließlich Firmware-Routinen für maschinelles Lernen und Audio-Frontend-Verarbeitung. (Bildquelle: NXP)

Die intelligente Toolbox-Firmware von NXP, die den Sprachverarbeitungsfunktionen dieser Softwareumgebung zugrunde liegt, bietet optimierte Funktionen für alle Audioaufgaben, einschließlich der ML-Inferenzmaschine (ML = Machine-Learning) und des ML-Audio-Frontends zur Audiosignalaufbereitung und -optimierung. Andere Middleware-Dienste unterstützen sichere Verbindungen, AWS-Kommunikation und Audiofunktionen. Über dieser umfassenden Serviceschicht vermittelt Software für AWS IoT Core, Onboarding und andere Anwendungssteuerungsfunktionen den Start von einem zweistufigen Bootloader mit Unterstützung für Over-the-Air (OTA)-Updates, die auf dem AWS IoT OTA-Dienst und dem Amazon FreeRTOS OTA-Client aufbauen.

Mit der werkseitig installierten Software, die auf dieser Umgebung läuft, können Entwickler sofort das SLN-ALEXA-IOT-Hardwarekit mit einer vollständigen Alexa-fähigen Anwendung aufrufen, die für die Verwendung eines NXP-Demonstrationskontos für AWS IoT entwickelt wurde. Die NXP-Dokumentation enthält eine detaillierte Anleitung, die den Prozess der Bereitstellung des Kits, der Bereitstellung von Wi-Fi-Zugangsdaten und der vollständigen Authentifizierung des AWS-Geräts mit dem Demonstrationskonto beschreibt. Als Teil dieses Prozesses interagieren die Entwickler mit dem Kit und der AWS über eine mobile Android-App, die im Softwareverteilungspaket enthalten ist. Diese ist auf der NXP-Website mit einem Aktivierungscode erhältlich, der mit jedem SLN-ALEXA-IOT-Kit geliefert wird. Nach ein paar einfachen Schritten können Entwickler sofort mit der Interaktion mit dem Kit beginnen, und zwar durch die gleiche Art von Alexa-Sprachinteraktionen, die von den intelligenten „Echo“-Lautsprechern bereitgestellt werden.

Für die schnelle Erstellung von Prototypen von Produkten mit Alexa-Fähigkeiten bieten das SLN-ALEXA-IOT-Kit und die werkseitig installierte Software eine fertige Plattform. Gleichzeitig dienen die Kit-Hardware und -Software als schnelle Entwicklungsplattform für die Erstellung kundenspezifischer Alexa-fähiger Designs auf der Basis des i.MX RT106A-Mikrocontrollers.

Kundenspezifische Entwicklung

Die Software für i.MX RT106A-basierte Alexa-Lösungen nutzt die Fähigkeiten der NXP-Sprachsteuerungs-Laufzeitumgebung über das NXP MCU Alexa Voice IoT SDK, das als Teil des bei der Produktaktivierung erhältlichen Software-Verteilungspakets bereitgestellt wird. Dieses SDK wurde als Add-On für die Eclipse-basierte integrierte Entwicklungsumgebung (IDE) MCUXpresso von NXP entwickelt und kombiniert den vollständigen Quellcode für Beispielanwendungen, Treiber und Middleware mit Headern für binäre Distributionen spezieller Firmware-Funktionen wie der NXP Intelligent Toolbox, der ML-Inferenzmaschine und dem ML-Audio-Frontend.

Entwickler, die schnell ein Alexa-fähiges Produkt einsetzen müssen, können im Prinzip die vollständige Alexa-Demo-Anwendung mit geringfügigen Änderungen nutzen. Im einfachsten Fall würden diese Modifikationen die Anwendung einfach auf das eigene AWS-Konto des Entwicklers unter Verwendung seiner eigenen Sicherheitszugangsdaten zurückführen. NXP bietet eine Schritt-für-Schritt-Beschreibung für den Abschluss dieses Prozesses.

Für die kundenspezifische Entwicklung bieten die in der Software-Distribution enthaltenen Beispielanwendungen ausführbare Beispiele, die zeigen, wie man mit dem NXP MCU Alexa Voice IoT SDK arbeitet. Anstatt direkt in die vollständige Alexa-Demonstrationsanwendung zu springen, können Entwickler Beispielanwendungen untersuchen, die es ihnen ermöglichen, sich stärker auf bestimmte Funktionen zu konzentrieren, einschließlich des Audio-Frontends, der Wi-Fi- und Bluetooth-Konnektivität, des Bootloadings und anderer. Die Audio-Front-End-Beispielanwendung veranschaulicht beispielsweise die grundlegenden Entwurfsmuster für die Durchführung der Wake-Word-Erkennung mit Amazon FreeRTOS-Aufgaben.

In der Audio-Front-End-Beispielanwendung zeigt die Hauptroutine, wie Entwickler Hardware- und Software-Subsysteme initialisieren und dann die FreeRTOS-Funktion xTaskCreate verwenden würden, um den Hauptanwendungs-Task (appTask) und einen Konsolen-Shell-Task (sln_shell_task) zu starten, bevor die Kontrolle an den FreeRTOS-Scheduler freigegeben wird (Listing 1). (Hinweis: Der vTaskStartScheduler-Aufruf zum Starten des FreeRTOS-Schedulers würde nur dann zurückkehren, wenn der Scheduler nicht über genügend Speicher verfügt).

Kopie
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: In der NXP MCU Alexa Voice IoT SDK-Distribution ist eine Audio-Frontend-Beispielanwendung enthalten, die die grundlegenden Initialisierungsanforderungen und die Erstellung von FreeRTOS-Aufgaben für die Hauptanwendungsaufgabe und eine Konsolen-Shell-Aufgabe demonstriert. (Codequelle: NXP)

Nach der Initialisierung des Audio-Subsystems startet die Hauptanwendungsaufgabe appTask wiederum ein Paar von FreeRTOS-Aufgaben. Eine Aufgabe führt eine Serviceroutine, audio_processing_task, aus, die die Audioeingabe verarbeitet, während die andere die Umwandlung der Mikrofon-PDM-Ausgabe in PCM (Pulse Code Modulation) übernimmt. Nach zusätzlichem Housekeeping geht appTask in eine Endlosschleife über und wartet auf eine RTOS-Benachrichtigung, die anzeigt, dass das Wake-Wort erkannt wurde (Listing 2).

Kopie
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: In der Audio-Frontend-Beispielanwendung startet die Hauptanwendungsaufgabe appTask Tasks, um die Audioverarbeitung und Mikrofondatenkonvertierung zu handhaben, und wartet dann auf eine FreeRTOS-Benachrichtigung (taskNotification), dass das Wake-Word erkannt wurde (kWakeWordDetected). (Code-Quelle: NXP)

Die Audioverarbeitungsaufgabe in dieser Beispielanwendung wiederum initialisiert die Wake-Word-Firmwarefunktion und initialisiert die Parameter für die Wake-Word-Erkennung, bevor sie ebenfalls in eine Endlosschleife eintritt, in der sie auf eine FreeRTOS-Benachrichtigung von der Mikrofondatenkonvertierungsaufgabe wartet, dass verarbeitete Mikrofondaten verfügbar sind. Zu diesem Zeitpunkt ruft die Audioverarbeitungsaufgabe die Intelligent Toolbox-Firmwarefunktionen auf, die die Audiodaten verarbeiten und eine Wake-Word-Erkennung unter Verwendung der ML-Inferenzmaschine (Listing 3) durchführen.

Kopie
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: In der Audio-Front-End-Beispielanwendung initialisiert die Audio-Verarbeitungsaufgabe die Firmware-Wake-Word-Engine, wartet auf eine FreeRTOS-Benachrichtigung, dass Mikrofondaten verfügbar sind, und ruft schließlich das analoge NXP Intelligent Toolbox-Firmware-Front-End (SLN_Voice_Process_Audio) und die ML-Inferenz-Engine (SLN_AMAZON_WAKE_ProcessWakeWord) zur Wake-Word-Erkennung auf. (Code-Quelle: NXP)

Nach der Erkennung des Wake-Words gibt die Audioverarbeitungsaufgabe eine FreeRTOS-Task-Benachrichtigung aus, um die Hauptaufgabe der Anwendung, appTask, über dieses Ereignis zu informieren. Nach Erhalt dieser Benachrichtigung blinkt bei appTask kurzzeitig eine blaue LED (siehe auch Listing 2).

Die vollständige Alexa-Beispielanwendung basiert auf denselben Mustern, die für die einfachere Audio-Frontend-Anwendung beschrieben wurden, erweitert jedoch die Basiscode-Basis erheblich, um die volle Alexa-Funktionalität zu unterstützen. Nachdem die ML-Inferenzmaschine beispielsweise das Wake-Word in der Alexa-Beispielanwendung erkannt hat, führt die Audioverarbeitungsaufgabe eine Reihe von FreeRTOS-Benachrichtigungen aus, die mit jeder Stufe der Alexa-Verarbeitungssequenz (Listing 4) verbunden sind.

Kopie
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: In der vollständigen Alexa-Anwendung ergänzt die Audioverarbeitungsaufgabe die in der Audio-Frontend-Anwendung durchgeführten Verarbeitungsschritte um zusätzlichen Code zur Verwaltung der nachfolgenden Audioverarbeitungsstufen in der Alexa-Sequenz. (Codequelle: NXP)

Nach der lokalen ML-Wake-Word-Erkennung benachrichtigt die Audio-Verarbeitungsaufgabe der vollständigen Alexa-Anwendung die Hauptaufgabe der Anwendung wie zuvor beschrieben. Darüber hinaus muss es nun Audioverarbeitungszustände verwalten, bei denen das Mikrofon offen bleibt, um den kompletten Audioeingang für die Sprachverarbeitung in der Alexa-Cloud zu erfassen, ohne den ursprünglichen Datenstrom mit dem lokal erkannten Wake-Wort zu verlieren. Dieser vollständige Datenstrom wird zur Verifizierung des Wake-Words sowie zur weiteren Sprachverarbeitung an die Alexa-Cloud übergeben.

In jeder Phase dieser Verarbeitungssequenz gibt die Audioverarbeitungsaufgabe entsprechende FreeRTOS-Benachrichtigungen an die Hauptanwendungsaufgabe aus. Wie bei der Audio-Verarbeitungsaufgabe erweitert die vollständige Alexa-Anwendung das Muster der Hauptanwendungsaufgabe, das in der Audio-Frontend-Anwendung in einfacherer Form dargestellt wird. Hier generiert der Hauptanwendungstask der gesamten Alexa-Anwendung, appTask, sowohl Ereignisse zur Übertragung an die Alexa-Cloud als auch zur Verwaltung der LEDs des Kits gemäß den Anforderungen des Amazon AVS UX Attention System. Wenn das Mikrofon beispielsweise nach der Wake-Word-Erkennung offen gehalten wird, benachrichtigt die Audioverarbeitungsaufgabe die Hauptanwendungsaufgabe, die den entsprechenden UX-Aufmerksamkeitszustand (solide cyanfarbene LED-Anzeige) einstellt (siehe gelbe Hervorhebungen in Listing 5 und entsprechende Hervorhebung in Listing 4 erneut).

Kopie
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: In der vollständigen Alexa-Anwendung orchestriert die Hauptanwendungsaufgabe die Alexa-Verarbeitungssequenz einschließlich der Steuerung der LED-Leuchten in Übereinstimmung mit den Alexa-Zertifizierungsanforderungen. (Codequelle: NXP)

Die Hauptroutine in der vollständigen Alexa-Anwendung erweitert in ähnlicher Weise das in der Audio-Frontend-Anwendung in einfacherer Form gezeigte Muster. In diesem Fall erstellt die Hauptanwendung auch zusätzliche FreeRTOS-Aufgaben für eine umfangreichere Initialisierungsprozedur sowie Aufgaben zur Handhabung der Schaltflächen des Kits und zur Unterstützung von OTA-Updates.

Auf der Grundlage dieser Anwendungsbeispiele können Entwickler mit Hilfe des NXP MCU Alexa Voice IoT SDK die integrierte Alexa-Funktionalität sicher in ihre eigenen i.MX RT106A-basierten Designs implementieren. Da sie die Vorteile von AVS for AWS IoT Core voll ausnutzt, ermöglicht diese Ausführungsplattform Entwicklern, Alexa-fähige Lösungen in kostengünstigen, ressourcenbeschränkten Geräten auf der Grundlage von immer ausgefeilteren IoT-Anwendungen auf breiterer Basis zu implementieren.

Fazit

Der Amazon Alexa Voice Service hat es den Entwicklern ermöglicht, die gleiche Sprachassistenten-Funktionalität zu implementieren, die das schnelle Wachstum der intelligenten „Echo“-Lautsprecher begründet. In der Vergangenheit erforderten Produkte, die die begehrte Alexa Built-in-Zertifizierung erhalten konnten, Ausführungsplattformen mit beträchtlichem lokalem Speicher und Hochleistungs-Verarbeitungsfunktionen. Ein Bausatz von NXP, der mit AVS for AWS IoT Core gebaut wurde, bietet eine Drop-in-Lösung für die Alexa-Einbaufunktionalität unter Verwendung eines Mikrocontrollers und einer zugehörigen Software-Ausführungsumgebung.