JoergS5's CoreXY 5 axis (robot kinematics)
-
About Calibration:
the X, Y and A axes shall be horizontal and parallel to each other in the XY plane. I use this tool to calibrate it:
It has precision of 0.02 mm/m, but of course every spirit level will do. Or dial gauge constructions for more precision.
When the bed 0,0 is on the position of the C axis, the is no C offset to measure, so
M669 C"C=0:0:1:0:0:0"
The first three parameters are the axis orientation, the next three the offsets. Orientation is to the Z top, i. e. looking from above, positive angles are counterclockwise.
If there is an offset between bed 0,0 and the C axis, the X and Y offsets are to be measured. The Z offset can be set to any value (the rule is to set to any point on the axis).The offsets of the A axis are to be measured:
offset Y:
If C axis and bed origin have XY offsets, the Y offset between bed and A axis needs to be measured instead.
offset Z:
which means to measure including the bed thickness.In my case:
M669 C"A=1:0:0:0:140:-70"
If the A axis is below the bed, Z is negative.
The X offset is irrelevant, because any point on the axis can be taken.That's all about axis measuring, because the axis positions of the linear axes don't play a role for the calculation. It's only important where in respect to the rotary axes they are placed (this is specified with the B parameter).
The final task is to home the axes, so the reference coordinates match the endpoint position. Or other round, place the endpoint perpendicular to the center of the bed and set homing values of the 5 axes to 0 each. I'll describe how I try to home most exactly in one of the next posts and which options there are.
-
Short update of the build 28 July:
for A0 the inverse kinematics didn't rotate C, because for the vertical Z axis there is no C solution. To make it short, I've implemented a solution around so C rotates. The advantage is, A0 can be used to have a hotend which follows the print path.
When A changes between positive and negative, there are sometimes very rude and fast C rotations by 180 degrees. I've added abSign=2 which doesn't correct C degrees. Need more testing and validating.
Another experience is that precision is key, I'll make the construction stiffer at the weekend. I have often crashes at the frame, so all calibration is gone. The Z is quite limited by the RTCP corrections.
The next is Z axis, based on ballscrew. I was becoming aware that when the table rotates by AC, the Z axis becomes the new XY axis (from the viewpoint of the print object), so the speed is too low. There are three options:
- place the Z axis to the bed like "traditional"
- place the Z axis to the XY frame like Voron
- place the Z axis to the hotend like a gantry CNC does it
The first two options have high mass to move, so I'll try the third option next, probably belt based. This options has the same Z movement as Voron (moving Z when Z axis points down diminishes the distance hotend-bed), so it's a test for Voron as well.
-
@JoergS5 said in JoergS5's CoreXY 5 axis (robot kinematics):
A0 can be used to have a hotend which follows the print path.
That would be handy for air-assisted laser or baird-air print cooling:
You could aim the air, where it is most effective.place the Z axis to the hotend like a gantry CNC does it
Then you need a very stable joint between the real XY-gantry and the z-axis. It would be best to have two XY-rails and two z-rails building a #.
-
@JoergS5 have you looked at the zeroing solution the BrendonBuilds implemented for the Voronoi build:
https://github.com/FreddieHong19/Open5x/tree/main/3D_Model/Voron_0/DuetConfig/macros
This is interesting because it relies entirely on Meta Gcode to set the 0,0,0,0,0 position of the 5axis machine.
Currently it simply iterates through to the 0 crossing point one axis at a time, this may be sped up using a different method to iteratively determine the 0 point. It relies on a nozzle touch probe which on the Voronoi is implemented with electrical contact.
-
@T3P3Tony thank you for the link. I'm thinking a lot about how to home and calibrate fast, e.g. with the help of the LDC1612.
-
@o_lampe I currently plan to use two linear rails for the X axis (one in front, one on top) to stabilize the Z axis vertically. This will be especially important for a long Z.
-
@JoergS5 yes, we have also discussed this. Using the LDC1612 to detect the nozzle.
-
3rd edition? You'd think they would have got it right the first time.
-
-
@Phaedrux also that tape measure looks wrong...
-
This post is deleted! -
I've change the kinematics from screw theory to geometric algebra. It works much better now, especially with the Z direction, I had some errors.
Screw theory says that directions of axes must be reversed, depending on whether the axis is attached to the hotend or the table. I'm unsure whether it's the same with geometric algebra. This matters for Voron, whose Z axis is attached to the hotend part. If it matters, I'll have to add a paramter to specifify whether X, Y, Z axes are attached to hotend or bed.
I expected that geometric algebra is slower than screw theory, but to my surprise it is faster: 15 microseconds (for both forward and inverse) compared to 30 of screw theory for each segment calculation. M669 R gives a statistic. (M669 R currently unhomes all axes, I don't know why).
=> Edit: I know why it unhomed, it was the seen variable in Config. I've added a D parameter (see documentation on the main page) to decide not to unhome if wished, if configuration is changed.
I currently build bins and will upload to github together with the sources. Duet 2 still compiles without error.
BC mode should work also, but I have no BC prototype and cannot test it.
I saw an article to build a machine with two rotary axes with arbitrary angles, this I will investigate. It uses Paden-Kahan 2 to translate AC/BC angles into the machine angles. This will cost processing time however.
-
Short update about my activities:
I am aware that RRF is restricted by memory and performance. It has only a few KB or available RAM and every ms is important. So I thought about how to optimize the usage for robot kinematics and will try the following procedure:
- best performance is when the axes are perpendicular and AC/BC axes are in A/B/C directions. The calculation is easiest then and performance best
- the algorithms allow skew axes and arbitrary axes also, so I want to support them also
- so I'll establish a decision tree to use the simple, fast calculations when configuration uses the first case and full calculation for the other
- at every move, first is a call to LimitPosition, so I can check configuration changes there and cache values if possible
- one performance measure I didn't use yet is to cache AC/BC values for moves where AC/BC don't change. I'll implement this now
For memory usage of the bin file, I'll remove every code which is not used. I have a lot of code to calculate between transformation matrix, quaternions, Euler angles, CGA and skrew theory. I don't want to loose it, but storing it into RRF uses much memory. So I'll make a separate github project to store it there. The redundant solutions allow cross check of the calcuations.
For visualisation, the DWC is a bit problematic for me, as I don't want to migrate between C++ and TrueScript. I'll use C++ with OpenCV until I have a better solution (or someone can tell be a solution). So I can use one C++ code base.
An open topic with 5 axis is that rotations are not velocity constant. I'm thinking about how segmentation could be changed, but this is code outside kinematics, it is part of the core RRF. An intersting article to introduce into the topic and how it could be solved with a modified slerp is "Yan/Jeng/Chieng Five-Axis Slerp for Tool-Orientation Planning in a Five-Axis CNC Machine".
-
@JoergS5 I am very interested in your progress so far. I am about to build a mini mill and will at some stage get a 4th and 5th axis so if you need help testing let me know. I will most definitely be 3-4 months off getting it done as funds don’t allow it at the moment so the project is being drip fed
-
@samlogan87 my next step is to CNC including milling, so my activities will help your project. I have e.g. a boring head (german: Ausdrehkopf) which I want to integrate.
-
@JoergS5 said in JoergS5's CoreXY 5 axis (robot kinematics):
Voron, whose Z axis is attached to the hotend part
Just a note. this is only the case for Voron 2.x, V0 and Trident move the bed.
-
@T3P3Tony thank you Tony for the comment. It's important to be aware where the axes are attached (hotend or bed), because this reverses the calculation.
I'll make a decision matrix in the documentation with sample config settings to make it clear. Especially with CNC and milling there are several variants, e.g. the A axis being at the drill side.
