Skip to content

Commit

Permalink
Docs, programmation : déplacements brouillon
Browse files Browse the repository at this point in the history
  • Loading branch information
Robin864 committed May 21, 2024
1 parent 40229bc commit d9dd094
Show file tree
Hide file tree
Showing 3 changed files with 39 additions and 3 deletions.
40 changes: 38 additions & 2 deletions docs/Robot/Programmation/Deplacements.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,42 @@ grand_parent: Robot
nav_order: 1
---

# Inserer votre contenu
<!-- Include mathjax for mathematical expressions -->
<script type="text/javascript" async
src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.7/MathJax.js?config=TeX-MML-AM_CHTML">
</script>

cf [guide markdown](https://www.markdownguide.org/)
# Les déplacements du RATP

## Code et fonctionnement

Avant d'écrire un quelconque programme, il faut connaitre la plateforme utilisée mécaniquement. Comme dit précédemment, le RATP embarque des roues mécanums (ou roues suédoises) qui lui permettent de garder son orientation quelque soit les déplacements. C'est un avantage à l'utilisation mais une contrainte supplémentaire dans le code. Cette contrainte est la suivante : nous aimerions donner des coordonnées polaires (angle, distance) relatives au robot et qu'il s'y déplace. Le défi auquel nous faisons face est le suivant : comment déplacer le robot suivant un angle quelconque ? En effet, chaque roues ne parcoureront pas la même distance lorsque le robot ira à une distance suivant un angle.

Pour résoudre ce problème, nous utilisons les équations cinématiques indépendantes sur les roues afin de déterminer pour chacune, sa vitesse (positive ou négative selon le sens de rotation), son accéleration (strictement positive suppérieure à zéro) et sa distance.

<!-- TODO : solve how to center the image and the equations in the table -->

| Schéma du robot | Équations correspondantes |
|:-------------|:------------------|
![](../../assets/Robot/Programmation/Deplacements/schema_mecanum.png) | $$a = sin(\alpha + \dfrac{\pi}{4})$$ <br /> $$b = cos(\alpha + \dfrac{\pi}{4})$$ <br /> $$c = -sin(\alpha - \dfrac{\pi}{4})$$ <br /> $$d = cos(\alpha - \dfrac{\pi}{4})$$

Des équations ressort un coéficient applicable sur la vitesse, l'acceleration et la distance. Elles permettent au moteurs pas à pas de terminer leur cycle de mouvement en même temps tout en les déplaçant à des vitesses et des accélérations différentes. Notons qu'il est plus simple de travailler avec un chassis parfaitement carré plutot qu'un chassis rectangulaire.

Une fois ces équations intégrées au programme, nous utilisons plusieurs autres multiplicateurs. D'abord il faut compenser le microstepping : sur notre robot il est réglé à $$\dfrac{1}{8}$$ step, donc toutes nos valeurs doivent être multiplitées par 8.

{: .note}
Le *microstepping* est un terme qui désigne la division de pas des moteurs par les drivers. Il permet d'augmenter la précision et de réduire le bruit des moteurs mais influe forcément sur la vitesse si les paramètres initiaux ne sont pas ajustés en conséquence.

Ensuite, on peut utiliser chaque coéficient pour calculer respectivement la vitesse, l'acceleration et la distance de chacune des roues (rappellons que chaque roue à sa propre vitesse, acceleration, distance). Finallement, on s'occupe de la calibration du robot qui consiste à régler la distance parcourue selon la distance demandée.

Tous ces réglages se trouve dans [la classe Movement](https://github.com/Robin864/Projet_CDR-2024_I2/tree/main/lib/Movement) et sont totalement transparents dans son utilisation, notamment au sein de la stratégie. La fonction qui s'occupe de déterminer les paramètres de chaque moteur reçoit les paramètres angle et distance qui sont les coordonnées polaires relative de la destination. Nous verrons par la suite qu'il aurait été intéressant d'utiliser des coordonnées cartésiennes absolues pour faciliter la mise en place de la stratégie.

N'oublions pas d'ajouter à notre programme la fonction particulière qu'est la rotation sur lui-même du robot : cette dernière fait tourner les roues opposées diagonalement dans le même sens de rotation. Pour tourner dans un sens ou dans l'autre il suffit d'inverser le sens de rotation de toutes les roues.

## Utilisation

La classe *Movement* est dédiée aux déplacements. Quasiment toutes les fonctions de cette classe sont utilisées dans la classe dédiée à la stratégie. Comme dit précédemment, pris par le temps nous n'avions pas eu le temps de programmer un déplacement selon des coordonnées cartésiennes absolues, nous utilisons donc uniquement des coordonnées polaires et cartésiennes relatives dans la statégie. C'est une perte de temps importante puisque pour définir chaque future position, il faut placer le plan selon la position du robot, sans oublier que lorsque le robot effectue une rotation, sont plan effectue aussi la rotation.

Ce détail fait partie des axes d'amélioration : utiliser un plan global donc des coordonnées absolues indépendamment du plan local du robot. Cette fonctionnalité permettrait d'accélerer le processus de réfléxion de la stratégie.

La fonction de la classe *Movement* reçoit les coordonnées polaires de la destinnation, les transforme en coordonnées cartésiennes, les corrige et les appliques aux différents paramètres des moteurs. Pour appliquer ces paramètres, nous utilisons [la librairie AccelStepper](https://www.airspayce.com/mikem/arduino/AccelStepper/classAccelStepper.html). Et la fonction qui s'occupe de la rotation reçoit simplement un angle. Sa vitesse de rotation est définie par la vitesse des moteurs qui est elle même définie par la vitesse par défaut définie dans le programme, qui est relativement lente afin d'éviter toute erreur d'approximation possible. À l'avenir il pourrait être intérressant de pouvoir faire varier cette vitesse selon les situations à l'aide d'un paramètre.
2 changes: 1 addition & 1 deletion docs/Robot/Programmation/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,7 +26,7 @@ Après avoir installé cet environnement de développement, nous pouvons créer
└── 📄 README.md
```

Le dossier `include` accueille les fichiers d'en-tête du projet, `lib` prévoi de recevoir les librairies spécifiques au projet et `src`, comme son nom l'indique, comporte les sources du projet dont le fichier `main.cpp` qui est le coeur du programme final du robot : sans ce dernier aucun autre programme ou aucune autre librairie ne peuvent être utilisés. `platformio.ini` est propre aux projets PlatformIO et dicte la configuration la cible du projet. Enfin `README.md` est facultatif et permet de présenter le projet dans le répertoire de la platefrome distante, ici GitHub.
Le dossier `include` accueille les fichiers d'en-tête du projet, `lib` prévoi de recevoir les librairies spécifiques au projet et `src`, comme son nom l'indique, comporte les sources du projet dont le fichier `main.cpp` qui est le coeur du programme final du robot : sans ce dernier aucun autre programme ou aucune autre librairie ne peuvent être utilisés. `platformio.ini` est propre aux projets PlatformIO et dicte la configuration de la cible du projet. Enfin `README.md` est facultatif et permet de présenter le projet dans le répertoire de la platefrome distante, ici GitHub.

{: .note }
Nous utilisons PlatformIO pour simplifier et accélerer les étapes relatives au développement. On peut cependant utiliser d'autres IDE tels que [ESP-IDF](https://github.com/espressif/vscode-esp-idf-extension) ou encore [l'IDE Arduino](https://github.com/arduino/arduino-ide).
Expand Down
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit d9dd094

Please sign in to comment.