Wiki de Projets IMA - Contributions de l’utilisateur [fr]

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

2013-02-27T10:48:19Z

Ielhasna : /* Février 2013 */

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

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

2013-02-27T10:47:55Z

Ielhasna : /* Février 2013 */

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

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

2013-02-27T10:47:37Z

Ielhasna : /* Février 2013 */

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

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

2013-02-27T10:47:08Z

Ielhasna : /* Février 2013 */

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

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

2013-02-27T10:46:02Z

Ielhasna : /* Février 2013 */

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

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

2013-02-27T10:45:00Z

Ielhasna : /* Février 2013 */

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

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

2013-02-27T10:44:17Z

Ielhasna : /* Février 2013 */

*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]] ===> [[Fichier:Robucar_exterieur.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.

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

Fichier:Robucar exterieur.jpg

2013-02-27T10:43:20Z

Ielhasna :

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

2013-02-27T10:41:28Z

Ielhasna :

*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]] ===> [[Fichier:IMG00233-20130220-1606.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.

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

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

2013-02-27T10:36:43Z

Ielhasna :

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

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

Fichier:Robucar cale1.jpg

2013-02-27T10:35:58Z

Ielhasna :

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

2013-02-27T10:33:45Z

Ielhasna :

*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_cale.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.

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

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

2013-02-27T10:26:40Z

Ielhasna :

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

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

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

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

2013-02-27T10:25:14Z

Ielhasna :

*Rapport du projet :[[media:Rapport_Février.pdf]]
*Codes ( 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.

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

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

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

2013-02-27T10:24:54Z

Ielhasna :

*Rapport du projet :[[media:Rapport_Février.pdf]]
[[Rapport_Février.pdf]]
*Codes ( 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.

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

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

Fichier:Rapport Février.pdf

2013-02-27T10:24:08Z

Ielhasna :

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

2013-02-27T10:22:49Z

Ielhasna :

*Rapport du projet :
*Codes ( 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.

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

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

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

2013-02-27T10:21:15Z

Ielhasna :

*Rapport du projet :
*Codes ( Arduino & MatlabSimulink nécessite Matlab 2006) : [[Fichier: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.

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

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

Fichier:ProjetRobucar1103.zip

2013-02-27T10:19:43Z

Ielhasna :

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

2013-02-27T10:17:31Z

Ielhasna :

Rapport du projet :
Codes ( Arduino & MatlabSimulink nécessite Matlab 2006) :

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

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

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

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

2013-02-21T11:01:27Z

Ielhasna : /* Janvier 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).

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

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

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

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

2013-02-21T10:59:41Z

Ielhasna : /* 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).

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

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

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

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

2013-02-21T10:54:32Z

Ielhasna : /* Janvier 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).

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

== Février 2013 ==

* Acquisition et sauvegarde des valeurs de courant/tension/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é de port USB. On a câblé 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 pour la communication entre le PC et la Dspace et les différentes librairies fourni par le fabriquant pour l'acquisition.

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

:::- 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 de 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épassé. Au delà la direction est arrêtée. Ces seuils ont été fixé à 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 un 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.

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

2013-02-21T10:34:44Z

Ielhasna : /* Séance 5 novembre */

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

== Février 2013 ==

* Acquisition et sauvegarde des valeurs de courant/tension/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é de port USB. On a câblé 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 pour la communication entre le PC et la Dspace et les différentes librairies fourni par le fabriquant pour l'acquisition.

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

:::- 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 de 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épassé. Au delà la direction est arrêtée. Ces seuils ont été fixé à 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 un 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.

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

2013-02-21T10:34:30Z

Ielhasna : /* Séance 5 novembre */

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

== Février 2013 ==

* Acquisition et sauvegarde des valeurs de courant/tension/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é de port USB. On a câblé 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 pour la communication entre le PC et la Dspace et les différentes librairies fourni par le fabriquant pour l'acquisition.

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

:::- 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 de 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épassé. Au delà la direction est arrêtée. Ces seuils ont été fixé à 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 un 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.

Fichier:Arduino.JPG

2013-02-21T10:32:52Z

Ielhasna :

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

2013-02-21T10:29:56Z

Ielhasna : /* Séance 24 septembre */

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

== Février 2013 ==

* Acquisition et sauvegarde des valeurs de courant/tension/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é de port USB. On a câblé 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 pour la communication entre le PC et la Dspace et les différentes librairies fourni par le fabriquant pour l'acquisition.

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

:::- 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 de 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épassé. Au delà la direction est arrêtée. Ces seuils ont été fixé à 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 un 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.

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

2013-02-21T10:29:44Z

Ielhasna : /* Séance 24 septembre */

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

== Février 2013 ==

* Acquisition et sauvegarde des valeurs de courant/tension/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é de port USB. On a câblé 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 pour la communication entre le PC et la Dspace et les différentes librairies fourni par le fabriquant pour l'acquisition.

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

:::- 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 de 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épassé. Au delà la direction est arrêtée. Ces seuils ont été fixé à 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 un 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.

Fichier:Epave 2.JPG

2013-02-21T10:29:18Z

Ielhasna :

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

2013-02-21T10:23:23Z

Ielhasna : /* 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).

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

== Février 2013 ==

* Acquisition et sauvegarde des valeurs de courant/tension/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é de port USB. On a câblé 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 pour la communication entre le PC et la Dspace et les différentes librairies fourni par le fabriquant pour l'acquisition.

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

:::- 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 de 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épassé. Au delà la direction est arrêtée. Ces seuils ont été fixé à 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 un 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.

Fichier:Robucar Scoque.JPG

2013-02-21T10:22:21Z

Ielhasna :

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

2013-02-21T10:19:28Z

Ielhasna : /* 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).

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

== Février 2013 ==

* Acquisition et sauvegarde des valeurs de courant/tension/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é de port USB. On a câblé 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 pour la communication entre le PC et la Dspace et les différentes librairies fourni par le fabriquant pour l'acquisition.

* 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_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.

:::- 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 de 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épassé. Au delà la direction est arrêtée. Ces seuils ont été fixé à 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 un 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.

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

2013-02-21T10:19:01Z

Ielhasna :

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

== Février 2013 ==

* Acquisition et sauvegarde des valeurs de courant/tension/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é de port USB. On a câblé 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 pour la communication entre le PC et la Dspace et les différentes librairies fourni par le fabriquant pour l'acquisition.

* 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_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.

:::- 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 de 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épassé. Au delà la direction est arrêtée. Ces seuils ont été fixé à 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 un 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.

Fichier:Robucar coque.JPG

2013-02-21T10:17:42Z

Ielhasna :

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

2013-02-21T10:11:38Z

Ielhasna : /* Janvier 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).

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

== Février 2013 ==

* Acquisition et sauvegarde des valeurs de courant/tension/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é de port USB. On a câblé 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 pour la communication entre le PC et la Dspace et les différentes librairies fourni par le fabriquant pour l'acquisition.

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

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

::- Ces différents tests nous ont permis de prendre connaissance puis de corriger de 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épassé. Au delà la direction est arrêtée. Ces seuils ont été fixé à 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 un 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.

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

2013-02-21T10:10:59Z

Ielhasna :

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

== Janvier 2013 ==

* Acquisition et sauvegarde des valeurs de courant/tension/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é de port USB. On a câblé 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 pour la communication entre le PC et la Dspace et les différentes librairies fourni par le fabriquant pour l'acquisition.

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

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

::- Ces différents tests nous ont permis de prendre connaissance puis de corriger de 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épassé. Au delà la direction est arrêtée. Ces seuils ont été fixé à 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 un 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.

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

2012-11-24T18:26:58Z

Ielhasna :

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

2012-11-24T18:24:44Z

Ielhasna : /* Séance 24 septembre */

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

2012-11-24T18:22:32Z

Ielhasna : /* Séance 24 septembre */

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

2012-11-24T18:16:41Z

Ielhasna : /* Séance 24 septembre */

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

2012-11-24T18:14:42Z

Ielhasna : /* Séance 24 septembre */

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

2012-11-24T18:14:01Z

Ielhasna : /* Séance 24 septembre */

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

2012-11-23T17:05:08Z

Ielhasna : /* Séance 19 novembre */

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

2012-11-23T17:03:51Z

Ielhasna : /* Séance 19 novembre */

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

2012-11-23T16:48:26Z

Ielhasna : /* Séance 14 novembre */

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

2012-11-23T16:47:04Z

Ielhasna : /* Séance 12 novembre */

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

2012-11-23T16:45:56Z

Ielhasna : /* Séance 7 novembre */

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

2012-11-23T16:45:10Z

Ielhasna : /* Séance 5 novembre */

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

2012-11-23T16:44:13Z

Ielhasna : /* Séance 18 octobre */

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

2012-11-23T16:43:25Z

Ielhasna : /* Séance 17 octobre */