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>

'''Configuration de l’ADC '''<br>

 

'''Configuration de l’ADC'''

<br>

Dans un premier temps nous avons mit en place un pont diviseur directement relié a la patte de l’ADC (PA0) qui supporte une tension de 0V à 3,3V. La résolution de 12 bit nous donne donc une valeur de 0 à 4096 exploitable pour cette plage de tension. La décharge de la batterie compris entre 17V et 13V correspond à une variation de 2,87V à 2,19V soit de 3400 à 2685. L’ADC fonctionne en «polling mode» : Il démarre, charge un condensateur pendant 10 ms , lit puis stock cette valeur dans une variable puis s’arrête jusqu’à la prochaine boucle.                                     

Dans un premier temps nous avons mit en place un pont diviseur directement relié a la patte de l’ADC (PA0) qui supporte une tension de 0V à 3,3V. La résolution de 12 bit nous donne donc une valeur de 0 à 4096 exploitable pour cette plage de tension. La décharge de la batterie compris entre 17V et 13V correspond à une variation de 2,87V à 2,19V soit de 3400 à 2685. L’ADC fonctionne en «polling mode» : Il démarre, charge un condensateur pendant 10 ms , lit puis stock cette valeur dans une variable puis s’arrête jusqu’à la prochaine boucle.                                     

<br>

<br>

'''Configuration des timers '''<br>

'''Configuration des timers'''

<br>

Pour piloter le buzzer et la led en fonction du niveau de la batterie, nous devons mettre en place des signaux PWM générés par des timers. Pour cela nous configurons l’horloge des timers à 16Mhz. CubeMX nous permet de régler ensuite le préscaler qui divise la fréquence. Ensuite il nous reste à régler le counter_périod qui est un registre de 16 bits qui compte de 0 à 65536, cela nous permet d’avoir la fréquence souhaitée. <br>

Pour piloter le buzzer et la led en fonction du niveau de la batterie, nous devons mettre en place des signaux PWM générés par des timers. Pour cela nous configurons l’horloge des timers à 16Mhz. CubeMX nous permet de régler ensuite le préscaler qui divise la fréquence. Ensuite il nous reste à régler le counter_périod qui est un registre de 16 bits qui compte de 0 à 65536, cela nous permet d’avoir la fréquence souhaitée. <br>

Pour le buzzer le préscaler est à 16 (1Mhz) et le  counter_périod est à 2272 pour donner un avertissement sonore en La (440hz) .

Pour le buzzer le préscaler est à 16 (1Mhz) et le  counter_périod est à 2272 pour donner un avertissement sonore en La (440hz) .

Pour la led nous avons un préscaler de 1000 (16khz) et un  counter_period de 8000 pour un clignotement de (2hz).  

Pour la led nous avons un préscaler de 1000 (16khz) et un  counter_period de 8000 pour un clignotement de (2hz).  

 

'''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"

A gauche du chip, il y a toute la partie quartz. Au dessus, on peut voir la partie Buck Converter. A droite, il y a la partie CAN, et le connecteur pour programmer et débugger le chip "JLink1". En dessous, il y a l'espace pour le bouton, le buzzer et les LED de niveau de batterie. A gauche du Buck, on peut y voir le pont diviseur de tension qui adapte la tension de la batterie pour pouvoir la mesurer avec l'ADC.

A gauche du chip, il y a toute la partie quartz. Au dessus, on peut voir la partie Buck Converter. A droite, il y a la partie CAN, et le connecteur pour programmer et débugger le chip "JLink1". En dessous, il y a l'espace pour le bouton, le buzzer et les LED de niveau de batterie. A gauche du Buck, on peut y voir le pont diviseur de tension qui adapte la tension de la batterie pour pouvoir la mesurer avec l'ADC.

<br>

<br>

==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>

  encRg = encRg - encRg_save;

  encRg = encRg - encRg_save;

  encRd = encRd - encRd_save;

  encRd = encRd - encRd_save;

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>

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>

  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]]

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

[[Fichier:Capture menu FreeRTOS.png|centré|vignette]]

[[Fichier:Capture menu FreeRTOS.png|centré|vignette|Paramétrage de FreeRTOS]]

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

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

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

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

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

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

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

==Améliorations possibles==

==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 1 , il faudrait réaliser le code pour la communication via le bus CAN afin de pouvoir envoyer à la STM principale la tension de la batterie, et de pouvoir recevoir des instructions d'arrêt d'urgence de l'application. En effet, ça peut être intéressant de déclencher l'arrêt d'urgence depuis l'appli.

 

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 :