Site ELEC344/ELEC381

Partie interactive du site pédagogique ELEC344/ELEC381 de Télécom ParisTech (occurrence 2010).

Catégories

Et quand ça n'avance pas...

Après avoir laissé vendredi soir Wheely tout juste monté, nous avons pu partir contents de nous pour un week-end bien mérité.

En rentrant, j’ai fait quelques tests sur le LQR pour remarqué quelques problémes bètes, en particulier un problème de saturation qui faisait repartir le robot dans le mauvais sens quand il était trop penché… Après quelques heures de tests, nous avons décidé de commencer par essayer de faire rouler Wheely grâce à un PID sur l’angle, sans l’asservir du tout en position, puisque cela ne faisait que compliquer la recherche pour le moment.

Lundi, nous avons donc refait toue une série de tests tous ensemble (puisque les avions ne volent plus…) sur le PID et Fabien a rajouté un étage au robot pour monter encore le centre de gravité.

Mardi, je me suis penchée sur le problème de la mise en flash du code. Daniel y travaillait déjà sans succés, donc on s’est dit qu’un autre essai ne ferait pas de mal. Après de longues recherches et un certain désespoir, j’ai fini par découvrir que notre problème venait d’une mauvaise initialisation de la flash, que nous faisions trop tard (ie après que l’horloge soit réglée sur la PLL et non avant). Sam a aussi remarqué un warning du compilateur qui nous a poussé à faire une petite modification dans le ld script.

Ce matin, j’ai donc modifié le hardware_init et le ld script pour toutes les cartes, ainsi tous nos codes seront harmonisés, en vérifiant bien que ce code fonctionnait aussi bien en flash qu’en ram, et que toutes les tâches fonctionnent toujours correctement (vu les problèmes rencontrés par les autres gruopes, je m’attendais à tout!). J’ai fait tous les tests qu’il me semblait possible de faire sur la carte propulsion et je n’ai rencontré aucun problème majeur.

Ne reste plus qu’à faire rouler Wheely maintenant…

Wheely - le robot en déséquilibre !

Aujourd’hui, nous avons réussi à corriger le problème lié au filtre complémentaire (cf. post d’Arnaud) et commencer les tout premiers tests de l’asservissement LQR.
En voici une première vidéo (merci Florent pour la caméra !). Nous mettrons à jour des vidéos plus intéressantes la semaine prochaine (au fur et à mesure que nos tests seront plus satisfaisants), puisque le robot est désormais monté (merci Fabien !).
Je vais m’occuper de la mise en en flash du programme (pour l’instant nous ne flashons qu’en RAM) ce weekend puisque mon avion pour l’Irlande a été annulé :(

Propulsion

Depuis le début de la semaine j’ai travaillé sur la propulsion, le LQR et le filtre complémentaire.

Concernant l’avancement du filtre complémentaire : voir l’article d’Arnaud.

Pour la propulsion : J’ai asservi les roues en lacet. C’était d’autant plus nécessaire que la réponse de chaque moteur à un même PWM était nettement différente et risquait de compromettre les tests en lignes droite même sur de petites distance. J’ai également fait quelques tests de mesure de vitesse avec le protocole suggéré dans l’insider guide mais les résultats ne sont pas satisfaisant : soit le temps entre deux mesures de vitesse est trop long, soit la précision est insuffisante.

Sur le LQR, J’ai modifié mes valeurs en fonction de ce qu’on a déjà fait. L’adaptation entre l’échelle des capteurs et les entrées du LQR ne devrait pas posé de problème mais la correspondance entre la valeur de sortie du LQR et la commande des moteurs n’est pas aussi évidente.

Wheely – filtre complémentaire

Depuis quelques jours, nous travaillons sur les données du gyroscope et de l’accéléromètre que l’on filtre (respectivement en passe haut et passe bas) afin d’utiliser la technique du filtre complémentaire. Pour l’instant, (après pas mal de tests) le temps de stabilisation du filtre se situe aux alentours de 20 secondes (ce qui est un peu long quand même !). De plus, la moyenne des signaux filtrés n’est pas centrée en 0 (ce qui est embêtant pour l’utilisation du LQR par la suite…).

Réseau Wheely

Hier, j’ai passé trois heures à essayer en vain de recevoir des informations par UART en les entrant dans minicom pour m’apercevoir que le câble qui connecte la carte à l’odrinateur était en train de se désouder.

J’ai aussi fait un programme permettant de commander la vitesse des roues en l’écrivant dans minicom, puis en passant par la carte logique par UART et enfin à la carte de puissance par CAN.

J’ai ensuite adapté le code de commande des servos-moteurs fait par le club robotique (merci!) pour pouvoir faire des tests d’angle et de vitesse avec notre carte logique. Ce code fonctionne bien, donc nous allons pouvoir commencer les tests.

J’ai commencé à relire ce que nous avions décidé pour le LQR et les fichiers Matlab. Nous devons nous synchroniser avec Fabien pour avoir un code bien cohérent entre ce qui sera fait sur la carte logique et ce qui sera fait sur la carte propulsion.

Ce matin, j’ai ajouté le code de l’UART au code de la carte propulsion et j’en ai profité pour harmoniser tout le code avec le code de la carte logique.

Communication et harmonie...

Hier, j’ai harmonisé le code qui avait été codé par chacun d’entre nous et donc avec différentes conventions… ça a ainsi permis au groupe d’arriver à un concensus sur la structure du code.

Aujourd’hui, j’ai enfin réussi à faire marcher la communication par l’UART1, et j’ai donc pu afficher les données filtrés de l’accéléromêtre et du gyroscope, ayant ainsi la confirmation que le code global fonctionne bien.

Ensuite, j’ai fait une fonction qui teste l’identifiant de la carte, pour qu’on ne puisse pas faire fonctionner le code prévu pour la carte logique sur une carte IMU et inversement. Cette fonction focntionne bien.

A l’arrivée de Daniel, nous avons pu tester mon code sur une carte IMU, nous avons bien réussi à allumer les LEDs simplement en changeant le #define dans le fichier de configuration global.

Nous avons eu pas mal de problèmes avec le bluetooth qui ne fonctionnait même plus avec la carte IMU. Nous avons finalement réussi à le faire fonctionner sur la carte logique! Il nous a semblé que les coordonnées que l’on additionne n’étaient plus les bonnes (on additionne le x de l’accéléromêtre avec le y du gyroscope). Daniel fera plus de tests et corrigera les calculs demain.

Et moi, je vais pouvoir me lancer dans le codage du LQR!

Matlab : le retour de la vengeance 2.

Avancées en ce début de vacance :

-Lecture de datasheet de pont en H avec Kellya. (et pas mal de problème pour faire des correspondances entre deux datasheet).

Poursuite de la modélisation matlab. Ah LQR j’ai ajouté les filtres complémentaires.

Sur les conseils d’Alexis nous avons décidé d’abandonné Kalman au profit des filtres complémentaires.Cela consiste à faire un passe-bas sur l’accéléromètre et un passe haut sur le gyro, avec deux filtre dont le gain de la somme vaut 1 à toute les fréquence.

J’ai modélisé les mesures de l’accéléromètre par la mesure de l’angle prédit par mon modèle + pas mal de bruit + un offset (aléatoire sur chaque tirage)et la mesure du gyro + par la vitesse angulaire prédite par le modèle + du bruit blanc+ un offset puis j’intégre la mesure. (D’où un bruit en forme de marche aléatoire + une dérive).

Résultats :

Points positifs :

  • même en surdosant clairement les bruits par rapport aux valeurs données dans les datasheets, les résultats sont vraiment bons et les réglages faciles.
  • Facile à implémenter en C (suites récursives d’ordre 2)

Fait également : tests rapides pour voir l’influence des différents paramètres mécaniques sur l’efficacité de l’asservissement. A priori ce n’est pas crucial cependant il va falloir trouver comment les déterminer le plus précissement possible une fois qu’on aura le robot au complet. (@ Alexis : n’hésite pas à me prévenir si tu recois les moteurs pendant les vacances, je reste à Paris…).

à avancer : carte de puissance.

à éluder : en simulation le robot se stabilise en x autour d’une position proportionnel à la dérive du gyroscope. à priori pas génant (de l’ordre de 10cm) mais je n’arrive pas à savoir pourquoi…

Premier remplissage du site de Wheely

Avec Fabien, nous avons décidé ce soir de commencer à remplir le wiki présentant notre robot.

J’ai complété la page de présentation du projet sur la première page et mis notre planning pendant que Fabien s’est chargé de présenter le LQR et la simulation adaptée aux caractéristiques de notre futur robot.

Wheely : modélisation matlab

Simulation du modèle physique du robot en équilibre sur matlab.

L’asservissement LQR marche bien et se paramètre bien.

En attente de résultat de l’équipe Kalman pour modéliser plus fidèlement le bruit des capteurs et implémenter Kalman sur le modèle.

En attente du robot pour corriger les paramètres mécaniques. (Croulebois prévenu ? Commande des moteurs ? )

Exemple de résultat : freinage à partir d’une vitesse initiale de 1m/s avec un bruit blanc de 5% sur les mesures de vitesse angulaire et de position au sol. Et un bruit blanc de +/-0.1V sur la commande de chaque moteur. la postion est en [m] et les angles en radian. Le temps de calcul entre commandes sur le moteur est fixé à 50ms.

à venir : choix des composants et PCB de la carte propulsion.

Wheely : asservissement et méca

- Etablissement des équations différentielles qui décrivent la mécanique du robot

- Recherche du principe du LQR.

- Détermination de la matrice qui prend en entrée l’angle des roues et du corps du robot et qui rend la tension à appliquer au moteur en fonctions de tous les paramètres du moteur.

Problème : les infos sur les moteurs et les roues sont insuffisants pour faire les choses précisemment ( on recevra peut-être la datasheet avec les moteurs, avec un peu de chance).

- Choix du l’accéléromètre (LIS3LV02DQ) à faire valider.

- Méca : plans terminés à communiquer à Alain Croulebois.

à venir ce soir : simulation matlab avec en entrée des mesures bruitées et en sortie l’angle du robot en fonction du temps (donc avec Kalman + asservissement) pour tester l’influence des différents paramètres.