Plan de développement du projet N°50

3.L’informatique

Le problème principal auquel nous avons été confronté au début du projet a été d’une part de définir la stratégie globale de notre robot, mais également de savoir comment l’implémenter et quel matériel informatique utiliser. La piste qui s’est le plus rapidement imposée était de reprendre en grande partie le travail réalisé les années précédentes, développé autour de deux ATmega128. Il existait pour cela une documentation laissée par les élèves de l’année précédente, mais celle-ci était relativement incomplète. Nous avons décidé de partir sur les bases données par celle-ci, et de produire une documentation aussi complète que possible, pour que les prochains élèves travaillant sur le projet puissent partir sur des bases solides le plus rapidement possible.

Afin de maximiser les performances de la partie logicielle, nous avons utilisé un seul microcontrôleur, puisque le nombre de pattes sur un ATmega128 était suffisant pour le connecter au reste du robot (contrairement à l’année passée où un ATmega128 était dédié au déplacement – relié aux HCTL – et un autre était dédié à la stratégie, les deux étant reliés entre eux par une connexion série directe). Après ces considérations techniques, nous avons dû définir l’architecture logicielle. Dans un souci d’évolutivité (faciliter la maintenance future du logiciel), nous avons découpé le programme en plusieurs parties. Cette architecture est pensée de manière à ce que nos successeurs n’aient pas à « réinventer la roue », c'est-à-dire n’aient pas à réécrire les instructions de bas niveau, par exemple pour le déplacement du robot, mais puissent rapidement se concentrer sur la conception d’une stratégie.

3.1.Présentation du logiciel

Comme vous pouvez le voir dans le schéma ci-dessous, le logiciel (le code) est divisé en plusieurs fichiers. Cette structuration facilite la compréhension et, dans le même temps, délimite clairement les parties du code qui dépendent du microcontrôleur choisi pour contrôler les HCTL et ceux qui n’en dépendent pas.


Fig. 6 - Schéma de présentation du logiciel

On présentera succinctement chaque partie, en soulignant quelles sont celles qui dépendent du microcontrôleur.

Pour plus de renseignements, consulter directement les fichiers indiqués (sur BSCW), car ils contiennent un commentaire détaillé.

3.1.1.Fonctions utiles (fonctions_utiles.h)

Ces petites directives permettent de faciliter la manipulation des données pour chaque patte de l’ATmega128. En effet le microcontrôleur comporte six ports avec huit pattes, et un autre avec cinq. Il permet en outre de contrôler chaque patte indépendamment les unes des autres, et pour cela nous avons besoin de faire des contrôles ou des manipulations sur un seul bit de l’octet relatif au port (contrôler une seule patte à la fois) : ces fonctions sont là pour cela et elles sont utilisées dans toutes les autres fonctions.

3.1.2.HCTL (cst_hctl.h, hctl.c, hctl.h)

• 
  cst_hctl.h
  

Ce fichier contient les constantes utilisées pour travailler avec les HCTL. En fait, ces constantes sont les adresses des registres les plus importants.

• 
  hctlc.c
  

Toutes les fonctions communiquant avec les HCTL sont définies dans ce fichier. Voici un descriptif des principales fonctions :

Reset : permet de mettre les HCTL dans un état connu (par exemple pour l’initialisation en début de programme, etc.)

Synchronisation : permet de synchroniser l’exécution du code de déplacement entre les deux HCTL.

Lecture, écriture : permet de lire ou d’écrire dans les registres des HCTL afin de se déplacer ou de savoir combien de chemins il reste à parcourir. L’implémentation théorique de ces fonctions est d’une complexité normale, néanmoins son utilisation pratique est rendue relativement difficile compte tenu du comportement de l’ATmega128. En effet il convient d’utiliser des instructions de bourrage de manière à temporiser correctement l’exécution des instructions (ce qui a posé de grandes difficultés cette année compte tenu du changement de compilateur, les instructions de bourrage utilisées l’année précédente n’étaient plus compilées de la même manière étant donné que ce n’était pas des NOP, ce qui a nécessité un nouvel étalonnage empirique de ces fonctions). Il existe six fonctions de ce type : deux pour la lecture et l’écriture simultanée sur les deux HCTL, et quatre pour la lecture et l’écriture sur chaque HCTL séparément. Même si l’ordre logique des instructions est bon, seule la fonction qui écrit dans les deux HCTL marche (hdctls_send_different(…)¹). Pour les autres, les temporisations n’ont pas encore été déterminées².

Ces fonctions ne doivent pas être interrompues, sauf si l’interruption est particulièrement courte. La communication avec les HCTL est très sensible aux temporisations et vous risquez de planter le système si vous ne respectez pas cette règle.

Il est bien évident que les fonctions d’ici sont très sensibles au changement du microcontrôleur de déplacement et qu’il faut ajouter des temporisations pour que ces fonctions soient bonnes.

• 
  hctl.h
  

Dans ce fichier vous allez trouver de nombreuses macros pour vous faciliter le travail avec les HCTL. Attention : beaucoup de ces macros n’ont jamais été testées mais, normalement, elles doivent marcher parce que les indications du datasheet ont été totalement respectées. Néanmoins, si vous utilisez une macro pour la première fois vous pouvez la re-vérifier.

