• Développement des fonctions adaptées au Rug Warrior
• Initialisation
• Réception des impulsions(détection acoustique)
• Envoie des données à l`hôte
• Conclusion
 
• Système de positionnement par impulsions sonores
• Schéma du circuit de réception des impulsions sonores
 

• Documentation de référence
• Liens interressants

Cette partie du développement consiste à relever des données de position , les transmettre à un ordinateur hôte afin d’exécuter une commande motrice calculé par celui-ci . Afin de ne pas surcharger les exécutions du robot , la majorité des traitements sont fait sur l'ordinateur . Vous trouverez ,dans ce compte-rendu ,le  schéma de fonctionnement du robot ainsi que le cheminement parcouru pour atteindre nos objectifs.
 

L’initialisation contient principalement la déclaration des variables utilisées pour les commandes et la mise en fonction du nput-capture2 servant pour la détection acoustique(voir section suivante) . De plus , il est important de désactiver le `pcode` utilisé par interactive C . Cette désactivation permet d’avoir libre accès au port série du microcontrôleur et ainsi pouvoir établir un lien avec l’ordinateur hôte .
 

• générateur d’impulsions

Afin de positionner le robot , on utilise un cycle de 4 impulsions dont les pulses sont décalées de 150 millisecondes .À raison d’un cycle par seconde , nous avons établie une séquence facile à synchroniser et permettant d’éliminer l’effet des échos . Le générateur produit des impulsions à 10 kHz facilement détectable avec un micro bon marché .

• Micro de réception

Le micro utilisé est filtré par un filtre passe bande autour de 10 kHz , fréquence évitant de détecter les bruits ambiant . Nous avons ajusté nos gains afin de capter des signaux relativement fort par rapport aux échos pour une meilleur fiabilité .
 

• Principe de la réception

Pour savoir notre position , nous devons calculer les délais entre chacune de nos impulsions . Pour ce faire , on utilise la fonction input-capture du 68HC11 permettant de détecter des pulses et de savoir le moment exacte de leurs arrivés . En effet , la particularité de cette fonction est de mémoriser le temps de son registre compteur . Ainsi , lorsqu’une pulse est détecter , son temps est automatiquement insérer à l’adresse du input-capture. Le registre compteur est de 16 bits avec une vitesse d’horloge de 2 Mhz , ce qui représente un débordement à toute les 32.7 ms .

Au commencement , nous comptions le nombre débordement mais nous nous sommes rendu compte qu’on surchargeait le contrôleur, ce qui avait pour conséquence de nous donner une précision de 1200 coups d’horloge : environ 0.6 ms d’incertitude .

Puisque nous savons que l’on a environ 4-5 débordement entre chaque pulse , nous pouvons facilement utilisé la donnée la plus probable . Cette procédure nous a permis de réduire l’incertitude à 200 coups d’horloge (0.1ms) .

Pour synchroniser notre système , nous utilisons des fonctions définis dans interactive C . Il existe des fonctions permettant de calculer un temps en millisecondes . Il suffit simplement de remettre à zéro un compteur et de faire appel à la fonction mseconds() , fonction retournant un float indiquant un temps en ms . Ainsi , on identifie notre première pulse en vérifiant si nous avons eu un délai plus grand que 300 ms entre deux pulses . Ensuite , on fait une série de input-capture pour mémoriser le temps entre chaque pulse . On insère une attente de 100ms entre chaque détection pour éliminer les réflexions immédiate . Après cette attente , on « clear » le flag du input capture pour recevoir la pulse suivante et ainsi de suite.
 
 

Lors de l`initialisation du processus , on désactive le pcode utilisé par interactive C afin d`avoir le contrôle sur le port série . Nous ne changeons pas la configuration du port  , c`est-à-dire qu`on communique à 9600 bauds , un stop bit et un start bit .
 
 

• Communication

Après avoir reçu les quatre impulsions , on transmet les données retenues par le input-capture et on envoie l'état des bumper . Ainsi , l`hôte peut calculer les délais entre chaque pulse et peut savoir s`il y a des obstacles devant le robot . On utilise pas de protocole spéciale , on ne vérifie pas si la donnée a été reçu car on se contente d`une procédure transmission / réception simplement . Ce qui est important de remarquer , c`est que le register compteur  du 68hc11 est de type `signed` , ainsi le compteur contient une valeur comprise entre 0 à 32 768 et passe ensuite de  -32 767 à -1 .C`est alors qu`il se produit l`débordement  . Nous avons perdu du temps sur la compréhension du compteur et sur la façon de taiter la donnée . En effet, après une multitude de tests , nous avons découvert que le contrôleur ne pouvait pas traiter rapidement nos calculs . C`est qu`il fallait faire des calculs sur 32 bits…ce qui est trop long pour le robot. Nous avons réglé le problème en laissant calculer les délais à l`ordinateur . Ainsi , on a simplement quatre états de compteur(16 bits) à envoyer à l`hôte ; ce qui réduit la quantité `information à transmettre . Il aurait fallu transmettre trois délais de 32 bits comparativement à quatre états de compteur 16 bits présentement utilisé.

• Réception de la commande

La commande reçue au robot est codée sur huit bits . nous avons un bit pour la vérification de la batterie , trois bits pour les commandes de rotation* et 2bits de vitesse des roues pour chacune des roues .
 

Nous avons des problèmes avec les encoders de roue faisant en sorte que nous n`avons aucune précision dans la rotation . Ainsi , nous n`utilisons pas beaucoup ces commandes ajustant plutôt la vitesse des roues pour faire une rotation . C`est plus lent mais nous avons préféré cette méthode pour une meilleur performance à ce stade-çi du projet . Il serait question de changer les encoders de roues pour la prochaine session pour avoir une meilleure capacité à savoir la distance parcourue par le robot …

N'ayant pas beaucoup d`informations sur le robot , il a été difficile d`avancer rapidement pour la communication
série. Ainsi , une fois cette étape franchit , nous avons rapidement progresser pour avoir ce résultat finale . Avoir
réussit plus tôt la communication série , nous aurions probablement un meilleur système puisque nous connaissons
quelques unes des erreurs qui se produit lors des tests pratique , notamment au niveau de la vitesse de traitement
des données qui est plus lent que prévus . Ce problème amène des modifications majeurs au projet …mais il faut
le donner au client comme ça!

Ce circuit a été testé en remplaçant le micro par un générateur d’onde. Dans les conditions de ce test, le circuit
fonctionnait correctement. Il faudra cependant effectuer des tests avec le micro pour être certain que ce circuit
est approprié à notre application.

Bien que nous ayons déjà une bonne idée de comment faire, nous n’avons toujours pas élaboré le programme
du microcontrôleur qui traite la sortie de ce signal.

En plus des échange d’information et avec le robot et de son contrôle, le PC devra envoyer un signal de syncronisation
au robot lorsque lorsqu’un série de quatre impulsions débutera.

En fait, puisque notre travail avec le microcontrôleur s’est résumé jusqu’à présent à essayer de comprendre le
protocole de communication avec le PC. Il nous faudra par la suite, au besoin, modifier cette interface en plus
d’y ajouter le contrôle des différents périphériques que nous avons rajouté au robot.

**Cette section est à jour dans le rapport final
 
 
 

• Rapport final sur le contrôle
• Document technique sur le Rug Warrior
• Documentation du MF8
 

• Code source du contrôle :   common.c ,  port_serie ,  projet2 ,  track
 

• Motorola : 68HC11