127 réponses à ce sujet

[Sandro]

Quand je parlais de binaire, j'entendais ne pas envoyer le "texte" des valeurs (ni en décimal, ni en binaire, ni en hexadécimal), mais directement envoyer l'octet correspondant à la valeur.

 

Quand tu envois le texte "80,"  , tu envois 3 octets, chacun codant en ascii un caractère. En occurrence, tu enverra les octets 0x38("8") 0x30("0") et 0x2C(",")

A la place, tu pourrais envoyer un seul octet, 0x50 qui vaut 80

 

L'avantage est multiple :

- tu envois 1 octet au lieu de 3 (sous réserve d'envoyer des nombres entre 0 et 255, ou alors entre -128 et +127)

- tu n'as plus de traitement complexe (sscanf) à faire, il suffit de lire chaque octet et de l'affecter à la variable souhaitée

 

Le principal inconvénient est que les données sont un poil moins "lisibles" par l'homme.

 

 

Pour ma part, j'envois en général les trames sous le format suivant :

octet_constant_de_début_de_frame   octet_longueur_de_la_frame D1 D2 D3 ... DN octet_checksum

 

- l'octet constant de début de frame(trame) est une valeur constante "quelconque", qui permet de retrouver le début des frames si on est complètement perdu (je prends souvent 42 ou 0x42, mais n'importe quelle valeur pas trop utilisée par ailleurs est bien aussi.

- octet_longueur_de_la_frame : si les trames n'ont pas une longueur fixe, j'envois la longueur de la trame (dans le cas contraire, pas la peine)

- j'envois ensuite les données sous forme d'octets (nb : si j'ai besoin de nombres ne rentrant pas sur un octet, je sépare manuellement entre octet de poids fort et octet de poids faible, au cas où les deux ordinateurs/controleurs n'utiliseraient pas la même conventionà

- enfin, j'envois une checksum (somme module 256 ou xor), qui permet d'identifier les trames invalides

[Little french kev]

J'ai fait ce que Sandro explique pour mon dernier projet .

Le code peut etre trouvé sur mon site : https://www.littlefr...-controller-arm

 

Le code est fait pour etre utilisé sur unity mais ca reste du C# donc il y a moyen de juste récupérer la fonction qui envoie les octets au arduino .


Je me suis inspiré des exemples donnés sur le forum arduino : https://forum.arduin...0764#msg1810764

[Oracid]

Le code peut etre trouvé sur mon site : https://www.littlefr...-controller-arm

Si tu ne comprends pas, tu mets en FR. Tu verras, c'est plus cool !  

[Little french kev]

Si tu ne comprends pas, tu mets en FR. Tu verras, c'est plus cool !  

Il faut que je me motive à faire la traduction !!! J'ai pas d'accent sur mon clavier ducoup ca me prend un temps fou!

[Jean Brunet]

Merci à tous les deux, j'ai chargé le code. 

Reste à voir comment je vais intégrer cela.

[Jean Brunet]

J'avais écrit mon logiciel sur PC en un temps record, sans trop débuguer.

 

Si vous avez déjà programmé avec les évênements windows, vous savez sans doute qu'un évênement sur un champs de saisie peut déclancher un évênement sur un ascenseur horizontal, qui lui même peut très bien déclancher l'évênement dans le champs de saisie etc... etc...

Quand on travaille avec 15 ascenseurs horizontaux cela devient coton. J'étais arrivé à un truc de fou, quatre trames partaient en rafale pour chaque déplacement d'une commande groupée. Pas étonnant que cela se bouscule à l'arrivée.

 

Euh, va falloir que je revois cela demain.

[Jean Brunet]

Le programme avance, toutefois j'ai des difficultés avec ce code. Il ne fonctionne pas, la trame n'est pas lue.

byte ch2[20]; 
int o = Serial.readBytes(ch2, 14);
  if(o == 14){
       calculPos(ch2[0],ch2[1],ch2[2],ch2[3],ch2[4],ch2[5],ch2[6],ch2[7],ch2[8],ch2[9],ch2[10],ch2[11],ch2[12],ch2[13]);
 }

[Sandro]

que vaut "o"?

Est-ce que tu vérifies avant combienttu as d'octets disponibles (Serial.available() te donne le nombre d'octets dispo dans le buffer)?

[Jean Brunet]

Je vais faire les tests. Par contre ce code fonctionne, mais il faut que je vérifie si tous les octets sont disponibles.

 while (Serial.available()>0) {
                  gb = Serial.read();
                  ge = Serial.read();
                  gc = Serial.read();
                  db = Serial.read();
                  de = Serial.read();
                  dc = Serial.read();
                  Agb = Serial.read();
                  Age = Serial.read();
                  Agc = Serial.read();
                  Adb = Serial.read();  
                  Ade = Serial.read();
                  Adc = Serial.read();
                  tms = Serial.read();
                  Nbi = Serial.read(); 
                 }
                  calculPos(gb,ge,gc,db,de,dc,Agb,Age,Agc,Adb,Ade,Adc,tms,Nbi);

[Sandro]

Et si tu remplaçais

 while (Serial.available()>0)

par

 while (Serial.available() >= 14)

ça permettrait de ne traiter les données que s'il y en a assez.

 

Et est-ce volentaire que calculPos est en dehors du while?
 

[Jean Brunet]

Merci, je vais faire le test avant, ce sera plus sur.

Oui c'est volontaire pour calculPos, je lis d'abord mes variables sur le port série, puis je lance la routine de calcul et je positionne les servos.

D'ailleurs un 

if (Serial.available() >=14)

est suffisant dans ce cas il me semble.

[Jean Brunet]

Bon, finalement ce fonctionne parfaitement en mettant

 if(Serial.available() == 14) {
      gb = Serial.read();
// etc... 14 variables
}
  else
{
 // vide le buffer
 while(Serial.available () > 0){
    Serial.read(); 
}

Vider le buffer solutionne tous mes problèmes de saturation du buffer, je recommande cette fonction.

[Jean Brunet]

Bien, les choses avancent. J'ai repris à 90 % mon logiciel et implanté un transfert de données par byte, évité la saturation du buffer série.

J'ai aussi revu la présentation du programme "Little Jo". De nouveaux films vont venir. 

Oracid, penses-tu que l'on puisse ajouter la technique de la cinématique inverse avec un paramétrage personnalisé ?

 

PS. J'ai reposté l'image du programme, je le change encore selon mes essais.

Image(s) jointe(s)

• 

[Oracid]

Oracid, penses-tu que l'on puisse ajouter la technique de la cinématique inverse avec un paramétrage personnalisé ?

Désolé, mais je ne comprends pas vraiment ta question.

 

Si tu fais référence à ma petite étude, https://www.robot-ma...-pour-les-nuls/,  toutes les longueurs du 5 barres peuvent effectivement être modifiées. Depuis, je suis passé au 4 barres, ce qui simplifie légèrement les calculs. Je fais cela quotidiennement.

 

Dans ton cas, il s'agit d'un mécanisme "série" et non "parallèle". Et même si le principe mathématique est le même, je ne pense pas que tu puisses utiliser mon programme, tel quel.

 

Si tu as un minimum de capacité en maths, ce qui n'est pas mon cas, j'ai juste mon Certif, alors tu devrais y arriver.

Mais ai-je bien compris ta question ?

En tout cas, je suis modestement, très modestement, à ta disposition sur ce sujet.

[Jean Brunet]

Oui, excuses moi si ce n'étais pas clair. 

Je me demandais si je pourrais inclure dans mon programme un module de calcul de cinématique inverse qui donnerait les positions des servos pour éviter les contraintes sur les servos.

 

Avec mon programme je peux tatoner avec la souris pour obtenir le meilleur enchainement, mais c'est assez pointu, et il faut de la patience. Ceci dit cela permet de bien comprendre les efforts sur le robot et les problèmes d'équilibre.

 

Je comprends que j'ai encore de nombreuses heures à passer pour maîtriser le sujet.

 

Merci à toi pour tes vidéos, elles m'ont beaucoup apporté.

[Oracid]

Ton quadrupède comme les miens, sont assez simples dans leurs conception. Je pense qu'il faut commencer par quelque chose de simple, puis tu pourras en faire un autre plus complexe. Déjà, le tien a 12 DOF, ce qui est assez complexe pour débuter.

 

Tu pourrais commencer par faire un mouvement cyclique, c'est ce que je fais, qui fasse avancer ton quadrupède avec 8 DOF, ce serait une bonne étape.

Tu ne peux imaginer la joie de voir, la première fois, son quadrupède avancé. Ce serait ton premier objectif.

 

Si ton programme peut aider à programmer un cycle de marche, ce serait déjà pas mal.

Il faut bien comprendre que ton quadrupède peut être taillé pour très bien fonctionner, mais que malheureusement tu ne trouves pas le bon cycle pour le faire avancé.

 

Si tu as vu mes vidéos, tu as pu t'apercevoir que j'ai opté pour la simplicité en choisissant un mouvement rectangulaire pour mon cycle de marche.

Au début ce rectangle était dessiné de manière symétrique par rapport à l'axe Y de la patte. Avec un peu de chance, cela a bien fonctionné avec mes premiers quadrupèdes.

Mais, j'en suis revenu, de ce principe. Aujourd'hui, je translate le rectangle sur X, vers l'avant pour les pattes avants, et vers l'arrière pour les pattes arrières.

Je vois des vidéos où des quadrupèdes, mêmes sophistiqués, sont couchés sur les pattes arrières. Ils suffiraient de translater le rectangle (ou un autre mouvement) vers l'arrière pour résoudre ce problème.

 

Pour récupérer la position d'un servo, ce n'est pas très compliqué, pourquoi ne crées-tu pas un fil spécifique.

[Jean Brunet]

Je commence doucement.

 

Mon programme devrait me permettre d'enregistrer quelques mouvements. Mais pour l'instant il est tombé de la table et j'ai deux pièces à imprimer pour le remettre en état. Le mouvement "le dos me gratte" a été un peu violent ! :-) 

[Jean Brunet]

Les tous premiers pas.

 

 

Problème, il bascule quand je ramène la patte arrière gauche (le robot vu de dessus)

[Oracid]

Bon début !

 

Je me trompe peut-être, mais il me semble que les pas avants et arrières ont la même amplitude et les mêmes cordonnées de déplacement.

As-tu essayé de translater le mouvement un peu vers l'arrière pour les pattes arrières ?

 

Regarde bien les pattes arrières de Petoï (même configuration que toi), elles vont vraiment vers l'arrière.

[Jean Brunet]

ah oui, la configuration des pattes est différente sur l'arrière.

 

Du coup le centre de gravité est ramené vers le centre.

Les servos d'épaule sont penchés, ils mettent sans doute le 90° à l'équerre. En interchangeant les pattes arrières et en changeant l'angle au 90° je dois pouvoir retrouver la même configuration.