Journal Pycao: modeleur 3D en python

Posté par lelama le 20 septembre 2016 à 14:49. Licence CC By‑SA.

Étiquettes :

sept.

2016

Cher journal,

J'essaie de faire des velos dans mon atelier, et je prepare le boulot par un modele 3D. N'ayant pas trouvé chaussure a mon pied après essais de logiciels divers ( blender, povray, freecad…), j'ai ecrit un modeleur python qui commence a etre visible et utilisable.

Voila une image du projet:
Oh le joli velo

Le but principal du modeleur est de minimiser la longueur du code. Il faut entre 200 et 300 lignes de code pour le velo de l'image.

Pour en savoir +, c'est ici: http://math.univ-angers.fr/~evain/software/pycao/distributed/documentation/

# Un vélo python ?

Posté par denisb le 20 septembre 2016 à 15:38. Évalué à 3.

J'aime bien l'idée de programmer en python un modeleur pour modéliser un vélo python !

Pour ma part j'ai fait (en vrai) quasiment le même : https://goo.gl/photos/KSpjqPbVpGKqrGA79

mon idée est d'ajouter un degré de liberté au vélo couché TD classique en permettant au guidon de contrôler le basculement latéral du siège, afin de décaler le centre de gravité. Cela semble fonctionner, mais malheureusement j'ai pas mal sous-estimé les efforts dans les liaisons du siège et les soudures du cadre, et j'ai tout cassé… Il faut que je m'y remette !

Côté modélisation j'avais fait un modèle SolidWorks, en espérant pouvoir faire une simulation dynamique dessus, mais en pratique c'est extrêmement dur de définir correctement des conditions initiales, et surtout des critères d'analyse permettant de caractériser le comportement réel (stabilité, directivité, couplages divers…).

As-tu réfléchi à la question, et surtout ton modeleur est-il justement destiné à permettre lune optimisation paramétrique selon des critères dynamiques ? C'est clairement le gros intérêt de ta solution par rapport aux outils CAO, qui même si ils permettent de faire ce genre de choses sont d'une lourdeur monstrueuse.

Sur le modèle de l'image tu sembles avoir mis une direction arrière, or j'avais vu quelque part que cela ne fonctionnait pas, tu as testé ?
- [^] # Re: Un vélo python ?
  
  Posté par ʭ ☯ le 20 septembre 2016 à 15:48. Évalué à 2.
  
  Heu l'axe de direction est à la base de la roue avant, non? Moi c'est le garde-boue qui me perturbe : il n'y en a pas derrière?
  
  …. m'enfin je suppose que c'était juste un exemple non finalisé….
  
  ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
  - [^] # Re: Un vélo python ?
    
    Posté par lelama le 20 septembre 2016 à 16:03. Évalué à 2.
    
    Yes, l'axe de direction avant est a la base de la roue avant. Et il y a un autre axe de direction pour la roue arriere.
    
    A l'avant, ce n'est pas un garde boue, mais un tube metal autour de la roue. Il faudra des gardes boues, mais pour l'instant le modele ne decrit que la partie mecanique a souder. Il reste a mettre tous les peripheriques ( freins, vitesses, garde-boue …) En revanche, la geometrie ne devrait pas trop changer. Elle est plus ou moins definitive ( pour ce proto la, il y aura sans doute d'autres protos si ca ne donne pas satisfaction).
