Asservissement-Positionnement

Historique du choix de l'architecture


Introduction

Où comment on en est arrivé à une usine à gaz. (Attention document écrit en 2005, 3 ans après les faits ...)

Documentations

1 - Les objectifs

En arrivant au club en 2002 (en fait juin 2001), le premier objectif de l'asservissement était d'avoir un asservissement fiable et précis ... parce que ça semblait crucial. Plus pragmatiquement, se déplacer sur le terrain en donnant juste quelques temps pour chaques moteurs mis au pifomètre dépendant de la tension de la batterie, des frottements, etc n'était pas acceptable.

Il est à noter qu'à ce moment personne n'avait vraiment la notion de ce qu'était réellement un asservissement de robot. Les seuls asservissements connus étaient ceux de petits moteurs avec des codeurs de qques points par tours (disque percé de trous ..).

2 - Acte I : Le LM629

Donc ne connaissant pas les contraintes l'idée de prendre un composant déjà existant capable de faire ça (le coup de la boite noire en informatique ..) semble intéressante. Le composant il en existe au club, c'est le LM629. Ce composant au aussi eu la réputation d'être compliqué à faire marcher, sur les 2 précédentes années. (mais avait été mis en oeuvre encore avant avec succes). Après impression de la datasheet de la chose (ridiculement petite ...), il semble que la chose ne soit pas si complexe ... (là c'était fin juin 2001). Fin de l'Acte I.
A noter : pendant ce temps j'avais récupéré un sample de DSP TI C33 pour mon usage perso, chose que j'ai soudé et commencé à faire marcher durant le début de l'été 2001, mais celà se limita à alimenter le biniou, y mettre un quartz et envoyer 16 octets de code dedans visant à faire bagotter une des 2 pin d'E/S directe du truc - ce qui a marché.

3 - Acte II : Le LM629, la pratique

Septembre 2001, rentrée du club. Après le rangement d'autonome, et avant la constitution réelle du bureau, le robot de 2001 est démonté pour en récupérer la base mécanique (base + 2 roues + 2 codeurs).

Pendant le même temps, Coco avait fait des essais sur le positionnement en uilisant des souris et est ensuite venu contribuer à l'atelier de production de gaz dès le début.

Tout commence par une carte veroboard avec un LM629 branché sur le port // d'un PC pour commencer à discuter, puis de la puissance(LMD18200), puis un 2ème LM, puis embarquement du tout sur la base mécanique précédente.

On y ajoute une petite carte véroboard avec :

  • 2 LMD18200 - repéré l'année précédente en sample
  • 2 LM629 reliés aux LMD
  • Les LM629 sont directement reliés au port //

Il peut être noté que c'est à ce moment précis que ça a commencé à tourner en usine à gaz. En fait un petit bout de soft sur PC avait été fait avec ce que je savais mettre en oeuvre très rapidement, du code en C, Win32. Pourquoi commencer sur PC ? Pour avoir un débug et une visu la plus simple et la plus complète possible. Pouvoir voir en permanence ce que retournent les LM, etc ... ce qui vu les difficultés annoncés s'avérait indispensable pour assurer le succès de l'opération. Et après coup c'était bien indispensable ..

En fait une fois mis en marche fonctionnellement les LM629 (réussir à faire une trajectoire), là on a vu la nécessité d'avoir une visu plus complète avec la position représentée sur un terrain (fait par Coco), puis on a commencé à explorer toutes les subitilités des LM et je le rapelle de l'asservissement en particulier. Notamment les concepts de base :

    • Existance d'une position réelle (physique) sur le terrain
    • Existance d'une position mesurée (retournée par les codeurs + calculs)
    • Existance d'une position de consigne déterminée par la trajectoire générée

Et ces 3 positions ne sont absolument pas confondues, il y a forcément une erreur entre chaque, erreur qu'il faut minimiser. D'ailleurs celà est apparu assez tôt qu'en fait d'asservissement, il y avait 2 choses à faire :

  • Un POSITIONNEMENT sur le terrain (savoir où on est)
  • Un ASSERVISSEMENT (aller où on veut)

Le LM629 + les roues codeuses + un peu de soft permettent de faire le positionnement (savoir où on est). Le LM629 + la partie puissance + un peu de soft permettent de faire l'asservissement (aller où on veut).

Il apparait à ce moment aussi qu'il est clair qu'en ayant un mauvais positionnement, on ira pas là où on veut réellement. Avoir un bon positionnement est crucial.Et on ne peut pas ruser en soft pour améliorer ça, sans avoir d'autres sources d'infos (pour la suite : idée du recalage sur les lignes)

Après même si l'asservissement n'est pas terrible, c'est à dire qu'on ne va pas réellement là où on veut, mais que l'on sait où l'on est, ça on pouvait imaginer de bricoler du soft pour améliorer le chantier. (serrer les PID en pratique suffit déjà pas mal).

4 - Acte III : Embarquons, embarquons ...

Ayant avancé dans la connaissance de ce qu'on voulait faire, il devenait de plus en plus urgent de se trouver une architecture embarquée ... En fait cette démarche a eu lieu en même temps. Pour resituer on doit être en octobre/novembre.
Là, on assiste à des combats de chapelle (comme d'habitude), d'ailleurs, raison de l'écriture de ce document 3 ans plus tard ...
A titre perso, je penche à ce moment pour une architecture embarquée du type gros µC, si possible rapide et capable de faire des multiplications en cablé (histoire de pas être trop limité). A ce moment (fin 2001), le choix n'est pas encore très vaste. A ce moment, je souhaite éviter autant que possible une architecture "processeur" complète (RAM, Flash, etc) comme c'est déjà le cas avec la carte principale ...
Les autres idées évoquées sont :
  • les PICs (on a des 16F877 sous la main) utilisé pour les mini proj, avec création d'un flasheur "embarqué", adapté aux contraintes du robot (les 2 erreurs de conceptions de ce truc sont de ne pas avoir imposé de contraintes mécaniques et de ne pas avoir prévu les ports // 3.3V des portables - autrement dit pas respecté les specs de tension min d'un port //)
  • les AT Mega (AVR) d'Atmel. Malgré les déboires de l'année précédente avec les Atmel ces bestioles semblent intéressantes pour faire de l'asser.
  • Quelque chose de la famille 68xxx ou un 68332 comme la carte principale .. bref, de base à ce moment on évitait.
  • Une carte DSP C31, il y a des cartes d'éval à l'ESEO utilisée pour les TP de traitement du signal, mais mise au rebus par l'arrivées des flamboyantes SMT

D'où :

  • On fait donc des essais sur les PICs. Résultat : il existe quelques routines de calculs dans le compilo des PICs (le fameux fumant CCS dont l'éditeur à l'époque plante lors d'un copier/coller sur 2 ..). Mais les temps d'executions sont prohibitifs, de plus certaines opérations en 32 bits prennent moins de temps qu'en 8 bits, ce qui semble hautement louche.
  • Les AT Mega. Oui, il ne sont pas encore sorti, et il faut demander des samples ... samples que l'on a attendu un moment tout ça pour avoir une réponse négative.
  • Dons il ne reste pas grand chose. Le 68332 parait pas forcément très intéressant pour l'asser et tant qu'à faire de prendre quelquechose d'usine à gaz autant prendre quelquechose de plus souple. En plus les essais réalisés l'été précédent sur le C33 avait permis d'engranger pas mal d'infos et de connaissance sur le fonctionnement des DSP C3x, a vrai dire largement plus que les 3 cours sur le 332 .. d'où ... Le fait que le C31 soit sur une carte d'éval directement opérationnelle appportait aussi un plus. On branchait et c'était directement opérationnel.Le C31 avait un peu de RAM interne, ce qui a première vue pouvait suffir (donc pas de RAM externe, juste eventuellement une flash) [grosse erreur]

Donc après avoir été chercher cette carte (dans la caverne d'Ali Baba de l'ESEO), on commence dans le grand froid du club courant décembre à mettre le truc en marche ... On a à ce moment :

  • La carte d'éval qui a le DSP, son alim, un PAL qui décode qques adresses, un peu de tripaille pour faire le chargement du code, le debug, etc depuis le port // d'un PC
  • Une disquette zip avec dessus, les outils de l'ESEO pour le C31, les TP fait à l'eseo, etc + le contenu des softs fourni avec le kits de dév (un debuggeur - sous DOS) permettant de charger le code dans le DSP + qques sources fournies avec le kit d'éval..
  • Les TP de l'ESEO sont fait moyennant un bricolage de batchs sous dos appelant les outils de compilation et imbriqués + ou - avec un bout de code issu du kit de dev permettant de faire le chargement du code (le tout sous DOS).

5 - Acte IV : Le ver était dans le fruit ...

A partir de ce point, tout reste à faire. Garder cet utilitaire DOS était non envisageable par rapport à ce qu'on avait. Donc il y a déjà eu un premier port des sources permettant d'envoyer le code dans la cible et de venir lire et écrire dans la mémoire de la cible.

Ensuite il y a eu une carte veroboard pour tester tout ce qu'il fallait mettre en extension. Au début, les extension prévues étaient : les LM629, la tripaille pour rentrer des capteurs en IT (moustaches pour detecter les paniers) et une interface avec le PIC pour l'I²C (autre choix non judicieux).

Cette carte veroboard était assez 'touffue', et a quand même permis de développer une première version ayant toutes les bases soft de la carte finale, tout ça pour se rendre compte que la mémoire interne du DSP ne suffisait (en plus du fait qu'il n'y avait pas de flash !). Le code DSP C3x prend relativement de place, même s'il reste assez efficace. L'utilisation de capteur de panier (moustaches) en IT est aussi discutable. Ce genre de fonctionnement intégralement en IT est fondamentalement asynchrone et ne permet pas vraiment de faire du temps réel dur à 100%, du moins c'est nettement moins facilement vérifiable. Ce qui n'arrangea pas les lourdeurs du soft embarqué. Par contre, c'est l'architecture qui permet d'avoir les meilleurs temps de latence ...

Donc sur les schemas de la carte définitive, s'est rajouté de la RAM (en pagaille, mais c'est surtout la quantité de RAM qui coutait le moins cher, en mettre moins coutait plus cher !) et de la flash. Voilà, tout était dit, la carte était devenue une usine à gaz.

Une erreur dans le documentation faisant la spécif des connecteurs de la carte d'éval a en plus ajouté une inversion de 2 connecteurs, ce qui a rajouté à la non fiabilité de la carte ...

6 - Acte V : La production de gaz ...

La suite, c'est tout ce qu'il a fallu développer pour tester la RAM, écrire dans la flash (et le tout toujours rajouté dans l'usine à gaz). Et là l'usine à gaz s'est deployée.

Mais par contre cette architecture, autant sur le point de vue quantité de RAM, que communication souple et + ou - sans limite avec le PC a permis de rapatrier nombre de courbes de vitesse, positions, info de débug structurées diverses et variées pour le recalage sur les lignes, et comprendre beaucoup de choses.

Par la suite s'est ajouté toute la gestion des balises qui a achevé l'aspect usine à gaz des choses !

Mais tout était fait maison là dedans, et rien n'était réellement bullet-proof, c'est à dire qu'il fallait nécessairement connaitre ou se pencher sur tous les aspects du système.
Rendre le système bullet proof aurait nécessité de sabrer une certaine quantité du temps de développement, ce qui est tout de même peu envisageable pendant la coupe ... et n'aurait été possible qu'après.

En conclusion, l'architecture était intéressante de par ses possibilité, mais elle serait d'autant meilleures si l'ensemble des outils étaient bullet-proof, c'est à dire déjà existant avec une carte d'éval.