Boîtier Edge Computing Pont Roulant YOLOv8n TensorRT
Paramètres clés
Pour l’informatique en périphérie, nous recommandons le NVIDIA Jetson Orin NX (100 TOPS, 16 Go, 15 W), avec déploiement du modèle de détection d’objets YOLOv8n (quantification TensorRT INT8, latence d’inférence de 5 à 12 ms) et du suivi multi-objets ByteTrack (2 à 3 ms), pour une cadence de détection de 30 images/s. Une seule boîte périphérique peut traiter simultanément 2 à 4 caméras IA. Plus de 50 systèmes ont été déployés dans des aciéries, des cimenteries et des usines automobiles, avec un taux de précision d’alerte anticollision ≥ 97 %.
Les fonctions avancées telles que l’anticollision par vision IA sur pont roulant, le suivi de trajectoire du crochet et la détection de fils cassés du câble métallique reposent sur l’informatique en périphérie pour exécuter l’inférence IA en temps réel localement. Contrairement au traitement cloud qui impose le téléversement des flux vidéo, la solution périphérique effectue l’inférence directement sur le pont roulant, réduisant la latence de plus de 500 ms à 5–12 ms tout en éliminant les fluctuations réseau et les goulots d’étranglement de bande passante. Cet article analyse de bout en bout la chaîne d’ingénierie d’une boîte d’informatique en périphérie pour pont roulant : sélection du matériel, déploiement du modèle, optimisation de la quantification et communication PLC.
Comparatif du matériel pour boîte d’informatique en périphérie
Les exigences clés d’un système de vision IA pour pont roulant vis-à-vis de la boîte périphérique : puissance de calcul IA ≥ 40 TOPS (INT8), prise en charge de plusieurs caméras (≥ 2 voies MIPI CSI ou USB 3.0), plage de température industrielle (−25 °C à 70 °C), et compatibilité avec les protocoles industriels Profinet/EtherNet/IP. Voici une comparaison détaillée de trois boîtes périphériques grand public dans un contexte de pont roulant —
| Paramètre | Jetson Orin NX 16GB | Jetson Orin Nano 8GB | RK3588 16GB |
|---|---|---|---|
| AIPuissance de calcul(INT8) | 100 TOPS | 40 TOPS | 6 TOPS |
| GPUArchitecture | Ampere 1024Cœur@918MHz | Ampere 512Cœur@765MHz | Mali-G610 MP4 |
| Mémoire/Bande passante | 16GB LPDDR5 68GB/s | 8GB LPDDR5 34GB/s | 16GB LPDDR4X 17GB/s |
| Décodage vidéo | 2×4K@30 + 4×1080@30 | 1×4K@30 + 2×1080@30 | 8K@30 + 4K@120 |
| Consommation électrique | 15W/25WCommutable | 7W/15WCommutable | 8~15W |
| Protocole industriel | Profinet/Modbus TCP/EIP | Profinet/Modbus TCP/EIP | Modbus TCP |
| YOLOv8nLatence d | 5~8ms (INT8) | 12~18ms (INT8) | 80~150ms (FP16) |
| Prix indicatif | ¥6,500~7,500 | ¥2,500~3,500 | ¥800~1,200 |
| pont roulant Niveau de recommandation |
Entraînement du modèle YOLOv8n et quantification TensorRT INT8
YOLOv8n (version nano, 3,2 M de paramètres) est aujourd'hui le modèle de détection d'objets offrant le meilleur compromis précision-vitesse pour les applications de vision IA sur ponts roulants. Par rapport à YOLOv8s (11,2 M de paramètres), la vitesse d'inférence est 2,5 fois supérieure, avec une baisse de mAP de seulement 1,2 %. L'entraînement s'appuie sur le jeu de données annoté accumulé par Kelude Industries Lourdes (120 000 images couvrant cinq classes d'objets — crochet de pont roulant, câble métallique, personnel, AGV, obstacles — dans 12 conditions d'éclairage : jour, nuit, ciel couvert, contre-jour, etc.).
Processus de déploiement quantifié : ensemble de calibration FP32 (500 images de scénarios typiques) → quantification PTQ INT8 TensorRT → sérialisation du moteur d'inférence (fichier .plan). Paramètres clés : résolution d'entrée 640×640, seuil de confiance 0,5, seuil NMS IoU 0,45. Après quantification, le modèle passe de 12,5 Mo (FP32) à 4,2 Mo (INT8), soit une compression de 66 % ; la latence d'inférence passe de 8 à 12 ms (FP16) à 5 à 8 ms (INT8). Les fichiers de déploiement sont transmis par OTA à l'unité de calcul en périphérie (pack de mise à jour incrémentale d'environ 5 Mo par envoi).
Pipeline d'inférence (traitement par frame) : ① acquisition d'image par caméra (30 fps, resize 1920×1080 → 640×640) ② inférence TensorRT (YOLOv8n INT8, 5 à 8 ms) ③ post-traitement NMS (1 à 2 ms) ④ suivi d'objets ByteTrack (2 à 3 ms, basé sur filtre de Kalman + appariement hongrois) ⑤ calcul de distance de collision (1 ms) ⑥ écriture des résultats en mémoire partagée pour lecture par l'API. La latence totale par frame est de 10 à 14 ms, satisfaisant l'exigence de détection temps réel à 30 fps (intervalle de 33 ms par frame, laissant 19 à 23 ms pour la logique de niveau supérieur).
Suivi multi-cibles ByteTrack et calcul de distance de collision
YOLOv8n ne fournit que la détection d'objets par frame (boîte englobante + classe + confiance), sans suivi de trajectoire continue. L'algorithme ByteTrack, appliqué aux résultats de détection, prédit la position de chaque cible à la frame suivante via un filtre de Kalman, puis associe les détections aux trajectoires existantes par l'algorithme hongrois. Avantage de ByteTrack sur DeepSORT : pas d'extraction de caractéristiques ReID (économie du coût d'inférence CNN supplémentaire), ce qui le rend adapté au déploiement en périphérie avec des ressources de calcul limitées.
Calcul de distance de collision : à partir des positions et vecteurs de vitesse en temps réel de chaque équipement (crochet de pont roulant, AGV, personnel) obtenus par suivi de trajectoire, on calcule la distance de plus proche approche (DCPA) et le temps de plus proche approche (TCPA) entre chaque paire. Formule : DCPA = |d × (v_rel)| / |v_rel|, où d est la différence des vecteurs de position et v_rel le vecteur de vitesse relative. Une alerte est déclenchée lorsque DCPA < seuil de sécurité (1,5 m pont-pont, 2,0 m pont-personnel) ou TCPA < 2 s. Le calcul de collision est exécuté à chaque frame ; les résultats sont écrits dans un bloc de données en mémoire partagée (64 octets, incluant ID de cible, distance, vitesse, classe de risque) entre l'unité périphérique et l'API.
Configuration du protocole de communication entre l'unité périphérique et l'API
L'unité de calcul en périphérie échange des données avec l'API du pont roulant (S7-1200/1500) via Profinet ou Modbus TCP. Configuration recommandée : l'unité périphérique (Jetson Orin NX) exécute la pile de protocole Profinet esclave (pile PROFINET Siemens pour Linux + configuration de la carte réseau en RT Class 1, cycle de communication de 4 ms) ; côté API, l'unité périphérique est ajoutée comme périphérique IO Profinet dans la configuration matérielle. Bloc d'échange de données (64 octets en entrée/sortie) : entrée (unité périphérique → API) comprend la classe de risque de collision (0 à 3), la distance cible (mm), la vitesse recommandée (% de la vitesse nominale), l'état du système ; sortie (API → unité périphérique) comprend les coordonnées actuelles du pont, la vitesse, le mode de fonctionnement. Redondance de communication : en cas d'interruption de la connexion Profinet pendant plus de 3 cycles (12 ms), l'API bascule automatiquement en mode d'interverrouillage de base sans assistance IA ; une panne de l'unité périphérique n'affecte pas les opérations fondamentales du pont.
Validation du déploiement et indicateurs de performance
Kelude Industries Lourdes a déployé des unités de calcul en périphérie sur 12 ponts roulants dans une coulée continue d'une aciérie. Avant le déploiement, la détection de collision reposait sur l'observation visuelle humaine, avec un délai de réponse de 3 à 5 secondes. Après déploiement, les indicateurs clés sont : mAP@0.5 = 0,953 (moyenne sur cinq classes), latence d'inférence moyenne de 6,8 ms (INT8), délai de bout en bout de l'alerte de collision ≤ 50 ms (de la capture d'image à la déclenchement API), MTBF ≥ 10 000 heures (environ 14 mois). Sur les 6 mois suivant le déploiement, les événements à risque de collision sont passés de 23 par jour à 0,4 (les cas restants étant des évitements d'urgence dus à des entrées soudaines de personnel), et le score de satisfaction des opérateurs est passé de 62 à 91. Kelude Industries Lourdes propose un service complet, de la sélection du matériel et de l'entraînement du modèle au déploiement sur site. La rénovation d'un pont roulant avec calcul en périphérie coûte environ 1 900 à 3 200 EUR (unité périphérique + caméras + installation et mise en service).
Comparaison des performances d'inférence IA : FP16 vs quantification INT8
FP32 Brut Précision 12.5MB Latence d 18~25ms m AP 0.953(Maximum) pont roulant Non recommandé pour ce scénario | FP16 Demi Précision 6.3MB Latence d 8~12ms m AP 0.951(-0.2%) Nano Version recommandée | INT8 Quantification 4.2MB Latence d 5~8ms m AP 0.948(-0.5%) NXVersion recommandée |
Questions fréquentes sur les grues industrielles
Q : La puissance de calcul du RK3588 est insuffisante, pourquoi ne pas l'utiliser pour la vision IA ?
A : Le NPU du RK3588 ne délivre que 6 TOPS. L'inférence YOLOv8n en FP16 affiche une latence de 80 à 150 ms, ce qui ne permet pas d'atteindre une détection en temps réel à 30 fps (intervalle de 33 ms par image). En réduisant la cadence à 10 fps (latence de 100 ms acceptable), l'intervalle de détection devient trop grand pour les cibles mobiles rapides (un AGV à 1 m/s se déplace de 100 mm par image), ce qui dégrade fortement la précision de l'alerte de collision. Le RK3588 convient donc uniquement comme passerelle de collecte de données, et non pour l'inférence IA en temps réel. Kelude recommande au minimum le Jetson Orin Nano (40 TOPS), offrant le meilleur rapport performance/prix.
Q : Quelles configurations sont nécessaires pour la communication Profinet entre le boîtier périphérique et l'API ?
A : Trois étapes sont requises : ① installer la pile de protocole Profinet sur le système Linux du boîtier (recommandé : SDK PROFINET IO-Device de Siemens ou la pile open source pnio_stack), puis configurer le nom de l'appareil et l'adresse IP ; ② dans l'API (TIA Portal), ajouter le boîtier en tant qu'IO Device Profinet dans les appareils et le réseau, et attribuer les adresses d'E/S (64 octets en entrée et 64 octets en sortie) ; ③ implémenter les fonctions de lecture/écriture des données d'E/S dans l'application du boîtier, en écrivant les résultats d'inférence IA dans la zone d'entrée et en lisant l'état de l'API depuis la zone de sortie. La configuration initiale prend environ 1 jour. Kelude fournit une image de communication Profinet préconfigurée, permettant de passer directement à l'utilisation sans configuration lors du déploiement.
Q : Quelle quantité de données est nécessaire pour l'entraînement du modèle ? Quelle précision peut-on atteindre ?
A : Kelude recommande un minimum de 20 000 images annotées pour la première phase d'entraînement (au moins 4 000 images par catégorie), couvrant les conditions typiques de jour/nuit, ciel dégagé/nuageux et contre-jour. La mAP@0.5 peut atteindre 0,93 à 0,96. L'annotation des données est réalisée avec l'outil LabelImg (annotation par boîtes englobantes, environ 30 secondes par image). Kelude dispose déjà d'un ensemble de données de base de 120 000 images annotées de scénarios de ponts roulants. Les nouveaux clients peuvent affiner le modèle de base avec 500 à 1 000 images de leur propre environnement (fine-tuning), ce qui permet d'adapter le modèle en 2 à 3 jours avec une mAP stable au-dessus de 0,90.
Q : Le boîtier périphérique peut-il fonctionner de manière stable dans les aciéries et cimenteries à haute température et forte poussière ?
A : La version industrielle du Jetson Orin NX (Jetson Orin NX Industrial) prend en charge une plage de température étendue de -40 °C à 85 °C, avec dissipateur thermique et ventilateur actif en standard. Plus de 50 unités sont déployées dans les zones de coulée continue des aciéries (température ambiante de 45 à 55 °C, concentration de poussière d'environ 5 mg/m³), avec 12 mois de fonctionnement continu sans arrêt thermique. Le boîtier est installé dans une armoire de protection IP54 (avec ventilateur de refroidissement et filtre anti-poussière) ; la température du GPU mesurée reste stable entre 65 et 72 °C. Kelude propose en option une armoire anti-poussière et haute température (avec refroidissement par air forcé et surveillance de la température), au prix de 800 €/unité.
