-
Notifications
You must be signed in to change notification settings - Fork 803
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
IncrementalFixedLagSmoother with Smart Factors: Marginalization Causes VariableIndex Assertion Failure #1976
Comments
Thanks for assigning me, @varunagrawal ;-) |
@dellaert what I am currently doing (and what I also see implemented in Kimera) is deleting smart factors that reference marginalized poses and rebuilding them without those poses. In scenarios where an environment is being traversed, it may be possible that a landmark stops being visible after some time and that that time just so happens to be within the optimization window, but it is just as likely that a trajectory allows a landmark to be observed during a significant portion of the trajectory. What I expect should happen is that the smart factor logic has a way to deal with partial marginalization, such that a pose can be removed from it to return a partially marginalized smart factor.
|
Yes, I think your intuition is right. Except, there is a possible issue with 1, using the “current estimate”. We might want to use the Jacobian when the factor was first linearized, so called FEJ. See https://pgeneva.com/downloads/papers/Chen2023IROS.pdf Step 2 is really two steps: B involves some work (and unit tests) to even enable the smart factor to allow for that. That is not too hard, I think, but should be done in isolation and tested in a separate PR. Another PR then, however, needs to somehow allow the incremental smoother to call this “fixPose” method on smart factors. It might be worth assuming that
Is already written and see how PR 2 could be done. |
Alternatively, what if smart factors were made to operate with isam2's wildfire threshold, such that they can internally manage what measurements to consider for triangulation. Perhaps if a landmark is already settled/not changing by much, the measurements linked to old pose variables don't need to be considered. Since the fixed-lag smoother is based on isam2, this could be a more far-reaching functionality? |
Hmmm. I think that enabling smart factors to fix poses with their marginalization values is more general, as that could be used with any scheme; fixed lag smoother, iSAM, batch with graph simplification etc. |
So perhaps some implementation that first allows smart factors to internally marginalize poses, and then allows for selection? In an extended isam2 case, a smart factor could virtually cause a batch optimization over its pose history, no? |
A smart factor by itself cannot marginalize a pose, because that pose might be connected to many smart factors. So I think what you need is a method 1st fixPose` at this value: it will then calculate the Jacobian and redefine the error function to add that additional cost. |
Description
When using
IncrementalFixedLagSmoother
withSmartProjectionPoseFactor<Cal3_S2>
, marginalizing out a pose included in a smart factor causes the following assertion failure:gtsam/gtsam/inference/VariableIndex.h:188: gtsam::FactorIndices& gtsam::VariableIndex::internalAt(gtsam::Key): Assertion
item != index_.end()' failed.
Steps to reproduce
I created a unit test for a center-pointing agent, observing a cluster of 5 points:
This is the full output:
Expected behavior
I expect that smart factors should be able to handle references to marginalized poses. If not, then the smart factor would need to be recreated without the marginalized pose.
Environment
I am currently on gtsam commit d48b1fc, on Ubuntu 22.04, and am using C++.
The text was updated successfully, but these errors were encountered: