- Configuring LinuxCNC
- Basic Configuration
- Exceeding JOINT_N.MAX_VELOCITY limits with genserkins kinematics
Exceeding JOINT_N.MAX_VELOCITY limits with genserkins kinematics
- 3radfahrer
- Offline
- New Member
-
- Posts: 18
- Thank you received: 5
yes, the individual Joints violate their limits, even if I am only moving along one axis. Of course, the axis is then exactly on its limit and the cutter driving with max_velocity of this axis, but the joints are way over their limits...
Please Log in or Create an account to join the conversation.
This is a long-standing issue. The (unsatisfactory) workaround is to set the Axis limits artificially low, ie for worst-case geometry.
I think that the problem is that the trajectory planner, where the limit checking takes place, happens in cartesian space.
It's actually a harder problem than it might appear, as the same G-code could be running anywhere in the machine envelope so there isn't a simple mapping.
I have contemplated schemes where the kinematics is called twice at small distances along the path to get a finite differential to calculate speed from (or 3 times to get acceleration too)
There is probably scope for a clunky fix in HAL. A component could monitor joint velocity in real-time and adjust the adaptive feed pin to slow the whole motion.
Please Log in or Create an account to join the conversation.
In world mode (e.g.,running gcode by mdi or program),
joint *positional* following errors are detected by the
motion module and will abort motion.
github.com/LinuxCNC/linuxcnc/blob/master...otion/control.c#L412
github.com/LinuxCNC/linuxcnc/blob/master...otion/control.c#L739
However, joint dynamic errors (velocity, acceleration) are not
detected in world mode because the trajectory planner has no
knowledge of joints -- it just passes planned Cartesian motion to
the installed kinematics module's inverse kinematics function.
One could write a specific kinematics module to detect dynamic
violations and do something with them but what to do is a
a remaining problem.
See also:
github.com/LinuxCNC/linuxcnc/issues/97
As noted, "obeying joint constraints (velocity and acceleration)
while running in Cartesian mode is a major area for
future work"
emphasis on *major*
Please Log in or Create an account to join the conversation.
- 3radfahrer
- Offline
- New Member
-
- Posts: 18
- Thank you received: 5
thank you both for your answer. This clarifies the behaviour of my setup
![:D :D](/media/kunena/emoticons/laughing.png)
It's actually a harder problem than it might appear, as the same G-code could be running anywhere in the machine envelope so there isn't a simple mapping.
Of course, a simple mapping is not possible. But I think, the jacobian of the kinematics and its inverse for the actual axis position, which could either be calculated within the kinematics or somewhere outside (as you described by calling the kinematics multiple times) represents the "mapping" and could be used to slow the trajectoryplanner down.
But obviously this is not (yet) implemented in the trajectoryplanner.
I'll try your suggestion, Andy, on monitor the joint velocity via hal component. seems to be a plausible but dirty workaroundThere is probably scope for a clunky fix in HAL. A component could monitor joint velocity in real-time and adjust the adaptive feed pin to slow the whole motion.
![:D :D](/media/kunena/emoticons/laughing.png)
![;-) ;-)](/media/kunena/emoticons/wink.png)
The actual joint-speed and a possible violation of its limits could for sure be detected within the kinematics. But as long as there is no interface to slow the trajectoryplanner down, this information would lead into a deadlockOne could write a specific kinematics module to detect dynamic
violations and do something with them but what to do is a
a remaining problem.
![:( :(](/media/kunena/emoticons/sad.png)
Dewey: since the post you cited is from 2016, do you know what the current status on this topic is? or is it still marked as "major area for future work"? Is there an active branch that handles this issue that can be checked out for testing? If there is a way to contribute on this topic, please let me know
![;-) ;-)](/media/kunena/emoticons/wink.png)
Cheers and thank you!
Please Log in or Create an account to join the conversation.
Of course, a simple mapping is not possible. But I think, the jacobian of the kinematics and its inverse for the actual axis position, which could either be calculated within the kinematics or somewhere outside
As I understand it (I learned about the Jacobian at undergraduate level, and then have never had any reason to use one again, despite a career in engineering) the Jacobian is only relevant to situations where the kinematics is computed by matrix maths.
We have some kins that use matrices, genserkins for example, but many do not, using either simple trigonometry or straight-through mapping. Hence my suggestion to do it numerically with repeated calls at small offsets from the current posiiton.
And bear in mind that the inverse kins of many systems that do use matrices is solved by successive approximation.
Please Log in or Create an account to join the conversation.
- ExcessiveO
- Offline
- Senior Member
-
- Posts: 54
- Thank you received: 5
I'm having the same issue with the joint speed being exceeded. I tried using the adaptive feed pin and it sort of helps but not in the cases where you really need it to. When the robot approaches a singularity, the joint speed increases exponentially, so much so that even if the adaptive feed is set to zero, the time it takes to linearly decelerate is enough that the joint will still way overspeed. For it to truly be fixed a good amount of work needs to go into linking the cartesian and joint kins.There is probably scope for a clunky fix in HAL. A component could monitor joint velocity in real-time and adjust the adaptive feed pin to slow the whole motion.
Please Log in or Create an account to join the conversation.
So maybe if genserkins could calculate and output the numerical value of the determinant of the jacobi matrix that could then be used to control the adaptive feed pin.
Unfortunately I'm no good at C and the source code is somewhat sparsely commented.
Please Log in or Create an account to join the conversation.
- Configuring LinuxCNC
- Basic Configuration
- Exceeding JOINT_N.MAX_VELOCITY limits with genserkins kinematics