Poivron Robotique

Raspberry Pi Pico - Le debug

Keuronde — 2025-09-24T20:20:35Z

Raspberry Pi Pico - Le débogage

Le débogage d'un RP2040, le microcontrôleur du Raspberry Pi Pico, n'est pas trivial. Le guide de démarrage rapide donne quelques pistes et l'architecture nécessaire :

Un Raspberry Pi Pico avec son programme (compiler en mode débug, de préférence)
Une sonde de débogage
OpenOCD qui s'interface avec la sonde de débogage
gdb (https://www.sourceware.org/gdb/)
Un IDE qui s'interface avec gdb

Architecture pour le débogage du Raspberry Pi Pico

La sonde de débogage

La fondation Raspberry Pi vend une sonde de débogage, nommée Raspbery Pi Debug Probe. Mais si vous avec des Raspberry Pico sous la main et un fer à souder, vous serez plutôt intéressés par la possibilité de réaliser vous-même la sonde.

Le dépôt contenant le code se trouve ici : https://github.com/raspberrypi/debugprobe.git

Le Reademe détaille bien la compilation du code. D'abord récupérer le code :

mkdir debugprobe cd debugprobe git clone https://github.com/raspberrypi/debugprobe . git submodule update --init --recursive

Puis le compiler, presque comme un projet standard. Il faut cependant préciser sur on compile pour Raspberry Pi Pico ou pour la Raspberry Pi Debug Probe. Pour le Pico :

 mkdir build cd build cmake -DDEBUG_ON_PICO=ON .. make

Et injection du code avec Pico Tool, dans le répertoire build

sudo picotool load build/debugprobe_on_pico.uf2

OpenOCD

Open On-Chip Debugger, le déboguer de puce libre. C'est le logiciel qui s'interface avec la sonde de débogage. La sonde de débogage que nous utilisons est supportée à partir de la version 12. Si vous être dans Debian 13 (Trixie), une installation classique devrait faire l'affaire :

sudo apt install openocd

Sinon, prenez la version de la fondation Raspberry Pi. Dans le répertoire de votre choix

mkdir openocd cd openocd git clone https://github.com/raspberrypi/openocd.git . git submodule sync git submodule init --recursive

Pour compiler openocd, il vous faudra jimtcl, qui est dans un répertoire de openocd

cd jimtcl ./configure make sudo make install cd ..

Vous pouvez compiler openocd :

./configure make sudo make install

Testez pour vous assurer que l'installation s'est bien passée, si vous avez le résultat suivant, vous êtes bon !

$ sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000" Open On-Chip Debugger 0.12.0+dev-00002-gcd4873400 (2025-09-21-13:58) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Info : [rp2040.core0] Hardware thread awareness created Info : [rp2040.core1] Hardware thread awareness created adapter speed: 5000 kHz Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Error: unable to find a matching CMSIS-DAP device

Nous nous servirons d'openocd avec les droits d'administrateur, ajoutez-le à la liste des programmes 'root' utilisables sans mots de passe. Trouvez où est installé openocd :

$ whereis openocd openocd: /usr/local/bin/openocd

Lancez visudo :

sudo visudo

Et ajoutez la ligne ci-dessous

%dialout ALL=(ALL) NOPASSWD: /usr/local/bin/openocd

Assurez-vous d'être dans le groupe dialout avec la commande groups :

$ groups dialout cdrom floppy sudo audio dip video plugdev netdev bluetooth lpadmin scanner

Dans le cas contraire, ajouter votre utilisateur au groupe dialout, un redémarrage peut-être nécessaire pour que la commande prenne effet :

$ sudo adduser $USER dialout

Install gdb-multiarch

La version dans les dépôts fait très bien l'affaire !

sudo apt install gdb-multiarch

Test de programmation

Le Pico cible doit être alimenté, la sonde est alimentée par l'USB. Vous pouvez alimenter la cible par l'USB aussi.

Attention mon_programme.elf doit correspondre avec votre fichier. Notez que Picotool nécessite un fichier .uf2 tandis que openocd prend un fichier .elf.

sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000" -c "program mon_programme.elf verify reset exit"

Compilation avec symboles de débogage

Videz votre répertoire 'build' de vote projet, relancez cmake avec l'option de Debug.

cmake -DCMAKE_BUILD_TYPE=Debug .. make

Flasher votre programme sur la cible.

Premier debogage

Lancer openOCD

sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000"

Vous devrez relancer cette commande à chaque fois que vous débranchez votre sonde (debugprobe).

Exécutez gdb en lui donnant en argument le nom de votre programme. Entrez les commandes suivantes pour vous connecter à la cible à travers OpenOCD.

gdb mon_programme.elf > target remote localhost:3333 > monitor reset init > continue

Configuration de VS Code

Tout d'abord, créons une tâche pour compiler en mode debug. Ajouter dans le fichier task.json la tâche suivante :

 , { "type": "shell", "command": "cd debug; cmake -DCMAKE_BUILD_TYPE=Debug ../; make Flash", "label": "Flash Debug", "problemMatcher": [], "group": { "kind": "build", "isDefault": false } }

Créez le répertoire debug dans votre projet avant de lancer la tâche.

Dans le dossier .vscode de votre projet, créez le fichier launch.json suivant :

{ "version": "0.2.0", "configurations": [ { "name": "Pico Debug (Cortex-Debug with external OpenOCD)", "cwd": "${workspaceRoot}", "executable": "debug/mon_programme.elf", "request": "launch", "type": "cortex-debug", "servertype": "external", "gdbTarget": "localhost:3333", "gdbPath": "gdb-multiarch", "device": "RP2040", "svdFile": "${env:PICO_SDK_PATH}/src/rp2040/hardware_regs/RP2040.svd", "runToEntryPoint": "main", // Fix for no_flash binaries, where monitor reset halt doesn't do what is expected // Also works fine for flash binaries "overrideLaunchCommands": [ "monitor reset init", "load debug/mon_programme.elf" ] }, ] }

Adaptez le chemin de "debug/mon_programme.elf" pour le faire correspondre au vôtre.

Si tout c'est bien passé, vous pouvez vous connecter à votre cible en USB, et la flasher avec le programme compilé en debug. Puis brancher votre sonde, lancer le serveur openOCD :

sudo openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "adapter speed 5000"

Enfin, dans VS Code, appuyez sur F5 (ou allez dans Run -> Start Debugging) et vous débogguer votre cible !

Triangulation

Keuronde — 2023-10-29T14:36:55Z

Voici l'étude d'une localisation en se basant sur les angles que mesure un robot par rapport à des points connus (balises).

Les principes

La logique se base sur deux principes mathématiques :

La somme des angles d'un triangle vaut 180°
L'équation d'une droite dans le plan

Convention pour les angles

Nous utiliserons le sens conventionnel pour les angles, comme indiqué dans l'image ci-dessous

Signe des angles

La somme des angles d'un triangle

L'équation d'une droite

Un point $M$ de coordonnées $(x, y)$ décrit une droite s'il répond à certaines équations.

La première équation qui vient à l'esprit est généralement :

$$ y = ax+b$$

Cette équation est imparfaite dans la mesure où elle ne permet pas de représenter une droite verticale. Nous lui préférons généralement cette forme :

$$ ax + by + c = 0 $$

Mais dans notre cas, nous allons vouloir représenter des droites qui ont un certain angle $\alpha$ et qui passent par un point connu (notre balise - de coordonnées $(P_x, P_y)$).

Équation d'une droite

Travailler avec l'équation ci-dessus devrait simplifier la démarche :

$$ \left\{ \begin{array}{c} x = P_x + cos(\alpha) \times t\\ y = P_y + sin(\alpha) \times t\\ \end{array} \right. $$

La logique

Intersections de droites

Notre point est à l'intersection de 3 droites, passant chacune par une balises et par le robot.

Notons $\alpha$, l'angle de la droite qui passe par la balise $A$ et notre robot. Puis $\beta$ et $\gamma$, les angles des droites qui passent respectivement par la balise $B$ et le robot et la balise $C$ et le robot.

Angles recherchés

Notre robot est le point qui appartient à ces trois droites, il faut donc résoudre les équations :

$$ \left\{ \begin{array}{c} x = A_x + cos(\alpha) \times t_a\\ y = A_y + sin(\alpha) \times t_a\\ \\ x = B_x + cos(\beta) \times t_b\\ y = B_y + sin(\beta) \times t_b\\ \\ x = C_x + cos(\gamma) \times t_c\\ y = C_y + sin(\gamma) \times t_c\\ \end{array} \right. $$

Ce qui nous fait un total de 8 inconnues : $x$, $y$, $\alpha$, $\beta$, $\gamma$, $t_a$, $t_b$, $t_c$, pour 6 équations indépendantes. Pour trouver les deux équations restantes, nous allons travailler sur les angles

Réduction des inconnues par les angles

Notre robot mesure l'angle entre les balises $A$ et $B$ et les balises $A$ et $C$. Notons les $\theta_1$ et $\theta_2$.

Angles mesurés

Sachant que la somme des angles d'un triangle vaut 180°, nous pouvons exprimer $\beta$ et $\gamma$ en fonction d'$\alpha$ et de données connues.

Exprimons les angles $\alpha$, $\beta$ et $\gamma$ en fonction d'angles connus :

$$ \left\{ \begin{array}{c} \alpha = \widehat{A_1} - \widehat{RAB} \\ \beta = \widehat{B} + \widehat{RBA} \\ \gamma = \widehat{C} - \widehat{ACR} \\ \end{array} \right. $$

Réductions des inconnues (1)

On peut exprimer tous ces angles en fonction d'un seul angle inconnu, choisissons $\widehat{RAB}$.

Considérons le triangle ABR, pour exprimer $\beta$ en fonction de $\widehat{RAB}$ et des angles connus :

Triangle ABR

$$\beta = \widehat{B} + (180 - \theta_1 - \widehat{RAB}) $$

Considérons le triangle ACR, pour exprimer $\gamma$ en fonction de $\widehat{RAB}$ et des angles connus :

Triangle ACR

$$ \begin{array}{l} \gamma = \widehat{C} - (180 - \theta_2 - \widehat{CAR}) \\ \gamma = \widehat{C} - (180 - \theta_2 - (\widehat{A_1} - \widehat{A_2} - \widehat{RAB}))\\ \gamma = \widehat{C} - 180 + \theta_2 + \widehat{A_1} - \widehat{A_2} - \widehat{RAB} \end{array} $$

Nous obtenons alors les équations suivantes :

$$ \left\{ \begin{array}{lc} x = A_x + cos(\widehat{A_1} - \widehat{RAB}) \times t_a & (1)\\ y = A_y + sin(\widehat{A_1} - \widehat{RAB}) \times t_a & (2)\\ \\ x = B_x + cos(\widehat{B} + (180 - \theta_1 - \widehat{RAB})) \times t_b & (3)\\ y = B_y + sin(\widehat{B} + (180 - \theta_1 - \widehat{RAB})) \times t_b & (4)\\ \\ x = C_x + cos(\widehat{C} - 180 + \theta_2 + \widehat{A_1} - \widehat{A_2} - \widehat{RAB}) \times t_c & (5)\\ y = C_y + sin(\widehat{C} - 180 + \theta_2 + \widehat{A_1} - \widehat{A_2} - \widehat{RAB}) \times t_c & (6)\\ \end{array} \right. $$

Ce qui nous fait 6 inconnues $x$, $y$, $\widehat{RAB}$, $t_a$, $t_b$, $t_c$ pour 6 équation indépendantes. Le tour parait joué, "y'a plus qu'à" résoudre le système, et pourquoi pas avec une méthode de Cramer ?

La règle de Cramer ne s'applique qu'aux équations linéaires ! Or ici, nous avons des inconnues dans les fonctions sinus et cosinus.

Résolution

La résolution analytique ne semble pas bien partie, mais essayons quand même de résoudre ce système d'équation au maximum, pour dépendre d'un minimum d'inconnues.

Exprimons $t_b$ et $t_c$ en fonction de $t_a$ à l'aide des équations (1) et (3) puis (1) et (5).

$$ t_b = \frac{A_x - B_x + \cos(\widehat{A_1} - \widehat{RAB}) \times t_a}{ \cos(\widehat{B} + 180 - \theta_1 - \widehat{RAB})} $$

$$ t_c = \frac{A_x - C_x + \cos(\widehat{A_1} - \widehat{RAB}) \times t_a}{cos(\widehat{C} - 180 + \theta_2 + \widehat{A_1} - \widehat{A_2} - \widehat{RAB})} $$

Maintenant, utilisons ces expressions de $t_b$ et $t_c$ dans les équations en y, (4) et (6)

$$ \left\{ \begin{array}{lc} y = B_y + sin(\widehat{B} + (180 - \theta_1 - \widehat{RAB})) \times \frac{A_x - B_x + \cos(\widehat{A_1} - \widehat{RAB}) \times t_a}{ \cos(\widehat{B} + (180 - \theta_1 - \widehat{RAB})} \\ y = C_y + sin(\widehat{C} - 180 + \theta_2 + \widehat{A_1} - \widehat{A_2} - \widehat{RAB}) \times \frac{A_x - C_x + \cos(\widehat{A_1} - \widehat{RAB}) \times t_a}{cos(\widehat{C} - 180 + \theta_2 + \widehat{A_1} - \widehat{A_2} - \widehat{RAB})} \\ \end{array} \right. $$

Sachant que $\tan(x) = \frac{\sin(x)}{\cos(x)}$ et que $\tan(x+180) = \tan(x-180) = \tan(x)$, nous pouvons simplifier légèrement l'écriture.

$$ \left\{ \begin{array}{lc} y = B_y + \tan(\widehat{B} -\theta_1 - \widehat{RAB}) \times [A_x - B_x + \cos(\widehat{A_1} - \widehat{RAB}) \times t_a] \\ y = C_y + \tan(\widehat{C} + \theta_2 + \widehat{A_1} - \widehat{A_2} - \widehat{RAB}) \times [A_x - C_x + \cos(\widehat{A_1} - \widehat{RAB}) \times t_a] \\ \end{array} \right. $$

À partir de là, comme $y=y$ nous pouvons exprimer $t_a$ en fonction de $\widehat{RAB}$.

$$ \begin{array}{rl} C_y - B_y = & \tan(\widehat{B} -\theta_1 - \widehat{RAB}) \times [A_x - B_x]\\ & - \tan(\widehat{C} + \theta_2 + \widehat{A_1} - \widehat{A_2} - \widehat{RAB}) \times [A_x - C_x] \\ & + \tan(\widehat{B} -\theta_1 - \widehat{RAB}) \times \cos(\widehat{A_1} - \widehat{RAB}) \times t_a \\ & - \tan(\widehat{C} + \theta_2 + \widehat{A_1} - \widehat{A_2} - \widehat{RAB}) \times \cos(\widehat{A_1} - \widehat{RAB}) \times t_a \end{array} $$

En isolant les termes contenant $t_a$ :

$$ \begin{array}{rcl} C_y - B_y - \tan(\widehat{B} -\theta_1 - \widehat{RAB}) \times [A_x - B_x] \\ + \tan(\widehat{C} + \theta_2 + \widehat{A_1} - \widehat{A_2} - \widehat{RAB}) \times [A_x - C_x] & = & [\tan(\widehat{B} -\theta_1 - \widehat{RAB}) - \tan(\widehat{C} + \theta_2 + \widehat{A_1} - \widehat{A_2} - \widehat{RAB})] \\ & & \times \cos(\widehat{A_1} - \widehat{RAB}) \times t_a \end{array} $$

Soit :

$$ t_a = \frac{C_y - B_y - \tan(\widehat{B} -\theta_1 - \widehat{RAB}) \times [A_x - B_x] + \tan(\widehat{C} + \theta_2 + \widehat{A_1} - \widehat{A_2} - \widehat{RAB}) \times [A_x - C_x] }{ [\tan(\widehat{B} -\theta_1 - \widehat{RAB}) - \tan(\widehat{C} + \theta_2 + \widehat{A_1} - \widehat{A_2} - \widehat{RAB})] \times \cos(\widehat{A_1} - \widehat{RAB})} $$

Solveur

Maintenant, nous avons toutes les équations, mais en fonction de l'angle $\widehat{RAB}$ choisi, nous trouvons plusieurs positions pour le robot en fonction des équations utilisées. La "bonne" valeur de $\widehat{RAB}$ est celle qui donne le même point qu'il soit calculé avec les équations (1) et (2) ou (3) et (4). Il faut maintenant travailler sur une résolution rapide de ce problème.

Voici un tableur, Calculs de triangulation, pour visualiser les calculs et les résultats.

Capsicum - le robot qui garde le cap !

Elfline, Keuronde — 2023-08-15T20:42:49Z

Ce robot est basé sur l'architecture de 2014, même moteurs, même gyroscope, même base mécanique, même carte électronique.

Le but était de reprendre la compétition en douceur en visant uniquement les actions simples mais en étant capable de les réaliser de manière répétable.

Nous construisons donc Capsicum actionneur après actionneur. Ce qui en résultera sera un tas de baguettes de bois actionnés par des servomoteurs. Un seul actionneur nécessite 2 servomoteurs. Tous nos autres actionneurs utilisent un unique servomoteur. Robustesse, simplicité.

Les résultats

Capsicum se hisse à la 10e place au classement général et nous obtenons le prix de l'éco-conception de la part du Jury. Le choix du jury est principalement motivé par :

la mécanique en bois ;
la carte électronique utilisant des microcontrôleurs peu puissants ;
la simplicité de nos actionneurs.

Stratégie

Le robot sort de sa zone de départ avec sa réplique et attrape la statuette.
Le robot fait tomber les échantillons, les pousse sous l'abri de chantier puis dépose la réplique
Le robot tente de lire et pousse les carrés de fouille. Il tente encore et encore tant que le temps imparti n'est pas écoulé ou qu'il n'a pas réussi à identifier tous les carrés de fouille.
Le robot va à la vitrine et dépose la statuette.
La vitrine s'active et rentre intégralement la statuette dans son enveloppe.
Le robot rentre à sa zone de départ.

Description de la stratégie 2022

Voici la vidéo du second match qui illustre assez bien toutes ces actions.

Match 2 - Coupe de France 2022
La vidéo est disponible en 720p ici (mp4 - 25 Mo).

Électronique

Le robot utilise la carte électronique conçue en 2013 pour le robot 2014. C'est à dire :

Moteurs MFA 919D11:1
Codeurs HEDR-5420-ES21
Gyroscope ADXRS453
Roues Qfix 50 mm
Châssis Contre-plaqué 30x30 cm en 5 mm
Capteurs soniques SRF05

Le tout coordonné par notre carte électronique maison :

Deux microcontrôleurs : dsPIC33FJ128MC802 et un 18F4550
Deux ponts en H, A4950
4 pont en H répartis dans deux L298 (non utilisés)
8 sortie pour servomoteurs
Quelques entrées capteurs

Composants auxquels nous rajoutons un écran e-Ink piloté par un Raspberry Pi Zero.

Carte électronique 2014

La gestion du déplacement a été améliorée tandis que la stratégie a été totalement adaptée. Nous avons rajouté un Raspberry Pi Zéro pour gérer un affichage et gagner en confort de programmation (objectif à demi atteint).

Voici notre "documentation" pour la carte...

Asservissement

Le robot comporte deux niveaux d'asservissement :

Le premier se situe au niveau des roues et des codeurs. La boucle d'asservissement reçoit en entrée une consigne de vitesse pour la roue. L'asservissement compare la vitesse actuelle, obtenue grâce au codeur avec la vitesse consigne. Ce qui détermine l'erreur envoyée à un correcteur PI (proportionnel et intégral).

Le deuxième se situe au niveau de la position. C'est un asservissement polaire, relativement classique pour la Coupe de France de robotique, mais assez peu documenté ailleurs. Le principe est le suivant :
- La distance calculée entre la position réelle et la position souhaitée est appelée erreur de position
- L'angle calculé entre l'orientation actuelle du robot et l'orientation nécessaire pour aller au point consigne en ligne droite est appelé erreur d'orientation.

Ces deux erreurs sont envoyées dans des correcteurs indépendants l'un de l'autre.

Les consignes de vitesse pour les deux moteurs sont obtenues ainsi :

Moteur droit = Commande en distance + commande en orientation
Moteur gauche = Commande en distance - commande en orientation

C'est relativement simple et efficace.

Pour plus de détail, nous recommandons le cours de RCVA.

Déplacement

Construit sur la même base que les robots de 2014 (Rustique) et 2015 (Gousse et petit pois), le robot connaît sa position grâce à un gyroscope et aux roues codeuses montées sur les moteurs. Alors que les robots précédents se déplaçaient avec un système de point de passage, Capsicum est asservi sur une trajectoire continue. À chaque instant, le robot calcule la nouvelle position consigne et l'envoie aux boucles d'asservissement.

Cette année, le principal intérêt est de pouvoir réaliser des courbes plus fluides.

Détection de l'adversaire

Nous savons que nous devons détecter devant et derrière nous. Nous savons également qu'un seul capteur par côté n'est pas suffisant. Le robot précédent disposait d'un capteur avant motorisé qui scrutait successivement à droite, devant et à gauche, et d'un capteur fixe à l'arrière. La détection arrière avait trop d'angles morts.
Pour améliorer le système, nous installons les deux capteurs ultrason côte à côte.

Mais nous souhaitons continuer à n'utiliser que deux capteurs : le code gérait déjà deux capteurs et le nombre d'entrées-sorties disponibles sur la carte électronique du robot se réduisait. Nous fixons les deux capteurs sur un axe qui pivote, les orientant vers l'avant ou l'arrière en fonction du besoin.

Ce système se révélera particulièrement satisfaisant. Tout d'abord la couverture de détection passe de médiocre à bonne. Ensuite le sens d'avancement du robot est donné par l'orientation des capteurs ce qui permet facilement de comprendre si l'obstacle qui le bloque se trouve devant lui, derrière lui ou les deux à la fois.

La détection
La vidéo est disponible en 720p ici (Ogg - 5 Mo).

Affichage du score

Depuis notre dernière participation en 2015, c'est notre première année où nous devons estimer le score du robot. Nous souhaitons faire ça bien et avec élégance.

Affichage du logo

Notre choix porte sur un écran e-ink.

Affichage état du robot

Le seul point qui nous chagrine : le temps nous manque, alors nous le pilotons avec un Raspberry Pi Zero en utilisant les scripts pythons fournis par le fabriquant. Mettre un ordinateur juste pour piloter un écran via une liaison SPI, nous avons vu plus efficace. Mais cela nous permet d'avoir un système fonctionnel avec une jolie police d'affichage.

Affichage du score

Actionneurs

Dépose de la réplique à l'arrière du robot

Un simple servomoteur maintient la réplique (un cube de 58 mm de côté) dans le robot, puis la pousse lorsque le robot est en position.

Actionneur de la réplique - position de maintien

Actionneur de la réplique - position de dépose

Prise et pose de la statuette

La prise et la pose de la statuette se font avec un seul servomoteur. L'astuce résidant plus dans la forme de la statuette que dans l'actionneur en lui-même. La statuette contient un crochet qui permet de la manipuler

Capsicum attrape la statuette

Pousse des carrés de fouille

Un autre servomoteur pousse un doigt qui lui pousse le carré de fouille.

Poussoir rentré

Poussoir sorti

Là où le système se complexifie, c'est que nous avions besoin de longer les murs avec précision. Pour cela, nous avons monté des capteurs infrarouges au-dessus des capteurs pour se recaler à chaque carré de fouille.

Moteur et capteur infra-rouge

Lecture des carrés de fouilles

Notre seul actionneur absolument pas fiable. Soyons honnêtes, nos tests unitaires semblaient prometteurs, mais l'alignement du robot avec la résistance n'a pas été assez bon en match pour arriver à la lire...

Journal de développement

HEXA - Une expérience holonome

Elfline, Keuronde — 2023-07-23T20:45:00Z

HEXA, pour Holonome Experience Xylo Asservi.

Contexte

A l'origine, ce robot est une sorte de défi. Pour se remettre dans le contexte, nous avions de nombreuses participations à la coupe de France de robotique derrière nous. L'année précédente, après 6 ans sans participation, nous partions sur un robot simple, grandement repris des années précédentes, visant les actions faciles.

A notre grande surprise, nous atteignions la 10e place.

Nos particularités : un robot intégralement construit avec des baguettes de bois carrées, une carte électronique qui avait déjà servi sur des anciens robots participants à la Coupe et une base roulante avec 2 roues motrices et une bille folle.

Cette année, nous voulions changer plusieurs choses. Tout d'abord, nous voulions un robot holonome, à trois roues. 3 roues, 3 moteurs, 3 codeurs, nous devions alors remplacer notre carte électronique, non adaptée, et les microcontrôleurs PICs nous avaient montrés ce qu'ils avaient dans le ventre. Monter en gamme dans la même marque ne nous tentait pas, et le Raspberry Pi Pico, le microcontrôleur de la fondation Raspberry Pi nous faisait de l'œil. Nous voici partis sur une nouvelle architecture électronique.

L'an dernier, un peu avant la compétition, nous avons fait l'acquisition d'une scie à chantourner. Celle-ci nous permettra une plus grande liberté dans la conception mécanique de notre robot, les baguettes en bois ayant, parfois, quelques limites.

Au niveau des actions, nous voulions un minimum de spectacle. Nous choisissons d'aspirer les petites balles en mousse qui se trouvent sur le bord du terrain et de les lancer, idéalement, tout ça avec une seule turbine !

Pouvons-nous dire que nous sommes partis de zéro pour concevoir ce robot ? Non, voici ce que nous gardons :

la localisation avec roues codeurs montées sur les moteurs et un gyroscope,
l'utilisation exclusive de microcontrôleurs,
la communication I2C entre nos microcontrôleurs.

Les résultats

Sommes-nous satisfaits des résultats obtenus ? Jamais, ou rarement en tout cas. Pour H.E.X.A. un manque de fiabilité, malgré nos nombreux tests, nous rendra frileux et nous forcera à adopter des stratégies très prudentes. Surtout, nous travaillerons sur la résolution de ce souci plutôt que de tenter des stratégies plus ambitieuses.

Cela n'empêchera pas H.E.X.A de se hisser à la 8e place du classement général.

Si ce classement est au-delà de nos espérances, le spectacle offert par notre robot nous a un peu déçus...

Par contre, nous sommes satisfaits de la réalisation technique, en un an, d'étudier un robot holonome, de le réaliser et de l'asservir honnêtement et proprement. Voici en détail les principales étapes qui nous ont permis de le réaliser. Mais avant, le voici à l'œuvre !

En match

Notre meilleur match est sans aucun doute celui de la 5ᵉ série, le voici :

Match 5 (480p - 14 Mo | 720p - 30 Mo).

La localisation - théorie

Fin août, nous prenons une feuille et un crayon pour comprendre comment le robot peut, à partir des informations des codeurs montés sur les roues, connaître sa position. Dans cette partie, nous ne tenons pas compte du gyroscope (ce qui aurait grandement simplifié le problème).

Il nous faut deux semaines pour comprendre que l'outil adéquat est le tenseur cinématique associé avec la loi du transport des moments. Nous sortons des équations assez indigestes qui se simplifient énormément une fois pris en compte que :

Les trois roues sont à égale distance du centre du robot
Les angles entre les roues sont de 120°

Nommage des angles

Nous publions nos résultats sur le site, localisation d'un robot holonome (partie 1 et partie 2).

La stratégie

Mi-septembre, le brouillon du règlement est publié. Nous dévoilons notre stratégie à deux robots.

Le robot des gâteaux sera imaginé et ré-imaginé, en fonction du temps qu'il nous restait pour ne rester qu'une chimère.

Par contre, toutes les tâches du robot des cerises seront réalisées (et même plus !).

Grâce à cette stratégie, nous identifions nos principaux capteurs et actionneurs et pouvons commencer à travailler sur notre carte électronique

La base roulante

Nous voulons une base roulante tôt dans l'année, car c'est la clé pour avoir un robot qui fait du spectacle.

Mi-octobre, nous avons d'un côté la carte prête à être soudée, de l'autre, les moteurs montés avec les roues sur le châssis provisoire du robot.

Base roulante holonome

Carte Holonome 2023 nue

Malgré cela, il faudra attendre mi-novembre pour faire tourner une roue.

Et une roue qui tourne, ce n'est pas un robot qui se dirige. Codeurs, qui permettent de mesurer précisément les mouvements des moteurs ne seront montés que fin novembre.

Nous en profitons pour réaliser la première boucle d'asservissement : le contrôle en vitesse des moteurs. Cet asservissement marche vraiment bien et permet de faire des trajectoires relativement précises, telles que se déplacer suivant un rectangle :

Tests en boucle ouvertes

Le code pour arriver à ce résultat est de l'ordre de 400 lignes. C'est peu !

Asservissement des moteurs

Une fois les codeurs montés, il s'agit de coder, tester, coder, tester et recommencer.

Nous intégrons ensuite les données du gyroscope dans la localisation du robot. Puis nous commençons à travailler sur le concept de trajectoire et de trajet.

Pour nous, une trajectoire est l'ensemble des positions que le centre du robot va occuper au cours du temps. Il s'agit de droites, d'arcs de cercle ou de courbes de Bézier.

Un trajet est le parcours d'une trajectoire en tenant compte de la vitesse que doit avoir le robot. Le trajet tient compte de :

la distance avant la fin de la trajectoire (pour freiner le robot)
la vitesse actuelle du robot (pour le faire freiner ou décélérer en douceur)
l'accélération maximale du robot pour le trajet
la vitesse maximale du robot pour le trajet

Découper ces deux concepts nous ont permis de vraiment faire des mouvements sympathiques en gardant un code clair.

Architecture logicielle des déplacements

Voici un exemple d'une translation circulaire avec accélération et décélération

Trajectroire circulaire avec accélération contrôlée (720p - 3,3 Mo).

La détection de l'adversaire

Maintenant que le robot bouge, il faut qu'il s'arrête avant de rentrer dans le robot adverse.

La détection de l'adversaire est un sujet difficile pour deux raisons :

L'adversaire n'a pas forcément la forme qu'on s'imagine
Une partie des capteurs sont perturbés par l'environnement de la compétition

Sur les robots précédents, nous utilisions des capteurs à ultrason. Nous avions éprouvé cette solution et connaissions ses limites. Le temps de lecture d'un capteur est relativement long et nous avions cru comprendre que plusieurs capteurs pouvaient se perturber mutuellement. Ce n'est pas gênant avec deux capteurs qui mesurent alternativement. Mais avec le robot holonome, nous avions besoin de détecter tout autour du robot.

C'est donc en nous servant des retours et des conseils des autres équipes que nous partons sur les capteurs VL53L1X de STMicroelectronics pour détecter soit une balise que nous poserions sur l'adversaire, soit l'adversaire lui-même.

Sachant à quel point il peut être compliqué de différencier un problème de logique d'un problème de détection, nous associons à chaque capteur une DEL multicolore qui indique la distance vue par le capteur. Ainsi, un simple coup d'œil nous dit quel capteur détecte un obstacle.

Évidemment, qui dit DEL multicolore, dit arc-en-ciel !

Les capteurs ne nous ont pas déçus ! Nous les avons trouvés précis et fiables. Leur seul point noir est qu'ils partagent tous la même adresse I2C au démarrage et qu'ils sont amnésiques : dès qu'ils sont désactivés, ils perdent leur configuration...

L'évitement

C'est vraiment la partie sur laquelle nous n'avons pas pu travailler sérieusement cette année. Pour être précis, la partie que nous n'avons pas pu intégrer. Car nous avions commencé à travailler l'évitement que sur le mois de la Coupe.

Nous envisagions plusieurs niveaux d'évitement :

Le robot s'arrête, s'il détecte un obstacle, repart si l'obstacle disparaît.
Le robot s'arrête et repart en sens inverse sur la même trajectoire.
Le robot s'arrête et repart vers une autre cible
Le robot contourne l'obstacle

Les trois premiers niveaux décrits ci-dessus étaient fonctionnels. Nous avions une idée assez précise de comment nous y prendre pour contourner l'obstacle mais faute de temps, nous ne l'avons pas implémenté.

La programmation

La programmation de ce robot sera pour nous l'occasion de découvrir le microcontrôleur Rapsberry Pi Pico. Nous publions 4 articles, qui sont nos aide-mémoires, sur le développement pour ce microcontrôleur :

Nous publions également un fichier Readme avec notre dépôt de code qui détaille la structure du code.

Enfin, nous avons un article dédié au calcul de la consigne de vitesse du robot : Consigne de vitesse.

Globalement, la programmation a bien représenté 75% du travail sur ce robot...

Les capteurs et actionneurs

L'aspiration

Pour marquer des points, nous avions décidé d'aspirer et de lancer les balles (appelées cerises dans le règlement). Pendant plusieurs mois, nous avons cherché une conception de trompe qui permettrait d'aspirer les balles et les faire sortir du flux d'air sans arrêter la turbine. Après de nombreux échecs, nous nous sommes rabattus sur une trompe reliée à une chambre mise en dépression par une turbine.

Système d'aspiration des cerises

Aspiration cerises : démontée

La chambre de stockage est faite en medium et la trompe avec un tube de carton et une buse en papier mâché.

Prototype pour l'aspiration

La chambre, en aval, est fermée par une porte. Cette porte permet aussi au robot de "doser" les balles qui sortent.

La rampe

En sortie de cette chambre, les balles sont guidées par une rampe faite en fil de fer soudé à l'étain. La réalisation a été non-conventionnelle mais pas particulièrement longue. Nous avons d'abord fixé deux grands morceaux de fil de fer sur le robot à l'aide de pâte-à-fixe ; qui a permis d'ajuster leur position. Ensuite, à l'aide de la troisième main, nous soudons les renforts.

Rampe pour les balles

Rampe montée

Cerises sur la rampe

Le propulseur

Enfin, les balles sont éjectées par le propulseur : un ensemble de deux moteurs avec des petites roues et un guide imprimé en 3D. Théoriquement c'est beau ! Mais en pratique, les moteurs du propulseur ne sont pas très puissants et perdent beaucoup d'inertie à chaque envoi de balle. C'est pour cela que nous avions travaillé sur la porte doseuse. L'ensemble a bien fonctionné avec un taux de réussite d'envoi des balles en match de 100% ! Son inconvénient, c'est qu'avec le dosage des balles, il fallait près d'une seconde par balle, soit 26 secondes juste pour l'envoi des balles lors de notre 5ᵉ match (et nous avions l'ambition d'envoyer bien plus de balles...).

Moteurs du propulseur

Et la modélisation 3D du guide qui expédie les balles avec le bon angle :

Modélisation propulseur

Propulseur monté

Le bras

Bricolé pendant la dernière nuit de la coupe de France de robotique, nous installons un bras qui nous permet de pousser 2 "gâteaux" sur une de nos assiettes. Ce petit accessoire, composé d'un servomoteur et d'une baguette de bois, nous rapportera 6 points lors du dernier match.

Les contacteurs

Pour faire fonctionner tout ça, quasiment aucun capteur. Les seuls présents sont les contacteurs qui permettent au robot de détecter ou de longer une bordure ou de recaler la position du robot.

Contacteurs pour longer les murs

Recalage du robot

L'affichage du score

Pour l'affichage du score, nous repartons comme l'an dernier sur un écran e-ink (ou écran à encre électronique).

Cette technologie présente deux avantages :

L'écran est très lisible
L'écran affiche une image même non-alimenté

L'an dernier, nous nous servions d'un ordinateur pour piloter cet écran à l'aide des scripts d'exemple en Python. Mais cette année, nous voulons nous passer de l'ordinateur. Nous essayons les codes de démo avec succès. Là où les choses se corsent, c'est qu'il n'y a pas de fonction de démo fournie pour charger une image partielle. Or nos beaux caractères d'affichage du score sont justement des images.

Il faut alors développer en parallèle :

la fonction pour charger une image
un système pour convertir une image bitmap en données binaires

Et quand le résultat n'est pas celui attendu, difficile de savoir d'où vient le problème.

Nous nous arrêtons dès que nous arrivons à afficher une image en noir et blanc. L'écran supporte 2 nuances de gris supplémentaires que nous ne prendrons pas en charge.

Affichage de 22 points !

Le déguisement

Le déguisement n'est venu compléter le robot que dans les dernières semaines avant la coupe. Le but était de transformer notre robot en aubergine (cf le nom de notre équipe).

Un système de fils relié à un servomoteur pour faire dérouler les tissus.

Actionneur du déguisement

Déguisement déplié

Prototype déguisement (1080p - 2 Mo).

Journal de développement

Raspberry Pi Pico - S'installer avec VS Code

Keuronde — 2023-01-15T21:05:54Z

Vous avez votre éditeur de texte d'un côté, votre terminal de l'autre, vous arrivez à compiler et programmer votre Raspberry Pi Pico. Maintenant, vous aimeriez avoir un projet plus conséquent avec plusieurs fichiers, un moyen simple de naviguer d'une fonction à l'autre, bénéficier de l'autocomplétion et peut-être même d'un raccourci clavier pour compiler votre code.

Bref, vous souhaitez un environnement de développement intégré. Le script d'installation de la fondation Raspberry Pi installe VS Code, alors essayons avec celui-là !

Installation

Nous n'allons pas grandement détailler l'installation de VS Code, prenez-le à partir de vos dépôts ou à partir de leur site ou même Codium (recommandé mais non testé).

Une fois installé, lancez-le, et utiliser le menu "Fichier" pour "ouvrir le dossier", celui de votre projet.

Ouvrez le gestionnaire d'extension et ajoutez les trois extensions recommandées par la Fondation RPi :

marus25.cortex-debug
ms-vscode.cmake-tools
ms-vscode.cpptools

Compilation

La première difficulté est de compiler votre projet. VS Code est hautement configurable et contient un grand nombre de tâches pré-configurées. Cependant, nous n'avons pas trouvé de configuration par défaut qui s'adapte à notre projet.

Nous créons donc le fichier tasks.json dans le répertoire .vscode que VS Code aura probablement créé dans votre répertoire de travail. Sinon, créez-le. Nous créons deux tâches pour l'exemple, make et make Flash :

.vscode/tasks.json { "tasks": [ { "type": "shell", "command": "cd build; cmake ../; make", "label": "CMake in build/", "problemMatcher": [], "group": { "kind": "build", "isDefault": false } }, { "type": "shell", "command": "cd build; cmake ../; make Flash", "label": "CMake & Flash", "problemMatcher": [], "group": { "kind": "build", "isDefault": true } } ], "version": "2.0.0" }

En très bref :

command : la commande shell à lancer
label : le nom qui apparaît dans VS Code

Pour en profiter, utilisez le raccourci MAJ+F9 pour faire apparaître le menu des tâches, vous devriez trouver les vôtres rapidement. Rapidement, la tâche se trouve en premier de la liste, et un simple appui sur Entrée vous permet de compiler et Flasher votre Raspberry Pi Pico.

Problèmes d'analyse et auto-complétion

L'auto-complétion, cette fonction qui permet de compléter un mot que vous avez commencé à écrire, s'enclenche avec CTRL+Espace lorsque vous écrivez votre code. Si vous essayez, vous remarquerez rapidement que les fonctions du SDK ne sont pas reconnues.

Pire, l'analyse du code vous remonte plein de problèmes qui n'en sont pas. Prenez par exemple cette capture d'écran.

Erreurs d'analyse dans VS Code Exemple d'erreurs remontées par VS Code lors de la programmation pour Raspberry Pi Pico

Si vous avez lu notre article sur la création d'un projet Raspberry Pi Pico, notamment notre mot sur les bibliothèques du SDK, vous savez que les fichiers include sont éparpillés dans le SDK. Pour indiquer à VS Code où trouver les fichiers include, nous utilisons ce long fichier c_cpp_properties.json

c_cpp_properties.json { "env": { "myDefaultIncludePath": [ "${workspaceFolder}", "${workspaceFolder}/build", "${env:PICO_SDK_PATH}/src/**/include", "${env:PICO_SDK_PATH}/build/generated/pico_base" ], "myCompilerPath": "/usr/bin/arm-none-eabi-gcc" }, "configurations": [ { "name": "Linux", "intelliSenseMode": "linux-gcc-arm", "includePath": [ "${myDefaultIncludePath}", "${workspaceFolder}/build/" ], "compilerPath": "/usr/bin/arm-none-eabi-gcc", "cStandard": "c11", "cppStandard": "c++17", "browse": { "path": [ "${workspaceFolder}" ], "limitSymbolsToIncludedHeaders": true, "databaseFilename": "" }, "configurationProvider": "ms-vscode.cmake-tools" } ], "version": 4 }

Graphs

Le pluging Teleplot de VS Code est particulièrement adapté à afficher des graphiques ou afficher clairement des états renvoyés par la carte. Nous recommandons fortement la lecture de la courte documentation sur les trames à envoyer.

VS Code avec Teleplot

Le pluging offre aussi un terminal série rudimentaire, ce qui permet d'envoyer des commandes et de visualiser les résultats sans jongler entre les fenêtres !

Git

Nous supposons que vous utilisez git pour vos projets et, si ce n'est pas le cas, nous vous le recommandons fortement. VS Code gère git, mais sans le fichier .gitignore qui va bien, tous vos fichiers de build apparaissent comme modifiés, comme dans l'image ci-dessous.

Trop de fichiers modifiés !

Nous conseillons donc la création d'un fichier .gitignore qui exclue le repertoire build de git, comme ceci :
.gitignore build/

Enregistrez et admirez votre vue "contrôle de code source" se simplifier grandement !

Voilà ! Avec ceci vous êtes confortablement installés avec VS Code pour programmer sur votre Raspberry Pi Pico !

Raspberry Pi Pico - Installer l'environnement de développement C/C++ sur Debian 11

Keuronde — 2022-12-26T16:16:23Z

La fondation Raspberry Pi fournit un script pour installer l'environnement de développement du Raspberry Pi Pico sur un Raspberry Pi. Ce script est livré sans garantie pour les autres plateformes. L'idée est d'analyser le script pour récupérer les morceaux essentiels pour un développement sur Debian 11 Bullseye.

En pré-requis, l'utilisateur courant doit avoir accès à sudo. L'utilisateur doit être dans le groupe dialout pour accéder à \dev\ttyAMA0 - mais ceci ne sera pas utile pour cette étape.

Ceci en trois étapes :

L'installation du compilateur.
L'installation du SDK pour le développement en C/C++.
L'installation du Picotool qui permet de programmer le Rpi Pico.

Installation du compilateur

Les paquets requis pour la compilation sont :

cmake
gcc-arm-none-eabi
gcc
g++

Mais nous installons à cette étape :

git : nécessaire pour obtenir le SDK, le Picotool et recommandé pour le développement
libusb-1.0-0-dev : nécessaire pour la compilation de Picotool
cutecom : notre gestionnaire de liaison série préféré.

La commande complète est :

sudo apt install git cmake gcc-arm-none-eabi gcc g++ cutecom libusb-1.0-0-dev

Attention : La commande télécharge et installe 2,2 Go de programmes. Elle prend un peu de temps...

Installation du SDK

Créez un dossier pour le SDK, pico-sdk par exemple, et faites-en votre répertoire de travail. À partir de là, téléchargez le projet et ses dépendances avec git :

Téléchargement du SDK git clone -b master --depth 1 https://github.com/raspberrypi/pico-sdk.git --shallow-submodules . git submodule update --init

Les options —depth 1 et —shallow-submodules évitent de télécharger l'historique du projet. Mais nous avons téléchargé 2,2 Go à l'étape précédente...

Il faut encore initialiser la variable d'environnement qui va bien :

Variable d'environnement echo "export PICO_SDK_PATH=$(pwd)" >> ~/.bashrc source ~/.bashrc

Compilation et installation du Picotool

Créez un dossier pour le code du Picotool, picotool par exemple, et faites-en votre répertoire de travail. À partir de là, téléchargez le projet :

Téléchargement du code du picotool git clone -b master --depth 1 https://github.com/raspberrypi/picotool.git .

Compilez-le :

Compilation du picotool mkdir build cd build cmake .. make

Et installez-le :

Installation du picotool sudo cp picotool /usr/local/bin/

Suite à une évolution du SDK, la compilation de votre programme testera systématiquement la présence du picotool. Dans le cas où il ne trouve pas le Picotool, il va le recompiler. C'est long et pas nécessaire. On peut lui donner l'endroit où nous avons compilé le Picotool pour éviter ce désagrément.

Variable d'environnement echo "export PICOTOOL_FETCH_FROM_GIT_PATH=$(pwd)" >> ~/.bashrc source ~/.bashrc

Note : D'après la documentation, il vaut mieux utiliser la variable picotool_DIR, mais chez nous l'utilisation de cette variable restait sans effet.

Vous êtes maintenant prêts ! Vous pouvez créer votre premier projet !

Notons que le script de la fondation installe aussi OpenOCD, Visual Studio Code et des plugins, un SDK avec des fonctions non finalisées (pico-extra) et des exemples (pico-example et pico-playground) et picoprobe qui permet de deboguer un Rpi Pico avec un autre Rpi Pico.

Raspberry Pi Pico - Créer son projet C/C++

Keuronde — 2022-12-26T16:16:18Z

Pré-requis : avoir installé le SDK du Raspberry Pi Pico et avoir un répertoire vide pour le projet.

Les grandes étapes :

S'assurer de que PICO_SDK_PATH pointe bien vers le SDK
Copier le fichier pico_sdk_import.cmake dans le répertoire du projet
Utiliser un CMakeLists.txt "minimal"
Répertoire de build : mkdir build ; cd build

Vérification du PICO_SDK_PATH

Le plus simple :

echo $PICO_SDK_PATH /home/.../Projets/RpiPico/pico/pico-sdk

Si la variable n'est pas définie, l'une des solutions est d'éditer votre fichier .bashrc et de rajouter, en fonction de votre installation :

~/.bashrc export PICO_SDK_PATH=/home/.../Projets/RpiPico/pico/pico-sdk

Copier le fichier pico_sdk_import.cmake dans votre projet

Rien de sorcier, tant que vous savez où trouver votre fichier :

À la racine de votre projet cp $PICO_SDK_PATH/external/pico_sdk_import.cmake .

Fichier CMakeLists.txt

Ceci n'est pas le CMakeLists.txt minimal, mais celui que nous utilisons. Il contient deux ajouts :

L'ajout de la cible Flash, pour compiler et programmer le Rpi Pico d'une seule commande
- Merci à @madahin [Sharp'Attack] pour son aide avec cmake !
La suppression de la conversion automatique des '\n' en '\r\n'.

CMakeLists.txt cmake_minimum_required(VERSION 3.13) # Requis pour initialiser les variables liées au SDK du Rpi Pico include(pico_sdk_import.cmake) project(MonProjectRpiPico C CXX ASM) set(CMAKE_C_STANDARD 11) set(CMAKE_CXX_STANDARD 17) pico_sdk_init() # add_executable : nom de l'executable "MonExecutableRpiPico" suivi des fichiers à compiler. add_executable(MonExecutableRpiPico MonFichierSource.c ) # printf vers USB CDC, pas vers l'UART pico_enable_stdio_usb(MonExecutableRpiPico 1) pico_enable_stdio_uart(MonExecutableRpiPico 0) # Requis pour générer le .uf2 pico_add_extra_outputs(MonExecutableRpiPico) # Notre projet suivi des librairies appelées, notamment celles du SDK. target_link_libraries(MonExecutableRpiPico pico_stdlib) # Ajout de la cible Flash, qui programme le Rpi Pico après avoir add_custom_target(Flash DEPENDS MonExecutableRpiPico COMMAND sudo picotool load -f ${PROJECT_BINARY_DIR}/MonExecutableRpiPico.uf2 ) add_compile_options(-Wall) # Suppression de la conversion automatique LF -> CRLF add_definitions(-DPICO_STDIO_ENABLE_CRLF_SUPPORT=0)

Répertoire de compilation

Enfin, parce que c'est une bonne pratique et qu'éviter de mélanger les fichiers de compilations avec les fichiers sources est une très bonne idée. Et surtout qu'avec cmake, vous allez obtenir 247 répertoires et 501 fichiers - uniquement pour le code de démonstration...

À la racine de votre projet mkdir build

Testez !

Copier l'un des fichiers d'exemple, comme hello_usb.c ou blink.c dans votre fichier MonFichierSource.c.

Entrer dans le répertoire de compilation, actualiser votre chaîne de compilation et compilez :

Compilation cd build/ cmake .. make Flash

Si votre Pico est en mode BOOT ou a l'USB d'activé, vous devriez le reprogrammer avec succès.

Un mot sur les bibliothèques du SDK

Ce qui suit est grandement extrait de 'Raspberry Pi Pico C/C++ SDK'.

Chaque bibliothèque du SDK est considérée comme une interface au sens de cmake. Elle contient notamment :

Les fichiers "include"
Les fichiers sources
Les options de compilation

Par rapport à des bibliothèques pré-compilées, ceci permet avec un seul dépôt de code, de compiler les bibliothèques avec différentes options, d'obtenir les bibliothèques personnalisées pour notre puce, sans code "mort" qui traîne dans la bibliothèque embarquée et sans impacter les autres projets.

Cette modularité a un coût, chaque bibliothèque doit être ajoutée dans le CMakeLists.txt, en plus des #include à rajouter dans le code. Les noms des modules à rajouter dans le CMakeLists.txt sont indiqués dans Raspberry Pi Pico C/C++ SDK, dans 4.1. Hardware APIs et les autres titres 4.x. Pour les noms exacts des fichiers .h à mettre dans les #include, ils sont parfois précisés dans la documentation Doxygen du SDK.

Le SDK dans le détail

Rajouter un module dans la liste target_link_libraries ajoute un chemin où chercher les #include. Par exemple, ajouter hardware_pwm, rajoutera le chemin :

$PICO_SDK_PATH/src/rp2_common/hardware_pwm/include/

Vous le trouvez avec la commande find $PICO_SDK_PATH/src -name "hardware_pwm"

En regardant le contenu du répertoire, vous trouverez les noms des includes :

tree $PICO_SDK_PATH/src/rp2_common/hardware_pwm/include/ └── hardware └── pwm.h

Donc vous devrez inclure "hardware/pwm.h" pour compiler vos fichiers utilisant les fonctions PWM.

Raspberry Pi Pico - La documentation

Keuronde — 2022-12-26T16:16:11Z

Récapitulons les documentations utiles pour développer sur le Raspberry Pi Pico.

Bien évidemment, nous vous conseillons nos articles pour installer l'environnement de développement et créer son projet. Mais ceci ne vous suffira pas.

Vous avez la documentation en PDF de la fondation Raspberry Pi.

Le guide de démarrage rapide ;
La fiche technique du Rapsberry Pi Pico (la carte) ;
La fiche technique du RP2040, c'est le principal document pour comprendre le fonctionnement du RP2040.
La documentation du SDK en C/C++ ou son pendant en python ;
La FAQ ne nous a pas été utile, mais ne pas la lire est certainement une erreur.

Mais la documentation PDF, notamment pour le SDK, ne couvre pas tout. Si vous souhaitez plus de détails, notamment sur les fichiers d'entête à inclure, documentation Doxygen du SDK pourra vous aider (mais les entêtes ne sont pas précisés pour toutes les fonctions).

En plus vous avez les différents fichiers Readme des projets de la fondation Raspberry Pi :

pico-sdk : le SDK stable
pico-examples : les exemples du SDK stable.
pico-extras : le SDK non-stable
pico-playground : les exemples du SDK non-stable.

Nous contacter

Keuronde — 2022-11-20T17:25:16Z

Nous sommes souvent présents sur le forum de planète sciences que ce soit dans la partie "Coupe de France de Robotique" ou "Robotique / Robotic".

Mais si vous souhaitez nous contacter à propos d'un de nos projets ou à propos de ce site, le plus simple est de nous laisser un message ci-dessous.

"Robot en Carton" par Droop

Keuronde — 2022-09-10T18:36:48Z

Toi

Tu es bizarre, tu t'habilles comme un arbitre de Planète Sciences, mais tu poses ton robot sur les tables de match, qui es-tu ?

Je m'appelle Rémi, mais réponds également au surnom de Droop. Je suis passionné de robotique et je participe à la coupe depuis de nombreuses années.

Comment en es-tu arrivé là ?

Je suis ingénieur diplômé de l'UTT (Université de Technologie de Troyes). J'y ai passé de très bonnes années, c'est dans ce cadre que j'ai participé à la coupe de France de Robotique pour la première fois.

Et ta première participation s'est bien passée ?

Lors de ma première année, le club de l'école s'est classé 5ᵉ, c'était sur Funny Golf. Mais je n'étais pas encore dans le club.

Quand j'ai rejoint le club, tous les membres de l'équipe précédente étaient partis. Je me suis retrouvé tout seul avec les carcasses des robots. Pas de plan électronique des cartes, pas de code des programmes, pas de documentation. Juste des carcasses de robots et moi...

Alors j'ai appelé quelques copains à l'aide qu m'ont dit "On n'y connaît rien !". Je leur ai répondu : "C'est pas le problème !".

Pour notre première participation, nous avions bien travaillé nos actionneurs et fait la base roulante au dernier moment, nous n'avons pas réussi à nous homologuer.

La seconde année, nous nous sommes homologués et avons pu faire 3 matchs sur les 5.

Ça, c'était il y a quelque temps, et maintenant ?

Maintenant, après avoir fini mes études de mécanique, je suis informaticien dans les ERPs pharmaceutiques.

Je fais un robot tout seul, sans structure ni sponsor, pour mon plaisir personnel.

Toi et Planète Sciences

Mais ce n'est pas ta seule contribution à la Coupe de France de Robotique ?

Non, je fais aussi partie de Planète Science qui organise l'évènement ! Pour la Coupe 2022, j'étais impliqué dans la commission règlement. Il s'agit de rédiger le règlement pour la compétition, mais aussi de prendre en compte les retours des équipes après la publication du brouillon en septembre.

Pendant la coupe, il s'agit d'homologuer les robots, d'encadrer les matchs et de répondre aux arbitres lorsque des situations inhabituelles se présentent.

Tu parles de la rédaction du règlement, comment sont pris en compte les retours des équipes ?

Nous nous réunissons en commission pour étudier les demandes des équipes. Lorsque nous étudions les propositions des équipes nous faisons particulièrement attention à deux points :
– Est-ce que cela va favoriser une équipe ?
– Est-ce que cela va déséquilibrer les actions ?

Parle-nous un peu plus du règlement, que penses-tu de celui de cette année ?

C'était un règlement assez compliqué avec beaucoup d'actions.

Le ramassage des échantillons demandait 3 traitements de ramassage : les échantillons au sol, les échantillons sur les distributeurs horizontaux et les échantillons sur les distributeurs verticaux. Une fois ramassés, ces échantillons pouvaient marquer des points de 3 manières différentes, sur la galerie, sous l'abri de chantier ou dans la zone de départ.

Il est probable que l'an prochain, le règlement soit plus simple.

Cela fait plusieurs années que les robots marquent des points en revenant à leur zone de départ, pourquoi ?

La raison est assez simple, c'est pour dégager la table pour l'autre équipe !

Ton robot

D'où est venue l'idée d'avoir un robot des arbitres ? Avant n'était-ce pas une boite en carton avec un mât balise ?

Ça pouvait aussi être un robot d'une équipe qui avait déjà joué son match, mais c'était trop aléatoire. L'équipe n'était pas prête, ou son robot plantait et allait perturber l'autre équipe.

En 2020, les conditions pour la coupe ont été très particulières. Les équipes sont arrivées le mercredi pour s'homologuer, normalement. Le jeudi, le confinement est annoncé pour le soir même. Dans la même journée, Planète Science organise 3 séries de matchs et les phases finales.

Il y a moins d'équipes et les séries comptent toutes un nombre impair d'équipes. C'est là que nait l'idée d'avoir un robot pour les arbitres. Car jouer un match contre un simple carton, c'est parfois décevant !

Parlons un peu de ton robot, il est vraiment en carton ?

Pas uniquement, la structure est en bois, la carrosserie en carton et toute la mécanique un peu précise est imprimée en 3D. Ça comprend les supports moteurs, les supports des roues codeuses et les actionneurs.

Qu'est-ce qu'il fait comme actions ton robot ?

Le robot en carton pousse un carré de fouille, le numéro 2, celui qui est toujours de la couleur de l'équipe. Ensuite, il se dirige vers l'abri de chantier, il attrape la statuette puis il dépose la réplique.

Ensuite, il fait tomber les échantillons avec ses petits bras, les expulse sous l'abri de chantier puis il se dirige vers la vitrine pour déposer la statuette.

Enfin, il fait tomber l'échantillon à côté de la vitrine et rentre dans sa zone de départ.

Tu avais une stratégie particulière ?

Oui, le but est de ne pas perturber l'équipe adverse, donc de prendre les points qui étaient réservés à l'équipe.

De quoi es-tu le plus fier sur ton robot ?

C'est certainement d'être officieusement classé 21ᵉ (ou 20ᵉ) !

Tu as un composant particulier de ton robot à mettre en valeur ?

Oui, le convoyeur d'échantillons ! Plutôt que d'attraper les hexagones, de les retourner puis de les déposer, le convoyeur leurs faits traverser le robot ! Et au lieu de retourner les échantillons, c'est le robot tout entier qui se retourne !

En voici une vidéo lors des essais :

Traitement échantillons - Robot en Carton 2022
La vidéo est disponible en 720p ici (mp4 - 12 Mo) et en 1080p ici (mp4 - 34 Mo).

Divers

Tu as des projets en ce moment ?

Pour Planète Sciences, je travaille sur la rédaction du prochain règlement. Je commence aussi à réfléchir à la base roulante du prochain robot en carton, ce sera certainement une base holonome.

À côté de ça, j'ai un robot filoguidé pour explorer les terriers.

Tu as un conseil à donner ?

Venez ! Venez à la coupe !

Mais aussi "KISS : Keep it simple !", il vaut mieux un robot qui soit fiable qu'un robot qui fait tout.

Un message à faire passer ?

Il faut que les équipes s'organisent autrement ! Le planning pour un robot, ça devrait plutôt être : CAO en novembre, base roulante en décembre et un robot monté en février !

Un mot pour la fin ?

Lapin !

Merci de nous avoir consacré ton temps pour cette interview !