oui c'est vraiment du très beau boulot...

Voici le code utilisé et qui semble fonctionner à la fois pour recevoir des données et pour piloter le servo.

Je ne suis pas arrivé à utiliser la bibliothèque VarSpeedServo en même temps que la réception des données.

#include <Wire.h>
#include <Servo.h>

Servo myServo;
String cm1;
String m1;
String m2;
String m3;
int spd = 40;
int currentAngle = 0; // Angle actuel du servo
int targetAngle = 0;  // Angle cible du servo
int speed = 1;        // Vitesse de déplacement du servo

void setup() {
  Wire.begin(8); // Initialisation du module I2C avec l'adresse 8
  Wire.onReceive(rx);  
  myServo.attach(8);   
  myServo.write(0);   
}

void loop() {
  if (currentAngle < targetAngle) {
    currentAngle += speed;
    if (currentAngle > targetAngle) currentAngle = targetAngle;
  } else if (currentAngle > targetAngle) {
    currentAngle -= speed;
    if (currentAngle < targetAngle) currentAngle = targetAngle;
  }
  myServo.write(currentAngle); 
  delay(spd); // Délai pour ajuster la vitesse de déplacement
}

void rx(int bytes) {
  while (Wire.available()) {
     char c = Wire.read(); // Lecture des données reçues
     cm1 +=c;
  }
  m1 = cm1.substring(0,1);
  m2 = cm1.substring(2,7);    
  m3 = cm1.substring(8,14); 
  cm1 = ""; 
  char carray[m2.length() + 1]; 
  m2.toCharArray(carray, sizeof(carray)); 
  spd = 40;
  char carray2[m3.length() + 1]; 
  m3.toCharArray(carray2, sizeof(carray2)); 
  targetAngle  = atoi(carray2);   // angle
 }

oui absolument c'est intéressant. je ne connaissais pas. Merci Oracid.

Je teste. Même si j'ai un peu de mal à quitter la solution moteur pas à pas qui a été très chronophage

Merci Oracid,

Je me suis souvent servi de cette bibliothèque.

Mais dans le cas présent, l'Arduino Mega qui contrôle le moteur doit aussi recevoir des commandes d'un autre Arduino via I2C.

Et étant donné qu'il est monotâche le fait de faire des delay n'est pas optimal d'après ce que j'ai compris.

Il me semble que l'on ne peut pas régler la vitesse de déplacement du servo avec cette librairie ....

Bonjour Mike118 promis je vais tâcher de visiter la boutique Robomaker plus régulièrement.

Effectivement je vais devoir changer de moteur pour un moteur avec réducteur.

Ou alors ajouter un réducteur planétaire sur le moteur.

Je suis étonné que tu utiliserais plutôt le servo.

Le point le plus important à corriger dans ce cas serait la vitesse de déplacement. Je ne vois pas d'autre solution que d'utiliser un Arduino ou un ESP32 pour contrôler le servo.

Quelqu'un a-t-il déjà testé la librairie VarSpeedServo ?

Salut, J'avance aussi sur ce projet.

J'utilise une roue de guidage à l'arrière. Elle est commandée par un gros servo.

Les désavantages de cette solution :

- la rotation est limitée à 180°.

- les mouvements sont très rapides. Trop brutaux.

- le servo est assez bruyant. ...

Je suis en train d'essayer de remplacer le servo par un moteur pas à pas monté dans l'axe de la roue.

J'ai utilisé un Arduino supplémentaire qui reçoit les commandes et gère le moteur pas à pas avec la bibliothèque Accelstepper.h.

Les mouvements sont ainsi beaucoup plus progressifs.

Le problème c'est qu'après avoir fait de nombreux mouvements gauche / droite, le moteur ne revient pas parfaitement dans l'axe.

Et lorsqu'il y a un effort plus important appliqué sur la roue, le moteur perd des pas...

Il est vrai que les moteurs pas à pas c'est tout nouveau pour moi donc je loupe sûrement quelque chose.

Ou je n'utilise pas le bon matos :

