Je suis passé dimanche et c'était chouette d'avoir vu votre robot en vrai
Malheureusement pas vraiment eu le temps de dire bonjour.

Bonjour Loic,

Malheureusement je ne pense pas que le code donné par cet IA soit vraiment utilisable ...
Je pense qu'il serait plus intéressant de justement apprendre petit à petit d'écrire un code qui marche

Ludo

Hello Victorien,

Pour répondre à tes questions, est-ce que tu as un élément de référence absolu sur lequel te baser (et donc définir le 0 azimut) ou bien il faut que le capteur puisse le faire par rapport à la terre ?

Ludo

Hello GerardB,

Comme dit par Forthman ce qu'il faut savoir c'est si il va y avoir des pertubations dans ton système ou bien c'est faire tourner un arbre à vitesse constante sans variations des efforts appliqués.
Si on peut faire cette hypothèse, ce que tu dois également calculer c'est le couple nécessaire pour pouvoir choisir le bon moteur (de tel manière à avoir un système qui puisse au moins accélérer jusqu'à sa vitesse nominale).

Mais sinon pour le régulateur, il vaut mieux d'abord être certain du choix de ton moteur pour être sur qu'il convienne

Ludo

Hello !

Pour tout ce qui est software, je rejoins Mike, c'est un peu challengeant de faire quelque chose de performant (je m'y suis un peu frotté).
Je peux te conseiller de jeter à un œil à QMK qui est l'outil utilisé pour créer le code de plein de clavier (open-source ou non) et qui est aussi compatible avec beaucoup de mcu: https://qmk.fm/(et il y a plein de features sympa qui sont déjà implémentée) mais c'est un peu barbu.

Ludo

Bonjour bvking,

Pour être certains de bien avoir compris tu veux implémenter:
y0 = f(t)
ton signal de base qui oscille entre 0 et pi

yi = f(t-i*0.5) avec i compris entre 1 et 9

Ludo

Hello,

Si on fait l'analyse du système avec:
- ωo = la vitesse de la roue orange
- ωg = la vitesse de la roue grise
- ωb = la vitesse de la roue bleue
- ωv = la vitesse de l'arbre vert
- ωn = la vitesse de l'arbre noir

Si on pose que les vitesse sont positive quand elles rentrent dans le plan par le haut (pour ωo, ωv et ωn) et quand elle rentre dans le plan par la droite (ωg, ωb ) on peut écrire les équations:
ωv + ωg = ωo
ωv - ωg = ωn
ωn + ωb = 0
ωn - ωb = ωv
ωo = 3ω

Alors peut déduire que
2ωn = ωv
ωb = - ωn
ωg = ωn
3ωn = ωo
Et donc que
ωn = ωg = -ωb = ω
ωv = 2ω
ωo = 3ω



Ludo

Bonjour,
Si j'ai bien compris la proposition 1, c'est dire que le rapport de transmissinon est de 1/3 ?

Ludo

Hello !

Est-ce que tu aurais les dimensions générales de la boite, les différents matériaux et épaisseurs utilisées ?
Sinon au lieu de mettre la carte horizontalement, tu ne peux pas la mettre verticalement ? Ça serait éviter une protubérance trop importante. Il faudrait même voir si ce n'est pas possible de la cacher complètement (mais avec une boite légèrement plus profonde -- ça peut avoir des avantages ou des défauts donc je dirais peut-être creuser plus ce que tu veux)

Aussi il faut voir ce que tu veux par plus solide. Avec des matériaux fins, tu vas avoir un peu de flexion si on pousse dessus. Mais normalement Il ne vas pas y avoir beaucoup d'effort sur la boite et elle ne va pas se désagréger toute seule. Par contre si tu veux que ça soit plus rigide tu peux soit rajouter des bords soit rajouter des vis au milieu.

Je te dirais aussi de prévoir complétement ton assemblage (avoir des spacers entre ta plaque de plexi et ta plaque rouge) même à comment tes vis vont être fixées.


Ludo

Mais déjà beau boulot pour la réalisation actuelle

Rebonsoir,

En gros ma proposition était de n’utiliser que la dernière trame envoyée par le PC (et donc de ne pas utiliser les autres). Mais vu ce que vous voulez faire, ça ne s’applique pas vraiment.

Réaliser une pile Fifo sur l’Arduino va me sembler plus compliqué à gérer (si vous êtes des crack pas de soucis ). Quelque chose où il faut faire attention c’est la taille du buffer de la communication Série entre le PC et l’arduino. Si je ne me trompe pas l’arduino ne vas stocker que 64 Bytes.
Renvoyer l’info au PC est un bon moyen de ne pas se préoccuper de ça.

Une autre piste à explorer est d’envoyer plus de trame pour une même trajectoire (et donc d’avoir des différences entre la position actuelle et la position suivante plus petite ce qui pourrait améliorer le résultat).

Une video du bras en action pourrait intéresser les membres du forum !


Ludo

Bonjour Phil2P,

pour moi ta méthode actuelle (le PC pour les calcules complexe et l'arduino pour le contrôle des moteurs) est la bonne.

Si je comprends bien le soucis actuelle c'est que l'arduino reçoit trop de trames que le système (arduino + bras) ne sait traiter et qu'il faut donc diminuer le nombre de trame (ou bien accéléré les éxecutions des trames mais ce n'est pas spécialement possible).
Tes 2 propositions vont marcher à mon avis mais je pense que réduire le nombre de trame envoyée par l'ordinateur sera le plus simple à implémenter. Une autre amélioration que tu peux ajouter c'est que l'arduino vide le buffer de la communication série et n'utilise que le dernier message complet (elle pourrait donc passer des trames).

