merci pour le lien.

Il n'y a pas de problème d'échauffement avec ce petit driver ?

 

Pas de problèmes d'échauffements ( il est plus performant que le L298 )
Par contre le L298 est plus costaud... Autant le L298 va tenir bon sans trop de problème si tu bloques à la main ton moteur ( la chute de tension aidant à limiter le problème ) autant le TB6612FNG lui va essayer de fournir au max jusqu'à lâcher ... 

@Mike : bien vu, j'avais lu 2 moteurs cc en 2A, alors qu'il s'agit de 2A bloqué (et pas nominal). Du coup, ça devient moins dérangeant (il y aura encore bien plus de pertes qu'avec un driver récent, mais ça put passer). La forte chute de tension en cas de bloquage des moteurs peut même aider à protéger les moteurs.

 

@Mike : tu confirmes que ce module ne fait pas usage des pins de mesure de courant du L298?

Non ce module ne fait pas usage des pins de mesure de courant. 
 

Je ne suis pas aussi catégorique que Sandro sur le sujet du L298  

Pour moi la carte devrait pouvoir répondre à ton besoin, surtout que le courant de tes moteurs est faible donc tu auras pas tant de pertes que ça

 

Merci !

Une question: ce type de carte https://www.robot-ma...urs-cc-219.html ne règlerait il pas à la fois mes problèmes de driver (si je pars sur une solution 4 moteurs cc) et d'alimentation de mes capteurs ?

.
De plus l'avantage c'est que la carte intègre aussi au un régulateur 5V ce qui devrait peut être régler ton problème de limitation courant...

Je te propose d'essayer la carte et si elle ne te convient pas je te la rembourse =) 
Au moins tu pourras juger par toi même.  

 

Hello everyone!

We would like to share an update regarding our participation in the French Robotics Cup.

In terms of progress, the end of this year has been very intense, and although we haven't been able to make as much progress as we would have liked, we still have a few points to show you!

Firstly, we continue to refine our mecanum base.

Here is how the current version of the base is assembled and wired:

While we work on the final version of the robot base, we are also improving the localization algorithm and conducting movement tests with the prototype base.

Here are some video footages:

Video showing the robot  on the table:

Robot showing what display the Visualizer tool:

And finally, today is the day we need to submit our scientific project report and communication plan! As "veteran participants" (over 30 years old), we are registered in the "Legend" category and have a few additional tasks, including promoting the event

Here's a preview of our report:

 Mars Attacks! Scientific Project and Communication Plan.pdf   2,35 Mo   26 téléchargement(s)

We hope that among our readers, we can inspire a few people to participate in the Cup next year! =)

We'll be back with more updates soon!
Meanwhile, we wish you all a fantastic 2024!

Bonjour à tous !

Nous souhaitons partager avec vous une mise à jour concernant notre participation à la Coupe de France de robotique.

Du point de vue de l'avancement, la fin de cette année a été très intense, et bien que nous n'ayons pas pu progresser autant que nous l'aurions souhaité, nous avons tout de même quelques points à vous montrer !

Tout d'abord, nous continuons à perfectionner notre base mécanum.
 
Voici comment se monte et se câble la version actuelle de la base :



 

 

 

 

 


Pendant que nous travaillons sur la version finale de la base du robot, nous améliorons également l'algorithme de localisation et effectuons des tests de déplacement avec la base prototype. Voici un aperçu en vidéo :

Vidéo du robot sur la table : 

 
Vidéo de ce que nous voyons sur le visualisateur :


Et pour finir, aujourd'hui est le jour où nous devons rendre notre rapport de projet scientifique et notre plan de communication ! En tant que "vieux participants" (plus de 30 ans), nous sommes inscrits dans la catégorie "Légende" et avons quelques tâches supplémentaires, dont la communication autour de l'événement

Voici donc en avant-première notre rapport :
 Projet scientifique et plan de communication Mars Attacks!.pdf   2,36 Mo   45 téléchargement(s)

Nous espérons que parmi nos lecteurs, nous pourrons motiver quelques personnes à participer à la Coupe l'année prochaine ! =)
Nous reviendrons avec plus de nouvelles bientôt !
En attendant, nous vous souhaitons à tous une excellente année 2024 !

(French version here)

Hello everyone,

This year, I am participating again in the Coupe de France de Robotique, but this time, I'm starting with a new team composed of

pat92fr hdumcke  (whom I both met during the TRR), and myself.

Pat chose the name Mars Attacks! in reference to the movie of the same name because the theme for the 2024 edition of the Coupe de France de Robotique is "Farming Mars," revealed in September 2023.

It's the first participation for pat92fr and hdumcke (yes, I roped them into this, but I promise they are willing participants and not being held hostage ). Since it's their first time, we are starting a bit from scratch, but since we are not beginners in robotics, we're progressing quite well. As they are both in the Paris area and I'm in the south, near Biarritz, most of our sessions are conducted remotely, which can be a challenge, but we're managing quite well.

To provide a brief update on where we stand at the moment:

Mechanically:

We are working on a mecanum base with a lidar positioned quite low to hit the table edges for localization (based on my experience with vigibot). Counter-axes are added at the wheel level in the protective fairing to relieve the motor reducers a bit. The front motor train is mounted on a pivot linkage to keep all four wheels in perfect contact with the ground.

Some photos:

Assembled base from the top:

Assembled base from the front:

Highlight of the front train pivot without wheels:

Top view of the motor support integrating bearings and counter-axis in the wheel fairing:

Front view of the motor support integrating bearings and counter-axis in the wheel fairing:

For this mecanum base, we are using:

• 4 DJI M2006 motors with their C620 controller
• A set of 4 mecanum wheels
• 8 flanged bearings (8mm)

Several 3D-printed parts (PETG), (the files will be shared) and plenty of screws and fasteners 

 

This tool will be shared with various examples on the visualization tool's Git :  (Basic examples have already been shared, with the idea of providing building blocks so that everyone can develop the tool that suits them from examples) 

Robot Code:

 

Regarding the robot code, for now, we have mainly focused on robot control and localization on the table. The system runs on an STM32, and data is sent to the visualizer via WiFi using an ESP32. Currently, we have a working system, although not perfect yet, connected to our visualizer. During tests, we get results like in this video: 

In this video, the robot is moving on a table, and what we see is the data sent by the robot. It displays where it thinks it is on the table, and in red, we see the lidar points. 

Around 1 minute and 50 seconds, the robot touches an obstacle and loses its localization. We need to work on detecting opponents, and it's in progress, but the results are already quite interesting. 


We plan to publish a lot more, but we need to make progress first, so stay tuned for more soon!

Le code de référence, celui que je montre dans la vidéo à 0'38", est ici : https://www.robot-ma...-test/?p=119892

Dans la ligne qui définit la variable D, à la fin, on peut voir previousError = error;

float PID(){
  static float errorSum, previousError;
  float error = periodTarget - feedback;
  float P = kp * error;
  float I = ki * (errorSum = errorSum + (error * dt));
  float D = kd * (error - previousError) / dt;  previousError = error;
  return P + I + D;
}

Oui on est d'accord ce code est bien correct  


 

Toi, tu fais référence au code qui se trouve plus haut dans le fil, ici : https://www.robot-ma...-test/?p=119805

Mais là également, l'instruction se trouve dans la définition de la variable previous, en static, dans la première ligne.

float pid(float error){
  static float integral, previous = error;
  float P = kp * error;
  float I = ki * (integral = integral + error * dt);
  float D = kd * (error - previous) / dt;
  return P + I + D;
}

Mais pas de souci, au contraire, je te remercie d'avoir jeter un coup d'œil au code.

 

Oui en effet c'est bien à ce code dont je fait référence et justement puisque tu as déclaré ta variable en static le travail " previous = error " ne sera fait uniquement la première fois que la fonction est appelée... 

Pour s'en convaincre il suffit de faire un petit essai tout simple  : 

 

void setup() {
  Serial.begin(115200);
  testStatic(42);
}

void loop() {
  testStatic(10);
}

void testStatic(uint8_t val) {
  static uint8_t test = val;
  Serial.println(test);
}

Tu verras que la réponse sera toujours 42  


Sinon autre point de détail : 

 

 

Et d'ailleurs, si tu trouves un loup dans le code de ce post, https://www.robot-ma...board/?p=120002, je t'en remercie par avance.

 

Je n'ai pas trouvé de problème spécifique dans ton code, mais j'ai une petite remarque qui ne te concerne pas directement, mais plutôt de manière générale toute personne lisant ces lignes : 

Il peut parfois être tentant de regrouper deux ou même trois petites lignes de code sur la même ligne pour réduire le nombre total de lignes pour pouvoir dire "le code est super court, il fait seulement 63 lignes si on exclut les espaces..." Cependant, regrouper deux lignes de code sur la même ligne n'améliore souvent pas la lisibilité.

Pour illustrer davantage ce point, c'est un peu comme si on remplaçait toutes nos variables par a, b, c, d, etc., juste pour dire : "Mon code ne fait que tant de caractères..." Cela ne rend pas le code plus lisible (au contraire, c'est même le principe de l'obfuscation du code).

D'ailleurs, au contraire (et comme tu le fais déjà parfois aussi Oracid), il est parfois préférable de diviser une ligne de code en plusieurs lignes pour améliorer la lisibilité.

En général, il faut trouver un équilibre pour le cerveau humain. 
D'un côté, chaque ligne doit contenir une seule information à comprendre, associée à un commentaire bref. Si le commentaire commence à expliquer plusieurs opérations, il serait judicieux de diviser la ligne en plusieurs lignes.
D'un autre côté, il ne faut pas avoir trop de lignes de code pour permettre au cerveau de comprendre facilement le code dans son ensemble.
Souvent, la création de fonctions avec des noms explicites est la meilleure solution, ce que tu fais déjà (par exemple, la fonction PID()).

Bref une remarque un peu hors sujet, mais j'avais envie de l'écrire quelque part. Peut-être qu'un jour, on déplacera ce message vers un sujet plus adapté.

 Tu sais il y a du monde sur le marché.

 

Oui en effet il y a du monde sur le marché.

Moi aussi je propose un service d'impression 3D avec mes machines sur robot maker et il est très peu utilisé... 
Il dépanne juste de temps en temps mais rapidement le peu de clients qui ont des vrais besoins investissent dans une machine . 

Perso j'ai pas vocation a développer plus ce service... Il est là juste en complément pour dépanner si besoin =) En même temps que commander un capteur tu peux commander le support qui va avec... 

 

 je me demande si je ne vais pas me lancer dans l'activité d'impression 3D pour augmenter mes revenus et aussi parce que je n'arrive pas à évoluer dans mon boulot (apparemment quand on est en production on reste en production dans cette boîte).
 

Loin de moi l'idée de te décourager, au contraire, je suis le premier à essayer d'encourage les makers à vivre de leur passion =) 
Mais c'est pas si facile =) 

Bon courage il en faut ! Et de la persévérance aussi  

 

 

Mon code :

// Program inspired from the code of Ian Carey https://www.youtube.com/@careyian - 03/11/2023
const int INPUT_PIN = A0;
const int OUTPUT_PIN = DD5;
 
float dt, last_time = 0, init_time = 5000, loop_time = 200, target = 60.00, kp = 0.76, ki = 0.191, kd = 0.0009;
 
void setup(){
  Serial.begin(115200);
  analogWrite(OUTPUT_PIN, 0);
  delay(init_time);
}
 
void loop(){
  float now = millis(); dt = (now - last_time) /1000.00; last_time = now;
  float feedback = map(analogRead(INPUT_PIN), 0, 1024, 0, 255);
  float error = target - feedback;
  float output = pid(error);
  analogWrite(OUTPUT_PIN, (int)output);
  Serial.print(target); Serial.print(","); Serial.print(target*2); Serial.print(","); Serial.print(feedback); Serial.print(","); Serial.println(0);
  delay(loop_time);
}
 
float pid(float error){
  static float integral, previous = error;
  float P = kp * error;
  float I = ki * (integral = integral + error * dt);
  float D = kd * (error - previous) / dt;
  return P + I + D;
}

 

je note un peu tard une petite erreur dans la fonction pid. 
Il manque une petite ligne 

float pid(float error){
  static float integral, previous = error;
  float P = kp * error;
  float I = ki * (integral = integral + error * dt);
  float D = kd * (error - previous) / dt;
  previous = error; // La ligne qui manquait ...
  return P + I + D;
}

Que tu as bien rajouté dans ta version final  
( On pourrait peut être "masquer mon message " et corriger ton message pour intégrer la ligne ni vu ni connu )

Les sharp c'est bien mais c'est une techno qui commence a être sacrément dépassée ... ( Même si ça à l'avantage d'être une simple lecture analogique )

Moi je vous proposerais bien ce genre de capteur : https://www.robot-ma...l53l0x-161.html

Tout petit, fonctionnant en I2C + shutdown ... ( En gros il faut prévoir 1 fils par capteurs en plus de l'I2C si on veut en utiliser plus qu'un seul sur le même bus I2C ... )

Ci joint quelques résultats de tests assez "étranges" avec le lidar LD06 : 

Le setup: LD06->ttl/usb converter->PC

sur le PC : Ubuntu et ROS2, le driver https://github.com/l...ar_stl_ros2.git
la grille de rviz est configuré avec des cellules d'un centimetre

Test 1 : 
Des murs à 8.5cm autour du lidar ( la plaque noir fait 17cm et le lidar est au centre )

Config :

Les mesures

Déjà on a des phénomènes bizarre au niveau de 4 coins, et on a des erreurs de mesure...

Test 2 : 

Même config mais avec quatre entretoises M3 plastique noir qui bloquent le champs du lidar ... 


Les mesures :


On retrouve toujours les éléments bizarre du premier test et on note l'impacte des entretoises ...

Test 3 : 

Avec les murs à 20cm de distance : 


Le résultat : 


Le résultat est déjà mieux ... On comprend un peu mieux la limite de distance donnée à 20cm dans la datasheet du capteur... Mais on remarque quand même des erreurs de l'ordre de 1cm sur les mesures ... 

On a également remarqué que le lidar ne tire pas droit ... le faisceau est incliné ce qui nous fait une mesure " conique " ... 
( => D'où le fait d'utiliser le lidar "à l'envers " dans le cadre de la CFR pour que le faisceau du lidar ne passe pas au dessus des murs qui ne font que 7cm ... ) 

Est ce que le 1cm d'erreur observé est lié à cet angle ? 

( To do : caractériser l'angle et faire plus de tests sur différentes surfaces )
 

Great job ! =)

Oui

* Un condensateur ça se met en parallèle ou en série ? (j'imagine en parralèlle  )

oui en parallèle

 

* L'alimentation est commune à tous les capteurs, ça pose un problème ?

Non pas de problème.

Tu peux essayer de mettre un bon vieux condensateur chimique aux bornes de l'alimentation de ton HC-SR04...

Il y a peut-être une autre solution, c'est d'inverser les fils sur le moteur. Pas le servo, seulement le moteur !

Faut tester.

Non dans ce cas il faut également inverser le potentiomètre pour que ça puisse marcher...

Le problème c'est qu'au vu de son montage il a besoin d'inverser le signal du deuxième servomoteur. 
Par contre il existe justement des petits modules pour inverser le signal d'un servomoteur ... Quand tu as juste une radiocommande et 2 servo à piloter en sens inverse pourquoi pas mais quand tu utilises déjà un microcontrôleur programmable et que tu as des broches de disponible autant inverser le code dans ton microcontrôleur... 

Sinon autre astuce : tu joins l'utile à l'agréable en liant mécaniquement tes deux servomoteurs de sorte à ce que si tu les bouge bien en même temps cela fasse le mouvement que tu souhaitais réaliser sur ton sumo, mais que si tu bouges tes servo en sens inverse ça joue sur l'angle de la pelle ...

Bonjour

 

J'ai un problème avec mon sumo avec la pelle devant et je pense en connaître la raison. La "pelle" est motorisée avec 2 servos , qui sont dont liés mécaniquement. En fait j'ai flingué un servo très rapidement. Je suppose que cela vient du mode de pilotage, qui consiste à les piloter l'un après l'autre , même degré par degré, ce qui met une contrainte sur le mécanisme et les deux servos. 

 

Vous validez cette hypothèse ?

 

Erreur de débutant...

As tu bien calibré tes servomoteurs avant de les lier mécaniquement?

Exact !!! ce sont celles que j'ai achetées ici il me semble. Du coup je ne les ai jamais utilisées !

 

J'ai beaucoup utilisé des roues mecanum en effet , mais elles ont des dimensions trop importantes il faut moins de 26mm en largeur (tout compris). Avec ces roues je peux faire quoi, si je veux éviter d'acheter des roues mecanum plus petites  ?

Pour l'usage des roues omniwheel, disposé comme tu l'avais fait ça permet de faciliter la rotation sur soit même ( ce que tu vas je pense vouloir éviter en sumo ... sinon à la moindre poussette ton robot va facilement pivoter sur lui même ) ... Par contre les même roues mais positionnées différemment peuvent te permettre d'avoir un robot omnidirectionnel... Tu peux faire une config à 3 roues positionnés à 120° ou bien à 4 roues positionnés à 90° les unes des autres ... 

(English version here)

Bonjour à tous,

Cette année je participe à nouveau à la coupe de France de robotique, mais cette année je recommence avec une nouvelle équipe composée de 
pat92fr hdumcke (que j'ai tous les deux rencontré lors de la TRR ) et moi même. 
Pat à choisi le le nom de Marst Attacks! en référence au film éponyme, et par ce que le thème de l'année 2024 du règlement de la coupe de france de robotique,  c'est " Farming Mars ". Il a été dévoilé en septembre 2023.

C'est la première participation de pat92fr et hdumcke, (donc oui c'est moi qui les ais embarqué dans ce traquenard, mais oui promis ils sont consentants et non pas séquestré )  par conséquent on repart un peu du début, mais pas comme on est pas des débutant en robotique on va plutôt vite, et comme c'est la première fois qu'on travaille ensemble on prend un peu nos marques =). De plus comme ils sont tous les deux du côté de paris et que moi je suis dans le sud, du côté de biarritz on fait surtout des sessions en distanciels, cela n'aide pas forcément la chose mais ça va on s'en sort bien

