Version du 6 mai 2022 à 17:35

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.

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

[insérer fonctionnalités et solutions adaptées]

Projet réalisé au S6

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 .