RWS endpoints "joints-from-pose", "joints-from-cartesian" and "all-joints-solution"

Hi!
Has anyone got those RWS functions working correctly?
And yes, I know about required conversions millimeters ←→ meters, radians ←→ degrees.

joints-from-pose” will return error “An argument specified by the client is not valid for this type of operation”. Seams that body description on API reference pages is incorrect so I could not even test it.

joints-from-cartesian” and “all-joint-solutions“ both will return (same) incorrect values as if kinematics based on whitch conversion is done is different from my actual robot in project. I did also try same functions from AppStudio framework (API.RWS.MOTIONSYSTEM namespace) and SAME incorrect values are returned.

Robtarget is in wobj0 coordinates, world is same as baseframe, using tool0.
As I do not have real robot available, could it be that reverce kinematics is not working correctly in simulator?
Any ideas?

Fritz.

Can you please link the source where you did get that information.
Thank you!
Fritz.

Hi Fritz

Apologies for the uncited claims in my earlier reply.

Hello,

these methods don’t use absolute accuracy but always give you back the pure ideal transformation. Do you see the difference in robot that have absolute accuracy ? If so that may be that reason

Hi !
The results are not a bit off, the results are off by 10, 20… degrees. I haven’t had time to play with it more to figure out any patterns. I’m just curious at the moment if anyone has gotten it to work properly in a simulator. Unfortunately, I don’t have a real robot at hand at the moment.

Fritz.

I tested these methods with a gofa but the only error was the absolute accuracy one . Didn’t notice anything else

Did you test also “joints-from-pose”? If yes, how did your html GET function body look like?
Fritz.

Hi Fritz,

I tested on a real IRB 1600-6/1.2, RobotWare 6.13, IRC5.

First I tried the same action names you mentioned (get-joints-from-pose, get-joints-from-cartesian) and got HTTP 400 “Invalid action parameter value” because i think those names are wrong. The correct action names found in the ABB Developer Center RWS API reference (3HAC050973-001 Rev M) are CalcJointsFromPose
for IK and CalcPoseFromJoints for FK, and the method must be POST not GET.

The body parameters for CalcJointsFromPose according to the documentation:

curr_position=[x,y,z]
curr_orientation=[u0,u1,u2,u3]
curr_ext_joints=[j1,j2,j3,j4,j5,j6]
tool_frame_position=[x,y,z]
tool_frame_orientation=[u0,u1,u2,u3]
old_rob_joints=[j1,j2,j3,j4,j5,j6]
old_ext_joints=[j1,j2,j3,j4,j5,j6]
robot_configuration=[cf1,cf4,cf6,cfx]
robot_fixed_object=FALSE
elog_at_error=FALSE

The old_rob_joints seed is worth noting without the correct current joint state the solver may return a different valid solution, which could explain your wrong values in simulator. (im not sure about this)

Note the ABB docs themselves say “limited use-case testing has been performed for this API”.

If you want a guaranteed-correct alternative that uses the robot’s own calibrated kinematics, i do normally get like this :

! IK
VAR jointtarget result;
result := CalcJointT(myRobTarget, tool0 \WObj:=wobj0);

! FK
VAR robtarget pos;
pos := CalcRobT(myJointTarget, tool0 \WObj:=wobj0);

you can check by yourself :

hope it helps, took me quite a few hours of testing to figure this out :slight_smile: btw im bulding the rws vscode extension i would love to get you guys feedback.

Hi !

You are talking about old RWS 1.0.
My question is about latest RWS 2.0 for robots with newer firmware.

Fritz.

Hi, you didnt mention that is RWS2 before.
However while digging around i did noticed the example response values in the ABB developer docs for all-joint-solutions are -0.1347, 0.2333, 1.820, 1.946, 1.746, which looks like radians rather than degrees.
The ABB Developer Center documentation for GetJointValues() explicitly states: “The angles are given in radians, and are here converted to degrees.”
https://developercenter.robotstudio.com/api/robotstudio/articles/How-To/RobotMechanism/GetRobotCoordinatesExample.html

i cannot confirm this is the case for RWS 2.0 IK/FK endpoints specifically, but it might be worth checking