Version du 16 mai 2018 à 07:17 (voir la source) Gbontoux (discussion | contributions) (→‎Contrôle des contrôleurs moteurs) ← Modification précédente		Version du 16 mai 2018 à 07:32 (voir la source) Gbontoux (discussion | contributions) (→‎test de la simulation en réel) Modification suivante →
Ligne 1 184 :		Ligne 1 184 :
	Nous avons eu un comportement erratique sans comprendre d'où il pouvait provenir.		Nous avons eu un comportement erratique sans comprendre d'où il pouvait provenir.
	Nous allons donc passer en revue toute les sources de problèmes pour les éliminer une à une, à savoir : câblage défectueux, lecture des codeuses par le FPGA, communication FPGA- Raspberry, asservissement, défaut matériel (contrôleur moteur, codeuse, mécanique), alimentation.		Nous allons donc passer en revue toute les sources de problèmes pour les éliminer une à une, à savoir : câblage défectueux, lecture des codeuses par le FPGA, communication FPGA- Raspberry, asservissement, défaut matériel (contrôleur moteur, codeuse, mécanique), alimentation.
		+
		+
		+	=== Résolution du contrôle des moteurs ===
		+	Nous avions vu précédemment que les moteurs tels que contrôlés depuis le Raspberry Pi allaient dans le bon sens mais considérient l'entrée PWM analogique comme une entrée tout ou rien : soit les moteurs tournent à plein régime, soit ils ne tournent pas du tout. Le problème ne se produisant pas lors de nos tests sur Arduino, nous avons essayé de déporter le contrôle des moteurs sur le FPGA, pour voir si cela changeait quelque chose, en vain.
		+
		+	Après quelques recherches plus approfondies, nous nous sommes rendu compte que la capa à l'entrée du contrôleur moteur servait à lisser le signal d'entrée PWM, et la façon dont nous l'avons choisie ne permet d'utiliser des PWM dont la fréquence est au maximum 500 kHz. L'Arduino fonctionne correctement car sa fréquence de génération de PWM est de plusieurs kHz, mais pas le Raspberry étant de base à 19,2 MHz, et pas non plus le FPGA, dont nous avons réalisé la PWM pour une fréquence cible de 700 kHz.
		+
		+	En réduisant la fréquence cible des PWM du FPGA, nous avons pu contrôler les moteurs en toute fluidité. On a remarqué par la suite que la fréquence de génération de PWM du Raspberry Pi est configurable, et peut être changée pour des valeurs tolérées par notre contrôleur moteur, cependant pour des raisons d'optimisation de câblage nous préférereons conserver l'utilisation du FPGA.
	=== tle5206 suite et fin ===		=== tle5206 suite et fin ===

---

Version du 16 mai 2018 à 07:32

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 × HEDS-5500 C06. 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

• Filtre de Kalman Arduino (Geoffrey)
• Enlever le flag -D de avrdude Arduino (Geoffrey)
• Concevoir contrôleur moteur avec transistor de puissance Electronique (Amaury)
• ⇑Buildroot 2018.02 Raspberry Pi (Geoffrey)
• Buildroot en AArch64 Raspberry Pi (Geoffrey)
• Couche niveau 3 pour correction d'erreur Arduino Raspberry Pi FPGA (Geoffrey)
• Multi-ADC FPGA Capteurs (Geoffrey)
• Alléger noyau Linux (encore) Raspberry Pi (Geoffrey)
• Wi-Fi direct ? Raspberry Pi (Geoffrey)
• Faire les calculs en point fixe / entiers Arduino (Geoffrey)
• Retrograder la priorité de l'UART0 Arduino (Geoffrey)
• pilotage en courant des moteurs : recherches bibliographiques Wiki Electronique (Amaury)

À faire

• concevoir schematic LMt18200T Electronique (Amaury)
• commande composant complément pour 5206 Electronique (Amaury)
• router controleur moteur avec Lm 18200t sur eagle Electronique (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)
• PID polaire Arduino (Geoffrey)
• Analyse interference capteurs Arduino Capteurs (Amaury)
• Afficheur & Boutons Raspberry Pi
• faire mail Mr Flamen pour composants complémentaires Electronique (Amaury)
• IMU sous free RTOS Arduino Capteurs (Amaury)
• Gérer les signaux Raspberry Pi (Geoffrey)
• Calibration en position Raspberry Pi Arduino (Geoffrey)
• re vérifier datasheet puissance Electronique (Geoffrey)
• Analyser comportement HCSR04 quand pas d'echo Capteurs
• PWM sans IDE Arduino Arduino (Geoffrey)

En cours

• Expliquer Geoffrey IMU Capteurs (Amaury)
• commande matériel électronique de puissance Electronique (Amaury)
• acheter composant carte de puissance Electronique (Amaury)
• Programme chef Raspberry Pi (Geoffrey)
• analyse interférence capteurs : recherche bibliographiques Wiki Capteurs (Amaury)

À rédiger

• IMU sur FPGA: voir si c'est judicieux FPGA Arduino Capteurs (Geoffrey, Amaury)
• Repenser la récupération des données des codeuses FPGA Arduino Capteurs (Geoffrey)
• Mettre en place la liaison série Arduino ↔ FPGA FPGA Arduino (Geoffrey)
• Filtre capteurs FPGA Capteurs (Geoffrey)
• Améliorer le module communication FPGA (Geoffrey)

Terminé

• Liste de matériel Wiki (Geoffrey, Amaury)
• Rattrapage session Arduino Raspberry Pi Arduino (Geoffrey)
• rédaction correction V2 Mr Flamen Electronique Wiki (Amaury)
• Mettre en place la liaison série Arduino ↔ Raspberry Pi Raspberry Pi Arduino (Geoffrey)
• Différencier stop/brake Raspberry Pi Arduino (Geoffrey)
• Upload Pi → FPGA Raspberry Pi FPGA (Geoffrey)
• Établir protocole communication entre appareils Wiki FPGA Raspberry Pi Arduino (Geoffrey)
• Dépot git FPGA Arduino Raspberry Pi (Geoffrey)
• concevoir composants carte de puissance - V0 Electronique (Amaury)
• concevoir schematic carte de puissance Electronique (Amaury)
• concevoir carte de puissance Electronique (Amaury)
• Upload Pi → Arduino Raspberry Pi Arduino (Geoffrey)
• dimensionner tout les besoin carte de puissance Electronique (Amaury)
• modification V2-> V3 tle5206 Electronique (Amaury)
• vérifier typon capa 100uF --> dimension étrange Electronique (Amaury)
• Choix techniques Wiki (Geoffrey)
• changer bornier 5206 Electronique (Amaury)
• Tester l'IMU Capteurs (Geoffrey, Amaury)
• concevoir V0 contrôleur moteur avec TLE 5206-2 Electronique (Amaury)
• IMU test faisabilite sur IDE arduino Arduino Capteurs (Amaury)
• IMU documentation Wiki Electronique Arduino (Amaury)
• Script pour générer la feuille d'heure Wiki (Geoffrey)
• Codeuses FPGA Capteurs (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)

Calendrier prévisionnel

Difficile d'établir un calendrier prévisionnel quand notre méthode de travail se résume à « prendre un élément dans la liste des tâches à faire qui nous plaît, le faire, répéter ». Heureusement, notre client n'est pas trop pointilleux là dessus.

Réalisation du Projet

Feuille d'heures

Tâche	Prlg. 30/10	Prlg. 6/11	Prlg. 13/11	Prlg. 20/11	Prlg. 8/1	S1 15/1	S2 22/1	S3 29/1	S4 5/2	S5 12/2	S6 19/2	Vacs. 26/2	S7 5/3	S8 12/3	Total
Analyse et préparation	2			8											10
Prise en main FPGA et tests		5.5	1	0.5											7
Rédaction wiki						2	2.5	5	4.5	1.5	3	5	0.5		24
Système Raspberry Pi						3	7								10
Routage contrôleur moteur	3					9	3	1	2					4	22
Routage carte de puissance					0.5	0.5	0.5		0.5	6	4				12
Autre							0.5								0.5
Analyse et implémentation des capteurs								2	2.5	2	1				7.5
Nettoyage & Consolidation									3			3			6
Communication entre les appareils										22	8	16			46
Analyse et implémentation des capteurs											1.5				1.5
Vérification de l'implémentation													4		4
Simulation														4.5	4.5
Total	5	5.5	1	8.5	0.5	14.5	13.5	8	12.5	31.5	17.5	24	4.5	8.5	155

Liste des tâches à effectuer

Optionnel

• Filtre de Kalman Raspberry Pi (Geoffrey)
• Concevoir contrôleur moteur avec transistor de puissance Electronique (Amaury)
• ⇑Buildroot 2018.02 Raspberry Pi (Geoffrey)
• Buildroot en AArch64 Raspberry Pi (Geoffrey)
• Couche niveau 3 pour correction d'erreur Arduino Raspberry Pi FPGA (Geoffrey)
• Multi-ADC FPGA Capteurs (Geoffrey)
• Alléger noyau Linux (encore) Raspberry Pi (Geoffrey)
• Wi-Fi direct ? Raspberry Pi (Geoffrey)
• pilotage en courant des moteurs : recherches bibliographiques Wiki Electronique (Amaury)
• Filtre à réponse impulsionelle infinie FPGA

À faire

• router controleur moteur avec Lm 18200t sur eagle Electronique (Amaury)
• tester contrôleur moteur LM 18200T Electronique (Amaury, Geoffrey)
• PID Raspberry Pi (Geoffrey)
• Afficheur & Boutons Raspberry Pi
• Gérer les signaux Raspberry Pi (Geoffrey)
• Programme chef Raspberry Pi (Geoffrey)
• Calibration en position Raspberry Pi (Geoffrey)
• re vérifier datasheet puissance Electronique (Geoffrey)
• Analyser comportement HCSR04 quand pas d'echo Capteurs

En cours

• Analyse interference capteurs Arduino Capteurs (Amaury)
• i2c sur Rpb maitre escalve Raspberry Pi Capteurs (Amaury)
• Simulation du système (Geoffrey)

À rédiger

