Convert spatial coordinates into specific robot programming language

Quote from Askic

I hope you understand my question.

Not really.

"Path planning" normally is done in the robot system. But there is also a kind of 'path planning' that the robot user/programer has to do: set some positions the robot has to move by, so that he can do his job and no collisions occur.

The first one (done in the robot system) is calculating the robot axis positions during the movement to the various positions 'planned' by the robot user (as there aren't only linear movements, but also circles, splines ..) .

Quote from Askic

how to enter this data to a real world robot?

That depends on the robot system. No universal answer to that question.

OK, if you make path planning in another software, somes things have to be clear:

1. the coordinate origin is different with each robot manufacturer: KUKA and ABB has it on Axis 1 center of base. FANUC has it on axis 2 in 0° position of axis 1
2. the path planning is always structured with point to point, linear and circular movements
3. then each manufacturer has different flyby zones, sometimes speed dependend

If you figured that stuff out you can generate movement instructions based on your path planning. This has to be done in each robot manufacturers own language. ABB has RAPID, FANUC has KAREL, KUKA has KRL with inline forms and so on.

Also don't forget orientations. I see in your path only points but no orientations.

An example point for ABB looks like this:

CONST robtarget pExample:=[[1648.54,-1438.01,1106.93],[0.709321,0.704869,-0.00352078,0.00333264],[-1,-2,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];

with firsts bracket [x,y,z] as translation

and second bracket [q1,q2,q3,q4] as rotation by quaternions

and third bracket the configuration[c1,c2,c3,c4] because robots can reach a point in different poses (multiple pose solutions possible)

and fourth bracket the external axis [e1,e2,e3,e4,e5,e6]

As others have stated, every robot brand uses a different "notation" for representing a 6DOF (XYZ and Rx, Ry, Rz) point in space. The free version of RoboDK is pretty good for dabbling in this. Most robots use a specific Euler rotation, although ABBs use Quaternions.

So, for any 3rd-party software generating paths for robots, a postprocessor unique to that robot is required. This is similar to generating G-Code for CNC machines from CAD/CAM software.

Now, if we limit the discussion to 3DOF (XYZ), it gets simpler -- you simply have to ensure your reference frames are aligned between the software and reality, and your units are correct. It's not hard to create a simplistic script to convert a series of XYZ points into a string of robot commands. But since one of the reasons for using a robot is to take advantage of its 6DOF flexibility, such simple scripts are of very limited utility.

This gets more complex in execution, because while the software can generate a series of points, each robot decides to a degree on its own how to move between those points. The output of your postprocessor can (and should) include parameters for velocity, approximation, acceleration, etc, but the robot still gets a vote. The simplest example is speed: if you command the robot to move from Point A to Point B at 2m/s, but the robot cannot physically achieve that speed, it'll simply do the best it can.

Quote from SkyeFire

if you command the robot to move from Point A to Point B at 2m/s, but the robot cannot physically achieve that speed, it'll simply do the best it can.

Have you worked with Motoman robots before? My experience with "excessive segment" errors is somewhat contrary to that statement. If I am wrong, sorry. I have no particular love for those robots.

Quote from Lemster68

Have you worked with Motoman robots before? My experience with "excessive segment" errors is somewhat contrary to that statement. If I am wrong, sorry. I have no particular love for those robots.

I haven't had the "pleasure" , and user testimonials like this reassure me that I'm not missing anything.

What you can do is pick an offline programming (OLP) software, brand specific or brand agnostic, feed in the data from your path planning SW and let the OLP confirm if the path is feasible from a physical stand point (reach, singularities, joint limits) and generate the actual robot program in a format "understandable" for the controller.

You will have plenty of other "details" to worry about, you can skip the kinematic and post-processing aspect of it for a cost much lower than the time it would take to develop such tool yourself.
But obviously, if your time has no "value" (it's a hobby let's say), nothing is impossible and you can create such tool.

Jeremy

if you know what robot joint positions are (and you know transforms of each joint) you can calculate resulting position at the end of arm. this is called forward transform (and it is more straight forward).

to do the opposite, you need to use inverse kinematic transform. with this you can calculate joint angles when position is known. again, this requires knowing robot architecture because it has direct effect on all transforms.

KSS has suitably named functions for this: forward() and inverse()

Quote from SkyeFire

... Now, if we limit the discussion to 3DOF (XYZ), it gets simpler -- you simply have to ensure your reference frames are aligned between the software and reality, and your units are correct. It's not hard to create a simplistic script to convert a series of XYZ points into a string of robot commands....

The robot reference frames are stored in base_data[x], where x is the number of base frame. So you have to align one of the base frames to your path planning frame and are done.

The same with the tool frame, they are stored in the variable tool_data[x].

But you always need an orientation for every position, you can set it to a constant value.

Activating a tool, or base frame is done by the command

Bas(#base, x)

Bas(#tool, x), where x is the number of the tool or base.