93 réponses à ce sujet

[pmdd]

pmdd : Quel est le modèle de ton chargeur ?

 

J'achète ce modèle là: https://www.amazon.f...yY2hfYXRm&psc=1

 

Il y a un chargeur avec.

[pmdd]

Bonjour à tous

 

J'ai reçu mes batteries LIPO 800 mah, 30g c'est impressionnant. Je n'ai jamais voulu passer le cap, mais il faut reconnaitre que ça vaut le coup d'avoir quelques contraintes. Pour mes sumos c'est une vraie piste d'amélioration.

 

J'ai donc refait complètement mon suiveur de ligne pour l'alléger au maximum et aussi pour permettre le changement des moteurs sans aucun démontage.

 

Mon autre objectif reste de faire un robot cartérisé et esthétique. C'est ma limite perso. Je garde aussi l'écran ldc très pratique pour visualiser les paramètres et les informations des 8 capteurs de ligne. Je supprime les encodeurs de mise au point, tant pis, j'ai passé une semaine à coder, c'est sur mon compte de formation...

 

J'ai gagné 13 g sur la cartérisation (23%), 12g sur le chassis (29%), 21g sur les encodeurs que j'ai supprimés (100%), 10g sur les roues + pneus (28%), 18g sur le support batterie (90%) et 61g sur la batterie (67%). J'arrive à un poids final de 257g contre 392g, ce qui est très satisfaisant (avec 57g de carters)

 

Je vais maintenant déterminer la motorisation que je peux installer sur ce robot. Je repars des moteurs à 500 rpm et je vais monter progressivement en vitesse (et donc perdre en couple) jusqu'à ce que mon robot ne soit plus gérable. Je vais aussi essayer en même temps de diminuer le diamètre des roues, j'ai remarqué que la gestion des trajectoires et la réaction aux ordres étaient beaucoup plus efficaces avec des roues de petit diamètre. J'ai fait trois modèles : diamètre  32 mm, 27mm et 22mm et des largeurs différentes, le tout avec des pneus silicone taille très basse pour optimiser le poids.

 

A l'occasion de ce projet , j'ai découvert des très petites vis auto-taraudeuses que j'utilise pour assembler carters et chassis (il y en a 26 sur ce suiveur de ligne !), qui remplace avantageusement les systèmes de vis-écrous que j'ai utilisés sur les sumos, lourds et avec plus de contraintes à l'impression 3D (empreintes hexagonales)

 

 

 

 

Une question: que faut-il faire avec 2 batteries Lipo: alterner leur utilisation ou en stocker une ?

[Oracid]

Une question: que faut-il faire avec 2 batteries Lipo: alterner leur utilisation ou en stocker une ?

Perso, sur un robot, j'utilise toujours la même batterie. Mais c'est vraiment un choix.

SI cela ne t'embête pas de la changer à chaque fois, alors oui tu peux alterner, mais je n'en vois pas vraiment l'intérêt.

Néanmoins, dans un concours, il est toujours préférable d'avoir une batterie de secours, chargée en permanence.

[Mike118]

En dehors de la période de concours, si tu dois stocker une batterie il est préférable de ne pas la stocker à 100% chargée surtout si c'est pour un stockage prolongé... 
30% de charge seulement est recommandé ...

L'avantage d'alterner est que tu as une usure à peu près uniforme sur tes deux batteries ... 

[pmdd]

Bonjour à tous

 

J'ai reçu mes batteries LIPO 800 mah, 30g c'est impressionnant. Je n'ai jamais voulu passer le cap, mais il faut reconnaitre que ça vaut le coup d'avoir quelques contraintes. Pour mes sumos c'est une vraie piste d'amélioration.

 

J'ai donc refait complètement mon suiveur de ligne pour l'alléger au maximum et aussi pour permettre le changement des moteurs sans aucun démontage.

 

Mon autre objectif reste de faire un robot cartérisé et esthétique. C'est ma limite perso. Je garde aussi l'écran ldc très pratique pour visualiser les paramètres et les informations des 8 capteurs de ligne. Je supprime les encodeurs de mise au point, tant pis, j'ai passé une semaine à coder, c'est sur mon compte de formation...

 

J'ai gagné 13 g sur la cartérisation (23%), 12g sur le chassis (29%), 21g sur les encodeurs que j'ai supprimés (100%), 10g sur les roues + pneus (28%), 18g sur le support batterie (90%) et 61g sur la batterie (67%). J'arrive à un poids final de 257g contre 392g, ce qui est très satisfaisant (avec 57g de carters)

 

Je vais maintenant déterminer la motorisation que je peux installer sur ce robot. Je repars des moteurs à 500 rpm et je vais monter progressivement en vitesse (et donc perdre en couple) jusqu'à ce que mon robot ne soit plus gérable. Je vais aussi essayer en même temps de diminuer le diamètre des roues, j'ai remarqué que la gestion des trajectoires et la réaction aux ordres étaient beaucoup plus efficaces avec des roues de petit diamètre. J'ai fait trois modèles : diamètre  32 mm, 27mm et 22mm et des largeurs différentes, le tout avec des pneus silicone taille très basse pour optimiser le poids.

 

A l'occasion de ce projet , j'ai découvert des très petites vis auto-taraudeuses que j'utilise pour assembler carters et chassis (il y en a 26 sur ce suiveur de ligne !), qui remplace avantageusement les systèmes de vis-écrous que j'ai utilisés sur les sumos, lourds et avec plus de contraintes à l'impression 3D (empreintes hexagonales)

 

 

20240711_060811.jpg

 

 

Une question: que faut-il faire avec 2 batteries Lipo: alterner leur utilisation ou en stocker une ?

Bonjour à tous

 

Malgré l'optimisation du poids du robot et l'utilisation du double coeur du pico, j'ai beaucoup de mal à gagner en vitesse. Actuellement je fais ma boucle à 0.95 m/s et je ne parviens pas à faire mieux. j'ai essayé des moteurs de vitesse et de couple différents. Rien y fait. Dès que j'arrive à une vitesse donnée en fin de ligne droite (environ 2m/s), je ne parviens pas à prendre le virage à 90°.  Le robot file tout droit. J'ai essayé beaucoup d'algorithmes différents, en vain. 

 

Tout se passe comme si le temps entre la détection de la ligne et les ordres donnés aux moteurs était trop long. Est-ce possible ? Suivant les drivers peut-on avoir des différences ? 

[pat92fr]

Tu peux afficher la courbe de vitesse de rotation (consigne PWM et RPM mesuré) des deux moteurs pendant une boucle et notamment pendant un virage serré.

 

Si la cause n'est pas un problème d'adhérence des roues, alors il peut s'agir d'un manque de couple/vitesse/accélération des moteurs.

 

Plus la voie est importante et plus la motorisation est mise à l'épreuve pour les courbes serrées.

 

--edit : Autre cause, l'asservissement en direction mal réglé. Tu peux afficher la position de la ligne et les commandes moteurs (PMW droit et gauche). 

[pmdd]

Tu peux afficher la courbe de vitesse de rotation (consigne PWM et RPM mesuré) des deux moteurs pendant une boucle et notamment pendant un virage serré.

 

Si la cause n'est pas un problème d'adhérence des roues, alors il peut s'agir d'un manque de couple/vitesse/accélération des moteurs.

 

Plus la voie est importante et plus la motorisation est mise à l'épreuve pour les courbes serrées.

 

--edit : Autre cause, l'asservissement en direction mal réglé. Tu peux afficher la position de la ligne et les commandes moteurs (PMW droit et gauche). 

 

Le fait de programmer en micropython et non pas en C++ peut-il être une cause de latence ?

[Oracid]

Le fait de programmer en micropython et non pas en C++ peut-il être une cause de latence ?

Un 32bit, ça va vite, alors qu'un servo, c'est lent.

La réponse d'un servo ou d'un moteur, c'est en millisecondes. Ton processeur est en microsecondes.

Même en langage interprété, à mon avis, le maillon faible, c'est le moteur.

 

Mais, j'attends avec impatience, l'avis de personnes plus compétentes que moi.

[pat92fr]

Sauf accident dans l'implémentation logicielle, ca ne devrait pas être le facteur limitant. Tu devrais chercher du coté du temps de réaction de ton asservissement et du couple de tes moteurs.

[pmdd]

Sauf accident dans l'implémentation logicielle, ca ne devrait pas être le facteur limitant. Tu devrais chercher du coté du temps de réaction de ton asservissement et du couple de tes moteurs.

 Tu as probablement raison.

 

Ce projet, qui est basique et simple, est pourtant celui qui me donne le plus de fil à retordre. J'arrive à gérer une vitesse de pointe de 1 m/s et prendre un virage serré à 90°. Au-delà je pars en ligne droite ! je suis loin de mon objectif de 2 m/s, qui est peut-être trop ambitieux pour moi.

 

J'étais persuadé que j'avais un problème de temps de réaction entre le capteur de ligne et la commande moteur. J'ai creusé cette piste, en refaisant mon code plusieurs fois, en essayant d'optimiser les temps et même en passant d'un capteur (module de 8 capteurs) digital à un capteur analogique. J'ai essayé plusieurs solutions avec la programmation sur les 2 cores du Pico. En vain. J'ai fini par mesurer mes temps pour m'apercevoir qu'ils étaient très courts et que ce n'était pas le problème. Je pensais aussi rater des mesures, ce n'est pas le cas non plus.

 

De plus je suis obligé d'inverser le sens de rotation d'un moteur pour pouvoir prendre un virage serré. Ce n'est vraiment pas favorable pour les moteurs que je flingue régulièrement, électriquement ou mécaniquement. Ma carte avec les drivers ne permet pas de freiner les moteurs.

 

Bref, je bosse beaucoup sur le sujet, j'apprends mais je ne progresse pas.  La suite c'est :

 

* De passer à un driver TB6612FNG qui manifestement permet le freinage ? - Ce n'est pas ma tasse de thé, va falloir que je fasse quelques soudures pour faire ma propre carte.

* De changer encore de moteur pour que vitesse et couple correspondent à mon objectif. Ce n'est pas facile de trouver sous 8.4V

 

Ma question du jour : 

 

Est-ce que c'est un problème de piloter les deux moteurs avec une seule carte TB6612FNG, ou est-il intéressant d'en avoir une par moteur ? Cela permet-il d'absorber des pics d'intensité plus importants ?

[Oracid]

Voici une vidéo sur le driver de moteur TB6612FNG  :

Bon courage !

[pat92fr]

 Tu as probablement raison.

 

Ce projet, qui est basique et simple, est pourtant celui qui me donne le plus de fil à retordre. J'arrive à gérer une vitesse de pointe de 1 m/s et prendre un virage serré à 90°. Au-delà je pars en ligne droite ! je suis loin de mon objectif de 2 m/s, qui est peut-être trop ambitieux pour moi.

 

J'étais persuadé que j'avais un problème de temps de réaction entre le capteur de ligne et la commande moteur. J'ai creusé cette piste, en refaisant mon code plusieurs fois, en essayant d'optimiser les temps et même en passant d'un capteur (module de 8 capteurs) digital à un capteur analogique. J'ai essayé plusieurs solutions avec la programmation sur les 2 cores du Pico. En vain. J'ai fini par mesurer mes temps pour m'apercevoir qu'ils étaient très courts et que ce n'était pas le problème. Je pensais aussi rater des mesures, ce n'est pas le cas non plus.

 

De plus je suis obligé d'inverser le sens de rotation d'un moteur pour pouvoir prendre un virage serré. Ce n'est vraiment pas favorable pour les moteurs que je flingue régulièrement, électriquement ou mécaniquement. Ma carte avec les drivers ne permet pas de freiner les moteurs.

 

Bref, je bosse beaucoup sur le sujet, j'apprends mais je ne progresse pas.  La suite c'est :

 

* De passer à un driver TB6612FNG qui manifestement permet le freinage ? - Ce n'est pas ma tasse de thé, va falloir que je fasse quelques soudures pour faire ma propre carte.

* De changer encore de moteur pour que vitesse et couple correspondent à mon objectif. Ce n'est pas facile de trouver sous 8.4V

 

Ma question du jour : 

 

Est-ce que c'est un problème de piloter les deux moteurs avec une seule carte TB6612FNG, ou est-il intéressant d'en avoir une par moteur ? Cela permet-il d'absorber des pics d'intensité plus importants ?

 

Un seul CI devrait suffire pour commencer avec deux moteurs pololu.

 

Tu n'as vraiment aucune donnée de télémétrie à partager pour analyser ton asservissement ? Difficile de t'aider sans aucune information sur ce qui se passe dans ton robot.

 

Sur mes suiveurs de ligne et micromouse, lorsque la consigne de vitesse varie fortement (décélération max), il est normal d'envoyer au moteur un courant inverse à sa rotation pour le freiner (un court instant). En revanche, il n'est pas normal de négocier un virage en ayant besoin d'inverser le sens de rotation de la roue intérieure (les dimensions du chassis sont inadaptées au circuit dans ce cas). Le plus courant est de freiner voire d'arrêter la roue intérieure en virage serré.

 

https://youtu.be/d8e...qG4d98KsMJYVSa1

 

 

Si l'asservissement est correct, le moteur ne va pas griller. Une moteur pololu a une durée de vie de quelques heures en usage intensif. C'est suffisant pour la mise au point et quelques courses (compétitions).

 

 

 

Patrick.

[pmdd]

 

Un seul CI devrait suffire pour commencer avec deux moteurs pololu.

 

Tu n'as vraiment aucune donnée de télémétrie à partager pour analyser ton asservissement ? Difficile de t'aider sans aucune information sur ce qui se passe dans ton robot.

 

Sur mes suiveurs de ligne et micromouse, lorsque la consigne de vitesse varie fortement (décélération max), il est normal d'envoyer au moteur un courant inverse à sa rotation pour le freiner (un court instant). En revanche, il n'est pas normal de négocier un virage en ayant besoin d'inverser le sens de rotation de la roue intérieure (les dimensions du chassis sont inadaptées au circuit dans ce cas). Le plus courant est de freiner voire d'arrêter la roue intérieure en virage serré.

 

https://youtu.be/d8e...qG4d98KsMJYVSa1

 

 

Si l'asservissement est correct, le moteur ne va pas griller. Une moteur pololu a une durée de vie de quelques heures en usage intensif. C'est suffisant pour la mise au point et quelques courses (compétitions).

 

 

 

Patrick.

Non pour l'instant je n'enregistre aucune donnée. On verra pour la suite si nécessaire.

Effectivement ce n'est pas normal de devoir tourner dans l'autre sens pour prendre un virage.

 

En fait mon problème venait bien de l'impossibilité de faire du freinage actif avec mon driver. Avec le TB6612FNG ça marche nickel et instantanément en freinant plutôt qu'en tournant en sens inverse, j'ai gagné 2s sur les 8m du circuit ! (5.76 s/8m)

 

Du coup j'ai des perspectives pour atteindre les 4 secondes, en particulier en optimisant le PID (pour l'instant je ne travaille qu'avec le coefficient proportionnel) et en mettant au point un 2ème PID plus agressif pour les virages. En fait ça ouvre la porte à la suite (y compris la taille des roues et le type de pneus...) 

[pat92fr]

Le Kd peut jouer un rôle important dans les entrées/sorties de virages, pour stabiliser le robot.

 

J'utilise en générale deux valeurs de Kp et une même valeur de Kd :

- Le premier Kp sert à maintenir le robot sur la ligne afin de compenser les petites erreurs de positionnement.

- Le second Kp (plus grand) sert à suivre les virages.

 

Enfin, lorsque le robot perd la ligne, l'asservissement bascule en boucle ouverte, et on fait tourner le robot au maximum (arrêt de la roue intérieur) du coté de dernière ligne détectée, en espérant la récupérer.

 

Patrick.

[pmdd]

Le Kd peut jouer un rôle important dans les entrées/sorties de virages, pour stabiliser le robot.

 

J'utilise en générale deux valeurs de Kp et une même valeur de Kd :

- Le premier Kp sert à maintenir le robot sur la ligne afin de compenser les petites erreurs de positionnement.

- Le second Kp (plus grand) sert à suivre les virages.

 

Enfin, lorsque le robot perd la ligne, l'asservissement bascule en boucle ouverte, et on fait tourner le robot au maximum (arrêt de la roue intérieur) du coté de dernière ligne détectée, en espérant la récupérer.

 

Patrick.

Tu arrives à prendre les virages à 90° avec une gestion PID ? Pour l'instant je n'y arrive pas, pour les valeurs extrêmes des capteurs j'ai une action basée sur une règle simple, je freine la roue intérieure et fait tourner très vite la roue extérieure.

 

J'ai un autre problème, où le PID spécial virage , plus agressif, fonctionne aussi parfois en ligne droite et du coup j'ai des oscillations. Je me dis qu'on doit pouvoir répérer qu'on est en ligne droite ou en virage avec les séquences de mesure des capteurs. Fais tu cette distinction pour appliquer les valeurs de PID adéquates ?

 

Je suis descendu à 4s91 pour 8 mètres ce qui est déjà très bien, mais mon robot oscille beaucoup et je n'ai pas trouvé comment régler ce problème juste en optimisant les PID. Sans oscillation je ne dois pas être loin de mon objectif de 4s. J'ai l'impression que ces oscillations proviennent du PID agressif pour les virages.

 

Je vais essayer d'enregistrer toutes les lectures des capteurs sur un tour, mais j'ai peur que l'écriture en RAM génère de la latence et modifie le comportement du robot ?

[Sandro]

Si tu as des oscillations sur un PID, tu peux essayer :
- de diminuer Kp

- de diminuer Ki

- d'augmenter Kd

 

Après, intrinsèquement, si tu modifie brusquement la consigne, un PID aura tendance à osciller (sauf si tu le règles très peu réactif). En général, si des oscillations (ie dépassements) sont autorisés, alors la meilleure solution consiste en de petites oscillations qui s'atténuent rapidement (si tu oscilles longtemps une fois revenu en ligne droite, alors ton PID est probablement mal réglé).


Si tu dispose de l'information nécessaire, alors une bonne "astuce" est de combiner le PID avec une consigne en boucle ouverte.
Par exemple, pour aller à 1m/s en ligne droite, tu calcules que chaque moteur doit recevoir un PWM de 200.
Donc au lieu de juste demander au PID de "trouver" le PWM correct, tu donne à tes moteurs la consigne 200+PID_gauche et 200+PID_droite , avec PID_gauche/droite le correctif calculé par PID (dans un monde idéal 0, en pratique, de petites valeurs, qui compenseront la différence entre tes 2 moteurs, les frottements, ... bref, tout ce que tu ne sais pas calculer/modéliser).
Si brusquement tu change d'objectif (par exemple tu sais que tu as un virage de rayon R vers la droite), tu calcules que pour le parcourir à 0.8m/s, il te faut envoyer un PWM de 160+30 à gauche, et 160-30 à droite. Tu enverra donc 160+30+PID_gauche au moteur gauche, et 160-30+PID_drotie au moteur droit.

