Intégration d'une carte d'acquisition et de commande dans un véhicule autonome

De Wiki d'activités IMA


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).
- Epave 2.JPG

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.
- Arduino.JPG
  • 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 !!!)

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)

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

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

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.


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.
- Robucar Scoque.JPG ===> 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.
-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.