Manual fix to issue#287 for Hironx.

[130s]

Applying the change suggested in #287 (comment) for left and right arms.
As far as checked visually (making unittest for this issue is in progress at tork-a/rtmros_nextage#133), it looked ok.

[k-okada]

created test code for #287 and why you create new unittest under nextage?

[k-okada]

What is the plan ? since robot_model is likely to update to new version on next sync, are you going to merge this and create new version now, and remove this and create new version after next sync? and release reverted version on next-next sync?

[130s]

#287 (comment) tells all. We don't need this patch.

why you create new unittest under nextage?

Because the model file is different b/w hironx and nextage, I thought we need tests for both. But even for that purpose, I'm not sure if we need to have 2 different test cases, because all we need is the "run" of the tests against 2 different robots; testcase can be the same. So IMO as long as the test is run against both robots, we should utilize the same test cases.

[k-okada]

Ok, I understand, I just curious that it seems you create test code for nxo only not hiro.

[uesnaola]

Using the source code of github for nextage_ros_bridge we see that this issue is solved for simulation with nextage, but when we try with the real robot the problem remains. We calculated tfs using the nextage functions getCurrentPosition and getCurrentRPY to compare. I attach a picture

We tfs names LARM_JOINTx_Link are originals and the ones named LARM_JOINTx_Link_Controller are the ones we generated using nextage functions. You can see that the ones we generated match with the 3D model but the others not so I can not figure out where should the parsing error happen.

Another hint is that works for simulation but not for the real robot. Apart of the wrl model stored in the QNX of the robot, is there any other difference between simulation and real robot?

[emijah]

Hello everyone,

Is the deviation always in the Z direction?

If so, it could be because the LARM_JOINTX_Link_Controller points are
calculated using the command angles to the joints, and LARM_JOINTX_Link
points are calculated using the actual angles the robot is at. The
deviation in the Z direction would be the effects of gravity, as neither
Hiro nor Nextage Open has gravity compensation. That said, the amount of
deviation looks pretty large, but then, I don't know what is attached to
the end of the wrist.

Best regards,

Hajime

2015-03-05 21:24 GMT+09:00 uesnaola [email protected]:

Using the source code of github for nextage_ros_bridge we see that this
issue is solved for simulation with nextage, but when we try with the real
robot the problem remains. We calculated tfs using the nextage functions
getCurrentPosition and getCurrentRPY to compare. I attach a picture

[image: screenshot from 2015-03-05 10_42_30]
https://cloud.githubusercontent.com/assets/6713821/6504692/3a397e84-c33a-11e4-8f63-a5a671dc8b55.png

We tfs names LARM_JOINTx_Link are originals and the ones named
LARM_JOINTx_Link_Controller are the ones we generated using nextage
functions. You can see that the ones we generated match with the 3D model
but the others not so I can not figure out where should the parsing error
happen.

Another hint is that works for simulation but not for the real robot.
Apart of the wrl model stored in the QNX of the robot, is there any other
difference between simulation and real robot?

—
Reply to this email directly or view it on GitHub
#290 (comment)
.

[130s]

@uesnaola Is it possible for you to share the code you use to publish your custom tf frames (LARM_JOINTx_Link_Controller)?

@emijah Once we have the code is it possible for you to try reproducing the issue on the real robot?

Lacking both the code and the real robot, it's a bit hard for me to replicate the issue.

---

And in response to @emijah,

The deviation in the Z direction would be the effects of gravity,

Assuming this is true, then,

it could be because the LARM_JOINTX_Link_Controller points are calculated using the command angles to the joints, and LARM_JOINTX_Link points are calculated using the actual angles the robot is at.

I think this is the opposite.

• LARM_JOINTX_Link_Controller is based on the result values of hrpsys' getCurrentX functions, which should be considering the poses from the real robot. Gravity might matter here.
• LARM_JOINTX_Link is based rather on models in collada file. So no gravity applied.

If the above is true then LARM_JOINTX_Link_Controller shouldn't be located lower than the other.

Ref. #213 (comment)

After all, I can't yet explain why @uesnaola is seeing this issue.

[130s]

CORRECTION:

x: If the above is true then LARM_JOINTX_Link_Controller shouldn't be located lower than the other.
o: If the above is true then LARM_JOINTX_Link shouldn't be located lower than the other.

LARM_JOINTX_Link are the ones that are NOT affected by gravity.

[emijah]

@130s @uesnaola Okay. I'm afraid I'm rather busy until the 15th. I should be able to replicate the problem after that.