G4st0n, bras robotisé

Oui, dans tous les cas il faudra pouvoir lire un fichier, quelque soit le type de codage du fichier.

Si l'arduino n'est pas assez rapide pour convertir du Gcode XYZ en Gcode ARZ** cela peut être fait par post traitement*** du Gcode sorti par CB.

** ARZ: je ne sais pas si ça existe, mais A= axe rotatif de la base , R= axe lineaire = extension du bras, Z = axe linéaire mouvement en hauteur

bien sur, R est une combinaison de 3 rotations qui donnent l'extension + le maintient à la verticale du stylo et même chose pour Z ; cela pourrait même être également pré-calculé de façon à sortir un Gcode qui donne directement les valeurs angulaires des 4 axes rotatifs (ABCD), de cette façon l'arduino ne fait que lire un Gcode 4 axes rotatifs et tourner les moteurs de la valeur donnée, sans avoir à faire de calculs autres que la converion angle -> nb de pas/dir sur le moteur.

*** post traitement

le PP de CB peut lancer un programme externe (.exe) juste après avoir sauvé le Gcode, c'est ce programme externe qui pourrait lire le Gcode XYZ généré par CB pour le transformer en Gcode ARZ ou ABCD. A écrire avec n'importe quel langage capable de gérer des paramètres en ligne de commande (VB, C, Python etc)

++
David

Oups !  je viens de voir qu'il n'y avait que 3 axes et pas 4, donc si je comprends bien, les biellettes forcent la tête porte stylo à rester perpendiculaire à la table ; un truc de moins à gérer

++
David

Bonjour et félicitations pour ce beau projet que je suis dans l'ombre depuis un moment, si cela peut aider il est possible de passer facilement des coordonnées cartésienne (x;y) au coordonnées polaires ( r;téta)
pour téta entre -pi et pi on a :
téta = arctan(x/y) valable juste pour x>0 il faut ensuite ajouter pi selon le signe du rapport (x/y)
et r = racine carrée (x²+y²) un simple Pythagore.
si un logiciel est capable de transformer un dessin en coordonnées cartésienne, la transformation en cordonnées polaire est programmable.

Bon casse tête pour la suite.

Salut à tous

F6FCO, joli boulot

Si ça t'intéresse, je peux passer quelques minutes à te convertir les coordonnées d'un point en cartésien en polaire, voire même te calculer les angles qu'il faut donner aux axes pour que la pointe du stylo soit à une position en cartésien donnée.
Pour calculer tout ça, il faut :
la hauteur de la base, la longueur des bras, et la position du stylo par rapport à l'axe du poignet (décalage en radial et en hauteu
Je suppose (j'espère) que tu as mis le stylo dans l'axe du bras, c'est à dire que si tu replies le bras, le stylo va en ligne droite passant par l'axe de la base.

Si tu veux, je dois en avoir pour une vingtaine de minutes le temps de faire le dessin.

Il faut aussi voir si tu veux uniquement dessiner (2d) ou si tu veux travailler en 3D.

Si dessin uniquement, il y aura une relation sur les angles du bras, pour que le stylo soit en contact avec la feuille (et pour le relever, tu pourras tourner autour du coude du robot, sans chercher à remonter verticalement, ce qui simplifiera les actions et donc, a priori, accélèrera les mouvements)

Voilà, si c'est ça, comme je te disais, si ça t'intéresse, je peux mettre ça au propre ce midi

Le souci c'est qu'au niveau architecture le bras ne fonctionne pas du tout comme une CNC, il n'y a pas d'axes XYZ bien perpendiculaires les uns aux autres. Un rotatif qui te trace des arcs de cercles, et deux autres segments qui sont liés mécaniquement l'un à l'autre, tu fais bouger celui du bas et celui du haut suit. On reviens à la cinématique inverse pour résoudre le problème de la position finale dans l'espace. Je ne pense pas que Cb soit fait pour calculer çà.

J'ai fait quelques petits calculs pour faire varier le deuxième angle en fonction du premier afin que la tête reste sur un plan horizontal si cela peut aider :


j'ai un java qui fait bouger tout cela aussi si cela t'interesse

F6FCO a écrit:Le souci c'est qu'au niveau architecture le bras ne fonctionne pas du tout comme une CNC, il n'y a pas d'axes XYZ bien perpendiculaires les uns aux autres. Un rotatif qui te trace des arcs de cercles, et deux autres segments qui sont liés mécaniquement l'un à l'autre, tu fais bouger celui du bas et celui du haut suit. On reviens à la cinématique inverse pour résoudre le problème de la position finale dans l'espace. Je ne pense pas que Cb soit fait pour calculer çà.

Re'

J'ai bien compris que ce n'est pas un portique ou une cnc classique.
Mais ton dessin, il est en 2D avec des coordonnées XY. Ce que je te proposais, à la façon de Smalldave, c'est de transformer le XY du dessin en angles de rotation des bras du robot (trigo/géométrie dans l'espace)

