Messages

Hmm so I've now managed to get it to update on the "Cur. tool/base" window, by either using $ACT_BASE = 3 or BAS (#BASE, 3), but this hasn't fixed the issue. When looking at the "Display" -> "Actual position" window, the coordinates don't actually change despite the base changing. For example, if I use the "Cur. tool/base" window to change the base manually, then the coordinates switch from world to coordinates in the base system.

Any thoughts?

Hi Johannes,

I'm having a go at translating the commands into the coordinates of the base system.

The way I want to do this essentially involves switching bases after the first PTP move is complete, to then switch to the kinematically linked base.

The issue is that currently I think the way that the base is initialised means that it does not switch from Base #2 to Base #3.



So here, I tried two methods. I tried just copying the FDAT_ACT command on line 18 down to line 33 and then change "BASE_NO 2" to "BASE_NO 3". I also tried just inserting the $BASE = BASE_DATA[3]. Both of these did not change the "Base selection" in the top right at all, and if I look at DISPLAY>VARIABLE>SINGLE to monitor the $BASE variable, this does change, but just not in the "Cur. tool/base window" in the top right...

Any thoughts how to change the Base?

Best,

Alex

Ah okay that all makes sense re: floats and integers and transforming the positions. I'll give that a go.

Also very exciting that PRC is being fully rebuilt! In what sort of timeline will that happen?

If you ever want to collaborate more closely on testing Roboteam options and functionality in the future we'd be more than happy to lend a hand, also if you're visiting London and want access to our Roboteam cell then we'd also be more than happy to facilitate!

Best,

Alex

[And now the important bit... maybe:]

Hi Johannes,

So I've had a go at mocking up the robots working together with MotionSync and that's working fine if a little wobbly but I found it a bit too hard to figure out getting the output of one robot to then recalculate the base dynamically of the second robot.

So here are some of my thoughts, but they might be a little scattered.

You can right-click the Core component to set the base dynamically.
It's definitely possible to mock something like this up, however you might have problems with the normalized simulation slider. Because when you change the base, the toolpath changes and through that the time changes.

One issue with what you describe here is updating the base will surely regenerate the KRL code as well, so it would be hard to get a continuous program out of an approach like this.

Another issue is that surely there is a piece of information missing there, since if the only way to change the robot base is by updating the CORE component, then that also loses the information of where the second robot is located with respect to the first, i.e. the robot root.

The analysis output block also isn't fantastic for this because the planes output isn't directly linked to the number of input commands. I think this is primarily because it outputs planes for the movement from the home position to the first command. It makes the planes output useful for making a trail for the toolpath or something but its very hard to match up the output of one analysis block to the input of another Core component.

It would be useful if the robot geometry output or the analysis output included an axis planes output, so that for each cartesian target you could see what the joint values and locations are, but mainly just so that there is a plane outputted at the TCP on the geometry.

And now the important bit... maybe:

To me the easiest way to get this working is to just use the kinematically linked base on the controller so that essentially robot #2 is working in the coordinate system of the base/frame of robot #1. I'm working in the context of a really simple plywood drawing board attached directly to the flange with bolts through the drawing surface, and the resulting base definition taken from calibrating on the controller is:

So the resultant XYZABC KRL code outputted for robot #2 would all be based around the World XY in Rhino, and the robot would just translate/orient that to the base/frame of robot #1, in terms of running on the robot, and then in terms of simulating on PRC then it would just be orienting them to the TCP plane that I discuss in the previous paragraph.

But in the mean time, I can't think of a way of getting robot #2 to output KRL code based around the origin... I think this is because the only way to define the robot root is by using a base, but arguably there should be a way to define the robot root AND define a frame/base.

Not sure how clear I've made myself here...

Hi Karl,

I was looking at your Patreon and can't see this tutorial immediately in the preview. Is it still available there in the full post archive?

Best,

Alex

Hi Johannes,

Sorry for the late reply. Unfortunately we do not support the RoboTeam function where the other robot acts like a synchronized, external kinematic system.
It would be possible to integrate it with a reasonable effort, but we have never needed it so far.

Just as a final point on this thread, I would like to register our interest in this becoming a feature at some point!

Do you have any recommendations for mocking this functionality up i.e. a dynamic/moving base? I was thinking I could just take the planes from the Analysis Output of one robot and then Orient the planes for the other robot accordingly?

How is the "Frame" component supposed to be used? The tooltip says "e.g. for setting the base system without going through the GUI", but I cannot figure out where that should be plugged in to function?

Best,

Alex

Hi Johannes,

Nice, that fixed it, I must've clicked it when playing around and forgot to unclick it!

Another quick question, why is the first command provided to the Core component converted to a PTP move when it is provided as a LIN move? Is there a way to undo this?

Best,

Alex

Hi Johannes,

I've just got to the stage in Roboteam of trying to run my first program. I've got the robots to jog in a kinematically linked way and they correctly follow each other, and my calibrated tools are both on tool #1.

I have set up the grasshopper file as as attached below. The KR60 (master) robot, with its root at 0,0,0 is running the program no problem, but then the KR30 (slave) robot with the custom robot root is not able to run the program. When it begins to run the home position fold, the robot returns the error of "Array index inadmissible", which I can only assume is in relation to the Base or Tool numbers.

Any ideas what could be the issue?

Best,

Alex

Apologies, I clearly didn't look hard enough and have now found this thread.

The second robot there is giving an error of "1. An error occurred while synching the robots' commands. Please check if RoboTeam is setup correctly and if both robots use the same number of synchronization commands."

Furthermore, I am unsure of how to change the root points of the robots?

Sorry for the late reply. Unfortunately we do not support the RoboTeam function where the other robot acts like a synchronized, external kinematic system.

Also, in the discussion, this is mentioned. Could you please give an example of the limitation of this? I.e. is Video 2 not possible in that thread?

Apologies if I've just been unsuccessful in finding an existing topic, but I was wondering if there was a tutorial or example file for making two robots work together in Roboteam using KUKA|prc?

I was wondering if anyone had had any experience in trying to output a digital signal if the robot is moving? For example, if it is moving then digital out 1 would be HIGH, and if it is not moving then digital out 2 would be LOW. The application of this would be for 3D printing, i.e. disabling the extrusion motor if the TCP of the robot isn't moving to stop it from creating a massive blob of clay/molten plastic.

Here's the latest grasshopper definition!

Reversing the rotation axis of the turntable should flip the rotation direction as well - see the attached example!

Okay, so using Karl's x*-1 approach, I can now successfully reverse the turntable direction in my main Grasshopper definition, but this is still resulting in the same issue where I can see the A value increasing like before, rather than staying in a similar range.

Otherwise the approach would be to look into the machine data file, but let's keep that option for later.

I'm confused why this is the other option because the robot is doing what it is being told to do from the KRL, its more that the simulation isn't matching the KRL, if you understand what I mean?

Best,

Alex

Sorry for the long delay, has been very hectic here!

Recompute doesn't seem to be changing anything here.

Attached is the grasshopper file.

Best,

Alex

Hi Johannes,

Thank you for replying on your holiday! No rush needed with the replies.

So if you see the YouTube link below I don't think the reversed direction is working consistently? Angel came up with the solution to use the flipped surface which worked on both our computers at some point, but now I try and do the exact same process and it doesn't reverse?

https://youtu.be/lr7nmwQAooI