3.1.3.Déplacement (cst_deplacem.h, deplacem.c, deplacem.h)

• 
  cst_deplacem.h
  

CE fichier contient beaucoup de constantes. Premièrement on a les paramètres pour effectuer correctement les mouvements. On va vous présenter quelques paramètres.

Commençons avec signe_gauche et signe_droit. Ces constantes peuvent avoir soit la valeur 1 soit la valeur –1 et vous pouvez contrôler avec eux le sens de rotation de chaque moteur.

Puis on a vitesse_gauche, vitesse_droite, acceleration_gauche et acceleration_droit. Regardez les commentaires de ce fichier pour vous faire une idée de leur signification. Au début, il est très important d’initialiser ces paramètres avec une valeur relativement petite pour pouvoir faire la différence entre le cas où le moteur tourne à fond et le cas où le moteur est asservi. On vous propose la résolution d’encodeur divisé par 10.

Puis, on a les définitions des pattes utilisées dans la communication avec les HCTL. Bien évidement, ce fichier est fortement lié à l’architecture physique utilisée.

• 
  deplacem.c et deplacem.h
  

Cette partie est composée des fonctions qui commandent les déplacements ainsi que celles qui interagissent directement avec les HCTL (cf. § précédent). Parmi ces fonctions, les principales permettent d’avancer, de reculer, tourner à droite ou à gauche sur soi-même (une roue avance, l’autre recule), tourner à droite ou à gauche autour d’une roue (une roue reste fixe, l’autre bouge).

Ces fonctions ne doivent pas être interrompues, sauf si l’interruption est particulièrement courte. La communication avec les HCTL est très sensible aux temporisations et vous risquez de planter le système si vous ne respectez pas cette règle.

Ces fonctions, théoriquement, ne dépendent pas de l’architecture choisie.

Le principal a été codé. Aux nouveaux d’apprécier s’il y a besoin de coder de nouvelles fonctions.

3.1.4.USART (usart.c, usart.h)

C’est l’interface logicielle du microcontrôleur qui permet de communiquer avec l’extérieur, que ce soit avec un autre microcontrôleur (ce qui sera certainement le cas l’année prochaine), ou encore pour communiquer avec l’extérieur : un PC ou autre, afin d’obtenir des informations sur le microcontrôleur en temps réel. L’ATmega128 comporte deux unités de communication série indépendantes ce qui permet de réaliser ces deux tâches simultanément (par exemple, on peut envisager de contrôler deux microcontrôleurs avec un pc qui serait connecté à l’un des deux – un microcontrôleur serait donc contrôlé directement, et l’autre le serait par l’intermédiaire du premier).

Cette partie a été entièrement faite cette année (2003 - 2004). Il y a encore beaucoup de choses à faire ici, la plus importante étant l’implémentation d’un contrôle de flux dans les deux sens (bufferisation, handshake, etc.). Pour l’instant, le seul contrôle de flux qui existe est le délai qui existe entre chaque émission, et au niveau de la réception, un système hybride faisant appel aux interruptions et au polling. Ce système n’est fiable que dans certaines situations (cette approche suppose que le récepteur peut toujours accepter les données envoyés – ce qui n’est pas toujours le cas). Les paramètres de la liaison série utilisée cette année sont : 2400 bits/s, 8 bits de données, parité paire.

3.2.Problèmes rencontrés

3.2.1.Problèmes de compilateur

Cette année nous avons pris la décision de changer le compilateur pour des raisons financières. La licence pour l’ancien compilateur (ImageCraft) coûtant 500 euros, WinAvr, qui a le gros avantage d’être gratuit, a été choisi. Malheureusement, le nouveau code objet ne respecte pas les temporisations réglées avec le premier compilateur. N’ayant pas eu le temps de refaire ces réglages, nous avons décidé, deux semaines avant la compétition, de réutiliser ImageCraft même si cela signifiait la réinstallation du système d’exploitation (pour pouvoir réutiliser la version d’essai).

3.2.2.Problèmes de matériel

Un grand défi était de trouver une méthode pour communiquer avec le robot et de lui donner des commandes sans être obligés de recharger à chaque fois le logiciel. Pour développer cette méthode, plus de 30 heures de travail ont été nécessaires mais son utilité est incontestable.

Un autre problème était de déterminer si un microcontrôleur fonctionnait ou non. Ceci peut s’avérer être une tâche impossible. Pourtant, cette tâche peut être accomplie, partiellement, avec l’aide de certains logiciels que nous avons développés. Ainsi, nous sommes maintenant capables de vérifier la contrôlabilité de chaque sortie et le fonctionnement d’interruptions externes et d’unité USART. Cela s’est prouvé extrêmement utile lorsque l’Atmega a subi une surchauffe. Les quatre pattes qui n’étaient plus contrôlables ont facilement pu être identifiées.

Un dernier conseil : ne faites confiance à aucun compilateur ! Il est toujours utile de vérifier si le code objet est bien fait (surtout pour les parties sensibles). Pour cela, utilisez AVR Studio. Vous allez découvrir des choses incroyables .

3.3.Propositions

La plupart des améliorations possibles au niveau du logiciel sont décrites dans une version largement approfondie de cette présentation « Le système de déplacement développé par le Club de Robotique de l’ENST Bretagne ». Ce document est disponible sur le BSCW.