Exceeding JOINT_N.MAX_VELOCITY limits with genserkins kinematics

More
07 Jan 2021 20:37 - 07 Jan 2021 20:41 #194411 by 3radfahrer
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...
Last edit: 07 Jan 2021 20:41 by 3radfahrer.

Please Log in or Create an account to join the conversation.

More
08 Jan 2021 14:41 #194496 by andypugh
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.
The following user(s) said Thank You: 3radfahrer

Please Log in or Create an account to join the conversation.

More
08 Jan 2021 15:16 - 08 Jan 2021 15:20 #194498 by dgarrett
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*
Last edit: 08 Jan 2021 15:20 by dgarrett. Reason: 739
The following user(s) said Thank You: rodw, 3radfahrer

Please Log in or Create an account to join the conversation.

More
08 Jan 2021 23:09 #194550 by 3radfahrer
Hi Dewey, hi Andy,
thank you both for your answer. This clarifies the behaviour of my setup :D 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 :D 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!

Please Log in or Create an account to join the conversation.

More
10 Jan 2021 19:28 - 10 Jan 2021 19:28 #194757 by andypugh

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.
Last edit: 10 Jan 2021 19:28 by andypugh.

Please Log in or Create an account to join the conversation.

More
04 Jan 2022 04:43 #230715 by ExcessiveO

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.

Please Log in or Create an account to join the conversation.

More
04 Jan 2022 15:45 #230776 by Aciera
If I recall correctly, genserkins uses the jacobi matrix in it's calculations and the determinant of the jacobi approaches zero if the robot nears a singularity. My Mitsubishi controllers will decrease the joint velocity progressively the closer the robot is moved towards a singular joint.
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.

Time to create page: 0.078 seconds
Powered by Kunena Forum