You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/src/examples/custom_relative_factors.md
+14-3Lines changed: 14 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,6 +20,17 @@ end
20
20
```
21
21
New relative factors should either inheret from `<:AbstractManifoldMinimize`, `<:AbstractRelativeMinimize`, or `<:AbstractRelativeRoots`. These are all subtypes of `<:AbstractRelative`. There are only two abstract super types, `<:AbstractPrior` and `<:AbstractRelative`.
Relative factors involve computaton, these computations must be performed on some manifold. Custom relative factors require that the [`getManifold`](@ref) function be overridded. Here two examples are given for reference:
@@ -47,7 +58,7 @@ function getSample(cf::CalcFactor{<:Pose2Pose2})
47
58
end
48
59
```
49
60
50
-
The return type for `getSample` is unrestricted, and will be passed to the residual function "as-is".
61
+
The return type for `getSample` is unrestricted, and will be passed to the residual function "as-is", but must return values representing a tangent vector for `<:AbstractRelative`
51
62
52
63
!!! note
53
64
Default dispatches in `IncrementalInference` will try use `cf.factor.Z` to `samplePoint` on manifold (for `<:AbstractPrior`) or `sampleTangent` (for `<:AbstractRelative`), which simplifies new factor definitions. If, however, you wish to build more complicated sampling processes, then simply define your own `getSample(cf::CalcFactor{<:MyFactor})` function.
@@ -70,11 +81,11 @@ function (cf::CalcFactor{<:Pose2Pose2})(X, p, q)
70
81
end
71
82
```
72
83
84
+
It is recommended to leave the incoming types unrestricted. If you must define the types, make sure to allow sufficient dispatch freedom (i.e. dispatch to concrete types) and not force operations to "non-concrete" types. Usage can be very case specific, and hence better to let Julia type-inference automation do the hard work of inferring the concrete types.
85
+
73
86
!!! note
74
87
At present (2021) the residual function should return the residual value as a coordinate (not as tangent vectors or manifold points). Ongoing work is in progress, and likely to return residual values as manifold tangent vectors instead.
75
88
76
-
It is recommended to leave the incoming types unrestricted. If you must define the types, make sure to allow sufficient dispatch freedom (i.e. dispatch to concrete types) and not force operations to "non-concrete" types. Usage can be very case specific, and hence better to let Julia type-inference automation do the hard work of inferring the concrete types.
77
-
78
89
### Serialization
79
90
80
91
Serialization of factors is also discussed in more detail at [Standardized Factor Serialization](@ref factor_serialization).
Copy file name to clipboardExpand all lines: docs/src/examples/using_pcl.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
-
# Pointclouds and PCL Types
1
+
# [Pointclouds and PCL Types](@id pointclouds_and_pcl)
2
2
3
-
## Introduction Caesar._PCL
3
+
## Introduction `Caesar._PCL`
4
4
5
5
A wide ranging and well used [point cloud library exists called PCL](https://pointclouds.org/) which is implemented in C++. To get access to many of those features and bridge the Caesar.jl suite of packages, the base `PCL.PointCloud` types have been implemented in Julia and reside under `Caesar._PCL`. The main types of interest:
Copy file name to clipboardExpand all lines: docs/src/examples/using_ros.md
+13-2Lines changed: 13 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -53,10 +53,21 @@ Distributed.@everywhere using PyCall
53
53
54
54
Caesar.jl has native by optional package tools relating to RobotOS.jl (leveraging [Requires.jl](https://github.com/JuliaPackaging/Requires.jl)):
55
55
```julia
56
-
using RobotOS, Caesar
57
-
Distributed.@everywhereusing Caesar
56
+
using RobotOS
57
+
58
+
@rosimport sensor_msgs.msg: PointCloud2
59
+
60
+
rostypegen()
61
+
62
+
using Colors, Caesar
63
+
Distributed.@everywhereusing Colors, Caesar
58
64
```
59
65
66
+
Colors.jl is added as a conditional requirement to get `Caesar._PCL.PointCloud` support ([see PCL page here](@ref pointclouds_and_pcl)).
67
+
68
+
!!! note
69
+
Imports and type generation are necessary for RobotOS and Caesar to work properly.
70
+
60
71
## Prepare Any Outer Objects
61
72
62
73
Usually a factor graph or detectors, or some more common objects are required. For the example lets just say a basic SLAMWrapper containing a regular `fg=initfg()`:
0 commit comments