TinyML en action : Jon Norby sur emlearn, Zephyr et Edge AI
À l’approche de la conférence en ligne Elektor « Zephyr – The Open RTOS for Future Devices« , qui se tiendra en novembre, nous nous sommes entretenus avec Jon Nordby, cofondateur de Soundsensing et créateur de la bibliothèque TinyML open-source emlearn. Dans cette conversation, Jon partage ses idées sur le déploiement de l’apprentissage automatique dans les microcontrôleurs, sur la façon dont Zephyr RTOS permet de créer des appareils plus intelligents.
Elektor : Quels ont été les plus grands défis techniques auxquels vous avez dû faire face lorsque vous avez conçu emlearn pour qu’il fonctionne sur une gamme aussi large d’appareils avec seulement un compilateur C99 à disposition ?
John Nordby : emlearn s’efforce de garder les choses aussi simples que possible. Par exemple, nous utilisons du code C portable au lieu d’effectuer de nombreuses optimisations spécifiques à l’appareil ou à l’architecture. Heureusement, le code C99 est aujourd’hui très largement supporté. Nous prenons en charge certaines architectures de réseaux neuronaux standard, mais pas les réseaux neuronaux/graphes de calcul arbitraires. Cela limite le nombre de défis techniques que nous devons relever et permet à une petite équipe de maintenir la qualité et la maintenabilité du projet.
Elektor : Comment conciliez-vous la précision des modèles avec les contraintes de mémoire et d’énergie des composants embarqués lorsque vous convertissez des modèles de scikit-learn ou de Keras ?
John Nordby : emlearn vise à optimiser l’inférence pour les modèles les plus populaires. En général, nous y parvenons en supportant l’arithmétique en virgule fixe et en effectuant autant de calculs préalables que possible pendant le processus d’apprentissage, afin de simplifier les calculs nécessaires pendant l’inférence. Nous avons également quelques optimisations spécifiques pour des modèles particuliers, qui ne sont pas largement répandus. mis en œuvre ailleurs. Par exemple, l’inférence pour les ensembles d’arbres de décision (Random Forest, etc.) prend en charge le vote doux avec des valeurs de feuilles quantifiées (probabilités de classe), ce qui permet d’avoir un petit modèle sans perdre en précision comme le fait le vote dur. Nous travaillons sur un rapport technique qui décrit cela plus en détail.
Il existe d’autres aspects très importants pour trouver un bon compromis entre la performance prédictive du modèle et les coûts de calcul, tels que les hyperparamètres du modèle, la sélection des caractéristiques et l’ingénierie/le prétraitement des caractéristiques. Ces aspects sortent du cadre d’emlearn en tant qu’outil, mais nous essayons d’inclure des indications utiles sur ces sujets dans notre documentation.
Elektor : Quels types de données de capteurs (par exemple, audio, vibration, radar) ont été les plus difficiles à modéliser efficacement avec TinyML, et comment emlearn a-t-il relevé ces défis ?
John Nordby : emlearn est plutôt agnostique quant à la nature des données d’entrée, puisque l’utilisateur doit fournir le code d’extraction des caractéristiques. Il est donc plus facile de l’appliquer à des domaines de données et à des tâches où l’on peut trouver des références pour l’extraction de caractéristiques appropriées. Les données audio et les données d’accéléromètre sont très courantes, par exemple, alors que les données radar le sont un peu moins (d’après mon expérience). La recherche d’articles dans Google Scholar ou l’utilisation de votre LLM favori est une bonne approche dans ce cas. La documentation contient également des liens vers des projets utilisant emlearn, décrivant comment ils se sont adaptés aux données qu’ils ont utilisées.
Elektor : Quels avantages uniques Zephyr RTOS apporte-t-il aux déploiements de TinyML que vous ne voyez généralement pas dans d’autres plates-formes RTOS ?
John Nordby : Zephyr fournit une couche d’abstraction matérielle (HAL) portable et offre un support intégré pour de nombreuses options de connectivité, avec de nombreux pilotes inclus. Ceci est en dehors du champ d’application de beaucoup d’autres plateformes RTOS, et est donc relativement unique à Zephyr. L’utilisation de la couche d’abstraction matérielle de Zephyr facilite l’accès aux données des capteurs, ce qui est essentiel dans les applications TinyML. Et de nombreuses applications TinyML envoient généralement les résultats des modèles via BLE, WiFi, LoRa, etc. J’apprécie également la bonne prise en charge intégrée des systèmes de fichiers, car elle est très utile pour la collecte de données et la validation du pipeline de traitement des données.
Elektor : Pourriez-vous nous donner un exemple concret de la façon dont l’API de capteurs de Zephyr s’intègre à emlearn dans une application réelle ?
John Nordby : Le cas d’utilisation le plus simple est celui où il existe une correspondance univoque entre les données de capteur à lire et l’exécution du modèle d’apprentissage automatique. Par exemple, si vous construisez un appareil qui trie les objets par couleur (par exemple M&Ms ou Skittles). Vous pouvez alors faire quelques appels à l’API « Fetch and Get » du capteur Zephyr pour collecter le rouge, le vert et le bleu, et placer ces valeurs (les caractéristiques) dans un tableau à trois éléments. Vous passez ensuite ces valeurs de caractéristiques dans la fonction skittels_detect_predict() créée par emlearn.convertet vous obtiendrez en sortie la classification. En fonction de la valeur de la classe, vous pouvez par exemple piloter un servo pour trier tous les violets.
Une autre famille de tâches courantes consiste à utiliser des données de capteurs temporels, tels qu’un accéléromètre ou des données audio. Dans ce scénario, on souhaite généralement lire des blocs de données de longueur fixe au lieu de mesures individuelles, de quelques millisecondes à quelques secondes en fonction de la tâche. Avec l’API capteur de Zephyr, il y a deux façons d’y parvenir : Soit via la nouvelle API de capteur Read & Decode pour obtenir de tels blocs de données. directement, ou en utilisant un thread dédié de priorité supérieure qui appelle Fetch et Get à plusieurs reprises pour construire un morceau, qui est ensuite transmis au thread d’inférence du modèle (via une file d’attente).
Je suis en train de travailler sur des exemples de code pour les illustrer en pratique dans le cadre de mon prochain exposé. Notez que l’audio et la vidéo ont des APIs dédiées basées sur les chunk dans Zephyr qui sont préférées à l’API générique des capteurs.
Elektor : D’après vous, quels sont les secteurs ou les domaines qui bénéficieront le plus de l’adoption de TinyML au cours des cinq prochaines années ?
John Nordby : Je pense qu’il est pertinent dans la plupart des domaines qui ont besoin d’ingérer et d’analyser automatiquement de grandes quantités de données de capteurs. En ce sens, il y a beaucoup de chevauchement avec les applications ou les industries qui ont beaucoup bénéficié des technologies connexes, comme les capteurs MEMS (systèmes micro-électro-mécaniques) et les réseaux de capteurs sans fil. Mais la caractéristique clé qui rend TinyML particulièrement pertinent est lorsque le taux de données d’entrée (du capteur) est relativement élevé, mais que les données de sortie doivent être assez faibles. Par exemple, lorsque vous utilisez des capteurs audio/vidéo/radar/IMU, mais fonctionnant sur batterie et transmettant via un protocole à faible consommation tel que LoRa. D’autres préoccupations, telles que la protection de la vie privée, limitent la capacité à transmettre les données brutes des capteurs.
Pour plus d’informations sur la conférence en ligne d’Elektor « Zephyr – The Open RTOS for Tomorrow’s Devices » du 5 novembre, consultez le site web de la conférence.
Note de l’éditeur : ECInews est une publication d’Elektor International Media.
Si vous avez apprécié cet article, vous aimerez les suivants : ne les manquez pas en vous abonnant à :
