Wiki de Projets IMA - Contributions de l’utilisateur [fr]

IMA3/IMA4 2021/2023 P10

2023-05-09T22:26:43Z

Rfarault : /* Programme du robot */

=='''Résumé'''==

[[Fichier: SegwayRobot.jpg|200px|right|thumb|Exemple de robot similaire au notre]]

Notre projet est de concevoir un robot mobile à deux roues ayant la faculté de s'équilibrer automatiquement. En effet, ne possédant que deux roues, l'équilibre du robot sur son axe vertical est compromis, a la manière d'un '''segway'''.
Afin d'empecher ce désequilibre, nous avons pensé à intégrer au robot un système de contrôle de son angle vertical, utilisant des capteurs et des actionneurs mis en relation par une boucle de régulation automatique.
Les composants electroniques et mécaniques du robot nous étant fournis, notre travail consiste donc surtout à étudier ce système, pour ensuite concevoir un asservissement, et l'implémenter dans notre robot.

L'intégralité de notre programme est disponible sur le dépôt git à l'adresse: https://gitlab.com/remi_farault/self-balanced-robot

=='''Présentation générale'''==

==🌏Contexte==
Les moyens de transport actuels reposent principalement sur le principe du robot à deux roues, c'est la raison pour laquelle l'étude de celui ci s'avère importante, en effet l'étude
de sa conception et son contrôle va nous permettre de développer des outils innovants qui pourraient potentiellement intéresser des sociétés de transport .

==🎯Objectif==

Notre objectif principal est de commander le robot, de là interviennent d'autres objectifs tel que la stabilité ,développer un code robuste qui assure cette fonctionnalité et aussi le contrôler pour réaliser des fonctionnalités de déplacement et d'éviter des obstacles . Des objectifs secondaires sont de créer un site web à travers lequel nous allons mener toutes les opérations de contrôle .

==🔍Expression du besoin==

Un robot autoéquilibré à deux roues est un type de robot qui peut se maintenir en équilibre sur deux roues sans tomber. Pour réaliser cette fonctionnalité, le robot utilise un ensemble de capteurs, d'algorithmes de contrôle et de moteurs pour ajuster sa position en temps réel.

[[Fichier:Self_balanc_bt.png|400px|Bete a corne SBR]]

Le diagramme interacteurs permet en fait de visualiser les fonctions services assurées par le système

[[Fichier:341702419_560921119358434_1016673599353874396_n_(1).png|400px|DGI SBR]] [[Fichier:Btacorne.png |500px|DGI SBR|right]]

=='''Réalisations et Résultats'''==
[[Fichier: seg.jpg|200px|left|thumb|Exemple de commande désirée]]

Après mis en place notre stratégie de gestion de projet en s6 à travers le diagramme de GANTT et le cahier de charges fonctionnels, nous nous sommes focalisés sur l'étude technique.

[[Fichier: progg.png|300px|right|thumb|Organisation de notre programme]]

Tout d'abord, étudier à travers des outils automatiques la stabilité du robot en faisant appel à des modèles théoriques et pratiques et commencer par un raisonnement par niveaux, d'abord le niveau 1 du moteur à courant continu et les équations correspondantes puis le niveau 2 assurant la stabilité du robot directement, on avait la possibilité de passer directement au niveau 2 à travers le modèle du pendule inversé et les équations qui en découlent sauf que celui-ci ne nous permettra pas de revenir au niveau 1 et asservir le moteur à travers les codeurs incrémentales ,la deuxième partie consistait à réaliser les codes informatiques en s'appuyant sur les structures de données en C vues l'année dernière et conduire un même raisonnement(par niveaux) s'appuyant d'abord sur les codes sources correspondants à la génération d'un signal PWM pour les deux moteurs avec un rapport cyclique modifiable, et aussi les codes sources correspondants à la gestion des moteurs, en effet, ceux-ci tournent dans un sens ou dans un autre ou ne tournent pas en fonction de la variable in1 et in2 pour faire tourner les moteurs .

[[Fichier: Avr.png|100px|left|thumb|Compilateur utilisé]]

Cependant, nous avons rencontré quelques problèmes en automatique notamment pour trouver des valeurs des constantes théoriques pour les références du moteur entre les mains, ce qui nous a obligé à prendre des valeurs issues d'autres applications, nous avons rencontré aussi quelques problèmes choisir une modélisation parmi celles qui sont disponibles sur Internet .

=='''Etude Automatique'''==

Avant de programmer notre système sur la carte Arduino, nous avons également créé une simulation complète de notre système robotisé sur SIMULINK. Cependant, avant cela, nous avons dû déterminer les équations qui régissent notre système en trouvant les matrices d'inertie de chaque composant de notre robot, à savoir la masse transportée par le robot (M), le châssis constitué de deux plateaux et de la motorisation (les piliers et leur inertie ont été négligés car leur masse est très faible), ainsi que les roues (roue droite et roue gauche). Vous trouverez ci-dessous les matrices d'inertie que nous avons obtenues pour chaque composant.

'''Masse M :'''

[[Fichier:MatM.png|200px|thumb|left|Matrice de la masse M]]

Les coefficients seront notés dans la suite pour simplifier : AM,BM,CM

'''Chassis:'''

[[Fichier:MatB.png|800px|Matrice du chassis]]

Les coefficients de la diagonale seront notés dans la suite pour simplifier : AH,BH,CH

'''Roue gauche:'''

[[Fichier:Matrg.png |600px|Matrice de RG]]

Les coefficients de la diagonale seront notés dans la suite pour simplifier : AD,BD,CD

'''Roue droite:'''

[[Fichier:Matrd.png |600px|Matrice RD]]

Les coefficients de la diagonale seront notés dans la suite pour simplifier : AD,BD,CD

Ci-dessous un paramétrage de notre système : Chaque angle détermine un repère

Le repère R0 est supposé galliléen.

Le repère R1 est en rotation ,appelé angle de virage par rapport à R0.

Le repère R2 est en rotation ,appelé angle d’inclinaison du châssis par rapport à R0 .

Le repère R3 est en rotation ,appelé angle d’inclinaison arrière-avant de la masse par rapport à R0 .

Le repère R4 est en rotation ,appelé angle d’inclinaison droite-gauche de la masse par rapport à R0 .

[[Fichier:param.png |800px|Matrice du chassis]]

l’angle de consigne est de 0deg,nous employons un PID pour corriger l’angle de mesure,à sa sortie,on aura une tension W(p).Les blocs Km et W(p) assurent le passage tension->couple->angle ,il faut ensuite retirer pour ne garder que l’angle d’inclinaison du châssis .Km=0.0125N.m.V-1(d’après la datasheet du moteur)

[[Fichier:Bcle.png |800px|Asservissement]] [[Fichier:Matuu.png|right|800px|Asservissement]]

Les équations obtenues sont les suivantes (Le détail des calculs a été précisé dans le Rapport):

[[Fichier:Eq nnlin.png |500px|Asservissement]]

Après linéarisation : Considérer l'approximations des petits angles pour le sinus et cosinus,et négliger aussi la vitesse angulaire quadratique devant la vitesse angulaire,nous obtenons :

[[Fichier:Eqlin.png |300px|Asservissement]]

[[Fichier:Crbe.png|600px|Courbe]]

On obtient une courbe avec un bon temps de réponse, un léger dépassement et une stabilité .Le système est régulé de manière efficace, capable de répondre rapidement et précisément aux perturbations tout en maintenant une position d'équilibre stable.

[[Fichier:Mat3d.png|500px|Asservissement]]

=='''Environnement de developpement'''==

Notre microcontrolleur étant une Arduino Uno, nous aurions pu utiliser le framework ''Arduino'' donnant accès à un IDE intégrant les outils pour compiler et flasher le code, ainsi qu'une multitude de bibliothèques haut niveaux très simples d'utilisation et plutôt performantes, permettant de programmer notre robot en simplement quelques dizaines de lignes de code.

Cependant, l'Arduino est simplement une carte de prototypage intégrant un microcontrôleur ''AVR Atmega 328p''.
Les microcontroleurs AVR disposent d'une grande communauté, et il existe de nombreux outils nécessaires au developpement sur ces cartes.
Afin d'avoir un meilleur contrôle sur notre projet, et surtout d'en tirer un maximum de compétences, nous avons donc décidés de programmer notre robot directement en C en utilisant les outils AVR:

- '''avr-gcc''': compilateur open-source portant toutes les fonctionnalités du langage C standard sur les microcontroleurs AVR.
Seul, son utilisation est quasiment impossible et demande trop de travail en programmation bas-niveau.

- '''avr-libc''': implémentation basé sur le compilateur avr-gcc de la bibliothèque standard du langage C.
Cette bibliothèque permet donc d'utiliser les fonctions et structures standards du C (IO, maths, chaines de caractères), mais elle intègre également un mapping mémoire de tous les registres de l'atmega, ainsi qu'un mécanisme pour programmer des interruptions.

- '''avr-objcopy''': ce programme en ligne de commande formate le binaire obtenu en format utilisable par les AVR

- '''avr-dude''': ce programme en ligne de commande permet de flasher via une interface USB-série un microcontroleur AVR présent sur une carte Arduino.

Nous avons donc developpé un '''Makefile''' utilisant tous ces outils, constituant un environnement de developpement très efficace pour notre projet. Ce Makefile est disponible sur notre gitlab.

=='''Programme du robot'''==

==='''PWM'''===

La première étape consistait à commander nos moteurs DC, afin de poser les bases de notre
asservissement bas niveau. Ces moteurs sont contrôlés par le driver de moteurs, utilisant des signaux logiques pour définir l’état d’un moteur et des signaux '''PWM''' pour définir la vitesse de
rotation. La génération de signaux PWM sur AVR se fait en utilisant les '''timers''' en mode PWM.
Tout simplement, nous avons un registre compteur 16 bits incrémenté périodiquement, et une valeur
maximale définie par le registre ''ICRx''. Nous utilisons ensuite les registres ''OCRnx'' contenant une
valeur inférieure au maximum.
Lorsque le compteur atteint la valeur contenue dans OCRnx, il
inverse la valeur logique de sortie du pin ''OCnx''. Ainsi, nous pouvons modifier instantanément la
valeur d’OCRnx afin de modifier le rapport cyclique de notre signal. Ce rapport cyclique est ensuite
directement proportionnel à la vitesse de rotation du moteur associé.
La fréquence du signal est définie par la période d’incrémentation du compteur et par la valeur maximale ICRx.
Pour notre composant, nous pouvions utiliser une fréquence allant jusqu’à plusieurs kHz. Cette
fréquence n’a aucun impact sur la rotation du moteur. Nous avons donc choisis 20 kHz.
Nous avons définis la '''init_pwm''' pour configurer les registres nécessaires, et la fonction
'''generate_pwm''' pour modifier le rapport cyclique de nos deux signaux PWM avec la valeur
souhaitée.

==='''Encodeurs'''===

Une fois nos moteurs pouvant tourner à une vitesse voulue, nous avons du trouver un moyen de
mesurer leurs vitesses effectives afin de réaliser une boucle d’asservissement. Pour cela, nous avons
utilisés les encodeurs optiques disponibles sur nos moteurs DC.
Ces encodeurs envoient sur leur broches un front-montant à chaque tour de la roue codeuse reliée au moteurs (ayant une vitesse
proportionnelle à celle du moteur). En détectant ces fronts montant, nous pouvons donc compter le
nombre de tours du moteur pendant un intervalle de temps défini, puis déterminer la vitesse réelle
du moteur.
Pour détecter les fronts montant, nous utilisons l’interface '''Pin Change Interrupt''' de l’Atmega. Cette
interface exécute une interruption logicielle à chaque changement d’état logique du pin associé.
Dans notre cas, nous devons ensuite observé l’état précédent de la sortie et l’état actuel pour
déterminer si on est bien en présence d’un front montant. Une fois le front montant détecté, cette
interruption incrémente ensuite le compteur de tours.
Ce compteur est ensuite utilisé pour calculer la vitesse de rotation puis remis à zéro pour la mesure
suivante.
Dans notre cas, nous réalisons cette mesure à une fréquence d’environ 244 Hz, dans une autre
fonction d’interruption qu’on détaillera plus loin.

==='''Angle'''===

Notre boucle de régulation principale a besoin d’une mesure de l’angle d’inclinaison du robot sur
son axe vertical perpendiculaire à celui de déplacement. Cette mesure s’effectue via le '''MPU6050'''.
Ce composant fonctionne via le protocole '''i2c''', protocole de communication simple utilisé par la
plupart des systèmes électroniques. Ce protocole étant bas niveau, il existe de nombreuses
bibliothèques implémentés en C permettant son utilisation. De plus, le MPU6050 est un composant
très complet et complexe, afin d’en récupérer l’angle, il faut d’abord amorcer une communication
i2c puis configurer certains des ses registres, afin ensuite de pouvoir lire les registres contenant la
mesure de l’angle selon l’axe désiré. Afin de conserver un code efficace et concis, nous avons
également décidés d’utiliser une bibliothèque faisant office de « '''driver''' » pour ce composant,
intégrant des fonctions d’initialisation et de lecture des mesures faites par ce gyroscope.
Nous obtenons donc la valeur de l’angle en degrés, comprise entre 0 et 360.Dans notre cas, nous souhaitions obtenir une valeur comprise entre -180 et 180, car seule la valeur
absolue et le sens de l’inclinaison nous intéresse, nous avons donc appliqués une correction de cette
valeur.

==='''Interruption principale'''===

Lors de implémentation d’un asservissement automatique via un microcontrôleur, la puissance de
calcul finie impose que les commandes des actionneurs et les mesures des capteurs doivent être
réalisées périodiquement. Pour cela, nous pouvons utiliser une '''routine d’interruption''' qui s’exécute à
chaque ''overflow'' d’un compteur, via l’interface des '''timers''' de l’atmega. Dans notre cas, cette
interruption correspond à la fonction principale de notre programme. Nous avons réglés sa
fréquence à 244Hz, en divisant le fréquence de base de 16MHz avec un '''prescaler''' de 256 (plus une
deuxième division par 256 du à la taille du registre timer de 8 bits).
Cette interruption vient d’abord remettre a zéro les compteurs des encodeurs et récupérer la vitesse
des deux moteurs.
Ensuite, elle effectue les calculs nécessaires à la régulation de l’angle, mais également de la vitesse
linéaire et de la rotation du robot.
Chaque paramètre à réguler est corrigé par un régulateur PID de coefficients différents via la
fonction '''pid()'''.
Enfin, nous obtenons une commande à envoyer aux moteurs, qui actionnent notre robot de la
manière souhaitée.
Le code de notre système est disponible sur nôtre dépôt gitlab également.

=='''Gestion de projet'''==

Durant ces trois semestres, la gestion de projet est un des domaines où nous avons le plus de difficultés, mais également un de ceux dans lequel nous avons le plus appris.

Voici notre Diagramme de Gantt previsionnel réalisé au S6
[[Fichier:Gt.png|400px|thumb|left|texte descriptif]]

D'abord trois, nous nous sommes retrouvés à deux dès le deuxième semestre, et nous avons donc du modifier l'organisation prévue pour la suite.

Nous avons au final plus ou moins suivis ce diagramme previsionnel, à quelques choses près.

En travaillant à deux, nous avons du trouvé un moyen d'avancer efficacement.
L'un de nous étant en filière SA (Systemes Autonomes) et l'autre en filière SC (Systemes Communicants), la répartition des taches informatiques et automatiques était donc simplifiée.

Cependant, nous avons donc du réussir à expliquer et à mettre en relation chacune de nos parties, en s'améliorant sur la partie communication.
Pour cela, au début de chaque séance, nous commencions par faire le point sur l'avancement globale et propre à chacun.

Ensuite, nous nous répartitions les taches communes aux différentes parties.

Enfin, nous échangions sur les taches respectives à nos deux parties afin de pouvoir les faire coincider le moment venu, et il est arrivé plusieurs fois que l'on s'aide réciproquement chacun sur la partie de l'autre.

Globalement, cela a été positif car nous avons pu tous les deux sortir de notre zone de confort et apprendre beaucoup dans différents domaines.

Comme outils, nous utilisions donc git et gitlab pour la gestion de code et google drive pour le partage de documents.

Nous avons préferés travailler un maximum en présentiel, d'un accord commun.

== Semestre 6 ==

'''Séance du 01/03/22'''

Séance de découverte du sujet de notre projet.

Recherche de l'existant

Réalisation de recherches sur leurs différentes utilisations.

'''Séance du 08/03/22'''

Début de création du diagramme de Gantt .

Réalisation d'une étude du besoin.

'''Séance du 15/03/22'''

Etude du marché : Recherche des robots similaires.

Commencer à prendre en main le robot.

'''Séance du 22/03/22'''

Poursuite de l'étude de marché.

Etude des opportunités.

'''Séance du 29/03/22'''

Fin d'étude du marché.

Commencer à rédiger le cahier des charges.

'''Séance du 05/04/22'''

Commencer la rédaction du cahier des charges.

'''Séance du 26/04/22'''

Bilan du semestre.

Etude de faisabilité.

Etude des risques.

'''Séance du 03/05/22'''

Finalisation de l'étude des risques.

Finalisation de l'étude de faisabilité.

Finalisation du cahier des charges.

== Semestre 7 ==

'''Séance du 10/10/22'''

Commencement de l'étude technique des encodeurs .
Recherche des boucles d'asservissement du robot .

'''Séance du 21/10/22'''

Etude du changement de la carte arduino pour ajouter des nouvelles fonctionnalités : connexion Wifi, fréquence microprocesseur plus élevé,..
Test des encodeurs moteur DC : validé .
Poursuite de recherche des boucles d'asservissement du robot .

'''Séance du 28/10/22'''

Etude de génération des signaux PWM

Test sur Matlab Simulink des boucles d'asservissement issues des robots similaires .

'''Séance du 18/11/22'''

Poursuite de la programmation des signaux PWM du robot.

Calcul de la fonction de transfert issue de la boucle.

'''Séance du 21/11/22'''

Etude du fonctionnement du gyroscope et des autres composants pour programmer le robot .

Séparation du travail a effectuer pour le robot entre une boucle du moteur DC(niveau 1) et une boucle du niveau supérieur(niveau 2) pour asservir l'angle d'inclinaison du robot.

'''Séance du 25/11/22'''

Modification et amélioration du diagramme de Gantt pour le S7 et le S8.

Avancée de la modélisation de la boucle du niveau 1 .

Diagramme de Gantt S7-S8

'''Séance du 28/11/22'''

Fin d'implémentation de la boucle du niveau inférieur sur Matlab/Simulink et récupération des résultats sur le scope .

'''Séance du 08/12/22'''

Poursuite de la partie informatique et avancement de la partie automatique .
Programmation de la liaison série pour débugger les sorties de notre robot .

'''Séance du 15/12/22'''

Début de rédaction du rapport pour le S7

== Semestre 8 ==

'''Séance du 18/01/23'''

Recherches pour le gyroscope .
Test des encodeurs .
Communication sur les attentes du semestre s8 ,les fautes à éviter pour rebondir par rapport au retard S7
Mise à niveau pour comprendre les aspects techniques de la partie informatique pour pouvoir travailler ensemble sur les résultats du S8 .

'''Séance du 25/01/23'''

- Suppression des structures de données pour avancer plus rapidement sur les résultats du semestre s8 .

- Recherches pour la programmation des interruptions PCINT .

- Recherche sur la doc technique pour faire l'initialisation des interruptions externes .

- Recherche de la modélisation en 3D de notre robot pour trouver les paramètres PID de notre robot .

'''Séance du 01/02/23'''

Durant cette séance, nous avons :

Modification du code des encodeurs et test sur les moteurs DC .

Poursuite de recherche de l'existant pour trouver le code du gyroscope .

Mise à jour du git .

Début du calcul des matrices d'inertie de chaque solide.

Recherche du code des régulateurs.

Avancement sur la gestion de projet .

'''Séance du 08/02/23'''

Durant cette séance, nous avons essayé de récupérer les résultats des tests électronique de l'oscilloscope effectués dans les salles d'électronique .

Le code des encodeurs marchent ,la liaison série affiche exactement la vitesse de la consigne :les Régulateurs implémentés correspondent bien à notre applications.

Poursuite de la programmation de la partie informatique du gyroscope : Objectif : récupération de l'angle d'inclinaison sur la liaison série avec la meilleure précision possible .

'''Séance du 15/02/23'''

Fin du calcul des matrices d'inertie .

Paramétrage de notre robot pour avoir la visibilité sur les configurations possibles d'avoir(en virage, ligne droite),en précisant les angles d'inclinaison et es repères associés .

Poursuite de programmation des régulateurs par niveaux en utilisant le code précédemment implémenté pour les encodeurs .

'''Séance du 01/03/23'''

Fin d'implémentation du modèle en 3D de notre robot pour essayer de l'autoéquilibrer en utilisant les PIDS issues de l'autotune par rapport à nos préférences(stabilité,temps de réponse,dépassement,précision).

Nous avons testé le robot en l'alimentant par le biai la liaison USB ! et enregistrement des résultats .

Poursuite de la partie automatique en trouvant toutes les équations nécessaires à notre modèle .

'''Séance du 08/03/23'''

Réalisations de cette séance :

Test du robot pour se stabiliser sur le sol en applicant plusieurs .

Faire tous les calculs des dimensions géométriques de notre robot et test de la boucle d'asservissement avec les deux niveaux sur Matlab Simulink avec nos préférences de stabilité, temps de réponse,précision,dépassement .

'''Séance du 15/03/23'''

Absence justifiée .

IMA3/IMA4 2021/2023 P10

2023-05-09T21:13:34Z

Rfarault : /* Programme du robot */

=='''Résumé'''==

[[Fichier: SegwayRobot.jpg|200px|right|thumb|Exemple de robot similaire au notre]]

Notre projet est de concevoir un robot mobile à deux roues ayant la faculté de s'équilibrer automatiquement. En effet, ne possédant que deux roues, l'équilibre du robot sur son axe vertical est compromis, a la manière d'un '''segway'''.
Afin d'empecher ce désequilibre, nous avons pensé à intégrer au robot un système de contrôle de son angle vertical, utilisant des capteurs et des actionneurs mis en relation par une boucle de régulation automatique.
Les composants electroniques et mécaniques du robot nous étant fournis, notre travail consiste donc surtout à étudier ce système, pour ensuite concevoir un asservissement, et l'implémenter dans notre robot.

L'intégralité de notre programme est disponible sur le dépôt git à l'adresse: https://gitlab.com/remi_farault/self-balanced-robot

=='''Présentation générale'''==

==🌏Contexte==
Les moyens de transport actuels reposent principalement sur le principe du robot à deux roues, c'est la raison pour laquelle l'étude de celui ci s'avère importante, en effet l'étude
de sa conception et son contrôle va nous permettre de développer des outils innovants qui pourraient potentiellement intéresser des sociétés de transport .

==🎯Objectif==

Notre objectif principal est de commander le robot, de là interviennent d'autres objectifs tel que la stabilité ,développer un code robuste qui assure cette fonctionnalité et aussi le contrôler pour réaliser des fonctionnalités de déplacement et d'éviter des obstacles . Des objectifs secondaires sont de créer un site web à travers lequel nous allons mener toutes les opérations de contrôle .

==🔍Expression du besoin==

Un robot autoéquilibré à deux roues est un type de robot qui peut se maintenir en équilibre sur deux roues sans tomber. Pour réaliser cette fonctionnalité, le robot utilise un ensemble de capteurs, d'algorithmes de contrôle et de moteurs pour ajuster sa position en temps réel.

[[Fichier:Self_balanc_bt.png|400px|Bete a corne SBR]]

Le diagramme interacteurs permet en fait de visualiser les fonctions services assurées par le système

[[Fichier:341702419_560921119358434_1016673599353874396_n_(1).png|400px|DGI SBR]] [[Fichier:Btacorne.png |500px|DGI SBR|right]]

=='''Réalisations et Résultats'''==
[[Fichier: seg.jpg|200px|left|thumb|Exemple de commande désirée]]

Après mis en place notre stratégie de gestion de projet en s6 à travers le diagramme de GANTT et le cahier de charges fonctionnels, nous nous sommes focalisés sur l'étude technique.

[[Fichier: progg.png|300px|right|thumb|Organisation de notre programme]]

Tout d'abord, étudier à travers des outils automatiques la stabilité du robot en faisant appel à des modèles théoriques et pratiques et commencer par un raisonnement par niveaux, d'abord le niveau 1 du moteur à courant continu et les équations correspondantes puis le niveau 2 assurant la stabilité du robot directement, on avait la possibilité de passer directement au niveau 2 à travers le modèle du pendule inversé et les équations qui en découlent sauf que celui-ci ne nous permettra pas de revenir au niveau 1 et asservir le moteur à travers les codeurs incrémentales ,la deuxième partie consistait à réaliser les codes informatiques en s'appuyant sur les structures de données en C vues l'année dernière et conduire un même raisonnement(par niveaux) s'appuyant d'abord sur les codes sources correspondants à la génération d'un signal PWM pour les deux moteurs avec un rapport cyclique modifiable, et aussi les codes sources correspondants à la gestion des moteurs, en effet, ceux-ci tournent dans un sens ou dans un autre ou ne tournent pas en fonction de la variable in1 et in2 pour faire tourner les moteurs .

[[Fichier: Avr.png|100px|left|thumb|Compilateur utilisé]]

Cependant, nous avons rencontré quelques problèmes en automatique notamment pour trouver des valeurs des constantes théoriques pour les références du moteur entre les mains, ce qui nous a obligé à prendre des valeurs issues d'autres applications, nous avons rencontré aussi quelques problèmes choisir une modélisation parmi celles qui sont disponibles sur Internet .

=='''Etude Automatique'''==

Avant de programmer notre système sur la carte Arduino, nous avons également créé une simulation complète de notre système robotisé sur SIMULINK. Cependant, avant cela, nous avons dû déterminer les équations qui régissent notre système en trouvant les matrices d'inertie de chaque composant de notre robot, à savoir la masse transportée par le robot (M), le châssis constitué de deux plateaux et de la motorisation (les piliers et leur inertie ont été négligés car leur masse est très faible), ainsi que les roues (roue droite et roue gauche). Vous trouverez ci-dessous les matrices d'inertie que nous avons obtenues pour chaque composant.

'''Masse M :'''

[[Fichier:MatM.png|200px|thumb|left|Matrice de la masse M]]

Les coefficients seront notés dans la suite pour simplifier : AM,BM,CM

'''Chassis:'''

[[Fichier:MatB.png|800px|Matrice du chassis]]

Les coefficients de la diagonale seront notés dans la suite pour simplifier : AH,BH,CH

'''Roue gauche:'''

[[Fichier:Matrg.png |600px|Matrice de RG]]

Les coefficients de la diagonale seront notés dans la suite pour simplifier : AD,BD,CD

'''Roue droite:'''

[[Fichier:Matrd.png |600px|Matrice RD]]

Les coefficients de la diagonale seront notés dans la suite pour simplifier : AD,BD,CD

Ci-dessous un paramétrage de notre système : Chaque angle détermine un repère

Le repère R0 est supposé galliléen.

Le repère R1 est en rotation ,appelé angle de virage par rapport à R0.

Le repère R2 est en rotation ,appelé angle d’inclinaison du châssis par rapport à R0 .

Le repère R3 est en rotation ,appelé angle d’inclinaison arrière-avant de la masse par rapport à R0 .

Le repère R4 est en rotation ,appelé angle d’inclinaison droite-gauche de la masse par rapport à R0 .

[[Fichier:param.png |800px|Matrice du chassis]]

l’angle de consigne est de 0deg,nous employons un PID pour corriger l’angle de mesure,à sa sortie,on aura une tension W(p).Les blocs Km et W(p) assurent le passage tension->couple->angle ,il faut ensuite retirer pour ne garder que l’angle d’inclinaison du châssis .Km=0.0125N.m.V-1(d’après la datasheet du moteur)

[[Fichier:Bcle.png |800px|Asservissement]] [[Fichier:Matuu.png|right|800px|Asservissement]]

Les équations obtenues sont les suivantes (Le détail des calculs a été précisé dans le Rapport):

[[Fichier:Eq nnlin.png |500px|Asservissement]]

Après linéarisation : Considérer l'approximations des petits angles pour le sinus et cosinus,et négliger aussi la vitesse angulaire quadratique devant la vitesse angulaire,nous obtenons :

[[Fichier:Eqlin.png |300px|Asservissement]]

[[Fichier:Crbe.png|600px|Courbe]]

On obtient une courbe avec un bon temps de réponse, un léger dépassement et une stabilité .Le système est régulé de manière efficace, capable de répondre rapidement et précisément aux perturbations tout en maintenant une position d'équilibre stable.

[[Fichier:Mat3d.png|500px|Asservissement]]

=='''Environnement de developpement'''==

Notre microcontrolleur étant une Arduino Uno, nous aurions pu utiliser le framework ''Arduino'' donnant accès à un IDE intégrant les outils pour compiler et flasher le code, ainsi qu'une multitude de bibliothèques haut niveaux très simples d'utilisation et plutôt performantes, permettant de programmer notre robot en simplement quelques dizaines de lignes de code.

Cependant, l'Arduino est simplement une carte de prototypage intégrant un microcontrôleur ''AVR Atmega 328p''.
Les microcontroleurs AVR disposent d'une grande communauté, et il existe de nombreux outils nécessaires au developpement sur ces cartes.
Afin d'avoir un meilleur contrôle sur notre projet, et surtout d'en tirer un maximum de compétences, nous avons donc décidés de programmer notre robot directement en C en utilisant les outils AVR:

- '''avr-gcc''': compilateur open-source portant toutes les fonctionnalités du langage C standard sur les microcontroleurs AVR.
Seul, son utilisation est quasiment impossible et demande trop de travail en programmation bas-niveau.

- '''avr-libc''': implémentation basé sur le compilateur avr-gcc de la bibliothèque standard du langage C.
Cette bibliothèque permet donc d'utiliser les fonctions et structures standards du C (IO, maths, chaines de caractères), mais elle intègre également un mapping mémoire de tous les registres de l'atmega, ainsi qu'un mécanisme pour programmer des interruptions.

- '''avr-objcopy''': ce programme en ligne de commande formate le binaire obtenu en format utilisable par les AVR

- '''avr-dude''': ce programme en ligne de commande permet de flasher via une interface USB-série un microcontroleur AVR présent sur une carte Arduino.

Nous avons donc developpé un '''Makefile''' utilisant tous ces outils, constituant un environnement de developpement très efficace pour notre projet. Ce Makefile est disponible sur notre gitlab.

=='''Programme du robot'''==

[[Fichier:diag_class_pj10.png]]

==='''PWM'''===

La première étape consistait à commander nos moteurs DC, afin de poser les bases de notre
asservissement bas niveau. Ces moteurs sont contrôlés par le driver de moteurs, utilisant des signaux logiques pour définir l’état d’un moteur et des signaux '''PWM''' pour définir la vitesse de
rotation. La génération de signaux PWM sur AVR se fait en utilisant les '''timers''' en mode PWM.
Tout simplement, nous avons un registre compteur 16 bits incrémenté périodiquement, et une valeur
maximale définie par le registre ''ICRx''. Nous utilisons ensuite les registres ''OCRnx'' contenant une
valeur inférieure au maximum.
Lorsque le compteur atteint la valeur contenue dans OCRnx, il
inverse la valeur logique de sortie du pin ''OCnx''. Ainsi, nous pouvons modifier instantanément la
valeur d’OCRnx afin de modifier le rapport cyclique de notre signal. Ce rapport cyclique est ensuite
directement proportionnel à la vitesse de rotation du moteur associé.
La fréquence du signal est définie par la période d’incrémentation du compteur et par la valeur maximale ICRx.
Pour notre composant, nous pouvions utiliser une fréquence allant jusqu’à plusieurs kHz. Cette
fréquence n’a aucun impact sur la rotation du moteur. Nous avons donc choisis 20 kHz.
Nous avons définis la '''init_pwm''' pour configurer les registres nécessaires, et la fonction
'''generate_pwm''' pour modifier le rapport cyclique de nos deux signaux PWM avec la valeur
souhaitée.

==='''Encodeurs'''===

Une fois nos moteurs pouvant tourner à une vitesse voulue, nous avons du trouver un moyen de
mesurer leurs vitesses effectives afin de réaliser une boucle d’asservissement. Pour cela, nous avons
utilisés les encodeurs optiques disponibles sur nos moteurs DC.
Ces encodeurs envoient sur leur broches un front-montant à chaque tour de la roue codeuse reliée au moteurs (ayant une vitesse
proportionnelle à celle du moteur). En détectant ces fronts montant, nous pouvons donc compter le
nombre de tours du moteur pendant un intervalle de temps défini, puis déterminer la vitesse réelle
du moteur.
Pour détecter les fronts montant, nous utilisons l’interface '''Pin Change Interrupt''' de l’Atmega. Cette
interface exécute une interruption logicielle à chaque changement d’état logique du pin associé.
Dans notre cas, nous devons ensuite observé l’état précédent de la sortie et l’état actuel pour
déterminer si on est bien en présence d’un front montant. Une fois le front montant détecté, cette
interruption incrémente ensuite le compteur de tours.
Ce compteur est ensuite utilisé pour calculer la vitesse de rotation puis remis à zéro pour la mesure
suivante.
Dans notre cas, nous réalisons cette mesure à une fréquence d’environ 244 Hz, dans une autre
fonction d’interruption qu’on détaillera plus loin.

==='''Angle'''===

Notre boucle de régulation principale a besoin d’une mesure de l’angle d’inclinaison du robot sur
son axe vertical perpendiculaire à celui de déplacement. Cette mesure s’effectue via le '''MPU6050'''.
Ce composant fonctionne via le protocole '''i2c''', protocole de communication simple utilisé par la
plupart des systèmes électroniques. Ce protocole étant bas niveau, il existe de nombreuses
bibliothèques implémentés en C permettant son utilisation. De plus, le MPU6050 est un composant
très complet et complexe, afin d’en récupérer l’angle, il faut d’abord amorcer une communication
i2c puis configurer certains des ses registres, afin ensuite de pouvoir lire les registres contenant la
mesure de l’angle selon l’axe désiré. Afin de conserver un code efficace et concis, nous avons
également décidés d’utiliser une bibliothèque faisant office de « '''driver''' » pour ce composant,
intégrant des fonctions d’initialisation et de lecture des mesures faites par ce gyroscope.
Nous obtenons donc la valeur de l’angle en degrés, comprise entre 0 et 360.Dans notre cas, nous souhaitions obtenir une valeur comprise entre -180 et 180, car seule la valeur
absolue et le sens de l’inclinaison nous intéresse, nous avons donc appliqués une correction de cette
valeur.

==='''Interruption principale'''===

Lors de implémentation d’un asservissement automatique via un microcontrôleur, la puissance de
calcul finie impose que les commandes des actionneurs et les mesures des capteurs doivent être
réalisées périodiquement. Pour cela, nous pouvons utiliser une '''routine d’interruption''' qui s’exécute à
chaque ''overflow'' d’un compteur, via l’interface des '''timers''' de l’atmega. Dans notre cas, cette
interruption correspond à la fonction principale de notre programme. Nous avons réglés sa
fréquence à 244Hz, en divisant le fréquence de base de 16MHz avec un '''prescaler''' de 256 (plus une
deuxième division par 256 du à la taille du registre timer de 8 bits).
Cette interruption vient d’abord remettre a zéro les compteurs des encodeurs et récupérer la vitesse
des deux moteurs.
Ensuite, elle effectue les calculs nécessaires à la régulation de l’angle, mais également de la vitesse
linéaire et de la rotation du robot.
Chaque paramètre à réguler est corrigé par un régulateur PID de coefficients différents via la
fonction '''pid()'''.
Enfin, nous obtenons une commande à envoyer aux moteurs, qui actionnent notre robot de la
manière souhaitée.
Le code de notre système est disponible sur nôtre dépôt gitlab également.

=='''Gestion de projet'''==

Durant ces trois semestres, la gestion de projet est un des domaines où nous avons le plus de difficultés, mais également un de ceux dans lequel nous avons le plus appris.

Voici notre Diagramme de Gantt previsionnel réalisé au S6
[[Fichier:Gt.png|400px|thumb|left|texte descriptif]]

D'abord trois, nous nous sommes retrouvés à deux dès le deuxième semestre, et nous avons donc du modifier l'organisation prévue pour la suite.

Nous avons au final plus ou moins suivis ce diagramme previsionnel, à quelques choses près.

En travaillant à deux, nous avons du trouvé un moyen d'avancer efficacement.
L'un de nous étant en filière SA (Systemes Autonomes) et l'autre en filière SC (Systemes Communicants), la répartition des taches informatiques et automatiques était donc simplifiée.

Cependant, nous avons donc du réussir à expliquer et à mettre en relation chacune de nos parties, en s'améliorant sur la partie communication.
Pour cela, au début de chaque séance, nous commencions par faire le point sur l'avancement globale et propre à chacun.

Ensuite, nous nous répartitions les taches communes aux différentes parties.

Enfin, nous échangions sur les taches respectives à nos deux parties afin de pouvoir les faire coincider le moment venu, et il est arrivé plusieurs fois que l'on s'aide réciproquement chacun sur la partie de l'autre.

Globalement, cela a été positif car nous avons pu tous les deux sortir de notre zone de confort et apprendre beaucoup dans différents domaines.

Comme outils, nous utilisions donc git et gitlab pour la gestion de code et google drive pour le partage de documents.

Nous avons préferés travailler un maximum en présentiel, d'un accord commun.

== Semestre 6 ==

'''Séance du 01/03/22'''

Séance de découverte du sujet de notre projet.

Recherche de l'existant

Réalisation de recherches sur leurs différentes utilisations.

'''Séance du 08/03/22'''

Début de création du diagramme de Gantt .

Réalisation d'une étude du besoin.

'''Séance du 15/03/22'''

Etude du marché : Recherche des robots similaires.

Commencer à prendre en main le robot.

'''Séance du 22/03/22'''

Poursuite de l'étude de marché.

Etude des opportunités.

'''Séance du 29/03/22'''

Fin d'étude du marché.

Commencer à rédiger le cahier des charges.

'''Séance du 05/04/22'''

Commencer la rédaction du cahier des charges.

'''Séance du 26/04/22'''

Bilan du semestre.

Etude de faisabilité.

Etude des risques.

'''Séance du 03/05/22'''

Finalisation de l'étude des risques.

Finalisation de l'étude de faisabilité.

Finalisation du cahier des charges.

== Semestre 7 ==

'''Séance du 10/10/22'''

Commencement de l'étude technique des encodeurs .
Recherche des boucles d'asservissement du robot .

'''Séance du 21/10/22'''

Etude du changement de la carte arduino pour ajouter des nouvelles fonctionnalités : connexion Wifi, fréquence microprocesseur plus élevé,..
Test des encodeurs moteur DC : validé .
Poursuite de recherche des boucles d'asservissement du robot .

'''Séance du 28/10/22'''

Etude de génération des signaux PWM

Test sur Matlab Simulink des boucles d'asservissement issues des robots similaires .

'''Séance du 18/11/22'''

Poursuite de la programmation des signaux PWM du robot.

Calcul de la fonction de transfert issue de la boucle.

'''Séance du 21/11/22'''

Etude du fonctionnement du gyroscope et des autres composants pour programmer le robot .

Séparation du travail a effectuer pour le robot entre une boucle du moteur DC(niveau 1) et une boucle du niveau supérieur(niveau 2) pour asservir l'angle d'inclinaison du robot.

'''Séance du 25/11/22'''

Modification et amélioration du diagramme de Gantt pour le S7 et le S8.

Avancée de la modélisation de la boucle du niveau 1 .

Diagramme de Gantt S7-S8

'''Séance du 28/11/22'''

Fin d'implémentation de la boucle du niveau inférieur sur Matlab/Simulink et récupération des résultats sur le scope .

'''Séance du 08/12/22'''

Poursuite de la partie informatique et avancement de la partie automatique .
Programmation de la liaison série pour débugger les sorties de notre robot .

'''Séance du 15/12/22'''

Début de rédaction du rapport pour le S7

== Semestre 8 ==

'''Séance du 18/01/23'''

Recherches pour le gyroscope .
Test des encodeurs .
Communication sur les attentes du semestre s8 ,les fautes à éviter pour rebondir par rapport au retard S7
Mise à niveau pour comprendre les aspects techniques de la partie informatique pour pouvoir travailler ensemble sur les résultats du S8 .

'''Séance du 25/01/23'''

- Suppression des structures de données pour avancer plus rapidement sur les résultats du semestre s8 .

- Recherches pour la programmation des interruptions PCINT .

- Recherche sur la doc technique pour faire l'initialisation des interruptions externes .

- Recherche de la modélisation en 3D de notre robot pour trouver les paramètres PID de notre robot .

'''Séance du 01/02/23'''

Durant cette séance, nous avons :

Modification du code des encodeurs et test sur les moteurs DC .

Poursuite de recherche de l'existant pour trouver le code du gyroscope .

Mise à jour du git .

Début du calcul des matrices d'inertie de chaque solide.

Recherche du code des régulateurs.

Avancement sur la gestion de projet .

'''Séance du 08/02/23'''

Durant cette séance, nous avons essayé de récupérer les résultats des tests électronique de l'oscilloscope effectués dans les salles d'électronique .

Le code des encodeurs marchent ,la liaison série affiche exactement la vitesse de la consigne :les Régulateurs implémentés correspondent bien à notre applications.

Poursuite de la programmation de la partie informatique du gyroscope : Objectif : récupération de l'angle d'inclinaison sur la liaison série avec la meilleure précision possible .

'''Séance du 15/02/23'''

Fin du calcul des matrices d'inertie .

Paramétrage de notre robot pour avoir la visibilité sur les configurations possibles d'avoir(en virage, ligne droite),en précisant les angles d'inclinaison et es repères associés .

Poursuite de programmation des régulateurs par niveaux en utilisant le code précédemment implémenté pour les encodeurs .

'''Séance du 01/03/23'''

Fin d'implémentation du modèle en 3D de notre robot pour essayer de l'autoéquilibrer en utilisant les PIDS issues de l'autotune par rapport à nos préférences(stabilité,temps de réponse,dépassement,précision).

Nous avons testé le robot en l'alimentant par le biai la liaison USB ! et enregistrement des résultats .

Poursuite de la partie automatique en trouvant toutes les équations nécessaires à notre modèle .

'''Séance du 08/03/23'''

Réalisations de cette séance :

Test du robot pour se stabiliser sur le sol en applicant plusieurs .

Faire tous les calculs des dimensions géométriques de notre robot et test de la boucle d'asservissement avec les deux niveaux sur Matlab Simulink avec nos préférences de stabilité, temps de réponse,précision,dépassement .

'''Séance du 15/03/23'''

Absence justifiée .

Fichier:Diag class pj10.png

2023-05-09T21:13:07Z

Rfarault :

IMA3/IMA4 2021/2023 P10

2023-05-09T21:12:20Z

Rfarault : /* Programme du robot */

=='''Résumé'''==

[[Fichier: SegwayRobot.jpg|200px|right|thumb|Exemple de robot similaire au notre]]

Notre projet est de concevoir un robot mobile à deux roues ayant la faculté de s'équilibrer automatiquement. En effet, ne possédant que deux roues, l'équilibre du robot sur son axe vertical est compromis, a la manière d'un '''segway'''.
Afin d'empecher ce désequilibre, nous avons pensé à intégrer au robot un système de contrôle de son angle vertical, utilisant des capteurs et des actionneurs mis en relation par une boucle de régulation automatique.
Les composants electroniques et mécaniques du robot nous étant fournis, notre travail consiste donc surtout à étudier ce système, pour ensuite concevoir un asservissement, et l'implémenter dans notre robot.

L'intégralité de notre programme est disponible sur le dépôt git à l'adresse: https://gitlab.com/remi_farault/self-balanced-robot

=='''Présentation générale'''==

==🌏Contexte==
Les moyens de transport actuels reposent principalement sur le principe du robot à deux roues, c'est la raison pour laquelle l'étude de celui ci s'avère importante, en effet l'étude
de sa conception et son contrôle va nous permettre de développer des outils innovants qui pourraient potentiellement intéresser des sociétés de transport .

==🎯Objectif==

Notre objectif principal est de commander le robot, de là interviennent d'autres objectifs tel que la stabilité ,développer un code robuste qui assure cette fonctionnalité et aussi le contrôler pour réaliser des fonctionnalités de déplacement et d'éviter des obstacles . Des objectifs secondaires sont de créer un site web à travers lequel nous allons mener toutes les opérations de contrôle .

==🔍Expression du besoin==

Un robot autoéquilibré à deux roues est un type de robot qui peut se maintenir en équilibre sur deux roues sans tomber. Pour réaliser cette fonctionnalité, le robot utilise un ensemble de capteurs, d'algorithmes de contrôle et de moteurs pour ajuster sa position en temps réel.

[[Fichier:Self_balanc_bt.png|400px|Bete a corne SBR]]

Le diagramme interacteurs permet en fait de visualiser les fonctions services assurées par le système

[[Fichier:341702419_560921119358434_1016673599353874396_n_(1).png|400px|DGI SBR]] [[Fichier:Btacorne.png |500px|DGI SBR|right]]

=='''Réalisations et Résultats'''==
[[Fichier: seg.jpg|200px|left|thumb|Exemple de commande désirée]]

Après mis en place notre stratégie de gestion de projet en s6 à travers le diagramme de GANTT et le cahier de charges fonctionnels, nous nous sommes focalisés sur l'étude technique.

[[Fichier: progg.png|300px|right|thumb|Organisation de notre programme]]

Tout d'abord, étudier à travers des outils automatiques la stabilité du robot en faisant appel à des modèles théoriques et pratiques et commencer par un raisonnement par niveaux, d'abord le niveau 1 du moteur à courant continu et les équations correspondantes puis le niveau 2 assurant la stabilité du robot directement, on avait la possibilité de passer directement au niveau 2 à travers le modèle du pendule inversé et les équations qui en découlent sauf que celui-ci ne nous permettra pas de revenir au niveau 1 et asservir le moteur à travers les codeurs incrémentales ,la deuxième partie consistait à réaliser les codes informatiques en s'appuyant sur les structures de données en C vues l'année dernière et conduire un même raisonnement(par niveaux) s'appuyant d'abord sur les codes sources correspondants à la génération d'un signal PWM pour les deux moteurs avec un rapport cyclique modifiable, et aussi les codes sources correspondants à la gestion des moteurs, en effet, ceux-ci tournent dans un sens ou dans un autre ou ne tournent pas en fonction de la variable in1 et in2 pour faire tourner les moteurs .

[[Fichier: Avr.png|100px|left|thumb|Compilateur utilisé]]

Cependant, nous avons rencontré quelques problèmes en automatique notamment pour trouver des valeurs des constantes théoriques pour les références du moteur entre les mains, ce qui nous a obligé à prendre des valeurs issues d'autres applications, nous avons rencontré aussi quelques problèmes choisir une modélisation parmi celles qui sont disponibles sur Internet .

=='''Etude Automatique'''==

Avant de programmer notre système sur la carte Arduino, nous avons également créé une simulation complète de notre système robotisé sur SIMULINK. Cependant, avant cela, nous avons dû déterminer les équations qui régissent notre système en trouvant les matrices d'inertie de chaque composant de notre robot, à savoir la masse transportée par le robot (M), le châssis constitué de deux plateaux et de la motorisation (les piliers et leur inertie ont été négligés car leur masse est très faible), ainsi que les roues (roue droite et roue gauche). Vous trouverez ci-dessous les matrices d'inertie que nous avons obtenues pour chaque composant.

'''Masse M :'''

[[Fichier:MatM.png|200px|thumb|left|Matrice de la masse M]]

Les coefficients seront notés dans la suite pour simplifier : AM,BM,CM

'''Chassis:'''

[[Fichier:MatB.png|800px|Matrice du chassis]]

Les coefficients de la diagonale seront notés dans la suite pour simplifier : AH,BH,CH

'''Roue gauche:'''

[[Fichier:Matrg.png |600px|Matrice de RG]]

Les coefficients de la diagonale seront notés dans la suite pour simplifier : AD,BD,CD

'''Roue droite:'''

[[Fichier:Matrd.png |600px|Matrice RD]]

Les coefficients de la diagonale seront notés dans la suite pour simplifier : AD,BD,CD

Ci-dessous un paramétrage de notre système : Chaque angle détermine un repère

Le repère R0 est supposé galliléen.

Le repère R1 est en rotation ,appelé angle de virage par rapport à R0.

Le repère R2 est en rotation ,appelé angle d’inclinaison du châssis par rapport à R0 .

Le repère R3 est en rotation ,appelé angle d’inclinaison arrière-avant de la masse par rapport à R0 .

Le repère R4 est en rotation ,appelé angle d’inclinaison droite-gauche de la masse par rapport à R0 .

[[Fichier:param.png |800px|Matrice du chassis]]

l’angle de consigne est de 0deg,nous employons un PID pour corriger l’angle de mesure,à sa sortie,on aura une tension W(p).Les blocs Km et W(p) assurent le passage tension->couple->angle ,il faut ensuite retirer pour ne garder que l’angle d’inclinaison du châssis .Km=0.0125N.m.V-1(d’après la datasheet du moteur)

[[Fichier:Bcle.png |800px|Asservissement]] [[Fichier:Matuu.png|right|800px|Asservissement]]

Les équations obtenues sont les suivantes (Le détail des calculs a été précisé dans le Rapport):

[[Fichier:Eq nnlin.png |500px|Asservissement]]

Après linéarisation : Considérer l'approximations des petits angles pour le sinus et cosinus,et négliger aussi la vitesse angulaire quadratique devant la vitesse angulaire,nous obtenons :

[[Fichier:Eqlin.png |300px|Asservissement]]

[[Fichier:Crbe.png|600px|Courbe]]

On obtient une courbe avec un bon temps de réponse, un léger dépassement et une stabilité .Le système est régulé de manière efficace, capable de répondre rapidement et précisément aux perturbations tout en maintenant une position d'équilibre stable.

[[Fichier:Mat3d.png|500px|Asservissement]]

=='''Environnement de developpement'''==

Notre microcontrolleur étant une Arduino Uno, nous aurions pu utiliser le framework ''Arduino'' donnant accès à un IDE intégrant les outils pour compiler et flasher le code, ainsi qu'une multitude de bibliothèques haut niveaux très simples d'utilisation et plutôt performantes, permettant de programmer notre robot en simplement quelques dizaines de lignes de code.

Cependant, l'Arduino est simplement une carte de prototypage intégrant un microcontrôleur ''AVR Atmega 328p''.
Les microcontroleurs AVR disposent d'une grande communauté, et il existe de nombreux outils nécessaires au developpement sur ces cartes.
Afin d'avoir un meilleur contrôle sur notre projet, et surtout d'en tirer un maximum de compétences, nous avons donc décidés de programmer notre robot directement en C en utilisant les outils AVR:

- '''avr-gcc''': compilateur open-source portant toutes les fonctionnalités du langage C standard sur les microcontroleurs AVR.
Seul, son utilisation est quasiment impossible et demande trop de travail en programmation bas-niveau.

- '''avr-libc''': implémentation basé sur le compilateur avr-gcc de la bibliothèque standard du langage C.
Cette bibliothèque permet donc d'utiliser les fonctions et structures standards du C (IO, maths, chaines de caractères), mais elle intègre également un mapping mémoire de tous les registres de l'atmega, ainsi qu'un mécanisme pour programmer des interruptions.

- '''avr-objcopy''': ce programme en ligne de commande formate le binaire obtenu en format utilisable par les AVR

- '''avr-dude''': ce programme en ligne de commande permet de flasher via une interface USB-série un microcontroleur AVR présent sur une carte Arduino.

Nous avons donc developpé un '''Makefile''' utilisant tous ces outils, constituant un environnement de developpement très efficace pour notre projet. Ce Makefile est disponible sur notre gitlab.

=='''Programme du robot'''==

[[Fichier:diag_class.jpg]]

==='''PWM'''===

La première étape consistait à commander nos moteurs DC, afin de poser les bases de notre
asservissement bas niveau. Ces moteurs sont contrôlés par le driver de moteurs, utilisant des signaux logiques pour définir l’état d’un moteur et des signaux '''PWM''' pour définir la vitesse de
rotation. La génération de signaux PWM sur AVR se fait en utilisant les '''timers''' en mode PWM.
Tout simplement, nous avons un registre compteur 16 bits incrémenté périodiquement, et une valeur
maximale définie par le registre ''ICRx''. Nous utilisons ensuite les registres ''OCRnx'' contenant une
valeur inférieure au maximum.
Lorsque le compteur atteint la valeur contenue dans OCRnx, il
inverse la valeur logique de sortie du pin ''OCnx''. Ainsi, nous pouvons modifier instantanément la
valeur d’OCRnx afin de modifier le rapport cyclique de notre signal. Ce rapport cyclique est ensuite
directement proportionnel à la vitesse de rotation du moteur associé.
La fréquence du signal est définie par la période d’incrémentation du compteur et par la valeur maximale ICRx.
Pour notre composant, nous pouvions utiliser une fréquence allant jusqu’à plusieurs kHz. Cette
fréquence n’a aucun impact sur la rotation du moteur. Nous avons donc choisis 20 kHz.
Nous avons définis la '''init_pwm''' pour configurer les registres nécessaires, et la fonction
'''generate_pwm''' pour modifier le rapport cyclique de nos deux signaux PWM avec la valeur
souhaitée.

==='''Encodeurs'''===

Une fois nos moteurs pouvant tourner à une vitesse voulue, nous avons du trouver un moyen de
mesurer leurs vitesses effectives afin de réaliser une boucle d’asservissement. Pour cela, nous avons
utilisés les encodeurs optiques disponibles sur nos moteurs DC.
Ces encodeurs envoient sur leur broches un front-montant à chaque tour de la roue codeuse reliée au moteurs (ayant une vitesse
proportionnelle à celle du moteur). En détectant ces fronts montant, nous pouvons donc compter le
nombre de tours du moteur pendant un intervalle de temps défini, puis déterminer la vitesse réelle
du moteur.
Pour détecter les fronts montant, nous utilisons l’interface '''Pin Change Interrupt''' de l’Atmega. Cette
interface exécute une interruption logicielle à chaque changement d’état logique du pin associé.
Dans notre cas, nous devons ensuite observé l’état précédent de la sortie et l’état actuel pour
déterminer si on est bien en présence d’un front montant. Une fois le front montant détecté, cette
interruption incrémente ensuite le compteur de tours.
Ce compteur est ensuite utilisé pour calculer la vitesse de rotation puis remis à zéro pour la mesure
suivante.
Dans notre cas, nous réalisons cette mesure à une fréquence d’environ 244 Hz, dans une autre
fonction d’interruption qu’on détaillera plus loin.

==='''Angle'''===

Notre boucle de régulation principale a besoin d’une mesure de l’angle d’inclinaison du robot sur
son axe vertical perpendiculaire à celui de déplacement. Cette mesure s’effectue via le '''MPU6050'''.
Ce composant fonctionne via le protocole '''i2c''', protocole de communication simple utilisé par la
plupart des systèmes électroniques. Ce protocole étant bas niveau, il existe de nombreuses
bibliothèques implémentés en C permettant son utilisation. De plus, le MPU6050 est un composant
très complet et complexe, afin d’en récupérer l’angle, il faut d’abord amorcer une communication
i2c puis configurer certains des ses registres, afin ensuite de pouvoir lire les registres contenant la
mesure de l’angle selon l’axe désiré. Afin de conserver un code efficace et concis, nous avons
également décidés d’utiliser une bibliothèque faisant office de « '''driver''' » pour ce composant,
intégrant des fonctions d’initialisation et de lecture des mesures faites par ce gyroscope.
Nous obtenons donc la valeur de l’angle en degrés, comprise entre 0 et 360.Dans notre cas, nous souhaitions obtenir une valeur comprise entre -180 et 180, car seule la valeur
absolue et le sens de l’inclinaison nous intéresse, nous avons donc appliqués une correction de cette
valeur.

==='''Interruption principale'''===

Lors de implémentation d’un asservissement automatique via un microcontrôleur, la puissance de
calcul finie impose que les commandes des actionneurs et les mesures des capteurs doivent être
réalisées périodiquement. Pour cela, nous pouvons utiliser une '''routine d’interruption''' qui s’exécute à
chaque ''overflow'' d’un compteur, via l’interface des '''timers''' de l’atmega. Dans notre cas, cette
interruption correspond à la fonction principale de notre programme. Nous avons réglés sa
fréquence à 244Hz, en divisant le fréquence de base de 16MHz avec un '''prescaler''' de 256 (plus une
deuxième division par 256 du à la taille du registre timer de 8 bits).
Cette interruption vient d’abord remettre a zéro les compteurs des encodeurs et récupérer la vitesse
des deux moteurs.
Ensuite, elle effectue les calculs nécessaires à la régulation de l’angle, mais également de la vitesse
linéaire et de la rotation du robot.
Chaque paramètre à réguler est corrigé par un régulateur PID de coefficients différents via la
fonction '''pid()'''.
Enfin, nous obtenons une commande à envoyer aux moteurs, qui actionnent notre robot de la
manière souhaitée.
Le code de notre système est disponible sur nôtre dépôt gitlab également.

=='''Gestion de projet'''==

Durant ces trois semestres, la gestion de projet est un des domaines où nous avons le plus de difficultés, mais également un de ceux dans lequel nous avons le plus appris.

Voici notre Diagramme de Gantt previsionnel réalisé au S6
[[Fichier:Gt.png|400px|thumb|left|texte descriptif]]

D'abord trois, nous nous sommes retrouvés à deux dès le deuxième semestre, et nous avons donc du modifier l'organisation prévue pour la suite.

Nous avons au final plus ou moins suivis ce diagramme previsionnel, à quelques choses près.

En travaillant à deux, nous avons du trouvé un moyen d'avancer efficacement.
L'un de nous étant en filière SA (Systemes Autonomes) et l'autre en filière SC (Systemes Communicants), la répartition des taches informatiques et automatiques était donc simplifiée.

Cependant, nous avons donc du réussir à expliquer et à mettre en relation chacune de nos parties, en s'améliorant sur la partie communication.
Pour cela, au début de chaque séance, nous commencions par faire le point sur l'avancement globale et propre à chacun.

Ensuite, nous nous répartitions les taches communes aux différentes parties.

Enfin, nous échangions sur les taches respectives à nos deux parties afin de pouvoir les faire coincider le moment venu, et il est arrivé plusieurs fois que l'on s'aide réciproquement chacun sur la partie de l'autre.

Globalement, cela a été positif car nous avons pu tous les deux sortir de notre zone de confort et apprendre beaucoup dans différents domaines.

Comme outils, nous utilisions donc git et gitlab pour la gestion de code et google drive pour le partage de documents.

Nous avons préferés travailler un maximum en présentiel, d'un accord commun.

== Semestre 6 ==

'''Séance du 01/03/22'''

Séance de découverte du sujet de notre projet.

Recherche de l'existant

Réalisation de recherches sur leurs différentes utilisations.

'''Séance du 08/03/22'''

Début de création du diagramme de Gantt .

Réalisation d'une étude du besoin.

'''Séance du 15/03/22'''

Etude du marché : Recherche des robots similaires.

Commencer à prendre en main le robot.

'''Séance du 22/03/22'''

Poursuite de l'étude de marché.

Etude des opportunités.

'''Séance du 29/03/22'''

Fin d'étude du marché.

Commencer à rédiger le cahier des charges.

'''Séance du 05/04/22'''

Commencer la rédaction du cahier des charges.

'''Séance du 26/04/22'''

Bilan du semestre.

Etude de faisabilité.

Etude des risques.

'''Séance du 03/05/22'''

Finalisation de l'étude des risques.

Finalisation de l'étude de faisabilité.

Finalisation du cahier des charges.

== Semestre 7 ==

'''Séance du 10/10/22'''

Commencement de l'étude technique des encodeurs .
Recherche des boucles d'asservissement du robot .

'''Séance du 21/10/22'''

Etude du changement de la carte arduino pour ajouter des nouvelles fonctionnalités : connexion Wifi, fréquence microprocesseur plus élevé,..
Test des encodeurs moteur DC : validé .
Poursuite de recherche des boucles d'asservissement du robot .

'''Séance du 28/10/22'''

Etude de génération des signaux PWM

Test sur Matlab Simulink des boucles d'asservissement issues des robots similaires .

'''Séance du 18/11/22'''

Poursuite de la programmation des signaux PWM du robot.

Calcul de la fonction de transfert issue de la boucle.

'''Séance du 21/11/22'''

Etude du fonctionnement du gyroscope et des autres composants pour programmer le robot .

Séparation du travail a effectuer pour le robot entre une boucle du moteur DC(niveau 1) et une boucle du niveau supérieur(niveau 2) pour asservir l'angle d'inclinaison du robot.

'''Séance du 25/11/22'''

Modification et amélioration du diagramme de Gantt pour le S7 et le S8.

Avancée de la modélisation de la boucle du niveau 1 .

Diagramme de Gantt S7-S8

'''Séance du 28/11/22'''

Fin d'implémentation de la boucle du niveau inférieur sur Matlab/Simulink et récupération des résultats sur le scope .

'''Séance du 08/12/22'''

Poursuite de la partie informatique et avancement de la partie automatique .
Programmation de la liaison série pour débugger les sorties de notre robot .

'''Séance du 15/12/22'''

Début de rédaction du rapport pour le S7

== Semestre 8 ==

'''Séance du 18/01/23'''

Recherches pour le gyroscope .
Test des encodeurs .
Communication sur les attentes du semestre s8 ,les fautes à éviter pour rebondir par rapport au retard S7
Mise à niveau pour comprendre les aspects techniques de la partie informatique pour pouvoir travailler ensemble sur les résultats du S8 .

'''Séance du 25/01/23'''

- Suppression des structures de données pour avancer plus rapidement sur les résultats du semestre s8 .

- Recherches pour la programmation des interruptions PCINT .

- Recherche sur la doc technique pour faire l'initialisation des interruptions externes .

- Recherche de la modélisation en 3D de notre robot pour trouver les paramètres PID de notre robot .

'''Séance du 01/02/23'''

Durant cette séance, nous avons :

Modification du code des encodeurs et test sur les moteurs DC .

Poursuite de recherche de l'existant pour trouver le code du gyroscope .

Mise à jour du git .

Début du calcul des matrices d'inertie de chaque solide.

Recherche du code des régulateurs.

Avancement sur la gestion de projet .

'''Séance du 08/02/23'''

Durant cette séance, nous avons essayé de récupérer les résultats des tests électronique de l'oscilloscope effectués dans les salles d'électronique .

Le code des encodeurs marchent ,la liaison série affiche exactement la vitesse de la consigne :les Régulateurs implémentés correspondent bien à notre applications.

Poursuite de la programmation de la partie informatique du gyroscope : Objectif : récupération de l'angle d'inclinaison sur la liaison série avec la meilleure précision possible .

'''Séance du 15/02/23'''

Fin du calcul des matrices d'inertie .

Paramétrage de notre robot pour avoir la visibilité sur les configurations possibles d'avoir(en virage, ligne droite),en précisant les angles d'inclinaison et es repères associés .

Poursuite de programmation des régulateurs par niveaux en utilisant le code précédemment implémenté pour les encodeurs .

'''Séance du 01/03/23'''

Fin d'implémentation du modèle en 3D de notre robot pour essayer de l'autoéquilibrer en utilisant les PIDS issues de l'autotune par rapport à nos préférences(stabilité,temps de réponse,dépassement,précision).

Nous avons testé le robot en l'alimentant par le biai la liaison USB ! et enregistrement des résultats .

Poursuite de la partie automatique en trouvant toutes les équations nécessaires à notre modèle .

'''Séance du 08/03/23'''

Réalisations de cette séance :

Test du robot pour se stabiliser sur le sol en applicant plusieurs .

Faire tous les calculs des dimensions géométriques de notre robot et test de la boucle d'asservissement avec les deux niveaux sur Matlab Simulink avec nos préférences de stabilité, temps de réponse,précision,dépassement .

'''Séance du 15/03/23'''

Absence justifiée .

IMA3/IMA4 2021/2023 P10

2023-05-08T19:34:56Z

Rfarault : /* Etude Automatique */

Rfarault :

= Robot Auto-Equilibré =

IMA3/IMA4 2021/2023 P10

2023-01-03T19:52:47Z

Rfarault : Page vide créée

Projets IMA3 IMA4 2021/2023

2022-10-10T10:48:39Z

Rfarault : /* Répartition des projets */

== Répartition des projets ==

{| class="wikitable"
! Projets !! Encadrants école !! Eleves
|-
| P1 [[IMA3/IMA4 2021/2023 P1|IMA3/IMA4 2021/2023 P1]]
| ici nom encadrant
| ici etudiant 1 / etudiant 2 / ....
|-

|-
| P2 [[IMA3/IMA4 2021/2023 P2|ici nom du projet]]
| ici nom encadrant
| ici etudiant 1 / etudiant 2 / ....
|-

|-
| P3 [[IMA3/IMA4 2021/2023 P3|Convoyeur avec caméra]]
| Blaise Conrard / Othman Lakhal
| Brenier Timothé / Hornain François / Ling Dylan / Riffaut Mathis
|-

|-
| P4 [[IMA3/IMA4 2021/2023 P4|ici nom du projet]]
| ici nom encadrant
| ici etudiant 1 / etudiant 2 / ....
|-

|-
| P5 [[IMA3/IMA4 2021/2023 P3| Supervision d'un Parc d'imprimante 3D]]
| Rodolphe Astori / Blaise Conrard
| Dollet Arthur/ Touria El Azrak / Chichery Gregoire / Amoros Paul
|-

|-
| P6 [[IMA3/IMA4 2021/2023 P6|Robot ramasseur de mégots]]
| Othman Lakhal
| Delannoy Jason - Deffrennes Vianney - Thomas Gabriel
|-

|-
| P7 [[IMA3/IMA4 2021/2023 P4|ici nom du projet]]
| ici nom encadrant
| ici etudiant 1 / etudiant 2 / ....
|-

|-
| P8 [[IMA3/IMA4 2021/2023 P4|Vanne Piézoelectrique]]
| Othman Lakhal
| Pouillard Romain / Legendre Hugo/ Vion Antoine
|-

|-
| P7 [[IMA3/IMA4 2021/2023 P4|ici nom du projet]]
| ici nom encadrant
| ici etudiant 1 / etudiant 2 / ....
|-

|-
| P10 [[IMA3/IMA4 2021/2023 P4|Robot à deux roues auto équilibré]]
| Anne-Lise Géhin
| Bennani Mohamed / Farault Rémi
|-

|-
| P7 [[IMA3/IMA4 2021/2023 P4|ici nom du projet]]
| ici nom encadrant
| ici etudiant 1 / etudiant 2 / ....
|-

|-
| P12 [[IMA3/IMA4 2021/2023 P12|Communication entre des robots pour la gestion d'un entrepôt]]
| Anne-Lise Géhin
| Naudot François / Delétang Antoine / Sellali Amine / El Mariky Salim
|-

|-
| P7 [[IMA3/IMA4 2021/2023 P4|ici nom du projet]]
| ici nom encadrant
| ici etudiant 1 / etudiant 2 / ....
|-

|-
| P14 [[IMA3/IMA4 2021/2023 P14|Télé-opération d'un bras manipulateur collaboratif via un casque virtuel.]]
| Othman LAKHAL
| Julien CHARLEUX / Karl HABRE / Thomas LEFRANC / Tanguy RIDREMONT
|-

|-
| P7 [[IMA3/IMA4 2021/2023 P4|ici nom du projet]]
| ici nom encadrant
| ici etudiant 1 / etudiant 2 / ....
|-

|-
| P7 [[IMA3/IMA4 2021/2023 P4|ici nom du projet]]
| ici nom encadrant
| ici etudiant 1 / etudiant 2 / ....
|-
|}