Closed hendjoshsr71 closed 2 years ago
In general, the core developers are not interested in local regulations. However, there is no problem for your local regulation; WP0 provides the home location including the GPS altitude. So absolute altitude is already available in ianv firmware.
My question was in regards to this data structure that defines your mspSensorGpsDataMessage_t
message in the MSPV2 Protocol and not iNav itself. I'm not sure which project controls the protocol.
The MSPV2 protocol is used by many projects as users go between various autopilot software. https://github.com/iNavFlight/inav/blob/master/src/main/msp/msp_protocol_v2_sensor_msg.h#L62
Adding WGS84 would help users to continue to be able to use GPSs on that protocol when regulations require that info.
1.) DroneID requirements are not "local regulations" they are world wide -EU, USA, India, Japan, UK, Australia: I could go on....
2.) You misunderstand altitude frames. Having a absolute mean sea level altitude likely defined using the EGM96 geoid is not the same as providing the altitude in a WGS84 ellipsoid reference frame.
I will happily just mark all MSP GPSs noncompliant for ArduPilot users and move on. I was just creating an issue so you could think about the problem ahead of time.
I don't know where you got that information from. But in the EU and UK you certainly don't need remote ID with GPS coordinates.
As for "when" they're required here...hopefully never! When there are manned aircraft without the same requirements, it is not acceptable on model aircraft. Unless, of course, they also want to offer us benefits of using the system. Such as being able to fly BVLOS.
I'm hoping this is the right place for MSP Protocol discussion or someone can point me to it. :) While reviewing all GPS protocols in ArduPilot for compliance with OpenDroneID requirements I came across the MSPV2 protocol.
Current Behavior
From what I can tell the MSPV2 protocol does not have a field for either the WGS84 altitude or undulation with respect to AMSL altitude.
Desired Behavior
WGS84 altitude sent as part of the MSP GPS message and a flag such as INT32_T_MAX to represent WGS84 altitude is unavailable.
Suggested Solution
Not being familiar with the protocol I'm not sure if you can support extensions or not. Or if a new message or protocol version is required.
Who does this impact? Who is this for?
All USA drones in September 16, 2023. I'm unsure of the deadlines for other locales without going to look them up. After that time it will be illegal to takeoff without the WGS84 altitude being available.