-
Notifications
You must be signed in to change notification settings - Fork 503
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
[Servo] Change planning frame to base frame of active joint subgroup #2515
Merged
Merged
Changes from 1 commit
Commits
Show all changes
12 commits
Select commit
Hold shift + click to select a range
09eb17e
Change planning frame to base of active subgroup
sea-bass b741853
Make function to get IK base frame
sea-bass f003315
Catch tf2 exception nearer to actual code, use std::optionals
sea-bass 5612d88
Remove ee_frame and planning_frame params
sea-bass 7601fc6
PR comments
sea-bass 0c134b7
Merge remote-tracking branch 'origin/main' into fix-servo-subgroup-cmds
sea-bass b20b14e
Helper function doesn't need to be public actually
sea-bass daf5f6f
Weird clang-tidy style changes
sea-bass 85a382f
Move test fixture code from constructors to setup
sea-bass b193aa4
Merge branch 'main' into fix-servo-subgroup-cmds
sea-bass db97165
PR comments: errors and comments
sea-bass 0ad1d85
Merge branch 'main' into fix-servo-subgroup-cmds
sea-bass File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a better way to get the base link of a joint model group without having to grab the IK solver like this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't you do this?
But now I wonder if you rather need the IK solver base frame (i.e. your code as is), since the underlying IK solver could be working on a different frame, not necessarily the group root?
If that's the case, maybe create a
getIKSolverBaseFrame()
function that can be called here and below?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
This raises a follow up question that, if these changes are the right thing for changing subgroups, can we actually get rid of the planning frame parameter and have servo always do its own internal conversions to active group's IK base frame?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm.. looking deeper into Servo I got more confused about what the 'planning frame' is, but also how this fix works, since the IK base frame for the manipulator group is the one tilted 45 deg. right? so I would expect this to still move the wrong way.
Another q: the command has a
frame_id
. Shouldn't that be all that is needed to move in the same frame (e.g.world
), independently of the active group? Sorry I have more questions than answers!There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should have more questions than answers, I think there's a lot here that needs to be disentangled for clarity.
Basically, Servo has this rule that enforces that all commands passed into it are expressed w.r.t. a common frame -- this is the "planning frame" we speak of.
All we're trying to do, perhaps in an overly complex way, is the following:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... I just saw some other piece of code that reminded me of the fact that a planning group can have multiple tip frames. So can we really get rid of
moveit_params.ee_frame
after all?The other alternative, which is way more destructive, would be to modify the command message definitions for twist and pose tracking to contain both base and tip frames... which would basically require making custom messages for both instead of relying on existing
geometry_msgs
definitions.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can, at least the way it is now, because
ee_frame
doesn't seem to be used anywhere. The IK computation is done forik_solver->getTipFrame()
, so it will always use the first tip.Longer term what about having Servo expose a
/configure
service, where the user could set the planning group and tip frame?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given all the struggles we've had trying to make sure that parameters stay consistent w.r.t. each other, I quite like the idea of dedicated services that touch these interrelated parameters like planning group + ee frame.
Also, having this
configure
service / method means that configuring can implicitly do the task of pausing servo, changing values, and then unpausing it.Also, I guess to be fair this code was calling
getTipFrame()
already, and also there is an error logged when you callgetTipFrame()
on a planning group with multiple tips.So maybe this is just a known limitation for now and we proceed as is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A service to update the parameters might be a good idea b/c it would fix this issue: #2412
i.e. do the parameter validation in a callback in a different thread
Hate to change the API so drastically, so soon, though. Have to think carefully about this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think servo has changed enough with the refactor since we kept running into limitations trying to keep the API as stable as possible with the old version. It might be beneficial to do all the big changes as soon as possible in hopes that we get to a somewhat more stable API before people actually start using this new version.
That said, we should try do all this in a way that minimizes our need to keep twiddling the interfaces going forward.