forward kinematics and DH parameters

[AiSard]

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,

[Johannes @ Robots in Architecture]

Hello,

With KUKA, the redundancy parameters are called status and turn. They are described e.g. in the KSS 8.3 manual on page 301, chapter 9.10.
Through the analysis component of KUKA|prc you get all the axis values, which should allow you to easily derive the status and turn parameters. Or you go the other way, by setting status and turn (separated with a space) in a PTP movement.
I'm not 100% sure, but it may be that RSI requires status and turn in decimal format, where e.g. 101011 would be 43.

Best,
Johannes

[AiSard]

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

[Johannes @ Robots in Architecture]

Ah, OK, now I see what you want to achieve - I must have somehow blanked out before.
In any case, you can obviously also use KUKA|prc for forward/inverse kinematics, or try to use the relevant methods from the KUKAprcCore.dll. However, we don't officially support that.
If I remember correctly, Daniel Piker once wrote an open-source kinematic solver for Grasshopper.
Also, consider that Grasshopper isn't really the best platform for actual real-time applications. So if you get stutters in your movements, that may not be your interpolation algorithm, but rather a brief communication pause.

Best,
Johannes

[AiSard]

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

[Johannes @ Robots in Architecture]

From my experience there are plenty of pitfalls, especially for inverse kinematics ;)
E.g. how do you react if a position is not reachable? Is the axis then 0, NaN....? Just as a very basic example.
What we did is that we created a "fake" robot - basically a simple GH component that took the RSI commands and visualized them. That helped with troubleshooting!
Consider looking into how to give your server process a rather high priority. Or as a stop-gap, just right-click the process in the task manager and assign the priority manually.

Best,
Johannes