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

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

partie électronique

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.

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, nous sommes en test sur les différents moteurs existant à Robotech.
• 1 moteur pas à pas faible puissance (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.

Contrôleur moteur

partie informatique

Réalisation du Projet

Feuille d'heures

Tâche	Prélude	Heures S1	Heures S2	Heures S3	Heures S4	Heures S5	Heures S6	Heures S7	Heures S8	Heures S9	Heures S10	Total
Analyse du projet	0