Projet s2a (Single Arm Articulated)

Bonjour à tous,
je poste ici car j'ai un projet qui peut s'inclure dans le mouvement Reprap, du moins dans sa partie plastique, car il y a des points communs...

Mon objectif initial étant de créer un système de construction additive (et plus généralement de déplacement géométrique: par exemple pour découpe/marquage laser, placement CMS, etc...) le plus 'efficient' possible j'en suis venu à remettre en question le système 'classique' dit cartésien; j'ai étudié un peu les architectures 'delta' mais malgré leurs qualités indéniables elles ont des limitations/inconvénients qui me paraissent incompatibles avec l'évolution des applications envisagées dans le futur (par exemple construction à grande échelle pour véhicules, habitations, etc)
il existe aussi des alternatives de type SCARA (Morgan, Wally) ou POLAR qui sont très intéressantes mais qui selon moi, pour l'instant, restent trop complexes pour être efficaces; à moins de les "marier" dans des cas particuliers pour créer un genre hybride de type 'SCALAR' mais là je m'égare...

J'ai donc choisi une architecture de type bras articulé simple (d'où le nom) avec des articulations de type épaule (shoulder) et coude (elbow) produisant des déplacements angulaires correspondants à des coordonnées de type X et Y (cartésiennes) avec l'aide d'algorithmes simples basés sur des relations trigonométriques classiques.
http://www.invent2main.com/s2a-A5.png

Pour moi, cette architecture ne comporte quasiment que des avantages:
-faible encombrement
-pas de rails pour x et y (pas besoin de chassis encombrant/rigide)
-rapidité (selon charge)
-concept extensible en taille (extended working area)
-ajout simple de zone nettoyage/changement de couleur pour buse (sans réduire zone imprimable)
-bon ratio auto-replicable (plastique)
-nombre de pièces limitées (low part count)

Et les quelques inconvénients sont faibles par rapports aux avantages:
-mise au point/calculs plus complexes (transparent pour l'utilisateur)
-charge transportable plus faible que système cartesien

Actuellement j'ai donc commencé à fabriquer un prototype, sans le Z/élevation dans un premier temps afin de tester la répétabilité du système de coordonnées angulaire, mais le but est bien sûr de faire un prototype fonctionnel qui soit une 'preuve de concept'. Le format imprimable de la première version envisagée est de type A5 (demi-A4):
http://www.invent2main.com/s2a-t1.png
http://www.invent2main.com/s2a-t1b.png

J'en suis donc pour l'instant à essayer de modifier un firmware Marlin afin d'y inclure la cinématique "s2a" et c'est là que j'ai besoin d'aide, car même si étant électronicien je programme un peu, l'absence de doc/commentaires de ce code me pose quelques soucis (sans compter l'absence de debug de l'IDE Arduino!?)...
Y'a t-il des programmeurs dans le forum? Quelqu'un serait-il intéressé par ce projet?

merci d'avance
Pat

C est une imprimante scara.
Marlin fourni une configuration type pour ces imprimantes ; )

Bonjour One-T
c'est ce que je pensais aussi mais ce n'est malheureusement pas aussi simple !
Si le projet s2a-p peut effectivement faire partie de la « famille » générale SCARA, c’est une nouvelle variante par rapport à ce qui existe (à ma connaissance)
c'est vrai Marlin a intégré le type ‘Morgan’ et l’a baptisé SCARA mais la cinématique est différente et ils l’ont mélangé avec du code de type DELTA…

J'aime bien comme machine

Je ne sais pas si tu as suivi cette discussion : [forums.reprap.org]
Discussion sur teacup et les strategies d'implantation (notament ....retraiter le gcode avant de l'envoyer)

On y voit d'ailleurs cette machine : [www.heliumfrog.com] qui ressemble beaucoup à la tienne mais visiblement sa base est très imposante (stabilité ?)

Edit : sinon ici on parle d'une version en scara one arm [forums.reprap.org]
Edit2: ce que j'aime bien sur ton projet c'est que tous les moteurs sont en dehors du bras. Par contre effectivement ...il faudra voir la rigidité

Edited 3 time(s). Last edit at 06/16/2015 11:24AM by lyscanthrope.

Bonjour lyscanthrope,
j’avais déjà vu ces 2 projets mais ils n’ont pas aboutis pour l’instant (soft?) ; aussi, ils étaient basés sur des roues dentées imprimées (difficilement imprimables pour des courroies type GT2) ou intégrées (montage?) et j’ai trouvé une autre solution qui permet en plus de limiter le ‘backlash’ (la courroie est fixée sur une poulie)
HF06 est intéressant car le plateau est fixe ; mais cela doit effectivement engendrer d’autres contraintes (stabilité?)…
C’est le choix que je ferais pour des volumes/surfaces d’impression importantes (A4 ou supérieure) mais pour mon 1er proto type A5 j’ai choisi un plateau mobile ; ce n’est peut-être pas la meilleure solution mais cela permet d’avoir très peu de pièces imprimés : de l’ordre de la dizaine environ

Ce qui me pose souci (et probablement aussi aux autres projets) c’est vraiment le software : dès que j’ai une version qui fonctionne en 2D X-Y, je construis l’axe Z

Merci pour l’info Teacup je vais regarder cela ; J’avais choisi Marlin car il avait l’air assez répandu/universel mais je suis ouvert à tout…

Bonjour Invent2main,

Merci pour ta réponse, je trouve ton système de poulie très intéressant.
Le niveau soft est a mon avis assez complexe. Dans le dernier lien que je t'ai mis, il y a une version de marlin avec un support de scara "one arm". Si tu veux travailler avec marlin ca peut être une bonne base à mon avis.

