Différences entre versions de « Projet 5A 19 20 »

De Polybot Grenoble
Sauter à la navigation Sauter à la recherche
 
(19 versions intermédiaires par le même utilisateur non affichées)
Ligne 5 : Ligne 5 :
 
La volonté que nous avons, à travers ce projet, est de concevoir une architecture logicielle et matérielle aux robots développé par Polybot. Si le temps nous le permet, nous souhaitons aussi developper un superviseur. Ce superviseur serait exécuté sur un ordinateur et communiquerait avec les robots dans un but de monitoring.
 
La volonté que nous avons, à travers ce projet, est de concevoir une architecture logicielle et matérielle aux robots développé par Polybot. Si le temps nous le permet, nous souhaitons aussi developper un superviseur. Ce superviseur serait exécuté sur un ordinateur et communiquerait avec les robots dans un but de monitoring.
  
==Participant==
+
==Participants==
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
Ligne 14 : Ligne 14 :
 
| Justin Ruaux || IESE-5
 
| Justin Ruaux || IESE-5
 
|}
 
|}
 +
 +
Tuteur: Sylvain Toru
  
 
==Schéma==
 
==Schéma==
 +
[[Fichier:Architecture projet5A.png|1000px|architecture du projet]]
 +
<br>
 +
[https://github.com/polybot-grenoble/projet_5A/blob/master/archi.pdf Schéma de l'architecture]
  
[https://github.com/polybot-grenoble/projet_5A/blob/master/schema_archi.pdf Schéma de l'architecture]
+
==Principe technique==
 +
 
 +
==Travaux réalisés==
 +
* [[Guide STM32CubeIDE|Guide STM32Cube]]
 +
* [[Guide QT|Guide QT]]
 +
* [[Projet_5A_19_20/Superviseur|Superviseur]]
 +
* [[Projet_5A_19_20/Logiciel Robot|Logiciel Robot]]
 +
* [[Projet_5A_19_20/Gateway|Gateway]]
  
 
==Architecture logicielle==
 
==Architecture logicielle==
 
====Cahier des charges====
 
====Cahier des charges====
* Système distribué: une node centrale controle les autres modules
+
Le robot doit être capable de:
** Exemple de modules présents dans les robots: module capteur, module asservissement, module actionneurs...
+
* Se déplacer précisement
** La node principale doit être puissante et ne doit pas attendre inutilement
+
* Connaître sa position
** Node principale: microC, microP ? OS / Sans OS ?
+
* Éviter les obstacles
* Définition d'un protocole de communication commun entre modules
+
* Utiliser ses actionneurs
* Implementation d'un système de retour d'erreur, de log, afin de débugger efficacement
+
 
** Fault model
+
Comment programmer?
** Clock synchronization, timestamp...
+
* Transition du code Mbed vers STM32Cube pour plus de contrôle (débuggage entre autres).
** Log: affichage uart, dans fichier?
+
* Implémentation d'un système de retour d'erreur, de log, afin de débugger efficacement.
* Système modulaire: définition d'API afin de pouvoir remplacer des modules sans devoir redevelopper tout le système
+
** Définition d'un modèle de faute.
 +
** Historique: envoie des logs en UART vers la Raspberry Pi.
  
 
====Contraintes====
 
====Contraintes====
* Utilisation de méthodes abordable pour des étudiants de 3 et 4ème année
+
* Utilisation de méthodes abordables pour des étudiants de 3 et 4ème année
* Compréhension et maintenabilité du code facile
+
** À t-on vraiment besoin d'un OS temps réel?
 +
** Utilisation de C et C++ basique, pas de C++ avancé.
 +
* Compréhension et maintenabilité du code facile.
 +
** Code structuré et documenté.
  
 
==Superviseur==
 
==Superviseur==
Ligne 44 : Ligne 60 :
  
 
====Contraintes====
 
====Contraintes====
* Les robots ne doivent pas dépendre du superviseur: ils doivent rester autonome et il doit être possible de shunter le superviseur lors des matchs par exemple
+
* Les robots ne doivent pas dépendre du superviseur: ils doivent rester autonome et il doit être possible de désactiver le superviseur lors des matchs par exemple.
  
 
==Suivi de projet==
 
==Suivi de projet==
 
* [[Projet_5A_19_20/Semaine 1|Semaine 1]]
 
* [[Projet_5A_19_20/Semaine 1|Semaine 1]]
 
* [[Projet_5A_19_20/Semaine 2|Semaine 2]]
 
* [[Projet_5A_19_20/Semaine 2|Semaine 2]]
 +
* [[Projet_5A_19_20/Semaine 3|Semaine 3]]
 +
* [[Projet_5A_19_20/Semaine 4|Semaine 4]]
 +
* [[Projet_5A_19_20/Semaine 5|Semaine 5]]
 +
* [[Projet_5A_19_20/Semaine 6|Semaine 6]]

Version actuelle datée du 27 mars 2020 à 15:45

Présentation

Depuis plusieurs années consécutives, un des points faibles des robots développé par Polybot dans le cadre de la coupe de France de robotique est la partie programmation. En effet, une grande partie des efforts étaient concentrée sur des réalisations mécaniques et électronique et la certitude que la partie programmation pourrait se faire « en dernière minutes » était présente. L’expérience nous a montré que non.

La volonté que nous avons, à travers ce projet, est de concevoir une architecture logicielle et matérielle aux robots développé par Polybot. Si le temps nous le permet, nous souhaitons aussi developper un superviseur. Ce superviseur serait exécuté sur un ordinateur et communiquerait avec les robots dans un but de monitoring.

Participants

Prénom & Nom Filière
Charles Blanchard IESE-5
Justin Ruaux IESE-5

Tuteur: Sylvain Toru

Schéma

architecture du projet
Schéma de l'architecture

Principe technique

Travaux réalisés

Architecture logicielle

Cahier des charges

Le robot doit être capable de:

  • Se déplacer précisement
  • Connaître sa position
  • Éviter les obstacles
  • Utiliser ses actionneurs

Comment programmer?

  • Transition du code Mbed vers STM32Cube pour plus de contrôle (débuggage entre autres).
  • Implémentation d'un système de retour d'erreur, de log, afin de débugger efficacement.
    • Définition d'un modèle de faute.
    • Historique: envoie des logs en UART vers la Raspberry Pi.

Contraintes

  • Utilisation de méthodes abordables pour des étudiants de 3 et 4ème année
    • À t-on vraiment besoin d'un OS temps réel?
    • Utilisation de C et C++ basique, pas de C++ avancé.
  • Compréhension et maintenabilité du code facile.
    • Code structuré et documenté.

Superviseur

Cahier des charges

  • Affichage des positions des robots sur une carte
  • Retour des erreurs et des logs des robots
  • Mode automatique et mode manuel pour les robots
  • Envoie de commande aux robots: start/stop

Contraintes

  • Les robots ne doivent pas dépendre du superviseur: ils doivent rester autonome et il doit être possible de désactiver le superviseur lors des matchs par exemple.

Suivi de projet