ROS LinuxCNC Link

Grotius wrote: One thing i really would like to have is a 3d arc motion path. I was working on this for many hours, but no succes so far.

There is a (very stale) Arbirtrary Arcs branch:

github.com/LinuxCNC/linuxcnc/tree/arbitrary-arc

As far as I am aware, as long as the centre point is specified, only 2 arcs are possible. Without a defined plane I am not sure how you determine clockwise or anticlockwise, I suspect that if all three of IJK were specified then you would have to declare that the shortest arc will always be chosen, regardless of G2 or G3 choice. (and a centre on a straight line between start and end, ie a 180 degree arc, is simply disallowed.

Grotius wrote: I did some work in the meantime.
1. Created a embedded linux install version for robots.
2. Created a advanched s-curve motion planner. We need this for nice moves.
3. Created a realtime path planner wich behaves like a video player with 1000 frames a second. :laugh: This is really a big thing.
4. Created a c++ halviewer. We have now full control. :blink:
5. Now creating the different robot, cnc machine teach in functions for 3d usage.

Where do you buy these 50-hour days?

Oh he a cyborg, no sleep, no eat, just do !

Hi,

Cyborg here again. :woohoo:

Without a defined plane I am not sure how you determine clockwise or anticlockwise,
That is defined by point order. I now have the 3p 3d arc ready for teach in.
Waypoints out ok.
We don't have to know arc centre. We can reflect a euler angle on the 3d arc if needed in the future.

Where do you buy these 50-hour days?
I changed some priorities in life a few years ago.
Most of the time, my time is related to an old Egyptian filosofi.

Now finishing the teach pendant.
Let me know if the button's, layout etc is ok. Then i can finish it.

The old display is done with some magic.

Impressive as usual but I have two questions:

1. Could you also implement rotations (ABC) in Cartesian and TCP modes using the opencascade kinematics?

2. Is there a way to switch between World (joint), Cartesian and TCP modes and execute moves in the respective modes in GCode?

Hi Arciera,

1. Could you also implement rotations (ABC) in Cartesian and TCP modes using the opencascade kinematics?
A common implementation is the roll pitch yaw, but i like the euler angles above roll pitch yaw. The euler angles rotates the tool center point inline with the world frame axis.

2. Is there a way to switch between World (joint), Cartesian and TCP modes and execute moves in the respective modes in GCode?
I remember this question. So far as i can see there is no need to switch between modes. All modes are active at the same time. Except moving inline with the tool oriantation. This could be a extra button to activate.

If you press X+, the robot moves along the x world frame. For y and z the same.
If you press Euler X+ the robot rotates about tool center point in direction of the world frame axis x.
If you press J0+ the robot rotates about axis 0.

You can do above sequences without selecting a mode. When pressing a button, the other values will be calculated.

Arciera, if you mean something else, maybe provide a scetch so i can understand your comments even more.

There will be coded a kdl kinematics improvement wich performs anti locking and optimalisation of robot joint positions.
Maybe 300-600 lines of code. 2 day's work.

You did not see it, but the teach in function is really cool. It show your teach in path in the old screen. In fact the old screen is a
modern implementation of 3d opencascade. This widget can also show gcode etc.

For performing a gcode you can input a mdi command. What we can do is make a gcode input accelerator dialog that pop's up when
pressing the mdi line.

We need as much as idea's now. In this stage edit's are quite easy.

Impressive as usual but I have two questions:
Thank you! Coding become's easyer when you have some experience. My next programming project, will be something completely different. It will be a linux virus scanner. It's quite complex, but i did some debootstraps, chrooting, distro's (debian kali) and system.d's
to get some insights. If this suceed's maybe it can prevent something big in the future. Or maybe not. :blink:

I think it might be useful to have a reference document like the docs for my Mitsubishi robot. Doesn't really matter what manufacturer but I have this handy: www.electrobit.ee/web/file_bank/Manuals/...ons-detailed_ENG.pdf

From the above Document Section 3.2.1:



You seem to have created an application that lets me JOG the robot in two different modes:

"World"- which would correspond to JOINT mode ie. jog the six rotational joints of the robot
"Cartesian"-mode with "Euler-TCP" which would correspond to "XYZ" in the document.

1. Would it be possible to add what in the above document is called "TOOL - Jog"?

2 . Then since in your application we can jog the robot and there seems to be a "Teach-in" function I presume that we can save the current point and orientation to a file then jog to a different postion and orientation. Is that data stored as individual Points using joint angles?

3. Now say I want to write a program in GCODE to have the robot perform a task. If I take the line "G0 X0 Y0 Z0 A0 B0 C0" what does my robot do? Does it move the Hand to the Origin of the world coordinate system or does it move the six joints to their respective 0°
position?

What display are you targeting the gui on? I ask because that's way too dense for a 10" display. UR uses a 13" display and its not as packed as that. I suggest you break the functionality into 3 or more parts(mdi, jog, prog for example) and use tabs to make it more usable for small touchscreens. Otherwise it looks quite nice. Just not very touch friendly.

Also it would be nice if you would upload your code to github directly and not in zips. I'm no going to download random zips off the internet just to see some code.

Hi Arciera,

1. Would it be possible to add what in the above document is called "TOOL - Jog"?
Yes, that is the extra button i talked about in previous post. This will jog the robot in tool direction.

2 . Then since in your application we can jog the robot and there seems to be a "Teach-in" function I presume that we can save the current point and orientation to a file then jog to a different postion and orientation. Is that data stored as individual Points using joint angles?
Hi the data files are processed like video files. It can stream data every 1ms to save realtime teach in moves. This program is already
finished and is super fast.

One feature is :
If you dress yourself stitched with encoders on your body joint's we would see a very nice data stream input.
This is an amazing feature of the software i develloped. The robot can run the motion path you just streamed in with your stitched encoders.
But normally you can teach in position's, these will be preprocessed to 1ms resolution files. Every file contains about 1000 data lines.
A robot program has many processed files, working dir is /tmp/
This program is tested ok. The program name is linux-buffer.
The data storage (point, joint angles, position etc) as complete as possible. This data storage belongs to another program that
uses the kdl lib and the advanched s-curve to produce motion paths. The linux-scurve is finished already. The kdl motion path's i have to do after the teach pendant is ready. This is quite easy because i know the in's and out's of kdl c++ already.

3. Now say I want to write a program in GCODE to have the robot perform a task. If I take the line "G0 X0 Y0 Z0 A0 B0 C0" what does my robot do? Does it move the Hand to the Origin of the world coordinate system or does it move the six joints to their respective 0°
position?
The first reaction of the robot will be moving to hiss but. somewhere in the floor. :lol:

The robot works in a workframe for this. The robot frame is "worldframe". The robot program can be attached to a "workframe".
It's not a must for teaching. But if you are a more experienced robot programmer, you know that program's teached in a "workframe"
can be shifted afterwards. This can be handy when something is out of position. Then the programmer does a "workframe" correction.
A workframe can be any place and any direction. Multiplying "workframes" or call it matrices is quite easy. Later on it will be clear
how to create and use them.

This is a matrix where the g-code is applied to. The matrix can be teached-in by 3 points.
Or can be set by 3 point values offline. Later on more about matrixes and multipying them.

Hi Roiki,
What display are you targeting the gui on?
I thought about a wireless touch screen. But size is not defined. For now it's a process of complete the gui buttons etc.
If the gui is completed, we can split it up info tab's and define the exact display sizes it needs. Maybe i make 2 versions.
If users give their proposal for screen sizes, i can bring this info into the project.

Also it would be nice if you would upload your code to github directly and not in zips. My current upload style is tar.gz only at the release pages. This works far more efficient for me. Github has to change. The first thing they have to change is increase filesize.

I'm no going to download random zips off the internet just to see some code.

Ok. me too. :blink:

Hi Arciera,We have to think about the teach in mode.

Teaching can be done quite quickly. I see now Velocity end is missing.

Can you think about the "Action" when teaching a point. With "Action" i mean what has to be done during the path.

1. Must the machine activate an output when at 15mm on the path? And what is the lenght of the output? -1 for no end?
2. Must there be a component pin be set at a certain path distance to activate a interval option for example?
3. Do we need a WaitFor input option? I think yes.
4. We can add a function input line at the "Teach-in" control that does the following :

Teach in function line:

This will do a halcompile behind the screen.
The robot will execute this during runtime.
This is a quite advanched solution. I can realize this option quite easy.


This stay's a nice picture. Teaching a 3dspline, 3darc. Yellow=waypoint.