Exceeding JOINT_N.MAX_VELOCITY limits with genserkins kinematics

Hi Rod,

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...

Unfortunately I don't think that joint limits are honoured in non-trivial kinematics in World mode.
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.

Some additional notes:

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*

Hi Dewey, hi Andy,
thank you both for your answer. This clarifies the behaviour of my setup I'm glad, I didn't mess up something with my configuration

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.

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.

I'll try your suggestion, Andy, on monitor the joint velocity via hal component. seems to be a plausible but dirty workaround If I have a more or less working solution, I'll let you know

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.

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 deadlock

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

Cheers and thank you!

3radfahrer wrote: 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.

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.

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.