De cette manière, tu peux changer brusquement de consigne sans avoir besoin d'une valeur Kp importante (ce qui entraîne souvent les oscillations), tout en ayant le PID qui te permet de corriger si tu pars un peu trop à gauche ou à droite.


NB : cette approche est "facile" si tu connais ta trajectoire (par exemple par caméra), avec de simples capteurs alignés comme ça semble être ton cas, il faudrait un peu creuser pour savoir comment calculer la courbure du virage.



Pour l'enregistrement en RAM des valeurs des capteurs, il n'y a quasiment aucun risque que ça augment significativement la latence (à priori, lire le capteur devrait être aussi coûteux voir bien plus que de l'enregistrer en RAM), sauf si le code est très mal optimisé. N'hésites pas à poster ton code si tu veux qu'on y jette un coup d'oeil

[pmdd]

Si tu as des oscillations sur un PID, tu peux essayer :
- de diminuer Kp

- de diminuer Ki

- d'augmenter Kd

 

Après, intrinsèquement, si tu modifie brusquement la consigne, un PID aura tendance à osciller (sauf si tu le règles très peu réactif). En général, si des oscillations (ie dépassements) sont autorisés, alors la meilleure solution consiste en de petites oscillations qui s'atténuent rapidement (si tu oscilles longtemps une fois revenu en ligne droite, alors ton PID est probablement mal réglé).


Si tu dispose de l'information nécessaire, alors une bonne "astuce" est de combiner le PID avec une consigne en boucle ouverte.
Par exemple, pour aller à 1m/s en ligne droite, tu calcules que chaque moteur doit recevoir un PWM de 200.
Donc au lieu de juste demander au PID de "trouver" le PWM correct, tu donne à tes moteurs la consigne 200+PID_gauche et 200+PID_droite , avec PID_gauche/droite le correctif calculé par PID (dans un monde idéal 0, en pratique, de petites valeurs, qui compenseront la différence entre tes 2 moteurs, les frottements, ... bref, tout ce que tu ne sais pas calculer/modéliser).
Si brusquement tu change d'objectif (par exemple tu sais que tu as un virage de rayon R vers la droite), tu calcules que pour le parcourir à 0.8m/s, il te faut envoyer un PWM de 160+30 à gauche, et 160-30 à droite. Tu enverra donc 160+30+PID_gauche au moteur gauche, et 160-30+PID_drotie au moteur droit.

De cette manière, tu peux changer brusquement de consigne sans avoir besoin d'une valeur Kp importante (ce qui entraîne souvent les oscillations), tout en ayant le PID qui te permet de corriger si tu pars un peu trop à gauche ou à droite.


NB : cette approche est "facile" si tu connais ta trajectoire (par exemple par caméra), avec de simples capteurs alignés comme ça semble être ton cas, il faudrait un peu creuser pour savoir comment calculer la courbure du virage.



Pour l'enregistrement en RAM des valeurs des capteurs, il n'y a quasiment aucun risque que ça augment significativement la latence (à priori, lire le capteur devrait être aussi coûteux voir bien plus que de l'enregistrer en RAM), sauf si le code est très mal optimisé. N'hésites pas à poster ton code si tu veux qu'on y jette un coup d'oeil

Merci beaucoup pour toutes ces pistes que j'explorerai. Je combine déjà les PID avec une consigne en boucle ouverte.

Mon robot revient aussi très bien sur la piste après en être totalement sorti, mais évidemment ce n'est pas le but au niveau chrono.

Je m'aperçois aussi que le couple est très important dans la réaction au dfifférents paramètres du PID. Et ce couple est évidemment aussi en lien avec le diamètre des roues. L'adhérence à la piste qui doit être optimisée, ni trop forte, ni trop faible...cela fait beaucoup de paramètres pour un si petit projet !

Mes moteurs de 3000 RPM sont trop rapides. Du coup je ne les utilise pas au maximum de leur capacité, ce qui fait perdre du couple, alors qu'il n'est à la base déjà pas très élevé. Je vais essayer avec des 2000 RPM,, suffisamment rapides pour atteindre mon objectif, avec un couple 30% supérieur et qui seront utilisés beaucoup plus proches de leurs caractéristiques nominales.

[pmdd]

Bonjour à tous...

 

La suite de ma galère pour atteindre ces foutues 4s/8m sur mon circuit.

Après avoir travaillé avec un petit moteur polulu de vitesse 3000 RPM mais avec un couple faible , j'ai changé totalement de version. J'atteint une limite avec ce moteur à cause de son faible couple. Malgré des centaines de tests de paramètres PID, à une certaine vitesse je n'arrive plus à le maîtriser.

Je suis donc passé à un moteur légèrement plus gros (21g) , avec un couple nettement supérieur mais avec une vitesse beaucoup plus faible (750 RPM) que j'ai compensée avec un diamètre de roue supérieure et une utilisation à pleine capacité. J'arrive grosso modo à la même vitesse et là, je n'arrive pas à maîtriser les oscillations du robot, malgré tout un tas d'essais de PID, ou de boucles ouvertes ou pas... Je ne m'en sors pas, pourtant j'arrive à 4.85s/8m avec de grosses oscillations , ce qui me laisse penser que je pourrais atteindre mon objectif de 4s si je parvenais à supprimer ces oscillations.

 

Les roues de fort diamètre et ce couple rendent difficiles la maîtrise des trajectoires. J'ai testé des PID avec des coefficients dynamiques, des ramp-up pour les accélérations...rien n'y fait, mon robot oscille. J'arrive à lui donner une très belle trajectoire, mais avec un temps de 6s/8m...

 

Les essais sont compliquées à chaque fois il faut avoir une batterie chargée à 100% et des pneus parfaitement nettoyés (avec un nettoyant particulier pour assurer une adhérence maximale).

 

Je suis un peu en stdby, c'est finalement beaucoup de temps passé pour peu de progression.

 

je ne sais pas si le réglage du PID peut-être amélioré, en tout cas j'ai beau avoir suivi toutes les méthodes préconisées, je n'y parviens pas.

 

Je vais tenter le coup avec des petits moteurs de 2000 rpm, plus coupleux que les 3000 et donc que je vais pouvoir utiliser à 80% de leur vitesse avec des roues de faible diamètre, ce qui est favorable pour la tenue de route.

 

Image(s) jointe(s)

• 

[Oracid]

Voici 2 vidéos qui pourraient t'inspirer. Vas -tu aussi vite ?

En tout cas, il donne pas mal d'informations.

J'espère que ça pourra t'aider.

Désolé, je ne peux pas faire mieux.

 

 

 

[pmdd]

Voici 2 vidéos qui pourraient t'inspirer. Vas -tu aussi vite ?

En tout cas, il donne pas mal d'informations.

J'espère que ça pourra t'aider.

Désolé, je ne peux pas faire mieux.

 

 

 

 

 

Merci Oracid, c'est vrai que ces vidéos font envie quand on voit la trajectoire du robot. J'en ai regardé beaucoup, je crois que je me suis tapé tout youtube au niveau des suiveurs de ligne...

 

Pour ce qui est de l'équipement de mon robot, c'est exactement celui de ta 2ème vidéo quand je suis en configuration moteur 3000 rpm, avec le pico à la place de l'arduino (même capteur en 8 , mêmes moteurs)

 

Je vais au moins aussi vite semble-t-il mais j'ai honte de ma trajectoire !

 

A ma décharge, mais je l'assume, mon robot a un carénage qui le rend plus lourd et donc l'inertie est plus importante. mais esthétiquement il n'y a pas photo.

 

Voici un tour de circuit de 8m en 5s...