IMA5 2018/2019 P44 : Différence entre versions
(→notes) |
(→notes) |
||
| Ligne 52 : | Ligne 52 : | ||
peau banane ? | 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 | 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 | ||
=Résultats= | =Résultats= | ||
=Documents rendus= | =Documents rendus= | ||
Version du 17 janvier 2019 à 17:26
Sommaire
Présentation du projet
Description
Objectifs
Analyse du projet
analyse des concurents
Préparation
Cahier des charges
Choix matériels et technologiques
Réalisation du projet
Avancement préalable
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.
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-19 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.
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
