Messages

woops, X is facing the wrong direction >_>
and forgot to program for Z direction (I'd forgotten that was an option in v1..)
but still useful with a bit of tinkering :P

gronked one together, attached in case anyone else needs a quick convert :)

mm, always found the unexposed portions of PRC slightly confounding, though I guess its just a different design philosophy..

It's slowing down because, as the Master/Reference file, it holds 10+ quite heavy if individually manageable meshes that, together, become unmanageable.

Was looking for a quick plug'n'play system, but in this case I'll have to settle for a conversion tool I think. Still better than 20+ meshes freezing up gh though >_>

mostly I have to forgo most of the simpler* options as it'd just confuse the end-users (i.e. other people in the practice :P)

Thanks anyways,

but wouldn't it stand to reason that the transformation from base(v1) to flange(v2) is already embeded within the xyzabc data?
I will try and fiddle around with that..

Don't really want to manually orient the 10 or so meshes, especially as the base never seems to line up when I try :(
that and it'll double the filesize and it's already pretty laggy..

So I've been archiving all the tools I've ever used with kuka|PRC for archival purposes, when I was reminded that the tool mesh is inputted differently between PRC2 and PRC1 (and between X and Z for the latter)

Whats an easy way to transform the tooling mesh between PRC1 to PRC2 and vice-versa?
Given that I have the xyzabc of all the tools, I figured all the information was there to do the conversion, but I've never really wrapped my head around that transformation :-[

mm.. was really hoping there was an easy way for changing it dynamically. Will test out the Change Tool technique and see if it fits the scenario on Thursday.

Thanks,

Hmm.. I've vague recollections that in the preliminary tests, in between the planes (in between the commands) the focus would shift to the left/right before refocusing on the next plane/command. Will have to test further.. hopefully will get enough hands-on time with the robot before actual implementation!

Was wondering if there is a way to use kukaPRC to move a camera mounted on a robot in such a way that it is always focused upon a fixed (or moving) point?

I recall doing some tests way back when SPLine was not yet fully implemented in kukaPRC, but gave up as I couldn't find a way to keep the camera focused on a point in between commands. LIN and PTP always shifted the focus in between commands.

Not going to have access to the robot til Thursday so was wondering if it's possible to do on PRC, or if not if you have any tips for how to implement it with KRL code?..

Thanks,

Is there a way to switch posture using only LIN movements (no PTP)?
either using just PRC, or adding something to the KRC code maybe?

i.e. the first 10 movements I want it to be in 110 configuration, but the second set of ten movements I want to be in 010 configuration? something like that?

Thanks,

If the input is a Line Move, everything works as expected
if the input is Axis Move, re-inputting the plane as a Line Move input gives a different result.

Not sure if I'm missing something, a bug, or a hold-over from older versions:

Plane output from the Analysis component isn't the same as Plane input (in LinMove for instance).
Seems the tool direction isn't the same?

Edit: seems to happen when the input is through AxisMove

Ooo, didn't realize, thanks!
Already have the member version at the office thanks

Hi,

Apologies in advance if this is a stupid question; but where do we set the min/max axis limits? (I vaguely recall we could set these values in PRC1) or has this been internalized for each robot somehow?

Thanks,

Whelp, I finally hacked together my DH parameters by comparing a lot of examples and the help of that youtube video  :D
Hopefully no severe beginner pitfalls with forward/reverse kinematics..

Ah, by (stupid) interpolation, I meant just increasing B of the Euler angle or something :P Euler angles are annoying :(

You can get around movement stutters by keeping motion relative, ignoring orientation, and opening yourself to multiple seconds of terror every now and then when the robot keeps moving even though its not receiving from Grasshopper *cringe* not... the safest thing in the world granted.

Thankfully, that's why I'm trying my hand at writing up a Processing(Java) server now!

Thanks for the help regardless  :)

Ah, no. I meant Denavit-Hartenberg parameters, that works as a robotic blueprint mapping out the relations between the reference frames of axes. Found some code that purports to do forward and reverse kinematics xyzabc-->a[1-6] and back but it needs the 'a' and 'd' parameters (2 of the 4 variables).

If I have that I could compute the orientation in gh (or processing), get the euler angles, plug them in to the code, and send them off to the robot with RSI using Axis Correction as opposed to Position Correction, without having to worry about all the weird things that can happen when you (stupidly) try to brute force lerp/interpolate the ABC values >_<

https://en.wikipedia.org/wiki/Denavit%E2%80%93Hartenberg_parameters
https://www.youtube.com/watch?v=rA9tm0gTln8

Apologies if its a bit off topic,
But I've been messing around with forward kinematics for use with RSI along kukaPRC and stumbled on the need for Denavit-Hartenberg parameters (the 'a' [alpha?] and 'd' parameters specifically). Does anyone know where I can find this, calculate this, or derive this from the robot skeleton that kukaPRC produces?

Our robot is a Kuka KR10 K1100 sixx.

Thanks,