Version du 6 mai 2022 à 18:05

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

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 devons acheter :

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

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.

Niveau 0: Appréhension des données véhiculées

Niveau 1: Implémentation de la sécurité passive

Niveau 2: Implémentation de la télécommunication en LoRaWAN

Théorie intermédiaire: Modélisation du buggy en vue d'une autonomie totale

Niveau 3 (final): Réalisation de l'autonomie temporaire du buggy

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.