Posts made by JoergS5

@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?

@OttoJiang

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.

@jwilo M595 documentation says that calling M595 alone will tell you the current queue length.

One possiblity for your pause is that the moves may have much segments and the queue lengths came to its limits. Which arises the question whether segments are counted as single queue elements or not. I don't know that.

Whether straight lines are segmented depends on the kinematics type and the move type. For kinematics with rotational axes *), a straight line is not straight from the view of the actuator, but nonlinear and needs to be segmented to be straight. With move type I means that e.g. in testing mode, moves are not segmented.

*) examples for nonlinear axes is delta, scara, polar (the rotary axis), 5 axis scara. Linear axes are CoreXY, Cartesian. The segementation has two default values, how many segments per time and how long a segment can be.

I have time in May and June now to proceed developing robot kinematics. The order is

• 4 axis parallel (the black robot arm), probably as a quick-and-dirty approach first for @YuriConfessor
• DWC plugin to design and analyse a given model
• CoreXY/Prusa/Cartesian 5 axis AC and BC
• 6 axis robot
• testing whether Qt is a possibility for a designer/slicer
• elaborate tool design. My personal priority is using robot for CNC, so I'll work on support for different tools (tool shape etc).

I'll use 3.5.1 as basis.

@o_lampe Veritas Streichmaß or DICTUM Streichmaß and "veritas streichmaß ersatzmesser"

There is also one with assembled adjusting ring on https://www.feinewerkzeuge.de/veritas-marking-gauges.html, "VERITAS Schneidräder für Zapfen" but it's a bit expensive (22 EUR), but maybe one can DIY.

@Toaster0042 I don't need the measurements, because it's not a 4 axis parallel robot.

It's like an industrial 6 axis robot, but without the 6th axis. Instead the 6th axis, the 6th actuator is used to grip.

I have code for the 6 axis robot, but not for your 5 axis plus gripper. I have to think about it. Your project is interesting, I want to support your robot type if possible. I will ask you to test code with your robot to verify the code.

@Toaster0042 You can help me by providing

• some pictures of the robot arm. Special interest is how the parallelogram is built, i. e. is it a triangle or some other solution. How is the parallelogram connected to the endpoint?
• exact measures of arm lengths
• to which parts are the steppers connected

This allows me to build the same and verify the code before publishing.

Forward kinematics is supported in the robot kinematics, but 7 axes mean more axes than are needed for a given position + orientation (a given position and orientation need 6 axes). I. e. there are infinite solutions for the inverse kinematics (from given position + orientation calculating the stepper angles). There needs to be a preference, e.g. prefer the first axes, or take the solution with lowest velocity of all axes. This needs to be implemented. If your 7 axes robot is a Kuka IIWAR820 alike, then there are some strategies discussed in the book of Pardos-Gotor Screw Theory for Robotics, and the inverse kinematics is solvable.

@Toaster0042 I will make a release soon.