5 DoF robotic arm speed control

I have read that it doesn't check the end effector postion in relation to the joint limits.

That is correct the limits don't work [properly] with non-trivial kinematic.

[actually I found now that it does work to some extent as the joints will not be run over the limits set in the ini but the motion planner will not FORSEE that it will happen. Meaning program execution will just suddenly stop with a joint limit error]

Hi,

Pid tuning is really important for robot's. But the stepgenerator configurated as 'v' for velocity control concern's me.
Where is the position feedback control in this case? The encoder captures the position feedback, but a second "device or control" has
to bring the motors in exact position.

I am suggesting that the gensterkin's is not using a halcmd setp ratio for max_acc for each joint to each commanded position.
If it was so, the joint's will alway's end the movement together in the case of rapid moves. This result's in a dynamic movement.

If the robot is shocking at corners, you could see that in halshow. If parameters are not updated it can be easely spotted. It could be that there are no kinematics solutions during that shock time. Therefore more robust kinematic's use 100 iteration's instead of one.

@Grotius
He's using trivial kinematics.

Hi,

However, PID parameters have been autotuned with at_pid,so I think they are correct.

As for the kinematics, I am using the trivial one since the angle joints are worked out by another software which uses an inverse kinematics algortithm, then I export the gcode file to upload it on LinuxCNC.

The inverse kinematics algorithm works out the angle joints taking into account their limits, and finds the best solutions after some iterations.

Hm, I certainly don't see anything like that on my robot. I do get a fair bit of corner rounding if I don't use G64 P1 but you have already got that in your code.

The other thing I wanted to add is that my earlier statement saying limits don't work when using non-trivial kinematics is not quite correct after all. I found that it does work with some restrictions:
1) the Joint limits are respected. Meaning your joints will not be driven past the angles set in the respective [Joint] section of the INI. BUT:
2) since you cannot have joint limits that are smaller than axis limits declared in the INI without getting an error at startup the axis limits will have to be reset to eg +-99999999 after linuxcnc is started.
3) What doesn't work is the "lookahead" for limit violations by the interpreter/motion planner. So there will be no warning BEFORE the joint reaches its limit but motion will stop when it does.

Actually I tried to use G64 P0.05 maybe I have to use higher P values.

Could this be the reason?

Give it a try and report back.