Moteur Nema17HS19 Couple de maintien: 59Ncm

Contrôleur DRI0043 réglé sur 3.5A

https://www.gotronic.fr/art-commande-moteur-pas-a-pas-dri0043-25551.htm

La première impression c'est que le moteur n'est pas suffisamment puissant. La rotation de la roue ne nécessite pas un effort important.

Apparemment il faut une remise à zéro régulière.... bref c'est bien plus compliqué qu'il n'y paraît.

Voici ce que ça donne sur un robot miniature.

Bonjour

Oui il faut faire attention aux perturbations.

Voici les résultats obtenus après calibration magnétique.

Je les ai envoyés au support pour leur demander si ce sont des résultats "normaux" ou s'ils peuvent être améliorés.

Si c'est un résultat normal c'est assez décevant. Je vais dans ce cas chercher un autre récepteur de meilleure qualité.

Le Calcul sur le magnetic output semble donner de meilleurs résultats.

Dans la documentation du capteur la trame qui donne le "magnetic output" : 0x55 0x54 HxL HxH HyL HyH HzL HzH TL TH SUM
Calculated formular：
Magnetic(x axis)Hx=((HxH<<8)| HxL)
Magnetic(y axis)Hy=((HyH<<8)| HyL)
Magnetic(z axis)Hz=((HzH<<8)| HzL)
L'axe x du capteur est orienté vers l'avant du robot
La trame reçue du capteur : 55 54 A1 1A 0F F6 86 ED 00 00 DC
Je prends en considération HxL / HxH  A1 1A et HyL / HxH 0F F6

Après avoir fait un décalage de 8 bits vers la gauche et un OU binaire

Hx = 6817 et Hy = 62991

IF Hx > 32767 THEN Hx -= 65536
IF Hy > 32767 THEN Hy -= 65536

Ce n'est pas correct par rapport à une boussole

Une calibration est probablement indispensable pour obtenir des résultats cohérents.

Bonjour

Je souhaiterais utiliser un magnétomètre Wit Motion WT901CTTL pour récupérer la route magnétique suivie par un robot.

Donc l'angle entre le nord magnétique et l'axe du robot.

Le capteur WT901CTTL envoie une trame via le port série au format hexadécimal.

Savez-vous quelles valeurs il faut récupérer pour calculer l'angle par rapport au nord ?

Angle output ou magnetic output ou ..... ?

Voici ce que donne la doc :

6.1.4 Angle Output
0x55 0x53 RollL RollH PitchL PitchH YawL YawH VL VH SUM
Calculated formular：
Roll(X axis)Roll=((RollH<<8)|RollL)/32768*180(°)
Pitch(Y axis)Pitch=((PitchH<<8)|PitchL)/32768*180(°)
Yaw(Z axis)Yaw=((YawH<<8)|YawL)/32768*180(°)
Version calculated formula：
Version=(VH<<8)|VL
 

6.1.5 Magnetic Output
0x55 0x54 HxL HxH HyL HyH HzL HzH TL TH SUM
Calculated formular：
Magnetic(x axis)Hx=(( HxH<<8)| HxL)
Magnetic(y axis)Hy=(( HyH <<8)| HyL)
Magnetic(z axis)Hz =(( HzH<<8)| HzL)
Temperature calculated formular：
T=((TH<<8)|TL) /100℃

Exemple de calcul sur la trame Angle Output valeurs YawL YawH :

55 53 00 FF 94 00 16 16 CC 46 79

Calcul sur les valeurs : 16 16 ou 22 22 en décimal

Décalage de 8 bits vers la gauche de YawH et opération OU binaire cela donne :

1616 en hexadécimal et 5654 en décimal

5654 / 32768 * 180 = 31.058

Alors que l'angle devrait être de +/- 200°

Salut,

Je suis en train de faire un projet un peu similaire. Mais je souhaiterais qu'il soit multifonctions.

J'ai utilisé les moteurs de siège pmr mais ils sont très lourds et volumineux. Avec leur centrale de commande et joystick. J'ai finalement acheté les mêmes moteurs que toi. (mais axe de 17mm et je ne trouve pas de moyeu qui va là-dessus)

Le guidage peut se faire par gps rtk, AruCo, encodeurs, magnétomètre. (Mini pc embarqué et camera Jevois)

J'ai beaucoup cherché au niveau du guidage car sur un terrain plat le guidage avec les 2 roues motrices et 2 roues folles à l'arrière fonctionne bien. Par contre sur un terrain accidenté c'est autre chose. J'ai finalement utilisé un roue directrice à l'arrière commandée par un gros servo.

Je vais tester ce que ça donne avec une charge de 100 kg de terre.

Mais il me semble que la solution idéale serait une roue motorisée et directrice comme mentionné plus haut.....

Bonjour

Dans le cadre d'un projet de plateforme robotique j'envisage l'achat des balises Marvelmind qui permettent un positionnement précis en intérieur.

Le prix est assez conséquent : 900 eur avec les frais d'expédition.

Il me semble qu'il faut quand même investir un paquet d'heures pour atteindre des résultats valables.

Avez-vous déjà expérimenté cette technologie ?

Merci Sandro pour ce commentaire éclairant

Je ne cherche pas une grande précision au niveau du cap. C'est juste que le robot doit naviguer d'un point gps à un autre.

Je vais soumettre la question à Ardusimple.

Peut-être que je peux upgrader mon gps

En tout cas je confirme que la solution avec une roue directrice (et non folle) est bien utile dans mon cas.

Les trajectoires sont bien plus nettes.

C'est plus compliqué car il faut trouver les bons réglages de la roue par rapport aux vitesses des roues motrices.

Bonjour,

Quelques nouvelles du GPS RTK Ardusimple :

Je l'ai utilisé dans une pelouse entourée d'arbres et de maisons et la précision est RTK FIXED c'est à dire centimétrique. Donc dans un champ bien dégagé cela ne devrait pas poser de problème.

Je l'utilise sur un micro pc Windows 10 via une connexion série.

Il faut utiliser le soft U-center qui s'occupe de la réception des données en série et de la connexion avec le serveur NTRIP qui fournit la correction de position. Il faut donc une connexion internet en permanence. (je suis en Belgique donc j'utilise le réseau Walcors qui est gratuit pour l'instant)

Etant donné que mon application de guidage du robot a aussi besoin de la trame gps, il faut que le port série soit dupliqué.

J'ai finalement opté pour GPSGATE de Franson. Pas trop cher et fonctionne correctement.

Le dernier point qui reste à résoudre est que la trame NMEA venant du gps n'envoie pas le cap du robot. Je suppose que c'est parce qu'il roule trop lentement.

Je calcule donc le cap en fonction de la dernière position d'il y a 3 secondes par rapport à la position actuelle.

Le support Ardusimple est très efficace.

En résumé en ce qui me concerne cette solution Ardusimple me convient parfaitement.

Voici la bête

Je suis ravi d'avoir fait sa connaissance. Merci Oracid.

J'ai fait un montage provisoire et le servo fait le job.

Ce robot peut être guidé de 2 façons :

Mode manuel : avec une télécommande Spektrum DX8 qui commande 3 servos : marche avant - gauche droite (en faisant varier la vitesse des 2 roues de traction) et la roue arrière directrice. Quand le robot fait un virage à gauche il faut que la roue gauche ralentisse, la droite accélère et que la roue arrière pivote vers la droite. J'ai utilisé la fonction mixing de la télécommande spektrum qui permet d'actionner 2 servos sur un même canal. On va voir à l'usage.

Mode automatique : c'est le micro-pc qui dirige sur base des données du gps, de la camera AI, des capteurs de distance, ... Le mixage dans ce cas sera réalisé au niveau de l'Arduino qui commande les servos.

Pour l'instant j'ai bricolé avec une chaîne. Les pignons ne sont pas suffisamment solidaires des axes. Faut que je trouve une système simple et efficace pour fixer le pignon sur l'axe de 20mm de diamètre.

La chaîne "glisse" un peu sur les pignons ce qui n'est pas très précis quand on souhaite que la roue directrice revienne parfaitement dans l'axe. Peut-être qu'une courroie crantée serait préférable...

Passage de 4 roues à 3 roues effectué ...

Ok tu as raison, ma situation est bien moins à plaindre que la tienne.

J'espère qu'ils se rendent compte de la chance qu'ils ont d'avoir un papy comme toi !

Mais bon j'ai pas su attendre 15 dodo c'est trop long. J'ai commandé aussi ceci qui arrive demain...

oui je sais ... c'est honteux mais j'assume....

Il est vrai que ce servo est peut-être suffisamment puissant pour faire tourner la roue dans l'axe.

Mais si le servo est placé dans l'axe il va prendre de la place au-dessus de la roue et ce n'est pas souhaité....

Faudra attendre de le recevoir pour tester. Encore 15 dodo ... c'est long

Après différents essais et notamment la traction d'une remorque je vais supprimer les 2 roues folles et placer une roue centrale.

La commande directionnelle de la roue sera assurée par 2 pignons à chaîne et un moteur.

Etant donné que ce moteur va devoir faire plusieurs tours pour que la roue pivote de 180° un servo 10 tours comme mentionné par Oracid devrait faire l'affaire.

Je vais utiliser des pignons / chaîne de vélo pour la transmission.

Super le "gros" servo. Je ne connaissais pas. En effet cela ouvre des possibilités.... c'est ce qu'il me faut. Commandé.

C'est sûr que le swerve drive mentionné par Mike118 est génial. Mais cela me paraît trop compliqué pour moi à moins de trouver une grande roue de brouette motorisée directrice toute faite. Ce serait du bonheur.

A la limite une seule roue motrice serait même suffisante. Et 2 roues fixes à l'arrière.

En fait je souhaiterais conserver la mobilité des roues folles pour faire des virages sur place mais d'un autre côté stabiliser la trajectoire sur les lignes droites.

Je vais commencer par faire une maquette du système de direction.

Oui je ne sais pas si un servo serait assez puissant.

Il peut y avoir une centaine de kilos sur les 2 roues (donc 50 kg par roue)

Je pensais à un verin électrique mais je vais dessiner l'ensemble à l'échelle pour évaluer le déplacement à effectuer.

En tout cas merci pour vos suggestions.

Oui c'est sûr que ce serait bien. Mais ce n'est pas à ma portée. Et dans un hall industriel c'est probablement parfait mais dans l'herbe, terre, boue ...

Je préfère rester simple avec un truc de ce genre comme on trouve sur les micro tracteurs :

Il faut l'actionner via une crémaillère, un moteur ....

Bonjour

Je réalise un robot destiné à réalisé différents travaux extérieurs.

Poids +/- 150 kg à vide.

2 roues motorisées et 2 roues folles.

Modes de guidage : télécommande, camera AI et AruCo, Gps RTK

Equipement : micro pc, camera AI, Gps RTk, Arduino Mega

Comme pour la majorité des robots, le guidage se fait en faisant varier la vitesse de chaque roue.

Sur du terrain plat pas de problème, cela fonctionne bien.

Par contre sur un terrain accidenté, quand une roue rencontre un obstacle le robot part de travers car les roues arrière sont folles.

D'autant plus quand il est chargé de 60kg de terre.

La gestion de la vitesse de chaque roue n'est probablement pas optimale mais il me semble que si les 2 roues arrière étaient directrices (comme sur une voiture) la trajectoire serait plus facile à maintenir.

Cela nécessite l'utilisation d'un moteur supplémentaire qui va actionner la crémaillère. Moteur CC ? Moteur pas à pas ?

Avez-vous déjà utilisé ce système sur un robot ?

Merci pour vos commentaires.

Bonjour Oracid

Moi je suis d'accord avec Madame. Je trouve que c'est très bien. Très clair. Très didactique.

Merci beaucoup et continue stp.