Site ELEC344/ELEC381

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

Catégories

Serpentina - Bugs, blocage et une petite vidéo

Aujourd’hui, on a travaillé pour essayer de corriger des erreurs qui causaient des blocages de quelques cartes de notre serpent. Comme on a un système distribué, c’était dur de le debugger, et en plus on n’arrivait pas toujours à réproduire ces blocages. On a pu corriger quelques erreurs mais qui nous amenaient à d’autres, et à la fin de cette après-midi, notre exécution se bloquait encore au moment de faire un virage. Demain je me lance là pour trouver la cause du problème.

Ah, on a aussi transformé en paramétrable la variable qui donne la vitesse du serpent, et on a changé quelques configurations de la sinusoïde pour avoir des mouvements plus constants.

Et pendant qu’on essaie de trouver les solutions pour nos problèmes, voici une petite démo de notre serpent.

Wheely deuxième vidéo

Voici une deuxième vidéo illustrant l’état d’avancement du robot wheely.
Il nous reste encore à améliorer en priorité l’asservissement en position et l’interface de pilotage du robot.

ILDA

Alors aujourd’hui j’ai repris mon programme Python pour l’améliorer (il était assez sale à certains endroits et notamment j’utilisais un bout de code en C ce qui m’empêchait de le faire évoluer). Je n’ai pas tout à fait fini mais ca devrait plus être trop long.

Ce qui va me permettre de gérer un alphabet bien plus complet ce que j’ai pu faire jusqu’à présent.

J’ai aussi regardé niveau Ethernet ce qu’on pouvait faire avec Etienne, mais sans grand résultat. Une fois que tout ca marchera bien, il ne restera plus grand chose à faire pour finir le programme Python (peut être pas très beau esthétiquement…)

PuLSE, j-6

Actuellement on a une page web qui offre la possibilité d’envoyer une playlist, et quelques modes de fonctionnement (diaporama, lecture en continu, éventuellement lecture aléatoire de fichiers sur la carte). On a un serveur http qui n’est pas encore compatible avec le protocole http, on préfère dans un premier temps mettre notre protocole basé sur des requêtes http (get, put, post, delete) et le rendre conforme au protocole http ensuite (notemment dans le cas des gestions d’erreurs, en s’appuyant sur le serveur de Microchip). En particulier, en définissant à la main les contenus des requêtes on est arrivé à avoir des requêtes plus concises que celles générées dans les formulaires de firefox). Actuellement le protocole lit la playlist envoyée. A cause d’un bug dans le chargement des fichiers on n’a pas pu faire de test avec le laser, mais on y était presque.

Un petit apreçu de la page web (elle est un peu à revoir au niveau du style maisce n’est pas la priorité pour le moment)

Nouvelle avancée : rotation des blocs

Voici une petite vidéo pour illustrer la possibilité de tourner tous les blocs sauf le maître :

Heliokter : premiers vols

Depuis le dernier post, nous essayons de customiser notre PID pour parvenir à un résultat en vol meilleur. Le gros problème, c’est que c’est dur de définir ‘meilleur’, l’hélicoptère bouge forcément un peu, c’est difficile de le laisser completement libre dans la salle mais dès qu’on le contraint, on modifie son comportement …

Vendredi et samedi, on a quand même réussi à caractriser un comportement oscillatoire de grande période et grande amplitude, vraisemblablement dû à l’intégrale du PID : Si le le mouvement a tendance à être sinusoïdal, l’intégrale est aussi sinusoïdale mais déphasée de π/2, ce qui entretient voire amplifie les oscillations.

Pour remédier à cela, Alexis nous a conseillé une méthode de remise à zéro de l’intégrale dès que l’erreur change de signe pour eviter ce phénomène. Nous avions essayé d’autres méthodes de remise à zéro de l’intégrale avant mais celle-ci semble bien marcher.

Nous avons donc pu avoir, hier soir, un vol qu’on peut considérer comme stable d’une quinzaine de secondes, visible là :

L’hélicoptère descend lentement, c’est normal, il n’y a pas encore d’asservissement en altitude et  nous avons préféré le faire descendre plutôt que de le faire monter !

Voilà, sinon comme vous pouvez l’entendre, on gagne haut la main le prix du projet le plus bruyant ! :p

