Synchronisation of multiple DoFs / Control of synchronous movements
21 Jul 2022 15:49 #247955
by gftrobots
Dear All,
Can you point me to some documentation (or the source code), that describes control of synchronous movements?
I would like to understand the detailed implementation of the trajectory following component in a n-axis set-up (e.g. 5 axis) and how path constraints are solved (e.g. look ahead solver).
A sample scenario could be:
- One axis is not able to follow with speed of the other axes
- How is the synchronous movement controlled
Cheers, Mirko
Can you point me to some documentation (or the source code), that describes control of synchronous movements?
I would like to understand the detailed implementation of the trajectory following component in a n-axis set-up (e.g. 5 axis) and how path constraints are solved (e.g. look ahead solver).
A sample scenario could be:
- One axis is not able to follow with speed of the other axes
- How is the synchronous movement controlled
Cheers, Mirko
Please Log in or Create an account to join the conversation.
22 Jul 2022 09:06 #248016
by andypugh
Replied by andypugh on topic Synchronisation of multiple DoFs / Control of synchronous movements
At the moment I don't think that joint constraints _are_ complied with in the case of complex kinematics.
Axis constraints are, but I don't think that was your real question?
The difficulty is that the 9-axis planner works well in XYZ cartesian space, but it is not particularly clear what velocity and acceleration limits even mean in 9-axis space.
On top of that there is the kinematics module, which is used to convert the trajectory in cartesian space in to joint positions, but this comes _after_ the trajectory limitation has been applied. And is a simple positional mapping.
It is a matter that I have given some thought to, and what I think _could_ work is.
1) Store the previous two "poses" (ie joint positions")
2) Use (P(now) - P(now -1)) / dt to calculate the velocity of each joint now
3) Use (P(now) - P (now -1)) - (P(now -1) - P(now -2)) / dt2 to calculate the acceleration of each joint.
If either is at the limit. reduce the global feed override and recalculate. Repeat until the problem joint is within limits.
The numerical differentiation should be exact, this is all inside the control with no reference to hardware.
It would be better to consider the rate at which the limit is being approached, and aim to hit it asymptotically, rather than "panic" at the limit. But the latter would still be an improvement.
LinuxCNC suffers from being initially a 3-axis cartesian machine tool controller. Certain assumptions are baked-in and it takes great effort to extract them. we did (at 2.8) remove the assumption of a 1:1 mapping between joints and axes, though. so it can be done.
Axis constraints are, but I don't think that was your real question?
The difficulty is that the 9-axis planner works well in XYZ cartesian space, but it is not particularly clear what velocity and acceleration limits even mean in 9-axis space.
On top of that there is the kinematics module, which is used to convert the trajectory in cartesian space in to joint positions, but this comes _after_ the trajectory limitation has been applied. And is a simple positional mapping.
It is a matter that I have given some thought to, and what I think _could_ work is.
1) Store the previous two "poses" (ie joint positions")
2) Use (P(now) - P(now -1)) / dt to calculate the velocity of each joint now
3) Use (P(now) - P (now -1)) - (P(now -1) - P(now -2)) / dt2 to calculate the acceleration of each joint.
If either is at the limit. reduce the global feed override and recalculate. Repeat until the problem joint is within limits.
The numerical differentiation should be exact, this is all inside the control with no reference to hardware.
It would be better to consider the rate at which the limit is being approached, and aim to hit it asymptotically, rather than "panic" at the limit. But the latter would still be an improvement.
LinuxCNC suffers from being initially a 3-axis cartesian machine tool controller. Certain assumptions are baked-in and it takes great effort to extract them. we did (at 2.8) remove the assumption of a 1:1 mapping between joints and axes, though. so it can be done.
Please Log in or Create an account to join the conversation.
Time to create page: 0.186 seconds