Figure 1.1 - Cahier des charges du phare
Figure 1.2 - Plans du support du phare
Nous sommes allés au plus simple pour l'électronique du phare, ce dernier ayant uniquement de simples tâches à exécuter. Cela nous assure également une robustesse plus importante qu'une commande à l'aide d'une carte à puce.
Figure 1.3 - Schéma électronique du phare
Figure 1.4 - Modèle Catia du bâti du phare
Nous avons choisi une structure en X, semblable à un plateau à hauteur variable. En effet ce système permet un déploiement mécanique du phare ne nécessitant pas d'électronique, et donc pas de batterie, pas de fils, et pas de soudures qui risqueraient de s'user en raison des mouvements amples du phare. L'énergie d'élévation est contenue dans 4 ressorts de traction tendus, situés à la base de la structure en X au niveau des glissières. Ces dernières sont commandées (sous les conseils de Franck Spalony) sur le site d'Igus.
Les ressorts sélectionnés ont les dimensions parfaites pour notre système : 83 mm de longueur libre et 240 mm d'allongement maximum. Nous en avons commandé 10 de la marque RS PRO, au prix de 9€43 le lot. Cela permet de guider chaque pied de la structure en X avec la même force sur une distance de 100 mm. Les ajustements sur le point d'accroche du ressort et les ralentisseurs visqueux (vérins en plastique, joints qui frottent aux points de rotation) sont réalisées sur la maquette réelle.
Le système d'activation est encore incertain bien qu'en partie connu. Nous utiliserons un petit taquet en métal pour bloquer le phare en position basse, puis le robot venant taper dessus, cela libérera les ressorts de leur tension qui se rétracteront. Reste à savoir si le "tout mécanique" suffira (les frottements risquent d'être élevés avec les ressorts tendus) ou si nous devrons utiliser un autre système électrique que celui permettant l'éclairage.
Figure 2.1 - Diagramme SysML des 2 robots
Figure 2.2 - Squelette du grand robot
Figure 2.3 - Schéma cinématique du grand robot
Figure 2.4 - Méchanisme de hissage du pavillon n°1
Figure 2.5 - Méchanisme de hissage du pavillon n°2
Figure 2.6 - Modélisation Catia de l'arbre à cames
Figure 2.7 - Squelette du petit robot
Figure 2.8 - Photo 1 de la pince
Figure 2.9 - Photo 2 de la pince
Figure 3.1 - Photo du plateau de jeu
Figure 3.2 -Schéma des zones de jeu et des éléments d'interaction
Figure 3.3 - Schéma complet du plateau de jeu
Nous avons, pour commencer, décidé d'utiliser comme microcontrôleur la carte FEZ. Cela nous paraissait un bon compromis entre la nouveauté de la technologie et la facilité d'utilisation pour les élèves en BTS électronique de notre équipe. En effet, ils sont habitués à coder pour la Spyder 2 qui est un modèle obsolète du même constructeur. Comme la carte Spyder 2, la carte FEZ se programme en C#. L'intérêt est donc de pouvoir réutiliser au moins une partie des classes codées pour la Spyder 2. De plus, la carte FEZ est toujours en production et en vente par son constructeur, on peut donc l'obtenir à un prix plus de 10 fois inférieur à celui de la Spyder 2 (10 euros au lieu de 120).
Figure 4.1 - Photo de la carte FEZ
Figure 4.2 - Photo de la carte Arduino
Après nous être confrontés aux contraintes techniques, nous avons finalement décidé de privilégier une carte Arduino plutôt qu'une carte FEZ. En effet, l'Arduino présente l'avantage de disposer de plus de pins série et donc nous permet de faire plus de branchements pour communiquer avec d'autres composants comme les servomoteurs et cartes de contrôle. Les librairies disponibles avec la carte Arduino facilitent également le code des commandes.
La carte Sabertooth, plus précisément la Sabertooth 2x12, a été choisi pour ce projet car nous disposions déjà de cette carte de plus c’est une carte idéale pour ce genre de projet car elle permet de contrôler simultanément deux moteurs fonctionnant avec un courant de 12 ampères ainsi que facilement diriger et gérer la vitesse des moteurs. Il permet ainsi de pouvoir contrôler un robot d’un poids maximum de 45 kg.
Figure 4.3 - Photo du hacheur Sabertooth 2x12
Figure 4.4 - Photo de la carte Kangaroox2
Le module Kangaroo, associé à la carte Sabertooth, permet de lire jusqu’à deux encodeurs et ainsi pouvoir contrôler la vitesse et la position des moteurs avec plus de précision. On peut ainsi contrôler les moteurs avec deux modes différents, le mode drive, pour faire tourner les moteurs dans le même sens, et le mode turn, pour faire tourner les moteurs dans des sens opposées. Plus simplement, le mode drive permet d’avancer ou de reculer et le mode turn de tourner. Cependant, avant d’utiliser le module Kangaroo, il faut le calibrer en utilisant le logiciel de Dimension Engineering, DEScribe.
Il partage le signal serial de la carte FEZ entre la carte Kangaroo et le servo moteur AX-12. Nous avons cependant abandonné son utilisation lorsque nous avons remplacé la carte FEZ par la carte Arduino.
Figure 4.5 - Schéma du démultiplexeur
Figure 4.6 - Photo du servomoteur Dynamixel AX-12
Le servomoteur sert à asservir l'axe du moteur. Il ne marche pas pour les roues motrices à cause du patinage. En effet, ce qui nous intéresse étant le déplacement réel du robot et non la rotation des moteurs, nous avons choisi d'ajouter des roues libres plaquées au sol (avec une bonne adhérence grâce à un revêtement en caoutchouc) dont l'axe de rotation est relié à des codeurs incrémentaux. De cette manière on obtient une image plus fidèle du déplacement réel du robot et on améliore l'asservissement.
Ce servomoteur actionne les pinces à gobelet. Son faible poids (9g) et son très bas coût permettent d'en mettre un par pince. Cela confère de l'indépendance aux différentes pinces pour que le robot puisse déposer seulement les gobelets d'une couleur en actionnant les pinces correspondantes.
Figure 4.7 - Photo du servomoteur 9g
Figure 4.8 - Photo du codeur incrémental Kubler
Le codeur incrémental sert à asservir les roues. Notre stratégie quant à l'utilisation de ces codeurs incrémentaux sur les roues libres est décrite dans la rubrique du servomoteur.
Il s'agit de l'écran tactile sur lequel nous indiquons la couleur de l'équipe en début de match.
Nous avons choisi le modèle 2.8 pouces "TFT Touch Shield for Arduino with Resistive Touch Screen".
En effet, il présente l'avantage d'être un écran couleur, tactile et compatible avec Arduino.
Figure 4.9 - Photo de l'écran tactile
Figure 4.10 - Photo de la carte Raspberry
Pour l'analyse liée au module de la caméra qui n'est pas directement rattachée au robot, nous avons décidé d'utiliser une carte Raspberry PI 3 modèle B. En effet, cela facilite les choses pour ce module. On envoie ensuite sans difficulté le résultat à l'Arduino principale par bluetooth.