Export DH parameters and/or URDF?

[ipsod]

Hi,

I noticed this kinematic example. Might there be some way to convert those to Denavit-Hartenberg parameters and/or URDF files?

I need DH parameters and/or URDF files to simulate machines with Klampt, PyBullet, RoboDK, ROS, or whatever. I've been using SolidPython2 to model machines, but I haven't yet found a way to go from models to this data needed for simulation, and your kinematic example looks promising.

[jimy-byerley]

Hello !
There is no function to provide Denavit-Hartenberg decompositions of the madcad kinematics. I bet this wouldn't be too difficult to add since DH was meant to be systematic.

At the moment, I am reworking the kinematic system on development branch kinematic
If you feel ready for it, you can propose a pull request for this feature. Else I will see if I can find time to implement it.

[ipsod]

Thanks for the quick response.

It's a bit beyond anything I'm ready for. I hope to be able to circle back and check out your library and the kinematics stuff in it soon.

Would you please provide a sales pitch for you library? My position is, I'm struggling to design and create custom robotic machines. I've pushed SolidPython2 and OpenSCAD pretty far. I've made a lot of stuff pretty easy and comfortable with them, particularly the simple mechanical parts I need, with all sorts of printed-in gears, bushings, bolt holes, etc., but things get difficult when I'm trying to make something complex, with more than a few moving parts. I'd really like something that took my designs a little further into reality, too, so that I could kinematically play with things a little before going to the trouble of jigging them up into simulations or physically creating them. I'm constantly starved for time, so the idea of learning a new library, while appealing, is a difficult choice.

But, if your library could export file-formats necessary for PyBullet, Klampt, etc., it'd be very compelling. Like, if I could be modeling a machine, and then just continually send revisions straight to simulation... I'd be compelled to put in some work toward that. I'm not terribly advanced with this stuff, so I'm not sure how much help I'd be, but I am doing a lot of work in this direction.

[jimy-byerley]

Very interesting feedback, thanks !
I must say I completely understand having no time, I am often in this situation too which is why madcad is so slowly evolving.

I must warn you about the current kinematic stuff in madcad: while the API is nice, the solver is currently bad, and diverges when the kinematic chains has more than 5-6 DOF ... this is why I am reworking it. My goal is to have a robust kinematic solver handling any kinematic with any dof and kinematic loops and converging in less than 30ms.

A sales pitch ? ... No sure what I would write there :)
Maybe madcad concepts and comparision with main stream CADs may answer you question
As a comparision to openscad and solidpython I would say:

• pymadcad has much richer data types
  has not only solids, but also surfaces, wires, geometrical primitives
• pymadcad makes very easy to have functions or classes generating parametered parts
  functions, variable assignations, vector & matrices operations exist in openscad but much less convenient than in python
• pymadcad is more easily and efficiently interoperable with other libraries
  it does not need a separate software to convert the script into a mesh
• pymadcad has better graphical tools
  this is thanks to your rendering pipeline and to uimadcad
• pymadcad is slower
  ATM, due to the triangulation algorithm and pure python
• pymadcad has a smaller community
  ATM

I think the use-case you describe is an acceptable additional goal for madcad: model meshes and kinematics using pymadcad and export regularly the result in simulation input files. This is a bit like it is actually when modeling meshes using pymadcad then regularly running a renderer like madcad.show to show the result.
I will then keep this issue open until the feature is implemented. This is joining ambitions of #98

[jimy-byerley]

As a note for when I implement this, here are the references:

• Denavit-Hartenberg conventions
• URDF file format

[ipsod]

Great! That all sounds really promising. I wish I could just dive in and make it all happen. Thanks for your time, and thanks for accepting this feature request. If your solver is reliable for 4 axes, that's good enough for me to get started.

Yes, I read your comparison with mainstream CAD last night, and I am inclined to believe it, because it describes my limited experience. I've been thinking of learning a mainstream CAD for a while, researching them to pick one, because I see people seriously outperforming me, and I want to finish more projects and do better work. But, I was afraid of the sorts of things you say being true, as well as all of the implications of using a software that has a high yearly cost of ownership (ie: what happens if you change software, but want to edit an old model?). I don't have much time to master a CAD software, and I feel like code-CAD might leverage my time and skills better, since I'm very comfortable managing complexity in code, and always getting better, and I'm reluctant to learn some CAD software's house of cards of complexity that almost definitely won't have the same overlap with the rest of my work/skill-set. But, it's hard to argue with (other people's) results, and I'm not sure I'm always well-served by my tendency to choose a raw ideal over a developed jungle.

