PersyCup: Difference between revisions

From air
Jump to navigation Jump to search
 
(35 intermediate revisions by the same user not shown)
Line 27: Line 27:
*Installation de [https://sourceforge.net/p/lejos/wiki/Installing%20leJOS/ LEJOS for EV3]
*Installation de [https://sourceforge.net/p/lejos/wiki/Installing%20leJOS/ LEJOS for EV3]


'''Problème rencontré :
==='''Problème rencontré===
'''
'''
*Impossible de détecter la brique du robot par câble USB
*Impossible de détecter la brique du robot par câble USB


'''Solution :
==='''Solution avancée===
'''
'''
*Détecter la brique du robot par Bluetooth
*Détecter la brique du robot par Bluetooth
Line 45: Line 45:
*La vitesse du robot est réglable directement depuis le programme
*La vitesse du robot est réglable directement depuis le programme
*Le temps de processing pour une action est non-négligable devant la réactivité souhaitée
*Le temps de processing pour une action est non-négligable devant la réactivité souhaitée
*Le capteur ultrasonique permet uniquement de donner la distance séparant le robot d'un objet s'il y en a un. L'objet est détecté à partir d'une distance de 0.37m environ (pousser ces tests jusqu'au bout)
*Le capteur ultrasonique permet uniquement de donner la distance séparant le robot d'un objet s'il y en a un.
*S'il y en a un, l'objet est détecté à partir d'une distance de 0.37m environ (pousser ces tests jusqu'au bout).
*Le capteur de contact permet de détecter une collision avec un obstacle (palets à ramasser).
*S'il y en a un, la vitesse détermine si le capteur enclenche le mécanisme de détection de l'obstacle. (IMPORTANT)


Il faut à tout prix trouver un compromis pour optimiser les actions du robot : Problème du '''temps réel'''
Il faut trouver un compromis sur la vitesse des déplacements pour optimiser les actions du robot : Problème du '''temps réel'''


== Semaine 5 (8 février - 14 février) ==
== Semaine 5 (8 février - 14 février) ==
Line 54: Line 57:
*Obtention du code de classes de base communes à toutes les équipes
*Obtention du code de classes de base communes à toutes les équipes
*Ajout possible d'une caméra dans les règles du jeu : elle donne la position des palets à ramasser
*Ajout possible d'une caméra dans les règles du jeu : elle donne la position des palets à ramasser

==='''Détails===
'''
*Le terrain est effectivement quadrillés en lignes de couleurs

Parmi les programmes donnés par M. MAISONNASSE, il y a :
* un suivi de ligne de couleur
* un programme de reconnaissance de couleur


== Semaine 6 (15 février - 21 février) ==
== Semaine 6 (15 février - 21 février) ==
Line 60: Line 71:
*Test des classes et fonctions données la semaine dernière sur le terrain
*Test des classes et fonctions données la semaine dernière sur le terrain
*Début du développement de la stratégie
*Début du développement de la stratégie

== Semaine 7 (29 février - 6 mars) ==

*La caméra place les coordonnées des palets dans un repère orthonormé

==='''Problème rencontré'''===
*Le robot se déplace dans un repère polaire en fonction d'une distance et d'un angle de rotation.

==='''Solution avancée'''===
*Créer des fonctions qui permettent de changer de repère. Le robot pourra donc se déplacer dans un repère orthonormé.

== Semaine 8 (7 mars- 13 mars) ==

*Période de tests

==='''Problème rencontré'''===
*La caméra n'est pas encore mise à disposition

==='''Solution avancée'''===
*On simule des coordonnées statiques pour tester les fonctions suivantes :
**Récupérer les coordonnées des palets
**Calculer la position du robot sur le repère orthonormé
**Calculer la distance minimale le robot et la liste de palets
**Diriger le robot vers ce palet

== Semaine 9 (14 mars- 20 mars) ==

*La période de tests continue

== Semaine 10 (21 mars- 27 mars) ==

*Caméra mise à disposition à partir de la semaine prochaine
*Conception d'un automate pour la stratégie

== Semaine 11 (28 mars- 3 avril) ==

*Ecriture du rapport
*Finition de la stratégie

===Remarque===
*La stratégie est souvent remise en cause au fur et à mesure qu'on la conçoit

== Semaine 12 (4 avril- 10 avril) ==

Diapo : https://drive.google.com/file/d/0B40ufTGNlbmLODZLaVVDMlpGTXc/view?usp=sharing


== Design Pattern ==
== Design Pattern ==

Latest revision as of 05:55, 7 April 2016

Groupe

Elèves

  • Bin SUN
  • Taqqyeddine ZEGAOUI
  • Jordan ELLAPIN

Responsables

  • DONSEZ Didier
  • MAISONASSE Stéphane

Semaine 1 (11 janvier - 17 janvier)

  • Découverte du tournoi et de ses règles
  • Aucun robot à disposition pour le moment

Semaine 2 (18 janvier - 24 janvier)

  • Prise de contact avec M. MAISONNASSE
  • Acquisition du robot LEGO MINDSTORM

Semaine 3 (25 janvier - 31 janvier)

Problème rencontré

  • Impossible de détecter la brique du robot par câble USB

Solution avancée

  • Détecter la brique du robot par Bluetooth

Semaine 4 (1er février - 7 février)

  • Tests des différents capteurs du robot
  • Tests de fonctions de l'environnement sur le robot

Remarques :

  • La vitesse du robot est réglable directement depuis le programme
  • Le temps de processing pour une action est non-négligable devant la réactivité souhaitée
  • Le capteur ultrasonique permet uniquement de donner la distance séparant le robot d'un objet s'il y en a un.
  • S'il y en a un, l'objet est détecté à partir d'une distance de 0.37m environ (pousser ces tests jusqu'au bout).
  • Le capteur de contact permet de détecter une collision avec un obstacle (palets à ramasser).
  • S'il y en a un, la vitesse détermine si le capteur enclenche le mécanisme de détection de l'obstacle. (IMPORTANT)
Il faut trouver un compromis sur la vitesse des déplacements pour optimiser les actions du robot : Problème du temps réel

Semaine 5 (8 février - 14 février)

  • Premier accès au terrain de match à l'IMAG
  • Obtention du code de classes de base communes à toutes les équipes
  • Ajout possible d'une caméra dans les règles du jeu : elle donne la position des palets à ramasser

Détails

  • Le terrain est effectivement quadrillés en lignes de couleurs

Parmi les programmes donnés par M. MAISONNASSE, il y a :

  • un suivi de ligne de couleur
  • un programme de reconnaissance de couleur

Semaine 6 (15 février - 21 février)

  • Confirmation de l'ajout de la caméra
  • Test des classes et fonctions données la semaine dernière sur le terrain
  • Début du développement de la stratégie

Semaine 7 (29 février - 6 mars)

  • La caméra place les coordonnées des palets dans un repère orthonormé

Problème rencontré

  • Le robot se déplace dans un repère polaire en fonction d'une distance et d'un angle de rotation.

Solution avancée

  • Créer des fonctions qui permettent de changer de repère. Le robot pourra donc se déplacer dans un repère orthonormé.

Semaine 8 (7 mars- 13 mars)

  • Période de tests

Problème rencontré

  • La caméra n'est pas encore mise à disposition

Solution avancée

  • On simule des coordonnées statiques pour tester les fonctions suivantes :
    • Récupérer les coordonnées des palets
    • Calculer la position du robot sur le repère orthonormé
    • Calculer la distance minimale le robot et la liste de palets
    • Diriger le robot vers ce palet

Semaine 9 (14 mars- 20 mars)

  • La période de tests continue

Semaine 10 (21 mars- 27 mars)

  • Caméra mise à disposition à partir de la semaine prochaine
  • Conception d'un automate pour la stratégie

Semaine 11 (28 mars- 3 avril)

  • Ecriture du rapport
  • Finition de la stratégie

Remarque

  • La stratégie est souvent remise en cause au fur et à mesure qu'on la conçoit

Semaine 12 (4 avril- 10 avril)

Diapo : https://drive.google.com/file/d/0B40ufTGNlbmLODZLaVVDMlpGTXc/view?usp=sharing

Design Pattern

Modèles GoF:

  • State (machine à états)
  • Singleton (une ou peu d'instances par classe)

Testing pattern