Version actuelle datée du 6 mai 2022 à 19:01

Présentation générale

Contexte

Dans le cadre d'une accélération constante du développement des moyens de transport du futur, donc automatisés, nous souhaitons réaliser une voiture partiellement autonome pour comprendre les enjeux de la sécurité passive.

La sécurité passive constitue le degré d'autonomie le plus important pour assurer la sûreté de fonctionnement du véhicule.

Plusieurs applications ont été présentées sur les 3 semestres de Projet :

• Semestre 6 : Véhicule de course miniature à asservissement partiel avec suivi de trajectoire rectiligne, sans heurter les bords de la piste. Véhicule réalisé dans le cadre du Concours "Course en Cours".
• Semestre 7 : Véhicule quasi autonome simulé et validé, pour un déplacement sécurisé dans l'espace. Possibilité de le radiocommander.
• Semestre 8 : Véhicule autonome logistique réalisé, pour aider à l'automatisation des entrepôts de stockage. C'est un véhicule qui suit les murs, de manière à cheminer dans l'entrepôt tout seul. La radiocommande est toujours du véhicule est toujours possible.

Description

Notre Projet des Semestres 6 et 7 consiste en la réalisation d'une voiture autonome de degré 2. Voici la définition des degrés d'autonomie d'une voiture selon Wikipédia.

Notre Projet du S7 ne s'inscrit pas dans la pleine continuité de ce que nous avons réalisé au S6. En effet, au S6, nous avons participé à l'édition 2021 du Concours "Course en Cours". L'objectif de celui-ci est de réaliser une voiture de course sur départ arrêté en ligne droite. Il n'y avait donc aucune autonomie apportée à notre voiture, même si nous avions réalisé une innovation numérique dans le cadre du Concours qui consistait en l'implémentation d'une régulation en trajectoire, pour que la voiture suive une ligne droite sans jamais être en contact avec les bords de la piste.

