Nuremberg, Allemagne, le 6 mars 2026 – Savoir-faire Linux, une société leader dans le domaine de l’ingénierie logicielle open source spécialisée dans les systèmes embarqués et industriels, annonce lors du salon Embedded World 2026 le lancement officiel de ses services d’ingénierie Edge AI. S’appuyant sur plus de 25 ans d’expertise dans les technologies Linux embarquées et open source, la société propose désormais des services de conseil et de développement dédiés, axés sur le déploiement de l’intelligence artificielle directement sur les appareils embarqués.

Aujourd’hui, l’accélération rapide de l’innovation en IA est largement portée par l’écosystème open source, depuis les frameworks d’apprentissage profond jusqu’aux architectures de modèles et aux unités d’accélération matérielle. Pour les entreprises développant des systèmes embarqués, tirer parti de cet écosystème nécessite une expertise approfondie tant dans les piles logicielles d’IA que dans les plateformes matérielles embarquées. Savoir-faire Linux allie ces deux compétences, aidant les organisations industrielles à transformer l’innovation open source en IA vers des systèmes robustes, prêts pour la production.

L’IA embarquée, une capacité stratégique pour l’industrie

Pour de nombreux secteurs, dont la robotique, la fabrication, les transports et les infrastructures intelligentes, l’IA embarquée devient rapidement une capacité essentielle.

« L’intelligence artificielle migre rapidement des environnements cloud centralisés vers des systèmes embarqués opérant directement sur le terrain, » déclare Jérôme Oufella, vice-président technologie chez Savoir-faire Linux. « Une grande partie de cette innovation provient des écosystèmes open source. Chez Savoir-faire Linux, l’open source est au cœur de notre culture d’ingénierie, et notre expertise réside dans la transformation de ces technologies en solutions d’IA embarquée robustes, optimisées pour les contraintes industrielles réelles. »

Pour illustrer les capacités de cette nouvelle offre, Savoir-faire Linux présentera deux démonstrations en direct à son stand (Hall 4 – 4-642), mettant en lumière comment des traitements IA intensifs peuvent fonctionner efficacement sur des plateformes embarquées aux ressources limitées. Ces démonstrations soulignent les défis d’ingénierie et les optimisations matérielles-logicielles nécessaires pour atteindre des performances temps réel déterministes au plus près du terrain.

Démo 1 – Estimation de profondeur monoculaire en temps réel sur Toradex i.MX95

La première démonstration présente une estimation de la profondeur monoculaire en temps réel à une cadence de 30 images par seconde sur la plateforme Toradex Verdin i.MX95. À l’aide d’une simple caméra RGB, le système génère une carte de profondeur de la scène en temps réel en exploitant l’unité de traitement neuronal Neutron (NPU) intégrée au NXP i.MX95.

Cette approche élimine le besoin de capteurs coûteux comme les LiDAR ou les systèmes de caméras stéréo, réduisant ainsi la complexité du système et les coûts matériels. Fonctionnant entièrement en local sur le dispositif, le système permet des capacités avancées de perception pour des applications telles que la navigation de robots mobiles autonomes, l’assistance à la conduite de chariots élévateurs, l’inspection dimensionnelle sur convoyeurs ou la détection d’obstacles et de collisions. Pour atteindre ces performances, une optimisation poussée du modèle ciblant l’architecture NPU a été nécessaire. Les ingénieurs de Savoir-faire Linux ont adapté le modèle d’estimation de profondeur pour éviter les retours vers le CPU et ont repensé les pipelines de post-traitement afin de maintenir une inférence stable à 30 FPS.

« Déployer l’IA sur des systèmes aux ressources limitées ne se résume pas à exécuter un réseau de neurones, » explique le Dr. Thomas Garbay, expert en IA embarquée chez Savoir-faire Linux. « Cela nécessite une optimisation approfondie de l’ensemble de la pile logicielle, de l’architecture du modèle à la compilation matérielle, en passant par le post-traitement en temps réel. Cette démonstration montre comment une co-conception minutieuse entre le matériel et le logiciel permet une IA spatiale fiable directement sur des plateformes embarquées. »

Démo 2 – Segmentation d’instances en temps réel sur Renesas V2H

La deuxième démonstration présente une segmentation d’instances fonctionnant sur la plateforme Renesas V2H à l’aide d’un réseau de neurones YOLO optimisé pour le matériel embarqué. La segmentation d’instances fournit des contours au niveau des pixels pour chaque objet dans une scène, permettant une identification, une localisation et un comptage précis, même lorsque les objets se chevauchent. De telles capacités sont de plus en plus requises dans les environnements industriels pour des applications comme l’inspection automatisée des lignes de production, la robotique de picking, l’automatisation logistique ou le contrôle du port des équipements de protection individuelle.

Pour permettre des performances en temps réel sur une plateforme embarquée contrainte, les ingénieurs de Savoir-faire Linux ont exploité l’accélérateur matériel DRP-AI de Renesas et appliqué des techniques agressives d’élagage, réduisant le réseau de neurones de 70 à 90 % tout en maintenant la précision du modèle. Une optimisation supplémentaire du post-traitement des masques de segmentation a significativement réduit la latence d’inférence, démontrant comment des charges de travail avancées en vision par ordinateur peuvent fonctionner de manière fiable sur des plateformes embarquées, sans dépendre d’une infrastructure cloud.

Une nouvelle pratique d’ingénierie pour l’IA embarquée

Le lancement des services d’IA embarquée de Savoir-faire Linux répond à une demande croissante des fabricants industriels cherchant à intégrer l’intelligence artificielle directement dans les appareils connectés et les systèmes embarqués. La nouvelle offre de l’entreprise couvre l’ensemble du cycle de vie de l’IA embarquée, incluant :

• L’optimisation des modèles et l’accélération matérielle (quantification, élagage, compilation NPU)
• Les pipelines de vision par ordinateur et d’IA pilotées par capteurs
• Le MLOps pour les grandes flottes d’appareils embarqués
• La co-conception matériel-logiciel pour les systèmes d’IA embarquée
• L’entraînement de modèles d’IA sur des données et domaines spécifiques
• Le conseil en ingénierie et l’accompagnement des équipes.

En combinant une expertise approfondie des systèmes embarqués avec l’optimisation des modèles d’IA, Savoir-faire Linux permet aux organisations de déployer des solutions d’IA haute performance, à faible latence et directement sur les appareils, garantissant fiabilité, souveraineté et une dépendance réduite aux infrastructures cloud.

Retrouvez-nous à l’Embedded World 2026

Savoir-faire Linux invite les visiteurs, journalistes et analystes du secteur présents à l’Embedded World à visiter son stand (Hall 4 – Stand 4-642) pour découvrir les démonstrations en direct et discuter des stratégies de déploiement de l’IA embarquée avec son équipe d’ingénierie. Thomas Garbay, expert en IA embarquée, et Jérôme Oufella, vice-président technologie, seront disponibles tout au long de l’événement pour présenter les démonstrations et échanger avec les visiteurs sur les défis techniques du déploiement de l’IA dans les environnements embarqués.

Liens utiles

• Services d’ingénierie en IA embarquée : https://savoirfairelinux.com/fr/services/edge-ai
• Autres articles de blog publiés sur le sujet :
  • https://blog.savoirfairelinux.com/fr-ca/2026/generation-donnees-lidar-synthetiques-detection-temps-reel/
  • https://blog.savoirfairelinux.com/fr-ca/2026/detection-temps-reel-systeme-lidar-entrainement/

The post Savoir-faire Linux lance ses services d’ingénierie en IA embarquée à l’Embedded World 2026 appeared first on Blogue de Savoir-faire LInux.

Il s’agit du deuxième volet d’une série en trois parties consacrée à la détection temps réel sur système LiDAR. Retrouvez ici l’article 1 sur la génération de jeux de données synthétiques de profondeur et NIR.

Actuellement, de nouveaux LiDAR embarqués à basse résolution, tels que le VL53L9CX, émergent comme une option particulièrement adaptée pour la détection temps réel sur système LiDAR. Cette matrice de $54\times 42$ pixels fournit simultanément des données de profondeur basse consommation, d’infrarouge et d’illumination active. Dans ce contexte, l’intégration d’un modèle YOLO optimisé permet de transformer ces signaux pour la détection temps réel sur système LiDAR.

