Wiki de bureau d'études PeiP - Contributions de l’utilisateur [fr]

CageBut2013-2

2014-03-10T08:49:34Z

Mherwegh : /* Le but dans son ensemble */

== Introduction ==

Pour le bureau d'études d'IMA, nous devons réaliser une cage de but autonome et communicante. Pour cela, plusieurs contraintes nous semble essentiels :
* les robots ayant une certaine dimension et la balle mesurant tout de même 75mm, il faudra choisir une taille de but convenable.
* la cage de but doit émettre dans l'infra-rouge pour être repérable sachant que la balle émet déjà dans l'infra-rouge ainsi que le but adverse.
* la cage devant repéré si un but est encaissé, il faut donc dirigé cette dernière vers un capteur de pression, mais celui-ci sera forcément bien plus petit que le but. Il faut donc penser à diriger la balle vers ce dernier.
* Enfin, nécessitant un renvoie de balle, il faut penser à un système d'expulsion n'interferant pas avec le capteur de pression.

== Le capteur de pression ==

Le capteur de pression est soumis à trois contraintes :

* Il doit être suffisamment sensible pour bien comptabiliser chaque but, pour cela, nous utilisons deux approches :
une approche mécanique, une approche logicielle.
* Il ne doit pas être trop sensible pour éviter de comptabiliser plusieurs fois un même but pour cause de rebond de la balle ou autre interférence.
* La cage du but étant de taille bien supérieur au capteur il faut dirigé la balle vers le capteur.

==== Première étape : la formation mécanique du capteur ====

* Tout d'abord, nous avons décidé d'élargir un peu la zone de pression du capteur en lui donnant une forme semi-elliptique. D'un point de vue mécanique on peut voir que le capteur est soumis à plusieurs contraintes ce qui ne lui laisse qu'un seul degré de liberté : une translation selon son axe. En effet, les deux barres hautes évitent toutes rotations de notre bumper, rotation qui étaient présente au début et pouvait empêcher le déclenchement du capteur voire le bloquer.

[[Fichier:capteur_pression_v1.jpg]]

* Après avoir construit le squelette de la cage de but, nous avons remarqué que la forme de la cage ne suffit pas à la dirigé vers le capteur. En effet lorsque la balle arrive de face sur le bois elle perd toute sa vitesse et s’arrête avant de toucher le capteur. Nous avons donc décidé d'utiliser deux bras mécanique en rotation permanente afin que, quelque soit l'angle d'entrée de la balle dans le but, celle-ci soit dirigée vers le capteur.

[[Media:angles_morts.mp4]]

[[Fichier:but_bois_v2.jpg]]

* Suite aux modifications apportées à la structure de la cage de but nous avons modifié le capteur de plusieurs façons. Nous avons changer la forme du capteur afin que la balle soit dirigé vers son centre. Puis nous avons ajouté un amortisseur afin que la balle ne puisse pas rebondir sur le capteur sans l'actionner.

[[Fichier:capteur_pression_v2.jpg]]

=== Deuxième étape : la programmation ===

D'un point de vue logicielle trois possibilités s'offrent à nous dans la programmation MINDSTORM : une détection quand le capteur est enfoncé, quand il est relâché, quand il est heurté. Après avoir testé la fonction heurté, on en a déduit que ce dernier demandait une approche de la balle assez rapide, chose qui ne sera pas forcément le cas. C'est pourquoi nous avons choisi la fonction enfoncé qui semble être la plus adaptée.

[[Fichier:capteur_logiciel.png]]

== Le système d'expulsion ==

* Ensuite, nous avons construit un bras mécanique, autour du capteur, capable d'expulser la balle sans interférer avec celui-ci.

[[Fichier:capteur-profil_v1.png]]

* Nous avons supprimer le bras mécanique permettant d'expulser la balle puisque les deux autres bras peuvent s'en charger.

== Communication ==

Le cahier des charges demande explicitement que lorsqu'un but est encaissé, la cage communique cette information aux robots, ces derniers se replacent et, une fois replacés, la partie peut-être relancée. La partie se jouant entre 4 robots et le NXT pouvant communiquer avec seulement trois autres NXT, nous avons décidé que les deux buts communiqueraient entre eux sur la connexion 3 et chaque but avec les deux robots de son équipe sur les connexions 1 et 2. Notre but est donc esclave par rapport au but adverse et maitre par rapport aux deux robots. De plus nous avons décidé de communiquer sur la boite aux lettres du numéro de communication correspondante afin de bien différencier les messages provenant de chaque autre NXT.

=== Si notre but encaisse ===

Lorsque nous encaissons un but, nous gérons cette information à l'aide d'une variable que nous dénommons trivialement "but". Cette variable permet de lancer un programme parallèle adapté à la communication dans le cas présent. La gestion du but va donc se passer en trois grandes étapes.

* Nous encaissons le but : la variable "but" passe sur vrai et cela entraine un envoi du message "but" au but adverse sur la communication 0 boite au lettre 3 ainsi qu'aux robots de l'équipe sur les communications 1 et 2 sur respectivement les boites aux lettres 1 et 2.

* Nous attendons le temps que les robots se replacent et nous envoient chacun le message "replacer" sur nos boites au lettres 1 et 2 respectivement ainsi que sur la boite aux lettres 3 pour le but adverse.

* une fois ce dernier message reçu, nous pouvons donc renvoyer la balle et envoyer un message de libération à l'ensemble des robots : message que nous nommerons "bouge". Maintenant que la partie est relancée nous pouvons remettre nos trois variables "but", "replacer" et "bouge" à leurs états initiaux.

=== Si le but adverse encaisse ===

Lorsque le but adverse encaisse, en opposition à lorsque nous encaissons, nous recevons le message "but" sur la boite aux lettres 3. Une fois ce message reçu, nous gérons le but encaissé par l'adversaire en trois étapes similaire à celle de la partie précédente. :

* Le message "but" étant arrivé, nous le transmettons aux robots de notre équipe.

* Pour la suite, nous attendons que ces derniers se replacent. Une fois replacés, nous transmettons l'information au but adverse.

* Enfin, nous attendons que le but adverse nous informe que la balle a été renvoyé pour libérer les robots de notre équipe à l'aide du message "bouge". Une fois toute cette procédure finie, comme pour la partie précédente, nous pouvons réinitialiser l'ensemble de nos trois variables à leur état par défaut.

== Le but dans son ensemble ==

-[[Fichier:but_bois_v1.jpg]]

On peut voir sur la partie supérieur du but trois LEDs : celle du centre qui est une LED émettant dans le visible et donc une LED de contrôle visuel, et les deux LEDs des extrémités émettant dans l'infra-rouge. C'est trois LEDs sont réglés à une fréquence donnée de ... permettant aux robots de détecter le but.

Concernant la fréquence, deux contraintes sont apparus de façon évidente. Premièrement, les robots doivent différencier leur but d'attaque de leur but de défense et de la balle, il fallait donc trois fréquences différentes. Deuxièmement, les robots ne peuvent pas détecter n'importe quelle fréquence, il a donc fallu tester avec ces derniers la plage acceptable.

Enfin, ces LEDs sont placés en hauteur et sur les extrémités des robots. En effet les robots détectant les ondes en fonction de "zone", le fait de mettre les LEDs aux extrémités cela leur permet de détecter les deux poteaux du but mais aussi de faire une moyenne pour détecter le centre du but. Cette disposition nous a donc paru comme la meilleure.

CageBut2013-2

2014-03-10T08:49:17Z

Mherwegh : /* Le but dans son ensemble */

== Introduction ==

Pour le bureau d'études d'IMA, nous devons réaliser une cage de but autonome et communicante. Pour cela, plusieurs contraintes nous semble essentiels :
* les robots ayant une certaine dimension et la balle mesurant tout de même 75mm, il faudra choisir une taille de but convenable.
* la cage de but doit émettre dans l'infra-rouge pour être repérable sachant que la balle émet déjà dans l'infra-rouge ainsi que le but adverse.
* la cage devant repéré si un but est encaissé, il faut donc dirigé cette dernière vers un capteur de pression, mais celui-ci sera forcément bien plus petit que le but. Il faut donc penser à diriger la balle vers ce dernier.
* Enfin, nécessitant un renvoie de balle, il faut penser à un système d'expulsion n'interferant pas avec le capteur de pression.

== Le capteur de pression ==

Le capteur de pression est soumis à trois contraintes :

* Il doit être suffisamment sensible pour bien comptabiliser chaque but, pour cela, nous utilisons deux approches :
une approche mécanique, une approche logicielle.
* Il ne doit pas être trop sensible pour éviter de comptabiliser plusieurs fois un même but pour cause de rebond de la balle ou autre interférence.
* La cage du but étant de taille bien supérieur au capteur il faut dirigé la balle vers le capteur.

==== Première étape : la formation mécanique du capteur ====

* Tout d'abord, nous avons décidé d'élargir un peu la zone de pression du capteur en lui donnant une forme semi-elliptique. D'un point de vue mécanique on peut voir que le capteur est soumis à plusieurs contraintes ce qui ne lui laisse qu'un seul degré de liberté : une translation selon son axe. En effet, les deux barres hautes évitent toutes rotations de notre bumper, rotation qui étaient présente au début et pouvait empêcher le déclenchement du capteur voire le bloquer.

[[Fichier:capteur_pression_v1.jpg]]

* Après avoir construit le squelette de la cage de but, nous avons remarqué que la forme de la cage ne suffit pas à la dirigé vers le capteur. En effet lorsque la balle arrive de face sur le bois elle perd toute sa vitesse et s’arrête avant de toucher le capteur. Nous avons donc décidé d'utiliser deux bras mécanique en rotation permanente afin que, quelque soit l'angle d'entrée de la balle dans le but, celle-ci soit dirigée vers le capteur.

[[Media:angles_morts.mp4]]

[[Fichier:but_bois_v2.jpg]]

* Suite aux modifications apportées à la structure de la cage de but nous avons modifié le capteur de plusieurs façons. Nous avons changer la forme du capteur afin que la balle soit dirigé vers son centre. Puis nous avons ajouté un amortisseur afin que la balle ne puisse pas rebondir sur le capteur sans l'actionner.

[[Fichier:capteur_pression_v2.jpg]]

=== Deuxième étape : la programmation ===

D'un point de vue logicielle trois possibilités s'offrent à nous dans la programmation MINDSTORM : une détection quand le capteur est enfoncé, quand il est relâché, quand il est heurté. Après avoir testé la fonction heurté, on en a déduit que ce dernier demandait une approche de la balle assez rapide, chose qui ne sera pas forcément le cas. C'est pourquoi nous avons choisi la fonction enfoncé qui semble être la plus adaptée.

[[Fichier:capteur_logiciel.png]]

== Le système d'expulsion ==

* Ensuite, nous avons construit un bras mécanique, autour du capteur, capable d'expulser la balle sans interférer avec celui-ci.

[[Fichier:capteur-profil_v1.png]]

* Nous avons supprimer le bras mécanique permettant d'expulser la balle puisque les deux autres bras peuvent s'en charger.

== Communication ==

Le cahier des charges demande explicitement que lorsqu'un but est encaissé, la cage communique cette information aux robots, ces derniers se replacent et, une fois replacés, la partie peut-être relancée. La partie se jouant entre 4 robots et le NXT pouvant communiquer avec seulement trois autres NXT, nous avons décidé que les deux buts communiqueraient entre eux sur la connexion 3 et chaque but avec les deux robots de son équipe sur les connexions 1 et 2. Notre but est donc esclave par rapport au but adverse et maitre par rapport aux deux robots. De plus nous avons décidé de communiquer sur la boite aux lettres du numéro de communication correspondante afin de bien différencier les messages provenant de chaque autre NXT.

=== Si notre but encaisse ===

Lorsque nous encaissons un but, nous gérons cette information à l'aide d'une variable que nous dénommons trivialement "but". Cette variable permet de lancer un programme parallèle adapté à la communication dans le cas présent. La gestion du but va donc se passer en trois grandes étapes.

* Nous encaissons le but : la variable "but" passe sur vrai et cela entraine un envoi du message "but" au but adverse sur la communication 0 boite au lettre 3 ainsi qu'aux robots de l'équipe sur les communications 1 et 2 sur respectivement les boites aux lettres 1 et 2.

* Nous attendons le temps que les robots se replacent et nous envoient chacun le message "replacer" sur nos boites au lettres 1 et 2 respectivement ainsi que sur la boite aux lettres 3 pour le but adverse.

* une fois ce dernier message reçu, nous pouvons donc renvoyer la balle et envoyer un message de libération à l'ensemble des robots : message que nous nommerons "bouge". Maintenant que la partie est relancée nous pouvons remettre nos trois variables "but", "replacer" et "bouge" à leurs états initiaux.

