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

Voiture sans modification

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

La compétition IRONCAR permet de faire s'affronter différentes équipes entre elles plusieurs fois dans l'année. Chaque équipe à le droit d'avoir une voiture avec une ou deux raspi/arduino, une caméra ainsi que le necessaire electronique pour faire avancer la voiture. Le bolide doit être totalement autonome et entrainé par intelligence artificielle en apprentissage profond, deep learning en anglais.

La voiture est seule sur la piste et doit réaliser 3 tours de celle-ci en un temps minimum. La piste est large de 1 m 80 avec des bandes blanches latérales continues et possède également une ligne jaune pointillée centrale.

Le classement final est du type "championnat" est chaque competition selon son importance rapporte plus ou moins de points. A la fin de l'année, l'équipe ayant le plus de points gagne. Le projet de l'Ironcar étant de progresser via l'opensource, le gagnant est tenu de partager le projet github contenant les fichiers qui lui ont permis de gagner. Cela permet aux autres concurents de s'en inspirer et d'améliorer constamment algorithme de deep learning. Cette compétition est vraiment orientée vers le partage et la progression commune.

Plus d'informations sur le site de la compétition : ironcar

Objectifs

Notre objectif principal est avant tout d'avoir une voiture fonctionnelle. En effet, la victoire du championnant parait difficielement enviseagble pour une première participation, d'autant que la "saison" a déjà débuté depuis un bon moment et certaines équipes comptabilisent déjà plusieurs dizaine de points à leur compteur.

L'objectif technique est surtout de pouvoir gagner en compétences dans le domaine du depp learning et de l'intelligence artificielle afin de mettre en pratique les cours étudiés lors de nos échanges universitaires respectifs.

Nous partirons dons dans l'idée d'avoir une voiture la plus aboutie possible et permettant de faire le meilleur score possible lors de la course.

De plus, Monsieur Vantroys souhaiterait organiser la prochaine compétiton Ironcar début Mars. S'ajoute donc au projet finale, l'objectif d'organiser au mieux la compétition afin que les concurents puisse participer dans les meilleurs conditions.

Analyse du projet

analyse des concurents

analyse des premiers concurrents

autres voitures en compétition

Bien sûr les premiers concurrents directs seront les autres participants à la course de l'ironcar. Ces différents concurrents 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 requises pour participer à la compétition, bien évidemment.

Chaque équipe est généralement associé à une école. Ils ont plus ou moins de temps et de moyen à disposition à consacré pour cette compétition. Il est difficile de pouvoir analyser nos concurrents directs sans les avoir encore affronté en compétition, cependant certains score obtenus et certaines vidéos à l'appuie témoignent d'une réussite certaine de la part de certaines équipes. Nous tâcheront d'être assez compétitifs pour pouvoir les inquiéter dans leur course (nous espérons même pouvoir les battre ! Qui sait ?! )

analyse des seconds concurents

Voiture autonome Google

D'autres parts, il y aussi d'autre type de concurrents , notamment des grandes entreprises comme google, uber ou tesla qui conceptualisent et déploient des voitures autonomes depuis plusieurs années. En effet, la voiture autonome est déjà une réalité dans certains pays, notamment en Californie aux USA. Les résultats sont plus qu’impressionnants. On dénombres moins d'une dizaine d'accidents responsables pour les voitures autonomes ces deux dernières années. Les réseaux de neurones (deep learning) sont entraînés avec des datasets de plusieurs milliers d'heures de conduites et peuvent ainsi répondent à chaque cas possible. Ces datasets sont parfois disponibles gratuitement sur internet.

Bien que la technologie soit déjà utilisable et fiable, les recherches dans ce domaine sont en constante extension. L'idée d'améliorer l'intelligence artificielle des véhicules continue de croître dans la tête des aux décisionnaires des grandes entreprises comme google. Ce pourquoi nous pouvons actuellement rencontrés des entraînements de réseaux de neurones sujets à controverses, parfois à la limite de l'éthique morale. C'est notamment le cas avec des recherches qui sont effectués sur "qui doit on sacrifier?" en cas d'accidents inévitable. Cet algorithme prend en compte le nombre, l'âge des protagonistes, mais aussi le lien d'affection éventuel avec le propriétaire de la voiture (donc conducteur potentiel). Par exemple faut-il percuter trois personnes âgées pour sauver le propriétaire quadragénaire de la voiture ainsi que sa file en bas âge ? Des questions dérangeantes, qui suscitent beaucoup de réactions.

Préparation

Cahier des charges

Notre cahier des charges sera assez simpliste :

- Obtenir une voiture améliorée mécaniquement, via impression 3D ou découpe laser, afin de maintenir correctement les composants ajoutés nécessaires à l'apprentissage de la voiture.

- Obtenir une voiture fonctionnelle en orientation et en mouvement (qui se déplace correctement).

- Faire en sorte que le réseaux de neurones de la voiture soit fonctionnel et performant.

- Obtenir un score satisfaisant (le plus haut possible) lors de la participation de la voiture à la prochaine course Ironcar.

- Organiser le mieux possible (si elle a lieu), la prochaine IronCar, dans le hall de l'école.

- Faire en sorte que le travail réalisé sur la voiture soit propre et que le bolide est un design final agréable.

Choix matériels et technologiques

resau de neurones

Pytorch

Pour ce qui est du matériel, nous avons une voiture à l'échelle 1/10, achetée par un des tuteurs de stage. Nous y ajouterons une raspberry pi 3+ pour permettre de traiter au mieux les besoins du deep learning. Ainsi qu'une arduino pour contrôler les moteurs proprement avec une PWM uniquement prévue à cette effet. Il y aura également une caméra grand angle, essentiel pour la vision et l'enregistrement de la piste dans son intégralité pour l'entrainement de la voiture. Une alimentation (qui était déjà à notre disposition à l'école) sera utilisée pour fournir le jus à la raspi, qui alimentera elle même l'arduino. Les ajouts de pièces mécaniques seront quand à elles soit imprimées en 3D, soit découpé via la découpeuse laser du fabricarium. C'est en effet ce qui permet un travail sur des matières rigides, le plus net et le plus facilement accessible.

Pour ce qui est du software, nous utiliserons une méthode d’intelligence artificielle, imposée par la compétition : le deep learning. Cette méthode, l' apprentissage profond en français, consiste à entraîner un réseaux de neurones en lui fournissant de nombreuses informations. Dans notre cas, les informations seront des exemples de vidéos de pilotage, filmés avec la caméra, lorsque nous contrôlons la voiture via la télécommande. L'algorithme de deep learning va alors analyser les diverses situations et s'en inspirer pour pouvoir ensuite réagir de la façon la plus adéquate, au moment du pilotage autonome, lorsque la voiture sera confronté à une situation similaire ou identique. Nous utiliserons la librairie python Pytorch pour construire notre algorithme. C'est en effet une des plus utilisés et des plus performantes actuellement. Elle fait notamment concurrence à Keras ou encore au fameux TensorFlow de Google.

Réalisation du projet

Avancement préalable

Puisque nous étions tous deux en semestre à l'étranger, il était compliqué de pouvoir avancer concrètement le projet avant notre retour à Polytech Lille. Cependant nous nous sommes tout de même renseignés sur les composants nécessaires à la réalisation du projet afin de pouvoir anticiper leur commande et ainsi commencer le projet dès la rentrée des vacances de noël. De plus nous avons fait de nombreuses recherches afin d'orienter les choix que nous serions obligés de faire par la suite une fois le projet entamé. Ce qui nous à donc amené à prendre connaissance du projet DeepPiCar qui consiste lui aussi à créer une voiture miniature autonome à partir d'une raspberry et d'une caméra.

Semaine 1 (7-11 janvier)

Partie informatique

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.

Interface web

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.

Partie électronique

telecommande

Bien que les premiers tests sur la voiture concernaient l’orientation et la vitesse de pointe max, il fallait tester la télécommande dans son intégralité. Nous nous sommes donc longuement référés à la notice de la voiture. Finalement, voici l fonctionnalité des différentes commandes de ma télécommande.

La gâchette sert à accélérer ou reculer et à jauger la vitesse. La molette latérale droite sert à orienter les roues avant. La molette centrale sert à régler l’angle du servo moteurs contrôlant les roues avant (nous les mettront par défaut à 30 degrés, quitte à remodifier cette valeur par la suite) Le bouton en haut à droite change le sens de d’orientation des roues directrices (tourner à droite fais désormais tourner la voiture à gauche) Celui d’en bas à droite, permet de corriger l'orientation des roues "au repos", la position par défaut. Celui en bas à gauche permet de re-calibrer la tension de la voiture, si celle-ci n’est pas totalement à l’arrêt losqu’on ne lui donne aucune indications. Le bouton en haut à gauche permet d'inverser le sens de rotation des moteurs (inverser la tête et la queue de la voiture) Enfin le bouton power sert à alimenter la télécommande (pas trop compliqué celui-là)

Partie mécanique

Ensuite il était essentiel de prévoir un support pour les différents composants que nous allions ajouter à la voiture. Effectivement, il faut pouvoir fixer les différents contrôleurs pour remplacer la télécommande. L’utilisation d’une raspberry était évidente. Pour ce qui est du contrôleur des moteurs, notre tuteur nous a fait remarquer qu’il s’agissait d’une simple PWM. Ainsi, une arduino serait judicieuse afin d’avoir une PWM de bonne qualité. Pour alimenter le tout une batterie est également essentielle. Le choix des iles à était rapidement écarté puisque nous avons à notre disposition des batteries externe. Le but est donc de faire tenir l’ensemble de ces composants, finalement assez volumineux, dans la voiture. Il était évident que la « carcasse » en plastique original ne suffirait pas à contenir l’ensemble des éléments. Il sera donc nécessaire d’en modéliser une plus tard, sans doute imprimé en 3D (mais nous y reviendront plus tard). Pour ce qui est du maintien des différents composants, il fallait quelque chose de précis pour être fixer correctement sur l’emplacement confiné du châssis, rapide (nous ne pouvions pas risqué de perdre trop de temps via l’impression 3D par exemple), et surtout résistant au choc et stable face aux différentes vibrations engendrées par la voiture. Le choix d’utiliser la découpe laser était donc presque évident. Il est vrai que nous aurions pu choisir un bois résistant ou divers couche de contreplaqué. Finalement nous avons choisi par simplicité, de faire ce support en plexiglas épais de 6mm. Pour cela, on reprend les bonnes habitudes de Onshape pour modéliser les fichiers .dxf nécessaires à la découpe ! Le travail n’était pas très dur, mais assez fastidieux, et il fallait surtout être très rigoureux dans les mesures. Nous obtenu donc finalement un plaque aux mesures de la voiture, perforé pour recevoir l’arduino et la raspberry. La plaque possède également une encoche pour laisser passer éventuellement la nappe de la caméra de la raspi. Nous y avons ajouté quelques perforations pour laisser passer quelques câbles par la suite si nécessaire. Finalement, certains trous n’étant pas placés parfaitement ou étant oubliés, nous avons corrigés certaines perforations manuellement, à l’aide de la perceuse et d’un foret.

plaque de plexi schema

cache "bloc batterie"

Nous avions fait le choix de fixer les deux cartes arduino et raspi via un système classique de vis et d’écrous. Cela nous permettait d’utiliser les perforations déjà faites aux préalables sur les deux cartes. En revanche la batterie externe ne pouvant pas être percée, il nous fallait un système d’accroche plus proche de celui de l’encastrement. L’idée était donc de modéliser et d’imprimer en 3D, des sorte de « cache » dans lesquelles ont placerait les quatre coins de la batterie externes. Ces caches seraient quant à eux percés et fixés directement sur la plaque de plexi. Nous obtenions ainsi cette version finale à imprimer en quatre exemplaires.

plaque de plexiglas finale avec les cartes de contrôles fixées

Malheureusement après une première impression test, nous nous sommes aperçus que le la précision de l’impression laissait à désirer. Ce qui n’était pas acceptable dans notre cas. En effet, le fait de devoir imprimer une sorte de « boite », nécessitait soit l’impressions d’un support de non affaissement qui venait alors créer certaines bavures sur l’intérieur de la pièce, et donc laisser un certain jeu de battement, pouvant laisser s’échapper la batterie, ou même la rayer. Cependant sans ce support, la pièce était inclinée et donc pas exploitable non plus.

Semaine 2 (14-18 janvier)

Partie informatique

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.

Partie mécanique

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.

résultat final du mode de fixation de la batterie

coupe à suivre en découpe laser

Il nous fallait donc une nouvelle idée de fixation. Finalement, l’idée d’accumuler les découpe de plexiglas pour un faire une pièce volumineuse en 3D nous paraissait être une bien meilleure idée. Le hasard a en effet bien fait les choses puisque l’épaisseur de la batterie (15mm) était pile un multiple de l’épaisseur du plexi (3mm). De plus le tout parait bien plus propre et esthétique.

Nous avons juste pris soin de découper certaines branches pour pouvoir faciliter l’accès aux ports USB de la batterie. Nous avons donc un squelette global permettant de fixer nos trois pièces maitresses c’est-à-dire l’alim, l’arduino et la raspi. Le montage final ressemble à ceci.

Les pièces sont correctement maintenues et la plaque est fixable facilement sur la voiture sans encombrer les flans. De puis elle ne demande pas beaucoup d’espace nécessaire supplémentaire en comparaison à l’ancienne configuration.

Partie électronique

Finalement nous avons eu quelques soucis avec l’alimentation, que nous n’avons su expliquer. A chaque branchement, s’effectuait un reboot de la raspi mais s’en suivait rapidement une mise en arrêt. Nous n’arrivons toujours pas à comprendre l’origine du problème puisque le lendemain tout cela fonctionnait correctement. Nous soupçonnons un câble USB défectueux à l’origine de cet incident jumelé à un faux contact lors du branchement, et peut être aussi une batterie trop peu chargée. Cependant ce détail nous a fait perdre un peu de temps sur notre expérimentation. Le problème est cependant résolu, n’en parlons plus.

gaine thermique appliquée le plus proprement possible

alimentation de la raspi, version finale via pin 2 et 6

Nous arrivions facilement à alimenter la raspberry avec le port mini usb. Cependant notre câble était trop long. S’ajoute à ceci, le fait que le port mini usb est sur le flanc de la carte et donc élargit l’espace nécessaire latérale (car on le peut pas plier un câble usb à 90 degrés sans l’endommager sérieusement. De plus, le câble reliant la raspi à l’arduino (lui permettant par ailleurs de l’alimenter) prend déjà beaucoup d’espace. Aussi le volume disponible dans la carcasse de la voiture est assez limité. Pour gagner de la place et limité l’encombrement filaire, nous avons décidé de couper un de nos câbles USB de téléphone afin de pouvoir en dénuder le fil « plus » et la « masse ». Les câbles de transfert de données ne nous intéressent pas dans le cas d’une simple alimentation. Nous envisageons alors d’alimenter la raspi via les pins 2 et 6. Après avoir minutieusement dénudé les câbles concernés et soudé des pins à leurs extrémités, nous avions un système fonctionnel. Cependant le tout étant assez fragile, il nous fallait un système permettant de solidifier le tout. Pour cela nous avons suivi les conseils de Thierry qui nous a conseillé d’utiliser la gaine thermique qu’il avait à disposition. Le résultat final est plus que satisfaisant : propre et solide, parfait !

Pour ce qui est d’une éventuelle carte électronique, nous nous interrogeons sur la nécessité et le coté judicieux de cette dernière. En effet, reliant des pins très proches, nous ne savons pas si nous avons réellement besoin d’une faire notre propre circuit imprimé. Des soudures renforcées pour les pins devraient être suffisante. Nous reviendrons éventuellement sur la conception d’une carte électronique si il nous reste du temps en fin de projet, dans un souci de perfections de prototype final. Enfin, nous avons commencé une conception d’une coque profilé pour la voiture. L’ancienne n’est en effet plus fixable suite aux rajouts de la plaque de plexi. Et puis il faut avouer aussi que ça nous amuse de le faire ! Bon… cette première version est plus dans un but d’apprentissage des différentes fonctionnalités que nous offre onshape à vrai dire… Bien que le résultats ne soit pas rebutant, il ne constitue rien d’existant pour autant.

premier jet de la modélisatin de la coque de la voiture

montage final

Nous reprendrons la conception d’une nouvelle coque lorsque nous en auront le temps et lorsque nous auront un idée précise de ce que nous souhaitons concevoir. Ce n’est pas la priorité du projet pour le moment.

Semaine 3 (21-25 janvier)

Partie informatique

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.

Sans surprise, les premiers entraînements du réseau de neurones n'ont pas donné les résultats espérés. En effet, quelles que soient les données en entrées, les sorties du réseau convergeaient toujours vers une valeur constante. De plus, cette valeur n'était pas constante selon les entraînements, ce qui signifie qu'elle était issue de facteurs stochastiques. Nous avons donc tenté de mettre en place un autre réseau plus simple, et avons obtenu le même type de résultats. Après avoir longuement vérifié l'algorithme d'entraînement et s'être assurés que les données en entrée étaient bien différentes et correspondaient bien aux images, nous avons remis en cause la qualité des données en entrée. Après vérification, les images générées étaient très incomplètes et il nous était impossible de leur assigner manuellement une commande. Nous avons donc décidé de régénérer tout le jeu de données et passant plus de temps à comprendre le simulateur. Cela nous a également donné l'occasion d'y trouver quelques bugs et d'ouvrir une Issue sur Github. Les images générées cette fois étaient nettement plus intéressantes, et nous les avons à nouveau converties au format h5 pour les uploader sur Google Drive et les utiliser dans notre modèle Google Colaboratory.

Ce changement n'a pas amélioré la situation, et nous avons fini par trouver une piste de solution en fin de semaine. Cette dernière était liée au taux d'apprentissage utilisé pour l'optimisation du réseau, qui était trop élevé. En diminuant cette valeur d'un facteur 100, les valeurs en sortie n'étaient plus toutes similaires. Après divers ajustements du modèle et en augmentant le nombre d'époques de l'entraînement, nous avons enfin obtenu des résultats encourageants. Nous avons utilisé une métrique considérant les prédictions à +/-3 de la commande comme des succès et les autres comme des échecs. Avec un entraînement sur 2000 images et 30 époques, nous avons obtenu un score de 81% avec cette métrique. Ce n'est pas suffisant, mais étant donné la taille du jeu d'entraînement, cela correspondait à nos espérances. Nous avons donc lancé un second entraînement, cette fois sur un jeu de 20 000 images et 50 époques. Cet entraînement avait pour but de vérifier que le réseau ne faisait pas de sur-apprentissage ou ne se mettait pas à régresser après un certain nombre d'époques, ce qui peut arriver pour un réseau convolutionnel. A l'issue de l'entraînement, nous avons testé le réseau sur le même jeu de test que précédemment (2000 images) et avons obtenu un score de 90.25%. En assouplissant la métrique jusqu'aux valeurs à +/-5, ce score augmente à 94.5% et à 97% si l'on porte la valeur à 8. Ces résultats commencent à devenir très acceptables, cependant il reste visiblement des valeurs aberrantes qu'il nous faudra filtrer. On pourrait envisager un contrôle qui empêche à la voiture d'accepter des commandes trop contradictoires avec les précédentes. Par exemple, si la direction actuelle est de +20 et que le réseau retourne une valeur de -30, cette valeur serait soit ignorée soit moyennée avec la valeur actuelle.

La dernière chose que nous avons fait cette semaine était d'inclure le réseau de neurones dans l'algorithme sur la Raspberry Pi. Après un certain nombre d'ajustements, nous avons réussi à faire tourner le modèle. Cependant, à première vue il était capable de traiter environ une image par seconde, ce qui n'est évidemment pas suffisant pour conduire une voiture en situation de course. La semaine prochaine sera donc consacrée à trouver des optimisations pour faire tourner l'algorithme de façon plus performante. L'article de recherche DeepPicar cité précédemment en propose deux, que nous allons devoir essayer. Il y a probablement aussi certaines modifications à effectuer dans notre code pour l'alléger ou utiliser des API plus performantes. Même si nous aimerions l'éviter, il nous sera probablement nécessaire de nous orienter vers une architecture de réseau plus simple en sacrifiant un peu de performance au profit de la réactivité du système.

Partie mécanique

L’idée en début de semaine était de créer un support pour la caméra. Seulement après quelques essais sur une piste improvisée, nous avons constaté que la caméra offrait une vision trop étroite et restreinte de la piste. Il nous fallait donc une caméra grand angle. De plus la nappe à disposition est trop courte pour permettent une aisance des mouvements et des tests. Il nous en faudrait donc une un peu plus longue. Ces différents imprévus ont donc faits que nous devions prendre en considération une éventuelle marge d’erreur. Nous avons donc cherché de l’inspiration sur les différents sites de partage communautaire de fichiers .stl imprimables par une imprimante 3D. Nous étions donc partis pour s’inspirer du modèle suivant :

exemple de bras de support pour la caméra

emplcement potentiel de la caméra dans le par-buffle

Nous avions ensuite songé à éventuellement faire un prolongement de support via du pleglis découpé au laser. Mais cela était très vite limité par l’incapicité de cette méthode de créer des pièces complexes en 3D (le cumul des différentes couches d’épaisseur est rapidement insuffisant). Surtout que cette partie doit être la partie la plus fixe de la voiture, on ne peut pas se permettre que la caméra tremble lors de la mise en mouvement de la voiture.

Pourtant, après avoir longuement observé la voiture, nous avons remarqué un « trou » (volontaire de la part des designers de la voiture bien entendu) juste derrière le par-buffle, qui permettait de fixer la caméra très facilement. Ceci nous faciliterait vraiment le travail et rendrait en plus la caméra très discrète, tout en la protégeant de tout éventuel choc. Cependant, nous craignons que l’angle soit trop incliné et filme trop près de la piste, sans avoir une vision en profondeur correcte sur le reste de la piste. Nous n’avons actuellement aucun moyen de savoir si cette configuration sera fonctionnelle avec une caméra grande angle et une nappe plus longue. Nous décidons tout de même de supposer que cela sera suffisant. Si ce n’est pas le cas, nous modéliseront et imprimeront rapidement un nouveau support pour la caméra.

En attendant, nous avons décidé de reprendre un nouveau jet de la conception de la « coque » finale de la voiture. Après avoir regardé différents modèle existant dans la vraie vie, nous sommes tombés sur l’image d’un bus scolaire américain version 4x4. Comme cela n’avait aucun rapport avec quoi que ce soit dans notre projet mais nous a bien fait rire, nous avons décidé d’essayer de le reproduire.

second jet de la modélisation de la coque du bus 4x4

Nous n’avons pas encore terminé cette étape car elle demande beaucoup de précisions, de rigueur et de maitrise de Onshape. Ce que nous n’avons pas encore forcément. Cependant, notre création s’approche peu à peu du modèle original.

Enfin nous avons profité de ce léger temps d’ « attente de composants » pour mettre à jour notre wiki.

Semaine 4 (28 janvier - 2 Février)

Partie informatique

La priorité de cette semaine était de trouver un moyen de faire tourner notre modèle à une vitesse suffisante pour que la voiture puisse se conduire. En fin de semaine dernière et en début de cette semaine, nous avons essayé certaines optimisations suggérées dans l'article de recherche DeepPicar. Parmi ces dernières étaient notamment :

• Désactiver l'adaptation dynamique de la fréquence de la Raspberry Pi
• Utiliser l'ordonnanceur SCHED_FIFO avec priorité maximale
• Configurer PyTorch pour utiliser 4 threads pour les 4 coeurs du processeur.

Nous avons également amélioré le système de capture d'images en supprimant certaines synchronisations d'événements pour bloquer le moins possible les processus. Aucune de ces optimisations n'a donné des résultats miraculeux, et nous avons à peine atteint le cap des 2 images par seconde. Il nous faudrait un système 10 fois plus rapide pour espérer une conduite fluide. Deux solutions s'offrent alors à nous, et nous avons décidé d'explorer les deux. La première consiste à utiliser un autre backend en espérant de meilleures performances sur Raspberry Pi, en rappelant que nous avons compilé PyTorch nous-mêmes et que la librairie est probablement mal optimisée pour cette plateforme. En suivant l'exemple de pratiquement tous les participants à IronCar avant nous, nous nous sommes donc tournés vers TensorFlow et Keras. La seconde possibilité est de modifier et simplifier notre modèle en essayant de conserver les meilleures performances possibles. Ces deux solutions ne sont par ailleurs pas incompatibles, et un modèle plus simple sur un backend plus performant sera probablement notre résultat final.

Après une journée à essayer d'implémenter le modèle sur Keras, nous n'avons pas réussi à le rendre fonctionnel. Le modèle était exactement semblable, cependant Keras implémente une API de plus haut niveau qui nous empêche d'avoir un contrôle fin sur certains paramètres. Nous n'avons pas totalement abandonné l'idée de changer de Backend, car Keras a effectivement l'air beaucoup plus performant sur Raspberry Pi, cependant le temps de montée en compétence nécessaire a fait que nous nous sommes concentrés en priorité sur de nouvelles architectures. Par ailleurs, il existe des projets GitHub pour convertir un modèle PyTorch en Keras, que nous devrons tester dans la semaine. Nous avons donc essayé plusieurs modèles, que nous avons entraînés chacun sur 10 époques, et avons obtenu les statistiques de tests suivantes :

	Couches convolutionnelles	Couches fully-connected	Précision avec tolérance 3	Précision avec tolérance 5	Précision avec tolérance 8	Précision avec tolérance 10	Temps d'inférence du réseau
Modèle 1	(3->9) layers, 5x5, stride 2; (9->12) layers, 5x5, stride 2; (12->18) layers, 5x5, stride 2; (18->24) layers, 3x3; (24->32) layers, 3x3	(576 -> 50); (50 -> 10); (10 -> 1)	0.854	0.9155	0.951	0.958	0.078s
Modèle 2	(3->9) layers, 5x5, stride 2; (9->12) layers, 5x5, stride 2; (12->18) layers, 5x5, stride 2; (18->24) layers, 3x3; (24->64) layers, 3x3	(1152 -> 50); (50 -> 10); (10 -> 1)	0.8425	0.9185	0.955	0.9546	0.08s
Modèle 3	(3->9) layers, 5x5, stride 2; (9->12) layers, 5x5, stride 2; (12->18) layers, 5x5, stride 2; (18->24) layers, 3x3; (24->64) layers, 3x3	(1152 -> 100); (100 -> 50; (50 -> 10) (10 -> 1);	0.8735	0.9245	0.948	0.9535	0.08s
Modèle 4	(3->12) layers, 5x5, stride 2; (12->18) layers, 5x5, stride 2; (18->24) layers, 5x5, stride 2; (24->32) layers, 3x3; (32->64) layers, 3x3	(1152 -> 100); (100 -> 50; (50 -> 10); (10 -> 1)	0.818	0.902	0.938	0.9515	0.13s

La limite des 0.08s par inférence, soit environ 12.5 images par seconde, semble difficile à franchir même en mettant en place toutes les optimisations évoquées précédemment. Dans un premier temps, cette fréquence nous parait acceptable, sachant qu'elle risque d'être nettement améliorée si l'on parvient à convertir le modèle en Keras. Il nous faut maintenant choisir la meilleure architecture pour l'entraîner plus avant. La précision à 3 nous paraît une métrique secondaire, car une telle précision sur un réseau de neurones ne fait pas vraiment de sens. En nous concentrant sur les métriques supérieures, les modèles 2 et 3 semblent obtenir les meilleurs résultats. Après un nouvel entraînement sur 50 époques, la précision du modèle 2 monte à 0.8885 pour une tolérance de 3 et 0.932 pour une tolérance de 5. Le modèle 3 obtiens des résultats quasi-exactement similaires.

Le format ONNX est un format récemment créé dans le but de normaliser les représentation des réseaux de neurones entre les différentes librairies. Le format n'est pas encore complètement supporté par toutes les librairies, cependant PyTorch est capable d'exporter des modèles à ce format. La version 1.0.0 de PyTorch (nous utilisons la 0.4.1) nous permettrait d'exporter notre modèle et le réimporter dans TensorFlow par exemple. Cependant, nous pensons que le modèle n'est pas en cause et que le problème de l'entraînement avec Keras vient du reste du code (normalisation des données, optimiseur etc...).

Partie électronique

N'ayant pas encore reçu la caméra grand angle, nous n'avons pas retouché aux composants éléctroniques, qui était déjà fonctionnel la semaine dernière. Nous n'avons donc pas touché à la partie électronique du projet cette semaine.

Partie mécanique

"squelette" du car

La suite de la modélisation a en revanche été bien plus chronophage que prévue. Effectivement, la fonction "coque" sur onshape, qui permet de creuser une pièce en supprimant une des faces (dans notre cas la face inférieure), ne fonctionnait pas ou mal. La pièce du bus était sûrement un peu trop complexe pour cette fonction coque. Il est aussi possible que notre manière de designer le bus était non conventionnelle, ou non optimisée. Il est vrai que nous sommes finalement encore débutants sur ce logiciel. Toujours est-il qu'il a fallu creuser la pièce manuellement, en extrudant différentes formes, tout en veillant à ne pas créer de trou dans la carcasse à forme complexe. Bien que la tâche soit simple à comprendre, nous avons passé plusieurs heures sur cette étape... Heureusement, à force de perseverance, de rigueur et de minutie, nous avons enfin pu avoir notre "carcasse" finale, creuse et quasiment finalisée, comme ci contre, à gauche.

De plus, nous avons fait une erreur dans la manière de modéliser le car. En effet, la convention voudrait de faire différente partie (toit, arrière, capot,...) et de les assembler par la suite. Cela facilite les retouches, corrections, et surtout permet une impression 3D en plusieurs pièces, donc faciltée. Nous avons malheureusement fait tout en une seule et même pièce... Il a fallu donc faire une sorte de "fork" de la pièce unique, et la découper autant de fois que nous voulions une pièce partielle.encore une fois cette étape est dûe au fait que nous n'avions pas prévu ceci lors de la conception. On le saura pour la prochaine fois ! En attendant il a fallu tout découper pièce par pièce, et encore une fois, ceci n'est pas prévu à la base dans onshape. Nous avons donc perdu encore du temps à faire quelquechose qui aurait était très rapide si nous avions confectionné correctement le modèle.

assemblage virtuel avec la plaque de plexiglas

Et comme si tout cela ne suffisait pas, nous avions une coque de car trop petite... lors d'une simulation d'assemblage avec un modèle 3D de la plaque de plexiglas, celle ci ne pouvais pas s'encastrer dans le car ce dernier dernier était trop étroit. Il a donc fallu reprendre la pièce de base, creusée mais non séparée en différentes pièces, pour modifier l'échelle de manière non uniforme (si nous faisions ça de façon uniforme selon les axes x, y et z, la pièce finale aurait était bien trop grande (environ 70 cm de long pour 25 de haut). Nous avons donc finalement réussi à obtenir le résultat escompté, comme si contre à droite de l'écran. Et bien entendu une fois les échelles des différents axes enregistrés, nous devions recommencer l'étape de découpage en différentes pièces partielles. Tout le découpage précédent, n'étant pas aux bonnes dimensions, n'a donc servi absolument à rien. Enfin, toujours est-il que la modélisation est terminée (si elle est fonctionnelle une fois imprimée), c'est déjà ça.

Cependant, le plus compliqué reste à venir... l'impression en 3D. En effet, ceci constitue la pièce la plus garnde que nous ayons jamais imprimé dans nos petites vie ! Le "car" fait en effet une taille de 46 cm de long, 18 de large et 20 de haut ! Ces dimensions risquent d'être une calamité à imprimer. Effectivement, il suffit de constater le pourcentage d'erreur lors d'une impression de petite pièce. La plupart du temps il faut s'y reprendre à une ou deux fois avant d'avoir une impression "parfaite", sans bavure, et fonctionnelle pour notre projet. Alors imaginez avec un bébé de cette taille ... Nous nous sommes rapproché du fabricarium pour imaginer les différentes possibilités d'impressions. Comme anticipé, la pièce est bien trop grande pour une impression en 1 fois, et cela serait trop risqué pour imaginer un perfect du premier coup. Nous en étions conscient et c'est pour cela que nous avons "découper" notre car en différentes pièces.

Nous avons réservé plusieurs crénaux pour utiliser les différentes imprimantes 3D, mais cela risque d'être très long. Cependant nous gardons bon espoir d'avoir imprimé toute nos pièces avant la fin de la semaine, on croise les doigts !

notes (ne pas tenir compte de ce qui suit)

collé cable bleu imprimé logo polytech 3D missile ? peau banane ? néon ? 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