C'est vrai qu'on est loin de la boîte de Nesquick d'il y a 2 ans 

Joli boulot! C'est vrai que ca a bien progressé . Je trouve quand meme que la construction en boites de Nesquik avait un certain charme .

Personnelement je bosse toujours en perspective et j'utilise les vues orthographiques pour déplacer mes pièces . Pour tous ce qui est pièces esthétiques les vues isométriques ca donne des proportions bizares .

Le project est toujours en cours, malheureusement je n'ai pas beaucoup de temps à y consacrer ducoup il avance très lentement .

J'ai entrainé un agent à conduire conduire une voiture virtuelle et lui faire passer des portes dans le bon sens . Un petit bras robotique réplique les mouvements de l'agent sur la télécommande . J'aurai surment pu me passer su bras robotique mais j'aivais envie d'éssayer de conserver la vrai voiture téléguider le moins modifié possible .


J'ai presque résolu mon problème de tracking de la vrai voiture en utilisant un system de realité virtuelle (HTC Vive) . C'est fou de voir à qu'elle vitesse on peut régler ce genre de soucis juste en dépensant de l'argent . 

La prochaine étape est de donner la position de la vrai voiture à l'agent et qu'il utilise la télécommande pour la contrôler .

Tes roues de directions sont toujours parallèles?

 

Par curiosité : Pourquoi choisir un système propulsion + direction ? Et pas un système avec deux moteurs de propulsion droite gauche ? 

Ouai les roues sont toujours parrallèles(c'est pour ca que j'ai mentionné Ackermann), je sais que c'est pas idéal niveau performance vu que je vais avoir du glissement sur les roues avant pendant les virages . Je compte essayé d'entrainer l'IA en virtuel avant de lui mettre la vrai voiture entre les mains donc je suis parti sur le design que je pense etre le plus simple à simuler . Meme raisonnement pour les roues arrières, si les deux roues sont liées je n'aurai pas à me soucier au fait qu'elles ne tourne pas à la meme vitesse . 

Maintenant que tu le dis une future version avec un moteur dans chaque roue, ca pourrait etre plutot marrant!   
 

Je ne sais pas si un véhicule qui drift et suivre un parcours dont le robot aurai en mémoire la position des obstacles est compatible.

Il serai peut être plus judicieux de partir sur un lidar qui permet de connaitre les obstacles en temps réel et cela ne t'obligerai pas à avoir d’odométrie (meme si ça serai bien plus performant avec).

Une autre solution : un codeur sur le moteur, et pouvoir stocker ces donnés + position du servo, tu fait un tour en pilotant à la main, ca enregistre le trajet et ensuite ça le refait en auto.

Le fait d'enregistrer et de relire les positions de servo et de moteur ne me parait pas etre une solution très robuste, si les roues patinent ou que la voiture est poussée par un autre véhicule la trajectoire préenregistré sera decalée . De plus pour pouvoir enchainer les tours il faut réussir à enregistrer un tour qui commence et se termine au meme endroit, ca me parait difficile .
C'est pour ca que l'odométrie me parait vitale . En théorie si la position des obstacles est connue, il est possible de calculer le tracé du circuit (avec des courbes de Bézier ou autre), si la voiture connait sa position et sa direction il devrait donc etre possible de faire en sorte qu'elle suive le circuit . C'est comme ca que j'ai imaginé le problème, ca serai pas la première fois que je me plante   .
Enregistrer le tracé du circuit en fesant un tour conduit à la main me parait une bonne solution .

Etant donné que les obstacle sont souvent des tracés au sol ou des objets pas forcement très hauts, Je ne sais pas si un Lidar aidera beaucoup à la détection des obstacles mais il serait certainement bien plus fiable pour déterminer la position de la voiture dans l'espace que le gyrospope+accéléromètre que je compte utiliser .
Malheureusement je n'en ai pas sous la main pour le moment (j'éssaye de faire avec ce que j'ai chez moi pour le moment .)

 

Merci pour les conseils Ludovic!  

Le probleme de l'IMU qui dérive c'est ma plus grosse inconnu pour le moment . J'ai un capteur BNOo55 qui en théorie est censé donner une position absolu . Je ne l'ai pas encore essayé donc je ne sais pas combien de temps il peut tourner avant de donner des résultats to erronnés .

Je pense que si je fini par choisir d'ajouter un lidar ca serai plus dans l'idée de corriger la dérive de l'IMU plus que pour détecter les obstacles . Le fait de faire ca en intérieur il devrait etre possible d'utilisé les murs de la pièce comme de points de repères .





 

