# Rapport Track Trends V1.0

----

Rohmer Maxime Travail de diplôme Technicien ES 2023

[INSERT POSTER]

## Introduction

----

### Résumé

Track Trends est un outil de récupération et d'analyse de données de courses de Formule 1.

Pour le contexte, en dehors des cours, j'exerce différentes activités dont celle de Live Ticker F1 pour le 20 minutes. Pour m'aider dans ce travail, j'utilise actuellement la F1TV à laquelle je suis abonné qui me propose non seulement un feed vidéo de meilleure qualité avec des commentaires plus pertinents que ceux de la RTS mais qui aussi me permet d'accéder à un feed vidéo très important : la chaine data.

Ce dernier ressemble à cela :

!["Screenshot du feed data de la f1tv"](./Images/Screens/ScreenF1TvData.png)

(Attention ce n'est pas un joli tableau HTML, mais bien une vidéo qui contient un tableau.)

Sauf que toutes les informations sont étalées pêle-mêle sans hiérarchie ce qui fait que cela me prendrait trop de temps de tout déchiffrer à chaque fois, ce qui me fait rater des choses intéressantes.

Le but du projet est donc de fournir un outil qui hiérarchise et affiche différemment les données pour faciliter leur lecture et me permettre de faire de meilleurs commentaires.

### Abstract

Track Trends is a Formula 1 data and analysis tool.

To understand everything, a little bit of context. In my free time I have multiple activities and one is to be the Live Ticker F1 for the local journal "20 minutes". to help me in this work I'm currently using the F1TV to which I'm currently subscribed because it provides me with a better video feed with better commentary than the ones from the RTS (in my opinion) but also because it gives me access to a very important video feed : the data channel

See the screenshot above to see what it looks like.

[note: It's a pretty HTML table but a full on video feed that contains a table (probably, so you can't access data directly)]

You can see a lot of data all well and good BUT! All the data is displayed the same in a big table which make it really hard to read totally in a hurry, which means that I miss a lot of useful information.

The point of the project then is to provide with a tool that can display those data by taking into account their relevance. That would help me not miss any and provide a better commentary by never missing out battles, and be able to better write with the time I saved by using it.

### Description du besoin

Comme expliqué dans le résumé, je suis Live Ticker F1. Mais pour mieux comprendre le besoin que j'ai, je pense qu'il est pertinent de comprendre comment je travaille.

Pendant un Grand Prix de Formule 1 j'ai plusieurs tâches à effectuer :

- Suivre les différents évènements du Grand Prix
- Changer le titre et la photo de titre du Live
- Chercher des Tweets ou des Images à intégrer
- Ecrire les commentaires en faisant attention à dire ce qu'il se passe mais aussi l’expliquer, ce que cela implique, mais aussi ce que cela veut dire pour le reste de la course.
- Comprendre et expliquer les stratégies

Tout cela toutes les cinq minutes max...

Cela veut dire que je dois être le plus rapide possible quand je cherche des informations. Et comme le tableau en comporte trop et bien, je suis obligé de le lire en diagonale.

Par exemple dans le tableau, les infos que je cherche le plus sont :

- Le nombre de places gagnées (surtout au départ)
- Les écarts entre les pilotes (surtout ceux qui sont en dessous de deux secondes).
- Les pneus de chaque pilote et combien de tours, ils ont fait dessus
- Les temps d'arrêts aux stands
- Les temps au tour (surtout pour la stratégie)

Mais pleins d'autres informations existent si on les recoupe sur plusieurs tours.

Un outil qui permettrait de mettre en évidence les informations importantes serait donc une très grosse plus-value pour mon travail et s'il est facile à installer et à utiliser, il se pourrait qu'il devienne indispensable.

## Cahier des charges

----

Il s'agit d'une version coupée du cahier des charges qui ne contient pas l'explication du contexte. Mais l'original est disponible sur ce site également. Il est toutefois normal d'y voir des choses répétées ou légèrement différentes, en effet, il n'a pas été écrit en même temps que le reste de ce document.

