# getForwardKinematics(actual\_q) not providing the same answer as getActualTCPPose()

**URL:** https://forum.universal-robots.com/t/getforwardkinematics-actual-q-not-providing-the-same-answer-as-getactualtcppose/22623
**Category:** Report a Bug
**Created:** [July 12, 2022, 3:07pm UTC](https://forum.universal-robots.com/t/getforwardkinematics-actual-q-not-providing-the-same-answer-as-getactualtcppose/22623 "2022-07-12T15:07:31Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![anon49323107](https://avatars.discourse-cdn.com/v4/letter/a/a87d85/32.png) [@anon49323107](https://forum.universal-robots.com/u/anon49323107)
#### Post date: [July 12, 2022, 3:07pm UTC](https://forum.universal-robots.com/t/getforwardkinematics-actual-q-not-providing-the-same-answer-as-getactualtcppose/22623/1 "2022-07-12T15:07:31Z")

</div>

Steps to reproduce:

> > > import rtde\_control  
> > > import rtde\_receive  
> > > HOST = “127.0.0.1”  
> > > control = rtde\_control.RTDEControlInterface(HOST)  
> > > receive = rtde\_receive.RTDEReceiveInterface(HOST)

> > > ZERO\_COORD = receive.getActualTCPPose()  
> > > ZERO\_Q = receive.getActualQ()

> > > ZERO\_COORD  
> > > [-0.5688240883583726, 0.1385389418035598, 0.38379092026207345, 2.0629827979244912, 2.3351493370908547, -0.010060181623337425]  
> > > ZERO\_Q  
> > > [-0.5432213908580206, 0.394379499143662, -2.184086442468014, 0.24301507990286897, -1.559838562883069, -0.6669604472629826]

> > > test\_coord = control.getForwardKinematics(ZERO\_Q)  
> > > test\_q = control.getInverseKinematics(ZERO\_COORD)

> > > test\_coord  
> > > [0.6910947428839915, 1.3530535579213854, 0.3761237227919115, 2.0629827979244912, 2.3351493370908547, -0.010060181623337425]  
> > > test\_q  
> > > [-0.5432213908580206, 0.3943794991436613, -2.184086442468013, 0.24301507990287152, -1.5598385628830682, -0.6669604472629818]

Expected Behavior:  
I am expecting that getActualTCPPose and getForwardKinematics(ZERO\_Q), where ZERO\_Q is the actual joint position (obtained from getActualQ()) both return the same (or very similar) position in the cartesian space (tool space)… because they are the same position

Actual Behavior:  
The x, y, z coordinates differ in the getForwardKinematics() calculation. (I have to assume that getActualTCPPose() is giving the right values and it is getForwardKinematics() that is wrong. Here are the differences:

getActualTCPPose() gives [-0.5688240883583726, 0.1385389418035598, 0.38379092026207345, 2.0629827979244912, 2.3351493370908547, -0.010060181623337425]

getForwardKinematics(ZERO\_COORD) gives [0.6910947428839915, 1.3530535579213854, 0.3761237227919115, 2.0629827979244912, 2.3351493370908547, -0.010060181623337425]

Affected versions:  
Using Linux-based offline simulator version 5.12, on Ubuntu 20.04, running in a conda virtual environment using Python 3.8, with ur\_rtde package version 1.5.2

---

<div class="post-metadata">

### Author: ![bivaldi](https://avatars.discourse-cdn.com/v4/letter/b/2acd7d/32.png) [@bivaldi](https://forum.universal-robots.com/u/bivaldi)
#### Post date: [December 3, 2025, 9:03pm UTC](https://forum.universal-robots.com/t/getforwardkinematics-actual-q-not-providing-the-same-answer-as-getactualtcppose/22623/2 "2025-12-03T21:03:45Z")

</div>

Did you find a solution to this? I’m experiencing the same issue.

---

<div class="post-metadata">

### Author: ![bivaldi](https://avatars.discourse-cdn.com/v4/letter/b/2acd7d/32.png) [@bivaldi](https://forum.universal-robots.com/u/bivaldi)
#### Post date: [December 3, 2025, 10:41pm UTC](https://forum.universal-robots.com/t/getforwardkinematics-actual-q-not-providing-the-same-answer-as-getactualtcppose/22623/3 "2025-12-03T22:41:25Z")

</div>

Well I figured out my issue, maybe it can help others. I could call getForwardKinematics and get the correct result, then call getInverseKinematics and get the correct result, then call getForwardKinematics again but this time get the wrong result and it will not be fixed until you reboot. It appears that getInverseKinematics screws up the known position somehow. If instead you getTCPOffset and getForwardKinematics(q\_rad, my\_tcp\_offset), I am continuously getting the correct result.