Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect TF broadcast for robots-on-tracks #170

Closed
gavanderhoorn opened this issue Oct 4, 2023 · 6 comments · Fixed by #172
Closed

Incorrect TF broadcast for robots-on-tracks #170

gavanderhoorn opened this issue Oct 4, 2023 · 6 comments · Fixed by #172
Labels
bug Something isn't working rv:0.1.1 Reported in MotoROS2 0.1.1 yrc1000
Milestone

Comments

@gavanderhoorn
Copy link
Collaborator

After some discussion in #169, it appears the current implementation of TF broadcasting for robots on tracks is not working as it should.

Jogging a robot on a track does not update the world -> r1/base transform. Only robot pose changes are reflected in the r1/base -> r1/tool0 (and r1/base -> r1/tcp_0) transforms.

@gavanderhoorn
Copy link
Collaborator Author

gavanderhoorn commented Oct 4, 2023

somehow I didn't notice this, even though I have a robot-on-a-track here.

Most of the tools we use (also to test) don't consume the TF broadcast by MotoROS2, which could explain this.

As to a possible solution: if the Yaskawa Base to Yaskawa RF transform could be included in the world -> r1/base transform (on the ROS side), that would seem to fix this issue.


As to a possible solution: if the Yaskawa Base to Yaskawa RF transform could be included in the world -> r1/base transform (on the ROS side), that would seem to fix this issue.

Edit: a difficulty here would be that without a calibration of the robot's TCP origin to the track's "origin", this transform would likely still only be partially correct (ie: it would only provide an offset in X (or whichever axis the track is configured to move along)).

@gavanderhoorn
Copy link
Collaborator Author

Note that the FK performed by the robot_state_publisher (together with a correct URDF (including the robot and the track)) is correct, as it's based on joint angles.

@gavanderhoorn gavanderhoorn added this to the 0.1.2 milestone Oct 4, 2023
@ted-miller
Copy link
Collaborator

Now I'm really confused. Now I think that it should actually work.

Turns out that the offsetFromBaseToRobotOrigin is taken into account.

mpZYXeulerToFrame(&coordWorldToBase, &frameWorldToTrack);
mpZYXeulerToFrame(&coordTrackTravel, &frameTrackTravel);
mpZYXeulerToFrame(&group->baseTrackInfo.offsetFromBaseToRobotOrigin, &frameTrackToRobot);
mpMulFrame(&frameWorldToTrack, &frameTrackTravel, &frameWorldToTravel);
mpMulFrame(&frameWorldToTravel, &frameTrackToRobot, &frameWorldToRobot);
mpFrameToZYXeuler(&frameWorldToRobot, &coordWorldToBase);

I'll take a detailed look at this later today.

@gavanderhoorn
Copy link
Collaborator Author

Maybe something here is not happy with my setup?

motoros2/src/CtrlGroup.c

Lines 88 to 109 in 62ac8ed

if (Ros_CtrlGroup_IsRobot(ctrlGroup))
{
mpGetToolNo(ctrlGroup->groupId, &retToolData);
//TODO: need to update this value when selected tool changes
ctrlGroup->tool = retToolData.sToolNo;
int baseIdOffset = (int)ctrlGroup->groupId - (int)MP_R1_GID;
ctrlGroup->baseTrackGroupIndex = mpCtrlGrpId2GrpNo((MP_GRP_ID_TYPE)baseIdOffset + MP_B1_GID);
if (ctrlGroup->baseTrackGroupIndex != ERROR)
{
ctrlGroup->baseTrackGroupId = (MP_GRP_ID_TYPE)(baseIdOffset + MP_B1_GID);
GP_getBaseAxisInfo(ctrlGroup->baseTrackGroupIndex, &ctrlGroup->baseTrackInfo);
}
else
ctrlGroup->baseTrackGroupId = (MP_GRP_ID_TYPE)-1;
}
else
{
ctrlGroup->tool = 0;
ctrlGroup->baseTrackGroupId = (MP_GRP_ID_TYPE)-1;
ctrlGroup->baseTrackGroupIndex = -1;
}

@ted-miller

This comment was marked as outdated.

@ted-miller

This comment was marked as outdated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working rv:0.1.1 Reported in MotoROS2 0.1.1 yrc1000
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants