Move with Offset

The ability to add an offset to a waypoint


What is it?

The ability to easily add Positional offsets to waypoints in Polyscope.

Why is it needed?

The current options for offsetting positions is very confusing and difficult to implement.
the ability to simply offset positions in Polyscope would make it easier for the less confident / Non Script writers


There is already a few ways to offset most waypoints.

Select a waypoint and if available select Edit pose.

On the right you have (at least) 3 options to edit waypoints.

You can click the boxes circled in RED and type in the value you want into the dialog.

You can BRIEFLY click the boxes circled in GREEN and type in a value to add or subtract from the existing value (depending on whether you click + or -).

You can click longer on the BLUE boxes to increment the current position by .010" (Holding longer will move until you let up) You can use these features for all axis, rotations and joints.

In some cases the Edit pose button is not there and I don’t know why. However, you can still adjust existing waypoints by using the Set Waypoint button. The biggest different I’ve seen is that for the method using the Edit pose button you do not have to be at the current waypoint. Otherwise you have to move to the waypoint before changing it.

Move to the waypoint in question, then click Set waypoint. From there you can click one of the Tool Position boxes on the top right and it will open the same window that I posted above for Edit pose.

Maybe someone else knows why most waypoints have an Edit pose button and some don’t.

Yes I have used all of the suggestions you have shown,
the first is specifically for palettizing, not really what I was trying to suggest.

the second and third are more of an editing positions of a final position.

What I was trying to suggest was for approach positions based on a final position but with a given offset, (Instead of teaching approach point, final point, away point) you could have (final point with offset1, final point, final point with offset2).

It would be even better if you could assign variable values for each offset approach so it could be dynamic in your program.

to achieve that at the moment would require some level of script that some people are not confident in writing.
Isn’t the point to make programming easier for all?

1 Like

I think you missed the “easily” part! :slight_smile:

Currently the only way to deal efficiently with offset (translation and rotation) is with variables and script with pos_trans().

The ability to define a new waypoint from an existing one and apply to it an offset would be welcome.


I find the easiest way is to use the feature functionality…

then you can make all you waypoints dependent on this feature in the move node

now if you move this feature in the installation tab, using the edit button on the first picture every waypoint moves with this feature.
effectively creating an offset.

Yes you could do that,
but then you have to change the plane between every move

eg adjust plane for near position
move to near position

eg adjust plane back to original
move to work position

eg adjust plane for away position
move to away position

now that’s a pain in the A**!

Couldn’t you simply add more planes?
if you start by creating all your moves based on the Base feature.
you would “simply” need a plane for each “position”, that is offseted with respect to the base.
which you then could easily switch between using the feature dropdown

Ok I’ve got 12 stations x 3 planes each

that’s 36 planes I’ve got to teach just to do a couple of offsets for each work position

I’m tired just thinking about what a pain in the A** that would be! :rofl:

How is creating creating 36 Planes different then creating 36 “offset nodes”?

you create two offset nodes and just reuse them every time

the offset is applied to the position!

You can do the exact same things for the planes.
AKA if you can “copy paste” an offset node it should be complety posible to resuse the plane with a similar offset.

Do try it out on a real robot I think the result will surprise you.

You could try using Relative Waypoints

Yeah so I don’t think this is that hard to implement in a CAP (since the script to do it is very easy). I can throw it together for you sometime when I’m slow at work. How do you want it to work? I’m imagining a parent node, very similar to the Force template, and it just offsets all the child nodes inside it by whatever you type in. That how you’re picturing it?

I haven’t worked with accessing built-in nodes like Waypoints, so I might end up hitting a brick wall there, but who knows.

So if I understand you correctly you would like to be able to do something like this (see image) where the reference feature of your waypoint is another waypoint?

Note this is just me being creative with names of features this is not actually possible at the moment.

@jjbe that seems like a good start. Only potential downside/room for improvement would be that implemented that way, you would not be able to shift the waypoint with respect to a DIFFERENT reference frame. Presumably you’d be locked into either shifting with respect to the Base frame, or whatever frame the Waypoint was saved to.

This is exactly how I envisioned it working.

FYI I’m from a Fanuc background
so implementing an offset is SO easy

Simply create a Position register as the waypoint (taught position) then move to waypoint with either offset and, or TCP offset using another position register with simple values in X,Y,Z,W,P,R of J1,J2,J3,J4,J5,J6.

I know it might be scary for non-scripters but for now, a script oneliner which I believe does what you want looks something like this for e-series:

movel(pose_trans(Waypoint_1_p, p[0,0,0.1,0,0,0]))

I don’t know if it helps you?

Thanks for the info
That is how I’ve been doing it.

I just wanted to convey that it’s not the easiest for non script writers. Which I said in my very first post on the subject.

UR go on about how easy it is to get a cobot programmed and into production.

But some of the fundamental tools available on (supposedly difficult to program industrial robots) seem lacking.

The whole point of the wish list is exactly that. Suggest things to enhance the programing experience for all.