• IMU sur FPGA: voir si c'est judicieux FPGA Arduino Capteurs (Amaury, Geoffrey)
• Mettre en place la liaison série Arduino ↔ FPGA FPGA Arduino (Geoffrey)
• analyse interférence capteurs : recherche bibliographiques Wiki Capteurs (Amaury)
• Améliorer le module communication FPGA (Geoffrey)
• tester contrôleur moteur TLE 5206-2 e Electronique (Amaury, Geoffrey)

Terminé

• Expliquer Geoffrey IMU Capteurs (Amaury)
• Liste de matériel Wiki (Amaury, Geoffrey)
• Rattrapage session Arduino Raspberry Pi Arduino (Geoffrey)
• rédaction correction V2 Mr Flamen Electronique Wiki (Amaury)
• commande composant complément pour 5206 Electronique (Amaury)
• faire mail Mr Flamen pour composants complémentaires Electronique (Amaury)
• commande matériel électronique de puissance Electronique (Amaury)
• acheter composant carte de puissance Electronique (Amaury)
• Mettre en place la liaison série Arduino ↔ Raspberry Pi Raspberry Pi Arduino (Geoffrey)
• Différencier stop/brake Raspberry Pi Arduino (Geoffrey)
• Upload Pi → FPGA Raspberry Pi FPGA (Geoffrey)
• Établir protocole communication entre appareils Wiki FPGA Raspberry Pi Arduino (Geoffrey)
• Dépot git FPGA Arduino Raspberry Pi (Geoffrey)
• concevoir composants carte de puissance - V0 Electronique (Amaury)
• concevoir schematic carte de puissance Electronique (Amaury)
• concevoir carte de puissance Electronique (Amaury)
• Upload Pi → Arduino Raspberry Pi Arduino (Geoffrey)
• dimensionner tout les besoin carte de puissance Electronique (Amaury)
• modification V2-> V3 tle5206 Electronique (Amaury)
• vérifier typon capa 100uF --> dimension étrange Electronique (Amaury)
• Choix techniques Wiki (Geoffrey)
• changer bornier 5206 Electronique (Amaury)
• Tester l'IMU Capteurs (Amaury, Geoffrey)
• concevoir V0 contrôleur moteur avec TLE 5206-2 Electronique (Amaury)
• IMU test faisabilite sur IDE arduino Arduino Capteurs (Amaury)
• IMU documentation Wiki Electronique Arduino (Amaury)
• Script pour générer la feuille d'heure Wiki (Geoffrey)
• Codeuses FPGA Capteurs (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)
• Repenser la récupération des données des codeuses FPGA Arduino Capteurs (Geoffrey)
• Filtre capteurs FPGA Capteurs (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)
• Le bon modèle des codeuses Wiki (Geoffrey)

Semaine 1

Dimensionnement de la carte de puissance

Nous utiliserons comme source d'énergie une batterie Lithium-Polymère (ou LiPo) 4s délivrant une tension de 14.8V.

Note rétro-active : Certaines valeurs et remarques lors de cette analyse initiales sont erronnées, elles ont été corrigées en semaine 4.

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ée car elle peut entraîner des manques de stabilité dans le fonctionnement du micro-contrôleur et dans la qualité du 5V donnée 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 nominale cependant ils s'avèrent surdimensionnés pour notre usage. Empiriquement leur utilisation étaient plutôt de l'ordre de 1.5 A maximum. La tension nominale 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 parler n'ont pas encore toutes été parfaitement déterminées par notre client. On y reviendra donc plus tard.

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

Voici les caractéristiques demandées par le contrôleur moteur :

• 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 4 commposants suivants répondants à première vue à nos besoins :

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é.

Le LM 18200T et le LM 18201T 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 LM 18201T 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 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 rapides.

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.

Notre choix s'arrête donc sur la conception dans un premier temps du contrôleur avec les TLE 5206-2 avec deux PCB isolés (un par moteur), puis on utilisera un LM18200T qui pilotera les moteurs en tant que solution alternative mais sur un seul PCB.

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).

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 avec le composant TLE5206

L'intérêt de ce contrôleur est qu'il très bon marché (4€/pièce), et il permet de contrôler un moteur jusque 5A avec un pic de courant de 6A et une tension d'alimentation allant jusque 40V.

Cependant il disposes de quelques limites :

• Le pic 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 protections. En regardant la datasheet on voit que beaucoup court-circuits éventuels ne sont pas couvert par le système de protection, ni par l'indication de flag. La non-détection d'un court circuit au niveau du moteur pourrait lui entrainer des dommages. Étant l'élément le plus cher du robot, notre client nous a demandé d'apporter un soin particulier à ce composant, d'où cette préoccupation.

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

Pour nous assurer de la bonne qualité de notre carte, nous avons demandé à M. Flamen un retour sur la qualité de la conception. Voici les premiers éléments à améliorer :

• Les pistes sont trop étroites. Il est nous est conseillé d'utiliser l'application Electrodroid pour les choisirs.
• Il faut éviter les angles aigus.
• Il faut mettre les composants de puissance en bordure de PCB pour permettre l'installation d'un dissipateur.

Semaine 4

Conception de la carte de contrôleur moteur avec le composant TLE5206

Un deuxième retour nous a été effectué par M. Flamen.

Compatibilité Électro-Magnétique : Les angles à 90° sont à éviter mais pas forcément à proscrire, surtout si l'on ne fonctionne pas en haute fréquence (ce qui est notre cas). Les angles 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 broches parallèles afin d'optimiser l'espace et les fraises. 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 bonne pratique à garder si l'usinage des cartes est chimique car il peut favoriser une collection d'acide entraînant des grignotages sur la carte pouvant altérer son fonctionnement.

Texte sur la carte : 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. Il faut l'ajouter au format tdocu dans l'onglet Computer-Aided Manufacturing afin de graver les lettres et non le contour des lettres. De cette façon on économise en temps de conception et on éviter de trop user les fraises.

Design Rule Check : Il faut modifier la valeur copper dimension à 4mm afin de suivre les spécifications de la graveuse numérique. Cette valeur représente l'espace entre la découpe du contour du PCB et l'espace sans cuivre qu'on laisse autour.

Divers :

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

Après quelques ajustements mineurs par la suite, la carte a été envoyé en impression.

Centrale inertielle

Le problème avec les encodeurs de moteurs est qu'ils ne sont pas sensibles à d'éventuels dérapages des roues sur la piste. Dans la mesure où nous souhaitons de fortes accélérations, nous ne pouvons néglier ces pertes. C'est pourquoi nous allons utiliser une centrale intertielle, ou Inertial Measurement Unit (IMU), qui est un PCB embarquant avec lui un gyroscope, un accéléromètre et une boussole. Bien que la précision du capteur soit bonne que les encodeurs, elle permettra de détecter des incohérences liées aux dérapages et les corriger.

Notre IMU, une MinIMU-9 v3 embarque le gyroscope L3GD20H et un accéléromètre/magnétomètre LSM303D.

Nous avons fait des tests préliminaires A l'aide de la documentation fournie 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.

L'IMU peut nous donner les paramètres suivants : le yaw, le pitch et le roll.

Sur l'enregistre de gauche on voit que pour un passage brutal 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 pu être observé sur les autres axes.

Il ne semble pas que celui ci soit un obstacle à la fonctionnalité recherchée mais il est à prendre en compte dans la conception du programme d'asservissement afin d'éviter des corrections excessives en cas de rotation brutale.

Mise à jour du/par Raspberry Pi

Mise à jour de l'OS du Raspberry Pi

Nous avons vu que pour mettre à jour le système d'exploitation du Raspberry Pi, ré-écrire la carte SD en entier n'est ni pratique, ni rapide, ni bon pour la durabilité de la carte. On a donc établi -conformément à ce qui était demandé dans le cahier des charges- un moyen de le mettre à jour par liaison sans file. On a déjà un moyen de se connecter en SSH au Raspberry Pi par Wi-Fi, on transférera donc par ce canal les fichiers générés par buildroot avant mise en image, vers la racine de la carte. On utilisera pour cela `rsync`. Cela rajoute un programme en plus sur l'OS, mais cela permet de ne pas ré-envoyer les fichiers qui n'ont pas changé. Ce n'est pas une solution très élégante, mais elle est redoutablement fonctionelle. Il suffit alors de taper `make upgrade-filesystem` pour lancer l'opération.

Mise à jour de l'Arduino

Le programme utilisé pour téléverser un programme sur un Arduino s'appelle avrdude, et par chance il est dans les programmes proposés par buildroot. Il suffit simplement de l'activer dans la configuration de buildroot et d'ajouter une entrée `upgrade-arduino` dans le Makefile qui se chargera de l'envoi vers le Raspberry Pi et de l'invocation de la commande de téléversement.

Mise à jour du FPGA

On procèdera de la même manière pour téléverser un programme sur le FPGA. Cependant, le FPGA utilisé étant assez peu connu, il n'existe pas de programme directement dans buildroot capable d'effectuer le téléversement. De plus, le programme fourni par le constructeur pour le téléversement est sous forme d'interface graphique ce qui n'est pas adapté pour notre cas. Heureusement, la source du programme est ouverte, et quelqu'un l'a réécrit sous forme de programme en ligne de commande. Il ne reste qu'à créer un package pour buildroot et le tour est joué.

Semaine 5

Carte de puissance

Après de nombreuses discussions auprès du client (à savoir les différentes équipes travaillant sur le robot principal) il semble que les besoins en diverses tensions et courant sont à présent fixés, nous avons donc :

Bilan de puissance

Quantité	Consommateur	Alimentation	Courant maximum
1	Arduino MEGA	9-12V	500mA
1	Raspberry Pi 3	5V	1A
2	Moteur Faulhaber	24V	4,2 A bridé à 2,5A environ
1	FPGA MicroNova Mercury	5V	275mA (nominal 60mA)
1	Dynamixel AX-12 (demmande client)	9-10V	900mA (à vérifier)
2	QH4 4347 (demmande client)	?	?

Nous avons donc besoin de sources de tension suivantes :

• 5V délivrant 1,275A maximum
• 9V délivrant 1,4A maximum
• 24V délirant 5A maximum

