Poivron Robotique

Protocole de message et nouveau PAMI

2026-01-14T20:30:24Z

Protocole de messages

Finalement, nous avons repris le protocole de message. Nous avons maintenant deux couches bien séparée, la partie protocolaire et messagerie. Pour le protocolaire, la trame est composée ainsi :

2 octets de début : 0xFF 0xFF
1 octet pour la taille du message
Les données
1 octet de fin 0x00

Côté applicatif, nous gardons 3 types de messages :

Demande de donnée
Envoi de son état
Envoi d'une commande

PAMI

C'est pas encore vraiment un PAMI, c'est à dire qu'il n'est pas pressenti pour participer à la coupe de France de Robotique, même s'il suit le règlement.

L'idée c'est de testé les servomoteurs Feetech pour la propulsion et vérifier si on peut appliquer notre architecture de code de déplacement à ces servomoteurs.

Voici la modélisation 3D :

Modélisation PAMI 2026

Et le début de la réalisation mécanique :

PAMI 2026 - en construction

PAMI 2026 à côté de son grand frère

Performance et protocole de communication (USB)

2025-12-02T20:23:05Z

HID

Nous avons travaillé sur la lecture d'une manette USB, qui serait vraiment pratique pour piloter un robot. Nous sommes tombés sur un os, tout bête, mais qui nous a fait perdre du temps. TinyUSB prévoit par défaut 256 octets pour le descripteur HID. Et il nous a fallu un peu de temps pour trouver cette limite et réaliser que notre descripteur faisait 499 octets...

Bref, nous reportons notre code sur l'HID à plus tard.

Performances brutes

Nous reprenons alors nos essais de performances avec un Raspberry Pi Pico en client. La différence de résultats, entre un PC hôte et un Raspberri Pi Pico hôte, est notable :

Performance USB CDC - 1 seul périphérique

Dans le cas du Raspberri Pi Pico hôte deux choses nous surprennent :

Le pic de vitesse pour des paquets de 120 octets dépasse celui de l'ordinateur.
La vitesse s'effondre lorsque la taille du paquet augmente pour se stabiliser à 70 ko/s

Quand nous regardons le temps passé pour émettre le message, nous nous apercevons d'un temps qui augmente par palier de 1 milliseconde à chaque bloc de 64 octets.

Temps pour envoyer un message

Nous supposons qu'il y a quelque chose dans TinyUSB qui est responsable de ce temps d'attente, mais sans certitude.

Le découpage des messages

La réception des messages est un point assez sensible. Avec l'I2C, nous n'avions pas de soucis. Une trame I2C, délimitée par le bit de stop et le bit de fin, contenait un seul message : une réception, un message, un traitement. Facile ! ou presque...

Avec l'USB, ou d'autres protocoles modernes comme l'UDP, la trame reçue peut contenir plusieurs messages. Elle peut ne pas contenir le début du 1er message, ni la fin du dernier message.

Notre première étape est de stocker les données reçues (avec tuh_cdc_read()) dans un tampon tournant avec :

un pointeur vers où écrire les prochaines données ;
un pointeur vers où lire les données.

Enfin, nous avons un protocole qui défini différents messages, répartis en 2 familles :

Les messages ASCII, commencent par '>' et se terminent par '\n'
Des messages binaires, commencent par 'r', 'w' ou 'd'. leur entête donne leur taille et ils se terminent tous par '\0'

Nous recopions le tampon tournant vers un tampon normal pour l'analyser. Ce tampon est parcouru afin de détecter un caractère de début. Une fois le caractère de début détecté, la suite est parcourue jusqu'à trouver le caractère fin et sa position. Dans le cas des messages binaires, cette position est comparée avec celle déduite de la taille du message. Évidemment, à chaque étape, il faut prévoir le cas où nous arrivons à la fin du tampon.

Lorsqu'un message complet est détecté, celui-ci est ajouté à une pile de message qui sera traitée. Le pointeur de lecture du tampon tournant est mise à jour.

Honnêtement, nous nous sommes un peu emmêlé les pinceaux sur cette partie. Ce serait à refaire, nous ferions autrement. L'avantage de notre méthode est la simplicité d'envoi et de détection d'un message de texte. L'inconvénient est qu'avoir plusieurs types de message multiplie les codes de détection des messages, complexifiant l'architecture globale.

Cet art de découper les message s'appelle le framing. L'une des difficultés est le caractère de fin du message qui pourrait être contenu dans le corps du message (sauf à envoyer des données en ASCII). Deux options que nous avons étudiées mais pas retenues :

L'une des solutions (byte stuffing / bourrage d'octets) consiste à doubler chaque valeur qui serait une valeur de fin de message, sauf dans le cas où il s'agit réellement de la fin du message
L'autre, Consistent Overhead Byte Stuffing (COBS), consiste à se brider à des messages de 254 octets et à choisir une valeur arbitraire pour la fin du message (généralement 0). Le protocole commence le message par la position du prochain octet ayant la valeur de fin de message. Si c'est la fin du message, la valeur ne sera pas altérée. Sinon, cette valeur est remplacée par la position du prochain caractère qui vaut la valeur de fin de message. Les exemples de Wikipédia sont très parlant.