Nous commençons cet article par une brève introduction à YOLO. Nous menons ensuite une étude exploratoire évaluant la précision de YOLO sur plusieurs jeux de données. L’objectif est d’analyser l’impact des différentes modalités d’image. Les expériences d’entraînement ont été réalisées à partir d’entrées de profondeur relative, de profondeur absolue, de proche infrarouge (NIR) et multimodales (profondeur + NIR). Pour les détails concernant la génération de ces jeux de données, nous renvoyons le lecteur à l’article 1 de cette série. Enfin, nous abordons l’optimisation des hyperparamètres de YOLO afin d’obtenir les meilleures performances possibles compte tenu des caractéristiques des données d’entrée.

Introduction à YOLO et YOLOv8 : vision par ordinateur en temps réel

Dans le domaine de la vision par ordinateur, YOLO (You Only Look Once) a fondamentalement transformé la manière dont les machines perçoivent le monde visuel. Plus précisément, YOLO remplace les pipelines multi-traitements par une seule étape. Il effectue simultanément la proposition de régions d’intérêts et la classification. Par conséquent, cette architecture « one-shot » permet une inférence extrêmement rapide. Elle rend la détection temps réel sur système LiDAR possible.

L’évolution vers YOLOv8

YOLOv8, publié par Ultralytics en 2023, demeure l’état de l’art en matière d’équilibre entre précision et efficacité. Nous utilisons YOLOv8 plutôt que des versions plus récentes comme YOLO11 en raison de son meilleur support sur le matériel industriel, en particulier sur les plateformes NPU.

YOLOv8 introduit plusieurs améliorations architecturales clés :

• Architecture sans ancres : contrairement aux versions précédentes de YOLO, YOLOv8 prédit directement les centres des objets sans s’appuyer sur des boîtes d’ancrage prédéfinies. Cela améliore significativement la précision de détection, en particulier pour les silhouettes humaines aux postures et échelles variées.
• Backbone C2f : le module Cross-Stage Partial Bottleneck (C2f) améliore le flux de gradients tout en réduisant la complexité du modèle. Il en résulte des modèles plus légers avec de meilleures performances.
• Polyvalence native des tâches : au-delà de la détection de boîtes englobantes, YOLOv8 prend en charge nativement la segmentation d’instances et l’estimation de pose. Il offre ainsi une voie claire vers des tâches de perception et d’analyse comportementale plus avancées.

En résumé, YOLOv8 atteint une efficacité de Pareto supérieure en termes de latence-mAP lorsque l’on considère les jeux de données et l’exécution sur des plateformes embarquées. Cela le rend parfaitement adapté à la détection temps réel sur système LiDAR pour l’Edge AI.

Stratégies d’entraînement pour la détection en temps réel sur système LiDAR

Deux stratégies sont comparées afin de déterminer la meilleure approche pour un déploiement embarqué à haute performance. La stratégie 1 repose sur un mélange d’experts (Mixture of Experts, MoE). La stratégie 2 utilise un entraînement multimodal à modèle unique.

Stratégie 1 : Mixture of Experts (MoE)

Une approche Mixture of Experts (MoE) utilise deux modèles YOLOv8 parallèles, respectivement spécialisés sur les données de profondeur et de NIR. D’un point de vue méthodologique, cette stratégie est plus simple, chaque modèle étant optimisé pour une seule modalité.

Néanmoins, elle soulève plusieurs questions critiques. Premièrement, chaque modalité fournit-elle suffisamment d’informations discriminantes à ultra-basse résolution pour fonctionner de manière indépendante ? Deuxièmement, les architectures embarquées basse consommation peuvent-elles supporter des pipelines d’inférence concurrents avec des contraintes strictes de latence, de puissance et de mémoire ?

Stratégie 2 : entraînement multimodal à modèle unique

La seconde approche consiste à entraîner un seul modèle YOLOv8 sur des images d’entrée multimodales. Alors que les images RGB conventionnelles comportent trois canaux, nos entrées n’en contiennent que deux : la profondeur et le proche infrarouge (NIR). La mise en œuvre de cette stratégie implique de fusionner les modalités dans un nouveau jeu de données et d’adapter la chaîne d’entraînement à des représentations d’entrée personnalisées.

Le principal défi réside dans la capacité de généralisation du réseau à partir d’un entraînement avec cette modalité non conventionnelle. Toutefois, un pipeline à modèle unique réduit considérablement la charge de calcul et simplifie l’inférence sur des systèmes embarqués aux ressources limitées. Ce dernier point est significatif pour de la détection temps réel sur système LiDAR.

Vue d’ensemble des résultats expérimentaux

Nous présentons les résultats des entraînements suivants avec YOLOv8 sur trois jeux de données :

1. NIR, généré par inférence à l’aide du modèle Pix2Next.
2. Profondeur, produit par inférence à partir du modèle ZoeDepth.
3. Multimodal, où chaque image inclut simultanément des canaux de profondeur et de NIR.

Dans ce contexte, plusieurs variantes ont été évaluées selon ces stratégies. Nous avons comparé YOLOv8 et YOLO11 en entraînement from scratch et avec des poids pré-entraînés RGB (transfer learning). En outre, nous avons utilisé les topologies nano (n), small (s) et medium (m).

Le tableau suivant récapitule les modèles testés et met en évidence leurs performances de référence sur des images d’entrée en 640×640. Alors que le mAP ^{val 50–95} mesure la qualité et la cohérence de la détection, le nombre de paramètres et les FLOPs estiment le coût d’inférence. Toutefois, ces métriques nécessitent une contextualisation pour le déploiement sur NPU et les optimisations spécifiques au matériel pour de la détection temps réel sur système LiDAR.

Optimisation de l’entraînement : sélection et interprétation des bonnes métriques

Pour commencer, une évaluation complète des performances de YOLOv8 nécessite une approche multi-métriques plutôt que de s’appuyer sur un seul indicateur. L’objectif est d’optimiser le compromis entre la précision de localisation et la sensibilité de détection. Cela nous permettra d’ajuster efficacement l’entraînement de YOLO pour la détection temps réel sur système LiDAR.

Premièrement, les principales métriques de détection utilisées sont la précision et le rappel. La précision et le rappel constituent les métriques fondamentales de l’analyse de performance.

• Précision : quantifie la fiabilité du modèle en mesurant le ratio de détections correctes par rapport au nombre total de prédictions (minimisation des faux positifs).
• Rappel : mesure la sensibilité en calculant la proportion d’objets réels détectés avec succès. Un faible rappel reflète donc un nombre élevé de faux négatifs, lorsque le modèle ne détecte pas des objets existants.

En outre, le score F1 est la moyenne harmonique de la précision et du rappel. Il est particulièrement utile pendant l’entraînement, car il synthétise la performance globale en une seule valeur. Si le score F1 plafonne alors que la précision continue de s’améliorer, cela indique souvent une baisse du rappel. Cette information est précieuse pour ajuster le seuil de confiance afin de rééquilibrer précision et rappel.

Deuxièmement, une métrique spécifique à la détection d’objets est le mAP (mean Average Precision), qui constitue la référence standard pour comparer les modèles de détection. Il est calculé comme l’aire sous la courbe précision-rappel.

• MAP^{val 50} mesure la précision moyenne avec un seuil d’Intersection over Union (IoU) de 0,5. Elle reflète principalement la capacité du modèle à détecter les objets à un niveau grossier.
• MAP^{val 50-95} est une métrique stricte qui moyenne le mAP sur des seuils d’IoU allant de 0,5 à 0,95 ; des scores élevés reflètent un meilleur alignement des boîtes englobantes avec la vérité terrain.

YOLO sur le jeu de données NIR

Les premières expériences d’entraînement ont été menées sur un jeu de données comprenant 10 classes : [‘person’, ‘bench’, ‘backpack’, ‘bottle’, ‘cup’, ‘chair’, ‘tv’, ‘laptop’, ‘cell phone’, ‘book’].

Malheureusement, la détection a été limitée par la modalité NIR et par la faible résolution d’entrée de $54\times 42$. En conséquence, les MAP^{val 50-95} et MAP^{val 50} présentent de faibles performances pour cette modalité. De plus, la précision et le rappel sont également très bas, ce qui indique un taux élevé de faux positifs et de faux négatifs. Une analyse complémentaire à l’aide de la matrice de confusion normalisée fournit une vision plus fine des capacités de détection par classe du modèle. Elle met en évidence les classes les plus affectées et les zones de mauvaise classification. La matrice de confusion normalisée présentée correspond à un modèle YOLOv8s entraîné from scratch, servant de référence pour les améliorations ultérieures.

YOLOv8 sur le jeu de données de profondeur

Bien que la modalité NIR produise de meilleurs résultats de détection, les performances globales des modèles demeurent insuffisantes. Le MAP^{val 50-95} ne dépasse pas 0,25. La matrice de confusion présentée ci-dessus correspond à un modèle YOLOv8s entraîné from scratch sur le jeu de données de profondeur. Ces résultats préliminaires montrent qu’une approche MoE est difficilement optimisable pour la détection temps réel sur système LiDAR avec YOLO.

