The Cubl'Istia

Le projetPrésentation du projet

Stabilisation Gyroscopique

DEFINITION

L’origine étymologique du mot : « qui observe la rotation », nous renseigne sur ce qu’est la gyroscopie. En effet un gyroscope est basé sur le principe de la conservation angulaire : c’est un appareil qui donne la position angulaire sur un, deux ou trois axes par rapport à un référentiel inerte.

Cubli 2D

Aussi appelé « One Dimensional Cubli » en anglais, c’est la première étape avant de passer à un Cubli sur 3 axes dont nous parleront plus tard. Ce Cubli 2D constitue donc notre projet, c’est pourquoi nous allons le décrire et en parler un peu. Pour commencer voici un schéma qui illustre la maquette de départ de notre projet :

Nous avons 3 parties sur cette maquette :

• - Un socle qui permet au tout de rester à plat au sol,
• - Sur ce socle est fixé une plaque de forme carrée qui peut pivoter selon l’axe θb (+/- 45°),
• - Au centre de cette plaque est fixé un disque qui peut tourner selon un angle θw (360°).

En plus de ces éléments nous avons une carte moteur, une carte Arduino et une centrale inertielle. Tous ces éléments sont là pour commander le Cubli afin de le stabiliser. En effet en faisant tourner le disque à une certaine vitesse dans un sens ou dans l’autre on doit être capable grâce à l’inertie emmagasinée de faire pivoter la plaque carrée et de la faire tenir en équilibre sans qu’elle repose au sol.

Ce Cubli à une dimension a pour but de vérifier la faisabilité d’un Cubli en 3D dont nous allons parler juste après. Il nous permet de développer les algorithmes de contrôle pour ce Cubli 3D.

La maquette de départ qui nous a été fournie au début du projet comprenait tous les éléments cités plus haut. Cependant nous en reparlerons plus en détail par la suite mais nous avons dû rajouter un élément constitué d’un servomoteur. Ce servomoteur avec fixé dessus une sorte de clé nous a servi pour freiner plus rapidement le disque au moment de le faire tourner dans l’autre sens.

Cubli 3D

Le Cubli 3D est donc la suite logique du Cubli 2D car il reprend le principe de stabilisation gyroscopique mais cette fois-ci pour stabiliser un cube entier et non une face d’un cube. C’est pour cela que nous allons en parler brièvement.

Le but de ce Cubli est de rester en équilibre sur un des coins comme sur la photo ci-dessus. Certains modèles sont également programmés pour se déplacer.

Ce modèle est donc constitué de 3 « Cubli 2D » en quelques sortes. Ce qui lui permet de se mettre en équilibre selon 3 axes et donc sur un sommet.

Ce Cubli a été conçu par l’école polytechnique de Zurich et a été inspiré des systèmes qui permettent aux navettes spatiales et satellites d’ajuster leur attitude.

Le projetPrésentation de l'équipe

Actuellement en deuxième année du cycle d’ingénieur à l’ISTIA, école d’ingénieurs de l’Université d’Angers, nous sommes en spécialité « Automatique et Génie Informatique ».
Notre équipe est composée de trois personnes venues de parcours divers :

Guillaume R.

BAC S (Lycée Saint Michel, 36)
Paces (Tours, 37)
Pass’Med
EI3 AGI (ISTIA, Université d’Angers, 49)

Quentin B.

BAC STI Génie électronique (Lycée Chevrollier d’Angers 49)
DUT Génie Electrique et Informatique Industrielle (IUT d’Angers 49)
Pass’Med
EI3 AGI (ISTIA, Université d’Angers, 49)

Benjamin T.

BAC STI Génie électronique (Lycée Leonard de Vinci, 85)
DUT Génie Industriel et Maintenance (IUT de Saint-Nazaire, 44)
Pass’Med
EI3 AGI (ISTIA, Université d’Angers, 49)

Nos attentes

En effectuant ce projet, nous avions plusieurs attentes :

Premièrement, nous n’avons jamais eu la chance d’approfondir l’effet gyroscopique durant nos études. Ce projet était donc l’occasion de comprendre comment exploiter le principe de la conservation du moment angulaire.

Deuxièmement, nous avions déjà entendu parlé du Cubli 3D. Ce projet était pour nous l’occasion de comprendre comment le système fonctionnait et peut-être même la chance de réussir à reproduire ce système ou du moins, la version 2D.

Pour finir, la possibilité de mettre en pratique beaucoup de matières vues/étudiées durant notre parcours scolaire (microcontrôleur, modélisation et simulation, modélisation 3D, électronique, électricité, mécanique). C’était pour nous, un des projets les plus complet et varié parmi les différents projets de la liste.

Présentation de l'école

l’ISTIA, école d'ingénieurs de l'Université d'Angers, délivre les Diplômes suivant :

• - Ingénieur en Génie des Systèmes Industriels,
• - Ingénieur en Génie Bâtiment et Sécurité,
• - Ingénieur en Génie Biologique et Santé

L’objectif est de former des ingénieurs aptes à mettre en oeuvre les méthodes et des outils permettant d’optimiser la conception, l’élaboration et le fonctionnement des systèmes industriels avec l’objectif d’améliorer la productivité, l’efficacité et la rentabilité des opérations de l’entreprise, dans le respect des facteurs humains et environnementaux. en savoir plus

Travail réaliséProgrammation Arduino

INITIALISATION DU BUS CAN

Serial.begin(115200);
while (CAN_OK != CAN.begin(CAN_500KBPS))
{
	Serial.println("CAN BUS Shield init fail");
	Serial.println(" Init CAN BUS Shield again");
	delay(100);
}
Serial.println("CAN BUS Shield init ok!");

ENVOI DES INFORMATIONS VERS LA CARTE MOTEUR

La carte moteur permet de faire tourner la roue. Nous communiquons que 4 fois avec cette carte :

INITIALISATION

Pour l’initialisation, nous envoyons à la carte moteur le type de moteur que l’on souhaite sur l’id d’initialisation : 0x04.

byte _init[1] = {0x01};
CAN.sendMsgBuf(0x04,0, 1, _init);

AVANCER ET CHANGEMENT DE SENS

Pour avancer, nous envoyons un message de 3 bytes (1 byte pour le sens et la vitesse est codé sur deux bytes). Ici, pour les deux exemples, seul le sens de rotation est inversé.

byte _vitesse[3] = {0x00, 0x04, 0x20};
CAN.sendMsgBuf(0x03,0, 3, _ vitesse);
byte _inverse[3] = {0x01, 0x04, 0x20};
CAN.sendMsgBuf(0x03,0, 3, _ inverse);

ARRET / STOP

Pour dire au moteur que l’on souhaite s’arrêter, nous mettons simplement la vitesse à zéro.

byte _stop[3] = {0x00, 0x00, 0x00};
CAN.sendMsgBuf(0x03,0, 3, _stop);

ENVOI DES INFORMATIONS VERS LE SERVOMOTEUR

La communication avec le servomoteur est utile simplement pour le frein.

INITIALISATION

Nous initialisons le servomoteur en indiquant simplement le port de commande et nous lui indiquons sa position initiale :

Servo myservo;
myservo.attach(9);
myservo.writeMicroseconds(1500);

FAIRE TOURNER LE SERVOMOTEUR

FreinServo(1125) ;
void FreinServo(int pos)
{
	myservo.writeMicroseconds(pos);
	delay(200);
	myservo.writeMicroseconds(1500);
	delay(200);
}

RECUPERATION DES INFORMATIONS DE LA CARTE GYROSCOPIQUE

Cette partie est la plus délicate. Nous n’avons pour le moment, pas réussi à l’effectuer. Voici cependant le code que nous pensons bon. Pour cela, nous pensons utiliser la bibliothèque « Wire ».

RECUPERER LES DONNEES

Pour la récupération des données, nous pensions utiliser le code donné sur le site suivant :

knowledge.parcours-performance.com/ajouter-gyroscope-a-robot-arduino/

Qui utilise lui-aussi cette même bibliothèque afin de récupérer les valeurs d’un capteur gyroscopique pour une carte Arduino

Travail réaliséModelisation 3D

CREATION D’UN FREIN

Le freinage moteur n’étant pas suffisamment puissant pour permettre au système de s’élever, nous avons eu l’idée de rajouter un frein supplémentaire pour augmenter la force.

Pour la modélisation du frein, nous nous sommes basé sur l’assemblage que nous a fourni M. MERCIER.

POSITIONNEMENT DU SERVOMOTEUR

Nous avons passé beaucoup de temps à trouver un emplacement pour le servomoteur. En effet, celui-ci devait être au centre pour ne pas jouer sur le centre de gravité et suffisamment proche du disque pour pouvoir le toucher facilement. Nous avons pensé que le porte moteur était une bonne position.

Nous avons aussi essayé de réaliser un boitier solide pour supporter les chocs et les vibrations.

Voici le modèle final à son emplacement :

BLOCAGE DU DISQUE

Pour le blocage du disque, nous avons décidé de réaliser un bras en métal afin de frotter contre le disque. L’inconvénient de ce système est que seul une petite partie du bras est en contact avec la roue.