=== Si le but adverse encaisse ===

Lorsque le but adverse encaisse, en opposition à lorsque nous encaissons, nous recevons le message "but" sur la boite aux lettres 3. Une fois ce message reçu, nous gérons le but encaissé par l'adversaire en trois étapes similaire à celle de la partie précédente. :

* Le message "but" étant arrivé, nous le transmettons aux robots de notre équipe.

* Pour la suite, nous attendons que ces derniers se replacent. Une fois replacés, nous transmettons l'information au but adverse.

* Enfin, nous attendons que le but adverse nous informe que la balle a été renvoyé pour libérer les robots de notre équipe à l'aide du message "bouge". Une fois toute cette procédure finie, comme pour la partie précédente, nous pouvons réinitialiser l'ensemble de nos trois variables à leur état par défaut.

== Le but dans son ensemble ==

-[[Fichier:but_bois_v1.jpg]]

On peut voir sur l partie supérieur du but trois LEDs : celle du centre qui est une LED émettant dans le visible et donc une LED de contrôle visuel, et les deux LEDs des extrémités émettant dans l'infra-rouge. C'est trois LEDs sont réglés à une fréquence donnée de ... permettant aux robots de détecter le but.

Concernant la fréquence, deux contraintes sont apparus de façon évidente. Premièrement, les robots doivent différencier leur but d'attaque de leur but de défense et de la balle, il fallait donc trois fréquences différentes. Deuxièmement, les robots ne peuvent pas détecter n'importe quelle fréquence, il a donc fallu tester avec ces derniers la plage acceptable.

Enfin, ces LEDs sont placés en hauteur et sur les extrémités des robots. En effet les robots détectant les ondes en fonction de "zone", le fait de mettre les LEDs aux extrémités cela leur permet de détecter les deux poteaux du but mais aussi de faire une moyenne pour détecter le centre du but. Cette disposition nous a donc paru comme la meilleure.

CageBut2013-2

2014-03-06T16:09:52Z

Mherwegh : /* Communication */

CageBut2013-2

2014-03-06T15:23:18Z

Mherwegh :

CageBut2013-2

2014-03-06T15:18:39Z

Mherwegh :

CageBut2013-2

2014-03-06T15:00:59Z

Mherwegh : /* Deuxième étape : la programmation */

CageBut2013-2

2014-02-17T07:49:26Z

Mherwegh :

Fichier:Capteur profil v1.jpg

2014-02-17T07:48:47Z

Mherwegh :

CageBut2013-2

2014-02-17T07:46:20Z

Mherwegh :

Fichier:But bois v1.jpg

2014-02-17T07:45:35Z

Mherwegh :

CageBut2013-2

2014-02-17T07:44:47Z

Mherwegh :

CageBut2013-2

2014-02-17T07:42:12Z

Mherwegh :

Fichier:Capteur logiciel.png

2014-02-17T07:31:42Z

Mherwegh : a téléversé une nouvelle version de « Fichier:Capteur logiciel.png »

Fichier:Capteur logiciel.png

2014-02-17T07:29:31Z

Mherwegh :

CageBut2013-2

2014-02-17T07:29:18Z

Mherwegh :

CageBut2013-2

2014-02-17T07:21:34Z

Mherwegh : /* Première étape : la formation mécanique du capteur */

Fichier:Capteur pression v1.jpg

2014-02-17T07:16:54Z

Mherwegh :

CageBut2013-2

2014-02-03T07:09:59Z

Mherwegh :

CageBut2013-2

2014-01-27T10:07:38Z

Mherwegh : /* Le capteur de pression */

CageBut2013-2

2014-01-27T09:43:34Z

Mherwegh :

CageBut2013-2

2014-01-27T09:36:44Z

Mherwegh : /* Cage de But 2 - Bureau d'Etude IMA 2013-2014 */

== Introduction ==

Pour le bureau d'études d'IMA, nous devons réaliser une cage de but autonome. Pour cela, plusieurs contraintes nous semble essentiels :
* les robots ayant une certaine dimension et la balle mesurant tout de même 75mm, il faudra choisir une taille de but convenable.
* la cage de but doit émettre dans l'infra-rouge pour être repérable sachant que la balle émet déjà dans l'infra-rouge.
* la cage devant repéré si un but est encaissé, il faut donc dirigé cette dernière vers un capteur de pression, mais celui-ci sera forcément bien plus petit que le but. Il faut donc penser à diriger la balle vers ce dernier.
* Enfin, nécessitant un renvoie de balle, il faut penser à un système d'expulsion n'interferant pas avec le capteur de pression.

CageBut2013-2

2014-01-27T09:25:15Z

Mherwegh :

== Cage de But 2 - Bureau d'Etude IMA 2013-2014 ==

CageBut2013-2

2014-01-27T09:23:13Z

Mherwegh : Page créée avec « test »

test

Discussion:CageBut2013-2

2014-01-27T09:22:22Z

Mherwegh : Page créée avec « test »

test

BE 2013-2014

2014-01-20T07:37:47Z

Mherwegh : /* Cage de but */

= Objectif à atteindre =

Ce bureau d'étude a comme finalité la construction de robots joueurs de balle. Ces robots doivent s'affronter sur un terrain découpé en quatre zones avec des buts aux extrêmités opposées.
[[Image:terrain.png|500px|center]]
Les robots vont devoir s'affronter par paires. Le but d'une paire de robot est d'arriver à envoyer l'unique balle dans le but adverse sans qu'il leur arrive la même chose. Il n'y a pas de spécialisation dans les robots. Chacun pouvant attaquer ou défendre. Un robot qui trouve la balle va chercher à l'attraper et à la lancer sans rentrer en contact avec un autre robot. Un robot qui ne trouve pas la balle va se replier sur un rôle de défenseur. Les robots ne peuvent, bien entendu, pas quitter le terrain.

Pour repérer la balle et les buts des signaux modulés dans l'infra-rouge vont être utilisés. La balle et les buts ne moduleront pas suivant la même fréquence. Les robots vont devoir se repérer dans le terrain en utilisant un détecteur de couleur et des lignes au sol. Ils peuvent aussi se répérer via un pavage non couvrant du terrain par des cartes RFID.

Dans dispositif les buts sont des objets intelligents capable d'interagir avec la balle et les robots.

Pour 2013/2014, il est juste prévu d'explorer le thème, réaliser des compétitions entre robots autonomes paraissant encore hors d'atteinte. Pour pouvoir tout de même présenter des compétitions entre robots, des équipes réaliseront des robots télécommandés par WiFi. Des compétitions pourront donc avoir lieu mais entre humains, par l'intermédiaire des robots.

= Matériel à votre disposition =
{| style="float: right; height: 160px; margin-left:0.2em; border: 1px solid #bbb;"
| style="border: 1px solid #bbb;" valign="top" |[[File:boite_mindstorm.jpg|150px]]
|- style="font-size: 87%; text-align: center;"
| valign="center" | Legos Mindstorm
|}
{| style="float: left; height: 160px; margin-left:0.2em; border: 1px solid #bbb;"
| style="border: 1px solid #bbb;" valign="top" |[[File:foxboard.jpg|150px]]
| style="border: 1px solid #bbb;" valign="top" |[[File:arduino.jpg|150px]]
|- style="font-size: 87%; text-align: center;"
| valign="center" | Système FoxBoard
| valign="center" | Platine Arduino
|}
Les couches basses des robots et des buts seront réalisées à l'aide de Lego MindStorm. Le Lego va permettre de réaliser le chassis des robots avec sa motorisation et d'y installer divers capteurs. Le lego permettra aussi de réaliser les cages des buts avec les émetteurs infra-rouges, le dispositif de test de présence de la balle et le dispositif d'éjection. Il est même possible d'assurer une certaine communication entre robots et buts grâce à la technologie <tt>bluetooth</tt> intégrée au micro-contrôleur MindStorm. Pour aller plus loin, il est nécessaire d'embarquer un micro-PC de type FoxBoard sur les robots. C'est ce micro-PC qui permettra les acquisitions d'images et c'est à lui qui transmettera au micro-contrôleur du MindStorm les ordres de déplacement ou de lancement de balle. Pour réaliser le signal de repérage des buts, une platine Arduino sera utilisée.

 

= Répartition des tâches =

Chaque binôme va se voir affecter une des problématiques décrites dans les sous-sections suivantes.

== Cage de but ==
Une cage de but doit comporter les dispositifs décrits ci-dessous.
* La cage doit émettre un signal infra-rouge pour être facilement repérable par les robots. Pour cela vous partirez de LED infra-rouges et vous modulerez leur alimentation par une platine Arduino pour émettre un signal facilement identifiable. Ajouter quelques LED dans le visible pour mimer la fréquence dans l'infra-rouge ne peut pas nuire.
* La cage doit détecter quand la balle rentre dans la cage en la dirigeant précisement vers un capteur de contact.
* La cage doit signaler un but à l'ensemble des robots en comptétion et à l'autre cage. Elle tient aussi le compte du score.
* Enfin la cage doit pouvoir expulser la balle quand les robots se sont repositionnés sur le terrain pour une nouvelle action.

<table border="1">
<tr> <th>Elèves</th> <th>Matériel</th> <th>Page</th> </tr>
<tr>
<td> Raphaël De Clercq - Nicolas Duflos </td>
<td> Boite lego MindStorm, LED Infra-rouge, Arduino UNO </td>
<td> [[CageBut2013-1|Cage de but 1]] </td>
</tr>
<tr>
<td> Basile Lacombe-Bar - Matthieu Herwegh </td>
<td> Boite lego MindStorm, LED Infra-rouge, Arduino UNO </td>
<td> [[CageBut2013-2|Cage de but 2]] </td>
</tr>
</table>

== Robots d'attaque ==
Pour simplifier la conception des robots compétiteurs, les comportements d'attaque et de défense sont séparés. Pour cet atelier, il est demandé de se pencher sur le comportement d'attaque.

Il s'agit du comportement d'un robot lorsqu'il a su repérer la balle.
* Il se dirige vers la balle pour la capturer. Une fois la balle capturée le robot ne se déplace plus en translation.
* Il lance la balle vers le but adverse. Une rotation peut être nécessaire pour l'envoi.

D'un point de vue mécanique certains dispositifs doivent être étudiés.
* Un dispositif de capture de la balle, un simple récupérateur non articulé devrait suffire.
* Un dispositif de lancement. Vous pouvez étudier le lancement en utilisant un servo-moteur ou un dispositif de rotation du robot.

Les capteurs nécessaires à un robot d'attaque sont décrits ci-dessous.
* Le capteur infra-rouge pour se diriger vers la balle et estimer la position du but.
* Le capteur ultra-son pour éviter de percuter les objets (buts et autres robots).
* Un capteur de couleur pour éviter de sortir du terrain.

<table border="1">
<tr> <th>Elèves</th> <th>Matériel</th> <th>Page</th> </tr>
<tr>
<td> Prénom Nom - Prénom Nom </td>
<td> Boite lego MindStorm, Capteur infra-rouge </td>
<td> [[RobotAttaque2013-1|Robot d'attaque 1]] </td>
</tr>
<tr>
<td> Prénom Nom - Prénom Nom </td>
<td> Boite lego MindStorm, Capteur infra-rouge </td>
<td> [[RobotAttaque2013-2|Robot d'attaque 2]] </td>
</tr>
</table>

== Robot de défense ==
Le second comportement nécessaire à nos robots compétiteurs est le comportement de défense. C'est le comportement qu'adopte un robot lorsqu'il ne trouve plus la balle dans le doute qu'un autre robot l'ait capturée. Dans ce cas de figure le robot doit se rapprocher de toutes ses roues de son but pour le défendre.

Toute la difficulté de cette tâche consiste à se repérer sur le terrain. Pour cela le robot dispose de plusieurs moyens.
* Il peut repérer par infra-rouge son but.
* Chacune des zones du terrain peut être délimitée par une couleur spécifique à la zone. Le robot peut ainsi se situer dès qu'il tombe sur une ligne.
* Le terrain peut être pavé de cartes RFID. Il suffit d'associer aux identifiants des cartes leur position pour permettre un repérage très précis.

Votre but est d'essayer les différentes méthodes pour pouvoir les tester et les comparer. Il faudra peut être les mixer pour obtenir une méthode efficace dans toutes les situations.

Votre robot doit bien entendu ne jamais sortir du terrain (une partie du robot doit toujours être sur le terrain) et il ne doit pas rentrer dans les obstacles. Vous établirez aussi une règle pour que les robots ne puissent pas totalement obstruer le but.

Les capteurs nécessaires à un robot d'attaque sont décrits ci-dessous.
* Le capteur infra-rouge pour se diriger vers son but.
* Le capteur ultra-son pour éviter de percuter les objets (buts et autres robots).
* Un capteur de couleur pour reconnaître la zone et éviter de sortir du terrain.
* Un capteur RFID pour lire les cartes RFID de pavage du terrain.

<table border="1">
<tr> <th>Elèves</th> <th>Matériel</th> <th>Page</th> </tr>
<tr>
<td> Prénom Nom - Prénom Nom </td>
<td> Boite lego MindStorm, Capteur infra-rouge, Module RFID, Cartes RFID </td>
<td> [[RobotDefense2013-1|Robot de défense 1]] </td>
</tr>
<tr>
<td> Prénom Nom - Prénom Nom </td>
<td> Boite lego MindStorm, Capteur infra-rouge, Module RFID, Cartes RFID </td>
<td> [[RobotDefense2013-2|Robot de défense 2]] </td>
</tr>
</table>

== Robot téléguidé avec système embarqué ==
Votre robot doit pouvoir être radio-guidé par un contrôleur. Le dit contrôleur peut diriger le robot au vu de l'image de la webcam embarquée. L'acquisition de la webcam et sa diffusion par WiFi est assuré par un système embarqué FoxBoard. La FoxBoard vous sera livrée configurée mais il faudra l'embarquer dans votre robot avec tous ses accessoires (webcam, module <tt>bluetooth</tt>, boitier de piles). Un calcul du temps d'autonomie doit être effectué. Dans un premier temps le radio-guidage peut se faire à l'aide du logiciel MindStorm par <tt>bluetooth</tt>. Dans un second temps il faut étudier la possibilité d'un radio-guidage par WiFi, les ordres étant transmis par un navigateur Web au serveur Web de la FoxBoard puis transmis au micro-contrôleur MindStorm par <tt>bluetooth</tt>. Vous aurez le choix de programmer votre robot avec le logiciel MindStorm ou avec un langage de bas niveau proche du langage C (voir la page web [http://www.eggwall.com/2011/08/lego-nxt-mindstorm-with-linux.html]).

Pour pouvoir utiliser votre robot dans une compétition de balle, il devra comporter un dispositif de lancer de balle commandable lui aussi à distance. Pour cela vous devrez modifier légérement le logiciel installé sur la FoxBoard.

Pour configurer la FoxBoard avec tout le matériel nécessaire, suivez les [[FoxBoard pour MindStorm 2012|instructions]]. Pour une description du système à obtenir suivez la [[FoxBoard MindStorm système 2013|flèche]].

<table border="1">
<tr> <th>Elèves</th> <th>Matériel</th> <th>Page</th> </tr>
<tr>
<td> Prénom Nom - Prénom Nom </td>
<td> Boite lego MindStorm, Téléphone Android, FoxBoard avec webcam, interface WiFi, convertisseur <tt>bluetooth</tt>, Boitier piles </td>
<td> [[Teleguide2013-1|Robot téléguidé 1]] </td>
</tr>
<tr>
<td> Prénom Nom - Prénom Nom </td>
<td> Boite lego MindStorm, Téléphone Android, FoxBoard avec webcam, interface WiFi, convertisseur <tt>bluetooth</tt>, Boitier piles </td>
<td> [[Teleguide2013-2|Robot téléguidé 2]] </td>
</tr>
</table>

= Intégration des fonctionnalités =

Pour l'année 2013/2014, il ne vous est demandé que de montrer le bon fonctionnement du dispositif ci-avant dont vous aurez choisi de vous occuper.

Cela dit dans l'idéal, une démonstration complète pourrait être présentée avec le travail supplémentaire décrit dans la suite.
* Les équipes des robots d'attaque et de défense fussionnent leurs robots pour en faire des compétiteurs complets.
* Les équipes ayant travaillé sur les cages réalisent un terrain et implantent dans les robots la réception des buts marqués.
* Les équipes des robots télécommandés organisent une compétition sur un terrain avec deux buts avec remontée automatique du score sur le dispositif de télécommande.

= Notation =

{| class="wikitable"
! Noms !! Rapport Wiki !! Soutenance vidéo !! Total
|-
|
|
|
|
|
|
|}