Updated doc

This commit is contained in:
2023-04-03 12:52:56 +02:00
parent a7009dcc21
commit 5b8b7b6c0b
6 changed files with 174 additions and 1 deletions
@@ -134,4 +134,4 @@ Quand le programme affiche les data :
- Si on doit passer par une capture d'écran, trouver un moyen de stocker les données de manière à prévoir que parfois un tour pourrait avoir plus de données qu'un autre, que le user peut mettre pause, ou même quil revienne en arrière.
- Développer des algorithmes pour récupérer les données comme les différents pneus utilisés ou l'activation du DRS ainsi que développer des moyens de nettoyer les résultats de l'OCR (Par exemple utiliser différents champs redondants pour comparer les résultats)
- Stocker les données sur une base pour les traiter plus tard tout en prévoyant un moyen de voir les stats live
- Développer des algorithmes de prédiction qui prennent en compte d'anciennes courses pour tenter de prédire des choses comme les arrêts aux stands par exemple.
- Développer des algorithmes de prédiction qui prennent en compte d'anciennes courses pour tenter de prédire des choses comme les arrêts aux stands par exemple.
Binary file not shown.

After

Width:  |  Height:  |  Size: 545 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 574 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 608 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 34 KiB

+173
View File
@@ -597,3 +597,176 @@ Et c'est tout pour aujourd'hui je pense. Ce qui serait cool demain c'est que je
Note pour quand je ferai les tests. Je pense que la meilleure idée serait que je prenne pleins de photos du style et que je les mette dans un fichier CSV ou JSON avec leur contenu. Et ensuite je le fais passer en tests pour calculer la prescision de mon algo de décodage.
Pour le moment on est plutôt dans les clouts niveau planning.
## Mardi 4 Avril
Aujourd'hui je suis scensé plutôt bosser sur l'interpretation des données, mais une idée m'a taraudé l'esprit toute la nuit. Est-ce que je ne pourrais pas quand même essayer de décomposer la zone de pilote directment comme pour la Main zone.
Pour ce faire j'ai tenté de faire comme pour la main zone c'est à dire lancer la reconnaissance pour savoir ou étaient tous les champs de données mais malheureusement je ne pense pas que cela va être possible.
En effet non seulement ici les champs sont de tailles très variées, mais en plus la reconnaissance n'arrive pas à en récupèrer le même nombre sur chaque ligne ce qui risque d'être complexe à utiliser ensuite.
La preuve :
!["Tentative d'auto calibration"](./Images/Screens/AutoCalibration6.png);
Cependant tout n'est pas perdu ! Il y a peut-être un moyen qui serait mieux en tous points. Le soucis avec ce type de reconnaissance c'est qu'on utilise beaucoup de ressources inutiles. On peut peut-être hard coder la valeur des diviseurs et les utiliser pour créer des zones.
Ok alors visiblement c'est un problème car il semble y avoir d'autres pixels de cette couleur dans l'image (Qui l'aurait cru lol)
!["Tentative 2"](./Images/Screens/AutoCalibration7.png)
J'a tenté de réduire la tolérance mais le soucis c'est que c'est soit trop soit pas assez
Dernière tentative, j'ai essayé de prendre plusieurs pixels en hauteur pour chaque incrément de X et en faire la moyenne, et même comme ca, impossible de trouver de manière efficace les zones. Je pense que je vais donc revert tous mes changements pour revenir à la version ou on les choisissait manuellement.
Pas mal de temps perdu mais bon c'est comme ca ca arrive
Bon j'ai fait un revert mais j'ai ajouté une feature importante. Les zones font la largeur indiquée par l'utilisateur mais elles font la hauteur max comme ca toutes les window font la même hauteur et ca permet à l'utilisateur de ne pas forcément être ultra précis dans sa selection.
Ce qui nous donne :
!["Resultat final"](./Images/Screens/AutoCalibration8.png)
Maintenant je dirais que les deux prochaines choses à faire seraient de stocker ces zones dans un fichier JSON ou autre pour que la calibration puisse être envoyée directement dans le logiciel de reconnaissance et ensuite de faire une calibration sur des images qui font la taille qu'on aura pendant les Grands Prix. Pour le moment elles sont au format 16:10 qui est le format d'écrant de mon laptop.
Pour le stockage j'imagine un fichier qui donne des indications assez simples qui permettent de reconstruire le total des zones quand il est importé plutot que d'écrire les coordonnées en dur pour chacunes.
Chaque Grande zone va implémenter une methode qui s'occupe de mettre tous ses enfants dans un fichier.
```JSON
{
"MainZone":{
"x": 10,
"y": 20,
"width": 1450,
"height": 1340,
"DriverZone":{
"x": 0,
"y": 23,
"height": 25,
"Windows":[
{
"DriverPositionWindow":{
"x": 0,
"y": 0,
"width": 35
}
},
{
"DriverPositionChangesWindow":{
"x": 0,
"y": 0,
"width":45
}
}
]
}
}
}
```
C'est le résultat auquel j'aimerais arriver. Mais pour y arriver il faut encore que je crée les différents types de window.
Cela veut dire que je dois décider quelles informations je vais récupèrer de la page.
Par exemple je vais conserver la position du pilote mais au final les changements de positions sont difficiles à lire et sont redondants. Si je garde un historique des positions des pilotes je peux calculer moi même les changements.
Pareil pour gap avec la voiture devant. Je pense que je vais juste garder l'information des écarts absolus et ensuite je pourrai toujours calculer la différence entre les pilotes.
Ca peut paraître bête car cela rajoute du calcul mais en réalité le calcul de l'OCR est extrêmement gourmand alors il faut que j'évite le plus possible d'y faire recours. Il est bien plus rapide de calculer les écarts que d'essayer de reconnaitre le texte et le convertir en chiffre.
J'ai visiblement ajouté un bug dans mon code. Maintenant tous les pilotes ont la même image quand on les selectionne. Mais visiblement ca n'était pas le cas avant car j'avais pu prendres des images de chaque pilote.
J'ai passé 3 minutes à fixer un bug stupide j'ai un peu envie de brûler ma place de travail... Mais bon au moins maintenant cela fonctionne !
Toutes les images sont récupèrées et ont un format correct avec le bon nom :
!["Verstappen folder"](./Images/Screens/VerstappenFolder.png)
Avec un peu de code très moche j'ai pu créer un fichier JSON qui contient les différentes infos. Cependant en exportant TOUT on se retrouve avec un fichier de 1200 lignes ce qui n'est pas optimal.
Mais quand on regarde, il devrait être possible de faire un fichier qui ne contient que les infos d'un seul pilote car ensuite il y a simplement un offset à appliquer sur la zone et les windows.
Je vais donc pouvoir commencer enfin le logiciel de décodage qui prend en entrée un fichier JSON comme celui ci qui a été génèré avec le programme de calibration.
```Json
{
"Main": {
"x": 40,
"y": 230,
"width": 1845,
"height": 719,
"Zones": [
{
"DriverZone": {
"x": 0,
"y": 3,
"width": 1845,
"height": 35,
"Windows": [
{
"Position": {
"x": 2,
"y": 0,
"width": 32
},
"GapToLeader": {
"x": 204,
"y": 0,
"width": 96
},
"LapTime": {
"x": 413,
"y": 0,
"width": 105
},
"Drs": {
"x": 526,
"y": 0,
"width": 81
},
etc...
}
]
}
}
]
}
}
```
Dans le futur il faudrait ajouter d'autres choses comme par exemple les différents pilotes présents sur le Grand Prix et ce genre d'infos.
Quoique je vais l'ajouter déja maintenant et plus tard je mettrai en place la feature acessible depuis l'interface. Mais le hardcoder maintenant me permet déja de mieux coder l'autre côté.
Ce programme n'est en aucun cas terminé et je vais devoir travailler encore un peu dessus pour qu'il soit utilisable correctement mais au moins il fonctionne à peu près.
Exemple du json avec les noms de pilotes:
```Json
{
"Main": {
"x": 37,
"y": 238,
"width": 1851,
"height": 713,
"Zones": [
{
"DriverZone": {
"x": 0,
"y": -5,
"width": 1851,
"height": 35
}
}
]
},
"Drivers": [
"Leclerc",
"Verstappen",
etc...
]
}
```
Maintenant je vais m'attaquer au décodage.