Synchronise : Différence entre versions

De Wiki de bureau d'études PeiP
(Fonctionnement des programmes)
Ligne 35 : Ligne 35 :
  
 
= Fonctionnement des programmes  =
 
= Fonctionnement des programmes  =
 
+
== Connexion maître – esclave ==
 
+
<p align="justify">L'utilisation du Bluetooth sur les NXT Lego a nécessité un grand nombre de tests afin de comprendre le fonctionnement de cette connexion.  La connexion et l'envoi de messages par Bluetooth entre les 2 robots doit se faire en plusieurs étapes. Tout d'abord, un des 2 robots entame la connexion, il devient le « maître ». Il se connecte sur le deuxième robot grâce à son identification, en effet chaque robot doit posséder son propre nom (les nôtres se nomment 3PJ et BOB) et le programme doit contenir le numéro du port de connexion entre 1 et 3 que va utiliser le robot maître pour se connecter. L'autre robot accepte la connexion et devient ainsi « esclave », et le robot « maître » se connecte obligatoirement sur le port 0 de l'esclave. Après la connexion, le maître peut envoyer un message de forme numérique, texte ou booléenne à l'esclave, mais ce dernier peut également envoyer un message au maître. Ainsi, il suffit qu'un seul des robots prenne l'initiative de la connexion pour que les 2 puissent dialoguer. A la fin du programme, on peut utiliser une instruction pour que l'un des robots, maître ou esclave, coupe la connexion.</p>
  
 
= Remarques pour l'élargissement du programme aux autres robots =
 
= Remarques pour l'élargissement du programme aux autres robots =
 
test
 
test

Version du 4 mars 2011 à 08:15

Objectifs du premier semestre

Réaliser 2 robots communicants. C'est-à-dire réaliser un programme tel que :
- Les robots avancent s'ils ne rencontrent pas d'obstacle
- Un robot qui voit un obstacle s'arrête et envoie un message à l'autre robot pour que lui aussi s'arrête.
L'envoi des messages doit se faire via Bluetooth.
Les objectifs ont été atteints le 18/02 à 12h00.


Conception des robots

La conception du robot est une des difficultés rencontrées au cours de ce Bureau d’étude. Tout d’abord, il faut que nos robots puissent intégrer tous les programmes que les autres groupes réaliseront ; ainsi notre robot doit laisser place à un accès pour tous les capteurs susceptibles de s’y greffer (capteurs de couleurs, d’ultrasons, tactiles, etc.). Deuxièmement, nous devions aussi faire en sorte de facilement pouvoir atteindre le compartiment à piles pour que, lorsque l’on remplace ces dernières, le robot ne soit pas entièrement démonté. Enfin, en ce qui concerne les moteurs et la direction, 2 choix s’offrent à nous : soit on fait un robot sur chenilles, méthode simple pour faire des rotations mais qui ralentit considérablement le robot, soit on utilise 3 ou 4 roues (2 motrices et 1 ou 2 directionnelle(s)), méthode complexe au niveau de la programmation mais qui assure au robot une plus grande rapidité de mouvement. Etant donné que nous travaillons sur 2 robots, chacune des méthodes est utilisée : les chenilles sur 3PJ et les 4 roues avec une direction sur BOB.

Robot A : 3PJ

ben voila quoi.

Robot B : BOB

La conception de BOB a donc été la toute première étape du projet. Nous avons donc consacré les deux premières séances à prendre connaissance des objectifs et à réaliser un robot correspondant aux attentes, mais aussi à notre goût.

BOB 1.0

BOB 1.0
Version initiale de BOB

Lors de la première séance, nous avons créé le robot de « base », en suivant le plan étape par étape fourni avec la boîte du robot. Cela nous a permis de découvrir les pièces Lego™ à notre disposition, les différents capteurs, moteurs, et d’obtenir une première base.

BOB 2.0

BOB 2.0
Version actuelle de BOB

Très vite, cette version nous a gêné car peu recherchée. Et surtout, nous voulions utiliser les roues fournies dans la boîte plutôt que les chaînes, préférant une voiture à un char. Cette idée d’utiliser les roues a entrainé un premier problème, se résumant à cette question : comment le robot va-t-il tourner ?
L’avantage des chaines était qu’elles utilisaient un moteur de chaque côté, et permettaient au robot de pivoter sur lui-même en désynchronisant les moteurs.
Nous nous sommes alors inspiré d’un projet déjà existant : la NXT Race Car (http://www.nxtprograms.com/NXT2/race_car/index.html). Nous avons récupéré la direction de ce modèle afin de gagner du temps, puis avons adapté nos capteurs.

Branchements

A & B : Moteurs de propulsion (/!\ BOB avance quand les moteurs vont dans le sens « reculer »)
C : Moteur de la direction
1 : Libre pour l’instant
2 : Capteur photosensible (placé en dessous en position centrale)
3 : Libre pour l’instant
4 : Capteur à ultrason (placé à l’avant)

Fonctionnement des programmes

Connexion maître – esclave

L'utilisation du Bluetooth sur les NXT Lego a nécessité un grand nombre de tests afin de comprendre le fonctionnement de cette connexion. La connexion et l'envoi de messages par Bluetooth entre les 2 robots doit se faire en plusieurs étapes. Tout d'abord, un des 2 robots entame la connexion, il devient le « maître ». Il se connecte sur le deuxième robot grâce à son identification, en effet chaque robot doit posséder son propre nom (les nôtres se nomment 3PJ et BOB) et le programme doit contenir le numéro du port de connexion entre 1 et 3 que va utiliser le robot maître pour se connecter. L'autre robot accepte la connexion et devient ainsi « esclave », et le robot « maître » se connecte obligatoirement sur le port 0 de l'esclave. Après la connexion, le maître peut envoyer un message de forme numérique, texte ou booléenne à l'esclave, mais ce dernier peut également envoyer un message au maître. Ainsi, il suffit qu'un seul des robots prenne l'initiative de la connexion pour que les 2 puissent dialoguer. A la fin du programme, on peut utiliser une instruction pour que l'un des robots, maître ou esclave, coupe la connexion.

Remarques pour l'élargissement du programme aux autres robots

test