Et pour mieux comprendre le problème, les trames que vous envoyez c'est pour juste obtenir une position finale ou bien vous voulez suivre une trajectoire précise ?


Bien cordialement,
Ludo

Hello,

La documentation de geeetech est pas top je trouve mais à partir du moment ou l'imprimante est montée, il y a moyen de s'en sortir.

Peut-être commence par vérifier que tout est bien branché voir si ça règle le soucis de l'écran.


Ludo

Hello !

Ce sont 2 problèmes différents mais liés. Le plus simple serait de prendre des photos de ton compteur avec ton appareil photo au même endroit (donc en essayant de bouger le moins possible entre les prises)

et ensuite d'essayer de détecter cette transition. Une méthode que tu peux tester c'est:
- Convertir l'image en niveaux de gris
- Faire la différence pixel par pixel entre tes 2 images
- Faire la somme du carré de ces différences

- Voir quel est le seuil pour lequel tu détectes une différence significative

Ensuite passer à comment intégrer ça sur ton arduino.

Mais bien sur tu peux d'abord acheter la caméra et l'utiliser pour prendre des photos mais tu seras peut-être limité par la puissance de ton arduino.
La caméra que tu as link est compatible justement avec l'arduino donc pas de soucis la dessus.

Ludo

Hello !

Le prix d'une camera Huskylens est presque de 40€ ce qui fait le combo arduino + Huskylens plus cher que celui de la rpi + caméra mais bref passons

Si tu n'utilises pas une caméra intelligente mais que tu fais sur le traitement sur ton arduino il faut voir si ton taux de rafraichissement sera suffisant pour ton application.

Ludo

Hello,

Gérer une caméra avec un arduino c'est peut-être trop compliqué et directement utiliser une raspberry pourrait te faciliter la tâche (vu que tu as alors accès à open-cv pour faire de la reconnaissance d'image).
Mais sinon une idée à tester c'est d'utiliser un capteur de couleur sur le dernier chiffre et voir si la différence entre les chiffres est suffisante et pour être détectée.

Ludo

Bonne année !

Je t'avoue que comme ça va être compliqué de lire quoi que ce soit sur ta carte
 

Et bien hésite pas à poster une photo de la carte et de la liste des éléments à brancher pour pour qu'on puisse t'aider:)

Ludo

Hello,

Normalement si tu regardes ta carte de contrôle, il devrait y avoir des indications sur quoi doit être branché (motor X, motor Y, Hot end,...) donc tu peux déjà voir si tu arrives à identifier pas mal de tes cablâges

Ludo

Hello,

Je voudrais revenir sur ces points:
 

• Gestion d'un seul moteur plus simple

Pour moi tu as quand même 2 moteurs à gérer. Celui qui va faire avancer ton robot et celui qui va orienter la roue de ton robot donc pour moi le niveau de difficulté reste le même

• Consommation moindre puisque un seul moteur de traction

Il est vrai que tu n'as plus qu'un seul moteur mais celui lui doit faire le même travail que ce qu'effectuait tes 2 moteurs donc si tu veux garder le même couple, vitesse .... tu vas devoir prendre un moteur plus puissant.

• Précision du guidage

Il est possible que tu puisses avoir un contrôle plus fin de ton guidage (en fonction de la précision de ton servomoteur/moteur pas à pas)

• Souvent les 2 moteurs bien qu'identiques ne tournent pas exactement à la même vitesse

Cela est vrai. Cependant généralement, on va contrôler nos moteurs en vitesses (à l'aide d'une boucle de rétro-action) et donc si on a un contrôle intelligent (et pas juste appliquer 12V aux bornes de chacun de tes moteurs) c'est un problème qui ne se pose pas. Et même dans ton second cas si tu veux rouler à une vitesse définie alors tu auras aussi besoin d'une mesure de vitesse (via encodeurs) pour ajuster ton contrôle.

Le soucis majeur de ta solution, est d'avoir un bon mécanisme pour orienter cette roue ce qui rajoute selon moi une toute autre complexité

Ludo

Bienvenue

Comme dis par Mike, si tu veux changer ton moteur, il faut connaître la vitesse et le couple que tu as besoin. Ici en regardant les numéros de série et en utilisant la datasheet (https://www.mfacomod...0DLN-series.pdf), il y a moyen de récupérer ces infos la

Si tu veux changer de moteur, tu dois alors chercher un moteur suffisamment puissant avec le bon réducteur pour avoir la vitesse souhaitée et le couple requis. Pour ce qui est de l'encodeur soit il est déjà compris avec le moteur (comme celui proposé avant) soit tu le trouves en plus et il peut se rajouter sur ton axe de transmission (par exemple j'ai l'habitude de travailler avec l'amt102 qui est fait pour s'adapter sur plusieurs diamètres).

Hello,
Le message dit en gros qu'il ne trouve pas ton arduino (... can't open device ...) pour régler ce soucis tu peux regarder si ton arduino n'aurait pas changé de port. Si elle n'apparait plus tu peux tenter d'appuyer sur le bouton reset de ton arduino

Hello !
Super projet, tu as déjà commencé quelque part ?

Hello !

Est-ce que tu as déjà regardé pour un réducteur ?
Ça permettrait justement de régler ton soucis de moteur qui tourne trop vite et ton manque de couple.