Robotic kinematics
-
@T3P3Tony ok, I can do it this way, this makes sense.
-
I've finished the robot 6 axis inverse kinematics now with Paden-Kahan algorithms, the time measured on a 2 GHz laptop is 30 microseconds to get the 8 solutions. Maybe factor 10 for a Duet. Optimization is possible by calculating only the nearest angle solutions. (maybe in Limitposition calculating all solutions, and in segmented calculations only one solution).
I'm constantly updating the screw theory page, especially the literature links, if someone is interested following the underlying theory.
Next will be to implement linear axes with screw theory for the CNC/Prusa/CoreXY like 5 axis. Then I'll try to implement PK2 Dimovski et al solution (for 6 axis robot first three axes).
-
undefined JoergS5 referenced this topic
-
Thanks @toms to offer help,I'll take into account supporting the https://www.anninrobotics.com/ robot.
I currently join geometric algebra (thanks @xyzdims for pointing me to it) with screw theory and will tell you when the kinematics is ready for testing.
-
I have a coarse understanding of geometric algebra now and start changing the robot code RRF and RobotViewer DWC plugin next week.
After talking to the Duet team, it is clear that the memory gives me some restrictions to implementation, but I had the following idea:
- Denavit-Hartenberg (DH) code and configuration will move to RobotViewer DWC plugin, so it can be tested and configured there. DWC has the advantage that it runs on PC/table/Raspi with lot of RAM.
- in RobotViewer, the DH config can be translated into screw code there and can be copied to the config.g of Duet (first version will be manual, but I want to transfer it later to some robot.g as macro or into config.g on Duet).
- screw config can be input in Duet directly
- in Duet, only screw configuration will be set and stored in RRF for minimal storage need.
DH is a subset of screw (and with the Y extensions of DH is a 1:1 with screw), so this procedure should work.
If someone is against this proposal, now is the time to tell me.
-
@JoergS5 I guess you want to use DH-code for the robot-viewer because it already exists or does it have other advantages against screw-code?
-
@o_lampe DH configuration and screw configuration parameters are similar, so I want to store it only one time in RRF, because RRF is limited by memory.
Screw theory as such has advantages compard to calculations based on DH:
- closed form calculation of inverse kinematics, i. e. no iterations and all 8 (16) robot solutions
- no usage of Euler angles, which have singularities like gimbal lock from local calculations. Screw calculates globally.
And to answer your question: I want to support DH, because it was the standard method for industrial robots, so some users may be used to it. For me it offers the possibility to double check the algorithms by calculating both ways and comparing the results. The DH code will not be included in RRF, however, to spare memory.
In RobotViewer, I'll support both input methods and I'm thinking about a simple geometric algebra editor to support a third, visual approach to assemble the robot elements.
I want to start in RobotViewer with a selection of robot type like 6 axis industrial, 4 axis palletized, 5 axis CNC/Prusa/CoreXY and I like the robot type called Gantry robot (ABB IRB6620LX like with one linear and 5 rotary axes) and add this kinematics. It is mentioned and calculated in the Pardos-Gotor book, because it is valuable to route big parts like a wood door.
-
I feel the need today to tell that robot kinematics development is still alive. It takes only some time to learn about geometric algebra... I've created a new documentation page about it at https://docs.duet3d.com/User_manual/Machine_configuration/robot_geometric_algebra with some literature links. Geometric algebra is a great geometric approach, which unifies many different mathematical and physical areas and those areas are under constant development, so there are many things to detect for researchers.
I want to model the robot kinematics and inverse kinematics with geometric algebra, transform them into easier Paden-Kahan subproblems and implement them in RRF with limited memory.
I am currently half through the Dorst book, which is IMHO the best book to begin with if one wants to learn about it. Hildenbrand has also a very nice style, but it needs more pre-knowledge. Hestenes and Vince have also a very clear language. I am thankful that all those authors write books without typos, I know other books...
-
undefined JoergS5 referenced this topic
-
Short update to prove that I'm still alive.
I'm constantly updating the screw and geometric algebra pages, so if someone wants to follow what I learn and learn with me, please check sometimes what's new. I especially update the literature recommendations often, when I detect an interesting author who pleases me with knowledge or who is didactically good (IMHO).
While digging deep into the scientific articles about geometric algebra, I detect more and more topics which are interesting for 3D printing/CNC area, e.g.
- support of cylinder objects (additional to sphere), so intersection and distance is easy to calculate, i. e. collision detection will be possible
- much research is done to support curvature/surfaces like Bezier, Bspline and similar, and new topics are constantly emerging
I managed to model PK2 (Paden-Kahan subproblem for inverse kinematics solution for 6 axis robot) in geometric algebra with Gaalop tool, so I'm now implementing it into C++ for MCU compatible speed/memory usage. Some parts are better done with traditional algorithms, some with geometric algebra.
-
Hey @JoergS5! Glad to hear you're still making progress on this massive task!
Are you planning on updating your GitHub with the code as you work on it? Or only once you have a complete, working, solution? Either is cool, just curious.
Looking forward to getting to test out the new IK once it's ready 🦾🥳
-
@toms I'll update the github as soon I have a working version, based on the new algorithms. My procedure is to update github only if it is buildable. I will offer some binaries for dedicated Duet hardware also, Mini 5+ for sure, and 6HC/6XD if you/someone needs it.
My first version will be for 6 axis industrial robots. (configurable for all, but primarily tested for 6 axis robot).
-
@toms BTW I'm currently reading Colapinto (master thesis, thesis, and articles), it's an exceptionally good source of information about geometric algebra - and free. He clarified some of my open questions.
-
Hello Joerg,
First of all, thank you for your continuing support & effort, this is really impressive work you have accomplished so far. Looking forward to the first final release (although it will probably never be final I reckon)!
I was wondering if you had any recommendations as to what robot you would take into consideration that works best with the Duet boards. I am new to this, and I don't really know where to start and particularly what I need to pay attention to.
What I am looking for is a robot arm that would allow for a "build volume" (if you can even use that terms in this regard) of approximately 1500x1000x1000mm (1500mm being the maximum height) for 3D-printing. I know there are lots of commercial options out there, but I was wondering what criteria a second-hand robot would have to meet in order work with your code and the Duet 2 (or 3). I don't want to spend 10K plus EUR before I know what I am doing.
Would be great if you could share a few ideas, but I totally understand you're a busy man.
Looking forward to hearing from you.
wieman01
-
@wieman01 hello,
this is a big robot you're planning to buy (or maybe build?). I have no experience with big robots, so I can only give you some thoughts without guarantee, but maybe on the forum are users with experience.
My thoughts are, if it shall be Duet based:
- it will use probably servos with high current, so a 6XD board is probably the right choice, with a 3HC extension card for optional more axes for endpoint functionality if necessary
- those robots use a lot of energy to operate. It depends on your requirements, but I would personally try to buy a low enery one which is slower or smaller or has less payload capability, but this depends on what you're planning to do with it. For palletizing e.g. the 5 axis robots have counterweights, they should need less energy compared to the 6 axis ones. The palletizing robots use a parallelogram structure for one axis less.
-
@JoergS5 said in Robotic kinematics:
@wieman01 hello,
this is a big robot you're planning to buy (or maybe build?). I have no experience with big robots, so I can only give you some thoughts without guarantee, but maybe on the forum are users with experience.
My thoughts are, if it shall be Duet based:
- it will use probably servos with high current, so a 6XD board is probably the right choice, with a 3HC extension card for optional more axes for endpoint functionality if necessary
- those robots use a lot of energy to operate. It depends on your requirements, but I would personally try to buy a low enery one which is slower or smaller or has less payload capability, but this depends on what you're planning to do with it. For palletizing e.g. the 5 axis robots have counterweights, they should need less energy compared to the 6 axis ones. The palletizing robots use a parallelogram structure for one axis less.
Hello, @JoergS5,
Thank you, that is a starting point.
We will be using that robot for 3D-printing. The overall payload it will have to carry won't exceed a few kilograms. So there is no heavy lifting involved.
Buying vs. building one myself... that is the question. I will need to see what is available first and then decide. It's tempting through to start designing one from scratch now that you are asking...
wieman01
-
@wieman01 said in Robotic kinematics:
It's tempting through to start designing one from
When I restart prototyping again, I'll document it in the forum, and you can decide whether you want to join!
For 3D printing, you need higher precision than usual, and the typical 6 axis industrial Kuka robot has too low precision for 3D printing (if I remember correctly, they have around 70 micrometer precision or accuracy). It will be very difficult to achieve the required precision with 1.5 m added arms (maybe impossible). If possible, I expect a parallel arm based printer can achieve it.
For your case, a CoreXY or Cartesian will probably be better: high precision, high possible build volume. 5 or 6 axis support can be implemented by combining it with a 3-axis print bed (AC, BC or ABC axis). The TUM (munich university) in Garching has a printer in your desired print volume, I saw them printing clay as well. Here in the forum is a current thread about a high volume printer.
Edit: this thread: https://forum.duet3d.com/topic/31228/dr-d-flo-s-big-build -
Hey @wieman01,
If you're interested in building your own 6 axis arm, I'd recommend looking into AnninRobotics. Chris Annin has done an awesome job putting together a pretty capable, open source, robot arm. It certainly doesn't meet your reach requirements, and having built one, the backlash is substantial enough that I don't think 3D printing would make sense / be practical (at least with traditional nozzles < 1mm).
I have version 4 of his robot arm running on 6 HCL's and a 6XD at the moment. There's more info and videos on my GitHub repo if you're interested.
It's not the cheapest build, but it was certainly fun.
-
undefined dc42 referenced this topic
-
@JoergS5
Hi Joerg, we are building a 5 Axis printer, XYZAC, very close to robot type 'Open5x'. I was happy to see that you already did a huge amount of work to get robot kinematics work on Duet, so I would like to build on your work.
I took the sources from v3.5.0-beta.3 and added your 'RobotKinematics' files. With some minor updates I managed to generate a binary. Unfortunately the system crashes (reboot) when I try to set the D parameters. The configuration itself looks ok, but the crash occurs as soon as 'RobotKinematics::getForward' is called. I have the following questions:
1 - Did I take the correct set of sources
2 - Should robotType='Open5x' work with your code base of December 2022 ?
3 - If yes, can you give me some hints how to find out what I do wrong.
4 - If no, do you have any advice, what the best starting point is to develop the XYZAC kinematics.
Thanks in advance ,
Lex James -
@LexJames the code you reference is based on Denavit-Hartenberg configuration parameters, but I changed to Screw Theory. The reason for the change was, that some positions didn't iterate correctly, so the change is from iteration to closed form (i. e. algorithmic solution).
The sources changed. I currently build a CoreXY 5 axis prototype to validate the code and then publish the code on github, together with binaries.
Sorry for your waste of time of the old source. I'll delete the repository until the new build, which is based on 3.5.0beta3.
-
@LexJames
Thanks for your prompt reply.
I will wait for the implementation based on Screw theory. Can you say something about the timing?
Can I help to speed things up? I don't have a development environment for Duet but I can test and develop in Windows.
Is there an old branch that worked for XYZAC?
Thanks again for all your good work. -
@LexJames of course it will be great if you can test the build. Developing and testing in Windows is not necessary currently, as I do it myself a lot, unit testing.
It's better to wait for the new build, because in the old ones I've tried different methods and I lost the overview (I tried everything like Euler angles, Euler axis, Jacobian with inverse, random iterations, quaternion slerp). The great thing about geometric algebra is that it integrates and explains them all.
I build the prototype as fast as I can. The build will be soon after.