I'm also still trying to learn/develop a toolkit to draw the paths in 3d space that I need, to generate Cartesian paths for robots' end effectors, etc. Can your modeler do surface constraints? For a basic example, if I modeled a dial indicator touching an object on a lathe, and spun the object on the lathe slowly, could the dial-indicator's arm move back and forth to keep contact the object? And, could I get those values out - basically just get what the reading on the dial indicator would be? I also need to get other data out. Like, if the object on the lathe being measured was an egg, I'd like to get XYZ-ABC of the tangent of each contact point. I guess, at a certain point, it's going to need collision detection, instead of simple mapping like this. Or, maybe not - surely there's some 3d equivalent of OpenCV dilate/erode which could, for example, keep most of the surface the same, but fill in/smooth any holes too small for a ballnose bit to touch - but I don't see how this could work for other types of bits. Would be really cool to add CAM on top of your CAD - I've been playing with printing parts, then milling them for accuracy, and the process could be massively streamlined, even if the CAM was really basic.

Or, if you know of any other tools that would really open a lot of doors... just, judging by your library, it seems like you're a lot more familiar with this problem-space, and maybe you see some obvious solutions I'm missing.

[jimy-byerley]

I'm not sure I'm always well-served by my tendency to choose a raw ideal over a developed jungle.

This is a thought I sometime have too ;)

about madcad

Can your modeler do surface constraints?

This is not featured currently, this might be in the future, with a bit of precision loss compared to standard joints of course

I'd like to get XYZ-ABC of the tangent of each contact point

Once a cam joint or surface constraint is implemented, such information is very easy to get. However implemented in a kinematic framework will only allow to have a permanent contact between provided surfaces. This would work fine if you are just willing to try your mechanisms virtually while designing them, but if you are looking for something that can handle varying number of contact points, you will indeed need a collision simulation system.
I once played a bit with CopeliaSim which does this on top of bullet. Never tried Movit from ROS however, but it doesn't look that great.

If on the other hand you need a kinematic model suited to command a milling machine to follow some shape, I think no madcad tool will be suited. Maybe the new kinematic solver may work that out, but it will be far less efficient than a use-case-specific kinematic model optimized for this. Even the new kinematic solver won't be realtime.

Would be really cool to add CAM on top of your CAD

I sadly don't know much about how to generate CAM instructions. I usually recitfy my parts by hand when I need it ... I bet this shouldnt be complicated to generate milling paths: that's basically computing intersections between the part and planes, with a bit of inflate/deflate operations. But then how to compute time-bound trajectories and machining instructions based on that ?

about your need

What is the end-effector you need to use actually ?

• If it is convex, then a minkowski sum shall be suited to inflate the part you need to machine,
  Minkowski sum is not implemented in madcad yet, but is available in CGAL and its wrappers like pymesh
• If it is spherical or cylindrical, then even a simple inflate operator like there is in pymadcad should suffice.

Then slicing it each height should be sufficient to get 3D paths.
Translating the math into joint coordinates is only a kinematic model problem which usually can be solved in realtime with a bit of trigonometry.

[ipsod]

The idea to build a CAM is separate from the rest - the CAM is for making parts for machines, and the rest is to control those machines. I think it would be fairly easy to generate g-code for milling operations. Much easier than what you've done here. It would be very limited, because it doesn't have to mill much away. I'd really just use it to clean up top surfaces and vertical walls (holes on bushings, edges for parts that need precision dimensions) on simple parts. It would be less of a CAM and more of a g-code generator. I might even just define the path with your Wire geometry? Could then convert to g-code. I don't know if you've done much with g-code, but it basically just needs a series of points with a maximum allowable speed, and the motion-controller handles acceleration for you.

The end-effectors I need vary. The operations include milling, grinding, sanding, polishing, painting, etc. The more control over motion I get, especially coordinated motion between two or more end-effectors (tool+workpiece, tool+tool+workpiece, grinder+water+workpiece, etc.), the better.

I've been looking into Coppelia, pybullet, MoveIt, Pinocchio, Klampt, robotics-toolbox-python, and RoboDK. RoboDK looks by far the most compelling, but it's $4k, and I'm not yet sold on it. Coppelia seems most similar to RoboDK, and their licensing model is way nicer. Pinocchio looks like it would absolutely do what I want, giving me a great toolkit for end-effector-path-planning and for kinematics. Klampt looks like it may also, but I played with it a bit, and wasn't happy with the motion profiles I was able to get out of it after a few hours of playing with it. I haven't ruled any of them out, yet. I'm most closely looking at Pinocchio, because it's the only one that leaves me feeling certain that it's opening all of the doors I want opened, as far as path-planning and motion-planning goes. RoboDK looks like it would do a lot of the things I want to do out of the box, though, and easily.

There's also BowlerStudio, which seems to do almost everything I want - CAD with something like PyMadCad, export DH parameters, run it in a simulation, use it to control the actual robot. It's java, and I don't know Java, and it looks like the community is tiny, and the demo projects are really not in a similar vein to what I'm trying to do, but it's been around a long time and is still active, and it seems like it might promise an end-to-end solution that covers everything I'm looking for, as well as the glue between. It should probably be higher on my list. The only demos I've seen with it are little walking robots, though - not exactly machine tools - but it does mention controlling robot arms on its readme.

[jimy-byerley]

I might even just define the path with your Wire geometry?

Surely, for so simple use cases ;) Mesh.group() and Mesh.outline() might be far sufficient to extract such wire, and those wire might be sufficient as milling path.

It seems you have been far in your search of software, I didn't knew all of them. Interesting findings.
Despite I am working in robotics, I personnaly do not use much tools and instead I usually develop my own stuff for kinematic, dynamics, path and trajectory planning ^^
I usually prefer doing so, and splitting the framework into a class each of these features instead of having a big robot model doing all the stuff like in Pinocchio and movit.
I also use to call the kinematic and dynamic models in the control loops of my robot arms, so they must be deriable and fast, which is not always the case with the solvers from these libs.

I'm afraid I won't be of great help for you to choose between these softwares ^^

[ipsod]

Oh, cool. What a wizard. Man, what I'd give for your skill set. UI design, too - the screenshot here is maybe the coolest thing I've seen: https://madcad.netlify.app/

I'm a professional artist, and I want to make machines that help me make art-objects, and I also sometimes get distracted thinking about more objectively useful machines. I've been working for 10+ years toward this, in whatever time I could find, but most of my time was spent poorly. I developed, for example, a lot of iterations of not-great low-level motion control firmware, too-complex communication frameworks to talk from Python to microcontroller, and not-very-productive attempts to make SolidPython nicer to work with, etc. I think that, of the tens of thousands of lines of code I've written, very little of it is still relevant. I guess everyone has to learn somehow.

In the past year, I've kind of started over with a higher-level focus, keeping the microcontroller stuff as simple and bare-bones as possible, and researching to learn enough to find a path forward.

I've spent the past few days working on a basic trajectory planner in Python (just applying acceleration to a path, slowing down for corners), and it's cemented for me the idea that, if I approach things from a higher level (vector math instead of arithmetic), it is much simpler, and much less complex, even though the word "vector math" is kind of scary (I failed calc 2 twice, 20 years ago - maybe not smart enough, and definitely too lazy).

I am starting with stepper motors, because 3d printers are such cheap robotics platforms. I think I need to:
finish the trajectory planner
turn the trajectories into discrete steps (for stepper motors)
figure out communication
write firmware that receives, queues, and run steps
and, then I'll have enough control that I can make useful things.

I think, for now, I'll settle into that, and I'll pick up PyMadCad, and I'll try and play with it enough to become familiar with 3d geometry math, and learn from your code. I can get into kinematics, dynamics, and more advanced path planning as I build some basic skills with 3d math.

Thank you for your time and for sharing your code. It's truly inspirational work. I hope to someday accomplish something so great.

[ipsod]

Would PyMadCad be suitable to visualize a robot? Can I control the models in realtime? In the toolchain I described above: trajectory planner -> (basically drivers/firmware) -> robot, could I maybe do, trajectory planner -> (PyMadCad code) -> (PyMadCad visualization)?

[jimy-byerley]

I guess everyone has to learn somehow.

Definitely, I made tons of useless projects too ;)

... and I also sometimes get distracted thinking about more objectively useful machine

You distraction is what I call focus then ^^ but any machine is fun to make anyway

In the past year, I've kind of started over with a higher-level focus, keeping the microcontroller stuff as simple and bare-bones as possible, and researching to learn enough to find a path forward.

Too big topic for here, but this is something I could discuss during hours ;)

if I approach things from a higher level (vector math instead of arithmetic), it is much simpler, and much less complex

It is yes, I agree ! It is also why I choose to not hide any math details in the madcad API (like vectors, matrices, screws, etc). I agree it may be hard to learn at first, but often for a better flexibility, reusability and meaning for the user in the end.

Would PyMadCad be suitable to visualize a robot?

Definitely: I'm using the rendering pipeline of pymadcad everyday in my robots manual control and monitoring interface. However you will need to write a subclass of Group handling the placement of the solids in the kinematic according to the trajectory planner's positions, and eventually reacting to the user inputs.

[jimy-byerley]

As an overview, Here is my manual control interface.

It is closed source so I will not be able to share its code, but it is not a big job to build it on the top of pymadcad (I think it is 200 code lines)

[ipsod]

This is amazing. I want to know how to do this, and I want to be a part of it. I hope the math isn't too much of a barrier. I found vectors quite intuitive - much easier to grasp and much more powerful than the crazy synchronized-adding machines I've made that gave some small portion of their utility. It seems like you've provided a toolkit that's similarly... intelligent, sophisticated, efficient. Excellent documentation, too - it makes it all seem very approachable. And, the philosophy of "libraries should be free," lived out, sharing something so excellent. What a cool little corner of the world.

[jimy-byerley]

It seems like you've provided a toolkit that's similarly... intelligent, sophisticated, efficient

That was my goal, I'm happy you like it 😎
Tell me if you want to contribute to it at some point !

I found vectors quite intuitive

Once you are familiar with the dot product, next frontier is matrices ! It took me weeks to understand years ago

[jimy-byerley]

By exporting DH parameters, do you know a file format for it ? or simply a list or something you could get from a method of kinematic models ?

Regarding URDF, it will be a file format for export using madcad.io. I wouldn't make sense to have a URDF object type since Kinematic is already the object type for this kind of stuff, has more methods to provide.