Perhaps standardize time as stochastic variable?

E.g. RoME.Pose2 = [t;x;y;theta] etc.

Motivation

Not called Position, Navigation, and Time for nothing.
Current system introduces "timestamp" as a fixed idea where all clocks are somehow globally synchronized -- this is obviously not true.
- https://github.com/JuliaRobotics/DistributedFactorGraphs.jl/blob/master/src/entities/DFGVariable.jl#L186-L187
Most value in several navigation and multi-agent designs will exercise the ability to estimate local clocks.
All GPS receivers estimate time as 4th variable (albeit parametric).
Has previously been done in thesis work [Fourie] though poorly reported.

Problems:

Want to keep it simple for users to expand and develop their own factors

Alternatives

Somehow store time as an "internal" but still stochastic variable, although this might negatively impact performance if not done carefully.

Crazy Town (Factors)

Factors also have stochastic model or observation values p(Z=z), so the "time" a factor is instantiated is quite fuzzy to start with. E.g. receiving a coded transmission has no fixed "time" perhaps only a marker. Fundamentally it is bandwidth vs location of information (Heisenberg) and perhaps worth going a little down that road without losing sight of operational use if the package.

JuliaRobotics / IncrementalInference.jl