-
Notifications
You must be signed in to change notification settings - Fork 536
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::getRigidlyConnectedParentLinkModel()
does not recognise subframes
#3089
Comments
I've run the tests locally in Debug mode a la #3102, however they still pass. This suggests to me that |
@sea-bass I'd like to test this again using 2.5.6 as a base to rule out source and binary mixing issues. It seems like the apt repository is still hosting 2.5.5. Do you know how often this gets updated? No worries either way, as I can build from source from the tag 👍 |
If you want to use latest release packages, you need to use the testing repository. These are manually synced to the production repo on an irregular (usually monthly) basis. |
Added some prints to the subframe lookup code in
Interestingly, it seems to find the subframe (so not an issue with the AttachedBody::getGlobalSubframeTransform()):
I'm also unsure about the print after finding the frame... |
Extra prints, extra info (and errors):
|
I'm still very suspicious of this print:
We print the frame found flag shortly before returning in This feels very race condition-y |
Ah actually, we print out the link name first in Given the rogue print, and the fact that link is a mutable pointer, I'm suspicious of the latter. |
More prints:
And a nullptr check when we fetch the parent link of the attached body that has the subframe, after found.
|
In summary, the order of operations is:
|
Actually, I could be incorrect regarding 5. It might be the case that the |
Ok. Is there already code available (e.g. a test), adding an object + subframe and then calling getRigidlyConnectedParentLinkModel(), which you are using? Providing a code link (or code snippet) would save me some time to search for it. |
There's tests I added in pilz which call I did take a brief look over the moveit and pilz code to check callback group types (thinking that two of the same services that query the robot state might be running concurrently, but it appeared that only the pilz |
I'll be partially available on my personal account, so I might try adding a test to the pilz |
It looks like there is a call to backtrace:
|
Yeah, the robot state used to call |
Oh, I bet it's the passing of collision objects as diffs through the move group interface. I'll investigate that now. |
Yeah, it's moveit/moveit#3592. I'll port it now. |
Wait, no, I'm wrong, the version of moveit2 I was looking at was out of date. #3592 is already ported. I'll keep digging. |
Okay, it looks like |
Yeah, #3041 ports moveit/moveit#3592, but was never back-ported to humble. |
Nice! Just kicked off the backport and it has conflicts. Would you have time to poke at that? |
Ooh, you just beat me to it. I'll fix your PR rather than trying to sort out mine. |
Okay, I'm a bit confused. I've made a PR to your PR branch #3120 Or there's #3119 which I just closed, which is the same PR but directly to the humble branch. I wasn't sure why the humble branch had conflicts; it looks like the last change to the relevant file was a year ago, long before any of the changes in moveit/moveit#3592 |
The diff https://github.com/moveit/moveit2/pull/3119/files is almost identical to the diff https://github.com/moveit/moveit/pull/3592/files, so I think accepting all incoming changes is the right thing to do. |
The backport has been merged, but I think @rr-mark was getting linker issues testing it out. I'll be in work tomorrow so will give it a shot then |
Make sure you guys blow away all the binary installs of MoveIt |
Just got the compilation working and all looks good! No subframe issues. Closing as resolved |
Description
As of #3077,
RobotState::setFromIK()
should allow subframe names as thetip
. This does not appear to have fixed the issue however.ROS Distro
Humble + #3077
OS and version
Ubuntu 22.04 (Docker)
Source or binary build?
Source
If binary, which release version?
N/A
If source, which branch?
humble + #3077
Which RMW are you using?
FastRTPS
Steps to Reproduce
RobotState::setFromIK()
with the subframe name as thetip
Expected behavior
The call should succeed. This is because with #3077, the chain of calls is now
setFromIK()
->getRigidlyConnectedParentLinkModel()
->getFrameInfo()
. The latter function appears to include a search for subframes.Actual behavior
The call fails with the errors given below. The first error message suggests that
getFrameInfo()
is returningfalse
and the second message suggests that this is occuring when querying the pose frameBacktrace or Console output
The text was updated successfully, but these errors were encountered: