• Transform composition, inverse, 'division', etc.
• Rotation ".
• Transforming points.
• Using covariances.

Add a build target to generate the Doxygen HTML and PDF output.

Write a top-level README that explains high-level use of lgmath.

When reprojecting the matrix

|-1 0 0 |
| 0 1 0 |
| 0 0 -1|

with small epsilons on the off-diagonal terms it becomes identity. We should add a unit test and resolve the error.

Error:

CMake Warning (dev) at /home/jc/src/utiasASRL/lgmath/src/deps/catkin/catkin_optional/cmake/catkin_optional-extras.cmake:127 (get_target_property):
  Policy CMP0045 is not set: Error on non-existent target in
  get_target_property.  Run "cmake --help-policy CMP0045" for policy details.
  Use the cmake_policy command to set the policy and suppress this warning.

  get_target_property() called with non-existent target "lgmath".
Call Stack (most recent call first):
  CMakeLists.txt:34 (co_export)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at tests/CMakeLists.txt:10 (project):
  Policy CMP0048 is not set: project() command manages VERSION variables.
  Run "cmake --help-policy CMP0048" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.

  The following variable(s) would be set to empty:

    PROJECT_VERSION
This warning is for project developers.  Use -Wno-dev to suppress it.

A reference to the definition in Tim's textbook for each applicable function.

Not sure if it's wanted, but:

lgmath::se3::Transformation test2(Eigen::Matrix4d::Identity());

won't compile and yield:

home/frank/research/code/lgmath/tests/TransformTests.cpp:59:66: error: call of overloaded ‘Transformation(const IdentityReturnType)’ is ambiguous
     lgmath::se3::Transformation test2(Eigen::Matrix4d::Identity());
                                                                  ^
/home/frank/research/code/lgmath/tests/TransformTests.cpp:59:66: note: candidates are:
In file included from /home/frank/research/code/lgmath/tests/TransformTests.cpp:20:0:
/home/frank/research/code/lgmath/include/lgmath/se3/Transformation.hpp:73:12: note: lgmath::se3::Transformation::Transformation(const VectorXd&)
   explicit Transformation(const Eigen::VectorXd& xi_ab);
            ^
/home/frank/research/code/lgmath/include/lgmath/se3/Transformation.hpp:67:3: note: lgmath::se3::Transformation::Transformation(const Eigen::Matrix<double, 6, 1>&, unsigned int)
   Transformation(const Eigen::Matrix<double,6,1>& xi_ab, unsigned int numTerms = 0);
   ^
/home/frank/research/code/lgmath/include/lgmath/se3/Transformation.hpp:57:12: note: lgmath::se3::Transformation::Transformation(const Matrix4d&)
   explicit Transformation(const Eigen::Matrix4d& T);

Hi, developer! I wanne to ask a question about Could I omit the ament_cmake when installing lgmath? Cause I am a normal user of ROS1 Noetic, I don't have ament_cmake before. And When I try to install lgmath. I get an error in following:
"CMake Error at CMakeLists.txt:80 (find_package):
By not providing "Findament_cmake.cmake" in CMAKE_MODULE_PATH this project
has asked CMake to find a package configuration file provided by
"ament_cmake", but CMake did not find one.

Could not find a package configuration file provided by "ament_cmake" with
any of the following names:

ament_cmakeConfig.cmake
ament_cmake-config.cmake

Add the installation prefix of "ament_cmake" to CMAKE_PREFIX_PATH or set
"ament_cmake_DIR" to a directory containing one of the above files. If
"ament_cmake" provides a separate development package or SDK, be sure it
has been installed.
"

According to the readme, the master branch should have USE_AMENT=OFF
Only the ros2-master should have USE_AMENT=ON

This is partly done in #31, just splitting it into a different PR from the C++11 upgrade.

We really should change functions that accept const Eigen::Type & to use const Eigen::Ref<Eigen::Type>& as recommended by Eigen documentation.

This unifies Eigen::Matrix and Eigen::Map, to avoid an additional copy.

• Transformation * TransformationWithCovariance should have the same return type as TransformationWithCovariance * Transformation.
• There should be a RotationWithCovariance.
• Think about how we're going to handle points with uncertainty.

Ran into this making an example while sleepy. We should anticipate users doing things wrong.

Code Sample

#include <iostream>

#include <lgmath/lgmath.hpp>
#include <Eigen/Core>

int main() {
  // Create a transformation.
  Eigen::Matrix<double, 6, 1> transformation_vector;
  transformation_vector << 2.0, 0.0, 0.0, 0.0, 0.0, 0.0;
  lgmath::se3::Transformation transformation(transformation_vector);

  // Try to transform a non-homogeneous point.
  Eigen::Vector4d point;
  point << 1.0, 2.0, 3.0, 0.0;
  std::cout << "Point after transformation:\n" << transformation * point << "\n";
}

Expected Output

Some error message.

Actual Output

Point after transformation:
1
2
3
0

Solution

Could either:

1. Throw an exception, or
2. Change the interfaces to take Eigen::Vector3d.

Move the python implementation of Transform from vtr2/asrl__pose_graph to lgmath (and fix it up). Alternatively, write a C++ binding for python to replace it.

Low priority (covered in Tim's book, could make it more accessible)

• Explain Lie groups at a very high level w/ diagrams.
• The advantages of the Lie group perspective for optimizing transformations. ("Why shouldn't I just use Eigen's Geometry module".)
• It currently supports 3D problems: SO(3) and SE(3).

Previously, lgmath referred to points simply as Eigen::Vector4d. Now that we're interested in transforming the covariance associated with a point, it makes sense to formalize the interface for points a bit.

These seem obvious:

typedef Eigen::Vector4d HPoint;
typedef Eigen::Matrix3d Covariance;

To simplify transformations of points together with covariance, we could add

struct HPointWithCovariance {
  HPoint point_;
  Covariance covariance_;
  EIGEN_MAKE_ALIGNED_OPERATOR_NEW // Because HPoint is 16-byte vectorizable
  bool covarianceSet_;
};

---but do we micromanage the covarianceSet_ variable as in TransformWithCovariance? Or just leave it as a public struct member set/checked by the user (obviously set appropriately by the applied transform)?

Also, for a larger number of points we want to transform together, this seems obvious:

typedef Eigen::Matrix<double,4,Eigen::Dynamic> HPointCloud;

But should we have something like this:

struct HPointCloudWithCovariance {
  HPointCloud points_;
  std::vector<Covariance> covariances_;
  bool covariancesSet_;
};

---or should it be typedef Eigen::Matrix<double,9,Eigen::Dynamic> Covariances;, and Covariances covariances_;? The latter keeps memory management within Eigen, and to access one directly, you use Eigen::Map<Covariance>(covariances_.col(i).data());. This mostly depends on our preferred storage for example, for landmarks. If we're going to store them in a std::vector<Landmarks>, then Eigen::Map<Covariances, 0, sizeof(Landmark)>(first_cov_pointer,9,num_cov) will let us map directly onto those, but std::vector<Covariance> will not.

Thoughts?

@mpaton @kaivanes

Just to log somewhere that SO2 and SE2 are not implemented

See todos:
https://github.com/utiasASRL/lgmath/blob/develop/include/lgmath.hpp#L12

Add Doxygen documentation for the parameters and return values of every function. Clang has a great -Wdocumentation warning, I'll see if GCC has something similar.

Completed Files

• ./include/lgmath/CommonTools.hpp
• ./include/lgmath/se3/Types.hpp
• ./include/lgmath/se3/Transformation.hpp
• ./include/lgmath/se3/Operations.hpp
• ./include/lgmath/se3/TransformationWithCovariance.hpp
• ./include/lgmath/so3/Types.hpp
• ./include/lgmath/so3/Operations.hpp
• ./include/lgmath/so3/Rotation.hpp
• ./include/lgmath/CommonMath.hpp
• ./include/lgmath/r3/Types.hpp
• ./include/lgmath/r3/Operations.hpp
• ./include/lgmath.hpp
• ./src/CommonMath.cpp
• ./src/se3/Operations.cpp
• ./src/se3/Transformation.cpp
• ./src/se3/TransformationWithCovariance.cpp
• ./src/so3/Rotation.cpp
• ./src/so3/Operations.cpp
• ./src/r3/Operations.cpp

• The reproject function called in lgmath::se3::Transformation's constructor (and other spots) is conditioned on det(C) = 1 but this is not a sufficient check to determine if C is in SO(3)
• Therefore, users could create a Transformation with C_ab_ = diag(2,0.5,1), for example
• Even when constructed properly, round-off error can stack up in rare cases if matrix is never forcibly reprojected
• May want to add check that C^T * C = 1, if computationally feasible

Fix #31 so it's able to be merged.