Genial! J'ai hate de voir comment tu vas gérer toute la partie pilotage autonome . 

Malheureusement de mon coter j'ai eu beaucoup de travail et peu de temps pour mes projets ces derniers mois . Apres avoir experimenté avec deux IMU differentes (comme le dis Loduvic plus haut) sans un deuxieme type de capteur je n'ai aucun moyen de compenser la derive des IMU .

Je suis en train d'experimenter une technique utilisant la bibliotheque servant aux applications de realité augmenté (AR foundation) . La camera est pointé vers le plafond, l'idée étant suivre les deplacement du plafond pour determiner la position de la voiture sur le sol .

Les questions de Mike posent bien les problèmes.

 

Si ton objectif n'est pas de faire une voiture, mais un mobile de reconnaissance de l'environnement, j'aurais opté pour un 4 roues bloqués fonctionnant comme un char, voir carrément un petit char.

Là, tu vas tu vas être obligé de gérer le déplacement d'une voiture qui n'est pas un mobile symétrique.

Mon but dans ce cas est de faire une voiture qui doit évoluer sur une surface plate et lisse mais sur des circuits différents et de manière autonome . Pas de reconnaissance ici, une fois que le circuit est défini ya plus qu'à faire le tour le plus vite possible! 

Avant d'etre confiné, avec quelques-uns de mes collegues de travail on profitait d'une zone vide du bureau pour joué avec des voitures téléguidées (desfois on travaillait aussi  ) . En général on posait quelques obstacles ou bouts de scotch au sol pour créer un circuit . Les voitures étaient équipé pneus en plastique dur pour pouvoir drifter les virages .

Le but de ce projet est donc de créer une voiture télécommandée autonome . L'idée est de pouvoir enregistrer la position des obstacles mis au sol et faire en sorte que la voiture face le tour du circuit d'elle meme (Le plus vite possible) .  Je pense utilisé une IMU pour pouvoir calculer la position, direction et vitesse de la voiture par rapport au circuit .

Comme je n'avais pas envie de mutiler la voiture que j'ai déjà, j'ai décidé d'en concevoir une que je peux imprimer . J'ai privilégié la simplicité car je vais surment utilisé de l'apprentissage par renforcement sur Unity pour apprendre à une IA à conduire, il me faut donc quelque chose qui soit le plus "facile" possible a simuler .
Je suis donc parti sur une propulsion sans différenciel, sans suspension et avec aucune géométrie (carrossage, pincement, Ackermann....) . La géométrie de la crémaillaire (meme si il y en a pas ici) est faite de manière à ce que l'angle des roues avants soit égal à l'angle du servo de direction  .
Au niveau des proportions (empattement, voie, diamètre des roues...), j'ai prix les dimensions d'une Nissan silvia S15 et est tout mis à l'échelle 1/10 .

Pour ce qui est des differents composants, j'ai décidé d'utiliser ce qui trainait dans mes tiroirs . La seul chose que j'ai acheté est une courroie pour la transmission . Je ne sais pas trop si le moteur sera assez puissant pour ce que je veux faire .



Les premières pièces ont été assemblées et montées . Jusque la, tout va bien !

Je ne sais pas trop si un robot de ce type est considéré bipède, mais si j'avais à developper quelque chose avec 2 jambes je commencerais par ce genre de systèmes hybride entre les "vrais" bipèdes et un pendule inversé . Les "self balancing robots" sont dejà très bien documentés et accessibles aux amateurs .
 

cool! J'ai hate de voir comment ce projet va se developper . J'imagine qu'avec des scripts assez modulaires il y aura moyen de rajouter et enlever des jambes assez facilement .

Fair play pour t'attaquer aux equations de cinématique inversée . Personnelement, si j'avais a developper un projet comme ca sur unity je pense que j'essarai de voir si un squellette rigger dans un logiciel du type 3dsmax/maya ou blender peut etre importé tel quel dans Unity et directement utilisé pour calculer la position des articulations automatiquement . En meme temps je suis une feignasse! 

Tu prévois d'avoir qu'elle genre de capteurs dans le corp? J'imagine qu'un gyroscope et un accéléromètre est le minimum vital pour avoir un truc un minimum réactif au condition de l'environment .

Oui je suis bien conscient que j'aurai pu régler le problème de manière beaucoup plus simple avec openCV mais ce projet est plus un exercice pour apprendre à utiliser tensorflow et en apprendre plus sur les réseaux de neuronnes en général .

Vaut vidéos mon aidé quelques fois d'ailleur . Continuez ce super boulot!

Voila la donnée qui me manquait pour apprendre c'est en effet un très bon exercice ! je suis content que mes vidéos aident ! si vous voulez un avis sur le modèle, le code ou l'algo, n’hésitez pas c'est un très beau projet !

Merci pour l'offre! Je ferais signe si je me retrouve coincé ou que j'ai quelque chose sur lequel j'ai besoin d'un avis . Pour le moment je me base sur les exemples du site de tensorflow et je joue un peu avec l'architectures et les paramères du modèle . J'ai pas mal de rattrapage à faire niveau math et je préfère me documenter un peu de mon coté avant demander surtout qu'il me faut pas mal de temps pour assimiler certains concepts .
 

Yep je pense que changer le dataset peut-être une bonne idée. Tu pourrais commencer par prendre des photos à partir de différents angles, différents luminosités, différentes distances pour te constituer la base de ton dataset. Et puis tu peux modifier ces photos numériquement par après pour compliquer la tâche à ton réseau.

Je pense que je vais ecrire un petit script qui va prendre des photos de l'écran automatiquement . en le laissant tourner une journée entière je devrais avoir une bonne collection d'images avec differentes luminosités . Il y a une fonction dans tensorflow qui permet "d'augmenter" le data . Elle permet de zoomer, translater et changer la perspective des images aléatoirement . J'espère que ca fonctionnera mieux avec cette technique !!!

Les progrès ont été plus lents que prévu ce weekend .

La première chose à faire était de trouver une nouvelle solution pour collecter des images du jeu . Je me suis dit qu'il serait une bonne idée de prendre les images directement à partir de la Pi camera du robot . 
Le challenge était de faire communiquer le robot (jetson nano) et le jeu qui tourne sur un PC . J'ai decidé d'utiliser le jetson nano comme server et le jeu comme client . Le robot envoi un signal au jeu pour afficher l'image désirée avant de la capturer .

Je pensais que le contrôle du bras consisterai simplement à brancher les servos sur les GPIOs du jetson Nano et à les controller directement . Je n'avais juste pas prévu qu'il n'est pas possible d'utiliser le 'PWM' sur les GPIO du jetson . J'ai donc choisi de resortir le arduino nano du projet précédent pour controller les servos .



Maintenant il ne reste plus qu'à collecter des images, entrainer l'IA et ensuite écrire un petit script pour connecter les décisions de l'IA au servos (enfin ca c'est le plan  ) .

J'ai recyclé mon projet utilisant une manette de Xbox pour jouer . Je me suis amusé à faire s'affronter deux IA sur un jeu de air hockey . 
Cette fois ci j'ai réussi à passer directement de l'entrainement completement virtuel au control physique sans avoir à réentrainer les réseaux neuronaux .
 

J'ai commencé à m'attaquer à la partie logiciel et surtout à la vision du robot qui ne se passe pas tout à fait comme prevu . J'ai donc commencer par créer un jeu tout simple dont le but est de bouger le portal(le truc rond) au dessus du gateau .

Une fois le jeux fini, j'ai commencé à m'interesser à comment le robot allait voir le jeux . J'ai un peu hésité à utiliser un méthode de traitement d'image 'classique' (détection de couleur et autre) . Et comme le but de ce projet est quand meme d'apprendre de nouvelle chose je me suis dis qu'il serai sympa de créer et entrainer un réseau neuronal convolutif à l'aide de tensorflow .

Le but de ce réseau neuronal convolutif est de prendre une image en entrée et de donner une position de joystick en sortie . Il y a 9 positions de joystick, centre, gauche, haut+gauche, haut, haut+droite...etc
Pour entraîner un réseau de neurones il faut du data et si possible beaucoup . Ici le data consiste en des images du jeu avec le label associé a chaque image est la position du joystick . Collecter toutes ces images prend du temps, j'ai décidé de créer du data synthetique , c'est à dire qu'au lieu de prendre des photos du jeux en train de tourner sur ma télé, j'ai créer des images completements digitales du jeu .



Ici on peu voir que j'ai donc créé un écran noir qui simule l'écran de la télé avec les éléments du jeu dessus . La position de la télé est assez aléatoire de manière à ce que le robot puisse apprendre à jouer sans être parfaitement aligné avec l'écran . Le fond est aussi remplacé par un bruit aléatoire, l'idée derrière cela est que le robot apprendrai à ignorer ce qui se passe en dehors de l'écran .

Avec cette méthode, j'ai pu en quelques heures créer un demi millions d'images labelées . J'ai ensuite créé mon réseau neuronal à l'aide de Tensorflow . J'ai même passé quelques heures a créer un script pour importer les images et labels pour l'entrainement du réseau pour finalement me rendre compte que Tensorflow avait un fonction qui permet de le faire de manière plus efficace en 2 lignes de code!!!

Apres avoir bidouiller un moment avec les paramètres et entraîné le réseau neuronal, il était capable de prédire correctement la bonne position du joystick pour une image donnée a 90% sur le data synthétique.

Malheureusement sur les photos réelles les performances sont très mauvaises .

Je pense que cela vient du fait que mon data synthétique est bien trop simpliste (pas de réflexion sur l'écran et fond trop uniforme) .
Je pense que le travail effectué sur le réseau neuronal peut être gardé mais il faut que les data collectées soient de meilleure qualité .
 

Mon traffic vient surtout des sites exterieurs comme hackster.io .

J'avais jamais entendu parler de cette règle! Par contre ca ne m'etonne pas plus que ca, je travail dans le milieu du design et il a des choses qui déplaise au yeux/cerveau et il faut juste faire avec .

Comme tu le dis, je pense que le terme AI doit etre inclus dans le titre et que le mot game/gaming est assez vendeur . Je vais essayer de trouver un truc qui mixe un peu tt ca .

Peut etre que les gens qui se sont abonnés au moment ou tu fesais des chars se sont abonnés que pour ca, Je sais que sur Instagram j'ai des vagues de followers qui viennent et qui partent . J'avais eu beaucoup de gens qui m'avaient follower au moment ou j'ai fait la tourelle et quand j'ai commencé a faire autre chose certains sont partis et d'autres sont arrivés . Le plus important c'est de se faire plaisir ! 

Comme tu le dis c'est purement un exercice mais je trouve ca aussi assez interessant de voir que les techniques plus modernes ne sont pas forcement la solution a tout les problemes .

Le nombre d'abonnés monte tout doucement mais j'ai encore du chemin à parcourir pour te rattraper !

Merci pour les conseils !

Je voulais éviter l'approche du traitement "classique" vu que j'avais déjà un expérimenter avec ca dans des projet précédents et que je voulais apprendre quelque chose de nouveau .

Je vais éssayer de voir comment je peux faire pour faire de la régression en partant d'une image . 

Après avoir collecté quelques milliers de nouvelles images de bonne qualité et une autre session d'apprentissage les résultats s'améliorent mais il y a encore des moments ou il reste coincé dans des boucles .
 

Je vais commencer par poster la vidéo final du projet avant de commencer a blablater . Elle est en anglais mais sur la deuxième moitié de la vidéo on voit le processus d'apprentissage de l'IA ce qui ne nécéssite pas forcement de comprendre quoi que ce soit à la voie off :

Depuis un petit moment je me balade entre plusieur hobbys vagement en relation les uns avec les autres, l'apprentissage machine, le devellopement de jeux et la mécatronique .

J'ai donc eu l'idée de créer un jeu qui apprendrai à se jouer lui-même a l'aide d'une manette de Xbox . je me suis dis que ca pourrait etre un projet sympa qui combinerait trois choses que j'aime .

Avant d'aller plus loin . Oui, je sais que dans ce projet j'utilise un methode completement inappropriée pour le problème que j'éssaye de résoudre ! Un bon vieux controller PID aurai fait largement l'affaire et aurai surment meme été meilleur . J'ai decidé d'utiliser un réseau de neurones parce que je voulais voir comment il allait s'adapter à tout les défauts liés à un controlleur physique (jeux entre les pièces, inertie des pièces, calibration imparfaite...)

LE PLAN INITIAL :
 

Je voulais que ce projet soit assez rapide sans avoir à faire face a de grosses inconnues, j'ai donc décidé de réutiliser des compétences que j'avais déjà développées au cour de projets précédents . Je pensais que j'aurai fini en deux jours...lol

Pour le jeux et l'apprentissage machine, ca serait donc fait sur Unity avec le 'ML-agents toolkit' aussi développé par Unity . J'étais déjà familier avec ces deux éléments meme si j'ai été assez surpris de voir à quel point ils avaient évolué depuis la dernière fois que je les avais utilisé .

Le choix du jeu s'est fait très tot, il fallait quelque chose qui puisse se controller avec un minimum de button pour garder la partie physique du projet assez simple .

Le 'ML-agents toolkit'  contient quelques examples dont un qui pouvait facilement etre utilisé comme un jeu ne nécéssitant qu'un seul joystick, l'exercice du 'ball balancing' .

LE ROBOT.
 

J'ai commencé par créer un simple bras qui bouge le joystick droit de la manette . J'avais quelques servos MG-90 et un arduino nano qui trainaient dans un tiroir, c'est donc ce que j'ai utilisé .

La seule chose à laquelle j'ai du faire attention était de bien aligner le point de pivot du joystick avec l'axe des servos histoire de rendre la tache plus simple au niveau de la programmation du arduino .

L'étape suivante était d'écrire un programme pour le arduino qui permetterait de controller le joystick .
Une scène basique fut aussi créée pour permettre la calibration des mouvements .

Maintenant, il était temps de faire en sorte que le réseau de neurones puisse prendre le controle de la manette . La scene unity fut modifiée pour permettre au joystick droit d'etre controllé par celui de gauche .
Le joystick gauche est utilisé pour simuler les données de sorti du réseau de neurones, ceci permet de vérifier que la communication entre le PC et le arduino fonctionne correctement .

LE JEU .

Comme mentionné plus tot, j'ai donc recréé le jeu d'équilibrage de balle tout en y ajoutant un peu de difficulté . La première étant que la balle doit etre positionnée le plus près d'une cible se trouvant sur la platform . Le seconde étant que la balles est lancée d'une position et à une vitesse aléatoire en début de partie .

J'ai aussi éssayé de créer quelques magnifiques textures (je dis bien éssayer!)

L'APPRENTISSAGE .

Il était donc temps de commencer l'apprentissage .
Je vais pas rentrer en détail dans l'apprentissage par renforcement parce que c'est un sujet vaste et compliqué mais ici je vais expliquer très brièvement  ce qu'il va se passer durant cette étape .

1 - On va prendre notre IA, appelé agent . Il va observer l'état du jeu . Ici il va collecté la vitesse et position de la ball, la position de la cible et l'inclinaison de la platform .

2 - A partir de cette observation il va accomplir une action . Bouger le joystick .

3 - Suivant le résultat de cette action il va recevoir une punition (score negatif) si la balle est tombée, ou une récompense (score positif) si la balle est toujours sur la platform, plus la balle est proche de la cible plus la récompense est grande .

Le cycle va se répéter jusqu'à ce que l'IA apprend a prendre les décisions lui perméttant de gagner un score maximum .

Arrivé à ce point du projet je pensais que je n'aurai qu'à lancer l'entrainement et que par miracle j'obtienerai un robot en parfait état de marche quelques heures plus tard...J'avais tort .

Après la première session d'entrainement, l'IA avait en effet appris à jouer mais elle était très nerveuse .

J'ai donc relancé une nouvelle session, cette fois ci avec une récompense suplémentaire pour la souplesse .

Le résultat était un peu meilleur mais loin d'etre extraordinaire .

Un des gros facteur limitant en incluant la manette durant l'entrainement est que je ne pouvais entrainer qu'un seul agent à la fois et à vitesse réel .

J'ai donc opté pour une nouvelle stratégie, diviser l'apprentissage en deux . La première partie se fairait en excluant la manette, ceci me permettrai d'entrainer plusieurs agents a la fois et en accéléré . En deuxième partie je réintroduirai la manette à l'entrainement pour laisser le temps à l'IA 'd'apprendre' la manette .
Cette technique me permettrai de tester differents systemes de punitions/récompenses et aussi de tester différents paramètres liés au réseau de neurones lui meme comme le nombre de couches, nombre de neurones...etc . Ceci me permettrait d'économiser plusieurs heures .

La partie de l'entrainement completement virtuelle s'est très bien passé et m'a permit de trouver de bon paramètres . Maheureusement au moment de réintroduire la manette, il était clair que quelque chose ne fonctionnait pas correctement, la balle était constament jetée hors de la platform, la bonne nouvelle était que cela était fait de manière très souple sans aucune nervosité .
Je pense que l'érreur vient de mon code et pas de l'IA elle-meme mais je n'ai pas été capable de la trouver malgré le fait que je suis quasiment sure que c'est quelque chose d'extrement simple . A ce moment la, je savais que j'avais de bon parametres donc je pris la decision de recommencer l'entrainement avec la manette depuis le debut .

Après une dizaine d'heures d'entrainement, j'avais enfin un résultat avec lequel j'était satisfait!!!
 

Après avoir suivi les conseil de Laurent42, les prédictions du réseaux neuronal se sont améliorées . 
Je me suis amusé à essayer de la perturber pendant le jeu mais elle arrive toujours à jouer .

est il possible d'avoir les plan de la "pince" qui manipule le joystick pour pouvoir l'imprimer ?

Je pensais pas partager le projet au début parce que le code est vraiment degueux mais j'ai eu tellement de demande que j'ai fini par me motiver à mettre mon site à jour! pieces dispo ici : https://www.littlefr...-controller-arm

Merci, ca a vraiment aidé! Au final je suis resté assez fidèle à votre suggestion :

conv2d(None, ..., ..., 16) kernel=3 stride=2

conv2d(None, ..., ..., 16) kernel=3 stride=2

conv2d(None, ..., ..., 32) kernel=3 stride=2

Dense(128)

Dense(32)

Dense(10)

Le modèle est assez sensilble aux variations d'éclairage, j'imagine que cela vient du fait que l'éclairage de mes images d'apprentissage est relativement similaire .

Le fait de ne pas avoir d'action graduelle sur le joystick rend le jeu difficile à jouer pour le robot quand la vitesse du cercle est élevée . J'en ai conclu que la classification d'image pour ce genre de problème n'est pas idéale .

Vraiment sympa ton projet ! Prochaine étape, réaliser le plateau en vrai ?

 
J'y pense, Il faut que je trouve un moyen de recupérer les donnés nécéssaires au réseau de neurones avec une camera . Et aussi espérer que la physique de Unity sois assez fidèle à la réalité .

joli projet ! une prochaine étape sympa serait de faire tout ça avec du traitement de l'image, avec une caméra qui filme l'écran !

J'y pense aussi . Un jeu type pong ou un casse brique il pourrait etre un bon candidat . Un truc en 2D avec pas mal de contrast pour un debut pourrait etre pas mal en tout cas .

Mais, tu m'as rattrapé et même dépassé ! Ta vidéo va faire environ 600 vues les premieres 24h, alors que mes vidéos ne font au mieux que 300 vues.

De plus, ces derniers temps, le nombre de vues s'est écroulé sur YouTube. Il semblerait que ce soit dû au confinement.

Non, à mon avis, tu vas cartonner.

Par contre, va falloir que tu refasses tes pièces et que tu mettes à jour ton blog. Un fan club, ça se ménage . . .

Dans ton titre, il n'y a pas le terme "IA". A mon avis, un titre du style, "Virtual robot Ball balancing, with IA learning", ce serait beaucoup mieux.

Sur la photo de couverture, il faudrait que tu agrandisses le plan avec la balle dessus. C'est certain, l'idée du joystick, c'est génial, mais je ne suis pas sûr que l'on perçoive bien l'idée en raison d'un plateau nettement plus petit que la radiocommande. A mon avis, le plateau à gauche et la radiocommande à droite. Si tu peins un paysage avec un arbre, l'arbre doit être situé à gauche, pas à droite. C'est comme ça ! Et c'est pas négociable.

Encore, bravo !

C'est marrant, j'aurai parié que ca aurait l'inverse . Il y a pas mal de gens avec du temps à perdre .

J'ai fait un miniature avec la manette de l'autre coté avant celle que j'ai utilisé mais ca me parraissait bizare . Jvais tester pour voir si ca marche mieux . 
Jvais réfléchir à un titre a base d'IA . C'est vrai que ca parait evident maintenant que tu le dis !

Je me suis rendu compte que le data que j'ai collecté est vraiment pas top donc il faudra que je  recommence cette partie mais j'ai quand meme décidé de tester le tout avec un réseau neuronal assez mal entrainé (75% de précision) pour m'assurer que sur le principe ca fonctionne .
Je suis vraiment impressionné par les performances du jetson Nano, il tourne nikel a 25FPS . Bon par contre comme espéré le réseau neuronal lui ne fonctionne pas tres bien donc le robot se retrouve coincé dans des boucles .

ici le but du jeu c'est de mettre le cercle sur le carré blanc et de le tenir dans cette position pendant une demi seconde .