Sinon tu peux reprendre le travail sur teacup (https://github.com/RobertKuhlmann/Teacup_Firmware_Scara/blob/6361e37554b8783526bcc48694cf14f4fa2fb30c/dda_maths.c) où un scara de type morgan a été implanté (ca sera peut etre plus simple que sur marlin).

Dernièrement....et je pense que c'est le plus simple pour debugger c'est travailler sur un pre-processing du g-code (par exemple en reutilisant [github.com] ), ca permettrai de ne pas perdre du temps sur un firmware et voir si la machine fonctionne bien. Bon après il faut regarder comment est fait le firmware de wally par contre ...

Juste quelques idées

Edited 2 time(s). Last edit at 06/17/2015 04:01AM by lyscanthrope.

merci encore pour les pistes...
il faut que je creuse un peu mais les 2 softs ont leurs avantages/inconvénients et des approches très différentes:

Teacup:
+code clair
+bien documenté
+léger
-pas d'utilisation en standalone (SD+LCD)
-pas de "Auto-bed-leveling"


Marlin:
+la référence (très actif)
+utilisation en standalone (SD+LCD)
+fonction "Auto-bed-leveling"
-code 'fouillis' et complexe
-bugs

je ne vois pas trop encore comment ça se passe niveau "pre-processing du g-code" et comment l’intégrer mais j'aime bien l'approche 'python', il faudrait que je m'y mette...
Après mon but n'est pas forcement de 'réinventer la roue' (même si des fois on n'a pas le choix) ; c'est dommage de ne pas pouvoir utiliser ce qui a déjà été fait par la 'communauté' ; il suffirait qu'il y ait un fichier 'kinematics' avec les différentes architectures (avec le bon #define) et chacun pourrait expérimenter librement; on serait probablement surpris des résultats!

pour le proto s2a, j'ai essayé avec Marlin (et leur version de SCARA) et ça fonctionne à peu près avec Repetier (pour les 1er tests ça suffirait) mais c'est la cinématique qui n'est pas bonne, le résultat est déformé (video du 1er test)

Ca semble plutot bien !
C'est avec le marlin standart ou le marlin modifié pour un seul bras (https://github.com/vitaminrad/Marlin-for-Scara-Arm) que tu as testé ?
Effectivement, il y a des soucis de dimensions ...soit les longueurs de bras soit les nombre de pas qui conviennent pas à priori. Tu les calibres comment ?

j'avais testé avec des Marlin modifiés (vitaminrad et un autre) mais c'était pire (bugs); le test de la video a été fait avec un Marlin 'normal' en mode "SCARA"; il me semble que j'ai mis les bons paramètres de longueur et de nombres de pas, j'ai plus l'impression que le problème vient de la géométrie particulière du type 'Morgan'.
J'ai commencé d’intégrer un #define s2a dans le code mais je me suis perdu rapidement... Je pense changer d'approche pour les tests préliminaires: je vais essayer de modifier la cinématique existante pour valider le concept et si ça ne marche pas, j'essayerai avec Teacup...

Je pense que changer la cinematique devrait être le plus simple (meme si ca sera "brouillon").

Bon courage !
Je suis très curieux de savoir ce que cela va donner !

[j'ai beaucoup de travail à finir sur mon imprimante pour la faire fonctionner correctement avant me mettre à une seconde ..désolé.. par contre je suis curieux de la taille maximale de tes pièces]

Edited 1 time(s). Last edit at 06/23/2015 10:41AM by lyscanthrope.

C'est un beau projet !

De ce que je vois, le plus simple dans un premier temps serait de modifier le G code avant qu'il soit interprété par marlin.
Si tu as réussi à le paramétrer à peu près pour qu'il fasse bouger le bras, c'est un bon début.
Ensuite pour faire un préprocess du code, je verrais quelquechose dans le genre de faire 'tracer' des formes de base: carré, rond
En analysant le tracé, cela permettrait de déduire les corrections à apporter au code pour que ça trace ce qui est demandé.
par exemple tu fais tracer une droite de 0,0 à 100,0 mais tu obtiens 0,0 à 90,10, tu sais qu'il y a une déviation de -10% sur le x et de 10 sur y.

Ensuite c'est sur que le mieux ce serait de taper dans le firmware de marlin, ce serait plus simple d'utilisation au final.
J'ai vaguement regardé le code pour me faire une idée, mais je ne suis pas allé plus loin, vu que je programme pour des micros de la concurrence et que je suis resté simple utilisateur

A mon humble avis, ça ne doit pas être très sorcier, mais vu toutes les remarques sur marlin disant qu'il y a des parties plus ou moins propres dans le code, ça peut prendre du temps !

La chose qui me fait sourire c'est que des machines cartésiennes essayent de dessiner des courbes et la tienne fasse l'inverse

Je plussoies la suggestion de faire des formes simples. D'ailleurs, la manière dont est déformée ton dessus, me demandais si ca ne pourrait pas être une question d'origine du bras (en plus de vérifier la cinématique).
Même si le pre-processing du g-code me semble le plus simple (en partant de rien), adapter un code pourrait être plus facile (et puis tu apprendras sur marlin d'ailleurs )

Bref, bon courage et on attend de tes nouvelles !

J'ai jeté un coup d'oeil en vitesse sur https://github.com/vitaminrad/Marlin-for-Scara-Arm
Une partie de la magie s'opère à partir de la ligne 4343.
A premiere lecture, je ne comprends pas trop les calculs qui se font pour x sur un seul axe et pour Y sur les deux. Je suis beotien.
Il faudrait que je retourne à mes notes de mécanique cinématique

A la deuxième lecture, je comprends mieux Même si je n'aurais pas mis ces noms de variables

Est-ce que tu as essayé avec cette version de marlin ?

Dommage que Marlin ne soit pas plus modulaire dans le sens ou pour définir une machine on fait un include des fichiers spécifiques à la machine et les fonctions retournent ce que le noyau demande, nombre de pas pour chaque axe ou distance pour un nombre de pas, etc

Edited 2 time(s). Last edit at 06/24/2015 12:36PM by catslab.

merci pour les encouragements/conseils,
j'ai un peu avancé sur le code en identifiant les routines qui gèrent la cinématique mais tout n'est pas encore très clair; par contre avec les instructions SERIAL_ECHOPGM j'ai trouvé un moyen de debug en conjonction avec Repetier, ça va aider!

@ lyscanthrope:
les dimensions d'impression pour le premier proto s2a-P seront environ 220x140mm (soit à peu près le format A5, demi-A4) sur une hauteur de 150mm
il y a peut-être effectivement à creuser aussi niveau origine: pour l'instant je n'ai pas mis de fin de course mais c'est prévu sur le proto final...

@ catslab:
en effet ce sont ces routines spécifiques:
void calculate_SCARA_forward_Transform(float f_scara[3])
et
void calculate_delta(float cartesian[3])

et oui, j'avais testé ce firmware (vitaminrad) au tout début du projet mais je n'avais pas creusé plus que ça... je vais re-tester avec ces routines

Cool pour le debug !
Ah non je voulais parler des dimensions des bras eux même. COncernant l'origine, je voulais dire "le point d'ancrage de ton bras", c'est possible que ca ait un impact important ....justement sur la forme que tu auras à la fin !
Bon courage !

oui l'origine (0,0) par rapport au bras (ancrage) doit influer grandement, mais je n'ai pas encore compris comment l'ajuster... il y a bien des paramètres d'offset (SCARA tower offset) dans le config.h
les bras font 10cm d'axe à axe (donc environ 12cm de long) ; je ne peux pas plus grand car pour l'instant je n'ai qu'une UP mini pour faire toutes les pièces

J'ai regardé un peu le firmware de teacup (version scara). Je ne vois pas trop comment il pourrait fonctionner ...
Mais le gars de teacup a modifié son firmware pour que ca soit plus facile à intégrer d'autres machines.

Je me suis amusé à faire quelques simulations pour le scara 1 arm. Au final rien de nouveau ni de transcendant mais voila les résultats.

Hypothèse :
- Origine du plateau en bas à gauche
- Tour du bras positionné à x10 et y210
- Longueur des bras 120 chacun
- Bras originairement positionné allongé vers la droite (cad avec la tete en x250 y210)
- Tout le travail se fait dans le plan
- Je veux imprimer un carré (le carré de 0.5mm de calibration) dont j'ai recup le gcode de slic3r (et modifié pour en faire un tableau pour mettre dans R)

Graphiques :
en noir le chemin demandé, en rouge le chemin réalisé

Premier cas :
Je prends les consigne directement du slicer (cad qu'une ligne droite n'est définie que par le point de départ et d'arrivée et non ses points intermédiraires) et j'affiche le resultats en rouge.
Il y a 40 consignes gcode (dont beaucoup pour faire les angles arrondis)



Second cas :
Je échantillonne les consignes de manière à avoir des points intermédiaires sur les droites (je passede 40 points à 400 points)



C'est nettement mieux avec de la "segmentation" .. mais on s'y attendait

Sinon, au niveau de ta machine, tu as prévois quoi comme rapport pour les différents bras ?
Avec cette configuration, un moteur de 200 pas par tour (+ microstepping à 16) et un rapport de 4, on a une precision de positionnement du bras de 0.11mm (sans tenir compte des déformations)

bravo pour les simulations, ça peut donner une idée avant de tester 'in real life'; tu fais comment?
sinon qu'est ce que tu entends par:
- Tour du bras positionné à x10 et y210 ?

côté config, j'ai effectivement un rapport de 4 mais je suis parti sur des moteurs à 400pas/t (avec des µstep à 32 pour l'instant); niveau résolution c'est au moins au niveau de la plupart des machines 'classiques' mais avec la rapidité de mouvement en plus: j'envisage des applications de type Laser, PCB, etc...

de mon côté j'ai fais plusieurs essais et je suis rassuré niveau répétabilité mais j'ai toujours cette déformation quelle que soit la position du bras sur le plan (+ ou - prononcée mais toujours présente)
voici le code/config que je teste en ce moment (sur Marlin):

dans config.h:

#define SCARA
#define scara_segments_per_second 120 //careful, two much will decrease performance...
// Length of inner support arm
#define Linkage_1 100 //mm Preprocessor cannot handle decimal point...
// Length of outer support arm Measure arm lengths precisely and enter
#define Linkage_2 100 //mm

// SCARA tower offset (position of Tower relative to bed zero position)
// This needs to be reasonably accurate as it defines the printbed position in the SCARA space.
#define SCARA_offset_x 60 //mm
#define SCARA_offset_y -100 //mm
#define SCARA_RAD2DEG 57.2957795 // to convert RAD to degrees

#define THETA_HOMING_OFFSET 0 //calculatated from Calibration Guide and command M360 / M114 see picture in [reprap.harleystudio.co.za]
#define PSI_HOMING_OFFSET 0 // calculatated from Calibration Guide and command M364 / M114 see picture in [reprap.harleystudio.co.za]

//some helper variables to make kinematics faster
#define L1_2 sq(Linkage_1) // do not change
#define L2_2 sq(Linkage_2) // do not change
#define Link2x (Linkage_1+Linkage_2) // do not change

#define DEFAULT_AXIS_STEPS_PER_UNIT {128/0.9,128/0.9,200/1.25,1000} // default steps per unit for SCARA

dans Marlin_main:

#ifdef SCARA
void calculate_SCARA_forward_Transform(float f_scara[3])
{
// Perform forward kinematics, and place results in delta[3]

float x_sin, x_cos, y_sin, y_cos;

x_sin = sin(f_scara[X_AXIS]/SCARA_RAD2DEG) * Linkage_1;
x_cos = cos(f_scara[X_AXIS]/SCARA_RAD2DEG) * Linkage_1;
y_sin = sin(f_scara[X_AXIS]/SCARA_RAD2DEG + f_scara[Y_AXIS]/SCARA_RAD2DEG) * Linkage_2;
y_cos = cos(f_scara[X_AXIS]/SCARA_RAD2DEG + f_scara[Y_AXIS]/SCARA_RAD2DEG) * Linkage_2;

delta[X_AXIS] = x_cos + y_cos + SCARA_offset_x;
delta[Y_AXIS] = x_sin + y_sin + SCARA_offset_y;

}

void calculate_delta(float cartesian[3]){
// Inverse kinematics.
// Perform reversed kinematics, and place results in delta[3]

float SCARA_pos[2];
static float SCARA_C2, SCARA_S2, SCARA_K1, SCARA_K2, SCARA_theta, SCARA_phi;

SCARA_pos[X_AXIS] = cartesian[X_AXIS] * axis_scaling[X_AXIS] - SCARA_offset_x; //Translate SCARA to standard X Y
SCARA_pos[Y_AXIS] = cartesian[Y_AXIS] * axis_scaling[Y_AXIS] - SCARA_offset_y; // With scaling factor.

SCARA_K1 = sqrt( sq(SCARA_pos[X_AXIS]) + sq(SCARA_pos[Y_AXIS]) );

SCARA_C2 = asin( SCARA_pos[X_AXIS] / SCARA_K1);

SCARA_S2 = acos( SCARA_K1 / Link2x );


SCARA_phi = SCARA_C2 - SCARA_S2;
SCARA_theta = SCARA_C2 + SCARA_S2;


delta[X_AXIS] = SCARA_phi * SCARA_RAD2DEG; // Multiply by 180/Pi (shoulder)
delta[Y_AXIS] = SCARA_theta * SCARA_RAD2DEG; // 90 - (SCARA_theta * SCARA_RAD2DEG); // (elbow)
delta[Z_AXIS] = cartesian[Z_AXIS];

}

#endif

Je me suis fait un petit code en R (logiciel de calcul que j'ai l'habitude d'utiliser). Je pourrais mettre le code si tu veux.
Par contre je n'ai pas utilisé de formules de cinematiques inverses mais je travaille directement avec la cinématique direct (et la résolution de type "damepd least square").

(il me semble qu'il y a la dedans la cinématique inverse de ton bras, l'angle E et S, à vérifier que ça convient)

"Tour du bras", il s'agit en fait de la position de l'origine du bras. En ayant l'origine en bas à gauche de mes graphiques, ca signifie que la "tour" est en haut à gauche (a x=10 et y = 21°). C'est un choix de position arbitraire.

Concernant ta déformation, ça me fait penser à un probleme de cinematique ...ou de réglage de pas sur un des moteurs ?

Edit : est-ce que tu penses mettre ton projet sur thingiverse ? C'est quoi les specifications de tes moteurs ?

Edited 1 time(s). Last edit at 07/03/2015 09:44AM by lyscanthrope.

wow, ce code R c'est puissant mais ça a l'air assez pointu!
ok pour la "tour", ça correspond au fameux 'tower offset'...
je pense aussi qu'il y a un pb de cinématique (inverse); qd j'aurais du temps je vais décortiquer ça par étapes: G-code>>cinématique>>déplacements

pour thingiverse, oui probablement; je comptais plutôt mettre les sources sur un site dédié (invent2main.com) mais ça n'est pas incompatible à priori...
sinon je ne sais pas trop encore quelle suite donner à ce projet (j'en ai d'autres en cours); ça dépendra déjà des résultats obtenus et ensuite de l’intérêt et des collaborations (je le vois comme un projet collaboratif/évolutif qui si il fonctionne pourrait déboucher sur la création d'une structure participative de type SCOP ou autre).

pour les moteurs, pour l'instant j'utilise des petits NEMA14 avec ces caractéristiques:
moteur NEMA14 (14HR080654):
- angle 0.9°
- courant 0.65A
- couple de maintien min: 0.12N.cm

pour l'épaule du proto final et l'extrudeur(bowden), j'ai commandé ceux-ci:
moteur NEMA17 (42BYGHM809):
- angle 0.9°
- courant 1.7A
- couple de maintien min: 48N.cm

Ok, pas de soucis pour un site dedié ...C'etait juste pour savoir si tu partagerais les sources ^^
Je viens de me rendre compte que j'ai oublié de te mettre un lien pour la cinematique inverse (http://www.deltatau.com/Common/technotes/SCARA%20Robot%20Kinematics.pdf)
Ca devrait t'aider

Je me demandais ...
j'ai des moteurs 28BYJ chez moi et j'aurais bien testé ton projet (enfin il faut que je me recommande une ramps si c'est le cas ! Ces moteurs sont très lent mais ... c'est possible de les commander avec la ramps (http://www.electronicsmayhem.com/?p=13) et ils sont surtout très léger (et pas cher)
Bref, je me dis que ca pourrait être interessant d'essayer (quite à faire une adaptation avec une piece de ce style [www.thingiverse.com])

PS : ce n'est pas sérieux ...j'ai déjà trop de projet en cours !!!

Edited 1 time(s). Last edit at 07/06/2015 04:05AM by lyscanthrope.

dommage, je me serais senti moins seul ;-)
De toutes façons, les 28BYJ ne seraient pas vraiment adaptés: hormis leur lenteur, les engrenages internes doivent créer un 'backlash' de folie...
merci pour la doc deltatau; je l'avais déja vu (via ce lien: [machinedesign.com]) et j'ai même essayé d'implémenter les équations dans une version (avec le même résultat déformé)

Et oui, qd on est curieux il y a tellement à faire: difficile de se limiter à un seul projet!

Totalement d'accord pour la lenteur et le backlash !
Je ne pensais pas à une solution définitive mais plus à une solution pour tester à moindre coût.
Ceci dit, si le backlash est constant et évalable on a sûrement moyen de le compenser logicielemnt (dans un second temps).

Actuellement, tes pièces sont en nema 14?
Tu as eu le temps de reprendre la cinématique ?

oui pour faire un test du principe, pourquoi pas... mais sachant qu'ils sont de type unipolaires il faut aussi des drivers adaptés

et non pour l'instant je n'ai pas repris la cinématique; peut-être ce WE
mais j'ai avancé sur l'axe Z (bientôt des photos: il manque 1 ou 2 pièces) et un peu sur l'extrudeur...

oui pour l'instant le montage test est prévu pour des nema14 mais on pourrai le modifier pour mettre autre chose (des 28BYJ par exemple!?); si tu es intéressé je peux te faire passer des sources (au format DesignSpark)...

Des drivers standards conviennent (il y a moyen de convertir des unipolaires en bipolaire, voir lien un peu plus haut).
C'est justement pour cela que je suis intéressé par tester .... mais comme je n'ai pas encore reçu ma seconde ramps ..Ça peut attendre
L'idée sera de garer exactement ton design et de rajouter un adaptateur pour ces steppers à la phase de montage.

Merci pour la proposition, je te redis dès que j'ai reçu de quoi faire des tests. Je ne connaissais pas DesignSpark Mechanical, je vais regarder par curiosité

Des nouvelles du projet ?
De mon coté, je viens de recevoir seconde ramps ! Donc si j'arrive à faire passer l'idée d'un "nouveau projet" en plus à la maison, je devrais pouvoir essayer

hello,
quelques news du projet:

j'ai reçu les NEMA17 aussi bien avancé sur l'axe Z; j'ai imprimé toutes les pièces et je suis en cours de montage:


En vue de faire un test avec du plastique, j'ai aussi reçu les composants pour le 'hotend' et parallèlement j'étudie plusieurs solutions pour l'extrudeur, qui me semble être une partie délicate (et importante) pour bien maîtriser le filament...

PS: j'ai les mêmes souci pour les "nouveaux projets" ;-)

Je suis admiratif sur ce sujet,j'aime la mécanique sauf que pour moi la cinématique inverse ,je coule

---

[www.hotends.fr ]>>>[email protected] >>>GitHUB ([github.com])
My SketchFab >[sketchfab.com]

merci fourmi;
rien d'extraordinaire non plus, juste l'envie de faire avancer le 'schmilblick' ;-) je crois beaucoup à l'impression 3D (construction additive) dans beaucoup de domaines et à mon avis on n'est qu'au début...

j'avoue aussi que sur l'aspect 'cinématique' je trouve mes limites mais si je suis vraiment bloqué j'irais voir du côté des anglophones...

quelques photos du montage en cours:

Wow !!! très beau !! Félicitation !