Alors evidemment, ce n’est pas parfait, mais c’est vrai qu’on a du mal  à savoir si on peut mieux faire et comment, et comment le savoir !

Serpentina : début des bons mouvements

Jeudi :

La calibration des cartes (trouver le degré neutre de chaque servo de toutes les cartes) a été fini et le code a été changer pour prendre en compte le fait que les servos verticaux sont alternés toutes les deux cartes (degré positif -> la vertèbre monte, degré positif -> la vertèbre suivante descend).
À partir du moment qu’on a eu une interface pour contrôler individuellement les servos, Flavia et moi avons aussi corrigé la relation entre l’angle de mouvement et la largeur du pulse (avant le mouvement du serpent ne correspondait pas à ce qu’on voulait).
Cela corrigé, on a commencé à faire des tests de déplacement avec le serpent. Et, finalement il a bougé. Et après des corrections, on a pu le faire marcher en avant, en arrière et a le faire s’arrêter et retourner à une position de reset (tout droit et plat).
Le soir, j’ai commencé à vérifier les envois des messages pour faire le virage du serpent.
Ah, le bootloader arrive bien à flasher les dix cartes. On a eu un problème de temps qu’il mettait pour tout finir mais c’était notre carte du TP qui le retardait. Sans aucun affichage dans le LCD, il met à peu près une vingtaine de secondes pour flasher toutes les dix cartes en parallèle.

Vendredi :

L’après-midi, j’ai mis quelques heures pour trouver un problème dans notre bootloader. D’un coup, il ne marchait plus. C’était une configuration du can, mais comme rien par rapport à cette configuration n’avait été changé dans notre dépôt, c’était dur de le trouver. Le bizarre c’est qu’il marchait avant. Ensuite, j’ai continué à travailler sur les virages. J’ai vu que les messages envoyés étaient ce qu’on voulait, mais le robot ne marchait pas.

Samedi :

Ce matin, j’ai pensé à une autre solution pour le virage. Au lieu de le tourner en une position X fixé, la tête du serpent tourne quand elle reçoit le message TURN et ensuite elle envoie un message à la vertèbre suivante. Celle-ci attend quelques instants, tourne et envoie un message à la vertèbre suivante. Ça jusqu’à la dernière vertèbre. Après des corrections, on a réussi à faire des virages dans le deux sens (quand le serpent marche en avant et en arrière). Cependant, on a encore des erreurs : parfois, les cartes se bloquent. Je reviens à ça ensuite.

Glip: Affichage Mercredi 28 - Vendredi 30

Un résume du travail :

Mercredi:

Finalisation du code d’affichage. Changement de la manière comm on génère le PWM par software. Le Glitch avec l’ancienne routine d’affichage a disparu, par contre un nouveau Glitch dans la troisième ligne est apparu.

Création d’une librarie pour la construction des images et une autre pour la configuration des animation

Jeudi:

Correction du Glitch de la deuxième ligne de la matrice. Le problème, une variable qui n’était pas définie comme ‘static’ comme il fallait. Affichage d’une image fixe 100% fini

Début de la confection d’une barrière pour les modules. Après plusieurs heures de travail avec Alexis, le groupe a opté pour une solution qui incluait de la mousse. Finalement un commande a été envoyé à Farnell.

Vendredi :

Adaptation de la routine d’affichage d’une image en incluant une table de couleurs. Test dans une animation.

Lecture et compréhension de différents parties du code python de gif2glip.

Création d’un programme en C qui crée des fichiers include (DATA0, DATA1, …. ) à partir des données d’un fichier .glip pour la configuration des images à afficher dans chaque bloque.

Test dans les modules. L’image montré est similaire à celle qui est montré dans l’écran de l’ordinateur par gif2glip.

ILDA et Défilement

Alors aujourd’hui je me suis attaqué au défilement qui était en réalité plus compliqué que ce que je pensais.

J’ai continué en python en réutilisant quelques binaires écrit en c et tout marche bien ce soir. On fait des tests demain, maintenant que la vidéo marche!

Mais je suis confiant, j’ai pu testé avec gnuplot que ca donne.

La vidéo d'illustration ...

Voici la vidéo dont Julie a parlé :

EDIT : Les positions sont recalculées après déplacement !

EDIT2 : Avec une (petite) animation !