Merci à @madahin[Sharp'Attack] et à Wix [Girafes] (Legend) pour ces découvertes !

Une évolution possible / probable serait d'utiliser un entête commun à tous nos messages et de terminer le message par une somme de contrôle et un caractère de fin de message.

Bref, ce n'est pas la partie dont nous sommes le plus fier et mettre ceci au point nous a causé bien des soucis. À tel point que nous avons eu recours à un débogueur pour Raspberry Pi Pico, ce qui fut l'occasion pour nous d'écrire notre article de prise en main du débogueur.

Partie applicative

Nous fonctionnons uniquement avec des états. Chaque carte envoie à l'hôte USB ses données. L'hôte USB dispose d'une mémoire par carte périphérique et stocke les données reçues en écrasant les précédentes.

Les périphériques peuvent envoyer une demande de lecture, en indiquant l'adresse de la carte, l'adresse du registre à lire et la taille des données demandées. L'hôte répond en envoyant les données stockées.

Après ces efforts nous avons testé le protocole pendant 3h30 avec d'un côté une carte qui lit un capteur de distance, de l'autre une carte qui allume ou éteint une DEL en fonction de la distance du capteur et au milieu notre hôte (ce à quoi nous pourrions rajouter le Pico qui nous servait de sonde de débogage, pour décrire le bazar...). Bref le test fut enfin concluant !

Servomoteurs Feetech

2025-08-13T09:08:03Z

Dans le cadre de nos activités avec le Club Robotique de Riom, nous avons été amené à tester les servomoteurs Feetech. Nous proposons une documentation sur le site de Robot Maker.

Une copie au format PDF est disponible ici, au cas ou...

Bonne lecture

L'USB et la carte SD

2025-07-11T18:55:52Z

C'est Robotronik Phelma qui nous a aiguillé vers les cartes SD à la coupe. Alors, nous prenons notre moteur de recherche favori trouvons deux-trois informations prometteuses sur les cartes SD :

Nous pouvons communiquer avec le protocole SPI. C'est un protocole parfaitement supporté par le Rapsberry Pi Pico ;
Les cartes SD ont aussi un protocole plus évolué, le SDIO ;
Nous trouvons un projet, qui implémente le protocole SDIO grâce aux modules PIO du Rapsberry Pi Pico : no-OS-FatFS-SD-SDIO-SPI-RPi-Pico.

Le protocole SDIO ressemble au protocole de communication SPI, avec 4 lignes de données et des commandes normalisées pour commander la carte SD (probablement les mêmes qu'en SPI). C'est surtout une vitesse de transfert 4 fois plus élevée pour la même fréquence d'horloge qui nous intéresse. Vous trouverez assez facilement des documents décrivant le protocole SDIO, En voici un au hasard.

Concernant le projet no-OS-FatFS-SD-SDIO-SPI-RPi-Pico, le README est particulièrement encourageant : il annonce des vitesses de lecture et d'écriture supérieures à 10 Mo/s. Maintenant, nous voulons tester ça !

Adaptateur de carte SD

Côté brochage de la carte, nous n'arrivons pas à trouver la description dans la norme, mais de nombreux sites proposent tous le même brochage, que voici :

Brochage carte SD

C'est un commentaire dans le code qui nous explique comment raccorder l'adaptateur SD avec le microcontrôleur :
Extrait de simple_sdio/main.c (no-OS-FatFS-SD-SDIO-SPI-RPi-Pico) /* SDIO Interface */ static sd_sdio_if_t sdio_if = { /* Pins CLK_gpio, D1_gpio, D2_gpio, and D3_gpio are at offsets from pin D0_gpio. The offsets are determined by sd_driver\SDIO\rp2040_sdio.pio. CLK_gpio = (D0_gpio + SDIO_CLK_PIN_D0_OFFSET) % 32; As of this writing, SDIO_CLK_PIN_D0_OFFSET is 30, which is -2 in mod32 arithmetic, so: CLK_gpio = D0_gpio -2. D1_gpio = D0_gpio + 1; D2_gpio = D0_gpio + 2; D3_gpio = D0_gpio + 3; */ .CMD_gpio = 3, .D0_gpio = 4, .baud_rate = 125 * 1000 * 1000 / 6 // 20833333 Hz };

C'est donc l'heure du shopping ! Nous cherchons un adaptateur de carte SD, mais qui support le protocole SDIO. Attention, certains adaptateurs n'offrent que le protocole SPI ! Nous sommes en amont du projet et nous ne sommes pas prêts à faire des compromis là-dessus.

Après quelques minutes de recherche, nous nous agaçons. Ce truc va nous coûter des sous, mettre du temps à arriver... Bref, nous trouvons une autre solution, pas forcément des plus élégantes :

Adaptateur carte SD

Non, nous n'avons pas soudé les fils directement sur une carte SD, ceci aurait été problématique pour la lire sur un ordinateur. Il s'agit d'un adaptateur de carte SD vers micro SD. En utilisant des cartes micro-SD, nous pouvons les connecter à la plaque de test ou les sortir pour les lire sur le PC. Pile ce qu'il nous fallait.

Carte SD reliée au RP2040 sur plaque d'essai

Test unitaire

Nous prenons le code de no-OS-FatFS-SD-SDIO-SPI-RPi-Pico et modifions l'exemple SDIO pour mesurer la vitesse d'écriture. Nous sommes d'abord ravis de voir apparaître les fichiers avec le bon contenu sur la carte SD. Puis en regardant les vitesses d'écriture, le doute s'installe :

Écrit: 38 octets en 46995 us Écrit: 4066 octets en 30379 us Écrit: 65482 octets en 28264 us

Comme si, plus nous écrivions de données, plus le temps total de l'opération diminuait. Ce qui n'est pas logique.

Des essais suivants montrent qu'il y a :

Un coût fixe, en temps, assez élevé pour la moindre écriture (peu importe la quantité de données)
Un coût aléatoire, probablement dû à l'age de la carte SD ou à la qualité du câblage

Mais globalement nous atteignons une vitesse de l'ordre de 2 Mo/s, et ça, c'est top !

Intégration avec le code USB

Aviez-vous remarqué que dans le nom du projet no-OS-FatFS-SD-SDIO-SPI-RPi-Pico, il y avait FsFAT ?

Bref, notre code USB et le code SDIO utilisent la même bibliothèque. À nous de créer un bout de code pour que la bibliothèque gère les deux supports. Si vous vous rappelez de notre article précédent, vous vous souvenez que :

FsFAT peut gérer plusieurs disques
Qu'il n'y a que quelques fonctions à adapter qui s'appellent disk_*

Nous reprenons la structure décrite dans diskio.c de FsFAT et sélectionnons la "bonne" fonction disk_* en fonction du numéro du disque. Les disques 0 et 1 sont des cartes SD et les fonctions disk_* appellent leurs homologues SDIO_disk_* tandis que les disques 2 à 9 sont des périphériques USB et les fonctions disk_* appellent leurs homologues USB_disk_*.

Architecture logicielle - USB + Carte SD

Côté performances

Au lieu de nous contenter d'une ou deux écritures sur la carte, nous lançons des écritures de 64 ko sur la carte SD et sur la clé USB. Nous restreignons l'acquisition à 1 minute et obtenons le graphique suivant.

Performance d'écriture (USB vs carte SD)

L'écart, en termes de performance, est sans appel.

Si nous réalisons le même exercice mais juste avec les écritures sur la carte SD, nous obtenons beaucoup plus de points en une minute, ce qui permet de valider la stabilité des résultats.

Performance d'écriture (carte SD)

Nous observons bien quelques pics de lenteurs autour de 0,5 à 1 Mo/s mais la vitesse moyenne d'écriture se situe bien autour de 2,0 Mo/s, ce qui est une très bonne nouvelle.
Écrire à la fois sur la carte SD et sur la clé USB n'est pas le plus utile ici ! Ce qui nous intéresse vraiment, c'est d'avoir la pile USB hôte fonctionnelle avec la capacité d'écrire des logs massivement !

Notre code est disponible sur notre dépôt !

L'USB hôte, la clé USB et les fichiers

2025-07-11T16:38:40Z

Alors, oui, nous avons une piste pour régler nos problèmes de communication, surtout que l'USB nous avait été chaudement recommandé à la coupe.
Mais nous avions un autre souhait pour notre robot, avoir des logs. Mais pas juste une LED qui s'allume en cas de soucis, des vrais logs, des gros fichiers avec plein de données dedans !

Nous voyons que notre code de démonstration supporte la classe "Mass Storage", nous sommes donc sur la bonne voie. Mais que se passe-t-il lorsque nous connectons une clé USB ? Eh bien, pas grand-chose :

A device with address 1 is mounted A device with address 1 is unmounted

Alors comment aller plus loin ?

La bibliothèque TinyUSB propose une liste de fonctions pour gérer les périphériques "Mass Storage", accessible dans le fichier msc_host.h. Mais en observant ces fonctions, il n'y a rien qui ressemble à ouvrir ou fermer un fichier.

Du MSC au fichier : le système de fichier

Les fonctions USB vont permettre de lire ou d'écrire une plage d'octet sur le périphérique, comme si nous accédions à une mémoire — ce qui est le cas. C'est très bien pour écrire une donnée brute, mais pour créer des fichiers qui seront lisibles sur un ordinateur, il manque toute une couche logicielle. Ces fonctions USB sont inspirées du protocole SCSI dont nous avons la liste compréhensible des commandes. Et rien là-dedans ne permet d'ouvrir, lire ou écrire des fichiers. Il s'agit plutôt de fonctions pour copier des morceaux de mémoire.

Pour gérer des fichiers, il faut un système de fichier. Un système de fichier est une organisation de la mémoire qui contient :

d'une part une table de partition qui indique le nom des fichiers, leur arborescence dans les répertoires, leur taille et où trouver leur contenu
d'autre part, le contenu des fichiers aux endroits indiqués par la table de partition.

Sur microcontrôleur, il n'y a pas beaucoup de systèmes de fichier qui seraient à la fois simples et reconnus par un ordinateur. Le principal candidat est FAT/exFAT. Il s'agit en réalité d'une famille de système de fichiers (FAT12, FAT16, FAT32, exFAT). FAT12, le plus ancien date de 1980 et était utilisé sous QDOS, l'ancêtre de MS-DOS tandis que exFAT est encore couramment utilisé sur les cartes SD. Ces systèmes de fichier regroupent la mémoire par blocs pour faciliter sa gestion.

Si nous parlons d'une famille de système de fichier, c'est qu'au lieu d'implémenter la spécification, nous utilisons une bibliothèque qui gère toute cette famille. Cette bibliothèque, c'est FsFAT !

Interface entre TinyUSB et FsFAT

L'interface en TinyUSB et FsFAT se résume à quelques fonctions. Chacune de ces fonctions prend en argument le numéro du "disque" sur lequel effectuer les opérations.

disk_initialize : rien à faire, la connexion à la clé est gérée par l'USB
disk_status : renvoyer 0 si la clé correspondant à ce disque est branché, 1 sinon.
disk_read : appeler la fonction tuh_msc_read10 avec les bons paramètres, attendre que les tâches USB se soient bien exécutées
disk_write : appeler la fonction tuh_msc_write10 avec les bons paramètres, attendre que les tâches USB se soient bien exécutées
disk_ioctl : obtenir la taille et le nombre de blocs contenus sur la clé

Le code à étudier est certainement l'explorateur de fichier fourni dans les exemples de TinyUSB.

C'est un détail, mais FsFAT demande une fonction qui renvoie la date actuelle. Si vous n'avez pas d'horloge à l'heure sur votre microcontrôleur, Vous pouvez renvoyer n'importe quelle date, mais c'est cette date qui apparaîtra comme date de création ou de modification du fichier.

Côté architecture logicielle, nous avons "juste" rajouté la couche FsFAT à notre projet précédent :

Architecture logicielle - USB + FsFAT

Écrire dans un fichier

Nous étions un peu là pour ça, non ?

Pour écrire dans un fichier, la procédure est la suivante :

f_mount : monter le système de fichier ;
f_open : ouvrir le fichier ;
f_write : écrire dans le fichier ;
f_sync : forcer les écritures qui pourraient avoir été mises en attente ;
f_close : fermer le ficher - une bonne pratique, pas forcément utile ici.

Rien de sorcier, mais il y a une petite subtilité. Les chemins sont sous cette forme :

[disque#:][/]répertoire/fichier

Les crochets [...] indiquent des éléments facultatifs. Si vous n'indiquez pas de disque, FsFAT supposera que vous cherchez à écrire sur le disque 0. Dans notre cas, ceci nous a joué un tour. Si nous connections la clé USB directement sur le Raspberry Pi Pico, elle obtenait l'adresse 1. Nous avions codé en dur l'adresse du disque dans nos fonctions disk_*. Mais en ajoutant un hub, l'adresse de la clé passait à 2 et plus rien ne marchait. C'est embêtant au début, mais très flexible par la suite. Vous pouvez gérer plusieurs clés USB par exemple. Imaginez en garder une en permanence sur le robot et une qui reçoit automatiquement les derniers logs lorsque vous la branchée.

Pour plus de détails, lisez la bonne documentation.

Alors, nous y sommes ?

Les performances ? Pas terribles, nous ne dépassons pas les 64 ko/s, ce qui est aussi la limite trouvée par rppicomidi dans son projet pico-usb-host-msc-demo... D'après le projet de rppicomidi, c'est la conception de l'USB sur le Raspberry Pi Pico qui n'est pas faite pour obtenir de bonnes performances en mode "hôte". De notre côté, nous n'avons pas les compétences pour nous prononcer sur la cause, mais nous réalisons le même constat...

Alors 64 ko/s, ça paraîtrait OK pour du log, mais ça veut dire que nous utilisons un cœur complet pour écrire sur la clé, et que notre ressource USB ne fait qu'écrire les logs, Or nous comptons sur l'USB pour la communication intra-robot, pas question de partir sur une solution qui semble déjà montrer ses limites...

Vous trouverez notre code en ligne ici !

Et si on parlait de l'USB

2025-07-07T18:30:23Z

Après plusieurs participations, nous avons observé des problèmes de communication I2C entre nos cartes équipées de Raspberry Pi Pico. Nous avions deux choix :

Continuer à analyser le problème côté logiciel pour rétablir la communication en cas de coupure ;
S'assurer qu'il n'y ait plus de coupure de communication.

Nous avions tenté, avec plus ou moins d'acharnement et pas trop de succès, le premier choix. La difficulté résidant dans la reproduction du défaut. On peut toujours débrancher un fil, mais le débranche-t-on le bon fil ? au bon moment ? Bref, nous n'avons rien produit de concluant.

Pour la seconde solution, nous faisons l'hypothèse que les problèmes de communication viennent des perturbations électromagnétiques. Alors qu'est-ce qui permettrait de se protéger des perturbations électromagnétiques ?

Un protocole qui utilise une paire différentielle ;
Un câble blindé ;
Un connecteur qui relie le blindage à la masse proprement.

Et quel protocole (relativement) bien supporté par tout microcontrôleur moderne coche ces cases ? Devinez... L'USB !

Des notions d'USB

De son nom, Universal Serial Bus, nous pourrions croire que le protocole se rapproche d'une liaison UART un peu évoluée, mais il n'en est rien. Le protocole est organisé autour d'un "hôte" (host) et des périphériques (devices). La norme USB décrit un empilement de protocoles, de la définition du 0 et du 1 sur le bus à la définition des classes de périphériques (Devices class) qui vont jusqu'à spécifier, de manière flexible, les cas d'utilisation de l'USB.

Ces classes de périphérique permettent de prendre en charge un grand nombre de périphérique différents sans développer de pilote spécifique à chaque fois. Quelques exemples de classes :

Video device class : pour les webcam, autorisant des flux élevés de données mais avec de potentielles pertes de débit
Mass Storage class (MSC) : pour les systèmes de stockage tels que les clés USB, les disques USB. C'était aussi utilisé sur les vieux téléphones portables
Media storage class : pour les systemes de stockage qui vont gérer les permissions sur les fichiers indépendamment de l'hôte USB. C'est ce qui est actuellement utilisé sur les téléphones portables pour transférer des photos ou des vidéos. Vous n'avez accès qu'à ce que le téléphone vous propose.
Communication device class (CDC) : pour tout ce qui émule une liaison série. Si vous mettez un composant pour convertir votre UART en liaison USB, ce composant se déclarera certainement en CDC. C'est ainsi que le Raspberry Pi Pico (et probablement les autres microcontrôleurs) communique avec l'ordinateur par défaut
Human interface device (HID) : pour les claviers, les souris, mais aussi les manettes de jeux, et entrées de simulateurs (cockpits d'avion, volants et pédales de voiture).

Pour une liste plus complète, wikipédia en anglais propose quelque chose de compréhensible.

Vouloir utiliser l'USB sans utiliser l'une des classes existante demande un effort considérable ! Bref, nous ne le conseillons pas !

La flexibilité du protocole USB en fait sa force mais crée une complexité qui fait que, même si nous maîtrisions parfaitement le protocole, nous ne pourrions le résumer en un billet de blog. Le meilleur résumé que nous pouvons vous proposer en ligne est USB in a Nutsheel. En français, j'ai le souvenir d'une revue qui présentait l'USB à travers une série d'articles, mais je n'en trouve pas la trace.

Et nos microcontrôleurs, dans tout ça ? La plupart des cartes pour développer sur microcontrôleur proposent un port USB, mais nous les classerons en 3 familles :

Celle où le microcontrôleur sort les données en UART et les envoie à un composant qui les adapte pour l'USB
Celle où le microcontrôleur supporte nativement l'USB, mais pour la partie "périphérique" seulement
Celle où le microcontrôleur supporte nativement l'USB, la partie "hôte" et la partie "périphérique"

Les 2 premières familles peuvent envoyer des données sur le bus USB sans soucis. La première sera restreinte à la classe CDC, tandis que la seconde sera plus flexible et pourra, par exemple, émuler un clavier ou une souris.

Mais seuls les microcontrôleurs appartenant à la 3e famille peuvent coordonner le bus USB. La solution "simple" est de laisser un ordinateur embarqué assurer ce rôle. Mais ce n'est pas notre souhait. Le Raspberry Pi Pico, basé sur le RP2040 est de la 3e famille, qui support hôte et périphériques. Notons qu'ayant qu'un seul port, un seul des rôles USB (hôte ou périphérique) peut être actif à un moment donné.

Hôte USB

Pour tester la fonctionnalité hôte USB, nous utilisons le code de démonstration fourni dans pico-example : host_cdc_msc_hid.

L'exemple de la fondation RaspberryPi marche bien. Ce qui nous a pris du temps :

Compiler l'exemple dans un projet indépendant ;
Avoir le bon câble, de type MicroUSB OTG (lien boutique) ;
S'installer pour récupérer les retours du microcontrôleur hôte.

Câble micro USB OTG

Si le port USB est pris, il faut récupérer les informations par un autre moyen. Nous utiliserons la liaison UART avec un convertisseur UART / RS232 puis un second convertisseur RS232/USB (parce que nous avions ceci sous la main).

Montage pour tester l'USB hôte

Note : sur le montage ci-dessus, il manque encore un câble USB pour l'alimentation...

L'exemple permet de gérer 4 types de périphériques USB :

HUBs ;
HID (Claviers, souris, manettes) ;
CDC (Communication type série) ;
MSC (Mass storage : clé USB, disque USB).

Côté architecture logicielle, nous en somme là :

Architecture logicielle - démo USB

Pour tester, nous commençons par relier un Raspberry Pi Pico avec un bête code printf("exemple\n") toutes les secondes à notre hôte USB. La connexion est détectée et les informations sont bien reçues !

Sortie du programme TinyUSB Host CDC MSC HID Example # Branchement d'un Rapsberry Pi Pico CDC Interface is mounted: address = 1, itf_num = 0 Baudrate: 115200, Stop Bits : 0 Parity : 0, Data Width: 8 A device with address 1 is mounted # Echo des données reçues Exemple Exemple Exemple # Déconnection du Raspberry Pi Pico A device with address 1 is unmounted CDC Interface is unmounted: address = 1, itf_num = 0 # Branchement d'un hub USB A device with address 1 is mounted # Branchement d'un Rapsberry Pi Pico sur le hub CDC Interface is mounted: address = 2, itf_num = 0 Baudrate: 115200, Stop Bits : 0 Parity : 0, Data Width: 8 A device with address 2 is mounted # Echo des données reçues Exemple Exemple Exemple # Déconnection du Raspberry Pi Pico A device with address 2 is unmounted CDC Interface is unmounted: address = 2, itf_num = 0 # Déconnection du hub USB A device with address 1 is unmounted

Après la Coupe 2025

2025-06-29T15:51:35Z

Voilà un mois que la coupe 2025 s'est terminée. C'était pour nous une coupe très particulière. En effet, nous étions grandement impliqués dans les deux équipes "Riombotique", au point d'avoir décidé de ne pas réaliser de robot pour Poivron Robotique cette année. C'est une expérience totalement différente avec énormément de trucs chouettes et quelques écueils qui nous ont fait mal.

L'une de nos conclusions, c'est que nous aimons notre équipe "Poivron Robotique". Mais Poivron Robotique c'est quoi ? Notre équipe n'est pas la seule à se poser ce genre de questions existentielles, vous avez Les Karibou qui présentent leurs réflexions à ce sujet.

En très bref, Poivron Robotique est bâti sur deux axes : maîtriser les technologies que nous utilisons et écrire des articles les présentant. Le détail de nos réflexions se trouve sur notre page Présentation.

La suite

Poivron Robotique sera probablement présent à la coupe de France de Robotique 2026. Nous travaillons toujours - bien qu'avec moins d'acharnement - sur nos articles sur le déplacement d'un robot.

Après des échanges avec différentes équipes, nous allons troquer notre bus de communication I2C pour un bus USB. Ce qui amènera probablement un ou plusieurs articles sur l'USB. Nous cherchons également à stocker nos logs, pour enregistrer massivement ce que se passe sur le robot. Enfin, nous cherchons un moyen de mieux comprendre l'environnement du robot à partir des capteurs VL53L8CX. Nous avons bien quelques idées mais rien d'abouti pour l'instant.

L'été s'annonce chargé et j'espère que nous reprendrons le rythme de publication que nous avions les années précédentes !

Bonne année 2025

2025-02-15T18:03:42Z

Nous profitons de cette nouvelle année pour présenter, tardivement, nos meilleurs vœux pour cette année 2025.
Après une année 2023-2024 bien chargée, nous levons un peu le pied, ce qui explique cette activité éditoriale bien plus faible.
Cependant, plus faible ne veux pas dire inexistante ! Nous préparons une série d'articles sur le déplacement des robots qui sera publiée sur ce site quand elle sera prête, et pas avant. Si vous êtes curieux, ou que vous souhaitez participer à la rédaction de ces articles, notre bouillon (qui commence à prendre forme) est en ligne sur ce le wiki Eurobot.

Nos projets se concentrent sur les activités du club robotique de Riom. Ces activités nous amèneront probablement à publier des articles mais pas les points d'avancement que nous partagions habituellement sur ce site...

Bref, nous sommes toujours là, mais moins actifs ici !

La coupe de France de Robotique 2024 - le bilan

2024-05-19T16:44:11Z

Après une participation à la Coupe de France de robotique puis une participation à la Coupe d'Île de France, la fin du projet appelle un bilan et comme tous les ans, nous terminons ce projet avec une sensation d'inachevé.

Notre projet était ambitieux et supposait que nous partions d'une base solide - notre robot de l'année précédente.

Globalement, le travail réalisé cette année manquait de fiabilité :

La prise des pots était délicate et comptait énormément sur l'odométrie du robot. En l'absence de capteur dédié, le robot ne pouvait que supposer qu'il avait attrapé un pot.
La prise des plantes a gagné en fiabilité, ajustement après ajustement, mais avait parfois encore des ratés
Même la dépose des plantes ou relâcher un pot n'était pas fiable à 100%

Le robot de l'an dernier avait bien un ou deux soucis, tels que :

un plantage de la communication I2C ;
un plantage dans la lecture du gyroscope.

Nous avons observé ces soucis sur le robot de cette année également, dans une moindre mesure, certes, mais ces problèmes sont toujours présents. Et cette année, en plus, le robot pouvait redémarrer de manière "aléatoire". Nous ne l'avons observé que quelques rares fois en essais, mais une fois à notre dernier match de la coupe d'Île de France.

Vue arrière du robot (mars 2024)

Côté PAMI, c'est un peu le même constat. Nous sommes partis du code de déplacement du robot principal. Ceci nous a montré à quel point le code était réutilisable - et ça nous a fait vraiment plaisir ! Par contre, quand vous réglez l'asservissement la veille de la compétition, évidemment que le robot manque un peu de maturité. Nous nous sommes fait avoir par :

les boutons de sélection de couleur qui ont lâché les uns après les autres. Probablement à cause des efforts sur les contacts dû au manque de place sur le PAMI ;
la gestion des multiples tirettes et le départ différé. Un faux contact et votre PAMI s'enclenche. Au bout de 90s, il ne bouge pas, car il y a un autre PAMI devant lui. Quand les autres PAMIs partent, ils restent coincés derrière celui qui a fait un faux départ.
la gestion des piles. Nous avons limité nos essais pour ne pas vider nos batteries puis à la coupe d'Île de France, nous avons remarqué que notre chargeur de piles rechargeables était défectueux.

Les PAMIs juste avant le départ

Donc, oui, il y a des raisons d'être insatisfaits de nos robots.

Et de l'autre côté, nous avons rempli nos objectifs :

la manière d'attraper les pots était unique et n'était accessible qu'à un robot holonome ;
le robot a offert un vrai spectacle sur les tables de matchs ;
peindre le bois a rendu le robot plus lisible ;
nos PAMIs sont trop mignons - objectivement ;
les trajectoires courbes de nos PAMIs étaient classes.

Bref, nous espérons avoir quand même vendu du rêve, car c'était un de nos buts !

Alors pour fêter ça, voici une vidéo des meilleures actions du robot :

BestOf 2024
BestOf 2024 - 720p (18Mo).

La coupe de France de Robotique 2024 - la compétition

2024-05-19T14:28:09Z

Compétition - J1 - Mercredi

Nous arrivons donc à la compétition avec un robot qui pourrait marcher mais qui ne marque pas forcément de points et un PAMI non-homologable.

Nous travaillons d'abord sur le PAMI, et relativement rapidement nous obtenons un PAMI homologable (tirette, bouton de couleur, ajustement de l'asservissement).

L'après-midi sera consacrée à l'activation des panneaux solaires avec un bras tenant un pot. Vers 15h30, nous nous dirigeons vers l'homologation. 15h40, nous sommes homologués.

Il nous reste donc du temps pour travailler sur le robot ! Et ça tombe bien car nous avons du travail ! Les servomoteurs nous posent toujours des soucis et nous découvrons que celui de la pince chauffe. Nous sortons alors notre scie à chantourner et nous installons un gros servomoteur à la place du petit qui actionnait la pince.

Rappelez-vous, notre grappin ressemblait à ça :

Le grappin !

Maintenant, c'est moins élégant, mais plus fonctionnel :

Grappin avec un gros servomoteur

Le fonctionnement global des servomoteurs semble s'améliorer à partir de ce moment.

Compétition - J2 - Jeudi

Nous attaquons notre premier match avec sérénité. Le robot ne va pas faire des merveilles, nous le savons. Nous sommes du côté Jaune, celui sur lequel nous ne nous sommes quasiment pas entraînés.

Le robot n'attrape que 3 pots sur les 5. Il tente de pousser les panneaux solaires avec un pot, les rate tous puis en tourne un en allant chercher une plante. Le robot attrape une plante et la met sur un bras qui n'avait pas attrapé de pot. Au deuxième essai, le robot n'arrive pas à attraper la plante et rentre déposer ses pots. Il embarque par hasard une plante violette qui restera debout dans la zone de dépose. Il traverse ensuite le terrain pour aller se recharger. Notre PAMI parcourt nominalement ses 80 cm.

Nous marquons 41 points face à Ze Crazy Team (66 points - leur robot était bien abouti, bravo à eux !).

1 plante : 3 points
1 panneau solaire : 5 points
Zone de recharge : 10 points
Estimation du score : 17 points
PAMI : 5 points
non forfait : 1 point.

Match 1 - Coupe de France 2024
Match 1 - 720p (61Mo) ou sur Youtube : Match 1

Nous profitons du temps entre les matchs pour homologuer les PAMIs 2 et 3.

Pour ce deuxième match, nous mettons 3 PAMIs sur la table en plus du robot. Le robot attrape parfaitement les pots, pousse avec succès les 3 panneaux solaires, tente d'attraper une plante - sans succès - puis dépose ses pots avant d'aller en zone de recharge. Le PAMI 1 fonctionne bien, le 2 a fait grève et le troisième s'est retrouvé bloqué par le 2e.

Pour le deuxième match, nous marquons 51 points face à AREM (qui ne quitte pas sa zone de départ).

3 panneaux solaires : 15 points
Zone de recharge : 10 points
Estimation du score : 20 points
PAMI : 5 points
non forfait : 1 point.

Match 2 - Coupe de France 2024
Match 2 - 720p (18Mo) ou sur Youtube : Match 2

Nous finissons le match vers 16h30. Il nous reste toute la soirée pour atteindre notre objectif : attraper une plante et la mettre dans un pot. Et quitte à modifier la stratégie, autant en profiter pour évacuer le robot du chemin des PAMIs. Car actuellement, si le robot rencontre un obstacle sur le chemin de la recharge, il se dirigera vers la zone proche des PAMI.

La soirée sera longue :

Changement de la zone de départ avec re-calibration de l'attrapage des pots
Modification de l'asservissement du robot sur les plantes, nous divisons par deux la vitesse d'approche, ce qui améliorera nettement la chance d'attraper une plante
En cas d'échec, le robot ne rentre plus directement à la zone de dépose, il tente sa chance sur d'autres zones contenant des plantes

Compétition - J3 - Vendredi

Notre troisième match sera un match en demi-teinte. Le robot attrape ses deux pots avants et seulement un pot à l'arrière. Il va ensuite attraper une plante dans la première zone. En fait, il en attrape deux. L'une tombe dans le pot, l'autre devant le robot et se couche. Rapidement, le robot détecte qu'il ne pourra pas attraper une seconde plante dans cette zone et va tenter sa chance vers une autre zone de plantes. Il attrape une 2e plante puis échange ses pots avants avec ses pots arrières. Il va chercher sa troisième plante, l'attrape, mais la pose dans le bras qui n'a pas de pot, la plante se couche devant le robot. Le robot semble tenter d'aller à la troisième zone, mais la plante est bloquée devant le capteur, il rentre à sa zone de dépose.

Mais il ne dépose pas ses plantes !

Le code de fin de match s'enclenche et le robot abandonne son action pour aller vers la zone opposée, laissant ainsi la place aux PAMIs. S'il marque les points de la zone de recharge, ce n'est que grâce à un bras déplié. Les PAMIs de leur côté cafouillent. Le premier part comme s'il était de la couleur opposée, les suivants ne bougent pas.

En termes de mouvement, c'est un match magnifique, notre plus belle action réussie, un robot en mouvement jusqu'à la dernière seconde. En termes de points, c'est juste la déprime totale :

Zone de recharge : 10 points
Estimation du score : 10 points
non forfait : 1 point.

Match 3 - Coupe de France 2024
Match 3 - 720p (32Mo) ou sur Youtube : Match 3

Évidemment, un point pareil, nous le réglons avant le prochain match ! Ce temps entre les matchs sera pour nous l'occasion de faire homologuer un 4e PAMI.

Le quatrième match sera assez similaire au 3e, à 3 détails près :

Le robot dépose sa récolte dans la zone de dépose
Le robot tente de traverser le terrain, mais n'arrive pas à sa zone de recharge avant les 90s. Il s'arrête à 10 cm du but
Les 4 PAMIs partent et marquent des points

Nous marquons 37 points :

2 plantes dans leur pot : 8 points
Zone de recharge - échec : 0 point
Estimation du score : 8 points
PAMI : 20 points
non forfait : 1 point.

Match 4 - Coupe de France 2024
Match 4 - 720p (32Mo) ou sur Youtube : Match 4

C'est bien, c'est le premier match où nous marquons des points avec des plantes ! Nous avons grandement fiabilisé le robot, rajouté des PAMIs sur la table et marqué moins de points qu'au match 1 ou qu'au match 2.

Là, c'est le conseil de guerre ! Nous avons largement de quoi marquer 70 points sur la table et nous n'avons à peine fait la moitié. Nous relisons le règlement, faut-il vraiment arrêter le robot à 90s ? Réponse : non !

La soirée, puis la nuit, seront longues :

Nous changeons aussi la fin de la stratégie. Plus question de traverser la table, nous restons sur notre demi-table
Nous tentons d'activer les panneaux solaires en fin de match, dans la séquence de dépose des plantes.
Nous rajoutons un recalage pour assurer notre précision lors de l'activation des panneaux solaires.

Nous allons nous coucher après avoir testé le robot sur trois tables d'essai différentes.

Compétition - J4 - Samedi

Pour la première fois, le robot attrape une troisième plante pour la mettre dans son pot. C'est peut-être un détail pour vous - 4 points, ce n'est pas énorme - mais pour nous, ça veut dire beaucoup ! Cette troisième plante justifie d'attraper plus que les 2 premiers pots, cette troisième plante justifie cette séquence d'inversion des pots... Bref, c'est un peu l'accomplissement de notre projet.

La suite sera un peu moins glorieuse. Nous avions calibré le robot sur les tables d'essai où il glissait plus que sur les tables de match. Il ratera ses 2 premiers panneaux solaires et frôlera le troisième (assez pour marquer les points). Les PAMIs vont encore se planter. Le premier atteint son objectif tandis que les quatre suivants vont se pousser, suffisamment pour qu'un second arrive à la jardinière la plus proche, mais ce sera bien par chance.

Nous marquons 57 points face à ARC :

3 plantes dans leur pot : 12 points
Zone de recharge : 10 points
1 Panneau solaire : 5 points
Estimation du score : 19 points
PAMI : 10 points
non forfait : 1 point.

Match 5 - Coupe de France 2024
Match 5 - 720p (32Mo) ou sur Youtube : Match 5

Un petit mot sur les PAMIs. S'ils n'ont pas brillé cette année, c'est pour plusieurs raisons :

Le démarrage par tirette posait souci. C'est le même système que le gros robot, mais ces PAMIs sont bien plus légers, ils avaient tendances à être soulevés par la tirette.
1 tirette, ça va, 5, bonjour les dégâts. En partant en ligne, sur les derniers matchs seul le premier PAMI avait une tirette, les autres détectaient le départ du PAMI précédent.
Le départ l'un après l'autre garantissait un effet boule de neige en cas de problème. Mais c'était plus pratique et surtout plus joli !
Le bouton "couleur" - ou de sélection de l'équipe - a dysfonctionné sur 4 des 5 PAMIs.

Au classement, nous finissons 39e sur 97 équipes homologuées et avant-dernier des équipes Légendes 15e sur 16. C'est donc pour nous la fin de la compétition !

Quel bilan en tirons-nous ? Vous le saurez dans notre prochaine brève !

La coupe de France de Robotique 2024 - la fin de la préparation

2024-05-14T19:53:19Z

Et voilà, c'est terminé... Après 4 jours de défis intenses, de stress et de rencontres sympathiques nous voici de retour chez nous. Mais que s'est-il passé durant ces quatre jours ? Et pourquoi ?

Pour répondre à ces questions, nous allons reprendre l'histoire au 23 avril.

J-14 avant la compétition

Bien que nous ne l'ayons pas publié, nous avions également réalisé des essais pour attraper les plantes. Ces plantes sont des éléments assez sensibles, il est facile de les coucher. Elles ont aussi la fâcheuse manie de se regrouper lorsque le robot se rapproche (il les pousse). Une fois regroupées, il n'est plus possible de les attraper avec la pince à 3 doigts. Le robot en prend 2 ou même trois et ça devient le bazar.

Nous fixons alors un petit doigt sous le châssis pour saisir la plante, la reculer et l'isoler de ses congénères. Cette solution améliore grandement la saisie des plantes.

Nous avons donc une saisie des pots qui marche et une saisie de plante qui n'est pas affreuse.

J-10 avant la compétition

Nous faisons quelques démonstrations devant des amis, il parait maintenant flagrant que le robot n'attrape correctement une plante qu'une fois sur 3 ou 4. Pire, s'il n'attrape pas la plante, il part doucement dans le décor. Nous profitons d'un après-midi pour identifier les défaillances et gérer ces cas plus proprement.

Nous avons maintenant un robot qui rentre à une zone de dépose dans quasiment tous les cas, avec ou sans plantes...

J-8 avant la compétition

Nous rajoutons les bordures au terrain - regardez la vidéo précédente, vous verrez que les pots ne sont pas bloqués par la bordure. Ceci nous oblige à retravailler un peu la séquence de prise des pots. Notre mécanique est loin d'être parfaitement symétrique, nous réglons alors la distance de prise des pots pour chaque bras.

De plus, nous avions un système de calage automatique du robot : nous le posions sur le terrain dans une orientation approximative et il se mettait tout seul en position grâce à son capteur. Nos essais nous ont montré que ce système n'était pas assez répétable. Le robot pouvait se décaler jusqu'à 2 centimètres - rédhibitoire pour attraper les pots !

Petite mésaventure, un fil du câble d'un servomoteur se détache du servomoteur : démontage sur servomoteur, ouverture du boîtier, re-soudage du fil, remontage et noyage du tout dans le pistocolle...

Câble du servomoteur

Et voilà, il ne nous reste plus qu'un week-end avant la coupe et nous sommes loin d'enchaîner les essais pour fignoler la stratégie.

J-4 avant la compétition

Notre code se compose d'une vingtaine de cas de test, qui nous ont permis de travailler jusqu'à présent. Maintenant, nous devons absolument commencer le code principal, tenant compte de la "couleur" du robot - qui influe sur sa position de départ - et de la tirette - qui conditionne le départ du robot. Des "détails" qui peuvent réserver leurs surprises.

Mais avant, nous avons un dernier mouvement à programmer. Le robot est conçu pour pouvoir lâcher ses pots, tourner sur lui-même et les re-saisir. Du moins c'était notre ambition initiale. Quelques essais montrent que ce ne sera pas possible exactement comme ceci. Lorsque le robot lâche un pot, celui-ci s'éloigne du robot. Les bras sont alors trop courts pour récupérer les pots sans déplacer le robot. Vu la situation, nous travaillons sur un échange entre les deux pots avants (potentiellement remplis d'une plante) avec les pots arrières.

Dans l'après-midi, nous organisons une séance PAMI. Avec de l'aide, nous découpons les dernières pièces des PAMI, soudons les câbles, assemblons les petites bêtes. Mais la tâche est un peu plus ardue que prévu, la carte électronique ne se monte qu'en force et il faut dessouder une broche du microcontrôleur à cause d'un problème de conception de la même carte.

Nous finissons la journée avec des PAMI montés mais pas testés...

Les PAMIs juste avant le départ

J-3 avant la compétition

Nous enchaînons les essais et le comportement du robot se dégrade, essai après essai. Il n'arrive plus à lâcher les pots, les servomoteurs n'ont plus la force de décoller les aimants des pots. Puis même à vide, les doigts ne bougent plus. Les servomoteurs des doigts, ceux qui font avancer et reculer les aimants se mettent à "croustiller". Nous remplaçons nos servomoteurs à pignons en plastique par des servomoteurs avec des pignons métalliques.

Puis l'un servomoteur à pignons métalliques refuse de bouger, ou a la tremblotte à certains moments. Nous vérifions les branchements plusieurs fois, ce qui semble améliorer la situation. Avant qu'elle n'empire à nouveau.

Nous contrôlons alors la mécanique des doigts et, effectivement, certains doigts forcent plus que d'autres. Nous corrigeons ceci en ajustant la forme du fils de fer qui guide l'aimant tenu par le servomoteur. Et la situation s'améliore...

Autre problème, le translateur, ce bloc qui tient la pince et son ascenseur, qui lui permet de se positionner au-dessus des pots, ne va plus au bout de sa course. Là, il nous faudra qu'une heure ou deux pour comprendre que nous devons re-lubrifier les axes régulièrement. Les axes sont en carbone (baguettes de cerf-volants ) et le translateur en bois. Nous les avions lubrifiées avec du PTFE en bombe. C'est efficace, mais pas très pérenne. Nos gardons quand même cette solution et notant bien de prendre le lubrifiant avec nous. (Il faudra que nous soyons à la compétition pour réaliser que nous ne secouions pas assez la bombe et que nous ne projetions que des traces de PTFE sur les axes du translateur...)

J-2 avant la compétition

Maintenant, il faut vraiment écrire un bout de code pour l'homologation, prenant en compte la tirette et la couleur de départ du robot ! Mais avant, nous réalisons un ou deux tests et nous cassons un morceau de bras !

Bras cassé

La réparation sera heureusement rapide !

Bras réparé - mais pas repeint...

Nous continuons nos essais et rapidement nous avons le robot qui se "plante", moteurs arrêtés, le reste semblant fonctionnel. Nous avions déjà vu ce phénomène mais nous l'avions négligé. Après avoir vérifié la tension de la batterie, nous branchons le PC sur le robot et découvrons avec stupeur que le robot est en train de redémarrer. En réalisant ce branchement, nous frôlons le régulateur de tension qui nous parait excessivement chaud par rapport à la puissance consommée estimée. Après avoir inspecté la carte et ses branchements dans tous les sens, nous modifions deux choses sur le robot :

Nous alimentons la carte de détection - avec ses diodes RVB - directement depuis notre carte de puissance (et non plus en passant par notre carte principale).
Nous fixons un radiateur sur le convertisseur de tension.

En fin de journée, nous avons un code qui permet au robot d'attraper les pots, chercher des plantes dans une zone de plante, rentrer à une zone de dépose et déposer ses pots (potentiellement garnis de plantes).

Le code est fiable dans le sens où le robot réalise ces actions sans partir dans le décor. Mais il est loin d'attraper systématiquement une plante !

C'est également le moment de s'assurer que l'affichage du score marche bien... Et c'est un échec. Le code de la gestion de l'écran et celui de la lecture du capteur à l'avant, qui détecte les plantes, semblent entrer en conflit. Vu notre avancement, nous remettons un code qui gère le score, affichons "25 points" sur l'écran e-ink, et rebasculons sur le code qui ne gère que le capteur. Le robot affichera 25 points du début à la fin de la compétition.

J-1 avant la compétition

Fiabilisation du code ? Avancée sur la stratégie ? Que nenni !

Nous chargeons la voiture le matin et voyageons l'après-midi ! Nous avons seulement un peu de temps le soir, qui sera consacré à l'asservissement des moteurs du premier PAMI.

3 jours avant la coupe - le poster !

2024-05-05T21:44:27Z

Voici le poster de cette année :

Poster 2024

Côté avancement sur le robot, c'est mitigé :

D'un côté la gestion des plantes est loin d'être au niveau de ce que nous aimerions !
De l'autre, nous commençons a gérer un bon nombre de cas de défaillances et nous avons fait de petite amélioration que nous amène pas très loin d'un niveau acceptable.

Les PAMIs ont bien avancé, mais un seul a été testé...

Donc en gros, c'est tendu !!

2 semaines avant la coupe

2024-04-23T19:57:15Z

Voilà un mois que nous n'avons rien publié et nous voilà à 2 semaines de la compétition... Mais qu'avons-nous fait ?

Le VL53L8X

Rappelons que ce capteur mesure 64 distances à chaque acquisition, répartis sur une grille de 8x8.

Ce capteur nous a bien occupé et les résultats sont au niveau des attentes. Le robot détecte les bordures et se recale. Il trouve même sa position de départ tout seul !

L'identification de la bordure se fait en prenant 8 points horizontaux. Nous utilisons une régression linéaire et les caractéristiques de la droite trouvée nous ont vite donné satisfaction. Ce qui nous a embêté, c'est le rejet des valeurs perturbées par la présence d'un pot devant la bordure. Pour cela, nous utilisions un critère, nommé qualité de prédiction par Wikipédia. Ce critère, pour estimer que les points forment une droite, est proche de 1 si les points forment une droite, proche de 0 dans le cas contraire. Or dans notre cas, face à une bordure, le critère variait en fonction de l'angle du robot avec la bordure. Ci-dessous, nos données expérimentales :

Critère régression linéraire

L'explication détaillée mériterait un article, mais en gros, le critère que nous utilisions évaluait le rapport entre la variation en Y des points théoriques par rapport à la variation en Y des points réels. Quand l'angle entre la bordure et le robot est proche de 0, la variation des points théoriques devient très faible alors que la variation des points réels reste constant à cause des erreurs de mesures.

Nous avons bidouillé notre propre critère en se basant sur les écarts en les Y réels et les Y théoriques.

Le capteur permet aussi au robot de trouver les plantes, avec une logique simple, ciblant le point le plus proche.

Attraper les pots

Le robot a attrapé ses premiers pots. Un moment touchant pour nous, car le spectacle semble à la hauteur de nos espérances.

PAMI

Nous vous avions présenté la conception de la carte électronique des PAMIs, voici la conception mécanique !

Modélisation PAMI 2024

Et le premier PAMI partiellement monté :

PAMI 2024 - montage en cours

La suite

C'est maintenant une course contre la montre :

Aurons nous le temps (et les pièces) pour fabriquer 6 PAMI
Le gros du code du robot semble être en place, mais il faut
- intégrer la tirette ;
- intégrer la gestion de la couleur de démarrage ;
- s'assurer que la détection de l'adversaire fonctionne ;
- réaliser un semblant de stratégie

La pince à 3 doigts marche !

2024-03-23T20:47:18Z

... mais ce n'est plus un grappin.

Après nos essais non-concluants, nous nous sommes remis au travail. Nous avons coupé les doigts du grappin, percer des trous pour pouvoir fixer différents types de doigts. Finalement, notre seconde itération s'avérera concluante.

Finalisation électronique

Nous avons fixé nos cartes électronique et raccordé la quasi-totalité de capteurs et actionneurs. Il ne manque que la tirette, le bouton de sélection de la couleur de l'équipe et le petit écran qui indique le score.

Ce qui nous a permis de reprendre le programme de l'an dernier et ses nombreux tests unitaires. Le début ne s'est pas fait sans mal :

❌Recompilation du code en mode test : pas de mode test
❌make clean puis recompilation en mode test : pas de mode test
❌rm -r build/* puis recompilation en mode test : mode test OK (c'est le cache du cmake qui posait soucis), mais pas de retour des codeurs
❌ Oh, le code de test n'initialise pas le module codeur : le code tourne, mais les codeurs sont à 0 en permanence
✅ Ah, oui, après relecture du plan de la carte, les codeurs ne sont pas alimentés par l'USB. On attrape l'arrêt d'urgent de l'an dernier, le connecteur pour la batterie, la batterie et Oh ! Les données arrivent !
✅ Quoi ? Pas de graphique teleplot pour nos codeurs : ça c'est corrigé !

La suite se déroule beaucoup mieux :

✅ Lecture des codeurs
✅ Pilotage des moteurs
✅ Asservissement des moteurs
✅ Lecture du gyroscope
✅ Localisation par codeur + gyroscope

Finalisation mécanique

Vue arrière du robot (mars 2024)

Nous fixons l'arrêt d'urgence (à cause du souci rencontré plus haut), le gyroscope et le capteur de détection des plantes (VL53L8).

L'arrêt d'urgence se base sur notre système habituel, une sorte de tringlerie en bois qui active un interrupteur à levier.

Arrêt d'urgence (2024)

Le gyroscope est situé à un endroit accessible, afin de facilement pouvoir y accéder en cas de soucis (notamment l'enfermer dans une cage en aluminium).

Gyroscope - sur le toit du robot

Et notre capteur est situé au milieu du robot, à hauteur des plantes qu'il doit identifier.

VL53L8 - Monté sur le robot

Programmation

Nous avons réglé les positions des 6 bras avec leurs aimants et rajouter sur la carte servomoteur, le code pour communiquer en I2C.

Le gros point restant est le traitement du capteur VL53L8 et la stratégie !

Le grappin ne fonctionne pas

2024-03-02T21:34:52Z

S'il est important de célébrer nos succès, il faut parfois célébrer nos échecs. Après tout, n'est-ce pas d'eux que nous apprenons le plus ?

Alors, nous partageons avec vous notre conclusion, le grappin, pour attraper les plantes ne fonctionne pas. Ou alors pas de manière suffisamment fiable pour être utilisé à coupe.

La preuve en image :

Que faire maintenant ? Nous avons analysé le problème et trouvé deux causes :

la séquence du programme semblait se comporter de manière erratique, certains temps d'attente n'étaient pas toujours respectés. Un problème lié à la lecture d'une variable 16 bits, dont la valeur était modifiée en interruption, sur une architecture 8 bits.
mécaniquement, l'appui par trois points ne convient pas à la géométrie des plantes.

Nous vous présenterons prochainement nos améliorations. Nous utiliserons bien une pince 3 doigts pour attraper les plantes, mais ce ne sera pas un grappin !

L'électronique des PAMI

2024-02-28T20:26:08Z

Les PAMI sont des petits robots autonomes qui entrent en jeu dans les 10 dernières secondes du match.
Voici la carte électronique que nous comptons utiliser si nous avons le temps de réaliser ces PAMI.

Les fonctionnalités principales sont :

Microcontrôleur Raspberry Pi Pico
Connecteur pour l'arrêt d'urgence
2 prises moteurs (pilotés par un L293D)
2 prises codeurs
1 prise Gyroscope (L3GD20H)
1 prise I2C pour du TOF
1 prise "choix couleur"
1 prise tirette
Surveillance tension batterie
1 LED
3 Dip Switch

Dimensions : 50 mm x 90 mm

Tous nos fichiers sont ici.

Translation de la pince

2024-02-14T20:51:02Z

Ce dernier mois, la priorité n'était pas sur notre robot. Alors que nous étions plutôt bien partis côté planning, nous avons consommé une bonne partie de notre marge.

Mais nous avons quand même avancé !

Ensemble de la pince

Notre système de pince contient 3 axes :

Un pour la fermeture de la pince
Un pour l'ascenseur
Un pour la translation

Nous avons conçu et assemblé le translateur. En l'installant sur le robot, nous installons notre 15ᵉ servomoteurs sur le robot. Voici la première version de la mécanique :

Translateur (face)

Translateur (côté)

La cinématique est sympa, avec le servomoteur qui avant et recule lorsque l'ensemble va de gauche à droite. Malheureusement, les performances ne sont pas au rendez-vous : le système met du temps à atteindre les positions extrêmes (ça se voit sur la vidéo ci-dessous) et pire, l'ensemble se bloque assez facilement.

Translateur

Nous allons alors travailler sur une seconde version du translateur, où la course du servomoteur sera négligeable mais qui va nous faire gagner en rapidité et en fiabilité.

Alors nous tentons un test d'un cycle complet de manipulation de plante.

Manipulation de la plante

C'est l'occasion de critiquer la pince 3 doigts, où les frottements empêchent la pince de s'ouvrir et limite la force disponible lors de la fermeture. Nous changeons le point d'attache de la bielle pour améliorer grandement l'efficacité du mécanisme. Même si pour cela, nous devons revoir la fixation du servomoteur.

Il y aura bien encore quelques ajustements à effectuer, mais dans l'ensemble, les actionneurs du robot sont en place. Il est maintenant temps de re-travailler sur le déplacement et les capteurs (positionnement et traitement) !

La suite

Changer le mini-servo de la pince 3 doigts, car il "croustille" : nous prendrons un MG90-S avec des pignons en métal au lieu de notre SG90.
Régler les 5 positions des 6 bras
~~Finir de concevoir le 3ᵉ axe pour la pince 3 doigts~~
Rallonger les câbles des codeurs de moteurs
Fixer le capteur de détection des plantes
Fixer la batterie et la carte électronique

Les bras montés sur le robot

2024-01-05T10:22:12Z

Préparation des bras

Nous vous avions présenté l'actionneur principal, notre pince 3 doigts. Il est temps maintenant de vous présenter nos actionneurs "secondaires". Il s'agit des petits bras qui tiendront les pots. Nous vous avions donné un aperçu du prototype fin octobre dans cette brève.

Revenons en détail sur fonctionnement du bras, il est composé de deux parties. La première partie permet de lever et d'écarter le pot du robot, c'est la partie la plus visible ci-dessous :

Bras pour pot - pré-série

La seconde partie approche ou éloigne un aimant du pot pour le prendre ou le lâcher.

Nous avons d'abord réalisé un prototype, puis une version pré-série. Enfin, nous décidons de réaliser la série. Pour cela, il faut découper les pièces :

Pièces pour les bras pour les pots

Puis il faut percer les pièces avec précision. En fonction, soit nous perçons les pièces ensembles, 2 à 2, ou nous nous servons de gabarits de perçage pour être répétable.

Pièces percées

On ne dirait pas comme ça, mais c'est un peu de boulot de percer ces pièces !

Préparation du châssis

En parallèle, nous découpons le châssis.

Châssis du robot 2024

Nous perçons les trous de fixation des moteurs. Pour cela, nous utilisons l'ancien châssis comme gabarit et obtenons rapidement une sorte de base roulante.

Mécanique de la base roulante

Assemblage des bras

Il va falloir assembler les bras de manière à respecter la position des pots prévue initialement.

La base roulante sur son plan

Vous n'aurez pas de photos de l'assemblage des 6 bras. Avec la visserie, il y a plus d'une cinquantaine pièces par bras. Bref, ça nous a pris un peu de temps, mais le résultat est là :

Base roulante avec pots

Et en détail (notons qu'il manque le pignon et la bielle entre le servomoteur et l'aimant) :

Bras qui tient un pot

Ce qui donne en action :

Lève pot

La suite...

La suite, car nous sommes loin d'être en avance sur la planning, se compose principalement des tâches suivantes :

Régler les 5 positions des 6 bras
Finir de concevoir le 3e axe pour la pince 3 doigts
Rallonger les câbles des codeurs de moteurs
Fixer le capteur de détection des plantes
Fixer la batterie et la carte électronique

Ensuite, nous pourrons commencer les déplacements sur le terrain !

Démontage d'HEXA

2023-12-27T21:10:00Z

Eh oui, nous démontons notre précieuse création. Mais c'est surtout que nous avons bien appris avec ce robot et que nous souhaitons en réaliser un autre sur une structure proche.

Nous l'avons donc mis en pièces :

HEXA en pièces détachées

Ce que nous allons récupérer (en lettre) :
A : La batterie 12V NiMh
B : La carte électronique avec ses 2 Raspberry Pi Pico et ses 3 ponts en H
C : Les 3 blocs moteurs
D : Notre précieux gyroscope (pas vraiment mis en valeur sur la photo)
E : Notre carte de détection de l'adversaire, à base de VL53L1X
F : Notre logo poivron (on ne sait pas où il sera, mais il sera probablement sur le robot)
G : L'écran pour afficher le score

Ce que nous ne réutiliserons peut-être pas (en chiffre) :
1 : Montants verticaux et support pour la carte électronique
2 : Le toit avec le système de déclenchement du déguisement
3 : Notre bras, rajouté à l'arrache
4 : Les contacteurs pour détecter et longer les bords
5 : Le troisième montant vertical avec le propulseur
6 : Turbine, chambre d'aspiration et trompe
7 : Rampe pour guider les cerises jusqu'au propulseur
8 : Le châssis

Notre projet, un ascenseur et de la mécanique

2023-12-10T20:39:20Z

Du robot 2024 en général

Planète Sciences nous demande, pour participer à la coupe de France de Robotique, de produire une présentation de notre projet scientifique et technique. L'an dernier, nos axes principaux étaient :

La maîtrise d'un robot holonome,
L'utilisation du Raspberry Pi Pico
L'utilisation de courbe d'accélérations et de décélération

Globalement, nous avions tenu nos objectifs.

Cette année, notre projet, c'est d'avoir un robot qui impressionne, qui crée un effet "Wahou !". Pour cela, nous voulons :

une mécanique qui tire avantage d'un robot holonome
une réalisation en bois, à la scie à chantourner
un robot joli avec du bois teinté

Évidemment, une fois que nous avons annoncé cela, le risque de vous décevoir est grand. Mais tant pis, on y va !

Donc le but est de saisir les plantes avec une pince "3 doigts", celle présentée sur la brève précédente. Cette pince est montée sur un ascenseur (voir plus bas) et l'ensemble sur un translateur. Cette mécanique permet de prendre la plante et de la poser dans un pot, situé à gauche ou à droite de la pince.

Mais 2 pots ne nous suffisent pas ! Nous voulons en transporter 6. L'idée vient donc de les porter autour du robot, formant un hexagone. Une fois que les pots adjacents à la pince ont reçu leur plante, le robot lâche ses pots, tourne sur lui-même de 120° et rattrape ses pots. Ainsi les pots adjacents à la pince sont de-nouveau vide.

Voici deux vues issues de la modélisation.

Vue de dessus du robot 2024

Vue 3/4 du robot 2024

Ce qui implique d'avoir 6 bras pour les pots.

Donc pour résumer, il nous faut :

Une pince 3 doigts : OK
Un ascenseur : OK (si, si, regardez plus bas)
Un translateur : c'est en cours
6 bras pour les pots : prototype : ok, pré-série : ok.

Nous venons de finir le modèle "pré-série" pour les bras pour les pots. Ceci nous va nous permettre de continuer la modélisation 3D du robot et de réaliser les 6 bras prochainement (mais pas demain, hein !).

L'ascenseur

L'ascenseur, se base sur un principe (aimablement) piqué à l'équipe Les Karibous : un servomoteur, une bielle, une manivelle et un guidage. Avec ça, le tour est joué.

Ascenseur

La mécanique

Nous vous avons beaucoup parlé de la mécanique. Nous mettons nos fichiers à disposition !