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

RobotState::setFromIK is subframe unaware #3072

Closed
rr-tom-noble opened this issue Nov 8, 2024 · 0 comments · Fixed by #3077
Closed

RobotState::setFromIK is subframe unaware #3072

rr-tom-noble opened this issue Nov 8, 2024 · 0 comments · Fixed by #3077
Labels
bug Something isn't working

Comments

@rr-tom-noble
Copy link
Contributor

rr-tom-noble commented Nov 8, 2024

Description

RobotState::setFromIK() returns false when the tip frame passed is a subframe.

This is due to the method only checking if the frame is the name of an attached body.

This is in contrast to the ROS1 code, which calls getRigidlyConnectedParentLinkModel(), which is subframe aware.

The code is a bit different in ROS2, however, RobotState already has a method for looking up frames with subframe awareness.

As such, I think the call to hasAttachedBody() should be replaced with getFrameTransform().

ROS Distro

Humble

OS and version

Ubuntu 22.04

Source or binary build?

Binary

If binary, which release version?

2.5.5

If source, which branch?

N/A

Which RMW are you using?

None

Steps to Reproduce

  1. Call RobotState::setFromIK() where the tip parameter is a subframe
  2. The code will error and return false

Expected behavior

The call should recognise that the tip is a subframe, return true, and set the robot state accordingly. This is consistent with ROS1 behaviour.

Actual behavior

The code prints an error "The following Pose Frame does not exist: ", and returns false.

Backtrace or Console output

No response

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

Successfully merging a pull request may close this issue.

1 participant