Robotic kinematics
-
I am starting a new topic now in the "My Duet controlled machine" to apply the robot kinematics to robot prototypes of different kinds. You're invited to join the process of building:
- CNC 5 axis for abrasive drilling (with iHSV servos and 6XD) and CoreXYAC 5 axis for additive 3D printing
- 4 axis palletized for 3D printing (only for proof of firmware working)
- 6 axis industrial robot (later)
The next steps are:
- prototypes and verify robot kinematics in real life
- improve RobotViewer DWC plugin
- find or develop a free software solution to create 5 axis G-Code
I will concentrate on CNC. Some users plan to create CoreXY 5 axis printing, so for 3D printing, the 3D printer prototypes are mainly meant to help solving problems.
-
-
@JoergS5 Re: "My main confusion was reading an article about G-Code based on IJK (using tool vectors in G-Code) versus AC. The article wrote, an advantage of IJK is the machine independence. But in my understanding, AC is also machine independent (with the exception of the axis direction of AC versus BC). If someone knows if this is correct, a confirmation would be very kind."
Answer:
AFAIK, there is no international standard beyond 3 axis CNC G-code (ANSI/EIA RS-274D, ISO 6983-1:2009)XYZIJK notation is usually not interpreted by the CNC controller. It is usually used in an intermediate format of the CAM software. A post processor is used to convert it to the correct NC language for the selected machine.
There are two ways how G-code axis codes XYZABC can be interpreted.
a) direct joint control: each G-code axis is directly mapped to one joint/motor and controls only its position.
b) Tool center point control (TCPC): inverse kinematics are applied so that other joints compensate changes in the commanded position of the rotational axes.This way, G-code axes XYZ control the tool center point (TCP) position and axes ABC control the tool angle/orientation.LinuxCNC is based on "NIST RS274NGC interpreter, Version 3". It cannot interpret the XYZIJK notation. LinuxCNC by default uses identity kinematics ("trivkins") which means direct joint control. it can (should) be configured to use kinetics that match the machine geometry, e.g. by adding this section in the config INI file:
[KINS] KINEMATICS = xyzac-trt-kins
Then, at startup, it applies the correct inverse kinematics to allow TCPC. You can change to direct joint control mode at runtime using a combination of M66 and M68 commands.
For added confusion, LinuxCNC can be configured to start in direct joint control mode at startup:
[KINS] KINEMATICS = xyzac-trt-kins sparm=identityfirst
Source: https://linuxcnc.org/docs/devel/html/motion/switchkins.html
Siemens Sinumeric controllers cannot interpret XYZIJK or XYZABC notation, only their own formats: https://www.manualslib.de/manual/134235/Siemens-Sinumerik-840Di.html?page=69#manual
Haas
direct joint control mode: G49 (default)
TCPC mode: G234
XYZIJK notation: noFanuc:
direct joint control mode: G49 (default)
TCPC mode: G43.4
XYZIJK notation: G43.5 (RTCP type II) -
@DerAndere I wanted to use IJK, but then searched for alternatives, because IJ has a conflict with G2/G3 parameters. That's the reason why I changed to AC/BC and quaternions for full orientation. There is no G-Code standard for quaternions, so I use an artificial currently, until someone tells me which standard to use...
I am using the b) method which supports the RTCP mode mentioned and explained e.g. in the links (the beckhoff one gives the fastest overview):
https://www.cnczone.com/forums/uncategorised-cam-discussion/413638-cnc-mastercam.html
This method has the advantage that you can configure the robot to calibrate any inexactness of axes, e.g. between X and Y. The kinematics will calculate the true rotations and positions. The idea is to measure the endpoints and calculate back to the config parameters.
LinuxCNC is a great software and I'm taking it as reference sometimes how to propose parameters. It has however only experimental nurbs and bspline support, that's the next topic I want to address.
The Fanuc has IJK support, but they need to change modes before using it (probably because of the G2/G3 problem), so it's a proprietary solution. Fanuc has good manuals. I find only few information about 5 axis CNC, so it's a valuable additional information source.
-
The current status is that I changed internal calculations to skew symmetric matrices, but there were differences to the quaternion based calculations. The formulae in the internet are inexact (the rotation angle is set to 1), I've found the solution yesterday to get correct results now. Unfortunately from skew to rotation, there are also two solutions(!). As I said, orientations are a beast. I always use forward-inverse algorithms to calculate roundtrip calculation with random parameters. stackexchange and stackoverflow are very valuable information sources!
-
@DerAndere the different configurations of Haas and Fanuc shows imho that every manufacturer made his proprietary solution in the past. Worse, to get some advanced capabilities, one had to pay for those "options" additionally.
Some combinations were not possible, e.g. changing the tool length for Fanuc prohibited using some special modes afterwards. robot kinematics uses the G10 offset settting of the current tool, so tool change should be no problem.The second problem is that there is no free software to support 5 axis. There are plugins in Blender and FreeCad, but to my knowledge not advanced ones. Currently I think, best would be to develop an own solution based on OpenNurbs, which is an open library developed by Rhino. Rhino itself is a bit expensive if one wants to use it noncommercial as hobby. (Hobby, non-commercial, being not a student => 1000$).
-
@JoergS5 List of open source CAM software for multi axis FDM (tool path- and G-code generators). I did not test them yet:
- https://github.com/GuoxinFang/ReinforcedFDM (uses Rhino IIRC)
- https://github.com/zhangty019/MultiAxis_3DP_MotionPlanning
- https://github.com/Spiritdude/Slicer4RTN
- https://xyzdims.com/vgcodectl/ : source code release planned
-
@DerAndere thanks for posting these here. two of them are @xyzdims work!
Also not sure if you saw but the zhangty019 work is been built on further:
https://dl.acm.org/doi/10.1145/3550454.3555516 -
@T3P3Tony Hi Tony! Thanks for the update. As a reminder for my future self, here is the source code related to the publication you mentioned: https://github.com/zhangty019/S3_DeformFDM
-
@DerAndere thanks for the links, I'll check them!
-
@T3P3Tony this is a very promising article and slicer.
robot kinematics is based on quaternions, this fits. -
I rediscovered a book about screw theory (another name is: exponential coordinates), about robotics by Lynch/Park 2017. I had refused it, because the examples are without solutions (students shall not know the solutions if a teacher uses the tasks). But after review, the rest of the book is very good. I had problems understanding the book of Murray/Li/Sastry about the same topic. Both books together, all became much clearer.
Screw method is an alternative method to Denavit-Hartenberg and is faster than this method. I will change all internal methods to this new method, but let the configuration parameters at Denavit-Hartenberg as is. I will add an additional optional input method for screw parameters with the M669
RC parameter (S is unfortunately not free...).Screw method allows more precalculation of the configuration values, so calculation of specific positions is faster. The whole is based on Rodrigues formula and the screws are very similar (and can be transferred to/from) quaternions.
The name screw comes from the similarity of a screw: each actuator's movement is described by a rotation and a translation, like a screw. Forces/torque calculations are also described with this method.
http://hades.mech.northwestern.edu/index.php/Modern_Robotics provides information about the Lynch/Park book. The free preprint version is there also as pdf.
Little update: the following books are about screw theory:
- Lynch/Park 2017 as mentioned above
- Murray/Li/Sastry
- Peter Corke, Robotics, Vision and Control => Matlab extensions, visision analyzing code
- Pardos-Gotor, Screw Theory for Robotics. An illustrated handbook. *)
*) there is a book of the same author named Screw Theory in Robotis, being more expensive. It seems to be similar (I don't know for sure).
I'll use the Corke book to extend the robot kinematics into two directions: improving path planning for smooth curvature (nurbs etc) and to improve quality by camera analysis with help of OpenCV.
Little update Jan 3:
I'll concentrate on implementing the closed form Paden-Kahan subproblems now, which allows direct algorithmic solutions instead of iterating. The subproblems are explained in the Pardos-Gotor book.I've created a documentation page about screw theory now at https://docs.duet3d.com/en/User_manual/Machine_configuration/robot_screw_theory and will fill it with content.
Happy new year!
-
I'm currently converting the subproblem code from Matlab of Pador's book into C++ code for the firmware, with performance optimizing.
The results are very promising with respect to speed and quality (all solutions of inverse kinematics are provided), so I'll concentrate on screw theory now and will push back Denavit-Hartenberg (DH).
I'll remove documentation for DH next week and reorganize documentation, so if someone needs it, please back it up. I'll try to write a converter for DH->screw parameters, but this is low priority. The screw based setup is easier than DH parameters.
The first implemented robot types will be:
- 6 axis industrial robot
- serial scara
- CNC, CoreXY, Prusa like 5 axis
-
@JoergS5 said in Robotic kinematics:
remove documentation for DH next week
rather than removing it, could you update it to say tis not currently being used. You have put a lot of useful information in there, maybe some else will need to use DH in the future.
-
@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).
-
-
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...
-
-
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