Exactement, c'est bien comme çà que je compte faire aussi En fait on parle tous de la même chose. J'ai déjà pas mal réfléchi à l'affaire avant de tout commencer, vous pensez bien que je ne me serai pas lancé dans un truc pareil si je n'entrevoyais pas la fin. Ce qui ne m'empêchera peut-être pas de me planter au final.   on verra bien.
Voilà comment je vois le truc, et je pense que çà rejoint vos pensées, pour parler tous de la même chose il faut établir des conventions:

1/ Pour définir une position précise dans l'espace on a un bras à deux segments (appelons les "seg_bas" et "seg_haut") et ce bras pivotant sur une base (appelons-la "rotate"). Seg_bas étant le segment fixé sur la base rotative et Seg_haut le segment portant le stylo. Le point à atteindre, appelons-le point_cible.
Sur la photo lire "Point POP" (Prise Origine Pièce) au lieu de "Point POM", erreur de ma part en commentant la photo.

2/ Il faut une référence, ce sera la base de l'axe de rotation, le point qui correspond au centre de fixation du robot sur la Table. Tout sera calculé à partir de ce point.

3/ Il faut définir des conventions pour s'y retrouver et parler tous de la même chose, le point dans l'espace sera en coordonnées XYZ. Pour cela on se place en face du bras, le moteur de rotation complètement derrière. (je l'ai pris volontairement un peu de travers pour qu'on voie mieux).



4/ Pour travailler le programme à besoin qu'on lui indique des angles. Le point 0,0,0 de la feuille de dessin sera à la position POP .

5/ On ne peut pas réfléchir en axes comme sur une CNC alors on va travailler à partir des coordonnées du point et calculer les angles de tout le monde pour y arriver (toujours la fameuse cinématique inverse). En premier lieu calculer les deux angles formés par rotate/seg_bas et seg_bas/seg_haut pour déterminer la distance Y et la hauteur Z du point_cible.
b= longueur seg_bas
a= longueur seg_haut
c= Y
Point P= point_cible


C'est valable seulement si on utilise un stylo sur une feuille plaquée sur la table avec Z=0. Si on veut travailler dans l'espace il faut encore définir le triangle rectangle définit par le plan de la table, Y et la hauteur Z et dont C serait l'hypothénuse. Pas grand chose à faire, un peu de Pythagore mais des calculs supplémentaires pour l'arduino.



Le souci c'est qu'on ne peut pas définir un angle d'après un cos() avec les instructions de l'arduino, peut-être qu'il existe une librairie mais je ne sais pas. Donc il va falloir créer une table cos/angle en prenant exemple sur les tables papier qu'on utilisait à l'école et aller l'explorer à chaque calcul de position. Çà me plait moyen parce que çà va super ralentir le programme.

6/ Après il reste à définir la distance X en calculant l'angle à donner à rotate de la même façon. Je m'y intéresserais quand ce sera le moment si j'arrive à ce stade mais çà ne me semble pas insurmontable.

Po po pôôôô, je viens de voir en me relisant que ce sera encore un peu plus compliqué que çà car la base de seg_bas ne sera pas située sur la table mais à une hauteur Z au dessus de rotate. Il faudra recalculer Z en tenant compte.
Donc encore un peu plus de calculs pour ce pauvre arduino



Donc en premier définir C en calculant l'hypothénuse du triangle rectangle noir --> C²=Hauteur base²+Y².
Ensuite se servir de C pour calculer les cos(alpha) et cos(oméga). Comme il peut y avoir une infinité de postions valables des deux segments pour y arriver on peut forcer alpha par exemple et en déduire oméga.

Ensuite en tirer les angles en explorant une table.

Je ne comprends pas... a et b sont des longueur fixe!

