You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This will require a lot of work, but first we have to agree on what would be the plan.
I suggest to remove the use of UTM coordinates in favor of a mix between local coordinates (ENU/NED) and global coordinates.
Current situation
UTM coordinates are only used for fixedwings.
Rotorcrafts use NED coordinates for local flight, and ECEF for global coordinates.
Advantages of UTM coordinates:
cartesian (easy)
global
It makes its easy to compare two UAVs positions
but:
In the improbable, but anyway possible case of two UAVs that are not turned ON in the same UTM zone (if you are just at the border), comparing easting and northing will not make sense, you will have to do complex math.
The UTM coordinates in the south hemisphere are actually wrong ! 10000m must be added to northing.
The axis are not aligned with the north and east at your location. (except if you are exactly at the center of the zone)
Problems with NED coordinates, and how to deals with it
Positions of two UAVs with NED coordinates can be easily compared only if they share the same reference.
If needed, the GCS/Server could force UAVs to use the same reference, via a dedicated message.
The Z coordinate is not the same as the altitude, especially if you fly long range.
X and Y coordinates can be used for horizontal navigation only. Vertical navigation would use HMSL/ellipsoid alt.
plans for future (to be improved)
UTM could be removed, and fixedwing would use local NED coordinates for 2D position, together with HMSL/ellipsoid alt for altitude.
Fixedwings and rotorcraft would use the same coordinates systems, same struct... (e.g. the struct waypoint).
This would also be a great occasion to clarify what alt are above geoide or above ellipsoid, this is not always very clear.
Doing this would be a great step in unifying fixedwing and rotorcraft firmwares, and would remove a lot of similar code.
I'm ok with removing UTM coordinates. We are also currently busy with flying our fixedwings using rotorcraft 'hybrid' code, this means that we aren't using UTM/fixedwing at all anymore. It also means that code like navigation, arming/safety etc. is similar and tested more often.
removal fine by me, in case someone would need UTM out (or in) for cooperation with e.g. JAUS systems one could still make a module. See also @fvantienen remark for the likely path to follow. If it is for the new GCS supporting UTM and is a lot of effort, then IMHO first leave it out and make it a feature request, and try to add it only when someone really uses it.
This will require a lot of work, but first we have to agree on what would be the plan.
I suggest to remove the use of UTM coordinates in favor of a mix between local coordinates (ENU/NED) and global coordinates.
Current situation
UTM coordinates are only used for fixedwings.
Rotorcrafts use NED coordinates for local flight, and ECEF for global coordinates.
Advantages of UTM coordinates:
It makes its easy to compare two UAVs positions
but:
Problems with NED coordinates, and how to deals with it
Positions of two UAVs with NED coordinates can be easily compared only if they share the same reference.
If needed, the GCS/Server could force UAVs to use the same reference, via a dedicated message.
The Z coordinate is not the same as the altitude, especially if you fly long range.
X and Y coordinates can be used for horizontal navigation only. Vertical navigation would use HMSL/ellipsoid alt.
plans for future (to be improved)
UTM could be removed, and fixedwing would use local NED coordinates for 2D position, together with HMSL/ellipsoid alt for altitude.
Fixedwings and rotorcraft would use the same coordinates systems, same struct... (e.g. the struct waypoint).
This would also be a great occasion to clarify what alt are above geoide or above ellipsoid, this is not always very clear.
Doing this would be a great step in unifying fixedwing and rotorcraft firmwares, and would remove a lot of similar code.
What do you think?
@fvantienen @gautierhattenberger @OpenUAS
The text was updated successfully, but these errors were encountered: