Programmatical robot start position

[antl]

Hi Johannes,

Is their a solution to programmatically set the START position of a robot?

For the moment I have to change it manually in the Kuka|prc settings window, but it would be really helpful to be able to send it as a variable in order to change it on-the-fly.

My use case is that I have a pipeline for searching collision-free trajectories, and being able to change the start position would highly increase my search space while not increasing the computation time. Indeed, I could add a movement from a false START position to a custom one (adding 1 PTP movement), then change the custom one as any other variable. However this will increase a lot the computation cost of collision checking, whereas I know that I can reach my different START positions safely (through custom sub-functions manually written in my KUKA controller).

Best regards,
Antoine LUCAT

[Johannes @ Robots in Architecture]

Hello Antoine,

To get rid of the start position in the code, you can go to Settings/Advanced/Code and then untick the "Use robot-internal code pattern". Then simply get delete the STARTAXPOS line.
It will still show up in the simulation, but not in the code.
Does that help?

Best,
Johannes

[antl]

Thanks for the prompt response.

Unfortunately it does not solve my issue, since I need the START position to change in the simulation itself.
Have you any solution? Or maybe could you consider the possibility to add such a feature in a next release?
This would be very helpful for quick trajectory optimization  :)

[Johannes @ Robots in Architecture]

Hello,

For a reliable simulation the KUKA needs a clearly defined movement at the beginning, so I don't want to change it.
That being said, what stops you from adding your own axis movement at the beginning? Going from axis movement to axis movement is clearly defined, so even if your simulation shows one additional movement at the beginning, it won't change the rest of your simulation if you add your own start position afterwards. Just the time will be slightly off, but that is an approximation in any case. You can also simply subtract the time for the first movement from the total, if that is a factor for your optimization.

Best,
Johannes

[antl]

If I go into this direction, I run into a new problem.

But at first let me explain you what I try to do.
I have a robot that lives freely in a cell where I absolutely need to avoid collisions.
The target positions P1, P2, P3, ... Pn, ... of the robot are known on-the-fly, I cannot precompute them.
So my moves are : HOME->P1->HOME, then HOME->P2->HOME, ...
The objective of Kuka|prc is then to find a possibility to safety do HOME->Pn, as I know that Pn->HOME will then be safe too.
To do so, I use some degrees of freedom I have (status, rotation around tool X axis..) to cleverly explore the possibilities then retain the safe ones.

The problem is that when I have a fixed START position, some point P get unreachable without collision. But if I pre-flip the robot in another start configuration (a position here called Fm), the move becomes possible.
That is why I want the following moves: HOME->flip_to_Fm()->Pn->deflip_from_Fm()->HOME
These functions "flip" and "deflip" can be long and complicated, yet predefined directly in the Robot controller: I just need to add sub-program calls in the KRL code.
To be efficient, Kuka|prc should just know that going from HOME to Fm is safe.

Ideally, the problem becomes:
From a simulated move HOME->Fm->Pn, how to disable collision checking during the part HOME->Fm, and allow it for Fm->Pn?
Indeed, collision checking is very costly, then I don't want to check HOME->Fm :)

[Johannes @ Robots in Architecture]

Hmm.. I understand your challenge, but I really don't want to implement that option, as it's bound to confuse people which may lead to expensive mistakes.
Personally I'm tending towards a hidden option, e.g. if you set the E4 of the start-position to -48123 it will ignore it. Would that work for you?
Best,
Johannes

[Johannes @ Robots in Architecture]

Hello,

I've sent you an eMail with a special release. It does not contain an installer, simply overwrite the files.
If you now enter "NaN" instead of the default "5" as the A01 value of the startposition it will ignore the startposition.
Take care to provide your own axis value as the first command, otherwise many subsequent steps will fail.
In the file output, you still need to delete the [STARTAXPOS] line, otherwise it will show up in the KRL output.

Please let me know if it works, it will then be included in the next general release!
Best,
Johannes

[antl]

Hello Johannes,

Thank you so much for providing me this incredibly useful feature!

Then I tried it, replacing START A01 by NaN.
It displays correctly (as long as I don't set simulation slider to 0), but I cannot exploit the outputs of the Kuka|prc Core component.
You can find enclosed a minimal example showing the problem:

I set two PTP E6AXIS commands, my robot, then feed Kuka|prc Core with them.

The component gives the two following warnings (turning red):
1. The toolpaths contains collisions or unreachable positions. Proceed with care.
2. Solution exception:Object reference not set to an instance of an object.

I guess that the second warning prevents the component from giving any output, that are needed for further processing.
(In my minimal code, the analysis component is used to check the reachability of the trajectory)

Of course, when I turn back A01 to 5, no warning shows up.


Best regards,
Antoine

[Johannes @ Robots in Architecture]

Hello,

I slimmed the file down to two axis movements and in my case it seems to work fine.
Can you make sure that you installed the special version I sent you? Maybe Rhino was open in the background and prevented you from overwriting the file?

Best,
Johannes

[antl]

For some reason the KukaPRC version used by Rhino was still the previous one..
So, to be sure, I just copied again the custom version you sent to me into C:\Users\USERNAME\AppData\Roaming\Grasshopper\Libraries, deleting the former files (which were the from the very last available update).
However, with the custom version the Kuka|prc tab did not even shows up, and launching the .gha files gave me errors.

It was finally because I had to "unblock" your files, which is security provided by Windows when you download a file from an unknown source.

Now everything works like a charm :)
I'll come back to you if I find anything.


Thank you again for the version,

Antoine

[Johannes @ Robots in Architecture]

Hello Antoine,

We usually digitally sign our releases, which is why you don't get the "unblock" problem. In your case it was an "unofficial" release, so that's why the file wasn't signed.

Happy to hear that it works!

All the best,
Johannes