Au S7, nous réalisons donc une sécurité passive et un contrôle automatique sur un buggy que possédait déjà l'un d'entre nous. Lorsque le buggy est trop proche d'un obstacle, le mode de contrôle bascule en automatique pour qu'il puisse dévier l'obstacle efficacement, et ce, indépendamment de l'intervention humaine. Par défaut, le mode de contrôle de la voiture sera manuel (à l'aide de la télécommande fournie avec le buggy).

Enfin, le S8 consiste en la réalisation d'un véhicule logistique autonome, s'appuyant sur les nombreuses simulations et conceptions du S7. Le but est d'avoir un véhicule logistique automatisé pouvant stocker/déstocker des marchandises dans les entrepôts, de manière à soulager la peine humaine (des caristes). L'asservissement en vitesse ainsi qu'en position vis-à-vis des obstacles et murs environnants est essentielle.

Matériel

Nous disposons déjà du matériel suivant :

• Le buggy radiocommandé.
• Un moteur pour la traction du véhicule (intégré au buggy).
• Un servomoteur pour la direction du véhicule (intégré au buggy).
• 4 capteurs unidirectionnels à ultrason pour détecter une distance entre le buggy et un obstacle de manière continue.

Nous avons acheté (avec l'école) :

• Une carte Arduino MKR WAN 1310 en vue de réaliser une télécommunication en LoRaWAN (pour la remontée d'alertes), ainsi que pour la commande des 2 moteurs en fonction des informations analogiques récupérées sur les 3 capteurs à ultrason (pour la sécurité passive) : Commande Arduino MKR WAN 1310.
• 4 Piles AA pour la télécommande : Commande chez RS Components.
• Une LED bicolore (verte pour signaler si l'utilisateur a la main pour radiocommander le buggy, rouge si la sécurité passive a pris le dessus par interruption) : Commande de la LED bicolore chez RS Components
• Câbles de branchement (strap) mâle/mâle : Commande chez RS Components et mâle/femelle : Commande chez RS Components.

Fonctionnalités et Solutions adoptées

• Véhicule radio commandable : Télécommande émettrice et récepteur relié au variateur de vitesse.
• Autonomie partielle (sécurité passive) : Arduino contenant un programme fonctionnant par interruption, pour reprendre la main sur l'utilisateur quand obstacle détecté + 3 capteurs de distance à ultrason + Algorithme de régulation PI de la vitesse.
• Circuit de gestion fine de la puissance (sécurité interne avec boucle de régulation en courant) : Limiter les pics de courant pour assurer une durée de vie du moteur et des semi-conducteurs qui soit maximale.

Projet réalisé au S6

Cadre général

Nous nous sommes inscrits à un Concours : “Course en Cours”, organisé par l’association “Course en Cours” avec le soutien de Dassault Systèmes, Renault et PFA (Plateforme de la Filière Automobile). Pour ce concours, nous devons réaliser un véhicule électrique miniature, qui soit le plus rapide possible pour une course en ligne droite, avec un soin particulier apporté à l’aspect développement durable et à l’innovation mécanique & numérique du véhicule.

Nous sommes partis de la définition du Projet, en rédigeant le Cahier des Charges et en créant notre diagramme de GANTT, pour aller jusqu’à la réalisation de notre voiture électrique par multiples impressions 3D et découpes laser au Fabricarium de Polytech Lille. Entre-deux, nous avons bien réfléchi à la conception du véhicule, à ce dont on dispose déjà (mallette fournie par le Concours) et à ce qui est à réaliser. La partie réalisation mécanique fut la plus importante et fastidieuse, car il fallait toujours s’assurer que les pièces mécaniques conçues et imprimées en 3D s’assemblent bien entre elles.

Le Concours nous a mis à disposition une plateforme de travail collaboratif : 3DExperience. Elle est très pratique pour faire nos conceptions 3D (sur xShape & xDesign), les partager et les envoyer pour impression 3D. Nous avions donc tous les outils en main pour réaliser notre voiture électrique !

Cahier des Charges

Dans le cadre de notre concours il nous est demandé de concevoir et de construire une voiture innovante et rapide tout en respectant l’environnement. Pour ce faire, le bloc moteur est fourni par le concours.

Le concours consiste en 3 épreuves sur une piste officielle d’une longueur de 15m :

• Une course de vitesse où le but est de parcourir la piste officielle le plus rapidement possible.
• Une épreuve “temps de réaction” où il faut déclencher le départ du véhicule le plus rapidement possible.
• Une épreuve “Arrêt au stand” où l’objectif est d’arrêter le véhicule sur une zone précise de la piste.
• Il y a aussi une épreuve d’écoconduite : il faut effectuer un trajet sur une distance et une durée de course définies par les organisateurs de l’épreuve en limitant sa consommation d’énergie.

Architecture fonctionnelle de la voiture électrique

Voici l'architecture globale de la voiture électrique, mettant en exergue les transferts de puissance et les échanges d'information entre les principaux sous-systèmes :

Projet réalisé au S7

Overview

• 1ère étape : Premiers branchements et tests avec la carte Arduino MKR WAN 1310 et tous les capteurs et moteurs pour voir sous quelle forme sont acheminées les informations des capteurs (et donc savoir comment les traiter) et comment commander les moteurs. ENVIRON 2 SEMAINES

• 2ème étape : Implémenter la sécurité passive sur le buggy en programmant sur Arduino IDE et en réalisant divers tests. BUT : Éviter à tout prix les collisions entre le buggy et les obstacles (même si l'utilisateur fonce droit sur un obstacle). ENVIRON 2 SEMAINES

• 3ème étape : Implémenter la télécommunication en LoRaWAN lors de la détection d'obstacle (pour une remontée d'alerte en temps réel). ENVIRON 2 SEMAINES

• 4ème étape : Modélisation du buggy en vue d'une autonomie totale sur une période définie (10 secondes après détection d'obstacle). ENVIRON 2 SEMAINES

• 5ème étape : À partir de la modélisation du buggy asservi en direction (servomoteur) et en vitesse (moteur à traction), réaliser l'autonomie du buggy pendant 10 secondes pour qu'il suive la trajectoire voulue par l'utilisateur tout en se tenant à une distance raisonnable des obstacles qu'il pourrait rencontrer sur son chemin. ENVIRON 4 SEMAINES

• 6ème étape : Rédiger un dossier et réaliser un diaporama de présentation pour rendre compte de notre réalisation, tout en expliquant les aspects de modélisation (suivi analogique de la trajectoire du buggy grâce aux capteurs à ultrason), de réalisation et de tests du buggy à sécurité passive, tout en étant contrôlé manuellement par radiocommande + EXPLICATIONS de la remontée d'alertes via LoRaWAN (quand la sécurité passive reprend le dessus). ENVIRON 2 SEMAINES

Voici le diagramme de GANTT (version 2) pour le détail des phases, l'attribution des tâches et la temporalité d'exécution de celles-ci : Fichier:Diagramme de GANTT (V2) - Projet S7.pdf

Étude du câblage des composants

• Matériel détaillé:

Note: La carte utilisée pour le mapping est une carte Arduino UNO. Elle ne permet pas encore la communication, qui le sera grâce à une carte LoRa MKR WAN plus tard. Cependant, le câblage sera toujours valable, ainsi nous l'effectuerons sur le modèle de la UNO.

//A compléter avec des photos individuelles du matériel//

• Câblage:

Voici ci-dessous le mapping effectué sur Fritzing, sous ses vues "Platine" et "Schematic":

Câblage sous la vue "Platine"

Câblage sous la vue "Schematic"

Les éléments BAT, STR et THR sont des emplacements physiques du récepteur. L'emplacement BAT alimente l'ensemble de la carte, d'où le fait que les emplacements THR et STR ne soient pas alimentés directement. THR et STR sont les deux chaînes de communication radio utilisées: THR pour "Throttle", c'est la chaîne qui commande les "gaz" du moteur, connectée à la gâchette de la radiocommande; STR pour "Steering", c'est la chaîne qui commande le servomoteur, connectée au volant de la radiocommande.

Pour les deux représentations, les couleurs représentées sont les suivantes:

- câbles rouges pour l'alimentation 6V max. 3A venant du variateur (BEC)

- câbles verts pour l'alimentation 5V max. 500mA venant de l'Arduino UNO

- câbles noirs pour la masse

- câbles jaunes pour les données véhiculées depuis l'Arduino vers les capteurs et actionneurs (pins "Trigger" des capteurs ultrason et pins "pulse" du servomoteur et du variateur)

- câbles ocres pour les données véhiculées depuis les capteurs/actionneurs vers l'Arduino (données reçues par le récepteur radio et pins "echo" des capteurs ultrason)

Le variateur n'apparaît pas entièrement sur ces schémas. En effet, le BEC est un convertisseur intégré qui permet à la fois d'alimenter le récepteur (et bien plus ici) et de récupérer les données venant de ce même récepteur pour commander le moteur. Le variateur est alimenté par une batterie Li-Po 14,8V. Le BEC délivre quant à lui une tension de 6V et un maximum de 3A. C'est donc le variateur qui alimente l'ensemble de notre système, à travers ce BEC. Le BEC alimente donc en 6V:

- l'Arduino UNO lorsqu'elle n'est pas connectée en USB, sur son pin Vin (qui accepte une tension jusqu'à 12V)

- le récepteur

- le servomoteur

L'Arduino alimente à son tour les capteurs ultrason, qui fonctionnent en 5V.

Note: L'Arduino délivre 20mA par entrée/sortie, et un maximum de 500mA sur son pin d'alimentation 5V. 10 pins d'E/S sont utilisés, ainsi l'Arduino consomme un total de 10*20mA + 500mA = 700mA = 0,7A. Par ailleurs, notre servomoteur accepte une tension située entre 6V et 8,4V, et consomme 120mA à vide. La consommation de courant s'élève alors à ce stade à 820mA = 0,82A. Même en additionnant le courant consommé par le récepteur (inconnu mais certainement de l'ordre de la centaine de mA) et si on considère le fait que le servomoteur ne sera pas à vide et qu'il consommera donc plus que 120mA, nous respectons le courant maximal de 3A que le BEC est capable de fournir.

Le choix des pins d'entrée/sortie seront explicités dans la partie qui suit, dédiée à l'appréhension des informations véhiculées.

Projet actuel (S8)

À la fin du semestre précédent, peu de temps avant la soutenance, le variateur de vitesse que nous utilisions a cessé de fonctionner, pour une raison qui nous est encore inconnue. Nous avons alors, à ce moment, décidé de redéfinir notre Projet, en intégrant une partie d’électronique de puissance, afin d’intégrer nous-mêmes les composants nécessaires à l’alimentation hachée du moteur. Nous avons par la même occasion changé de moteur, pour finalement travailler avec une Machine à Courant Continu (MCC), pour faciliter la réalisation de cette nouvelle partie.

Cette étape témoigne en réalité d’une faiblesse importante dans notre gestion de Projet. Nous avons effectivement, depuis son lancement, fait preuve d’une agilité excessive. À chaque aléa, nous avons redéfini notre Projet au moins en partie, sans respecter de réelle ligne conductrice fixe que nous aurions établie au départ.

Pour ce dernier semestre, nous avons décidé de mieux appliquer notre gestion de Projet, même si notre excès d’agilité sur les semestres précédents nous avait déjà fortement retardé. Nous avons alors pour cette fin de projet adopté une stratégie reprenant la partie basse du cycle en V, à savoir : -La conception détaillée et les tests unitaires de chaque partie spécifique. -L’intégration de chaque nouvelle partie détaillée à la précédente. -L’intégration globale. Pour suivre cette méthodologie, nous avons opté pour l’établissement d’un Plan d’Action en parallèle du GANTT, mieux adapté à cette méthode.

Fichier:Plan d'action.pdf

Conception et Validations fonctionnelles

Gestion de la radiocommande:

Cette partie est reprise du semestre dernier. Nous avons dû comprendre et reproduire la communication entre la radiocommande et le récepteur pour que notre programme Arduino puisse le maîtriser. En effet et pour rappel de notre Cahier des Charges, notre système a deux modes de fonctionnement : En mode “normal”, le programme Arduino intercepte le message envoyé par la radiocommande et le retransmet aux actionneurs. En mode “sécurité”, c’est à dire lorsque le robot s’approche trop dangereusement d’un mur ou d’un obstacle, le programme rend la radiocommande muette et gère lui-même le véhicule pour “rectifier le tir”, et rend finalement la main à l’utilisateur (à la radiocommande donc) une fois le véhicule stabilisé à une distance sécurisante.

En mode normal, la radiocommande est écoutée sous forme d’interruptions. En effet, le récepteur, une fois le signal provenant de la radiocommande reçu, envoie à l’Arduino un signal MLI dont la durée des impulsions peut être interprétée par le servomoteur ou le variateur de vitesse. La routine d’interruption est programmée pour se déclencher à chaque front du signal provenant du récepteur, qu’il soit montant ou descendant. Ainsi, lors d’un front montant, on déclenche un timer, et lors du front descendant suivant, on mesure la durée du front, qui est ensuite pondéré suivant l’actionneur utilisé (en effet, pour le hacheur utilisé pour le moteur, on doit par exemple envoyer un signal numérique entre 0 et 255, tandis que la durée des impulsions transmises par le récepteur varie entre 1ms et 2ms).

Cette partie nous a donc permis de manipuler les interruptions du microcontrôleur de l’Arduino UNO. Pour cette partie, nous manipulons les interruptions sur le PORT D (les 8 premiers pins).

Gestion de l'alimentation du moteur

Pour cette partie, nous avons réalisé un hacheur simple cadran. Nous aurions pu réaliser un pont en H afin de permettre au véhicule de reculer voire de récupérer l’énergie lorsque le moteur est en inertie libre, mais nous nous limitons ici à la traction avant du moteur. Le moteur est donc, via ce circuit de puissance, alimenté par une batterie de 7,4V. Notons que nous pouvons alimenter la carte Arduino par cette batterie également, étant donné qu’elle accepte une tension en entrée entre 7V et 12V. Le hacheur simple est donc simplement réalisé grâce à une mise en parallèle d’un transistor IGBT et d’une diode de roue libre (de type Schottky pour permettre la circulation du courant généré par le moteur lorsqu’il est en inertie libre).

Au préalable, nous avons vérifié que les différents composants permettaient de réaliser la traction du système tout en restant dans les limites imposées. En effet, la batterie que nous utilisons a une capacité de 4 Ah avec une décharge de 1C, ce qui signifie qu’elle est capable de délivrer un courant maximal de 4 A pendant 1h. Ainsi, nous devons nous assurer que la traction ne nécessite pas plus de 4 A. Nous avons besoin pour cela d’estimer le couple nécessaire sur l’arbre moteur pour faire avancer le véhicule. Sa masse est de 4,2 kg. Le rayon de ses roues est de 7 cm, le couple appliqué sur le cardan est donc de 0,07*4,2*g (où g est l’accélération de pesanteur) soit 2,9 N.m. Nous avons estimé le rapport de réduction global entre l’arbre du moteur et le cardan des roues, en regardant combien de tours de l’arbre moteur étaient nécessaires pour que le cardan réalise un tour complet. On en déduit un couple nécessaire sur l’arbre moteur d’environ 0,15 N.m. Nous avons donc renseigné cette estimation en tant que couple de charge appliqué sur le moteur afin de réaliser la simulation et vérifier l’ordre de grandeur des courants échangés.

Pour valider, nous testons d’abord séparément le circuit avec une batterie et un moteur plus petits et moins consommateur, à vide. Le fonctionnement unitaire étant validé, nous pourrons l’intégrer au reste du système. Voici d’ailleurs une vue sur son implémentation physique, après soudure sur un Protoshield pour Arduino:

Gestion de la détection

La gestion de la détection d’obstacle se fait à l’aide de 3 capteurs (un à l’avant et un de chaque côté) et d’un algorithme implémenté dans la carte Arduino qui va corriger l’angle des roues en fonction de la position et de la distance entre le véhicule autonome et l’obstacle.

Tout d’abord, avant de tester notre algorithme de correction de trajectoire, nous avons étudié le fonctionnement des capteurs HC-SR04 que l’on a à disposition (Modulation de Largeur d’Impulsion).

Voici les étapes de la prise de mesure du capteur: 1) On envoie une impulsion “ETAT HAUT” de 10µs sur la broche TRIGGER du capteur 2) Le capteur envoie une série de 8 impulsions ultrasoniques à 40KHz 3) Les ultrasons se propagent dans l’air jusqu’à atteindre un obstacle et retournent dans l'autre sens vers le capteur 4) Le capteur détecte l’écho et termine la prise de mesure. Le signal de la broche ECHO du capteur reste à l’ETAT HAUT durant les étapes 3 et 4 ce qui permet de déterminer la distance D en fonction du temps de propagation T (s) et de la vitesse d’un ultrason V (340 m/s). D = ( V x T ) / 2 (car l’onde fait un aller-retour) . La Datasheet stipule une erreur de mesure inférieure à 2 %.

Ensuite, nous avons élaboré un modèle pour réguler l’angle des roues lorsqu’au moins un des capteurs détecte un obstacle. On peut distinguer plusieurs cas :

• Détection d'obstacle uniquement à l’avant (1) :

Dans ce cas on fait tourner les roues soit à gauche ou à droite avec un angle arbitraire car nous n’avons aucun moyen de connaître la meilleure direction à prendre (pas avec 3 capteurs).

• Détection d’obstacle uniquement à droite ou à gauche (2) :

Dans ce deuxième cas, les roues tourneront dans la direction opposée à l’obstacle qui peut ici être assimilé à un mur. La valeur de l’angle de correction sera déterminée en fonction de la distance mur-véhicule entre 2 instants t1 et t2 et de la vitesse moyenne V du véhicule, mesurable à l’aide d’un capteur à effet Hall (présenté plus haut). Ces mesures nous permettent de trouver l’angle de correction exact pour longer le mur : Nous avons D, la distance parcourue qui vaut D = dV / dT, d1 la première mesure de distance et d2 la deuxième en supposant que le véhicule se rapproche du mur. A l’aide de la trigonométrie nous pouvons définir l’angle de correction a (en rad): sin(a) = (d1 - d2) / D ⇔ a = arcsin( (d1 -d2) / D).

