Posts made by JoergS5

@Nakcam it's all fine with your information, I have "only" a time problem. I can proceed tomorrow for a few hours.

@DoodleCube said in Need help with 5 Bar SCARA configuration:

it seems RRF3 on Duet 2 stopped supporting 5 bar

there are flags in RRF to turn on or off those "exotic" kinematics, so if you're able to compile it yourself, you can turn it on for Duet 2.

Pins.h
'# define SUPPORT_FIVEBARSCARA 0
Set this to 1.

@Nakcam thank you for clearification.

Robot kinematics is based on a chain of the actuators: axes with position and orientation and arms between them. The endpoint is just an additional arm without axis. So you can add axes at the beginning and end, but inverse kinematics must be able to calculate it. Your rotating base is included in the 4 axis parallel robot type. Your linear axis at the beginning is something additional. The robot type sometimes has an additional actuator at the endpoint, for rotation of the end plate or for a gripper.

I proceed tomorrow to develop, because I feel that I have understood it now. I will develop with the blue line being curved optionally. (not a straight line between the three hinges of the blue line).

@Nakcam sorry for the delay. I had a family problem, I'll try to proceed.

I want to clearify, please tell me:

My understanding is:

• 1 is the first actuator
• 2 is the second one. Together they define through the parallelogram the blue arm and the lower end position, lower hinge
• 4 (the second arm in back of 1) is unclear for me: is it just to stabilize or has it a movement function?
• 5, 6 and 7 define the upper endpoint in respect to the lower endpoint through parallelism

Is my understanding correct?

Comment in advance to the linear rail where you plan to install it on: this fits perfect into a calculation chain, but you have 4 actuators and 3 degrees of freedom (xyz, orientation always the same). This results in indefinite solutions (you can reach a point with different combinations of linear rail and the 3 actuators), i.e. for a desired position there must be installed a strategy. E.g. if the planned coodination is out of reach, move the linear rail to the middle of the new next work area. This movement should not be in a move, but between moves. I want to make something similar: some (5 or 6) robot arm installed on a linear rail at the wall.

@droftarts said in Need help with 5 Bar SCARA configuration:

looks like the kinematics expect the X actuator on the left

the X parameter is for the first and second actuator's X coordinates, Y for the Y. In the documentations example: "E.g. X0:100.5 Y0:0 means 100.5 apart and both on the y axis." makes it clear. But this may be an example of confusing documentation...

The first actuator should be on the left. Otherwise some details like numbering of the work modes will be wrong.

@DoodleCube Stepper orientation: the definition is the axes are pointing out from the plane to you and then positive degrees are a rotation counterclockwise. So with H2 single actuator relative movement, a positive rotation must be counterclockwise. e.g. G91 G1 H2 X5 should rotate the first actuator counterlockwise by 5 degrees. Best start with small values and when you have confidence, use a value where you see whether the steps/degrees are correct, e.g. with a 90 degree rotation.

@oliof said in Need help with 5 Bar SCARA configuration:

H2/ direct motor moves happen in degrees

you're right. This may explain my strange experiences.

@DoodleCube I have some ideas, but I am not sure whether they are correct. But you can try:

• the wrong read can be due to incorrect steps/degree calculation. Check microsteps and the gear ratio. You can measure the gear ratio by turning one wheel by 360 degree and look how much the other turns. Sometimes documentation says 1:5 and in fact its something like 1:5.18. Another possibility is slightly wrong arm length definition or some tilting of the arms (or Z movement not exactly horizontal arms). Another possibility is that home setting was not exact. The 5 bar Scara is very sensitive to exact degree reading and setting, 0.1 degrees make a big difference. This is different to linear axes, where it doesn't matter much whether the endstop is slightly wrong (with the exception of eg polar kinematics, where the calculation depends on the true absolute position. But cartesian/CoreXY, it can be slightly wrong).
• when motors are moving in unexpected directions, in most cases it is a wrong stepper direction setting. Just reverse it (M569 S parameter). Your steppers are pointing down, so you need to reverse, compared to the normal usage. When using wrong settings, I also had some very strange behaviour, e.g. different results when using absolute or relative movements. You can verify that absolute and relative movements are behaving correctly both.
• the M92 settings are steps/degree for rotational axes, I've made a few examples. You can see the controller values of the position by calling M114, they are the values in section Count.

Hope this helps.

@DoodleCube said in Need help with 5 Bar SCARA configuration:

little bit confused on the documentation

please tell me what you don't understand, then I will clearify it (because I am the one who wrote the documentation - and developed the kinematics).

Did you read this page? https://docs.duet3d.com/User_manual/Machine_configuration/Configuration_five_bar_parallel_scara

@DoodleCube

I guess the C80:200:100:-17 values are wrong. X actuator from 80 to 200 degrees seems ok, but 100 to -17 not. Try 0 to 150 instead. The first value of the second actuator 100 is the min value, so it would mean from 100 to 343 (360 - 17), but I don't think that the code calculates 360-17. It will deny the calculation, because min is higher than the max value. Additionally, the 100 to 343 doesn't include your desired 90 degrees. The homing positions is outside the C values, that's probably the reason for the be unreachable message.

To make it short, try e.g. C80:200:0:150

If you want to make it exact, check which areas are reachable by the endpoint with the given mode L2, and watch the possible angles, then set them.

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

• 1 is connected with first actuator/stpper
• 2 is connected with the other
• 3 is connected to base
• 4 is a hinge connecting three parts: tringle low, big arm and other big arm

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?