IMA4 2017/2018 P66

Présentation générale

Description

La coupe de France de robotique est un événement où des équipes doivent créer un robot autonome afin de réaliser un maximum de tâches données au préalable dans un cahier des charges. Pour ce projet, nous nous concentrerons sur la réalisation de sa base mobile lui permettant de se déplacer ainsi que son “cerveau” qui lui permettra de le contrôler.

Analyse du projet

Positionnement par rapport à l'existant

On se limitera pour cette comparaison aux robots qui visent le même but que le nôtre (à terme) : marquer des points pour les matchs de la coupe de France de robotique. En effet, la robotique est omniprésente dans nos vies maintenant, et il y a un nombre incalculable de bases mobiles existantes, avec différentes caractéristiques : avec des moteurs pas à pas, asservies, rapides, puissantes, capables de se déplacer sur différents terrains… Et ne parlons pas des systèmes de contrôles.

Il y a approximativement 200 participants à l'événement, et donc presque autant de systèmes similaires au notre développés ou en train d’être développés. Cependant leur détails de conceptions sont jalousement gardés par les équipes. On fera donc notre études sur les robots de l’année dernière. On prendra le robot fait par Robotech Lille et celui fait par une autre équipe finaliste, Robotech Legends.

Analyse du premier concurrent

Le robot de l'année dernière en situation

Pour progresser il faut apprendre de ses erreurs. C’est pourquoi regarder en quoi le robot de l’année dernière n’a pas été un franc succès nous paraît judicieux pour pouvoir faire quelques chose de plus performant cette année.

L’erreur qui nous avait été fatale l’année dernière était le manque de qualité du contrôleur moteur. Réalisé avec la graveuse numérique de Polytech et non verni, son ancienneté aura eu raison de lui. De plus, on peut constater quelques défauts d’optimisation : le driver L298 sur la carte peut supporter le contrôle de deux moteurs mais n’en contrôle qu’un seul à la fois. La fonction de freinage est rendue inaccessible par le design de la carte. La solution que nous proposons est simple : créer une nouvelle carte, qui sera vernie pour pouvoir tenir plusieurs coupes.

La carte de puissance avait été réalisée de la même façon, et était beaucoup plus grande que nécessaire. Elle risque de d’avoir le même sort que son congénère. La solution que nous proposons est la même que précédemment, refaire une nouvelle carte plus optimisée et vernie.

L’asservissement en position du robot était aussi dérisoire (heureusement, nous n’avions pas eu à l’utiliser). Seule un encodeur sur deux était utilisé, et seule une des deux sorties de l’encodeur était considérée. De plus le fonctionnement de l’Arduino récupérant les données pouvait parfois faire en sorte qu’un front pouvait être négligé. Pour pallier à ça, on utilisera un FPGA, qui permettra de faire tourner autant de processus en simultané que l’on désire sans qu’ils n’interfèrent entre eux.

De plus, l’utilisation seule des encodeurs n’autorise pas les dérapages (même légers). Pour pallier à ça, on utilisera une centrale inertielle comme seconde source pour récupérer la position du robot.

Enfin, un souci assez récurrent que l’on a rencontré est la difficulté à modifier un programme dans un des processeurs du robot. Il fallait pour cela rapprocher son ordinateur du robot, déplacer la carte de son logement, et la brancher (en prenant le risque de déloger un autre composant au passage). Pour améliorer le processus, on fera en sorte que le Raspberry Pi puisse être mis à jour via une communication sans fil et puisse mettre à jour les autres cartes (Arduino, FPGA) à son tour. Cela permettra d’éviter de perdre du temps à rebrancher des composants.

On remarquera que le choix du matériel n’étais pas tellement un problème l’année dernière, ce dernier se situant plutôt de la manière dont il a été utilisé. C’est pourquoi on peut se permettre d’améliorer sans pour autant trop changer ce qui nous est disponible au départ.

Analyse du second concurrent

Regardons désormais ce qui se fait chez le voisin. Nous avons choisi cette équipe parce qu’elle nous a parlé des méthodes qu’elle a utilisé tout en faisant un bon score.

Cette équipe utilisait un moteur pas à pas afin d’éviter d’avoir à utiliser des encodeurs. Cependant, le caractère discret de la rotation du moteur rajoute un phénomène de glissement, qu’il est difficilement possible de calculer. Pour réduire ce phénomène, nous utilisons des moteurs à courant continu, et nous récupérons leur rotation à l’aide d’encodeurs. Un régulateur PID permet alors de réduire les variations de vitesse trop brusques.

Ils avaient un système de LEDs pour pouvoir savoir où en était le robot dans son programme, et ainsi faciliter le débogage des programmes. Pour reprendre ce principe et l’améliorer, on enregistrera toutes les informations que le système puisse obtenir, et on les transmet par liaison sans fil pour un débogage encore plus simple.

Enfin, ils utilisaient des microcontrôleurs STMicroelectronics pour tout le contrôle du robot. Bien que ces cartes soient très puissantes, elles embarquent un système d’exploitation multi-tâches. Cela simplifie énormément l’étape de programmation, cependant le multi-tâche rajoute de la latence pour les entrées sorties, et perd donc en précision. À la place, nous utiliserons trois puces (deux micro-contrôleurs et un FPGA) plus ou moins complexes parfaitement adaptées à leur tâche. On pourra aussi se vanter d’avoir un robot totalement open-source. Ces puces seront chargées avec le strict minimum pour répondre aux contraintes du cahier des charges, ni plus, ni moins.

Certes, certaines de ces “améliorations” ne sont pas nécessaires pour l’accomplissement du cahier des charges et/ou du défi. Les autres méthodes que nous n’utilisons pas peuvent être “suffisantes”, preuve en est, cette équipe est arrivée en finale alors que d’autres équipes avec des techniques similaires aux nôtres sont arrivées bien plus bas. Mais où est le challenge si on se contente du fait que ça fonctionne ?

Scénario d'usage du produit ou du concept envisagé

Notre robot (vue d'artiste)

Le scénario d’usage voulu serait de jouer et de remporter un match de la coupe de robotique. Cependant, cela ne pourra être atteint sans un travail hors contexte de ce projet, donc voici un scénario type utilisant toutes les éléments que nous aurons eu à réaliser pour ce projet.

Lorsque l’on appuie sur un bouton du robot, il doit se déplacer en suivant un trajet prédéfini ou aléatoire sur un terrain plat. Ce terrain peut être composé de différentes matières. Il possède des mur et des obstacles, si ces derniers se trouvent sur le trajet du robot, ce dernier émet un signal (sonore ou lumineux) et change de trajectoire. Il doit à terme revenir à sa position exacte de départ, avec une faible dérive même en étant passé sur sur des surfaces différentes. Des robots utilisant des capteurs similaires à ceux utilisés par le robot peuvent être disposés sur le parcours, ils doivent être évités mais ne pas faire de faux positifs liés aux interférences. L’utilisateur peut alors se connecter au robot via une communication sans fil et récupérer les journaux de fonctionnement du robot pendant son parcours.

Réponse à la question difficile

Nous n'avons pas eu de questions difficiles lors de la séance de présentation.

Préparation du projet

Cahier des charges

Le robot (du moins la partie du robot sur laquelle nous travaillons) devra répondre aux contraintes suivantes :

• Se déplace en suivant un parcours. Sur une piste de 2m×3m en PVC (type bâche adhésive décorative pour sol).

• Est capable de savoir où il est. On s'autorise une dérive de 1mm pour 5m de déplacements. Ces 5 mètres correspondent à la distance que parcourra le robot durant un match. Une précision de 1mm est nécessaire pour réaliser les actions.

• Évite les obstacles à l’avant et à l’arrière. Le parcours à réaliser est statique, cependant une protection basique contre les imprévus (autres robots) est nécessaire.

• Résiste aux interférences causées par d’autres capteurs de distance de même type. Il y aura d’autres robots présents sur la piste, et certains d’entre eux pourront utiliser les mêmes capteurs que nous utilisons. Il faudra donc faire en sorte que les interférences ne perturbent en rien le bon fonctionnement de notre robot.

• Est facilement débugguable. Après la réalisation du robot dans le cadre du projet, il passera dans une longue phase de test pour s'assurer du bon fonctionnement des actions qu'il est censé réaliser. Afin de faciliter et accélerer cette phase, on aimerait plusieurs choses du système de contrôle du robot. Il devra démarrer rapidement, utiliser le minimum de ressources nécessaires, et pouvoir être mis à jour et débuggué via une communication sans fil.

• Pouvoir interagir avec l'utilisateur. Une fois sur le chemin de compétition, le robot n'aura plus l'aide d'un ordinateur pour pouvoir communiquer avec l'utilisateur. L'utilisateur doit toutefois pouvoir effectuer des tâches simples (saisir la zone de départ, l'équipe, la stratégie...) et contrôler l'état du robot (batterie, calibrage...).

• Est conforme au cahier des charges de la Coupe de France de Robotique 2018 en tant que robot principal. Disponible ici, il fixe entre autres des conditions sur les dimensions du robot et sur le type de matériel qu'il peut embarquer.

• Réutilise le matériel disponible. La création depuis zéro d’un tel robot est largement hors-budget pour un projet IMA4. On utilisera au maximum le matériel mis à disposition par Robotech pour minimiser les dépenses.

• Dispose une alimentation 9 V. Sera utilisé pour les actions du robot hors projet.

Choix techniques : matériel et logiciel

Matériel

Alimentation

• Batterie Lipo 4S. Dans son sac inifugé.

• Carte de puissance. Dimensionnée en fonction des éléments et imprimée à Polytech.

Déplacement

• Support mécanique & Roues. Utilisées pour l'édition de l'année précédente.

• 2 × Faulhaber MOTOR 3557K024CS. Moteur à courant continu.

• Contrôleur moteur. Dimensionnée pour nos besoins et imprimée à Polytech.

Connaissance de l'environnement

• 2 × HEDM-550X. Encodeur rotatif pour l'asservissemnt.

• Capteur MinIMU-9 v3. Centrale intertielle utilisée en complément pour l'asservissement.

• X × Capteurs ultrasons / infrarouges. Pour détecter les robots environnants.

Contrôle

La commande et le controle du robot sera géré par 3 puces différentes :

• MicroNova Mercury FPGA Development Board. Ce FPGA sera utilisé pour les tâches nécessitant une faible puissance de calcul mais un parrallélisme un une très grande réactivité. Entre autre, il récupèrera les valeurs des codeuses des moteurs et s'occupera des l'asservissement des roues à l'aide d'un régulateur PID.

• Arduino MEGA 2560. Utilisé pour les tâches nécessitant une bonne réactivité mais une puissance de calcul un peu plus élevés. Il s'occupera de s'assurer du bon déroulement de l'action en cours (avancer, pivoter...). Il gèrera notamment les différents capteurs d'obstacles.

• Raspberry Pi 3. Utilisé pour les tâches n'ayant pas besoin d'une grande réactivité mais d'une grande puissance puissance de calcul. Il s'occupera de garder l'état du robot dans sa mission et de décider de ses prochaines actions. Il sera aussi utilisé pour toutes les actions de débug, sauvegarde et mise à jour des autres puces.

Interface humain-machine

• Écran LCD SPI. Pour afficher des informations à l'utilisateur.

• X × Boutons. Pour laisser l'utilisateur choisir des paramètres.

Logiciel

Systèmes d'exploitation

• Buildroot. Système d'exploitation à configurer et compiler pour le Raspberry Pi. Complètement customisable et permet donc une grande legerté et flexibilité pour les tâches requises.

• FreeRTOS. Système d'exploitation temps réel pour l'Arduino Mega 2560. Choisi pour simplifier les choses étant donné qu'on l'a déjà vu en TP de temps-réel.

Asservissement

• Régulateur PID. Asservissement encodeur → moteur à courant continu (direct).

• Filtre de Kalman / Fusion de données. Asservissement encodeur + IMU → informations sur l'emplacement du robot sur le terrain.

Conception cartes électroniques

• Eagle
• Altium

Liste des tâches à effectuer

Optionnel

• Concevoir contrôleur moteur avec transistor de puissance Electronique (Amaury)
• Filtre de Kalman Arduino (Geoffrey)
• Enlever le flag -D de avrdude Arduino (Geoffrey)
• PID polaire (Geoffrey)
• ⇑Buildroot 2018.02 Raspberry Pi (Geoffrey)
• Buildroot en AArch64 Raspberry Pi (Geoffrey)
• PID FPGA FPGA (Geoffrey)
• Couche niveau 3 et TxD/RxD Arduino Raspberry Pi FPGA (Geoffrey)
• Alléger noyau Linux (encore) Raspberry Pi (Geoffrey)
• Wi-Fi direct ? Raspberry Pi (Geoffrey)

À faire

• concevoir carte de puissance Electronique (Amaury)
• Établir protocole communication entre appareils Wiki FPGA Raspberry Pi Arduino (Geoffrey)
• concevoir schematic LMt18200T Electronique (Amaury)
• concevoir controleur moteur avec Lm 18200t sur eagle Electronique (Amaury)
• commande matériel électronique de puissance Electronique Arduino (Amaury)
• tester contrôleur moteur TLE 5206-2 e Electronique FPGA Arduino (Geoffrey, Amaury)
• tester contrôleur moteur LM 18200T Electronique Arduino FPGA (Geoffrey, Amaury)
• PID Arduino Arduino (Geoffrey)
• Analyse interference capteurs Arduino (Amaury)
• Gestion des liaisons séries par FreeRTOS Arduino (Geoffrey)
• Afficheur & Boutons Raspberry Pi
• Programme chef Raspberry Pi
• concevoir schematic carte de puissance Electronique (Amaury)
• Multi-ADC FPGA (Geoffrey)
• acheter composant carte de puissance Electronique (Amaury)
• faire mail Mr Flamen pour bornier, and capacitor Electronique (Amaury)
• Expliquer Geoffrey IMU Arduino Electronique FPGA (Amaury)
• IMU sous free RTOS Arduino (Amaury)

En cours

• modification V2-> V3 tle5206 Electronique (Amaury)
• vérifier typon capa 100uF --> dimension étrange Electronique (Amaury)
• changer bornier 5206 Electronique (Amaury)
• IMU sur FPGA: voir si c'est judicieux FPGA Arduino (Geoffrey, Amaury)
• IMU test faisabilite sur IDE arduino Arduino (Amaury)
• commande composant complément pour 5206 Electronique (Amaury)

À rédiger

• dimensionner tout les besoin carte de puissance Electronique (Amaury)
• Upload Pi → Arduino Raspberry Pi Arduino (Geoffrey)
• Upload Pi → FPGA Raspberry Pi FPGA (Geoffrey)
• Dépot git FPGA Arduino Raspberry Pi (Geoffrey)

Terminé

• Liste de matériel Wiki (Geoffrey, Amaury)
• rédaction correction V2 Mr Flamen Electronique Wiki (Amaury)
• Choix techniques Wiki (Geoffrey)
• Tester l'IMU Arduino FPGA (Geoffrey, Amaury)
• concevoir V0 contrôleur moteur avec TLE 5206-2 Electronique (Amaury)
• IMU documentation Wiki Electronique Arduino (Amaury)
• Script pour générer la feuille d'heure Wiki (Geoffrey)
• Codeuses FPGA (Geoffrey)
• Faire fonctionner la liaison série Raspberry Pi (Geoffrey)
• Tenter sauvetage module Wi-Fi Raspberry Pi Raspberry Pi Electronique (Amaury)
• Rajouter des illustrations Wiki (Geoffrey)
• Tester FPGA Robotech FPGA (Geoffrey)
• tester moteur pour propulsion des balles --> caractérisation technique indispensable pour la carte de puissance Electronique (Amaury)
• Rectifier le modèle de FPGA Wiki (Geoffrey)
• Faire fonctionner Wi-Fi Raspberry Pi (Geoffrey)
• commande matériel contrôleur moteur Electronique Arduino (Amaury)
• Base freeRTOS Arduino (Geoffrey)
• prendre en compte recommandations Mr Flamen sur V0 Electronique (Amaury)
• Travail prologue à documenter Wiki (Geoffrey)
• OS Raspberry Pi Raspberry Pi (Geoffrey)

Réalisation du Projet

Feuille d'heures

Tâche	Prlg. 30/10	Prlg. 6/11	Prlg. 13/11	Prlg. 20/11	Prélude 8/1	S1 15/1	S2 22/1	S3 29/1	S4 5/2	Total
Analyse et préparation	2			8						10.0
Prise en main FPGA et tests		5.5	1	0.5						7.0
Rédaction wiki						2	2.5	4	3	11.5
Système Raspberry Pi						3	7			10.0
Routage contrôleur moteur	3					9	3	1	2	18.0
Routage carte de puissance					0.5	0.5	0.5		0.5	2.0
Autre							0.5			0.5
Analyse et implémentation des capteurs								2	2.5	4.5
Nettoyage & Consolidation									3	3.0

Prologue

Codeuses, Arduino & FPGA

Pour connaitre la rotation des roues du moteur pour l'asservissement, on utilise des codeuses de référence HEDM-550X. Chacune de ces codeuses disposent de deux sorties tout ou rien, nommées A et B, dont la sortie en fonction de la rotation de roue évoluent comme ci-contre.

Pour un tour de roue, il y aura 1024 périodes du signal. On peut donc connaitre la rotation de la roue en comptant le nombre de fronts montant d'une des sorties, à condition que la roue tourne dans un sens. On peut s'affranchir de cette condition et connaitre le sens de rotation de la roue, en regardant l'état de B lors d'un front montant. Pour utiliser pleinement les capacités que nous propose les codeuses, on considèrera les différents fronts de chaque entrée, soit 4 fronts par périodes.

Faisons un rapide calcul. Les roues de nos moteurs font 4 cm de diamètre, et rouleront à un maximum de 10 km/h, soit un maximum de 11 tours par seconde, ce qui représente un maximum de 45270 fronts par seconde (pour une roue), ou une définition de 0,06 mm.

Cela représenterait une interruption toutes les 22 µs, ce qui fait beaucoup pour un Arduino. C'était ce que nous avions essayé lors de l'édition précédente de la coupe, en ne comptant que les fronts montants d'une seule sortie, le sens étant récupéré d'après l'ordre donné au moteur, et la seconde roue a été considérée mécaniquement symétrique à celle comptée. Autant vous dire que ni les performances de l'Arduino ni la précision de la mesure n'étaient au rendez-vous.

L'utilisation d'un FPGA en réponse à ce problème est donc totalement justifiée, ce dernier fonctionnant à 100 MHz, il peut largement gérer tous les fronts de la codeuse.

Semaine 1

Dimensionnement de la carte de puissance

Electronique de puissance Nous utiliserons comme source d'énergie une batterie Lipo 4s délivrant 14.8V. Voici l'ensemble des consommateurs constituants le robot :

Arduino MEGA:

• consommant 500mA avec une tension d alimentation recommandé de 7 à 12V ou par USB de 5V mais cette option est peu recommandé car elle peut entraîner des manques de stabilité dans le fonctionnement du microcontroleur et dans la qualité du 5V données par les broches.

Raspberry Pi 3:

• consommant 2.5A avec une tension d'alimentation de 5V.

Moteur déplacement:

• consommant 3A chacun au maximum de leur utilisation nominal cependant ils s'avèrent surdimensionné pour notre usage. Empiriquement leur utilisation étaient plutôt de l'ordre de 1.5 maximum.

La tension nominal est de 24V nous pouvons donc les alimenter en 12V tout en maintenant une bonne qualité de pilotage. Cependant on choisira de garder l'alimentation du contrôleur moteur en 24V afin de laisser pour les années à venir le choix aux futurs équipes.

FPGA Spartan 6

• Consommant au grand maximum 1A à une tension d'alimentation de 5V.

Moteur pour les actions du robot, les actions a proprement parlé n'ont pas encore toutes étaient parfaitement déterminé ce cahier des charges est donc amenés à évoluer dans les semaines à venir :

• usage d'un moteur DC alimenté en permanence. Après avoir réalisés différents tests via une alimentation réglable et en mesurant le courant nous nous sommes arrêtés sur le wk-ws-20-002 qui est un motor brushless tournant jusque 3200tr/min pour une tension d'alimentation de 10V maximum et un courant de 1A.

Remarque : cette décision est à faire valider par le reste de l'équipe participant à Robotech, elle sera soumise à la réunion du jeudi suivant. référence : https://www.xheli.com/walkeramotor-180l.html

• 1 moteur pas à pas faible puissance comme le Moteur 28BYJ-48-5 (probablement alimenté et contrôlé par l'arduino via une carte ULN2003)
• 2 servomoteur ( piloté et alimenté par l'arduino), on parle ici probablement de Servomoteur HSR-1425CR Hitec et du Rs-901 mgbb

Dimensionnement du contrôleur moteur avec pont en H intégré

Caractéristiques demandées : - alimentation au moins en 12V minimum et 24V maximum - sortie en 24 V maximum avec 3A de courant par moteur (donc x2) - dimensions réduites - capacité à être réparé/remplacé facilement lors de la Coupe de France - optionnel: protection intégré contre les retours de courants et les courts circuits

Lors de nos recherches nous avons trouvés les 3 commposants suivants  : L298 - LM 18200T - LM 18201T - TLE 5206-2

Le L298 offre un courant de 4 A maximum donc il ne permet pas de contrôler les deux moteurs en même temps il est donc d'office éliminé les 2 LM offrent un courant de 6 A en pilotant deux moteurs, ils ne sont pas très différents l'un de l'autre à part un prix plus élevé pour le 01 alors qu'il ne possède pas de capteur de courant. De toute façon nous n'avons pas prévu d'utiliser cette fonctionnalité.

le TLE 5206-2 est bien plus simple de fonctionnement et offre moins de services que le LM18200T, il permet donc également une simplicité de routage et de modularité mais il ne permet de piloter qu'un seul moteur. Le LM18200T permet lui un pilotage plus précis des moteurs avec des capteurs de courants et de températures intégrés mais la densité des pins rend plus complexes le routage et les réparations de dernières minutes lors de la compétition.

Notre choix s'arrête donc sur la conception dans un premier temps du contrôleur avec les TLE 5206-2 en deux pcb isolés, puis du LM18200T qui pilotera les deux moteurs à lui tout seul.

Pour la suite nous réaliserons nos PCB sous eagle. TLE5206-2 réalisation du schématic :

• • insérer photo**

FreeRTOS pour Arduino

L'Arduino du robot doit gérer plusieurs tâches à la fois, telles que : la gestion de l'asservissement, des capteurs, l'envoi des données de déboguage... Pour cela, l'utilisation d'un ordonnanceur est inévitable. On aura probablement besoin de sémaphores pour (entre autres) la gestion des ports série et des variables communes aux taches (celles concernant la position du robot notamment).

Nous avons choisi d'utiliser le système d'exploitation temps réel FreeRTOS pour deux raisons. La première est qu'il est très léger, et n'embarque pas plus que ce dont nous avons besoin. La deuxième est que c'est le système que nous avons utilisé dans les TP de l'enseignement Temps Réel, nous avons donc déjà un peu d'experience dans le domaine. La configuration de FreeRTOS pour un hôte Linux et une cible Arduino Mega 2560 nous a été fourni par M. Forget.

Buildroot pour Raspberry Pi

Le Raspberry Pi est le composant qui décide et envoie les ordres de déplacement à l'Arduino et au FPGA. Même s'il n'a pas besoin d'autant de réactivité que ses confrères, il est souhaitable que dès qu'il reçoit l'information que l'ordre précédent a été réalisé (et ses conditions de réalisation), il calcule et et envoie l'ordre suivant dès que possible.

Le problème d'un système d'exploitation de bureau est qu'il y a un certains nombre de services pour simplifier la vie de l'utilisateur tels que l'indexation des fichiers, la découverte réseau, le pare-feu, la vérification des mises à jour... Nous pouvons difficilement contrôler ces tâches, et si notre robot a besoin de la puissance de calcul de la carte quand le système réalise ces tâches plus ou moins inutiles dans notre cas, le temps de réponse pourrait augmenter. Sur une application comme la notre où le temps est compté, cela peut avoir une influence (elle est très probablement minime dans notre cas, mais on choisira de ne pas la négliger).

Répartition de la taille du système d'exploitation

Nous allons donc utiliser un système d'exploitation alternatif conçu uniquement les fonctionnalités dont nous avons besoin. Notons que le cahier des charges nous impose de pouvoir utiliser le Wi-Fi et de pouvoir mettre à jour le système des autres cartes, et on souhaitera pour cela utiliser des outils pré-existants. On n'utilisera donc pas un système type FreeRTOS. Notre choix se portera sur Buildroot qui est un utilitaire qui permet de construire des images de système d'exploitation sur base de noyaux Linux en sélectionnant les options et programmes via un simple fichier de configuration. Le système nous propose aussi de créer nos propres programmes et s'occupe lui-même de la cross-compilation, ce que l'on utilisera pour le(s) programme(s) régissant la logique du robot. La compilation des programmes étant faite sur une machine hôte (et non sur la machine cible, ici le Raspberry Pi), cela nous permet de réduire les temps de compilation. Cela sera particulièrement utile lors des phases de test du robot.

Après ~45 minutes de compilation, une image d'une soixantaine de Mio contenant notre système d'exploitation est générée. Le système démarre en une poignée de seconde, et en idle ne consomme qu'une dizaine de Mio de RAM et il n'y a que très peu d'activité sur le CPU. Toutes le reste des ressources sont alors disponibles pour notre utilisation. Seul bémol, devoir reflasher la carte à chaque modification du système (le programme étant inclus) est assez lourd. On décrira une solution à ce problème dans une prochaine section.

Semaine 2

Mode production / Mode debug

Lorsque le robot sera assemblé, il pourra être fastidieux de brancher un câble à l'interieur pour pouvoir mettre à jour les différentes cartes possèdant une mémoire (Raspberry Pi, Arduino et FPGA). D'autre part, après notre projet terminé, le robot sera transferé à Robotech qui s'occupera d'ajouter des actionneurs pour mener à bien sa tâche pour la compétition, et qui testera le robot. Il va donc falloir mettre à jour les programmes un nombre important de fois.

C'est pour cela qu'a été instauré la contrainte de pouvoir mettre à jour la mémoire des cartes via une communication sans fil. Nous avons choisi d'utiliser une communication Wi-Fi, car elle est simple à mettre en place, et elle permet d'utiliser le protocole SSH qui nous semble le plus simple à configurer pour déboguer. La simplicité est ici de mise, ce n'est pas une section critique du fonctionnement du robot donc si la méthode utilisé pour le déboguage n'est pas la plus performante, ce n'est pas un problème. De plus, l'utilisation d'un protocole très connu et bien testé nous évitera les complications.

Cependant, pour assurer que le Raspberry Pi se lance en un minimum de temps lors de la compétition, on s'assurera de charger uniquement ce qui est nécessaire. Les outils de debug, la connexion Wi-Fi ne seront activées que lorsque deux broches du Raspberry Pi sont court-circuitées. La vérification sera faite à la dernière étape de lancement à l'aide du binaire testpin, qui prend comme argument deux numéros de pins selon la bibliothèque Wiring Pi.

Raspberry Pi 3 : Réparation de la puce Wi-Fi interne

Nous avons constaté durant la semaine précédente que le wifi ne fonctionnait plus. Après avoir éliminé une possible source software nous avons voulu vérifier qu'aucun court-circuit n'était présent sur la carte, elle a donc été nettoyé avec du flux en C201. Le problème a persisté. Par curiosité nous avons mesuré la tension d'alimentation de la puce wifi, elle est de 1.34 V. Or la datasheet du constructeur nous a indiqué que la tension d'alimentation de cette puce doit être comprise entre 3 et 5V. Il semble donc que le problème se trouve au niveau de la carte de puissance. Le Raspberry Pi n'étant pas open hardware (et la possibilité d'une réparation assez faible, vu la taille et la protection des pistes), nous avons arrêté là nos investigations et installé un dongle wifi USB.

Raspberry Pi 3 : Mise en fonctionnement du Wi-Fi

Sur un système d'exploitation classique, il suffit généralement de brancher un dongle Wi-Fi pour faire en sorte qu'il fonctionne. Pour fonctionner, un dongle Wi-Fi (comme beaucoup d'autre périphériques) a besoin d'un firmware, c'est à dire un petit bout de code qui est chargé sur le matériel depuis par le noyau afin qu'il puisse fonctionner. Or, dans notre système d'exploitation à la carte, celui pour notre dongle Wi-Fi n'est pas installé par défaut, il a donc fallu le faire compiler. Ensuite à l’exécution, il faut charger le module correspondant au dongle via un `modprobe`, car il n'est pas chargé automatiquement par le système lors de l'insertion (cela nécessiterait un démon supplémentaire). À partir de là, l'interface `wlan0` est fonctionelle et on peut potentiellement se connecter à un réseau Wi-Fi.

Donc a priori, si on crée un fichier `/etc/network/interfaces` comme nous avons vu en TP de réseau et qu'on lance un `ifup wlan0` cela devrait fonctionner non ? Pas tout à fait. Il s'avère que la commande `ifup` inclue dans notre système (fournie par la boîte à outils BusyBox) n'est pas aussi complète que celle dans l'OS Raspbian utilisé en TP et ne gère pas les instructions `wpa-*` du fichiers `interfaces`. Pour parer à cela, il suffit d'appeler `wpa-supplicant` directement, qui est le programme qui s'occupe (même sur Raspbian) de l'authentification au réseau Wi-Fi. On peut ensuite utiliser `ifup` pour la configuration IP.

Après un rapide test de ping, on installe (enfin plus précisément on dit à Buildroot de compiler dans l'image, puisque le système n'a pas de gestionnaire de paquets) un serveur SSH sur la machine, et on met en place un petit système afin que les la clef privée et l'empreinte de la clef du client soient sur le Raspberry Pi afin de se connecter simplement et rapidement à la machine.

Conception de la carte de contrôleur moteur TLE5206

Intérêt de ce contrôleur: Ce contrôleur très bon marché, 4€ pièce, permet de contrôler un moteur jusque 5A avec un pique de courant de 6A et une tension d'alimentation allant jusque 40V.

Limite :

- Le pique de courant accepté n'est que de 100ms, ce qui peut être court si nous voulons avoir un déplacement agressif lors de la compétition.
- Il possède assez peu de protection, en regardant la datasheet on voit qu'un grand nombre de court circuit possible n'est pas couvert par le système de protection ni par l'indication de flag. Le plus problématique pouvant être le fait de ne pas détecter un court circuit au niveau du moteur pouvant entrainer des dommages à celui-ci. Le moteur est l'élément le plus cher de notre robot et il n'est pas envisageable de les perdre.

Conception du schematic:

La conception du schematic a été faite sur Eagle après avoir suivi plusieurs cours en ligne pour se former au logiciel.

schematic pour le contrôleur TLE5206

Conception du routage:

Le routage finale est le suivant :

Routage pour le contrôleur TLE5206

Retour de Mr Flamen : retour 1 : pistes trop étroites --> utilisez l'application Electrodroid pour les choisirs supprimer les anglais aigus mettre les composants de puissance en bordure de PCB pour permettre l'installation d'un dissipateur.

Semaine 3

Conception de la carte de contrôleur moteur TLE5206

retour 2 : (rendez-vous du lundi 29/01) Nous sommes revenus sur plusieurs points au niveau de la conception du circuit :

Explication sur la CEM dans les circuits : les angles à 90° sont à éviter mais pas forcément à proscrire surtout si l'on ne se trouve pas à haute fréquence les angles très aigus (inférieurs à 45° ) et ceux supérieurs à 135° sont à éviter autant que ceux à 90°. Il faut également essayer de garder le même angle entre des pins parallèle afin d'optimiser l'espace et les fraises.

piste non parrallèle

En effet en cas d'angle très aigus (comme ceux formés par une connexion en arc de cercle avec une ligne droite) la jonction entre les deux forment un angle très aigus que la fraiseuse va devoir usiner avec des fraises très spécifiques coûtant souvent plus cher que la machine. De plus il s'agit d'une "good practice" à garder si l'usinage des cartes est chimique car il peut favoriser une collection d'acide entraînant des "grignotage" sur la carte pouvant altérer son fonctionnement.

Texte sur le circuit : l'ajout d'annotations gravées sur le circuit directement est fondamentale, il permet d'éviter les erreurs de branchements et permet de garder un contrôle des versions sur les PCB. Par rapport à la version 2 il faut l'ajouter au format tdocu dans CAM afin d'avoir le "négatif" de ce qui a été fait en V2. De cette façon on économise en temps de conception et en usure des fraises.

DRC : Il faut modifier dans le DRC la copper dimension afin de la fixer à 4mm.

Divers:

*Faire attention avec le plan de masse à ne pas laisser des zones trop étroite, cela pourrait engendrer des échauffements.
*attention au trous de fixation , il faut prendre en compte la tête de la vis : pour ce simplifier la vie on utilisera Drill 3 qui la prend en compte sur le PCB contrairement à Hole qui se contente de faire un trou.

MinIMU-9 v3

intérêt de l'IMU dans le cadre du projet : L'inertial Measurement Unit (IMU) est un PCB embarquant avec lui un gyroscope, un accéléromètre et un compas. Dans le cadre de notre projet où nous voulons pousser le robot aux limites de ses capacités d'accélération afin de diminuer nos temps de déplacement lors de la compétition. Nous nous exposons de ce fait à des risques de dérapages des roues sur le terrain, ce que les codeuses ne seront pas capable de percevoir. C'est la qu'entre en jeu l'IMU en fournissant une indication sur le déplacement spatial du robot. En cas de manque d'incohérence constaté entre les codeuses et lIMU nous serons capable de déterminer la présence d'un dérapage et donc de le corriger.

Notre IMU embarque le gyroscope L3GD20H et un accéléromètre - magnétomètre LSM303D.

tests préliminaires : nous utilisons cette IMU. A l'aide de la documentation fournit par Pololu nous nous sommes assurés du câblage et avons pu nous renseigner sur la communication I2C et les différentes possibilités de l'IMU.

Pour le test préliminaire nous avons utilisé les codes fournis par Pololu ici.

Les constatations directs qui peuvent être apportés en observant 3 paramètres : le yaw, le pitch et le roll sont les suivantes :

illustration du yaw

voici une illustration pour comprendre le yaw le pitch et le roll :

illustration des 3 composantes

ici on voit que pour un passage brutale d'angle de la position verticale à horizontale on obtient un pic négatif important (50% de la variation réelle). Cependant il reste très bref (quelques millisecondes). Un pic similaire a été observé dans les autres axes. Il ne semble pas que celui ci soit un obstacle à la fonctionnalité recherché mais il est à prendre en compte dans la conception du logiciel d'asservissement afin d'éviter des corrections excessives en cas de rotation brutale. La semaine prochaine nous testerons l'IMU sur le robot afin de s'assurer que la constante de temps mécanique rend cette variation négligeable.