-
Notifications
You must be signed in to change notification settings - Fork 21
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
bug on approxConv through partial relative factor #1246
Comments
when Maybe should consolidate these two function calls? IncrementalInference.jl/src/ApproxConv.jl Lines 341 to 349 in f37ef01
IncrementalInference.jl/src/ApproxConv.jl Lines 298 to 316 in f37ef01
IncrementalInference.jl/src/ApproxConv.jl Lines 62 to 121 in f37ef01
|
On partial factors, it may be easier to provide the residual function directly instead of the dimension. A (crude) example would be: bel = AliasingScalarSampler(qr, pv)
plr = PartialLinearRelative(bel, (1,))
addFactor!(fg, [:x0, :x1], plr, tags=[:TERRAIN,:MATCH,:NORTH]) replacing the factor (line 2) with: f(x, y)=x[2]-y[2]
plr = PartialLinearRelative(bel, f) This may generalize better as you move towards manifold elements for variables |
would it be sensible to have a function that just returns the partial dimensions instead? E.g. plr = PartialLinearRelative(..., (p)->p[2]) and let the factor residual functions handle the calculation mechanics? I'm thinking about avoiding duplicate definitions of the residual mechanics... an example might be horizontal only range on pose3, which means a lookup function (p)->view(p,1:2) or perhaps heading-only factor on a Pose3Quat (p)->Circle(convert(YAW, p.rotation) assuming p is a point on the manifold and all other interesting data wrangling considerations in-toe. xref #1242 ah, another problem is that indexing in (especially on manifold conversions) is that the answer out should influence the original data (not simply an inverse function per se). |
I'm going to walk back my original suggestion and say I'm not convinced a function is the way to go (at least for a Your two examples - horizontal range and heading-only constraints - would normally not be implemented as generic partials, right? |
Correct, the way I have it at this time is to implement the partial mechanics in a dedicated factor. The See also: JuliaRobotics/Caesar.jl#680 (comment) |
think this issue should be fixed with the partial factor fixes in v0.32.0. A factor manifold now just represents the partial manifold, ie zDim is only the dimension of the partial manifold representing the factor measurements. A bearing only would be dimension 1. At present, the inference implementation (at least for nonparametric) is still defining the partial dimensions on the coordinates. More work is needed to consolidate partials through projection or embedding functions between the connected factors and that of the factor manifold itself. |
MWE
https://github.com/JuliaRobotics/Caesar.jl/blob/7167be93d3eef646ff6293e8398f8dfca7c8ef60/examples/dev/scalar/boxy.jl#L280
The text was updated successfully, but these errors were encountered: