Custom kinematics causes joint velocity limit violation
04 Jul 2023 15:07 - 04 Jul 2023 15:10 #274751
by iforce2d
Custom kinematics causes joint velocity limit violation was created by iforce2d
I'm making a machine with linked motion between the X and Y axes, so that when the Y axis motor turns, the X axis will also move the same distance unless compensated to stay in the same place. I made a custom kinematics for this which is barely more than the trivial one:This works great and the motion is correct. But I'm having problems moving in directions that require the X motor to move very fast. For example when the Y axis is moving in the direction that causes the X to go left, but the commanded movement for X is to go right, it needs to move as fast as the Y axis is going to cancel that out, plus whatever speed it needs to actually move right. The worst case is a 45 degree diagonal movement toward two specific directions that cause this, eg. 'north-west' and 'south-east'. Fast movements in these directions cause joint following errors.
I thought [JOINT_x]MAX_VELOCITY was intended to enforce a limit at the individual joint level, so that regardless of what speed the operator commands, all joints would only operate within their capabilities. Was I wrong about that? If so, what is the point of that setting I wonder? The docs say "Maximum velocity for this joint in machine units per second".
I'm pretty sure the math in my code above is ok, because if I change the sign of any part of it, after getting the joint follow error I can't even toggle the machine on anymore because there is another joint follow error immediately, over and over. With the code as shown above though, I can at least clear the error, turn the machine on again and keep running.
It's interesting that the joint max velocities do seem to be respected when not using the custom kinematics. For example with trivkins, I can crank the feed override up to a ridiculous value like 1000% and the maximum joint velocities are still respected.
So I'm guessing maybe the joint velocity enforcement has no knowledge of how the custom kinematics will affect speeds? But then, I thought that was the purpose of having a reverse kinematic transform...
// forward
pos->tran.x = joints[0] + joints[1];
// reverse
joints[0] = pos->tran.x - pos->tran.y;I thought [JOINT_x]MAX_VELOCITY was intended to enforce a limit at the individual joint level, so that regardless of what speed the operator commands, all joints would only operate within their capabilities. Was I wrong about that? If so, what is the point of that setting I wonder? The docs say "Maximum velocity for this joint in machine units per second".
I'm pretty sure the math in my code above is ok, because if I change the sign of any part of it, after getting the joint follow error I can't even toggle the machine on anymore because there is another joint follow error immediately, over and over. With the code as shown above though, I can at least clear the error, turn the machine on again and keep running.
It's interesting that the joint max velocities do seem to be respected when not using the custom kinematics. For example with trivkins, I can crank the feed override up to a ridiculous value like 1000% and the maximum joint velocities are still respected.
So I'm guessing maybe the joint velocity enforcement has no knowledge of how the custom kinematics will affect speeds? But then, I thought that was the purpose of having a reverse kinematic transform...
Last edit: 04 Jul 2023 15:10 by iforce2d. Reason: Every single time I post something on this forum the formatting gets mangled, wtf
Please Log in or Create an account to join the conversation.
04 Jul 2023 15:55 #274755
by andypugh
Replied by andypugh on topic Custom kinematics causes joint velocity limit violation
You have spotted a long-term problem with LinuxCNC and non-trivial kinematics.
The inverse kins can be used to spot _position_ violations, but it does not provide velocity information.
It could, of course. It provides an exact solution so the difference between the current joint positions and those calculated last servo period can give joint velocity, and the system could reduce the overall motion speed to keep the joints in range.
And keeping two sets of positions is enough to calculate acceleration, too.
It's on the list of things that I would love to do when I become independently wealthy and they invent 48 hour days.
It may not be a valid assumption that simply lowering the overall velocity will keep things in range in all cases. And what is the solution if a joint _deceleration_ is too high? Do we try reducing the overall deceleration, and risk over-shooting the position constraints?
My guess is that it isn't an easy fix, or at least not in the general case. But it could certainly be improved in a sub-set of cases.
The not-at-all-satisfactory answer that I was given when I first noticed this was to leave adequate headroom between the axis velocity limits and joint velocity limits. But that won't cover all cases, and is unsatifactory in all cases.
The inverse kins can be used to spot _position_ violations, but it does not provide velocity information.
It could, of course. It provides an exact solution so the difference between the current joint positions and those calculated last servo period can give joint velocity, and the system could reduce the overall motion speed to keep the joints in range.
And keeping two sets of positions is enough to calculate acceleration, too.
It's on the list of things that I would love to do when I become independently wealthy and they invent 48 hour days.
It may not be a valid assumption that simply lowering the overall velocity will keep things in range in all cases. And what is the solution if a joint _deceleration_ is too high? Do we try reducing the overall deceleration, and risk over-shooting the position constraints?
My guess is that it isn't an easy fix, or at least not in the general case. But it could certainly be improved in a sub-set of cases.
The not-at-all-satisfactory answer that I was given when I first noticed this was to leave adequate headroom between the axis velocity limits and joint velocity limits. But that won't cover all cases, and is unsatifactory in all cases.
The following user(s) said Thank You: tommylight
Please Log in or Create an account to join the conversation.
04 Jul 2023 18:09 #274767
by iforce2d
Replied by iforce2d on topic Custom kinematics causes joint velocity limit violation
Thanks Andy, I wondered if it might be something like that. It's certainly not a trivial problem to handle. In this case the transform is basic enough that I can just reduce the speed so that the diagonal case is achievable. My machine doesn't actually need to move that fast anyway, I was just exploring the limits while I build it.
Please Log in or Create an account to join the conversation.
Time to create page: 0.082 seconds