YOLOv8 sur un jeu de données multimodal

À la suite de ces premiers résultats d’entraînement, nous avons décidé d’abandonner le transfert d’apprentissage. Nous nous sommes concentrés sur l’entraînement des modèles from scratch. Les différences de performance étant marginales, nous avons cherché à spécialiser le modèle sur les modalités profondeur et NIR. En raison des faibles performances en mono-modalité, nous avons mis en place une fusion Depth-NIR à deux canaux pour l’entrée de YOLOv8. Cette représentation multimodale enrichit les données d’entrée avec des caractéristiques complémentaires. L’objectif final étant d’améliorer la performance de la détection temps réel sur système LiDAR.

Malgré l’entraînement sur deux modalités afin d’enrichir les caractéristiques extraites, les résultats ne sont pas encore satisfaisants. Actuellement, la différence de performance entre YOLOv8 et YOLOv11 n’est pas significative. En conséquence, nous avons privilégié le modèle offrant les meilleures performances sur le matériel cible, à savoir YOLOv8. Étant donné que YOLOv11 n’apporte aucun gain significatif en précision, la perte associée en efficacité matérielle n’est pas justifiée. Pour la détection temps réel sur système LiDAR pour l’Edge AI, les contraintes matérielles sont déterminantes et doivent être prises en compte dès les premières étapes.

De plus, certaines classes, telles que book et backpack, sont à peine détectées. La faible résolution et les contraintes de modalité empêchent une caractérisation fiable des objets. Par conséquent, nous avons décidé de réduire le périmètre de la tâche et de nous concentrer exclusivement sur la détection de personnes. Cette simplification permet de mieux contraindre le processus d’entraînement et d’améliorer la robustesse des modèles.

Optimisation de l’entraînement

Nous avons évalué trois tailles de modèles : nano (n), small (s) et medium (m), sur deux résolutions d’entrée : 224×224 et 54×42. Notre objectif était d’identifier le meilleur compromis entre performance et coût selon la taille du modèle et la résolution d’entrée. Cet équilibre est essentiel pour les contraintes de latence et ainsi permettre une détection temps réel sur système LiDAR. Nous avons automatisé le réglage des hyperparamètres. Pour cela, nous utilisons l’optimisation bayésienne avec YOLOv8 et Ray Tune. Contrairement à la recherche par grille, cette approche apprend des itérations précédentes afin d’explorer efficacement un espace de recherche continu et multidimensionnel. Enfin, la recherche d’hyperparamètres a été réalisée sur 15 itérations, suivie d’un entraînement avec une validation croisée à k=5. Les métriques de performance obtenues sont présentées ci-dessous.

Interprétation et conclusion

Ces résultats nous permettent d’analyser deux facteurs clés pour la détection temps réel sur système LiDAR : la résolution d’entrée et la complexité du modèle.

La réduction de la résolution d’entrée de 224 px à 54 px est significative sur l’ensemble des métriques. Le rappel est le plus affecté. Il passe de 0,48–0,53 à 224 px à seulement 0,32–0,36 à 54 px. Donc à basse résolution, le modèle ne détecte pas 65 % des personnes. La dégradation de la précision est moins marquée que celle du rappel. La baisse est d’environ 10 % (de ~0,78 à ~0,68–0,73).

Concernant la complexité du modèle, les résultats montrent une progression logique des performances. Cependant les gains sont marginaux. Le modèle medium (YOLOv8m) obtient la meilleure performance globale, en particulier le rappel le plus élevé à 224 px (0,528). Ce qui est notable: YOLOv8n se révèle étonnamment compétitif à 224 px, avec un mAP50 de 0,65 contre 0,68 pour YOLOv8m. En comparaison, à 54 px, les modèles plus grands comme YOLOv8m ne parviennent pas à compenser la perte d’information spatiale. Cette observation est déterminante pour orienter les prochaines étapes d’optimisation. En pratique, YOLOv8n à 224 px surpasse nettement YOLOv8m à 54 px sur l’ensemble des métriques.

Pour la détection temps réel sur système LiDAR, le meilleur compromis est atteint avec YOLOv8n à une résolution de 224×224. Cette configuration égale les performances de modèles plus volumineux. De plus, elle est optimisée pour une exécution en temps réel sur un matériel contraint. Nous allons désormais optimiser le processus d’entraînement. L’objectif est d’améliorer le rappel tout en maintenant les performances globales, en prenant YOLOv8n à 224×224 comme référence. Ce travail est en cours.

Le prochain article portera sur l’optimisation matérielle afin d’obtenir une inférence optimisée pour la détection en temps réel sur un système LiDAR.

The post Détection Temps Réel Système LiDAR : YOLO pour l’Edge AI appeared first on Blogue de Savoir-faire LInux.

Synthétiques

Cette série d’articles couvrira les éléments essentiels au déploiement d’un système de détection en temps réel avec un module dToF 3D LiDAR. Ce premier article est consacré à la génération de données LiDAR synthétiques.

• Génération de données LiDAR synthétiques pour la détection en temps réel

•  Détection Temps Réel Système LiDAR : YOLO pour l’Edge AI

• Déploiement sur une plateforme embarquée

L’intégration de modèles d’IA dans des plateformes embarquées permet désormais de nouveaux cas d’usage en vision par ordinateur, par exemple la robotique mobile ou la navigation autonome. Cependant, lorsque le système n’a pas accès à un flux RGB exploitable, e.g., dans des conditions de faible luminosité, il devient essentiel de s’appuyer sur des modalités de détection alternatives. L’exploitation des données de profondeur dToF et infrarouge garantit une détection robuste en temps réel pour les systèmes LiDAR embarqués.

En outre, un nouveau (à la date d’écriture de cet article en 2026) module embarqué dToF 3D LiDAR basse résolution, tels que le VL53L9CX, émerge comme une option particulièrement adaptée aux systèmes robotiques. Sa matrice 54 × 42 fournit simultanément des données de profondeur, d’intensité NIR et d’illumination active avec une empreinte énergétique minimale.

Ensuite, une architecture YOLO adaptée couplée à des données LiDAR brutes permet une perception en temps réel. L’implémentation matérielle devient un défi clé à ce stade. C’est pourquoi l’exploitation d’accélérateurs matériels tels que les NPU est essentielle. Cela garantira une détection en temps réel sur des systèmes LiDAR basse consommation.

Finalement, la qualité des données d’entraînement détermine directement les performances du modèle de détection. Cependant, collecter et annoter des données LiDAR même à basse résolution, est coûteux et difficile à mettre à l’échelle. Une alternative consiste en la génération de données LiDAR synthétiques. L’objectif est de permettre un prototypage rapide de la solution.

Génération de Données LiDAR Synthétiques pour la Détection en Temps Réel

Les jeux de données LiDAR existants proviennent principalement de capteurs 3D haute densité produisant des millions de points. Ceux-ci sont couramment utilisés dans la conduite autonome. De tels formats ne peuvent être ni capturés ni exploités sur des systèmes embarqués fortement contraints. En particulier dans notre cas, le matériel cible est le VL53L9CX, un LiDAR dToF produisant une matrice 2D de 54 × 42 pixels. Un entraînement adapté à nos contraintes nécessite donc des données de profondeur et d’infrarouge proche de la réponse NIR, à 940 nm, du capteur.

Cependant, collecter et annoter des données LiDAR à basse résolution reste un processus coûteux et lent. La génération de données LiDAR synthétiques est donc une approche efficace pour un entrainement de modèles d’IA. Parallèlement, les labels sont des éléments essentiels à la bonne exploitation des données générées. Ici, nous exploitons les labels du jeu de données COCO en ne convertissant que la modalité d’image : de RGB vers profondeur et NIR. En utilisant le jeu de données COCO, nous préservons les boîtes englobantes et les classes d’origine. La structure de la scène reste identique, seule la modalité change. La figure suivante illustre une image du jeu de données COCO en RGB original. En comparaison, la même image est traduite en modalités profondeur et NIR, avec les mêmes labels.

Implémentation Technique de la Génération Synthétique

Nous nous appuyons sur des modèles open-source spécialisés pour la génération de données LiDAR synthétiques :

• Pix2Next pour générer des images NIR cohérentes avec les caractéristiques optiques du capteur.

• ZoeDepth et DepthAnythingV2 pour produire respectivement des cartes de profondeur absolue et relative.

Génération de Données NIR

Pix2Next est une extension de la famille de modèles Pix2Pix, en intégrant des Modèles de Fondation pour la Vision – Vision Foundation Models. Ces modèles servent d’extracteurs de caractéristiques. Ils utilisent l’attention croisée dans une architecture encodeur-décodeur. Cette approche améliore significativement la cohérence visuelle des images NIR synthétiques. Particulièrement dans des conditions de faible luminosité ou d’illumination partielle qui sont des régimes de fonctionnement typiques pour les capteurs dToF. Le diagramme suivant illustre l’architecture Pix2Next :

Il s’agit d’un réseau antagoniste génératif – Generative Adversarial Network (GAN) – conçu pour la traduction RGB vers NIR. Il se compose d’un générateur et d’un discriminateur. De plus, un extracteur de caractéristiques renforce la représentation globale. La compétition entre le générateur (qui tente de tromper) et le discriminateur (qui tente de détecter les faux) guide la génération d’images NIR de haute fidélité.

Détails de l’architecture Pix2Next :

Générateur : une architecture Encodeur–Goulot d’étranglement–Décodeur prend une image RGB en entrée et produit une image NIR en sortie. L’encodeur utilise des blocs résiduels et des couches de sous-échantillonnage. L’objectif est de réduire progressivement les dimensions spatiales tout en extrayant les caractéristiques essentielles. Ces caractéristiques compressées atteignent le goulot d’étranglement : trois blocs résiduels représentant l’image à sa résolution la plus basse. Le décodeur utilise ensuite des blocs résiduels et des couches de sur-échantillonnage pour restaurer la résolution spatiale.

L’attention croisée permet aux caractéristiques de l’encodeur et du décodeur d’interagir avec la représentation globale de la scène provenant de l’extracteur. Cela améliore grandement la cohérence de la sortie NIR finale.

Extracteur : capture la sémantique de haut niveau de l’entrée RGB en utilisant des architectures de vision puissantes telles que ViT, SwinV2 ou InternImage. Il produit une représentation globale qui agit comme un résumé sémantique de l’image. Cela améliore la qualité de la génération NIR.

Discriminateur : évalue le réalisme des images NIR générées en les comparant avec la vérité terrain NIR réelle. Il opère à plusieurs échelles (D1, D2, D3). Cela permet l’évaluation de la qualité de l’image depuis les détails fins (haute résolution) jusqu’aux structures globales (basse résolution).

Génération de données de profondeur

Nous utilisons deux modèles complémentaires :

• ZoeDepth : estimation de profondeur absolue, directement corrélée à la distance capteur-objet.

• DepthAnythingV2 : estimation de profondeur relative, décrivant la structure de la scène indépendamment de l’échelle.

ZoeDepth est une architecture conçue pour générer des cartes de profondeur absolue à partir d’une seule image RGB. La profondeur absolue est la distance réelle entre l’objet et la caméra. Elle répond à une limitation majeure des modèles classiques d’estimation de profondeur. En effet, elle fournit des mesures directement utilisables dans des applications critiques telles que la robotique ou la navigation autonome. Aperçu du modèle Zoe :

Son architecture comprend deux composants : (1) une structure encodeur-décodeur qui capture la profondeur relative, et (2) un module d’intervalles métriques – Metric Bins Module qui convertit celle-ci en profondeur absolue.

Détails de l’architecture Zoe :

Encodeur-décodeur : l’encodeur, basé sur des architectures puissantes telles que BEiT ou SwinV2, extrait les caractéristiques clés. Le décodeur reconstruit une carte de profondeur relative (ordre des objets : qui est devant), en utilisant des connexions résiduelles pour préserver la fidélité des détails.

Module d’intervalles métriques : au lieu de prédire une seule distance, le module estime pour chaque pixel une distribution de probabilité sur des intervalles de distance prédéfinis (intervalles). Cela fournit une référence pour l’échelle du monde réel. Il fusionne ensuite cette information avec des indices structurels de la carte de profondeur relative en utilisant la convolution et une fonction de sortie dédiée.

Bien que la profondeur absolue s’aligne mieux avec les exigences de navigation et d’évitement d’obstacles, la profondeur relative peut fournir de précieux indices structurels. L’objectif est d’évaluer si la combinaison de ces modalités améliore la robustesse et la généralisation, en particulier dans des environnements non vus.

Nettoyage du jeu de données : la génération de données LiDAR synthétiques pour la détection en temps réel peut conduire à certains échantillons inutilisables. Par exemple, des sorties complètement noires causées par des problèmes de normalisation lors du traitement ZoeDepth, un problème connu. Une étape de post-traitement filtre automatiquement ces échantillons pour garantir un jeu de données cohérent et utilisable.

Adaptation Finale du Jeu de Données : Classes et Cibles de Détection

Le jeu de données COCO contient 80 classes, dont beaucoup ne sont pas pertinentes pour certaines applications spécifiques (animaux, catégories alimentaires). Pour concentrer l’entraînement sur des catégories cohérentes pour nos applications, nous avons réduit les labels et généré deux jeux de données :

1. Jeu de données 10 classes : [personne ; banc ; sac à dos ; bouteille ; tasse ; chaise ; tv ; ordinateur portable ; téléphone portable ; livre]

2. Jeu de données classe unique : [personne]

L’équilibrage des classes est un facteur critique influençant les performances et la robustesse des modèles de vision par ordinateur. Les classes sous-représentées tendent à être ignorées pendant l’entraînement. La conséquence est le sur-apprentissage du modèle des classes dominantes. Ainsi, la capacité de généralisation est réduite. Assurer des données équilibrées lors d’une génération de données LiDAR synthétiques peut améliorer significativement le résultat des étapes suivantes. Par exemple, atténuer le déséquilibre par sur-échantillonnage, augmentation ciblée ou pondération de la perte, améliore la stabilité d’entraînement et les performances globales. Les deux figures suivantes illustrent le résultat de l’augmentation de données effectuée sur le jeu de données 10 classes, avec augmentation de données à gauche et sans à droite.

Le prochain article de cette série, « Détection Temps Réel Système LiDAR : YOLO pour l’Edge AI », décrit l’exploitation de ces jeux de données synthétiques pour entraîner le modèle de détection d’objets YOLO.

The post Génération de données LiDAR synthétiques pour Détection Temps Réel appeared first on Blogue de Savoir-faire LInux.

De Paul Le Guen de Kerneizon

Introduction

Dans les produits embarqués, il est souvent essentiel de gagner quelques secondes, voire quelques centaines de millisecondes, entre la mise sous tension et la disponibilité de l’application. Dans cet article, je vais présenter un workflow pratique pour mesurer, comparer et réduire de manière itérative la fenêtre de démarrage précoce d’un système Linux embarqué, en se limitant au noyau et à la partie initramFS. Nous utiliserons le projet Yocto, et en particulier la fonctionnalité multiconfig de BitBake.

 [L’introduction est en français, le reste du texte en anglais]

Setting the context

Nowadays, modern embedded system boot sequence share the same boot-up sequence:

• • The board firmware looks for any bootable device (USB key, hard drive, etc), and loads a valid Linux bootloader.
  • The Linux bootloader is configured to load a Linux kernel image, with custom arguments.
  • Finally, the Linux kernel boots and set up the rootfs.

Our target BSP is composed of the following Yocto images:

• • lab-image-initramfs: this image contains the initramfs root file system, that will be responsible of the Linux first stage boot, including the load of the final rootfs. It is a very simple image, based on the core-image-minimal-initramfs image.
  • lab-image-rootfs: this image contains the final rootfs, packaged in a read-only file format such as ext4 or squashFS.
  • lab-image: this image packages the previous images into a single image, with an embedded Linux bootloader.

InitramFS optimization

As we saw previously, the initramfs image is loaded by the Linux bootloader. In embedded systems, I/O with devices such as disks are slow, and one of the most time consuming element is the initramfs image loading by the bootloader. So, reducing the size of this image will help to reduce it loading time, and so, the global system boot-time.

Initial measurements

We need to establish first what weight the most in the generated initramfs image. To do so, we are going to use the Bitbake buildhistory feature allowing to give some metrics about the contents of our generated image. It can be enabled by adding these lines in your distro file:

After building initramfs image, buildhistory has been generated:

We are interested in by the installed-package-sizes.txt file. It contains the size of each installed package in the initramfs image, sorted by weight:

Using an awk command we can get the total size of our initramfs image:

Here, the size of our image is about 39MiB.
To measure the boot-time on the target we highly recommend, if possible, to get the boot serial output and use the minicom timestamp feature.

List of Initramfs optimizations

On a first glance, we could interpret that there are not that much to optimize in our initramfs image, specially because it is already well minimized by the core-image-minimal-initramfs image. But some optimization can be implemented that can make the difference:

• • Changing the default C library from glib to musl library.
  • Changing the default initmanager from sysvinit to busybox-mdev.
  • Removing any additional unused packages.

Introducing Bitbake multiconfig feature

By default, a single Bitbake command can only build an image with a single configuration (distro, machine). Since the Langdale release of the Yocto Project, the multiconfig feature allows to easily apply different configuration within a single distro, for multiple images.
In our case, we would like to use the musl library and eudev init manager only for the lab-image-initramfs image, and not the rootfs image.

Setup a basic multiconfig

First, you need to add a new folder named “multiconfig” in the “conf” directory of your layer. In this folder, add a new file with the name of your multiconfig, in our example “mclabinitramfs”.

Now in your distro file (here lab.conf), add the following line:

We now have a basic multiconfig implementation, which currently does nothing.

Link the multiconfig to the initramfs

The usecase of the multiconfig here is to apply specific configuration boundared only to the lab-image-initramfs image. So we need to tell to Bitbake this dependency. To do so, add the following lines in your distro file (here lab.conf):

These lines specify two things:

• • INITRAMFS: the name of the initramfs used.
  • INITRAMFS_MULTICONFIG: tells to Bitbake that the kernel must be bundled with an initramfs image using a specific multiconfig and not the default one.
  • INITRAMFS_DEPLOY_DIR_IMAGE: the location where all the initramfs artifacts (images, etc) should be deployed.

Optimization

Use musl libray

musl is a C library for the Linux kernel. The main advantage of the musl library is that packages compiled with it are much lighter compared to packages build with glibc. However not all packages are compatible with musl library, especially for systemd, where musl support is still experimental. This is why I don’t recommend to use for all the images, in particular the rootfs image.

Back to our multiconfig, musl library can be enabled using the TCLIBC variable, set in the sources/meta-lab-distro/conf/multiconfig/mclabinitramfs.conf file:

Use a lighter init manager

By default, Bitbake uses sysvinit as the default initialization manager. It is great, but it can be easily improved by using mdev-busybox which is lighter compared to sysvinit. To use it, simply add these lines in the sources/meta-lab-distro/conf/multiconfig/mclabinitramfs.conf file:

Additional optimizations

To reduce further the size of the initramfs image, additional optimizations can be implemented, but are less applicable:

• • Use sh instead of bash as command interpreter, as sh is lighter compared to bash. Initramfs scripts are written using sh syntax, but keep in mind that you might need to convert your own script to the sh syntax if needed.
  • Kernel configuration minimization (unneeded file systems, etc)

Final results

With these optimizations, if we compute the size of the initramfs image, we get now a size of 29MiB, and so a reduction of 25%!
Now regarding the real result on target, it will also depends of the hardware used (CPU, disk type, etc). On our internal tests, on an ARM target we achieved to get 1.2s of boot-time reduction during initramfs image loading.

The post Accélérer le démarrage précoce de Linux avec Yocto multiconfig appeared first on Blogue de Savoir-faire LInux.

Les systèmes modernes reposent également sur une large base de composants open source : bibliothèques, noyaux, outils de compilation et dépendances tierces qui constituent une part importante de l’image finale du firmware. Si l’open source accélère l’innovation et permet de mutualiser les coûts de développement, il introduit aussi un flux continu de mises à jour en amont et de divulgations de vulnérabilités que les équipes doivent suivre et gérer.

Les SBOMs (Software Bill of Materials) se sont imposés comme une bonne pratique pour rendre transparente la composition logicielle. Toutefois, l’analyse des SBOMs à la recherche de vulnérabilités est souvent plus difficile qu’elle ne devrait l’être, en particulier dans les environnements embarqués, où de nombreux concepteurs de produits manquent d’expertise en cybersécurité et des ressources nécessaires pour réaliser des audits complets sans outils automatisés.

De plus, le Cyber Resilience Act (CRA) de l’Union Européenne impose aux fabricants de produits connectés avec des éléments numériques de créer et maintenir une Software Bill of Materials documentant les composants et vulnérabilités, et servant de base à un suivi continu à mesure que de nouveaux problèmes émergent. Bien que la divulgation publique ne soit pas obligatoire, les fabricants doivent fournir ces informations aux autorités de surveillance du marché sur demande.

C’est pourquoi nous avons créé VulnScout : pour aider les organisations à répondre à leurs besoins en matière de sécurité et de conformité pour les systèmes embarqués qu’elles développent.

VulnScout est un scanner de vulnérabilités basé sur les SBOMs, conçu pour être convivial pour les développeurs et simple à intégrer avec Yocto, Buildroot et la plupart des systèmes générant des SBOMs. Il prend en charge les formats SPDX, CycloneDX et OpenVEX, ce qui permet une détection et une exploration simplifiées des vulnérabilités au niveau de la compilation, avec un minimum de configuration et de mise en place. Il comble ainsi le fossé entre les outils de cybersécurité et le développement logiciel au quotidien, notamment dans les projets comportant des dizaines voire des centaines de dépendances open source.

 [L’introduction est en français, le reste du texte en anglais]

Limitations of Current SBOM Scanners

Many existing tools are excellent at what they do, but they often come with trade-offs that limit their usefulness as a single source of truth for project-level vulnerability assessment:

• Grype is powerful and lightweight but lacks fix tracking or SBOM enrichment.
• Dependency-Track provides a full-featured dashboard but requires centralized infrastructure with a server and database setup.
• Anchore’s tools focus on containerized environments and cloud-native workflows.

But what if you just want to:

• Scan SBOM files generated by Yocto, Buildroot, or any existing build system or distribution
• Merge results from SPDX, CycloneDX, or Yocto outputs
• Explore, sort, filter, track, and document what’s fixed vs. what’s still a risk, including which open-source components are still vulnerable
• Do all of this from a web-based interface, without setting up a server

That’s where VulnScout comes in.

What Sets VulnScout Apart

Unlike many other tools that require a persistent web and database infrastructure, VulnScout is fully self-contained. It runs locally, stores its state within your project repository, and integrates directly with your build system, making CVE assessments version-controlled and part of your release process.

VulnScout helps teams keep track of which components are vulnerable, which ones have been fixed, and which ones still need attention. This history is preserved in the repository, making it part of your engineering workflow and auditable over time.

While other solutions are tightly coupled to specific data formats, VulnScout is format-agnostic and supports SPDX 2.x, SPDX 3.0, CycloneDX, and OpenVEX out of the box, eliminating the need for format conversion. VulnScout can also act as a conversion and reporting tool, allowing you to transform SBOM inputs into:

• Structured SBOMs
• Human-readable reports (PDF, text, HTML)
• CLI summaries for quick CI/CD integration

This makes it ideal for both automated builds and preparing audit documentation, especially when you need to demonstrate how you’ve addressed vulnerabilities across your open-source dependencies.

How VulnScout Works

Instead of analyzing binaries or source code directly, VulnScout focuses on SBOM inputs. It consumes formats like SPDX, CycloneDX, Grype JSON, and Yocto CVE-check JSON, enriching them with data from:

• NVD (National Vulnerability Database)
• EPSS (Exploit Prediction Scoring System)
• OSV (Open Source Vulnerabilities) (coming soon)
• Grype-compatible data sources
• Vulnerability information already embedded in the SBOM files

Click to open the video

Once scanned, VulnScout generates:

• Rich web-based dashboards
• Extended reporting in PDF, CSV, and text
• Structured output files (SPDX, CycloneDX, OpenVEX)
• CLI summaries for quick integration
• CI alerts based on filters (for example: a new vulnerability with EPSS score > 7.0)

It is designed to run locally, either plugged into a Yocto or Buildroot setup or via a Docker container, and can be triggered with a single script (vulnscout.sh) or a Yocto layer (meta-vulnscout). This workflow allows you to continuously monitor open-source components as part of every build, catching regressions and new disclosures early.

Click to open the video

Try VulnScout

You can get started with VulnScout in just a few minutes.
Check out the VulnScout GitHub repository for installation instructions, examples, and quick-start guides. If you use Yocto, check out meta-vulnscout, allowing for seamless integration with your image recipes.

Run it locally or in your CI pipeline to keep your open-source components under continuous watch and stay ahead of new vulnerabilities.

The post VulnScout: The Easy-to-Use Tool for Securing Embedded Systems and Staying Compliant appeared first on Blogue de Savoir-faire LInux.

Introduction

L’essor des plateformes embarquées capables de traitement IA a profondément changé la donne : il est désormais possible de déployer des solutions intelligentes sur l’équipement lui-même, sans dépendre du cloud. C’est ce qu’on appelle l’« edge AI ».

