fix many docs link errors

docs/src/concepts/available_varfacs.md

@@ -102,4 +102,4 @@ Pose3Pose3XYYaw
 
 # Extending Caesar with New Variables and Factors
 
-A question that frequently arises is how to design custom variables and factors to solve a specific type of graph. One strength of Caesar is the ability to incorporate new variables and factors at will. Please refer to [Adding Factors](adding_variables_factors.md) for more information on creating your own factors.
+A question that frequently arises is how to design custom variables and factors to solve a specific type of graph. One strength of Caesar is the ability to incorporate new variables and factors at will. Please refer to [Adding Factors](../examples/adding_variables_factors.md) for more information on creating your own factors.

docs/src/concepts/concepts.md

@@ -137,6 +137,6 @@ It might also be convenient to warm up some of the Just-In-Time compiling:
 
 The best way to avoid compile time (when not developing) is to use the established Julia "first time to plot" approach based on PackageCompiler.jl, and more details are provided at [Ahead of Time compiling](https://juliarobotics.org/Caesar.jl/latest/installation_environment/#Ahead-Of-Time-Compile-RoME.so), and a few common questions might be answered via [FAQ here](https://juliarobotics.org/Caesar.jl/latest/faq/#Static,-Shared-Object-.so-Compilation).
 
-The next section describes the initial steps in constructing and solving graphs will be discussed in the upcoming documentation page [Building and Solving Graphs](building_graphs.md).  We also recommend reviewing the various examples available in the [Examples section](../examples/examples.md).  The variables and factors in Caesar should be sufficient for the majority of robotic applications, however Caesar allows users to extend the framework without changing the core code. This is discussed in [Creating New Variables and Factors](adding_variables_factors.md).  Caesar supports both in-memory solving (fast, for moderately-sized graphs) as well as [shared data persistence and inference](database_interactions.md) for massive graphs, multiple sessions, and multiple agents.
+The next section describes the initial steps in constructing and solving graphs will be discussed in the upcoming documentation page [Building and Solving Graphs](building_graphs.md).  We also recommend reviewing the various examples available in the [Examples section](../examples/examples.md).  The variables and factors in Caesar should be sufficient for the majority of robotic applications, however Caesar allows users to extend the framework without changing the core code. This is discussed in [Creating New Variables and Factors](../examples/adding_variables_factors.md).  Caesar supports both in-memory solving (fast, for moderately-sized graphs) as well as [shared data persistence and inference](database_interactions.md) for massive graphs, multiple sessions, and multiple agents.
 
 Although Caesar is Julia-based, it provides multi-language support with a ZMQ interface. This is discussed in [Caesar Multi-Language Support](multilang.md).  Caesar.jl also supports various visualizations and plots by using Arena, RoMEPlotting, and Director. This is discussed in [Visualization with Arena.jl and RoMEPlotting.jl](arena_visualizations.md).

docs/src/examples/basic_continuousscalar.md

@@ -17,7 +17,7 @@ using IncrementalInference
 # using Distributions # automatically reexported by IncrementalInference
 ```
 
-Guidelines for developing your own functions are discussed here in [Adding Variables and Factors](../concepts/adding_variables_factors.md), and we note that mechanizations and manifolds required for robotic simultaneous localization and mapping (SLAM) has been tightly integrated with the expansion package [RoME.jl](http://www.github.com/dehann/RoME.jl).
+Guidelines for developing your own functions are discussed here in [Adding Variables and Factors](../examples/adding_variables_factors.md), and we note that mechanizations and manifolds required for robotic simultaneous localization and mapping (SLAM) has been tightly integrated with the expansion package [RoME.jl](http://www.github.com/dehann/RoME.jl).
 
 The next step is to describe the inference problem with a graphical model with any of the existing concrete types that inherit from  `<: AbstractDFG`.
 The first step is to create an empty factor graph object and start populating it with variable nodes.
@@ -36,7 +36,7 @@ Factor graphs are bipartite graphs with `factors` that act as mathematical struc
 After adding node `:x0`, a singleton factor of type `Prior` (which was defined by the user earlier) is 'connected to' variable node `:x0`.
 This unary factor is taken as a `Distributions.Normal` distribution with zero mean and a standard devitation of `1`.
 `Graphviz` can be used to visualize the factor graph structure, although the package is not installed by default -- `$ sudo apt-get install graphviz`.
-Furthermore, the `writeGraphPdf` member definition is given at the end of this tutorial, which allows the user to store the graph image in graphviz supported image types.
+Furthermore, the [`drawGraph`](@ref) member definition is given at the end of this tutorial, which allows the user to store the graph image in graphviz supported image types.
 ```julia
 drawGraph(fg, show=true)
 ```

docs/src/examples/basic_definingfactors.md

@@ -99,7 +99,7 @@ The `cfo` object contains the field `.factor::T` which is the type of the user f
 
 Previously we looked at adding a prior.  This section demonstrates the first of two `<:AbstractRelative` factor types.  These are factors that introduce only relative information between variables in the factor graph.
 
-This example is on `<:AbstractRelativeRoots`.  First, lets create the factor as before 
+This example is on `<:IIF.AbstractRelativeRoots`.  First, lets create the factor as before 
 ```julia
 struct MyFactor{T <: SamplableBelief} <: IIF.AbstractRelativeRoots
   Z::T
@@ -116,9 +116,9 @@ end
 ```
 
 
-The selection of `<:AbstractRelativeRoots`, akin to earlier `<:AbstractPrior`, instructs IIF to find the roots of the provided residual function.  That is the one dimensional residual function, `res[1] = measurement - prediction`, is used during inference to approximate the convolution of conditional beliefs from the approximate beliefs of the connected variables in the factor graph.
+The selection of `<:IIF.AbstractRelativeRoots`, akin to earlier `<:AbstractPrior`, instructs IIF to find the roots of the provided residual function.  That is the one dimensional residual function, `res[1] = measurement - prediction`, is used during inference to approximate the convolution of conditional beliefs from the approximate beliefs of the connected variables in the factor graph.
 
-Important aspects to note, `<:AbstractRelativeRoots` requires all elements `length(res)` (the factor measurement dimension) to have a feasible zero crossing solution.  A two dimensional system will solve for variables where both `res[1]==0` and `res[2]==0`.
+Important aspects to note, `<:IIF.AbstractRelativeRoots` requires all elements `length(res)` (the factor measurement dimension) to have a feasible zero crossing solution.  A two dimensional system will solve for variables where both `res[1]==0` and `res[2]==0`.
 
 !!! note
     As of IncrementalInference v0.21, CalcResidual no longer takes a residual as input parameter and should return residual, see IIF#467.
@@ -128,7 +128,7 @@ Important aspects to note, `<:AbstractRelativeRoots` requires all elements `leng
 
 ### Two Dimension Minimize Example
 
-The second type is `<:AbstractRelativeMinimize` which simply minimizes the residual vector of the user factor. This type is useful for partial constraint situations where the residual function is not gauranteed to have zero crossings in all dimensions and the problem is converted into a minimization problem instead:
+The second type is `<:IIF.AbstractRelativeMinimize` which simply minimizes the residual vector of the user factor. This type is useful for partial constraint situations where the residual function is not gauranteed to have zero crossings in all dimensions and the problem is converted into a minimization problem instead:
 ```julia
 struct OtherFactor{T <: SamplableBelief} <: IIF.AbstractRelativeMinimize
   Z::T             # assuming something 2 dimensional
@@ -171,7 +171,7 @@ MyMagnetoPrior(z) = MyMagnetoPrior(z, (3,))
 getSample(cfo::CalcFactor{<:MyMagnetoPrior}, N::Int=1) = (reshape(rand(cfo.factor.Z,N),1,N),)
 ```
 
-Similarly for `<:AbstractRelativeMinimize`, and note that the Roots version currently does not support the `.partial` option.
+Similarly for `<:IIF.AbstractRelativeMinimize`, and note that the Roots version currently does not support the `.partial` option.
 
 ### Metadata
 
@@ -247,26 +247,26 @@ See the [parametric solve section](@ref parametric_factors)
 All factors inherit from one of the following types, depending on their function:
 * AbstractPrior: AbstractPrior are priors (unary factors) that provide an absolute constraint for a single variable. A simple example of this is an absolute GPS prior, or equivalently a (0, 0, 0) starting location in a [`Pose2`](@ref) scenario.
   * Requires: A getSample function
-* AbstractRelativeMinimize: AbstractRelativeMinimize are relative factors that introduce an algebraic relationship between two or more variables. A simple example of this is an odometry factor between two pose variables, or a range factor indicating the range between a pose and another variable.
+* IIF.AbstractRelativeMinimize: IIF.AbstractRelativeMinimize are relative factors that introduce an algebraic relationship between two or more variables. A simple example of this is an odometry factor between two pose variables, or a range factor indicating the range between a pose and another variable.
   * Requires: A getSample function and a residual function definition
   * The minimize suffix specifies that the residual function of this factor will be enforced by numerical minimization (find me the minimum of this function)
-* AbstractRelativeRoots: AbstractRelativeRoots are relative factors that introduce algebraic relationships between two or more variables. They are the same as AbstractRelativeMinimize, however they use root finding to find the zero crossings (rather than numerical minimization).
+* IIF.AbstractRelativeRoots: IIF.AbstractRelativeRoots are relative factors that introduce algebraic relationships between two or more variables. They are the same as IIF.AbstractRelativeMinimize, however they use root finding to find the zero crossings (rather than numerical minimization).
   * Requires: A getSample function and a residual function definition
 
 How do you decide which to use?
 * If you are creating factors for world-frame information that will be tied to a single variable, inherit from `<:AbstractPrior`
   * GPS coordinates should be priors
-* If you are creating factors for local-frame relationships between variables, inherit from AbstractRelativeMinimize
+* If you are creating factors for local-frame relationships between variables, inherit from IIF.AbstractRelativeMinimize
   * Odometry and bearing deltas should be introduced as pairwise factors and should be local frame
-TBD: Users should start with AbstractRelativeMinimize, discuss why and when they should promote their factors to AbstractRelativeRoots.
+TBD: Users should start with IIF.AbstractRelativeMinimize, discuss why and when they should promote their factors to IIF.AbstractRelativeRoots.
 
 !!! note
-    AbstractRelativeMinimize does not imply that the overall inference algorithm only minimizes an objective function. The Multi-model iSAM algorithm is built around fixed-point analysis. Minimization is used here to locally enforce the residual function.
+    IIF.AbstractRelativeMinimize does not imply that the overall inference algorithm only minimizes an objective function. The Multi-model iSAM algorithm is built around fixed-point analysis. Minimization is used here to locally enforce the residual function.
 
 What you need to build in the new factor:
 * A struct for the factor itself
 * A sampler function to return measurements from the random ditributions
-* If you are building a [`AbstractRelativeMinimize`](@ref) or a [`AbstractRelativeRoots`](@ref) you need to define a residual function to introduce the relative algebraic relationship between the variables
+* If you are building a [`IIF.AbstractRelativeMinimize`](@ref) or a [`IIF.AbstractRelativeRoots`](@ref) you need to define a residual function to introduce the relative algebraic relationship between the variables
   * Minimization function should be lower-bounded and smooth
 * A packed type of the factor which must be named Packed[Factor name], and allows the factor to be packed/transmitted/unpacked
 * Serialization and deserialization methods
@@ -278,6 +278,6 @@ What you need to build in the new factor:
 An example of this is the [`Pose2Point2BearingRange`](@ref), which provides a bearing+range relationship between a 2D pose and a 2D point.
 
 ```@docs
-AbstractRelativeMinimize
-AbstractRelativeRoots
+IIF.AbstractRelativeMinimize
+IIF.AbstractRelativeRoots
 ```

docs/src/examples/examples.md

@@ -132,4 +132,4 @@ Caesar can be extended with new variables and factors without changing the core
 
 ### Adding Factors - DynPose Factor
 
-[Intermediate Example: Adding Dynamic Factors and Variables](interm_dynpose.md)
+[Intermediate Example: Adding Dynamic Factors and Variables](../principles/interm_dynpose.md)

docs/src/examples/parametric_solve.md

@@ -50,6 +50,6 @@ end
 The factor is evaluated in a cost function using the Mahalanobis distance and the measurement should therefore match the residual returned.  
 
 ### Optimization
-[`solveGraphParametric!`](@ref) uses Optim.jl. The factors that are supported should have a gradient and Hessian available/exists and therefore it makes use of `TwiceDifferentiable`. Full control of Optim's setup is possible with keyword arguments.  
+[`IncrementalInference.solveGraphParametric!`](@ref) uses Optim.jl. The factors that are supported should have a gradient and Hessian available/exists and therefore it makes use of `TwiceDifferentiable`. Full control of Optim's setup is possible with keyword arguments.  
 
 

docs/src/principles/approxConvDensities.md

@@ -57,27 +57,23 @@ Or minimization of "low dimension" equations ([source code here](https://github.
 The factor noise term can be any samplable belief (a.k.a. [`IIF.SamplableBelief`](https://github.com/JuliaRobotics/IncrementalInference.jl/blob/2b9f1c3d03e796bc24fbcc622329769dadd94288/src/DefaultNodeTypes.jl#L3)), either through algebraic modeling, or (**critically**) directly from the sensor measurement that is driven by the underlying physics process.  Parametric factors ([Distributions.jl](https://github.com/JuliaStats/Distributions.jl)) or direct physical measurement noise can be used via `AliasingScalarSampler` or `KernelDensityEstimate`.
 
 !!! note
-
     Also see [[1.2], Chap. 5, Approximate Convolutions](https://juliarobotics.org/Caesar.jl/latest/refs/literature/#Direct-References-1) for more details.
 
 ### Illustrated Calculation in Julia
 
 The [IncrementalInference.jl](http://www.github.com/JuliaRobotics/IncrementalInference.jl) package provides a generic interface for estimating the convolution of full functional objects given some user specified residual or cost function.  The residual/cost function is then used, with the help of non-linear gradient decent, to project/resolve a set of particles for any one variable associated with a any factor.  In the binary variable factor case, such as the odometry tutorial, either pose X2 will be resolved from X1 using the user supplied likelihood residual function, or visa versa for X1 from X2.  
 
 !!! note
-
     Note in a factor graph sense, the flow of time is captured in the structure of the graph and a requirement of the IncrementalInference system is that factors can be resolved towards any variable, given current estimates on all other variables connected to that factor.  Furthermore, this forwards or backwards resolving/convolution through a factor should adhere to the Kolmogorov Criterion of reversibility to ensure that detailed balance is maintained in the overall marginal posterior solutions.
 
 The IncrementalInference (IIF) package provides a few generic conditional likelihood functions such as `LinearRelative` or `MixtureRelative` which we will use in this illustration.  
 
 !!! note
-
-    Note that the [RoME.jl](http://www.github.com/JuliaRobotics/RoME.jl) package provides many more factors that are useful to robotics applications.  For a listing of current factors see [this docs page](http://www.juliarobotics.org/Caesar.jl/latest/concepts/available_varfacs.md), details on developing [your own factors on this page](http://www.juliarobotics.org/Caesar.jl/latest/concepts/adding_variables_factors.md).  One of the clear design objectives of the IIF package was to allow easier user extension of arbitrary residual functions that allows for vast capacity to represent non-Gaussian stochastic processes.
+    Note that the [RoME.jl](http://www.github.com/JuliaRobotics/RoME.jl) package provides many more factors that are useful to robotics applications.  For a listing of current factors see [this docs page](../concepts/available_varfacs.md), details on developing [your own factors on this page](http://www.juliarobotics.org/Caesar.jl/latest/concepts/adding_variables_factors.md).  One of the clear design objectives of the IIF package was to allow easier user extension of arbitrary residual functions that allows for vast capacity to represent non-Gaussian stochastic processes.
 
 Consider a robot traveling in one dimension, progressing along the x-axis at varying speed.  Lets assume pose locations are determined by a constant delta-time rule of say one pose every second, named `X0`, `X1`, `X2`, and so on.
 
 !!! note
-
     Note the bread-crum discretization of the trajectory history by means of poses can later be used to allow estimation of previously unknown mapping parameters simultaneous to the ongoing localization problem.
 
 Lets a few basic factor graph operations to develop the desired convolutions: