IMA3/IMA4 2018/2020 P9 : Différence entre versions
(→Description) |
(→Récupérations de données) |
||
(264 révisions intermédiaires par 6 utilisateurs non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
+ | <include nopre noesc src="/home/pedago/pimasc/include/video-IronCarIMA32018-iframe.html" /> | ||
__TOC__ | __TOC__ | ||
<br style="clear: both;"/> | <br style="clear: both;"/> | ||
Ligne 5 : | Ligne 6 : | ||
==Description== | ==Description== | ||
− | Le projet consiste à réaliser une voiture autonome dans le but de participer au concours [http://www.ironcar.org/Ironcar] | + | Le projet consiste à réaliser une voiture autonome dans le but de participer au concours [http://www.ironcar.org/ Ironcar] dès 2019. |
+ | |||
+ | Ce dernier est une course de voitures (modèle réduit) intelligentes. | ||
+ | |||
+ | Afin d'y prendre part il nous faudra concevoir un véhicule pouvant suivre un circuit sans être télécommandé et pouvant s'adapter au tracé ainsi qu'à ses obstacles grâce à la Deep Learning Technologie. | ||
+ | |||
+ | Pour arriver à cette fin nous nous appuierons sur les fiches de conceptions des anciens concurrents disponibles [http://www.ironcar.org/github/ ici]. | ||
==Objectifs== | ==Objectifs== | ||
− | + | Pour participer à ce concours, nous devrons notamment : | |
− | |||
− | * | + | *mettre en place un réseau de capteurs et concevoir un algorithme qui les exploite pour pouvoir suivre la ligne discontinue du tracé; |
− | * | + | *mettre en oeuvre un Linux temps réel pour contrôler la voiture avec une phase de comparaison par rapport à un Linux classique ; |
− | * | + | *mettre en oeuvre d'autres algorithmes pour l'apprentissage automatique, déjà disponibles pour contrôler la voiture ; |
− | * | + | *gérer les servo-moteurs contrôlant la direction et la vitesse de la voiture (on utilisera un shield et un Arduino), et implémenter des algorithmes de contrôle de l'accélération et du freinage. |
=Analyse du projet= | =Analyse du projet= | ||
==Positionnement par rapport à l'existant== | ==Positionnement par rapport à l'existant== | ||
− | ==Analyse | + | |
− | == | + | ==Analyse des concurrents== |
+ | |||
+ | ===Patate42=== | ||
+ | [[Fichier:IMG 20181124 202851.jpg|300px|medium|]] | ||
+ | |||
+ | Le grand gagnant de la compétition édition 2018, réalisé par des élèves de l’école 42 paris, leur prototype a réussi à boucler les 3 tours en un temps record dont le meilleur tour a duré 1'17mn, ces résultats ont leurs permis de gagner le premier titre dans ce championnat national. | ||
+ | |||
+ | Ils ont choisi la Raspberry au lieu d'autres cartes électroniques parce qu’elle présente les avantages d’être facilement programmé, d'être puissance et très bon marché '''[1][2][3]''' | ||
+ | |||
+ | ===AxioNaut=== | ||
+ | AxioNaut sont un groupe d'étudiants qui viennent du groupe Axionable, une entreprise de conseil en Science de données. Ils ont remportés la seconde place de l’Iron Car France en 2018. | ||
+ | Ils ont utilisé une Raspberry pi 3 B+ équipée d'une camera qui assure la captation du parcours. L'autonomie dans le positionnement de la voiture et contrôle la vitesse durant le parcourt sont effectué par l'intelligence artificielle. '''[4][5]''' | ||
+ | |||
+ | |||
+ | [[Fichier:Ironcar 3-225x300.jpg|300px|]] | ||
+ | |||
+ | ===Navette autonome=== | ||
+ | |||
+ | Ce véhicule autonome est équipé de capteurs numériques (caméras, radars, sonars, lidars,etc) afin de se diriger seul. Par mesure de sécurité un conducteur est tout de même présent. | ||
+ | Les statistiques relèvent que 90% des accidents de la route sont liés à une erreur humaine. | ||
+ | La génération des voitures autonomes, comme cette navette, permet de réduire les accidents à travers un meilleur temps de réaction et une plus grande fiabilité des systèmes de commande. '''[6][7]''' | ||
+ | {| | ||
+ | [[Fichier:Navette-autonome-MEL-Transpole.png|500px|midium]] | ||
+ | |} | ||
+ | |||
==Scénario d'usage du produit ou du concept envisagé== | ==Scénario d'usage du produit ou du concept envisagé== | ||
+ | |||
+ | Phase d’entraînement : | ||
+ | |||
+ | On disposera d'une piste pour pouvoir effectuer la phase d'apprentissage de l'IA. Lors de la journée compétition que l'on organisera, les participants commanderont la voiture avec la manette type xbox et tenteront de faire des tours de piste le plus rapidement possible. | ||
+ | |||
+ | Pendant ce temps, la caméra de la voiture sera active et enregistrera les images du circuit, et les commandes entrées correspondantes par les utilisateurs seront elles aussi stockées. On pourra par la suite pondérer les résultats, par exemple une sortie de piste implique une mauvaise commande, et un tour rapide implique un bonne commande. | ||
+ | |||
+ | Pour plus de diversité, on entraînera la voiture à partir d'images générées aléatoirement qui correspondent à une portion de circuit Ironcar. | ||
+ | |||
+ | |||
+ | Phase de course autonome | ||
+ | |||
+ | On déposera la voiture sur la ligne de départ, et on attend le lancement de la course. Après celui-ci, la voiture démarre et essaie de suivre le tracé le plus rapidement possible. Dans le cas où elle sortirait de la piste, c'est à nous de la repositionner correctement. | ||
+ | |||
+ | ==La question difficile== | ||
+ | |||
+ | Comment entrainer notre IA ? | ||
+ | |||
==Réponse à la question difficile== | ==Réponse à la question difficile== | ||
+ | *Nous pouvons organiser des courses participatives à Polytech pour récupérer des données de trajectoire. Notre voiture pourra connaitre davantage de situations pour qu'elle puisse réagir dans des conditions plus variées. Il faudrait tracer un circuit sur le parking par exemple, puis organiser une compétitions entre étudiants et personnels pour récupérer le plus de données possibles. On peut pondérer les résultats en "récompensant" les temps plus courts dans le programmation de l'IA. | ||
+ | *Nous pouvons aussi mettre en place un environnement virtuel pour simuler un tracé et laisser le réseau de neurones s'entrainer de lui-même au sein de cette simulation. | ||
+ | |||
==Bibliographie et webographie== | ==Bibliographie et webographie== | ||
+ | [1]: https://www.42.fr/iron-car-2018-etudiants-champions/ | ||
+ | |||
+ | [2]: http://www.leparisien.fr/high-tech/qui-deviendra-le-champion-de-france-de-mini-voitures-autonomes-19-11-2018-7946379.php | ||
+ | |||
+ | [3]: https://github.com/EParisot/Patate | ||
+ | |||
+ | [4]: https://github.com/Axionable/Axionaut | ||
+ | |||
+ | [5]: https://www.axionable.com/axionaut-termine-1er-de-la-deuxieme-course-iron-car/ | ||
+ | |||
+ | [6]: https://www.ilevia.fr/cms/actualite/actus-des-reseaux/voyagez-navette-autonome-a-lille-mois-de-decembre.html | ||
+ | |||
+ | [7]: https://www.univ-lille.fr/nc/actualites/detail-actualite/?tx_news_pi1%5Bnews%5D=1423 | ||
+ | |||
+ | [*]: https://github.com/vinzeebreak/road_simulator | ||
+ | |||
+ | [*]: https://github.com/vinzeebreak/ironcar | ||
=Préparation du projet= | =Préparation du projet= | ||
==Cahier des charges du groupe== | ==Cahier des charges du groupe== | ||
+ | |||
+ | '''Cahier des charges pour la première année :''' | ||
+ | |||
+ | Reprendre le code source d'un ancien concurrent et l'implémenter dans notre châssis. | ||
+ | |||
+ | Avoir un modèle fonctionnel pour participer au concours de Septembre avec notre voiture. | ||
+ | |||
+ | |||
+ | '''Cahier des charges pour la seconde année :''' | ||
+ | |||
+ | Optimisation de la voiture (codes, commandes, ...) afin qu'elle soit plus performante. | ||
+ | |||
+ | La voiture fera 3 tours de pistes sans sortir de piste lors de la compétition de manière totalement autonome. | ||
+ | |||
+ | Ramenez la coupe à la maison | ||
+ | |||
+ | |||
+ | |||
+ | Détecter une sortie de piste sans avoir recours à des capteurs autres que la caméra. | ||
+ | |||
+ | La voiture finit la course le plus rapidement possible | ||
+ | |||
+ | Reconnaître des virages et des lignes droites plus ou moins grandes et adapter sa trajectoire et sa vitesse en conséquence. | ||
+ | |||
+ | Pouvoir faire exécuter le code de réseau de neurones par l'ordinateur suffisamment rapidement pour pouvoir réagir le plus rapidement possible (proche du temps réel). | ||
+ | |||
==Cahier des charges des équipes== | ==Cahier des charges des équipes== | ||
===Equipe 1=== | ===Equipe 1=== | ||
+ | |||
+ | * Mettre en place un Linux RT dans une Raspberry PI | ||
+ | |||
===Equipe 2=== | ===Equipe 2=== | ||
+ | |||
+ | * Récupérer le code des équipes précédentes et l'implémenter sur un PC puis sur une autre raspberry | ||
+ | * Installer toutes les dépendances pour chaque partie du code. | ||
+ | |||
===Equipe 3=== | ===Equipe 3=== | ||
+ | |||
+ | * Commander les moteurs de la voiture en utilisant un Arduino | ||
+ | * Envoyer les ordres à l'Arduino depuis un Raspberry pi | ||
+ | * Asservir les moteurs du chassis | ||
+ | * Créer une base en plexiglas pour tout le système de commande pour le rendre amovible | ||
==Choix techniques : matériel et logiciel== | ==Choix techniques : matériel et logiciel== | ||
===Equipe 1=== | ===Equipe 1=== | ||
+ | * Utiliser un mini-ordinateur à savoir Raspberry Pi 3 | ||
+ | * Installation de Linux RT sur carte micro SD avec Etcher | ||
===Equipe 2=== | ===Equipe 2=== | ||
+ | |||
+ | * Python pour tester le programme des vainqueurs de l'année précédente. | ||
+ | |||
+ | * Librairies associées pour permettre au code de fonctionner correctement. | ||
+ | |||
===Equipe 3=== | ===Equipe 3=== | ||
+ | * Installation d'un linux lite sur un raspberry pi | ||
+ | * Programmation de l'Arduino pour commande des moteurs | ||
+ | * Communication série entre raspberry pi (utilisation de Python) et l'Arduino | ||
==Liste des tâches à effectuer== | ==Liste des tâches à effectuer== | ||
− | ===Equipe 1=== | + | ===Equipe 1 : Linux RT=== |
− | ===Equipe 2=== | + | *Mise en place d'un Linux temps réel sur Raspberry |
− | ===Equipe 3=== | + | |
+ | ===Equipe 2 : Réseau neuronal=== | ||
+ | |||
+ | * Récupération du code des anciens vainqueurs | ||
+ | * Adaptation à notre système | ||
+ | * Amélioration / Entraînement du réseau neuronal | ||
+ | |||
+ | ===Equipe 3 : Contrôle de la voiture=== | ||
+ | *Installer un linux lite sur un raspberry pi 3 | ||
+ | *Etablir une connection série entre une Arduino et une raspberry pi | ||
+ | *Commander les moteurs de la voiture avec les ordres envoyés (moteur, vitesse, virages) par le raspberry pi grâce à l'Arduino. | ||
+ | *Agencement de la voiture | ||
==Calendrier prévisionnel== | ==Calendrier prévisionnel== | ||
Le calendrier prévisionnel peut se concrétiser sous la forme d'un diagramme de GANTT. | Le calendrier prévisionnel peut se concrétiser sous la forme d'un diagramme de GANTT. | ||
===Equipe 1=== | ===Equipe 1=== | ||
+ | [[Fichier:CPG1.png]] | ||
===Equipe 2=== | ===Equipe 2=== | ||
===Equipe 3=== | ===Equipe 3=== | ||
+ | [[Fichier:Calendar_gp3.png]] | ||
=Réalisation du Projet= | =Réalisation du Projet= | ||
==Projet S6== | ==Projet S6== | ||
+ | ===Semaine 4=== | ||
− | + | * Réponse à la question difficile | |
+ | * Prise d'informations sur le projet (le fonctionnement de la course, des IA), | ||
+ | * Analyse des projets des IMA4 et IMA5 | ||
− | |||
===Semaine 5=== | ===Semaine 5=== | ||
+ | Répartitions des tâches et début de la prise d'informations pour chacune des équipes. | ||
+ | |||
+ | *Equipe 1 : Haroun Raouak | ||
+ | *Equipe 2 : Maher Mathlouthi - Rémy Verbeke | ||
+ | *Equipe 3 : Thomas Mertz - Guillaume Cresmaschi | ||
+ | |||
===Semaine 6=== | ===Semaine 6=== | ||
+ | |||
+ | ====Equipe 1==== | ||
+ | Au début on a essayé d'installer Raspbian sur notre nano-ordinateur RPI et le patcher avec noyau RT ( PREEMPT-RT ou Xenomai ) mais ça n'as pas marché. | ||
+ | Alors on a décidé de chercher de nouveau sur le web jusqu'à trouver un moyen pour satisfaire les contraintes temporelles de la voiture. | ||
+ | |||
+ | ====Equipe 2==== | ||
+ | Pendant la première séance en équipe, nous avons recherché des ressources fiables et compréhensibles. Nous avons exploré le Github des gagnants des années précédentes, et avons retenu Patate 42. Leur code nous semblait plus fiable au départ, puisqu'ils ont réalisé le meilleur temps sur le parcourt, mais quand nous avons voulu le tester, nous n'avons pas compris les instructions à réaliser avant l'implémentation. | ||
+ | |||
+ | Nous nous sommes tourné alors vers Axionaute, qui ont pris soin de détailler les étapes nécessaires pour faire fonctionner leur code. | ||
+ | |||
+ | ====Equipe 3==== | ||
+ | Nous avons commencé par récupérer le matériel nécessaire à la mise en place du raspberry pi (raspberry pi 3, alimentation, câble Ethernet, carte SD + adaptateur). Puis nous avons recherché quel système d'exploitation nous pourrions utiliser. Nous somme restés sur une distribution raspbian lite assez classique et simple d'utilisation. Nous avons enfin choisit de programmer le raspberry pi en python car il existe de nombreuses bibliothèques dans ce langage et parce qu'il est simple d'utilisation. | ||
+ | |||
===Semaine 7=== | ===Semaine 7=== | ||
+ | ====Equipe 1==== | ||
+ | Installation d'une distribution linux intitulé RealtimePi sur Raspberry qui est déjà patché avec un noyau temps réel. | ||
+ | |||
+ | [https://github.com/guysoft/RealtimePi/blob/devel/README.rst Dépot Github RealtimePi] | ||
+ | |||
+ | ====Equipe 2==== | ||
+ | Nous avons cloné le dépôt Git d'Axionaute sur une machine Linux et essayé de le faire fonctionner. Nous nous sommes très vite aperçus que l'on avait besoin de python dans un premier temps. Nous avons dû l'installer à l'aide de différentes commandes. A chaque fois que nous essayions de lancer le programme d’entrainement, il nous manquait une librairie python ou un logiciel. Cette séance a été consacrée entièrement à chercher quelles librairies manquaient, et comment les installer. | ||
+ | |||
+ | Premier essai | ||
+ | #su | ||
+ | #apt-get update | ||
+ | #apt-get install python3-pip | ||
+ | #pip3 install -r requirements.txt | ||
+ | |||
+ | ====Equipe 3==== | ||
+ | Nous avons commencé à suivre les instructions du wiki [https://peip-ima.plil.fr/mediawiki/index.php/BE_2018-2019] pour installer correctement le système d'exploitation du raspberry pi. Nous sommes parvenu à l'installer et à communiquer par liaison série avec lui. Cependant à cause d'une erreur de manipulation nous avons supprimé le système de boot il a donc fallu recommencer l'installation. | ||
+ | |||
===Semaine 8=== | ===Semaine 8=== | ||
+ | ====Equipe 1==== | ||
+ | Implémentation du Rt-tests qui fournit un ensemble de programmes qui testent et mesurent divers composants de comportement en temps réel du noyau, tel que le temps de latence. | ||
+ | |||
+ | [https://packages.debian.org/jessie/rt-tests Paquet source de Rt-tests] | ||
+ | |||
+ | ====Equipe 2==== | ||
+ | Nous avons passé presque toute la séance à compléter l’environnent de travail pour le bon fonctionnent du programme d'entraînement. Après avoir fini d'installer toutes les libraires manquantes et lancé le script, nous avons essayé d'entrainer le système, mais nous n'avons pas eu le temps de le voir se terminer. | ||
+ | |||
+ | ====Equipe 3==== | ||
+ | L'Arduino et le raspberry pi communicant par port série, il fallait communiquer avec le raspberry pi par ssh. Nous avons mis en place cette communication à l'adresse 172.26.145.69. Le raspberry pi doit etre branché à l'Eternet du pc souhaitant se connecter par ssh. Il peut être nécessaire d'entrer différentes commadnes pour que cela fonctionne : | ||
+ | |||
+ | Sur le raspberry pi : | ||
+ | * export https_proxy=https://proxy.polytech-lille.fr:3128 | ||
+ | * export http_proxy=http://proxy.polytech-lille.fr:3128 | ||
+ | |||
+ | Sur le pc : | ||
+ | * iptables -F & iptables -tnat -F & iptables -PFORWARD ACCEPT | ||
+ | |||
+ | Pour que le raspberry ait une connection à internet | ||
+ | |||
===Semaine 9=== | ===Semaine 9=== | ||
+ | ====Equipe 1==== | ||
+ | A titre indicatif, on donnera les mesures de temps de latence dans le cas où le processeur est non chargé et dans le cas où le processeur est chargé. | ||
+ | |||
+ | [https://rt.wiki.kernel.org/index.php/Cyclictest. L'utilitaire cyclictest] On pourra l'installer comme suit : | ||
+ | $ cd | ||
+ | $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git | ||
+ | $ cd rt-tests | ||
+ | $ make | ||
+ | $ su | ||
+ | $ make install | ||
+ | |||
+ | ====Equipe 2==== | ||
+ | |||
+ | Nous avons condensé la liste des instructions à entrer pour faire fonctionner le programme. Ces instructions sont les suivantes : | ||
+ | |||
+ | Créer un nouveau répoertoire | ||
+ | $ mkdir ~/Ironcar | ||
+ | $ cd ~/Ironcar | ||
+ | |||
+ | cloner le repo | ||
+ | $ git clone https://github.com/Axionable/Axionaut.git | ||
+ | |||
+ | Telecharger la Dataset à partir de https://s3.amazonaws.com/axionautdataset/Datasets.zip | ||
+ | $ cp -r ~/Downloads/Datasets.zip ~/Ironcar/Axionaut/ | ||
+ | $ unzip Dataset | ||
+ | |||
+ | installer pip | ||
+ | $ apt-get install python-pip | ||
+ | |||
+ | installer les requirements | ||
+ | $ pip install -r requirements.txt | ||
+ | |||
+ | installer tensorflow | ||
+ | $ pip install --upgrade tensorflow | ||
+ | |||
+ | Lancer l'entrainement | ||
+ | $ python train.py | ||
+ | |||
+ | |||
+ | Le programme d'entrainement se lance sans prolèmes, mais prend beaucoup de temps. | ||
+ | |||
+ | ====Equipe 3==== | ||
+ | |||
+ | *Installation du paquet python3-serial pour que le raspberry pi puisse communiquer sur le port série | ||
+ | *Recherche sur le fonctionnement de la communication série [http://electroniqueamateur.blogspot.com/2014/05/communication-par-usb-entre-raspberry.html] [http://anothermaker.xyz/iot/communication-entre-un-raspberry-pi-et-un-arduino-5319] | ||
+ | |||
+ | *Recherche sur la voiture pour connaitre quels sont les fils de commande | ||
+ | *Début de la réalisation du programme Arduino de commande des moteurs | ||
+ | |||
+ | Voici le circuit de commande de la carte Arduino pour la voiture : | ||
+ | Les fils gris et orange sont les fils de commande, les rouges sont les fils d'alimentation et les bruns correspondent à la masse. | ||
+ | |||
+ | [[Fichier:circuit_commande_arduino.png|600 px]] | ||
+ | |||
===Semaine 10=== | ===Semaine 10=== | ||
+ | ====Equipe 1==== | ||
+ | |||
+ | On utilisera cyclictest pour générer un processus Temps Réel périodique dans l'espace utilisateur de plus forte priorité 99 de période 1000 µs par la commande : | ||
+ | |||
+ | $ su | ||
+ | $ cyclictest -n -p 99 -i 1000 | ||
+ | |||
+ | ====Equipe 2==== | ||
+ | |||
+ | Pour vérifier que nous avons correctement installé toutes les librairies, nous avons décidé de retester sur une autre machine les instructions que nous avons entré lors du premier lancement du programme. Cependant, on a eu plusieurs erreurs. En effet, certains packages ne s'installeint pas correctement et cela nous a retardé. Nous avons cherché à quoi ces erreurs étaient dûes. | ||
+ | |||
+ | ====Equipe 3==== | ||
+ | Nous avons terminé la communication entre le raspberry pi et l'arduino ce qui nous a permis de contrôler la direction des roues de la voiture. Nous avons ensuite essayé de controler le second moteur de la voiture à l'aide de l'arduino sans succés. Le calibrage de l'ESC (contröleur moteur) est à continuer en poursuivant l'étude de la documentation. | ||
+ | |||
===Semaine 11=== | ===Semaine 11=== | ||
+ | ====Equipe 1==== | ||
+ | Enfin, les mesures données ci-après sont à titre indicatif et mesurées sur quelques dizaines de secondes. Pour avoir un temps de latence correspondant au pire cas, il faudrait faire une mesure pendant des heures voire des jours en stressant le système de toutes les façons possibles en même temps... | ||
+ | |||
+ | Noyau linux non chargé: | ||
+ | $ cyclictest -n -p 99 -i 1000 | ||
+ | policy: fifo: loadavg: 0.07 0.05 0.02 1/240 3148 | ||
+ | T: 0 ( 3148) P:99 I:1000 C: 26416 Min: 5 Act: 5 Avg: 6 Max: 39661 | ||
+ | Temps de latence maximum mesuré : 39961 µs | ||
+ | |||
+ | ====Equipe 2==== | ||
+ | Nous avons résolu le problème, il suffisait de configurer le proxy de l'ordinateur. | ||
+ | Le programme se lance sans problèmes sur nimporte quelle machine apres avoir entré toutes les instructions nécessaires. | ||
+ | |||
+ | ==== Equipe 3==== | ||
+ | Nous avons continuez d'essayer de contrôler la vitesse de la voiture. Après des essais infructueux les roues se sont mises à tourner, puis, plus rien. La LED de l'ESC indiquait un fonctionnement anormal de la voiture. Après appel d'un professeur, vérification du circuit et du bon fonctionnement de la carte et des connexions, la voiture a de nouveaux accélérer avant de ne plus fonctionner. | ||
+ | |||
===Semaine 12=== | ===Semaine 12=== | ||
+ | ====Equipe 1==== | ||
+ | Résultats de cyclictest sur un noyau linux chargé: | ||
+ | $ cyclictest -n -p 99 -i 1000 | ||
+ | policy: fifo: loadavg: 66.78 19.73 6.82 52/344 3312 | ||
+ | T: 0 ( 3194) P:99 I:1000 C: 71956 Min: 2 Act: 3 Avg: 3 Max: 14 | ||
+ | Temps de latence maximum mesuré : 14 µs | ||
+ | |||
+ | ====Equipe 2==== | ||
+ | Après avoir communiqué avec l'équipe 3 sur le fonctionnement de la voiture, nous nous sommes apperçus que la manière dont Axionaute commande son chassis était totalement incompatible avec la notre. En effet, Axionaute utilise une architecture Nvidia Autopilot, qui necessite une carte electronique Nvidia spécifique que nous n'avons pas à notre disposition. | ||
+ | Nous nous sommes donc tournés vers le code de Patate42, qui après examination, correspond davantage à notre architecture matérielle. | ||
+ | |||
+ | Note : Après concertation, nous avons remarqué que nous nous étions completement trompés sur ce point. Le code d'Axionaute est bel et bien compatible avec le notre. | ||
+ | |||
+ | ====Equipe 3==== | ||
+ | Nous avons réussi à résoudre le problème concernant la vitesse de la voiture. En effet celle-ci a besoin d'un calibrage des gaz à chaque démarrage de cette dernière. | ||
+ | |||
+ | Deux problèmes mineurs se posent à présent : | ||
+ | |||
+ | *La voiture ne roule pas en marche arrière; | ||
+ | *Pour une même valeur envoyée, la vitesse varie légèrement d'un allumage à l'autre. | ||
+ | |||
+ | |||
+ | Ces deux problèmes n'étant pas handicapant pour la course nous avons décidé de ne pas nous en occuper pour le moment. | ||
+ | |||
+ | ===Semaine 13=== | ||
+ | ====Equipe 1==== | ||
+ | Le test du noyau intégrant le patch RT démontre un comportement « temps réel » car la variation du temps de réponse en temps réel est bien moindre que dans le cas d’un noyau standard, même si les résultats ne sont pas extraordinaires, certainement à cause de la qualité (moyenne) du noyau de la RPI. | ||
+ | |||
+ | Nous avons pu voir la mise en œuvre d'une distribution linux temps réel destiné pour le Raspberry Pi 3. Ce système permet de faire du Temps Réel et d'avoir des temps de latence de quelques µs sur notre nano-ordinateur tout en respectant les contraintes temporelles. | ||
+ | |||
+ | ====Equipe 2==== | ||
+ | Nous avons essayé d'implanter le dépot git de Patate42 dans la Raspberry Pi en Linux RT de l'équipe 1 et d'installer les programmes et librairies nécessaires. Nous n'avons pas réussi pour le moment à installer le module picamera.array. | ||
+ | |||
+ | Nous avons finalement abandonné cette perspective après avoir remarqué que le code d'Axionaute fonctionnait aussi. Les séances suivantes ont été consacrées à réaliser un programme qui puisse récupérer les prédictions du modèle quand il était face à une des photos du set d'entrainement. Nous avons eu plusieurs modèles à notre disposition : celui d'Axionaute, Patate42, celui des IMA4 et 5, et enfin le notre que nous avons entrainé nous meme avec le programme d'entrainement d'Axionaute. | ||
+ | |||
+ | Les résultats de chaque modèle sont très décevants. En effet, le modèle pré-entrainé d'Axionaute renvoie toujours les meme résultats quelle que soit l'image envoyée, celui de Patate42 renvoie des valeurs impossibles, et enfin le modèle que nous avons entrainé a un taux de réussite de 35%, ce qui est très loin d'un cas idéal, surtout sur des images inclues dans son set d'entrainement. Les modèles des IMA4 et 5 ont été enregistrés dans des structures de données différentes des notres et nous n'avons pas eu le temps d'essayer de les faire fonctionner pour comparaison. | ||
+ | |||
+ | ====Equipe 3==== | ||
+ | Nous sommes parvenu à commander la voiture pour qu'elle puisse reculer. Pour cela nous avons observé son fonctionnement à l'aide de la télécommande fournie. Nous avons ainsi vu que les moteurs étaient mal qualibrés et ne permettait pas la marche arrière. Nous avons refait le qualibrage des moteurs et cela nous à permis de commander parfaitement la voiture avec la télécommande. Pour que cela soit possible il est d'abord nécessaire de pousser le frein à son maximum puis de relacher la commande. Il est ensuite possible de faire reculer la voiture. Nous avons adapté ce principe à la commande de l'Arduino. Nous pouvons maintenant parfaitement contrôler la voiture à partir de la raspberry pi. | ||
===Documents Rendus=== | ===Documents Rendus=== | ||
+ | Les codes pour le commande de la voiture (Arduino/Raspberry pi) [https://github.com/Thorsieger/IronCar] | ||
+ | |||
+ | Compte-rendu du projet S6 [[Fichier:Rapport_Projet_IMA_P9.pdf]] | ||
==Projet S7== | ==Projet S7== | ||
− | === | + | ===Equipe 3=== |
+ | |||
+ | Pour la suite de ce projet deux taches principales sont à réaliser par notre groupe : | ||
+ | * Récupération de données pour entraîner notre IA | ||
+ | * Contrôle par l'IA de la voiture | ||
+ | |||
+ | Pour simplifier l'utilisation de la voiture nous allons également créer un support. | ||
+ | |||
+ | ====Récupérations de données==== | ||
+ | |||
+ | Nous souhaitons augmenter la taille de nos données pour l’entraînement de l'IA. | ||
+ | Pour cela , nous allons utiliser le module caméra fourni avec la Rapsberry pi pour prendre des photos du circuit. | ||
+ | |||
+ | Cependant nous voulons simplifier l'utilisation de ces données en associant à chaque image l'information du sens de la route automatiquement (pour ne pas le faire à la main). | ||
+ | |||
+ | |||
+ | Nous allons nous baser sur un système de suivis de ligne. Les 2 lignes extérieurs du circuit vont nous servir de guide pour que la voiture se déplace seule. | ||
+ | |||
+ | Nous allons utiliser le capteur de suivis de ligne QRE1113 pour détecter les lignes de la piste. | ||
+ | Nous avons commencé à développer un programme de suivis de ligne : [https://github.com/Thorsieger/IronCar/blob/master/Arduino/Command_car_by_line_sensor.ino github] qui se base sur l'utilisation de 4 capteurs. | ||
+ | |||
+ | Pour la ligne droite on va regarder l'état des deux capteurs, si les deux sont sur la ligne on ne fait rien. Dans le cas contraire on fait tourner la voiture pour quel se place correctement sur la piste. On fait de même avec la ligne gauche. Ces deux informations permettent de savoir s'il faut tourner beaucoup ou non. | ||
+ | |||
+ | |||
+ | Les prochaines tâches à réaliser sont : | ||
+ | * Test de notre programme de suivis de ligne | ||
+ | * Envoi de la commande des roues au raspberry pi | ||
+ | * Récupération des photos de la piste et tag de la commande de la voiture. | ||
+ | |||
+ | ====Contrôle de la voiture par l'IA==== | ||
+ | |||
+ | Nous n'avons pour le moment pas avancé sur cette partie. Voici cependant ce que nous voulons faire : | ||
+ | |||
+ | L'Intelligence artificielle nous donnera des informations sur le sens futur de la route. Pour l'instant le format de donné devrait être le suivant : [0,0,1,0,0]. Notre but sera de transformer cette donnée en une commande. | ||
+ | Cependant l'IA n'étant pas tout à fait fixé (de ce que nous en savons) le format de donnée pourrait évoluer. | ||
+ | |||
+ | Nous allons pouvoir nous baser sur le travail de l'année dernière (contrôle de la voiture à travers le raspberry pi et l'Arduino). | ||
+ | Il nous faudra tester pour connaître les valeurs de commande à donner en fonction des sorties de L'IA. | ||
+ | |||
+ | |||
+ | ''Finalement nous souhaitons proposer que le choix entre le mode entraînement et course se fasse facilement (interrupteur/bouton). Il faudra assembler notre code lorsque chaque partie fonctionnera correctement.'' | ||
+ | |||
+ | ====Support==== | ||
+ | |||
+ | Nous souhaitons créer un support pour la carte Raspberry pi et Arduino. Cela permettra de clarifier le câblage et d'avoir quelque chose de pratique à utiliser. | ||
+ | Nous avons prit les mesures du châssis de la voiture pour réaliser une plaque pouvant contenir tout nos composants. | ||
+ | |||
+ | Il nous faut aussi que nos capteurs de suivi de ligne soient au dessus des lignes de chaque côté de la piste. Pour concevoir le support des capteurs, il faut prendre en compte que les capteurs doivent être situés entre 1 et 3 mm de la ligne pour fonctionner. En dehors de cet intervalle, les valeurs sont incohérentes et on risquerait de fausser l'entrainement du réseau de neurones. | ||
+ | |||
+ | Le support imaginé est donc le suivant : | ||
+ | [[Fichier:support_capt.png|600px]] | ||
+ | |||
+ | ====Organisation des séances==== | ||
+ | [[Fichier:Organisation.jpeg]] | ||
+ | |||
+ | Pendant les trois premières séances nous avons travaillé ensemble. Puis M.Cresmaschi à travaillé sur le support et M.Mertz sur le suivis de ligne. | ||
+ | |||
+ | ===Equipe 2=== | ||
+ | |||
+ | Suite à l'échec de l'année dernière concernant la partie réseau de neurones, notre but pour ce semestre est d'avoir un modèle définitif fonctionnel et performant pour pouvoir faire fonctionner la voiture dans des conditions réelles. | ||
+ | |||
+ | '''Recherches''' | ||
+ | |||
+ | Nous avons passé une grande partie de notre temps à faire des recherches pour trouver un autre programme d'entrainement proposé par un autre concurrent. Nous en avons trouvé plusieurs, mais la plupart n'étaient pas adaptés à notre façon de faire. Dans les quelques uns qui fonctionnaient, nous avons observé des résultats peu concluants. En parallèle, nous avons aussi étudié le code fourni par les IMA5, et la solution astucieuse qu'ils ont trouvé pour entrainer leur modèle. Nous avons décidé de partir sur la même voie, car le gain de temps offert par Google Collaboratory n'est pas négligeable et nous permet de faire nos tests beaucoup plus facilement et rapidement. A savoir, pour un epoch d'entrainement qui nous prendrait 30min sur nos machines, on réduit le temps à seulement quelques minutes. | ||
+ | |||
+ | '''Entrainement''' | ||
+ | |||
+ | Pendant les semaines 5 et 6, nous avons pris la décision d'abandonner nos recherches car elles ne nous avaient menées nulle part jusqu'ici. Nous avons récupéré totalement le script d'entrainement des IMA5 et entrainé notre propre modèle avec le dataset d'images fourni par l'équipe Axionaut. Il a fallu faire un programme pour adapter le format du dataset (deux array numpy, un contenant les images et un les directions) en images jpg séparées, avec les directions intégrées dans leur nom de fichier. | ||
+ | |||
+ | Nous avons entrainé plusieurs modèles, d'abord avec un dataset réduit pour tester rapidement si les prédictions sont correctes, puis avec le dataset entier. Pour cela, on utilise l'architecture Nvidia que nous avons trouvé sur github et 200 epochs. Nous avons par la suite complété ce dataset avec d'autres que nous avons pu trouver, qui correspondent à d'autres circuits. Nous avons aussi pensé à utiliser le road simulator, mais après des tests rapides, nous avons vu que les modèles entrainés avec ce type d'images donnaient de mauvais résultats sur des images réelles. A tout cela s'ajoute les fonctions de traitement d'image proposées par PIL (contraste, luminosité, mirroir) qui augmentent la taille effective du dataset. | ||
+ | |||
+ | '''Résultats''' | ||
+ | |||
+ | Avec ces paramètres et données d'entrée, nous obtenons des résultats nous paraissants prometteurs pour une situation réelle. Nous avons testé pour deux genre de modèles : un à trois directions, et un à cinq. Pour le premier, en donnant au modèle une image qui provient d'un dataset séparé qui n'a pas été utilisé comme entrainement, on obtient 94% de bonnes prédictions en moyenne. Pour celui à cinq directions, 85%. | ||
+ | |||
+ | [[Fichier:94.jpg]][[Fichier:85.jpg|650px]] | ||
+ | |||
+ | '''Conclusion''' | ||
+ | |||
+ | Ce modèle à cinq prédictions est une grande amélioration par rapport à celui des IMA5, car ils avaient un pourcentage de réussite assez faible. Pour notre part, il n'est pas parfait mais nous pensons que c'est acceptable. | ||
+ | |||
+ | Nous attribuons ce résultat en grande partie à l'architecture que nous avons trouvé. En effet, avec la leur nous n'arrivions pas non plus très haut. Cependant, l'architecture ne fait pas tout. Nous avons du agir sur les différents paramètres de l'entrainement. Premièrement, notre dataset est plus complet et varié, il a été formé d'images provenant de différents circuits, ce qui adapte le modèle a plus de situations. Des traitements d'images plus nombreux, qui augmentent la taille du dataset en applicant des variations sur chaque image. Et enfin le nombre d'epochs, qui a été augmenté pour entrainer le modèle davantage. | ||
+ | |||
+ | ===Bibliographie=== | ||
+ | Doc caméra : https://www.raspberrypi.org/documentation/hardware/camera/ | ||
+ | |||
+ | Doc capteur de ligne : https://www.sparkfun.com/products/9453 | ||
==Projet S8== | ==Projet S8== | ||
===Documents Rendus=== | ===Documents Rendus=== |
Version actuelle datée du 5 janvier 2020 à 21:08
Sommaire
- 1 Présentation générale
- 2 Analyse du projet
- 3 Préparation du projet
- 4 Réalisation du Projet
Présentation générale
Description
Le projet consiste à réaliser une voiture autonome dans le but de participer au concours Ironcar dès 2019.
Ce dernier est une course de voitures (modèle réduit) intelligentes.
Afin d'y prendre part il nous faudra concevoir un véhicule pouvant suivre un circuit sans être télécommandé et pouvant s'adapter au tracé ainsi qu'à ses obstacles grâce à la Deep Learning Technologie.
Pour arriver à cette fin nous nous appuierons sur les fiches de conceptions des anciens concurrents disponibles ici.
Objectifs
Pour participer à ce concours, nous devrons notamment :
- mettre en place un réseau de capteurs et concevoir un algorithme qui les exploite pour pouvoir suivre la ligne discontinue du tracé;
- mettre en oeuvre un Linux temps réel pour contrôler la voiture avec une phase de comparaison par rapport à un Linux classique ;
- mettre en oeuvre d'autres algorithmes pour l'apprentissage automatique, déjà disponibles pour contrôler la voiture ;
- gérer les servo-moteurs contrôlant la direction et la vitesse de la voiture (on utilisera un shield et un Arduino), et implémenter des algorithmes de contrôle de l'accélération et du freinage.
Analyse du projet
Positionnement par rapport à l'existant
Analyse des concurrents
Patate42
Le grand gagnant de la compétition édition 2018, réalisé par des élèves de l’école 42 paris, leur prototype a réussi à boucler les 3 tours en un temps record dont le meilleur tour a duré 1'17mn, ces résultats ont leurs permis de gagner le premier titre dans ce championnat national.
Ils ont choisi la Raspberry au lieu d'autres cartes électroniques parce qu’elle présente les avantages d’être facilement programmé, d'être puissance et très bon marché [1][2][3]
AxioNaut
AxioNaut sont un groupe d'étudiants qui viennent du groupe Axionable, une entreprise de conseil en Science de données. Ils ont remportés la seconde place de l’Iron Car France en 2018. Ils ont utilisé une Raspberry pi 3 B+ équipée d'une camera qui assure la captation du parcours. L'autonomie dans le positionnement de la voiture et contrôle la vitesse durant le parcourt sont effectué par l'intelligence artificielle. [4][5]
Ce véhicule autonome est équipé de capteurs numériques (caméras, radars, sonars, lidars,etc) afin de se diriger seul. Par mesure de sécurité un conducteur est tout de même présent. Les statistiques relèvent que 90% des accidents de la route sont liés à une erreur humaine. La génération des voitures autonomes, comme cette navette, permet de réduire les accidents à travers un meilleur temps de réaction et une plus grande fiabilité des systèmes de commande. [6][7]
Scénario d'usage du produit ou du concept envisagé
Phase d’entraînement :
On disposera d'une piste pour pouvoir effectuer la phase d'apprentissage de l'IA. Lors de la journée compétition que l'on organisera, les participants commanderont la voiture avec la manette type xbox et tenteront de faire des tours de piste le plus rapidement possible.
Pendant ce temps, la caméra de la voiture sera active et enregistrera les images du circuit, et les commandes entrées correspondantes par les utilisateurs seront elles aussi stockées. On pourra par la suite pondérer les résultats, par exemple une sortie de piste implique une mauvaise commande, et un tour rapide implique un bonne commande.
Pour plus de diversité, on entraînera la voiture à partir d'images générées aléatoirement qui correspondent à une portion de circuit Ironcar.
Phase de course autonome
On déposera la voiture sur la ligne de départ, et on attend le lancement de la course. Après celui-ci, la voiture démarre et essaie de suivre le tracé le plus rapidement possible. Dans le cas où elle sortirait de la piste, c'est à nous de la repositionner correctement.
La question difficile
Comment entrainer notre IA ?
Réponse à la question difficile
- Nous pouvons organiser des courses participatives à Polytech pour récupérer des données de trajectoire. Notre voiture pourra connaitre davantage de situations pour qu'elle puisse réagir dans des conditions plus variées. Il faudrait tracer un circuit sur le parking par exemple, puis organiser une compétitions entre étudiants et personnels pour récupérer le plus de données possibles. On peut pondérer les résultats en "récompensant" les temps plus courts dans le programmation de l'IA.
- Nous pouvons aussi mettre en place un environnement virtuel pour simuler un tracé et laisser le réseau de neurones s'entrainer de lui-même au sein de cette simulation.
Bibliographie et webographie
[1]: https://www.42.fr/iron-car-2018-etudiants-champions/
[3]: https://github.com/EParisot/Patate
[4]: https://github.com/Axionable/Axionaut
[5]: https://www.axionable.com/axionaut-termine-1er-de-la-deuxieme-course-iron-car/
[7]: https://www.univ-lille.fr/nc/actualites/detail-actualite/?tx_news_pi1%5Bnews%5D=1423
[*]: https://github.com/vinzeebreak/road_simulator
[*]: https://github.com/vinzeebreak/ironcar
Préparation du projet
Cahier des charges du groupe
Cahier des charges pour la première année :
Reprendre le code source d'un ancien concurrent et l'implémenter dans notre châssis.
Avoir un modèle fonctionnel pour participer au concours de Septembre avec notre voiture.
Cahier des charges pour la seconde année :
Optimisation de la voiture (codes, commandes, ...) afin qu'elle soit plus performante.
La voiture fera 3 tours de pistes sans sortir de piste lors de la compétition de manière totalement autonome.
Ramenez la coupe à la maison
Détecter une sortie de piste sans avoir recours à des capteurs autres que la caméra.
La voiture finit la course le plus rapidement possible
Reconnaître des virages et des lignes droites plus ou moins grandes et adapter sa trajectoire et sa vitesse en conséquence.
Pouvoir faire exécuter le code de réseau de neurones par l'ordinateur suffisamment rapidement pour pouvoir réagir le plus rapidement possible (proche du temps réel).
Cahier des charges des équipes
Equipe 1
- Mettre en place un Linux RT dans une Raspberry PI
Equipe 2
- Récupérer le code des équipes précédentes et l'implémenter sur un PC puis sur une autre raspberry
- Installer toutes les dépendances pour chaque partie du code.
Equipe 3
- Commander les moteurs de la voiture en utilisant un Arduino
- Envoyer les ordres à l'Arduino depuis un Raspberry pi
- Asservir les moteurs du chassis
- Créer une base en plexiglas pour tout le système de commande pour le rendre amovible
Choix techniques : matériel et logiciel
Equipe 1
- Utiliser un mini-ordinateur à savoir Raspberry Pi 3
- Installation de Linux RT sur carte micro SD avec Etcher
Equipe 2
- Python pour tester le programme des vainqueurs de l'année précédente.
- Librairies associées pour permettre au code de fonctionner correctement.
Equipe 3
- Installation d'un linux lite sur un raspberry pi
- Programmation de l'Arduino pour commande des moteurs
- Communication série entre raspberry pi (utilisation de Python) et l'Arduino
Liste des tâches à effectuer
Equipe 1 : Linux RT
- Mise en place d'un Linux temps réel sur Raspberry
Equipe 2 : Réseau neuronal
- Récupération du code des anciens vainqueurs
- Adaptation à notre système
- Amélioration / Entraînement du réseau neuronal
Equipe 3 : Contrôle de la voiture
- Installer un linux lite sur un raspberry pi 3
- Etablir une connection série entre une Arduino et une raspberry pi
- Commander les moteurs de la voiture avec les ordres envoyés (moteur, vitesse, virages) par le raspberry pi grâce à l'Arduino.
- Agencement de la voiture
Calendrier prévisionnel
Le calendrier prévisionnel peut se concrétiser sous la forme d'un diagramme de GANTT.
Equipe 1
Equipe 2
Equipe 3
Réalisation du Projet
Projet S6
Semaine 4
- Réponse à la question difficile
- Prise d'informations sur le projet (le fonctionnement de la course, des IA),
- Analyse des projets des IMA4 et IMA5
Semaine 5
Répartitions des tâches et début de la prise d'informations pour chacune des équipes.
- Equipe 1 : Haroun Raouak
- Equipe 2 : Maher Mathlouthi - Rémy Verbeke
- Equipe 3 : Thomas Mertz - Guillaume Cresmaschi
Semaine 6
Equipe 1
Au début on a essayé d'installer Raspbian sur notre nano-ordinateur RPI et le patcher avec noyau RT ( PREEMPT-RT ou Xenomai ) mais ça n'as pas marché. Alors on a décidé de chercher de nouveau sur le web jusqu'à trouver un moyen pour satisfaire les contraintes temporelles de la voiture.
Equipe 2
Pendant la première séance en équipe, nous avons recherché des ressources fiables et compréhensibles. Nous avons exploré le Github des gagnants des années précédentes, et avons retenu Patate 42. Leur code nous semblait plus fiable au départ, puisqu'ils ont réalisé le meilleur temps sur le parcourt, mais quand nous avons voulu le tester, nous n'avons pas compris les instructions à réaliser avant l'implémentation.
Nous nous sommes tourné alors vers Axionaute, qui ont pris soin de détailler les étapes nécessaires pour faire fonctionner leur code.
Equipe 3
Nous avons commencé par récupérer le matériel nécessaire à la mise en place du raspberry pi (raspberry pi 3, alimentation, câble Ethernet, carte SD + adaptateur). Puis nous avons recherché quel système d'exploitation nous pourrions utiliser. Nous somme restés sur une distribution raspbian lite assez classique et simple d'utilisation. Nous avons enfin choisit de programmer le raspberry pi en python car il existe de nombreuses bibliothèques dans ce langage et parce qu'il est simple d'utilisation.
Semaine 7
Equipe 1
Installation d'une distribution linux intitulé RealtimePi sur Raspberry qui est déjà patché avec un noyau temps réel.
Equipe 2
Nous avons cloné le dépôt Git d'Axionaute sur une machine Linux et essayé de le faire fonctionner. Nous nous sommes très vite aperçus que l'on avait besoin de python dans un premier temps. Nous avons dû l'installer à l'aide de différentes commandes. A chaque fois que nous essayions de lancer le programme d’entrainement, il nous manquait une librairie python ou un logiciel. Cette séance a été consacrée entièrement à chercher quelles librairies manquaient, et comment les installer.
Premier essai
- su
- apt-get update
- apt-get install python3-pip
- pip3 install -r requirements.txt
Equipe 3
Nous avons commencé à suivre les instructions du wiki [1] pour installer correctement le système d'exploitation du raspberry pi. Nous sommes parvenu à l'installer et à communiquer par liaison série avec lui. Cependant à cause d'une erreur de manipulation nous avons supprimé le système de boot il a donc fallu recommencer l'installation.
Semaine 8
Equipe 1
Implémentation du Rt-tests qui fournit un ensemble de programmes qui testent et mesurent divers composants de comportement en temps réel du noyau, tel que le temps de latence.
Equipe 2
Nous avons passé presque toute la séance à compléter l’environnent de travail pour le bon fonctionnent du programme d'entraînement. Après avoir fini d'installer toutes les libraires manquantes et lancé le script, nous avons essayé d'entrainer le système, mais nous n'avons pas eu le temps de le voir se terminer.
Equipe 3
L'Arduino et le raspberry pi communicant par port série, il fallait communiquer avec le raspberry pi par ssh. Nous avons mis en place cette communication à l'adresse 172.26.145.69. Le raspberry pi doit etre branché à l'Eternet du pc souhaitant se connecter par ssh. Il peut être nécessaire d'entrer différentes commadnes pour que cela fonctionne :
Sur le raspberry pi :
- export https_proxy=https://proxy.polytech-lille.fr:3128
- export http_proxy=http://proxy.polytech-lille.fr:3128
Sur le pc :
- iptables -F & iptables -tnat -F & iptables -PFORWARD ACCEPT
Pour que le raspberry ait une connection à internet
Semaine 9
Equipe 1
A titre indicatif, on donnera les mesures de temps de latence dans le cas où le processeur est non chargé et dans le cas où le processeur est chargé.
L'utilitaire cyclictest On pourra l'installer comme suit :
$ cd $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git $ cd rt-tests $ make $ su $ make install
Equipe 2
Nous avons condensé la liste des instructions à entrer pour faire fonctionner le programme. Ces instructions sont les suivantes :
Créer un nouveau répoertoire
$ mkdir ~/Ironcar $ cd ~/Ironcar
cloner le repo
$ git clone https://github.com/Axionable/Axionaut.git
Telecharger la Dataset à partir de https://s3.amazonaws.com/axionautdataset/Datasets.zip
$ cp -r ~/Downloads/Datasets.zip ~/Ironcar/Axionaut/ $ unzip Dataset
installer pip
$ apt-get install python-pip
installer les requirements
$ pip install -r requirements.txt
installer tensorflow
$ pip install --upgrade tensorflow
Lancer l'entrainement
$ python train.py
Le programme d'entrainement se lance sans prolèmes, mais prend beaucoup de temps.
Equipe 3
- Installation du paquet python3-serial pour que le raspberry pi puisse communiquer sur le port série
- Recherche sur le fonctionnement de la communication série [2] [3]
- Recherche sur la voiture pour connaitre quels sont les fils de commande
- Début de la réalisation du programme Arduino de commande des moteurs
Voici le circuit de commande de la carte Arduino pour la voiture : Les fils gris et orange sont les fils de commande, les rouges sont les fils d'alimentation et les bruns correspondent à la masse.
Semaine 10
Equipe 1
On utilisera cyclictest pour générer un processus Temps Réel périodique dans l'espace utilisateur de plus forte priorité 99 de période 1000 µs par la commande :
$ su $ cyclictest -n -p 99 -i 1000
Equipe 2
Pour vérifier que nous avons correctement installé toutes les librairies, nous avons décidé de retester sur une autre machine les instructions que nous avons entré lors du premier lancement du programme. Cependant, on a eu plusieurs erreurs. En effet, certains packages ne s'installeint pas correctement et cela nous a retardé. Nous avons cherché à quoi ces erreurs étaient dûes.
Equipe 3
Nous avons terminé la communication entre le raspberry pi et l'arduino ce qui nous a permis de contrôler la direction des roues de la voiture. Nous avons ensuite essayé de controler le second moteur de la voiture à l'aide de l'arduino sans succés. Le calibrage de l'ESC (contröleur moteur) est à continuer en poursuivant l'étude de la documentation.
Semaine 11
Equipe 1
Enfin, les mesures données ci-après sont à titre indicatif et mesurées sur quelques dizaines de secondes. Pour avoir un temps de latence correspondant au pire cas, il faudrait faire une mesure pendant des heures voire des jours en stressant le système de toutes les façons possibles en même temps...
Noyau linux non chargé:
$ cyclictest -n -p 99 -i 1000 policy: fifo: loadavg: 0.07 0.05 0.02 1/240 3148 T: 0 ( 3148) P:99 I:1000 C: 26416 Min: 5 Act: 5 Avg: 6 Max: 39661 Temps de latence maximum mesuré : 39961 µs
Equipe 2
Nous avons résolu le problème, il suffisait de configurer le proxy de l'ordinateur. Le programme se lance sans problèmes sur nimporte quelle machine apres avoir entré toutes les instructions nécessaires.
Equipe 3
Nous avons continuez d'essayer de contrôler la vitesse de la voiture. Après des essais infructueux les roues se sont mises à tourner, puis, plus rien. La LED de l'ESC indiquait un fonctionnement anormal de la voiture. Après appel d'un professeur, vérification du circuit et du bon fonctionnement de la carte et des connexions, la voiture a de nouveaux accélérer avant de ne plus fonctionner.
Semaine 12
Equipe 1
Résultats de cyclictest sur un noyau linux chargé:
$ cyclictest -n -p 99 -i 1000 policy: fifo: loadavg: 66.78 19.73 6.82 52/344 3312 T: 0 ( 3194) P:99 I:1000 C: 71956 Min: 2 Act: 3 Avg: 3 Max: 14 Temps de latence maximum mesuré : 14 µs
Equipe 2
Après avoir communiqué avec l'équipe 3 sur le fonctionnement de la voiture, nous nous sommes apperçus que la manière dont Axionaute commande son chassis était totalement incompatible avec la notre. En effet, Axionaute utilise une architecture Nvidia Autopilot, qui necessite une carte electronique Nvidia spécifique que nous n'avons pas à notre disposition. Nous nous sommes donc tournés vers le code de Patate42, qui après examination, correspond davantage à notre architecture matérielle.
Note : Après concertation, nous avons remarqué que nous nous étions completement trompés sur ce point. Le code d'Axionaute est bel et bien compatible avec le notre.
Equipe 3
Nous avons réussi à résoudre le problème concernant la vitesse de la voiture. En effet celle-ci a besoin d'un calibrage des gaz à chaque démarrage de cette dernière.
Deux problèmes mineurs se posent à présent :
- La voiture ne roule pas en marche arrière;
- Pour une même valeur envoyée, la vitesse varie légèrement d'un allumage à l'autre.
Ces deux problèmes n'étant pas handicapant pour la course nous avons décidé de ne pas nous en occuper pour le moment.
Semaine 13
Equipe 1
Le test du noyau intégrant le patch RT démontre un comportement « temps réel » car la variation du temps de réponse en temps réel est bien moindre que dans le cas d’un noyau standard, même si les résultats ne sont pas extraordinaires, certainement à cause de la qualité (moyenne) du noyau de la RPI.
Nous avons pu voir la mise en œuvre d'une distribution linux temps réel destiné pour le Raspberry Pi 3. Ce système permet de faire du Temps Réel et d'avoir des temps de latence de quelques µs sur notre nano-ordinateur tout en respectant les contraintes temporelles.
Equipe 2
Nous avons essayé d'implanter le dépot git de Patate42 dans la Raspberry Pi en Linux RT de l'équipe 1 et d'installer les programmes et librairies nécessaires. Nous n'avons pas réussi pour le moment à installer le module picamera.array.
Nous avons finalement abandonné cette perspective après avoir remarqué que le code d'Axionaute fonctionnait aussi. Les séances suivantes ont été consacrées à réaliser un programme qui puisse récupérer les prédictions du modèle quand il était face à une des photos du set d'entrainement. Nous avons eu plusieurs modèles à notre disposition : celui d'Axionaute, Patate42, celui des IMA4 et 5, et enfin le notre que nous avons entrainé nous meme avec le programme d'entrainement d'Axionaute.
Les résultats de chaque modèle sont très décevants. En effet, le modèle pré-entrainé d'Axionaute renvoie toujours les meme résultats quelle que soit l'image envoyée, celui de Patate42 renvoie des valeurs impossibles, et enfin le modèle que nous avons entrainé a un taux de réussite de 35%, ce qui est très loin d'un cas idéal, surtout sur des images inclues dans son set d'entrainement. Les modèles des IMA4 et 5 ont été enregistrés dans des structures de données différentes des notres et nous n'avons pas eu le temps d'essayer de les faire fonctionner pour comparaison.
Equipe 3
Nous sommes parvenu à commander la voiture pour qu'elle puisse reculer. Pour cela nous avons observé son fonctionnement à l'aide de la télécommande fournie. Nous avons ainsi vu que les moteurs étaient mal qualibrés et ne permettait pas la marche arrière. Nous avons refait le qualibrage des moteurs et cela nous à permis de commander parfaitement la voiture avec la télécommande. Pour que cela soit possible il est d'abord nécessaire de pousser le frein à son maximum puis de relacher la commande. Il est ensuite possible de faire reculer la voiture. Nous avons adapté ce principe à la commande de l'Arduino. Nous pouvons maintenant parfaitement contrôler la voiture à partir de la raspberry pi.
Documents Rendus
Les codes pour le commande de la voiture (Arduino/Raspberry pi) [4]
Compte-rendu du projet S6 Fichier:Rapport Projet IMA P9.pdf
Projet S7
Equipe 3
Pour la suite de ce projet deux taches principales sont à réaliser par notre groupe :
- Récupération de données pour entraîner notre IA
- Contrôle par l'IA de la voiture
Pour simplifier l'utilisation de la voiture nous allons également créer un support.
Récupérations de données
Nous souhaitons augmenter la taille de nos données pour l’entraînement de l'IA. Pour cela , nous allons utiliser le module caméra fourni avec la Rapsberry pi pour prendre des photos du circuit.
Cependant nous voulons simplifier l'utilisation de ces données en associant à chaque image l'information du sens de la route automatiquement (pour ne pas le faire à la main).
Nous allons nous baser sur un système de suivis de ligne. Les 2 lignes extérieurs du circuit vont nous servir de guide pour que la voiture se déplace seule.
Nous allons utiliser le capteur de suivis de ligne QRE1113 pour détecter les lignes de la piste. Nous avons commencé à développer un programme de suivis de ligne : github qui se base sur l'utilisation de 4 capteurs.
Pour la ligne droite on va regarder l'état des deux capteurs, si les deux sont sur la ligne on ne fait rien. Dans le cas contraire on fait tourner la voiture pour quel se place correctement sur la piste. On fait de même avec la ligne gauche. Ces deux informations permettent de savoir s'il faut tourner beaucoup ou non.
Les prochaines tâches à réaliser sont :
- Test de notre programme de suivis de ligne
- Envoi de la commande des roues au raspberry pi
- Récupération des photos de la piste et tag de la commande de la voiture.
Contrôle de la voiture par l'IA
Nous n'avons pour le moment pas avancé sur cette partie. Voici cependant ce que nous voulons faire :
L'Intelligence artificielle nous donnera des informations sur le sens futur de la route. Pour l'instant le format de donné devrait être le suivant : [0,0,1,0,0]. Notre but sera de transformer cette donnée en une commande. Cependant l'IA n'étant pas tout à fait fixé (de ce que nous en savons) le format de donnée pourrait évoluer.
Nous allons pouvoir nous baser sur le travail de l'année dernière (contrôle de la voiture à travers le raspberry pi et l'Arduino). Il nous faudra tester pour connaître les valeurs de commande à donner en fonction des sorties de L'IA.
Finalement nous souhaitons proposer que le choix entre le mode entraînement et course se fasse facilement (interrupteur/bouton). Il faudra assembler notre code lorsque chaque partie fonctionnera correctement.
Support
Nous souhaitons créer un support pour la carte Raspberry pi et Arduino. Cela permettra de clarifier le câblage et d'avoir quelque chose de pratique à utiliser. Nous avons prit les mesures du châssis de la voiture pour réaliser une plaque pouvant contenir tout nos composants.
Il nous faut aussi que nos capteurs de suivi de ligne soient au dessus des lignes de chaque côté de la piste. Pour concevoir le support des capteurs, il faut prendre en compte que les capteurs doivent être situés entre 1 et 3 mm de la ligne pour fonctionner. En dehors de cet intervalle, les valeurs sont incohérentes et on risquerait de fausser l'entrainement du réseau de neurones.
Le support imaginé est donc le suivant :
Organisation des séances
Pendant les trois premières séances nous avons travaillé ensemble. Puis M.Cresmaschi à travaillé sur le support et M.Mertz sur le suivis de ligne.
Equipe 2
Suite à l'échec de l'année dernière concernant la partie réseau de neurones, notre but pour ce semestre est d'avoir un modèle définitif fonctionnel et performant pour pouvoir faire fonctionner la voiture dans des conditions réelles.
Recherches
Nous avons passé une grande partie de notre temps à faire des recherches pour trouver un autre programme d'entrainement proposé par un autre concurrent. Nous en avons trouvé plusieurs, mais la plupart n'étaient pas adaptés à notre façon de faire. Dans les quelques uns qui fonctionnaient, nous avons observé des résultats peu concluants. En parallèle, nous avons aussi étudié le code fourni par les IMA5, et la solution astucieuse qu'ils ont trouvé pour entrainer leur modèle. Nous avons décidé de partir sur la même voie, car le gain de temps offert par Google Collaboratory n'est pas négligeable et nous permet de faire nos tests beaucoup plus facilement et rapidement. A savoir, pour un epoch d'entrainement qui nous prendrait 30min sur nos machines, on réduit le temps à seulement quelques minutes.
Entrainement
Pendant les semaines 5 et 6, nous avons pris la décision d'abandonner nos recherches car elles ne nous avaient menées nulle part jusqu'ici. Nous avons récupéré totalement le script d'entrainement des IMA5 et entrainé notre propre modèle avec le dataset d'images fourni par l'équipe Axionaut. Il a fallu faire un programme pour adapter le format du dataset (deux array numpy, un contenant les images et un les directions) en images jpg séparées, avec les directions intégrées dans leur nom de fichier.
Nous avons entrainé plusieurs modèles, d'abord avec un dataset réduit pour tester rapidement si les prédictions sont correctes, puis avec le dataset entier. Pour cela, on utilise l'architecture Nvidia que nous avons trouvé sur github et 200 epochs. Nous avons par la suite complété ce dataset avec d'autres que nous avons pu trouver, qui correspondent à d'autres circuits. Nous avons aussi pensé à utiliser le road simulator, mais après des tests rapides, nous avons vu que les modèles entrainés avec ce type d'images donnaient de mauvais résultats sur des images réelles. A tout cela s'ajoute les fonctions de traitement d'image proposées par PIL (contraste, luminosité, mirroir) qui augmentent la taille effective du dataset.
Résultats
Avec ces paramètres et données d'entrée, nous obtenons des résultats nous paraissants prometteurs pour une situation réelle. Nous avons testé pour deux genre de modèles : un à trois directions, et un à cinq. Pour le premier, en donnant au modèle une image qui provient d'un dataset séparé qui n'a pas été utilisé comme entrainement, on obtient 94% de bonnes prédictions en moyenne. Pour celui à cinq directions, 85%.
Conclusion
Ce modèle à cinq prédictions est une grande amélioration par rapport à celui des IMA5, car ils avaient un pourcentage de réussite assez faible. Pour notre part, il n'est pas parfait mais nous pensons que c'est acceptable.
Nous attribuons ce résultat en grande partie à l'architecture que nous avons trouvé. En effet, avec la leur nous n'arrivions pas non plus très haut. Cependant, l'architecture ne fait pas tout. Nous avons du agir sur les différents paramètres de l'entrainement. Premièrement, notre dataset est plus complet et varié, il a été formé d'images provenant de différents circuits, ce qui adapte le modèle a plus de situations. Des traitements d'images plus nombreux, qui augmentent la taille du dataset en applicant des variations sur chaque image. Et enfin le nombre d'epochs, qui a été augmenté pour entrainer le modèle davantage.
Bibliographie
Doc caméra : https://www.raspberrypi.org/documentation/hardware/camera/
Doc capteur de ligne : https://www.sparkfun.com/products/9453