Messages

Hello,

Ok I see, I can find another way of achieving my purpose, so that's fine for me ;)

Best,
Antoine

Hello,

If it is something in the graph I don't really need this feature.
If you look at my gh file, the thing I need is to have an interpolated orientation of the tool along the path.
It should be similar to setting $CIRC_TYPE = #PATH in a KRL file.

With your circ component, the interpolation exists but ends way before reaching the end point of the circular move.
Do you know how to achieve this? I haven't seen anything similar in your example files.

Best,
Antoine

Hello Johannes,

I try to play with circular moves, but I see a strange behavior in the simulation.
I attached an example, where you an see that the A6 axis behaves strangely, and is not correlated to what is written in the "analysis" graph.
The analysis graph tells that the A6 axis should not change, but you can see in the simulation that it changes during the first half of the circular move.

I don't know if I miss something or if there is a bug, but I need your help :)

Best,
Antoine

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

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

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 :)

Thank you for your consideraton :)

Antoine

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  :)

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

Hi Johannes,

I wanted to report you a bug: some Kuka|prc settings not saved in the .gh file.
For example, the status of "Simulate Without KRL Generation" or the "PTP acceleration" value.

This can be annoying, especially for the status of "Simulate Without KRL Generation" since I run multiple simulation in
a single gh file, then I am not garanteed that the right KRL code is generated.

My Kuka|prc version is 2018-04-27.

Best regards,
Antoine LUCAT

Yes that was the solution, I finally managed to convert my E6POS into E6AXIS due to the analysis component! (Find enclosed my solution)

Now it is working, I can pilot my robot directly from KukaPRC  8)

Hello,

For live communication with the robot purposes, I need to have all my movements as "PTP E6AXIS".
Yet, in my KukaPRC pipeline, I use a "PTP Movement" component with specified status & turn values.
Looking at the simulations, I am pretty sure that, for a given PTP E6POS+S/T, it exists an equivalent command of the form PTP E6AXIS.
Is there any possibility to do this conversion?

Regards,
antl