Différences entre versions de « Projet 5A 19 20 »
| Ligne 23 : | Ligne 23 : | ||
==Architecture logicielle== | ==Architecture logicielle== | ||
====Cahier des charges==== | ====Cahier des charges==== | ||
| − | + | Le robot doit être capable de: | |
| − | ** | + | * Se deplacer précisement |
| − | * | + | * Connaitre sa position |
| − | * | + | * Eviter/ne pas toucher des obstacles |
| − | * | + | * Utiliser ses actionneurs |
| + | |||
| + | Comment programmer? | ||
| + | * Transition du code Mbed vers STM32Cube pour plus de contrôle (débuggage entre autres). | ||
* Implementation d'un système de retour d'erreur, de log, afin de débugger efficacement | * Implementation d'un système de retour d'erreur, de log, afin de débugger efficacement | ||
** Fault model | ** Fault model | ||
| − | + | ** Log: affichage uart, raspberry pi, dans fichier? | |
| − | ** Log: affichage uart, dans fichier? | ||
| − | |||
====Contraintes==== | ====Contraintes==== | ||
* Utilisation de méthodes abordable pour des étudiants de 3 et 4ème année | * Utilisation de méthodes abordable pour des étudiants de 3 et 4ème année | ||
| − | ** | + | ** À t-on vraiment besoin d'un OS temps réel? |
** Utiliser du c++ basique et du c, pas de c++ avancé | ** Utiliser du c++ basique et du c, pas de c++ avancé | ||
* Compréhension et maintenabilité du code facile | * Compréhension et maintenabilité du code facile | ||
Version du 10 février 2020 à 13:46
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 logicielle
Cahier des charges
Le robot doit être capable de:
- Se deplacer précisement
- Connaitre sa position
- Eviter/ne pas toucher des obstacles
- Utiliser ses actionneurs
Comment programmer?
- Transition du code Mbed vers STM32Cube pour plus de contrôle (débuggage entre autres).
- Implementation d'un système de retour d'erreur, de log, afin de débugger efficacement
- Fault model
- Log: affichage uart, raspberry pi, dans fichier?
Contraintes
- Utilisation de méthodes abordable pour des étudiants de 3 et 4ème année
- À t-on vraiment besoin d'un OS temps réel?
- Utiliser du c++ basique et du c, 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 shunter le superviseur lors des matchs par exemple