Celui-ci sera usinée à partir d’une plaque Sandwich Alu brossé de 3mm d’épaisseur (Alupanel-Dipond). Cette matière a l’avantage d’être très résistent aux chocs et se scie, se plie, de perce, se colle et s’usine très bien.

ASSEMBLAGE

Voici ci-dessous une visualisation du montage souhaité :

Comme on peut le voir, nous avons laissé un peu de place entre le servomoteur et le boitier de fixation pour laisser passer la tête des vis de maintien (7mm d’après nos plans).

Comme on peut le voir sur le modèle ci-dessous, il n’y a pas beaucoup d’espace entre le bras et le châssis (2.3mm). Nous savons ainsi que la précision lors du montage sera très importante et qu’il faudra essayer de limiter au maximum la rotation du bras en cas de jeu.

Travail réaliséElectronique

MATERIEL

Pour ce projet, nous avions à disposition une centrale inertielle (INEMO-M1) et une carte Arduino atMEGA2560. Pour commander et utiliser le capteur. Le but de ce capteur est de nous fournir des informations d’accélération et gyroscopique sur les 3 axes.

Pour communiquer avec cette centrale, il nous a été soumis utiliser le canal de communication I²C. I²C est un bus informatique qui permet une communication facile entre un microcontrôleur (carte Arduino) et un circuit électronique (centrale inertielle). I2C est un bus série synchrone bidirectionnel half-duplex, où plusieurs équipements, maîtres où esclaves, peuvent être connectés au bus. La connexion à ce bus ce bus est réalisée par l’intermédiaire de deux files :

• - SDA (Serial Data Line) qui représente la ligne de donnée
• - SCL (Serial Data Line) qui représente l’horloge de synchronisation bidirectionnelle

Les deux bus sont tirés au Vcc via des résistances de pull-up. Le bus I²C possède 7 bits d’adressage ce qui permet de connecter 128 périphériques et 1 bit R/W pour indiquer l’émetteur et le récepteur.

La vitesse typique de transmission du bus est de 100kbit/s. Cependant, on peut utiliser le bus en mode « fast-mode ». Dans ce cas le bus peut aller jusqu’à une vitesse de transmission de 400kbit/s.

CABLAGE

La centrale inertielle est capable de communiquer via I²C. Grace aux pin 10 & 11 respectivement I2C1_SCl & I2C1_SDA. Nous avons utilisé ces deux branches.

Nous avons connecté le GND à la pin 14, en vérifiant toutefois, grâce à un ohmmètre que tous les GND du capteur était un reliées. Enfin, nous avons choisi de mettre le VCC à la pin 1. Le capteur est alimenté entre 2.4V et 3.6V.

La carte Arduino possède également des broches capables de communiquer en I²C. Il y a deux pins dédiés à cet effet se sont les pin 21 (SCL) & 22 (SDA). Ces entrées/sorties sont contenues dans le port D à l’adresse 0 et 1.

Le carte Arduino et le central inertielle ne fonctionnent pas sous la tension d’alimentation. Pour cela, nous avons dû mettre un dispositif entre les deux périphériques comme ci-dessous.

Le montage présenté est composé de deux résistances de pull-up et d’un transistor FET à canal N. Le montage a été doublé pour chacun des deux canaux (SCL & SDA). Nous avons réalisé ces montages sur une platine d’essai.

Nous développerons dans le chapitre suivant le programme de test pour la communication I²C. Le résultat de ce test fût plutôt médiocre et le test programme test ne reconnaissait pas la centrale. En voici, le résultat recueillit à l’oscilloscope.

On peut voir que les créneaux ne sont pas très nets ce qui doit poser des problèmes de communication. Mr Hassan nous a suggéré de mettre deux portes inverseurs en série afin de jouer le rôle d’hystérésis. Ces portes sont appelées « buffer gate ».

Nous n’avons pas opté pour cette solution. En effets, Mr Mercier nous a proposé de réaliser une carte en prenant un convertisseur 3,3V/5V.

Cette solution pouvant résoudre les problèmes électriques comme les faux contactes. Nous avons réalisé une carte électronique sur Eagle. Nous avons rajouter des résistances de pull-up au schéma électrique ci-dessus afin de répondre aux exigences de protocole I²C.

Les résultats obtenus à la suite de cette carte n’ont pas été ceux escompté. En effet, les tensions semblent varier au-dessus des tensions d’une manière étrange. Nous n’avons pas trouvé le temps de résoudre ce problème.

PROGRAMME DE TEST UTILISE

