Proposal distribution inflation

[dehann]

Summary

added

fg = initfg()
getSolverParams(fg).inflation = 3.0 # the default

# and per factor control
addFactor!(fg, ...., inflation=0.01) # or 0 to switch off like before

---

Original Comment

It might be worth experimenting with an option to inject more entropy when calculating proposal distributions before the product step. Likely best to start with default off, but mathematically not expected bias the posterior estimates but rather enhance the reach over the domains when searching for a posterior.

• Increases hit-rate on trivial error Pose3Pose3 trivial failure at rotation [pi;pi;pi] RoME.jl#412

[dehann]

xref JuliaRobotics/RoME.jl#380

[dehann]

Suggestion is to generalize this:

IncrementalInference.jl/src/ApproxConv.jl

Line 399 in c6a8457

addEntropyOnManifoldHack!(addEntrNH, addOps, spreadDist)

will fix less important "hack" aspect after JuliaRobotics/RoME.jl#244 and JuliaRobotics/ApproxManifoldProducts.jl#41 are complete.

[dehann]

decision on unconstrained dimensions with only a partial constraint, whether noise should be added or not. Might be useful as an option that can be turned on or off, and dependent on mechanics inside inference. Perhaps start with default off with intention to switch on when ready.

[dehann]

Hi @Affie , just a FYI that to fix this I have to add DFG.GenericFunctionNodeData.inflation::Float64. Will link separate PR here, and likely need to tag DFG v0.12.0 as a result.

[dehann]

automation closed this too soon

[dehann]

EDIT, deferred and tracked separately, see JuliaRobotics/RoME.jl#412

Likely have to look at relative entropy injection per dimension. e.g. Pose3 test case in RoME results in double peaks on rotations (should just be single around 0):

investigating more.

cc @Affie