Modifications

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.

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.

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.

<br>

<br>

<br>

<br>

<br>

<br>

'''Liste des composants'''<br>

'''Liste des composants'''<br>

 

<br>

<br>

<br>

<br>

Dans un premier temps le  but de notre partie software est de récupérer la valeur précise de la batterie sur l’ADC pour pouvoir piloter les signaux d’alertes (led, buzzer) et ouvrir les circuits en fonction du niveau de décharge de la batterie.

Dans un premier temps le  but de notre partie software est de récupérer la valeur précise de la batterie sur l’ADC pour pouvoir piloter les signaux d’alertes (led, buzzer) et ouvrir les circuits en fonction du niveau de décharge de la batterie.

Ensuite nous souhaitons mettre en place un bus CAN pour communiquer avec la carte STM principale pour lui permettre de commander les relais via l'application développée par l'autre binôme de notre projet.

Ensuite nous souhaitons mettre en place un bus CAN pour communiquer avec la carte STM principale pour lui permettre de commander les relais via l'application développée par l'autre binôme de notre projet.

<br>

<br>

<br>

<br>

 

'''Signaux d’alerte et coupure des circuits en fonction de la décharge de la batterie '''<br>

'''Signaux d’alerte et coupure des circuits en fonction de la décharge de la batterie'''

<br>

{| class="wikitable"

{| class="wikitable"

|-

|-

! Tension de la batterie !! % de décharge !! Action

! Tension de la batterie !! Valeur adc !!% de décharge !! Action

|-

|-

| 17 V || 100% ||  

| 16,16 V || 80% || 3255 ||

|-

|-

| 16,16 V || 80% ||  

| 15,32 V || 60% || 3115 ||  

|-

|-

| 15,32 V || 60% ||  

| 14,48 V || 40% || 2980 || Led clignote

|-

|-

| 14,48 V || 40% || Led clignote

| 14.06 V || 30% || 2930 || Buzzer alerte

|-

|-

| 14.06 V || 30% || Buzzer alerte

| 13,64 V || 20% || 2880|| Coupure des circuit de puissance 12V , 5V et des moteurs

|-

|-

| 13,64 V || 20% || Coupure des circuit de puissance 12V , 5V et des moteurs

| 13.32 V || 10% || 2720 || Coupure de la Raspberry

|-

|-

| 13.32 V || 10% || Coupure de la Raspberry

| 13 V || 0% || 2685 || Seuil critique

|}     

|}     

<br>

<br>

Il faut également filtrer cette alimentation avec une perle de ferrite et des capacités pour alimenter l'ADC. En effet, sa tension doit être extrêmement stable pour pouvoir faire des mesures précises.

Il faut également filtrer cette alimentation avec une perle de ferrite et des capacités pour alimenter l'ADC. En effet, sa tension doit être extrêmement stable pour pouvoir faire des mesures précises.

<br>On peut voir tout ça sur le schéma au début de cette section.

<br>On peut voir tout ça sur le schéma au début de cette section.

==Projet 2 : Écran de contrôle==

==Projet 2 : Écran de contrôle==

<br>

<br>

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).

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. Durant les derniers jours du projet, nous avons tenté de passer à un baudrate plus élevé afin d’accélérer l'envoie et l'affichage des données. En effet, nous avons remarqué que parfois les données s'accumulaient dans le module nous avons donc essayer de résoudre le problème avec ce changement de Baudrate. Malheureusement, le robot était défectueux durant les derniers jours du projet, nous n'avons donc pas eu le temps de tester cette modification. Nous tenterons quand même de la tester la semaine suivant la soutenance si le robot est réparé.

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.  

<br>

<br>

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... Dans notre cas, on choisira le mode Asynchrone pour l'UART, un baudrate de 9600 et on activera les interruptions.

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... Dans notre cas, on choisira le mode Asynchrone pour l'UART, un baudrate de 9600 et on activera 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.

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'UART4.

On utilisera par exemple les fonctions :  

