@Nakcam thanks a lot, I hope this is sufficient information for now to start. After the firmware runs, we can discuss improvements if you like. As always it will depend on what you want to do with it whether it's worth to improve precision etc.
This remembers me of that I need a load lifter, maybe I'll build it this this kinematics. Similar to a IRB 760.
@Nakcam here is a short explanation of the parallelograms:
The blue and red ones are connected through the triangle. The triangle is like a curve of the arms from up to down.
The opposite sides of blue, red and green parallelograms shall be parallel each. When they become "flat", i.e. small angles and opposite sides near at each other, the movements and caluclations will become inexact. So this situations should be avoided.
@Nakcam thank you! I don't have Fusion, so from your image I can make a prototype as well.
Please measure the triangle lenghts as well, from hinge to hinge each.
@Nakcam the D values make only sense when the axes are calculated in the chain. This is only implemented for CoreXY. I you want to test setting D values in advance, just define your config for CoreXY.
@Nakcam I can work next weekend on it, and it would be nice if you can make some tests with the prototype, verifiying code, while I develop the code. I can provide you the RRF binary for each test.
@Nakcam the kinematics is not implemented yet, but I'll try to do it with your help.
Please confirm or correct me:
Your short video looks like the front horizontal platform tilts a bit, the front going a bit down. This may be an optical illustion. But if it's real, then some of the angles are wrong and the construction is not a parallelogram. Maybe you'll need to change the prototype a bit. But let's make the kinematics first.
BTW I like your prototype, because the gear is belt based, which means low or no backlash. The planetary based gears have some play when changing orientation of the rotations.
@Nakcam it's more complicated then serial Scara:
the platform in front stays horizontal, due to the arm's nature: they make movements of a parallelogram, which means some of the arms stay parallel. The calculation is simliar to 5 bar paralleld scara, where two actuators together make a movement which is restricted by the connection at the end point. The inverse kinematics must calculate back with this restriction, with the added problem that there are multiple solutions for the inverse kinematics.
Your image looks fine, but differs from the black robot model: the back arms of his model are fix connected to the platform at the bottom. (looking from back, the left one)
Do you have a prototype, or only the drawing? If you have a working model or prototype, please give me information about how it is built exactly. (which of the arms are connected to the actuators=steppers, which are only connected through hinge, but not driven by the stepper)
@o_lampe no, it's the crossing point of the three last axes of the industrial robot. The calculation of the inverse kinematics is much easier when they cross. The nozzle will simply add with his length and orientation.
@MihaiDesigns this robot type is very similar to Gantry Robot (eg ABB IRB 6620LX), discussed in the book Pardos-Godor Screw Theory for Robotics. It is 6 axis. The book's approach finds all solutions by calculation (no iterations needed).
It can be described by the order of the axes (linear, then rotational etc) and the tool orientation and position.
The inverse calculation is described in the book, which divides the calculation into subproblems. You will have to handle multiple solutions for the inverse kinematics.
I tried different approaches, starting with Denavit-Hartenberg and Euler angles, but those calculations have many special cases like Gimbal lock and special handling when 90 degrees are crossed etc. This is "local calculation", meaning the axes are calculated one after another. The "global calculation" method by using screw theory is much better and avoids some of the special cases (the singularity situations).
I currently develop a general approach which will cover your case, but I don't want to make a promise about the time frame. Robot kinematics is planned for RRF 3.6.
An important aspect which I want to add is that those kinematics need to take into account the orientation of the tool, in addition to the position. Some RRF code expects the tool to be vertical, eg mesh compenstation (probably same with baby steps). It doesn't work with non-vertical tools. It is currently a workaround to include the tool into the calculation tool chain, so you have control over the calculation, and set the tool to 0 length.
Last comment: with two rotational axes you will not be able to make all rotational movements. 3 rotational axes would be better (like the Gantry robot I mentioned above). Easiest to calculate is if they are mechanical built as spherical, i. e. the three axes cross in one point. Similar to how most industrial robots are built with axes 4 to 6 in the head.
@OttoJiang I don't recommend it, because this kinematics is only one of several ones of robotics kinematics. When they are complete, we can github it.
As an overview please see https://docs.duet3d.com/User_manual/Machine_configuration/Configuring_RepRapFirmware_for_a_Robot_printer with additional documentation pages.
@OttoJiang said in voron5x with RTCP:
This kinematics approximates linear motion by means of segmentation
thank you that you found the solution of a problem I was not aware of.
@dc42 could you please add this code to the GCodes part, maybe with some flag condition for specific kinematics?
I am confused a bit by your mp4 video file, because the printer behaves exactly as expected. Is the video with your bug code correction?
Maybe you means the Z moving up and down a bit during the movement. This may also be because of Z backlash *) in the construction. How is your Z axis built? It needs to be without backlash. The requirement of Z movement is much higher now than a simple movement in one direction for a 3-axis printer.
*) you will probably know what I mean with backlash. But for other readers: I mean when the Z axis motor changes direction, some steps are lost because there is play in the gear/ball gears/axes with the effect that the opposite movement is later than expected. Some steps are lost. The 3-axis printers don't have backlash because they move only upward and gravity assures that the gear/beal gear are always at one flange of the machanics.
@OttoJiang said in voron5x with RTCP:
It should actually move in a curve to keep the nozzle's XYZ coordinates in the workpiece coordinate system constant during the movement.
Hello,
correction of the XYZ, so the nozzle stays at the position when BC changes, is exactly what the code shall do, and it worked in my tests. Please tell me where you mean the error in the code lies.
Your other post, you want constant velocity:
Segmentation works to linearly segment every axis movement/rotation angle. To achieve what you want, you need a change of the segmentation code. First to change is the BC angle change. As an example, to rotate in 10 segments 45 degrees, segmentation is 4.5 degrees for every segment. But needed is something like the Slerp algorithm to divide the BC into a constant velocity. But the code needed is located outside of the kinematics code. Currently angles are simply divided for segmentation, B divided and C divided.
(to be more exact: you cannot make all rotation movements with BC alone, you would need 3 rotation axes. There is an article to approach the correct movement with BC, missing the A axis, with minimal error. The code uses Slerp code also. Slerp is easiest calculated using Quaternions)
To make it worse, if you need true constant velocity, you must know your path and combine the movements of the linear axes with the rotation Slerp-based calcuation and then calculate the segmentation needes of every axis. Calcuation of the exact path needs a lot of mathematical calculation. It is better made in advance by a slicer and sending the single segments as G-Code, instead of letting Duet calculate the segmentation. You need in the range of 10 microseconds for every segment to have an efficient movement. (You want a low millisecond for a movement, with maybe 100 segments). The current code is in this range, but a path movement (including BSpline, Bezier and such) calculation will add time.
The current RRF code is based on time framed calculation: how many steps needs every axis, then put them together into the time frame, then try to send one step signal to as many axes as possible at the same time (Duet sends one signal to multiple motor drivers). You requirement needs separate signal calcuations and step signals for every axis at his own, each one at a given time. It's not impossable, but needs more caculating power.
@Toaster0042 you're right, I should inform, I will prepare an update.
@Mafco77 thank you for using the kinematics and nice to hear that you're using it successful.
I probably have implemented the homing of CoreXY wrong somewhere. I'll check it. But please be patient for solving this, it's not the highest priority and you have a workaround.
Hello @Mafco77 your homeall is:
G91 ; relative positioning
G1 H1 X255 Y255 F1800 ; move quickly to X axis endstop and stop there (first pass)
G1 X-5 Y-5 F1800 ; go back a few mm
G1 H1 Y255 X255 F360 ; move slowly to X axis endstop once more (second pass)
G92 X120.94 ; set x position to the center of bed (you may want to adjust this)
G90
and the documentation in https://docs.duet3d.com/User_manual/Machine_configuration/Configuration_coreXY says to home the X and Y separately.
In my understanding, your procedure will stop at X or Y, which is reached first, then ends. So one endstop will always be unhomed. If you starting position is near to the Y endstop, your X endstop will remain unhomed. If it's near X, the Y will stay unhomed.
The move back and fine home doesn't help, because it will trigger one endstop again and stop, the other endstop being unhomed.
The homeall in the documentation moves X and Y in two commands separately. This makes sure that both axes are homed.
Documentation:
G91 ; relative mode
G1 H1 X-240 Y-240 F3000 ; coarse home X or Y
G1 H1 X-240 ; coarse home X
G1 H1 Y-240 ; coarse home Y
G1 X4 Y4 F600 ; move away from the endstops
G1 H1 X-10 ; fine home X
G1 H1 Y-10 ; fine home Y
So X will be homed first, then Y is moved until homed.
Your homall will move both X and Y, until one of the endstops is triggered, then stops.
@OttoJiang I have not added any special code to the kinematics regarding homing or interpretation of G1 H commands (G-Code handling is out of my reach).
@jwilo in the source code of the firmware is the comment in Move.cpp for the method MotorStepsToCartesian (the method calculates the cartesian coordinate from the current stepper positions):
// Convert motor coordinates to machine coordinates. Used after homing and after individual motor moves.
So this method is called after each individual move and probably interrupts the movement merging.
When the hinge play is the problem, you could design a solution with eg springs to press the ball bearing to one side always, so the inner ring stays there.
The backlash could be play between stepper axis and wave generator of the harmonic drive, but the backlash is with the harmonic drive ratio, i.e. if it's for example a 1:50 gear ratio, the play would result in very low backlash (1:50 th of the stepper-wavegenerator-play), so I suspect the other hinges.
@NortonAntivirus my opinion is that it's not the harmonic drive causing the problem, because harmonic drives don't have backlash by design (the flexible spline and the circular spline are connected with the teeth having no play). In you example if the left line movement is from right above to left down, and then the short shaky lines, then the right to right above, that's when the stepper change direction.
This shaking and offset of line can come from one of the hinges having too much play, so the balls inside the ball bearing is changing from running and touching one side of the bearing to touching the other side, and this play causes the offset. Can you test whether one of the hinges have play? Test the hinges horizontally and by twisting.
I mean this, being a ball bearing:
The play can come from the axis inside the hinge as well or flexing of the arms. Arms probably not, they have a high e-module, but the inner axis of the hinge seems to be a screw, this could have play.
When arms are low angles between proximal and distal arms as in your example (= near the steppers), then low play is especially important for precision of the movement. And the steppers need more force to move than if the endpoint if farther away, i. e. there could be lost steps also, especially when the acceleration is fast.