A factor graph is bipartite: variable nodes (poses, landmarks, calibration parameters, biases) and factor nodes (measurements, priors), with an edge wherever a factor depends on a variable. The posterior is the product of the factors, and the negative log posterior is the sum of squared residuals from the previous topic.
The correspondence to the linear algebra is exact:
| Graph | Information matrix |
|---|---|
| variable | diagonal block |
| factor between and | off-diagonal block |
| no shared factor | structural zero |
| eliminating a variable | Schur complement on its neighbours |
The Schur complement, and why bundle adjustment uses it
-
Order the variables poses-first, landmarks-second. H_ll is block-diagonal: no factor connects two landmarks directly.
-
Solve the lower block for the landmarks. Inverting H_ll is cheap precisely because it is block-diagonal — one small inverse per landmark.
-
Substitute back. The reduced camera system involves only the poses, of which there are far fewer than landmarks.
-
The price. The reduced matrix is denser than the original: eliminating a landmark connects every pose that observed it. Ordering the elimination to minimise this is what a good sparse solver spends its time on.
Why do incremental smoothers re-order variables rather than just appending new ones?
Show answer
Because fill-in depends on elimination order, and the best order changes as the graph grows. Appending naively produces a factorisation with steadily worse sparsity, so the cost per update creeps up until it dominates. Incremental systems (iSAM2 and relatives) re-eliminate only the affected subtree and periodically re-order, keeping the factorisation close to what a batch solve with a good ordering would have produced — which is what makes the update cost track the size of the change rather than the size of the map.