IMA5 2018/2019 P44

Présentation du projet

Ce wiki est mis à jour régulièrement par le binôme Erwan Dufresne et Eloi Zalczer, lors des différentes évolutions du projet

Dans un premier temps, il nous semble nécessaire de préciser que nous étions chacun en semestre à l'étranger. Ainsi nous pouvions chacun choisir des cours "à la carte" et façonner une formation un peu différente que celle proposer à polytech Lille. Ce pourquoi nous avons tous deux choisi des cours ayant un rapport de près ou de loin avec l'intelligence artificielle. Forts de ces différentes expériences plus ou moins approfonfies dans ce domaine, nous jugions judicieux de les mettre en pratique lors du PFE de 5ème année. Suite à différentes propositions jugées non adéquates par les professeurs, monsieur Vantroys nous a finalement proposé un projet, original, qui nous permettrait de mettre à bien les nouvelles connaissances aquises dans le domaine de l'IA lors du semestre d'échange,

Le projet consiste à réaliser une voiture autonome miniature capable de s'orienter via de l'intelligence artificielle. Cette voiture ainsi réalisée devrait pouvoir être conforme aux différentes normes lui permettant de participer à la compétition IRONCAR. Cette compétiton regroupe les véhicules minaturisés de différentes équipes et permet de les confronter entre eux.

Description

rappel sur la compet

Objectifs

truc fctionnel , compet organisé, comprend ruc sur ia et manipuler faire un tableau des objectifs chaque semaine

Analyse du projet

analyse des concurents

analyse des premiers concurents

Bien sûr les premiers concurants directs seront les autres participants à la course de l'ironcar. Ces différents concurents peuvent chacun déployer le dispositif qu'ils souhaitent, selon leur moyen et leur envie. Sous réserve que le prototype final soit respecte les conditions reqises pour participer à la compétiton, bien évidemment.

photo des differentes voiture de la compet

analyse des seconds concurents

D'autres parts, il y aussi d'autre type de concurents , notamment des grandes entreprises comme google, uber ou tesla qui conceptualisent et déploient des voitures autonomes depuis plusieurs années.

parler des concurents de la compet mais aussi des concurents type google etc avec es voitures autonomes

parler du projet de organiser la compet à lille par TV

Préparation

Cahier des charges

fixer obj

Choix matériels et technologiques

expliquer le matos, et celui impossé/interdit par la compet

Réalisation du projet

Avancement préalable

expliqué ce qu'on a fait avant de retourner à popo

planning du taff comme en 4A avec le temps passé sur les différentes etapes

Semaine 1 (7-11 janvier)

Cette première semaine nous a permis d'établir les bases qui nous permettront de nous attaquer au vif du projet. Nous avons commencé par installer Raspbian sur la Raspberry Pi 3B+, et par installer les librairies et paquets nécessaires. Pour Python, nous avons utilisé le gestionnaire de paquets Conda. Il nous permet d'installer et de gérer facilement les versions des librairies scientifiques que nous utiliserons (numpy, scipy, scikit-learn...). Ce gestionnaire de paquets est compatible avec l'architecture ARMv7 de la Raspberry Pi. L'installation de ces packages n'a donc pas posé de problèmes. Le plus difficile à été de mettre en place Pytorch, la librairie de machine learning sur laquelle sera basé notre projet. Cette librairie n'est en effet pas compilée pour Raspberry Pi par défaut, nous avons donc du le faire nous-mêmes. Après avoir récupéré le code depuis le dépôt GitHub du projet, nous avons du initialiser les bonnes variables d'environnement pour paramétrer la compilation. La compilation sur Raspberry Pi implique de se passer de certains fonctionnalités comme CUDA. Nous avons utilisé ce guide pour nous aider. Il a également été nécessaire d'augmenter la taille de la partition de swap pour que la compilation puisse se finir. La compilation a pris plusieurs heures, et nous l'avons étalée sur une nuit. Cette étape a été la plus difficile du setup. Certaines autres librairies, comme engineio pour les websockets, ont demandé des démarches d'installation un peu différentes car les versions disponibles sur anaconda n'étaient pas les bonnes. Nous avons donc du construire l'arbre des dépendances séparément.

Le deuxième jour, nous avons commencé à établir l'architecture du projet et à développer. Le plus urgent était d'établir un système de contrôle de la voiture qui nous permettra de capturer d'entraîner le réseau. Nous avons donc développé une petite application web et un serveur websockets en Node.js afin de faire communiquer la Raspberry Pi avec une interface de contrôle en HTML. Nous avons d'abord envisagé d'utiliser la Raspberry Pi comme serveur, mais par souci de légèreté nous avons choisi d'héberger le serveur sur un PC portable. La voiture et l'application client se connectent tous les deux en tant que clients sur le serveur, qui se charge de rediriger les messages reçus depuis l'appli web. Dans un premier temps, nous avons supposé que les angles de rotation de la voiture ne seraient pas supérieurs à 30°. Nous avons également normalisé la vitesse entre 0 et 30 sur le système de contrôle. La première version de ce dernier était très simple et consistait en un cercle sur un canvas qui suit les déplacements de la souris. Si le cercle est lâché, il retourne à sa position d'origine et arrête donc la voiture. L'interface ressemblait alors à l'image à droite.

Interface web

L'application a fonctionné sans problème majeur, cependant il nous a fallu un certain temps pour déterminer la façon optimale d'utiliser la librairie python-socketio. La réception des commandes est en event-based, ce qui n'est pas habituel en Python et nous a demandé quelques recherches. Nous avions commencé par mettre la réception des commandes dans un thread séparé, puis nous nous sommes aperçus que ce n'était pas nécessaire. Le jeudi, nous avons essayé pour la première fois la voiture. Après quelques courses dans les couloirs et le hall, nous avons démonté une partie du capot pour observer les branchements à l'intérieur. La documentation est pratiquement introuvable sur internet, donc cela nous a permis de nous faire une idée du fonctionnement du système et du protocole à utiliser. Suite à une discussion avec le tuteur de projet, nous avons décidé d'utiliser une Arduino pour générer les PWM car elle sera plus stable que sur un Raspberry Pi.

Une autre partie du travail a été de préparer la partie Machine Learning qui se fera dans quelques semaines. Nous avons modifié le code principal du projet pour enregistrer les images capturées par la caméra et les commandes correspondantes pendant la course. Pour cela, nous avons également ajouté un bouton Lancer/Arrêter l'enregistrement sur l'application Web. L'enregistrement pourra ainsi être contrôlé et arrêté si la voiture sort des traces. Lorsque la voiture est arrêtée définitivement, les données sont enregistrées dans un fichier horodaté au format hdf5 qui est optimisé pour le stockage de datasets. Les images et les commandes sont enregistrées sous forme de tableaux numpy qui sont facilement lisibles et re-convertibles en images. Nous avons écrit un petit code pour vérifier que les images n'étaient pas corrompues et que les commandes étaient correctement enregistrées, ce qui nous a permis de détecter un bug.

En effectuant ce travail, nous avons pris certains risques concernant l’entraînement futur du réseau. Nous avons en effet décidé de travailler avec des valeurs de vitesse et de direction continues, alors que tous les projets trouvables en ligne utilisent un set de valeurs discrètes. Notre approche peut nous permettre d'obtenir une voiture plus précise, mais demandera également plus de données pour l'entraîner efficacement. De plus, la qualité des données dépendra de la qualité de notre pilotage. Il est possible que cette décision doive être modifiée à l'avenir si les performances obtenues ne sont pas satisfaisantes.

Semaine 2 (14-18 janvier)

L'objectif principal de cette semaine était de réussir à faire rouler et contrôler la voiture via notre propre système. Nous avons donc essayé de connecter une Arduino et de faire fonctionner la voiture avec une PWM que nous générons, mais sans succès. Nous avons donc décidé d'observer la sortie du récepteur à l'oscilloscope pour déterminer la différence. Nos observations ne correspondaient pas du tout à nos attentes, car la sortie du récepteur de la voiture ne ressemblait pas à une PWM. En attendant de pouvoir discuter avec le tuteur du projet, nous avons fait une nouvelle version de l'application sur une autre branche dans laquelle les commandes sont des valeurs discrètes. Nous avons ainsi deux versions fonctionnelles, ce qui nous permettra de choisir l'architecture de réseau donnant les meilleurs résultats. Nous avons décidé d'utiliser 5 valeurs de direction et 2 valeurs de vitesse différentes, ce qui était également les choix faits par l'équipe gagnante de l'an dernier. Nous avons également modifié le script de vérification du fichier h5 pour l'adapter à ces modifications.

Le mercredi, nous avons enfin réglé les problèmes qui nous empêchaient de faire avancer la voiture. Le premier problème était la fréquence de la PWM, qui était beaucoup trop élevée sur l'Arduino (500Hz au lieu des 50~60Hz pour un servomoteur). Nous avons découvert ce problème après avoir contacté un technicien chez T2M et avoir discuté avec les tuteurs de projet. Pour corriger ce problème, nous avons simplement utilisé la librairie Servo de Arduino qui est conçue exprès pour notre cas. Après cette première correction, la voiture ne fonctionnait toujours pas et nous avons supposé que l'alimentation de l'Arduino n'était pas suffisante. Une mesure au voltmètre nous a permis de déterminer que l'alimentation était en 6.5V soit au-dessus et ce que peut fournir l'Arduino. Nous avons testé avec une alimentation 7.5V et avons pour la première fois réussi à faire bouger les servomoteurs. Enfin, nous avons établi un petit circuit pour réutiliser l'alimentation fournie par le récepteur et remplacer le signal par celui en sortie de l'Arduino. Le dernier dysfonctionnement était du aux masses qui n'étaient pas connectées, ce que nous avons corrigé rapidement. Une fois que les servomoteurs bougeaient, nous avons entrepris de calibrer les valeurs pour les contrôler. Comme nous l'attendions, les angles de rotation pour les servomoteurs sont compris entre -30° et 30°. La valeur moyenne étant 90, la plage de valeurs va de 60 à 120. Une fois cette première étape finie, nous avons répété la procédure pour le moteur brushless principal. Le système a rapidement fonctionné, et nous avons pu déterminer que le moteur commençait à tourner pour une valeur de 100. Nous avons supposé que la valeur maximale était 180 mais nous n'avons pas testé jusque là car la voiture était en position instable.

Une fois ces problèmes réglés, le reste a été assez rapide. Nous avons réalisé un code Arduino pour contrôler la voiture en fonction des instructions reçues sur le port série, et nous avons refait une partie de mécanique pour améliorer le chassis et la gestion des câbles. Le vendredi, nous avons pu faire rouler la voiture pour la première fois sans aucun lien extérieur. Cela nous a permis de faire les premiers tests de caméra et d'apprécier certaines caractéristiques, notamment le rayon de braquage qui est assez élevé. L'orientation de la caméra sera essentielle, d'autant plus que nous n'avons pas un modèle grand angle. Parmi les prochaines étapes, nous allons devoir trouver un système d'attache de la caméra (peut-être imprimé en 3D), construire une piste de test et éventuellement adapter le code de capture d'images. Une fois que nous aurons conduit la voiture suffisamment pour obtenir des données conséquentes, nous passerons à la partie Deep Learning du projet. Pour finir la semaine, nous avons construit un tronçon de piste à taille réelle pour apprécier la vision que la caméra aurait. Nous avons remarqué que la voiture ne voyait la piste qu'environ 1.50m devant elle, ce que nous avons jugé trop lointain. Nous avons donc décidé de commander une caméra grand angle pour remplacer le Camera Module V2. Nous avons également commandé une nouvelle nappe de connexion de 30 centimètres pour avoir plus de liberté au niveau du placement de la caméra.

Semaine 3 (21-25 janvier)

En attendant de recevoir la nouvelle caméra qui nous permettra de passer au Deep Learning, l'objectif de cette semaine sera de faire en sorte que tout soit prêt pour cette seconde étape. Nous devons donc finir la partie mécanique (support de la caméra, ajustements divers) et tenter d'optimiser la partie informatique pour s'assurer qu'elle fonctionne bien le moment venu. Nous allons utiliser un simulateur déjà existant ici pour générer des images d'entraînement avant de pouvoir créer les nôtres. Ces images nous permettront de tester et éventuellement d'adapter notre réseau de neurones. Le simulateur génère une série d'images au format jpg et les commandes associées sont encodées dans le nom du fichier (format frame_<nb_frame>_gas_<vitesse>_dir_<direction>.jpg). L'inconvénient de ce simulateur est que la seule vitesse possible est de 0.5, ce paramètre n'est donc pas pertinent. Les directions fournies sont globalement comprises entre -2 et 2, nous devons donc également normaliser ces valeurs pour matcher nos paramètres. Enfin, nous devons transformer le dossier d'images jpeg en un fichier h5 que nous utilisons dans notre cas.

notes

wiki néon bus, 4x4, piece cassé a réparé collé cable bleu corps de la voiture missile ? peau banane ? https://www.amazon.fr/Revoltec-RM128-N%C3%A9on-Twin-Set-Boitier/dp/B006W9U29M/ref=pd_sbs_147_1?_encoding=UTF8&pd_rd_i=B006W9U29M&pd_rd_r=812e66c3-1a48-11e9-a12a-4b13213faf1c&pd_rd_w=eTKZW&pd_rd_wg=th5nN&pf_rd_p=5d361e0c-9e85-4b01-8261-3ff932bec9c8&pf_rd_r=A6YME0CC1RQQCEC5ESZW&psc=1&refRID=A6YME0CC1RQQCEC5ESZW conception mecaniques et soudures a expliquer faire toute lintro et tt