general questions about 6dof system

LinuxCNC can control a robot, just not sure how close to a say Kuka that would be.
It can do 9 axis but each of those axis can also have more than one joint or motor per axis, i think 8 but not sure.
Do a search for scara and puma there are some robots working under LinuxCNC control on this forum, there are also simulations of them included with LinuxCNC, so download the ISO from the downloads in the main page and write it to a USB using win32diskimager, boot the PC from it and test as much as you like, it will not delete the hard drive as a Live session. Oh and it also has 3D animation of those robots and what they are actually doing when moving them.

I have a 6 axis industrial robot that is controlled by LCNC:

forum.linuxcnc.org/10-advanced-configura...nfig-with-simulation

It works but with severe limitations. I would say that it can handle simple tasks like materials handling. But for anything that needs the tool to follow exact trajectories at constant speeds (as in 3D milling) I think we are still a long way from a usable solution.
If I were to build a 3D milling machine I would tend to prefer a more conventional kinematics with cartesian XYZ and rotary AB. One of the main reasons being the availability of CAD/CAM systems to create GCODE that can be used in LCNC.

Aciera wrote:

It works but with severe limitations..

What are the limitations? With the correct kinematics a LinuxCNC robot should simply run G-code in XYZABC space.
It is certainly _meant_ to work that way.

What are the limitations? With the correct kinematics a LinuxCNC robot should simply run G-code in XYZABC space.
It is certainly _meant_ to work that way.

Unfortunately it's not quite as simple as that when it comes to serial manipulators.
These are limitations that I am certain about:
1. Limitation: We need to be able to switch kinematics from inside gcode and we cannot do that in regular LinuxCNC-master. We need to build Dewey Garrett's 'switch-kins-branch' since his work was not allowed to be merged with master. So we are already out on a limb. (This by the way was developed for the use in 5-axis machining so it's by no means limited to serial manipulators)
Why do we need to be able to switch kinematics?
Because due to the mathematical model used to calculate the joint positions for a requested position and orientation in cartesian space (ie the inverse kinematic) there are discontinuities in the results (gimbal lock, singularities) that the physical robot simply cannot execute. This is NOT limited to LinuxCNC it plagues ALL robot contollers and manufacturers have spent millions trying to get a handle on this. So what this means is that we cannot use a robot properly just by using the correct kinematics because we KNOW that the inverse kinematics WILL fail in certain areas of the work envelope.
Because the calculation of the position and orientation for a given set of joint angles (ie the forward kinematic) is not plagued by such problems we can always control the robot by commanding joint angles directly and the kinematic model will accurately calculate the cartesian values. But this means that we need to be able to switch from our (non-trivial) kinematic that needs to fit our robot model to the trivial kinematics that maps the XYZABC of our gcode to the joints. (Note that velocity and acceleration limit also need to be changed when switching the kinematics, but this can be handled in HAL)
2. Limitation: The Kinematic (genserkins) used in LinuxCNC
I found that the inverse kinematic model in genserkins is less robust that what is available in other software like ROS or RoboDK. This means that, even if you write a post processor to translate the output of a more powerful 3rd party software the generated GCODE will likely not work because genserkins inverse kinematic model fails.
3. Limitation: The motion planner in LinuxCNC knows nothing about the kinematics used.
Because the motion planner does not take the kinematics into account there can be no look ahead in the gcode to check for limit violations. It should however stop code execution with an error when reaching a line that would exceed a Joint limit.
4. Limitation: There is no jerk control in LinuxCNC
For a robot and particularly a larger one the lack of jerk limitation will limit your acceleration.


These are limitations that I'm not entirely sure about as I don't have enough insight into LinuxCNC source code:
- As I understand it the new motion planner will fall back to one line look ahead for anything other than XYZ moves.
- Not sure if LinuxCNC really handles the definitions of joints as LINEAR or ANGULAR correctly as it seems that linear speeds always apply to XYZ and angular to ABC regardless of the definition in the INI.

Roiki wrote:

You're about right. Linuxcnc currently has no inverse kinematics solver for robots

It has several kinematics modules that solve forward and reverse kins. Genserkins might be a bit brittle, but it exists. I think that Pumakins is less brittle, but less adapable, and there is Scarakins too, which I think "just works".

theres no radian or quarternion support.

posemath contains quaternion support
github.com/LinuxCNC/linuxcnc/blob/2e75b0.../posemath/posemath.h

And TCP _is_ supported.