On utilisera par exemple les fonctions :  

  *'''HAL_UART_Transmit_IT'''(&huart4, (uint8_t*) txt_a_envoyer,sizeof(txt_a_envoyer));

  '''HAL_UART_Transmit_IT'''(&huart4, (uint8_t*) txt_a_envoyer,sizeof(txt_a_envoyer));

  *'''HAL_Delay'''(temps) qu'on remplacera par osDelay(temps) avec l'utilisation de FreeRTOS

  '''HAL_Delay'''(temps) qu'on remplacera par osDelay(temps) avec l'utilisation de FreeRTOS

La fonction HAL_UART_Transmit permet de transmettre une chaine de caractère sur l'UART souhaité. Les fonctions HAL_Delay et osDelay permettent d'ajouter un temps d'attente entre les différents Transmit afin de laisser suffisamment de temps au microcontrôleur pour envoyer les données.

La fonction HAL_UART_Transmit permet de transmettre une chaine de caractère sur l'UART souhaité. Les fonctions HAL_Delay et osDelay permettent d'ajouter un temps d'attente entre les différents Transmit afin de laisser suffisamment de temps au microcontrôleur pour envoyer les données.

*Pour calculer la vitesse du robot, sa position et la distance parcourue, on a besoin de récupérer les valeurs renvoyées par les encodeurs. Les encodeurs nous indique précisément le nombre de tours qu'a réalisé chaque roue du robot. Ils sont gérés par un contrôleur MCP233 sur le robot, qui est connecté à l'UART1 de la STM. On doit donc récupérer les valeurs des encodeurs à travers l'UART1 et le MCP233. On utilise des fonctions déjà crées par les équipes de Polybot, à savoir :  

*Pour calculer la vitesse du robot, sa position et la distance parcourue, on a besoin de récupérer les valeurs renvoyées par les encodeurs. Les encodeurs nous indique précisément le nombre de tours qu'a réalisé chaque roue du robot. Ils sont gérés par un contrôleur MCP233 sur le robot, qui est connecté à l'UART1 de la STM. On doit donc récupérer les valeurs des encodeurs à travers l'UART1 et le MCP233. On utilise des fonctions déjà crées par les équipes de Polybot, à savoir :  

  *uint8_t '''MCP233_readEncoderCountM1'''(MCP233_t *mcp, int32_t *count)  

  uint8_t '''MCP233_readEncoderCountM1'''(MCP233_t *mcp, int32_t *count)  

  *uint8_t '''MCP233_readEncoderCountM2'''(MCP233_t *mcp, int32_t *count)  

  uint8_t '''MCP233_readEncoderCountM2'''(MCP233_t *mcp, int32_t *count)  

Ces fonctions permettent de récupérer les valeurs d'incrémentation des encodeurs et les stockent à des adresses (int32_t *count). L'argument (MCP233_t *mcp) permet quant à lui de lire dans le contrôleur MCP233. <br>

Ces fonctions permettent de récupérer les valeurs d'incrémentation des encodeurs et les stockent à des adresses (int32_t *count). L'argument (MCP233_t *mcp) permet quant à lui de lire dans le contrôleur MCP233. <br>

*Afin d'obtenir les différentes données à envoyer, à savoir la vitesse, la distance parcourue, ainsi que la position (x,y) du robot, nous devons mettre en place des calculs spécifiques. On notera que l'on ne peut pas reset les encodeurs car ceux ci servent aussi à asservir les moteurs du robot en position. On va donc d'abord mettre en place quelques lignes permettant de faire nos calculs comme si nous avions un reset des encodeurs : <br>

*Afin d'obtenir les différentes données à envoyer, à savoir la vitesse, la distance parcourue, ainsi que la position (x,y) du robot, nous devons mettre en place des calculs spécifiques. On notera que l'on ne peut pas reset les encodeurs au début de chaque boucle (plus facile pour calculer la différence de tour par rapport à la boucle précédente) car ceux ci servent aussi à asservir les moteurs du robot en position. On va donc d'abord mettre en place quelques lignes permettant de faire nos calculs comme si nous avions un reset des encodeurs. On commence par stocker les valeurs des encodeurs avant que ceux ci soient mis à jour avec la fonction de lecture des encodeurs, on récupère ensuite les nouvelles valeurs puis on réalise la différence entre ces 2 valeurs. On obtient alors le nombre de tours en plus (ou en moins dans le cas d'une marche arrière) par rapport au while précédent.

(lignes de code RESET) <br>

On en vient maintenant aux calculs en eux même. Pour la distance totale parcourue, on met en place des variables qui calculent le cumul des incréments des encodeurs depuis le démarrage du robot, on calcule ensuite la moyenne des valeurs (des 2 encodeurs) afin d'obtenir la distance parcourue par le centre du robot. Finalement, on vient multiplier cette résultante par 2xpixR/incr (incr étant le nombre incréments de l'encodeurs lorsqu'il effectue un tour et R le rayon des encodeurs) : <br>

MCP233_readEncoderCountM2(&mcp,&encRd);

On en vient maintenant aux calculs en eux même. Pour la distance totale parcourue, on met en place des variables qui calculent le cumul des incréments des encodeurs depuis le démarrage du robot, on calcule ensuite la moyenne des valeurs (des 2 encodeurs) afin d'obtenir la distance parcourue par le centre du robot. Finalement, on vient multiplier cette résultante par 2*pi*R/incr (incr étant le nombre incréments de l'encodeurs lorsqu'il effectue un tour et R le rayon des encodeurs). Dans notre cas on aura incr = 4096 et R=44mm. <br>

  distRd = distRd + encRd;   

  distRd = distRd + encRd;   

  distRg = distRg + encRg;   

  distRg = distRg + encRg;   

Pour la position (x,y) du robot, on calcule d'abord l'angle du robot par rapport à son angle d'origine : <br>

Pour la position (x,y) du robot, on calcule d'abord l'angle du robot par rapport à son angle d'origine : <br>

angle = ((M_PI*2*R/incr)*((distRd-distRg)/LargRobot));  //angle en radian   

angle = ((M_PI*2*R/incr)*((distRd-distRg)/LargRobot));  //angle en radian   

On calcule ensuite les positions x et y en faisant respictivement le cosinus et sinus de l'angle multiplié par la distance parcourue entre 2 relevés d'encodeurs auxquels on ajoute les positions precédentes afin de pouvoir voir le robot se déplacer comme s'il était dans un repère orthonormé : <br>

On calcule ensuite les positions x et y en faisant respectivement le cosinus et sinus de l'angle multiplié par la distance parcourue entre 2 relevés d'encodeurs auxquels on ajoute les positions precédentes afin de pouvoir voir le robot se déplacer comme s'il était dans un repère orthonormé : <br>

  posx = (cos(angle)*dist)+posx;  //posx en mm   

  posx = (cos(angle)*dist)+posx;  //posx en mm   

  posy = (sin(angle)*dist)+posy;  //posy en mm   

  posy = (sin(angle)*dist)+posy;  //posy en mm   

*Notre code est maintenant prêt à être implémenté sur le robot.

*Notre code est maintenant prêt à être implémenté sur le robot.

Par exemple l'image ci-dessous avec des valeurs fictives (compteurs qui s'incrémente) :

Par exemple l'image ci-dessous avec des valeurs fictives (compteurs qui s'incrémentent) :

[[Fichier:Terminal.png|200px|vignette|centré|Réception de données]]

[[Fichier:Terminal.png|200px|vignette|centré|Réception de données]]

'''Système d'exploitation Temps Réel''' <br>

'''Système d'exploitation Temps Réel''' <br>

[[Fichier:Logo freertos.jpg|vignette|droite]]

[[Fichier:Logo freertos.jpg|vignette|droite]]

