164 réponses à ce sujet

[pat92fr]

Suite à la coupe 2025 (la fatigue pour des vétérans de presque 50 ans), et la chaleur (été 2025), nous nous sommes visiblement égarés sur le chemin de la conception mécanique du robot de cette année. Heureusement, un rebondissement de dernière minute, nous a réorienté vers une conception plus proche de notre ADN. Voici quelques images de nos prototypes et réalisations de la saison passée, en matière de base roulante. https://www.robot-ma...-2026/?p=122673

[dagguy_]

Question : comment vous avez reussi a remplir toute la ram de la teensy ?

[pat92fr]

* RAM1 : Le code (150ko), les données scan et cloud des LIDAR (angle/distance + points XY), le graphe de navigation, un paquet de buffers (UART) et la palce pour recevoir en OTA le binaire de mise à jour de la Teensy. Comme la mémoire est abondante, tout est en float32. C'est le gaz parfait qui occupe toute le volume. En fait, on ne cherche pas à optimiser tant qu'on atteint pas la limite.
* RAM2 : La situation a changé entre la coupe et aujourd'hui. La coupe arrive toujours trop tot dans le planning ! Avant : un énorme buffer pour un protocole de communication maison (une forme de TCP pour le transfer des gros fichiers ; Behavior Trees au format texte, Log de match, Mise à jour du binaire de la Teensy OTA), puis environ 200ko de Behavior Trees compilés (un compilo et formats binaire maison, incluant les lignes de texte du BT avant compilation comme un executable en mode debug), et 100ko de Log de match (toutes les actions du behavior tree exécuté, avec timestamp, état SUCCES/FAILURE/RUNNING, des commentaires associés aux actions en texte et les lignes de texte du BT d'origine avant compilation). APRES : suppression du buffer de protocole de communication (on a transféré le problème du coté de l'ESP32 qui se tourne les pouces pendant le match, et la communication entre ESP32-Teensy en série s'avère très fiable). Et enfin, on a travaillé la compilation du Behavior Tree (une forme de mode release, avec deux passes pour éviter la fragmentation de la mémoire au moment de la création de l'arbre de décision en mémoire) et le format du log de match pour le rendre plus compact et éviter de dupliquer les informations entre le BT au format texte, celui compilé et le contenu du log. Aujourd'hui, un gros BT "de compétition" prend environ 100ko, le log de match est compact (moins de 50ko pour un paquet d'évènement), et le reste est disponible ! Ca tout récent (de quelques jours).
Pour l'anecdote, je pars de loin avec la Teensy. En 2024, j'avais constaté que les appels aux différentes formes de printf/scanf coutent cher en taille de code (RAM1). Pareil pour les conteneurs STL hors Array en code et mémoire. Au troisième match des qualification pendant la coupe, je me souviens que je devais supprimer des traces/printf pour pouvoir ajouter des fonctionnalités dans le code... plus jamais !

[dagguy_]

J'avoue avoir reussi tout juste a saturer la RAM1 avec un parhfinding pas opti mais jamais a saturer la RAM2. Mais c'est bien ca me confirme que j'arriverais a tout caser l'année prochaine avec un peu d'optimisation

[pat92fr]

Oui, la place disponible est quand même confortable. En 2025, le path planner était sur une RPi5 sous ROS2. Cette année, pour faire plus simple et tout rentrer dans la Teensy, on est passé d'une carte (occupancy grid map à 2 ou 3 cm de résolution) à un simple graphe avec une centaines de points de passage calculés par le robot au départ du match en fonction des objets et des dimensions de l'aire de jeu. Le tout stocké en RAM1. Je n'ai pas cherché à refaire une map avec la Teensy, je m'étais dit que ca ne passerai ni en mémoire ni en vitesse de traitement (obstacle inflation, etc). Je n'ai donc pas essayé.
Et puis, il y a aussi beaucoup de Flash dans la Teensy, on y stocke un paquet de fichiers : des configurations, la forme et les dimensions de l'aire de jeu pour la localisaton, les behaviors trees (texte), les logs de match (les 10 derniers), et pour les PAMI des routes prédéfinies en fonction de leur numéro.

[dagguy_]

Notre gridmap a une resolution de 25mm (9600 noeuds) et ca tient parfaitement en RAM2 avec un A* qui met 3ms max a calculer un chemin

[pat92fr]

Vous reportez les obstacles dans cette map avec une étape d'inflation pour tenir compte des dimensions du robot ou vous faites autrement ?

[dagguy_]

Oui c'est exactement ca
Et on calcule le chemin a chaque nouveau scan lidar

[pat92fr]

Oui je vois. Comme quoi, il y a assez de RAM dans cette Teensy.

[pat92fr]

En attendant le règlement de la CdR 2027, je teste un ESP32P4 à la place de la Teensy 4.1 et la bibliothèque Ruckig pour la planification de trajectoire du robot. Ruckig est un peu lourd pour un ESP32 (FPU seulement, avec émulation logicielle des calculs en double précision). La planification de trajectoire avec cette librairie est néanmoins parfaite. Quant à l'ESP32P4, il permet de gérer toutes les taches temps réel du robot et une interface Web assez poussée.
https://youtu.be/Dd-...RIJFd7XVT3Wok9r

[Barbatronic]

Ah top ! Le P4 est vraiment un bon concurrent pour la suite du S3 je trouve.

[victor_dubois]

Attention, pas de wifi/bluetooth !

[pat92fr]

Effectivement, l'ESP32P4 n'intègre pas la partie Wifi/BT. Celle-ci est déportée dans un ESP32 compagnon qui exécute un code fourni par Espressif (on peut mettre un S3, un C5 ou C6 au choix). Dans le code du P4, la mise en oeuvre du Wifi/BT est totalement transparente. La communication avec l'ESP32 compagnon est transparente. Ca marche comme si le Wifi était disponible dans le P4.
On va essayer de faire une carte maison avec le module ESP32P4C6 ou ESP32P4C5, pour remplacer notre carte habituelle avec Teensy4.1 et ESP32S3. L'idée est de n'avoir plus qu'un seul logiciel dans le robot avec le temps réel et l'IHM/WebUI.

[__wix__]

On utilise ruckig sur pico pour les servo et la trajectoire théorique boucle ouverte des steppers (dont propu). On en est très contents, surtout que pour les BO tu peux calculer d'avance (genre servos).

En revanche ça avale la ROM surtout si mal instancié plusieurs fois avec des templates pas bien gérés.
(en gros faut le mettre en privé derrière une classe qui cache le template)

[pat92fr]

Avec l'ESP32, ca prend entre 50 et 100ko en Flash. Avec Mike, on a refait les calculs à la main et notre propre implémentation, on va essayer de s'y ternir. Mais Ruking calcule bien et facile à utiliser.

[pat92fr]

10 cm d'erreur de position sur un simple aller-retour, ca va pas du tout ! Après une reprise complète de l'asservissement des moteurs et de la planification de trajectoire pour passer de la Teensy à l'ESP32P4, toujours une mauvaise précision ! Décidément, la Loi Murphy se vérifie parfaitement tous les ans !
La cause était finalement mécanique : mes moyeux imprimés en PLA ont pris du jeu et patinent dans les roues à forte accélération. Les moteurs tournent, les encodeurs sont contents... mais le robot bouge pas (ou beaucoup moins). Lorsque j'ai inséré les moyeux en force (vraiment à la presse), je m'étais dit "non ! quand même pas ! ca va pas bouger"..... en plus c'est le genre de pièce facile à changer sur un châssis aussi dense (et pas très bien aménagé).
Une petite Upgrade mécanique : pour l'année prochaine, des roues goBILDA avec un moyeux plus sérieux. Bonne marque aiu passage, très utilisée sur les robots de compétition FTC aux États-Unis.

Et voila, ca va tout de suite mieux. Un bon centimètre d'erreur à la fin, mais ca donne accès à des réglages plus aggressifs pour un holonome avec les petits moteurs dji et es petites roues 48mm : Vmax = 1.5m/s, Amax = 4.5m/s², Jmax = 14m/s^3.
https://www.robot-ma...h_query=gobilda

[argail25]

Pour la localisation tu es en full odometrie ?

[__wix__]

On a eu le même soucis, le PLA pour les moyeux ça passe pas. Quand j'avais vos photos j'étais étonné que ça marche... Mais en fait non ^^
Mauvaise précision de l'odometrie ou en boucle ouverte ?

[pat92fr]

En fait, le mode de fixation des roues omni nexus n est pas terrible. Le hub est juste inséré en force avec une canelure micrometrique. Ca ne tient pas dans le temps en effet. La matière n'est pas vraiment un problème. Nos anciennes roues mecanum étaient fixées avec un hub hexagonal en pla+ ou petg et ca ne bougeait pas. Les omni gobilda se fixent avec 4 vis, ca ne devrait pas bouger, meme avec un hub en impression 3d. Pour faire plus compact, il faudra une pièce usine. A voir.
Oui, je faisais quelques essais en boucle ouverte. L'odometrie prend les 4 moteurs et le gyro. Sur un aller retour, l erreur est d un bon centimetre sur un sol pas très propre. J'imagine que c est acceptable dans ces conditions, avec ce type de chassis, a cette vitesse.
Le lidar bas positionné juste au dessus des roues a 5cm du sol voit les bordures et améliore/corrige l'odometrie du robot pendant tout le match.

[Mike118]

Hello, petit partage qui j'espère pourra vous intéresser ! https://www.robot-ma...2027-simulator/
Lien vers le simulateur : https://www.robot-ma...2027-simulator/ n'hésitez pas à laisser des commentaires sur le forum !