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

*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 ==

== 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: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.

::::- [[Fichier: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.


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