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 23 novembre)
(Séance 27 novembre)
Ligne 157 : Ligne 157 :
 
:::=> Amélioration de l'interface visuel.
 
:::=> 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.
 
::- 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:
 +
::- 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é.
 +
:::=> Chargement automatique du fichier ".sdf" dans la dSPACE au lancement du programme.
 +
:::=> 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).
 +
:::=> 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).
 +
 +
*Problèmes à régler:
 +
::- Observation de temps en temps d'un signal transmis involontairement aux roues.
 +
:::=> Il semblerait qu'un signal bruité puisse être à l'origine de ce problème.
 +
:::=> Un filtre à l'entré des variateurs des moteurs de roue pourrait résoudre ce soucis, en attente de résolution.
 +
 +
*Reste à faire:
 +
::- Acquisition/sauvegarde des valeurs de courant/tension/vitesse via dSPACE ControlDesk (pour supervision).
 +
::- Intégrer une centrale inertielle au châssis.
 +
::- Test du véhicule à l'extérieur en pilotage manuel.

Version du 29 janvier 2013 à 16:39

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

Fichier:Epave1.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.
  • 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:
- 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é.
=> Chargement automatique du fichier ".sdf" dans la dSPACE au lancement du programme.
=> 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).
=> 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).
  • Problèmes à régler:
- Observation de temps en temps d'un signal transmis involontairement aux roues.
=> Il semblerait qu'un signal bruité puisse être à l'origine de ce problème.
=> Un filtre à l'entré des variateurs des moteurs de roue pourrait résoudre ce soucis, en attente de résolution.
  • Reste à faire:
- Acquisition/sauvegarde des valeurs de courant/tension/vitesse via dSPACE ControlDesk (pour supervision).
- Intégrer une centrale inertielle au châssis.
- Test du véhicule à l'extérieur en pilotage manuel.