Lors d’un récent projet, nous avons exploré comment déployer un système de détection d’objets en temps réel à l’aide d’un modèle de vision par ordinateur sur une carte Verdin NXP i.MX 8M Plus, une cible populaire grâce à son unité de traitement neuronal (NPU) intégrée.

Cet article partage notre retour d’expérience technique : depuis la conversion des modèles jusqu’à leur intégration dans une image Yocto, en passant par les compromis nécessaires pour atteindre des performances en temps réel avec des résultats satisfaisants.

Contexte et objectif

ICOR Technology conçoit et fabrique des robots, outils et équipements innovants et de haute qualité pour les communautés EOD et SWAT à travers le monde. Les utilisateurs peuvent piloter les robots ICOR à distance via une unité de commande et de contrôle, qui affiche en temps réel les flux vidéo provenant des caméras du robot.

L’objectif du projet était de concevoir une démonstration de navigation robotique assistée par la vision, reposant sur un modèle de détection d’objets en temps réel comme le montre le schéma ci-dessous.

Les principaux objectifs étaient :

• Traitement à 30 images par seconde
• Exécution sur une cible embarquée basse consommation
• Usage d’un modèle pré-entraîné de type YOLOv8 (You Only Look Once)
• Détection d’objets génériques (personnes, chaises, etc…), détection de visages et détection d’éléments de navigation (portes, escaliers, fenêtres)
• Intégration complète dans une image Linux Yocto

Nous avons choisi de travailler avec le System on Module (SoM) Verdin i.MX 8M Plus, qui combine CPU, GPU, VPU et NPU dans un format adapté aux applications industrielles.

Plateforme matérielle

Le Verdin NXP i.MX 8M Plus, co-développé par NXP et intégré sur une carte conçue par Toradex, offre un bon compromis pour le traitement de l’IA embarquée :

• CPU : 4 cœurs Cortex-A53 à 1.8 GHz
• GPU : Jusqu’à 16 GFLOPS
• NPU : Jusqu’à 2.3 TOP/s
• VPU : Encodeur/décodeur matériel pour la vidéo (H.264/H.265)

Ce matériel permet d’accélérer les inférences IA, tout en restant dans les contraintes d’encombrement, de dissipation thermique et de consommation des systèmes embarqués.

TensorFlow et TensorFlow Lite

TensorFlow est une bibliothèque open source développée par Google, largement utilisée dans le domaine du machine learning et de l’intelligence artificielle. Elle fournit une infrastructure complète pour l’entraînement et le déploiement de modèles de réseaux de neurones, avec un large écosystème d’outils et de ressources qui en font une référence pour la recherche comme pour l’industrie.

TensorFlow Lite (TFLite) est une déclinaison de TensorFlow spécialement conçue pour les environnements contraints comme les systèmes embarqués et les appareils mobiles. Il permet d’exécuter des modèles optimisés en réduisant leur taille et leur consommation de ressources, tout en profitant d’accélérations matérielles (GPU, NPU, DSP).

Yocto

Yocto Project est un projet open source qui fournit un ensemble d’outils, de scripts et de couches pour construire des systèmes Linux embarqués personnalisés. Yocto permet de créer des images Linux embarquées optimisées pour des matériels spécifiques. Cela en fait un outil de référence pour les environnements contraints, où l’optimisation de la taille, des performances et de la sécurité est essentielle.

Intégration de TensorFlow Lite dans Yocto

L’environnement Yocto, bien que flexible, demande une configuration rigoureuse pour supporter les bibliothèques de Machine Learning. Voici les étapes clés que nous avons suivies :

1. Base BSP Toradex : fournie pour le SoM utilisé
2. Ajout de la couche meta-imx-ml : elle fournit les recettes pour tensorflow-lite, etc.
3. Dépendances nécessaires : opencv, python3-numpy, etc.
4. Configuration de l’image : inclusion des paquets nécessaires dans local.conf ou un fichier .bbappend
5. Résolution de conflits : les couches Yocto pour l’IA ne sont pas toujours alignées, un certain travail d’intégration est requis.

En effet, dans les systèmes embarqués, les versions des packages sont fixées. Cependant certains packages peuvent partager des dépendances mais avec des versions différentes, qu’il faut donc résoudre.

Conversion et quantification du modèle

Le modèle de détection utilisé YOLOv8 a été entraîné avec Ultralytics. Nous avons choisi YOLOv8 car c’était un modèle d’architecture à l’état de l’art lorsque nous avons commencé ce projet. Il est développé sous PyTorch, puis nous avons converti en modèle TensorFlow Lite afin d’être compatible avec le NPU du i.MX 8M Plus. La version utilisée était la Nano, la plus légère de la gamme, choisie afin de respecter la contrainte de temps réel.

Étapes de conversion :

• Conversion .pt (PyTorch) → .onnx (Open Neural Network Exchange) → .tflite(TensorFlow Lite)
• Quantification en int8 : la quantification réduit la taille mémoire des modèles et accélère considérablement leur exécution, tout en assurant leur compatibilité avec le NPU.
• Certaines opérations du modèle original n’étant pas supportées dans le format TFLite, nous avons dû implémenter manuellement les étapes de prétraitement et de post-traitement, notamment le Non-Maximum Suppression (NMS) comme démontré dans le schéma ci-dessous.

Le réseau de neurones produit plusieurs détections potentielles pour un même objet. L’algorithme de NMS élimine les détections redondantes en retenant la proposition avec le score de confiance le plus élevé.

Le NPU du i.MX 8M Plus n’accepte que les modèles entièrement quantifiés (full integer). Il est donc nécessaire de calibrer les modèles pour assurer leur exécution sur l’accélérateur matériel.

Stratégie multi-réseaux et sélection des résolutions

Notre application devait couvrir trois tâches de détection distinctes :

1. Détection d’objets génériques avec le dataset COCO
2. Détection d’éléments de navigation (portes, escaliers, fenêtres) à partir d’un dataset spécialisé
3. Détection de visages à partir d’un dataset d’identification faciale

Une première approche centralisée…

Dans un premier temps, nous avons tenté d’entraîner un réseau unique combinant les trois datasets. Cette approche, bien que séduisante sur le papier, a rapidement montré ses limites en termes de performance. Les raisons sont multiples :

• Incohérences dans les conventions d’annotation entre datasets
• Nature hétérogène des images (scènes intérieures, visages, objets du quotidien)
• Déséquilibre dans la distribution des labels, certains étant largement sous-représentés

Ci-dessous nous pouvons voir :

• un exemple d’image du dataset de segmentation de COCO avec son annotation : les pixels des objetcs sont colorés dans leur contour.
• un montage de plusieurs images du dataset de visages : un visage est une image du dataset et son annotation correspond à toute l’image.

Vers une approche multi-réseaux spécialisés

Pour contourner ces limitations, nous avons opté pour une solution plus modulaire : un réseau de neurones distinct pour chaque tâche, chacun optimisé avec une résolution adaptée. C’était une approche audacieuse, car exécuter trois réseaux de neurones distincts sur un système embarqué limité en ressources constitue un véritable défi technique. Et pourtant, nous avons réussi à le faire fonctionner efficacement en temps réel Notre approche rappelle également le concept d’une architecture Mixture of Experts, où différents modèles spécialisés contribuent à résoudre différents aspects d’un problème. Voici les dimensions que nous avons choisies pour les différents jeux de données :

• COCO : réseau quantifié à 320×320
• Navigation (portes, escaliers, fenêtres) : 160×160
• Visages : également à 160×160

Ce choix nous a permis d’obtenir des résultats très satisfaisants, tout en réduisant la charge de calcul. Le tableau et le graphique suivants résument les performances mesurées selon la résolution.

Résultats de performance

Comme on peut le voir dans le tableau et sur le graphique, les résolutions plus faibles permettent un traitement ultra-rapide (faible temps d’inférence ou haut nombre de FPS), ce qui les rend idéales pour des réseaux spécialisés sur des tâches précises, où la perte de précision reste acceptable.

Conclusion

Dans ce projet, nous avons intégré TensorFlow Lite dans Yocto en résolvant les conflits de dépendances, exploré une approche multi-réseaux pour spécialiser les tâches de détection, et optimisé la résolution afin de trouver le meilleur compromis entre vitesse et précision. Nous n’avons pas seulement déployé un seul modèle, mais trois réseaux de neurones spécialisés sur un système embarqué tout en repectant la contrainte temps réel (30 fps), démontrant ainsi le potentiel de l’IA embarquée appliquée au monde réel.

