Intégration d'une carte d'acquisition et de commande dans un véhicule autonome : Différence entre versions
De Wiki de Projets IMA
(→Séance 15 octobre) |
(→Février 2013) |
||
(45 révisions intermédiaires par 2 utilisateurs non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
+ | *Rapport du projet :[[media:Rapport_Février.pdf]] | ||
+ | *Codes ( Layouts interface ControlDesk & Arduino & MatlabSimulink nécessite Matlab 2006) : [[media:ProjetRobucar1103.zip]] | ||
+ | |||
+ | |||
== Introduction : Projet de Fin d'Etude == | == Introduction : Projet de Fin d'Etude == | ||
Ligne 15 : | Ligne 19 : | ||
* Première rencontre avec le châssis (épave sans moteurs/roues à l'arrière). | * Première rencontre avec le châssis (épave sans moteurs/roues à l'arrière). | ||
− | [[Fichier: | + | ::::- [[Fichier:Epave_2.JPG]] |
== Séance 25 septembre == | == Séance 25 septembre == | ||
Ligne 73 : | Ligne 77 : | ||
::- Mise en place des blocs "évaluation RRA" et "capteurs" pour le modèle. | ::- Mise en place des blocs "évaluation RRA" et "capteurs" pour le modèle. | ||
::- Documentation sur les seuils (bloc détection + isolation). | ::- Documentation sur les seuils (bloc détection + isolation). | ||
− | :::=> Matrice de signature de | + | :::=> Matrice de signature des fautes. |
− | + | ||
− | ::- devoir | + | *Commande du vérin : |
+ | Le vérin est équipé d'un codeur absolu communicant en SSI. N'ayant pas d'interface SSI sur notre carte d'acquisition Dspace nous avons choisi de réaliser une conversion SSI -> RS232 à travers un arduino. | ||
+ | Matériel : | ||
+ | ::- devoir se procurer un arduino pour réaliser la conversion SSI/RS232. | ||
+ | |||
== Séance 18 octobre == | == Séance 18 octobre == | ||
*Supervision | *Supervision | ||
Ligne 81 : | Ligne 89 : | ||
::- Réalisation sous control Desk d'une fenêtre "message d'erreur". | ::- Réalisation sous control Desk d'une fenêtre "message d'erreur". | ||
::- pour l'instant le système n'est pas isolable redondance capteur à envisager). | ::- pour l'instant le système n'est pas isolable redondance capteur à envisager). | ||
+ | |||
+ | *Matériel: | ||
+ | ::- Récupération d'un arduino Mega | ||
+ | |||
== Séance 5 novembre == | == Séance 5 novembre == | ||
*Installation d'une carte avec Arduino dans le boitier de puissance. | *Installation d'une carte avec Arduino dans le boitier de puissance. | ||
+ | |||
+ | ::::- [[Fichier:Arduino.JPG]] | ||
+ | |||
*Travaux réalisés: | *Travaux réalisés: | ||
::- Réalisation d'un code sur Arduino pour récupérer la valeur du capteur absolu. | ::- Réalisation d'un code sur Arduino pour récupérer la valeur du capteur absolu. | ||
− | :::=> On trouve des valeurs entre 8000 et 13000 | + | :::=> On trouve des valeurs entre 8000 et 13000 (valeurs incohérentes !!!) |
+ | |||
== Séance 7 novembre == | == Séance 7 novembre == | ||
* Câblage du vérin de direction. | * Câblage du vérin de direction. | ||
* Travaux réalisés : | * Travaux réalisés : | ||
::- Génération d'un signal PWM pour commander le vérin. | ::- Génération d'un signal PWM pour commander le vérin. | ||
− | ::- Génération de signaux digitaux pour l'inhibit et la direction. | + | ::- Génération de signaux digitaux pour l'inhibit et pour le choix du sens de la direction. |
− | :::=> Déplacement du vérin opérationnel. | + | :::=> Résultat: Déplacement du vérin opérationnel. |
+ | |||
== Séance 12 novembre == | == Séance 12 novembre == | ||
*Travaux réalisés : | *Travaux réalisés : | ||
− | + | ||
::- Implémentation du code liaison série sur Arduino | ::- Implémentation du code liaison série sur Arduino | ||
:::=> mise en place de la communication série ( parité, nb bits stop, longueur du message) | :::=> mise en place de la communication série ( parité, nb bits stop, longueur du message) | ||
− | + | ||
== Séance 14 novembre == | == Séance 14 novembre == | ||
*Travaux réalisés : | *Travaux réalisés : | ||
− | ::- Réalisation d'une carte conversion TTL->RS232. | + | ::- Réalisation d'une carte pour la conversion TTL -> RS232 à l'aide d'un pic MAX232N. |
− | ::- Test de la carte => | + | ::- Test de la carte => communication série fonctionnel. |
+ | |||
== Séance 19 novembre == | == Séance 19 novembre == | ||
*Travaux réalisés : | *Travaux réalisés : | ||
− | + | ||
::- Test de la carte. | ::- Test de la carte. | ||
− | :::=> Communication Arduino/Dspace établie | + | :::=> Communication Arduino/Dspace établie sur 1 octet. Données échangées entre le capteur et l'arduino sur 2 octets. |
− | ::- Problème envoie sur 2 octets. | + | ::- Problème : envoie sur 2 octets NON fonctionnel. |
:::=> Développement du code arduino pour essayer de résoudre le problème. | :::=> Développement du code arduino pour essayer de résoudre le problème. | ||
+ | ::-Solution : temporisation entre chaque envoi | ||
+ | |||
== Séance 20 novembre == | == Séance 20 novembre == | ||
*Travaux réalisés: | *Travaux réalisés: | ||
Ligne 127 : | Ligne 147 : | ||
::- Implémentation sous Simulink de la régulation de direction. | ::- Implémentation sous Simulink de la régulation de direction. | ||
::- Tests de la régulation | ::- Tests de la régulation | ||
+ | |||
+ | |||
+ | == Séance 23 novembre == | ||
+ | *Travaux réalisés : | ||
+ | ::- Implémentation sous Simulink de la régulation de direction. | ||
+ | :::=> la régulation n'est pas parfaite, les biellettes de direction touchent légèrement le châssis. | ||
+ | :::=> La régulation n'est pas "smooth", on voit des paliers ainsi que des dépassements. | ||
+ | :::=> A corriger pour la prochaine séance. | ||
+ | == Séance 26 novembre == | ||
+ | *Travaux réalisés : | ||
+ | ::- Tests pour différentes valeurs des paramètres du correcteur. | ||
+ | :::=> les paliers sont moins visibles et il n'y a plus de dépassement. | ||
+ | == Séance 27 novembre == | ||
+ | *Travaux réalisés : | ||
+ | ::- Nettoyage sur Simulink et ControlDesk. | ||
+ | :::=> Amélioration de l'interface visuel. | ||
+ | ::- Recherche d'un modèle cinématique pour prendre en compte la différence de vitesse de chaque roue en virage. | ||
+ | |||
+ | == Janvier 2013 == | ||
+ | *Modification du code Matlab-Simulink: | ||
+ | ::- Jusqu'à présent les différents programmes ont été réalisés uniquement pour le train arrière. | ||
+ | ::- Duplication du code pour le train avant. | ||
+ | ::- Modification des blocs pour prendre en compte les capteurs et actionneurs du train avant. | ||
+ | |||
+ | *Régulation de la traction: | ||
+ | ::- Branchement du train avant sur la dSPACE. | ||
+ | :::- Premiers tests pas très convainquant : problèmes de hardware (mauvais branchements sur la voiture). | ||
+ | :::- Résolu : les quatre roues tournent à la même vitesse de consigne. | ||
+ | |||
+ | *Modification du code Arduino: | ||
+ | ::- Branchement du deuxième capteur absolu. | ||
+ | ::- Initialisation des registres. | ||
+ | ::- Récupération des données des deux capteurs. | ||
+ | ::- Envoie des données sur le port RS232 de la dSPACE. | ||
+ | :::- On récupère bien les bonnes données, nous pouvons donc passer à la régulation de la direction. | ||
+ | |||
+ | *Régulation de la direction: | ||
+ | ::- Premiers tests = échec : la direction avant part en buté malgré l'inhibit. | ||
+ | :::- Problème trouvé : le variateur est mal câblé. | ||
+ | :::- Résolu : la direction est bien régulée, à l'avant comme à l'arrière. | ||
+ | |||
+ | *Interface graphique: création d'un interface graphique évolué. | ||
+ | |||
+ | :::- Réalisation d'un script en python permettant : | ||
+ | ::::- Le chargement automatique du fichier "Map File" dans la dSPACE au lancement du programme. | ||
+ | ::::- L'affichage automatique du poste de pilotage en plein écran en mode animation (l'utilisateur peut conduire la voiture directement, sans connaître le logiciel ControlDesk). | ||
+ | |||
+ | :::- Réalisation de plusieurs layouts : | ||
+ | :::::- Poste de pilotage (avec toutes les données importantes à la conduite). | ||
+ | :::::- Mode manuel alternatif (permet de contrôler manuellement la voiture en cas de bug de la régulation). | ||
+ | :::::- Régulation de la direction (toutes les données utiles pour la régulation de la direction). | ||
+ | :::::- Régulation de la traction (toutes les données utiles pour la régulation de la traction). | ||
+ | |||
+ | |||
+ | *Reste à faire: | ||
+ | ::- Acquisition et sauvegarde des valeurs de courant, tension et vitesse. | ||
+ | ::- Intégrer une centrale inertielle au châssis. | ||
+ | ::- Monter la coque du véhicule | ||
+ | ::- Test du véhicule à l'extérieur en pilotage manuel. | ||
+ | |||
+ | |||
+ | [[Fichier:Robucar_cale1.jpg]] | ||
+ | |||
+ | == Février 2013 == | ||
+ | |||
+ | * Acquisition et sauvegarde des valeurs de courant, tension et vitesse. | ||
+ | |||
+ | ::- Utilisation de la librairie "Clib". Cette librairie en C permet de communiquer avec la Dspace sans passer par le logiciel habituel ControlDesk. | ||
+ | ::- En utilisant cette librairie, on a réalisé un programme permettant de récupérer les différentes mesures en temps réel et de les stocker dans un fichier .txt . | ||
+ | |||
+ | * Intégration d'une centrale inertielle du type Xsens MTi. | ||
+ | |||
+ | ::- La Dspace n'est pas équipée de port USB. On a bronché la centrale directement sur un des ports USB du PC. | ||
+ | ::- Le fabriquant fourni plusieurs librairies pour l'acquisition des mesures. | ||
+ | ::- Réalisation d'un programme en C++ utilisant la librairie Clib et les différentes librairies fourni par le fabriquant pour l'acquisition des données et la communication entre le PC et la Dspace . | ||
+ | |||
+ | * Optimisation de l'espace et montage de la coque | ||
+ | ::- Une fois les différents programmes (commande, acquisition et supervision) testés sur cales, on a : | ||
+ | :::- Soudé les connectiques. | ||
+ | :::- Optimisé l'espace occupé par les câbles. | ||
+ | :::- Nettoyé le châssis et la coque. | ||
+ | :::- Monté la coque. | ||
+ | |||
+ | ::::- [[Fichier:Robucar_Scoque.JPG]] ===> [[Fichier:Robucar_coque.JPG]] | ||
+ | |||
+ | * Test et validation du véhicule à l’extérieur. | ||
+ | ::- Les tests du véhicule se sont effectués dans la piste d'essai du laboratoire Lagis qui se situe à 50 m de Polytech'Lille. | ||
+ | |||
+ | ::::-[[Fichier:Robucar_exterieur.jpg]] | ||
+ | |||
+ | :::- Les parties testées et validées : | ||
+ | ::::- La traction et les accélérations. | ||
+ | ::::- La régulation de la direction. | ||
+ | ::::- L'interface graphique de commande et de supervision. | ||
+ | ::::- Les modes de direction : Multi-direction, Parking, avant seul, arrière seul. | ||
+ | ::::- Fiabilité du montage de la coque. | ||
+ | |||
+ | ::- Ces différents tests nous ont permis de prendre connaissance puis de corriger plusieurs problèmes à savoir : | ||
+ | |||
+ | :::- Accélérations brutales: | ||
+ | ::::- Analyse : Pendant la phase de teste, on a remarqué que les accélérations sont trop brutales ce qui rend la conduite du véhicule désagréable. En effet les moteurs passent de 0 à la consigne désirée instantanément. | ||
+ | ::::- Solution : On a augmenté le temps de réponse des moteurs au niveau des variateurs. | ||
+ | |||
+ | :::- Blocage de la direction : | ||
+ | ::::- Analyse : On a remarqué que la direction se bloque. Le problème venait de la stratégie de commande, en effet afin d'éviter que les vérins de direction aillent en buté, on a fixé des seuils à ne pas dépasser. Au-delà la commande de la direction est arrêtée. Ces seuils ont été fixés à vide sur cale, avec le poids et l'inertie du véhicule ces seuils sont vite dépassés. | ||
+ | ::::- Solution : On a défini de nouveaux seuils expérimentalement. | ||
+ | |||
+ | :::- Connectique non fixée : | ||
+ | ::::- Analyse : Il suffisait d'aller légèrement plus vite (15 km/h) puis de freiner brutalement pour se rendre compte qu'il fallait revérifier les connectiques. En effet la connectique reliant les codeurs absolus au bloc de puissance s'est débranché ce qui a causé l'arrêt de la régulation de direction et donc de la direction. | ||
+ | ::::- Solution : On a démonté la coque pour revérifier toutes les connectiques. |
Version actuelle datée du 27 février 2013 à 10:48
- Rapport du projet :media:Rapport_Février.pdf
- Codes ( Layouts interface ControlDesk & Arduino & MatlabSimulink nécessite Matlab 2006) : media:ProjetRobucar1103.zip
Sommaire
- 1 Introduction : Projet de Fin d'Etude
- 2 Objectifs
- 3 Séance 24 septembre
- 4 Séance 25 septembre
- 5 Séance 26 septembre
- 6 Séance 1 octobre
- 7 Séance 3 octobre
- 8 Séance 8 octobre
- 9 Séance 10 octobre
- 10 Séance 15 octobre
- 11 Séance 17 octobre
- 12 Séance 18 octobre
- 13 Séance 5 novembre
- 14 Séance 7 novembre
- 15 Séance 12 novembre
- 16 Séance 14 novembre
- 17 Séance 19 novembre
- 18 Séance 20 novembre
- 19 Séance 21 novembre
- 20 Séance 23 novembre
- 21 Séance 26 novembre
- 22 Séance 27 novembre
- 23 Janvier 2013
- 24 Février 2013
Introduction : Projet de Fin d'Etude
Objectifs
- But principal : remonter un robucar.
- Sous objectifs :
- => Intégrer la carte d'acquisition Dspace.
- => Commander les moteurs.
- => Commander les vérins de direction.
- => Lire les valeurs de capteurs.
- => Réguler la direction et la vitesse.
- => Réaliser la supervision du véhicule.
Séance 24 septembre
- Prise de contact avec l'équipe LAGIS travaillant sur le projet INTRADE.
- Première rencontre avec le châssis (épave sans moteurs/roues à l'arrière).
Séance 25 septembre
- Contact avec notre tuteur (Mr. Rochdi Merzouki) : présentation des attentes et des objectifs du projet.
- => PowerPc Dspace 1103 et sa carte d'acquisition unique.
- => Définition de l'objectif final : faire rouler le robucar.
- Remontage des moteurs (triangles + biellettes de direction) sur le châssis.
- => Remontage des batteries.
- Matériel disponible :
- - Dspace 1103 et sa carte d'acquisition.
- - Ordinateur fixe équipé de : Matlab 2006a + Control Desk + clé usb d'activation de controlDesk + une interface pour communiquer avec la DS1103.
Séance 26 septembre
- Prise en main de Dspace/Control Desk à travers la réalisation d'un tutoriel récupéré sur internet.
- La programmation de la Dspace se fera à travers matlab en temps réel. le logiciel Control Desk nous permettra de réaliser une interface de commande.
Séance 1 octobre
- Récupération des paramètres des deux variateurs alimentant les deux moteurs depuis un autre véhicule Robucar opérationnel.
- Génération d'un signal 0 -> 5V à travers l'E/S Analogique de la Dspace pour la commande des moteurs.
- Attente de la fin du câblage des moteurs (arrières) pour des premiers tests.
Séance 3 octobre
- Premiers tests :
- => envoi d'une consigne aux moteurs.
- => problèmes sur la commande : les variateurs sont en défaut.
- => Solutions : câblage de toutes les masses sur une seul masse commune et initialisation des moteurs à l'arrêt (envoi d'une consigne 2,5V).
- travaux réalisés :
- - Réalisation d'une première interface de contrôle sur Control Desk.
- - Démarrage des deux moteurs du train arrière.
- - Génération d'un signal PWM (en prévoyance pour le vérin de direction).
Séance 8 octobre
- Travaux réalisés :
- - Câblage des codeurs incrémentaux.
- - Récupération des données des codeurs incrémentaux (droit et gauche).
- =>possibilité de réguler la vitesse des roues.
- Objectifs prochaine séance : commencer la régulation des roues en vitesse.
Séance 10 octobre
- Travaux réalisés :
- - Conversion de la valeur du capteur incrémental : position -> vitesse (tr/s).
- - Choix et réalisation de la commande des moteurs en pourcentage (0% = arrêt , 100% = vitesse max).
- - Instauration d'un switch sur notre interface de commande pour la marche arrière.
- - Régulation de chaque roue en vitesse.
- => Résultat : Les deux roues sont synchronisées et tournent à la même vitesse.
Séance 15 octobre
- Acquisition du modèle du moteur.
- Travaux réalisés
- - Réalisation du modèle de supervision sous Simulink.
- - test du modèle + comparaison avec système réel.
- => résultats cohérents.
Séance 17 octobre
- Supervision
- - Mise en place des blocs "évaluation RRA" et "capteurs" pour le modèle.
- - Documentation sur les seuils (bloc détection + isolation).
- => Matrice de signature des fautes.
- Commande du vérin :
Le vérin est équipé d'un codeur absolu communicant en SSI. N'ayant pas d'interface SSI sur notre carte d'acquisition Dspace nous avons choisi de réaliser une conversion SSI -> RS232 à travers un arduino. Matériel :
- - devoir se procurer un arduino pour réaliser la conversion SSI/RS232.
Séance 18 octobre
- Supervision
- - Détermination des seuils pour une correspondance avec la MSF.
- - Réalisation sous control Desk d'une fenêtre "message d'erreur".
- - pour l'instant le système n'est pas isolable redondance capteur à envisager).
- Matériel:
- - Récupération d'un arduino Mega
Séance 5 novembre
- Installation d'une carte avec Arduino dans le boitier de puissance.
- Travaux réalisés:
- - Réalisation d'un code sur Arduino pour récupérer la valeur du capteur absolu.
- => On trouve des valeurs entre 8000 et 13000 (valeurs incohérentes !!!)
- - Réalisation d'un code sur Arduino pour récupérer la valeur du capteur absolu.
Séance 7 novembre
- Câblage du vérin de direction.
- Travaux réalisés :
- - Génération d'un signal PWM pour commander le vérin.
- - Génération de signaux digitaux pour l'inhibit et pour le choix du sens de la direction.
- => Résultat: Déplacement du vérin opérationnel.
Séance 12 novembre
- Travaux réalisés :
- - Implémentation du code liaison série sur Arduino
- => mise en place de la communication série ( parité, nb bits stop, longueur du message)
- - Implémentation du code liaison série sur Arduino
Séance 14 novembre
- Travaux réalisés :
- - Réalisation d'une carte pour la conversion TTL -> RS232 à l'aide d'un pic MAX232N.
- - Test de la carte => communication série fonctionnel.
Séance 19 novembre
- Travaux réalisés :
- - Test de la carte.
- => Communication Arduino/Dspace établie sur 1 octet. Données échangées entre le capteur et l'arduino sur 2 octets.
- - Problème : envoie sur 2 octets NON fonctionnel.
- => Développement du code arduino pour essayer de résoudre le problème.
- -Solution : temporisation entre chaque envoi
- - Test de la carte.
Séance 20 novembre
- Travaux réalisés:
- - Utilisation d'un volant/pédales en usb sur Dspace.
- - Commencement d'une stratégie de commande en vitesse. (5 vitesses déclarées).
- => objectif : obtenir un démarrage doux.
- - Obtention d'information décisives sur le capteur absolue
- => Correction du code Arduino pour correspondre aux données du capteur (13bits et codé en binaire).
Séance 21 novembre
- Travaux réalisés:
- - Développement de la stratégie de commande en vitesse.
- => Résultat acceptable.
- - Récupération des valeurs extrêmes pour le codeur absolu (5040 et 3984).
- - Mise en place d'un système de freinage.
- - Réalisation sur papier de la régulation de la direction.
- - Nettoyage du code Arduino + commentaires.
- - Développement de la stratégie de commande en vitesse.
- Objectifs prochaine séance :
- - Implémentation sous Simulink de la régulation de direction.
- - Tests de la régulation
Séance 23 novembre
- Travaux réalisés :
- - Implémentation sous Simulink de la régulation de direction.
- => la régulation n'est pas parfaite, les biellettes de direction touchent légèrement le châssis.
- => La régulation n'est pas "smooth", on voit des paliers ainsi que des dépassements.
- => A corriger pour la prochaine séance.
- - Implémentation sous Simulink de la régulation de direction.
Séance 26 novembre
- Travaux réalisés :
- - Tests pour différentes valeurs des paramètres du correcteur.
- => les paliers sont moins visibles et il n'y a plus de dépassement.
- - Tests pour différentes valeurs des paramètres du correcteur.
Séance 27 novembre
- Travaux réalisés :
- - Nettoyage sur Simulink et ControlDesk.
- => Amélioration de l'interface visuel.
- - Recherche d'un modèle cinématique pour prendre en compte la différence de vitesse de chaque roue en virage.
- - Nettoyage sur Simulink et ControlDesk.
Janvier 2013
- Modification du code Matlab-Simulink:
- - Jusqu'à présent les différents programmes ont été réalisés uniquement pour le train arrière.
- - Duplication du code pour le train avant.
- - Modification des blocs pour prendre en compte les capteurs et actionneurs du train avant.
- Régulation de la traction:
- - Branchement du train avant sur la dSPACE.
- - Premiers tests pas très convainquant : problèmes de hardware (mauvais branchements sur la voiture).
- - Résolu : les quatre roues tournent à la même vitesse de consigne.
- - Branchement du train avant sur la dSPACE.
- Modification du code Arduino:
- - Branchement du deuxième capteur absolu.
- - Initialisation des registres.
- - Récupération des données des deux capteurs.
- - Envoie des données sur le port RS232 de la dSPACE.
- - On récupère bien les bonnes données, nous pouvons donc passer à la régulation de la direction.
- Régulation de la direction:
- - Premiers tests = échec : la direction avant part en buté malgré l'inhibit.
- - Problème trouvé : le variateur est mal câblé.
- - Résolu : la direction est bien régulée, à l'avant comme à l'arrière.
- - Premiers tests = échec : la direction avant part en buté malgré l'inhibit.
- Interface graphique: création d'un interface graphique évolué.
- - Réalisation d'un script en python permettant :
- - Le chargement automatique du fichier "Map File" dans la dSPACE au lancement du programme.
- - L'affichage automatique du poste de pilotage en plein écran en mode animation (l'utilisateur peut conduire la voiture directement, sans connaître le logiciel ControlDesk).
- - Réalisation d'un script en python permettant :
- - Réalisation de plusieurs layouts :
- - Poste de pilotage (avec toutes les données importantes à la conduite).
- - Mode manuel alternatif (permet de contrôler manuellement la voiture en cas de bug de la régulation).
- - Régulation de la direction (toutes les données utiles pour la régulation de la direction).
- - Régulation de la traction (toutes les données utiles pour la régulation de la traction).
- - Réalisation de plusieurs layouts :
- Reste à faire:
- - Acquisition et sauvegarde des valeurs de courant, tension et vitesse.
- - Intégrer une centrale inertielle au châssis.
- - Monter la coque du véhicule
- - Test du véhicule à l'extérieur en pilotage manuel.
Février 2013
- Acquisition et sauvegarde des valeurs de courant, tension et vitesse.
- - Utilisation de la librairie "Clib". Cette librairie en C permet de communiquer avec la Dspace sans passer par le logiciel habituel ControlDesk.
- - En utilisant cette librairie, on a réalisé un programme permettant de récupérer les différentes mesures en temps réel et de les stocker dans un fichier .txt .
- Intégration d'une centrale inertielle du type Xsens MTi.
- - La Dspace n'est pas équipée de port USB. On a bronché la centrale directement sur un des ports USB du PC.
- - Le fabriquant fourni plusieurs librairies pour l'acquisition des mesures.
- - Réalisation d'un programme en C++ utilisant la librairie Clib et les différentes librairies fourni par le fabriquant pour l'acquisition des données et la communication entre le PC et la Dspace .
- Optimisation de l'espace et montage de la coque
- - Une fois les différents programmes (commande, acquisition et supervision) testés sur cales, on a :
- - Soudé les connectiques.
- - Optimisé l'espace occupé par les câbles.
- - Nettoyé le châssis et la coque.
- - Monté la coque.
- - Une fois les différents programmes (commande, acquisition et supervision) testés sur cales, on a :
- Test et validation du véhicule à l’extérieur.
- - Les tests du véhicule se sont effectués dans la piste d'essai du laboratoire Lagis qui se situe à 50 m de Polytech'Lille.
- - Les parties testées et validées :
- - La traction et les accélérations.
- - La régulation de la direction.
- - L'interface graphique de commande et de supervision.
- - Les modes de direction : Multi-direction, Parking, avant seul, arrière seul.
- - Fiabilité du montage de la coque.
- - Les parties testées et validées :
- - Ces différents tests nous ont permis de prendre connaissance puis de corriger plusieurs problèmes à savoir :
- - Accélérations brutales:
- - Analyse : Pendant la phase de teste, on a remarqué que les accélérations sont trop brutales ce qui rend la conduite du véhicule désagréable. En effet les moteurs passent de 0 à la consigne désirée instantanément.
- - Solution : On a augmenté le temps de réponse des moteurs au niveau des variateurs.
- - Accélérations brutales:
- - Blocage de la direction :
- - Analyse : On a remarqué que la direction se bloque. Le problème venait de la stratégie de commande, en effet afin d'éviter que les vérins de direction aillent en buté, on a fixé des seuils à ne pas dépasser. Au-delà la commande de la direction est arrêtée. Ces seuils ont été fixés à vide sur cale, avec le poids et l'inertie du véhicule ces seuils sont vite dépassés.
- - Solution : On a défini de nouveaux seuils expérimentalement.
- - Blocage de la direction :
- - Connectique non fixée :
- - Analyse : Il suffisait d'aller légèrement plus vite (15 km/h) puis de freiner brutalement pour se rendre compte qu'il fallait revérifier les connectiques. En effet la connectique reliant les codeurs absolus au bloc de puissance s'est débranché ce qui a causé l'arrêt de la régulation de direction et donc de la direction.
- - Solution : On a démonté la coque pour revérifier toutes les connectiques.
- - Connectique non fixée :