Afin de coordonner toutes les tâches que le robot a à effectuer, on utilise conjointement avec l'équipe de projet de 4A un OS (système d'exploitation) temps réel. Il s'agit de FreeRTOS. Celui-ci est intégrable directement depuis l'outil stm32cubeide et il est même possible de prédéfinir nos différentes tâches et une multitude de paramètres (les priorités des tâches par exemple). Un OS temps réel permet aussi de gérer la préemptivité (ou la priorité) de chaque tâche, une tâche de haute priorité ayant toujours la priorité sur une tâche de basse priorité. Il va de soit que notre tâche prendra une priorité faible par rapport aux autres tâches puisque le plus important pour le robot est qu'il puisse se diriger et manœuvrer et que notre tache consiste juste à afficher des données. 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 pourra par contre revoir cette priorité dans le cas où l'on ajoute un bouton d'arrêt d'urgence sur notre application ou même créer une autre tâche spécialement pour ce bouton avec une forte priorité. Une fois la ou les tâche(s) et les paramètres définis, il nous suffit de générer le code et de remplir notre tâche.

 

Afin de coordonner toutes les tâches que le robot a à effectuer, on utilise conjointement avec l'équipe de projet de 4A un OS (système d'exploitation) temps réel. Il s'agit de FreeRTOS. Celui-ci est intégrable directement depuis l'outil STMCubeIDE et il est même possible de prédéfinir nos différentes tâches et une multitude de paramètres (les priorités des tâches par exemple). Un OS temps réel permet aussi de gérer la préemptivité (ou la priorité) de chaque tâche, une tâche de haute priorité ayant toujours la priorité sur une tâche de basse priorité. Il va de soit que notre tâche prendra une priorité faible par rapport aux autres tâches puisque le plus important pour le robot est qu'il puisse se diriger et manœuvrer et que notre tache consiste juste à afficher des données. 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 pourra par contre revoir cette priorité dans le cas où l'on ajoute un bouton d'arrêt d'urgence sur notre application ou même créer une autre tâche spécialement pour ce bouton avec une forte priorité. Une fois la ou les tâche(s) et les paramètres définis, il nous suffit de générer le code et de remplir notre tâche.

===Réalisation de l'application===

===Réalisation de l'application===

Pour télécharger l'application et la faire fonctionner, nous vous invitons à suivre notre tuto d'utilisation au lien suivant :  

Pour télécharger l'application et la faire fonctionner, nous vous invitons à suivre notre tuto d'utilisation au lien suivant :  

<br>

<br>

[[Fichier:Code3 2.png|vignette|centré|500px|Connexion au périphérique Bluetooth]]

[[Fichier:Code3 2.png|vignette|centré|500px|Connexion au périphérique Bluetooth]]

Ensuite, on créé et on initialise une variable globale nommée flag (à ne pas confondre avec le flag envoyé par la STM) qui va nous permettre de bien synchroniser la réception des données. En effet, à chaque parcours de boucle on ne veut recevoir qu'une seule donnée (par exemple la tension) et au tour de boucle suivant, on affichera la donnée suivante (par exemple la vitesse).  

Ensuite, on créé et on initialise une variable globale nommée flag (à ne pas confondre avec le flag envoyé par la STM) qui va nous permettre de bien synchroniser la réception des données. En effet, à chaque parcours de boucle on ne veut recevoir qu'une seule donnée (par exemple la tension) et au tour de boucle suivant, on affichera la donnée suivante uniquement (par exemple la vitesse).  

Et afin de synchroniser parfaitement l'envoi et la réception on commence détecter la réception d'une donnée précise (le flag de la STM) valent -9999. Nous avons choisi cette valeur car elle ne pourra jamais être atteinte par aucune des données affichées donc pas d'erreur possible. Une fois qu'on a reçu cette donnée valant -9999 on sait que les données reçues ensuite seront la distance parcourue (encodeurs), la tension de la batterie, la vitesse, la position x et la position y. On chaque fin d'un tour de boucle, on incrémente le flag.

Et afin de synchroniser parfaitement l'envoi et la réception on commence détecter la réception d'une donnée précise (le flag de la STM) valant -9999. Nous avons choisi cette valeur car elle ne pourra jamais être atteinte par aucune des données affichées donc pas d'erreur possible. Une fois qu'on a reçu cette donnée valant -9999 on sait que les données reçues ensuite seront, dans l’ordre, la distance parcourue (encodeurs), la tension de la batterie, la vitesse, la position x et la position y. On chaque fin d'un tour de boucle, on incrémente le flag.

 

[[Fichier:Code3 3.png|vignette|700px|centré|Réception et affichage des données]]

[[Fichier:Code3 3.png|vignette|700px|centré|Réception et affichage des données]]

Enfin, nous avons créé plusieurs fonctions permettant le stockage des données affichées si l'utilisateur le souhaite. Nous avons par exemple crée la fonction nettoyer_fichier qui vide le fichier à chaque nouveau lancement de l'application, et la fonction stockage_data qui va ajouter les données dans le fichier de stockage.

Enfin, nous avons créé plusieurs fonctions permettant le stockage des données affichées si l'utilisateur le souhaite. Nous avons par exemple créé la fonction nettoyer_fichier qui vide le fichier à chaque nouveau lancement de l'application, et la fonction stockage_data qui va ajouter les données dans le fichier de stockage. En amont, il faudra ajouter un fichier .csv dans le téléphone. Pour avoir plus d'informations sur la façon dont nous avons géré le stockage, nous vous invitons à aller voir notre page de tuto : [[Projet_5A_2020_2021/Tuto utilisation et modification|Tutoriel d’utilisation]]

Pour avoir plus d'informations sur la façon dont nous avons géré le stockage, nous vous invitons à aller voir notre page de tuto : METTRE LE LIEN DE LA PAGE TUTO.

=Résultats et bilan du projet=

=Résultats et bilan du projet=

==Résultat et performances==

==Résultat et performances==

*Pour le projet 1,  

*Pour le projet 1, nous avons pu tester le fonctionnement de la carte et tout marche parfaitement. Par exemple, lorsque l'on a branché sur notre carte une batterie à moins de 30% de sa puissance alors les LED et les buzzers l'ont bien signalé. Après vérification de la tension de la batterie, on était bien dans la bonne fourchette de tension.

*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!!

*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) ou a un baudrate trop faible mais comme nous l’avons dit plus haut, nous n’avons pas eu le temps de tester nos solutions car le robot ne fonctionnait pas les derniers jours de projet. Pour le moment, une même donnée sera actualisée toutes les 0,8 secondes.  

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.

Cependant, certains bouts de code du robot (qui ne font pas partie de notre projet) sont manquants ou défaillants, notamment le code des encodeurs qui engendre souvent des erreurs (envoie de valeurs négatives), 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==

==Difficultés rencontrées==

Voici les principales difficultés que nous avons rencontrées durant ce projet :  

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.<br>

*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. 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. Globalement nous avons avancé très vite au début et beaucoup lentement sur la fin mais nous avons terminé à temps.<br>

*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.

*Pour le projet 1, lors de la première commande, nous avions commandé des transistors beaucoup trop petits (moins d'un millimètre de long), ce qui les rendait insoudables. Nous avions également commandé des convertisseurs de tension qui étaient tout simplement insoudables, car leur pad de soudure étaient en dessous du composant. Nous avons donc recomandés d'autres composants plus adéquats et de la bonne taille. Nous avons eu aussi pendant nos test, des composants qui chauffaient trop. On a pu pour certains changer le schéma à temps pour baisser la tension par exemple pour les relais, et on a mis un radiateur sur le convertisseur, ce qui le refroidit bien. Et enfin, les délais de commande de PCB nous retardaient pour pouvoir réaliser la carte, et surtout pour la deuxième.

*Pour le projet 2, nous n'avions pas réalisé que la gestion de petit bugs nous prendrait 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 pour 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.

Concernant le projet 2, nous aurions pu ajouter plusieurs fonctionnalités supplémentaires, telles que :  

Concernant le projet 2, nous aurions pu ajouter plusieurs fonctionnalités supplémentaires, telles que :  

*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.

*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".

*Enfin, nous aurions 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".

[[Fichier:Trajectoire.png|vignette|centré|Espace prévu pour l'affichage de la trajectoire]]

[[Fichier:Trajectoire.png|vignette|centré|Espace prévu pour l'affichage de la trajectoire]]

=Suivi du projet=

=Suivi du projet=