Les deux programmes utilisés sont les programmes fournis par Arduino pour tester la communication sur le bus i²C. Il suffit de configurer les ports souhaités pour le bus soit dans notre cas les pin 0 & 1 du port D, de mettre le fast-mode à 0. Ils existent deux programmes fournis « I2CScanSoftI2C » & « I2CScanSoftWire », ses deux programmes ont pas la même structure il initialise la communication et ensuite énumère tous les adresses du bus.

Travail réaliséModelisation et Simulation

Le modèle suivi est celui de l’étude intitulé « The Cubli : A Cube that can Jump Up and Balance » par Mohanarajah Gajamohan, Michael Merz, Igor Thommen et Raffaello D’Andre. Nous allons expliquer l’étude qui nous a servi de base.

Les éléments importants du cubli à deux dimensions sont l qui est la longueur entre l’axe du moteur et le pivot au sol, Ib est le moment d’inertie du corps de cubli, Iw est le moment d’inertie de la roue, Cw est le coefficient dynamique de friction de la roue, Cb est le coefficient dynamique de friction du corps de cubli.

La conservation du moment angulaire durant l’impact est décrite par l’équation ci-dessous.

Iwωw = (Iw + Ib + mwl 2 )ωb

L’énergie dégagée est décrite par l’équation ci-dessous :

1/2 (Iw + Ib + mwl 2)ω2b = (mblb + mwl)g(1 − 1 / √ 2 ).

Enfin, l’étude utilise une équation de type x˙(t) = Ax(t) + Bu(t) afin de décrire le système dans sa globalité. X étant composé de (θb, ˙θb, ˙θw) décrivant respectivement l’angle par rapport à la verticale du corps de cubli, la vitesse du corps de cubli et la vitesse de la roue.

ConclusionCe qu'il reste à faire

Suite aux différentes pertes de temps sur les différentes parties, nous n’avons pas eu la chance de finir le projet. Voici ce que nous aurions voulu faire :

MECANIQUE

Nous n’avons pas eu l’occasion de tester le frein pour le moment, mais, nous pensons qu’il faudrait ré-usiner la roue pour réduire son poids. Sa taille resterait la même mais avec des trous. Le visuel

serait ainsi le suivant :

Nous pensons qu’il serait même plus intéressant de réduire l’épaisseur des « rayons » afin de minimiser son poids au milieu et augmenter le poids externe ce qui apporterait l’inertie nécessaire pour le décollage de la roue.

RECUPERATION DES INFORMATIONS

Malgré le temps passé sur la récupération des données en I²C du capteur nous n’avons toujours pas réussi à récupérer des informations de la part de celle-ci. Si le projet est continué dans le futur, nous pensons qu’il pourrait être intéressant d’utiliser le capteur gyroscopique « gy-521 », équipé d’un MPU-6050 qui ne coûte vraiment pas cher et qui est équipé d’un capteur gyro ainsi que d’un accéléromètre (ce qui serait suffisant pour notre cas). De plus, ce capteur semble bien plus simple à utiliser et de nombreux tutoriaux sont disponible sur le WEB. De plus, nous aurions sûrement essayé de tester le capteur sur un autre canaux de communication dont il est équipé pour tenter d’établir une communication plus fiable et plus rapide.

PROGRAMMATION

Sans les informations I²C, nous n’avons pas programmer le sens de rotation du moteur en fonction des différentes données pour permettre cette stabilisation.

AnnexesNos logiciels

LOGICIELS ET TECHNOLOGIES UTILISES

LES LOGICIELS DE MODELISATION 3D

• - SolidWorks : Déjà installé sur les PC de l’ISTIA.
• - Autodesk Inventor : Pour un meilleur rendu 3D. Plus complet que SolidWorks.
• - 3D Builder : Pour modifier l’unité de mesures des pièces sous format STL afin d’éviter les conflits entre les différents logiciels et outils de réalisation 3D (imprimante 3D, Charly Robot).

PROGRAMMATION DES DIFFERENTES CARTES

• - Atmel Studio : pour la programmation de la carte moteur.
• - Arduino : pour celle de notre carte Arduino et son extension atMega2560.

CREATION DE LA CARTE

Nous avons réalisé une carte pour convertir la tension de 5 à 3 volts. Pour cela, nous avons utilisé le logiciel : EAGLE (CadSoft).

PARTAGE DES DONNEES

• - Atlassian Bitbucket : Partage du code en développement. Code non Open Source.
• - Github : Partage du code final. Pour le code Open Source.
• - Git & GitKraken (GIT UI) pour le versionning.
• - Microsoft OneDrive : pour les fichiers image et traitement de texte.

GESTION DE PROJET

• - Excel : pour le Gantt et Scrum.
• - Atlassian Trello : pour créer et gérer nos tâches.