si c'est le cas il n'y a qu'une solution possible pour alpha et oméga une fois que c est calculé!

il y a un truc qui m’échappe?

Mais oui tu as raison, c'est moi qui me suis laissé emporter

F6FCO a écrit:
Le souci c'est qu'on ne peut pas définir un angle d'après un cos() avec les instructions de l'arduino, peut-être qu'il existe une librairie mais je ne sais pas. Donc il va falloir créer une table cos/angle en prenant exemple sur les tables papier qu'on utilisait à l'école et aller l'explorer à chaque calcul de position. Çà me plait moyen parce que çà va super ralentir le programme.

F6FCO a écrit:Po po pôôôô, je viens de voir en me relisant que ce sera encore un peu plus compliqué que çà car la base de seg_bas ne sera pas située sur la table mais à une hauteur Z au dessus de rotate. Il faudra recalculer Z en tenant compte.
Donc encore un peu plus de calculs pour ce pauvre arduino

sinon tu peux utiliser un developpement limité pour estimer la valeur du arcus cosinus



mais c'est au voisinage de 0  
et pas sur que cela allege le nombre de calculs pour l'arduino, meme si ceux la, il sait les faire

t'es sur que arduino sait pas faire un inverse cosinus ???? bizarre, si il sait pas d'origine, tu dois surement trouver une lib qui le fait

atan , acos et asin normalement ? sinon faut mathlib

https://www.arduino.cc/en/Math/H

#define acosf   acos

#define asinf   asin

#define atanf   atan

par exemple
double acos ( double __x )

The acos() function computes the principal value of the arc cosine of __x. The returned value is in the range [0, pi] radians. A domain error occurs for arguments not in the range [-1, +1].

F6FCO a écrit:
Donc en premier définir C en calculant l'hypothénuse du triangle rectangle noir --> C²=Hauteur base²+Y².
Ensuite se servir de C pour calculer les cos(alpha) et cos(oméga). Comme il peut y avoir une infinité de postions valables des deux segments pour y arriver on peut forcer alpha par exemple et en déduire oméga.

Je rejoins samuel, a et b etant connu, c aussi garce à Y et HBase connue, il 'ny a qu'une seulle valeur possible pour Oméga et Alpha ...

Oui je me suis trompé .
Ben non il n'a pas çà en stock: http://www.mon-club-elec.fr/pmwiki_reference_arduino/pmwiki.php?n=Main.Reference
Je vais aller explorer cette librairie math que je ne connaissais pas. Sinon s'il rame trop j'aurai toujours la solution de migrer vers un Rasperry, j'ai vu qu'on pouvait relier un Rasp et un arduino en I²C. Mais il me faudra me mettre au Python.

Pour les souci de acos , j'utilise en ce moment un truc qui va vous paraitre ridicule mais comme je n'ai pas peur je vous montre:

C'est scratch , une appli de programmation sur laquelle on peut coller une arduino et il y a pas mal de fonctions mathématiques. en plus comme c'est accessible à des élèves de primaires j'y arrive bien


http://arduinooo.com/main/11-blog/42-programmez-un-arduino-avec-scratch

Hello

J'adore ce sujet
Je vous lis avec les 2 yeux grands ouverts car c'est quand même un peu technique

vivement la suite !

Smalldave a écrit:Pour les souci de acos , j'utilise en ce moment un truc qui va vous paraitre ridicule mais comme je n'ai pas peur je vous montre:

C'est scratch , une appli de programmation sur laquelle on peut coller une arduino et il y a pas mal de fonctions mathématiques. en plus comme c'est accessible à des élèves de primaires j'y arrive bien


http://arduinooo.com/main/11-blog/42-programmez-un-arduino-avec-scratch

hello

tiens, on dirait du blocky, le langage utilise dans mon soft de domotique pour faire des macros basiques

Je ne suis pas fan de ce genre d'aide à la programmation, çà te sort un code pré-programmé parfois (souvent) lourd. Et quand on a un bug ou une erreur de programmation, on fait comment pour relire le code et la trouver ?

F6FCO a écrit:Je ne suis pas fan de ce genre d'aide à la programmation, çà te sort un code pré-programmé parfois (souvent) lourd. Et quand on a un bug ou une erreur de programmation, on fait comment pour relire le code et la trouver ?

Hello

ben tu recommences avec les légos

