Vous pouvez me dire comment détecter des défauts d...
Criado em: 14 de agosto de 2026
Respondido usando GPT-5.6 Thinking por Chat01
Criado em: 14 de agosto de 2026
Respondido usando GPT-5.6 Thinking por Chat01
Vous pouvez me dire comment détecter des défauts de l'ombrage sur les sites ou systèmes solaires photovoltaïques en utilisant un système de détection automatique en des modèles de Deep learning comme MobileNetV2 et YOLOv8-nano ? je veux savoir tous sur ce défaut spécifique.
Oui. Pour un système photovoltaïque, l’ombrage partiel mérite d’être traité comme une anomalie opérationnelle spécifique : il peut réduire fortement la production, créer un mismatch entre cellules/modules, activer les diodes bypass et, dans certaines conditions, placer des cellules en polarisation inverse et favoriser des points chauds. La perte de puissance n’est pas nécessairement proportionnelle à la surface ombragée, car elle dépend aussi de la topologie série/parallèle et des diodes bypass. Des courbes P–V sous ombrage partiel peuvent notamment présenter plusieurs maxima locaux. (PVP-MC)
Je vous conseille de ne pas définir seulement deux classes normal / ombrage. Pour un projet sérieux, séparez au minimum :
| Classe | Signification |
|---|---|
normal | Module normalement éclairé |
partial_shading | Une partie du module est ombragée |
full_shading | Presque tout le module est dans l'ombre |
vegetation_shading | Ombre causée par arbre/végétation |
structure_shading | Bâtiment, poteau, cheminée, clôture… |
row_shading | Auto-ombrage entre rangées |
temporary_shading | Nuage ou objet temporaire |
hotspot | Échauffement local anormal |
soiling | Salissure — important comme classe négative |
normal_reflection | Reflet solaire — autre faux positif important |
Il faut surtout distinguer l'ombre elle-même de ses conséquences électriques ou thermiques. Par exemple, un hotspot peut être associé à un mismatch dû à l'ombrage, mais un hotspot peut aussi avoir une autre origine. Les travaux de NREL montrent que la polarisation inverse et les fortes dissipations locales peuvent produire un échauffement et, selon la technologie PV, une dégradation permanente. (OSTI)
MobileNetV2 est particulièrement adapté à la classification.
Vous lui donnez par exemple cette image :
[image d'un module PV]
et il renvoie :
textNormal : 0.03 Ombrage partiel : 0.94 Salissure : 0.02 Hotspot : 0.01
MobileNetV2 utilise notamment des inverted residuals et des linear bottlenecks et a été conçu pour obtenir un bon compromis entre capacité de représentation et coût de calcul sur des plateformes à ressources limitées. (arXiv)
Avantage : très intéressant si votre caméra fournit déjà une image centrée sur un seul panneau/module.
Inconvénient : il vous dit essentiellement ce qu'il y a dans l'image, mais pas précisément où se trouve l'ombre.
YOLOv8n est beaucoup plus approprié lorsque vous voulez obtenir :
textModule 27 └── Ombrage ├── bounding box ├── confiance = 0.91 └── position dans l'image
Vous pouvez donc traiter une photographie contenant 20, 50 ou 100 modules simultanément et obtenir les modules ou zones affectés. YOLOv8 supporte notamment détection, segmentation et classification; yolov8n.pt correspond à sa variante légère nano. (Ultralytics Docs)
Pour votre application, je privilégierais donc :
YOLOv8n → localisation
MobileNetV2 → classification/confirmation
plutôt que d'essayer de faire exactement la même chose avec les deux réseaux.
Pour obtenir un système fiable sur un véritable site photovoltaïque :
textSITE PHOTOVOLTAÏQUE │ ┌────────────┴────────────┐ │ │ Caméra RGB Caméra IR │ │ ▼ ▼ YOLOv8-n MobileNetV2 │ │ Localisation ombrage État thermique + modules affectés du module │ │ └──────────┬──────────────┘ │ ▼ Fusion des résultats │ ┌─────────────┴─────────────┐ │ │ Irradiance / météo V, I, P DC │ │ └─────────────┬─────────────┘ ▼ ALGORITHME DE DÉCISION │ ▼ Diagnostic final
Par exemple :
textYOLO : ombrage détecté = 92 % Thermique: anomalie détectée = 81 % SCADA : déficit de puissance = 17 % => ALERTE : Ombrage partiel confirmé Module/string : S04-M17 Sévérité : élevée
Cette fusion est beaucoup plus robuste qu'une décision basée uniquement sur une photographie.
C'est extrêmement important.
Une caméra RGB peut parfaitement voir une ombre, mais cela ne signifie pas nécessairement qu'elle entraîne une anomalie de maintenance importante.
Inversement, la caractéristique électrique peut montrer :
Ces comportements sous ombrage partiel sont bien documentés dans les travaux PV de Sandia/NREL. (PVP-MC)
Une approche intelligente est donc de calculer :
puis :
où tient compte au minimum de l'irradiance et de la température. Les modèles de performance PV utilisent justement irradiance, température et caractéristiques électriques pour estimer le comportement attendu du module ou du champ. (PVP-MC)
Le meilleur système utilise les deux.
Très efficace pour reconnaître :
YOLOv8n convient très bien à ce problème.
Elle permet de rechercher les conséquences thermiques du mismatch électrique :
La thermographie extérieure des centrales et modules PV fait d'ailleurs l'objet de la spécification IEC TS 62446-3, qui couvre notamment conditions environnementales, instrumentation, procédure d'inspection et classification des anomalies thermiques. (IEC Webstore)
Mais il faut éviter la règle simpliste :
« zone ombragée = zone froide »
Ce n'est pas toujours vrai électriquement. Une cellule affectée peut dans certaines situations devenir une zone de dissipation et donc être plus chaude que son environnement. (OSTI)
C'est probablement la partie la plus importante du projet.
Un excellent réseau entraîné sur un mauvais dataset donnera un mauvais système.
Votre dataset devrait contenir différentes :
Vous devez également mettre beaucoup d'exemples difficiles :
textombre vs salissure ombre vs reflet ombre vs nuage ombre vs cellule sombre ombre vs module endommagé hotspot lié à ombrage vs hotspot d'une autre origine
C'est souvent là que se décide la qualité réelle du système.
Deux stratégies sont possibles.
Vous annotez tout le module :
text┌─────────────────────┐ │ │ │ PANNEAU │ │ ///////// │ │ //ombre// │ │ ///////// │ │ │ └─────────────────────┘ Bounding box = panneau complet Classe = partial_shading
C'est simple et généralement efficace pour la maintenance.
text┌─────────────────────┐ │ panneau │ │ │ │ ┌──────┐ │ │ │ombre │ │ │ └──────┘ │ │ │ └─────────────────────┘
Vous pouvez alors calculer approximativement :
Mais la surface ombragée ne doit pas être directement assimilée à la perte électrique : deux ombres de même superficie peuvent affecter différemment les cellules/substrings et les diodes bypass. (PVP-MC)
Pour mesurer réellement la surface de l'ombre, je préférerais même YOLOv8n-seg, qui fournit un masque, plutôt qu'une simple bounding box. YOLOv8 prend en charge la segmentation d'instances en plus de la détection. (Ultralytics Docs)
Vous pourriez utiliser :
textdataset/ │ ├── train/ │ ├── normal/ │ ├── partial_shading/ │ ├── severe_shading/ │ ├── hotspot/ │ └── soiling/ │ ├── validation/ │ ├── normal/ │ ├── partial_shading/ │ ├── severe_shading/ │ ├── hotspot/ │ └── soiling/ │ └── test/ └── ...
Pour le transfert d'apprentissage :
pythonbase_model = MobileNetV2( weights="imagenet", include_top=False, input_shape=(224, 224, 3) )
puis typiquement :
textMobileNetV2 ↓ GlobalAveragePooling ↓ Dropout ↓ Dense ↓ Softmax
Avec l'implémentation TensorFlow/Keras de MobileNetV2, preprocess_input ramène les valeurs d'entrée dans l'intervalle . (TensorFlow)
La logique est par exemple :
pythonfrom ultralytics import YOLO model = YOLO("yolov8n.pt") model.train( data="pv_shading.yaml", epochs=100, imgsz=640, batch=16 )
avec un fichier :
yamlpath: dataset train: images/train val: images/val test: images/test names: 0: normal_panel 1: partial_shading 2: severe_shading 3: vegetation_shading
Ultralytics fournit directement les modes entraînement, validation, prédiction, export et benchmark pour ces modèles. (Ultralytics Docs)
C'est une erreur très courante dans les projets PV.
Imaginons qu'un drone fasse une vidéo :
textframe 001 frame 002 frame 003 frame 004 ...
Ne mettez pas :
textframe 001 -> train frame 002 -> test frame 003 -> train
Les images sont presque identiques.
Le réseau peut obtenir artificiellement :
textAccuracy = 99 %
sans réellement généraliser.
Je recommande plutôt de séparer par :
textsite + date d'acquisition + rangée + séquence de vol
Par exemple :
textSite A + Site B -> train Site C -> validation Site D -> test
Ce test est beaucoup plus sévère mais représente réellement la capacité du système à fonctionner sur une installation inconnue.
Pour MobileNetV2 :
mais surtout :
et la matrice de confusion.
Pour YOLO :
Dans votre cas, le Recall de la classe ombrage est particulièrement important : un système qui ne génère presque jamais de fausses alarmes mais manque beaucoup de vrais cas d'ombrage n'est pas très utile.
Une seule image peut créer un faux diagnostic.
Considérez :
textt = 0 s ombre détectée t = 1 s ombre détectée t = 2 s ombre détectée t = 3 s aucune ombre
Probablement phénomène temporaire.
Mais :
text08:00 -> ombrage 08:10 -> ombrage 08:20 -> ombrage ... 10:00 -> ombrage
le système possède davantage d'éléments pour considérer l'événement comme significatif.
Vous pouvez donc ajouter un filtre :
plutôt que :
C'est une différence majeure entre un prototype de Deep Learning et un véritable système de diagnostic PV.
Je proposerais cette architecture :
textDRONE / CAMÉRA FIXE │ ├──────────── RGB ────────────────┐ │ │ │ YOLOv8-nano │ │ │ localisation ombrage │ │ └──────────── IR ─────────────────┤ │ MobileNetV2 │ diagnostic thermique │ ▼ FUSION DES DONNÉES │ ┌───────────────────┼───────────────────┐ │ │ │ irradiance V/I/P string historique │ │ │ └───────────────────┼───────────────────┘ ▼ MOTEUR DE DÉCISION │ ┌───────────────────────┴────────────────────────┐ ▼ ▼ NORMAL OMBRAGE │ ┌────────────┼────────────┐ ▼ ▼ ▼ faible moyen sévère │ │ │ └────────────┼────────────┘ ▼ alerte maintenance
C'est l'approche que je trouve la plus pertinente pour votre cas : YOLOv8n voit et localise l'ombrage, MobileNetV2 apporte une classification légère, et les mesures électriques/thermiques servent à confirmer que l'ombre est réellement problématique.
YOLO peut ensuite être exporté vers ONNX, TensorRT, OpenVINO et plusieurs autres formats, ce qui facilite un déploiement sur PC industriel ou matériel embarqué. (Ultralytics Docs)
Si votre objectif est un mémoire, PFE, master ou article scientifique, ne formulez pas simplement le problème comme :
« détecter une ombre avec YOLO ».
Un sujet nettement plus solide serait :
« Détection, localisation et diagnostic automatique de l'ombrage partiel dans les systèmes photovoltaïques par fusion d'imagerie RGB/thermique et de données électriques, utilisant YOLOv8-nano et MobileNetV2. »
Cela vous permet d'étudier séparément détection → localisation → classification → sévérité → validation électrique → décision de maintenance, ce qui correspond beaucoup mieux au problème physique réel de l'ombrage photovoltaïque.