Cette expérience montre que la vision intelligente embarquée est réalisable sur des plateformes à ressources limitées, à condition de bien maîtriser les outils, des frameworks IA aux couches Yocto.

Nous croyons que ce type d’intégration entre systèmes Linux embarqués et IA représente une voie prometteuse pour l’avenir de l’automatisation, de la robotique et de l’industrie en général.

The post Déployer un réseau de neurones artificiels convolutionnels sur un système embarqué appeared first on Blogue de Savoir-faire LInux.

Le débogage de microcontrôleurs (MCU) a toujours été essentiel pour produire du code de haute qualité, mais la dépendance aux environnements de développement spécifiques aux fabricants et aux configurations complexes des serveurs de débogage peut parfois nuire à un flux de travail fluide.

Bien que VSCode ait révolutionné la façon dont les développeurs écrivent et déboguent du code, configurer une session de débogage pour les MCU peut parfois s’avérer difficile.

Heureusement, grâce à l’outil Zephyr west et à quelques extensions VSCode, mettre en place une session de débogage n’a jamais été aussi simple.

Dans cet article, nous allons configurer VSCode pour exécuter west debugserver, qui se charge de lancer un débogueur et de le connecter à l’IDE VSCode avec l’extension Cortex-Debug.

 [L’introduction est en français, le reste du texte en anglais]

Prerequisites

For debugging Zephyr application through VSCode you’ll need to install the powerful Cortex-Debug extension. Also, the Zephyr SDK should be installed. Please follow the Getting Started Guide if you haven’t installed it.

Easy setup with West debugserver

The west debugserver command is very helpful to set up a minimal debug environment, as it run runners with the appropriate configuration for your board and can be used generically with any Zephyr supported board. The runners may be openocd, jlink, pyocd or others, depending on your board support.

With these two following steps, you will be able to run a debug session with VSCode:

1. Create a task in your tasks.json file to run west debugserver.
2. Create a launch.json file to configure Cortex-Debug.

For this example, we will use the STM32L562E_DK board as it supports west debugserver out of the box.

West debugserver task

The default runner of this board is pyocd, but an external package needs to be installed to use it. Due to this, we will set openocd as the runner, which is already installed with the Zephyr SDK. First, you have to create a VSCode task to run west debugserver in the background. In your tasks.json file, add the following task:

Some explanations about the configuration:

• args : The -r option specifies the runner to use, in this case, openocd.
• problemMatcher : This is used to parse the output of the west debugserver command and display it in the Problems panel. In our case, it matches the openocd output. If another runner is used, you may need to adjust the regex patterns.
•  runOptions: As west debugserver opens a server, we don’t want to have port conflicts, so only one instance of the task can run at a time.
• presentation: This is used to control the output of the task in the terminal. In this case, we want to reveal the output silently and close it after the task is finished.

Now the task is ready to use. You can try to run it by pressing Ctrl+Shift+P, selecting the Tasks: Run Task command and selecting the West Debugserver or whatever label you have given to the task.

Another small task is needed to stop the west debugserver task when you are done debugging. Otherwise, it will keep running in the background. You can add the following task to your tasks.json file:

Here, the command will open an input box to select the task to terminate.

And that’s it for the tasks.json file!

Cortex-Debug configuration

The Cortex-Debug will now make the link between the debugserver and the VSCode debugging interface. To do this, you need to create a launch.json file in the .vscode directory of your project.

Add this configuration to your launch.json file:

Some explanations about the configuration:

• executable: This is the path to the ELF file generated by the Zephyr build system. By default, the build directory is build/zephyr/zephyr.elf, but you can change it if you have a different build directory.
•  runToEntryPoint: This option specifies the entry point to run to when starting the debug session. In this case, it is set to main.
• gdbPath: The gdb path is set to the Zephyr SDK’s GDB executable.
• preLaunchTask and postDebugTask: these options specify the tasks we created just before. The name should be the same as task’s label.

The VSCode debugging session is now ready to be launched. You can add some breakpoints to your code and try running the debug session by pressing F5 or selecting the session by pressing Ctrl+Shift+D and clicking on the green play button.

Special case: Attach debugger to running target

Sometimes, target cannot support a reset when starting a debugging session.

We have dealt with this behavior when supporting the Cortex-M33 of the STM32MP2 board.

Thus, the VSCode configuration has been slightly changed to attach the debugger to the running target instead of reset and run the code. In the tasks.json file, the West Debugserver task is updated as follows:

Only the args parameter is updated to ask the west debugserver to not reset the target when launching the task. Accordingly, the launch.json file is also modified to permit VSCode to attach the debugger:

The request parameter is updated to attach the debugger.

Also the gdb port is set to 3334, because the stm32mp2 SoC has multiple architecture, so the debugserver set by default the Cortex-M33 to the 3334.

Conclusion

As you can see, setting up a debug environment for Zephyr development is trivial, thanks to the tools provided by the RTOS and the full-featured VSCode extension Cortex-Debug.

Feel free to use the configuration for running or attaching a debug session!

Find the config on GitHub : Main branch 

The post Easy Debugging Zephyr with VSCode appeared first on Blogue de Savoir-faire LInux.

Dans cet article, nous partageons les moments forts de nos présentations et les différents projets auxquels nous avons contribué.

LF Energy SEAPATH

En tant que contributeur principal du projet LF Energy SEAPATH, nous souhaitons partager notre travail lors de conférences internationales :

• En février, au FOSDEM à Bruxelles, Paul Le Guen de Kerneizon a donné une présentation générale du projet SEAPATH ainsi que du travail effectué autour de l’implémentation des tests de latence IEC61850 pour des algorithmes de protection de postes sources.

• En avril, à Seattle, en Amérique du Nord, a eu lieu EOSS (Embedded Open Source Summit). Lors de cet événement organisé par la Linux fondation, Christophe Villemer a été interviewé par Swapnil Bhartiya de TFIR, pour discuter du projet Lf Energy SEAPATH et de son rôle dans l’élaboration de l’avenir de la gestion de l’énergie.

• Vous pouvez retrouver toutes les vidéos de cette interview de Christophe Villemer et Swapnil Bhartiya ici/ sur leur site !

• En septembre 2024, à Bruxelles, nous avons été fiers de participer à la deuxième édition du Lf Energy Summit en tant que sponsor Silver ! Durant cet événement dédié à l’accélération de la transition énergétique, Christophe Villemer a présenté une keynote sur « Construire un business Open Source » en utilisant le projet Lf Energy SEAPATH comme exemple.

• À ce même événement, Erwann Roussy et Camilo De Arriba, Senior Substation Automation Manager chez General Electric Vernova, ont présenté leur travail démontrant la performance de SEAPATH dans un scénario de défaillance du réseau électrique réel. Ils ont ensuite approfondi les détails de leur présentation : « Déployer un IED virtuel sur LF Energy SEAPATH, conseils et retours d’expérience ».

• Toujours au LF Energy Summit, Eloi Bail, TSC Chair du projet SEAPATH a présenté « SEAPATH « Certified » : Hardware pour des infrastructures virtualisées dans le domaine des solutions énergétiques».

• Enfin, cet événement a été l’occasion de réunir la communauté SEAPATH au meetup présenté par Eloi Bail.

Linux embarqué

Nous participons régulièrement à des événements axés sur notre activité principale : Linux embarqué.

Projet Yocto

• Lors d’EOSS à Seattle, notre Web Practice Leader Mohammed Raza a donné deux conférences sur le projet Yocto. La première était sur « Le développement du projet Yocto avec  VSCode : accélérer votre productivité » fournissant des avantages concrets en montrant comment l’extension VS CODE peut être utilisée pour fournir une expérience de codage moderne pour les développeurs du projet Yocto.

• Sa deuxième conférence était sur « Le développement du projet Yocto avec TOASTER : simplifier la courbe d’apprentissage ». Il y a souligné les difficultés que rencontrent les développeurs pour configurer et gérer les builds sans une interface intuitive comme Toaster.

• En décembre, Enguerrand de Ribaucourt a présenté l’implémentation de Yocto VSCode et Typescript au Yocto Projet Summit.

• En avril, nous avons participé à Embedded World à Nuremberg en Allemagne, où nous avons présenté notre expertise et mis en avant nos partenariats. Nous avons également apporté notre soutien au stand du projet Yocto, renforçant notre engagement envers la communauté des systèmes embarqués.

L’équipe de Savoir-faire Linux présente au stand Yocto

