Version du 6 mai 2022 à 16:31

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)