I am plan to diy this wonderful arm, but I am not found stl for right leg.

There are no documentation on how to wire the TB6600 and A4988 with the RAMPS, can you provide that ?

Excuse me, would you please tell me how can provide 3 d solid model file, or have already cooperate with good assembly file, thank you

 //
  float lmax = max(abs(xff[0]-xfi[0]),abs(xff[1]-xfi[1]));
  lmax = max(lmax,abs(xff[2]-xfi[2]));
  lmax = max(lmax,abs(xff[3]-xfi[3]));
  lmax = max(lmax,abs(xff[4]-xfi[4]));
  lmax = max(lmax,abs(xff[5]-xfi[5]));
  unsigned long preMil = micros();
  double l = 0.0;
  vel0 = min(vel0,sqrt(lmax*acc0+0.5*velini*velini+0.5*velfin*velfin));
  unsigned long curMil = micros();
  unsigned long t = 0;
  double tap = vel0/acc0-velini/acc0;
  double lap = velini*tap+acc0*tap*tap/2.0;
  double lcsp = lmax-(vel0*vel0/2.0/acc0-velfin*velfin/2.0/acc0);
  double tcsp = (lcsp-lap)/vel0+tap;
  double tfin = vel0/acc0-velfin/acc0+tcsp;

It's a bit confusing. Are you using trapezoidal velocity profile here?
Vini is initial velocity, V0 is constant velocity and Vf is final velocity, it seems that calculation is wrong to me.

What software do you use to make schematics?

I startet building the robot and I'm printing since a view days the files. I use different standoffs (10mm in diameter) and I need to change the "Axis1MotorHolderOp" in Fusion 360 file Axis3. The component in this file is damaged (two bodies that fit not well together). The Fusion 360 files do not fit to the supplied STL files.

Hello,
timing belts GT2 with 3mm teeth are not available. Would you be so kind to reconstruct the two pulleys with a 2mm version or send the Fusion-files for those pulleys ?
This would really help.
Thanks a lot and great job.
Joerg

First of, hats off to Mr. Skyentific for sharing this code with us. I took a deep dive in it for the IK math implementation (seems too hard for me to implement from scratch), and I ran into several issues related to IK calculations:

(1) InverseK() function works good, but ForwardK had a math error:
Xfk[3]=Xfk[3]/PI*180.0; Xfk[4]=Xfk[4]/PI*180.0; Xfk[5]=Xfk[5]/PI*180.0;
The above lines are not interpreted correctly, as Arduino honors the multiplication first and division second in this case. The correct version for Arduino looks like:
Xfk[3] = Xfk[3] * 180.0 / PI; Xfk[4] = Xfk[4] * 180.0 / PI; Xfk[5] = Xfk[5] * 180.0 / PI;

(2) The dreaded singularity (and maybe division by zero issues):
I wrote some additions to the code that run IK calculations, take the result and run FK on them, then return the error between initial target and round-trip calculated values. So far I am getting a stable round-trip error of less than 0.001 when feeding IK otput directly to FK input - which proves the math is implemented correctly.

For the cartesian X, Y and Z axes everything is very stable.
However, or the ZYZ Euler angles I was getting weird numbers when input values are equal to 0, 90, -90, 180, -180 or anywhere beyond +- 180 degrees - this causes singularity which was not accounted for in original code, and it's strange it works so well in the videos given the heavy use of +-90 / 180 degree angles as example inputs.

Singularity looks quite detectable by calculating error. Normally at 89.9 degrees input max error is below 0.001 degree, however at 89.99 degrees the calculated error rises to 0.02, and at 90.0 the output goes haywire to random values like +-30 degrees.

They say, dealing with singularity is one of the more complex robotics problems. I see super simple ways to deal with it on a hobby scale:
1 (mandatory) - limit the possible input values strictly between -180 and +180 degrees and convert any values beyond those to within limits
2 (mandatory) - take into account axes travel limits and reject moves that would lead to out of bounds
3 (dirty) - add or substract a little value like 0.01 from a 0.00 / 90.00 / 180.00 degree input just to avoid singularity
4 (clean)- run an FK calculation, detect high calculated error and reject command before executing.

For a desktop robot - I agree skipping all this is totally fine. However, for upscaling (which I see the potential for in this project) to anything bigger needs a serious approach to math in such a complex subject as IK.

Can you please let me know the minimum and maximum size of the Robot.
Also total weight of the Robot arm

Small Robot Arm ,The project is very great. Thanks! But how to control by Marlin software? Like 3D printer machine can print GCode files.

I know this code is 4 years old, and it's just a small robot arm we should not expect much from, but it is a great resource to learn from and I love Mr. Skyentific's implementation of inverse kinematics here. I took a deep dive into the code looking to scale it up to a bigger and more serious arm, and I have issues with the coordinatedMotion() function and moveMotors() behavior.

Essentially, what the implemented coordinatedMove() function does is breaks the move into 3 phases: acceleration, stable speed and deceleration. Then calculates the time and number of steps needed to go through each of these stages.

HOWEVER, the steps are always administered to the driver at the maximum possible step rate, leading to all of them being sent in one batch and then just waiting for the time for the next phase of the move to come. Rinse and repeat.
What if the motors are so fast that they perform the move sooner than the time for the next movement phase comes?
What if the move is very slow and very long?
The effect is compounded by doing that to 6 motors, one at a time (!), leading to an uneven start of movement in every one (of three) phases of motion.

Verdict: this is not coordinated movement at all!

What can be done for this to be scalable?
1 - the delay between high/low pulses for each motor must be adjusted individually for all 6 motors to ensure smooth stepping from the beginning to the end of each phase of movement

2 - steps need to be administered to motors in an asynchronous way simultaneously: e.g. synced first step, and then all steps given out with various (calculated) delays, all leading to motion at the right speed for each individual motor.

3 - use a ready library and a faster microcontroller, like Teensy 4.1 and AccelStepper, or copying code from one of the 3D printer firmwares.