- [^] # Re: Un vélo python ?
  
  Posté par lelama le 20 septembre 2016 à 15:57. Évalué à 2.
  
  Ah super ton projet. Bravo pour l'inventivité. C'est vrai qu'il y a pas mal de choses a experimenter encore.
  
  Oui tu as bien vu, il y a une direction arriere. En fait, c'est un double direction avant arriere, Y'avait un proto qui existait et qui, comme le tien, a cassé rapidement. J'essaie maintenant de faire un truc un peu plus pro, qui corrige les defauts precedents. Une tite video qui montre que c'est bien conduisible et stable : https://www.youtube.com/watch?v=kP08CeD9aV8 Sentiment de glisse assez incroyable.
  
  L'idee, c'etait de partir des velos ayant le meileur rendement actuellement ( velo a traction directe, dont le python) et d'essayer d'ameliorer encore un peu (maniabilité, stabilité, rendement).
  
  Pour des conseils de construction pour ton futur cadre ;-), tu peux venir discuter sur http://veloartisanal.fr
  - [^] # Re: Un vélo python ?
    
    Posté par denisb le 20 septembre 2016 à 16:28. Évalué à 1.
    
    Effectivement celui-ci avait l'air d'être contrôlable… peut-être que je vais revenir à cette solution, car le guidage sous le siège est une vraie galère, il faudrait que je mette un rail courbe avec des galets à bille, cela fait un paquet de pièces à usiner. Je vais étudier la question… En fait cela revient à peu près au même, la double direction va avoir pour effet de décaler le centre de gravité, ce qui est le but voulu.
    
    Quant au cadre, déjà la soudure à l'arc sur des tubes de 0.8, bof. Alors en plus quand je n'ai même pas pris la peine de les décaper avant…
    - [^] # Re: Un vélo python ?
      
      Posté par lelama le 20 septembre 2016 à 17:36. Évalué à 1.
      
      Je regarde tes photos, et je trouve que la triangulation est assez bonne. Bizarre que ca ait casse'. Sans doute a cause des conditions de soudage comme tu le dis.
      
      Tu dis que c'etait galere le guidage sous le siege. Pourquoi ?
      - [^] # Re: Un vélo python ?
        
        Posté par denisb le 20 septembre 2016 à 21:21. Évalué à 4.
        
        Pour les soudures, en fait j'avais juste fait un semblant de cordon à l'arc, en me disant que si cela fonctionnait j'irais souder cela proprement chez un copain qui a un MIG. Donc c'est normal ! Effectivement le dimensionnement est bon et a même été calculé.
        
        Pour la liaison pivot (arc de cercle) sous le siège, j'ai en fait complètement sous-estimé l'effort axial induit par le pédalage, et il est énorme. Mes pièces nylon imprimées 3D en SLS (support des galets) en ont été broyées en quelques minutes, quant au rail, fait en tole d'acier de 5 mm, on a l'impression qu'il a été mâché… Il faudrait que je fasse une solution de type guidage linéaire, avec 2x3 galets à 120°, montés sur des supports en alu usinés CN, et que je vienne souder une barre en acier très dur pour faire le rail courbe. C'est faisable, mais on attaque la vraie mécanique !
        
        C'est pour cela que l'idée du pivot arrière judicieusement placé n'est peut-être pas à négliger. C'est tellement plus facile à réaliser. L'intérêt de ma solution, c'est que l'axe de basculement du siège passe par l'axe du pédalier, et donc en théorie il n'y a pas de couplage entre le pédalage et la direction, ce qui est le problème majeur de tous les vélos TD que j'ai testé.
        
        [^] # Re: Un vélo python ?
        
        Posté par lelama le 21 septembre 2016 à 09:11. Évalué à 1.
        
        Tu dis avoir calcule' le dimensionnement. Tu peux dire quelques mots la dessus ? A priori on peut toujours faire plus ou moins rigide. Comment tu mets des limites ? Quels types de calcul tu fais ?
        
        [^] # Re: Un vélo python ?
        
        Posté par denisb le 21 septembre 2016 à 16:31. Évalué à 1.
        
        J'avais fait un calcul éléments finis basique avec SolidWorks Simulation, donc du très classique : un effort au niveau du siège (supposé rigide), et des réactions au niveau des axes de roue (appui ponctuel).
        Mais je n'avais pas spécialement modélisé les soudures…
        
        [^] # Re: Un vélo python ?
        
        Posté par lelama le 21 septembre 2016 à 17:11. Évalué à 2.
        
        Ce que je ne comprends pas, c'est comment on interprete les calculs pour dimensionner. Par exemple, je sais calculer les moments de force a la main, je peux les mettre dans un logiciel. Et le logiciel peut me donner une deformation. Cette deformation sera plus grande si les tubes sont de plus petit diametre ou si j'ai mal triangule'. Mais dans tous les cas, je ne sais pas ou est la bonne limite. Le logiciel peut me donner 8, 15 ou 30 pour trois montages differents. Mais il ne me dit pas s'il vaut mieux prendre 8, 15, ou 30. En general, le plus lourd sera aussi le plus rigide. Autrement dit, je peux faire des calculs, mais je ne sais pas interpreter les calculs.
        
        [^] # Re: Un vélo python ?
        
        Posté par denisb le 21 septembre 2016 à 23:55. Évalué à 2.
        
        En pratique sur ce genre de problème on dimensionne avec un critère de limite élastique. Le problème c'est que les soudures sont des zones de concentration de contraintes, et donc qu'il faudrait prendre cela en compte de façon plus précise, mais là on rentre dans des trucs de spécialistes. Certains codes éléments finis permettent de définir des comportement spécifiques au niveau des soudures, mais je ne suis pas du métier…
        
        le calcul de la raideur n'est pas fondamental, car on est sur de l'acier, et donc les déformations élastiques se font avec très peu d'amortissement, et donc cela n'intervient que très peu dans le rendement global du vélo. En revanche, si on avait une modélisation physique très précise, cela serait intéressant de faire une analyse modale pour voir si on peut avoir des couplages avec le pédalage, ou des effets de guidonnage à grande vitesse. Mais à mon avis c'est négligeable
        
        [^] # Re: Un vélo python ?
        
        Posté par lelama le 22 septembre 2016 à 10:44. Évalué à 2.
        
        Merci Denis pour tes reponses.
- [^] # Re: Un vélo python ?
  
  Posté par lelama le 20 septembre 2016 à 16:08. Évalué à 1.
  
  Pour la modelisation, je n'ai pas trop avancé la dessus. J'ai juste regardé s'il y avait des softs interessants. Il y a mbDyn qui a l'air vraiment bien. Difficile a utiliser si on ne connait pas un peu de physique. Mais vraiment tres simple et minimaliste en mode commande, avec des modeles assez elaborés cependant. Un genre de shell pour l'analyse mecanique. Donc a priori, c'est faisable de faire un module d'interfacage.
# OpenSCAD

Posté par Sébastien Maccagnoni (site web personnel) le 20 septembre 2016 à 15:52. Évalué à 2.

Salut,

J'ai survolé la doc de ton projet, ça me fait un peu penser à OpenSCAD. Qu'en penses-tu ? Comment comparerais-tu les deux ?
- [^] # Re: OpenSCAD
  
  Posté par lelama le 20 septembre 2016 à 16:32. Évalué à 4.
  
  Les avantages d'open-scad:
  - fichiers d'export
  - un visualiseur 3D digne de ce nom
  
  Les avantages de Pycao: un langage de haut niveau avec plein de paradigmes permettant un code compact ( box, genealogie enre les objets, systemes de mesure en coordonnees proportionnelles ou absolues, langage de la geometrie affine pour des notations compactes, primitive d'interpolations pour les courbes, squelettes, classes pour construire des librairiees facilement…).
  
  Mon experience avec les langages de bas niveau, c'est qu'il faut au moins milles lignes de code pour decrire un velo comme celui que je donne en exemple, avec plein de calcul intermediaires pour ajuster les decalages. Ca donne un code tres difficile a maintenir. Et quand on change un parametre, par exemple, si on ecartes les roues, il faut relire le code et reajuster tous les calculs. Rien que le bonhomme tout seul sans le velo me semble un boulot colossal sans un minimum de primitives de haut niveau.
  
  Face a ces difficultés, j'ai commencé a écrire de plus en plus de macros pour pouvoir changer a la volee tous les parametres de construction. On peut voir pycao comme un ajout d'une couche de macros assez epaisse aux elements de langage commun a plus ou moins tous les langages de cao.
- [^] # Re: OpenSCAD
  
  Posté par lelama le 20 septembre 2016 à 17:05. Évalué à 3. Dernière modification le 20 septembre 2016 à 20:34.
  Pour etre un peu plus concret, voila la code complet pour decrire la personne sur le velo. C'est un squelette dont on bouge les articulations.
```
########
#Body
########
body=Body().rotate(Segment(origin,origin+X),math.pi/4.6).translate(-.35*Z)
legAngleAfter=atan(.5*feetDistance/body.leftPelvis.position[2])
legAngleBefore=atan(.5*leftRightLegAxes/body.leftPelvis.position[2])
angleForLegDistance=legAngleAfter-legAngleBefore
body.bend.leftPelvis(+angleForLegDistance,Y)
body.bend.rightPelvis(-angleForLegDistance,Y)
body.bend.leftPelvis(math.pi/2+.12,X)
body.bend.leftKnee(-math.pi/3-.15,X)
body.bend.rightPelvis(math.pi/2*1.15,X)
body.bend.rightKnee(-math.pi/4*1.3,X)
body.bend.rightPelvis(-math.pi/20,X,toggleJoint=True)
body.bend.leftShoulder(-math.pi/5,X)
body.bend.leftElbow(math.pi/3,X)
body.bend.rightShoulder(-math.pi/4.5,X)
body.bend.rightElbow(math.pi/3,X)
body.bend.neck(-math.pi/6,X)
```
# comparaisons

Posté par yeKcim (site web personnel) le 20 septembre 2016 à 15:59. Évalué à 7.

Pour l’exemple donné sur le site de pycao :
myCylinder=Cylinder(radius=.2,length=.3).move_at(origin).colored("Red")
camera=Camera()
camera.filmAllActors=True
camera.file="premierCylindre.pov"
camera.shoot
camera.show

le langage par rapport à d’autres…

coffeescad :
cylinder({r:2,h:3}).color([1,0,0])

openscad :

$fn = 50;
color([1,0,0]) cylinder(3,2,2);

de ce fait, je ne comprends pas vraiment pourquoi sur le site de l’application pycao est comparé à blender, Freecad et Salome et non à openscad, coffeescad, ImplicitCAD,… qui m’ont l’air de plus correspondre. J’ai loupé quelque chose ?
- [^] # Re: comparaisons
  
  Posté par lelama le 20 septembre 2016 à 17:14. Évalué à 2.
  
  Tu as raison. C'est juste que je ne connais pas suffisamment ces outils pour me permettre de les commenter.
# En python aussi

Posté par falbala le 20 septembre 2016 à 18:11. Évalué à 1.

cadquery : c'est en python, ça s'intègre dans freecad et ça marche même en version en ligne…

Je m'en sers pour donner à manger à mon imprimante 3D…
- [^] # Re: En python aussi
  
  Posté par lelama le 21 septembre 2016 à 11:44. Évalué à 2.
  
  Je ne connaissais pas. Merci pour les liens. Il y avraiment des idees similaires entrre pycao et cadquery: le code doit etre le plus pres possible du langage parlé, chainage des operations, plugins, travail en coordonnees proportionnelles, documentation …
  
  A premiere vue, il y a une difference neanmoins, c'est que la construction est pensée dynamique dans cadquery, avec la notion de "Working point", qui bouge au gré des constructions. Cette notion n'existe pas dans Pycao. Dans Pycao, pour decrire des coordonnees relatives, on utilise le formalisme des vecteurs (pycao fait la difference entre points et vecteurs) sans notion dynamique. Les objets sont pensés de facon statique, mais on fournit des outils pour ensuite pouvoir les placer facilement les uns par rapport aux autres( fonctions screw_on et against notamment).
  
  Ca me fait penser a un tableur contre une base de donnees. C'est plus rapide avec un tableur pour un petit projet, mais c'est difficile a maintenir au dela d'une certaine taille avec l'insertion de colonnes qui rend le code fragile au dela d'une certaine taille. Ca me semble un peu pareil ici. Les workings points, ca va aller vite pour des petits dessins, mais ca peut etre compliqué a gerer quand on insere du code au milieu d'un gros bloc.
  
  En tout cas, ca a l'air bien pensé et ca me donne envie d'aller voir si il y a des idees interessantes qui pourraient etre utiles dans Pycao.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.