Il reste une inconnue pour le moment, l'alimentation du moteur QH4 4347.

Il nous reste à présent le choix des composants, 3 possibilités s'offrent à nous :

• Acheter des convertisseurs clés en mains [1] de ce type. Ils proposent souvent un prix imbattable mais sont rarements fiable presque dangereux.

• Acheter des composants à souder sur des sites réuputés de ce type. Le prix est plus élevé mais nous avons un composants bien plus fiable et où les échauffements sont très réduits offrant une efficacité imbattable. De plus on a le plaisir de concevoir le PCB qui l’accueillera.

• Créer nous même le convertisseur en descendant encore d'un niveau. Cependant cela demande de nombreuses heures de conceptions et de tests tout en ayant un prix pas si compétitif face à l'option 1 et 2 et aucune garantie quant à l'efficacité du produit final.

Si l'on s'appuie sur l'expériences des dernières années nous pouvons prospecter la deuxième option : Pour le 5 et le 9V nous pouvons : [2]. Pour le 24V : [3]. Il s'agit de la même famille de composants qui permettent de choisir la tension de sortie à l'aide de quelques composants extérieurs offrant une modularité à cette carte pour les années suivantes. Soit un total de plus de 70€, une solution couteuse mais de qualité.

Pour trancher cette décision nous en avons discuté avec un professeur d'électronique de puissance, M. Delarue.

Il nous a conseillé de favoriser l'option 2 qui reste la meilleure option « en terme de fiabilité, de rendement, d'encombrement, de prix, ... ».

Les composants proposés précédemment sont cepednat des step-down, ils ne peuvent pas produire des tensions supérieures à la tension d'alimentation. On ne pourra donc pas créer de tension à 24V.

Pour le booster qui alimentera nos deux moteurs nous avons vérifié la datasheet du moteur. Il n'y a pas d'indications sur le pic de courant au démarrage du moteur, nous nous baserons donc sur les composants qui ont résisté lors des compétitions précédentes pour que ceux choisis correspondent au minimum aux mêmes caractéristiques techniques.

Pour alimenter nos moteurs nous utiliserons ce composant en 2 exemplaires (1 par contrôleur moteur et donc par moteur).

Nous avons donc routé une première version de deux cartes d'alimentation, une pour les moteurs et une pour le reste (images ci-dessus). Elles sont encore améliorables, il est notamment question d'éventuellement placer un bornier sur les pins inutilisés afin de permettre un éventuel usage plus tard.

Communication entre les appareils

Le Raspberry Pi, l'Arduino et le FPGA doivent pouvoir communiquer ensemble afin de remplir leur rôle. Pour établir un système de communication adapté à leur besoins, établissons la liste (grossière) des informations qui doivent être envoyées d'un appareil à l'autre.

Raspberry Pi → Arduino

• Ordre d'arrêt
• Ordre de nouvelle destination
• Réinitialisation des informations de position

Arduino → Raspberry Pi

• Arrivée à destination
• Informations d'état pour le débug

Arduino → FPGA

• Réinitialisation de la valeur des encodeurs

FPGA → Arduino

• Valeur des encodeurs
• Valeur des capteurs de distance

Informons nous sur les différents modes de communication natif des différents appareils :

• Le Rapsberry Pi possède des accélérateurs matériels pour communiquer en I2C, en SPI et en UART. De plus, une liaison série supplémentaire avec un Arduino est aisément possible à l'aide d'un câble USB.
• L'Arduino Mega 2560 possède 4 liaisons UART matérielles, et une liaison SPI matérielle.
• Le FPGA peut utiliser n'importe quel protocole de communication sans effort.

Passons en revue les autres systèmes de communication que nous seront amenés à utiliser et pour lesquels il n'y a peut-être pas de solution alternative.

• Sur le Raspberry Pi, on aimerait garder la liaison UART matérielle étant un moyen très peu prones aux erreurs d'accéder à un shell du Raspberry Pi. De plus, le port SPI sera utilisé pour l'écran LCD qui servira pour l'interface humain-machine.
• Sur l'Arduino, la liaison SPI sera utilisée pour communiquer avec la centrale intertielle. La liaison série n°0 est aussi utilisée pour la mise à jour du programme de l'Arduino par USB, il faudra donc éviter de brancher quelque chose dessus.

Cependant ces deux contraintes n'en sont pas réellement, puisque le protocole SPI autorise le branchement de tous les périphériques sur le même réseau de par son schéma maître-esclave. En conséquence, chaque élément possède un temps de parole limité, ce qui peut être problématique dans notre cas d'usage. En effet, il serait facheux que le FPGA doive attendre pour transmettre des informations concernant une collision imminente alors que le réseau est occupé à transférer des données de debug. De plus, les périphériques esclaves ne peuvent communiquer entre eux, tout doit passer par le maître qui devra jouer le rôle de messager au besoin.

Pour ces raisons, et aussi pour des raisons de simplicité, on connectera chaque appareil deux à deux à l'aide d'une liaison série. On obtient un schéma de communication suivant :

Pour les liaisons séries, on utilisera en couche applicative notre propre format de trame. Chaque trame commencera par un octet indiquant le type d'information à être envoyé. Elle peut être ensuite suivie par des données, dont la taille et la consitution est définie par le type d'information. Chaque information pouvant être transmise, et la structure de données à envoyer est définie dans des fichiers .h, un pour la communication Arduino↔FPGA et un pour la communication Arduino↔Raspberry Pi (dans ces fichiers le Raspberry Pi est aussi appelé Chef, pour le nom du programme).

Certaines informations seront envoyée à l'initiative de l'appareil possédant l'information (Direct), tels que les ordres du Raspberry Pi à l'Aruino. D'autres, seront envoyés à l'initiative de l'appareil ayant besoin de l'information (Indirect), tels que les valeurs des codeuses qui changent bien plus souvent que l'Ardnuio ne saura les traiter. Les dernières, seront envoyés dès que certaines valeurs dépassent un certain seuil (Trigger), seuil fixé par l'appareil reçevant l'information, telles que les valeurs des capteurs de distance. Tout cela permet de garder uniquement les informations utiles, afin de réduire au maximum la congestion du réseau et le traitement par les appareils.

Communication série par interruptions sur Arduino

Jusque là en cours, pour envoyer ou reçevoir des octets sur l'Arduino, on utilisait une boucle qui attendait que les bits RXCn et UDREn du regsitres UCSRnA soit mis à 1, affin d'attendre qu'un octet soit reçu ou prêt à être envoyé respectivement. Le problème de cette méthode, est qu'elle utilise excessivement le CPU et empêche de faire quelque chose d'autre en même temps. Avec le système RTOS, on peut faire plusieurs choses à la fois, mais il faut attendre que la tâche de cette boucle soit élue pour pouvoir traiter l'envoi / la réception de données.

Heureusement, l'Atmega2560 dispose d'interruptions sur le port série. Il suffit d'activer le bit RXCIEn dans le registre UCSRnB pour qu'à chaque réception d'octet sur le port série, l'interruption USARTn_RX_vect se déclenche. Dans notre cas, cette interruption réveille une tâche FreeRTOS à l'aide d'une notification, tâche qui va s'occuper récupérer et traîter les données juste reçues, et se ré-endort jusqu'à la prochaine réception.

On pourrait directement traîter les données dans l'interruption, mais cette méthode a plusieurs avantages. En effet la durée de l'interruption est minime, permet d'utiliser le système de priorités des tâches (alors que l'interruption a une priorité absolue) et évite d'empêcher l'arrivée d'autres interruptions. D'autre part, la tâche peut-être interrompue à n'importe quel endroit, elle est donc un moyen simple de stocker à quel endroit de la reception on en est.

Pour la transmission, deux choix s'offrent à nous : l'utilisation de l'interruption USARTn_TX_vect ou de l'interruption USARTn_UDRE_vect. La première est déclenchée quand un caractère vient de finir sa transmission. On peut alors utiliser cette interruption pour envoyer le prochain caractère dans la file d'attente. Cependant, si on utilise la même méthode que pour la réception, entre le moment où la transmission d'un caractère est terminée et celui où la transmission d'un nouveau caractère est initiée, il va falloir que la tâche faisant l'envoi soit élue. On peut en revanche utiliser le cache matériel de l'Atmega2560, qui permet de stocker deux caractères, et nous permet donc d'envoyer une suite ininterrompue de caractères, et ainsi envoyer les messages plus rapidement. Il faut pour cela utiliser l'autre interruption, USARTn_UDRE_vect qui se déclenche quand il est possible d'écrire dans le cache.

