Add /tf_static publisher of the home position (world->map transform)

[Ryanf55]

Feature request

Is your feature request related to a problem? Please describe.

As a ROS user, I want to know the transform from "world" to "map" in ECEF. This is the location of "home" in ECEF, in other words the transform from the world origin to the local tangent plane that Ardupilot got a home position.

Describe the solution you'd like

• Add another topic published by static transforms of the home location.
• If home changes, publish a new transform
• Only publish when it changes

Describe alternatives you've considered

When integrating Ardupilot with other systems in DDS, you don't know where home is unless you snapshot the geopose data against the local filtered pose and calculate it. Back-calculating from these two topics is clunky.

Platform
[ ] All
[ ] AntennaTracker
[ ] Copter
[ ] Plane
[ ] Rover
[ ] Submarine

Additional context

Add to the same interface of #23393

[Georacer]

It would be nice to disambiguate, but I assume you don't actually want the Earth center to HOME transformation, but the Earth center to EKF ORIGIN transformation. These two are not the same.

So, given this image:

you want the transformation (translation, rotation) from $O_e$ to $O_n$?

Is it then this what you're looking for? https://en.wikipedia.org/wiki/Geographic_coordinate_conversion#From_geodetic_to_ECEF_coordinates
with the the rotation yaw component being the longitude and the pitch component being the latitude.

I don't know why you would need that, but yeah, I think it can be done.

[Ryanf55]

One use case is if you want to reference objects between UAV's that do not share a HOME position, while also using a cartesian coordinate system (handy for robotics algorithms due to homogonous transforms between frames make the vector math easier than geodetic).
Another use case is integration with Gazebo, which is a cartesian coordinate system. In order for a NavSatFix sensor in gazebo to give the correct results, while you supply a continual updated local position relative to home, and you want to use the FDM from AP, is making a call to set the spherical coordinate origin of the world, as explained here.

DDS currently uses the Home position to give its cartesian pose relative to it, which is a call to
AP::ahrs::get_relative_position_NED_home
That is the cartesian distance home point, which does not update unless the user requests it on the GCS like so.

As you hinted, the other origin in AHRS is the EKF origin,, and can be found with a call to
AP::ahrs::get_origin. From what I understand, the EKF origin moves at the autopilots discretion to maintain numerical precision. DDS doesn't report data in frame of the EKF AHRS origin because it would cause discontinuities in the state of the offboard data. This origin is considered an implementation detail of the autopilot.

I just got some great related info from @srmainwaring .

[Georacer]

One use case is if you want to reference objects between UAV's that do not share a HOME position, while also using a cartesian coordinate system (handy for robotics algorithms due to homogonous transforms between frames make the vector math easier than geodetic).

I think it would be easier to create a transform from each vehice's map to a virtual "global home" and ask for the transformations between those. Going through the center of the Earth to get that transform will likely lose you precision.
I don't remember how things are implemented, but if you can't have an individual map frame for each vehicle, you can for sure spawn them away from (0,0,0) so each locks its home somewhere differently.

Another use case is integration with Gazebo, which is a cartesian coordinate system. In order for a NavSatFix sensor in gazebo to give the correct results, while you supply a continual updated local position relative to home, and you want to use the FDM from AP, is making a call to set the spherical coordinate origin of the world, as explained here.

Does that mean that you want to provide lat/lon coordinates from SITL to Gazebo to drive the transformations? Again, probably using the local frame calculated by AP is better suited to a Cartesian world such as Gazebo.

[Ryanf55]

One use case is if you want to reference objects between UAV's that do not share a HOME position, while also using a cartesian coordinate system (handy for robotics algorithms due to homogonous transforms between frames make the vector math easier than geodetic).

I think it would be easier to create a transform from each vehice's map to a virtual "global home" and ask for the transformations between those. Going through the center of the Earth to get that transform will likely lose you precision. I don't remember how things are implemented, but if you can't have an individual map frame for each vehicle, you can for sure spawn them away from (0,0,0) so each locks its home somewhere differently.

If you have two vehicles across the globe sharing information, then sharing a home will lead to inaccuracies in the lower level positions of things each relative to each vehicle's map frame.
ROS REP-105's example tree only shares earth frame to handle this. Thus, TF recommends a "map" frame for each vehicle.

Another use case is integration with Gazebo, which is a cartesian coordinate system. In order for a NavSatFix sensor in gazebo to give the correct results, while you supply a continual updated local position relative to home, and you want to use the FDM from AP, is making a call to set the spherical coordinate origin of the world, as explained here.

Does that mean that you want to provide lat/lon coordinates from SITL to Gazebo to drive the transformations? Again, probably using the local frame calculated by AP is better suited to a Cartesian world such as Gazebo.

Yes, this works well in either coordinate system. When certain algorithms are written in geodetic space, then it's handy to be able to interface through the simulator through either interface. By supplying the static TF, it would allow simulator users to pick which coordinate system they want for their application, also allow them to have accurate global WGS-84 coordinates of simulator objects even if they do everything else in local cartesian which is handy for debugging against tools such as Google Earth that can read KML.

[Georacer]

Agreed. One thing I don't understand still:
If you plan to simulate in Gazebo vehicles that are very far away from each other (where having geodetic coordinates makes sense), how will you achieve that?
Can they both fit on the same ENU plane?
Or you plan to launch two Gazebo instances?

[Ryanf55]

Agreed. One thing I don't understand still: If you plan to simulate in Gazebo vehicles that are very far away from each other (where having geodetic coordinates makes sense), how will you achieve that? Can they both fit on the same ENU plane? Or you plan to launch two Gazebo instances?

I haven't figured that out yet, but can share some details when I do. It doesn't need to block this PR.