L'objectif du projet de robotique est de programmer un robot capable de ramasser un maximum de palets sur un plateaux en un minimum de temps. Le programme devra être embarqué sur le robot. La forme des robots vous est imposée. L'évaluation consistera à opposer vos différents robots lors d'une compétition au bout de 12 semaines de préparation. Votre note de projet tiendra compte des évaluations hebdomadaires ainsi que des documents que vous devrez nous rendre. Le projet est à réaliser en binôme. Le détail du règlement de la compétition est donné ci-dessous. Que le meilleur binôme gagne !!

Au sein de votre binôme, vous êtes évalués à la fois de manière collective et de manière individuelle. Autrement dit, les membres d'un même groupe de projet peuvent avoir des notes différentes. 2 éléments permettent aux responsables de l'UE de déterminer votre note finale :

• Une note N sur 20 obtenue par :
  • la note collective sur 10 répartie comme suit :
    • 5 pts sur la méthodologie de mise en oeuvre du projet (planification, qualité des documents fournis, collaboration, etc.)
    • 5 pts sur l'aboutissement du projet (qualité de la réalisation par rapport aux objectifs)
  • une note individuelle répartie comme suit :
    • 5 pts pour la présentation orale et la réponse aux questions hebdomadaires
    • 5 pts pour vos compétences informatiques dans le cadre de ce projet
• Cette note sur pourra être modulée par l'appréciation donnée par les enseignants sur votre investissement personnel et votre apport au projet tout au long des 12 semaines.

En outre, un bonus sera attribué en fonction du classement à la compétition (cf. règlement ci-dessous). La somme des bonus ne pourra pas excéder 3 points.

Sauf mention contraire, les documents à rendre en cours de projet sont à déposer sur votre page wiki aux dates indiquées dans le planning du projet. La remise des documents avant les dates limites indiquées constitue une des éléments de notation de votre projet.

La production de documentation est une tâche importante du développement de logiciels. Il n’y a pas de logiciel de qualité sans une documentation de qualité. Dans le cadre de votre projet, nous vous demandons de rendre un certains nombre de documents relatifs à votre application. Les documents à déposer sur la plateforme Plenadis dans l'espace de votre équipe sont les suivants :

1. Le cahier des charges (à rendre semaine 3);
2. Le plan de développement (à rendre semaine 5);
3. Le plan de tests (à rendre semaine 11);
4. La documentation interne du code + code source (à rendre semaine 12).
5. Le rapport de projet (à rendre semaine 12);

Le cahier des charges est un document rassemblant les obligations et les éléments nécessaires pour définir un besoin et les principales contraintes à respecter pour le satisfaire. Le cahier des charges est un élément objectif qui permet à un client de choisir son fournisseur. Les rubriques spécifiques du cahier des charges sont les suivantes :

1. Introduction
   1. Contexte : Décrire brièvement l’environnement dans lequel s’inscrit le projet (stratégie, enjeux, domaine, etc.)
   2. Historique : Donner un bref historique du contexte dans lequel s’inscrit le projet
2. Description de la demande
   1. Les objectifs : Définir les résultats que le projet doit atteindre
   2. Produit du projet : Proposer une description générale de ce produit
   3. Les fonctions du produit : Lister et justifier les principales fonctionnalités du produit
3. Contraintes
   1. Contraintes de délais : Spécifier la date de livraison du produit et les éventuelles échéances intermédiaires
   2. Contraintes matérielles : Spécifier le matériel nécessaire au bon fonctionnement du produit
   3. Autres contraintes : Spécifier les éventuelles contraintes à prendre en compte dans le cadre du projet (normes techniques, clauses juridiques, etc.)
4. Déroulement du projet
   1. Planification : Représenter les grandes phases du projet et les étapes principales
   2. Ressources : Lister les ressources humaines et matérielles
   3. Organisation : Décrire l’ensemble des activités introduites dans l’organigramme des tâches de la gestion de projet (Décomposition en tâches, Structure des équipes)

Modèle de document : Modèle de cahier des charges

Il vous est demandé de fournir une documentation interne de votre application. Cette documentation vise à faciliter la maintenance de votre application par un tiers. Celle-ci peut prendre plusieurs formes en fonction du langage utilisé pour l’implantation, e.g., javadoc pour java, oxygène pour C++.
Toutefois, un document générer automatiquement à l'aide de ces outils est insuffisant.

Elle doit aussi contenir une description issue de l'analyse détaillée du projet :

• Description des modules ou des classes. Pour chaque module :
  1. Rappel des objectifs du module
  2. Relations d’utilisation avec d’autres modules
  3. Lister les modules utilisés par ce module et ceux utilisant ce module
  4. Définitions de types : Lister les définitions de type ou les attributs de l’objet associé au module
  5. Procédures externes : Lister les procédures visibles par les modules utilisant ce module
  6. Variables externes : Lister les variables visibles par les modules utilisant ce module

Le plan de tests est très important dans la mesure où il garantit que votre logiciel respecte le cahier des charges. Les rubriques suivantes doivent être présentes:

1. Présenter un ensemble de tests ou recettes ainsi que leur ordonnancement
2. Description des tests d’intégration. Pour chaque test :
   1. Description du test : Décrire le test de façon externe
   2. But du test :Décrire ce que prouve le test
   3. Principe de réalisation : Décrire la procédure de test ainsi que les paramètres et
3. Description des tests unitaires : Pour chaque module/classe :
   1. Mise en œuvre
   2. Pour chaque jeu d’essai : Données d’entrées, résultats attendues, critère d’évaluation

• Les tests fonctionnels du plan de test sont-ils les mêmes que ceux du cahier de recette ?
  En fait, il ne s'agit pas tout à fait de la même chose, et on s'attend à ce que les tests fonctionnels du plan de test soient au moins aussi nombreux que les tests qui figurent dans le cahier de recette.
  En effet, le cahier de recette permet de vérifier que le fonctionnement de l'application correspond de manière satisfaisante à ce qui est attendu par la maitrise d'ouvrage (le “client”) afin de permettre sa validation. L'ensemble des tests qu'il contient doit donc être compris comme un minimum.
  Tandis que les tests décrits dans le plan de test doivent couvrir l'ensemble des fonctionnalités de l'application conçue. Il est raisonnable de considérer qu'au cours de la conception de l'application, la maîtrise d'oeuvre ait pris en considération des situations ou des contraintes qui n'avaient pas été envisagées lors de l'élaboration du cahier des charges, ni lors de l'élaboration du cahier de recette. Il est évidemment indispensable que le plan de test en tienne compte. Il en est de même lorsque le périmètre fonctionnel de l'application s'avère être plus vaste que celui qui a été défini dans le cahier des charges.

Modèle de document : Modèle de plan de test

Le rapport du projet est un document qui peut contenir toutes les informations ne figurant pas dans les autres documents demandés.

Pour cette compétition, les différents robots impliqués dans la compétition devront résoudre le problème du ramasseur de balles. La compétition comporte 2 ligues :

1. La ligue Mindstorms Solo, au sein de laquelle deux robots s’affrontent lors d’un match pour déposer le plus de palets possibles dans la zone d’en-but de l’adversaire.
2. La ligue Mindstorms Duo, au sein de laquelle quatre robots s’affrontent en équipes de deux pour déposer le plus de palets possibles dans la zone d’en-but de l’adversaire.

Les enseignants en charge du module se réservent le droit de modifier ce règlement à tout moment de la compétition s’il juge cela nécessaire afin de faire respecter l’esprit de cette rencontre. Au cas où une modification du règlement interviendrait, les modifications apportées seront affichées et le jury organisera une réunion pour informer tous les participants encore en jeu. Le jury est souverain et ses décisions sont sans appel. Il peut notamment décider de pénaliser un robot ou une équipe qui présenterait un comportement contraire à l’esprit de cette compétition, même si la faute reprochée n’est pas explicitement prévue par ce règlement.

Les étudiants ne conçoivent pas les robots, les plans sont fournis à l'article 8. du règlement. Les plans ne peuvent pas être modifiés par les équipes. Les étudiants programment les robots et les mettent au point pour la compétition. Pour les aider dans cette tâche, les enseignants peuvent mettre à disposition les outils logiciels standards de leurs choix. En aucun cas, les modules matériels du robot ne pourront être des modules spécialisés pour la compétition.

Le compétition est organisé en cinq phases : homologation, qualification, phase finale et remise des prix (bonus sur la note finale).

Pour participer aux épreuves, un robot doit être homologué. L’homologation se déroule en deux étapes.

3.1.2. - Etape 1 : homologation par le jury, homologation des caractéristiques du robot
Le jury vérifiera que le robot est conforme aux plans fournis pour la construction du robot.

3.1.2. - Etape 2 : test d’homologation, homologation sur l’aire de jeu
Le robot doit être capable (en moins de 3 minutes), au choix de :

• se déplacer de son point de départ à la zone d’en-but adverse
• se saisir d’une balle/ d’un palet placé au centre du terrain et de la déposer dans la zone d’en-but.

Le robot ne sera pas homologué s’il ne réussit pas au moins l’un de ces test avant la fin de la période d’homologation. Il ne pourra donc pas participer à la compétition.

3.2.1. - Règle d’engagement
Tous les robots homologués participent à la première phase du concours appelée phase de qualification.

3.2.2. - Organisation de la phase de qualification
Au cours de la phase de qualification, chaque équipe rencontre une fois toutes les équipes adverses qualifiées, au sein d’une même poule. Chaque match comprend deux manches d’une durée de 5 minutes pour les toutes les ligues. Le temps de pause entre deux manches est de 5 minutes.

3.2.2. - Décompte des points
Au cours de chaque manche, les robots marquent des points suivant les conditions énoncées dans les articles de la section 4 du présent règlement. Le score est final est la somme des points obtenus dans chaque manche.

3.2.3. - Classement
Les points des rencontres de chaque robot sont additionnés. Les robots sont classés par ordre décroissants de points obtenus. En fonction de la ligue, les 2 ou 4 premiers de ce classement sont qualifiés pour la phase d’élimination directe. En cas d'équipes ex-eaquo, l'équipe sélectionnée sera celle dont le temps cumulé de premières marques (sur tous ses matchs) est le plus court.

3.3.1. - Règle d’engagement
Dans la deuxième phase, appelée phase d’élimination directe, seules les équipes qualifiées participent.

3.3.2. - Organisation de la phase d’élimination directe
Cette phase comprend cinq rencontres réparties en deux matchs de demi-finale, une petite finale et une grande finale. Pour passer au niveau suivant, une équipe doit remporter son match. La petite finale permet d’établir le classement des 4 premières équipes.

3.3.3. - Déroulement du match
Chaque match comprend trois manches de 5 minutes avec des pauses intermédiaire de 5 minutes. Au cours d’une pause, une équipé peut changer le programme de son robot.

3.3.4. - Élimination aux nombres de manches gagnées
A la fin de chaque manche, l’équipe qui totalise le plus de points gagne. L’équipe qui gagne 2 manches gagne le match.

3.3.5. - Cas des équipes ex-aequo
En cas de score identique, l’équipe victorieuse sera celle qui aura marqué en premier sur l’ensemble du match.

Les compétiteurs qui recevront un prix seront les 3 premiers de chaque ligue :

1. Médailles d’or + 3 points de bonus
2. Médailles d’argent + 2 points de bonus
3. Médailles de bronze + 1 points de bonus

Pour chaque match, un arbitre est désigné par le jury de la compétition pour s’assurer du bon respect du présent règlement. L’arbitre doit:

1. vérifier le bon état de l’aire de jeu.
2. vérifier la conformité des robots avant le coup d’envoi.
3. garantir le respect des règles de la compétition.
4. comptabiliser les points marqués par les robots (voir article 4.4.4 & 4.4.5)
5. Après avoir vérifier que les conditions initiales du match étaient bien réunies, l’arbitre autorise le début du match et donne le coup d’envoi du match. Le camp de l’équipe est décidé par l’arbitre de manière aléatoire. A chaque manche, les équipes changent de camp. En cas d’anomalie au démarrage d’un des robots, l’arbitre peut faire recommencer le match. Cette décision ne peut intervenir qu’une fois par manche, dans les 30 premières secondes. Au cours du match, l’arbitre peut suspendre le match s’il constate un problème sérieux. A la fin de chaque match, il siffle le coup de sifflet final, puis annonce le nom du gagnant ainsi que le score obtenu. Chaque équipe doit prendre soin de respecter le règlement de la compétition et les décisions de l’arbitre. Tout manquement, pourra entraîner une pénalité.

Seuls deux des membres d’une équipe sont autorisés à assister au déroulement du match dans la zone de proximité du terrain. De même, ils sont les seuls autorisés à intervenir sur les robots pour des opérations de maintenance ou pour modifier la stratégie de jeu et ce uniquement lors des pauses entre les manches.

Les robots de chaque équipe doivent avoir une couleur spécifique. Il sera mis à disposition des équipes un système de pastilles autocollantes pour différencier les robots. L’arbitre vérifiera que les robots en sont pourvus. Les robots devront être autonomes, i.e., que les programmes devront être embarqués. Autrement dit, il n’est pas autorisé de piloter à distance les robots ou d’exécuter son programme de manière déportée. Tout manquement à règle entraînera l’exclusion immédiate de la compétition.

4.4.1. - Positions initiales des robots
Les robots sont positionnés au choix par les équipes sur les positions notées R sur la figure 1 dans leur camp. Chaque équipe doit annoncer à l’arbitre la position de départ de son robot (ou ses robots dans le cas de la ligue Mindstorms Duo) avant le début de la manche ou de la reprise (après une interruption de jeu).

4.4.2. - Positions initiales des balles
Avant le coup de sifflet, l’arbitre place neuf balles ou neuf palets sur les intersections de lignes (cf. figure 1).

4.4.3. - Début et fin d’une manche
Les robots doivent être démarrés à distance en bluetooth ou en WIFI par l'intermédiaire d’un ordinateur portable. L’arbitre vérifiera que le programme s’exécute sur le robot et n’est pas déporté sur un ordinateur portable. A l’issue du temps réglementaire, l’arbitre siffle la fin de la manche :

• Il arrête de comptabiliser les points,
• Il procède au calcul du score de chaque équipe pour la manche.

4.4.4.- Calcul du score pour les ligues Mindstorms Solo et Duo

Le calcul des scores s’effectue comme suit :

• 5 points pour chaque palet placé dans la zone d’en-but adverse,
• 3 points de bonus pour l’équipe ayant marqué en premier,
• 2 points pour le robot ayant un palet en sa possession a la fin de la manche.

Il est interdit aux robots de pousser les palets dans l’en-but. Seules les balles saisies puis déposées dans l’en-but adverse sont comptabilisées.

4.4.5. - Autonomie
Le robot est autonome. Il ne reçoit aucune information lors du déroulement d’un match. Un robot qui exploiterait des informations qui lui seraient transmises serait immédiatement disqualifié par l’arbitre.

4.4.6. - Apprentissage autonome
Un robot peut exploiter de façon autonome ses expériences des précédents match à condition que cet apprentissage soit réalisé de manière logicielle.

4.4.7. - Changement des batteries
Les batteries peuvent être remplacées à la fin de chaque manche ou au cours des temps morts.

Si un robot ne répond plus il est considéré comme perdu. Dans les 30 premières secondes de la manche, l’équipe responsable du robot peut alors demander un temps mort afin de remettre en état de fonctionnement le robot. Le temps mort accordé est fixé à 5 minutes maximum. Il ne pourra pas être demandé plus de deux temps morts par match. Pour les phases finales, aucun temps mort ne sera autorisé.

Les collisions entre robots sont à éviter afin de limiter les risques de détérioration ou de casse. Toutefois, les robots pourront être utilisés pour bloquer l’accès aux balles ou bloquer l’accès à la zone d’en-but.

Le terrain mesure 3m x 2m. Il est entouré d’une bordure rigide d’une hauteur de 15cm (cf. Figure 1 et Figure 2). Les R représentent les positions initiales des robots.

Figure 1: Schéma de principe du terrain.

Les zones du terrain sont délimitées par des lignes de couleurs. La couleur de fond du terrain sera gris clair. Les lignes blanches marquent la limite des en-buts. Les lignes vertes et bleues délimitent respectivement l’Est et l’Ouest du terrain tandis que les lignes rouges et jaunes le Nord et le Sud. Les lignes noires partagent le terrain en son milieu de l’Est à l’Ouest et du Nord au Sud. Les balles à ramasser seront positionnées aux intersection des lignes.

La profondeur de l’en-but est de 30 cm et chaque zone du terrain délimitée par les lignes de couleur a une dimension de 50cm x 60cm.

Figure 2: Exemple de terrain sans les accessoires

Les robots LEGO Mindstorms sont des tribots (cf. figure 3). Le plan du robot est disponible ici. Les pinces sont actionnables par un moteur. Les plans sont fournis en annexe du règlement. Ses robots possèdent les capteurs et actionneurs suivants:

• Capteur tactile : Réagit à une pression.
• Capteurs de son : Mesure l'intensité sonore en décibels.
• Capteurs à ultrasons : Permet de détecter les objets et de mesurer les distances (en centimètres ou en pouces)
• Les servomoteurs peuvent servir de capteur de rotations, mais présentent une résistance au mouvement.
• Capteur de couleurs : Distingue différentes couleurs

La brique programmable a les caractéristiques suivantes:

• Microprocesseur 32 bit ARM7 d'ATMEL,
• Fonction Bluetooth (connexion à d'autres NXT ou à un PC et possibilité de contrôler le NXT avec un téléphone portable ou un autre appareil Bluetooth),
• 1 port USB 2.0 (12 Mbps),
• 4 ports d'entrée pour la connexion des capteurs nommés 1, 2, 3 et 4,
• 3 ports de sortie pour les moteurs nommés A, B et C,
• Écran à cristaux liquides 100 × 64 pixels,
• haut-parleur intégré (qualité sonore 8 kHz - 8 bit - échantillonnage 2-16 kHz),
• Alimentation : 6 piles AA (1,5 V) ; une batterie 9 V est commercialisée par LEGO.
• Dimensions : 112 × 72 × 40 mm

Fig. 3: Tribot légo mindstorms