Pour faire un peu le point sur là où on en est pour le moment : 

Mécaniquement : 

On part sur une base mecanum avec un lidar positionné assez bas de sorte à taper sur les bordures de la table pour se localiser ( mon expérience avec vigibot ) . Des contre axes sont ajoutés au niveau des roues dans le carrénage de protection pour soulager un peu les réducteur des moteurs et le train moteur avant est monté sur une liaison pivot afin d'avoir les 4 roues toujours parfaitement en contact sur le sol.

Quelques photo : 

La base assemblée vue de dessus : 

La base assemblée vue de face : 

La mise en évidence de la liaison pivot du train avant sans les roues : 

Vu de dessus du support moteur intégrant roulement et contre axe dans le carénage de roues : 


Vu de face du support moteur intégrant roulement et contre axe dans le carénage de roues

Pour cette base mécanum de robot on utilise : 

• 4 moteurs dji m2006 avec leur contrôleur C620
• 1 lot de 4 roues mecanum
• 8 roulements à collerette 8mm

ainsi que plusieurs pièces en imprimées en 3D (PETG) dont les fichiers seront partagées et pas mal de visserie.

Voilà à quoi ressemble l'outil pour le moment : 

 

Cet outil va être partagé avec différents exemple sur le github de l'outil de visualisation :  ( Les exemples de base ont déjà été partagé, l'idée étant de fournir des briques afin que chacun puisse développer l'outil qui lui convient à partir d'exemples )


Côté code du robot : 

Côté code du robot, pour le moment on s'est concentré essentiellement sur le pilotage du robot et sa localisation sur la table. L'ensemble tourne sur un stm32 avec l'envoie des données vers le visualisateur se faisant en wifi avec un esp32.

On a un actuellement un ensemble qui tourne même si c'est pas encore parfait et qui est connecté à notre visualisateur. 

Pendant les tests on obtient pour le moment ce genre de choses :

Dans cette vidéo on a un robot qui se déplace vraiment sur une table et ce qu'on voit c'est ce que le robot envoie comme données. 

Il affiche où il pense être sur la table,  et en rouge on voit les points lidar... 

On peut voir que vers 1min50 le robot touche un obstacle et perds sa localisation... Il faut qu'on travaille la partie la détection des robots adverse, c'est en cours de dev   mais les résultats sont déjà assez intéressant =). 


On a prévu de publier pas mal de choses mais il faut encore qu'on avance donc je vous dit à bientôt pour la suite ! =)
 

 

 

Voici la base, qui est déjà très compacte. il a fallu que je rabote les extrémités des moyeux des roues mecanum pour descendre à 100mm de largeur ! Et la longueur, compte tenu du diamètre des roues est déjà à 96 mm ! Et là pas possible de loger les batteries sous le robot !

Pour l'instant c'est du 100% compatible Lego, les roues et les servomoteurs (Geekservo)

 

20231120_062908.jpg

ça ce sont des roues omniwheels et non pas des roues mécanum et disposé ainsi ça ne te permettra pas de translater "en crabe "

ça, c'est du cube !

 

Si je comprends bien, tu optes pour le principe du bulldozer.

La pelle est motorisée ?

Oui visiblement la pelle est motorisée avec un petit servomoteur.

 

 

Et plutôt que d'utiliser un Arduino Nano et un Breadboard, j'ai préféré un Arduino Uno qui permet de fixer un petit câble de connexions entre ces deux pins.

 

Difficile de faire plus minimaliste pour se lancer dans l'étude du PID. 

 

Tu aurais pu utiliser une nano et mettre un fil femelle femelle  
En changeant de pin et en prenant le pin 3 à la place du 12 tu aurais même pu mettre un simple cavalier entre 2 et 3 vu qu'ils sont côte à côte  

Ensuite si tu veux quelque chose d'un peu plus " drôle " tu peux choisir une broche PWM ( comme par hasard 3 est aussi une broche PWM ) et chercher à modifier la valeur de pwm pour avoir un temps à l'état haut qui correspond à ce que tu souhaites ( par contre oui dans ce cas il va te falloir mettre ton interruption en " CHANGE " et non plus en RISING ... Et bien compter que le temps à l'état haut dans ton interruption ... ) Il va aussi peut être te falloir changer la fréquence de PWM sur le Timer 2 dans ce cas ... Bref tu peux éventuellement proposer cela dans un deuxième temps

 

Et par pitié, évite la famille des L298 : c'est des antiquités avec des performances horribles (https://www.st.com/r...asheet/l298.pdf) : à 1A, tu as entre 1.8V et 3.2V de perdu dans le pont en H, à 2A tu peux perdre jusqu'à 4.9V de tension. Toute cette tension est dissipée en chaleur, donc il faut refroidir le L298 (et tu vides inutilement ta batterie).

 

@Mike : pourquoi continuer à vendre un composant aussi antique? (il semblerait qu'il existait déjà au milieu des années 70 (https://forum.arduin...98-age/480905/2), c'est à dire quand mes parents étaient des gosses!)

Je suis d'accord pour dire que le L298 c'est pas le top du top et que c'est pas celui que je recommande le plus, ( d'ailleurs j'en ai à peine 25 en stock sur 3 références ... alors que j'ai plus de 50 pcs sur une seule référence pour d'autres produits de la même famille)  mais c'est un produit qui est moins cher que pas mal d'autre solution,  et "plus costaud " que d'autres solution ( plus costaud que le TB6612fng )  ... De plus il est fournit sur des cartes avec un forme factor intéressant et est présent dans de nombreux tutoriels ce qui en fait un produit demandé ... C'est un peu la loi de l'offre qui s'ajuste à la demande ... 

Par contre d'expérience il est pas si " horrible que tu le dis " ... Pour du 2A il chauffe pas tant que ça ... Il est largement utilisable... Plus utilisable que le TB6612FNG ... 
D'ailleurs sur un projet j'ai fini par remplacer les TB6612FNG qui étaient prévu initialement par des L298 carle client réussissait à suffisamment forcer sur ses moteurs ( qui étaient prévu pour 1A max en condition normale ) et réussissait à cramer le TB6612FNG ... Après remplacement plus de soucis ... 

Bref pour un meilleur rendement et pas trop de courant et pas trop cher il y a des nouvelles références qui marchent bien, mais si tu veux un truc solide, pas cher et que le rendement c'est pas ta priorité N°1 , le l298 a encore selon moi une petite place ... En 70 le matériel fabriqué à cette époque il était encore costaud... Je suis sûr qu'il sera encore utilisé dans 50 ans ce composant ... x)

Après si tu me recommandes d'autres driver de moteur pour la plage de 3A en continue, qui sont costaud est pas cher ( genre 6€ 7€ max ) je suis preneur de référence pour remplacer le L298 ...

 

* Un "agile" que j'imagine avec des roues mécanum

 

 

Je suis un très grand fan des roues mécanum mais typiquement les compétitions sumo c'est vraiment un cas où je n'utiliserais pas ce type de roues ...