Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

correct coefficients of approximated SE3 Q_r #507

Merged
merged 6 commits into from
Sep 26, 2020

Conversation

JzHuai0108
Copy link
Contributor

No description provided.

@jlblancoc
Copy link
Member

Thanks! A unit test that first fails, then passes with your fix would be great ;-)

@JzHuai0108
Copy link
Contributor Author

Alright. I will add a unit test soon.

@varunagrawal varunagrawal added the bugfix Fixes an issue or bug label Sep 3, 2020
Copy link
Member

@dellaert dellaert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome. Two small nits, but a real question about the test.

@@ -181,6 +181,9 @@ class GTSAM_EXPORT Pose3: public LieGroup<Pose3, 6> {
static Vector6 Local(const Pose3& pose, ChartJacobian Hpose = boost::none);
};

static Matrix3 computeQforExpmapDerivative(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

static methods should be Capitalized in GTSAM

@@ -181,6 +181,9 @@ class GTSAM_EXPORT Pose3: public LieGroup<Pose3, 6> {
static Vector6 Local(const Pose3& pose, ChartJacobian Hpose = boost::none);
};

static Matrix3 computeQforExpmapDerivative(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please move the Doxygen string from .cpp to .h. Our convention is not to duplicate: if a functions is declared in the header, the docs go there, and not in the .cpp.

w.head<3>() = w.head<3>() * 0.09;
Matrix3 Qexact = Pose3::computeQforExpmapDerivative(w);
Matrix3 Qapprox = Pose3::computeQforExpmapDerivative(w, 0.1);
EXPECT(assert_equal(Qapprox, Qexact, 1e-5));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is tested against itself. How do we know the new coefficients are correct, vs the old ones?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the original implementation is kept but with a different function signature, then it is straightforward to show that the original implementation fails with this unit test. But I don't know if it is proper to keep the original implementation, say, in the unit test file as it looks messy. Do you have an alternative suggestion?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My suggestion would be to use numerical derivative (there are many examples on how to d- this with our specialized header).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All right, Sir. As I understand, Q is one block of the Jacobian of the SE3 Expmap. As you hinted, there are two ways to compute it: the analytical one by the function we are to test, and the numeric one by the powerful numericalDerivative in gtsam. By comparing the two results, we can tell if the function is working properly. If this is what you mean, I will go ahead and write up the unit test?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, a derivative check for Expmap may already exist, If so it’s just a matter of asserting that a test fails before your change and succeeds after your change. If there is no numerical derivative test yet for expmap then it should be added, and we would welcome that addition to GTSam :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright. I will add it soon.

@dellaert
Copy link
Member

dellaert commented Sep 25, 2020

Don’t you love unit tests?? :-) Is this now ready for merging in your opinion?

@JzHuai0108
Copy link
Contributor Author

Don’t you love unit tests?? :-) Is this now ready for merging in your opinion?

Absolutely, Sir. Unit tests are my faithful company when I am working alone on a repo. I think the pull request is ready to be merged.

@dellaert dellaert merged commit 79d6d5f into borglab:develop Sep 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugfix Fixes an issue or bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants