Also, we need to remove the registration calls from the Node::link() places.
And take care to update the places where Frames become Kfs and vice-versa.
How is this compatible with registerStateBlocks()? Could it happen that when calling it some of them are already registered? Is it an issue? We have to check if registering twice a stateblock is a problem.
Yes, registerStateBlocks() should check and not re-register SB's that are already registered, or pending for registration. I don't know how to do it, though. Is it possible with the current design?
Regarding notifications, the function problem->notifyStateBlock() already checks if a previous notification exists.
inlinewolf::StateBlockPtrHasStateBlocks::addStateBlock(conststd::string&_sb_type,constStateBlockPtr&_sb,ProblemPtr_problem){assert(state_block_map_.count(_sb_type)==0&&"Trying to add a state block with an existing type! Use setStateBlock instead.");state_block_map_.emplace(_sb_type,_sb);if(!isInStructure(_sb_type))appendToStructure(_sb_type);// conditionally register to problemNotificationnotification;if(_problem)_problem->notifyStateBlock(pair_key_sbp.second,ADD);return_sb;}
Modify HasStateBlocks::addStateBlock(key, sb) --> (key, sb, problem). If problem is not nullptr, register the SB.
Keep registerStateBlocks() as is. It is still required.
In FrameBase, overload addStateBlock(key, sb).
If KF, then use getProblem() to pass to addStateBlock(key, sb, getProblem()). Else, pass nullptr.
Keep using registerStateBlocks() since sometimes (e.g. in the constructor) the SB are added but there is no Problem yet. Registration will be made as before at the time of emplacing / linking.
In SensorBase, overload addStateBlock(key, sb). This is related to the dynamic state blocks that may end up in Captures.
In the implementation, use getProblem() to pass to the base addStateBlock(key, sb, getProblem())
Write a couple of tests for registration issues:
Make a Frame and link it to Problem -> SBs not registered
Set it keyframe -> SBs registered
Make a new Frame and link it to Problem -> SBs not registered
Just one thing to clarify, Problem doesn't keep a list of state blocks and factors registered to the solver (maybe it should), it just keeps the notifications that are pending to be consumed by the solver.
In other words:
problem->notifyStateBlock(sb1, ADD) -> notifies the addition of sb1 (stored in notifications in Problem)
problem->notifyStateBlock(sb1, ADD) -> duplicated addition handled by Problem since the solver hasn't been notified yet.
solver->update() -> notifications from Problem are consumed, i.e. no notifications remains
problem->notifyStateBlock(sb1, ADD) -> duplicated addition handled by Solver (I don't know if an error is thrown)
Two comments:
I don't think registerStateBlocks() can be removed, this functionality is still required.
Maybe a copy of the state blocks and factors registered in the solver should be also stored in problem, to properly check this duplicated addition or removal of not registered state block.