Cómo desplegar rápidamente aplicaciones de aprendizaje automático preparadas para el borde

El aprendizaje automático (ML) ofrece un enorme potencial para la creación de productos inteligentes, pero la complejidad y los retos que conlleva el modelado de redes neuronales (NN) y la creación de aplicaciones ML para el borde han limitado la capacidad de los desarrolladores para ofrecer rápidamente soluciones útiles. Aunque las herramientas fácilmente disponibles han hecho más accesible la creación de modelos de ML en general, las prácticas convencionales de desarrollo de ML no están diseñadas para satisfacer los requisitos exclusivos de las soluciones para el Internet de las cosas (IoT), la automoción, los sistemas industriales y otras aplicaciones integradas.

Este artículo ofrece una breve introducción a la modelización NN. A continuación, presenta y describe cómo utilizar una completa plataforma de ML de NXP Semiconductors que permite a los desarrolladores ofrecer con mayor eficacia aplicaciones de ML preparadas para el borde.

Un rápido repaso a la modelización NN

Los algoritmos de ML ofrecen a los desarrolladores una opción muy diferente para el desarrollo de aplicaciones. En lugar de escribir un código de software destinado a resolver explícitamente problemas como la clasificación de imágenes, los desarrolladores entrenan los modelos de NN presentando un conjunto de datos como imágenes anotadas con el nombre real (o clase) de la entidad contenida en la imagen. El proceso de entrenamiento utiliza diversos métodos para calcular los parámetros del modelo de pesos y valores de sesgo para cada neurona y capa, respectivamente, lo que permite al modelo proporcionar una predicción razonablemente precisa de la clase correcta de una imagen de entrada (Figura 1).

Figura 1: Las NN, como esta red totalmente conectada, clasifican un objeto de entrada utilizando los parámetros de peso y sesgo establecidos durante el entrenamiento. (Fuente de la imagen: NXP Semiconductors)

Los investigadores de ML han desarrollado una amplia gama de arquitecturas de NN más allá de la NN genérica totalmente conectada que se muestra en la Figura 1. Por ejemplo, las aplicaciones de clasificación de imágenes suelen utilizar la NN convolucional (CNN), una arquitectura especializada que divide el reconocimiento de imágenes en una fase inicial que encuentra las características clave de una imagen, seguida de una fase de clasificación que predice la probabilidad de que pertenezca a una de varias clases establecidas durante el entrenamiento (Figura 2).

Figura 2: Los expertos en ML utilizan arquitecturas de NN especializadas, como esta red neuronal convolucional (CNN), para tareas específicas como el reconocimiento de imágenes. (Fuente de la imagen: NXP Semiconductors)

Aunque la selección de una arquitectura de modelo y un régimen de entrenamiento adecuados ha estado limitada a los expertos en ML, la disponibilidad de múltiples herramientas comerciales y de código abierto ha simplificado enormemente el desarrollo de modelos para las implantaciones a gran escala. En la actualidad, los desarrolladores pueden definir los modelos con unas pocas líneas de código (listado 1) y utilizar herramientas como el visor de modelos Netron, de código abierto, para generar una representación gráfica del modelo (figura 3) y comprobar la definición de cada capa y su conectividad.

Copiar
def model_create(shape_in, shape_out):
    from keras.regularizers import l2
    
    tf.random.set_seed(RANDOM_SEED)
 
    model = tf.keras.Sequential()
    model.add(tf.keras.Input(shape=shape_in, name='acceleration'))
    model.add(tf.keras.layers.Conv2D(8, (4, 1), activation='relu'))
    model.add(tf.keras.layers.Conv2D(8, (4, 1), activation='relu'))
    
    model.add(tf.keras.layers.Dropout(0.5))
    
    model.add(tf.keras.layers.MaxPool2D((8, 1), padding='valid'))
    model.add(tf.keras.layers.Flatten())
    
    model.add(tf.keras.layers.Dense(64, kernel_regularizer=l2(1e-4), bias_regularizer=l2(1e-4), activation='relu'))
    model.add(tf.keras.layers.Dropout(0.5))
    model.add(tf.keras.layers.Dense(32, kernel_regularizer=l2(1e-4), bias_regularizer=l2(1e-4), activation='relu'))
    model.add(tf.keras.layers.Dropout(0.5))
    model.add(tf.keras.layers.Dense(shape_out, activation='softmax'))
    model.compile(optimizer='adam', loss='categorical_crossentropy', metrics=['acc'])
    
    return model

Listado 1: Los desarrolladores pueden definir los modelos NN utilizando solo unas pocas líneas de código. (Fuente del código: NXP Semiconductors)

Figura 3: Generada por el visor de Netron, esta representación gráfica del modelo definido en el Listado 1 puede ayudar al desarrollador a documentar la función y la conectividad de cada capa. (Fuente de la imagen: Stephen Evanczuk, ejecutando Netron en el código fuente del modelo NXP en el Listado 1)

Para el despliegue final, otras herramientas eliminan las estructuras del modelo requeridas solo durante el entrenamiento y realizan otras optimizaciones para crear un modelo de inferencia eficiente.

Por qué ha sido tan difícil desarrollar aplicaciones basadas en ML para productos inteligentes

La definición y el entrenamiento de un modelo para el IoT u otros productos inteligentes sigue un flujo de trabajo similar al de la creación de un modelo para aplicaciones de aprendizaje automático a escala empresarial. Sin embargo, más allá de esa similitud, el desarrollo de aplicaciones de ML para el borde conlleva múltiples desafíos adicionales. Junto con el desarrollo de modelos, los diseñadores se enfrentan a los conocidos retos de desarrollar la aplicación principal necesaria para ejecutar su producto basado en un microcontrolador (MCU). Como resultado, llevar el ML al borde requiere gestionar dos flujos de trabajo interrelacionados (Figura 4).

Figura 4: El desarrollo de una aplicación basada en ML para el borde amplía el típico flujo de trabajo de desarrollo de la MCU integrada con un flujo de trabajo de ML necesario para entrenar, validar y desplegar un modelo de ML. (Fuente de la imagen: NXP Semiconductors)

Aunque el flujo de trabajo del proyecto MCU es familiar para los desarrolladores de sistemas embebidos, el proyecto ML puede imponer requisitos adicionales a la aplicación basada en MCU mientras los desarrolladores trabajan para crear un modelo de inferencia ML optimizado. De hecho, el proyecto de ML tiene un impacto dramático en los requisitos del dispositivo embebido. La gran carga computacional y los requisitos de memoria que suelen asociarse a la ejecución de modelos pueden superar los recursos de los microcontroladores utilizados en el IoT y los productos inteligentes. Para reducir las necesidades de recursos, los expertos en ML aplican técnicas como la poda de la red de modelos, la compresión, la cuantificación a una precisión menor, o incluso los parámetros y valores intermedios de un solo bit, y otros métodos.

Sin embargo, incluso con estos métodos de optimización, los desarrolladores pueden encontrar que los microcontroladores convencionales carecen del rendimiento necesario para manejar el gran número de operaciones matemáticas asociadas a los algoritmos de ML. Por otro lado, el uso de un procesador de aplicaciones de alto rendimiento podría manejar la carga computacional de ML, pero ese enfoque podría dar lugar a un aumento de la latencia y a una respuesta no determinista, degradando las características de tiempo real de su diseño integrado.

Aparte de los retos de selección de hardware, la entrega de modelos ML optimizados para el borde tiene retos adicionales únicos para el desarrollo integrado. El gran número de herramientas y métodos desarrollados para las aplicaciones de ML a escala empresarial podría no adaptarse bien a la aplicación y el entorno operativo del desarrollador integrado. Incluso los desarrolladores experimentados que esperan desplegar rápidamente dispositivos basados en ML pueden encontrarse con dificultades para encontrar una solución eficaz entre la gran cantidad de arquitecturas, herramientas, marcos y flujos de trabajo de modelos de NN disponibles.

NXP aborda tanto el rendimiento del hardware como las facetas de implementación del modelo en el desarrollo de ML de borde. A nivel de hardware, los microcontroladores cruzados i.MX RT1170 de alto rendimiento de NXP satisfacen los amplios requisitos de rendimiento de la ML de borde. Para aprovechar al máximo esta base de hardware, el entorno de desarrollo de software ML eIQ (edge intelligence) de NXP y los paquetes de software de aplicación ofrecen a los desarrolladores de ML, tanto a los inexpertos como a los expertos, una solución eficaz para crear aplicaciones ML preparadas para el edge.

Una plataforma eficaz para el desarrollo de aplicaciones ML preparadas para el borde

Los procesadores cruzados NXP i.MX RT combinan la respuesta en tiempo real y de baja latencia de los microcontroladores integrados tradicionales con las capacidades de ejecución de los procesadores de aplicaciones de alto rendimiento. La serie de procesadores cruzados i.MX RT1170 de NXP integra un procesador Arm® Cortex®-M4 de bajo consumo y un procesador Arm Cortex-M7 de alto rendimiento con un amplio conjunto de bloques funcionales y periféricos necesarios para ejecutar aplicaciones exigentes, incluidas las soluciones basadas en ML en dispositivos integrados (Figura 5).

Figura 5: Los procesadores cruzados i.MX RT1170 de NXP combinan la capacidad de eficiencia energética de los microcontroladores convencionales con la capacidad de procesamiento de alto rendimiento de los procesadores de aplicaciones. (Fuente de la imagen: NXP Semiconductors)

Totalmente integrado en los entornos de desarrollo MCUXpresso SDK y Yocto de NXP, el entorno NXP eIQ está diseñado específicamente para facilitar la implementación de modelos de inferencia en sistemas embebidos construidos con microprocesadores y microcontroladores de NXP. Incluido en el entorno eIQ, el eIQ Toolkit admite los flujos de trabajo BYOD (Bring Your Own Data) y BYOM (Bring Your Own Model) a través de varias herramientas, como el eIQ Portal, la eIQ Model Tool y las herramientas de línea de comandos (Figura 6).

Figura 6: El kit de herramientas NXP eIQ apoya a los desarrolladores BYOD que necesitan crear un modelo y a los desarrolladores BYOM que necesitan desplegar su propio modelo existente en un sistema de destino. (Fuente de la imagen: NXP Semiconductors)

Diseñado para dar soporte a los flujos de trabajo BYOD tanto para los expertos como para los desarrolladores que se inician en el desarrollo de modelos ML, el eIQ Portal proporciona una interfaz gráfica de usuario (GUI) que ayuda a los desarrolladores a completar más fácilmente cada etapa del flujo de trabajo de desarrollo de modelos.

En la fase inicial de desarrollo, la herramienta de curador de conjuntos de datos de eIQ Portal ayuda a los desarrolladores a importar datos, capturar datos de una cámara conectada o capturar datos de un dispositivo remoto (Figura 7).

Figura 7: La herramienta de conservación de conjuntos de datos de eIQ Portal facilita la tarea crítica de preparación de los datos de formación. (Fuente de la imagen: NXP Semiconductors)

Con la herramienta de curaduría de conjuntos de datos, los desarrolladores anotan, o etiquetan, cada elemento del conjunto de datos etiquetando toda la imagen, o solo regiones específicas contenidas dentro de un cuadro delimitador específico. Una función de aumento ayuda a los desarrolladores a proporcionar la diversidad necesaria al conjunto de datos difuminando las imágenes, añadiendo ruido aleatorio, cambiando características como el brillo o el contraste, y otros métodos.

En la siguiente fase, el eIQ Portal ayuda a los desarrolladores a seleccionar el tipo de modelo más adecuado para la aplicación. Para los desarrolladores que no estén seguros del tipo de modelo, un asistente de selección de modelos les guía a través del proceso de selección basado en el tipo de aplicación y la base de hardware. Los desarrolladores que ya saben qué tipo de modelo necesitan pueden seleccionar un modelo personalizado proporcionado con la instalación de eIQ u otras implementaciones personalizadas.

El eIQ Portal lleva a los desarrolladores a través del siguiente paso crítico de entrenamiento, proporcionando una GUI intuitiva para modificar los parámetros de entrenamiento y ver los cambios en la precisión de la predicción del modelo con cada paso de entrenamiento (Figura 8).

Figura 8: Los desarrolladores utilizan la herramienta de entrenamiento de eIQ Portal para observar la mejora en la precisión del entrenamiento con cada paso, y para modificarlos si es necesario. (Fuente de la imagen: NXP Semiconductors)

En el siguiente paso, la GUI de eIQ Portal ayuda a los desarrolladores a validar el modelo. En esta etapa, el modelo se convierte para ejecutarse en la arquitectura de destino para determinar su rendimiento real. Cuando se completa la validación, la pantalla de validación muestra la matriz de confusión, una herramienta fundamental de validación de ML que permite a los desarrolladores comparar la clase real del objeto de entrada con la clase predicha por el modelo (Figura 9).

Figura 9: La herramienta de validación del eIQ Portal proporciona a los desarrolladores la matriz de confusión resultante de la ejecución de un modelo en una arquitectura objetivo. (Fuente de la imagen: NXP Semiconductors)

Para el despliegue final, el entorno proporciona a los desarrolladores una selección de motores de inferencia de destino en función del procesador, entre ellos:

• Arm CMSIS-NN (Common Microcontroller Software Interface Standard, Neural Network): núcleos de redes neuronales desarrollados para maximizar el rendimiento y minimizar la huella de memoria de las redes neuronales en los núcleos del procesador Arm Cortex-M
• Arm NN SDK (red neuronal, kit de desarrollo de software): un conjunto de herramientas y motor de inferencia diseñado para servir de puente entre los marcos de redes neuronales existentes y los procesadores Arm Cortex-A, entre otros
• DeepViewRT-Motorde inferencia propio de NXPpara MCUs i.MX RT crossover
• Glow NN, basadoen el compilador Glow (graph lowering) de Meta y optimizado por NXP para los núcleos Cortex-M de Arm mediante el uso de llamadas de función a los núcleos CMSIS-NN o a la biblioteca NN de Arm si está disponible, o bien compilando el código desde su propia biblioteca nativa
• ONXX Runtime: herramientas de MicrosoftResearch diseñadas para optimizar el rendimiento de los procesadores Arm Cortex-A.
• TensorFlow Lite for Microcontrollers: una versión más pequeña de TensorFlow Lite, optimizada para ejecutar modelos de aprendizaje automático en MCUs i.MX RT crossover
• TensorFlow Lite:una versión de TensorFlow que ofrece soporte para sistemas más pequeños

En el caso de los flujos de trabajo BYOM, los desarrolladores pueden utilizar la herramienta eIQ Model Tool para pasar directamente al análisis del modelo y a la elaboración de perfiles temporales por capas. Para los flujos de trabajo BYOD y BYOM, los desarrolladores pueden utilizar las herramientas de línea de comandos de eIQ, que proporcionan acceso a la funcionalidad de la herramienta, así como a las características de eIQ que no están disponibles directamente a través de la GUI.

Además de las características descritas en este artículo, el eIQ Toolkit soporta un amplio conjunto de capacidades, incluyendo la conversión y optimización de modelos que va mucho más allá del alcance de este artículo. Sin embargo, para la creación rápida de prototipos de aplicaciones ML preparadas para el borde, los desarrolladores generalmente pueden avanzar rápidamente a través del desarrollo y la implementación con poca necesidad de emplear muchas de las capacidades más sofisticadas del entorno eIQ. De hecho, los paquetes de software de aplicación (App SW) especializados de NXP ofrecen aplicaciones completas que los desarrolladores pueden utilizar para su evaluación inmediata o como base de sus propias aplicaciones personalizadas.

Cómo evaluar rápidamente el desarrollo de un modelo mediante un paquete SW de aplicaciones

Los NXP App SW Packs proporcionan una aplicación completa basada en ML, combinando código fuente listo para producción, controladores, middleware y herramientas. Por ejemplo, el paquete de software NXP ML State Monitor App ofrece una solución inmediata basada en ML al frecuente problema de determinar el estado de sistemas complejos a partir de las entradas de los sensores (Figura 10).

Figura 10: Los desarrolladores pueden utilizar NXP App SW Packs como el ML State Monitor App SW Pack para su evaluación inmediata, o como base para el desarrollo de código personalizado. (Fuente de la imagen: NXP Semiconductors)

El ML State Monitor App SW Pack implementa una solución completa para una aplicación destinada a detectar cuando un ventilador está funcionando en uno de los cuatro estados:

• ON (Encendido)
• OFF (Apagado)
• CLOGGED (Obstruido), cuando el ventilador está encendido pero el flujo de aire está obstruido
• FRICTION (Fricción), cuando el ventilador está encendido, pero una o varias aspas del ventilador encuentran un exceso de fricción durante su funcionamiento

Igual de importante para los desarrolladores de modelos, el ML State Monitor App SW Pack incluye modelos ML así como un conjunto completo de datos que representan las lecturas del acelerómetro de un ventilador que funciona en cada uno de esos cuatro estados.

Los desarrolladores pueden estudiar el código, los modelos y los datos proporcionados en el ML State Monitor App SW Pack para entender cómo utilizar los datos de los sensores para entrenar un modelo, crear un modelo de inferencia y validar la inferencia contra un conjunto de datos de sensores de validación. De hecho, el cuaderno Jupyter ML_State_Monitor.ipynb de NXP, incluido en el paquete de software de la aplicación, proporciona una herramienta inmediata para estudiar el flujo de trabajo de desarrollo del modelo mucho antes de cualquier despliegue de hardware.

El Jupyter Notebook es una plataforma interactiva de ejecución de Python basada en el navegador que permite a los desarrolladores ver inmediatamente los resultados de la ejecución del código Python. La ejecución de un Jupyter Notebook genera un bloque de código Python, seguido inmediatamente por los resultados de la ejecución de ese bloque de código. Estos resultados no son simples visualizaciones estáticas, sino que son los resultados reales obtenidos al ejecutar el código. Por ejemplo, cuando los desarrolladores ejecutan el Jupyter Notebook ML_State_Monitor.ipynb de NXP, pueden ver inmediatamente un resumen del conjunto de datos de entrada (Figura 11).

Figura 11: El Jupyter Notebook ML_State_Monitor.ipynb de NXP permite a los desarrolladores trabajar de forma interactiva a través del flujo de trabajo de desarrollo de modelos de redes neuronales, visualizando los datos de entrenamiento proporcionados en el ML State Monitor App SW Pack. [Nota: Código truncado aquí por motivos de visualización]. (Fuente de la imagen: Stephen Evanczuk, ejecutando el Jupyter Notebook ML_State_Monitor.ipynb de NXP)

La siguiente sección de código en el Jupyter Notebook proporciona al usuario una visualización gráfica de los datos de entrada, presentados como gráficos separados para la secuencia temporal y la frecuencia (Figura 12).

Figura 12: El Jupyter Notebook ofrece a los desarrolladores la visualización de series temporales y frecuencias del conjunto de datos del estado del ventilador de muestra (OFF: verde; ON: rojo; CLOGGED: azul; FRICTION: amarillo). [Nota: Código truncado por motivos de presentación]. (Fuente de la imagen: Stephen Evanczuk, ejecutando Jupyter Notebook ML_State_Monitor.ipynb de NXP)

Otras secciones de código proporcionan más análisis de datos, normalización, conformación y otros preparativos hasta que la ejecución del código llega a la misma definición de la función de creación del modelo, model_create(), mostrada anteriormente en el Listado 1. La siguiente sección de código ejecuta esta función model_create() e imprime un resumen para una rápida validación (Figura 13).

Figura 13: El Jupyter Notebook ML_State_Monitor.ipynb de NXP crea el modelo (mostrado en el Listado 1) y muestra la información del resumen del modelo. (Fuente de la imagen: Stephen Evanczuk, ejecutando el Jupyter Notebook ML_State_Monitor.ipynb de NXP)

Tras una sección de código para el entrenamiento y la evaluación del modelo, el Jupyter Notebook ML_State_Monitor.ipynb muestra cada matriz de confusión para el conjunto de datos completo, el conjunto de datos de entrenamiento y el conjunto de datos de validación (un subconjunto del conjunto de datos excluido del conjunto de datos de entrenamiento). En este caso, la matriz de confusión para el conjunto de datos completo muestra una buena precisión con cierta cantidad de errores, sobre todo cuando el modelo confunde un pequeño porcentaje de conjuntos de datos como si estuvieran en el estado ON cuando en realidad están en el estado CLOGGED, como se anota en el conjunto de datos original (Figura 14).

Figura 14: Los desarrolladores pueden ver matrices de confusión como esta para el conjunto de datos completo. (Fuente de la imagen: Stephen Evanczuk, ejecutando el Jupyter Notebook ML_State_Monitor.ipynb de NXP)

En una sección de código posterior, el modelo se exporta a varios tipos de modelos y formatos diferentes utilizados por los distintos motores de inferencia que admite el entorno de desarrollo de eIQ (Figura 15).

Figura 15: El Jupyter Notebook ML_State_Monitor.ipynb de NXP demuestra cómo los desarrolladores pueden guardar su modelo entrenado en varios tipos de modelos y formatos diferentes. (Fuente de la imagen: Stephen Evanczuk, ejecutando elJupyter Notebook ML_State_Monitor.ipynb de NXP)

La elección del motor de inferencia puede ser muy importante para cumplir con los requisitos de rendimiento específicos. Para esta aplicación, NXP midió el tamaño del modelo, el tamaño del código y el tiempo de inferencia (tiempo necesario para completar la inferencia sobre un único objeto de entrada) cuando el modelo se dirige a varios motores de inferencia, uno que funciona a 996 megahercios (MHz) y otro que funciona a 156 MHz (Figuras 16 y 17).

Figura 16: La elección del tipo de modelo puede influir drásticamente en el tamaño del mismo, aunque las diferencias drásticas que se muestran aquí podrían no aplicarse a los modelos más grandes. (Fuente de la imagen: NXP Semiconductors)

Figura 17: El tiempo de inferencia puede diferir significativamente para la evaluación de un objeto de entrada cuando se carga desde la RAM o la memoria flash, o cuando se opera el procesador a una frecuencia más alta de 996 MHz frente a 156 MHz. (Fuente de la imagen: NXP Semiconductors)

Como señala NXP, esta aplicación de ejemplo utiliza un modelo muy pequeño, por lo que las diferencias bastante marcadas que se muestran en estas cifras podrían ser sustancialmente menos pronunciadas en un modelo más grande utilizado para clasificaciones complejas.

Creación de una solución de sistema para la supervisión del estado

Además del cuaderno Jupyter para la exploración interactiva del flujo de trabajo de desarrollo del modelo, el paquete SW de la aplicación NXP ML State Monitoring proporciona el código fuente completo para implementar el diseño en la placa de evaluación MIMXRT1170-EVK de NXP. Construida en torno a una MCU cruzada NXP MIMXRT1176DVMAA, la placa de evaluación proporciona una plataforma de hardware completa, con memoria adicional y múltiples interfaces (Figura 18).

Figura 18: La placa de evaluación MIMXRT1170-EVK de NXP ofrece una completa plataforma de hardware para el desarrollo de aplicaciones basadas en la MCU cruzada de la serie NXP i.MX RT1170. (Fuente de la imagen: NXP Semiconductors)

Los desarrolladores pueden utilizar la aplicación de estado del ventilador de NXP para predecir el estado de un ventilador apilando la placa de evaluación MIMXRT1170-EVK con una placa de sensores opcional NXP FRDM-STBC-AGM01, un escudo Arduino y un ventilador de 5 voltios de corriente continua sin escobillas adecuado, como el 4468 de Adafruit (Figura 19).

Figura 19: Los desarrolladores pueden probar la aplicación de ejemplo del estado del ventilador de NXP con una simple pila construida en la placa de evaluación MIMXRT1170-EVK. (Fuente de la imagen: NXP Semiconductors)

Utilizando el entorno de desarrollo integrado (IDE) de MCUXpresso, los desarrolladores pueden configurar la aplicación para que simplemente adquiera y almacene los datos del estado del ventilador, o ejecute inmediatamente la inferencia sobre los datos adquiridos utilizando un motor de inferencia TensorFlow, un motor de inferencia DeepViewRT o un motor de inferencia Glow (Listado 2).

Copiar
/* Action to be performed */
#define SENSOR_COLLECT_LOG_EXT                  1   // Collect and log data externally
#define SENSOR_COLLECT_RUN_INFERENCE            2   // Collect data and run inference
 
/* Inference engine to be used */
#define SENSOR_COLLECT_INFENG_TENSORFLOW        1   // TensorFlow
#define SENSOR_COLLECT_INFENG_DEEPVIEWRT        2   // DeepViewRT
#define SENSOR_COLLECT_INFENG_GLOW              3   // Glow
 
/* Data format to be used to feed the model */
#define SENSOR_COLLECT_DATA_FORMAT_BLOCKS       1   // Blocks of samples
#define SENSOR_COLLECT_DATA_FORMAT_INTERLEAVED  2   // Interleaved samples
 
 
/* Parameters to be configured by the user: */
/* Configure the action to be performed */
#define SENSOR_COLLECT_ACTION                   SENSOR_COLLECT_RUN_INFERENCE
 
#if SENSOR_COLLECT_ACTION == SENSOR_COLLECT_LOG_EXT
/* If the SD card log is not enabled the sensor data will be streamed to the terminal */
#define SENSOR_COLLECT_LOG_EXT_SDCARD           1   // Redirect the log to SD card, otherwise print to console

Listado 2: Los desarrolladores pueden configurar fácilmente la aplicación de ejemplo NXP ML State Monitor modificando las definiciones incluidas en el archivo de cabecerasensor_collect.h. (Fuente del código: NXP Semiconductors)

La aplicación funciona con un flujo de procesos sencillo. La rutina principal en main.c crea una tarea llamada MainTask, que es una rutina ubicada en el módulo sensor_collect.c.

Copiar
void MainTask(void *pvParameters)
{
    status_t status = kStatus_Success;
 
    printf("MainTask started\r\n");
 
#if !SENSOR_FEED_VALIDATION_DATA
    status = SENSOR_Init();
    if (status != kStatus_Success)
    {
        goto main_task_exit;
    }
#endif
 
    g_sensorCollectQueue = xQueueCreate(SENSOR_COLLECT_QUEUE_ITEMS, sizeof(sensor_data_t));
    if (NULL == g_sensorCollectQueue)
    {
        printf("collect queue create failed!\r\n");
        status = kStatus_Fail;
        goto main_task_exit;
    }
 
#if SENSOR_COLLECT_ACTION == SENSOR_COLLECT_LOG_EXT
    uint8_t captClassLabelIdx;
    CAPT_Init(&captClassLabelIdx, &g_SensorCollectDuration_us, &g_SensorCollectDuration_samples);
    g_SensorCollectLabel = labels[captClassLabelIdx];
 
    if (xTaskCreate(SENSOR_Collect_LogExt_Task, "SENSOR_Collect_LogExt_Task", 4096, NULL, configMAX_PRIORITIES - 1, NULL) != pdPASS)
    {
        printf("SENSOR_Collect_LogExt_Task creation failed!\r\n");
        status = kStatus_Fail;
        goto main_task_exit;
    }
#elif SENSOR_COLLECT_ACTION == SENSOR_COLLECT_RUN_INFERENCE
    if (xTaskCreate(SENSOR_Collect_RunInf_Task, "SENSOR_Collect_RunInf_Task", 4096, NULL, configMAX_PRIORITIES - 1, NULL) != pdPASS)
    {
        printf("SENSOR_Collect_RunInf_Task creation failed!\r\n");
        status = kStatus_Fail;
        goto main_task_exit;
    }
#endif

Listado 3: En la aplicación de ejemplo NXP ML State Monitor, MainTask invoca una subtarea para adquirir datos o ejecutar inferencia. (Fuente del código: NXP Semiconductors)

MainTask realiza varias tareas de inicialización antes de lanzar una de las dos subtareas, dependiendo de las definiciones establecidas por el usuario en sensor_collect.h:

• si SENSOR_COLLECT_ACTION se establece como SENSOR_COLLECT_LOG_EXT, MainTask inicia la subtarea SENSOR_Collect_LogExt_Task(), que recoge los datos y los almacena en la tarjeta SD si está configurada
• si SENSOR_COLLECT_ACTION se establece como SENSOR_COLLECT_RUN_INFERENCE, MainTask inicia la subtarea SENSOR_Collect_RunInf_Task(), que ejecuta el motor de inferencia (Glow, DeepViewRT, o TensorFlow) definido en sensor_collect.h contra los datos recogidos, y si SENSOR_EVALUATE_MODEL está definido, muestra el rendimiento resultante y la predicción de clasificación

Copiar
if SENSOR_COLLECT_ACTION == SENSOR_COLLECT_LOG_EXT
void SENSOR_Collect_LogExt_Task(void *pvParameters)
{
[code deleted for simplicity]
    while (1)
    {
[code deleted for simplicity]
            bufSizeLog = snprintf(buf, bufSize, "%s,%ld,%d,%d,%d,%d,%d,%d,%d\r\n", g_SensorCollectLabel, (uint32_t)(sensorData.ts_us/1000),
                    sensorData.rawDataSensor.accel[0], sensorData.rawDataSensor.accel[1], sensorData.rawDataSensor.accel[2],
                    sensorData.rawDataSensor.mag[0], sensorData.rawDataSensor.mag[1], sensorData.rawDataSensor.mag[2],
                    sensorData.temperature);
 
#if SENSOR_COLLECT_LOG_EXT_SDCARD
                SDCARD_CaptureData(sensorData.ts_us, sensorData.sampleNum, g_SensorCollectDuration_samples, buf, bufSizeLog);
#else
                printf("%.*s", bufSizeLog, buf);
[code deleted for simplicity]
    }
 
    vTaskDelete(NULL);
}
#elif SENSOR_COLLECT_ACTION == SENSOR_COLLECT_RUN_INFERENCE
[code deleted for simplicity]
 
void SENSOR_Collect_RunInf_Task(void *pvParameters)
{
[code deleted for simplicity]
    while (1)
    {
[code deleted for simplicity]
                /* Run Inference */
                tinf_us = 0;
                SNS_MODEL_RunInference((void*)g_clsfInputData, sizeof(g_clsfInputData), (int8_t*)&predClass, &tinf_us, SENSOR_COLLECT_INFENG_VERBOSE_EN);
 
[code deleted for simplicity]
#if SENSOR_EVALUATE_MODEL
                /* Evaluate performance */
                validation.predCount++;
                if (validation.classTarget == predClass)
                {
                    validation.predCountOk++;
                }
                PRINTF("\rInference %d?%d | t %ld us | count: %d/%d/%d | %s      ",
                       validation.classTarget, predClass, tinf_us, validation.predCountOk,
                       validation.predCount, validation.predSize, labels[predClass]);
 
                tinfTotal_us += tinf_us;
                if (validation.predCount >= validation.predSize)
                {
                    printf("\r\nPrediction Accuracy for class %s %.2f%%\r\n", labels[validation.classTarget],
                            (float)(validation.predCountOk * 100)/validation.predCount);
                    printf("Average Inference Time %.1f (us)\r\n", (float)tinfTotal_us/validation.predCount);
                    tinfTotal_us = 0;
                }
#endif
 
    }
 
exit_task:
    vTaskDelete(NULL);
}
#endif  /* SENSOR_COLLECT_ACTION */

Listado 4: La aplicación de ejemplo NXP ML State Monitor demuestra el patrón de diseño básico para adquirir datos de sensores y ejecutar el motor de inferencia seleccionado en los datos adquiridos. (Fuente del código: NXP Semiconductors)

Dado que el paquete SW de la aplicación NXP ML State Monitor proporciona el código fuente completo junto con un conjunto completo de controladores y middleware necesarios, los desarrolladores pueden ampliar fácilmente la aplicación para añadir funciones o utilizarla como punto de partida para su propio desarrollo personalizado.

Conclusión:

La implementación de ML en el borde en productos inteligentes en el IoT y otras aplicaciones puede proporcionar un poderoso conjunto de características, pero a menudo ha dejado a los desarrolladores luchando por aplicar herramientas y métodos de ML desarrollados para aplicaciones a escala empresarial. Gracias a la disponibilidad de una plataforma de desarrollo de NXP que incluye procesadores cruzados y software de desarrollo de modelos especializado, tanto los expertos en ML como los desarrolladores con poca o ninguna experiencia en este campo pueden crear con mayor eficacia aplicaciones de ML diseñadas específicamente para cumplir los requisitos de rendimiento eficiente de los bordes.