-
Notifications
You must be signed in to change notification settings - Fork 67
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
🌐 Spherical coordinates: bug fix, docs and sanity checks #235
Conversation
Signed-off-by: Louise Poubel <[email protected]>
Signed-off-by: Louise Poubel <[email protected]>
Signed-off-by: Louise Poubel <[email protected]>
Codecov Report
@@ Coverage Diff @@
## ign-math6 #235 +/- ##
==========================================
Coverage 99.39% 99.40%
==========================================
Files 66 66
Lines 6162 6185 +23
==========================================
+ Hits 6125 6148 +23
Misses 37 37
Continue to review full report at Codecov.
|
Signed-off-by: Louise Poubel <[email protected]>
Signed-off-by: Louise Poubel <[email protected]>
src/SphericalCoordinates_TEST.cc
Outdated
EXPECT_GT(xyzOrigin.Y(), xyz.Y()); | ||
} | ||
|
||
// Decrease longitude == go West == go -X (and a bit -Y) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it seems weird that a change to longitude in either direction causes Y to decrease slightly. I would have thought it would be linearized
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was also surprised to see this, I assumed it was an artifact of the projection and didn't look further into it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so I spent some time looking into this and I think I understand what's happening. This image should help:
Note that the ENU plane is tangent to the ellipsoid.
What this test is doing is changing lambda while keeping phi fixed. As you do that, the projection of the point onto the plane will only move on a straight line if you're exactly on the equator. If you're on the northern hemisphere, it goes further North (+Y) and if you're in the southern hemisphere, like on the test, it goes further South (-Y).
Here's a handy way of visualizing it, see how the projection of the blue line is not linear:
Signed-off-by: Louise Poubel <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe consider adding +/- altitude tests as well for completeness.
Signed-off-by: Louise Poubel <[email protected]>
Done in a8933ca |
* Migration guide and LOCAL2 Signed-off-by: Louise Poubel <[email protected]> Co-authored-by: Carlos Agüero <[email protected]> Co-authored-by: Steve Peters <[email protected]> Signed-off-by: Arjo Chakravarty <[email protected]>
/// There's a known bug with this computation that can't be fixed on | ||
/// version 6 to avoid behaviour changes. Directly call |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@scpeters The comments indicate that the behavior was only intended to be kept for gz-math6. However, it slipped through to gz-math7. Is there some will to straighten this up in 8, or will we live with this forever?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, we can fix it in gz-math8
can you open an issue or pull request to main
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good, I'll try the PR.
I've noticed another discrepancy in the interface: SphericalFromLocalPosition returns spherical coordinates in degrees, while PositionTransform uses radians. Shouldn't this be also united to using degrees everywhere? Or was there a reason for keeping it this way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think consistency would be preferred; it was probably oversight in the first place that caused them to diverge. A std::vector<math::Angle>
type would handle the units more clearly but it a little more overhead than Vector3d
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🦟 Bug fix
Fixes gazebosim/gazebo-classic#2022
Part of gazebosim/gz-sim#981
Summary
I believe that gazebosim/gazebo-classic#2022 is only an issue with the
*FromLocal*
functions. While the heading rotation fromGLOBAL
toLOCAL
seems to be correct, the rotation fromLOCAL
toGLOBAL
was not the inverse of that, which resulted in incoherent behaviour.In order to preserve behaviour on version 6, which is being used by a lot of people who compensate for the bug, I introduced a new frame,
LOCAL2
, which can be used to get the correct calculation.I also added several tests with sanity checks (i.e. higher latitude means further North...).
It's my first time playing with this class, so I'd appreciate it if people paid close attention to the math and test cases, in case I'm misunderstanding something.
Checklist
codecheck
passed (See contributing)Note to maintainers: Remember to use Squash-Merge
🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸🔸