Tool mounting base frame - #33
Open
gonzalocasas wants to merge 3 commits into
Open
Conversation
`Joint._create` transformed `current_axis` in place instead of recomputing it from `axis`, so it only produced the right answer the first time it ran. Re-initializing the tree of a model that has joints rotated every axis once more — 90 degrees per extra call for a joint whose origin is rotated by 90 degrees. Nothing hit this while models were built or loaded in a single pass, which is why it went unnoticed, but it makes any structural edit followed by a re-initialization silently wrong. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The geometry of a ToolModel had to be modelled in the tool's own base frame, because that frame was hardcoded to the origin: the mesh coordinates *were* the base frame. So a tool drawn the natural way in a CAD document had to be redrawn to mount correctly on a robot. Add `reframe_base`, and a `base_frame` shorthand on the constructor, to state that the flange takes hold of the tool at a given frame instead, re-expressing the tool accordingly. Nothing is baked into the geometry: the frame is folded into the `origin` of the link and joint elements, the same mechanism URDF uses, so it survives serialization and is honoured by every consumer of the model. Tools with joints are re-framed as a whole — the base link's geometry, the joints leaving it, and the TCF all follow — so a gripper keeps articulating around the correct axes. Verified against the 3-link kinematic gripper of compas_fab's ToolLibrary as well. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
10 tasks
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
After endless talks with @yck011522 about what was the correct way to define tool mounting according to ROS-I conventions and also our own experience beyond ROS-I, I believe I have found an approach that is sane, defaults to proper stuff, aligns well with what is intuitive, and it is also backwards compatible (for the most part).
The change is fundamentally simple: rely on the fact that ToolModels are robots, and each link can define its origin (origin==frame in urdf, not just point), so instead of leaving the base origin (ie. frame) empty, we can allow the user to define it, and that will be the mounting plane to whatever end-effector plane is detected on the target robot. This means that tools don't have to be defined in X+ or Z+, they can be defined in whatever the fuck the user feels like, as long as they provide a meaningful base plane. X+ needs a matching base plane, and Z+ would default to the XY world plane, which is the most sensible default for the vast majority of our users.
This PR is only one half of the change. The other is on
compas_faband it includes an automated test with visual verification for mounting tools across robots, planner backends and tool model orientations.What type of change is this?
Checklist
Put an
xin the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.CHANGELOG.mdfile in theUnreleasedsection under the most fitting heading (e.g.Added,Changed,Removed).invoke test).invoke lint).