Cependant, cette interruption s'utilise différemment des deux précédentes. En effet, là où les interruptions se déclenchent à un changement d'état (e.g. reception d'un octet), USARTn_UDRE_vect se déclenche continuellement quand le cache de la liaison série est écrivable. D'une part, il faut donc désactiver l'interruption quand il n'y a rien à transmettre. D'autre part, il faut donc écrire dans le cache à l'interieur de l'interruption. On définiera donc un pointeur global vers les données à écrire et leur taille qui sera écrit depuis la tâche voulant envoyer des informations et lue par 'interruption. Une fois l'envoi terminé, l'interruption se désactivera d'elle même et réveillera la tâche ayant initié l'envoi. Cette méthode nous permet d'utiliser au maximum de sa capacité la liaison série tout en encombrant un minimum le processeur de l'Arduino.

Répartitions des messages reçus

Que ce soit du côté de l'Arduino ou du Raspberry Pi, la réception d'octets sur la liaison série est gérée par une seule tâche (ou thread sur le Raspberry Pi). Cependant, pour éviter de complexifier trop cette tâche et de la rendre indépendante des types de messages reçus, on utilisera un système d'observateurs. N'importe quelle partie du programme peut demander à ajouter un observateur sur un certain type de message. L'observateur, étant une fonction, est éxecutée lors de la réception dudit type de message. Cette fonction peut alors récupérer les données du message pour les stocker à l'endroit voulu, et dire à une autre tâche de faire quelque chose avec ces données.

Pour faire cela, la tâche de réception garde un tableau d'observateurs indexés par le type de message auquel il est accroché. Quand le début d'un message est reçu, la tâche regarde dans le tableau si un observateur a été associé au type de message, si oui éxecute la fonction (dans la même tâche, afin que cette fonction puisse lire le reste du message) et si non affiche une erreur.

Récupération de session

Chaque appareil (FPGA, Arduino et Raspberry Pi) est censé pouvoir fonctionner indépendament. Par exemple, si l'on pousse le robot alors que le programme chef du Raspberry Pi est inactif, on veut quand même enregistrer le déplacement afin d'éviter de devoir re-calibrer la position du robot par rapport à son environnement. Ce n'est pas inclus dans le cahier des charges, mais c'est une fonctionalité simple à réaliser vu la réalisation choisie. On pourra donc travailler facilement sur le programme principal (c'est à dire le redémarrer et le modifier) sans que ce dernier n'ait à sauvegarder la dernière position du robot puis la relire.

Cependant, que se passe-t-il si le programme du Raspberry Pi est interrompu alors que l'Arduino est en train d'attendre des informations ? Vraisemblablement, les premiers messages envoyés par le Raspberry Pi seront considerés comme des données de message et seront donc ignorés en tant que message, et par la suite un décalage s'ensuivra. Pour éviter cela, on instaure un nouveau message, le ping. Quand le Raspberry Pi envoi un message de ce type (sur 1 octet), l'Arduino doit lui renvoyer un message du même type et ne rien faire d'autre. Lors du démarrage du programme du Raspberry Pi, ce dernier envoi plein de requêtes ping à la suite, jusqu'à ce que ce que l'Arduino lui renvoie son message. De cette manière tout message en cours de réception côté Arduino sera rempli et les deux appareils seront de nouveau synchronisés. Il faut juste prendre gare à envoyer un message d'arrêt des actionneurs du robot dès la première réponse reçue, car le message en cours de réception contient alors des données invalides qu'il faut annuler.

Semaine 6

Simulation du FPGA

Écrire un programme pour FPGA est un processus plus compliqué que l'écriture d'un programme pour ordinateur. En effet, dans le premier, il n'y a pas possiblité d'utiliser de débuggueurs pour observer le contenu des variables, ou de moyen simple d'afficher des messages à l'écran. De plus, le processus de synthétisation est plutôt long, et lorsque le FPGA est utilisé avec d'autres périphériques il n'est pas toujours facile de les avoir sous la main pour tester.

Heureusement, il est possible de simuler les programmes de FPGA à l'aide de simulateurs. La génération d'une simulation est généralement beaucoup plus rapide que la synthétisation d'un design, et permet d'observer les signaux internes des composants. L'outil Isim, proposé par Xilinx -le constructeur du FPGA que nous utilisons-, est l'un de ces simulateurs, mais il n'est pas très flexible et s'utilise difficilement sans projet de l'IDE Xilinx, que nous n'utilisons pas pour des raisons évoquées dans le prologue. Nous allons plutôt utiliser deux outils libres, GHDL et GTKWave.

La simulation d'un process commence par l'élaboration d'un testbench, qui est un fichier VHDL qui embarquera comme composant le module à tester, et génèrera des signaux sur les entrées du module à différents instants de la simulation. On peut alors vérifier que les sorties du modules soient conformes à ce qui est attendu : on réalise de la sorte des tests unitaires (cf capture de terminal à gauche). On peut aussi afficher avec GTKWave l'évolution des signaux en fonction du temps afin de débuguer plus finement le programme (cf capture d'écran à droite). Bien entendu, tout le processus de simulation (à part l'élaboration du testbench) a été intégré dans un makefile, afin de pouvoir rafraichir la simulation d'un seul relancement de commande. On retrouvera des fichiers XXX_tb.vhd contenant le testbench pour le module XXX ; des fichiers build/XXX.ghw contenant l'évolution des signaux dans la simulation ; et des fichiers XXX.gtkw contenant les informations d'affichage desdits signaux dans le logiciel (ordre, couleur, type de données...).

Il faut faire cependant attention aux différences existantes entre la simulation et la synthétisation. En effet la simulation est beaucoup plus permissive ce qui permet notamment de simplifier l'écriture de testbenchs. Cependant, certains comportements sont inconnus voire ignorés par le synthétiseur. Par exemple, dans un process il est possible de définir des listes de sensiblité, qui font en sorte que le process ne soit executé uniquement si une des valeurs des éléments de cette liste est changée. Cependant sur le vrai FPGA, cette liste de sensibilité est totalement ignorée et le process est éxecuté à chaque front d'horloge, ce qui peut causer de grandes différences entre la simulation et la réalité. Il faut donc garder en tête ces différences lors de la simulation.

Recherche sur le capteur à ultrason HCR04

Ce composant est un grand classique de la robotique et pourtant on trouve assez peu d'informations précises sur son fonctionnement et ses limites.

étude du capteur

on note qu'il fonctionne à 40Hz soit potentiellement un résultat toutes les 25ms. Les différentes datasheet consultées préconisent une acquisition toutes les 60ms.

Notre objectif dans cette analyse était principalement de chercher une technique pour s'assurer que le signal provient bien de notre capteur et pas d'un capteur adverse ou d'un autre appareil présent lors de la compétition.

Comme on peut le voir sur ce datagramme il ne sait pas faire la différence entre son écho ou l'envoi d'un autre capteur, cela pourra poser un problème lors de la compétition.

Solutions envisageables

Une solution envisageable peut-être d'intégrer dans le code une logique qui vérifie une certaine redondance de l'information (le delta du capteur étant très inférieur à celui du déplacement des robots) pour s'assurer qu'il s'agit bien de l'écho de notre capteur. On peut également le placer à la limite haute réglementaire qui n'est pas souvent privilégiées par les concurrents.

Une autre solution peut consister à remplacer le capteur ultrason par d'autres types de capteurs. On peut envisager d'utiliser le VL53L0X qui mesure le time of flight (comme le HSR04 au final) mais avec une lumière infrarouge. Il offre sur le papier un capteur sensible de 3cm à 2m avec une précision de 1mm à plus ou moins 10% dans le pire cas. Pour notre usage il n'offre pas d'avantages immenses vu que la précision n'est pas notre critère cependant en utilisant une autre technologie cela pourrait éviter des conflits avec les capteurs adverses. VL53L0X

Nous utiliserons la première solution, pour des raisons financières et également parce que c'est une technique qui a fait ses preuves lors des années précédentes. Cependant elle sera soumise dans le rapport final pour les années futures.

Fréquence d'échantillonage

Il est recommandé dans la datasheet du composant d'échantilloner au minimum toutes les 60 ms, afin d'éviter les intérférences avec les ondes des précédentes mesures (en 60ms le son a la temps de parcourir 10m, distance à partir de laquelle on considère qu'il est complètement atténué). Notre robot possèdera au plus 4 capteurs à ultrasons, est-on obligé de lire les valeurs des capteurs un par un, réduisant la fréquence d'échantillonage à 4 Hz ? La réponse est non. En effet nos capteurs sont positionnés dans des distances opposées, et si les 4 envoient une onde en même temps, la première onde reçue sera renvoyée par l'obstacle le plus proche du capteur la reçevant. On peut donc conserver une fréquence d'échantillonage de 16 Hz.

Vacances

Vue d'ensemble du FPGA

Cette semaine nous allons beaucoup parler du FPGA. Pour mieux comprendre la suite, il peut être utile de rappeler ce que cette carte est censée faire et comment nous comptons lui faire faire.

Les tâches à réaliser par le FPGA sont les suivantes :

• Récupérer les valeurs des capteurs de deux capteurs distance (un devant et un derrière) (pour l'instant ce sont des capteurs ultrasons de type HC-SR04)
• Filtrer les précédentes valeurs de façons à enlever les valeurs aberrantes liées aux interférences
• Récupérer les valeurs des encodeurs (un à gauche et un à droite)
• Communiquer les valeurs récupérées par liaison série

Basiquement, on écrira un modules VHDL pour chaque tâche, respectivement hcsr04.vhd, fir.vhd,

Récupération des données des encodeurs

Au départ on pensait stocker les valeurs des encodeurs (générées par le FPGA) sur un entier signé de 32 bits, et ce dernier serait envoyé à l'Arduino à chaque fois que ce dernier en a besoin pour actualiser la position du robot. Cependant, on s'est rendu compte que l'Arduino n'a besoin que de la différence entre la précédente valeur et la valeur actuelle pour calculer le déplacement en position. Nous avons donc fait en sorte d'envoyer directement la différence, en remettant à 0 les valeurs à chaque lecture par l'Arduino. Cela se fait par l'entrée zero des modules VHDL des encodeurs, forçant leur valeur à 0, qui est donc mise à '1' pendant un cycle d'horloge.

Mais que se passe-t-il si la valeur des encodeurs change pendant une lecture  ? L'utilisation d'un signal VHDL pour stocker les valeurs ne permet pas d'être modifiée deux fois en un cycle d'horloge (une pour remettre à 0 et une pour incrémenter/décrémenter la valeur), on perdrait donc un peu de données. On utilisera plutôt une variable VHDL. À l'instar d'un signal, elle permet de stocker des données (ici un entier) mais au lieu d'être relative au module elle est relative au processus mais permet d'être écrite plusieurs fois dans le même cycle d'horloge : on ne perd donc pas de données. La probabilité d'une perte de donnée est faible (0,073% de chance pour chaque lecture de valeur à 10 km/h) et l'erreur aussi faible (0,077 mm pour chaque perte), et ce problème aurait certainement pu être négligé par rapport aux dérapages de la roue.

On peut d'ailleurs en profiter pour réduire le nombre entier des valeurs des encodeurs à 16 bits, ce qui laisse au robot le temps de parcourir 5 m sans mise à jour de position avant de faire un dépassement.

Implémentation du filtre pour les interférences

Note : le travail sur le filtre est basé en partie sur le travail réalisé dans le cadre du tutorat de Circuits Numériques Programmables du S7 par Eloi Zalczer et Geoffrey Preud'homme.

Pour filtrer les intérférences et autres valeurs erronées des capteurs de distance, on utilisera un filtre à réponse impulsionnelle finie (ou FIR). L'avantage de ce type de filtres est qu'il est très générique : on peut changer le mode de filtrage (passe-bas, passe-haut...) et ses paramètres (fréquence de coupure...) en changeant les valeurs d'un tableau de coefficients. Plus le nombre N de coefficients est grand, plus Le calcul du signal de sortie se fait simplement en faisant la somme du produit de chaque coefficient par le signal d'entré décalé dans le temps proportionellement à l'indice du coefficient.

Les opérations réalisées sont donc de simples retard, additions et multiplications (à l'opposé du filtre à réponse impulsionelle infinie), qui sont des opérations très simple pour le FPGA. Cepedant, les facteurs du filtre sont des décimaux inférieurs à 1, ce que traite difficilement un FPGA. Pour pallier à ce problème, on utilisera la propriété linéaire du filtre : on multipliera les facteurs par un nombre N afin qu'ils signifient quelque chose en tant qu'entier, puis on divisera le résultat par N. Afin de pouvoir effectuer la division simplement sur le FPGA, on prendra une puissnce de 2 comme valeur de N : la division se simplifie alors par un décalage de bits par la droite.

L'implémentation réalisée précédemment calcule la sortie du filtre en un seul front d'horloge. Cette méthode a un avantage : elle est très rapide car prend avantage des ressources du FPGA : chaque multiplication est réalisée en parallèle et chacune utilise une partie des ressources du FPGA (i.e. les tables de correspondances (LUT) et les bascules (flip-flop)). Mais c'est aussi un inconvénient, car ces ressources ne peuvent pas être réutilisées pour quelque chose d'autre. Dans notre cas, la sortie du filtre n'a pas besoin d'être calculée en un coup d'horloge (20 ns), on préfèrera utiliser un fonctionnement dit en « pipeline ». Cela consiste à répartir une partie des calculs sur différents coups d'horloge. Dans notre cas, on effectuera une multiplication et une addition par coup d'horloge. Beaucoup moins de ressources du FPGA seront utilisées, car elles seront utilisées plusieurs fois pour le calcul de plusieurs coefficients (cf capture ci-contre).

On peut remarquer que la méthode « pipeline » utilise un des multiplieurs 18 bits × 18 bits du FPGA. Or, ils n'étaient pas utilisés dans la méthode « immédiate ». On peut supposer ceci : étant donné que les coefficients du filtre étaient fixes, chaque multiplication effectuée possèdait un membre fixe. Les blocs de multiplication ont pu donc être optimisés (par exemple une multiplication par un coefficient de valeur '1' peut être remplacée par une identité).

Module de communication

Ce module permet de connecté les différentes valeurs qui peuvent être lues / écrites depuis / vers les autres modules avec le module de la liaison série. Il s'occupe alors de traiter les données arrivant sur la liaison série, modifier valeurs à envoyer sur les autres modules si besoin, et de renvoyer un message sur la liaison série si nécessaire.

À l'arrivée d'un premier octet (qui est dans notre cas le code du message), des signaux sont modifiés pour indiquer la taille du message et ce qu'il faut faire une fois totalement reçu. Le reste du message est lu puis est stocké dans un buffer. Une fois totalement reçu, une routine redirigeant les informations contenues dans le buffer dans les signaux connectés aux autres modules est executée. Éventuellement, un message à envoyer est stocké dans une queue d'envoi. Lorsque cette queue n'est pas vide, le premier élément de la queue est lu, les informations correspondantes sont stockées dans un buffer d'envoi, et le message est envoyé octet par octet. Une fois terminé, l'opération est recommencée jusqu'à ce que cette queue soit vide.

Une première version de ce module a été écrite, elle utilisait beaucoup de variables de process. Cela faisait en sorte que chaque traitement était réalisé au maximum en un coup d'horloge. Cependant, la vitesse de communication de la liaison série (même à 115200 baud/s) est 400 fois plus lente que les coups d'horloge. Il n'est pas nécessaire d'utiliser des variables dont la modification est immédiate. Le module a donc été réécrit à base de signaux, et 4 coups d'horloge sont à attendre entre la finalisation de la reception d'un message et l'initation de l'envoi de la réponse (reception du caractère, redirection des informations et ajout à la pile, dépilage et écriture du buffer, envoi du caractère). Cela a deux avantages : il réduit la complexité du programme en réduisant le nombre de LUT et de liens, et permet une fréquence de travail plus élevée, ce qui permet ainsi à notre code de fonctionne sur des FPGA dont la fréquence d'horloge est plus basse.

Corrections après usinage carte 5206

Suite à l'usinage nous avons constaté que le plan de masse n'avais pas été correctement interprété par le logiciel, il s'avère que cette toute première étape avait été mal faite. En effet le polygone permettant de créer la masse comportait un segment supplémentaire qui probablement à causé une mauvaise interprétation du logiciel. Cependant grâce au sauvetage de Mr Flamen, nous pouvons tout de même utiliser la carte afin de réaliser un premier test lors de la semaine de rentrée.

Finalisation avec le "client" des besoins en terme de puissance

A la suite d'une dernière réunion nous avons tranché les besoins et les composants de puissances ont donc pu être commandés.

Semaine 7

I2C et IMU

Après avoir étudié les données que nous fourni l'IMU, étudions d'un peu plus près la communication entre l'IMU et l'Arduino, qui avait été faite par abstraction jusqu'à aujourd'hui. La communication se fait via le protocole I2C. Une communication I2C fonctionne à l'aide de 2 pins, SCL et SDA. La pin SCL fourni une clock à l'IMU pour que celui-ci puisse envoyer ses datas via SDA.

La communication peut se faire à plusieurs vitesses différentes, la commutation des bits se fait sur un intervalle de durée déterminé par le tableau ci-dessous.

Mode	tLOWmin	tHIGHmin
Standard	4,7 μs	4 μs
Fast	1,3 μs	0,6 μs
Fast plus	0,5 μs	0,26 μs

On remarque que les délais sont assez courts. De plus, l'Arduino ne possède pas d'accélérateur matériel pour ce genre de communication. On en déduit donc que le code d'exemple que nous avons utilisé jusqu'ici gère la communication I2C par le programme, et monopolise le CPU pour avoir un timing conforme.

Or, le problème est que notre Arduino est multi-tâches. A première vue FreeRTOS ne nous autorise pas un contrôle aussi précis d'une tâche, et même si c'était le cas les performances seraient probablement fortement dégradées. On abandonne donc l'idée d'utiliser l'IMU depuis l'Arduino.

Retour sur nos pas

Une confusion avait été faite lors de l'élaboration du système d'inter-communication des périphériques. En effet, on pensait que l'IMU communiquait en SPI au lieu de I2C, protocole de communication pour lequel l'Arduino possède un accélérateur matériel. On va donc devoir repenser ce système.

La solution la plus simple pour passer outre ce problème serait d'utiliser le FPGA pour recevoir les communications I2C et les re-transmettre par la liaison série. Cependant, considérons les choses suivantes :

• Le Raspberry Pi possède un accélérateur matériel pour les liaisons I2C
• Le Raspberry Pi possède aussi des broches de sortie tout ou rien et deux sorties PWM, de quoi contrôler les moteurs
• L'Arduino prend beaucoup de temps à effectuer les calculs en point flottant (environ 7 ms pour simplement calculer la position à partir des informations des codeuses), alors que le Raspberry Pi est beaucoup plus rapide

Il serait beaucoup plus judicieux d'effectuer les calculs de position et d'asservissement directement sur le Raspberry Pi, et s'affranchir complètement de l'Arduino. Et c'est d'ailleurs ce que nous allons faire à partir de maintenant.

Pourquoi ne pas être parti sur cette méthode depuis le départ alors ? La raison principale est qu'il était initialement prévu de réaliser l'asservissement sur le FPGA, et ne faire des calculs de positions qu'à chaque nouvel ordre (soit relativement peu fréquemment). En voyant la possibilité de faire de la fusion de données (pour pouvoir connaitre la position à partir de deux sources, les codeuses et la centrale inertielle), trop compliquée à réaliser sur un FPGA à notre niveau, on a simplement remonté le traitement d'un étage sans se poser de question. Ce qui était une erreur, parce que les calculs en points flottant (qu'on devra utiliser de toute manière si l'on ne veut pas rentrer dans de la théorie mathématique trop poussée pour utiliser des nombres entiers) sur l'Arduino ont une performance très faible. On le savait, mais une autre erreur a été de penser que la latence rajoutée du fait des lents calculs était négligeable par rapport à la latence du Raspberry Pi liée au système d'exploitation. Après avoir vérifié en pratique, il se trouve que c'est même l'inverse.

L'Arduino n'a donc plus aucun rôle à jouer dans le déplacement du robot. Mais le travail réalisé sur la communication Raspberry Pi <-> Arduino et sur la carte de puissance n'est pas perdu puisqu'il y aura toujours un Arduino sur le robot pour réaliser les actions nécessaires pour le client mais hors du contexte du projet. De plus une partie sera réutilisée pour la communication Raspberry Pi <-> FPGA.

Voici donc ci-dessous le système de communication repensé. A noter qu'une confusion avait été aussi faite précédemment sur le système de communication de l'écran LCD, qui est lui aussi en I2C et non en SPI. Cependant cela ne pose pas de problème car le protocole I2C supporte le mode maître-esclave et que l'écran ne sera pas mis à jour très régulièrement.

Semaine 8

Carte de puissance 24V

Nous avons pu tester notre composant de puissance 24V, nous avons ainsi pu noter que : le composant est capable de délivrer un 24V continu on note un décrochage à 8,5V et une tension d'accrochage à 9V. Certaines fonctionnalités des pins Sense et du ON/OFF ont été vérifiée à l'aide d'un potentiomètre mais nous n'en aurons pas l'usage. Cependant pour respecter le choix du client nous garderons toutes les pins disponibles pour assurer la modularité du composant à long terme. Plusieurs modifications doivent donc être ajoutées au design du PCB.

Carte de puissance 10V-5V

Le downconverter de la carte de puissance utilise une résistance pour ajuster la tension de sortie, à partir de la tension d'entrée de la batterie. Afin de la choisir simplement (et parce qu'un ingénieur qui doit faire au moins deux fois la même chose se doit de l'automatiser), nous avons créé un tableur permettant de connaître :

• la résistance selon la tension de sortie
• la tension selon la résistance
• le taux de variation entre les deux tests précédents (pour savoir si l'approximation réalisée est correcte)

Routage LMT18200

Pour ce contrôleur moteur nous sommes partis sur une autre approche, l'idée est de réaliser un PCB permettant le contrôle des deux moteurs directement et utilisant les différents enseignements acquis lors de la conception du PCB destiné au TLE5206.

Pour ce PCB nos objectifs sont dont les suivants :

• Un seul PCB pour contrôler les deux moteurs
• Utilisation de toutes les fonctionnalités offertes pas le LMT (brake, current sense, bootstrap...)
• Optimisation du PCB en terme de place
• Travail sur du double face
• Applications des bonnes pratiques appris durant le routage du TLE5206

Ci-contre se trouve la première version du routage réalisé cette semaine.

Semaine 9

Finalisation du routage

Nous avons modifié le DRC (Design Rule Check) afin de permettre des soudures plus simples. Pour cela nous avons changé la taille de la fraise qui grave le contour des pistes en prenant un diamètre supérieur. Cela permet d'éviter les ponts de soudures et dans l'absolu (même si ici le problème ne se pose pas vu les fréquences utilisées). Cela nous évite également d'avoir des diaphonies en cas de pistes trop proches ou collées entre elles.

Nous avons donc finalisé les 4 PCB :

• La carte de puissance pour les moteurs
• La carte de puissance pour le Raspberry Pi et les autres tâches du robot
• Le contrôleur moteur à base de TLE5206
• Le contrôleur moteur à base de LMT18200

Ce dernier sera en complément usiné en Chine, afin de permettre sa réutilisation pour plusieurs années.

Semaine 10

Routage

Nous avons envoyé à l'usinage les cartes après les derniers ajustements réalisés pendant le weekend.

préparation du robot

Le robot est remonté pour permettre une démonstrations rapide lors de la séance de mercredi. La carte de puissance de l'année dernière a été remise en place avec de nouveaux borniers pour ceux abîmés. Le convertisseur 9V est mort mais nous le savions depuis longtemps.

Problèmes rencontrés et solutions appliquées:

• Un des deux contrôleur moteur qui avait pourtant passé le test lors des soudures s'avèrent défectueux. Une étincelle est apparue au niveau d'un des condensateur qui sera changé. Des tests doivent être refait à basse tension mais la mise en sécurité de l'alimentation et l'échauffement du condensateur ont disparu, il faut à présent vérifier que le pont en H n'a pas été endommagé.
• Tout le câblage a été remplacé avec du câble neuf et bien dimensionné pour les courants passant dedans. De plus nous avons appris lors de nos discussions avec Mr Flamen que l'étamage d'un fil peut engendrer de forts échauffements or un de nos câble était étamé ce qui explique peut être la défaillance du convertisseur 9V de l'année précédente (même si cela est très peu probable car nous n'avons pas ni très fortes tensions ni de très forts courants).

Export Gerber pour usinage de PCB à l'extérieur

Afin de réaliser l'export en gerber de notre PCB nous avons utilisé le fichier CAM suivant[[4]] préconisé par electrow.

Préparation du test de la simulation

Suite aux échanges que nous avons eu avec M. Boé et M. Redon nous avons compris l'importance de la réalisation d'un test grandeur nature de notre système. Pour le moment nous avons développé un simulateur permettant de tester l'algorithme de déplacement du robot afin de ne pas risquer de l'abîmer lors des tests et pour des gains de temps (on simule en quelques secondes un comportement de quelques minutes). Toujours est-il que nous n'avons encore jamais vérifié que ce simulateur est bel et bien un simulateur de notre robot. Nous allons donc mettre en place le protocole suivant dans les plus brefs délais :

• test n°1 : Déplacements basique

Situation : robot équilibré Déplacements : le robot va aller tout droit sur 1m, 2m et 3m. Mesures : nous mesurerons la dérive droite et gauche après chacun des déplacements ainsi que la fiabilité de la distance parcourue (arrêt trop tardif ou trop précoce)

• test n°2 : Déplacements déséquilibrés à droite

Situation : robot déséquilibré sur sa droite par des poids équivalent à environ 30% du poids du robot actuel Déplacements : identiques au test 1 Mesures : identiques au test 1

• test n°3 : Déplacements déséquilibrés à gauche

Identique au test 2 mais à gauche

Afin de mesurer les dérives nous placerons un repère droit au sol à l'aide de scotch rouge ou vert centré sur la roue mobile placé au centre du robot. Nous mesurerons ensuite la distance qui sépare le centre de la roue mobile au scotch à la fin du trajet cela nous indiquera la dérive à l'aide de trigonométrie basique, comme l'illustre le schéma ci-dessous en connaissant AC et AB nous pourrons en déduire Gamma.

Semaine 11

Debugue du TLE5206

Après avoir changé le câblage, les condensateurs et vérifié les pistes du circuits nous en sommes venus à la conclusion que pour une obscure raison les pont en H étaient défaillant. Nous allons donc les dessouder et les remplacer par ceux de rechange. On peut peut-être conclure que ces ponts en H aux rapports prix/fonctionnalités si intéressants sur le papier ne le sont peut-être pas tant que cela dans la réalité. Nous sommes d'autant plus heureux d'avoir anticipé avec la conception des autres contrôleurs LMT18200, beaucoup plus fiable normalement.

Nous avons donc pris la décision de ne pas l'utiliser sur les parties vitales du robot lors de la Coupe de France au profit des LMT18200 jugés plus fiables.

Discussion sur l'agencement du robot

Nous avons discuté avec le responsable mécanique de la coupe de France de l'agencement du robot avec les nouvelles cartes plus modulable. Nous avons envisagés 3 méthodes :

• à l'horizontale avec la construction de plusieurs étages
• à la verticale sur un seul étage ou sur plusieurs avec les cartes les unes derrières les autres
• en carré avec toutes les cartes à la verticale se faisant face.

Certaines parties du robot n'ayant pas encore été complètement conçu nous ne pouvons pas trancher cette question très épineuse surtout en considérant les multiples problèmes que nous avons eu avec les gestions de câbles lors des phases de test. (voir ci-après)

Gestion des câbles: déporter la contrainte

Lors de nos tests nous avons eu beaucoup de difficultés pour maintenir les différents PCB en place sans obtenir de faux contacts ou des câbles débranchées. En faisant part de ce problème avec Mr Boé, il nous a expliqué que la meilleur technique consiste à déplacer la contrainte mécanique en dehors des borniers en utilisant des colliers de serrages attachées à la structure du robot. Nous avons également décidé de changer certaines borniers pour des plus résistants et surtout emboîtable, de cette façon nous pourrons pour certains PCB visser dans un premier temps les câbles puis placer les pcb à l'intérieur du robot et enfin seulement attacher ces borniers, la majorité des difficultés étant rencontrées à l'installation.

Pilotage en courant

Nous nous sommes posés la question du pilotage en courant de nos moteurs. En effet il pourrait être intéressant de les contrôler en courant ne serait-ce que pour réguler le fait qu'il n'y ait pas de surcharge ou pour lisser les accélérations, décélérations... Ou simplement parce que c'est intéressant.

La méthode la plus simple pour piloter facilement en courant nos moteurs consisterait à placer une résistance en sortie de celui-ci et d'utiliser la loi d'ohm pour déduire de la tension mesuré le courant. Cette tension pouvant aisément être lue par le convertisseur CAN d'un arduino. Attention toutefois à bien choisir la valeur de la résistance pour ne pas envoyer une trop grande tension dans l'arduino. Une autre méthode pourrait être d'acheter des capteurs de courants qui ne sont pas si onéreux. De cette façon on peut asservir le moteur en courant bien que le seul moyen reste l'envoi d'une tension découpée de l'alimentation à l'aide d'un contrôleur moteur.

Cet aspect restera uniquement théorique malheureusement par manque de temps et surtout d'intérêt pratique immédiat pour la poursuite du projet.

Contrôle des contrôleurs moteurs

Chaque contrôleur moteur possède plusieurs entrées, soit analogique (dans laquelle une PWM est fournie), soit numérique (tout ou rien). Les premières servent généralement à indiquer la tension à appliquer aux moteurs, les deuxièmes servent généralement à indiquer le sens de rotation, ou de sélectionner le mode frein ou roue libre.

Nous avons donc créé des fonctions permettant le contrôle des moteurs (fonctions avancer, freiner, reculer...) en appliquant les bonnes entrées sur les contrôleurs moteurs reliés aux broches du Raspberry Pi (cf table ci-contre). On remarque que le Raspberry Pi contient uniquement deux sorties PWM matérielles dédoublées, ce qui est suffisant dans notre cas mais aurait été un facteur limitant dans le cas du TLE5206 possèdant deux entrées PWM par contrôleurs.

Pour contrôler les broches du Raspberry Pi, on utilise la bibliothèque wiringPi, qui s'occupe de mettre les broches dans le bon mode (chaque GPIO peut être mis dans un mode différent offrant une fonctionalité différente) et d'effectuer les appels systèmes nécessaires pour mettre à jour la valeur des broches.

Le contrôle des moteurs est désormais fonctionnel, à une exception près : malgré que les valeurs des PWM soient correctes quand mesurées à l'aide d'un multimètre, les moteurs roulent à puissance maximale ou ne roulent pas, ce qui n'est pas le cas quand on les contrôle avec un Arduino. C'est un problème à investiguer.

Semaine 12

Récupération des PCB de puissance et corrections d'erreurs

A la récupération des PCB nous avons pu constater une erreur apparemment classique de la conception. Lors du choix des composants nous avons placé des borniers en les mesurant en millimètres, or le logiciel était paramétré en mil ou en pouces lors de l'export. Nous avons donc obtenu les PCB avec un décalage de 1 millimètre soit un décalage suffisant pour nous empêcher de placer nos borniers.

Nous sommes donc retournés dans les bibliothèques de composants pour modifier l'espacement et renvoyé à l'impression un seul des 3 PCB pour s'assurer que les corrections sont adaptées.

Cette semaine une partie du temps est consacrée à la soudure de tout ces PCB et également celui usiné en Chine : le fameux LMT18200.

câble : gestion de la contrainte mécanique

Nous avons continué de traiter ce problème en travaillant avec le responsable mécanique du robot pour envisager les intégrations possibles évoquées la semaine précédente.

anticipation modification cartes d'alimentation à découpage

Actuellement toutes les cartes sont fonctionnelles et délivre exactement : 4,89V 9,2V 24V

Cela nous permet d'alimenter tout ce dont nous avons besoin en respectant les tensions acceptées sur les différents appareils. En effet la plupart des alimentations secteurs (surtout celles de mauvaises qualités) ne délivrent pas parfaitement 5V et les instruments sont donc souvent tolérants à des tensions comprises entre 5 et 10% entre la tension nominale. Cependant le Easpberry Pi model B+ est très capricieux sur sa tension d'alimentation et il peut facilement "décrocher" ce qui entraîne des reset aléatoirement durant son fonctionnement d'après nos recherches et des tests réalisés à l'aide d'une alimentation réglable.

Afin de se tenir prêt à toute éventualité nous avons mis de côté des potentiomètres, ceux-ci vont nous permettre de placer en parallèle à notre résistance déjà soudés une résistance d'ajustement. Nous avons des potentiomètres qui possèdent un petit écrou qui peut-être serré de façon à bloquer la résistance. A l'aide de ce système en cas de difficulté lors de la Coupe de France nous pourrons réajuster le système très rapidement.

Interruption pédagogique

Première semaine

Durant cette période nous partagerons notre temps entre gestion avec les autres membres travaillant sur le robot (essentiellement pour éviter les incompatibilités de conception entre notre travail et le leur) et progression/tests de notre projet IMA4.

test de la simulation en réel

Suite à la discussion avec nos encadrants nous avions compris l'importance de la réalisation de tests du simulateur qui a été réalisé au cours des semaines précédentes. Cela n'a jamais été aussi vrai vu que lors des tout premiers essais le robot ne s'est pas comporté comme prévu. Nous avons eu un comportement erratique sans comprendre d'où il pouvait provenir. Nous allons donc passer en revue toute les sources de problèmes pour les éliminer une à une, à savoir : câblage défectueux, lecture des codeuses par le FPGA, communication FPGA- Raspberry, asservissement, défaut matériel (contrôleur moteur, codeuse, mécanique), alimentation.

Résolution du contrôle des moteurs

Nous avions vu précédemment que les moteurs tels que contrôlés depuis le Raspberry Pi allaient dans le bon sens mais considérient l'entrée PWM analogique comme une entrée tout ou rien : soit les moteurs tournent à plein régime, soit ils ne tournent pas du tout. Le problème ne se produisant pas lors de nos tests sur Arduino, nous avons essayé de déporter le contrôle des moteurs sur le FPGA, pour voir si cela changeait quelque chose, en vain.

Après quelques recherches plus approfondies, nous nous sommes rendu compte que la capa à l'entrée du contrôleur moteur servait à lisser le signal d'entrée PWM, et la façon dont nous l'avons choisie ne permet d'utiliser des PWM dont la fréquence est au maximum 500 kHz. L'Arduino fonctionne correctement car sa fréquence de génération de PWM est de plusieurs kHz, mais pas le Raspberry étant de base à 19,2 MHz, et pas non plus le FPGA, dont nous avons réalisé la PWM pour une fréquence cible de 700 kHz.

En réduisant la fréquence cible des PWM du FPGA, nous avons pu contrôler les moteurs en toute fluidité. On a remarqué par la suite que la fréquence de génération de PWM du Raspberry Pi est configurable, et peut être changée pour des valeurs tolérées par notre contrôleur moteur, cependant pour des raisons d'optimisation de câblage nous préférereons conserver l'utilisation du FPGA.

tle5206 suite et fin

Les contrôleurs moteurs TLE5206 se sont révélés très décevant en tests, ils ont rapidement été défaillants n'assurant aucune constance dans leurs fonctionnements même lors des tests avec une alimentation de laboratoire et en respectant les schémas typiques proposés dans la datasheet. Vu la nécessité de fiabilité extrême dont nous avons besoin il n'est pas possible de compteur sur eux.

Point rapide sur la soudure : le RoHs

Il avait été soulevé la question des températures tolérées par les différents composants à la soudure, en effet on le sait les microcontroleurs par exemple ne sont jamais soudés à même le système car bien trop sensible aux températures élevées. Dans nos datasheet nous avions pu voir une indication de température à propos des "wave solder temperature" autour de 250° mais aucune concernant une soudure "classique". Dans les petites lignes nous avons cependant vu que le composant répondait à la norme Rohs ("Restriction of Hazardous Substances") qui indique pour les soudures les alliages autorisés ou non et surtout nous indique les températures de soudures pour chaque cas. De cette façon nous avons vu qu'il n'y avait pas de souci à se faire de ce côté là.

Contrôleur moteur différence entre un PCB double face et un PCB industriel

Carte industriel analyse

Lors de nos essais à Polytech de contrôleur moteur nous avions laissé passer une patte normalement relié à la masse au travers d'une piste, cela n'avait pas posé de problème, nous avons juste soudé le composant d'un seul côté et non pas en traversant et le problème était réglé. Cependant lors de l'usinage industriel nous n'avions pas imaginé une certaine différence : l'intérieur des trous est étamé. Cela signifie que lorsque l'on usine un trou pour composant celui ci est relié entre les pistes de chaque côté! Dans le cas de notre PCB cela n'a pas eu de conséquence pour son fonctionnement global. C'est un point tout de même intéressant à prendre en compte à l'avenir.

Solutions et opportunités

Toutefois cette situation nous permet d'envisager une solution très élégante pour le robot. Le problème principal sur notre projet réside au final dans le volume disponible pour la disposition de tout nos éléments au sein du robot, c'est cette contrainte, très forte, qui a conduit à de nombreux choix sur le robot. Suite à la constatation précédentes nous devons donc souder 2 cartes pour contrôler les moteurs en utilisant les PCB usinés à l'extérieur. Cela nous offre donc des PCB beaucoup plus petit et nous pouvons donc exploiter un espace pour le moment inutilisé : l'étage des moteurs! A cet étage se trouve les moteurs, les codeuses et les engrenages allant à la roue, tout ces éléments occupent environ 80% de l'étage et il n'avait donc jamais été envisagé de l'utiliser jusqu'à présent. Mais avec nos nouveaux PCB nous le pouvons à présent et c'est un gain énorme pour le robot et ses étages supérieurs. Cela devrait même nous permettre de ne pas avoir besoin d'intégrer de 3ème étage, entreprise complexe au vue du barillet très massif qui gêne cette proposition.

LM18200T

Le LM18200T a été soudé et est parfaitement fonctionnel sur le robot. Fidèle à sa réputation il permet un contrôle rapide et précis des moteurs sans faille constatée pour le moment. Nous nous sommes mêmes amusés à le pousser dans ses retranchements en bloquant les moteurs à 12V ou en le laissant fonctionner durant plus de 15min pour mesurer si l'échauffement nécessitait un dissipateur passif ou actif. La température est resté raisonnable lors de ces tests donc nous n'en inclurons pas.

Alimentation 5v-10V

Le PCB permettant la conversion du 14V de la batterie en deux tensions utilisables 5V et 10V utilisables pour respectivement le raspberry et le moteur du barillet ainsi que d'une éventuel arduino Mega est fonctionnel. Il a été testé sur alimentation réglable afin de visualiser les écarts en cas de variation de tensions. En effet les batteries Lipo n'offrent pas une tension très stable, en charge complète on peut observer 15.3V et en décharge descendre en dessous de 14.4 V! Dans ces conditions notre cartes à toujours maintenus une tension équivalente ce qui est très positif. Nous avions ici fait le pari d'un PCB très petit au détriment éventuellement de certains composants extérieurs de feedback ou de filtres en comptant sur le fait que les possibles fluctuations pouvant s'opérer seraient tolérer par nos composants, ce qui est parfaitement le cas.

Construction du robot

Les étages du robot précédent ont été démonté. Afin de limiter les court circuit un revêtement en caoutchouc a été placé sur tout l'étage principal. Après relecture du cahier des charges nous avons utilisé une règle étalon avec toutes les mesures (hauteur maximal du robot, de sa balise, hauteurs des différents éléments de jeux influençant le design du robot etc.) ainsi qu'une corde pour vérifier rapidement le périmètre du robot. La partie haute du robot accueillant la balise a été surélevée de plusieurs centimètres, une platforme a été intégré, cela a eu deux effets : de la place disponibles en dessous pour permettre la disposition de cartes, un support bien pratique pour fixer les Lipo qui prennent une place très conséquente.

Disposition des cartes et éléments vitaux sur le robot

Nous avons a disposer les éléments suivants : 1 Lipo placé dans un sac de protection Lipo Safe 1 carte de puissance 24V 1 carte de puissance 5V/10V 2 cartes de contrôleurs moteurs 1 Raspberry pi 1 PCB pour le contrôle d'un moteur Bioloid 1 Arduino Mega ( en discussion avec les autres équipes travaillant sur le robot pour voir à incorporer cette partie dans la raspberry)

Pour cette étape nous avons rajouté un étage sur le robot, cela a pu être fait car le reste des actionneurs étaient choisis et installées et nous savions donc la place qu'il nous restait de disponible.

Capteurs de distance : détermination d'un filtre

Les capteurs de distance sont primordiales, ils nous permettront lors de la coupe de France de calibrer le robot automatiquement et surtout d'éviter les potentiels robots adverses (voir même notre robot secondaire si il existe). Le problème que nous avons déja évoqués est qu'ils sont fortement bruités en environnement "sain" (le fabricarium quand personne ne s'y trouve), lors de la coupe de france l'environnement sera bien pire.

Voici une représentation graphique de ce que renvoi un capteur HSr04 :

Réalisations : Enregistrements des valeurs renvoyés par le capteur dans un fichier texte au format csv : Pour réaliser cela nous échantillonnons notre capteur à 200Hz en renvoyant sur le port série les valeurs. Puis nous avons utilisé putty qui est capable de façon très simple de lire un port série et d'enregistrer les valeurs dans un fichier texte. Après une petite remise en forme des données à coup de sed nous obtenons le graphique présenté plus haut.

Afin de pouvoir tester différents filtres passe bas nous sommes passés par matlab, en bref nous avons : Chargé le fichier csv dans une matrice

Réaliser une FFT sur cette matrice

Remis en forme les valeurs pour pouvoir les afficher et ainsi obtenir ce graphe : Testé différents filtre comme montré ci dessous :

à 5Hz : à 1Hz : à 10Hz : Pour conclure c'est le filtre 10Hz qui l'emporte, il permet un retard négligeable compte tenu de notre constante de temps mécanique (le robot ne se déplacera pas à plus de 8 km/h en moyenne)

Ce filtre sera intégré sur le FPGA.

Point d'attention lié à l'alimentation du robot avec les batteries

Nous avons remarqué quelque chose quelque peu surprenant mais bel et bien non négligeable. Lorsque la batterie baisse en charge, autour de 40% soit 15.1V-15V, la batterie ne délivre plus assez de courant pour alimenter l'ensemble du robot bien que nos tensions au sein du robot restent stable (donc aucune coupure des ordinateurs de bords et moteur alimenté en 24V). La carte de puissance remplit donc bien son rôle mais le courant ne suit plus. Ce problème nous a causé plusieurs fois des soucis car il n'est pas évident à déceler le système fonctionnant toujours mais au ralenti pour les moteurs, nous avons donc souvent suspecter des problèmes d'ordre informatique lié à la commande.

Seconde semaine

Cette semaine a été consacré à l'amélioration du système d'asservissement du robot, l'électronique de puissance et le câblage étant finalisé (il faut toutefois régulièrement lutter contre les branchements chaotique des bénévoles travaillant sur les actionneurs et devant se connecter aux cartes ou aux ordinateurs.

Asservissement en position

Interface Homme-Machine

Afin d'afficher des informations pour le debug de sélectionner des paramètres lors des phases de fonctionnement du robot, un afficheur et des boutons étaient nécessaires. Nous disposions d'un afficheur LCD 16 caractères × 2 lignes contrôlable par une liaison I2C et d'un grand nombre de boutons et d'interrupteurs. Le nombre de paramètres à modifier et de données à afficher n'étant pas très grand, nous avons opté pour un système à base d'écrans. Chaque paramètre modifiable (ex: parcours du robot) et chaque action réalisable (ex : remettre la position à 0) possède son propre écran. On peut passer d'un écran à l'autre à l'aide d'un bouton (le jaune en l'occurence), et changer le paramètre / lancer l'action à l'aide d'un autre bouton (rouge). Cette méthode nous limite donc à des paramètres booléens ou sous forme de liste, mais c'est largement suffisant pour nos besoins. Les informations de debug sont assez nombreuses pour la taille de l'écran, on préferera utiliser les journaux.

L'implémentation des boutons a été réalisée simplement en reliant une broche du bouton à une du Raspberry Pi et l'autre broche du bouton à la masse (la carcasse du robot pouvant servir de masse commune, cela permet de réduire le nombre de fils). Il a ensuite suffit de configurer la broche de l'Arduino en pull-up et de fournir un objet C permettant au reste du programme de les utiliser. L'implémentation de l'écran a été réalisé en paramètrant le fichier /boot/config.txt du Raspberry Pi pour qu'il active la liaison I2C, en activant les modules nécessaires, en créant un objet C pour simplifier la communication I2C (utilisant notamment des verrous pour éviter les conflits), et enfin un objet C pour contrôler l'afficheur LCD.

Le code de l'afficheur LCD a été principalement repris de codes d'exemple pour Arduino. En effet nous n'avons pas étudié en profondeur le fonctionnement de cet écran car ne souhaitions pas utiliser les fonctionalités avancée de l'écran, et si celui-ci venait à devenir défaillant, possédant uniquement des types différents d'afficheur cette étude et le code produit serait devenu obsolète. Cependant, on a remarqué que l'écran se mettait de temps en temps en défaut, affichant des caractères japonais. Ce problème est probablement dû aux modes de l'afficheur (envoi de données sur 8 ou 4 bits) se décalant. En guise de solution créative au problème, nous avons connecté la masse de l'afficheur sur une broche de sortie du Raspberry Pi, permettant de remettre à zéro l'afficheur à volonté (notamment pour les moments critiques).

Enfin, afin de pouvoir contrôler le robot à distance, l'affichage de l'écran a été dédoublé pour être aussi affiché sur la sortie standard lorsque le programme est éxecuté en mode attaché, et les deux boutons peuvent être aussi appuyés en tapant 1 ou 2 dans l'entrée standard. Cela permet un contrôle à distance, certes basique mais amplement suffisant pour nos besoins.

Coupe de France de Robotique

préparatif

Nous avons choisi et inventorié tout le matériel emmené "au cas-où", en ce qui concerne le projet il s'agissait essentiellement de cartes de secours et de composants de secours pour le contrôleur moteur, élément le plus susceptible de défaillir lors de la compétition.

Sur place

Toujours en ce qui concerne le projet nous n'avons pas eu de difficultés majeurs hormis une soudure qui a sauté lors du transport mais qui a été décelé lors des tests préliminaire à l'arrivée. A chaque déplacement du matériel il est conseillé de faire un rapide test de continuité au multimètre puis un essai sous alimentation réglable en courant limité, c'est là que nous avons décelé le problème.

un isolant pas si isolant

Pour isoler nos circuits imprimés du reste de la carcasse métallique nous avons utilisé un caoutchouc déjà disponible dans le matériel de Robotech. Or nous avons découvert que celui-ci n'était pas isolant! Il semble d'après nos recherches que ce caoutchouc soit complété avec du carbone ce qui le rend conducteur, nous avons mesuré une résistance de 300 kΩ sur un échantillon de 10 cm². Cette erreur heureusement ne nous a pas causé de dégradation par chance. Toutefois cet imprévu à demander d'improviser une nouvelle isolation, forcément un peu moins propre, à base de bois et de carton.

Différence entre théorie et pratique lors de la compétition

Lors de notre arrivée à la compétition nous avions à disposition 3 terrains officiels d'entrainement pour plus de 150 équipes. Toutefois nous avons pu tester notre robot et constater que certains paramètres devait être réajuster, notamment au niveau de l'asservissement. Est-ce un problème suite au transport ou lié aux différences entre notre traitement d'entrainement et le terrain officiel? Nous n'avons pas pu le déterminer.

Homologation

Lors de la compétition les robots doivent passer devant les arbitres qui vérifient que le robot respectent les différents points précisés dans le cahier des charges. Tout d'abord on a une vérification statique où le robot est mesuré et inspecté puis une vérification dynamique où le robot est placé en situation sur le terrain pour vérifier son bon fonctionnement et surtout qu'il ne peut pas être un danger pour le robot adverse.

Statique

L'homologation s'est très bien déroulé, les aspects du projet qui ont été évalués n'ont pas posés de problème : - sécurité et contrôle des batteries - présence d'un bouton d'arrêt d'urgence permettant de mettre en sécurité le robot et son environnement - respect des dimensions du robot

Dynamique

L'homologation dynamique a elle été un peu plus délicate notamment parce que l'arbitre a considéré qu'il existait trop d'angle mort dans notre système de détection d'obstacle. Après un simple réajustement des capteurs le problème était résolu. L'asservissement un peu capricieux sur le terrain officiel nous a également causé certains problèmes mais encore une fois après ajustements le robot a été homologué.

Comparatif avec les autres robots

Lors de la compétition nous avons l'occasion d'échangé avec de nombreuses équipes sur les choix techniques fait sur leur robot. Il en ressort plusieurs éléments intéressants :

• très peu d'équipe réalisent eux mêmes leurs circuits imprimés, des cartes toutes faites sont achetés puis mise ensemble voir pour certaines équipes l'ensemble de l'électronique est rassemblé sur une seule et même carte professionnel éludant complètement cette difficulté dans la conception du robot.
• Le langage privilégié par les étudiants restent le C mais on constate par rapport à l'année dernière une croissance des langages haut niveau voir très haut niveaux avec certains robots programmés intégralement en Labview par exemple!
• Le choix des capteurs, nous avons utilisé l'existant car Robotech est souvent difficile à convaincre pour l'achat de nouveau matériel quand il en existe déjà du fonctionnel. Nos capteurs bas de gamme et assez anciens sont très loin de ceux d'adversaires qui comportent souvent beaucoup plus d'informatique embarqué que les notre. C'est une piste à souligner pour les années futurs, cela nous aurait probablement faciliter la tâche pour réaliser l'auto-calibrage du robot qui s'est révélé assez incertain malgré l'implémentation de notre filtre sur FPGA pour filtrer les données.

Un capteur pouvant être un bon candidat pour une montée en gamme serait le SRF10 (20€ environ) qui reste un capteur ultrason donc à large cône (environ 30°) ce qui limite le nombre nécessaire sur le robot pour couvrir tout le périmètre de déplacement. De plus grâce à sa communication en I2C il permet un accès facile et une moins grande utilisation des GPIO de la Raspberry ou de l'arduino. Pour réaliser un auto-calibrage de qualité il faudrait utiliser un capteur dédié de préférence laser sera toujours plus précis qu'un capteur ultrason.

Dernière semaine et conclusion

Lors de cette dernière semaine nous avons tourné une vidéo présentant le travail accomplit et dans quel but. Nous remercions d'ailleurs le cameraman, monteur pour sa patience et son professionnalisme.

Nous avons également finalisé la rédaction du rapport.

Documents Rendus

Rapport : Media:IMA41718P66-Rapport.pdf

Source (code et PCB)

Bibliographie

Datasheet : moteurs : Média:P66_Moteurs_principal.zip