Hello everbody, i am writing a urcap to generate waypoints using RDTE and createFixedPositionConfig method. Made some tests without a tcp in the simulation and everthing is working fine. Now i wanted to test everthing on a robot. There i was a bit puzzled sometimes the robot decides to sort its joi…

It seems like @Ebbe is referring to this workaround from 2019 : API generated Waypoints lack in Range of TCP Offset - #8 by jbm Apparently, there is a quite long-lived bug in the way API generated waypoints have their inverse kinematics solution calculated. It only seems to happen when the relevant…

Hi @anon59974243 , There seems to be some issues with the qnear related to API created waypoints. It should not be an issue if you choose a fixed TCP instead of the active one. For reference there is created a ticket ER-829 around the issue. Ebbe

Hi @Ebbe . My team have been struggling with this issue the past weeks too. When you say that we need to choose a fixed TCP, do mean that we need to add a zero array as TcpOffset to createFixedPositionConfig and add the offset to the pose itself? Can we use TCPSelection createIgnoreActiveTCPSelecti…

Hi @db11 , That might also solve the qnear challenge, but introducer other as you say. My suggestion is to utilize createTCPSelection(TCP tcp) where you can select the TCP the match your setup. Ebbe

Thank you for your reply @Ebbe . Can you please be more specific on how to get around this issue? Just as the thread starter we are trying to generate waypoints using the createFixedPositionConfig method based on some teached points. But simulation in Polyscope and the real robot produces different r…

@db11 The funny thing is, that nearly everybody creates the same functionality. In my case, the customer shipped the robot to their customer already, and I could not verify my solution at the exact same robot. But it worked on another one. I created my parent move node like this: MoveNode moveNode…

Continuing the discussion from Joints differ from RTDE values : For clarity: is the workaround described by @jbm mentioned by @anon21284509 the correct one? Trying not to come off as blunt, but your answers leave quite some confusion on our part.

I was a bit unclear there, sorry. I meant to refer only to the last post in the thread by m.birkholz , where he describes how to recreate a bug in the inverse kinematics calculation for API generated waypoints.

@db11 Yes. The Workaround of jbm should work. You can use the code provided by @anon21284509 as reference. He is cycling through the Collection of TCP to choose a “fixed” TCP for that MoveNode. The term “fixed” just means that you select a certain TCP in the MoveNode instead of creating the MoveNode…

Joints differ from RTDE values

Technical Questions

Ebbe September 20, 2022, 7:37am 8

Yes, the workaround is the same. But the issue is different. The one described by @m.birkholz is fixed by the RobotPositionCallback2 callback.

Topic		Replies	Views
API generated Waypoints lack in Range of TCP Offset Technical Questions bugs	10	1923	September 23, 2019
FixedPositionDefinedWaypoint Java	1	885	December 6, 2021
Problem with getUserDefinedRobotPosition / joint positions Technical Questions bugs	7	2615	July 9, 2019
Calling Pose from URCap generated Waypoint misses TCP Offset Technical Questions bugs	16	2404	March 25, 2019
Wrong inverse calculation when adding a waypoint to a movej node Report a Bug	14	1306	August 5, 2021

Joints differ from RTDE values

Related topics