i faced another Bug when creating API generated Waypoints with a TCP Offset of
Z = 400 mm:
when i create a Waypoint with this Pose through the Polyscope UI:
everything is fine:
but if i use the same Pose for a API generated Waypoint i get an Error that the Inverse kinematics could not find a solution:
Please note that this has nothing to do with reachable Ellipse Points it is just an example to reproduce the error. It even could not find the center Point!
It seems to be related with Calling Pose from URCap generated Waypoint misses TCP Offset
any Help? i could not be the only one having this issue
So i spent some time elaborating on this Error again and found some changes in the procedure how waypoints are generated through the API in the Ellipse example using the MovePConfigBuilder Interface inside the configureMoveNode() function and thought it should solve the Issue by using this method because my logic is basically the same used in the 1.3 API examples .
Using API 1.6.1 and URSim 5.3.and a TCP configured with Z = 400 mm i installed the html Ellipse Example with modified horizontal and vertical ellipse radius (20mm, 12mm) to be sure it has nothing to do with the Ellipse itself.
I found out that the MoveNode TCPSelection was configured to ignore active TCP Selection so i changed it to createActiveTCPSelection() and hoped it would finally work, but no, this is the farest the Robot can move to the left without getting a inverse kinematics Error:
a little step more to the Left:
same Problem on version 5.4.0 with sdk 1.6.1
It seems like to me that the API points always calculate to a point with the TCP set as Flange during calculation and then after sets the TCP, but basically fails before that due to that the flange would not be able to reach that position.
If you would try to reach that point with the TCP as toolflange, the length of the x,y,z vector would be pretty close to 1300 mm, with just a few mm longer.
Any workaround on that seems like it would be a pain. How do you handle it right now?
i’m actually waiting for the API 1.7.0 release to test it again.
As there is no option to re-assign waypoints with another TCP through the API i can’t think of a suitable workaround.
teaching the waypoints with a 0,0,0,rx,ry,rz tcp would be an option but messes up any program that uses a MoveL or MoveP with orientation change…
I would like to suggest a possible workaround for this bug.
Please report back if this is able to mitigate this issue.
When inserting a waypoint, you are either capturing the data from the RobotPositionCallback, or the RTDE.
Either way, you are getting: Pose (including TCP) and the JointPositions at the given waypoint.
- Create a Move node
- Create a Move Node configuration, that configures the MoveNode to:
a. MoveL or MoveP
b. Specifies a TCP on the MoveNode other than “Use Active TCP” or “Ignore TCP” - selecting a distinct TCP.
- Insert the MoveNode in the Tree.
- Create a new Waypoint
- Insert the unconfigured waypoint in the Tree, under the MoveNode
- Create a Waypoint Configuration, that includes the Pose and JointPositions captured.
- Apply the Waypoint Configuration to the “unconfigured” Waypoint in the Tree.
This should properly account for the TCP.
Repeat steps 4-7 for each subsequent waypoint.
Critical step are 2.b and 5.
thank you for your answer on this. we’re still struggling with this bug.
I tried to append your guide to the html ellipse urcap example using SDK 1.7.0 and URSim 5.4.0. which basically inserts the waypoints in the mentioned steps.
First i tried to use moveNode.getTCPSelectionFactory().createTCPSelection with a new TCP:
which didn’t work:
So i tried to use the TCPContributionModel which is normally suited for installation Node:
EDIT: This works!! (i just used the wrong test pose causing a pose out of working area, even with tcp z 500 mm)
@m.birkholz Many thanks for the feedback, that the workaround was successful.
I would recommend using an already configured TCP in the list of TCP’s.
But guess it depends on the application and usage.
If the URCap is provided for a system, which includes the end-effector (i.e. a wleding system, where a welding torch with known properties), then I would assume that the URCap’s installation node already created the appropriate TCP.
Then it should be no problem pre-selecting this TCP in the Move nodes.
In the other use case, where the end-effector is not provided by the URCap vendor (TCP is not known), the URCap parent program node could ask the user which TCP to use for the child waypoints inserted, and apply these to all child move nodes inserted by the URCap by default.
we will create a custom tcp installation node with pre-defined immutable tcp’s depending on the welding equipment and an option to create a user-defined one.