Équipe du micro-contrôleur 6811
Objectifs
Dans le cadre du projet UBI, l'équipe 6811 a comme objectifs principaux de permettre au robot de transmettre des coordonnées fournies par le système de positionnement sonore (SPS) à la station de guidage, de recevoir les commandes de guidage transmises par l'équipe logiciel et d'en faire l'exécution en actionnant par exemple le moteur des roues ainsi que gérer les collision en arrêtant le robot lorsqu'il y a contact.
Responsabilités
L'équipe 6811 s'est donné comme responsabilité de fournir un protocole de communication permettant le dialogue entre la station de guidage et le robot ainsi que définir les messages reçus et transmis. Une autre responsabilité est de programmer le micro-contrôleur 68HC11 de Motorola de façon à atteindre les objectifs mentionnés précédemment.
Aspects techniques
Communications
La communication entre le robot et la station de guidage s'effectue par la transmission RF de l'équipe de communication RF. Afin de faciliter l'interfaçage, le port série du robot est utilisé pour transmettre l'information aux module RF. Ceci a permis de faire des essais avec le logiciel de la station de guidage même si les modules n'étaient pas disponibles.
Il a été décidé de mettre de côté l'interpréteur IC puisque ce dernier prend le contrôle du port série et ce, même durant l'exécution autonome du code. Cette décision a permis également d'opter pour un protocole de communication plus adapté en cas de difficultés de communication. On gagne ainsi sur la fiabilité du système en prévoyant, par exemple, un code de CRC pour la détection d'erreurs. Un autre avantage est la possibilité de communication entre plusieurs robots et plusieurs stations de guidage sur une même fréquence de communication puisqu'une adresse de destination est prévue dans les paquets de communication. Un aspect négatif cependant d'une telle décision a été l'obligation de recoder les procédures de contrôle et de lecture des périphériques du robot (roues, détecteurs de collisions, LCD, etc.).
Vous retrouverez dans les prochaines sections la version finale du protocole de communication et des messages reçus et transmis.
Protocole et messages
La communication s'effectue par transfert de paquets. Un paquet est un regroupement d'octets divisés en plusieurs champs.
Détails d'un paquet
L'identification de l'émetteur se fait par le premier champ. Chaque émetteur devrait avoir un identificateur qui lui est propre. Les intervalles suivants ont été prévus:
Trois stations de guidage distinctes et un nombre de 12 robots peuvent être adressés. Chacun des récepteurs devrait prendre en considération les messages ayant comme adresse de destination celle réservée pour la diffusion (0xF).
La longueur correspond au nombre d'octets dans le message. Le CRC-16, pour sa part, se calcule sur l'octet des adresses, l'octet de longueur et les octets des données. L'octet le plus significatif du CRC est en premier. Il est à noter qu'un message de longueur zéro est invalide. Un octet supplémentaire, soit le EOP (END OF PACKET), a été prévu afin de faciliter la resynchronisation. Sa réception n'assure cependant pas que le prochain octet sera le début d'un nouveau message puisqu'il peut y avoir conflit avec un autre octet du paquet. Le CRC peut alors être utilisé pour déterminer le moment où il s'agit bien de la fin du paquet.
Types de protocoles
Deux types de protocoles de communication ont été prévus. Le premier, soit le type I, ne permet que la communication point à point. Dans ce cas, l'émetteur ne fait que transmettre le message au récepteur. Ceci ne permet que la communication entre un robot et une station de guidage. Le second, soit le type II, permet la communication entre plusieurs robots et plusieurs stations de guidage pour un seul canal de communication qui est partagé. Dans ce cas, une station de guidage maître à qui on attribue une adresse 0x0 est définie. Cette station joue le rôle de médiateur dans la communication en donnant des temps d'antenne à chacun des modules sur le même canal. Lorsqu'un module, robot ou station de guidage, désire communiquer, il doit attendre son temps d'antenne, soit le message TALK, avant de pouvoir transmettre son message. Après réception, il transmet le message au destinataire. S'il ne réagit pas dans le délais de temps fixé par la station maître, le temps d'antenne sera décerné à un autre module. Cependant, dès que la station maître détecte qu'un message a été transmis par la station ayant le temps d'antenne, il remet à zéro son compteur pour permettre au module en communication de transmettre un autre message s'il y a lieu. Si le module n'a plus de messages spécifiques à transmettre, il peut transmettre le message DONE à la station maître pour indiquer qu'il a terminé ses transmissions . Les messages suivants ont été réservés pour ce type de protocole:
Messages transmis
Le code du message est sur 8 bits et les paramètres suivent ce dernier. Les paramètres sont données dans l'ordre, c'est-à-dire que le premier paramètre suit le code du message, le deuxième suit le premier et ainsi de suite. L'octet le plus significatif est en premier pour les valeurs 16 bits.
Messages reconnus par le robot
Message reconnus par la station de guidage
|
Demande à la station de guidage de transmettre un ACKNOWLEDGE. |
|||
|
Transmet l'état actuel du robot. SENSORS_STATUS est l'état actuel des détecteurs de collisions. Voir tableau See États des détecteurs de collisions.. . |
Limitations actuelles du protocole et des messages
Au moment de la rédaction de ce rapport final, le protole et les messages implantés dans le code du 6811 ont les limitations suivantes:
Développement du code
Le projet a été développé en assembleur et en C. Le compilateur utilisé est ICC (Image Craft C Cross Compiler) 0.48 du domaine publique comprenant également l'assembleur. La transmission initiale d'un déboggeur en mémoire du 6811 a été effectuée à l'aide de M68PCBug11 version 3.40. Le déboggeur utilisé est BUFFALO version 3.40 placé à l'adresse 0xE000 en mémoire. C'est à partir de ce déboggeur et un terminal en 9600-N-8-1 qu'il a été possible de transférer le code en format S19. Lorsque le robot est mis en marche en position "RUN", le code développé situé à l'adresse 0xC000 est automatiquement exécuté. Il est possible de sauter à BUFFALO en tenant enfoncé le détecteur de collision arrière lors de la mise sous tension du robot en position "RUN" pour pouvoir ainsi transférer une nouvelle version du code.
Librairies développés et programme principal
Vous retrouverez au tableau suivant les noms librairies qui ont été développées par l'équipe 6811 ainsi que le nom du programme principal.
Contrôle et lecture des périphériques
États du robot
Le robot peut être dans les quatres états suivants:
Mouvement du robot
L'activation des moteurs sur chacune des deux roues du robot permet à ce dernier d'avancer, de reculer, de pivoter vers la gauche et de pivoter vers la droite. Une puissance est donnée aux moteurs en pourcentage, ce qui a nécessité une conversion de cm/sec et deg/sec vers une puissance donnée. Cette conversion s'est effectuée à partir de mesures pour déterminer un facteur de conversion. La distance parcourue est déterminée par la lecture des encodeurs optiques sur chacune des roues, provoquant ainsi 32 transition pour un tour complet. À l'aide d'une routine en temps réel appelée à chaque milliseconde, il a été possible d'échantillonner suffisament pour déterminer les transitions au niveau des encodeurs. Lors d'un déplacement sur une certaine distance en centimètres ou d'une rotation avec un certain angle en degrés, dès qu'une roue a effectuée la rotation requise, le robot est arrêté. Ce contrôle se fait par la routine appelée en temps réel.
De façon pratique, nous avons observé que le robot offre peu de précision possible. Par exemple, une succession de rotation de 90 degrées et de -90 degrés ne permet pas de revenir continuellement au même point. Le fait de ne plus appliquer de force sur les moteurs ne fait pas bloquer immédiatement les roues et ce temps d'arrêt peut être plus grand sur une roue que sur une autre. Un asservissement en position serait intéressant avec l'utilisation d'une parabole pour l'application de la puissance.
Détection des collisions
La détection des collisions se fait par la routine en temps réel appelée à chaque milliseconde. Ainsi, des qu'une collision est détectée, le robot arrête immédiatement ses roues et attend qu'il n'y ait plus de collision pour permettre à nouveau un mouvement.
Nous avons noté que le robot détecte parfois de façon erroné une collision. Il peut s'agir d'interférences du moteur. Ceci a comme conséquence que parfois le robot s'arrête avant d'avoir terminé son mouvement.
Configuration du robot
Le robot peut être configuré à l'aide d'un terminal en 9600-N-8-1 en gardant enfoncé un des deux détecteurs de collision avant lors dde la mise sous tension en mode "RUN". Le menu suivant devrait apparaître sur l'écran du terminal:
L'adresse du robot peut être spécifiée. Dans ce cas, les messages transmis par ce dernier auront comme adresse de source cette adresse et le robot ne traitera que les messages ayant comme destinataire son adresse ou l'adresse BROADCAST. De plus, le robot ne considère que les messages ayant comme source l'adresse de la station de guidage à laquelle il est configuré. Les drapeaux de communication sont donnés au tableau See Drapeaux de communication. . Le mode "Manual Control" permet de contrôler le robot à l'aide du clavier de façon directe afin de faire des tests. Le mode "Run" permet de quitter la configuration et de commencer la boucle de traitement des messages.
Objectifs atteints et non atteints
Le protocole de base a pu être implanté avec succès. Il s'est avéré être un outil précieux ayant grandement facilité l'intégration avec l'interface. Le robot peut traiter les messages prévus et effectuer les mouvements désirés. La détection des collision fonctionne bien. La réalisation d'une routine appelé périodiquement en temps réel a été particulièrement pratique pour faciliter le contrôle du robot et permet une détection des collisions en tout temps.
Au moment de l'écriture de ce rapport, la lecture de la carte de positionnement n'a pu être implantée et vérifiée car les modules n'était pas disponibles. Il s'agit donc d'un objectif qui n'a pu être atteint.