pour des trucs basiques, ou qq qui ne connait rien en programation, c'est pas mal mais pour du basique et s'initier, faut pas lui en demander plus, mais ca suffit pour donner le gout pour aller plus loin
surtout qu'un connaisseur, il risque de se faire pieger, car dans mon soft de domo par exemple, le blocky if . . then . . else if . . . ne fait pas du tout ce qu'on croit, et c'est troublant, il execute tout et ne s'arrete pas a la premiere condition verifiee, et quand tu geres un volet avec ce genre de condition au comportement particulier, ben tu fais un yoyo un peu comme les visiteurs, jour nuit jour nuit

Simulation d'une éolienne EDF de 120m plantée dans ta cour

Le danger avec ces legos c'est d'en prendre l'habitude et de ne pas pouvoir se remettre en question pour recommencer avec de la vraie prog. La même chose que moi pour la 3D, je me suis forcé à faire l'étude du bras sous Freecad pour l'apprendre, j'ai bien progressé mais y'a pas, dés que je veux faire un petit truc rapide je saute sur Sketchup. Dur de couper le cordon.

F6FCO a écrit:Simulation d'une éolienne EDF de 120m plantée dans ta cour

Le danger avec ces legos c'est d'en prendre l'habitude et de ne pas pouvoir se remettre en question pour recommencer avec de la vraie prog. La même chose que moi pour la 3D, je me suis forcé à faire l'étude du bras sous Freecad pour l'apprendre, j'ai bien progressé mais y'a pas, dés que je veux faire un petit truc rapide je saute sur Sketchup. Dur de couper le cordon.

pas toujours quand meme, prends labview, bon, c'est pas du lego basique comme l'etait testpoint, mais cela evite des tonnes de code, et faut quand meme encore savoir programmer, et meme bien programmer, mais de maniere differente

Hello tous,
Maintenant que j'en suis arrivé à la prog du maître et en y réfléchissant plus profondément je me rend compte que je n'ai peut-être pas choisi l'architecture idéale pour faire du dessin. Pour amener le crayon à un point XYZ précis pas de problème. Pour l'envoyer à un autre point précis XYZ pas de pbm non plus. Mais pour que le stylo reste sur le papier entre les deux points ? C'est qu'il va falloir recalculer les trois angles des segments mais çà impose des calculs en plus en permanence si on veut maintenir un Z constant pendant les déplacements.
Théoriquement c'est possible je subodore que çà va prendre un temps fou et que ce ne sera peut-être pas viable avec un pauvre arduino. Il y a bien une tolérance faite par le ressort poussant le stylo pour maintenir la pointe en contact mais elle a des limites.

L'archi idéale aurait été de concevoir un bras avec seulement deux segments qui se déplacent horizontalement et un petit système pour le relevé/descente du stylo. Il aurait suffit de lui donner le prochain point à atteindre et çà aurait suffit pour faire de beaux tracés.
Prochain projet dans les cartons

Si tu avais voulu faire simple pour écrire tu n'aurais pas fait un bras... mais sans difficulté pas de joie à réussir

Ah mais je continue à persister dans la même voie, suis pas arrivé là pour m'enfuire. C'était juste une petite constatation issue de mon pauvre cerveau déliquescent qui commence seulement à percuter sur les tenants et les aboutissants. Le but premier c'était de construire un bras robot et de le rendre valide, çà c'est fait, maintenant comme j'ai de la suite dans les idées je me tourne vers les utilisations possibles. Dans l'ordre le dessin étant une de mes préférées, maintenant si au final çà ne fonctionne pas ou mal on lui fera faire autre chose
2) du morse.
3) passer en mode poursuite quand ma femme quand elle vient dans l'atelier, allumer une vilaine diode rouge, mode [G4st0minator] et lui tirer un élastique dans les cheveux.

toutenbois a écrit:Si tu avais voulu faire simple pour écrire tu n'aurais pas fait un bras... mais sans difficulté pas de joie à réussir

C'est rigolo, moi c'est encore avec mon bras que j'écris le mieux

Bon, assez de bêtises, oui, garder le stylo en contact avec le papier impose des mouvements de chaque moteur simultanément, si il ne sont pas à la même distance de la base. Après, il faut voir aussi si quand tu joins deux points, tu le fais forcément en ligne droite ou pas.

Le truc çà va être de définir plein de points intermédiaires. Çà risque de ralentir pas mal le processus.