### Projet

----

Un outil de style compagnon sous forme d'application C# Windows Form qui récupère en temps réel les informations de la course et affiche les informations les plus importantes. Le but est non seulement de faciliter mon job, mais aussi faire en sorte d'améliorer la plus-value de mon travail en me permettant de fournir des commentaires qui ne sont pas disponibles pour le tout venant qui regarde simplement le flux RTS.

Exemples :

- Les pilotes qui sont proches (moins de 1-2 secondes qui sont donc en train de se battre).
- Les pilotes qui améliorent leur temps au tour et ceux qui perdent le plus de temps
- Le classement pondéré tenant compte des futurs arrêts au stand

Maintenant afficher différemment les infos, c'est sympa, mais cela serait encore mieux de traiter ces data et de permettre des petites prédictions.

Exemples :  

- Prédire les arrêts aux stands en prenant en compte les baisses de performances des pneus
- Prédire le pneu que le pilote va chausser s'il rentre aux stands dans le prochain tour
- Prédire dans combien de tour tel pilote va rattraper tel autre pilote
- Prédire combien de temps le pilote va perdre dans les stands en fonctions des arrêts précédents

### Réalisation

Malheureusement, la Formula 1 Management ne propose aucune API publique qui puisse nous permettre de faire ce projet "simplement".
La raison la plus probable étant qu'Amazon avec son service AWS propose exactement ce genre de services pour le flux télévisé et il doit y avoir un contrat d'exclusivité.

Il existe des API "Pirates" faites par la communauté, le problème est qu'elles ne sont pas forcément des plus pratiques à utiliser.

Mais comme je possède un abonnement premium ++ à la F1TV, j'ai accès pour chaque grand prix à un flux vidéo nommé : DATA F1 CHANNEL

Qui ressemble à ça :

!["Data channel exemple"](./Images/Screens/Formula1DataChannel.png)

Donc la seule façon que je vois de récupérer ces données est de les prendre directement sur ce feed.

Même si le but final de l'application est de faire pleins de choses super avec les datas, le gros du projet va surtout être la récupération des données et leur stockage.

Les données viennent du flux vidéo et ainsi dans un premier temps, il va falloir récupérer d'une manière ou d'une autre des images qui viennent d'un grand prix en direct ou en rediffusion.

Ensuite, dans un second temps, il faut lire les informations directement sur l'image en utilisant une librairie prévue pour (exemple Tesseract) et vérifier l'intégrité de ces dernières pour qu'on puisse ensuite les stocker.

Dans un troisième temps, il faut stocker toutes ces données dans une forme qui permette d'aller facilement faire des requêtes de récupération et déjà préparer des méthodes qui permettent de récupérer des infos importantes (ex : la moyenne des cinq derniers tours, le temps moyen d'arrêt etc.) pour faciliter la dernière étape

Quand tout cela est fait, on peut ensuite s'amuser un peu avec les Data.

La dernière étape est donc l'affichage. L'idée est de créer une Windows Form qui contienne toutes ces informations dans un format beaucoup plus lisible et avec laquelle on pourrait interagir pour permettre de plus facilement commenter les Grands Prix. (exemple plus bas avec un croquis de ce à quoi l'application pourrait ressembler)

Voici la liste des données qui pourraient être affichées (Non contractuel, simplement des idées).

- Les pilotes qui sont proches (moins de 1-2 secondes qui sont donc en train de se battre).
- Les pilotes qui améliorent leur temps au tour et ceux qui perdent le plus de temps
- Le classement pondéré tenant compte des futurs arrêts au stand
- La moyenne de temps que les pilotes perdent dans les stands
- La performance moyenne des 5 types de pneus
- La moyenne de temps de chaque pilote sur le pneu actuel
- Le nombre de points que chaque pilote gagnerait selon sa position
- Le classement de la course

Voire même si c'est possible :

- Prédire les arrêts aux stands en prenant en compte les baisses de performances des pneus
- Prédire le pneu que le pilote va chausser s'il rentre aux stands dans le prochain tour
- Prédire dans combien de tour tel pilote va rattraper tel autre pilote
- Prédire combien de temps le pilote va perdre dans les stands en fonctions des arrêts précédents
- Prédire les temps au tour de chaque pilote selon l'usure des pneus

Voici un exemple d'interface possible pour une page :

!["Proto"](./Images/Figma/Prototype.png)

### Cas d'utilisation

----

*On va considérer que tous les user ont un abonnement F1 TV PRO

Un user veut récupérer les data :

- Il ouvre son navigateur et lance la page DATA de la F1 TV
- Il calibre la capture des data via le programme   (pour la première utilisation).
- Il confirme que les données initiales sont bonnes (pour la première utilisation).
- Il regarde tranquille son Grand Prix

Le programme récupère les data :

- Il récupère des images depuis la F1TV
- Il utilise Tesseract (ou autre) pour en récupérer les infos.
- Il met ces infos dans un Objet Pilote, dans un Objet course avec un attribut tour pour hiérarchiser les data

Pour ce qui est de l'affichage, l'idée est de faire une application C# comme on l'a appris à l'école, mais avec assez de style pour qu'elle puisse être agréable à utiliser.

Quand le programme affiche les data :

- Il prend les données venant directement de la F1TV.
- Il affiche différemment les données pour permettre une meilleure lisibilité
- Il interprète avec des règles plutôt simples certaines data pour faire des miniprédictions ou aider à la lecture
- Il récupère des infos d'autres courses pour les comparer et proposer des prédictions plus intéressantes

### Difficultés techniques

----

- Récupérer un flux vidéo plutôt propre malgré les contres mesures de la F1 TV pour en empêcher la lecture par un logiciel
- 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 qu’il 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.

## Différences sur le cahier des charges

----

[À remplir dans les dernières semaines du travail de diplôme]

## Planning prévisionnel

----

Mes suiveurs m'ont demandé un planning de type GANTT pour ce travail de diplôme

Je n'ai pas utilisé un logiciel particulier pour faire ce dernier, mais je me suis inspiré des principes fondamentaux d'un diagramme de ce type.

Comme l'original a été fait sur Excel, je ne peux pas vraiment l'insérer de manière lisible ici, mais il est disponible dans le dossier Planning.

Mais voici un résumé de son contenu :

### Tâches

J'ai décidé de décomposer mon planning en trois grands types de tâches.

1. Programmation
2. Documentation
3. Tests

L'idée est de permettre une meilleure lisibilité et de me permettre à moi de me faire plus facilement à l'idée de ce qu'il m'attend.

Voici la liste des tâches par rubrique :

#### PT

Cette rubrique contient les tâches qui n'ont pas leur place dans les trois catégories principales.

##### PT1 / préparation au travail de diplôme (2)

Cette tâche est un peu hors catégorie, mais c'est normal, c'est une supertâche qui regroupe beaucoup de choses. C'est une tâche qui est planifiée pour deux jours et qui normalement devrait être faite les deux premiers jours du travail.

Le but est de préparer tout ce qui peut être préparé en avance niveau documentation et mise en place pour ne pas avoir besoin de s'en soucier ensuite.

#### DT

Rubrique documentation qui contient toutes les tâches en rapport de près ou de loin avec la documentation du projet.

##### DT1 Création du poster (1)

Cette tâche consiste à faire une version numérique du poster qui soit en accord avec les consignes qu'on nous a données. Le but est aussi et surtout de faire poster dont je sois fier et que je sois content de montrer.

Il y a déjà des croquis de poster et j'ai clairement prévu de travailler sur ça pendant les vacances alors, je n'ai mis qu'un jour et je l'ai placé juste avant le rendu de ce dernier.

##### DT2 Documentation Analyse de l'existant (2)

Cette tâche est dédiée à l'écriture de la documentation et plus précisément de l'analyse de l'existant.

Comme il y a pas mal de technologies utilisées dans mon projet, j'aimerais faire correctement un vrai debrief de pourquoi j'ai utilisé l'une ou l'autre alors, j'ai assigné deux jours dessus.

##### DT3 Documentation Analyse organique (5)

Cette tâche est la plus grosse dans la catégorie documentation. Il s'agit de documenter comment l'application fonctionne.

J'y ai mis cinq jours et je pense que c'est un minimum car c'est dans cette tâche que je vais devoir détailler exactement comment fonctionne chaque partie du projet.

Ces cinq jours sont éparpillés sur le projet en général à la fin du développement de chaque grande partie de projet. Le but est de ne rien oublier et de ne pas avoir à tout faire en même temps.

##### DT4 Documentation Analyse fonctionnelle (2)

Cette tâche est déjà moins grosse, elle consiste à documenter le fonctionnement de l'application et comment utiliser les composants que j'ai développés.

Je l'ai mis en fin de projet, car comme j'ai l'habitude de faire des analyses fonctionnelles plutôt précises, le moindre changement dans l'UI peut tout rendre obsolète.

J'y ai mis deux jours, car j'aimerais correctement documenter avec de bonnes photos et scénarios pour qu'on puisse voir toutes les possibilités de l'application.

##### DT5 Documentation Tests (1)

Cette tâche est un peu plus petite qu'elle ne le devrait. Elle concerne la documentation des différents tests. Je n'y ai mis qu'un seul jour, car en réalité les différentes tâches de tests contiennent aussi beaucoup de documentation,

##### DT6 Documentation Reste (2)

Cette tâche est une tâche un peu vague. Elle contient toutes les actions autres que j'aurai besoin de faire (Mise au propre, orthographe, génération de PDF ...). J'y ai mis deux jours pour avoir un peu de marge, car ce sont toujours des tâches qui paraissent faciles, mais qui à la fin prennent beaucoup de temps si on les fait bien.

#### PT

Rubrique programmation qui contient toutes les tâches qui touchent à la programmation et au développement de l'application.

##### PT1 Programmation récupération des images (3)

Cette tâche est estimée à seulement trois jours, il ne faut pas s'y méprendre, c'est une des tâches les plus dures et lourdes niveaux documentation en explications. Cependant, un POC (Proof Of Concept) assez avancé a déjà été fait et donc cela permet de n'envisager que trois jours, car il suffit de l'implémenter et de la paufinner.

Cette tâche consiste à prendre en entrée un lien de Grand Prix et de sortir une image tous les x secondes de la page DATA. Cela peut sembler simple, mais pour le faire sans prendre d'espace d'écran et ne demandant pas à l'utilisateur de copier-coller quoi que ce soit où de donner ses identifiants F1TV c'est un challenge.

Cela peut paraitre curieux alors de mettre cette tâche loin dans le planning même si c'est la première étape du projet. Encore une fois cela s'explique avec le fait qu'il y a déjà un POC qui fonctionne à peu près et que donc préfère commencer avec des tâches plus incertaines dans le cas où elles prendraient plus de temps que prévu.

##### PT2 Programmation OCR (5)

Cette tâche consiste à développer la partie qui reconnait le texte sur les images. C'est très certainement la tâche qui risque le plus de déborder car c'est celle qui est la plus complexe techniquement puisqu'elle demande non seulement la lecture sur image, mais aussi le développement d'algorithmes de traitement de cette donnée pour être sûr qu'elle a bien été lue.

J'y ai ainsi alloué cinq jours, mais j'espère que j'arriverai à gagner du temps sur les autres pour y allouer plus dans le planning effectif, car je suis convaincu que plus, on y passe du temps, meilleur sera le résultat.

##### PT3 Programmation, stockage et modèle (5)

Cette partie est moins technique, mais concerne le stockage des données que nous retourne la lecture des images. Mais elle va demander de la réflexion et de l'intelligence de programmation, car il faut que cette partie anticipe les besoins de la vue et prépare un terrain fertile qui ne demande pas un refactor quand on passera au développement de la vue.

C'est pour cela que je lui ai aussi assigné cinq jours de travail et elle doit absolument être commencée après la lecture.

##### PT4 Programmation Vue de l'APP (5)

Cette partie peut être horrible comme très facile, cela dépend complètement de la qualité du travail avant. Si le modèle est parfait et que les données sont intègres, cela devrait être plutôt simple de les afficher de manière intéressante. Cependant, cette partie débordera sûrement un peu, car tout le temps gagné avec de bonnes données sera utilisé pour tenter de faire de la prédiction.

Pour ces raisons, je lui ai assigné également cinq jours de travail et elle doit absolument être faite après le modèle.

##### PT5 Programmation mise en commun (3)

Cette tâche est aussi un petit peu spéciale, car elle regroupe plusieurs choses. En gros, chaque partie de programmation sera sûrement assez indépendante et il faudra à un moment faire un seul projet C# qui contient tout.

Il est difficile d'estimer à quel point cela va être compliqué alors, j'ai été conservateur et j'ai mis trois jours.

#### TT

Cette rubrique contient les tâches qui sont uniquement des tests. La plupart des tâches de programmations contiennent déjà des tests, mais certaines demandent une attention particulière.

##### TT1 Tests OCR (2)

Cette tâche est une des tâches les plus importantes. Son but est de faire un protocole de tests complet qui permette de comparer les différents algorithmes de reconnaissance de texte.

Je l'ai mise après la reconnaissance, mais même maintenant en écrivant ces lignes, je me dis que dans le planning effectif, elle sera faite pendant la tâche de programmation. En effet, comment savoir si mon tout nouvel algorithme est réellement mieux que le précédent.

Je prévois deux jours, car je pense que faire le dataset va prendre beaucoup de temps, il faut prévoir un certain nombre d'images et de texte qui pourront ensuite être données sous forme de tests. C'est certes une tâche de test, mais c'est aussi de la programmation.

##### TT2 Tests finaux (2)

Cette tâche de tests est un peu vague, elle regroupe les différents tests pour vérifier que les données sont bien affichées correctement. Ce qui serait cool si j'ai du temps en fin de travail de diplôme serait de faire un système de test qui permet d'entrainer le programme à mieux reconnaitre certaines choses comme des arrêts aux stands si on lui donne les trois dernières années de grands Prix.

J'ai mis une durée arbitraire de deux jours, mais je ne sais pas vraiment combien de temps cela va vraiment durer. Elle est évidemment à effectuer une fois que tout est à peu près terminé.

## Planning effectif et différences

----

[A remplir dans les dernières semaines du travail de diplôme]

## Analyse fonctionnelle

----

[A remplir au fur et à mesure dans la seconde moitié du travail de diplôme]

## Analyse Organique

----

[A remplir au fur et à mesure que les features sont développées]

### OCR

Ici je vais parler du processus de reconnaissance de data sur une image du feed DATA de la F1TV.

C'est je pense la partie qui a demandé le plus tests et de refactor.

Toute la partie OCR a été développée dans un projet à part avant d'être intègrée dans le projet final.

Il faut savoir que la reconnaissance est différente celon ce que l'on cherche. Je vais donc décomposer cette partie du document en sous rubriques selon les données recherchées.

Mais avant ca je dois expliquer certains concepts qui seront importants.

#### Fonctionnement général

Voici un screenshot de la page DATA de la F1TV que le programme va recevoir :

!["Screen F1TV"](./Images/Screens/ScreenF1TvData.png)

Si on regarde de loin on peut se dire que la structure est plutôt simple mais c'est loin d'être le cas.
On peut y voir au moins 4 zones contenant de l'information dans un format différent.

!["Main zones"](./Images/Figma/WindowZoneExplanation1.png)

Dans l'exemple ci dessus on peut voir 3 zones mais on aurait également pu comprendre la zone de position des pilotes autour du circuit pour faire 4.

Ces 4 zones sont très différentes et contiennent d'autres informations. Pour ce travail de diplôme je ne m'occupe que de la zone principale. Mais je pense que le titre et les infos de circuit ne prendrait pas tant de temps que ca à implémenter.

J'ai utilisé le mot "Zone" plus haut et ca n'est pas juste un mot en l'air. C'est le nom de l'objet que j'utilise pour les représenter dans mon programme. Mais comme c'est important de bien comprendre ce concept avant de continuer je vais vous l'expliquer.

ZONE :

L'objet "Zone" parent est un objet qui est une zone d'image. Je m'explique, le but d'une zone est d'être un morceau d'une image plus grande.

Le but d'une Zone est de contenir une liste de plus petites Zones ou bien une liste de "Window" (j'explique ce que c'est juste après). Elle contient la portion d'image qui la concerne et ses propres dimensions.

Le parent zone ne prévoit que de pouvoir ajouter ou supprimer des éléments des listes de zones ou de windows ainsi qu'une methode qui permet d'aller chercher toutes informations des livres qu'elle contient.

L'intérêt d'une zone est de pouvoir compartimenter une image dans des parties intéressantes au niveau de la reconnaissance mais pas de traiter d'information.

WINDOW :

L'objet "Window" est un objet qui peut ressembler beaucoup à l'objet "Zone". En effet elle aussi est une partie d'une image plus grande et contient ses dimensions, mais elle se distingue en deux points importants.

- Elle ne contient pas d'autres Zones ou Windows
- Elle peut retourner les informations écrites sur son image.

Toutes les Window qui héritent du parent Window peuvent implémenter une methode qui permet de renvoyer ce qui peut être décodé sur son image. Les enfants peuvent aussi aller piocher dans les nombresues methodes de récupèration de données contenues dans le parent Window. Mieux vaut réutiliser le plus possible que de réinventer la roue pour chaque Window.

Une analogie un peu bancale pourrait se présenter comme la suivante :

La zone est une armoire ou une bibliotèque. Si c'est une zone qui contient d'autres zones c'est une bibliotèque et chacune de ces sous-zones sont des armoires. Leur unique but est de contenir de manière ordonnée des objets qui eux contiennent de l'information.

Les livres ici sont les Windows. Ils contiennet de l'information et sont stockés dans des armoires et on y accède en allant dans la bonne bibliotèque et en allant dans la bonne armoire.

Dernières choses pour comprendre le diagramme:

- Il existe une Main Zone qui est une des 4 grandes zones dont je parlais dans la décomposition de l'image.
- Il existe aussi des "Driver Zone" qui sont de plus petites zones contenues dans la Main Zone qui et qui ne contiennent que les informations d'un pilote.
- L'objet Window n'est quasi jamais utilisé, c'est presque tout le temps des enfants de Window plus spécifiques qui sont utilisés, le but est que chaque type d'information sur l'image aie son type de window.

Voila donc un petit diagramme qui montre le découpage du programme :

!["Diagramme zones"](./Images/Figma/WindowZoneExplanationDiagram.png)

Pour visualiser encore un peu mieux comment ce découpage prend forme voici ce que chaque zone et Window contient.

Main Zone :

Driver Zone :

Driver Position Window :

Driver Name Name Window :

Driver LapTime Window :

Driver Tyre Window :

### Récupération des images

### Lecture des images

### Interprétation des données

### Stockage des données

### Affichage des données

### Prédictions

## Tests

----

[A remplir au fur et à mesure de la création des tests]

## Résumé des difficultés techniques

----

[A remplir au fur et à mesure dans la seconde moitié du travail de diplôme]

## Améliorations futures

----

[A remplir dans les dernières semaines du travail de diplôme]

## Conclusion

----

[A remplir la dernière semaine du travail de diplôme]
