Version du 24 janvier 2018 à 16:57

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.

Objectifs

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

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é

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 :

• Xilinx Spartan-6 FPGA LX9 Microboard. 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 differentiel (Geoffrey)
• ⇑Buildroot 2018.02 Raspberry Pi (Geoffrey)
• Buildroot en AArch64 Raspberry Pi (Geoffrey)
• PID FPGA FPGA (Geoffrey)

À faire

• Tester FPGA Robotech FPGA (Geoffrey)
• concevoir carte de puissance Electronique (Amaury)
• Établir protocole communication entre appareils Wiki FPGA Raspberry Pi Arduino (Geoffrey)
• Dépot git FPGA Arduino Raspberry Pi Electronique (Geoffrey, Amaury)
• Upload Pi → Arduino Raspberry Pi Arduino (Geoffrey)
• Upload Pi → FPGA Raspberry Pi FPGA (Geoffrey)
• concevoir controleur moteur avec Lm 18200t sur eagle Electronique (Amaury)
• commande matériel électronique de puissance Electronique Arduino (Amaury)
• commande matériel contrôleur moteur Electronique Arduino (Amaury)
• tester contrôleur moteur TLE 5206-2 e Electronique FPGA Arduino (Amaury, Geoffrey)
• tester contrôleur moteur LM 18200T Electronique Arduino FPGA (Amaury, Geoffrey)
• Tester l'IMU Arduino
• PID Arduino Arduino (Geoffrey)
• Analyse interference capteurs

En cours

• concevoir contrôleur moteur avec TLE 5206-2 e Electronique (Amaury)
• dimensionner tout les besoin carte de puissance Electronique (Amaury)
• tester moteur pour propulsion des balles --> caractérisation technique Electronique (Amaury)
• Faire fonctionner Wi-Fi Raspberry Pi (Geoffrey)

À rédiger

• Rajouter des illustrations Wiki (Geoffrey)
• Travail prologue à documenter Wiki (Geoffrey)
• Base freeRTOS Arduino (Geoffrey)
• OS Raspberry Pi Raspberry Pi (Geoffrey)

Terminé

• Liste de matériel Wiki (Geoffrey, Amaury)
• Choix techniques Wiki (Geoffrey)
• Codeuses FPGA (Geoffrey)
• Faire fonctionner la liaison série Raspberry Pi (Geoffrey)

Calendrier prévisionnel

Réalisation du Projet

Feuille d'heures

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 suit :

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**

Semaine 2

Mode production / Mode debug

Pour assurer que le Raspberry Pi se lance en un minimum de temps, 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.

Documents Rendus