Projet 5A 2020 2021
Dans le cadre de notre projet de fin d'étude, nous avons choisi de travailler sur l'amélioration des robots de Polybot, le club de robotique de Polytech Grenoble, dans l'objectif de participer à la Coupe de France de Robotique 2021.
Après réflexion et discussion avec les autres groupes et notre tuteur, nous avons décidé d'apporter des améliorations aux robots via deux sous-projets que vous découvrirez plus en détail dans la suite de ce rapport : la création d'une nouvelle carte de puissance et l'affichage des données en temps-réel concernant le robot.
Présentation du projet
La coupe de France de robotique
La Coupe de France de Robotique est un défi s’adressant à n’importe quelle équipe de jeune s’intéressant à la robotique. Les participants doivent concevoir puis réaliser 2 robots autonomes, conformes au règlement et aptes à participer aux matchs organisés. Chaque match oppose les 2 robots d'un groupe contre les 2 robots d'un autre adverse. Le but pour chaque robot est de réaliser différentes actions afin de récolter plus de points que l’adversaire.
Cette année, la coupe de France de robotique aura lieu à la Roche-Sur-Yon en Juillet 2021. Le thème de cette année est “Sail the World”. Le terrain représentera une carte du monde sur laquelle se trouveront des phares, des chenaux, des gobelets (représentant des bouées), des drapeaux ou encore d’autres éléments avec lesquels pourra interagir notre robot pour gagner des points.
Présentation du robot principal
Deux robots sont actuellement en préparation pour participer à la coupe de France de robotique 2021. Mais pour l’instant, seul le premier robot est déjà à un stade avancé. Pour ce projet on se concentrera donc principalement sur ce premier robot même si la plupart de nos modifications seront applicables sur le second robot quand il sera construit.
Composants du robot
Le robot principal est composé de :
- 2 moteurs
- 2 encodeurs
- Stepper (moteurs pas-à-pas)
- Servomoteurs (non utilisés pour le moment)
- Carte STM32 F446 Nucleo-64
Fonctionnement du robot
Comme nous l'avons mentionné plus haut, le robot devra interagir avec son environnement.
On pourra par exemple demander lui demander de :
- Ramasser des gobelets
- Activer les phares
- Relever les drapeaux
- Revenir à sa base
Les moteurs permettent les déplacements du robot via la rotation de ses 2 roues motrices. Les encodeurs permettent de déterminer le nombre de tours qu'a effectué chacune des roues, nous pourrons ainsi en déduire la position du robot ainsi que sa vitesse.
Les servomoteurs ne sont pas utilisés pour le moment.
Enfin, le microcontrôleur STM32 nous permet de gérer le fonctionnement de robot. En effet, celui ci va exécuter le programme mis en mémoire qui envoie des consignes pour gérer le comportement de tous les composants reliés à la STM32.
Présentation de notre projet
Objectifs
Cette année, nous avons choisi de travailler sur 2 sous-projets :
- Projet 1 : Réalisation d'une carte de puissance pour les robots
- Projet 2 : Récupération et affichage des informations concernant le fonctionnement du robot, à distance
L'objectif du projet 1 est de réaliser une carte de puissance afin de protéger la batterie et d'avoir une alimentation stable. On devra également prévoir le cas où l'on ajoute une carte Raspberry sur le robot. En effet, la Raspberry nécessite une alimentation continue tandis que la STM32 non. Florian et Flavien s'occuperont de cette partie du projet.
L'objectif du projet 2 est de récupérer des données sur le bon fonctionnement du robot (coordonnées, état, tension de la batterie...). Nous allons donc choisir un mode de communication fiable nous permettant d'afficher toutes ces données sur un ordinateur, une tablette ou un smartphone. Si nous avons le temps, nous développerons peut-être une application permettant de se connecter au robot et d'afficher les informations recueillies. Cette application pourrait également servir à connecter les autres robots (actuels ou futurs) de Polybot. Camille et Valentin s'occuperont de cette partie du projet.
Participants
| Prénom & Nom | Filière |
|---|---|
| Camille Langrand | IESE-5 |
| Flavien Mougeot | IESE-5 |
| Florian Jacquin | IESE-5 |
| Valentin Blumert | IESE-5 |
Tuteur: Sylvain Toru
Organisation de notre équipe
Nous étions donc 4 pour ce projet. Nous nous sommes donc répartis le projet en 2 sous projets (présentés ci-dessus) et nous avons travaillé en binôme sur chacun d'entre eux. Nous avons ainsi travaillé pendant environ 7 semaines environ dans les locaux de Polybot la plupart du temps. Nous avons fait très peu de télétravail du fait du matériel nécessaire.
Pour l'organisation du projet, nous avons utilisé plusieurs applications, notamment :
- Google Drive : pour le partage de fichiers
- Messenger : pour la communication écrite
- GitLab : pour le partage de codes
- Wiki : pour la rédaction de notre avancement sur le projet
Afin d'avancer efficacement, nous avons dès le début réfléchi aux différentes étapes qui allaient constituer notre projet. Cela nous a permis de voir à peu près la quantité de travail à réaliser. Une fois la liste établie, nous avons pu créer un diagramme de Gantt afin de pouvoir visualiser notre avancement au fil des séances.
Projet 1 : Carte de Puissance
Le but de ce projet est de réaliser une carte d’alimentation polyvalente qui pourra s’adapter sur les deux robots. Le but de cette carte est de fournir des alimentations stables, tout en protégeant la batterie contre la décharge abusive, et d’isoler aussi la Raspberry contre les arrêts d’urgence qui l'endommagent.
Cahier des charges
.png)
Les circuits de puissance:
- 5V (200mA max)
- STM32L432 (mini STM)
- 5V (4A max)
- STM32 (0.5A max)
- Servo (2.5A max)
- 5.2V (2A max)
- Raspberry
- 12V (4A max)
- Moteur pas à pas
- Moteurs
- Connecté en direct sur la batterie via le contrôleur
Tensions de coupure:
On veut avoir plusieurs seuils qui déclenchent plusieurs avertissements:
- Batterie à 40%:
- Une LED commence à clignoter
- Batterie à 30%:
- La LED continue de clignoter
- Le buzzer commence à faire du bruit
- Batterie à 20%:
- Les circuits moteur, 12V et 5V sont coupés
- Batterie à 10%:
- Coupe du circuit d'alimentation de Raspberry, puisque la charge de la batterie devient critique
Réalisation
Comme vu plus haut, on part sur une solution de protection et d'alimentation gérée et coupée par une STM32. Nous allons voir ici comment nous coupons l'alimentation dans les cas de batterie faible.
Hardware
Pour cette partie Hardware, on peut voir le schéma en entier de cette carte ci-dessous:
Circuit relais
Nous optons pour une solution de coupure à base de relais normalement ouverts. Ils seront pilotés par des transistors NMOS, et reliés à la tension 5V du µC comme on peut le voir sur le schéma ci-dessous.
Le relais sur cette image n'est pas le relais utilisé (on utilise le relais HF118F)
Ces relais ont une résistance de 113 ohm et ont une tension de bobine de 5V. Donc ces transistors sont dimensionnés pour faire passer du 50mA dans la bobine du relais. On choisit alors de commander des NMOS CMS (boîtier SOT-23), pour prendre moins de place, c'est plus joli et ça rajoute un peu de challenge pour souder.
Bus CAN
On aimerait envoyer la tension de la batterie sur l'application du deuxième projet. Pour cela, il faut communiquer entre notre STM et la STM principale du robot, grâce à un bus CAN (Controller Area Network). On utilise un chip SN65HVD230, que nous câblons comme on peut le voir sur le schéma à droite.
Convertisseurs de tension
Pour les convertisseurs de tension, on choisit d'utiliser les convertisseurs déjà utilisés sur l'ancienne carte, et qui peuvent fournir 12V 4A pour l'un, et 5V 4A pour l'autre. Les références:
- 12V: JCK5012S12
- 5V: JCK2012S05
Pour alimenter la Raspberry, il nous fallait la possibilité de pouvoir régler la tension précisément. En effet, si on l'alimente avec une tension juste en dessous de 5V, la Raspberry va fonctionner mais avec une fréquence grandement réduite. Ainsi, il est conseillé de lui fournir du 5.2V pour avoir un fonctionnement optimal. On a donc choisi d'utiliser un petit module buck réglable grâce à un petit potentiomètre. Une fois la tension fixée, on empêche la vis de tourner grâce à un peu de colle chaude.
On a également ajouté des fusibles avant les convertisseurs, pour protéger coûte que coûte.
Connecteurs
Pour les connecteurs, nous avons décidé d'utiliser des XT-60 pour connecter la batterie, le bouton d'arrêt d'urgence et le contrôleur moteur (qui est en série avec l'arrêt d'urgence et la batterie). Ce choix a été fait car ces connecteurs sont bien connus pour pouvoir faire passer beaucoup de puissance, et sont en général la référence dans les batteries Lipo.
Pour les sorties en tension 12V et 5V, nous utilisons des borniers à vis, doublés avec des connecteurs JST, si jamais on choisi de faire des connecteurs permanents pour plus de facilité.
On a choisi d'utiliser un connecteur JST pour alimenter la Raspberry, pour avoir un connecteur permanent qui est propre et sans risque de court-circuit comme avec les borniers à vis où il peut y avoir quelques brins d'un des fil qui s'en échappe.
Microcontrôleur
Nous avons choisit un contrôleur NUCLEO32-F303K8 qui nous permet de réaliser ces fonctions:
- Envoi par le bus CAN
- Mesure de la tension de la batterie à travers un pont diviseur (car on ne peut pas mettre du 17V dans l'ADC)
- Pilotage des relais permettant de distribuer la tension dans les convertisseurs de puissance
Ce µC est monté sur des connecteurs pin femelle, ce qui nous permet de le changer facilement si jamais un soucis arrive, et qu'un remplacement est nécessaire.
LED et Buzzer
Comme vu auparavant, nous avons choisi une LED et un buzzer pour prévenir quand la batterie atteint un niveau assez bas. On connecte ces composants sur des pattes du contrôleur où il y a un timer. Ainsi, on peut facilement faire clignoter la LED et faire fonctionner le buzzer. Nous avons cependant commis une erreur que nous avons corrigé sur la deuxième carte (que nous verrons plus tard): nous n'avons pas mis de transistor pour piloter le buzzer, ce qui fonctionne, mais qui risque de cramer la patte de sortie si on n'a pas de chance. Donc pour être sur, il vaut mieux piloter le buzzer avec un transistor et y ajouter une diode de roue libre pour décharger sa bobine.
Projet 2 : Écran de contrôle
Etude préliminaire du sujet
Cahier des charges
- Système fiable, donc plateforme Raspberry/STM et moyen de communication RF/bluetooth/WiFi à choisir par rapport à ça.
- Documentation du projet sur le wiki polybot
- Affichage des infos telles que:
- Les coordonnées des robots
- L'état (blocked, busy, idle etc)
- Les points du suivi du parcours
- La tension de batterie
- ...etc
- Boutons de contrôle/écran tactile/switchs?
Contraintes
- Interdiction de commander le robot à distance pendant la compétition
- L'organisation de la Coupe de France utilise des dispositifs radio à hautes fréquences pouvant entraîner des dysfonctionnements.
- Un grand nombre de robot sera présent à la compétition, attention aux interférences.
- On désire un système fiable.
Environnement de travail
Pour ce projet, nous avons utilisé plusieurs outils. Voici ceux que nous avons le plus utilisé :
- MBED : Logiciel que nous avons utilisé au début pour tester la communication avec la STM.
- SMTCubeIDE : Permet de programmer le fonctionnement et le comportement du robot. Dans notre cas, on l'utilise pour écrire le programme qui permet l'affichage des données.
- MIT - App Inventor : pour la réalisation de l'application permettant d'afficher les données recueillies
Étapes principales du projet 2
Nous avons réfléchis aux grandes étapes qui vont composer ce projet :
- Le choix, la commande et le montage des composants
- La communication entre la STM32 et le module HC-06
- Affichage des données (communication entre le module HC-06 et le terminal/application via Bluetooth)
- Réalisation d'une application pour un meilleur affichage des données
Choix, commande et montage des composants
Choix du protocole de communication
Pour répondre au cahier des charges, nous avons choisi d'utiliser une communication Bluetooth pour envoyer les données souhaitées à depuis notre microcontrôleur STM32. En effet, il s'agit d'un moyen de communication suffisamment fiable et plutôt simple à implémenter. De plus, nous n'avons pas besoin d'une grande distance de fonctionnement, ni de beaucoup de stockage. Le Bluetooth semble donc être une solution adaptée pour répondre à notre cahier des charges.
Choix et commande des des composants
Après quelques recherches, nous avons découvert le module HC-06 qui permet de réaliser une liaison Bluetooth entre des microcontrôleurs et un autre appareil. Nous avons donc commandé ce composant en double. Il s'agit du seul matériel que nous avons eu besoin de commander pour ce projet.
Montage des composants
Concernant le montage du montage sur la STM32, il suffit de brancher les 4 pins du module sur la STM32 :
| Pin HC-06 | Pin STM32 |
|---|---|
| VCC | 5V |
| GND | GND |
| RXD | en fonction du protocole de communication |
| TXD | en fonction du protocole de communication |
Communication STM/HC-06
Protocoles de communication existants
Après avoir connecté notre module Bluetooth HC-06 à la STM, il faut maintenant réaliser une communication entre les 2 composants pour envoyer les informations souhaitées sur le module HC-06 qui transmettra ensuite ces informations à notre application via Bluetooth. Il existe différents protocoles de communication comme le SPI, I2C, UART, CAN... Après quelques recherches, nous nous sommes rendus compte que pour ce genre de système, l'UART offrait une communication série fiable et plutôt simple à implémenter.
Nous avons donc choisi d'utiliser le protocole UART et plus particulièrement l'UART3 de la SMT32 car il n'est pas encore utilisé par le robot (l'UART1 et 2 étaient déjà pris). On branchera donc la pin RXD du module Bluetooth sur la pin PB10 de la STM32 et la pin TXD du module sur la pin PC5 de la STM32.
- La liaison UART (Universal Asynchronous Receiver Transmitter) est une liaison “point à point”, ce qui signifie que deux dispositifs numériques sont connectés entre eux directement, sans passer par un routeur ou tout dispositif qui permettrait d’aiguiller des trames venant d’un émetteur vers plusieurs récepteurs. Une liaison “point à point” est clairement une version très simple et rudimentaire de liaison série. Il existe d’autres normes que la liaison UART en mode “point à point” mais c’est la plus utilisée car, comme son nom l'indique, elle revendique d’être universelle.
- On distingue ensuite les liaisons multipoints à bas débit. On connait par exemple le CAN (pour Controller Area Network) utilisé notamment dans l’automobile. L’idée, dans l’automobile ou dans les véhicules en général, est de diminuer les kilomètres de câbles qui permettent de relier tous les dispositifs numériques entre eux, en connexions point à point. C’est donc un BUS (pour Bit Unit System) qui relie en mode multipoint tous les systèmes numériques entre eux (l’ABS, le contrôle de trajectoires ESP, les éléments de confort, climatisation, chauffage, etc.). Une unité centrale envoie des trames que tous les dispositifs esclaves reçoivent, mais dans la trame figure également le destinataire qui seul exécutera la commande correspondante.
- Enfin, on distingue les liaisons multipoints à haut débit comme Ethernet, mis en œuvre pour Internet, USB ou FireWire.
Présentation du protocole UART
La liaison UART (pour Universal Asynchronous Receiver Transmitter), se veut universelle et est implémentée dans la quasi-totalité des microcontrôleurs du marché (STM, Arduino...).
Une trame UART est composée de la manière suivante :
- Un bit de START à 0 qui sert à synchroniser l’envoi de la trame avec le récepteur;
- Les bits de données dont la taille est comprise entre 5 et 9 bits qui sont envoyés du LSB (bit de poids faible) au MSB (bit de poids fort);
- Un bit de parité pour le contrôle d’erreur;
- Un ou deux bits de STOP à 1 pour marquer la fin de la trame. Le niveau logique de repos est le 1.
Quand on initialise la liaison (il faut le faire du côté émetteur et aussi du côté récepteur), il faut initialiser de façon cohérente des deux côtés de la liaison. En particulier, il faut régler la vitesse de transmission sur l’une des vitesses standard (le Baudrate).
Pou ce projet, nous allons utiliser un baudrate de 9600 qui correspond à 9600 bits par seconde. C’est suffisamment rapide pour que la transmission de quelques chaînes de caractères assez courtes semble instantanée, et suffisamment lent pour permettre au code STM de tourner.
Réalisation de la communication via UART
Pour réaliser la communication UART entre la STM32 et notre module Bluetooth, on commence par brancher les câbles comme mentionnées un peu plus haut. On doit ensuite configurer notre projet sur STMCubeIDE. Pour cela il suffit de sélectionner l'UART, de l'activer puis de régler certains paramètres.
On pourra ainsi modifier le baudrate, la structure de la trame (nombre de bit de stop, nombre de bits de données...), activer ou non les interruptions...
Une fois ces réglages réalisés, notre communication est opérationnelle. On pourra ainsi utiliser différentes fonctions dans le code de la STM32 pour envoyer les données sur les pins de l'UART3. On utilisera par exemple les fonctions :
- HAL_UART_Transmit_IT(&huart3, (uint8_t*) txt_a_envoyer ",sizeof(txt_a_envoyer));
- HAL_Delay(temps) qu'on remplacera par osDelay(temps) avec l'utilisation de FreeRTOS
On pourra ainsi envoyer des données et aller les récupérer via un terminal (connecté au module Bluetooth) ou a une application.
Affichage des données
Choix des valeurs à afficher
Nous avons discuté avec les autres groupes travaillant sur le robot pour savoir quels types d'informations ils aimeraient que l'on affiche sur notre écran.
Nous allons donc afficher les données suivantes :
- Tension de la batterie
- Encodeurs (nombre de tours réalisé par chaque encodeur)
- Vitesse du robot
- Coordonnées du robot (position)
- Trajectoire (peut-être), le but serait qu'à la fin du parcours on affiche graphiquement la trajectoire qu'a emprunté le robot. Mais à voir si cela est possible et utile surtout
Nous aimerions également pouvoir stocker les données recueillies pendant le parcours du robot. Toutes ces informations pourraient nous permettre pendant le parcours de vérifier le bon fonctionnement du robot. En cas d'erreur/problème/bug on pourra étudier les données stockées pour tentant de trouver l'origine du problème. A MODIFIER EN FONCTION DE NOTRE AVANCEMENT
On pense également qu'il pourrait être intéressant de rajouter une option sur l'écran de contrôle permettant l'arrêt d'urgence du robot en cas de problème détecté. Pour cela, nous avons travaillé avec Florian et Flavien qui travaillent sur la carte de puissance pour qu'ils intègrent cela à leur système. A MODIFIER EN FONCTION DE NOTRE AVANCEMENT
Affichage des valeurs souhaitées
Dans notre code
Pour transmettre les différentes valeurs, nous avons donc utilisé les fonctions mentionnées plus haut.
On commence par envoyer le flag, nous avons choisi de lui donner la valeur -100. Ce flag nous sera utile pour la suite car cela signalera à l'application qui réceptionne les données quand nous serons au début de la boucle while du code. Cela permet donc de synchroniser l'envoi des données.
On convertit ensuite chacune des valeurs a envoyer en texte afin de pouvoir les envoyer sous forme de texte à l'aide de la fonction sprintf.
- parler de la synchronisation de la clock de l'appli avec la synchronisation des Delay.
- parler de la valeur du flag
- parler de comment on récupére les données dans le code du robot (encodeurs et tension)
- parler des calculs pour déterminer les valeurs de la vitesse et de la position.
- parler des différentes lignes de code : sprintf, hal_uart_transmit, osDelay(200)...
- dire qu'après on peut tester sur le vrai robot
Par exemple l'image ci-dessous avec des valeurs fictives (compteurs qui s'incrémente) :
Pour suivre le schéma de code utilisé par les autres groupes, nous avons dû créer une nouvelle tâche avec FreeRTOS : dataDisplayTask. Tout notre code se trouve donc à l'intérieur de cette tâche. FreeRTOS se chargera ensuite d'alterner entre toutes les tâches du programme du robot en fonction de leur priorité. On considère comme vous pouvez vous en douter que notre tâche ne sera que de priorité assez faible puisqu'il s'agit simplement d'affichage. On pourra par contre revoir cette priorité dans le cas où l'on ajoute un bouton d'arrêt sur notre application. Il serait même peut être plus simple de créer une nouvelle tâche uniquement pour l'arrêt d'urgence qui sera de priorité très forte.
METTRE LOGO FREERTOS
Réalisation de l'application
Interface
Pour réaliser notre application, nous avons utilisé MIT App Inventor qui permet de réaliser des applications pour mobile, tablette ou autre périphérique grâce au langage de programmation Scratch.
Nous aurions pu réaliser une application plus développée avec autre langage de programmation mais le but de ce projet n'était pas de réaliser la meilleure application mais plutôt de bien recevoir et afficher les données.
Nous avons donc commencé à réaliser les différentes pages (Screen) de l'application. Pour cela nous avons utilisé les différents outils mis à notre disposition par App Inventor (boutons, texte, switch, images ...).
Voici les différents Screen crées :
- Screen 1 : Page de lancement avec logo Polybot
- Screen 2 : Choix des valeurs à afficher et choix de stocker ou non les données affichées
- Screen 3 : Affichage des données souhaitées
METTRE LES PHOTOS DES TROIS SCREEN
Pour télécharger l'application et la faire fonctionner, nous vous invitons à suivre notre tuto d'utilisation au lien suivant :
METTRE LE LIEN DU TUTO
Programmation
Etant donné que nous avons utilisé App Inventor pour réaliser notre application, nous avons uniquement pu utiliser du Scratch pour coder le fonctionnement de l'appli.
Résultats et bilan du projet
Résultat et performances
- Pour le projet 1,
- Pour le projet 2, nous avons réalisé un système fonctionnel qui récupère correctement les informations souhaitées et les affiche sur l'application Polybot. Cependant, nous nous sommes retrouvés limités concernant la fréquence d'affichage et d'envoi des données. Cela est peut être dû à l'application qui a été réalisé en Scratch (pas un code très précis). Pour le moment, une même donnée sera actualisé toutes les 0,7 secondes. A CONFIRMER!!
Cependant, certains bouts de code du robot sont manquants ou défaillants, notamment le code des encodeurs qui engendre souvent des erreurs ainsi, ou encore le code pour récupérer la valeur de la tension de la batterie (bus CAN de la carte d'alimentation) qui n'a pas encore été crée.
Difficultés rencontrées
Voici les principales difficultés que nous avons rencontrées durant ce projet :
- Réalisation du diagramme de Gantt et avancement du projet : Par manque d'expérience nous ne connaissions pas toujours le temps nécessaire à la réalisation de chaque étape. Nous avons donc eu un peu de mal à respecter le diagramme de Gantt prévu, mais heureusement nous allions en général toujours plus vite que prévu. Nous avons également constaté que de nouvelles étapes arrivaient au fur et à mesure du projet, des étapes que nous n'avions pas prévu à la base. Mais grâce à notre avance, nous avons eu le temps de réaliser ces nouvelles étapes.
- Pour le projet 2, nous n'avions pas réalisé que la gestion de petit bugs nous prendraient autant de temps. Par exemple, nous avons mis 3 ou 4 jours pour réaliser une certaine version du code pour la STM32, et cela nous a pris tout autant de temps de réussir à intégrer ce code au code actuel du robot. Nous avons retrouvé ce problème à plusieurs étapes de ce projet. Nous pensions donc pouvoir finir en avance mais nous avons fini tout juste à temps.
Améliorations possibles
Concernant le projet 1 , ....PARLER DE LA COMMUNICATION SUR LE BUS CAN POUR COMMUNIQUER LA TENSION DE LA BATTERIE PAR EXEMPLE ...
Concernant le projet 2, nous aurions pu ajouter plusieurs fonctionnalités supplémentaires, telles que :
- L'ajout sur l'application d'un bouton d'arrêt d'urgence permettant de contrôler le robot. A noter que le binôme travaillant sur la carte de puissance à pris cela en compte dans la conception de la carte. Cela sera donc tout à fait possible, il suffira de créer le code pour cette fonctionnalité.
- Il pourrait aussi être intéressant de faire communiquer les 2 robots ensemble en leur branchant tous les 2 un module Bluetooth HC-06. Cela leur permettraient de mieux se coordonner ensemble sur le terrain pendant les matchs.
- On pourrait également ajouter un bouton permettant de choisir la stratégie que le robot doit adopter sur le terrain (parmi plusieurs stratégies possibles).
- On pourrait également améliorer la fréquence d'envoi et d'affichage des données. On se demande si la limite ne provient de l'application qui a été réalisée sur Scratch et qui ne permet donc pas vraiment une grande liberté dans la conception de l'appli.
- Nous aurions également souhaité afficher la trajectoire du robot sur l'image du terrain de jeu que nous avons mis sur l'application. Nous aurions par exemple pu utiliser une petite croix placée sur la carte pour signaler sa position. Cependant, App Inventor, que nous avons utilisé pour la conception de notre application, ne semble pas permettre de pouvoir réaliser cela de manière simple (on ne peut pas placer d'image librement sur l'interface). Nous n'avons donc pas vraiment eu le temps de réfléchir à une manière d'implémenter cela. En attendant, il est tout de même possible d'aller dans le fichier .csv contenant les valeurs enregistrées et de tracer nous-même le dessin de la trajectoire du robot à partir des données "position x" et "position y".
Suivi du projet
Sources
- http://thierryperisse.free.fr/documents/TER/TER-BUS-CAN/note_application_com_pic_mppt.pdf
- https://www.technologuepro.com/cours-systemes-embarques/cours-systemes-embarques-Bus-CAN.htm
- https://openclassrooms.com/fr/courses/5224916-developpez-un-robot-mobile-connecte-par-bluetooth/5500616-utilisez-une-liaison-serie-uart