amsl_origin and utm_origin now correctly use altitude from RTK instead of GNSS

[petrlmat]

Merge only when we verify that this works in real world. So far we have tested it in sim only.

• This concerns only EMLID RTK receivers. Holybro F9P is not affected as it is connected into pixhawk and not into NUC.
• So far, the amsl transformations (amsl_origin, utm_origin) published by transform_manager were based on the topic hw_api/altitude, which was based on the GNSS altitude reported by mavros/pixhawk.
• Now, when RTK is available (it is in the list of state estimators in custom config), the RTK altitude will be used instead.
• The altitude is using the tf fcu -> rtk_antenna to transform the measurements received by the antenna into the fcu frame, which is typically offset vertically on the drones.
• The fcu -> rtk_antenna tf was previously published from sensors.launch but I deleted the tf from the launch file because it is drone-specific and thus is the responsibility of the user to provide them in the tmux session. If the tf is not provided, transform manager will crash and inform the user to provide the tf.
• Affected tfs: fcu -> amsl_origin - contains only the amsl altitude (no xy position or orientation), fcu -> utm_origin - contains the amsl altitude, the xy position in the utm frame (latlon converted to meters), and the orientation.
• EMLID uses the WGS84 ellipsoid model for altitude and we don't do any conversion, so our altitude is also in WGS84. Pixhawk uses geographiclib to convert GNSS WGS84 data into some geoid model (one of EGM2008, EGM96, EGM84), so the altitude in hw_api/gnss (pixhawk) and hw_api/rtk (emlid) will differ by tens of meters (depending on the location).

[klaxalk]

@petrlmat Could you pls reflect the changes (the points in the PR) somewhere in the docs https://ctu-mrs.github.io/?

[petrlmat]

I'm thinking about how to communicate this and similar changes. I'm not sure if writing the changes directly into the documentation is the best approach. Shouldn't the documentation list only the current state of the system? I thought that the blog would be most useful for that and then maybe in changelog when a new stable version is released?

[klaxalk]

@petrlmat ye the blog would be the right place to document changes. The documentation allows versioning, so the the new state should be reflected in the "upcoming" version (I have not yet figured out how to properly distinguish the current unnumbered rolling version... now it is the right time to do it)...