• Jérôme Oufella et Eloi Bail ont discuté de l’importance croissante de la conformité en cybersécurité dans le développement des systèmes embarqués, en particulier avec l’émergence de réglementations plus strictes. Ils ont souligné la nécessité d’intégrer ces exigences dès le processus de développement afin de garantir la conformité des logiciels. La discussion a également mis en lumière le partenariat de longue date entre Savoir-faire Linux et Toradex et le rôle clé de Torizon (une distribution Linux industrielle open source) dans le respect de normes rigoureuses comme IEC 62443.

• Savoir-faire Linux est fier d’avoir été l’un des principaux sponsors de Montréal Python, une série de conférences mensuelles portant sur divers sujets liés à Python. En novembre, Serosh Deljam a présenté « Computer Vision avec Python dans les systèmes embarqués », mettant en valeur notre expertise dans ce domaine.

Conclusion

Cette année 2024 a été riche en événements et rencontres. Au travers de nos conférences, nous avons eu l’occasion de partager nos connaissances et notre expertise. Nous remercions sincèrement nos partenaires pour leur confiance et la communauté pour son soutien. Nous nous réjouissons d’innover ensemble dans les années à venir !

The post Rétrospective : les connaissances que nous avons partagées lors des conférences internationales en 2024 appeared first on Blogue de Savoir-faire LInux.

Permettre à l’industrie des systèmes embarqués de se conformer aux cyber-réglementations grâce à un outil de gestion des vulnérabilités innovant et open source.

Nuremberg, le 11 mars 2025 – Savoir-faire Linux, société de conseil et d’ingénierie en logiciels libres et Open Source est fière d’annoncer la sortie officielle de VulnScout.io, une solution Open Source de cybersécurité conçue pour aider les organisations à suivre, gérer et corriger efficacement les vulnérabilités logicielles de leurs produits. Faisant suite au lancement l’année dernière de ses services professionnels spécialisés en cybersécurité, cette sortie confirme l’engagement continu de Savoir-faire Linux envers l’open source, renforcé par son implication active au sein des communautés de la Linux Foundation et du projet Yocto.

“L’open source fait partie de notre ADN”, souligne Christophe Villemer, vice-président exécutif de Savoir-faire Linux et membre du conseil de direction de la LF Energy. “C’est pourquoi nous avons choisi de publier VulnScout.io sous une licence libre. Notre profonde implication dans les initiatives de la Fondation Linux ainsi que notre expérience en matière de contributions au projet Yocto nous conforte dans le choix d’offrir une solution communautaire et accessible à tous. Avec VulnScout.io, nous offrons aux équipes de développement et aux industriels une réponse concrète aux défis croissants de conformité en matière de cybersécurité, particulièrement dans le contexte du Cyber Resilience Act bientôt applicable en Europe. »

Un outil open source dédié aux systèmes embarqués

VulnScout.io offre une boîte à outils efficace et pragmatique pour le suivi des vulnérabilités, conçue pour s’intégrer de manière transparente dans les cycles de développement des produits embarqués. Ayant été testé en premier lieu sur des systèmes Linux embarqués développés avec le Projet Yocto – VulnScout.io permet d’assurer une détection et une gestion complètes des vulnérabilités affectant la solution OS embarquée.

Principales fonctionnalités de VulnScout.io

• SBOM et Gestion des vulnérabilités – Automatise la génération de SBOM et la détection de CVE, offrant ainsi une vision en temps réel des menaces.
• Large compatibilité avec les formats standard de l’industrie tels que CycloneDX et SPDX, ainsi qu’avec OpenVEX de l’Open Source Security Foundation (OpenSSF).
• Conçu pour les analystes et l’intégration continue – Il s’intègre de manière transparente dans les flux de travail d’intégration continue existants, permettant ainsi aux équipes de développement et de sécurité de faire de la gestion des vulnérabilités une partie intégrante des flux de travail quotidiens.
• Dévoué à la communauté Open Source – Hébergé ouvertement sur GitHub, VulnScout.io bénéficie de l’innovation collective et des contributions extérieures, reflétant ainsi l’éthique Open Source de Savoir-faire Linux.

Répondre aux défis du Cyber Resilience Act européen

Avec l’arrivée imminente du Cyber Resilience Act (CRA) en Europe, VulnScout.io offre une approche transparente et automatisée pour générer et gérer les données de la Software Bill of Materials (SBOM). Cette démarche proactive permet aux organisations d’anticiper efficacement les vulnérabilités et de se préparer sereinement aux normes de conformité telles que IEC62443, IEC62304, UL2900 et DO-326A.

“Des contrôleurs industriels complexes aux appareils IoT de nouvelle génération, les entreprises ont besoin d’une solution robuste et évolutive,” précise Jérôme Oufella, Vice-président Technologie chez Savoir-faire Linux “De par notre expertise pointue des systèmes embarqués et notre expérience multi-secteurs, nous assurons une intégration naturelle de Vulnscout.io dans les processus de développement et d’ingénierie produit. ”

Présentation et démos à Embedded World 2025

Savoir-faire Linux présentera officiellement Vulnscout.io à l’événement Embedded World 2025 à Nuremberg, du 11 au 13 mars, sur son stand 4-642. Les visiteurs pourront assister à des démonstrations pratiques illustrant comment les équipes de développement de systèmes embarqués peuvent utiliser Vulnscout.io pour améliorer continuellement la sécurité et la conformité de leurs produits. Simultanément, l’entreprise sera également présente au salon Global Industrie à Lyon, dans le Village Captronic, pour promouvoir Vulnscout.io et ses services associés auprès des entreprises développant des produits embarqués et concernées par le CRA.

Liens pertinents

• https://github.com/savoirfairelinux/vulnscout
• https://savoirfairelinux.com/fr/services/cybers%C3%A9curit%C3%A9-pour-ing%C3%A9nierie-de-produit

The post Savoir-faire Linux annonce à Embedded World 2025 la sortie en Open Source de VulnScout.io appeared first on Blogue de Savoir-faire LInux.

DHTNet permet aux développeurs d’établir des connexions P2P sécurisées entre des appareils en utilisant uniquement des clés publiques, éliminant le besoin d’une infrastructure centralisée ou d’un adressage IP direct.

[L’introduction est en français, le reste du texte en anglais]

Features

• Connection Management: DHTNet simplifies the establishment and management of connections to peers, streamlining the communication process.
• Multiplexed Sockets: It provides multiplexed sockets that allow multiple channels for data transmission, optimizing network resources.
• UPnP Integration: DHTNet seamlessly integrates with UPnP, enabling automatic port mapping and enhanced network connectivity.
• Server TURN Support: DHTNet includes support for server TURN, used as a fallback for connections if the NAT block all possible connections.

Technical Overview

DHTNet is a C++17 library designed to serve as a network overlay that provides an IP network abstraction. Its main objective is to establish secure peer-to-peer connections using public-key authentication.

DHTnet allows you to connect with a device simply by knowing its public key and efficiently manages peer discovery and connectivity establishment, including NAT traversal.

At its core, DHTNet integrates several established standards and technologies to provide robust P2P connectivity:

• OpenDHT serves as the foundation for peer discovery on the distributed network
• ICE (Interactive Connectivity Establishment) is handled by pjnath, supporting connection through NATs and firewalls
• Security and authentication are implemented through GnuTLS

The library implements a true peer-to-peer architecture where devices can discover and connect to each other through public key-based addressing. This approach eliminates the need for static IP addresses or central coordination servers, making it particularly suitable for dynamic network environments.

Use Cases and Applications

DHTNet is particularly well-suited for:

• Embedded systems and IoT devices that require direct peer-to-peer communication
• Distributed applications that need to operate without central infrastructure
• Systems where traditional client-server architectures are impractical
• Development of decentralized networking protocols and applications

Technical Requirements

• Build tested with:
  • GCC on GNU/Linux
  • Clang on Android, iOS and macOS
  • MSVC on Windows
• C++17 compatible compiler required
• Dependencies:
  • OpenDHT
  • Our fork of pjproject, implementing ICE/TCP
  • GnuTLS

Contributing

DHTNet is an open-source project under the GPLv3+ licence, and contributions from the community are welcome. The codebase aims to maintain high standards of code quality and documentation to facilitate collaboration and maintainability.

Future Development

The development roadmap includes:

• Additional transport protocol support
• Enhanced API documentation
• Performance optimizations for constrained environments
• Extended example implementations

We encourage developers interested in distributed systems and peer-to-peer networking to explore DHTNet and provide feedback on its functionality and potential improvements.

https://github.com/savoirfairelinux/dhtnet/

https://github.com/savoirfairelinux/dhtnet/blob/master/BUILD.md

The post Introducing DHTNet: Distributed Peer-to-Peer Networking Made Simple appeared first on Blogue de Savoir-faire LInux.