ELECINF344/381

Partie interactive du site pédagogique ELECINF344/ELECINF381 de Télécom ParisTech (occurrence 2011).

Catégories

[CASPER] Demo de vendredi et API RS232

Voici dans ce post un bilan de la démonstration de Vendredi, ainsi qu’un bref état des lieux des avancées d’aujourd’hui concernant la programmation série en C sous linux.

 

Démonstration de vendredi

Nous avons Vendredi fait état de nos dernières avancées.

Nous avons débuté la démonstration par la présentation du PCB que nous avions réalisé et qu’Alexis nous avait remis il y a peu. Alain a, comme il l’a montré dans un post précédent, réussi à piloter l’écran LCD et afficher une animation simple comportant des rectangles de couleur et du texte.
Reste maintenant à réaliser l’interface série entre la carte et un ordinateur, puis programmer la mémoire flash embarquée.

Nous avons poursuivi par la démonstration de Thomas qui a piloté par l’intermédiaire de la carte de TP STM32 l’un des servomoteurs que nous allons utiliser. Grâce à son programme, nous sommes capables de piloter ces moteurs en leur fournissant une consigne angulaire.
Reste désormais à piloter le prototype en installant trois servomoteurs dans sa base.

Nous avons ensuite effectué une démonstration logicielle qui rassemblait les « helloworlds » que nous avions réalisés avec les différentes bibliothèques. Nous avons ainsi pu piloter à la voix l’ordinateur, lui demander de faire l’apprentissage de deux visages, puis de passer en mode reconnaissance. Une fois en mode reconnaissance, le moteur de synthèse vocale interfacé pour le moment avec pulseaudio a salué les visages connus en les nommant par leurs prénoms.

 

Comme Thomas l’a signalé dans son billet, nous avons pour le moment mis de côté le développement de drivers, pour nous concentrer essentiellement sur la mécanique, la programmation du PCB, et le port de nos applications sur la beagleboard.

Afin de préciser notre démarche, nous publierons bientôt sur ce site une liste actualisée de nos PSCC et des responsables associés.

 

Avancées de la journée : API RS232

De mon côté, je me suis penché sur la programmation du port série en C sous linux. J’ai trouvé à ce sujet une excellente source de documentation, qui m’a permis de comprendre rapidement l’interface posix permettant d’en effectuer la configuration. Vous retrouverez ce guide ici.

J’ai créé une interface de plus haut niveau permettant de lire et d’écrire sur un nombre indéfini de ports série, et de rentre transparente la gestion des lectures et écritures avec tampon.

Il suffit en effet pour utiliser un port série d’en demander l’ouverture en précisant le fichier /dev/tty* associé, et de donner en argument la fonction que l’on souhaite être appelée pour traiter les données.

L’API se charge ensuite d’appeler cette fonction lorsque de nouvelles données sont disponibles, ainsi que d’écrire les données stockées dans des tampons chainés lorsque le matériel est prêt.

L’utilisateur peut donc utiliser des fonctions non bloquantes pour écrire, et utiliser ses propres fonctions pour lire.

Pour finir, bien que cela ne soit pas encore implémenté, il est possible d’ajouter à cette API les sockets en plus des ports série. Cela permettrait de gérer par le biais d’une interface unique toutes les transmissions de la beagleboard, que ce soit par réseau ou avec le PCB.

[CASPER] Avancées du projet côté mécanique…

Du côté de la mécanique, nous avons mis en pause le développement des drivers linux qui doivent à terme contrôler les moteurs. En effet, nous avons jugé que commander les moteurs au plus tôt et avec précision était plus prioritaire. Nous nous sommes donc penchés sur le contrôle des servos par PWM en utilisant la carte de TP STM32.

Jusque ici nous avons écrit un programme qui prend en charge les trois servos, qui est capable de prendre en entrée un angle comprit entre 0 et 180° et d’amener un servo à cette position. La prochaine étape est d’implémenter le modèle mécanique que nous avons conçu afin de donner au programme la direction de casper (sur 360°) et son inclinaison (sur 90°). Le programme interprétera ces données en terme de commandes moteurs.

RoseWheel : Test bench & Kalman

Aujourd’hui nous avons continué l’amélioration de notre test bench d’un coté et recommencé la modélisation physique de l’autre.

 

Le document de Rich Chi Ooi a été complètement abandonné, il y aurait apparemment des erreurs de calcul (au moins intermédiaire) et son implémentation complexe n’était vraiment pas pratique.

Les équations de BoRam seraient de loin bien plus simple à implémenter et les résultats sont beaucoup plus satisfaisants.

Il reste néanmoins un facteur 4 dans le sens où on obtient des commandes en tension au dessous de 100V au lieu de 24V (alors qu’on avait une erreur de l’ordre de 10 000V avec Rich Chi Ooi).

 

Les améliorations sur le test bench sont moins conséquentes puisqu’il ne s’agissait que d’optimisations.

Tout d’abord avons rendu le test asynchrone de façon à pouvoir changer d’inclinaison cible en cours de route sans avoir à attendre la fin de l’exécution d’une commande (ce qui peut être long si la vitesse demandée est faible). Pour ce faire, nous utilisons des queues que nous remplissons d’objets composés de commandes angulaire et de leur délai associé pour aller à la vitesse demandée.

Enfin, nous avons doublé la précision de calibration de la commande du moteur en mesurant de nombreuses fois chaque PWM associé à un angle et ce tous les 10°.

A l’origine, nous utilisions un tableau de valeurs à interpoler pour calculer les PWM à mettre dans le registre TIM1->CCR3 :

const static uint16_t PWM_list[] =
{
59840, 60130, 60400, 60700, 61010, 61310 // -60° -> -10
61580, // 0°
61900, 62190, 62500, 62780, 63050, 63430, // +10° -> +60°
};

Cette mesure expérimentale présentait une irrégularité non négligeable mais en considérant la linéarité du moteur nous avons fait une régression linéaire pour diminuer l’imprécision.

Voici l’approximation graphique obtenue avec open office (courbe de tendance) :

 

On peut voir en haut à gauche de l’image la fonction à utiliser dans notre code C.

Et pour finir, pour interpréter les données obtenues par l’ADC de façon à connaitre plus précisément notre inclinaison nous avions un tableau similaire :

const static uint16_t ADC_list[] =
{
663, 845, 1018, 1169, 1324, 1485, // -60° -> -10
1644, // 0°
1764, 1975, 2127, 2284, 2455, 2611, // +10° -> +60°
};

…et voici l’approximation graphique ainsi que la fonction linéaire associée que nous en avons extrait :

 

On peut voir que R², le coefficient de détermination, est très proche de 1 dans les 2 cas, donc notre linéarisation peut être considérée comme fiable.