search

borglab / GTDynamics

Full kinodynamics constraints for arbitrary robot configurations with factor graphs.
BSD 2-Clause "Simplified" License
39 stars 10 forks source link

Optional parent and child link keys for `poseConstraint` #365

Closed varunagrawal closed 1 year ago

varunagrawal commented 1 year ago

This will allow us to specify custom keys as passed to the second constructor of PoseFactor.

varunagrawal commented 1 year ago

Also, more generally, it seems odd that there should be cases when you are using a joint's pose calculations but not using the same keys as the parent/child links (some inconsistency), but maybe this is because some other code has previously used certain keys for links and you don't want to interfere with that or something?

This is because for the base link of a robot I am using a GTSAM key X(t) and not a GTD key, so the key value (as an int) doesn't match what PoseKey(base_link->id(), t) will return. I think of keys as symbolic pointers (like a person's name) so I can ask the joint for a result but I can refer to its links by a different names right?

I also decided to add this since it allows for greater flexibility. E.g. GPMP2 was written before GTD but could benefit from GTD. I can now use GTD features but keep changes to GPMP2 to a minimum, especially for someone like Matt who knows GTSAM well but isn't acquainted with the key structure (aka DynamicsSymbol) of GTD.

varunagrawal commented 1 year ago

This was accidentally closed. :(

@yetongumich

varunagrawal commented 1 year ago

@yetongumich please don't merge PRs until the parent PR is reviewed and approved. This makes reviewing harder since now @gchenfc has to figure out what changed.