Asservissement-Positionnement
Historique du choix
de l'architecture
Où comment on en est arrivé à
une usine à gaz. (Attention document écrit en 2005,
3 ans après les faits ...)
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 ..).
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.
|