Skip to content
This repository has been archived by the owner on Nov 13, 2017. It is now read-only.

getLinkState() from robot_state issue #87

Closed
davetcoleman opened this issue Sep 10, 2013 · 4 comments
Closed

getLinkState() from robot_state issue #87

davetcoleman opened this issue Sep 10, 2013 · 4 comments

Comments

@davetcoleman
Copy link
Member

In the Rviz plugin, using the interactive markers, the end effector of Baxter is being rendered incorrectly with its links in the wrong position. I have also ran into this issue in some of my custom code. I have tracked it down to the getRobotMarkers() function in robot_state.cpp so I am positing this issue in moveit_core. Perhaps the issue is in the function getLinkState() - what is a link's state when no tf or joint_states are being published?

The two green fingers in the bottom left are the issue - they work normal in most other situations as pictured on the right.

Thanks!

end_effector_marker

@isucan
Copy link
Contributor

isucan commented Sep 10, 2013

I was worries the code was not using updated transforms, but things seem to be fine. If there are no joint states published, a default transform is used (as computed by RobotState::setToDefaultValues())

@davetcoleman
Copy link
Member Author

I'm not sure what you are saying - I am still having the issue pictures above where the green fingers are "floating" in the wrong position, when they should be attached to the end effector. I'm having this issue both with the current debs release and the latest source build.

Since I am not publishing joint states, it will assume some default value - usually 0, correct? Even if it assumed the joints were at zero, the above image should not happen.

@isucan isucan closed this as completed in c3bd65c Sep 11, 2013
@davetcoleman
Copy link
Member Author

As we discussed via chat, does this really fix the issue I was experiencing? I think we agreed that the bug is in global_link_transforms_[lm->getLinkIndex()], though I'm not using this latest version of MoveIt!

@davetcoleman davetcoleman reopened this Sep 12, 2013
@isucan
Copy link
Contributor

isucan commented Sep 12, 2013

Not properly fixed indeed. Will fix properly :)

@isucan isucan closed this as completed in eda1b4d Sep 12, 2013
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants