HomeChanged rounding errors

Hi folks,

I’m currently running an Anafi in Sphinx via Olympe. Lately I wondered about bad positioning of the Anafi: its state estimates (i.e. GPS values of PositionChanged) matched my targets, but when inspecting the simulation visually, the Anafi was far off the targets.

I tracked this down to a rounding error. We’d expect that HomeChanged reads out the tag <spherical_coordinates> in the .world file and adds the offset introduced by the spawning point (i.e. the tag in the .drone file together with the tag <spawn_point> in the .world file) and that should produce the actual position of the drone. However, the <spherical_coordinates> are rounded to 4 decimal places. That might sounds sufficient, but it actually introduces errors of up to 5m.

As an example, I spawned the drone in the origin of a .world frame with this GPS configuration:

<spherical_coordinates>
  <surface_model>EARTH_WGS84</surface_model>
  <latitude_deg>1.12345678</latitude_deg>
  <longitude_deg>1.0</longitude_deg>
  <elevation>1</elevation>
  <heading_deg>0</heading_deg>
</spherical_coordinates>

This produces a HomeChanged of

  • latitude: 1.1234600000000001
  • longitude: 1.0

which is approximately 5m too far north. All subsequent positions are hence shifted by 5m as well, which is not tolerable, e.g, in confined spaces.

My current workaround is to shift my <spherical_coordinates> to the next possible coordinate. Maybe someone can confirm that this is indeed a bug / not desired. Either way, I hope this post helps to prevent other people from falling into this trap as well.

Best,
Dominik

Hi Dominik,

Which version of sphinx/anafi are you using?
Would you be able to reproduce that issue with the real drone?

Hi Samuel,

thanks for getting back!

About my setup: sphinx --version returns
Parrot-Sphinx simulator version 1.8
Gazebo multi-robot simulator, version 7.0.1
and in my .drone file I use
http://plf.parrot.com/sphinx/firmwares/anafi/pc/latest/images/anafi-pc.ext2.zip
as my firmware.

I don’t see how this error can be reproduced on the real drone. In my eyes the problem lies in the incorrect usage of spherical coordinates in the simulated world. But on the real hardware I hope the drone references itself w.r.t. some global reference, and if that works in a given position it should as well work in any other. Or what do you think?

Hi Dominik,
After looking into this issue, it appears to be a limitation of sphinx1.8 / gazebo7.
Thank you for reporting it.
Samuel

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.