Feature Description
Proposal
QGroundControl currently supports region-specific Remote ID settings for FAA and EU.
I would like to add a China region option to the existing Remote ID settings path, based on the current MAVLink OpenDroneID message set.
The initial scope would be limited to:
- Add China as a selectable region of operation
- Reuse existing MAVLink OpenDroneID messages
- Add UI fields for China-specific identifier input
- Add validation for the identifier format where applicable
- Avoid introducing any vendor-specific protocol
- Avoid claiming full regulatory compliance
Motivation
Some users need to configure Remote ID information for China-region operation while still using the standard MAVLink OpenDroneID workflow.
This would keep the implementation aligned with the existing RemoteIDManager architecture instead of adding a separate protocol path.
Proposed implementation
The implementation would reuse:
- OPEN_DRONE_ID_BASIC_ID
- OPEN_DRONE_ID_SYSTEM
- OPEN_DRONE_ID_OPERATOR_ID
No MAVLink enum extension is planned in the initial version.
Question
Would this scope be acceptable for QGroundControl upstream, or should this remain in a custom downstream build?
Use Case
No response
Flight Stacks
No response
Vehicle Types
No response
Platforms
No response
Feature Description
Proposal
QGroundControl currently supports region-specific Remote ID settings for FAA and EU.
I would like to add a China region option to the existing Remote ID settings path, based on the current MAVLink OpenDroneID message set.
The initial scope would be limited to:
Motivation
Some users need to configure Remote ID information for China-region operation while still using the standard MAVLink OpenDroneID workflow.
This would keep the implementation aligned with the existing RemoteIDManager architecture instead of adding a separate protocol path.
Proposed implementation
The implementation would reuse:
No MAVLink enum extension is planned in the initial version.
Question
Would this scope be acceptable for QGroundControl upstream, or should this remain in a custom downstream build?
Use Case
No response
Flight Stacks
No response
Vehicle Types
No response
Platforms
No response