• Détection d’obstacle uniquement à droite ou à gauche + en face (3) :

Dans ce cas, nous faisons tourner les roues dans la direction ou il n’y a pas d’obstacle avec un angle arbitraire prédéfini.

• Détection d'obstacles dans toutes les directions (4) :

Le véhicule s’arrête.

Notre programme permet l’ajout d’autant de capteurs que nous le souhaitons, leur gestion étant faite grâce à des tableaux. L’ajout de capteurs ne demande donc aucune adaptation du code, si ce n’est la taille des tableaux. Nous utilisons pour cela une librairie dédiée sur ArduinoIDE, nommée NewPing. Ainsi, nous pouvons gérer les informations envoyées séparément par chaque capteur, reconnaître le cas de détection et agir en conséquence avec la commande de vitesse du moteur et la commande en position du servomoteur.

Le but de la détection est que, lorsque le véhicule se trouve à une distance inférieure à un seuil défini d’un mur ou d’un obstacle, le programme prend la main sur les actionneurs. Par conséquent, les signaux envoyés par le récepteur de la radiocommande doivent être ignorés, voire tus. L’intégration intermédiaire consiste alors simplement à faire en sorte que la détection d’une distance critique arrête l’écoute de la radiocommande et transmet une valeur fixe aux actionneurs. Pour cela, on manipule le registre PCICR du microcontrôleur afin d’autoriser ou non les interruptions, selon le mode dans lequel on se trouve. Lors de cette étape, la régulation n’étant pas encore faite, cette intégration intermédiaire permet de valider cette partie et son intégration, au moins matérielle, avec le reste du système.

Détermination des paramètres du moteur à courant continu

Une partie technique majeure de notre projet pour ce semestre a été la détermination des paramètres de notre système nécessaires à l’établissement de l’asservissement en vitesse, et particulièrement ceux concernant le moteur utilisé. En effet, à partir du moment où nous utilisons un moteur récupéré dont nous n’avons aucune spécification constructeur, nous avons expérimenté le reverse engineering pour déterminer expérimentalement différents paramètres électriques et mécaniques qui lui sont associés. La seule donnée que nous avons du moteur est 15T = 4317 rpm/V. Évidemment, quelques paramètres à l’échelle du système complet sont aussi nécessaires pour établir cette régulation, comme sa masse totale, le rapport de réduction global entre l’arbre moteur et les roues, le diamètre des roues…

Tout d’abord, les paramètres électriques que nous avions à déterminer étaient :

• L’inductance du bobinage inducteur.
• La résistance du bobinage inducteur.
• La constante de temps électrique (déduite de l’inductance et de la résistance, car 𝜏 = L/R).
• Le coefficient de conversion électromagnétique K.

Avec le schéma équivalent électrique du Moteur à Courant Continu, on définit les équations associées au moteur comme suit : Loi des mailles : U(t) = E + R.i(t) + L.di/dt avec E = K.Ω et Ce = K.I avec K la constante électromagnétique du moteur

L’équation mécanique de la MCC est la suivante : PFD en rotation sur l’arbre moteur isolé : J.dΩ/dt = Ce - f.Ω - Cs - Cc où J est l’inertie de l’arbre, Ce le couple électromagnétique développé par la MCC, f le coefficient de frottement visqueux, Cs le couple de frottement sec et Cc le couple de charge.

• Détermination de la résistance d'induit

On fait tourner le moteur pendant quelques minutes, on déconnecte l’alimentation puis on branche un ohmmètre aux bornes de la MCC, on mesure ensuite la résistance pour différentes positions du rotor. En effet, la résistance d’induit dépend de la position des balais et du collecteur. On fait ensuite la moyenne de ses différentes mesures.

On mesure une résistance d’induit R = 0.87 .

• Détermination de l'inductance d'induit

D’après l’équation électrique du moteur décrit plus haut. Si le rotor est bloqué on a E = K.Ω = 0 V, d’où U = R.i + L.di/dt avec la constante de temps électrique τe = L/R

En mesurant l’évolution temporelle du courant, on peut mesurer la constante de temps et en déduire l’inductance d’induit connaissant la résistance. Après avoir réglé l’oscilloscope en mode monocoup, on mesure le courant et on relève une constante de temps τe = 400 s. On en déduit L = 0.33 mH.

• Détermination de la constante électromagnétique

Pour mesurer la constante K, on doit faire un essai en génératrice à vide (car aucun courant ne circule dans ces conditions, ainsi la tension aux bornes du moteur est égale à la force électromotrice), étant donné que K = E/Ω , on effectue des mesures de vitesse du moteur pour différentes valeurs de E.

Pour cet essai, nous avons réalisé le banc suivant. Deux moteurs identiques sont utilisés, l’un est moteur tandis que l’autre est en génératrice. Les deux pignons sont identiques également, afin de garantir que les arbres moteurs tournent à la même vitesse. Grâce à une donnée constructeur, nous connaissons pour ce moteur le rapport entre la tension d’alimentation et sa vitesse de rotation. Comme les moteurs sont identiques, on connaît également celle de la machine en génératrice et on en déduit K en mesurant la tension (E dans ces conditions) à ses bornes.

On déduit de cet essai la droite suivante de E en fonction de la vitesse de rotation, et on en déduit le coefficient de de conversion électromécanique qui est la pente: on trouve K = 0.00076 V/rd/s.

• Détermination de la constante de temps mécanique

Pour mesurer τm, on fait tourner le moteur puis on coupe l’alimentation brutalement. À ce moment, U=E (car l’alimentation étant coupée, le moteur est en génératrice à vide le temps de s’arrêter). Le temps mis par E à atteindre 0 V est égal au temps mis par Ω pour atteindre 0 rd/s et ce temps est égal à τm. On mesure une constante de temps mécanique de 720 ms.

• Détermination du coefficient de frottement et de l'inertie

Pour mesurer le coefficient de frottement f, on trace la courbe I = f() à vide:

On calcule ensuite le coefficient de frottement visqueux avec la formule : f = K * ΔI/ΔΩ . On mesure f = 0.3e-6 N*m/rd*s^-1. On en déduit enfin l’inertie : J = f*m = 0.2e-6 kg*m².

Finalement, avec le peu de données constructeurs à notre disposition, nous avons réussi à caractériser les différentes grandeurs physiques de la MCC, afin de les réutiliser dans la modélisation du système sur MATLAB Simulink pour la conception de l'asservissement en vitesse.

Asservissement en vitesse et capteur de vitesse

Nous réalisons, ici, la conception de l’asservissement en vitesse du véhicule autonome logistique sous MATLAB Simulink. Nous utilisons une librairie de blocs permettant d’établir la Représentation Énergétique Macroscopique (REM), qui permet de mettre en exergue les transferts de puissance avec les accumulateurs d’énergie (rectangles barrés), les transformateurs (carrés) et les gyrateurs (cercles).

L’intérêt majeur de cette représentation est de pouvoir asservir facilement le système grâce à une partie commande (en bleu), similaire à la chaîne d’énergie (en rouge-orange), mais en sens opposé et avec une constitution inversée à l’intérieur du bloc.

En se permettant d’ajouter une boucle de régulation du courant avec une consigne en courant filtrée (pour ne pas avoir de dépassement indésirable, lié à un correcteur PI engendrant un ordre 1 au numérateur), voici le schéma MATLAB Simulink de notre véhicule autonome asservi en vitesse sous le formalisme de la REM :

Avec les paramètres du système bien renseignés dans un script MATLAB d’initialisation et les noms des variables bien recopiées dans les blocs de la REM sur Simulink, nous pouvons déterminer les paramètres optimaux à mettre pour le correcteur de vitesse.

L’asservissement nécessite bien-sûr l’ajout de composants permettant de mesurer la vitesse du véhicule, ainsi que le courant pour assurer la sécurité du système électronique. Nous avons donc opté pour un capteur à effet hall, placé à l’intérieur d’une roue. Un aimant est positionné sur le flanc de la roue, et chaque fois que l’aimant passe devant le capteur, un tour est réalisé.

Nous avons donc dû réaliser des supports spécifiques pour ce capteur, grâce au logiciel OnShape pour la conception, puis aux imprimantes 3D et au logiciel Cura pour la réalisation. Voici la modélisation réalisée pour les supports du capteur à effet hall :

La partie ocre est l’environnement, c'est-à-dire la roue et le triangle du véhicule sur lequel le capteur doit être positionné. Les supports imprimés sont en bleu. La modélisation de l’environnement était primordiale pour assurer l’intégration réelle du support sur le véhicule. En calculant le temps entre la détection du premier passage t1 de l'aimant et le deuxième t2 (1 tour de roue), on peut connaître la vitesse moyenne du véhicule entre ces deux instants grâce à la formule suivante: V = (2 * pi * R) / (t2 - t1)

Asservissement en position

Il faut réguler le véhicule en position par rapport à un obstacle distant, tel qu’un mur. Nous utilisons donc des capteurs à ultrason, de manière à acquérir la distance du véhicule par rapport aux obstacles environnants. Ensuite, un code Arduino permet de réaliser le traitement avec un algorithme de régulation PI, de manière à atteindre la valeur de consigne de distance par rapport au mur. Ainsi, le Robot Logistique sera apte à suivre des murs pour se guider à travers un entrepôt.

De plus, l'utilisation d'un capteur à effet Hall avec un capteur incrémental permettent de connaître la vitesse moyenne V du véhicule à un instant t. On peut donc en déduire la distance parcourue par le véhicule à chaque tour complet de roue.

Intégration globale

Schéma électrique final

Realisation éléctrique finale

Bilan

Tout d’abord, nous avons acquis énormément de compétences techniques grâce aux nombreuses conceptions, simulations et réalisations effectuées. En effet, les simulations MATLAB Simulink permettant de réguler en vitesse le véhicule autonome nous ont permis de mettre en pratique de nouvelles méthodes de représentation, telle que la REM. De plus, les problématiques survenant à une fréquence très élevée nous ont beaucoup appris sur les solutions techniques existantes pour y pallier. Il en sort donc une culture ingénieur enrichie. L’une des parties ayant apporté le plus de plus-value a été la détermination des paramètres du Moteur à Courant Continu de manière complètement autonome. La programmation en elle-même aura aussi apporté quelques spécificités techniques, comme la gestion des interruptions, notamment appliquées à l’appréhension de signaux à Modulation de Largeur d’Impulsion dans le cadre de la communication radiocommandée.

Ensuite, nous nous sommes concentrés sur la démarche de gestion de Projet, en utilisant la méthode A.G.I.L.E. Nous avons même élaboré un Plan d’Action, pour structurer et répartir nos activités. Nous avons donc bien appris en termes de compétences transversales, de manière à bien organiser un travail collaboratif dans un but commun. Néanmoins, nous ferons attention à ne pas être trop agile, c’est-à-dire à ne pas trop souvent redéfinir le Projet à chaque problème rencontré.

Enfin, notre patience et notre persévérance auront été mises à l’épreuve avec les nombreux et conséquents retards de livraison de matériel, voire l’indisponibilité de celui-ci. Mais il en ressort une résilience plus forte et une adaptabilité toujours plus aiguisée.

Conclusion du projet

Finalement, nous avons réussi à concevoir et tester unitairement tous les composants de notre Projet, même si nous avons peiné à intégrer le tout. Le Robot Logistique existe donc en simulation et partiellement en réel. Cependant, la chaîne de conversion énergétique est maîtrisée, il s’agit juste de perfectionner la régulation.

Le Cahier des Charges a donc été respecté, surtout concernant la partie validation fonctionnelle grâce aux nombreux tests unitaires menés. Néanmoins, le trop d’agilité que nous avons eu a nui à la finalisation de notre Projet, car il a souvent été redéfini, pour pallier aux nombreux problèmes auxquels nous avons fait face.

Véritablement, ce qui aura été créé au cours de ce Projet est une architecture électronique solide, des algorithmes de régulation cohérents et plutôt robustes et des simulations fonctionnelles. Le réel aura été partiellement construit, mais avec au moins toute l’architecture électronique fonctionnelle.

En définitive, ce Projet étalé sur 3 semestres nous a permis de mettre en œuvre le principe de véhicule autonome sous différentes applications.