Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Johannes @ Robots in Architecture

#1
Support / Re: Inaccurate Robot Movement
February 11, 2025, 10:48:35 PM
Hello,

Two things come to mind:
First of all, make sure that the tool and base values (XYZABC and number) are identical on the physical and simulated robot.
Secondly, I see that you are using a Lego robot. It may be the case that the robot position is not properly calibrated. I.e. the robot thinks that it is somewhere but it is physically somewhere else.

Best,
Johannes
#2
Support / Re: Casting Goo to KUKA|prc Command
February 10, 2025, 10:37:36 PM
Hello Mark,

Instead of KUKAprcCore.PRC_Classes.PRC_CommandData use KUKAprcGH.PRC_IOClasses.GH_PRC_CommandData.
The second one is the class that extends GH_Goo and contains PRC_CommandData.

I tested it briefly and it worked for me! You will also need to import the KUKAprcGH namespace on top.
Best,
Johannes
#3
Support / Re: Casting Goo to KUKA|prc Command
February 08, 2025, 10:33:57 PM
Hello Mark,

I use Python from time to time e.g. in Blender or Fusion, but honestly never properly used it within Rhino.
Can you make a very "slim" example that I could debug? Note that I'm officially out of the office next week, so it might take a bit longer than usual...

Best,
Johannes
#4
Support / Re: Coordinating Motion with an External Axis
February 08, 2025, 10:28:03 PM
Great! Wes McGees should be provided with every robot!
Best,
Johannes
#5
Support / Re: Coordinating Motion with an External Axis
February 06, 2025, 11:16:57 AM
Hello Mark,

That's a nice setup! A good way to check the synchronization would be in your case that you move the TCP onto your object in a Cartesian movement mode with the external base active and then rotate E1.
The robot should perfectly follow the rotation.

If it doesn't: If it's a KUKA motor then it would be good to check if the gearbox is properly configured. If it's a custom setup - because you mention a stepper motor - then in addition you would need to look into its controller, whether you can customize the acceleration/deceleration ramps etc.

Best,
Johannes
#6
Support / Re: KUKA Robot Speed, Settings & Calibration
February 06, 2025, 11:11:13 AM
So the A4 rotation is defined by the so-called STATUS value that defines the posture. If you don't provide a PTP movement before, KUKA|prc will add one. Look into the Settings window, Initial Posture, and change it. The most common values are 010 and 110. Please refer to the KUKA documentation for a good explanation of the STATUS value.

Regarding the reachability, I cannot say anything from the image. You might be going through a singularity and winding up your A4, for example.

Best,
Johannes
#7
There are all kinds of Euler conventions, you probably picked the wrong one unfortunately.

If you are doing it in Grasshopper, you take a plane, create a rotation by the A value around the Z-axis, then rotate the plane accordingly, do the B value for Y, rotate the plane accordingly, and finally the C value for X and rotate the plane accordingly. That will get you the correct coordinate system. Note that the transformation is cumulative and that the order makes a difference.
The same should work in any other software where you can do 3D transformations!

Best,
Johannes
#8
Support / Re: KUKA Robot Speed, Settings & Calibration
January 31, 2025, 05:35:41 PM
Hello,

Via Display/Variables you should be able to query the speed via $VEL_ACT

For the 4 point calibration, you can pick any point in space.

Regarding the base, the robot in KUKA|prc is moved backward, so that the Rhino origin is always the base. So the further away the origin of your base is from the robot, the more the robot is moved back from the Rhino origin. I guess you simply calibrated a tilted base. Take a look at the ABC values - a base roughly parallel to the floor will have mostly rotation in A but few in B and C.

Best,
Johannes
#9
Support / Re: KUKA Robot Speed, Settings & Calibration
January 31, 2025, 09:57:59 AM
Hello,

We have got an OrangeApps Lego robot as well and like it a lot, but you need to remember that it is not a "real" KUKA robot. So issues with speed etc. are mostly due to that. What they do is that they get the position where the simulated robot is and send it to the Lego robot to move there. So you won't get exactly the same movement as with a real KUKA robot.

That is assuming you are running the robot in T2 or AUT, because T1 speeds are by default limited.
You cannot block an axis easily. If you need more control over the toolpath, add additional positions to make sure that your robot is where you want it to be.
Regarding calibration, that is the standard way, but if you 3D printed your tool you can just take the measurements from the digital model. A good way to check the tool calibration is to move the robot in ABC - if it's properly calibrated, the tip will remain in place and rotate exactly around the TCP. Base calibration is very straightforward anyways.
In KUKA|prc you can add cell geometry (Custom Cell component), which will keep its relative position to the robot.
What do you mean by setting a base in real-time?

Best,
Johannes
#10
Support / Re: spline tree error
January 24, 2025, 05:57:28 PM
The email was sent 1h ago, please check your spam folder!
#11
Support / Re: spline tree error
January 24, 2025, 04:43:25 PM
Sure, I'll send it to the email address listed in your profile.
Best,
Johannes
#12
Hello,

The start and end positions need to be axis positions, as in the user interface!

Best,
Johannes
#13
Support / Re: Custom Tool Axis Issue
December 20, 2024, 08:53:04 AM
Feel free to ask if you run into any problems, my replies might just be a bit delayed over the holidays!
Best,
Johannes
#14
Support / Re: Prevent Rotation of Tool
December 20, 2024, 08:52:19 AM
Hello,

You can set the rotation to infinite, meaning the robot will take the shortest path. For the KUKA|prc simulation that means simply right-clicking a robot component and selecting the infinite A6 option. On the actual hardware, you can set the axis type in the $machine.dat if I remember correctly. Of course infinite rotation means that you could easily wind up cables as well.
You could also use the TURN value of a PTP movement to define whether A6 is positive or negative in that particular example.

I'm not sure if disabling the axis is feasible, that would probably be a question for KUKA support. I could imagine that you could mess with the gear value of the axis, so that the robot thinks that it's moving a lot while it is physically only moving a tiny bit. That would be pretty "hacky" and the simulation would not fit the physical robot anymore.

Best,
Johannes
#15
General Discussion / Re: Adding Analog Output Module KRC2
December 20, 2024, 08:46:32 AM
Hello,
Sorry, I must have missed your post. I never got deep into IO configuring on KRC2 unfortunately. The Wago seems to use two bytes for each channel, so it sounds plausible. You might get better KRC2-related replies on robot-forum.
Best,
Johannes