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

Default SphericalCoordinates frame should be East-North-Up (ENU) #2022

Open
osrf-migration opened this issue Jul 28, 2016 · 9 comments · Fixed by gazebosim/gz-math#235
Open
Labels
all bug Something isn't working common major

Comments

@osrf-migration
Copy link

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).


The <spherical_coordinates> tag in sdformat declares itself to be using an East-North-Up (ENU) coordinate frame in spherical_coordinates.sdf (though rather indirectly, the language there should be clarified).

However, the gazebo SphericalCoordinates class appears to be using a West-South-Up (WSU) coordinate frame. I've committed a test in 67dde67 (branch spherical_coordinates_enu) showing the failure.

@osrf-migration
Copy link
Author

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).


  • set version to "all"

@osrf-migration osrf-migration added major common bug Something isn't working all labels Apr 19, 2020
@chapulina
Copy link
Contributor

Fixing the current behaviour in a minor / patch release would break existing code that is compensating for it, which we shouldn't do.

But luckily, the compensation just involves a 180 degree heading rotation like this:

    <spherical_coordinates>
        <!-- currently gazebo has a bug: instead of outputing lat, long, altitude in ENU
        (x = East, y = North and z = Up) as the default configurations, it's outputting (-E)(-N)U,
        therefore we rotate the default frame 180 so that it would go back to ENU -->
        <heading_deg>180</heading_deg>
    </spherical_coordinates>

@chapulina
Copy link
Contributor

I'm addressing this issue for ignition::math::SphericalCoordinates in gazebosim/gz-math#235. If that goes in, it could potentially be ported to gazebo::common::SphericalCoordinates.

@beaucolley
Copy link

beaucolley commented Oct 5, 2022

I find this hard to believe but this still seems to be an issue in both ignition::math::SphericalCoordinates and gazebo::common::SphericalCoordinates can anyone confirm?

@peci1
Copy link
Contributor

peci1 commented Jan 4, 2024

OMG lost a few hours debugging this on G11!!! Couldn't there be at least some warning in G11 when user code calls SphericalFromLocal etc.? And also when there is a subscriber to the default GPS sensor's output?

@traversaro
Copy link
Collaborator

Couldn't there be at least some warning in G11 when user code calls SphericalFromLocal etc.?

This is a bit trick, but doable. Gazebo Classic does not depend on any C++14 feature, but it compiles using the default version of C++ provided by the compiler, that is C++14 at least on GCC since GCC 6 (see https://gcc.gnu.org/gcc-6/changes.html). So we could just use some preprocessor logic to define a macro (for example in

, or even locally to the affected file) that is defined as [[deprecated(message)]] if the code is compiled with C++14, that will end to be defined on any reasonable modern system.

And also when there is a subscriber to the default GPS sensor's output?

That may be more tricky, I am not sure how we can achieve this.

@traversaro
Copy link
Collaborator

I find this hard to believe but this still seems to be an issue in both ignition::math::SphericalCoordinates and gazebo::common::SphericalCoordinates can anyone confirm?

Indeed the issue is still there in gazebo::common::SphericalCoordinates, and it is still there as default behaviour in ignition::math::SphericalCoordinates, even if in gazebosim/gz-math#235 a way to fix it by slightly changing the calling code was implemented.

@peci1
Copy link
Contributor

peci1 commented May 26, 2024

I find this hard to believe but this still seems to be an issue in both ignition::math::SphericalCoordinates and gazebo::common::SphericalCoordinates can anyone confirm?

Indeed the issue is still there in gazebo::common::SphericalCoordinates, and it is still there as default behaviour in ignition::math::SphericalCoordinates, even if in gazebosim/gz-math#235 a way to fix it by slightly changing the calling code was implemented.

I've just sent a fix for this to gz-math main branch: gazebosim/gz-math#596.

@peci1
Copy link
Contributor

peci1 commented Aug 22, 2024

A proper fix for this issue has landed into Gazebo Ionic: gazebosim/gz-math#616, gazebosim/gz-msgs#450 and gazebosim/gz-sim#2535 . I'll have a look at ways how to backport it into Classic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
all bug Something isn't working common major
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants