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
I had many discussions with Mike about this and it looks like a lot of the ugliness on both sides of the curves/continuous scanmatching code base are because of our goal to keep curves and the gtsam library logically separate. Therefore I propose a fix to this.
We should use #ifdef USE_GTSAM to make the library gtsam compatible. This would able only very minimal changes to the library:
It would make the Coefficient class derive from gtsam::DerivedValue<Coefficient>. This already works without any other code modification
It would enable functions within the curve that produce gtsam::Expression objects. This is bleeding edge functionality in gtsam but it would eclipse our use of Evaluator types, it would be fast because every curve could produce information that includes the fixed-sized Jacobians, and it would be simple to work with.
To do this, we have to do the following:
Add a CMake option to enable GTSAM. For now, we can enable by default.
Implement optional functions in the curve that produce Expression types.
* i.e. in a VectorSpaceCurve<3> (a 3D vector space curve) you would have a function like: virtual Expression< Point3 > evaluate(Time time) = 0;. This is the Block Automatic differentiation of an evaluator. Nice bits: we don't have to implement all of these evaluators for different things, and the curves can build the expressions with strong type-size information (so they are fast).
I had many discussions with Mike about this and it looks like a lot of the ugliness on both sides of the curves/continuous scanmatching code base are because of our goal to keep curves and the gtsam library logically separate. Therefore I propose a fix to this.
We should use
#ifdef USE_GTSAM
to make the library gtsam compatible. This would able only very minimal changes to the library:Coefficient
class derive fromgtsam::DerivedValue<Coefficient>
. This already works without any other code modificationgtsam::Expression
objects. This is bleeding edge functionality in gtsam but it would eclipse our use ofEvaluator
types, it would be fast because every curve could produce information that includes the fixed-sized Jacobians, and it would be simple to work with.To do this, we have to do the following:
* i.e. in a
VectorSpaceCurve<3>
(a 3D vector space curve) you would have a function like:virtual Expression< Point3 > evaluate(Time time) = 0;
. This is the Block Automatic differentiation of an evaluator. Nice bits: we don't have to implement all of these evaluators for different things, and the curves can build the expressions with strong type-size information (so they are fast).https://bitbucket.org/gtborg/gtsam/src/2f6165331661f4b52aa545428eeebadf5a98b9d1/gtsam_unstable/nonlinear/Expression.h?at=feature/BAD
https://bitbucket.org/gtborg/gtsam/src/2f6165331661f4b52aa545428eeebadf5a98b9d1/gtsam_unstable/nonlinear/tests/testExpressionFactor.cpp?at=feature/BAD
I'll work with Mike to come up with the right design for this over the next few days. This will simplify everything that happens downstream.
The text was updated successfully, but these errors were encountered: